Optima nie przyjmuje zamówień z Magento? 7 błędów

Dlaczego zamówienie z Magento 2.4.7 w ogóle nie pojawia się w buforze RO Optimy?

Gdy Comarch ERP Optima odrzuca zamówienie ze sklepu, w 90% przypadków winny jest brak walidacji danych po stronie integratora: rozjazd stawek VAT, zdublowany NIP blokujący rekord w MSSQL lub brakujący kod SKU w cenniku ERP. W SISL każda integracja Magento z Comarch Optima zaczyna się od audytu wyjątków w payloadzie, ponieważ domyślne konektory wyłożą się na pierwszej niestandardowej transakcji z PayU czy InPostu. To nie jest awaria silnika Magento, lecz niezgodność typów danych między e-commerce a logiką księgową Comarchu.

Podstawowy mechanizm wymiany opiera się najczęściej na module pośredniczącym (tzw. middleware) komunikującym się przez REST API / GraphQL Magento oraz interfejs COM (Optima API) lub e-Sklep WebService. Jeśli zamówienie ze statusem Processing lub Pending nie tworzy dokumentu RO (Rezerwacja Odbiorcy) ani PA/FS w Optimie, pierwszym miejscem weryfikacji nie jest panel administracyjny, lecz logi w var/log/ oraz kolejka asynchroniczna.

• Kolejka RabbitMQ / DB Queue wisi: W Magento 2.4.7 na PHP 8.3 asynchroniczne wysyłanie zdarzeń (np. sales_order_place_after) wymaga bezbłędnie działającego crona. Jeśli proces bin/magento cron:run dostanie timeout lub zderzy się z błędem pamięci (częste przy memory_limit < 2G dla CLI), joby queue:consumers:start przestają przetwarzać wiadomości.
• Brakujący produkt w kartotece Optimy: Wystarczy, że w Magento produkt prosty wchodzący w skład Configurable Product ma kod SKU-CZARNY-XL, a w Optimie ktoś założył go jako SKU_CZARNY_XL (podkreślenie zamiast myślnika). Optima API rzuci błędem: Nie znaleziono towaru o podanym kodzie i natychmiast odrzuci całą strukturę XML/JSON zamówienia.
• Nieobsługiwany status rabatu: Moduły promocyjne (np. Amasty Special Promotions czy Mirasvit Rewards) potrafią wygenerować rabat pozycji rzędu 0.001 PLN. Podczas parsowania do formatu Optimy suma pozycji netto + VAT nie zgadza się z sumą nagłówka z dokładnością do 1 grosza. Rezultat? Błąd walidacji sumarycznej dokumentu handlowego.

Co psuje mapowanie stawek VAT, walut i płatności (BLIK, Przelewy24)?

Optima wymaga żelaznej dyscypliny w tabeli stawek podatkowych. Podczas gdy Magento 2 operuje na regułach podatkowych (Tax Rules) powiązanych ze strefami geograficznymi, Comarch ERP Optima oczekuje precyzyjnych literowych kodów stawek przypisanych do polskiego systemu podatkowego (A = 23%, B = 8%, C = 5%, D = 0%, E = zwolniony/ZW, NP = nie podlega).

Najczęstszy problem pojawia się przy sprzedaży zagranicznej w procedurze OSS (One Stop Shop) lub B2B z odwrotnym obciążeniem (reverse charge). Jeśli klient z Niemiec z aktywnym numerem VAT-UE złoży zamówienie ze stawką 19%, a Twój konektor nie posiada skonfigurowanej tablicy translacji stawek unijnych do odpowiednich rejestrów VAT w Optimie, obiekt COM wyrzuci błąd zapisu pozycji dokumentu. Transakcja utknie w stanie błędu, a magazyn nie zarezerwuje towaru.

Rozbieżności groszowe wynikają z różnic w algorytmach zaokrągleń: Magento domyślnie liczy podatek na poziomie całego wiersza lub sumy koszyka (zależnie od ustawienia Tax Calculation Method Based On), podczas gdy Optima przelicza każdą sztukę towaru w oparciu o cenę bazową i stawkę przypisaną do karty towarowej. Przy koszykach powyżej 20 pozycji rozjazd o 0.01 PLN jest niemal gwarantowany, o ile middleware nie stosuje algorytmu korygującego grosze na pozycji transportowej.

W przypadku bramek płatności (Przelewy24, PayU, Stripe, Autopay) integracja musi jednoznacznie powiązać metodę płatności ze zdefiniowanym w Optimie rejestrem kasowym lub bankowym. Zapisanie płatności BLIK o kodzie p24_blik wymaga zmapowania na formę płatności o typie Karta/Kompensata z terminem 0 dni. Brak takiego mapowania skutkuje przypisaniem formy domyślnej (często Gotówka) i błędnym stanem rozrachunków.

Jak konflikty kartotek kontrahentów i blokady MSSQL uniemożliwiają zapis?

Obsługa klientów B2B oraz B2C to punkt zapalny integracji. W środowisku e-commerce klient może kupować jako gość (Guest Checkout) lub zalogowany użytkownik, wpisując ten sam NIP z różnymi prefiksami (np. PL1234567890 vs 1234567890) lub z myślnikami.

1. Deadlocki na tabeli CDN.KntKarty: Gdy w tym samym ułamku sekundy spływają trzy zamówienia od tego samego klienta B2B (lub zamówienia z Allegro przez BaseLinkera i jednocześnie ze sklepu Magento), równoległe sesje próbują zaktualizować ten sam rekord kontrahenta w bazie Microsoft SQL Server Optimy. Dochodzi do zjawiska Transaction Deadlock, w wyniku którego serwer SQL ubija jeden z procesów, a zamówienie w Magento zostaje oznaczone jako niesynchronizowane.
2. Biała lista podatników VAT i walidacja NIP: Optima potrafi automatycznie blokować zapis kontrahenta, jeśli jego NIP jest nieaktywny w bazie VIES lub na Białej Liście MF, podczas gdy formularz checkoutowy w Magento (szczególnie oparty o szybkie checkouty typu Hyvä Checkout czy OneStepCheckout) przepuścił dane bez pełnej weryfikacji w API MF.
3. Puchnięcie bazy przez kontrahentów jednorazowych: Tworzenie nowego rekordu w CDN.KntKarty dla każdego zakupu B2C o statusie gościa prowadzi do degradacji wydajności bazy MSSQL Express (limit 10 GB). Poprawna konfiguracja powinna kierować sprzedaż paragonową na jednego kontrahenta zbiorczego (np. !KLIENT_DETALICZNY!), rozróżniając jedynie dane do wysyłki w polach adresu dostawy.

Gdzie gubią się dane przesyłek InPost Paczkomat i punktów odbioru?

Standardowy schemat zamówienia w Magento przechowuje adres dostawy w encji sales_order_address. Gdy klient wybiera Paczkomat InPost, punkt DPD Pickup czy Orlen Paczkę, kod punktu (np. KRA01M) jest zapisywany w polach rozszerzonych (extension attributes) lub w niestandardowych kolumnach dodanych przez moduł kurierski.

Konektor Optimy musi wiedzieć, jak te dane wyciągnąć i wstrzyknąć do odpowiednich pól dokumentu RO:

• Pole Odbiorca w nagłówku dokumentu (jeśli towar ma jechać na adres inny niż adres nabywcy).
• Zakładka Kontrahent / Dostawa z precyzyjnym wpisaniem kodu punktu w polu Opis lub w dedykowanym atrybucie dokumentu (klasy atrybutów w Optimie: DOKUMENT_PUNKT_ODBIORU).
• Numer telefonu odbiorcy — Optima wymaga formatu znormalizowanego (bez spacji, myślników, często bez +48 w zależności od konfiguracji modułu kurierskiego Comarchu). Błąd w formacie numeru telefonu przerywa proces generowania listu przewozowego z poziomu ERP.

Jak wymogi KSeF wpływają na przepływ zamówień i wystawianie dokumentów?

Krajowy System e-Faktur wymusza absolutną zgodność danych już na etapie zamówienia. Wszelkie literówki w nazwie firmy, brak kodu kraju przy NIP-ie czy błędne oznaczenie procedur (np. transakcja trójstronna, mechanizm podzielonej płatności MPP) uniemożliwią przekształcenie bufora RO w fakturę ustrukturyzowaną FA(2) lub FA(3).

U nas w projektach integrujących Magento 2.4.7 z Optimą stosujemy prewalidację danych po stronie sklepu. Zanim zamówienie trafi do kolejki integracyjnej, customowy plugin w Magento weryfikuje:

1. Format numeru identyfikacji podatkowej względem kraju nabywcy.
2. Zgodność wymogów MPP — jeśli kwota brutto przekracza 15 000 PLN, a koszyk zawiera towary z załącznika nr 15 ustawy o VAT (oznaczone atrybutem is_mpp = 1 w Magento), integrator automatycznie ustawia znacznik podzielonej płatności w nagłówku RO w Optimie.
3. Poprawność e-maila do wysyłki faktur — odrzucenie znaków niedozwolonych przez schemat XSD KSeF.

Jak debugować błędy integracji? Ścieżka techniczna

Zanim zaczniesz restartować usługi, przejdź przez powtarzalną procedurę diagnostyczną:

1. Weryfikacja logów Magento: Sprawdź pliki var/log/system.log, var/log/exception.log oraz dedykowany log konektora (np. var/log/optima_sync.log). Szukaj błędów HTTP 500, 400 Bad Request oraz komunikatów SOAP Fault.
2. Stan procesów i kompilacji: Upewnij się, że po aktualizacjach kodu wykonano pełny deployment: bin/magento setup:upgrade && bin/magento setup:di:compile && bin/magento cache:flush. Niezgodność wygenerowanego kodu w generated/code/ potrafi cicho ubić interceptory odpowiedzialne za wysyłkę zamówień.
3. Podgląd XML/JSON payloadu: Zaloguj surowy payload wysyłany do API Optimy. Jeśli używasz interfejsu COM, sprawdź kody błędów biblioteki CDNOB1.dll. Przykładowo błąd 0x80040154 oznacza brak zarejestrowanej biblioteki na serwerze Windows, a -2147220990 wskazuje na naruszenie więzów integralności bazy MSSQL.
4. Weryfikacja blokad w MSSQL: Wykonaj zapytanie diagnostyczne w SQL Server Management Studio na bazie firmowej Optimy, aby sprawdzić aktywne blokady: SELECT * FROM sys.dm_tran_locks WHERE request_status = 'WAIT';.

Ile kosztuje naprawa i audyt integracji Magento z Comarch Optima?

Standardowy audyt zablokowanej lub niestabilnej integracji to koszt rzędu 3 500 – 7 000 PLN netto, w zależności od tego, czy komunikacja odbywa się przez gotowy konektor komercyjny, dedykowany middleware w Node.js/Pythonie, czy bezpośrednie procedury w MSSQL. Kompleksowa przebudowa szyny integracyjnej, uwzględniająca asynchroniczne kolejki RabbitMQ, obsługę wariantów, zaawansowane mapowanie stawek VAT dla UE oraz pełną zgodność z KSeF, mieści się zazwyczaj w budżecie 12 000 – 28 000 PLN netto.

Jeśli Twoja Optima codziennie blokuje zamówienia, na magazynie rosną opóźnienia, a w logach Magento widzisz setki nieprzetworzonych payloadów — napisz do nas. Przeanalizujemy strukturę danych, wskażemy wąskie gardła i ustawimy stabilny transfer zamówień, który nie wyłoży się przy najbliższym Black Friday.