Zerowa faktura korygująca w Optimie – jak ją zaksięgować?

Zerowa faktura korygująca w Comarch ERP Optima może na pierwszy rzut oka wyglądać nietypowo, bo dokument nie zmienia wartości rozrachunku ani wyniku finansowego. Nie oznacza to jednak, że trzeba ją obsługiwać zupełnie inną ścieżką niż zwykłą korektę. Najczęściej księguje się ją tak samo jak pozostałe faktury korygujące, ale trzeba sprawdzić, czy schemat księgowy dopuszcza dokumenty o wartości 0,00.

Najpierw sprawdź sens wystawienia korekty zerowej

Warto zacząć od pytania, po co taka korekta została wystawiona. Czasem korekta zerowa ma znaczenie techniczne, porządkujące albo opisowe, np. koryguje dane, ale nie kwoty. Wtedy jej zaksięgowanie może mieć inny cel niż standardowe ujęcie wartości w kosztach, przychodach lub VAT.

Jeżeli dokument ma tylko zostawić ślad w obiegu, trzeba upewnić się, że przyjęty sposób księgowania jest zgodny z polityką księgową firmy. Jeżeli ma wpływać na ewidencję, należy sprawdzić, jakie zapisy powinny powstać mimo wartości zerowej.

Księgowanie jak zwykłej korekty, ale z kontrolą schematu

Co do zasady zerową fakturę korygującą można księgować tak samo jak pozostałe faktury korygujące. Problem pojawia się wtedy, gdy schemat księgowy zawiera warunki, które wymagają dodatniej albo ujemnej wartości dokumentu. W takim przypadku dokument z kwotą 0,00 może nie podpowiadać się do księgowania albo zostać pominięty przez automat.

Najczęściej trzeba sprawdzić, czy schemat nie filtruje dokumentów po wartości netto, VAT, brutto albo po rodzaju korekty. Jeśli taki warunek istnieje, schemat może wymagać dopisania obsługi korekt zerowych.

Definicja dokumentu i rodzaj księgowania

Drugim miejscem do sprawdzenia jest definicja dokumentu oraz ustawiony rodzaj księgowania. Jeżeli dokument nie zachowuje się jak standardowa korekta, może nie trafiać do tego samego procesu księgowania co pozostałe dokumenty.

W praktyce warto porównać zerową korektę z inną, prawidłowo zaksięgowaną korektą tego samego typu. Różnice w definicji, statusie, rejestrze albo ustawieniach dokumentu często szybko pokazują, dlaczego automat nie działa.

Gdy dokument nie podpowiada się do księgowania

Jeśli zerowa faktura korygująca nie pojawia się automatycznie do księgowania, nie oznacza to od razu błędu programu. Często system działa zgodnie z konfiguracją, a blokadą jest sam schemat księgowy. Można wtedy wskazać dokument ręcznie przy księgowaniu albo poprawić schemat tak, aby obsługiwał również przypadki zerowe.

Przy częstych korektach zerowych warto rozważyć osobny warunek albo osobny wariant schematu. Dzięki temu nie trzeba za każdym razem ręcznie analizować, dlaczego dokument nie został ujęty.

Kiedy poprawiać schemat księgowy?

Schemat warto poprawiać wtedy, gdy korekty zerowe pojawiają się cyklicznie i mają być obsługiwane w powtarzalny sposób. Jeżeli to jednorazowy przypadek, czasem wystarczy ręczne zaksięgowanie lub świadome pominięcie, ale tylko po weryfikacji z księgowością.

Najważniejsze jest to, żeby nie zmieniać schematu “na ślepo”. Warunki w schematach księgowych często obsługują wiele dokumentów, więc drobna zmiana może wpłynąć na standardowe faktury, korekty dodatnie, korekty ujemne albo dokumenty z innych rejestrów.

Perspektywa ELTE-S: problem zwykle leży w schemacie, nie w korekcie

Przy zerowych fakturach korygujących w Optimie najczęściej nie chodzi o to, że dokumentu nie da się zaksięgować. Chodzi raczej o to, że istniejący schemat księgowy nie przewidział przypadku dokumentu o wartości 0,00. Dlatego najlepsza diagnostyka to porównanie dokumentu z normalną korektą, sprawdzenie definicji dokumentu i przejrzenie warunków w schemacie księgowym.

Dopiero po takim sprawdzeniu można zdecydować, czy dokument księgować tak jak zwykłą korektę, wskazać go ręcznie, czy dopisać osobny warunek dla korekt zerowych.

Jeśli podobne wyjątki pojawiają się częściej, warto uporządkować schematy księgowe tak, żeby obsługiwały nie tylko standardowe faktury, ale też nietypowe przypadki bez ręcznych obejść.

Porozmawiajmy o usprawnieniach.

BF -> BR w Optimie nie zakłada nowych kontrahentów po imporcie – co sprawdzić?

W pracy rozproszonej Comarch ERP Optima, szczególnie przy imporcie z BF do BR, automatyczne zakładanie kontrahentów zależy nie tylko od jednego zaznaczonego parametru. System podczas importu analizuje dane kontrahenta, identyfikatory, istniejące kartoteki oraz ustawienia po stronie bazy Biura Rachunkowego. Dlatego sytuacja, w której dokumenty importują się, ale nowi kontrahenci nie są zakładani, najczęściej wymaga sprawdzenia danych wejściowych, parametrów importu, duplikatów NIP i logów.

Import BF -> BR działa według parametrów w bazie BR

Import pracy rozproszonej do BR odbywa się według parametrów ustawionych w Optimie po stronie BR. To właśnie tam należy weryfikować konfigurację importu, a nie tylko ustawienia po stronie źródła danych. Jeżeli w bazie BR parametry są inne niż zakłada użytkownik, system może nie tworzyć nowych kart kontrahentów mimo tego, że po stronie eksportu wszystko wygląda poprawnie.

Sprawdź identyfikator kontrahenta w danych z BF

Najważniejsze pytanie brzmi: po czym Optima rozpoznaje kontrahenta przy imporcie. Najczęściej będzie to NIP, ale w niektórych przypadkach może pojawić się PESEL albo inny identyfikator. Jeżeli dane przychodzą bez NIP, z błędnym NIP albo z formatem innym niż oczekiwany, program może nie założyć nowej karty albo może nie dopasować jej tak, jak oczekuje użytkownik. Warto sprawdzić jeden konkretny rekord z pliku lub importu i porównać go z kartoteką w BR.

<screen>

Jeżeli kontrahent o tym NIP już istnieje

Częsty scenariusz wygląda tak: użytkownik oczekuje założenia nowej karty, ale w bazie BR istnieje już kontrahent o tym samym NIP. Wtedy Optima może nie tworzyć kolejnego kontrahenta, tylko podpiąć importowany dokument do już istniejącej karty. To nie musi być błąd. Z punktu widzenia systemu założenie drugiej karty z tym samym NIP mogłoby prowadzić do bałaganu w rozrachunkach i kartotekach.

<screen>

Blokada tworzenia kontrahentów z tym samym NIP

W Optimie może działać blokada tworzenia nowych kart kontrahenta o tym samym NIP. Jeżeli taka blokada jest aktywna, import nie założy nowego kontrahenta, kiedy znajdzie już taki identyfikator w bazie. W biurach rachunkowych często jest to dobre zabezpieczenie, ale przy imporcie danych może tłumaczyć, dlaczego system nie zakłada nowych kontrahentów.

<screen>

Konfiguracja importu i log

Poza samym parametrem zakładania kontrahentów trzeba sprawdzić konfigurację importu w BR: rodzaj źródła, mapowanie pól, filtry oraz ustawienia decydujące o tym, czy kontrahent ma zostać utworzony, zaktualizowany czy tylko dopasowany. Jeżeli mapowanie pola NIP, nazwy albo typu kontrahenta jest niepoprawne, import może pominąć utworzenie kartoteki lub połączyć dokument z innym rekordem. Dużo informacji daje też log importu, bo często pokazuje, czy kontrahent został pominięty, dopasowany do istniejącej karty albo zablokowany przez regułę duplikatu NIP.

<screen>

Test na jednym prostym rekordzie

Jeżeli problem jest niejasny, najlepszy test to pojedynczy rekord kontrahenta, którego na pewno nie ma w bazie BR. Najlepiej użyć czystej bazy testowej albo przynajmniej kontrahenta z jednoznacznym NIP i prostymi danymi. Taki test pozwala odróżnić problem konfiguracji importu od problemu w danych wejściowych albo w dopasowaniu po NIP.

Perspektywa ELTE-S: najpierw dopasowanie po NIP, potem parametry importu

Przy problemach BF -> BR nie warto zaczynać od przypadkowego przestawiania opcji. Najpierw trzeba ustalić, co dokładnie widzi Optima: jaki NIP przychodzi z BF, czy taki kontrahent już istnieje w BR, czy działa blokada duplikatów i co pokazuje log importu. Dopiero po tej diagnostyce można bezpiecznie zmieniać parametry pracy rozproszonej, mapowanie pól albo zasady zakładania nowych kart kontrahentów.

Porozmawiajmy o usprawnieniach.

Podwójne pobieranie faktur z KSeF i podwójne naliczanie limitu – co sprawdzić?

Jeżeli Comarch ERP zaczyna od konkretnej daty podwójnie pobierać faktury z KSeF, a dodatkowo podwójnie nalicza je do limitu pobrań, warto potraktować temat jako problem diagnostyczny, a nie zwykłą pomyłkę użytkownika. Szczególnie ważna jest informacja, że faktury mają ten sam numer KSeF.

Taki objaw może oznaczać, że system ponownie odpytuje usługę KSeF dla tych samych identyfikatorów, że zmieniła się konfiguracja pobierania albo że po aktualizacji pojawił się problem w mechanizmie obsługi dokumentów.

Zacznij od daty, od której problem występuje

W tym przypadku kluczowa jest data 13 sierpnia. Jeżeli wcześniej pobieranie działało poprawnie, a od konkretnego dnia zaczęły pojawiać się duplikaty i podwójne naliczanie limitu, trzeba sprawdzić, co zmieniło się w tym czasie.

W pierwszej kolejności warto sprawdzić:

– czy była aktualizacja programu,

– czy zainstalowano poprawki automatyczne,

– czy zmieniano konfigurację KSeF,

– czy zmieniano schemat importu,

– czy zmieniła się baza docelowa albo firma, do której trafiają dokumenty,

– czy zaczęło działać dodatkowe automatyczne pobieranie w tle.

Sprawdź wersję programu i poprawki

Przy problemach KSeF bardzo ważna jest aktualna wersja programu. Warto zweryfikować, czy środowisko pracuje na najnowszej wersji 2026.5.1 ze wszystkimi poprawkami.

Jeżeli problem dotyczy ERP XL, również należy sprawdzić aktualną wersję i komplet poprawek dla konkretnego wydania. Problemy z KSeF po zmianach wersji często wymagają porównania działania przed i po aktualizacji.

Zawęź pobieranie do jednego dnia

Dobrym testem diagnostycznym jest pobranie dokumentów z bardzo wąskiego zakresu, np. z jednego dnia. Dzięki temu łatwiej ustalić, czy system faktycznie zapisuje dwa dokumenty z tym samym numerem KSeF, czy tylko wykonuje dwie operacje pobrania i podwójnie nalicza limit.

Warto porównać:

– numer KSeF,

– numer faktury,

– NIP kontrahenta,

– datę wystawienia,

– kwotę,

– miejsce zapisu dokumentu,

– log operacji pobrania.

Czy dokumenty rzeczywiście są zdublowane w bazie?

Nie zawsze “podwójne pobranie” oznacza, że w systemie powstały dwa identyczne dokumenty. Czasem użytkownik widzi jeden dokument, ale licznik pobrań spada dwa razy. Czasem dokument zapisuje się na dwóch listach albo w dwóch miejscach procesu.

Dlatego trzeba rozdzielić dwie rzeczy:

– czy powstaje duplikat dokumentu w bazie,

– czy podwójnie nalicza się samo użycie limitu KSeF.

To rozróżnienie jest kluczowe przed zgłoszeniem sprawy do serwisu.

Kiedy licencja KSeF powinna być pobierana?

Zgodnie z zasadą działania wskazywaną przez producenta, licencja powinna zostać pobrana przy pobraniu dokumentu z KSeF na listę zakupów albo sprzedaży, jeśli faktury wystawione do KSeF nie są w programie. Dalsze przeniesienie dokumentu do Handlu albo do rejestru VAT nie powinno już ponownie pobierać licencji.

Jeżeli w praktyce licznik spada drugi raz przy dalszym przenoszeniu dokumentu, warto udokumentować to na konkretnym przykładzie.

Sprawdź logi operacji KSeF

Przy powtarzalnym problemie niezbędne będą logi. Sama informacja “pobiera dwa razy” może być niewystarczająca, zwłaszcza jeśli trzeba zgłosić temat do Partnera albo serwisu producenta.

Do analizy warto przygotować:

– numer wersji programu,

– datę i godzinę pobrania,

– zakres dat pobierania,

– numer KSeF przykładowej faktury,

– informację, czy dokument zapisał się raz czy dwa razy,

– informację, ile razy zmniejszył się limit,

– logi komunikacji KSeF.

Weryfikacja pobrań w SQL Server Management Studio

Pomocniczo można sprawdzić logi bezpieczeństwa w bazie danych. W SQL Server Management Studio można użyć zapytania:

sql Select * from CDN.SecurityLogs

<screen>

Takie sprawdzenie powinien wykonywać administrator lub osoba, która wie, na jakiej bazie pracuje i jak bezpiecznie odczytywać dane. Nie należy wykonywać zmian w bazie bez kopii i bez świadomości skutków.

Kiedy zgłosić temat do Partnera lub serwisu?

Jeżeli po aktualizacji do najnowszej wersji i po sprawdzeniu konfiguracji problem dalej się powtarza, temat warto zgłosić z kompletem danych. Szczególnie jeśli ten sam numer KSeF powoduje podwójne pobranie albo podwójne naliczenie limitu.

Perspektywa ELTE-S: najpierw odróżnij duplikat dokumentu od duplikatu pobrania

W praktyce przy takich zgłoszeniach najważniejsze jest ustalenie, co dokładnie dubluje się w systemie. Jeśli dubluje się dokument, diagnozujemy ścieżkę importu i miejsce zapisu. Jeśli dubluje się tylko zużycie limitu, analizujemy operacje komunikacji z KSeF i logi pobrań.

Dopiero po takim rozróżnieniu można sensownie ocenić, czy problem wynika z konfiguracji, aktualizacji, automatu pobierającego czy błędu programu wymagającego zgłoszenia do producenta.

Porozmawiajmy o usprawnieniach.

Faktury sprzedaży z KSeF mają kwalifikację “Do archiwum” w Optimie – czy to błąd?

W Comarch ERP Optima faktury sprzedaży widoczne na liście KSeF mogą otrzymywać kwalifikację “Do archiwum”. Dla wielu użytkowników jest to zaskoczenie, szczególnie jeśli wcześniej dokumenty pojawiały się jako “Niezakwalifikowane” i były ręcznie przenoszone do rejestru VAT.

Warto jednak rozdzielić dwie sytuacje: faktury sprzedaży wystawiane w Optimie oraz faktury pobierane z KSeF jako dokumenty do dalszego ujęcia w księgowości.

Dlaczego faktura sprzedaży trafia do “Do archiwum”?

Jeżeli faktura sprzedaży została wystawiona w Optimie, to dokument źródłowy już istnieje w systemie, najczęściej w module Handel. Taka faktura po wysyłce do KSeF jest widoczna również na liście dokumentów KSeF, ale nie oznacza to, że trzeba ją ponownie przenosić do rejestru VAT.

Kwalifikacja “Do archiwum” jest w takim przypadku sygnałem, że dokument z KSeF nie powinien uruchamiać drugiego obiegu księgowego. Innymi słowy: faktura jest już w systemie i powinna być księgowana z miejsca, w którym została wystawiona.

Własnej sprzedaży z Optimy nie przenoś ponownie z KSeF do rejestru VAT

Jeżeli faktury sprzedaży są wystawiane w Optimie, powinny być przenoszone do rejestru VAT z modułu Handel, a nie ponownie z zakładki KSeF.

Przenoszenie własnej sprzedaży z KSeF do rejestru VAT może doprowadzić do zdublowania dokumentów albo płatności. System może potraktować fakturę pobraną z KSeF jako kolejny dokument, mimo że jej odpowiednik już istnieje w Handlu.

Skąd wzięła się wcześniejsza kwalifikacja “Niezakwalifikowane”?

Jeżeli wcześniej dokumenty miały status “Niezakwalifikowane”, mogło to wynikać z innego mechanizmu kwalifikacji, wcześniejszej wersji programu, ustawień procesu lub sposobu pracy na liście faktur z KSeF. Nie oznacza to automatycznie, że obecna kwalifikacja “Do archiwum” jest błędem.

W praktyce najważniejsze pytanie brzmi: skąd dana faktura ma trafić do księgowości?

Jeżeli została wystawiona w Optimie, właściwą ścieżką jest Handel -> Rejestr VAT / księgowanie zgodnie z przyjętym procesem. Jeżeli jest to dokument zewnętrzny, którego nie ma w systemie, wtedy kwalifikacja do dalszego przeniesienia ma sens.

Kiedy zmiana kwalifikacji może mieć sens?

Ręczne przywracanie dokumentu z “Do archiwum” do “Niezakwalifikowane” może być zasadne tylko wtedy, gdy firma świadomie chce obsłużyć dany dokument z poziomu KSeF i ma pewność, że nie istnieje on już w innym miejscu w Optimie.

Przed zmianą kwalifikacji warto sprawdzić, czy faktura nie jest już w module Handel, czy nie została zaksięgowana i czy nie wygenerowała płatności w preliminarzu. Bez tej kontroli łatwo zrobić duplikat.

Co sprawdzić w pierwszej kolejności?

Przy takim zgłoszeniu sprawdziłbym:

– czy faktury sprzedaży są wystawiane bezpośrednio w Optimie,

– czy są widoczne w module Handel,

– czy proces księgowania sprzedaży odbywa się z Handlu,

– czy po przeniesieniu z KSeF nie powstają duplikaty w rejestrze VAT,

– czy w preliminarzu nie pojawiają się zdublowane płatności,

– czy zmiana kwalifikacji jest rzeczywiście potrzebna.

Perspektywa ELTE-S: “Do archiwum” może chronić przed duplikatami

W przypadku własnych faktur sprzedaży wystawianych w Optimie kwalifikacja “Do archiwum” może być bardziej zabezpieczeniem niż problemem. Chroni przed sytuacją, w której ta sama faktura przechodzi przez system dwa razy: raz jako dokument handlowy, a drugi raz jako dokument pobrany z KSeF.

Dlatego zamiast szukać błędu wyłącznie w ustawieniach, warto przejrzeć cały obieg: wystawienie faktury w Handlu, wysyłkę do KSeF, księgowanie do rejestru VAT i generowanie płatności. Dopiero wtedy można ocenić, czy kwalifikacja faktycznie wymaga zmiany, czy po prostu system zapobiega dublowaniu danych.

Porozmawiajmy o usprawnieniach.

Błąd krytyczny przy instalacji wersji demo Optimy na Windows 10 – od czego zacząć?

Instalacja wersji demo Comarch ERP Optima powinna przejść standardowo, ale w praktyce na niektórych stanowiskach Windows 10 instalator potrafi zakończyć pracę błędem krytycznym. Jeżeli instalator zamyka się w trakcie procesu, przyczyny zwykle trzeba szukać w środowisku systemowym: brakujących komponentach, SQL Server, zabezpieczeniach Windows albo blokadzie ze strony programu ochronnego.

Bez dokładnej treści komunikatu z załącznika nie da się wskazać jednej pewnej przyczyny, ale można przejść przez najważniejsze punkty diagnostyczne.

Uprawnienia administratora – sprawdź, ale to nie zawsze główny trop

Pierwszy standardowy krok to uruchomienie instalatora jako administrator. Warto kliknąć prawym przyciskiem na plik instalacyjny i wybrać Uruchom jako administrator.

Jeżeli jednak już na początku procesu pojawia się monit Windows o zgodę na uruchomienie instalatora, a użytkownik go zatwierdza, sam brak uprawnień jest mniej prawdopodobną przyczyną. Wtedy bardziej podejrzane są brakujące komponenty systemowe albo problem z SQL.

Brakujące składniki systemowe .NET

Comarch ERP Optima i instalator mogą wymagać określonych komponentów systemowych. Na Windows 10 najczęściej warto zweryfikować .NET Framework oraz aktualizacje systemowe.

Jeżeli .NET jest wyłączony, uszkodzony albo Windows nie ma wymaganych poprawek, instalator może zatrzymać się błędem krytycznym. Dobrym krokiem jest uruchomienie Windows Update, sprawdzenie składników systemu oraz ponowne uruchomienie komputera przed kolejną próbą instalacji.

SQL Server i komponenty bazodanowe

Optima pracuje na bazie danych SQL, dlatego problem może pojawić się również na etapie instalacji lub konfiguracji SQL Server. Dotyczy to szczególnie stanowisk, na których wcześniej były inne wersje SQL, nieudane instalacje albo pozostałości po starszych środowiskach.

Warto sprawdzić, czy instalator próbuje doinstalować SQL, czy łączy się z istniejącą instancją, oraz czy w systemie nie ma konfliktu z poprzednią instalacją SQL Server. Przy ograniczonych informacjach to jeden z najważniejszych tropów.

Antywirus, Firewall i kontrola aplikacji

Program antywirusowy, Windows Defender albo firmowe zabezpieczenia mogą blokować instalator, szczególnie jeśli proces próbuje instalować usługi, komponenty SQL lub zapisywać pliki w katalogach systemowych.

Na czas instalacji warto sprawdzić, czy ochrona nie zablokowała pliku instalatora, a w środowisku firmowym skonsultować to z administratorem IT. Nie chodzi o trwałe wyłączenie zabezpieczeń, tylko o kontrolowaną instalację i ewentualne dodanie wyjątków.

Log instalatora i Podgląd zdarzeń Windows

Jeżeli instalator zamyka się z błędem krytycznym, najważniejsze są logi. Komunikat widoczny na ekranie bywa zbyt ogólny, ale w logach często widać konkretny komponent, na którym proces się zatrzymał.

Warto sprawdzić:

– logi instalatora,

– Podgląd zdarzeń Windows,

– błędy aplikacji z momentu instalacji,

– błędy instalacji SQL lub .NET,

– komunikaty antywirusa lub Windows Defender.

Co zrobić, gdy informacji jest za mało?

Jeżeli użytkownik ma tylko zrzut ekranu i ogólny komunikat “błąd krytyczny”, diagnostyka będzie ograniczona. Wtedy najlepiej zebrać kilka informacji: dokładny komunikat, wersję instalatora Optimy, wersję Windows 10, status aktualizacji systemu, informację czy SQL był już wcześniej instalowany oraz ewentualny wpis z Podglądu zdarzeń.

Dopiero po tym można zdecydować, czy naprawiać .NET, czyścić pozostałości SQL, zmieniać ustawienia zabezpieczeń, czy pobrać świeży instalator.

Perspektywa ELTE-S: najpierw środowisko, potem ponowna instalacja

Przy błędach krytycznych instalatora najgorsze jest klikanie instalacji wielokrotnie bez sprawdzenia przyczyny. Jeśli problem leży w brakującym komponencie .NET, uszkodzonej instalacji SQL albo blokadzie antywirusa, kolejne próby będą kończyć się podobnie.

Dlatego najlepiej najpierw sprawdzić środowisko Windows, komponenty .NET, SQL Server, zabezpieczenia i logi. Dopiero później ponawiać instalację wersji demo Optimy.

Porozmawiajmy o usprawnieniach.