Jak mapować statusy zamówień między ERP, WMS i e-commerce

Status „w realizacji” może znaczyć coś innego w sklepie, ERP, WMS i na marketplace. Dla sklepu zamówienie jest gotowe do obsługi po płatności. ERP może czekać na potwierdzenie dokumentu, a WMS uzna realizację dopiero po utworzeniu zlecenia magazynowego. Jeżeli integracja łączy te pola jeden do jednego, prędzej czy później pojawi się cofanie statusów, pętla aktualizacji albo komunikat dla klienta, który nie odpowiada rzeczywistości.

Poprawne mapowanie zaczyna się od procesu biznesowego. Statusy systemowe są jego lokalnym widokiem. Trzeba więc najpierw nazwać zdarzenia, właścicieli i dozwolone przejścia, a dopiero potem przypisać do nich wartości API.

Rozdziel osie stanu zamówienia

Jedno pole status jest wygodne na liście zamówień, ale rzadko wystarcza do integracji. Zamówienie ma kilka niezależnych wymiarów:

• stan płatności: oczekuje, opłacone, częściowo zwrócone, zwrócone,
• stan akceptacji: nowe, zweryfikowane, odrzucone,
• stan realizacji: oczekuje, kompletowane, gotowe, zakończone,
• stan wysyłki: bez przesyłki, nadane, w drodze, doręczone,
• stan anulowania: aktywne, żądanie anulowania, anulowane,
• stan dokumentów: brak, wystawione, przekazane.

Jeżeli wszystkie te informacje zostaną sklejone w jedną listę, liczba kombinacji szybko rośnie. Powstają statusy typu „opłacone-częściowo-wysłane-faktura-wystawiona”, których nie da się konsekwentnie mapować. Lepiej utrzymywać osobne osie, a dla użytkownika wyliczać status główny według priorytetów.

Przykładowo zamówienie może mieć płatność paid, realizację picking i wysyłkę not_shipped. Klient widzi „w realizacji”, magazyn widzi zadanie kompletacji, a księgowość ma informację o rozliczeniu. Każdy otrzymuje właściwy obraz bez utraty szczegółów.

Zdarzenia biznesowe zamiast podobnych nazw

Mapowanie nie powinno brzmieć „PROCESSING w systemie A równa się IN_PROGRESS w systemie B”. Obie nazwy są zbyt ogólne. Najpierw należy wskazać zdarzenie, które powoduje przejście, na przykład:

Zdarzenie	Właściciel	Skutek w modelu wspólnym
płatność potwierdzona	operator płatności / sklep	payment = paid
zamówienie przyjęte do ERP	ERP	acceptance = accepted
utworzono zlecenie magazynowe	ERP / OMS	fulfillment = queued
rozpoczęto kompletację	WMS	fulfillment = picking
zamknięto paczkę	WMS	fulfillment = packed
przesyłkę przekazano przewoźnikowi	system wysyłkowy	shipment = shipped
doręczenie potwierdzone	przewoźnik	shipment = delivered

Dokumentacja Allegro dotycząca obsługi zamówień rozróżnia stan formularza zamówienia od fulfillment.status i pozwala aktualizować status realizacji. To dobry przykład, dlaczego integrator powinien znać semantykę pola, a nie tylko jego listę wartości.

Wyznacz właściciela każdego przejścia

Status nie powinien krążyć między systemami bez kierunku. Jeżeli ERP ustawi „w realizacji”, sklep przekaże to do WMS, a WMS odeśle ten sam status do ERP, łatwo zbudować pętlę. Dla każdego pola należy wskazać system, który może je zmienić, oraz systemy tylko odczytujące.

Przykładowo WMS jest właścicielem etapów kompletacji, system płatniczy — płatności, a przewoźnik — doręczenia. Warstwa integracyjna tłumaczy zdarzenia na model wspólny i publikuje odpowiednie projekcje. ERP może pokazywać status WMS, lecz nie powinien go nadpisywać ręcznie bez zdefiniowanej komendy i potwierdzenia.

W systemach rozproszonych kopie danych są często ostatecznie spójne. Microsoft w materiale o odpowiedzialności za dane podkreśla potrzebę jednego źródła prawdy dla danego faktu. Dla statusów oznacza to, że lokalna kopia służy do prezentacji, ale nie staje się drugim właścicielem procesu.

Zbuduj maszynę stanów i reguły cofania

Lista wartości nie definiuje procesu. Potrzebne są dozwolone przejścia. Zamówienie może przejść z queued do picking, a potem do packed. Nie powinno wrócić z shipped do picking tylko dlatego, że opóźniony webhook dotarł po czasie.

Każde zdarzenie warto opatrzyć identyfikatorem, czasem biznesowym i wersją zamówienia. Odbiorca sprawdza, czy komunikat jest nowszy oraz czy przejście jest dozwolone. W razie konfliktu nie zgaduje, lecz kieruje zdarzenie do uzgodnienia.

Są sytuacje, w których cofnięcie jest prawidłowe. Błędnie spakowana paczka może wrócić do kompletacji, a anulowanie może zatrzymać zlecenie przed wydaniem. Takie przejścia powinny mieć własną komendę, powód, autora i ślad audytowy. Nie należy realizować ich przez zwykłe ustawienie starszego statusu.

Częściowa realizacja i anulowanie

Jedno zamówienie może zostać wysłane w dwóch paczkach z różnych magazynów. Wtedy status pozycji i przesyłki jest ważniejszy niż status nagłówka. Nagłówek może pokazać „częściowo wysłane”, ale integracja musi wiedzieć, które pozycje są zakończone, które czekają i jakie ilości anulowano.

Anulowanie również jest procesem. Kliknięcie klienta nie zawsze oznacza natychmiastowe anulowanie: WMS mógł już zakończyć pakowanie, przewoźnik odebrać paczkę, a faktura zostać wystawiona. Warto rozróżnić cancellation_requested, cancellation_accepted i cancellation_rejected. Decyzję podejmuje system znający aktualny etap realizacji.

Podobnie zwrot nie powinien cofać zamówienia do „nowe”. Jest oddzielnym procesem powiązanym z pierwotną transakcją, własnym przyjęciem magazynowym, rozliczeniem i dokumentami.

Kontrakt integracyjny i komunikaty dla użytkownika

Model statusów powinien być częścią wersjonowanego kontraktu. OpenAPI Specification pozwala formalnie opisać wartości pól i struktury żądań, ale dokument techniczny warto uzupełnić tabelą semantyki: kto ustawia wartość, po jakim zdarzeniu, czy jest końcowa i co użytkownik może zrobić dalej.

Komunikat dla klienta nie musi ujawniać wewnętrznych etapów. „WMS_PICK_RELEASED” może zostać pokazany jako „przygotowujemy zamówienie”. Ważne, aby obietnica była prawdziwa. Status „wysłane” powinien pojawić się po faktycznym zdarzeniu nadania lub wydania, nie po samym wydrukowaniu etykiety, jeżeli proces firmy rozróżnia te momenty.

Monitoring powinien wykrywać zamówienia pozostające zbyt długo na danym etapie, przejścia niedozwolone, brak zdarzenia pośredniego i różnice pomiędzy projekcją kanału a właścicielem danych. Dla każdego wyjątku potrzebny jest bezpieczny sposób ponowienia albo uzgodnienia.

Checklista mapowania statusów

Przed produkcją sprawdź:

1. osobne osie płatności, realizacji, wysyłki i anulowania,
2. wspólny słownik zdarzeń biznesowych,
3. właściciela każdego pola i przejścia,
4. dozwoloną maszynę stanów oraz reguły wyjątków,
5. wersję i czas zdarzenia,
6. obsługę częściowych ilości i wielu przesyłek,
7. ochronę przed pętlą aktualizacji,
8. komunikaty dla klienta i operatora,
9. alerty dla zamówień zatrzymanych oraz niespójnych.

Wniosek

Dobre mapowanie statusów nie polega na znalezieniu najbardziej podobnych nazw. Polega na odtworzeniu wspólnego procesu z jasno przypisanymi zdarzeniami i właścicielami. Gdy status kanału jest kontrolowaną projekcją danych ERP, WMS i przewoźnika, firma unika pętli, błędnych powiadomień i ręcznego sprawdzania, który system „mówi prawdę”.