Klient je skupina, která přes 17 e-shopů v šesti zemích prodává stínicí techniku a další sortiment. Jedenáct e-shopů běží na Shoptetu, šest na Shopify. Každý má vlastní administraci, vlastní exporty a vlastní měnu. Faktury šesti e-shopů na Shopify jsou ve Fakturoidu, reklama v Meta, Skliku a Google Ads. Odpověď na otázku „kolik jsme tento měsíc vydělali” znamenala skládat tabulku z desítek exportů.
Od března 2026 to dělá přehled, který jsem postavil a provozuju. Objednávky se synchronizují každých 10 minut a zpětně je načteno přes milion objednávek. Tenhle text je o tom, proč se každé číslo v něm ověřuje proti zdrojovému API, a co všechno nesedělo, než sedělo.
Proč do haléře
Přehled, kterému majitel nevěří, je horší než žádný. Jakmile se jednou rozejde s účetnictvím a nikdo neví proč, přestane se na něj dívat. Proto platí pravidlo: číslo je hotové, až sedí se zdrojem na haléř, nebo přesně vím, proč se liší.
Nejviditelnější případ jsou faktury. V srpnu dodal klient klíče ke zbylým pěti účtům Fakturoidu a jeden běh synchronizace stáhl 88 040 dokladů, celkem tedy 141 460. Nic „podle obrazovky”. Pro každý účet jsem stáhl červenec 2026 přímo z API a porovnal s databází: počet dokladů, počet dobropisů i součet s DPH seděl u všech pěti do haléře. Před uložením každého účtu se navíc ověřilo, že patří k tomu e-shopu, ke kterému ho klient přiřadil: vzorek čísel objednávek na dokladech proti objednávkám v databázi. Záměna by tiše nasypala cizí faktury pod špatný e-shop a z čísel by to nikdo nepoznal.
Jedna past z toho ověřování. Ověřovací skript rozešel součet u jednoho účtu přesně o 12 eur a vypadalo to jako chyba synchronizace. Chybu měl skript. Předpokládal, že opravný doklad je vždy záporný, a Fakturoid má i opravu směrem nahoru. Synchronizace znaménko z Fakturoidu nechává být, což bylo správně. Ověřovat se má i ověřovač.
Co nesedělo
Měna. Měna je v datech per objednávka, ne per e-shop. První verze sčítala koruny, eura a zloté jako holá čísla a psala k tomu „Kč”. Celkový obrat za dvanáct měsíců tím byl podhodnocený zhruba o čtvrtinu. Od července se všechno přepočítává kurzem ČNB.
Storna s nulou v hlavičce. Shoptet u stornované objednávky vynuluje cenu v hlavičce, ale položky si ji drží. Zhruba 99 % storen mělo v hlavičce nulu, takže řádek „Storna v Kč” nikdy nesedl a měsíc jsem ho považoval za neopravitelný. Stačilo se podívat o úroveň níž: částka storna se počítá ze součtu položek.
Shopify storna bez položek. Shopify u zrušené objednávky vynuluje všechna aktuální pole, včetně množství. Mapper filtroval položky s nenulovým množstvím, takže storno ukládal bez jediné položky a šest zahraničních e-shopů mělo storna trvale na nule. Po opravě a zpětném načtení: 1 902 storen za dvanáct měsíců, dřív nula.
Storno stavy per e-shop. Kód rozpoznával dva názvy stavů. Šest e-shopů používalo jiné. Dva slovenské mají „Stornovaná” místo „Stornována”, rozdíl jednoho písmene, o kterém nikdo nevěděl. Shoptet má přitom číselník stavů se systémovým identifikátorem pro storno. Ten se od té doby čte z API místo hádání podle textu.
Kurzy k datu objednávky. Původně jeden aktuální kurz na celou historii, což je vědomé rozhodnutí pro marketingový přehled. Pro srovnání s účetnictvím ale potřebujete kurz ke dni objednávky. Postavil jsem kurzovou osu ČNB od roku 2018, 3 175 dní krát 34 měn, a ke každé objednávce, faktuře i útratě za reklamu zmrazil kurz jejího dne. Přepnutí by pohnulo celoživotním obratem o 0,42 %. Kód je nasazený, přepínač vypnutý. Rozhodnutí patří klientovi, ne mně.
0,44 %
Finanční oddělení klienta dostalo přístup a porovnalo přehled se Shoptetem. Tabulka rozdílů byla první skutečný test. Za červenec 2026 jsem pak srovnal dva české e-shopy skupiny objednávka po objednávce: 2 662 a 1 622 objednávek, nula chybějících, nula přebývajících, nula rozdílů ve stavu ani v částce. Obrat seděl na haléř. Rozdíl proti tabulce financí byl v metodice počítání, ne v datech.
Na řádku storen v korunách zůstal u jednoho z nich rozdíl 0,44 %. U ostatních e-shopů vyšly rozdíly stejného druhu a všechny měly stejnou příčinu: jiný počet započtených objednávek, ne jinou hodnotu.
Dvě věci, které jsem se u toho naučil. Srovnávat se musí uzavřený měsíc k pevnému dni, protože obě strany se hýbou: osm objednávek přeřazených mezitím na „storno duplikát” vyrobilo rozdíl, který nebyl chyba. A finanční oddělení přepočítávalo zahraniční e-shopy pevným kurzem, přehled kurzem ČNB, takže zahraniční čísla nesednou nikdy, dokud se obě strany nedohodnou na kurzu.
Co si z toho odnést
Přehled nad daty z více systémů je hotový, až když každé číslo sedí se zdrojem, nebo víte přesně, proč ne. Ověřuje se proti API, ne proti obrazovce, a ověřovat se má i ověřovací skript. Největší rozdíly nebyly v kódu, ale v tom, jak jednotlivé systémy chápou storno, měnu a kurz. Rozhodnutí o metodice patří tomu, kdo čísla čte, ne tomu, kdo je počítá.