Jak synchronizować zadłużenie i limit kredytu kupieckiego klienta między ERP a sklepem

Sklep B2B powinien znać limit przyznany, zaksięgowane zadłużenie, zaległości, rezerwacje i czas aktualizacji danych klienta. Te informacje wystarczają do decyzji zakupowej, choć nie muszą odtwarzać pełnego widoku rozrachunków z ERP.

Limit przyznany oznacza maksymalną kwotę zakupów z odroczonym terminem płatności, którą firma zaakceptowała dla danego klienta. Zaksięgowane zadłużenie pochodzi z rozrachunków, a zaległości to należności po terminie płatności. Rezerwacja oznacza kwotę przypisaną do zamówienia, które obciąża limit, ale nie zostało jeszcze rozliczone fakturą.

Dostępny limit jest wartością operacyjną. Firma powinna zatwierdzić formułę z księgowością i sprzedażą, na przykład: limit przyznany minus zadłużenie uwzględniane w polityce kredytowej minus aktywne rezerwacje. Ustal też, czy do wartości koszyka wchodzą podatek i koszt dostawy oraz kiedy rezerwacja przechodzi w zadłużenie.

Tabela pokazuje, które pola pomagają sklepowi podjąć decyzję o przyjęciu zamówienia. Nazwy pól i ich znaczenie powinny pozostać takie same w ERP, integracji i sklepie.

Tabela ułatwia sprawdzenie, czy sklep ma dane o kwocie i ich aktualności. Firma powinna wskazać właściciela każdego pola oraz określić, które statusy zamówienia tworzą, zmniejszają albo zwalniają rezerwację.

Nie każda firma powinna pokazywać klientowi dokładne saldo księgowe. Sklep może prezentować dostępny limit lub samą decyzję o możliwości zakupu, a szczegółowe zaległości udostępniać wyłącznie uprawnionym pracownikom. Taki podział zmniejsza ryzyko ujawnienia danych wewnętrznych i ogranicza nieporozumienia wynikające z różnych definicji salda.

ERP powinien być źródłem prawdy dla przyznanego limitu i zaksięgowanego zadłużenia, jeśli w nim firma prowadzi rozrachunki z klientami. Sklep może zarządzać koszykiem i przekazywać zamówienia, ale nie powinien samodzielnie zmieniać wartości ustalonych przez księgowość lub sprzedaż.

System pośredni może buforować dane, mapować identyfikatory i obsługiwać kolejkę komunikatów. Bufor nie staje się jednak właścicielem limitu tylko dlatego, że przechowuje jego kopię. Przy każdej wartości powinien zachować źródło, czas pobrania i informację, czy synchronizacja zakończyła się poprawnie.

Tabela przedstawia podział odpowiedzialności między ERP, sklepem B2B i systemem pośrednim. Jedno pole powinno mieć jeden system nadrzędny, a pozostałe systemy powinny je odczytywać lub przekazywać.

Tabela wskazuje, gdzie powinna powstawać dana wartość i kto jej używa. Jeśli firma prowadzi rezerwacje w osobnym systemie, należy wskazać go jako jedyny autorytatywny rejestr rezerwacji.

Dwie edytowalne kopie limitu mogą się wzajemnie nadpisywać. Przykładowo pracownik obniża limit w ERP, ale starsza wartość wysłana ze sklepu wraca do ERP w synchronizacji dwukierunkowej. Rozwiązaniem jest wyłączenie zapisu zwrotnego dla pola limitu albo zdefiniowanie jawnej reguły, kto i w jakich okolicznościach może go zmienić.

Zalecamy również rozdzielić blokadę techniczną od decyzji handlowej. ERP może zwrócić status klienta, sklep może zablokować automatyczne przyjęcie zamówienia, a uprawniony pracownik może zatwierdzić wyjątek z uzasadnieniem i zapisem autora decyzji.

ERP powinien przekazywać do sklepu dane kredytowe, a sklep powinien przekazywać zamówienia do ERP lub wspólnego mechanizmu rezerwacji. API to interfejs wymiany danych między systemami, a kolejka przechowuje komunikaty do przetworzenia, gdy odbiorca chwilowo nie odpowiada.

Przed ustaleniem częstotliwości synchronizacji rozdziel dwa procesy: aktualizację danych klienta i sprawdzenie konkretnego zakupu. Limit może zmieniać się sporadycznie, więc jego kopia w sklepie może być odświeżana po zmianie w ERP. Ostateczna kontrola kredytowa powinna jednak nastąpić w chwili składania zamówienia, gdy system może sprawdzić bieżące saldo i utworzyć rezerwację.

Tabela pokazuje kolejność komunikatów potrzebnych do powiązania klienta, limitu i zamówienia. Każdy komunikat powinien zawierać stabilny identyfikator klienta oraz identyfikator operacji, który pozwoli rozpoznać ponowienie.

Tabela pokazuje, które zdarzenia muszą zostać rozróżnione w integracji. Zmiana statusu nie powinna tworzyć nowej rezerwacji, jeśli aktualizuje tę samą operację.

Identyfikator kontrahenta z ERP powinien być głównym kluczem mapowania. NIP może pomóc przy pierwszym dopasowaniu, ale może nie wystarczyć, jeśli kontrahent ma kilka kont, oddziałów albo różne warunki handlowe. Zachowaj osobne relacje między identyfikatorem ERP a kontem sklepowym i sprawdzaj je przed wysłaniem zamówienia.

Komunikaty o zmianie limitu można wysyłać zdarzeniowo albo w cyklicznym imporcie. Zdarzenie skraca czas aktualizacji, ale wymaga obsługi niedostarczonych wiadomości. Import cykliczny jest prostszy, lecz pozostawia okres, w którym sklep korzysta ze starszych danych. W obu rozwiązaniach końcowa kontrola przy składaniu zamówienia powinna uwzględniać oznaczenie wieku danych.

Dla kolejki zapisz identyfikator komunikatu, klienta, zamówienia, czas wysłania, liczbę prób i rezultat. Ponawiaj błędy przejściowe, takie jak timeout lub chwilowa niedostępność usługi. Błędy trwałe, takie jak brak mapowania klienta albo nieprawidłowa kwota, kieruj do obsługi wyjątków zamiast ponawiać bez końca.

Wdrożenie integracji z ERP wymaga uzgodnienia zakresu danych, reguł kredytowych i obsługi zamówień. Jeśli planujesz sklep B2B, projekt sklepu internetowego na WooCommerce warto powiązać z tymi ustaleniami przed wyborem sposobu wymiany danych.

Sklep powinien wstrzymać automatyczne przyjęcie zamówienia, gdy koszyk przekracza dostępny limit, klient ma blokadę kredytową albo system nie potrafi potwierdzić aktualności danych. Ostrzeżenie wystarczy tylko wtedy, gdy polityka firmy dopuszcza sprzedaż ponad limit.

Firma powinna określić, czy blokada dotyczy wyłącznie płatności z odroczonym terminem, czy także innych metod płatności. Można na przykład zatrzymać kredyt kupiecki i pozostawić klientowi możliwość zapłaty z góry, jeśli takie rozwiązanie dopuszcza regulamin i proces sprzedaży.

Tabela pokazuje możliwą reakcję sklepu dla typowych stanów kontroli kredytowej. Próg świeżości danych i uprawnienia do ręcznej akceptacji firma powinna określić przed uruchomieniem procesu.

Tabela opisuje zachowanie dla sytuacji, w których automatyczna decyzja może opierać się na niepełnych danych. Firma powinna zapisać, które przypadki pozwalają na płatność z góry, a które wymagają całkowitego zatrzymania zamówienia.

Komunikat dla klienta powinien wskazywać możliwy kolejny krok, a nie ujawniać wewnętrzne saldo. Przykład: "Nie możemy teraz potwierdzić zamówienia z odroczonym terminem płatności. Wybierz płatność z góry albo skontaktuj się z opiekunem handlowym".

Gdy ERP nie odpowiada, pusta odpowiedź ani błąd połączenia nie oznaczają wolnego limitu. Sklep może zatrzymać zamówienie, skierować je do ręcznej akceptacji albo dopuścić inną formę płatności zgodną z polityką firmy. Każda decyzja awaryjna powinna zostawić ślad z przyczyną, czasem i osobą odpowiedzialną.

Zajęty limit powinien uwzględniać zaksięgowane należności oraz rezerwacje na zamówienia, które firma zdecydowała się obciążać przed wystawieniem faktury. Firma powinna ustalić moment utworzenia rezerwacji, ponieważ sam koszyk może być porzucony albo edytowany.

Przykład: klient ma limit 10 000 zł i zadłużenie 6 000 zł, więc dostępne pozostaje 4 000 zł. Dwa koszyki po 2 500 zł mogą równocześnie odczytać dostępne 4 000 zł, jeśli system tylko sprawdza saldo i nie rezerwuje kwoty. Wtedy oba zamówienia przejdą, choć łączna kwota 5 000 zł przekroczy pozostały limit o 1 000 zł.

System powinien wykonać sprawdzenie i rezerwację jako jedną kontrolowaną operację. Pierwsze zamówienie rezerwuje 2 500 zł, a drugie sprawdza ponownie saldo i widzi 1 500 zł. Drugie zamówienie nie powinno zostać automatycznie przyjęte na kredyt.

Firma powinna uzgodnić sposób obsługi dokumentów i statusów:

• Faktura nieopłacona zwiększa zadłużenie według rozrachunków ERP.
• Zamówienie oczekujące tworzy rezerwację, jeśli polityka firmy obciąża limit przed fakturą.
• Anulowanie zwalnia rezerwację dopiero po potwierdzeniu anulowania w systemie nadrzędnym.
• Częściowy zwrot zmniejsza saldo lub rezerwację po aktualizacji dokumentu korygującego.
• Podatek i dostawa wchodzą do kwoty rezerwacji zgodnie z zatwierdzoną regułą firmy.

Przejście zamówienia w fakturę powinno przenieść kwotę z rezerwacji do zadłużenia. Jeśli integracja doda fakturę do salda, ale nie zwolni odpowiadającej jej rezerwacji, sklep policzy tę samą kwotę podwójnie. Przy anulowaniu zamówienia odwrotna kolejność może przez pewien czas zawyżać dostępność limitu, dlatego należy logować oba zdarzenia i ich kolejność.

Ręczna korekta salda w ERP powinna tworzyć nową wersję danych, a nie zmieniać historię wcześniejszego komunikatu. Dzięki temu można wyjaśnić, dlaczego zamówienie przeszło lub zostało wstrzymane przy konkretnej wartości limitu.

Każda wartość limitu używana przez sklep powinna zawierać identyfikator klienta, źródło i czas pobrania. Znacznik czasu pozwala odróżnić aktualne dane od kopii, która przekroczyła firmowy próg świeżości.

Zdefiniuj zachowanie dla trzech przypadków: ERP jest niedostępny, odpowiedź nie zawiera wszystkich wymaganych pól albo dane są starsze niż dopuszczalny czas. W każdej sytuacji sklep powinien zablokować automatyczną decyzję kredytową albo wysłać zamówienie do ręcznej oceny. Próg świeżości powinien wynikać z ryzyka i częstotliwości zmian rozrachunków, a nie z przypadkowego ustawienia technicznego.

Log integracji powinien zawierać identyfikator żądania, identyfikator klienta, ID zamówienia, czas wysłania i odpowiedzi, kod błędu oraz liczbę ponowień. Nie zapisuj pełnych danych płatniczych ani informacji osobowych, które nie pomagają w diagnozie. Operator powinien móc przejść od komunikatu dla klienta do konkretnego zdarzenia w logu.

Z naszych wdrożeń wynika, że obsługa szybciej rozstrzyga spór o dostępny limit, kiedy przy decyzji widzi czas synchronizacji i system źródłowy. Zalecamy alert, gdy kolejka komunikatów rośnie albo odpowiedzi ERP przekraczają czas ustalony dla procesu. Alert powinien wskazywać zakres problemu i właściciela reakcji, nie tylko informować o ogólnym błędzie integracji.

Idempotencja oznacza, że ponowne dostarczenie tego samego komunikatu nie wywołuje drugiego skutku biznesowego. System powinien rozpoznać identyfikator operacji i nie tworzyć drugiej rezerwacji, faktury ani zamówienia. Przy błędzie timeout sprawdź najpierw, czy pierwsza próba nie została już wykonana po stronie odbiorcy.

Testy integracji powinny sprawdzać decyzję kredytową i rezerwację, a nie tylko to, czy ERP odpowiada na żądanie. Wykonaj je na środowisku testowym lub osobnych kontach, z których zamówienia nie trafią do realizacji.

Przed testami zapisz dla każdego przypadku wartość początkową limitu, zadłużenie, status klienta i oczekiwany wynik. Po teście porównaj stan ERP, sklepu i rejestru rezerwacji. Jeśli test obejmuje ręczną akceptację, zapisz także konto pracownika i uzasadnienie decyzji.

Tabela obejmuje przypadki graniczne dotyczące limitu, zwrotu, korekty, ponowienia komunikatu i współbieżnych koszyków. Dla każdego testu zachowaj wynik oraz identyfikator logu.

Tabela pozwala odróżnić sprawny transport danych od poprawnego działania reguł biznesowych. Test zalicz dopiero wtedy, gdy wynik odpowiada regule, a kwoty po obu stronach można uzgodnić.

Poza ścieżką poprawną przerwij połączenie w chwili rezerwacji i sprawdź, czy ponowienie nie tworzy duplikatu. Sprawdź również zmianę statusu zamówienia z oczekującego na fakturę oraz zwolnienie rezerwacji po anulowaniu. Operator powinien umieć odtworzyć przebieg każdej próby na podstawie identyfikatora komunikatu.

Rozbieżność zacznij diagnozować od identyfikatora klienta i czasu synchronizacji, a dopiero później sprawdzaj formułę salda. Dzięki temu można ustalić, czy różnica wynika z błędnego mapowania, opóźnionej kolejki, zdublowanej rezerwacji czy reguły biznesowej.

Tabela łączy objaw widoczny w sklepie z prawdopodobną przyczyną i pierwszym miejscem kontroli. Wartość należy porównywać dla tego samego klienta, zamówienia i momentu aktualizacji.

Tabela podpowiada pierwszy punkt diagnozy dla każdego objawu. Po znalezieniu przyczyny oznacz, czy powstała w mapowaniu, obliczeniu, dostarczeniu danych czy regule kredytowej.

W WooCommerce sprawdź logi integracji, harmonogram zadań i status wtyczek, które przekazują zamówienia. Przy problemach z wymianą danych z Subiektem nexo pomocny będzie poradnik diagnozowania synchronizacji Subiekta nexo ze sklepem. Jeśli występuje awaria samego sklepu, porównaj objaw z typowymi problemami WooCommerce i sposobami diagnozy.

Jeśli klient porzuca koszyk po otrzymaniu blokady, oddziel problem komunikatu od samej reguły kredytowej. Diagnoza porzuconego koszyka WooCommerce pomaga rozpoznać, czy klient przerwał proces przez ograniczenie płatności, błąd techniczny czy niejasny następny krok.

Jeżeli potrzebujesz wykonawcy, który uwzględni limit kredytowy, rezerwacje i obsługę błędów na etapie projektu, sklep B2B na WooCommerce przygotowany do integracji powinien mieć uzgodnione źródło prawdy i testy odbiorowe. Zakres integracji zależy od ERP, dostępnych interfejsów oraz firmowych zasad sprzedaży.

• Jak przyspieszyć realizację zamówień w e-commerce bez chaosu w obsłudze
• Zaliczka na 100% wartości zamówienia: zasady i wdrożenie w sklepie
• Logika warunkowa we wtyczce Flexible Checkout Fields: konfiguracja i testy
• Jak zwiększyć zyski sklepu internetowego dzięki danym i technologiom