Napojení e-shopu na sklad a fakturaci

Tohle je jeden z nejčastějších důvodů, proč mě firmy s e-shopem oslovují. E-shop běží, objednávky chodí, ale dál to drhne: někdo je ručně opisuje do fakturace, zakládá zásilky u dopravce a dvakrát denně přepisuje stav skladu. V sezóně je z toho patnáct minut na objednávku a desítky chyb týdně. Cílem napojení je, aby tahle ruční práce zmizela a aby data v e-shopu, skladu i účetnictví ukazovala to samé.

Proč ruční přepisování objednávek nefunguje

Ruční opisování se zdá jako levné řešení, dokud objednávek pár denně. Problém je, že náklady i chybovost rostou s objemem, a nejhůř to bouchne přesně tehdy, kdy máte nejvíc práce, tedy v sezóně nebo při akci. Konkrétně se to projevuje takhle:

• Chyby z přepisu. Překlep v adrese, špatné množství, jiná varianta produktu. Každá taková chyba znamená reklamaci, vrácenou zásilku nebo dobropis, a to už není patnáct minut, ale půl dne navíc.
• Zpoždění. Když se objednávky zpracovávají dávkově ráno a večer, zákazník čeká na potvrzení i fakturu déle, než musí. U expedice se to přenáší až k dopravci a prodlužuje dodací lhůtu.
• Neaktuální sklady. Pokud se stav zásob přepisuje ručně, web skoro nikdy nesedí. Buď prodáváte zboží, které už došlo, a pak ho sháníte a omlouváte se, nebo naopak schováváte zboží, které máte, a zbytečně přicházíte o tržby.
• Závislost na jednom člověku. Když celý proces drží jeden zaměstnanec v hlavě a v Excelu, jeho nemoc nebo dovolená zastaví expedici. To není systém, to je riziko.

Co konkrétně se propojuje

Typické zapojení vypadá jako řetězec: e-shop ↔ skladový systém ↔ fakturace a účetnictví, a vedle toho ještě dopravci. Každý článek řeší něco jiného:

• E-shop. Nejčastěji WooCommerce nebo Shoptet, oba mají použitelné API. Tady vznikají objednávky a tady se musí zobrazovat aktuální dostupnost a ceny.
• Skladový systém nebo ERP. Hlavní zdroj pravdy o zásobách a cenách. Drží se v něm reálné množství a do e-shopu se jen synchronizuje.
• Fakturace a účetnictví. Fakturoid, iDoklad, Money nebo Pohoda. Sem se propisují objednávky a vznikají z nich faktury ve správné číselné řadě, aby účetnictví sedělo a nemusel se nic dopisovat ručně.
• Dopravci a štítky. Zásilkovna, PPL, DPD, Česká pošta a další. Po expedici se založí zásilka, vygeneruje štítek a sledovací číslo se vrátí zpět k objednávce a zákazníkovi.

Co se napojuje na úrovni dat

• Sklad a ceny. Stav skladu a ceny se drží v jednom systému, typicky ve vašem ERP nebo skladu, a do e-shopu se synchronizují, aby web ukazoval reálnou dostupnost.
• Objednávky. Po zaplacení se objednávka sama propíše do fakturace, vystaví se faktura a u dopravce se založí zásilka se sledovacím číslem.
• Stavy objednávek. Změna stavu (zaplaceno, expedováno, doručeno) se synchronizuje mezi systémy, takže zákazník i obsluha vidí všude to samé.
• Produkty. Nové zboží a úpravy katalogu se dají hromadně importovat z feedu nebo CSV, místo zakládání ručně.

Jak napojení přes API vlastně funguje

API je rozhraní, přes které spolu dva systémy mluví strojově, bez člověka uprostřed. Konkrétní detaily se liší systém od systému, ale princip je pořád stejný a stojí na několika věcech:

• Autentizace. Každé volání se musí prokázat. Většinou se používá přístupový token nebo klíč, který vystaví cílový systém. Tenhle klíč ukládám bezpečně mimo kód a dávám mu jen ta práva, která integrace opravdu potřebuje.
• Synchronizace objednávek. Nová objednávka se z e-shopu přečte přes API nebo se ohlásí webhookem ve chvíli, kdy vznikne, a putuje dál do skladu a fakturace.
• Synchronizace stavů a zásob. Stav skladu a stav objednávky se aktualizují oběma směry, aby se data nikde nerozešla.
• Číselné řady. Faktury a doklady musí vznikat ve správné řadě, na kterou je navázané účetnictví. Integrace si hlídá, aby se čísla nepřeskakovala ani neduplikovala.

Obousměrná synchronizace, ne jednorázový export

Klíčové slovo je obousměrná a průběžná. Jednorázový export jednou denně problém neřeší, protože mezi exporty se data rozejdou. Dělám to tak, že synchronizace běží přírůstkově každých pár minut: posílá se jen to, co se změnilo, ne celý katalog dokola. To šetří limity API i výkon a zároveň drží data čerstvá.

Reálné scénáře z provozu

Aby to nebylo jen v teorii, takhle vypadají situace, které napojení řeší každý den:

• Automatické vystavení faktury po objednávce. Zákazník zaplatí, integrace založí fakturu ve Fakturoidu nebo Pohodě, doplní položky, sazby DPH a variabilní symbol a vrátí číslo dokladu zpět k objednávce.
• Odečet skladu. Jakmile objednávka projde, množství se odečte ve skladovém systému a nová dostupnost se synchronizuje na web.
• Sync dostupnosti. Když přijde nové zboží nebo se cena změní v ERP, web se aktualizuje sám, bez zásahu do administrace e-shopu.
• Hromadné generování štítků. Na konci dne se připravené objednávky pošlou dopravci, založí se zásilky, vygenerují se přepravní štítky a sledovací čísla se rozešlou zákazníkům.

Na co si dát pozor

Limity API

Skoro každé API má limit, kolik dotazů zvládne za minutu. Když ho překročíte, začne odpovídat chybou a synchronizace se zadrhne. Proto se synchronizuje přírůstkově a po dávkách, ne tak, že se celý katalog posílá pořád dokola.

Párování položek

Aby produkt v e-shopu odpovídal položce ve skladu a na faktuře, musí existovat společný klíč, typicky kód zboží nebo SKU. Když párování chybí nebo je nekonzistentní, faktury sedí jen někdy a sklad se odečítá u špatné položky. Tohle je nudná část, ale rozhoduje o tom, jestli celé napojení funguje.

Souběh objednávky a importu

Co se stane, když ve stejnou chvíli někdo koupí poslední kus a běží synchronizace skladu? Bez ošetření se data poperou. Řeším to zámky na úrovni databáze, aby se ke stejné položce nedostaly dva procesy najednou.

Idempotence a duplicity

Synchronizace musí snést, že se spustí dvakrát po sobě, aniž by založila duplicitní fakturu nebo zásilku. Každá operace dostane svůj identifikátor a systém si pamatuje, co už zpracoval. To je věc, na kterou laciná řešení často kašlou a pak vznikají dvojité doklady, které se musí ručně dohledávat a stornovat.

Co když API spadne

Dopravce nebo ERP občas neodpoví. Systém s tím musí počítat: zařadit úlohu do fronty a zkusit to znovu, ne tiše ztratit objednávku. Proto to stavím přes fronty a logování po krocích, aby se dalo dohledat, kde přesně se co zaseklo, a aby se nedokončená úloha sama zopakovala.

Hotový konektor, nebo řešení na míru?

Na běžné kombinace, třeba WooCommerce a známé účetnictví, existují hotové konektory a často stačí. Mají svoje výhody: jsou levné a rychle nasazené. Hodí se, když máte standardní procesy a běžné systémy. Pokud tahle cesta dává smysl, doporučím ji a nebudu vám prodávat vývoj na míru.

Jakmile ale máte vlastní nebo méně obvyklý systém, specifické číselné řady, vlastní logiku skladu nebo potřebujete kombinovat víc dopravců a skladů najednou, hotový konektor naráží. Pak píšu napojení přímo na API vašeho systému, abych měl pod kontrolou, co se kdy posílá, jak se řeší chyby a jak se to chová ve špičce. Víc o tom, jak přistupuju k softwaru na míru, a o automatizaci, která se zaplatí, najdete na samostatných stránkách. Pro náročnější propojení a vlastní rozhraní se hodí i webové aplikace.

Cíl je jednoduchý: objednávku se po zaplacení už nikdo nedotkne rukou a sklad na webu sedí. Zbytek je technika, jak se k tomu spolehlivě dostat.

Co to přinese

Hlavní efekt napojení obvykle není jen ušetřený čas, ale klid. Sklad na webu sedí, faktury vznikají samy ve správné řadě a expedice nestojí na jednom člověku. Objednávka projde celým řetězcem bez ručního zásahu a vy řešíte jen výjimky, ne každý běžný případ. Čím víc objednávek máte, tím víc se to vyplatí.

Časté otázky

Jde napojit WooCommerce na Fakturoid nebo Pohodu?

Ano. WooCommerce i Shoptet mají API a Fakturoid, iDoklad i Pohoda umí přijímat data zvenčí. Napojení znamená, že se po zaplacení objednávky sama vystaví faktura ve správné číselné řadě a propíše se zpět číslo dokladu. U Pohody se obvykle jede přes její XML rozhraní nebo mezikrok, u Fakturoidu a iDokladu přímo přes jejich REST API.

Co když pro můj systém není hotový konektor?

To je nejčastější důvod, proč mě firmy oslovují. Pokud má váš skladový nebo účetní systém API nebo umí import a export souborů, dá se napojení napsat na míru. Píšu integraci přímo na API vašeho systému, takže mám pod kontrolou, co se kdy posílá a jak se řeší chyby.

Jak probíhá synchronizace skladu?

Stav zásob se drží v jednom hlavním systému, typicky ve skladu nebo ERP, a do e-shopu se synchronizuje přírůstkově každých pár minut. Posílá se jen to, co se změnilo, ne celý katalog dokola. Po objednávce se sklad odečte a web ukazuje reálnou dostupnost, takže se neprodává zboží, které už není.

Je napojení přes API bezpečné?

Ano, pokud se dělá poctivě. Komunikace běží šifrovaně přes HTTPS, přístupové klíče se ukládají bezpečně mimo kód a každé volání má svá oprávnění. Doporučuji vystavit pro integraci samostatný účet nebo token s minimem práv, aby se případný únik dal rychle zneplatnit.

Kolik napojení e-shopu stojí?

Záleží na tom, kolik systémů se propojuje a jestli mají rozumné API. Jednoduché napojení e-shopu na fakturaci je výrazně levnější než kompletní obousměrná synchronizace skladu, cen, objednávek a dopravců. Napište mi, co používáte, a řeknu vám, jestli stačí hotový konektor, nebo se vyplatí řešení na míru, a kolik to bude.

Pojďme to propojit

Pokud váš e-shop a interní systém spolu nemluví, napište mi, co používáte. Projdu s vámi celý řetězec od objednávky po fakturu a štítek a řeknu vám, jestli stačí hotový konektor, nebo se vyplatí napojení na míru. Začít můžete na stránce weby a e-shopy, kde popisuju, jak stavím a propojuju e-shopy, nebo se podívejte na software na míru, pokud už víte, že vás čeká vlastní integrace.