---
title: "Dlaczego ERP i sklep różnią się stanami magazynowymi"
description: "Błąd synchronizacji, który w końcu dotyka każdy sklep: dwa systemy przekonane, że są właścicielem stanu, i wzorce, które eliminują tę niespójność."
author: "Luboš Zápotočný"
published: "2026-06-11"
language: "pl"
canonical: "https://zapolu.com/pl/blog/dlaczego-erp-i-sklep-roznia-sie-stanami/"
---

# Dlaczego ERP i sklep różnią się stanami magazynowymi

Prędzej czy później każdy sklep z ERP-em dostaje ten sam ticket:
storefront pokazuje pięć sztuk, magazyn zero, a klient właśnie
zapłacił za coś, czego nie ma. Support nazywa to usterką, ale ślad
prowadzi do decyzji architektonicznej, której podjęcia nikt nie
pamięta.

## Przyczyną jest własność, nie skrypt synchronizacji

Kiedy liczby przestają się zgadzać, uwaga kieruje się na skrypt
synchronizacji. Ale skrypt zwykle wykonuje dokładnie to, co
zaprojektowano;
problem w tym, że dwa systemy naraz uważają, że to one są
właścicielem stanu. ERP zdejmuje sztuki, gdy księguje zamówienie.
Sklep zdejmuje, gdy kończy się checkout. Każdy ma rację według
własnych zasad, a synchronizacja nie ma reguły rozstrzygania
konfliktów.

Rozwiązanie to jedna zasada: **jedno źródło prawdy na jeden fakt.**
Prawda o stanie jest przechowywana w dokładnie jednym miejscu,
niemal zawsze w ERP albo WMS, bo tam księguje się stany i tam
odbywa się fizyczny ruch towarów. Sklep
trzyma kopię do wyświetlania i *rezerwację*. Gdy powie się to
wprost, każde pytanie o synchronizację ma odpowiedź: w razie
wątpliwości wygrywa źródło prawdy.

## Błędy, które powtarzają się najczęściej

Gdy własność jest ustalona, pozostałe błędy są mechaniczne
i powtarzają się niezależnie od platformy i ERP-a:

- **Zgubione aktualizacje.** ERP wypycha zmianę stanu, sklep jest
  akurat w trakcie deployu albo odrzuca wywołanie z powodu rate
  limitu i nikt go nie ponawia. Tygodnie później ktoś pyta, dlaczego
  jedno SKU jest
  „niedostępne” od miesiąca.
- **Podwójne dostarczenia.** Ten sam webhook przychodzi dwa razy
  (dostarczanie jest zwykle at-least-once, więc
  [to samo zdarzenie może przyjść więcej niż raz](/pl/blog/webhooki-sie-powtarzaja/)),
  a handler zdejmuje stan dwukrotnie.
- **Pełne synchronizacje ścigające się z deltami.** Nocny pełny
  import i aktualizacje zdarzeniowe piszą po tych samych wierszach;
  wygrywa proces, który zakończy się ostatni, a bywa, że to ten
  z nieaktualnymi danymi.
- **Dryf mapowania.** SKU przemianowane w ERP staje się w sklepie
  nowym produktem bez żadnego sygnału; stare zachowuje nieaktualny
  stan bezterminowo.
- **Zestawy i komplety.** Sklep sprzedaje zestaw; ERP liczy
  składniki. Jeśli przeliczenie jest utrzymywane w arkuszu
  kalkulacyjnym, zwykle jest nieaktualne.

## Wzorce, które eliminują niespójność

Warstwa integracji, która przestaje generować takie tickety,
wygląda tak samo bez względu na to, jaki ERP za nią stoi:

1. **Delty plus rekoncyliacja.** Aktualizacje zdarzeniowe dla
   szybkości i okresowe pełne porównanie, które znajduje to, co
   zdarzeniom umknęło. Rekoncyliacja to siatka bezpieczeństwa,
   dzięki której szybkiej ścieżce można ufać.
2. **Idempotentni konsumenci.** Każda aktualizacja niesie
   identyfikator, po którym konsument deduplikuje, więc przetworzenie
   jej dwa razy nic nie zmienia. To
   eliminuje problem ponowień i replayów. Konflikty współbieżności
   to osobny problem: zgubione aktualizacje i pełne synchronizacje
   ścigające się z deltami wymagają numerów wersji albo sekwencji,
   żeby nieaktualny zapis nie nadpisał nowszego.
3. **Correlation ID od końca do końca.** Kiedy zamówienie 18342 nie
   dotarło do magazynu, ustalenie, gdzie utknęło, powinno wymagać
   jednego zapytania do logów, a nie kilku godzin analizy.
4. **Alarmuj już przy rozjeździe.**
   Synchronizacja, która raportuje sukces, podczas gdy liczby się
   rozchodzą, jest gorsza od takiej, która kończy się jawnym błędem.
   Porównuj agregaty według harmonogramu i uruchamiaj alert, gdy
   delta rośnie.
5. **Rezerwacje z terminem ważności.** Jeśli Twoja konfiguracja
   rezerwuje stan wcześnie, koszyk trzyma go przez minuty, a
   nieopłacone zamówienie dłużej; domyślnie jednak rezerwacja
   powstaje przy złożeniu zamówienia, a nie przy dodaniu do koszyka.
   Tak czy inaczej wszystko wygasa z powrotem do źródła prawdy. Oversell podczas kampanii prawie
   zawsze prowadzi do rezerwacji, które nigdy nie wygasły albo nigdy
   nie istniały.

Nic z tego nie zależy od dostawcy. Tę samą architekturę
budowaliśmy dla
Business Central, Comarch ERP i Subiekta, ale też dla NetSuite, Odoo
czy Pohody i Money S5. Ten długi ogon systemów, które
międzynarodowi dostawcy gotowych konektorów zwykle ignorują, to
połowa powodu, dla którego istnieją
[nasze integracje](/pl/services/integrations/).

Jeśli Twój sklep i Twój ERP wykazują dziś taką niespójność, zacznij
od postawienia pytania o własność wprost. A jeśli chcesz pomocy,
[wystarczy jedna rozmowa](/pl/contact/). Decyzja, gdzie
leży każdy fakt, to
[projektowanie systemów](/pl/services/system-design/); reszta to już
rzetelna inżynieria.