Integrácia e-shopu s Pohodou, Money S3 alebo Heliosom: Praktický sprievodca

Každú noc sa niekde na Slovensku opakuje rovnaká scéna: účtovníčka otvára e-shop, číta objednávky a prepisuje ich do účtovného systému. Päť minút na objednávku, tridsať objednávok denne — to sú dve a pol hodiny čistej administratívy, ktorá nepridáva žiadnu hodnotu. A to ešte nerátame chyby z únavy, nesúlad skladových stavov ani faktúry odoslané s oneskorením o dva dni.

Problém nie je ľudský — je systémový. E-shop a účtovný softvér sú dve oddelené aplikácie, ktoré sa navzájom nevidia. Kým medzi nimi nestojí integrácia, dáta sa musia prenášať ručne. A ručný prenos dát je spoľahlivo najdrahší spôsob, ako riešiť niečo, čo vie stroj. V našom všeobecnom sprievodci integráciou e-shopu s ERP a účtovníctvom sme sa pozreli na základné prístupy. Tento článok ide o krok hlbšie: konkrétne tri systémy — Pohoda, Money S3 a Helios — a čo od každého z nich môžete realisticky čakať.

Každý z týchto systémov má iné integračné možnosti, inú zrelosť API a iné typické úzke miesta. Správna voľba závisí od toho, ktorý systém už používate — alebo ktorý sa chystáte nasadiť. Pojďme na to.

Ako integrácia funguje na technickej úrovni

Predtým, než sa pustíme do konkrétnych systémov, je užitočné pochopiť, ako integrácia medzi e-shopom a účtovným softvérom technicky funguje. Existujú v zásade tri prístupy, pričom moderné projekty ich kombinujú.

XML a CSV import/exportje najstarší a stále najrozšírenejší spôsob. E-shop vygeneruje súbor s objednávkami v dohodnutom formáte a účtovný systém ho importuje. Výhoda: funguje bez sieťového pripojenia medzi systémami. Nevýhoda: nie je to real-time — typická latencia je 15 minút až hodina, záleží od frekvencie behu importu. Pri XML je tiež kritická otázka idempotentnosti: ak sa ten istý súbor importuje dvakrát (napr. pri chybe siete), systém nesmie vytvoriť duplikátne záznamy. Väčšina profesionálnych implementácií rieši idempotentnosť cez externý identifikátor objednávky.

REST API je modernejší prístup, kde e-shop aj účtovný systém komunikujú priamo cez HTTP volania. Objednávka vznikne na e-shope, connector ju okamžite odošle do účtovného systému a dostane späť potvrdenie s interným číslom záznamu. Latencia sa merá v sekundách. Kľúčovým dizajnovým rozhodnutím je párovanie záznamov: každá objednávka musí byť jednoznačne identifikovateľná v oboch systémoch, aby sa dali neskôr synchronizovať stavy (zaplatená, odoslaná, stornovaná).

Middleware layer— napríklad n8n alebo Make — sedí medzi e-shopom a účtovným systémom a orchestruje tok dát. Výhoda: jeden middleware môže obsluhovať viacero systémov naraz, centralizovať error handling a umožniť vizuálne ladenie tokov bez nutnosti zasahovať do kódu. Nevýhoda pri vysokom objeme: každé HTTP volanie cez middleware pridá latenci — čo pri stovkách objednávok za hodinu začína byť znateľné. Pre tieto prípady sú vhodnejšie priame automatizácia procesov riešenia písané na mieru.

Pohoda: silné a slabé stránky integrácie

Pohoda od Stormware je na Slovensku (aj v Česku) de facto štandard pre malé a stredné firmy. Jej rozšírenosť znamená, že integračné knowledgebase je bohatá — existuje množstvo hotových riešení, agentov a komunity. To je výhoda pri štarte projektu.

XML rozhranie a mServer

Pohoda ponúka dve hlavné integračné rozhrania. Prvé je súborový XML import/export: e-shop generuje XML súbory s objednávkami (prípadne aj so zákazníkmi a skladovými pohybmi) a Pohoda ich importuje cez dávkový mechanizmus. Štruktúra XML je dobre zdokumentovaná v technickej príručke Stormware a väčšina populárnych e-shopových platforiem (Shoptet, WooCommerce, PrestaShop) má na tento formát dostupné pluginy alebo exportné moduly.

Druhé rozhranie je mServer— HTTP server zabudovaný priamo do Pohody, ktorý umožňuje real-time volania cez REST rozhranie. mServer je výrazne flexibilnejší než dávkový import: môžete overovať dostupnosť tovaru, vytvárať objednávky a faktúry v reálnom čase a čítať stavy existujúcich záznamov. Pre väčšinu integračných projektov nad 50 objednávok denne odporúčame začať práve s mServerom.

Typické pracovné toky

Najbežnejší integračný tok vyzerá takto: nová objednávka na e-shope spustí webhook, connector ju transformuje do XML alebo JSON a odošle na mServer. Pohoda vytvorí vydanú faktúru (prípadne najskôr prijatú objednávku, podľa nastavenia), vráti interné číslo záznamu a connector ho uloží do e-shopu ako externý identifikátor. Keď zákazník zaplatí, e-shop alebo platobná brána pošle potvrdenie a connector zmení stav faktúry v Pohode na uhradenú. Keď sklad expeduje tovar, môže Pohoda zapísať odoslanú zásielku a e-shop aktualizovať stav objednávky.

Limity, ktoré treba poznať

Pohoda má niekoľko obmedzení, s ktorými treba pri integrácii počítať. Desktopová verzia (inštalovaná na Windows PC) dovoľuje pri XML importe otvoriť databázu len jedným procesom súčasne — kým prebieha import, iný používateľ nemôže zapisovať. To môže byť problém v multi-user prostredí. mServer toto obmedzenie zmierňuje, ale stále beží na jednom stroji a výkon závisí od jeho hardvéru. Pre veľmi vysoké objemy (stovky transakcií za hodinu) je vhodnejšie uvažovať o Pohoda SQL verzii s robustnejším backendom. mServer je voliteľný modul — má vlastný licenčný poplatok, čo treba zarátať do celkových nákladov projektu.

Money S3: silné a slabé stránky integrácie

Money S3 vyvíja spoločnosť Seyfor (do roku 2022 Cígler Software). Je to dlhodobo obľúbený systém s veľkou základňou používateľov v SR a ČR, najmä v malých firmách a živnostiach. Seyfor v posledných rokoch agresívne investoval do cloudovej verzie a modernizácie API, čo integrácii prospelo.

XML a API rozhranie

Money S3 podporuje import a export dát cez XML súbory s vlastnou schémou. Podobne ako Pohoda, tento kanál je vhodný pre dávkové spracovanie menej frekventovaných objemov. Pre real-time integráciu existuje REST API, ktoré je dostupné najmä v cloudovej a SQL variante. Desktopová verzia má API funkčnosť obmedzenejšiu, ale väčšina integračných projektov dnes smeruje zákazníkov k SQL alebo cloudovej licencii práve pre lepší API prístup.

Cloud vs. desktop variant a multi-user správanie

Cloudová verzia Money S3 (prípadne prechod na Money S5, novšiu generáciu produktu) odstraňuje problém single-user XML zámku, ktorý je obmedzením desktopových inštalácií. V cloude môže API zapisovať súbežne s tým, ako účtovníčka pracuje v rozhraní — databáza to zvládne bez konfliktov, pretože beží na dedikovanom serveri. Pre nové integračné projekty dnes väčšina partnerov odporúča práve cloudovú alebo SQL verziu, aj keď prechod z desktopovej licencie si vyžaduje migráciu dát.

Integračný prístup cez Money S5 connector alebo middleware

Pre firmy, ktoré prechádzajú z Money S3 na novšiu generáciu Money S5, je API výrazne modernejšie a integrácia jednoduchšia. Money S5 má REST API s OAuth2 autentifikáciou a Swagger dokumentáciou, čo umožňuje priame napojenie bez nutnosti tretej strany. Pre zostatok na Money S3 je zaužívaný prístup cez middleware (n8n, Make) so XML konektorom. Výhodou middlewarového riešenia je vizuálna transparentnosť tokov a jednoduchšia údržba pri zmenách v obchodnej logike.

Helios: silné a slabé stránky integrácie

Helios od Asseco Solutions je silný hráč v strednom a vyššom segmente trhu. Zatiaľ čo Pohoda a Money S3 dominujú u malých firiem, Helios sa výraznejšie presadzuje tam, kde je potrebné pokryť komplexnejšie procesy: viacero pobočiek, multi-currency operácie, rozsiahle skladové hospodárstvo alebo prísnejšie auditné požiadavky. Moderný nástupca v portfóliu Asseco je Helios iNuvio— cloudovo-natívna platforma s API-first prístupom.

API-first architektúra Helios iNuvio

Na rozdiel od Pohody a staršieho Money S3, Helios iNuvio je navrhnutý s API integráciou ako prvotriednym kanálom od základov. Disponuje REST API s rozsiahlejšou dokumentáciou, podporou webhookov a auditným logom zmien — to je kľúčové pre firmy, kde je traceability obchodných udalostí zákonnou alebo internou požiadavkou. Pre integráciu e-shopu to znamená, že connector môže byť napísaný čisto ako API klient bez nutnosti obchádzať systém cez súbory.

Asseco ekosystém a rozšírenia

Helios funguje v rámci širšieho ekosystému Asseco Solutions, čo prináša výhody pri komplexných projektoch: natívna integrácia s WMS (warehouse management), EDI prepojenia na dodávateľov a odberateľov, alebo napojenie na logistické platformy. Pre e-shopy s veľkým počtom SKU (tisíce produktov, viaceré sklady) je toto ekosystémové zázemie dôležité — Pohoda ani Money S3 neponúkajú porovnateľnú hĺbku skladového modulu out-of-the-box.

Komplexita nastavenia

Helios je výkonný, ale tá výkon za niečo stojí. Implementácia trvá dlhšie než u Pohody alebo Money S3 — typicky viac týždňov a vyžaduje certifikovaného partnera Asseco. Pre jednoduchý e-shop s niekoľkými stovkami objednávok mesačne je Helios predimenzovaný. Kde dáva zmysel, je B2B e-commerce s piatimi a viac skladovými miestami, cross-border predajom v cudzích menách a požiadavkou na full-audit trail každej skladovej operácie. V takýchto scenároch vie mať vlastný integračný layer s AI vrstvou nad Heliosom zmysel — napríklad pre automatické mapovanie produktových kódov medzi e-shopom a ERP pri stovkách nových SKU mesačne.

Ako si vybrať: rozhodovacia matica

Ak ešte nemáte fixný účtovný systém a rozhodujete sa pred integračným projektom, tu je päť otázok, ktoré vám pomôžu vybrať správny:

• Objem faktúr mesačne.Do 500 faktúr mesačne zvládne bez problémov Pohoda aj Money S3. Nad 2 000 faktúr mesačne začína byť dôležitejší výkon backendu — SQL varianty oboch systémov alebo Helios iNuvio.
• Multi-user súbežnosť.Ak viacero ľudí naraz zapisuje do systému (sklad, obchod, účtovníctvo), desktopové verzie Pohody a Money S3 môžu spôsobovať konflikty zámkov. Cloudové varianty alebo Helios tento problém riešia nativ­ne.
• Multi-sklad a viacero pobočiek.Pohoda a Money S3 podporujú viaceré sklady, ale pri skutočne distribuovanej logistike s cross-dock operáciami je Helios robustnejší. Pre jednoduchý jedno-skladový e-shop je táto otázka irelevantná.
• Multi-currency a cross-border predaj. Ak predávate do Česka, Maďarska alebo ďalej a pracujete s viacerými menami, uistite sa, že váš účtovný systém to zvládne aj v automatickom revalvačnom účtovaní. Helios má tu dlhšiu históriu a väčšiu konfigurovateľnosť.
• Prísnosť auditného záznamu.Ak ste v regulovanom odvetví alebo máte interné požiadavky na full-audit trail každej zmeny (kto čo zmenil a kedy), Helios iNuvio ponúka najsilnejší auditný model. Pohoda a Money S3 majú základný log zmien, ale nie v rovnakej granularite.

Implementačný plán bez bolesti

Bez ohľadu na to, ktorý systém ste vybrali, overený implementačný postup vyzerá rovnako. Tu je päť krokov, ktoré oddeľujú úspešné projekty od tých, čo sa zasekli na polceste.

1. Audit aktuálneho stavu

   Zmapujte všetky toky dát, ktoré dnes prebiehajú manuálne: objednávky, zákaznícke karty, skladové pohyby, faktúry, platby. Zistite, koľko záznamov denne, aké výnimky existujú (dobierky, vrátenia, B2B vs. B2C cenníky) a kde sú najčastejšie chyby. Tento audit je vstupom pre návrh dátového kontraktu aj pre odhad nákladov.

2. Definícia dátového kontraktu

   Dohodnite sa na presnom mapovaní polí medzi e-shopom a účtovným systémom: ako sa mapujú produktové kódy, DPH skupiny, platobné metódy, stavy objednávok. Zdokumentujte to do jednoduchej tabuľky — tento dokument je referenciou pri každej zmene v budúcnosti. Zanedbanie tohto kroku je najčastejšia príčina neskorších problémov pri integrácii.

3. Idempotentný konektor

   Naprogramujte alebo nakonfigurujte konektor tak, aby opakované spracovanie tej istej objednávky nevytvorilo duplikátny záznam. Každá objednávka musí mať jednoznačný externý identifikátor, ktorý sa ukladá na oboch stranách. Konektor pri každom spracovaní najskôr skontroluje, či záznam existuje — a len ak neexistuje, vytvorí ho. Toto pravidlo platí bez výnimky, aj pri opakovaných pokusoch po chybách siete.

4. Testovanie v sandboxe

   Pred ostrým spustením otestujte všetky scenáre v testovacom prostredí: štandardná objednávka, objednávka s vrátením tovaru, dobierka, čiastočná platba, storno pred expedíciou. Overte, že stavy sa správne propagujú v oboch smeroch a že chybové stavy (zamietnutá platba, nedostupný produkt) sa spracujú elegantne bez zanechania „osirotených" záznamov.

5. Ostrý štart s rekonciliáciou

   Pri prechode na ostrú prevádzku spustite paralelný beh: prvé 1–2 týždne kontrolujte každý deň, že záznamy v e-shope a v účtovnom systéme sedí. Nastavte si automatický rekonciliačný report — napríklad zoznam objednávok z e-shopu, pre ktoré neexistuje zodpovedajúci záznam v účtovníctve. Keď je chybovosť pod 0,1 %, môžete odstrániť manuálnu kontrolu a nechať systém bežať autonómne.