Rozbieżność stanu między sklepem a systemem zarządzania magazynem WMS
Sklep internetowy, w którym pokazywana dostępność nie odpowiada stanowi faktycznemu, prędzej czy później sprzeda produkt, którego nie ma już na regale. Klient składa zamówienie, dostaje potwierdzenie, a po kilku dniach czyta, że towar jest niedostępny. Taka sytuacja obniża zaufanie do sklepu szybciej niż większość innych błędów obsługi. Źródłem problemu rzadko bywa platforma sprzedażowa. Najczęściej brakuje połączenia z systemem WMS, który zarządza rzeczywistymi zapasami.
Platforma e-commerce nie wie, ile sztuk leży na regale. Operuje liczbą, którą ktoś wpisał ręcznie w panelu albo która pochodzi z ostatniego importu arkusza. Jeśli import wykonuje się raz dziennie, w międzyczasie towar mógł się sprzedać w innym kanale, ulec uszkodzeniu przy kompletacji albo trafić na inną lokalizację. Im większy asortyment i im więcej zamówień na dobę, tym trudniej utrzymać zgodność bez narzędzia, które robi to automatycznie.
Rozwiązaniem jest integracja systemów magazynowych z platformą sprzedażową, w której WMS zostaje jedynym źródłem informacji o dostępności. Sklep nie przechowuje wtedy własnej liczby sztuk. Przed potwierdzeniem zamówienia pyta system magazynowy o aktualny stan. Rola WMS wykracza w tym ujęciu poza sam magazyn i wpływa na wynik sprzedaży, co szerzej opisuje strona o roli WMS w rozwoju firmy.
Skutki rozbieżności widać w całej obsłudze klienta. Dział wsparcia tłumaczy opóźnienie, którego nie spowodował, zwrot pieniędzy rozlicza się ręcznie, a klient zostawia negatywną opinię, zanim dostanie wyjaśnienie. Przy kilkudziesięciu zamówieniach na dobę koszt takich zdarzeń, liczony czasem zespołu i utraconą sprzedażą, potrafi przekroczyć koszt integracji, która usuwa problem u źródła. Podstawy pracy ze stanami magazynowymi opisuje osobny artykuł.
Przepływ zamówienia od sklepu do wysyłki
Zamówienie przechodzi kilka etapów, zanim dotrze do klienta w postaci przesyłki, a każdy z nich realizuje system magazynowy, nie sama platforma. Po złożeniu zamówienia WMS rezerwuje towar i blokuje go przed sprzedażą w innym kanale. Po potwierdzeniu płatności zlecenie trafia do kolejki kompletacji. Magazynier dostaje listę pozycji z lokalizacjami, co skraca czas szukania. Proces kompletacji zleceń kończy się zapakowaniem przesyłki, a system generuje dokumenty magazynowe.
Na końcu towar trafia do przewoźnika, a ten krok wiąże się z planowaniem wysyłek z magazynu: godzinami odbioru i priorytetami zamówień. Numer przesyłki wraca do sklepu bez ręcznego wpisywania, więc klient dostaje powiadomienie o nadaniu bez udziału obsługi. Praktyki współpracy z przewoźnikami omawia strona o wysyłce z magazynu przez firmy kurierskie.
Etapy zamówienia online w systemie WMS
Tabela pokazuje, co dzieje się na każdym etapie z perspektywy systemu magazynowego i jaki skutek widzi klient sklepu.
| Etap zamówienia online | Działanie WMS | Skutek dla klienta |
|---|---|---|
| Złożenie zamówienia | Rezerwuje towar i blokuje go przed sprzedażą w innym kanale | Widzi status przyjęcia do realizacji zamiast informacji o braku towaru |
| Potwierdzenie płatności | Zwalnia zlecenie do kolejki kompletacji | Zamówienie trafia do pakowania bez zwłoki |
| Kompletacja i pakowanie | Generuje listę kompletacyjną i dokument WZ | Dostaje towar zgodny z zamówieniem |
| Nadanie przesyłki | Przekazuje numer śledzenia do platformy sprzedażowej | Widzi status wysyłki i przewidywany termin dostawy |
| Dostawa | Aktualizuje status zamówienia jako zrealizowane | Zamówienie zamyka się bez działania obsługi |
Dla sklepów, które łączą sprzedaż z własnym transportem, ważne bywa też planowanie tras. Ten temat omawia artykuł o programie TMS w e-commerce.
W handlu internetowym przeważają zamówienia o małej liczbie pozycji, więc magazyn nie kompletuje ich pojedynczo. Zlecenia grupuje się w fale według godziny odbioru przewoźnika. Lista kompletacyjna fali porządkuje pozycje według kolejności lokalizacji na hali, a przy stanowisku pakowania towar zostaje rozdzielony na konkretne zamówienia. Skrócenie drogi magazyniera zależy wtedy od tego, jak system układa listę, a nie od tempa samego człowieka.
Rezerwacja towaru i ostatnia sztuka
Dostępność, którą widzi klient, jest różnicą między stanem fizycznym a rezerwacjami. Sklep pokazuje więc liczbę, która maleje już w chwili złożenia zamówienia, a nie dopiero po kompletacji. Trudność pojawia się, gdy dwóch klientów kupuje ostatnią sztukę w tej samej sekundzie. Obie transakcje odczytają stan równy jeden i obie spróbują go zarezerwować.
Bezpieczne rozwiązanie sprawdza warunek i zmienia dane w jednej instrukcji. Poniższy szkic używa pojedynczego UPDATE z warunkiem dostępności. Nazwy tabel są przykładowe i nie oddają struktury konkretnego produktu.
-- przykładowy schemat, nie struktura konkretnego produktu
UPDATE StockLevel
SET Reserved = Reserved + @Qty
WHERE ItemId = @ItemId
AND OnHand - Reserved >= @Qty;
IF @@ROWCOUNT = 0
SELECT 'BRAK' AS Result; -- za mało wolnego towaru
ELSE
SELECT 'OK' AS Result;Instrukcja UPDATE zakłada blokadę na wierszu, więc druga rezerwacja czeka na zakończenie pierwszej i dopiero potem sprawdza warunek na zmienionych danych. Zasady blokowania i wersjonowania wierszy opisuje przewodnik Transaction locking and row versioning guide w Microsoft Learn.
Reguła: rezerwacja ma termin ważności. Zamówienie bez zaksięgowanej płatności zwalnia towar po ustalonym czasie, a robi to zadanie SQL Agent uruchamiane co kilka minut. Bez tego niezapłacone koszyki blokują zapas i sklep pokazuje towar jako niedostępny, choć leży na regale.
Czas rezerwacji zależy od metody płatności. Płatność natychmiastowa wymaga krótkiego okna, a przelew tradycyjny dłuższego. Warto zapisywać w rezerwacji jej powód i termin, żeby raport wolnych zapasów pokazywał, które sztuki zablokowano w oczekiwaniu na wpłatę.
Synchronizacja stanów przez API i webhooki
Zgodność stanów nie jest zadaniem jednorazowym, tylko procesem ciągłym. Każda zmiana ilości, na przykład przyjęcie dostawy albo korekta inwentaryzacyjna, powinna być widoczna w sklepie po kilku sekundach, a nie po zbiorczej synchronizacji co godzinę. Systemy komunikują się przez API albo przez powiadomienia typu webhook. W drugim wariancie informacja o zmianie trafia do platformy zaraz po zapisie w magazynie, bez cyklicznego odpytywania obu stron.
| Mechanizm | Opóźnienie | Ryzyko do opanowania |
|---|---|---|
| Import zbiorczy raz na godzinę | Do godziny | Sprzedaż towaru, który już się skończył |
| Odpytywanie API co kilka minut | Minuty | Duża liczba zapytań o niezmienione dane |
| Webhook po każdej zmianie | Sekundy | Powiadomienia docierające w złej kolejności lub wcale |
Powiadomienia mogą dotrzeć w innej kolejności, niż powstały. Odbiorca musi więc rozpoznać nowsze dane po numerze wersji, a nie po czasie odbioru. Przykładowy komunikat pokazuje minimalny zestaw pól.
{
"eventId": "EV-0001874",
"sku": "KRZ-100",
"available": 14,
"version": 5231,
"sentAt": "2026-09-30T08:15:42Z"
}Odbiorca zapisuje stan tylko wtedy, gdy version jest większa od zapisanej dla danego SKU. Ponowione powiadomienie z tym samym eventId zostaje pominięte. Dzięki temu opóźniony komunikat nie cofa stanu do wartości sprzed kilku sekund.
Zasada awaryjna: przy braku kontaktu z WMS sklep pokazuje ostatni znany stan tylko dla towarów o dużym zapasie. Dla ostatnich sztuk wstrzymuje sprzedaż do odzyskania łączności.
Dobrą praktyką jest niewielki bufor bezpieczeństwa między stanem rzeczywistym a pokazywanym w sklepie, zwłaszcza dla towaru o dużej rotacji, sprzedawanego równolegle w kilku kanałach. Margines chroni przed sytuacją, w której dwóch klientów kupuje ostatnią sztukę, zanim synchronizacja zdąży zablokować ofertę. Bufor ustawia się osobno dla kategorii, zależnie od tego, jak często zmienia się jej stan.
Integracja musi znosić awarie łącza. Komunikaty, których nie udało się dostarczyć, trafiają do kolejki i są ponawiane z rosnącym odstępem czasu, a nie w pętli bez przerwy. Gdy opóźnienie przekroczy ustalony próg, system zgłasza alert opiekunowi.
Mapowanie towarów i jednostek między systemami
Sklep i magazyn opisują ten sam towar innymi pojęciami. Dla platformy produkt ma warianty i ceny. Dla WMS liczy się kod SKU oraz jednostka miary. Integracja wymaga tabeli odwzorowań, która wiąże identyfikator produktu w sklepie z kartoteką magazynową. Błąd w tej tabeli jest trudniejszy do wykrycia niż awaria łącza, bo wszystko działa, tylko na niewłaściwym towarze.
| Pojęcie w sklepie | Odpowiednik w WMS | Pułapka |
|---|---|---|
| Wariant produktu, na przykład rozmiar | Osobny kod SKU w kartotece | Brak wspólnego kodu wariantu po obu stronach |
| Zestaw promocyjny | Lista składników pobieranych do kompletacji | Rezerwacja liczona dla zestawu, a nie dla składników |
| Opakowanie zbiorcze | Przelicznik jednostek miary | Zaokrąglenie ilości przy przeliczaniu |
| Status zamówienia "opłacone" | Zwolnienie zlecenia do kompletacji | Dwukrotne zwolnienie po ponowionym powiadomieniu o płatności |
Identyfikator zamówienia ze sklepu zapisuje się w dokumencie magazynowym jako numer zewnętrzny z indeksem unikalnym. Ponowiony import tego samego zamówienia zostaje wtedy odrzucony i nie tworzy drugiego zlecenia. Ten sam numer pozwala później powiązać zwrot z pierwotną sprzedażą, o czym mowa w ostatniej części artykułu.
Sprzedaż wielokanałowa z jedną pulą zapasów
Niewiele firm sprzedaje przez jeden kanał. Obok własnego sklepu pojawiają się profile na marketplace'ach, takich jak Allegro czy Amazon, a czasem także punkt stacjonarny. Każdy kanał ma własny panel i własny sposób pokazywania dostępności. Bez wspólnego systemu magazynowego ten sam produkt sprzedaje się z dwóch niezsynchronizowanych pul zapasu.
WMS połączony ze wszystkimi kanałami prowadzi jedną pulę zapasów. Każdy kanał pobiera z niej dostępność w chwili wyświetlania oferty. Sprzedaż w sklepie stacjonarnym natychmiast zmniejsza stan widoczny w sklepie internetowym i na marketplace'ach, więc żaden kanał nie oferuje towaru, który opuścił magazyn. Model ten nazywa się sprzedażą omnichannel. Wymaga od systemu obsługi wielu formatów zamówień i wielu integracji jednocześnie. W zamian pracownik wykonuje jedną operację w WMS, a jej skutek pojawia się we wszystkich podłączonych kanałach. Szerszy przegląd łączenia WMS z systemami ERP oraz platformami sprzedaży zawiera strona o integracjach programu WMS.
Firma może też ustalać priorytety. Część zapasu warto zarezerwować dla zamówień hurtowych, jeśli dają wyższą marżę niż detal. Osobne reguły minimalnego stanu dla kanałów pozwalają odłożyć niewielką pulę wyłącznie dla sklepu stacjonarnego, w którym klient stoi już przy kasie, podczas gdy kanały internetowe pokazują wyprzedany produkt kilka minut wcześniej.
Marketplace'y ograniczają liczbę zapytań API w jednostce czasu. Integracja kolejkuje więc zmiany stanu i łączy kilka zmian tego samego SKU w jedną, zamiast wysyłać każdą osobno. Taki mechanizm zmniejsza ryzyko przekroczenia limitu i zablokowania wymiany danych w środku sezonu sprzedaży.
Zasada: reguły przydziału zapasu do kanałów przechowuje WMS, a nie panele platform. Gdy każdy kanał operuje na własnej kopii danych, reguł nie da się egzekwować.
Zwroty z e-commerce w systemie magazynowym
Zwroty są w handlu internetowym stałym elementem pracy magazynu, bo klient kupuje bez obejrzenia produktu i częściej korzysta z prawa do odstąpienia od umowy niż w sprzedaży stacjonarnej. Bez systemu magazynowego obsługa polega na ręcznym przyjęciu paczki i sprawdzeniu zawartości. Potem trzeba osobno poinformować sklep o zmianie stanu, co wydłuża czas, zanim towar wróci do sprzedaży.
WMS rejestruje zwrot jako osobny dokument magazynowy, zwykle korektę wydania. Następnie kieruje towar do jednej z kilku ścieżek. Automatyczne powiązanie zwrotu z pierwotnym zamówieniem przyspiesza też zwrot płatności, bo dział obsługi widzi moment przyjęcia towaru z powrotem. Rodzaje dokumentów towarzyszących takim operacjom opisuje artykuł o dokumentach magazynowych, a przypadki uszkodzeń i reklamacji - strona o programie do reklamacji w sklepie.
| Stan zwróconego towaru | Decyzja | Skutek w stanie magazynowym |
|---|---|---|
| Nienaruszone opakowanie | Powrót do sprzedaży | Ilość dostępna rośnie po zatwierdzeniu przyjęcia |
| Wątpliwy stan produktu | Strefa kontroli jakości | Towar zablokowany do decyzji, niewidoczny w sklepie |
| Uszkodzenie uniemożliwiające sprzedaż | Utylizacja lub reklamacja u dostawcy | Zdjęcie ze stanu z zapisem przyczyny |
Zwrot częściowy wymaga osobnego wiersza dokumentu dla każdej pozycji, a nie dla całego zamówienia. Sklep dostaje informację o ilościach faktycznie przyjętych, więc kwota zwrotu płatności odpowiada zawartości paczki, a nie deklaracji klienta. Gdy paczka zawiera towar spoza zamówienia, dokument oznacza go jako nadwyżkę i kieruje do wyjaśnienia z klientem.
Ważne, by decyzja o losie towaru zapadała przed przywróceniem go do stanu dostępnego. Zwrot przyjęty od razu jako dostępny bywa sprzedany kolejnemu klientowi, zanim ktoś sprawdzi jego stan. System, w którym przyjęcie zwrotu domyślnie trafia do strefy kontroli, ogranicza takie zdarzenia. Opis programu, który obsługuje takie procesy, znajduje się na stronie programu magazynowego WMS.
