Zaliczka CIT-8 w Optimie nie dolicza przychodu – co sprawdzić?

Zdarza się, że przez kilka miesięcy zaliczka CIT działa poprawnie, a nagle w jednym okresie – np. za lipiec – Comarch ERP Optima nie dolicza przychodu. Na pierwszy rzut oka wszystko wygląda dobrze: konta są podpięte, konfiguracja wcześniej działała, a problem pojawił się dopiero teraz.

W takiej sytuacji nie warto zaczynać od przypadkowej przebudowy schematu. Najpierw trzeba ustalić, czy przychód faktycznie trafił do ksiąg w tym okresie i czy jest widoczny na obrotówce.

Krok 1 – sprawdź, czy przychód jest na obrotówce

Pierwsza rzecz do weryfikacji to obrotówka za okres, którego dotyczy zaliczka. Jeżeli zaliczka za lipiec nie dolicza przychodu, sprawdź, czy konta przychodowe mają obroty właśnie w lipcu.

Jeżeli przychodu nie ma na obrotówce, zaliczka CIT nie ma z czego go pobrać. Wtedy problem leży nie w samym wyliczeniu zaliczki, tylko w księgowaniu dokumentów.

Najczęstsze przyczyny są proste:

– faktury są wprowadzone tylko do rejestru VAT,

– dokumenty nie zostały zaksięgowane do księgi handlowej,

– zapisy trafiły do innego okresu,

– użyto innego konta przychodowego niż zwykle,

– schemat księgowy zaksięgował dokument inaczej niż w poprzednich miesiącach.

Krok 2 – jeżeli przychód jest na obrotówce, sprawdź schemat zaliczki

Jeżeli konta przychodowe mają obroty w danym okresie, a zaliczka CIT nadal nie pokazuje przychodu, trzeba przejść do schematu wyliczania zaliczki.

W tym miejscu należy sprawdzić, czy właściwe konta są podpięte do zestawienia/schematu CIT. Czasem problem nie wynika z tego, że konto nie jest podpięte w ogóle, tylko z tego, że lipcowe księgowanie trafiło na inne konto analityczne niż wcześniejsze miesiące.

Przykład: dotychczas przychody trafiały na konto 700-1, a w lipcu schemat księgowy użył konta 700-2 albo nowej analityki, której nie obejmuje definicja zaliczki. Na obrotówce przychód jest widoczny, ale zaliczka CIT go nie pobiera.

Krok 3 – sprawdź okres księgowania dokumentów

Jeżeli problem pojawił się tylko za jeden miesiąc, warto sprawdzić daty księgowania dokumentów sprzedażowych. Dokument może być wystawiony lub ujęty w VAT za lipiec, ale zaksięgowany do innego okresu w księdze.

To szczególnie ważne, gdy dokumenty były poprawiane, importowane z innego modułu albo księgowane zbiorczo. Zaliczka CIT bazuje na danych księgowych, więc sam zapis w VAT nie wystarczy.

Krok 4 – porównaj lipiec z poprzednim miesiącem

Jeżeli wcześniej wszystko działało, dobrym testem jest porównanie lipca z czerwcem. Sprawdź:

– czy przychody są na tych samych kontach,

– czy księgowania trafiły do tego samego typu zapisów,

– czy nie pojawiła się nowa analityka,

– czy schemat zaliczki obejmuje nowe konta,

– czy nie zmienił się schemat księgowania dokumentów sprzedaży.

Takie porównanie zwykle szybko pokazuje, czy problemem jest brak księgowania, zły okres, czy zakres kont w schemacie CIT.

Perspektywa ELTE-S: zaliczka CIT pokazuje tylko to, co ma poprawnie zaksięgowane

W takich sytuacjach najważniejsze jest rozdzielenie dwóch rzeczy: czy przychód istnieje w księgach, czy tylko powinien tam być. Jeżeli nie ma go na obrotówce, trzeba wrócić do dokumentów i księgowania. Jeżeli jest na obrotówce, ale nie trafia do zaliczki, trzeba sprawdzić definicję kont w schemacie wyliczenia CIT.

To dobry przykład, dlaczego w księgowości systemowej nie wystarczy samo „konto jest podpięte”. Trzeba jeszcze sprawdzić, czy realne zapisy z danego miesiąca trafiają dokładnie w zakres, który pobiera zaliczka.

Porozmawiajmy o usprawnieniach.

BPM zawiesza się przy generowaniu dokumentu do Optimy – co sprawdzić po aktualizacji?

Po aktualizacji Comarch DMS/BPM wszystko powinno działać szybciej i stabilniej, ale czasem dzieje się odwrotnie. Użytkownik generuje dokument do Comarch ERP Optima, system zaczyna mielić, zawiesza sesje BPM, a część osób widzi komunikat „Skontaktuj się z administratorem systemu”. Problem nie dotyczy jednego stanowiska, tylko wielu użytkowników naraz.

W takiej sytuacji nie warto zaczynać od ręcznego poprawiania dokumentów. Jeżeli generowanie do Optimy nagle zwolniło po aktualizacji, najpierw trzeba sprawdzić warstwę techniczną: generator dokumentów, sposób działania BPM, logowanie, IIS oraz zgodność wersji.

Sprawdź pliki generatora dokumentów do Optimy

Najczęstsza przyczyna po aktualizacji to niezgodne lub nieaktualne pliki generatora dokumentów do Optimy. Generator powinien być dobrany dokładnie pod wersję Comarch ERP Optima, z którą pracuje środowisko.

Pobierz z portalu Comarch generator C# zgodny z używaną wersją Optimy, a następnie podmień pliki generatora w katalogu BPM. Miejsce podmiany zależy od konfiguracji: w części środowisk dotyczy to wersji desktopowej, w innych aplikacji działającej na IIS.

Jeżeli BPM korzysta z niewłaściwych plików generatora, objawy mogą wyglądać jak zawieszenie systemu, bardzo długie generowanie dokumentu albo rozłączanie sesji użytkowników.

Sprawdź, czy BPM działa przez IIS czy lokalny plik EXE

Sposób diagnozy zależy od tego, jak uruchamiany jest mechanizm generowania dokumentów. Inaczej wygląda środowisko, w którym BPM działa przez serwer IIS, a inaczej instalacja, gdzie plik EXE działa lokalnie na każdym stanowisku.

Jeżeli środowisko działa przez IIS, po podmianie plików generatora warto wykonać restart serwera IIS. Jeżeli generator działa lokalnie, trzeba upewnić się, że odpowiednie pliki zostały podmienione na właściwych stanowiskach.

Dodaj ścieżkę do Optimy w zmiennej PATH

Po aktualizacji warto sprawdzić również zmienną środowiskową PATH. Jeżeli generator ma korzystać z komponentów Optimy, ścieżka do instalacji Optimy powinna być poprawnie dostępna w środowisku systemowym.

Brak właściwej ścieżki może powodować, że generator nie znajduje wymaganych bibliotek albo wykonuje operacje znacznie wolniej. Po zmianach w PATH warto zrestartować usługę, IIS lub serwer, zależnie od konfiguracji.

Przełącz logowanie z aplikacji na plik tekstowy NLog

Po aktualizacji Comarch BPM może ustawić domyślnie logowanie do aplikacji. Według praktyki wdrożeniowej potrafi to znacząco wydłużyć generowanie dokumentów do Optimy.

W wielu przypadkach przełączenie logowania z aplikacji na plik tekstowy NLog skraca czas generowania dokumentu do kilku sekund.

To ważny trop, gdy dokument ostatecznie się generuje, ale trwa to bardzo długo i blokuje pracę użytkowników. Wtedy problemem nie musi być sam dokument, tylko sposób logowania i obsługi procesu po stronie BPM.

Zrestartuj IIS i sprawdź efekt na szybko

Jeżeli BPM działa na IIS, szybkim testem jest restart serwera IIS i ponowne sprawdzenie generowania dokumentu. Nie rozwiązuje to przyczyny docelowo, ale pozwala ocenić, czy problem dotyczy zawieszonego procesu, usług lub zasobów serwera.

Jeżeli po restarcie następuje poprawa, warto iść dalej w stronę diagnostyki IIS, logów generatora, obciążenia serwera i konfiguracji środowiska.

Zaktualizuj BPM do wersji 2026.1.1 z aktualnym pakietem poprawek

Jeżeli środowisko pracuje na wersji 2026.0.1, warto rozważyć aktualizację BPM do wersji 2026.1.1 z aktualnym pakietem poprawek. W odpowiedziach eksperckich pojawia się wskazanie, że problemy z generowaniem dokumentów były poprawiane w nowszych wersjach.

Aktualizacja nie powinna być robiona „w ciemno” na produkcji. Najpierw dobrze jest sprawdzić pliki generatora, logowanie, IIS i logi, a następnie zaplanować aktualizację w kontrolowany sposób.

Perspektywa ELTE-S: BPM i Optima muszą działać jako jeden proces, nie dwa osobne światy

Generowanie dokumentu z BPM do Optimy to nie tylko kliknięcie w aplikacji. Pod spodem pracują wersje systemów, pliki generatora, środowisko IIS lub lokalne EXE, biblioteki Optimy, logowanie i uprawnienia serwerowe. Po aktualizacji jeden niezgodny element potrafi zatrzymać pracę wielu użytkowników.

Dlatego przy takich awariach warto diagnozować proces technicznie: zgodność generatora z wersją Optimy, sposób uruchomienia BPM, konfigurację PATH, ustawienia NLog, logi i wersję BPM. Dopiero wtedy można odróżnić jednorazowe zawieszenie od problemu konfiguracyjnego, który będzie wracał przy każdym generowaniu dokumentu.

Porozmawiajmy o usprawnieniach.

Błąd 5_26 w Optimie – dlaczego nie można zmienić kodów JPK na zatwierdzonym dokumencie?

Korekta JPK często zaczyna się od drobnej poprawki: błędna data, oznaczenie, kod JPK albo dane dokumentu, które trzeba uzupełnić przed ponowną wysyłką. Problem pojawia się wtedy, gdy dokument jest już zatwierdzony, a Comarch ERP Optima wyświetla komunikat: “5_26 – na zatw. dok. nie jest możliwa zmiana kodów JPK”.

W takiej sytuacji nie chodzi zwykle o sam plik JPK ani o błąd w deklaracji. System blokuje zmianę, ponieważ operator nie ma prawa edytować atrybutów lub kodów JPK na zatwierdzonych dokumentach.

Co oznacza komunikat 5_26?

Komunikat 5_26 informuje, że próbujesz zmienić kody JPK na dokumencie, który został już zatwierdzony, ale aktualny operator nie ma odpowiedniego uprawnienia.

To zabezpieczenie jest logiczne. Kody JPK wpływają na ewidencję i pliki wysyłane do administracji skarbowej, dlatego system nie pozwala każdemu użytkownikowi zmieniać ich na zamkniętych lub zatwierdzonych dokumentach.

Nadaj uprawnienie operatorowi

Aby umożliwić edycję kodów JPK na zatwierdzonych dokumentach, zaloguj się jako administrator albo osoba z pełnymi uprawnieniami. Następnie przejdź do konfiguracji operatorów: START – Konfiguracja – Program – Użytkowe – Operatorzy.

<screen>

Otwórz kartę operatora, który ma wykonywać korektę, i przejdź do zakładki Parametry – Wspólne. W tym miejscu trzeba zaznaczyć opcję “Zmiana atrybutów/kodów JPK na zatw. dok.”.

<screen>

Po zaznaczeniu parametru zapisz zmiany. Samo zaznaczenie uprawnienia w konfiguracji może nie wystarczyć, jeśli użytkownik cały czas pracuje w tej samej sesji programu.

Po zmianie uprawnień wyloguj się i zaloguj ponownie

Po zapisaniu parametru operator powinien wylogować się z Optimy i zalogować ponownie. Dopiero wtedy program odczyta nowe uprawnienia dla tego użytkownika.

To częsty szczegół, który jest pomijany. Użytkownik zaznacza parametr, wraca do dokumentu i nadal widzi blokadę, bo program pracuje jeszcze na poprzednim zestawie uprawnień.

Jeżeli nadal nie można zmienić kodów JPK

Jeżeli po nadaniu uprawnienia i ponownym zalogowaniu problem nadal występuje, trzeba sprawdzić dodatkowe blokady. Najważniejsze są dwa obszary: zamknięty okres oraz uprawnienia do rejestru lub modułu, w którym znajduje się dokument.

Dokument może być technicznie zatwierdzony, ale dodatkowo objęty blokadą wynikającą z zamknięcia okresu. Wtedy sama zgoda na zmianę kodów JPK na zatwierdzonych dokumentach może nie wystarczyć.

Warto też upewnić się, że operator ma dostęp do właściwego rejestru, modułu Handel lub obszaru, z którego pochodzi dokument. Jeżeli dokument został wystawiony lub przeniesiony z innego modułu, ograniczenia operatora mogą nadal blokować zmianę.

Perspektywa ELTE-S: korekty JPK wymagają kontroli uprawnień, nie przypadkowego klikania

Błędy przy korektach JPK często wynikają nie z braku wiedzy księgowej, tylko z konfiguracji uprawnień w systemie. Operator wie, co trzeba poprawić, ale system nie pozwala tego zrobić, bo dokument jest zatwierdzony, okres zamknięty albo dostęp do danego modułu jest ograniczony.

Dlatego przy obsłudze JPK warto mieć jasno ustawione role operatorów: kto może zmieniać kody JPK, kto może pracować na zatwierdzonych dokumentach, a kto tylko wprowadza dane bieżące. To ogranicza chaos przy korektach i zmniejsza ryzyko przypadkowych zmian w dokumentach, które już trafiły do rozliczeń.

Porozmawiajmy o usprawnieniach.

Błędne dane o płatnościach w BI – dlaczego raport pokazuje zapłacone faktury jako niezapłacone?

Raport płatności działał przez lata poprawnie. Pokazywał faktury niezapłacone, filtrował dokumenty według ustalonego pola stanu i był używany jako stałe narzędzie kontroli należności. Nagle zaczyna pokazywać faktury sprzed kilku lat, które dawno zostały zapłacone i wcześniej w ogóle nie pojawiały się w tym zestawieniu.

Jeżeli podobny błąd występuje jednocześnie w kilku raportach BI, nie warto zaczynać od poprawiania każdego raportu osobno. Bardziej prawdopodobne jest to, że zmienił się zakres danych źródłowych, sposób odświeżenia danych albo logika modelu BI, z którego te raporty korzystają.

Najpierw sprawdź konkretną fakturę w Optimie

Pierwszy krok to wybranie jednego błędnego dokumentu z raportu BI i sprawdzenie go bezpośrednio w Comarch ERP Optima. Chodzi o prostą weryfikację: czy faktura faktycznie jest rozliczona w systemie źródłowym.

Jeżeli w Optimie dokument ma status Rozliczono całkowicie, a wartość Pozostaje wynosi 0,00, to faktura po stronie ERP wygląda poprawnie. W takim przypadku raport BI nie powinien traktować jej jako otwartej należności.

To zawęża diagnozę. Problem nie leży wtedy w samej płatności na dokumencie, tylko w tym, jak BI pobrało, odświeżyło albo przeliczyło dane.

Porównaj status w ERP z tym, co widzi BI

Najlepiej zrobić porównanie na jednym konkretnym przykładzie. Po jednej stronie sprawdzasz status dokumentu w Optimie, po drugiej to, co widzi model lub raport BI.

Jeżeli ERP pokazuje dokument jako w pełni rozliczony, a BI nadal pokazuje należność, trzeba ustalić, na którym etapie dane się rozjeżdżają. Może to być warstwa źródłowa, odświeżenie modelu, definicja atrybutu, miara odpowiedzialna za stan płatności albo filtr użyty w raporcie.

Sprawdź, czy po aktualizacji nie zmieniła się logika modelu

Jeżeli problem pojawił się „od jakiegoś czasu”, warto sprawdzić, czy w tym okresie nie było aktualizacji, zmian administracyjnych albo ponownego odświeżenia historii danych. Szczególnie ważne są pola używane w filtrach raportu, np. pole „stan”.

Zmiana definicji atrybutu lub miary może sprawić, że raport formalnie nadal ma ten sam filtr, ale filtruje już dane interpretowane inaczej niż wcześniej. Dla użytkownika wygląda to tak, jakby raport „nagle się zepsuł”, choć faktyczna przyczyna może leżeć w modelu danych.

Możliwy problem z odświeżeniem lub przeliczeniem historii

Jeżeli dawno zapłacone faktury zaczęły wracać do raportów, trzeba sprawdzić również proces odświeżenia danych. BI mogło ponownie wczytać historię, przeliczyć zaległości albo zmapować płatności po innym kluczu niż wcześniej.

W takim scenariuszu pojedyncza faktura jest tylko objawem. Jeżeli błędy pojawiają się po kilka sztuk w kilku różnych raportach, bardziej podejrzany jest wspólny model danych niż ręczny błąd na konkretnym dokumencie.

Dziennik zmian i konfiguracja administratora BI

Warto sprawdzić, czy administrator BI nie zmieniał w ostatnim czasie konfiguracji raportu, modelu, źródeł danych lub harmonogramu odświeżania. Nawet drobna zmiana w definicji pola używanego w kilku raportach może dać efekt widoczny w wielu zestawieniach jednocześnie.

Jeżeli raporty były stabilne przez lata, a problem pojawił się nagle, historia zmian jest jednym z najważniejszych miejsc do sprawdzenia.

Perspektywa ELTE-S: raport BI jest tak dobry, jak jego model danych

Raporty BI często wyglądają jak gotowe zestawienia, ale ich wiarygodność zależy od warstwy danych pod spodem. Jeżeli model źle interpretuje status płatności, raport może pokazywać zaległości, których w ERP już nie ma. To szczególnie ryzykowne przy raportach należności, windykacji i kontroli płynności.

Dlatego przy takich błędach nie wystarczy ukryć pojedynczych faktur filtrem. Trzeba sprawdzić, czy dokumenty są poprawnie rozliczone w ERP, jak BI pobiera status płatności, czy model został poprawnie odświeżony i czy po aktualizacji nie zmieniła się logika miar lub atrybutów.

Porozmawiajmy o usprawnieniach.

Jak szybko przenieść historię kadrowo-płacową do Optimy przy przejmowaniu nowego klienta?

Przejęcie obsługi kadrowo-płacowej nowego klienta często zaczyna się od pytania: co zrobić z historią pracowników, którzy są zatrudnieni w firmie od wielu lat?

W praktyce nie są to tylko dane archiwalne. W Comarch ERP Optima informacje z poprzednich okresów mogą być potrzebne później m.in. do naliczania wynagrodzenia chorobowego, wynagrodzenia urlopowego, ustalenia stażu pracy czy przygotowania świadectwa pracy. Przy pracownikach z 10-20-letnią historią ręczne uzupełnianie wszystkiego od początku zatrudnienia byłoby czasochłonne i podatne na błędy.

Dlatego przy takim wdrożeniu kluczowe jest nie tyle przepisywanie danych, ile dobrze zaplanowana migracja.

Nie zawsze trzeba uzupełniać wszystko ręcznie od początku zatrudnienia

Najbezpieczniejszym podejściem jest wykorzystanie mechanizmów przygotowanych z myślą o migracji danych do systemu. Partnerzy Comarch mają dostęp do narzędzi i procedur, które pozwalają zaimportować do Optimy niezbędne dane historyczne w uporządkowany sposób.

W takim modelu nie tworzy się historii na piechotę rekord po rekordzie, tylko przygotowuje dane w odpowiedniej strukturze. Najczęściej odbywa się to przez arkusze migracyjne, które można uzupełnić na podstawie eksportu z dotychczasowego systemu kadrowo-płacowego.

To znacząco skraca czas pracy i zmniejsza ryzyko pomyłek.

Jakie dane warto przenieść w pierwszej kolejności?

Zakres migracji powinien wynikać z tego, do czego dane będą potrzebne w bieżącej obsłudze. Najważniejsze są informacje, które wpływają na poprawne naliczanie wynagrodzeń i obowiązki pracodawcy.

W praktyce należy zwrócić uwagę m.in. na:

– dane pracownika i przebieg zatrudnienia,

– informacje potrzebne do wyliczania podstaw chorobowych,

– dane urlopowe i limity urlopów,

– składniki wynagrodzeń istotne dla dalszych naliczeń,

– absencje i okresy nieobecności,

– dane potrzebne do wystawienia świadectwa pracy,

– informacje podatkowe i ubezpieczeniowe, jeśli są wymagane do dalszej obsługi.

Nie zawsze trzeba przenosić pełną historię w maksymalnym możliwym zakresie. Ważne jest, żeby przenieść dane konieczne do poprawnej pracy systemu i zgodnej obsługi kadrowo-płacowej od momentu przejęcia klienta.

Dlaczego arkusze migracyjne są szybsze niż ręczne uzupełnianie?

Arkusze migracyjne porządkują dane przed importem. Dzięki temu można sprawdzić kompletność informacji, wychwycić braki i przygotować dane w formacie akceptowanym przez system.

Jeśli poprzedni system pozwala na eksport danych, duża część pracy polega na odpowiednim przemapowaniu informacji do arkuszy. To zwykle znacznie szybsze niż ręczne zakładanie pełnej historii dla każdego pracownika bezpośrednio w Optimie.

Dodatkową zaletą jest możliwość kontroli jakości przed importem. Zamiast odkrywać błędy dopiero przy naliczaniu wypłaty, można wcześniej sprawdzić strukturę danych, braki i pola wymagające uzupełnienia.

Perspektywa ELTE-S: migracja danych kadrowych to etap wdrożenia, nie ręczna przepisywanka

Przy przejmowaniu nowego klienta najważniejsze jest ustalenie, jakie dane faktycznie muszą znaleźć się w Optimie, skąd je pozyskać i jak bezpiecznie je zaimportować. Dobrze przygotowana migracja pozwala uniknąć chaosu w pierwszych miesiącach obsługi i ogranicza ryzyko błędów przy naliczaniu wynagrodzeń.

Jeżeli firma lub biuro rachunkowe przejmuje nową obsługę kadrowo-płacową i chce sprawnie przenieść historię pracowników do Comarch ERP Optima, warto podejść do tego jako do małego projektu migracyjnego: eksport danych, przygotowanie arkuszy, weryfikacja, import i kontrola poprawności.

Porozmawiajmy o usprawnieniach.