---
title: "Proč se ERP a e-shop neshodnou na skladě"
description: "Chyba synchronizace, na kterou narazí každý e-shop: dva systémy přesvědčené, že sklad patří jim, a integrační vzory, které ten spor ukončí."
author: "Luboš Zápotočný"
published: "2026-06-11"
language: "cs"
canonical: "https://zapolu.com/cs/blog/proc-se-erp-a-eshop-neshodnou-na-sklade/"
---

# Proč se ERP a e-shop neshodnou na skladě

Dřív nebo později narazí každý e-shop s ERP na stejný ticket:
storefront hlásí pět kusů skladem, sklad hlásí nulu a zákazník právě
zaplatil za něco, co neexistuje. Podpora tomu říká výpadek, jenže
stopa vede k architektonickému rozhodnutí, o kterém si nikdo
nepamatuje, že ho udělal.

## Kořen je ve vlastnictví, ne v synchronizaci

Když se čísla rozejdou, všichni ladí synchronizační skript. Skript
ale většinou dělá přesně to, co dostal za úkol; problém je, že dva
systémy jsou oba přesvědčené, že skladové číslo vlastní. ERP odečítá
při zaknihování objednávky. E-shop odečítá při dokončení pokladny.
Podle vlastních pravidel mají pravdu oba a synchronizace mezi nimi
rozhoduje bez jasného pravidla.

Oprava je jeden princip: **jeden zdroj pravdy na jeden fakt.**
Pravda o skladu žije právě na jednom místě, téměř vždy
v ERP nebo ve WMS, protože tam se sklad zaknihuje a zboží se
fyzicky hýbe. E-shop drží
kopii v cache pro zobrazení a *rezervaci*. Jakmile je
tohle explicitní, má každá otázka synchronizace odpověď:
v pochybnostech vyhrává zdroj pravdy.

## Poruchy, které nacházíme pořád dokola

S vyřešeným vlastnictvím jsou zbylé chyby mechanické a opakují se
napříč platformami i ERP:

- **Ztracené aktualizace.** ERP pošle změnu skladu, e-shop je zrovna
  uprostřed deploye nebo volání odmítne kvůli rate limitu, a nikdo
  to nezopakuje. Za pár týdnů se někdo ptá, proč je jedno SKU celý
  měsíc „vyprodané“.
- **Duplicitní doručení.** Tentýž webhook dorazí dvakrát (doručení
  webhooků je typicky at-least-once, takže
  [tatáž událost může dorazit víckrát](/cs/blog/webhooky-se-opakuji/))
  a handler odečte sklad dvakrát.
- **Plné synchronizace v závodě s deltami.** Noční plný import
  a událostmi řízené aktualizace běží nad stejnými řádky; vyhrává,
  kdo skončí poslední, a občas je to ten zastaralý.
- **Rozjeté mapování.** SKU přejmenované v ERP se v e-shopu tiše
  stane novým produktem; to staré si nechá zastaralý počet navždy.
- **Sety a bundly.** E-shop prodává sadu; ERP počítá komponenty.
  Pokud převod žije v excelu, počítejte s tím, že je neaktuální.

## Vzory, které spor ukončí

Integrační vrstva, která tyhle tickety přestane produkovat, vypadá
stejně bez ohledu na to, jaké ERP za ní stojí:

1. **Delty plus rekonciliace.** Událostmi řízené aktualizace pro
   rychlost a pravidelné plné porovnání, které najde, co událostem
   uteklo. Rekonciliace je pojistka, díky které se dá rychlé cestě
   věřit.
2. **Idempotentní konzumenti.** Každá aktualizace nese identifikátor,
   na kterém konzument deduplikuje, takže zpracovat ji dvakrát nic
   nezmění. Tahle jediná vlastnost pohltí
   opakovaná doručení i replaye. Souběžné konflikty jsou samostatný
   problém: ztracené aktualizace a plné synchronizace v závodě
   s deltami potřebují čísla verzí nebo pořadová čísla, aby zastaralý
   zápis nemohl přepsat novější.
3. **Correlation ID od začátku do konce.** Když objednávka 18342
   nedorazila do skladu, má být „kam se poděla“ minutový dotaz do
   logů, ne celé odpoledne.
4. **Alert na rozjezd čísel, ne jen na selhání.** Synchronizace,
   která svítí zeleně, zatímco se čísla rozcházejí, je horší než ta,
   která spadne. Porovnávejte agregáty podle plánu a vzbuďte někoho,
   když delta roste.
5. **Rezervace s expirací.** Pokud u vás rezervace vzniká brzy, drží
   košík zboží minuty a nezaplacená objednávka déle; ve výchozím
   nastavení ale rezervace vzniká až při založení objednávky, ne při
   vložení do košíku. Tak či tak všechno expiruje zpět do zdroje
   pravdy.
   Přeprodání během kampaní má většinou kořeny v rezervacích, které
   nikdy neexpirují nebo nikdy nevznikly.

Nic z toho nezávisí na dodavateli. Stejný tvar jsme stavěli proti
NetSuite, Business Central, Odoo i českým a slovenským systémům jako
Pohoda a Money S5, se kterými mezinárodní výrobci konektorů
většinou nepočítají. Právě kvůli téhle dlouhé řadě menších lokálních systémů
z poloviny existuje
[naše práce na integracích](/cs/services/integrations/).

Pokud se u vás skladová čísla mezi e-shopem a ERP právě rozcházejí,
začněte tím, že otázku vlastnictví uděláte explicitní, a pokud
chcete pomoct,
[stačí se ozvat](/cs/contact/). Rozhodnout, kde který fakt sídlí, je
[návrh systému](/cs/services/system-design/); zbytek je běžná
inženýrská práce.