Skladová dostupnost v realtime: technické řešení
Zboží leží u dodavatele, ale zákazník chce vědět, kdy dorazí. Ukážeme, jak data o skladu dodavatele stahovat rychle a úsporně, jak z nich udělat pravdivou dostupnost a jak ji poslat do srovnávačů a Google.
Zákazník na stránce produktu vidí „skladem u dodavatele, doručíme ve čtvrtek“. Za touto větou je řetěz dat: stav skladu u dodavatele, jeho doba expedice, vaše pravidla a doba přepravy. Když je některý článek starý nebo špatně přeložený, věta přestane platit.
Proč se vyplatí mít sklad aktuální, jsme popsali v článku Realtime skladová synchronizace: proč na ní záleží. Jak postavit synchronizaci mezi vlastním ERP, e-shopem a marketplace pomocí webhooků a front, rozebírá článek Realtime synchronizace skladu: jak funguje pod kapotou. Tady se díváme na opačný konec: jak převzít dostupnost ze skladu dodavatele, na který nemáte přímý přístup, a jak ji pravdivě ukázat zákazníkům, srovnávačům a Google.
Tři způsoby, jak dodavatel sklad vydává
Na straně dodavatele nemáte kontrolu nad technologií. Pracujete s tím, co nabízí. V praxi potkáváme tři varianty.
| Varianta | Co obsahuje | Rozumná frekvence | Slabina |
|---|---|---|---|
| Plný XML feed | celý katalog včetně popisů a obrázků | několikrát denně | velký objem, sklad se v něm schová mezi texty |
| Skladový nebo delta feed | kód, množství, případně čas změny | jednotky až desítky minut | dodavatel ho musí nabízet |
| API | aktuální stav na dotaz, někdy i změny od času X | minuty, podle limitů | limity dotazů, autentizace, výpadky |
Nejlepší je kombinace. Katalog se stahuje z plného feedu jednou nebo několikrát denně. Sklad se bere z malého skladového feedu nebo z REST API dodavatele v krátkém intervalu. Když dodavatel nabízí webhooky při změně skladu, ještě lépe. Výhody API oproti feedu podrobně popisuje článek API napojení dodavatelů.
Delta: stahujte jen to, co se změnilo
Stahovat celý katalog každých pět minut je plýtvání na obou stranách. Dodavatel vás může zablokovat a vaše zpracování nestihne doběhnout do dalšího spuštění. Proto se snažíme přenášet jen změny.
Tři techniky, od nejlepší:
- Delta od dodavatele. API nebo feed přijme parametr s časem posledního stažení a vrátí jen změněné položky. Čas si ukládáte po každém úspěšném běhu.
- Podmíněný HTTP požadavek. Pokud dodavatelův server posílá hlavičky
ETagneboLast-Modified, pošlete při dalším staženíIf-None-MatchneboIf-Modified-Since. Když se soubor nezměnil, server podle standardu HTTP odpoví kódem 304 Not Modified bez obsahu. Nic nestahujete ani nezpracováváte. - Vlastní porovnání. Když dodavatel neumí ani jedno, stáhnete celý soubor, ale porovnáte ho s minulým stavem. Do e-shopu zapíšete jen produkty, u kterých se změnilo množství nebo dostupnost. Zátěž na straně e-shopu tak klesne na zlomek.
U každé techniky pravidelně, třeba jednou denně, udělejte plnou kontrolu. Delta umí ztratit změnu. Denní plné porovnání ji dožene. Plánování obou úloh typicky řeší cron.
Z množství u dodavatele na dostupnost pro zákazníka
Číslo „12 ks“ ve feedu dodavatele zákazníkovi nic neřekne. Potřebuje vědět, jestli zboží dostane a kdy. Proto mezi daty dodavatele a e-shopem stojí převodní pravidla.
| Stav u dodavatele | Dostupnost na e-shopu | Dodací lhůta |
|---|---|---|
| nad bezpečnostní zásobou | skladem u dodavatele | expedice dodavatele + přeprava |
| pod bezpečnostní zásobou | na dotaz, případně nedostupné | neuvádět pevné datum |
| 0, ale s termínem naskladnění | na objednávku | termín naskladnění + expedice |
| 0 bez termínu | nedostupné | žádná |
| data starší než limit | na dotaz | žádná, spustí se upozornění |
Když máte stejné zboží i na vlastním skladě, má vlastní sklad přednost. Když ho nabízí víc dodavatelů, rozhoduje pořadí podle ceny nebo rychlosti. Zákazník má vidět dostupnost toho zdroje, ze kterého objednávku opravdu vyřídíte.
Platformy na to mají vlastní mechanismy. Například Shoptet podle nápovědy k dostupnostem rozlišuje dostupnost pro zboží skladem a dostupnost při vyprodání. U dostupnosti lze zadat dobu naskladnění v hodinách, která se předává do srovnávačů. E-shop smí mít nejvýš 50 dostupností, aby automatické importy nevytvářely duplicity. Integrace proto nepřenáší textové stavy dodavatele, ale mapuje je na několik vašich pevných dostupností.
Dodací lhůta ve srovnávačích: DELIVERY_DATE a dostupnostní feed
Heureka i Zboží.cz čtou dostupnost z elementu DELIVERY_DATE. Obsahuje počet dní do expedice. Hodnota 0 znamená „skladem“. Zboží.cz podle specifikace zobrazuje hodnoty v pásmech: 1–3 dny jako dostupnost do 3 dnů, 4–7 do týdne, 8 a více za týden a déle. Místo počtu dní může být i datum ve tvaru RRRR-MM-DD pro předobjednávky. Zboží u dodavatele s expedicí do dvou dnů tedy posílejte jako 2, ne jako 0.
Heureka má navíc samostatný dostupnostní XML feed. Podle specifikace ho stahuje zhruba každých 10 minut. Obsahuje počet kusů stock_quantity a čas doručení delivery_time s povinným parametrem orderDeadline, tedy do kdy musí zákazník objednat, aby uvedený termín platil. Produkt s nulovým množstvím se do feedu nemá dávat vůbec. Tenhle feed je slib s konkrétním časem. Posílejte do něj jen zboží, u kterého termín opravdu zaručíte. U dodavatele, který expeduje „většinou druhý den“, je bezpečnější ho vynechat.
Strukturou celého feedu pro srovnávače se zabývá článek Feed pro Heureku a Zboží.cz.
Dostupnost v Google Merchant Center
Google používá atribut availability s hodnotami in_stock, out_of_stock, preorder a backorder. U hodnot preorder a backorder je povinné i datum availability_date. Dobu, než zásilku předáte přepravci, zadáváte atributy min_handling_time a max_handling_time v pracovních dnech. U zboží od dodavatele sem patří jeho doba expedice.
Google porovnává dostupnost ve feedu se stránkou produktu. Když nesedí, produkt zamítne, a jako častou příčinu uvádí časový rozdíl mezi aktualizací webu a feedu. Proto musí stránka produktu, strukturovaná data na ní a feed brát dostupnost z jednoho výpočtu, ne každý z jiného importu.
Pro časté změny skladu je lepší API než plánované stahování feedu. Content API for Shopping podle dokumentace Googlu skončilo 18. srpna 2026 a od 1. září 2026 začíná vracet chyby. Jeho nástupcem je Merchant API. To umožňuje aktualizovat jen vybraná pole produktu, například dostupnost, bez posílání celého záznamu. Pokud vaše integrace ještě používá staré API, je nejvyšší čas na přechod.
Monitoring: jak poznat, že dostupnost lže
Rychlá data jsou k ničemu, když tiše přestanou chodit. U každého dodavatele sledujeme:
- Čas posledního úspěšného stažení a upozornění, když překročí limit.
- Počet změn za běh. Náhlý pád na nulu často znamená, že dodavatel změnil formát nebo přístup.
- Podíl nedostupných produktů. Když ze dne na den zmizí polovina katalogu, zastavte zápis a ověřte data. Často jde o chybu na straně dodavatele, ne o vyprodání.
- Rozdíly mezi kanály. Stejný produkt musí mít stejnou dostupnost na webu, v Heurece i v Google.
- Storna kvůli nedostupnosti podle dodavatele. To je nejlepší měřítko, jestli nastavení funguje.
Jak na to prakticky
- Zjistěte u každého dodavatele, jestli nabízí skladový feed, deltu, API nebo webhooky.
- Oddělte stahování katalogu a skladu a sklad stahujte v kratším intervalu.
- Používejte deltu nebo podmíněné požadavky a jednou denně plnou kontrolu.
- Nastavte převodní tabulku z množství u dodavatele na vaše dostupnosti a dodací lhůty.
- Posílejte do Heureky, Zboží.cz a Google skutečný počet dní do expedice.
- Počítejte dostupnost jednou a stejnou hodnotu dávejte webu i všem feedům.
- Hlídejte stáří dat a storna podle dodavatelů.
Napojení skladu dodavatelů stavíme v rámci služby napojení dodavatelů a feedů. Jednorázová implementace začíná od 3 000 Kč za dodavatele, správa běží měsíčním paušálem. Pokud potřebujete dostupnost od dodavatelů propojit s vlastním skladem, ERP a marketplace v jednom toku, řešíme to jako automatizaci a realtime synchronizaci.
Potřebujete s tím pomoct?