Dlaczego stany i rezerwacje „rozjeżdżają się” między ERP a marketplace
Główne źródła niespójności: opóźnienia, błędy, procesy
Niespójne stany magazynowe między ERP a marketplace’ami zwykle nie biorą się z jednego, spektakularnego błędu. To wynik nałożenia się kilku zjawisk: opóźnień w synchronizacji, nieprzemyślanej logiki rezerwacji, ręcznych korekt w magazynie, niepełnych integracji oraz zmian robionych „na szybko” przez różne działy. Efekt: w ERP widać 5 sztuk, Allegro pokazuje 3, Amazon 0, a sklep SaaS 4 – i nikt nie jest w stanie powiedzieć, kto ma rację.
Najczęstsze źródła niespójności to:
Opóźnienia integracji – cron odświeżający stany co 15–30 minut przy intensywnej sprzedaży jest proszeniem się o podwójną sprzedaż ostatnich sztuk.
Błędy w mapowaniu statusów – zamówienia „oczekujące na płatność” czasem rezerwują towar, czasem nie. Integracja nie zawsze to rozróżnia.
Ręczne operacje w ERP lub WMS – korekty stanów, awaryjne przesunięcia, dopisywanie brakujących sztuk bez konsekwentnego przepchnięcia tych zmian do marketplace.
Niejednoznacznym „stanem magazynowym” – dla magazynu to sztuki fizyczne, dla sprzedaży – to, co można jeszcze sprzedać, dla księgowości – to, co jest na dokumentach PZ/WZ.
Brak jednego systemu nadrzędnego – każdy kanał „wie swoje”, integrator potrafi nadpisywać ERP, marketplace może nadpisywać integratora.
Synchronizacja stanów magazynowych ERP z marketplace’ami bez wyraźnie zdefiniowanej logiki „kto decyduje kiedy” prowadzi do sytuacji, w której każdy system widzi inne dane przez większość dnia, a dopiero nocna synchronizacja „prostuje” obraz – jeśli w ogóle.
Żeby sensownie połączyć ERP z marketplace tak, aby stany i rezerwacje nie rozjeżdżały się w nocy, trzeba prześledzić cały cykl życia zamówienia. W uproszczeniu wygląda to tak:
Klient składa zamówienie w marketplace (np. Allegro).
Marketplace tworzy zamówienie i zwykle blokuje stock po swojej stronie (swoją logiką).
Integrator (lub bezpośrednia integracja ERP) pobiera to zamówienie przez API.
ERP tworzy dokument zamówienia i rezerwację towaru lub jedynie informację o zapotrzebowaniu.
Magazyn (WMS lub moduł magazynowy ERP) kompletuje zamówienie, skanuje produkty, wydaje towar.
ERP aktualizuje stan magazynowy oraz stan dostępny do sprzedaży.
Integracja odsyła aktualny stock do marketplace.
Na każdym kroku można popełnić błąd procesowy lub integracyjny. Jeśli rezerwacja w ERP nie powstanie odpowiednio wcześnie albo powstanie za późno, kolejne zamówienie z innego kanału „zje” te same sztuki. Jeśli marketplace ma swoje własne opóźnienia w przetwarzaniu płatności, a ERP tworzy rezerwacje dopiero przy statusie „opłacone” – okno konfliktu dramatycznie się wydłuża.
Co się dzieje w nocy: crony, batchowe aktualizacje, brak ludzi
Noc to najczęściej czas, gdy:
odpalane są zadania batchowe – masowa aktualizacja stanów, cen, synchronizacja opisów, importy dostaw, zaciąganie faktur,
nie ma pełnej obsady w magazynie ani w dziale IT – nikt „na żywo” nie reaguje na błędy,
w marketplace’ach nadal trwają zakupy – zwłaszcza w retailu, kategorii hobby, elektronice, ubraniach,
niektóre integracje są celowo spowalniane, aby nie przekraczać limitów API marketplace.
W nocy szczególnie groźne są:
dlugie okna synchronizacji – np. jednorazowe, nocne „zrównanie” stanów zamiast stabilnego, całodobowego mechanizmu near real-time,
korekty magazynowe i inwentaryzacje – wykonywane po zamknięciu dnia sprzedażowego, a publikowane w marketplace dopiero rano,
brak retry – jeśli integracja nie potrafi powtórzyć aktualizacji stanu po błędzie API, dane potrafią „utknąć” na całą noc.
To właśnie wtedy pojawiają się nadpisane stany magazynowe: ERP po inwentaryzacji wysyła „prawdziwy” stan, integrator ma jeszcze w kolejce kilka nieprzetworzonych zamówień, marketplace trzyma swoje rezerwacje, a każdy system uważa, że ma aktualne dane.
Różnice filozofii: „stan księgowy” vs „stan dostępny do sprzedaży”
ERP i marketplace inaczej rozumieją pojęcie „stocku”. ERP jest z natury systemem księgowo-logistycznym, więc interesuje go stan księgowy: ile sztuk jest na dokumentach PZ, ile wydano na WZ, ile jest w trakcie przyjęcia lub przesunięcia. Marketplace patrzy na stan dostępny do sprzedaży: czy da się wystawić ofertę z daną liczbą sztuk i uniknąć oversellingu.
Przykładowe różnice filozofii:
W ERP część stanów jest w drodze (np. PZ w buforze, dostawa na przeładunku) – dla marketplace to nie istnieje, dopóki nie da się tego fizycznie wysłać do klienta w założonym SLA.
ERP potrafi trzymać towar zarezerwowany na zamówienia, ale nadal fizycznie leżący na półce – marketplace chce widzieć tylko to, co nie jest już nigdzie zablokowane.
ERP może obsługiwać kompletacje, rozkompletowania zestawów, partie i numery seryjne – marketplace widzi tylko prostą liczbę sztuk na poziomie SKU.
Dlatego proste „wysyłaj aktualny stan z ERP” rzadko bywa dobrą radą. Najczęściej należy z ERP wyciągnąć stan dostępny, czyli stan fizyczny minus rezerwacje i inne blokady, ewentualnie jeszcze z korektą buforu bezpieczeństwa.
Przykładowy scenariusz: kilka zamówień na ostatnią sztukę z różnych kanałów
Realistyczny scenariusz pokazujący, skąd się bierze „rozjechanie”:
W magazynie jest 1 sztuka produktu X.
ERP pokazuje 1 szt., integrator wypchnął 1 szt. na Allegro, Amazon, sklep SaaS.
W odstępie kilku minut wpadają zamówienia:
klient A kupuje przez Allegro,
klient B kupuje przez sklep SaaS,
klient C składa zamówienie przez telefon, sprzedawca rejestruje je w ERP.
Jeśli:
rezerwacja w ERP powstaje dopiero po zaksięgowaniu płatności z marketplace,
integracja stanów działa co 15 minut,
sprzedawca telefoniczny nie widzi w ERP rezerwacji z marketplace’ów w czasie rzeczywistym,
to bardzo łatwo o trzy rezerwacje na jedną sztukę. Magazyn wykryje problem dopiero przy kompletacji, zwykle w ciągu dnia roboczego, a klienci z marketplace’ów dowiedzą się o braku towaru z opóźnieniem – po nocy z oversellingiem w tle.
Jak zmapować procesy magazynowe na logikę marketplace
Stan fizyczny, księgowy, dostępny, zarezerwowany – definicje i rozgraniczenie
Zanim zacznie się konfigurację integracji, trzeba zdefiniować słownik pojęć. Bez tego rozmowy typu „wyślij stan magazynowy” zawsze kończą się błędnym zrozumieniem.
Najpraktyczniejszy podział:
Stan fizyczny – ile sztuk faktycznie leży w magazynie (na półkach, w strefach pickingowych, rezerwowych). To „prawda fizyczna”, zwykle znana najlepiej WMS.
Stan księgowy – to, co wynika z dokumentów przyjęć (PZ), wydań (WZ), przesunięć (MM) i korekt. Księgowość patrzy na niego w raportach, ale rzadko odpowiada on temu, co faktycznie można sprzedać w danym momencie.
Stan zarezerwowany – ilość sztuk przypisana już do konkretnych zamówień (marketplace, B2B, telefon, sklep stacjonarny). Ta ilość nie powinna być dostępna do sprzedaży w innych kanałach.
Stan dostępny do sprzedaży – stan fizyczny minus rezerwacje (i ewentualnie minus inne blokady, np. uszkodzenia, towar na reklamacji). To właśnie ten stan powinien być bazą do synchronizacji z marketplace.
Większość problemów zaczyna się wtedy, gdy integracja bierze „stan magazynowy” z ERP bez precyzji, co to znaczy. W jednym systemie „stan magazynowy” obejmuje rezerwacje, w innym nie. W jednym wynik jest po inwentaryzacji, w innym bez.
Gdzie w ERP powstaje rezerwacja i kiedy powinna blokować sprzedaż
Moment powstania rezerwacji to jedna z kluczowych decyzji procesowych. Zbyt wcześnie – blokuje się towar dla zamówień, które i tak upadną. Zbyt późno – otwiera się okno oversellingu.
Typowe podejścia:
Rezerwacja przy utworzeniu zamówienia – towar blokowany już przy statusie „oczekujące na płatność”. Bezpieczne dla stocku, ale może blokować go pod niezapłacone zamówienia, które w ogóle nie dojdą do skutku.
Rezerwacja przy potwierdzeniu / opłaceniu – rezerwacja powstaje dopiero, gdy marketplace zgłosi „paid” lub „ready to ship”. Bezpieczniejsze dla obrotu towarem, ale tworzy ryzyko, gdyż kilka kanałów może w tym samym czasie widzieć tę samą 1 sztukę jako dostępną.
Rezerwacja hybrydowa – twarda rezerwacja powstaje przy opłaceniu, ale ERP lub integrator stosuje tymczasowe blokady przy zamówieniu oczekującym, aby obniżyć stan dostępny dla innych kanałów.
W praktyce najlepiej sprawdza się model, w którym:
zamówienia z marketplace’ów tworzą rezerwację już przy statusie „przyjęte / oczekujące”, ale z krótkim czasem życia (np. automatyczne zwalnianie po wygaśnięciu zamówienia),
zamówienia B2B czy telefoniczne – w zależności od ustalonej polityki – mogą blokować towar od razu lub dopiero po potwierdzeniu,
ERP od razu redukuje stan dostępny na potrzeby synchronizacji, nawet jeśli rezerwacja jest „miękka”.
Jak marketplace rozumie „stock” (bez rezerwacji)
Większość marketplace’ów (Allegro, Amazon, eBay) nie chce znać złożonej struktury stanów w ERP. Oczekują jednej liczby:
stock = liczba sztuk dostępnych do sprzedaży.
To oznacza, że dla marketplace nie ma znaczenia:
czy część towaru leży na innym magazynie, jeśli i tak nie będzie z niego obsługiwana dana oferta,
czy towar jest „w drodze”, dopóki nie ma go w strefie, z której można wysłać przesyłkę,
czy ERP ma jakieś wewnętrzne blokady, np. na zamówienia wewnętrzne lub produkcję.
Marketplace interesuje tylko to, co można wysłać klientowi w czasie zgodnym z deklaracją. Wszystko inne trzeba zatrzymać w ERP/WMS i nie wypuszczać do zewnętrznych kanałów jako dostępny stock.
Dlaczego proste „wysyłaj aktualny stan z ERP” często się mści
Popularna rada integratorów – „wystarczy co X minut wysyłać aktualny stan z ERP” – działa wyłącznie w małych, mało dynamicznych magazynach, gdzie:
liczba zamówień na SKU jest bardzo niska,
nie ma wielu kanałów sprzedaży,
nie ma złożonych rezerwacji (np. B2B z terminem realizacji).
Kiedy to nie działa:
przy popularnych SKU, które potrafią sprzedać się kilkanaście razy w godzinę na różnych marketplace’ach,
gdy ERP jest „ciężkie” i generowanie stanu dla całego asortymentu trwa długo,
kiedy pracuje dodatkowy WMS i to on wie pierwszy o przyjęciach i wydaniach.
W takich warunkach co 15–30 minut powstaje „fotka” stanów, która szybko się dezaktualizuje. Marketplace pracują na przestarzałej informacji, a integracja z opóźnieniem nadpisuje dane, zamiast je uzupełniać.
Kiedy lepiej wysyłać stan „dostępny” zamiast „magazynowy”
W praktyce większość firm powinna do marketplace’ów wysyłać stan dostępny, a nie „stan magazynowy”. Stan dostępny to:
stan fizyczny – rezerwacje – blokady techniczne – bufor bezpieczeństwa.
Kiedy to szczególnie pomaga:
przy sprzedaży wielokanałowej (ERP, B2B, sklep stacjonarny, kilka marketplace’ów),
Bufor bezpieczeństwa – po co, jak go policzyć i kiedy z niego zrezygnować
Większość integracji stocku prędzej czy później dochodzi do tematu „bufora bezpieczeństwa”. Zwykle przychodzi to w formie prostej rady: „odejmij 1–2 sztuki od stanu i będzie po problemie”. Działa to tylko częściowo.
Bufor ma sens, gdy:
sprzedajesz produkty o wysokiej rotacji i częstych zwrotach,
masz fizycznie rozproszony magazyn (kilka lokalizacji, strefy przeładunkowe),
integracja nie jest całkowicie on-line i musisz pogodzić się z kilkuminutowym opóźnieniem.
Prosty, stały bufor „minus 1 sztuka” bywa jednak zabójczy dla produktów o niskiej rotacji. Jeżeli kupujesz po 2–3 sztuki na sezon, a integracja ustawia stan 0 tylko dlatego, że „tak ustawiliśmy bufor”, to tracisz sprzedaż nie dlatego, że nie ma towaru, tylko dlatego, że logika integracji jest zbyt prymitywna.
Rozsądniejsze podejście do buforów:
Bufor procentowy (np. 5–10% stanu, zaokrąglany w dół) – ma sens przy produktach z dużym stanem i dużą rotacją. „Zjada” część towaru, ale zostawia pole manewru przy pomyłkach i zwrotach.
Bufor zależny od rotacji – dla produktów szybko rotujących większy bufor, dla „leżaków” minimalny lub zerowy. Dane o rotacji zazwyczaj są w ERP lub w BI, wystarczy je wykorzystać w logice eksportu.
Bufor zależny od kanału – dla Allegro/FBA większe bezpieczeństwo, dla własnego sklepu mniejszy (łatwiej skoordynować obsługę i komunikację z klientem).
Dość rzadko mówi się o tym, że bufor w ogóle nie jest potrzebny, gdy:
ERP/WMS rezerwuje w czasie rzeczywistym wszystkie zamówienia z marketplace’ów,
stan jest aktualizowany „eventowo” (po każdej rezerwacji, a nie co X minut),
fizyczny proces kompletacji jest bardzo zdyscyplinowany (mało błędnych wydań, skanowanie kodów kreskowych obowiązkowe).
Wtedy bufor staje się protezą złych procesów, a nie zabezpieczeniem. Lepiej zainwestować wysiłek w uspójnienie rezerwacji i integracji niż maskować wszystkie problemy nadmiernym „minus 2 sztuki na wszystko”.
Źródło: Pexels | Autor: Tiger Lily
Modele integracji: od prostych aktualizacji po dwukierunkowe sprzężenie
Jednokierunkowa aktualizacja stanów – kiedy wystarczy
Najprostszy model integracji to:
ERP liczy stan dostępny → integrator wysyła go do marketplace’ów w określonym interwale.
Taka integracja wystarcza, jeśli:
sprzedaż marketplace’ów to mały procent całości obrotu,
nie ma dodatkowych kanałów „zjadających” stock w czasie rzeczywistym (np. duża sprzedaż B2B, hurtownie, kilka sklepów stacjonarnych),
nie sprzedajesz produktów o ekstremalnie wysokiej rotacji na pojedyncze SKU.
Dobrą praktyką jest w tym modelu:
oddzielenie logiki wyliczania stanu dostępnego od warstwy integracyjnej (osobny widok, procedura, API w ERP),
aktualizacja stanów różnicowo (wysyłanie tylko tego, co się zmieniło),
priorytetowe wysyłanie zmian dla bestsellerów, zamiast „przeklikiwania” całego katalogu w kółko.
Jeśli w takim środowisku „rozjeżdża się” stock, to zwykle winny jest nie model integracji, tylko:
brak spójnej logiki rezerwacji (np. zamówienia telefoniczne nie tworzą od razu blokad),
ręczne korygowanie stanów na marketplace’ach przez opiekunów kont,
brak jednego źródła prawdy – część zamówień wpada najpierw do systemu marketplace, część do ERP, a integracja „domyśla się”, co zrobić.
Dwukierunkowa integracja: zamówienia i stany jako jeden obieg
ERP → marketplace: stany dostępne, statusy zamówień, numery przesyłek.
Tu kluczowe jest to, żeby integracja była zbudowana wokół zdarzeń, a nie tylko harmonogramów. Pełen obieg wygląda wtedy mniej więcej tak:
Marketplaces generuje zamówienie → integrator natychmiast (webhook/API) tworzy je w ERP.
ERP od razu tworzy rezerwację i przelicza stan dostępny.
Zmiana stanu dostępnego dla SKU trafia – najlepiej od razu – do wszystkich marketplace’ów, gdzie to SKU jest wystawione.
Magazyn kompletuje, system WMS/ERP aktualizuje wydania, co znowu obniża fizyczny stan.
Integrator eksportuje statusy wysyłki i numery śledzenia do marketplace’ów.
Największy błąd w tym modelu to traktowanie zdarzeń pochodzących z marketplace’ów jak czegoś mniej ważnego niż zamówienia z własnego sklepu czy zamówienia B2B. Jeśli zamówienia „zewnętrzne” trafiają do ERP z opóźnieniem, rezerwacje zawsze będą spóźnione względem tego, co widzi klient na portalu sprzedażowym.
Decentralizacja: integrator jako „mini-ERP” dla kanałów online
Popularna, ale rzadko dobrze opisana praktyka: część firm wykorzystuje warstwę integracyjną jako bufor przed ERP. Zamówienia z marketplace’ów trafiają najpierw do integratora, który:
tworzy wstępne rezerwacje „wirtualne”,
od razu aktualizuje stany na innych marketplace’ach,
a dopiero potem – w cyklu wsadowym – wprowadza zamówienia do ERP.
Taka „mini-warstwa ERP” w integratorze ma sens, gdy:
posiadasz kilka różnych ERP/WMS (np. po przejęciach spółek),
główne ERP nie jest dostępne 24/7 lub ma bardzo ograniczone API,
kanały e-commerce są dużo bardziej dynamiczne niż reszta organizacji.
Minus: łatwo wtedy stworzyć dwa rozbieżne światy – „prawdziwe” ERP i „szybkie” ERP w integratorze. Jeśli nie definiuje się jasno, który system „ma rację” w przypadku konfliktu, eskalacja problemów jest tylko kwestią czasu.
Kluczowe punkty styku: zamówienia, rezerwacje, stany, zwroty
Jak traktować zamówienie z marketplace jako zdarzenie magazynowe
Dla marketplace zamówienie to rekord w bazie i prowizja. Dla magazynu – konkretne polecenie: odłóż X sztuk z lokalizacji Y, nie sprzedawaj ich nikomu innemu. Sensowna integracja powinna:
przekładać każde zamówienie na rezerwację magazynową w ERP/WMS,
powiązać rezerwację z konkretnym miejscem składowania (jeśli WMS jest na tyle zaawansowany),
widzieć zamówienie jako „zjadające” stan dostępny natychmiast, a nie dopiero po płatności/fakturze.
W praktyce oznacza to, że:
status „zamówienie nowe / oczekujące” z marketplace powinien obniżyć stan dostępny,
status „zamówienie anulowane / nieopłacone” musi zwolnić rezerwację,
wszystkie te zmiany powinny przechodzić pełnym obiegiem – aż do aktualizacji oferty.
Zwroty i reklamacje – cichy zabójca spójności stanów
Zamówienia wszyscy widzą, zwroty lubią ginąć w gąszczu procedur. Z punktu widzenia integracji kluczowe są dwa momenty:
Chwila, kiedy marketplace rejestruje zwrot/otwarcie sprawy (RMA, return request).
Chwila, kiedy towar fizycznie wraca do magazynu i przechodzi przyjęcie.
Między tymi dwoma punktami towar jest „w zawieszeniu”. Jeśli integracja traktuje go jako dostępny stock, o overselling nietrudno; jeśli blokuje go zbyt długo, ogranicza sprzedaż bez realnej potrzeby.
Praktyczny kompromis:
od razu po zgłoszeniu zwrotu w marketplace – tymczasowo obniżyć stan dostępny, np. założyć, że towar wróci i będzie znowu sprzedawalny dopiero po inspekcji,
w momencie przyjęcia zwrotu na magazyn – przenieść go najpierw na strefę kontroli jakości (technicznie osobny magazyn / strefa w ERP/WMS),
dopiero po pozytywnej weryfikacji – przywrócić do strefy sprzedażowej i tym samym podnieść stock na marketplace’ach.
Wiele integracji zupełnie omija etap „zwrot w drodze”, przez co raporty wyglądają dobrze, dopóki nie trzeba wyjaśniać, dlaczego w systemie było 10 sztuk, a fizycznie na półce tylko 7.
Rezerwacje wewnętrzne vs sprzedaż marketplace – kto ma priorytet
Konflikt typowy dla firm łączących B2B i B2C: duży klient hurtowy ma zamówienie na całe palety, a marketplace generuje dziesiątki zamówień detalicznych. Jeśli ERP nie rozstrzyga priorytetów, integracja będzie ślepo aktualizować stany, nie wiedząc, że część stocku jest „nietykalna”.
Do poukładania:
czy rezerwacje dla kluczowych klientów B2B w ogóle mają wpływać na stan dostępny dla marketplace’ów,
czy bufory bezpieczeństwa mają być różne dla sprzedaży hurtowej i detalicznej,
czy wolno „ruszyć” stock zarezerwowany pod B2B, gdy marketplace ma płatne zamówienie (reguły awaryjne).
Kontrariański, ale praktyczny wariant: część firm świadomie wydziela osobną pulę stocku „tylko na marketplace” (osobny magazyn logiczny), którą uzupełnia wsadami z głównego magazynu. Z punktu widzenia księgowości to dodatkowa komplikacja, ale dla spójności stanów w kanałach online bywa to najczystsze rozwiązanie.
Źródło: Pexels | Autor: Tiger Lily
Podejście do synchronizacji stanów: pull/push, częstotliwość i priorytety
Model pull: marketplace okresowo „podgląda” ERP
W modelu pull marketplace lub integrator cyklicznie pobiera stany z ERP (np. API/plik) i aktualizuje oferty. Ten model jest naturalny dla starszych ERP-ów, gdzie to one „dyktują tempo”, a integracja ma ograniczony wpływ.
Korzyści:
mniejsza liczba wywołań API na stronę ERP (szczególnie, gdy ten jest wolny lub licencjonowany per request),
łatwiejsza parametryzacja – zmiana jednego harmonogramu kontroluje wszystko,
mniejsze ryzyko, że ERP zostanie „zastrzelone” setkami małych aktualizacji.
Słaby punkt: przy dużej dynamice sprzedaży pull zawsze będzie się spóźniał. Nawet gdy interwał wynosi minutę, w ciągu tej minuty mogą wpaść dziesiątki zamówień na bestseller.
Model push: ERP/integrator wysyła zmiany „na gorąco”
W podejściu push to ERP lub warstwa integracyjna inicjuje aktualizację:
powstała rezerwacja → natychmiast zmniejsz stan na ofertach,
został przyjęty towar → od razu go „dodaj” do stocku marketplace,
anulowano zamówienie → odblokuj stan i zwiększ ilość w ofertach.
Największy zysk z push widać przy:
SKU z bardzo wysoką rotacją,
integracji z WMS, który generuje zdarzenia z kompletacji i przyjęć,
kanałach wymagających szybkich reakcji (Amazon, systemy z twardymi karami za overselling).
Wadą jest obciążenie: wiele małych zdarzeń generuje dużo requestów. Jeśli marketplace ogranicza API (limity zapytań), trzeba rozważyć batching – grupowanie zmian w małe paczki, zamiast wysyłania każdej sztuki osobno.
Hybryda: push dla „wrażliwych” SKU, pull dla reszty
Najbardziej sensowny wariant dla wielu firm to model mieszany:
dla kilku/kilkunastu procent produktów generujących większość obrotu – push eventowy z priorytetem,
dla „ogona” asortymentu – okresowy pull co kilkanaście/kilkadziesiąt minut.
Logika wyboru „wrażliwych” SKU może opierać się na:
rotacji (np. top 10% SKU po liczbie sprzedaży w ostatnim kwartale),
marży (produkty strategiczne),
specyfice branży (np. limitowane kolekcje, które szybko schodzą).
Dzięki temu nie ma potrzeby budowania superwydajnej integracji dla całego katalogu – wystarczy zoptymalizować miejsce, gdzie faktycznie pojawia się ryzyko oversellingu.
Projektowanie buforów, nadpisywania i zasady „kto ma rację”
Bufory ilościowe – prosty bezpiecznik czy ukryty koszt sprzedaży
Standardowa porada brzmi: „ustaw bufor bezpieczeństwa na marketplace, np. pokazuj o kilka sztuk mniej niż masz w ERP”. Działa to przy stabilnych towarach, ale przy szybko rotujących SKU taki bufor potrafi trwale „zamrozić” kilkanaście procent realnego stocku.
Przy projektowaniu buforów rozsądniej patrzeć na nie jak na inwestycję w bezpieczeństwo, a nie magiczne rozwiązanie. Konkretnie:
bufor stały (np. zawsze -2 sztuki) ma sens przy niskiej rotacji i małej liczbie kanałów,
bufor procentowy (np. -10% stanu) sprawdza się przy drobnicy, gdzie jednostkowe sztuki nie są krytyczne,
bufor dynamiczny – powiązany z rotacją, lead time’em dostawy i liczbą kanałów – to rozwiązanie dla bardziej świadomych organizacji.
Model dynamiczny można oprzeć o proste zasady biznesowe zamiast zaawansowanej matematyki. Przykładowo:
SKU z rotacją > X zamówień dziennie na wszystkich kanałach – większy bufor (np. 15–20%),
SKU z dostawą „na telefon” od lokalnego dostawcy – minimalny bufor, bo ryzyko braku można szybko „załatać”,
SKU strategiczne dla B2B – osobny bufor lub wręcz odcięcie od marketplace (tylko sprzedaż własna).
Kluczowa pułapka: bufory ilościowe często są ustawiane „na sztywno” i nikt do nich nie wraca. Gdy zmieniają się wolumeny lub liczba kanałów, ten sam bufor, który kiedyś ratował przed oversellingiem, po kilku latach stanowi tylko ciche ograniczenie obrotu.
Bufory czasowe – świadome opóźnianie informacji
Drugim typem buforów są opóźnienia w propagacji informacji. Brzmi jak herezja („przecież chcemy jak najszybszej synchronizacji”), ale czasem chwilowe spowolnienie działa lepiej niż nerwowa aktualizacja po każdym wydarzeniu.
Przykład z praktyki: firma, która co noc przeprowadza inwentaryzację części magazynu i w tym czasie fizyczne operacje są wstrzymane lub wykonywane ręcznie. Zamiast udawać, że system „żyje” w czasie tej przerwy, lepiej:
wstrzymać aktualizacje stanów na marketplace’ach na czas inwentaryzacji,
po jej zakończeniu wykonać pełne przeliczenie stocku i dopiero wtedy puścić falę aktualizacji,
w integratorze nałożyć miękki limit zamówień na kluczowe SKU w tym oknie (np. maksymalna liczba sztuk sprzedawalnych w ciągu godziny).
Bufory czasowe są sensowne również przy:
nocnych batchach MRP/planowania, które drastycznie zmieniają rezerwacje,
dużych importach stanów z zewnętrznego WMS,
operacjach relokacji między magazynami (z punktu widzenia marketplace to jeden magazyn, ale w ERP stock „podróżuje”).
Popularna rada „aktualizuj zawsze jak najszybciej” nie działa tam, gdzie dużo dzieje się w tle. Lepiej zdefiniować krótkie „okna spójności”, w których system może się przeorganizować, niż serwować marketplace’om serię sprzecznych informacji w ciągu kilku minut.
Zasady „kto ma rację” przy konflikcie stanów
Bez jednoznacznej odpowiedzi na pytanie, który system jest nadrzędny w sporze o stan magazynowy, każdy kryzys będzie kończył się improwizacją. Zwykle są trzy typowe modele:
ERP ma zawsze rację – marketplace i integrator tylko odzwierciedlają to, co jest w systemie centralnym.
Integrator ma rację w obszarze e-commerce – ERP przyjmuje „gotowe” liczby dla kanałów online.
Model hybrydowy – ERP jest nadrzędne dla globalnych stanów, ale integrator może tymczasowo nadpisywać wartości w kanałach.
Pierwszy model jest naturalny dla organizacji z silnym działem finansów i rozbudowanymi procesami magazynowymi. Drugi – dla firm, w których ERP jest słabe technologicznie i pełni rolę bardziej księgi głównej niż realnego „mózgu operacji”. Hybryda jest próbą pogodzenia obu światów.
W praktyce warto doprecyzować kilka reguł konfliktu:
priorytet źródła: czy ręczna korekta w ERP może nadpisać dane z integratora, czy musi przejść przez określony workflow,
czas ważności danych: jak długo oferta marketplace może „żyć własnym życiem” po utracie kontaktu z ERP (np. awaria VPN),
obsługa niezgodności: co dzieje się, gdy integrator widzi 10 sztuk, ERP 7, a marketplace twierdzi, że sprzedał kolejne 5.
Kuszące jest ustawienie zasady „najniższy stan wygrywa” – bezpiecznej z punktu widzenia oversellingu. Problem zaczyna się, gdy błędna korekta lub awaria jednego systemu „wciąga w dół” cały ekosystem ofert, a sprzedaż siada na kilka godzin czy dni.
Nadpisywanie ręczne a automaty: kto komu przeszkadza
Ręczne korekty stanów w ERP to klasyczny sposób gaszenia pożarów. Problem w tym, że jeśli integracja działa w trybie push/pull bez świadomości takich działań, kolejne automatyczne przebiegi po prostu „odkręcą” to, co zrobił człowiek.
Żeby uniknąć wojny człowiek–automat, przydają się proste, ale klarowne zasady:
oznaczanie ręcznych korekt specjalnym typem dokumentu magazynowego (np. „ADJ_MANUAL”),
w integratorze reguła: jeśli pojawił się dokument korekty powyżej określonego progu (np. >10% stanu), wstrzymaj automaty dla tego SKU i eskaluj do osoby odpowiedzialnej,
krótka notatka przy korekcie – dlaczego została wykonana (np. inwentaryzacja ad hoc, błąd w przyjęciu dostawy, kradzież, uszkodzenie).
W większych organizacjach sprawdza się też odwrotna zależność: kluczowe korekty nie są robione w ERP, tylko w dedykowanym narzędziu (np. panel integratora), które następnie w kontrolowany sposób rozsyła zmiany do ERP i marketplace’ów. To odcina problem „kto ostatni kliknął” i pozwala zapanować nad historią zmian.
Źródło: Pexels | Autor: Tiger Lily
Transakcje, blokady i wydajność: techniczny fundament spójności
Transakcyjność w ERP a zdarzenia dla marketplace
Na papierze wszystko wygląda prosto: powstaje dokument WZ, system zmniejsza stan, integracja wysyła update do marketplace. W rzeczywistości operacje w ERP często są bardziej złożone: jedna akcja użytkownika uruchamia serię zapisów w wielu tabelach, nie zawsze w jednej transakcji.
Jeżeli integrator „nasłuchuje” nieodpowiedniego momentu, potrafi odczytać stan w połowie operacji. Efekt: marketplace dostaje informacje, że jest 0 sztuk, podczas gdy po zakończeniu procesu będzie ich 5. Dlatego przy projektowaniu mechanizmu zdarzeń sensowne jest:
korzystanie z hooków w ERP, które są wywoływane po pełnym zatwierdzeniu dokumentu (np. po zapisaniu WZ, a nie w trakcie kompletacji),
projektowanie kolejek zdarzeń (message queue), które przyjmują informację „co się stało” i dopiero potem spokojnie przetwarzają aktualizacje,
unikać bezpośredniego „podsłuchiwania” tabel bazodanowych ERP bez znajomości ich logiki transakcyjnej.
Wygrywa to podejście, w którym ERP lub WMS wysyła zdarzenie typu „reservation_created”, „shipment_confirmed”, a integrator sam dociąga aktualny stan z API. Minimalizuje to ryzyko, że pojedyncza literówka w zapytaniu SQL czy zmiana schematu bazy rozjedzie wszystko po cichu.
Blokady i sekcje krytyczne – jak nie zabić wydajności
Drugim, mniej widocznym problemem są blokady na rekordach magazynowych. Przy intensywnej sprzedaży wiele procesów chce jednocześnie modyfikować ten sam SKU: pakowanie, przyjęcie dostawy, korekta inwentaryzacyjna, a do tego integrator próbujący odczytać najnowszy stan.
Jeśli każdy update stanu wymaga twardej blokady rekordu, ERP może zwolnić do poziomu, który paraliżuje magazyn. Mimo to rozluźnienie blokad bez przemyślenia kończy się wyścigiem, kto „nadpisze” ostatni. Rozsądny kompromis zwykle obejmuje:
operacje magazynowe w krótkich, dobrze zdefiniowanych transakcjach,
odciążenie ERP przez cache stanów po stronie integratora (odczyt bez ciągłego sięgania do ERP, przy czym zapis nadal jest w ERP),
batchowe aktualizacje do marketplace zamiast wysyłania każdej zmiany osobno.
W niektórych WMS-ach pomaga też rozdzielenie „stanu księgowego” i „stanu operacyjnego”. Ten drugi może być aktualizowany częściej i z mniejszym reżimem blokad, będąc podstawą dla marketplace’ów, podczas gdy pierwszy służy księgowości i raportom okresowym.
Idempotencja i odporność na duplikaty
Integracje, które zakładają idealną sieć bez opóźnień i błędów, najczęściej wywracają się przy pierwszej większej awarii. Wyślij to samo zdarzenie dwa razy – i już stock na marketplace „skacze” o kilka sztuk w górę lub w dół.
Żeby temu zapobiec, mechanizm powinien traktować zdarzenia w sposób idempotentny – ten sam komunikat przetworzony wielokrotnie daje taki sam efekt. Można to osiągnąć na kilka sposobów:
nadawanie zdarzeniom unikalnych identyfikatorów (event_id) i trzymanie ich historii po stronie integratora,
zamiast wysyłać „-2 sztuki”, wysyłanie nowej wartości bezwzględnej (np. „aktualny stan 13 sztuk”),
weryfikacja, czy nowsze zdarzenie nie zostało już przetworzone (prosty timestamp/logiczny numer wersji stanu).
To kolejny obszar, gdzie prosta rada „wysyłaj tylko różnice (delta)” nie zawsze działa. Delta jest oszczędna, ale bardzo wrażliwa na duplikaty i zmianę kolejności zdarzeń. Dla krytycznych SKU lepiej wysyłać co jakiś czas pełen stan, nawet kosztem większego ruchu w API.
Strategie degradacji – co, gdy coś się psuje
Systemy produkcyjne mają to do siebie, że czasem po prostu nie działają: awaria łącza, przeciążone API marketplace, aktualizacja ERP, która trwa dłużej niż planowano. Bez planu awaryjnego integracja zamienia się wtedy w generator losowych oversellingów albo, przeciwnie, w blokadę sprzedaży.
Przy projektowaniu „trybów awaryjnych” warto jasno zdefiniować:
co się dzieje, gdy ERP jest niedostępne: czy integrator ma prawo dalej sprzedawać na podstawie ostatnich znanych stanów (i jak długo),
co jeśli API marketplace ma limity i odrzuca nadmiarowe żądania: czy batchujemy zmiany, czy priorytetyzujemy kluczowe SKU,
jakie działania są zabronione w trybie awaryjnym (np. brak możliwości ręcznych korekt stanów, tylko rejestracja sprzedaży).
Dobrym, choć nieintuicyjnym podejściem jest też ustalenie progu bólu: „jeśli błąd synchronizacji dotyczy mniej niż X zamówień dziennie, akceptujemy ręczne poprawki, zamiast komplikować architekturę”. Nadmierne zabezpieczanie się techniczne przed scenariuszami, które zdarzają się raz na rok, bywa droższe niż ich ręczne ogarnięcie.
Integracja z WMS, kodami kreskowymi i procesami fizycznymi w magazynie
WMS jako źródło prawdy operacyjnej
W organizacjach z rozbudowanym magazynem ERP coraz częściej jest tylko „księgą główną”, a realne życie dzieje się w WMS. Jeśli integracja marketplace’ów patrzy wyłącznie na ERP, a WMS rządzi fizycznym ruchem towaru, rozjazdy są tylko kwestią skali.
Zdrowszym podejściem bywa przyjęcie, że:
WMS jest nadrzędny dla poziomu SKU–lokalizacja–rezerwacja,
ERP dostaje podsumowania operacji (przyjęcia, wydania) w trybie wsadowym lub z opóźnieniem,
integrator e-commerce komunikuje się przede wszystkim z WMS (bezpośrednio lub pośrednio), a dopiero potem z ERP.
To kłóci się z intuicją części działów finansowych („ERP musi widzieć wszystko pierwsze”), ale realnie zwiększa spójność między tym, co na półce, a tym, co na marketplace. Warunek: dobra umowa pomiędzy zespołem WMS a zespołem ERP, kto za co odpowiada i w jakim czasie.
Skany kodów kreskowych jako zdarzenia integracyjne
W wielu integracjach skaner kodów kreskowych to tylko „klawiatura na kablu”. A przecież każdy skan to precyzyjne zdarzenie: ten konkretny egzemplarz produktu przeszedł z miejsca A do B w konkretnym momencie.
Jeśli WMS rejestruje skany z odpowiednią granularnością, można na nich oprzeć znacznie dokładniejszą synchronizację:
Najczęściej zadawane pytania (FAQ)
Jak połączyć ERP z marketplace, żeby stany magazynowe się nie „rozjeżdżały”?
Kluczowe jest wybranie jednego systemu nadrzędnego dla stanów – zwykle ERP lub WMS – i podporządkowanie mu wszystkich kanałów sprzedaży. Integracja powinna wysyłać na marketplace nie „stan księgowy”, ale stan dostępny do sprzedaży: stan fizyczny pomniejszony o rezerwacje i blokady.
Sama technologia (API, integrator, cron) jest drugorzędna, jeśli procesy są źle zdefiniowane. Trzeba opisać, w którym momencie zamówienie rezerwuje towar, kto może ręcznie korygować stan i co się dzieje z tymi korektami w integracji. Bez tego nawet najdroższa integracja będzie tylko szybciej rozsyłać błędne dane.
Co zrobić, żeby w nocy nie dochodziło do oversellingu na Allegro i innych marketplace?
Największym wrogiem nocy są długie okna synchronizacji i jednorazowe zrzuty stanów. Zamiast nocnego „zrównania” lepiej wdrożyć mechanizm near real-time: aktualizacja stocku po każdym wydaniu z magazynu, stworzeniu rezerwacji czy korekcie. Jeśli to nierealne, skróć interwały cronów do kilku minut dla towarów szybko rotujących.
Drugi element to bufor bezpieczeństwa. Popularna rada „odejmij 1 sztukę od stanu” ma sens tylko przy wolno rotujących SKU i małej liczbie kanałów. Przy bestsellerach lepszy jest dynamiczny bufor: większy dla produktów z dużą sprzedażą i kilku marketplace, mniejszy dla reszty. Dzięki temu w nocy nie sprzedajesz tej samej ostatniej sztuki trzy razy.
Dlaczego stany w ERP różnią się od tego, co widzę na marketplace (Allegro, Amazon itp.)?
ERP i marketplace inaczej rozumieją pojęcie „stan magazynowy”. ERP liczy wszystko, co jest na dokumentach (PZ, WZ, MM), także towary w drodze, w buforach czy w trakcie przyjęcia. Marketplace obchodzi tylko to, co da się faktycznie wysłać klientowi – bez pozycji w rezerwacjach, reklamacji czy uszkodzeń.
Druga przyczyna to błędna logika integracji: często wysyłany jest „stan magazynowy” z ERP, który zawiera już zarezerwowane sztuki. W efekcie marketplace pokazuje ilość, której fizycznie nie jesteś w stanie sprzedać. Rozwiązaniem jest wyliczanie stanu dostępnego do sprzedaży po stronie ERP lub integratora i synchronizowanie właśnie tej wartości.
Jak poprawnie ustawić rezerwacje towaru z marketplace w ERP?
Rezerwacja powinna powstać jak najbliżej momentu złożenia zamówienia, a nie w chwili zaksięgowania płatności. Jeśli ERP rezerwuje dopiero przy statusie „opłacone”, okno ryzyka podwójnej sprzedaży otwiera się na kilkanaście–kilkadziesiąt minut, szczególnie przy sprzedaży wieczorami i w nocy.
Bezpieczniejsze podejście to wstępna rezerwacja po statusie „zamówienie utworzone” lub „oczekuje na płatność”, z automatycznym zwolnieniem po określonym czasie braku wpłaty. Popularna rada „rezerwuj tylko opłacone” zmniejsza liczbę zamrożeń towaru, ale przy szybko rotujących produktach i wielu kanałach sprzedaży generuje więcej konfliktów niż oszczędności.
Jak często synchronizować stany między ERP a marketplace’ami?
Dla asortymentu wolno rotującego wystarczające bywają interwały kilku–kilkunastu minut. Przy bestsellerach i sprzedaży wielokanałowej sensowniejsze jest podejście zdarzeniowe: wysyłanie aktualizacji po każdym kluczowym zdarzeniu (rezerwacja, wydanie, korekta) zamiast sztywnego crona.
Paradoksalnie, „aktualizacja co minutę” nie zawsze rozwiązuje problem – przy źle zaprojektowanej logice może tylko szybciej nadpisywać prawidłowe stany błędnymi. Najpierw należy jasno określić, kto jest właścicielem danych o stanach i jak wyliczany jest stan dostępny, a dopiero potem ustalać częstotliwość synchronizacji.
Jak rozróżnić stan fizyczny, księgowy, zarezerwowany i dostępny do sprzedaży w ERP?
Przydatny jest prosty słownik roboczy:
stan fizyczny – to, co realnie leży w magazynie;
stan księgowy – to, co wynika z dokumentów PZ/WZ/MM i korekt;
stan zarezerwowany – ilość przypisana do konkretnych zamówień i blokad;
stan dostępny do sprzedaży – stan fizyczny minus rezerwacje i blokady.
Dopiero na takim podziale można sensownie zaprojektować integrację. Najczęstszy błąd to używanie jednego, ogólnego pola „stan magazynowy” we wszystkich miejscach. W jednym ERP zawiera ono rezerwacje, w innym nie, a integrator traktuje je tak samo. Efekt to ciągłe „rozjazdy”, mimo że każdy system z osobna liczy poprawnie.
Czy integrator powinien móc nadpisywać stany w ERP, czy tylko je odczytywać?
Jeżeli ERP pełni rolę systemu nadrzędnego magazynu, integrator nie powinien samowolnie nadpisywać stanów – jego zadaniem jest raczej przenoszenie informacji o zamówieniach i odzwierciedlanie decyzji ERP w marketplace. Pozwalanie wielu systemom „pisać” w stanach magazynowych kończy się wojną o to, który zapis wygra w danym momencie.
Są jednak wyjątki. Gdy sprzedaż jest mocno marketplace-centryczna, a ERP ma ograniczone możliwości, dopuszcza się scenariusz, w którym integrator sumuje sprzedaż z wielu kanałów i wysyła korekty do ERP. Taki model wymaga jednak bardzo jasnych reguł priorytetów (kto ma rację przy konflikcie) oraz porządnych logów, bo diagnostyka błędów bez tego staje się koszmarem.
