Synchronizacja stanów magazynowych między kanałami — jak uniknąć rozjazdów [2026]

Synchronizacja stanów magazynowych między kanałami to najczęstsze miejsce, w którym sprzedaż wielokanałowa się rozjeżdża: sklep pokazuje 5 sztuk, Allegro sprzedaje 3, Amazon nie wie o żadnej, a klient kupuje produkt, którego fizycznie nie ma. Rozwiązanie nie polega na „szybszej synchronizacji", tylko na trzech elementach: jednym źródle prawdy, buforze bezpieczeństwa i rekoncyliacji z alertami.

KEY: Stany magazynowe powinny płynąć zdarzeniowo (webhook/kolejka w czasie zbliżonym do rzeczywistego) z jednego źródła prawdy, pomniejszone o bufor bezpieczeństwa per produkt. Sama synchronizacja nie wystarczy — potrzebna jest rekoncyliacja porównująca stany między kanałami i alert, gdy rozjazd przekroczy próg.

Dlaczego stany magazynowe się rozjeżdżają

Rozjazdy mają cztery typowe źródła, które nakładają się na siebie

Wyścig zamówień (race condition). Dwa zamówienia z różnych kanałów w tej samej sekundzie sprzedają ostatnią sztukę, bo oba widziały stan „1". Bez bufora i rezerwacji ten scenariusz jest kwestią czasu, nie pecha.

Opóźnienie synchronizacji. Stany aktualizowane harmonogramem (co 15 minut, co godzinę) zawsze mają okno, w którym kanały pokazują nieaktualne dane. Im dłuższe okno, tym więcej sprzedaży widmo.

Błędy API i sieci. Zapytanie do marketplace’u nie doszło, odpowiedź się zgubiła, limit tempa odrzucił aktualizację. Bez kolejki z ponowieniami każdy taki błąd zostawia trwały rozjazd.

Ręczne edycje. Ktoś poprawił stan bezpośrednio w panelu marketplace’u, poza integracją. System o tym nie wie i nadpisze zmianę przy najbliższej synchronizacji — albo zostawi rozjazd, jeśli edycja była w drugą stronę.

Jedno źródło prawdy — fundament, bez którego reszta nie działa

Zanim cokolwiek zsynchronizujesz, ustal, który system jest nadrzędny dla stanów magazynowych. W praktyce jest to ERP (Subiekt, Comarch, enova365, SAP) albo magazyn sklepu internetowego. Zasady są proste:

• Wszystkie kanały pobierają stany ze źródła prawdy; żaden kanał nie modyfikuje stanu bezpośrednio.
• Sprzedaż w dowolnym kanale zmniejsza stan w źródle prawdy natychmiast (zdarzeniowo), a nie przy najbliższym imporcie.
• Ręczne korekty wykonuje się wyłącznie w źródle prawdy — z dziennikiem zmian, żeby dało się prześledzić, kto i dlaczego zmienił stan.

Dwa systemy, które „wiedzą" o stanach i żaden nie jest nadrzędny, to nie problem synchronizacji — to problem architektury. Żadna synchronizacja go nie naprawi.

Bufor bezpieczeństwa — najtańsze ubezpieczenie od reklamacji

Bufor to liczba sztuk, o którą pomniejszasz stan wysyłany do kanałów zewnętrznych. Sklep ma 5 sztuk, na Allegro wystawiasz 4 — ostatnia sztuka zostaje jako zapas na wyścig zamówień i korekty.

Bufor konfiguruje się per produkt (albo per grupa), nie globalnie

• Bestsellery i produkty o wysokiej rotacji: bufor 1–2 sztuki — chroni przed sprzedażą podwójną, kosztuje niewiele.
• Produkty o niskiej rotacji: bufor 0–1 — zamrażanie sztuk na produkcie, który sprzedaje się raz na kwartał, to niepotrzebny koszt.
• Produkty jednosztukowe (unikaty): bufor 0, ale z natychmiastową rezerwacją przy zamówieniu.

Bufor nie zastępuje szybkiej synchronizacji — uzupełnia ją. Nawet przy synchronizacji zdarzeniowej zostaje okno kilku sekund, w którym dwa kanały mogą sprzedać tę samą sztukę.

Rezerwacja stanu przy zamówieniu — moment, w którym system podejmuje decyzję

Gdy zamówienie wpływa z marketplace’u, system powinien natychmiast zarezerwować towar: zmniejszyć stan w źródle prawdy i rozesłać nowy stan do pozostałych kanałów. Kolejność jest istotna — najpierw rezerwacja, potem potwierdzenie zamówienia do marketplace’u.

Rezerwacja działa też w drugą stronę: gdy zamówienie zostanie anulowane albo zwrócone, stan wraca do puli (z korektą bufora). Bez automatycznego zwrotu rezerwacji po anulowaniu zespół znowu zaczyna pracować ręcznie.

Synchronizacja zdarzeniowa a harmonogramowa — co wybrać

W praktyce najlepiej działa hybryda: stany płyną zdarzeniowo (webhook z marketplace’u i kolejka do aktualizacji kanałów), a raz na godzinę lub dzień uruchamiany jest raport uzgodnieniowy, który porównuje stany między źródłem prawdy i kanałami. Rozjazd powyżej progu generuje alert — zamiast czekać na reklamację.

Rekoncyliacja i alerty — monitoring, który zamienia reklamacje w tickety

Rekoncyliacja to systematyczne porównanie stanów: źródło prawdy vs każdy kanał. Wynik powinien trafiać do dziennika i generować alert w dwóch sytuacjach:

1. Rozjazd przekracza próg (np. różnica większa niż bufor + 1) — coś poszło nie tak w przepływie.
2. Kanał nie odpowiada albo odpowiedzi są spójnie błędne — problem z API lub limitem tempa.

Z naszych wdrożeń: dopóki rozjazdy wykrywa reklamacja klienta, średni czas wykrycia problemu to dni. Po wdrożeniu alertów — poniżej godziny. To różnica między gaszeniem pożaru a przeglądem instalacji. Więcej o warstwie niezawodności piszemy w przewodniku o odpornych integracjach API i webhookach.

Wdrożenie krok po kroku

1. Inwentaryzacja kanałów i systemów. Kto dziś „właściwie" trzyma stany, kto je modyfikuje, gdzie są ręczne obejścia.
2. Wybór źródła prawdy. ERP albo magazyn sklepu — z decyzją zapisaną w dokumentacji, nie w czyjejś głowie.
3. Projekt przepływu. Zdarzenia, kolejka z ponowieniami, bufor per produkt, rezerwacja przy zamówieniu.
4. Rekoncyliacja. Raport porównujący stany + progi alertów + osoba odpowiedzialna za reakcję.
5. Testy przypadków brzegowych. Anulowania po rezerwacji, zwroty, produkty wycofane, zamówienia zbiorcze.
6. Monitoring po wdrożeniu. Alerty, dziennik zdarzeń, okresowy przegląd rozjazdów i czasów reakcji API.

Ile to kosztuje

Synchronizacja stanów w ramach integracji przez hub: zwykle w koszcie konfiguracji huba (100–1 000 zł/mies. plus wdrożenie). Dedykowana synchronizacja z kolejkami, buforami i rekoncyliacją: 4 000–15 000 zł netto zależnie od liczby kanałów i systemów. Utrzymanie: od 400 zł netto miesięcznie. Punkt odniesienia z rynku: pojedyncza reklamacja sprzedaży towaru, którego nie było, to koszt logistyki zwrotu, obsługi i utraconego klienta — przy kilku takich zdarzeniach miesięcznie integracja zwraca się w kwartał.

Case study: rozjazdy stanów wyeliminowane w 6 tygodni

W case study integracji omnichannel opisujemy sklep na PrestaShop sprzedający na Allegro i Amazonie, w którym stany rozjeżdżały się między kanałami, a zespół weryfikował każde zamówienie ręcznie. Po wdrożeniu buforów per produkt, rezerwacji przy zamówieniu i alertów rozjazdów: sprzedaż towaru nieobecnego spadła do zera, wykrycie rozjazdu skróciło się z dni do godziny, a czas obsługi zamówienia spadł o 40%.

Jeśli chcesz uporządkować stany w swoim sklepie, zobacz usługę integracje e-commerce i API albo napisz — analizę przepływu zrobimy bezpłatnie.

Najczęściej zadawane pytania

Jak często synchronizować stany magazynowe między kanałami?

Stany powinny płynąć zdarzeniowo — każda zmiana wywołuje aktualizację pozostałych kanałów przez webhook lub kolejkę. Dodatkowo warto uruchamiać pełną rekoncyliację raz na godzinę (przy wysokiej rotacji) albo raz dziennie (przy niskiej). Sam harmonogram „co 15 minut" to minimum, nie cel — przy wysokiej rotacji okno nieaktualnych danych generuje reklamacje.

Co zrobić, gdy stany rozjeżdżają się między Allegro a sklepem?

Ustal jedno źródło prawdy dla stanów (zwykle magazyn sklepu lub ERP), wystawiaj na Allegro stan pomniejszony o bufor, rezerwuj towar natychmiast przy zamówieniu i uruchom raport uzgodnieniowy z alertem przy przekroczeniu progu. Sprawdź też, czy ktoś nie edytuje stanów bezpośrednio w panelu Allegro — ręczne edycje poza integracją to najczęstsza ukryta przyczyna rozjazdów.

Jak działa bufor bezpieczeństwa na stanach magazynowych?

Bufor to liczba sztuk, o którą pomniejszasz stan widoczny w kanale zewnętrznym. Sklep ma 5 sztuk, Allegro widzi 4 — ostatnia sztuka chroni przed podwójną sprzedażą w oknie synchronizacji. Bufor ustawia się per produkt: 1–2 sztuki dla bestsellerów, 0–1 dla wolno rotujących, 0 z rezerwacją dla unikatów.

Czy sprzedaż na dwóch kanałach wymaga synchronizacji stanów?

Tak — nawet dwa kanały (sklep plus jeden marketplace) wymagają wspólnego stanu, inaczej prędzej czy później sprzedasz tę samą sztukę dwa razy. Przy dwóch kanałach wystarczy zwykle prosty moduł lub hub; dedykowana integracja zaczyna się opłacać od 3 kanałów albo przy niestandardowej logice.

Ile kosztuje synchronizacja stanów magazynowych z marketplace’ami?

• W ramach huba: koszt konfiguracji (część wdrożenia huba, 100–1 000 zł/mies. plus setup). Dedykowana synchronizacja z kolejkami, buforami i rekoncyliacją: 4 000–15 000 zł netto, zależnie od liczby kanałów i systemów. Utrzymanie od 400 zł netto miesięcznie.

Dlaczego stany wracają do starych wartości po synchronizacji?

Najczęściej dlatego, że dwa systemy uznają się za nadrzędne — ERP nadpisuje stany sklepu, sklep nadpisuje ERP i wartości „skaczą". Drugą przyczyną jest brak dziennika zmian: bez zapisu, kto i kiedy zmodyfikował stan, nie da się ustalić, który system przywrócił starą wartość. Rozwiązanie: jedno źródło prawdy plus pełny audit log zmian stanów.

Źródła i lektury

• Case study: integracja sprzedaży omnichannel — jak rozjazdy stanów zostały wyeliminowane
• Integracja omnichannel — co to jest i jak wdrożyć — przewodnik po modelu
• Duplikaty zamówień w integracjach — idempotencja i kolejki
• Integracja z marketplace — modele integracji kanałowej
• Integracja sklepu z hurtownią i dropshipping — stany dostawcy i bufory