Propojení e-shopu se skladem má zajistit, že zákazník vidí množství, které lze skutečně prodat, a sklad dostává objednávky bez ručního přepisování. Nejde pouze o pravidelný import jednoho čísla. Systém musí počítat s rezervacemi, nezaplacenými objednávkami, storny, vratkami, poškozenými kusy, více sklady i prodejem přes další kanály.
Největší riziko vzniká, když WooCommerce a sklad považují své množství za jedinou pravdu a navzájem se přepisují. E-shop odečte objednávku, následný import starého absolutního stavu ji vrátí zpět a stejný kus se prodá podruhé. Spolehlivé řešení proto začíná definicí skladových stavů, vlastnictví dat a přesného životního cyklu pohybu.
Co znamená „skladem“
Ve skladu může fyzicky ležet 120 kusů, ale všechny nemusejí být prodejné. Část je rezervovaná pro rozpracované objednávky, část čeká na kontrolu a firma může držet bezpečnostní rezervu. Web má zobrazovat prodejnou zásobu, nikoli prostý výsledek inventury.
Základní skladové veličiny
- Fyzická zásoba: kusy skutečně přítomné na lokaci.
- Rezervováno: množství přidělené objednávkám, ale ještě nevydané.
- Blokováno: poškozené, kontrolované nebo jinak neprodejné kusy.
- Na cestě: potvrzený příjem, který ještě není dostupný.
- Bezpečnostní rezerva: ochrana proti nepřesnosti a souběžnému prodeji.
- K prodeji: množství, které může e-shop nabídnout právě teď.
Jednoduchý výpočet může znít: fyzická zásoba minus rezervace, blokace a bezpečnostní rezerva. Ve složitějším provozu se přidává budoucí příjem, lokace nebo omezení konkrétního kanálu.
Který systém je zdrojem pravdy
Určete jednu autoritu pro fyzické množství a jednu pro rezervace. U malého e-shopu může vše řídit WooCommerce. U více skladů, prodejen nebo kanálů bývá autoritou WMS či ERP, které přijímá objednávky ze všech zdrojů a vrací prodejnou dostupnost.
WooCommerce jako skladová autorita
Hodí se pro jeden e-shop a jednoduchý sklad. WooCommerce při zapnuté správě skladu odečítá množství podle objednávek, umí držet zásobu pro čekající platby a po stanovené době ji uvolnit. Externí sklad pak dostává objednávky k vychystání a vrací hlavně potvrzení expedice či ruční korekce.
ERP nebo WMS jako autorita
Je vhodné, když stejnou zásobu využívá e-shop, prodejna, marketplace a obchodníci. Centrální systém přijímá rezervace ze všech kanálů a vypočítává prodejné množství. WooCommerce jeho stav zobrazuje a nové objednávky mu rychle předává.
Hybridní model
WooCommerce může dočasně rezervovat kus během pokladny a po vytvoření objednávky předat rezervaci skladu. Sklad ji potvrdí nebo odmítne. Tento model vyžaduje jednoznačný stav předání a pravidla, která rezervace je už započtená, aby se množství neodečetlo dvakrát.
Produkt musí mít stabilní skladovou identitu
Systémy párujte podle stabilního SKU nebo externího skladového ID, ne podle názvu. Každá samostatně skladovaná varianta potřebuje vlastní identifikátor. Rodičovský produkt může být jen skupina a fyzický sklad se vede na úrovni barvy, velikosti nebo balení.
WooCommerce umožňuje správu zásoby na úrovni celého variabilního produktu i jednotlivých variant. Zvolený model musí odpovídat realitě. Pokud mají tři barvy vlastní kusy, sdílený sklad rodiče by dovolil prodat vyprodanou barvu jen proto, že jiná zůstává.
Sady a výrobky složené z komponent
U balíčku může prodejnou kapacitu určovat nejméně dostupná komponenta. Sada obsahující dva filtry a jednu láhev je prodejná podle minima z počtu lahví a poloviny počtu filtrů. Rozhodněte, zda se komponenty rezervují už při objednávce sady a zda mohou být současně prodávané samostatně.
Absolutní stav versus skladový pohyb
Absolutní stav
Zdroj říká: SKU A má nyní 42 kusů. Implementace je jednoduchá a pravidelný úplný snímek dokáže opravit drobné rozdíly. Pokud však stav vznikl před několika minutami a mezitím e-shop prodal dva kusy, jeho slepé použití vrátí zásobu do minulosti.
Skladový pohyb
Zdroj říká: příjem +20, rezervace −2, storno +2 nebo poškození −1. Každý pohyb má jedinečné ID, čas, typ, zdroj a vazbu na objednávku. Opakovaně doručený pohyb se nezapočítá podruhé. Historie je lépe auditovatelná, ale systém musí správně zpracovat pořadí a počáteční stav.
Doporučená kombinace
Průběžné události přenášejte jako idempotentní pohyby nebo rezervace. Pravidelný absolutní snímek používejte ke kontrole a řízenému srovnání, ne jako bezpodmínečný přepis. Rozdíl nad toleranci patří k vyšetření.
Životní cyklus objednávky a zásoby
1. Košík
Položka v košíku obvykle není pevná rezervace. Dlouhé držení každého opuštěného košíku by blokovalo zásobu. U velmi omezeného zboží lze použít krátkou rezervaci, ale zákazník musí znát časový limit a systém ji musí spolehlivě uvolnit.
2. Pokladna a čekající platba
WooCommerce má nastavení Hold Stock pro objednávky čekající na platbu: po zadaném počtu minut se pending objednávka zruší a držená zásoba uvolní. Dokumentace upozorňuje, že toto nastavení se vztahuje na stav Pending payment, nikoli automaticky na On hold. Platební a skladové stavy proto nesmějí být zaměněné.
3. Potvrzená objednávka
Po úspěšné platbě nebo obchodním schválení je rezervace závazná. Objednávka se odešle skladovému systému s jedinečným ID. Sklad vrátí potvrzení, případně informaci o nedostatku.
4. Vychystání a expedice
Rezervované množství se při fyzickém výdeji změní na skladový úbytek. Prodejná zásoba se nemusí podruhé snížit, protože rezervace už ji snížila při přijetí objednávky. Mění se struktura stavu: fyzicky −2 a rezervováno −2.
5. Storno
Pokud zboží ještě nebylo vydané, rezervace se uvolní. Pokud už opustilo sklad, storno obchodního dokladu samo kus fyzicky nevrátí. Čeká se na přijetí vratky a kontrolu stavu zboží.
6. Vratka
Vrácený produkt se nejdřív přijme do kontrolní nebo blokované lokace. Do prodejné zásoby vstoupí až po potvrzení, že je znovu prodejný. Automatické zvýšení skladu při vytvoření refundace by mohlo nabídnout poškozený nebo dosud nedoručený kus.
Odolný tok synchronizace
Události, fronta a potvrzení
Objednávku neposílejte skladu pouze jedním vzdáleným požadavkem v okamžiku, kdy zákazník čeká na dokončení pokladny. Událost nejdřív spolehlivě uložte do fronty. Pracovní proces ji odešle, ověří odpověď a při dočasné chybě ji zopakuje.
Každá zpráva nese jedinečné ID operace, ID objednávky, SKU, množství, typ pohybu a verzi. Cílový systém si pamatuje zpracovaná ID. Stejná zpráva po timeoutu nesmí vytvořit druhou rezervaci.
Potvrzení není totéž jako HTTP 200
Odpověď musí obsahovat aplikační výsledek: rezervace přijata, částečně přijata, odmítnuta nebo čeká. Technicky úspěšný požadavek může obsahovat chybu produktu či množství. Integrace ukládá stav každé položky, ne jen celé objednávky.
Souběžné objednávky posledního kusu
Dva zákazníci mohou poslední kus potvrdit téměř současně. Kontrola dostupnosti na produktové stránce nestačí. Rozhodující rezervace musí proběhnout atomicky v autoritativním skladovém systému nebo databázi, která zabrání záporné prodejné zásobě.
Pokud skladové API neumí okamžitou rezervaci, e-shop potřebuje konzervativní bezpečnostní zásobu a jasný postup pro výjimky. Periodický import po patnácti minutách nemůže sám garantovat dostupnost u rychle prodávaného zboží.
Více prodejních kanálů
WooCommerce, marketplace, kamenná prodejna a obchodníci nesmějí každý prodávat celý fyzický stav. Buď používají společnou centrální rezervaci, nebo mají přidělené kanálové kvóty.
Centrální dostupnost
Každý kanál před prodejem rezervuje v jednom systému. Poskytuje nejefektivnější využití zásoby, ale vyžaduje vysokou dostupnost a rychlou integraci.
Kanálové kvóty
E-shop dostane například 20 kusů, prodejna 10 a marketplace 5. Výpadek jednoho kanálu neohrozí ostatní, ale část zásoby může zůstat nevyužitá. Kvóty je potřeba řízeně přerozdělovat.
Bezpečnostní rezerva
Jednoduchou pojistkou je odečíst několik kusů nebo procent. Není náhradou za synchronizaci, ale tlumí zpoždění a inventurní nepřesnost. Rezerva se může lišit podle obrátkovosti a spolehlivosti skladu.
Více skladů a poboček
Celková fyzická zásoba nemusí být celá dostupná online. Některý sklad neexpeduje, pobočka má kus rezervovaný pro osobní odběr a převoz trvá několik dní. Pro každou lokaci evidujte:
- fyzický, rezervovaný a blokovaný stav,
- zda smí zásobovat e-shop,
- prioritu a termín expedice,
- čas poslední aktualizace,
- povolené země nebo dopravní služby,
- minimální rezervu a provozní omezení.
Výběr skladu
Objednávku lze přidělit podle kompletnosti, vzdálenosti, nákladů nebo priority. Rozdělení do dvou zásilek může zvýšit dostupnost, ale také dopravu a ekologickou zátěž. Pravidlo má zohlednit obchodní hodnotu, ne jen první lokaci s jedním kusem.
Přesuny mezi sklady
Převod není okamžité zvýšení cílové lokace. Kus se odečte ze zdroje, eviduje „na cestě“ a na cíli se zpřístupní až po příjmu. Jinak může být prodán na obou místech.
Varianty, sady a alternativní SKU
Každá skladovaná varianta musí mít vlastní mapování. WooCommerce podporuje sklad na úrovni rodiče, varianty nebo kombinaci; integrace musí vědět, která úroveň je autoritativní.
U balení 1 kus a 6 kusů může sklad vést základní jednotku. Objednávka balení po šesti vytváří pohyb −6. Převodní koeficient je součástí mapování a nesmí se měnit bez kontroly rozpracovaných objednávek.
Pokud se produkt prodává pod více SKU, ale sdílí stejný fyzický kus, vytvořte vazbu na společnou skladovou položku. Prosté synchronizování stejného absolutního čísla do obou SKU dovolí každému kanálu prodat celý stav.
Backorder a předobjednávka
Záporná zásoba může být záměrná jen tehdy, když firma umí dodat a zákazník zná termín. WooCommerce dovoluje u produktu či varianty povolit backorders. Integrace ale musí rozlišit:
- skutečně skladem,
- lze objednat s delší dodací dobou,
- předobjednávka na konkrétní příjem,
- nedostupné bez známého termínu.
Nepřevádějte všechny kladné stavy dodavatele na „skladem“. Dostupnost u dodavatele je jiná služba než vlastní fyzická zásoba a má jinou dodací dobu i riziko.
Výpadek propojení
Integrace musí vědět, jak stará jsou poslední ověřená data. Stav 10 kusů bez času aktualizace je nebezpečný. Pro každý sklad a produktovou skupinu nastavte maximální stáří a režim po jeho překročení.
Možné bezpečné režimy
- pokračovat s bezpečnostní rezervou u stabilního sortimentu,
- omezit maximální množství v objednávce,
- přepnout na „dostupnost ověříme“,
- zakázat prodej rychloobrátkových nebo drahých položek,
- ponechat jen předobjednávku,
- zastavit celý kanál při nefunkčním potvrzování rezervací.
Volba závisí na ceně ztracené objednávky proti ceně přeprodeje. U běžně dostupného spotřebního zboží lze být odvážnější než u jedinečného kusu.
Co se stane s objednávkou při výpadku skladu
Objednávku lze přijmout do stavu „čeká na potvrzení skladu“. Zákazníkovi neslibujte expedici, dokud systém nemá potvrzení. Po obnovení se fronta zpracuje ve správném pořadí. Pokud zásoba nestačí, proces nabídne částečné plnění, náhradu, nový termín nebo storno.
Neodesílejte potvrzení „zboží máme rezervované“ pouze na základě úspěšné platby, pokud rezervaci provádí nedostupný externí systém.
Storno, refundace a vrácení zásoby
Obchodní storno musí vytvořit opačný skladový pohyb jen tehdy, pokud byl původní pohyb skutečně proveden. U každé položky uchovávejte množství, které bylo rezervováno a fyzicky vydáno. Opačná operace odkazuje na původní ID.
WooCommerce skladové funkce evidují, zda byl sklad pro položku snížen, a při obnově mají ochranu proti opakovanému vrácení. Vlastní integrace musí zachovat stejný princip napříč systémy. Dvojí kliknutí na storno nesmí zvýšit sklad dvakrát.
Inventura a korekce rozdílů
Žádný digitální sklad nezaručí fyzickou správnost bez inventury. Krádeže, poškození, záměny SKU a chybné příjmy vytvářejí rozdíly. Inventurní korekce je samostatný pohyb s důvodem a odpovědnou osobou.
Pravidelná kontrola porovná:
- fyzicky zjištěný stav,
- účetní nebo WMS stav,
- rezervace otevřených objednávek,
- prodejnou zásobu publikovanou e-shopem,
- nepotvrzené pohyby v integrační frontě.
Automatické srovnání velkého rozdílu nespouštějte bez revize. Nejdřív zjistěte, zda chybí událost, nebo je fyzický stav skutečně jiný.
API, webhooky a pravidelná kontrola
Rychlé změny přenášejte událostmi nebo API. WooCommerce webhooky mohou oznamovat změny objednávek a produktů. Příjemce ověřuje podpis, událost uloží a zpracuje na pozadí.
Pravidelný úplný snímek slouží jako pojistka. Najde ztracenou událost nebo ruční zásah mimo integrační cestu. Nesrovnalosti se reportují a opravují podle autority dat.
Nepoužívejte veřejné interní endpointy bez ochrany
Skladová API pracují s obchodně citlivými údaji. Používejte HTTPS, samostatné technické účty, nejmenší oprávnění a rotaci klíčů. Webhooky mají podpis a ochranu proti opakování. Přístupové údaje nepatří do veřejného repozitáře ani do logu.
Monitoring a administrace
Provozní tým musí vidět stav bez čtení serverových logů. Administrace má ukázat:
- čas poslední aktualizace každého skladu,
- čekající, potvrzené a chybné pohyby,
- objednávky bez potvrzené rezervace,
- SKU bez mapování,
- rozdíly mezi e-shopem a autoritativním skladem,
- produkty v omezeném režimu kvůli starým datům,
- počet opakování a poslední chybu,
- historii ručních zásahů a korekcí.
Alarmy podle závažnosti
Jedno neznámé SKU patří do pracovní fronty. Nefunkční autentizace všech rezervací vyžaduje okamžité upozornění a omezení prodeje. Nastavte prahy pro stáří dat, délku fronty, podíl chyb a neobvyklé změny zásoby.
Výkon a frekvence synchronizace
Frekvenci řiďte rychlostí prodeje a hodnotou zásoby. Drahý unikátní kus potřebuje okamžitou rezervaci, stabilní zásoba stovek levných položek snese krátký interval. Nemusíte aktualizovat celý katalog při každém pohybu.
Posílejte změněná SKU, dávkujte aktualizace a vyhněte se zbytečnému ukládání stejných hodnot. Každý zápis ve WooCommerce může spustit cache, feedy, vyhledávací index nebo webhooky.
Testovací scénáře
- objednávka běžného produktu a potvrzení rezervace,
- dvě souběžné objednávky posledního kusu,
- nezaplacená objednávka a vypršení držení skladu,
- storno před a po fyzickém výdeji,
- částečné storno jedné položky,
- vratka přijatá nejdřív do kontroly,
- varianta se samostatným skladem,
- sada sdílející komponenty s jinými produkty,
- objednávka rozdělená mezi dvě lokace,
- přesun mezi sklady,
- opakovaně doručený stejný pohyb,
- události doručené v obráceném pořadí,
- timeout po vytvoření rezervace,
- výpadek skladu delší než limit stáří,
- inventurní korekce a následné srovnání,
- ruční změna zásoby mimo integrační cestu.
Postup zavedení krok za krokem
1. Zmapujte současný tok
Určete, kdy se zásoba odečítá, kde vznikají rezervace, kdo provádí storno a které kanály používají stejné kusy.
2. Definujte skladové stavy
Sepište fyzickou, rezervovanou, blokovanou a prodejnou zásobu. U každého stavu určete autoritu a okamžik změny.
3. Sjednoťte identifikátory
Vyčistěte SKU a vytvořte mapu produktů, variant, sad a lokací. Konfliktní položky vyřešte před automatizací.
4. Zaveďte frontu a idempotenci
Každý pohyb dostane ID a dohledatelný stav. Opakovaný požadavek nesmí změnu započítat podruhé.
5. Spusťte jednosměrný pilot
Začněte jedním skladem nebo kategorií. Nejdřív přenášejte objednávky a porovnávejte potvrzené stavy bez automatického přepisování celého katalogu.
6. Přidejte rychlou dostupnost a fallback
Po ověření rezervací publikujte prodejnou zásobu a nastavte režimy při výpadku.
7. Zapněte pravidelné srovnání
Úplný snímek kontroluje rozdíly a upozorňuje na ruční nebo ztracené pohyby.
Kontrolní seznam před ostrým provozem
- Je jasně určený zdroj pravdy pro fyzickou zásobu a rezervace.
- Každá varianta a skladová položka mají stabilní ID.
- Prodejná zásoba má jednoznačný výpočet.
- Objednávka se rezervuje atomicky a jen jednou.
- Pohyby mají jedinečné ID a lze je bezpečně opakovat.
- Storno vrací jen skutečně rezervované nebo vydané množství.
- Vratka nejde do prodeje před kontrolou.
- Více kanálů používá centrální rezervaci nebo kvóty.
- Každý sklad má čas poslední aktualizace a fallback.
- Fronta a rozdíly jsou viditelné v administraci.
- Monitoring upozorní na stará data i nefunkční rezervace.
- Pravidelné srovnání nenahrazuje historii pohybů.
Jedna pravda o zásobě vyžaduje jasná pravidla
Dobré propojení skladu nepřepisuje čísla naslepo. Přenáší objednávky, rezervace a pohyby s identitou, potvrzením a možností bezpečného opakování. E-shop pak nabízí jen množství, které dokáže firma splnit, a při výpadku přejde do předem připraveného režimu.
Pokud chcete propojit WooCommerce s ERP, WMS, prodejnami nebo dalšími kanály, popište nám svůj skladový proces. Navrhneme datový model, integrační frontu a kontrolu rozdílů podle skutečného toku zboží, objednávek a vratek.