Integrace e-shopu s Pohodou, Money S3 nebo Heliosem: Praktický průvodce

Každou noc se někde opakuje stejná scéna: účetní otevírá e-shop, čte objednávky a přepisuje je do účetního systému. Pět minut na objednávku, třicet objednávek denně — to jsou dvě a půl hodiny čisté administrativy, která nepřidává žádnou hodnotu. A to ještě nepočítáme chyby z únavy, nesoulad skladových stavů ani faktury odeslané s opožděním o dva dny.

Problém není lidský — je systémový. E-shop a účetní software jsou dvě oddělené aplikace, které se navzájem nevidí. Dokud mezi nimi nestojí integrace, data se musí přenášet ručně. A ruční přenos dat je spolehlivě nejdražší způsob, jak řešit něco, co umí stroj. V našem obecném průvodci integrací e-shopu s ERP a účetnictvím jsme se podívali na základní přístupy. Tento článek jde o krok hlouběji: konkrétně tři systémy — Pohoda, Money S3 a Helios — a co od každého z nich můžete realisticky čekat.

Každý z těchto systémů má jiné integrační možnosti, jinou zralost API a jiná typická úzká místa. Správná volba závisí na tom, který systém už používáte — nebo který se chystáte nasadit.

Jak integrace funguje na technické úrovni

Předtím, než se pustíme do konkrétních systémů, je užitečné pochopit, jak integrace mezi e-shopem a účetním softwarem technicky funguje. Existují v zásadě tři přístupy, přičemž moderní projekty je kombinují.

XML a CSV import/exportje nejstarší a stále nejrozšířenější způsob. E-shop vygeneruje soubor s objednávkami v dohodnutém formátu a účetní systém ho importuje. Výhoda: funguje bez síťového propojení. Nevýhoda: není to real-time — typická latence je 15 minut až hodina. Kritická otázka je idempotentnost: pokud se stejný soubor importuje dvakrát (např. při chybě sítě), systém nesmí vytvořit duplikátní záznamy. Většina profesionálních implementací řeší idempotentnost přes externí identifikátor objednávky.

REST API je modernější přístup, kde e-shop i účetní systém komunikují přímo přes HTTP volání. Objednávka vznikne na e-shopu, konektor ji okamžitě odešle do účetního systému a dostane zpět potvrzení s interním číslem záznamu. Latence se měří v sekundách. Klíčové dizajnové rozhodnutí je párování záznamů: každá objednávka musí být jednoznačně identifikovatelná v obou systémech.

Middleware layer — například n8n nebo Make — sedí mezi e-shopem a účetním systémem a orchestruje tok dat. Výhoda: jeden middleware může obsluhovat více systémů najednou, centralizovat error handling a umožnit vizuální ladění toků bez nutnosti zasahovat do kódu. Nevýhoda při vysokém objemu: každé HTTP volání přes middleware přidá latenci. Pro tyto případy jsou vhodnější přímá automatizace procesů řešení psaná na míru.

Pohoda: silné a slabé stránky integrace

Pohoda od Stormware je v Česku (a na Slovensku) de facto standard pro malé a střední firmy. Její rozšířenost znamená, že integrační knowledgebase je bohatá — existuje množství hotových řešení, agentů a komunity. To je výhoda při startu projektu.

XML rozhraní a mServer

Pohoda nabízí dvě hlavní integrační rozhraní. První je souborový XML import/export: e-shop generuje XML soubory s objednávkami (případně i se zákazníky a skladovými pohyby) a Pohoda je importuje přes dávkový mechanismus. Struktura XML je dobře zdokumentovaná v technické příručce Stormware a většina populárních e-shopových platforem (Shoptet, WooCommerce, PrestaShop) má pluginy nebo exportní moduly.

Druhé rozhraní je mServer — HTTP server zabudovaný přímo do Pohody, který umožňuje real-time volání přes REST rozhraní. mServer je výrazně flexibilnější než dávkový import: můžete ověřovat dostupnost zboží, vytvářet objednávky a faktury v reálném čase a číst stavy existujících záznamů. Pro většinu integračních projektů nad 50 objednávek denně doporučujeme začít právě s mServerem.

Limity, které je třeba znát

Pohoda má několik omezení, se kterými je třeba při integraci počítat. Desktopová verze (instalovaná na Windows PC) dovoluje při XML importu otevřít databázi jen jedním procesem současně — než probíhá import, jiný uživatel nemůže zapisovat. To může být problém v multi-user prostředí. mServer toto omezení zmírňuje, ale stále běží na jednom stroji a výkon závisí na jeho hardwaru. Pro velmi vysoké objemy (stovky transakcí za hodinu) je vhodnější uvažovat o Pohoda SQL verzi. mServer je volitelný modul — má vlastní licenční poplatek, který je třeba zahrnout do celkových nákladů projektu.

Money S3: silné a slabé stránky integrace

Money S3 vyvíjí společnost Seyfor (do roku 2022 Cígler Software). Je to dlouhodobě oblíbený systém s velkou základnou uživatelů v ČR a SR, zejména v malých firmách a živnostech. Seyfor v posledních letech agresivně investoval do cloudové verze a modernizace API, což integraci prospělo.

XML a API rozhraní

Money S3 podporuje import a export dat přes XML soubory s vlastním schématem. Podobně jako Pohoda, tento kanál je vhodný pro dávkové zpracování. Pro real-time integraci existuje REST API, které je dostupné zejména v cloudové a SQL variantě. Desktopová verze má API funkcionalitu omezenější, ale většina integračních projektů dnes směřuje zákazníky k SQL nebo cloudové licenci právě pro lepší API přístup.

Cloud vs. desktop a multi-user chování

Cloudová verze Money S3 (případně přechod na Money S5, novější generaci produktu) odstraňuje problém single-user XML zámku, který je omezením desktopových instalací. V cloudu může API zapisovat souběžně s tím, jak účetní pracuje v rozhraní. Pro nové integrační projekty dnes většina partnerů doporučuje právě cloudovou nebo SQL verzi.

Money S5 konektor nebo middleware

Pro firmy přecházející z Money S3 na novější generaci Money S5 je API výrazně modernější a integrace jednodušší. Money S5 má REST API s OAuth2 autentifikací a Swagger dokumentací. Pro zůstávající na Money S3 je zaužívaný přístup přes middleware (n8n, Make) s XML konektorem.

Helios: silné a slabé stránky integrace

Helios od Asseco Solutions je silný hráč ve středním a vyšším segmentu trhu. Zatímco Pohoda a Money S3 dominují u malých firem, Helios se výrazněji prosazuje tam, kde je potřeba pokrýt komplexnější procesy: více poboček, multi-currency operace, rozsáhlé skladové hospodářství nebo přísnější auditní požadavky. Moderní nástupce v portfoliu Asseco je Helios iNuvio — cloudově-nativní platforma s API-first přístupem.

API-first architektura Helios iNuvio

Na rozdíl od Pohody a staršího Money S3 je Helios iNuvio navržen s API integrací jako prvotřídním kanálem od základů. Disponuje REST API s rozsáhlejší dokumentací, podporou webhooků a auditním logem změn — to je klíčové pro firmy, kde je traceability obchodních událostí zákonnou nebo interní požadavkem. Pro integraci e-shopu to znamená, že konektor může být napsán čistě jako API klient bez nutnosti obcházet systém přes soubory.

Komplexita nastavení

Helios je výkonný, ale ten výkon za něco stojí. Implementace trvá déle než u Pohody nebo Money S3 — typicky více týdnů — a vyžaduje certifikovaného partnera Asseco. Pro jednoduchý e-shop s několika stovkami objednávek měsíčně je Helios předimenzovaný. Kde dává smysl: B2B e-commerce s pěti a více skladovými místy, cross-border prodej v cizích měnách a požadavek na full-audit trail každé skladové operace.

Jak si vybrat: rozhodovací matice

Pokud ještě nemáte fixní účetní systém a rozhodujete se před integračním projektem, tady je pět otázek, které vám pomohou vybrat ten správný:

• Objem faktur měsíčně. Do 500 faktur měsíčně zvládne bez problémů Pohoda i Money S3. Nad 2 000 faktur začíná být důležitější výkon backendu — SQL varianty nebo Helios iNuvio.
• Multi-user souběh. Pokud více lidí najednou zapisuje (sklad, obchod, účetnictví), desktopové verze mohou způsobovat konflikty zámků. Cloudové varianty nebo Helios tento problém řeší nativně.
• Multi-sklad a vícero poboček. Pohoda a Money S3 podporují vícero skladů, ale při skutečně distribuované logistice s cross-dock operacemi je Helios robustnější.
• Multi-currency a cross-border prodej. Pokud prodáváte do více zemí a pracujete s více měnami, ujistěte se, že váš účetní systém to zvládne i v automatickém revalvačním účtování. Helios má delší historii.
• Přísnost auditního záznamu. Pokud jste v regulovaném odvětví nebo máte interní požadavky na full-audit trail, Helios iNuvio nabízí nejsilnější auditní model.

Implementační plán bez bolesti

Bez ohledu na to, který systém jste vybrali, ověřený implementační postup vypadá stejně. Tady je pět kroků:

1. Audit aktuálního stavu

   Zmapujte všechny toky dat, které dnes probíhají manuálně: objednávky, zákaznické karty, skladové pohyby, faktury, platby. Zjistěte, kolik záznamů denně, jaké výjimky existují a kde jsou nejčastější chyby.

2. Definice datového kontraktu

   Dohodněte se na přesném mapování polí mezi e-shopem a účetním systémem: jak se mapují produktové kódy, DPH skupiny, platební metody, stavy objednávek. Zdokumentujte to do jednoduché tabulky.

3. Idempotentní konektor

   Naprogramujte konektor tak, aby opakované zpracování stejné objednávky nevytvořilo duplikátní záznam. Každá objednávka musí mít jednoznačný externí identifikátor uložený na obou stranách.

4. Testování v sandboxu

   Před ostrým spuštěním otestujte všechny scénáře v testovacím prostředí: standardní objednávka, vrácení zboží, dobírka, částečná platba, storno před expedicí.

5. Ostrý start s rekonciliací

   Při přechodu na ostrý provoz spusťte paralelní běh: první 1–2 týdny kontrolujte každý den, že záznamy v e-shopu a v účetním systému sedí. Nastavte automatický rekonciliační report. Když je chybovost pod 0,1 %, můžete odstranit manuální kontrolu.