/ By Mateusz Łukasiński / Baza wiedzy • Comarch BPM/ • • • • • • • / 0 Comments

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.

Skontaktuj się z nami

/ By Mateusz Łukasiński / Baza wiedzy • Comarch ERP Optima/ • • • • • • / 0 Comments

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.

Skontaktuj się z nami

/ By Mateusz Łukasiński / Baza wiedzy • Comarch BI Point/ • • • • • • • • / 0 Comments

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.

Skontaktuj się z nami

/ By Mateusz Łukasiński / Baza wiedzy • Comarch ERP Optima/ • • • • • • • / 0 Comments

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.

Skontaktuj się z nami

/ By Mateusz Łukasiński / Baza wiedzy • Comarch ERP Optima/ • • • • • • • • / 0 Comments

Pakiet medyczny dla studenta na zleceniu w Optimie – jak ustawić składnik?

Pakiet medyczny finansowany częściowo przez pracodawcę wydaje się prostym dodatkiem, dopóki nie pojawia się konkretny przypadek kadrowo-płacowy: student, umowa zlecenia i świadczenie, które trzeba poprawnie pokazać w wypłacie.

W Comarch ERP Optima nie warto wrzucać takiego świadczenia jako jednego ogólnego składnika. Jeżeli część finansuje pracodawca, a część student, system powinien mieć rozdzielone oba elementy. Dzięki temu łatwiej kontrolować opodatkowanie, potrącenie i prawidłowe powiązanie świadczenia z umową zlecenia.

Dlaczego potrzebne są dwa elementy?

W opisanym przypadku pakiet medyczny ma dwie strony rozliczenia. Pierwsza to dofinansowanie przez pracodawcę, czyli świadczenie stanowiące przychód związany z umową zlecenia. Druga to część finansowana przez studenta, którą trzeba ująć jako potrącenie.

Jeżeli połączysz oba mechanizmy w jednym elemencie, łatwo o błąd w rozliczeniu. System musi wiedzieć, która część zwiększa przychód, a która jest potrąceniem.

Element finansowany przez pracodawcę

Dla części finansowanej przez pracodawcę można wykorzystać standardowy element “Opieka medyczna (bez ZUS)”. Najbezpieczniej utworzyć jego kopię za pomocą skrótu Ctrl+Insert i dopiero na kopii dostosować ustawienia do konkretnego przypadku.

<screen>

Przy osobie zatrudnionej na podstawie umowy zlecenia kluczowa jest zakładka dotycząca podatków i deklaracji PIT. W tym miejscu należy ustawić pozycję “PIT-8B 6. Przychody z osobiście wykonywanej działalności, w tym umowy zlecenia”.

<screen>

To ważne, bo świadczenie nie jest rozliczane jak zwykły dodatek pracowniczy z etatu, tylko jako przychód związany z umową zlecenia.

Element potrącenia dla części finansowanej przez studenta

Dla części finansowanej przez studenta można wykorzystać standardowy element “Opieka medyczna (potrącenie)”. Ten element odpowiada za ujęcie kwoty, którą zleceniobiorca pokrywa samodzielnie.

<screen>

W praktyce oznacza to, że w wypłacie powinny pojawić się dwa logicznie odrębne zapisy: świadczenie po stronie przychodu oraz potrącenie po stronie finansowania przez studenta.

Powiązanie dodatku z umową zlecenia

Po skonfigurowaniu dodatku finansowanego przez pracodawcę trzeba powiązać go z właściwą umową zlecenia. Najpierw dodaj element do pracownika i zapisz zmiany. Po ponownym otwarciu dodatku pojawi się zakładka “Wypłacany z umowami”.

<screen>

Na tej zakładce należy użyć przycisku “+” i wskazać aktywną umowę zlecenia, z którą dodatek ma być rozliczany.

<screen>

To jeden z tych kroków, które łatwo pominąć. A jeżeli dodatek nie zostanie powiązany z umową, rozliczenie może nie zachować się tak, jak oczekujesz przy naliczaniu wypłaty.

Sprawdzenie kodu tytułu ubezpieczenia studenta

Przy studencie na umowie zlecenia trzeba dodatkowo zweryfikować kartotekę pracownika, szczególnie zakładkę 4. Ubezpieczenie. Kod tytułu ubezpieczenia powinien odpowiadać aktualnemu statusowi studenta.

<screen>

Kod ten jest wskazywany również przy konfiguracji umowy zlecenia, ale jego poprawność na kartotece pracownika ma znaczenie dla prawidłowego rozliczenia ubezpieczeń i świadczeń naliczanych razem z umową.

Perspektywa ELTE-S: mały składnik, duże ryzyko błędu w wypłacie

Pakiet medyczny to pozornie drobny element listy płac, ale w praktyce dotyka kilku obszarów naraz: przychodu, potrącenia, PIT, umowy zlecenia i statusu studenta. Jeżeli któryś z tych elementów zostanie ustawiony z rozpędu tak, jak dla etatu, rozliczenie może być niepoprawne.

Najbezpieczniejsze podejście to rozdzielić część finansowaną przez pracodawcę i część finansowaną przez studenta, sprawdzić pozycję PIT, powiązać dodatek z aktywną umową oraz zweryfikować kod tytułu ubezpieczenia. Dopiero wtedy naliczenie wypłaty będzie miało solidną podstawę.

Porozmawiajmy o usprawnieniach.

Skontaktuj się z nami