Jak zaprojektować przenoszenie i aktualizację zamówień między ERP a sklepem

Do ERP powinny trafić identyfikatory, pozycje, kwoty, dane klienta i warunki realizacji potrzebne do odtworzenia sprzedaży. Sama suma zamówienia nie wystarcza, ponieważ nie określa podatków, kosztu dostawy ani sposobu płatności.

Zakres pól i kierunek przepływu zatwierdźcie przed konfiguracją. Poniższa tabela pokazuje przykładowy zakres, a warunki synchronizacji trzeba dopasować do sklepu, ERP i rodzaju tworzonego dokumentu.

Pola pozycji, dostawy, płatności i odbiorcy wymagają osobnych reguł, nawet jeśli sklep prezentuje je razem. Uzgodnijcie format waluty, sposób zaokrąglania, strefę czasową oraz to, czy ERP przyjmuje kwoty netto czy brutto.

WooCommerce udostępnia dane zamówień przez REST API, czyli interfejs do odczytu i zapisu danych, oraz może wysyłać webhooki po skonfigurowanych zdarzeniach. Webhook to komunikat o zdarzeniu wysyłany na wskazany adres URL; logi dostarczenia pokazują żądanie i odpowiedź. Dokumentację producenta sprawdziliśmy 18 października 2026 roku w dokumentacji WooCommerce REST API i dokumentacji webhooków. Szerszy opis sposobów wymiany danych zawiera przewodnik po integracji systemów przez API.

Źródłem prawdy dla pola powinien być system, którego wartość ma pierwszeństwo po zmianach w obu miejscach. Właściciela danych ustalcie osobno dla każdego pola i etapu procesu, zamiast wyznaczać jeden system dla całego zamówienia.

Jedno pole powinno mieć jednego właściciela na danym etapie, nawet jeśli oba systemy pozwalają je edytować. Macierz powinna określać, czy zmiana jest dopuszczalna, jak długo trwa okno edycji i co następuje po jego zamknięciu.

Z naszych wdrożeń wynika, że reguły zmiany adresu, częściowego zwrotu i korekty ilości przed wysyłką często pozostają nieopisane. Zalecamy zatwierdzić macierz z osobami odpowiedzialnymi za sprzedaż, magazyn i księgowość. Typowe problemy mapowania opisujemy w poradniku o diagnozowaniu problemów z integracjami sklepu.

Przepływ powinien najpierw zweryfikować dane, następnie utworzyć rekord w ERP i zapisać jego identyfikator przy zamówieniu sklepowym. Trwałe powiązanie pozwala po przerwaniu komunikacji sprawdzić, czy ERP zapisał już dokument.

Przykładowa kolejność obsługi obejmuje:

1. Sklep zapisuje zamówienie z niezmiennym identyfikatorem.
2. Integracja odbiera zdarzenie albo pobiera zamówienie według harmonogramu.
3. Walidator sprawdza SKU, VAT, walutę, metodę dostawy i wymagane dane.
4. ERP tworzy uzgodniony dokument, na przykład zamówienie klienta.
5. Integracja zapisuje identyfikator ERP przy zamówieniu sklepowym.
6. System zapisuje wynik operacji i udostępnia numer dokumentu.

Zamówienie opłacone może po walidacji przejść do utworzenia dokumentu zgodnego z polityką firmy. Dla pobrania integracja przekazuje kwotę pobrania i właściwą metodę płatności. Zamówienie wymagające ręcznej weryfikacji trafia do kolejki wyjątków z przyczyną i osobą odpowiedzialną.

W WooCommerce webhooki konfiguruje się w WooCommerce > Ustawienia > Zaawansowane > Webhooki. Producent podaje, że sklep automatycznie wyłącza webhook po więcej niż pięciu kolejnych nieudanych dostarczeniach; za niepowodzenie uznaje odpowiedź inną niż HTTP 2xx, 301 lub 302. Logi webhooków pozwalają sprawdzić wysłane żądanie i odpowiedź. Informacje te sprawdziliśmy 18 października 2026 roku w oficjalnej dokumentacji webhooków WooCommerce.

Gdy zamówienia napływają z wielu kanałów, integracja zamówień z BaseLinkerem może uporządkować przepływ między kanałami a systemem operacyjnym firmy. Zakres należy dopasować do źródeł zamówień i zasad ich przekazywania. W przypadku sprzedaży na marketplace warto też poznać integrację Allegro z WooCommerce.

ERP powinien aktualizować status sklepu po zdarzeniu, które faktycznie zmienia etap realizacji. Sama zgodność nazw nie wystarcza, ponieważ dwa systemy mogą przypisywać tę samą etykietę do różnych etapów procesu.

Zwrot częściowy obejmuje wybrane pozycje albo część kwoty, więc nie oznacza zakończenia obsługi pozostałych pozycji. Zwrot pełny dotyczy całego zamówienia. Jeśli systemy na to pozwalają, przechowujcie status zwrotu oddzielnie od statusu realizacji.

Zablokujcie przejścia cofające proces, takie jak zmiana statusu z "Wysłane" na "W realizacji" po nadaniu przesyłki. Dozwolone może być przejście z "W realizacji" do "Wysłane", gdy ERP potwierdzi nadanie i przekaże numer przesyłki. Anulowanie można dopuścić przed rozpoczęciem kompletacji, a po jej rozpoczęciu skierować do ręcznej decyzji.

Wyjątek powinien trafić do kolejki obsługi zamiast nadpisywać bieżący status. Operator sprawdza przyczynę, uzgadnia faktyczny etap z magazynem lub przewoźnikiem i zatwierdza korektę z zapisem poprzedniej oraz nowej wartości. Integracja nie powinna ponownie wysyłać powiadomienia klientowi, jeśli status sklepu się nie zmienił.

Częstotliwość synchronizacji dobierzcie do oczekiwanego czasu obsługi, limitów API i dostępności ERP. Częstsze wywołania zmniejszają opóźnienie, ale zwiększają obciążenie oraz liczbę punktów wymagających monitorowania.

API synchroniczne wybierzcie, gdy sklep potrzebuje natychmiastowej odpowiedzi, a ERP zapewnia stabilny czas odpowiedzi. Kolejkę zdarzeń rozważcie, gdy awaria ERP nie powinna blokować przyjmowania zamówień. Synchronizacja cykliczna może wystarczyć, gdy opóźnienie jest akceptowalne, a systemy nie udostępniają zdarzeń.

Ustalcie, co dzieje się z zamówieniem podczas niedostępności ERP. Sklep może przyjąć zamówienie i oznaczyć je jako oczekujące na przekazanie albo wstrzymać sprzedaż, jeśli brak rezerwacji stanu tworzy niedopuszczalne ryzyko. Wybór powinien wynikać z zasad sprzedaży i magazynu.

Nieudana synchronizacja powinna zachować dane, zapisać przyczynę błędu i umożliwić bezpieczne wznowienie procesu. Ponowienie nie może utworzyć kolejnego dokumentu, jeśli ERP zapisał już pierwszą próbę.

Rozdzielcie błędy według sposobu obsługi:

• Błąd walidacji, taki jak brak SKU lub nieznana stawka VAT, wymaga poprawy danych przed ponowieniem.
• Błąd chwilowy, taki jak timeout lub niedostępność ERP, może uruchomić ponowienie po przerwie.
• Konflikt, taki jak istniejący rekord dla tego samego klucza, wymaga odczytu powiązania i uzgodnienia stanu.

Każdy log powinien zawierać identyfikator zamówienia sklepowego, identyfikator ERP, czas, etap i wynik operacji. Alert powinien odróżniać pojedynczy błąd walidacji od rosnącej liczby zamówień oczekujących. Nie zapisujcie pełnych danych osobowych, jeśli do diagnozy wystarczą identyfikator i kod błędu.

Stosujcie klucz idempotencji, czyli identyfikator pozwalający rozpoznać ponowione żądanie jako tę samą operację. Jeśli ERP go nie obsługuje, integracja powinna przed utworzeniem dokumentu sprawdzić, czy istnieje rekord z identyfikatorem zamówienia. Po wznowieniu porównajcie statusy obu systemów i przekażcie rozbieżność do ręcznej obsługi.

Test odbiorowy powinien potwierdzić zgodność danych, brak duplikatów i przewidywalne zachowanie po błędach. Ustalcie przypadki testowe na danych zbliżonych do produkcyjnych, bez wykonywania rzeczywistych płatności ani wysyłek.

Lista testów powinna obejmować:

• nowe zamówienie opłacone i zamówienie pobraniowe;
• produkt z wariantem, rabatem, różną stawką VAT i kosztem dostawy;
• brak kartoteki SKU, błędne dane firmy i nieobsługiwaną metodę dostawy;
• zmianę statusu, dodanie numeru przesyłki i częściowy zwrot;
• anulowanie przed kompletacją oraz próbę anulowania po nadaniu;
• timeout ERP, ponowienie komunikatu i ponowne dostarczenie tego samego zdarzenia.

Kryteria akceptacji powinny określać wynik dla danych i procesu. Przykładowo ERP zawiera te same pozycje i sumy co sklep, zamówienie ma jeden powiązany rekord, błędne SKU trafia do kolejki wyjątków, a ponowienie nie tworzy duplikatu. Firma powinna określić własny dopuszczalny czas synchronizacji i maksymalny czas reakcji operatora.

Przed startem porównajcie kontrolną próbkę zamówień w obu systemach. Protokół odbioru powinien wskazywać zaliczone przypadki, błędy, właściciela poprawki i wynik ponownego testu.

Monitoring powinien pokazywać liczbę zamówień oczekujących, błędy według typu i czas od złożenia zamówienia do zapisu w ERP. Progi alarmowe ustalcie z zespołami sprzedaży i magazynu, uwzględniając dopuszczalne opóźnienie oraz godziny pracy.

W panelu operacyjnym lub dashboardzie śledźcie liczbę zamówień oczekujących, błędów walidacji, błędów chwilowych i rekordów bez powiązanego identyfikatora. Mierzcie także czas synchronizacji i liczbę spraw wymagających ręcznej obsługi.

Uzgadniajcie okresowo identyfikatory, sumy i statusy za wybrany przedział czasu. Różnice zapisujcie w raporcie wyjątków, który wskazuje, czy operator ma wznowić komunikat, skorygować dane czy uzgodnić dokument z księgowością.

Jeśli zamówienia trafiają do ERP przez kilka kanałów i potrzebujecie wykonawcy, wdrożenie integracji z BaseLinkerem może objąć konfigurację przepływu zamówień i reguł obsługi wyjątków. Zakres prac warto uzgodnić na podstawie źródeł zamówień, mapowania statusów i procedury ponowień. Dodatkowe podejście do integracji sklepu z ERP opisuje przewodnik po połączeniu WooCommerce z ERP.

• Integracja API krok po kroku: jak połączyć sprzedaż z operacjami
• Jak zintegrować zamówienia ze sklepu internetowego z systemem księgowym?
• Mapowanie danych w integracji systemów: jak zapewnić spójność i poprawność
• Automatyzacja obsługi sprzedaży na Allegro: od zamówienia do wysyłki