W dropshippingu jedno zamówienie może jednocześnie istnieć w sklepie, systemie płatności, integratorze, panelu hurtowni i systemie przewoźnika. Każdy z tych systemów używa własnych statusów. Problem zaczyna się wtedy, gdy „processing” w sklepie oznacza coś innego niż „processing” u dostawcy, a „shipped” pojawia się jeszcze przed pierwszym skanem przesyłki.
Dobre mapowanie statusów powinno odpowiadać na jedno pytanie: jaki fakt biznesowy rzeczywiście wydarzył się z zamówieniem? Nie wystarczy przetłumaczyć nazwy statusu. Trzeba zdefiniować warunki przejścia, źródło prawdy i reakcję systemu na opóźnienia, cofnięcia oraz duplikaty komunikatów.
Dlaczego nazwy statusów nie powinny sterować integracją bezpośrednio?
Hurtownia może oznaczyć zamówienie jako „completed”, gdy utworzyła dokument WZ, podczas gdy sklep rozumie „completed” jako doręczenie klientowi. Inny dostawca użyje „sent”, gdy tylko wygeneruje etykietę. Dlatego status tekstowy powinien zostać przetłumaczony na wewnętrzny stan procesu.
| Stan biznesowy | Co musi być prawdą? | Czego nie zakładać? |
|---|---|---|
| paid | Płatność została potwierdzona | Że hurtownia już przyjęła zamówienie |
| accepted_by_supplier | Dostawca zwrócił poprawne ID zamówienia | Że towar został zarezerwowany, jeśli API tego nie gwarantuje |
| in_fulfillment | Hurtownia rozpoczęła kompletację | Że paczka opuści magazyn tego samego dnia |
| label_created | Istnieje numer przesyłki | Że przewoźnik odebrał paczkę |
| in_transit | Przewoźnik zarejestrował realny skan | Że przesyłka dotrze w pierwotnym ETA |
| cancelled | Anulowanie zostało potwierdzone przez system odpowiedzialny za realizację | Że wysłany wcześniej request anulowania na pewno zatrzymał paczkę |
Najpierw zdefiniuj własny słownik statusów
Najbezpieczniejsza integracja ma mały, kontrolowany zestaw stanów wewnętrznych. Dopiero do niego mapujesz statusy każdego dostawcy. Dzięki temu zmiana nazwy po stronie jednej hurtowni nie musi przebudowywać całej logiki sklepu.
Przykład: hurtownia A zwraca packed, hurtownia B ready_for_carrier, a plik CSV hurtowni C ma wartość 2. Wszystkie trzy wartości mogą odpowiadać jednemu stanowi ready_to_ship, o ile dokumentacja i testy potwierdzają ten sam fakt.
Który system powinien być źródłem prawdy?
Źródło prawdy zależy od informacji. Płatność najlepiej potwierdzać na podstawie operatora płatności lub wiarygodnego statusu transakcji w sklepie. Przyjęcie zamówienia — po odpowiedzi API hurtowni. Faktyczny ruch paczki — na podstawie przewoźnika, nie samej etykiety.
- Płatność: PSP/sklep.
- ID zamówienia u dostawcy: hurtownia.
- Rezerwacja i kompletacja: hurtownia, jeśli udostępnia te stany.
- Numer trackingowy: hurtownia lub przewoźnik.
- Pierwszy skan i ruch przesyłki: przewoźnik.
- Zwrot środków: operator płatności.
Sam numer trackingowy nie powinien automatycznie oznaczać „wysłano”. Różnicę między etykietą a realnym przejęciem paczki opisuje poradnik Tracking jest, ale przewoźnik nie ma pierwszego skanu.
Co zrobić z webhookiem, który przychodzi dwa razy?
Integracje powinny zakładać, że ten sam komunikat może zostać dostarczony ponownie. Retry po timeoutach jest normalnym mechanizmem systemów sieciowych. Jeżeli każde odebranie webhooka bezwarunkowo uruchamia „utwórz zamówienie u dostawcy”, powstaje ryzyko dwóch paczek.
Do każdej operacji tworzącej efekt biznesowy potrzebny jest klucz idempotencji albo własna blokada oparta na identyfikatorze zamówienia. Problem i sposób myślenia szerzej opisuje artykuł o duplikacie zamówienia po retry webhooka.
Jak mapować anulowanie, żeby refund nie wyprzedził paczki?
Najbardziej ryzykowny błąd to uznanie wysłanego żądania anulowania za potwierdzone anulowanie. Jeżeli dostawca już rozpoczął kompletację, API może przyjąć request, ale paczka nadal zostanie nadana.
Warto rozdzielić co najmniej trzy stany:
cancel_requested— sklep poprosił o anulowanie;cancel_confirmed— hurtownia potwierdziła zatrzymanie realizacji;cancel_failed— anulowanie nie było już możliwe.
Dopiero drugi stan pozwala bezpiecznie traktować zamówienie jako zatrzymane. Jeżeli anulowanie się nie udało, proces powinien przejść w obsługę wyjątkową: przechwycenie paczki, odmowa przyjęcia, zwrot lub inna procedura ustalona z dostawcą.
Jak obsłużyć częściową wysyłkę?
Jedno zamówienie klienta może zostać rozbite na kilka przesyłek. Wtedy status całego zamówienia nie powinien usuwać informacji o pozycjach. Najlepiej przechowywać stan realizacji na poziomie linii zamówienia: SKU, ilość zamówiona, ilość przyjęta przez dostawcę, ilość wysłana, tracking i ewentualny backorder.
Praktyczny proces komunikacji z klientem znajdziesz w artykule o częściowej wysyłce w dropshippingu.
Co powinno trafić do kolejki wyjątków?
Nie każdą sytuację da się poprawnie rozstrzygnąć automatem. Zamiast zostawiać zamówienie w statusie „processing” przez tydzień, system powinien po przekroczeniu określonego czasu utworzyć zadanie do sprawdzenia.
- płatność jest potwierdzona, ale brak ID dostawcy;
- dostawca zaakceptował zamówienie, ale nie ma ruchu przez ustalony czas;
- jest tracking, ale brak pierwszego skanu;
- status cofnął się z „shipped” do „processing”;
- hurtownia podaje inną ilość niż sklep;
- anulowanie pozostaje bez potwierdzenia;
- dwie integracje próbują aktualizować ten sam fulfillment.
Przy rozbieżnościach produktów koniecznie kontroluj także mapowanie wariantów. Nawet poprawny status nie pomoże, jeśli system wysłał dostawcy zły identyfikator. Zobacz jak błędne SKU i warianty prowadzą do wysyłki niewłaściwego produktu.
Minimalny log audytowy dla każdego zamówienia
Przy reklamacji lub awarii trzeba odtworzyć kolejność zdarzeń. Warto zapisywać czas, źródło, poprzedni status, nowy status, ID komunikatu oraz odpowiedź zewnętrznego systemu. Log powinien pozwolić odpowiedzieć: kto zmienił stan, na jakiej podstawie i czy operacja została wykonana raz.
W przypadku trackingów importowanych plikiem przydaje się też kontrola braków i duplikatów. Proces można oprzeć na zasadach opisanych w poradniku o automatycznym dopasowaniu trackingów z CSV i e-maila.
Najczęstsze pytania
Czy „shipped” u dostawcy można od razu wysłać klientowi jako „paczka w drodze”?
Tylko jeśli wiesz, że ten status oznacza fizyczne przekazanie przewoźnikowi. Jeżeli oznacza jedynie utworzenie etykiety, lepiej poczekać na pierwszy skan.
Czy sklep i hurtownia muszą mieć identyczne statusy?
Nie. Ważne jest spójne mapowanie faktów biznesowych, nie identyczne nazwy.
Co zrobić, gdy hurtownia nie dokumentuje znaczenia statusów?
Przetestuj pełny cykl na zamówieniach kontrolnych i zapisz obserwowane przejścia. Krytycznych automatyzacji nie opieraj na niezweryfikowanym znaczeniu pola.
Jaki status jest najlepszy dla zamówienia z błędem integracji?
Osobny stan typu exception lub kolejka operacyjna jest bezpieczniejsza niż pozostawienie zamówienia w pozornie prawidłowym „processing”.
admin
Autor praktycznych materiałów o dropshippingu, e-commerce, automatyzacji i rozwijaniu sprzedaży internetowej.