Błąd wysyłki zbiorczej do KSeF w Comarch ERP XL – OpenBatchSessionAsync unauthorized access

Zbiorcza wysyłka faktur do KSeF z Comarch ERP XL i w konsoli ląduje długi łańcuszek błędu: Invalid operation ‘SendBatch’: Operation failed due to component error: OpenBatchSessionAsync failed due to unauthorized access and token refresh error: Bad Request. W praktyce to komunikat z jednym prostym znaczeniem – XL próbuje otworzyć sesję zbiorczą w KSeF, dostaje 401 Unauthorized od API MF i przy próbie odnowienia tokena łapie kolejny błąd 400. Nie chodzi tu o dane faktury ani o schemę XML – problem jest po stronie sesji i tokena operatora.

Dlaczego XL zwraca ten błąd

Każda sesja KSeF w Optimie i XL bazuje na parze: token autoryzacyjny operatora + aktywna sesja API MF. Token ma swój czas życia i zakres uprawnień, sesja – jeszcze krótszy TTL. Kiedy XL próbuje uruchomić wysyłkę zbiorczą (SendBatch), otwiera nową sesję na tokenie operatora. Jeśli token wygasł, został wygenerowany dla innego środowiska (np. Demo, a wysyłka idzie na Produkcję) lub ma za wąski zakres uprawnień, MF zwróci 401. XL próbuje wtedy odnowić token (token refresh), ale endpoint refresh nie akceptuje wygasłego lub niepasującego tokena – dostaje 400 Bad Request. Efekt: często obie sesje (poprzednia i nowa) są w niespójnym stanie, a XL nie potrafi się sam z tego wygrzebać.

Krok po kroku – jak przywrócić wysyłkę

Krok 1 – zamknij aktywną sesję KSeF w XL

Z menu System → Sesja KSeF wybierz opcję zamknięcia aktywnej sesji. To wymusza porzucenie niespójnego stanu sesji, której używał SendBatch. Jeśli w oknie jest widoczna aktywna sesja – zamknij ją ręcznie, nawet jeśli status wygląda poprawnie.

<screen>

Krok 2 – zrestartuj Comarch ERP XL

Zamknij całkowicie aplikację (nie tylko okno modułu handlowego) i uruchom ją ponownie. Przy starcie XL nawiąże nową sesję na aktualnym tokenie operatora – bez śladów poprzedniej, uszkodzonej. W wielu przypadkach ten krok wystarcza, żeby wysyłka zbiorcza znowu ruszyła.

Krok 3 – jeśli błąd wraca, usuń wpis operatora z cdn.KSeFTokeny

Uruchom SQL Server Management Studio, połącz się z bazą firmową XL i sprawdź tabelę cdn.KSeFTokeny – to tam XL trzyma zapisane tokeny/uwierzytelnienia poszczególnych operatorów. Znajdź wiersz odpowiadający operatorowi, który napotkał błąd i usuń go (przed usunięciem zrób backup lub zapisz zawartość na bok). Po ponownym uwierzytelnieniu tego operatora w XL, wpis zostanie odtworzony automatycznie już na świeżym tokenie. To rozwiązuje sytuacje, w których w tabeli siedzi “martwy” token, którego XL nie potrafi odnowić.

<screen>

Krok 4 – zweryfikuj środowisko tokena (Demo vs Produkcja)

W konfiguracji KSeF w XL sprawdź, dla jakiego środowiska wygenerowano token operatora. Częsty scenariusz: token pochodzi z testowego środowiska Demo, a wysyłka celuje w Produkcję (lub odwrotnie po przełączeniu klienta z Demo na Prod). MF nie zaakceptuje takiego tokena i zwróci 401 nawet dla poprawnego formalnie żądania. Wygeneruj nowy token dla właściwego środowiska.

<screen>

Krok 5 – zweryfikuj uprawnienia tokena

Token KSeF ma zakres uprawnień (m.in. wystawianie faktur, odczyt, zarządzanie uprawnieniami, samofakturowanie). Do wysyłki zbiorczej (SendBatch) potrzebujesz przynajmniej uprawnienia do wystawiania faktur. Jeśli token był generowany “minimalistycznie” (tylko odczyt lub tylko konkretna rola) – MF odrzuci wysyłkę. W praktyce najbezpieczniej wygenerować nowy token z pełnym zestawem uprawnień dla operatora technicznego biuletynu KSeF, który będzie używany przez XL.

<screen>

Kiedy sprawa jest po stronie MF, a nie XL

Zdarza się, że cały powyższy łańcuszek jest w porządku, a XL nadal zwraca 401/400 – warto wtedy sprawdzić status środowiska KSeF na stronie MF (podatki.gov.pl → KSeF → Status środowiska). Krytyczne prace serwisowe lub incydenty po stronie MF potrafią blokować wysyłkę zbiorczą z tym samym komunikatem błędu, mimo że token i sesja są poprawne. W takich sytuacjach jedyne co pomaga to poczekać na przywrócenie usługi.

Perspektywa ELTE-S

OpenBatchSessionAsync unauthorized w 9 na 10 wdrożeń sprowadza się do jednego z trzech twórców problemu: uszkodzony stan sesji po restarcie serwera, martwy token w cdn.KSeFTokeny albo niezgodność środowiska Demo/Prod na tokenie. Dopóki nie odetnie się tych trzech możliwości, nie warto szukać problemu w schemacie faktury ani w połączeniu sieciowym. Praktyczna wskazówka na przyszłość: dokumentujcie u siebie który operator w bazie ma token na jakie środowisko i pilnujcie, żeby po zmianie z Demo na Produkcję wyczyścić cdn.KSeFTokeny lub wygenerować nowe tokeny – to eliminuje 80% przypadków tego błędu. Interwencja w tabeli KSeFTokeny wygląda mocno technicznie, ale w praktyce jest bardzo bezpieczna – wpis odtwarza się automatycznie przy następnym logowaniu operatora.

Porozmawiajmy o uporządkowaniu integracji KSeF w Twoim Comarch ERP XL.

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.

Przebudowa drzewa struktury podległościowej w Comarch ERP XL – jak przenieść lub skopiować grupę?

Reorganizacja firmy, zmiana nazw działów czy połączenie kilku spółek w jeden organizm – to sytuacje, które naturalnie wymuszają zmiany w systemie ERP. W Comarch ERP XL struktura podległościowa to jeden z kluczowych elementów organizujących pracę, dostęp do dokumentów i akceptacje obiegów.

Często na forach pojawia się pytanie: jak szybko zreorganizować takie drzewo? Czy da się złapać całą gałąź z pracownikami i po prostu skopiować ją lub przenieść w inne miejsce za pomocą jednego kliknięcia?

Krótka odpowiedź brzmi: nie. System nie posiada przycisku “Kopiuj/Wklej gałąź”.

Jak poprawnie przebudować strukturę?

Próby znalezienia “magicznego przycisku” do kopiowania całych grup z pracownikami zwykle kończą się frustracją. Comarch ERP XL wymaga nieco bardziej ustrukturyzowanego podejścia do takich zmian operacyjnych.

Jeśli chcesz zreorganizować dział lub przenieść grupę ludzi, zastosuj poniższą ścieżkę:

1. Zbuduj nową gałąź ręcznie: W pierwszej kolejności utwórz w strukturze podległościowej nowe centrum (grupę/gałąź), docelowo nazywając i ustawiając jego parametry.

2. Wykorzystaj zbiorcze przepięcie: Nie musisz przenosić pracowników pojedynczo. Przejdź do starej grupy, zaznacz wszystkich pracowników, którzy mają trafić do nowego centrum i wykonaj operację zbiorczego przepięcia (zmiany przydziału).

3. Zarchiwizuj lub usuń stare centrum: Gdy stara gałąź jest już pusta i nie ma do niej przypisanych żadnych historycznych obiegów, które mogłyby ulec uszkodzeniu, możesz ją usunąć lub ukryć.

Dlaczego nie ma na to automatu?

Nasi wdrożeniowcy często spotykają się z prośbami o stworzenie “automatu” do klonowania struktury. Prawda jest jednak taka, że gruntowna przebudowa drzewa podległościowego w dużych firmach to operacja, którą wykonuje się niezwykle rzadko – raz na kilka lat, zwykle przy dużych przekształceniach lub restrukturyzacjach.

Pisanie dedykowanych skryptów czy funkcji dodatkowych tylko po to, by zaoszczędzić 15 minut na ręcznym założeniu nowych folderów i zbiorczym przeniesieniu ludzi, mija się z celem ekonomicznym.

Oczywiście, jeśli reorganizacja dotyczy setek centrów i tysięcy pracowników, a ręczna praca paraliżuje wdrożenie, jesteśmy w stanie interweniować na poziomie bazy danych. W 99% przypadków jednak standardowa ścieżka (nowa gałąź + zbiorcze przepięcie) jest najszybsza i najbezpieczniejsza dla spójności danych.

Jeżeli planujesz dużą reorganizację w Comarch ERP XL i boisz się o stabilność obiegów dokumentów, uprawnień i procesów w tle – daj nam znać. Chętnie pomożemy zaplanować to przejście.

Kod QR i numer w dwóch kolumnach na wydruku Comarch sPrint – jak to ustawić?

Tworzenie niestandardowych wydruków w Comarch sPrint daje ogromne możliwości, ale bywa też wyzwaniem, zwłaszcza gdy zależy nam na idealnym ułożeniu elementów w tabeli (np. na dokumencie ZS – Zamówienie od Klienta).

Jednym z częstych problemów jest próba umieszczenia kodu QR (zawierającego np. nazwę towaru lub EAN) obok numeru pozycji w tabeli. Domyślnie edytor potrafi zrzucać te elementy jeden pod drugim, co zaburza wygląd dokumentu, rozciąga wiersze i utrudnia czytanie na produkcji czy magazynie.

Jak zmusić sPrint do wyświetlenia tych danych w dwóch kolumnach obok siebie?

Czytaj dalej

Comarch ERP XL w wersji webowej – nowa era czy tylko lifting?

Przez lata w branży IT utarło się przekonanie, że zaawansowane systemy ERP klasy enterprise muszą być skomplikowane, trudne w nauce, wizualnie przestarzałe i toporne. Wymagały one od użytkowników wielogodzinnych szkoleń, wertowania grubych instrukcji obsługi i mozolnego “przeklikiwania” dziesiątek ukrytych zakładek. Comarch ERP XL od lat uchodził za jedno z najpotężniejszych narzędzi na polskim rynku, ale jego klasyczny interfejs desktopowy wyraźnie przypominał rozwiązania z poprzedniej epoki.

Teraz ten stan rzeczy drastycznie się zmienia. Nowa wersja webowa Comarch ERP XL to nie tylko odświeżenie szaty graficznej, ale jasny komunikat technologiczny dla całego rynku: ERP XL to światowej klasy, nowoczesne oprogramowanie. Nowa odsłona systemu nie tylko perfekcyjnie radzi sobie ze skomplikowanymi procesami największych polskich i międzynarodowych korporacji, ale również dorównuje – a w wielu miejscach znacznie przewyższa najnowsze, globalne rozwiązania choćby pod kątem User Experience (UX), responsywności oraz dostępności dla użytkownika końcowego.

Zapraszamy do obejrzenia analizy wideo przygotowanej przez ekspertów ELTE-S oraz przeczytania naszego obszernego podsumowania i opinii na temat najnowszej webowej odsłony Comarch ERP XL.

Czytaj dalej