Propojení ERP, e-shopu a skladu — jeden zdroj pravdy

Zákazník si objedná poslední kus. Ve stejnou minutu ho skladník prodá na prodejně a ERP po nočním importu přepíše stav v e-shopu na tři kusy, protože vychází ze včerejší inventury. Ráno máte dvě objednávky na zboží, které neexistuje. Tohle není chyba jednoho systému. Je to chyba v tom, jak jsou systémy propojené.

Rostoucí e-shop má data aspoň na třech místech: v platformě, v ERP nebo účetnictví a ve skladu, ať už je to modul ERP, WMS, nebo fulfillment. Aby spolu fungovaly, potřebují jedno pravidlo: každý údaj má právě jeden zdroj pravdy. Ukážeme, jak ho určit a jak na něm postavit synchronizaci.

Co je zdroj pravdy a proč na něm záleží

Zdroj pravdy (anglicky single source of truth) je systém, který smí daný údaj měnit. Ostatní systémy ho přebírají a samy ho nepřepisují. Neznamená to, že všechno musí být v jednom systému. Znamená to, že u každého údaje víte, kde platí.

Když zdroj pravdy chybí, vznikají typické problémy:

• Stav skladu se liší mezi e-shopem a ERP a nikdo neví, které číslo je správné.
• Cena upravená v e-shopu se při další synchronizaci přepíše cenou z ERP.
• Objednávka stornovaná v ERP v e-shopu dál visí jako „vyřizuje se".
• Inventura v ERP „opraví" sklad, ale mezitím prodané kusy se ztratí.

Kdo vede který údaj

Rozdělení se liší podle firmy, ale tahle tabulka odpovídá většině e-shopů s ERP a vlastním skladem:

Tabulku doporučujeme sepsat a nechat ji podepsat všemi, kdo do systémů zasahují: majitelem, účetní, skladem i správcem e-shopu. Většina „záhadných" rozdílů v datech je ve skutečnosti ruční zásah do údaje, který měl vést jiný systém.

Pohyby, ne stavy

Nejčastější technická chyba je synchronizovat absolutní stav: ERP každou hodinu pošle „produkt X má 5 kusů" a e-shop číslo přepíše. Mezi odečtením stavu v ERP a zápisem do e-shopu ale mohly proběhnout objednávky. Výsledek: prodané kusy se vrátí do dostupnosti.

Bezpečnější je pracovat s pohyby: „prodáno 1 ks", „naskladněno 20 ks". Například API Shoptetu podle dokumentace (k 9/2026) umožňuje u skladu nastavit absolutní množství i relativní změnu (amountChange) a vede seznam skladových pohybů s časem změny. Absolutní stav má smysl hlavně po inventuře, a to ve chvíli, kdy víte, že mezitím nevznikly objednávky.

K pohybům patří rezervace. Objednávka, která ještě neopustila sklad, by měla zboží blokovat. Shoptet to řeší skladovými nároky: vybrané stavy objednávky vznášejí nárok na sklad, a když zboží odejde, nárok zaniká a kusy se odečtou. Pokud stejnou logiku nemá i ERP, musí integrace rezervace hlídat sama, jinak ERP nabízí zboží, které už je slíbené.

Rychlost: webhooky a fronty

Druhá otázka je, jak rychle se změna propíše. Plánované dávky přes REST API každých pár minut stačí pro ceny a katalog. Pro sklad a objednávky se vyplatí reagovat na události.

• [Webhooky](/kb/integrace/webhooky) oznámí změnu hned. Shoptet má například webhook stock:movement, který ale posílá jen identifikátor skladu, kde se pohyb stal. Konkrétní pohyby si integrace dotáhne přes API.
• [Fronta zpráv](/kb/automatizace/message-queues) mezi příjmem a zpracováním zajistí, že výpadek ERP nezastaví e-shop. Zpráva počká a zpracuje se později.
• Asynchronní zápis do ERP je běžný. Money S3 přes modul API zapisuje data do fronty importu, takže integrace musí výsledek dohledat a chyby řešit (víc v hesle Money S3). ABRA Flexi kombinuje webhooky s Changes API, kterým se dají dohledat změny od posledního známého bodu (viz ABRA Flexi).

Pro všechny cesty platí: zpráva může přijít dvakrát nebo v jiném pořadí. Zpracování musí být idempotentní. Druhé doručení stejné objednávky nesmí vytvořit druhou fakturu ani dvakrát odečíst sklad.

Přímé napojení, nebo middleware

Middleware nic nevyřeší, pokud nemá jasná pravidla. Když se neví, kdo vede sklad, jen přesune chaos na jiné místo. Proto vždy začínáme tabulkou zdrojů pravdy, ne výběrem nástroje. Kdy a jak se ERP obecně napojuje, rozebíráme v článku Napojení e-shopu na ERP: kdy a jak.

Dorovnání: pojistka, na kterou se zapomíná

Ani nejlepší synchronizace není stoprocentní. Webhook se nedoručí, API vrátí chybu, někdo ručně upraví kartu. Proto patří ke každé integraci pravidelné dorovnání (reconciliation):

1. Jednou denně (typicky v noci) porovnejte stavy skladu mezi zdrojem pravdy a ostatními systémy.
2. Rozdíly nezapisujte automaticky. Nejdřív zjistěte, jestli nejde o rozpracovanou objednávku nebo rezervaci.
3. Vysvětlitelné rozdíly opravte ve směru od zdroje pravdy, nevysvětlitelné pošlete člověku.
4. Sledujte trend. Když rozdílů přibývá, někde v toku je chyba.

Stejně tak porovnávejte objednávky: každá objednávka z e-shopu musí mít doklad v ERP. Chybějící doklad objevený druhý den je drobnost. Objevený při uzávěrce měsíce je problém pro účetní.

Checklist propojení

• Tabulka zdrojů pravdy je sepsaná a odsouhlasená.
• Každý produkt má jednoznačný kód shodný ve všech systémech.
• Sklad se synchronizuje pohyby, absolutní stav jen po inventuře.
• Rezervace z nevyřízených objednávek se promítají do dostupnosti.
• Příjem událostí je idempotentní a má frontu nebo opakování.
• Chyby zápisu končí v alertu, ne jen v logu.
• Běží denní dorovnání skladu a objednávek.
• Existuje dokumentace toků, aby řešení nestálo na jednom člověku.

Jak vám pomůžeme

Začínáme analýzou: jaké systémy máte, kdo do nich zapisuje a kde vznikají rozdíly. Z toho vznikne tabulka zdrojů pravdy a návrh toků. Pak postavíme nebo opravíme integraci, ať už jde o Pohodu, Money, ABRA nebo jiný systém, a doplníme monitoring a dorovnání v rámci služby Integrace systémů.

Základní synchronizace objednávek a skladu u nás obvykle trvá 2–4 týdny. Pokud řešíte i samotný provoz skladu, pokračujte článkem Skladové hospodářství a WMS pro rostoucí e-shop.