Účetnictví e-shopu má dvě poloviny, které spolu musí sedět.
Roky to u nás řešila placená propojovací služba — za každé jednotlivé napojení mezi e-shopem, bankou a účetnictvím se platil vlastní paušál. Když jsem si všechna propojení postavil sám, ušetřilo to 52 000 Kč ročně na samotných licencích. A hlavně: vlastní řešení umí i to, co ta služba neumožňovala.
Na jedné straně doklady — faktury, které jsme vystavili zákazníkům. Na druhé straně peníze — co reálně přistálo na účtu. Účetní práce je z velké části o tom, přiřadit jedno k druhému.
My máme čtyři e-shopy ve dvou zemích, tři banky, platební bránu a dopravce, který vybírá dobírky. Každý z těch zdrojů žije jinde, mluví jiným jazykem a peníze posílá jindy.
Ta práce není složitá. Je jí jen strašně moc a je pořád stejná.
Roky to řešila placená propojovací služba. Fungovala, ale platili jsme ji každý měsíc a uměla jen část toho, co jsme potřebovali. Tak jsem si to postavil sám. Tohle je princip.
První polovina: dostat faktury z e-shopu do účetnictví
Začal jsem tím, co vypadalo jednodušeji. Nebylo.
Shoptet umí faktury vyexportovat, ale ne tak, jak bych si přál. Není tam API, které by řeklo „dej mi faktury za včerejšek“ — je tam export v administraci, který vygeneruje XML ve formátu pro Pohodu. Klikací věc pro člověka.
Řešení je robot v prohlížeči: skript se přihlásí do administrace, proklikká se k exportu, nastaví datum, vybere formát a stáhne soubor. Pak ho převede z formátu pro jedno účetnictví do formátu pro druhé a nahraje přes API do Abra Flexi.
Znělo to jako nejkřehčí část celého systému. Ukázalo se, že běží nejspolehlivěji — jen bylo potřeba vyřešit pár věcí, které nejsou vidět:
- Export je chráněný tokenem. Formulář nejde odeslat napřímo, potřebuje bezpečnostní token, který se objeví jedině tehdy, když si předtím načtete stránku s doklady. Pořadí kroků je tedy součástí funkčnosti, ne jen kosmetika.
- Faktury se stahují se dvoudenním zpožděním. To není opatrnost, ale zkušenost: u zboží, které se prodává na míru, se faktura ještě den dva po vystavení mění. Kdybych ji naimportoval hned, přepisoval bych v účetnictví doklad, který už může být zaplacený.
- Hotovostní faktury potřebují protikus. Když zákazník zaplatí na místě, žádný bankovní pohyb nevznikne. Skript proto k takové faktuře rovnou založí pokladní příjem a spáruje ho — jinak by faktura navždy visela jako neuhrazená.
- Slovenské e-shopy mají vlastní daňový režim. Prodej koncovým zákazníkům jde v režimu OSS se slovenskou sazbou, prodej firmám s ověřeným DIČ v přenesené daňové povinnosti. Rozdíl se nepozná podle toho, jestli má zákazník DIČ — ale podle toho, jakou DPH mu e-shop reálně naúčtoval.
Druhá polovina: peníze ze čtyř různých světů
Tady je ta zajímavější část. Čtyři zdroje peněz a každý má úplně jinou úroveň vstřícnosti.
- FIO — ukázka, jak to má vypadat. Obyčejné REST API, zavoláte adresu s obdobím a dostanete pohyby v čitelném formátu. Jediné omezení je rychlostní limit, jeden dotaz za třicet vteřin na účet, takže při chybě se musí počkat a zkusit to znovu.
- ČSOB — opačný konec spektra. Žádné jednoduché API. Jde se přes firemní konektor: požadavek na seznam souborů se posílá jako SOAP, spojení se ověřuje klientským certifikátem, a to, co si stáhnete, je soubor ve formátu GPC.
- Shoptet Pay — platební brána s vlastní logikou. Denní výpis se stáhne přes API. Zásadní je pochopit, že jeden výpis znamená tři účetní pohyby: přijdou platby od zákazníků, brána si strhne poplatek, a zbytek pošle na bankovní účet. Když se zaúčtují všechny tři, průběžný účet brány se vynuluje. Když jen některé, nesedí nic.
- Zásilkovna — peníze, které vybere někdo jiný. Dobírky vybírá dopravce od zákazníků a posílá je souhrnně. Přes API se stáhnou jednotlivé zásilky a zaúčtují jako příjmy s číslem objednávky, aby se měly čím spárovat s fakturou.
Nejdéle netrvalo napsat kód. Trvalo pochopit, jak která strana přemýšlí o penězích.
| Zdroj | Co dává | Jak se to bere | Stav |
|---|---|---|---|
| Shoptet | Vystavené faktury | robot v prohlížeči → XML | OK |
| FIO | Bankovní pohyby | REST API | OK |
| ČSOB | Bankovní pohyby | SOAP + certifikát → GPC | OK |
| Shoptet Pay | Platby kartou a poplatky | REST API → CSV | OK |
| Zásilkovna | Vybrané dobírky | REST API | OK |
Párování
Když jsou v systému faktury i peníze, zbývá je spojit.
Účetní systém párování plateb umí sám a dělá to dobře — podle variabilního symbolu a částky. Jediné, co chybělo, bylo někoho donutit tu funkci pravidelně spustit. Takže poslední úloha dne není žádný chytrý algoritmus, jen jedno zavolání do API, které řekne „teď spáruj, co jde“.
Na pořadí záleží
Všechno běží v cloudu podle časového plánu, bez serveru a bez zásahu člověka. Není to ale pět nezávislých úloh — je to choreografie.
Párování musí běžet jako poslední, až když jsou v systému doklady i peníze. Kdyby se pustilo dřív, nemělo by co spárovat a výsledek by vypadal, že polovina faktur je neuhrazená. Banky proto jedou brzy ráno, faktury po nich, dobírky ještě před párováním, a párování až úplně nakonec.
Tohle je typ chyby, který se nehlásí. Nic nespadne, nikde není červený text — jen vám v účetnictví visí pohledávky, které jsou dávno zaplacené.
Co to změnilo
Nejvíc je vidět to, co zmizelo. Nikdo neexportuje faktury, nikdo nenahrává výpisy, nikdo neopisuje dobírky. Ráno je v účetnictví včerejšek a většina plateb je spárovaná.
Druhý efekt je méně nápadný, ale cennější: data jsou v účetnictví včas. Díky tomu nad nimi můžou stát další věci — třeba hlídání cash flow nebo report nákladů na dopravu. Kdyby se účetnictví dodělávalo měsíc zpětně, byly by ty přehledy k ničemu.
A do třetice: přestali jsme platit paušál za službu, která tohle dělala jen zčásti.
Kde do toho vstupuje AI
Stejná pointa jako u feedů. Nic z toho není technicky převratné — je to pět integrací, každá pár set řádků kódu.
Ale zkuste si to spočítat postaru: prokousat se dokumentací bankovního konektoru, rozparsovat formát z devadesátek podle pozic znaků, ošahat si nezdokumentované chování administrace e-shopu, a k tomu čtyři různá API. To byly týdny práce a sazba vývojáře. Pro firmu naší velikosti se to nevyplatilo — proto jsme platili tu službu.
Nezměnilo se, co jde postavit. Změnilo se, komu se to vyplatí.
Moje práce na tom nebyla psát kód, ale vědět, co má na konci vyjít: že se účet platební brány musí vynulovat, že se faktury nesmí tahat hned, že párování patří až nakonec. To je znalost provozu — a tu za vás zatím nikdo neudělá.
Kdy to dává smysl
Když vám měsíčně protéká dost dokladů na to, aby jejich ruční přepisování bylo znát, máte účetní systém s použitelným API a někoho, kdo pozná, že výstup nesedí.
Nedává to smysl, když vystavíte deset faktur měsíčně a máte jeden bankovní účet. Tam je ruční práce levnější než cokoliv jiného.
A pokud přemýšlíte, kde začít: nezačínejte tím nejsložitějším zdrojem. Napojte banku, která má normální API, nechte to měsíc běžet a zvykněte si věřit tomu, co v účetnictví přistane. Až pak se pouštějte do certifikátů a robotů v prohlížeči.
A těch 180 000 Kč v titulku
Přiznávám, trochu clickbait. Není to ušetřeno na licencích — je to roční cena externí účetní, kterou dnes nemám.
Nestalo se to tím, že by data tekla do účetnictví sama. Stalo se to tím, že FlexiBee má API, a nad ním můžou pracovat agenti, kteří účetnictví hlídají a odvádějí i běžnou agendu.
Příklad: vytvořit zápočet faktury byla v FlexiBee práce na několik minut — najít doklady, otevřít správnou evidenci, vyplnit ji. Dnes to trvá tolik, kolik zabere napsat pokyn do terminálu. Pár vteřin.
Napojení dat byla jen podmínka. Úspora přišla až z toho, co nad nimi jde postavit.
