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

Schemat księgowania listy płac w Comarch ERP – jak rozdzielić koszty pracownika na różne “piątki”?

Znasz tę sytuację? Księgujesz listę płac i musisz rozbić wynagrodzenie części zespołu na różne centra kosztowe (tzw. “piątki”). Konfigurujesz schemat księgowy, dodajesz pozycje, ale przy księgowaniu system nie łapie wyjątków i księguje wszystko błędnie lub zatrzymuje się z błędem. To jeden z najczęstszych problemów na styku kadr i księgowości.

Wbrew pozorom, rozwiązanie tego problemu nie sprowadza się tylko do wpisania odpowiedniego konta “po Wn” w jednym wierszu schematu. Wymaga zrozumienia, jak system Comarch traktuje składniki wynagrodzeń.

Dwie kluczowe kwestie do ustalenia przed budową schematu

Zanim zaczniesz modyfikować warunki w oknie schematów księgowych, musisz odpowiedzieć sobie na dwa krytyczne pytania:

1. Czy proporcja rozksięgowania (podziału) jest stała dla tych konkretnych pracowników? (np. zawsze 50/50, albo 70/30).

2. Czy konta zespołu 5 posiadają analitykę rodzajową? A jeśli tak, to czy są to różne analityki w odniesieniu do składników wynagrodzeń i wszystkie mają być odpowiednio podzielone?

Odpowiedzi na te pytania zdeterminują, z której ścieżki wdrożeniowej musisz skorzystać.

Ścieżka 1: Proporcja podziału jest stała

Jeśli odpowiedź na pierwsze pytanie brzmi “TAK” (czyli podział dla tych 10 pracowników jest z góry ustalony i niezmienny), sprawa jest stosunkowo prosta.

Możesz wprowadzić w schemacie stałą proporcję. Należy wtedy oprzeć schemat księgowania na poziomie pracownika, stosując warunek PIE_Znacznik = 'P'. Wewnątrz schematu wprowadzasz odrębne pozycje dla wybranych akronimów (czyli konkretnych pracowników).

W praktyce wygląda to tak: księgujesz pełną kwotę dla pozostałych pracowników na standardowe konta zespołu 5, a dla tej wybranej “dziesiątki” system stosuje zapisaną na sztywno proporcję na wymagane konta.

Ścieżka 2: Proporcja podziału jest zmienna

Jeżeli proporcja jest zmienna (czyli co miesiąc zależy od innych czynników), pojawia się problem. Musisz sprawdzić, czy w module Kadry i Płace w ogóle generowany jest jakikolwiek opis analityczny dla wynagrodzenia, z którego wynika ten podział.

Jeśli opis analityczny istnieje, lecz w księgowości stosujesz podział na konta zespołu 5 z analityką rodzajową – trafisz na systemowy mur. Comarch ERP na tym etapie nie pozwala na tak precyzyjny podział wynagrodzenia. Możesz co najwyżej rozbić kwoty na zgrubne kategorie: Brutto, ZUS i PPK. System nie wyodrębni samodzielnie poszczególnych, drobnych składników wynagrodzenia na różne analityki.

Jak z tego wybrnąć? Klucz podziałowy

Finalnie, jeśli proporcja kosztów jest zmienna, a konta zespołu 5 posiadają analitykę rodzajową, najlepszym i najbezpieczniejszym podejściem jest proces dwuetapowy:

1. Zaksięguj całą Listę Płac bez wyodrębniania tych pracowników (lub dla ułatwienia księgowań zaksięguj ten koszt technicznie na jedno, odrębne konto przejściowe).

2. Użyj klucza podziałowego, który rozksięguje zgromadzoną kwotę na właściwe konta docelowe.

Klucz podziałowy to potężne narzędzie – może on zaciągać dane z dowolnego źródła. Informacje o odpowiednich proporcjach mogą płynąć bezpośrednio z Comarch ERP XL, modułu HR, czy nawet z zewnętrznej aplikacji. Kwestią do ustalenia pozostaje tylko wybór odpowiedniej metody dostarczenia tych danych do bazy.

Perspektywa ELTE-S: Nie rzeźb w schematach bez planu

Konfiguracja schematów księgowych na styku z listami płac to jeden z najbardziej narażonych na błędy obszarów. Próby tworzenia “kombinowanych” warunków na siłę zazwyczaj kończą się tym, że przy pierwszym nietypowym składniku wynagrodzenia schemat po prostu się sypie, a koszty lądują w niewłaściwych miejscach.

Jeśli Twój podział analityczny jest skomplikowany i schematy przestały sobie z tym radzić, chętnie przeanalizujemy to na żywym organizmie. Możemy ułożyć odpowiednie warunki dla stałych proporcji lub zaprojektować automatyczne klucze podziałowe pod Twoją unikalną strukturę “piątek”.

Skontaktuj się z nami

/ By Mateusz Łukasiński / Baza wiedzy • Produkty ELTE-S/ • • • • • / 0 Comments

Automatyzacja zwrotów z BaseLinkera w Comarch ERP Optima – jak uniknąć ręcznych korekt?

Znasz tę sytuację? Zamówienia spływają automatycznie, paragony i faktury wystawiają się same, ale gdy klient zwraca paczkę, cały proces zwalnia i wymaga ręcznej interwencji. Pracownik przyjmuje zwrot w module RMA w BaseLinkerze, klika zwrot środków (np. przez Allegro), a następnie w księgowości ktoś i tak musi ręcznie odszukać dokument w Optimie, skorygować ilości i ustawić odpowiedni sposób płatności. To wąskie gardło, które bardzo często pozostaje niezałatane w wielu firmach e-commerce.

Czy można w pełni zamknąć i zautomatyzować ten proces?

Automatyczne korekty paragonów i faktur – jak to działa?

Integrator ELTE-S BaseLinker Sync pozwala na zautomatyzowanie ostatniego ręcznego ogniwa. Narzędzie zostało wyposażone w dedykowany moduł korekt, który śledzi moduł zwrotów (RMA) po stronie platformy BaseLinker.

Generowanie dokumentu korygującego (czy to do paragonu, czy do faktury) wyzwalane jest odpowiednim statusem zwrotu. Kiedy pracownik zweryfikuje paczkę i zmieni status w BaseLinkerze, łącznik samodzielnie tworzy stosowny dokument w Comarch ERP Optima.

Ważne jest to, że system obsługuje korekty częściowe. Oznacza to, że korekta tworzy się precyzyjnie w oparciu o produkty (i ich ilości), które fizycznie znalazły się w zewidencjonowanym zwrocie.

Powrót danych do Base. (PDF i numer dokumentu)

Wystawienie dokumentu księgowego to połowa sukcesu, ale dział e-commerce musi mieć do niego podgląd, by chociażby obsłużyć akcje automatyczne i komunikację z klientem.

Nasz łącznik, po poprawnym wygenerowaniu korekty w Optimie, potrafi pobrać jej numer oraz plik PDF, a następnie przekazać je z powrotem do BaseLinkera. Zgodnie z najlepszymi praktykami, pliki PDF dla korekt z modułu RMA dodawane są jako załączniki do pola dodatkowego w samym zwrocie. Z kolei PDF-y standardowych dokumentów sprzedażowych trafiają do pola dodatkowego lub dedykowanej sekcji w panelu zamówień.

Jeśli chcesz, aby dokument automatycznie trafiał do klienta w mailu z informacją o zwrocie, wystarczy w Base. zmodyfikować szablon emaila – po prostu wskazujesz, by system zaciągał plik ze wspomnianego pola dodatkowego.

Dokładne ustawienia tego mechanizmu można podejrzeć w oficjalnej dokumentacji: Instrukcja modułu korekt Premium (PDF).

Perspektywa ELTE-S: Zamknij proces e-commerce w 100%

Zostawianie korekt jako “ostatniego ręcznego ogniwa” to bardzo częsty błąd we wdrożeniach systemów e-commerce z programami klasy ERP. W okresach poświątecznych lub przy wzmożonych zwrotach sezonowych księgowość traci dziesiątki godzin na mozolne przeklikiwanie dokumentów, a ryzyko ludzkiej pomyłki (szczególnie przy przepisywaniu kwot) drastycznie rośnie.

Jeśli Twój proces obsługi Allegro i własnego sklepu jest już rozbudowany po stronie BaseLinkera, nie warto marnować potencjału. Poprawna konfiguracja łącznika i modułu RMA gwarantuje, że procesy magazynowe i księgowe w Comarch ERP Optima będą toczyć się całkowicie w tle.

Jeżeli potrzebujesz pomocy we wdrożeniu synchronizacji pod swoje scenariusze zwrotów, nasz zespół z chęcią przeanalizuje Twój proces.

Skontaktuj się z nami

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

“Nie udało się wykryć wersji SQL Server” – problemy przy aktualizacji Comarch ERP Optima

Znasz tę sytuację? Planujesz aktualizację systemu do najnowszej wersji (np. 2026.5.1). Robisz backup, pobierasz instalator z serwerów Comarch, uruchamiasz proces, a na wszystkich stanowiskach pojawia się niespodziewany komunikat ostrzegawczy: “Nie udało się wykryć wersji SQL Server”.

Frustracja rośnie, zwłaszcza gdy środowisko opiera się na stabilnym Microsoft SQL Server 2017, a wcześniejsze uaktualnienia oprogramowania przechodziły zupełnie bezszelestnie. Skąd bierze się ten problem po stronie nowej Optimy?

Dlaczego system nie widzi poprawnej bazy?

Wielu informatyków i użytkowników w pierwszej kolejności szuka winy w braku najnowszych, drobnych poprawek dla serwera Windows lub samego SQL-a (tzw. Cumulative Update). W praktyce jednak wersja CU nie ma tutaj żadnego znaczenia. Instalator Optimy nie odrzuca środowiska przez brak drobnej łatki.

Nowe wydania Comarch ERP Optima mają po prostu podniesione wymagania co do samej bazowej wersji silnika MSSQL (2014, 2016, 2017, 2022 itd.) oraz zmieniony mechanizm jej wykrywania.

Jeśli Twój serwer to faktycznie Microsoft SQL Server 2017 (który obecnie stanowi minimalny rygorystyczny próg), a błąd i tak występuje, przyczyna leży w warstwie komunikacyjnej. Należy wtedy głęboko wejść w logi instalatora Optimy i zweryfikować sposób, w jaki system próbuje połączyć się z instancją. Najczęściej problemem okazują się zablokowane porty, błędnie rozwiązywana nazwa instancji w sieci lub brak odpowiednich uprawnień administracyjnych (np. po stronie konta instalującego uaktualnienie).

Co ze starszymi serwerami? Wymagania dodatków autorskich

Komunikat o niewykrytej wersji serwera to też doskonały moment na weryfikację całej infrastruktury IT. Comarch nieustannie podnosi poprzeczkę, a wraz z nim robią to firmy tworzące rozwiązania zintegrowane.

Jako zespół ELTE-S jasno komunikujemy naszym klientom: nasze autorskie dodatki do Optimy nie działają już na wersjach starszych niż SQL 2017.

Dlaczego?

Ponieważ w najnowszych systemach e-commerce, rozwiązaniach WMS czy narzędziach do automatyzacji korzystamy z zaawansowanych funkcji T-SQL. Starsze edycje bazy (np. popularny kiedyś SQL 2014) po prostu nie obsługują nowych metod wymiany danych.

Pozostawienie skrajnie przestarzałej bazy danych podczas aktualizacji ERP do najnowszych wydań to krótka droga do tego, by z dnia na dzień przestały działać kluczowe automatyzacje w Twojej firmie.

Zróbmy audyt Twojego środowiska

Zamiast siłowo “przepychać” aktualizację, warto oddać sprawę w ręce specjalistów, którzy odczytają logi i precyzyjnie wskażą wąskie gardło.

Masz problemy ze stabilnością aktualizacji, komunikacją z SQL Server lub chcesz upewnić się, że najnowsza Optima zadziała z Twoimi dodatkami? Pomożemy w zdalnej weryfikacji środowiska przed kolejną próbą uaktualnienia.

Skontaktuj się z nami

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

Przywracanie rezerwacji po korekcie i modyfikacji ZK w Comarch ERP XL – gdzie leży błąd?

Znasz tę sytuację? Proces kompletacji jest w toku, wystawiasz Zlecenie Kompletacji (ZK), do niego generujesz Rozchód Wewnętrzny (RW), potem okazuje się, że trzeba to skorygować, więc robisz RWK. Nagle anulujesz RWK, modyfikujesz ZK dodając nowy towar, zamykasz dokument, i w systemie pojawiają się rezerwacje widmo na towary, które przecież dawno zeszły ze stanu.

Chaos na magazynie gotowy. Zastanawiasz się, czy to wina konfiguracji, czy może system sam z siebie generuje podwójne rezerwacje. Jednak gdy zaczynamy badać logikę tego obiegu i działanie API w Comarch ERP XL, szybko okazuje się, że to nie wina samego systemu, a najprawdopodobniej Twojej zewnętrznej integracji.

Jak naturalnie działa obieg ZK i RW w ERP XL?

Podczas standardowego zatwierdzania Zlecenia Kompletacji (ZK), Comarch ERP XL automatycznie generuje rezerwacje na wszystkie potrzebne składniki towaru. Kiedy praca rusza i robimy dokument RW (rozchód składników), system naturalnie ściąga rezerwacje, bo składniki zostały już fizycznie pobrane.

Jeśli na tym etapie pojawia się potrzeba wycofania lub korekty (RWK), teoretycznie (zgodnie ze sztuką) rezerwacje powinny wrócić. Jednak mechanizm rezerwacji w Comarch ERP XL ma w tym miejscu swoje “niedorobienia” i nie odtwarza ich automatycznie po wygenerowaniu RWK. Wielu klientom takie zachowanie wręcz bardzo odpowiada, ale w tym scenariuszu rezerwacje niespodziewanie wracają później – po dodaniu nowej pozycji i zamknięciu zlecenia.

Gdzie leży błąd w Twoim procesie?

Wiele osób uważa, że przy częściowo zrealizowanym ZK (gdy powstaną RW/RWK) system w ogóle nie pozwala na edycję. To nie do końca prawda. Interfejs programu dopuszcza dodanie kolejnej, całkowicie nowej pozycji do takiego dokumentu bez konieczności ponownego zamykania całego zlecenia. Kiedy robi się to z poziomu interfejsu (lub poprawnie w tle), rezerwacja pojawi się tylko na tę nową część. Cała historyczna część dokumentu pozostaje nienaruszona.

Skąd w takim razie rezerwacje widmo na wszystko? Odpowiedzią jest wywoływanie funkcji ZamknijDokumentZlc za pomocą API lub zewnętrznego skryptu.

Wywołanie tej metody to dla systemu sygnał do wykonania procedury zamykania dla całości dokumentu, dokładnie tak jak przy pierwszym zatwierdzaniu. Program wykonuje ślepo to polecenie – przelicza wszystkie pozycje i generuje na nowo rezerwacje dla każdego składnika, nie analizując tego, że powiązane dokumenty zjadły już te stany. Wywoływanie funkcji ponownego zamykania całego zlecenia przy dodaniu zaledwie jednej nowej pozycji to poważny błąd logiczny.

Perspektywa ELTE-S: Niestandardowe operacje wymagają precyzji

Tworzenie własnych rozwiązań opartych na API czy integracjach to świetny sposób na przyspieszenie pracy, ale wymaga głębokiego zrozumienia mechaniki Comarch ERP XL. Powyższe działania to krótka droga do poważnego problemu: stany magazynowe zaczną się rozjeżdżać, system zacznie mnożyć rezerwacje widmo na tysiące sztuk, a to w prostej linii prowadzi do paraliżu procesów magazynowych i wstrzymania wysyłek do innych klientów, bo system zablokuje towar jako rzekomo “zarezerwowany”.

Zamiast walczyć z systemem i zamykać produkcję na czas sprzątania bazy, warto oddać integracje w ręce kogoś, kto zna API Comarcha na wylot. W ELTE-S chętnie sprawdzimy, w jaki sposób Twoja aplikacja odpytuje system, zlokalizujemy luki w logice i zaprojektujemy poprawki, dzięki którym proces przestanie generować fikcyjne blokady towaru.

Nie ryzykuj uszkodzenia bazy i chaosu na magazynie. Zostaw to nam.

Skontaktuj się z nami

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

Błędy po aktualizacji Comarch ERP Optima do wersji 2026.5 (64-bit) – co nie działa?

Wgrywasz najnowszą aktualizację systemu, by cieszyć się nowymi funkcjami i w pełni 64-bitową architekturą, a w zamian dostajesz błędy w modułach, które do wczoraj działały bez zarzutu.

Najnowsze wydanie Comarch ERP Optima 2026.5 przyniosło sporo ważnych zmian “pod maską”, ale w wielu biurach rachunkowych i firmach nie obyło się bez zgrzytów. Zebraliśmy najczęstsze usterki zgłaszane w ostatnich dniach przez użytkowników na forach i grupach społecznościowych.

Brak oficjalnego wsparcia dla Microsoft SQL Server 2025

Zanim przejdziemy do listy błędów, ważna uwaga technologiczna dotycząca silnika bazodanowego. Aktualna wersja Optima 2026.5 nie jest jeszcze sprawdzona ani w pełni zweryfikowana do działania z najnowszym Microsoft SQL Server 2025.

Nie oznacza to jednak, że temat został porzucony. Przeciwnie – kolejna aktualizacja programu ma zostać oficjalnie dostosowana do SQL 2025. To rewelacyjna wiadomość dla małych i średnich firm. Zastosowanie nowej wersji silnika Microsoftu w wersji Express (darmowej) pozwoli na korzystanie z baz danych o pojemności aż do 50 GB (wcześniejsze limity dla darmowych wersji SQL nakładały znacznie twardsze restrykcje przestrzenne).

Lista najczęściej zgłaszanych błędów w wersji 2026.5.1

Użytkownicy, którzy wykonali już aktualizację bazy, mierzą się obecnie z kilkoma uciążliwymi problemami:

Brak możliwości otwarcia Rejestrów VAT

Dla wielu księgowych to usterka krytyczna. Przy próbie wejścia w Księgowość -> Rejestry VAT program zgłasza błąd “System.FormatException: Nieprawidłowy format ciągu wejściowego”. Okno w ogóle się nie otwiera, co na ten moment całkowicie blokuje pracę w tym obszarze.

KSeF a Jednostki Podległe (JST)

Firmy podlegające pod JST (Samorządy) straciły nagle możliwość wysyłki faktur. Komunikat informuje, że dany kontekst NIP “nie jest uprawniony do wystawienia faktury w imieniu sprzedawcy”. W poprzedniej wersji mechanizm IDWew zdefiniowany w konfiguracji działał bez problemu.

Błędy w module Migrator 2026.5

Narzędzie do przenoszenia danych potrafi odrzucić prawidłowy plik po jego wskazaniu, wyświetlając błąd o niemożności otwarcia arkusza Excel.

Brak obsługi starych kolektorów danych (np. CipherLab 8400)

Po aktualizacji Optima przestała “widzieć” niektóre urządzenia zewnętrzne. Mimo poprawnych sterowników w systemie Windows i otwartego portu COM, program przy próbie importu wywala błąd o braku urządzenia.

Nierozpoznana wersja SQL Server podczas aktualizacji

Często na początku procesu instalacyjnego w środowiskach z Windows Server 2016 i SQL 2017 (np. 14.0.3515.1 X64) pojawia się komunikat ostrzegawczy: “Nie udało się wykryć wersji SQL Server”. Problem ten występuje na wszystkich stanowiskach podczas aktualizacji do 2026.5.1.6382, mimo że we wcześniejszych wersjach aktualizator działał bez tego błędu.

Perspektywa ELTE-S: Wdrażaj aktualizacje świadomie

Każda duża aktualizacja oprogramowania ERP, szczególnie ta wprowadzająca przejście na architekturę 64-bitową, niesie za sobą ryzyko tzw. chorób wieku dziecięcego. Zamiast instalować pakiety w dniu ich premiery, zawsze doradzamy chwilę wstrzemięźliwości i odczekanie na pierwsze poprawki producenta (o ile szybki update nie jest wymuszony przez wchodzące w życie, nowe przepisy podatkowe).

Równie istotne jest przetestowanie nowej wersji na tzw. bazie testowej, zanim wdrożymy ją na żywym środowisku w całej firmie.

Dlatego jeśli Twoja Optima sypie błędami po aktualizacji lub blokuje kluczowe procesy w firmie, pomożemy przywrócić ją do stabilności i odpowiednio przygotujemy serwer na nadchodzące wdrożenie SQL 2025.

Skontaktuj się z nami