Účetní deník POHODA: jak dostat aktuální údaje k AI

Majitel se v pondělí zeptá, proč firmě vzrostly náklady. Účetní však v pátek opravil doklad, přesunul jeden náklad do jiného měsíce a doplnil chybějící fakturu. Pokud AI pracuje se starým exportem, může připravit přesvědčivé vysvětlení čísel, která už neplatí.

U účetního deníku proto nestačí jednou přenést údaje. Potřebujeme vědět, ze které firmy pocházejí, jaké období pokrývají a zda obsahují pozdější změny. POHODA poskytuje XML export deníku podvojného účetnictví. Prostřednictvím mServeru jej lze využít také v průběžné integraci.

Co má smysl přenášet z účetního deníku

Užitečný podklad obsahuje ID zápisu, zdroj a číslo dokladu, text, částky, účty a dostupná data. Podle vyplněných údajů také středisko, činnost a zakázku. Prázdné středisko znamená chybějící členění, nikoli automaticky administrativu.

Číslo faktury nemusí jednoznačně označovat řádek deníku. Jeden doklad může vytvořit více zápisů. Pro uložení použijte klíč zahrnující firmu, konkrétní databázi, účetní rok a ID zápisu. Stejné ID v jiné databázi nesmí přepsat cizí údaje.

Zachovejte také vazbu na zdrojový doklad. Podnikatel tak při vysvětlení růstu nájemného dostane konkrétní fakturu, kterou může účetní ověřit. Význam analytických účtů pomůže doplnit účtová osnova POHODA pro AI.

Nejdříve určete, které datum rozhoduje

Účetní měsíc, datum vystavení dokladu a datum zdanitelného plnění představují rozdílné pohledy. Pro analýzu nákladů vyberte pravidlo účetního období. Při kontrole DPH použijte pravidla příslušné evidence. Datum platby zase patří do otázky o pohybu peněz.

dateFrom a dateTill jsou elementy XML filtru, nikoli parametry URL mServeru. Stejně se v XML zadává název uloženého výběru userFilterName nebo podmínka queryFilter. Samotný název „datum od“ ještě nepotvrzuje, že výběr odpovídá požadovanému účetnímu datu.

Ověřte chování na dokladu s účetním datem 31. ledna, vystavením 3. února a daňovým datem 5. února. Lednový účetní přehled jej má zahrnout podle zvoleného pravidla, výběr únorových vystavení podle jiného. Otestujte také 1. leden, 31. leden a 1. únor, abyste potvrdili hranice intervalu. Potřebné datum případně doplňte ze zdrojového dokladu; nevytvářejte jej odhadem.

První načtení musí projít celý výběr

Úvodní export vytvoří základ, se kterým budou další změny pracovat. Požadavek listAccountancyRequest umožňuje blok limit s elementy idFrom a count. Velikost stránky může být od 1 do 10 000 záznamů; praktický začátek je například 500.

Stránku ukládejte podle jedinečných ID. Pokud má poslední přijatá stránka nejvyšší ID 8242, další požadujte od 8243. Mezery v číslování neznamenají chybu. Sledujte, že maximum postupuje, a ukončení potvrďte úspěšnou prázdnou stránkou při stejném výběru.

HTTP odpověď 200 sama nestačí. Zkontrolujte výsledek zpracování XML i jednotlivých požadavků a dokončete všechny stránky. Výpadek uprostřed exportu nesmí vytvořit přehled označený jako úplný. Do té doby může aplikace používat poslední ověřenou verzi s jasným časem aktualizace.

Další běhy načtou nové a změněné zápisy

Filtr lastChanges vybírá záznamy změněné od zadaného data a času. Je to vstup do požadavku. Neznamená, že každý exportovaný řádek obsahuje vlastní pole updated_at, ani nenahrazuje historii všech úprav.

V návrhu synchronizace si před během zaznamenejte čas jeho začátku. Následující běh může začít pět minut před posledním úspěšně uloženým bodem. Takové překrytí pomáhá zachytit změny na hranici běhů; jeho délku je třeba přizpůsobit provozu a sladit časové pásmo i hodiny systémů.

Opakovaně přijatý zápis podle stejného klíče aktualizujte. Nepřičítejte jeho částku znovu. Při opravě účtu nebo období nahraďte původní hodnoty a přepočítejte dotčené součty. Tento postup musí být idempotentní: opakování stejné dávky nemění výsledek.

Kontrolní bod posuňte až po úspěšném zpracování všech stránek a uložení údajů. Při chybě zůstává původní bod a běh lze zopakovat. Čas začátku, nikoli libovolný čas po skončení, pomáhá nepřeskočit úpravy provedené během přenosu.

Změny nehledejte pouze v aktuálním měsíci

Účetní může v říjnu opravit lednový doklad. Pokud integrace vybírá jen říjen, tato změna se do porovnání ročních nákladů nedostane. Průběžný výběr změn proto nemá být omezen pouze na poslední měsíc, ale má pokrývat sledovanou databázi a účetní rok.

Příklad: náklad 600 € se původně nacházel v lednu. Po opravě účetního data patří do února. Lednové náklady klesnou o 600 € a únorové vzrostou o stejnou částku. Roční součet zůstane stejný. Otázka „proč se změnil leden?“ potřebuje vysvětlení přesunu, nikoli tvrzení, že firma ušetřila.

Při přechodu do nové roční databáze vytvořte samostatný kontext a první úplné načtení. Starší rok může nadále vyžadovat aktualizace během závěrky.

Pravidelně porovnávejte také celý soubor ID

Průběžné změny doplňte úplným kontrolním načtením sledovaného období. Porovnání aktuálních a uložených ID odhalí zápisy, které už ve výběru nejsou. Právě tyto případy samotný seznam nových a změněných položek nemusí spolehlivě vyřešit.

Chybějící ID však není automaticky důkaz smazání. Zápis mohl přejít do jiného období, přestat vyhovovat filtru nebo se stát nedostupným po změně práv. Nejdříve ověřte stejnou firmu, databázi, uživatele a definici výběru. Teprve úspěšný úplný běh poskytuje podklad pro vyhodnocení rozdílu.

Vlastní reportingová integrace může sporné zápisy označit ke kontrole a ověřit je mimo původní období. Interval kontrol určete podle objemu oprav a požadované aktuálnosti. Po větších úpravách nebo závěrce má smysl mimořádná kontrola.

Souběžné úpravy potřebují další kontrolu

Stránkovaný export během práce účetního není automaticky atomický snímek databáze. Mezi první a poslední stránkou může vzniknout nebo se změnit doklad.

Proto si uschovejte čas začátku úplného načtení a následně zpracujte změny od tohoto času s překrytím. Při důležitém závěrkovém porovnání zvolte klidnější čas, zopakujte kontrolu a porovnejte výsledek se sestavou POHODY. Označení „aktualizováno v 10:20“ vyjadřuje stav synchronizace, nikoli záruku, že od té doby nikdo nic neupravil.

Jak AI vysvětlí růst nákladů

Představme si nájemné 1 200 € měsíčně, které od března vzrostlo na 1 350 €. Nárůst je 150 €, tedy 12,5 %. AI může ukázat první vyšší doklad, porovnat navazující měsíce a oddělit pravidelný růst od jednorázové opravy.

Pokud v jednom měsíci přibylo také vyúčtování energií 400 €, celkový rozdíl nelze celý připsat nájmu. Potřebujeme rozlišit analytické účty, texty a zdrojové doklady. Výsledek může znít: „Zvýšení o 550 € tvoří vyšší nájem 150 € a vyúčtování energií 400 €.“

Výpočty provádějte podle ověřených pravidel: správná strana MD/Dal, znaménka, měna a mapování účtů. Nesčítejte mechanicky obě strany účtování jako dva náklady. AI potom vysvětluje vypočítaný výsledek a uvádí podklady, období i čas poslední úspěšné synchronizace. Vztah k oficiálním sestavám rozebírá článek o finančních výkazech a DPH z POHODY.

Otázky, které pomohou podnikateli i účetnímu

Podnikatel může začít konkrétním porovnáním:

• „Porovnej náklady na pronájem za leden až září. Ukaž pravidelné změny a jednorázové položky.“
• „Proč se lednové náklady změnily od minulého přehledu? Odděl nové doklady, opravy a přesuny.“
• „Která střediska vysvětlují největší část růstu nákladů? Nezařazené zápisy ukaž samostatně.“

Účetní potřebuje spíše kontrolovatelný seznam:

• „U každého rozdílu uveď ID zápisu, zdrojový doklad, účty a použité datum.“
• „Porovnej obraty vybraného účtu se sestavou POHODY za stejné období a stejný výběr.“
• „Ukaž zápisy, které zmizely z lednového výběru, a prověř, zda se přesunuly do února.“

Dobrá odpověď také přizná chybějící údaje. Z nevyplněné zakázky nelze spolehlivě odvodit náklad konkrétního projektu.

ÚčtoMost jako hotové připojení k AI

ÚčtoMost je hotové řešení. Připojte AI asistenta ChatGPT/Claude ke svému účetnímu programu POHODA, Money S3, KROS OMEGA, ALFA plus nebo MRP-K/S bez migrace a bez výměny programu. Přidejte trochu samoobsluhy a ušetřete účetnímu čas.

Připojení zpřístupňuje podporované údaje a operace podle oprávnění. Samostatný reportingový sklad, plánované synchronizační běhy a vlastní pravidla porovnávání představují možné návrhy další integrace. Jejich rozsah a provoz je třeba dohodnout podle potřeb firmy; tento článek je nepředstavuje jako automatickou součást každého připojení.

Začněte jedním ověřitelným přehledem

Vyberte jednu firmu, jeden nákladový účet a dva měsíce. Zkontrolujte data, úplnost stránek a součty oproti POHODĚ. Potom opravte testovací doklad, přesuňte jej mezi měsíci a zopakujte načtení. Výsledek musí zohlednit opravu bez zdvojení částky.

Takový pilot rychle ukáže, zda údaje poskytují dostatečný základ pro odpovědi AI. Nastavení připojení a práv popisuje průvodce ÚčtoMost a POHODA. Teprve po ověření jednoho přehledu rozšiřte stejná pravidla na další účty, období a firmy.