Jak przetestować synchronizację stanów magazynowych przed Black Friday

Co może pójść źle przy stanach

Najczęstsze przyczyny sprzedaży towaru, którego nie ma:

• Opóźnienie. Ostatnia sztuka sprzedaje się w kanale A, a kanał B dowiaduje się o tym po kilku minutach.
• Różne definicje stanu. Sklep dostaje jedną liczbę, a ERP planuje sprzedaż według innej. W Subiekcie nexo zamówienie od klienta ze statusem rezerwacji dostaw lub rezerwacji stanu rezerwuje towar, choć nie został jeszcze wydany, a ilość zarezerwowana i dostępna to osobne wielkości (opisuje to e-Pomoc InsERT).
• Zamówienia nieopłacone. WooCommerce może trzymać stan dla zamówień ze statusem „Pending payment” przez liczbę minut ustawioną w opcji Hold stock. Po upływie limitu zamówienie jest anulowane, a stan wraca do puli. Dotyczy to wyłącznie „Pending payment”, nie „On hold”.
• Zatrzymane powiadomienia. Webhook WooCommerce po pięciu kolejnych nieudanych dostarczeniach (odpowiedź inna niż HTTP 2xx) jest wyłączany i trzeba go włączyć przez REST API.
• Brak powrotu stanu. Przy anulowaniach i zwrotach stan nie wraca tam, gdzie powinien.

Co przygotować

• kopię sklepu (środowisko stagingowe) połączoną z firmą testową w ERP; testów nie rób na produkcji ani na prawdziwych ofertach marketplace,
• od 8 do 10 produktów testowych o różnych stanach: 0, 1, 2 i kilka większych, w tym jeden wariant produktu i jeden zestaw, jeśli takie sprzedajesz,
• arkusz z kolumnami: scenariusz, stan początkowy w każdym kanale, działanie, wynik po 1, 5 i 15 minutach, uwagi,
• dostęp do logów: w WooCommerce w menu WooCommerce > Status > Logs, a w ERP do dziennika integracji lub tabel pomocniczych,
• stoper lub zegar z sekundami.

Krok 1: lista kanałów i źródło stanu

Zrób tabelę. Dla każdego kanału (sklep, marketplace, ERP, ewentualnie TikTok Shop) wpisz:

Najważniejsza kolumna to „którą liczbę wysyła”. W ERP rozstrzygnij, którą wielkość wysyłasz do kanałów: stan fizyczny, ilość dostępną czy ilość pomniejszoną o rezerwacje. Różnicę między rezerwacją dostaw a rezerwacją stanu opisuje e-Pomoc Subiekta nexo: rezerwacja stanu rezerwuje pozycje zamówienia bez wiązania ich z konkretną dostawą i jest przewidziana także na sytuację, gdy towaru nie ma na magazynie, a pełna rezerwacja dostaw wymaga, by cała ilość była dostępna. W przykładzie InsERT rezerwacja stanu zwiększa ilość zarezerwowaną i nie zmienia ilości dostępnej, więc sprawdź na próbie, którą wielkość eksportuje twoja integracja. Wybór wpływa na to, co zobaczy kupujący.

W WooCommerce zajrzyj do ustawień zapasów (WooCommerce > Settings > Products > Inventory w angielskim interfejsie): zarządzanie zapasami, Hold stock, próg niskiego stanu i próg braku w magazynie. W polach produktu REST API stan opisują manage_stock, stock_quantity, stock_status (wartości instock, outofstock, onbackorder) oraz backorders (no, notify, yes).

Krok 2: scenariusze testów

Przejdź kolejno poniższe scenariusze i zapisz wynik każdego.

1. Sprzedaż w sklepie. Kup 1 sztukę produktu o stanie 10. Oczekiwane: sklep 9, ERP odzwierciedla zamówienie zgodnie z przyjętą definicją stanu, marketplace 9 (lub 9 po zapasie bezpieczeństwa, patrz krok 5).
2. Zamówienie nieopłacone. Złóż zamówienie i nie płać. Sprawdź, czy stan jest zarezerwowany i czy wraca po czasie ustawionym w Hold stock.
3. Anulowanie. Anuluj zamówienie opłacone. Oczekiwane: stan wraca we wszystkich kanałach.
4. Zwrot. Przyjmij zwrot i sprawdź, czy stan wraca do sprzedaży, a jeśli towar ma wrócić na półkę dopiero po kontroli, kto i kiedy zwiększa stan.
5. Zmiana w ERP. Wprowadź przyjęcie towaru lub korektę stanu w ERP. Oczekiwane: nowy stan trafia do sklepu i marketplace.
6. Stan zero. Sprzedaj ostatnią sztukę. Sprawdź status zapasów, widoczność w katalogu (w WooCommerce opcja „Out of stock visibility” ukrywa takie produkty) i to, co widzi kupujący na marketplace.
7. Wariant i zestaw. Powtórz scenariusz 1 dla wariantu produktu i dla zestawu. To tutaj najczęściej mylą się identyfikatory.
8. Awaria odbiorcy. Na kopii wyłącz tymczasowo endpoint odbierający webhooki i złóż kilka zamówień. Sprawdź, co zobaczysz w logach, czy webhook się wyłączył po pięciu błędach i jak go przywrócić. Po teście przywróć endpoint.

Dla każdego scenariusza zapisz, czy wynik zgadza się z oczekiwaniem. Rozjazdy opisz dokładnie: produkt, godzina, wartości w każdym kanale.

Krok 3: pomiar opóźnienia synchronizacji

Opóźnienie to czas od zmiany stanu w źródle do pojawienia się nowej wartości w kanale docelowym. Mierz je powtarzalnie:

1. Zmień stan produktu w źródle i zapisz czas z dokładnością do sekundy.
2. Odpytuj kanał docelowy, na przykład żądaniem GET do produktu w REST API sklepu, i zapisz czas, kiedy pojawi się nowa wartość.
3. Powtórz kilkanaście razy, o różnych porach i, jeśli możesz, przy równoległym ruchu na sklepie.
4. Policz wartość największą, nie średnią. Klienta nie interesuje średnia, tylko najgorszy przypadek.

W logach WooCommerce zapisywany jest czas trwania każdego żądania webhooka wraz z odpowiedzią odbiorcy, co ułatwia odróżnienie wolnego odbiorcy od opóźnienia w kolejce. Webhooki są domyślnie przetwarzane w tle przez wp-cron.

Jeśli kanałem jest Allegro, pamiętaj o limicie z dokumentacji API: główny limit to 9000 zapytań na minutę na Client ID, po jego przekroczeniu serwer zwraca status 429, a środowisko testowe ma takie same limity jak produkcja. Test, który zalewa API zapytaniami, może więc zablokować Client ID także w teście.

Krok 4: ostatnia sztuka w dwóch kanałach naraz

To jedyny scenariusz, którego nie da się w pełni zabezpieczyć samym szybkim przesyłaniem. Dwóch kupujących może kliknąć „kup” w tej samej sekundzie.

1. Ustaw stan produktu testowego na 1 we wszystkich kanałach.
2. Złóż zamówienie w sklepie i w tej samej chwili w drugim kanale (z dwóch urządzeń albo z dwóch sesji; w kanale zewnętrznym użyj środowiska testowego, jeśli jest dostępne).
3. Sprawdź, co zrobił każdy system. Czy oba zamówienia zostały przyjęte? Który system odrzucił drugie? Jaki status ma drugie zamówienie?
4. Powtórz, zmieniając ustawienie dostaw na zamówienie (backorders: no, notify, yes) i obserwując różnice.

Zapisz, co robi firma w takiej sytuacji: kto kontaktuje się z kupującym, w jakim czasie i jaką propozycję składa (zwrot pieniędzy, termin uzupełnienia, zamiennik). Ten opis wydrukuj na dzień wyprzedaży.

Krok 5: zapas bezpieczeństwa

Zapas bezpieczeństwa to liczba sztuk, której kanały nie widzą. Zamiast wysyłać stan 3, wysyłasz 1 (zapas 2), a przy stanie 2 lub mniej wysyłasz 0. To ogranicza ryzyko sprzedaży ostatnich sztuk w dwóch kanałach naraz, kosztem tego, że część towaru formalnie nie jest sprzedawana. Wielkość zapasu to decyzja biznesowa, na przykład 1-2 sztuki dla produktów o dużej rotacji, i nie wynika z żadnego przepisu.

Przetestuj regułę na produktach o stanie 0, 1, 2 i 3. Reguła musi działać też w kierunku powrotnym: po przyjęciu dostawy stan w kanałach ma wzrosnąć, a nie zostać na zerze.

Alternatywą jest rezerwowanie towaru w ERP w chwili złożenia zamówienia (zamówienie od klienta ze statusem rezerwacji), tak by stan dostępny spadał od razu, a nie dopiero po wydaniu towaru.

Plan reakcji w dniu wyprzedaży

• Dyżur. Jedna osoba, która ma uprawnienia do zmiany stanów i wstrzymania kanału.
• Co sprawdzasz co godzinę. Wiek najstarszego zamówienia w kolejce, liczba zamówień bez numeru dokumentu w ERP, błędy w logach webhooków, produkty o stanie bliskim zera.
• Kiedy wstrzymujesz kanał. Zapisz próg z góry, na przykład brak nowych stanów przez określoną liczbę minut.
• Co mówisz kupującym. Gotowy tekst na wypadek sprzedaży towaru, którego nie ma.
• Notatnik zdarzeń. Godzina, objaw, decyzja.

Szerszy kontekst przygotowań opisuje wpis o tym, co sprawdzić w integracjach przed Black Friday. Dopasowanie statusów zamówień między sklepem a ERP omawia poradnik mapowanie statusów zamówień.

Lista kontrolna

• Tabela kanałów i źródeł stanu jest uzupełniona.
• Wiadomo, którą liczbę (fizyczną czy dostępną) wysyłają kanały.
• Osiem scenariuszy zostało przetestowanych, a wyniki zapisane.
• Największe opóźnienie jest znane i akceptowalne.
• Sprzedaż ostatniej sztuki w dwóch kanałach została przećwiczona.
• Zapas bezpieczeństwa jest ustalony i przetestowany.
• Plan reakcji ma dyżur, progi i gotowy komunikat do klientów.

Podsumowanie

Test synchronizacji stanów to nie jednorazowa kontrola, ale zestaw scenariuszy, które powtórzysz po każdej zmianie w integracji. Jeśli wyniki pokazują rozjazdy, których nie umiesz wyjaśnić, albo integracja wymaga przebudowy, M8T zajmuje się wtyczkami, konektorami i integracjami; zakres opisano w sekcji Usługi.