Mapowanie statusów zamówień polega na zbudowaniu jednej tabeli, która mówi: gdy zamówienie w sklepie ma status X, w ERP powstaje dokument Y, a status zmienia się dalej, gdy wydarzy się Z. Bez takiej tabeli integracja działa „jakoś”, a zamówienia rozjeżdżają się w najgorszych przypadkach: anulowanych, opłaconych z opóźnieniem i zwróconych. Poniżej pięć kroków i wzór tabeli, na przykładzie WooCommerce i Subiekta nexo. Zasady są takie same dla innych sklepów i innych systemów ERP.
Jak wybrać sposób połączenia sklepu z ERP, opisuje wpis konektor do ERP, hub czy integracja na zamówienie. Tu zakładamy, że integracja już działa lub jest planowana i trzeba ustalić reguły.
Po co wspólna tabela statusów
Status w sklepie i dokument w ERP opisują ten sam fakt z dwóch stron. Klient widzi „w realizacji”, magazyn widzi zamówienie od klienta albo wydanie. Jeśli reguły nie są spisane, każdy zakłada coś innego: sklep uważa, że „zrealizowane” oznacza wysłane, ERP, że wystawiono fakturę.
Wspólna tabela robi trzy rzeczy: pozwala zaprogramować integrację bez zgadywania, daje punkt odniesienia przy reklamacjach („zamówienie powinno było mieć status Y”) i pozwala testować integrację na przypadkach, a nie na wrażeniach.
Co przygotować
- Dostęp do sklepu z podglądem statusów i zamówień testowych.
- Dostęp do ERP z możliwością utworzenia dokumentów testowych.
- Listę kanałów, które zasilają ERP (sklep, marketplace).
- Informację, kto w firmie wystawia faktury, kto pakuje i kto obsługuje zwroty.
- Tabelę lub arkusz do zapisu wyniku.
Krok 1: spis statusów w sklepie i kanałach
Zacznij od spisu wszystkiego, co może się zdarzyć z zamówieniem. W WooCommerce dokumentacja wymienia osiem statusów:
- Szkic (Draft): tymczasowy rekord z płatności blokowej, usuwany codziennie, jeśli nieużywany; nie jest zamówieniem,
- Oczekuje na płatność (Pending payment): zamówienie przyjęte, brak płatności,
- W trakcie realizacji (Processing): płatność wpłynęła, stan magazynowy zmniejszony, zamówienie czeka na realizację,
- Wstrzymane (On hold): czeka na potwierdzenie płatności, stan już zmniejszony (często przy przelewie tradycyjnym lub płatnościach z opóźnionym potwierdzeniem),
- Zrealizowane (Completed): zamówienie wykonane, nic więcej nie jest potrzebne,
- Nieudane (Failed): płatność nieudana lub odrzucona,
- Anulowane (Cancelled): anulowane przez administratora lub klienta, stan wraca do magazynu,
- Zwrócone (Refunded): zamówienie w pełni zwrócone.
Dodaj statusy, które mogą powstać w sklepie przez wtyczki lub ustawienia, jeśli je masz. Dla każdego marketplace spisz jego statusy zamówień i realizacji osobno: Allegro ma własne wartości, które sprzedawca może zmieniać przez API (aktualizacja statusu realizacji i dodanie numeru przesyłki), a ich pełną listę sprawdź w dokumentacji REST API Allegro. Nie zakładaj, że status „wysłane” znaczy w każdym kanale to samo.
W wyniku powinieneś mieć listę: kanał, status, co ten status oznacza, czy można go zmienić ręcznie.
Krok 2: dokumenty w ERP: ZK, faktura, wydanie
Teraz spisz dokumenty w ERP. W Subiekcie nexo zamówienie od klienta (ZK) jest dokumentem handlowym przypominającym formularz faktury sprzedaży. Tworzy się go w module Handel, w zakładce Zamówienia. Zgodnie z dokumentacją InsERT zamówienie od klienta można zrealizować jako dokument sprzedaży, wydanie magazynowe lub rozchód wewnętrzny, a także zrealizować je bez dokumentu, na przykład gdy sprzedaż obsłużono na kasie fiskalnej. W wersji PRO opis programu wymienia dodatkowo rezerwację dostaw potrzebnych do realizacji zamówienia oraz seryjną realizację wielu zamówień naraz.
To oznacza, że dla każdego zamówienia musisz zdecydować, jaki dokument ma powstać na którym etapie. Zwykle są to trzy punkty:
- Przyjęcie zamówienia: powstaje ZK (z rezerwacją lub bez, zależnie od wybranych ustawień i edycji programu).
- Wydanie towaru: powstaje dokument wydania lub sprzedaży.
- Fakturowanie: faktura według zasad firmy, na przykład przy wydaniu albo na życzenie klienta.
Dokładne nazwy typów dokumentów i ich zachowanie sprawdź w dokumentacji InsERT i na własnym środowisku testowym. Nie przenoś reguł z innego systemu, bo każde ERP ma własne.
Krok 3: kto zmienia który status
To krok, który najczęściej decyduje o sukcesie. Dla każdego przejścia ustal jedno źródło prawdy: system, który jako jedyny zmienia dany status. Przykładowo:
- status „Oczekuje na płatność” zmienia się w „W trakcie realizacji” w sklepie, bo tam wpływa płatność,
- „W trakcie realizacji” zmienia się w „Zrealizowane” w ERP, gdy powstaje dokument wydania, a integracja przenosi tę zmianę do sklepu razem z numerem przesyłki,
- anulowanie przed wysyłką zaczyna się w sklepie (klient lub administrator), a integracja przenosi je do ERP.
Warto też zapisać, co się dzieje, gdy zmiana statusu nie dociera do drugiego systemu: kto o tym wie, jak szybko i jak wygląda ponowna próba. Bez takiej reguły błąd synchronizacji zostaje niezauważony do pierwszej reklamacji klienta.
Zasada: dwa systemy nie powinny zmieniać tego samego statusu. Jeśli mogą, wprowadzasz konflikty, które wychodzą dopiero przy dużym ruchu.
Do przekazywania zmian z WooCommerce do zewnętrznego systemu służą webhooki, czyli powiadomienia wysyłane na wskazany adres po zdarzeniu. Pamiętaj o jednej własności: WooCommerce wyłącza webhook automatycznie po ponad pięciu kolejnych nieudanych dostarczeniach (odpowiedź inna niż 2xx, 301 lub 302). Jeśli integracja korzysta z webhooków, ustaw monitorowanie ich statusu, bo wyłączony webhook oznacza zamówienia, które nie dotrą do ERP, bez żadnego błędu widocznego w sklepie.
Krok 4: anulowania i zwroty
Anulowania i zwroty psują najwięcej tabel, bo mają wiele wariantów. Rozpisz osobno:
- Anulowanie przed wysyłką: co dzieje się z ZK, rezerwacją towaru i płatnością. W WooCommerce anulowanie zwraca stan do magazynu (przy włączonym zarządzaniu zapasami), a zamówienie może wymagać zwrotu płatności.
- Anulowanie po wystawieniu dokumentu wydania lub faktury: tu potrzebna jest korekta w ERP, nie sama zmiana statusu.
- Zwrot pełny: w WooCommerce status „Zwrócone”, w ERP dokument zwrotu lub korekta według zasad firmy.
- Zwrot częściowy: zamówienie zostaje w swoim statusie, a zwrot jest zapisany osobno. Sprawdź, czy integracja go widzi.
- Zmiana zamówienia po zapisie: dodanie lub usunięcie pozycji po utworzeniu ZK.
Przy każdym wariancie zapisz, co ma się stać w sklepie, w ERP i w kanale, a także kto jest za to odpowiedzialny.
Krok 5: test na kilku zamówieniach
Przed uruchomieniem zrób zestaw zamówień testowych, który obejmuje:
- zamówienie opłacone od razu i zrealizowane w całości,
- zamówienie z przelewem, które zostaje „Oczekuje na płatność” lub „Wstrzymane”, a po kilku dniach zostaje opłacone,
- zamówienie anulowane przed wysyłką,
- zamówienie anulowane po wydaniu towaru,
- zwrot pełny i zwrot częściowy,
- zamówienie z kilkoma pozycjami, z których jedna jest niedostępna,
- zamówienie z zewnętrznego marketplace.
Dla każdego zapisz: status w sklepie po każdym kroku, dokument w ERP, numer przesyłki i status w sklepie po wysyłce. Test jest zdany, gdy tabela z kroku 3 i zachowanie systemów są zgodne w każdym punkcie, a nie tylko w typowym.
Wzór tabeli mapowania
| Zdarzenie | Status w sklepie | Dokument w ERP | Kto zmienia | Uwagi |
|---|---|---|---|---|
| Złożenie zamówienia z płatnością online | Oczekuje na płatność | brak lub ZK bez rezerwacji (do ustalenia) | sklep | czeka na płatność |
| Płatność wpłynęła | W trakcie realizacji | ZK | sklep, potem integracja | stan magazynowy zmniejszony w sklepie |
| Przelew tradycyjny | Wstrzymane | brak lub ZK z oznaczeniem | sklep | do potwierdzenia płatności |
| Wydanie towaru | Zrealizowane | wydanie lub dokument sprzedaży | ERP, przeniesione do sklepu | numer przesyłki wraca do zamówienia |
| Anulowanie przed wysyłką | Anulowane | ZK anulowane lub zrealizowane bez dokumentu (do ustalenia) | sklep, przeniesione do ERP | stan wraca do magazynu |
| Zwrot pełny | Zwrócone | korekta lub dokument zwrotu | ERP lub księgowość | zgodnie z zasadami firmy |
| Płatność nieudana | Nieudane | brak | sklep | bez dokumentów |
Wpisy „do ustalenia” znaczą dokładnie to: nie przejmuj ich bez sprawdzenia na własnym środowisku. Tabela jest szablonem, a nie gotowym przepisem.
Podsumowanie
Dobrze zmapowane statusy to różnica między integracją, która działa w demonstracji, a taką, która działa przy anulowaniach, przelewach i zwrotach. Spisz statusy i dokumenty, wyznacz jedno źródło prawdy dla każdego przejścia, rozpisz wyjątki i przetestuj je na kilku zamówieniach.
Jeśli potrzebujesz integracji, która zachowuje się według twojej tabeli, a nie według domyślnych ustawień gotowego konektora, możesz zapytać M8T: wtyczki, konektory i integracje to jeden z obszarów usług.