Späť na blog

Účtovný denník POHODA: ako dostať aktuálne údaje k AI

Ako načítať účtovný denník POHODA cez XML API, zachytiť opravy aj presuny a pripraviť spoľahlivé podklady pre otázky podnikateľa.

Účtovný denník POHODA prepojený s AI a kontrolou aktuálnosti údajov

Majiteľ sa v pondelok opýta, prečo firme stúpli náklady. Účtovník však v piatok opravil doklad, presunul jeden náklad do iného mesiaca a doplnil chýbajúcu faktúru. Ak AI pracuje so starým exportom, môže pripraviť presvedčivé vysvetlenie čísel, ktoré už neplatia.

Pri účtovnom denníku preto nestačí raz preniesť údaje. Potrebujeme vedieť, z ktorej firmy pochádzajú, aké obdobie pokrývajú a či obsahujú neskoršie zmeny. POHODA poskytuje XML export denníka podvojného účtovníctva. Prostredníctvom mServera ho možno využiť aj v priebežnej integrácii.

Čo má zmysel prenášať z účtovného denníka

Užitočný podklad obsahuje ID zápisu, zdroj a číslo dokladu, text, sumy, účty a dostupné dátumy. Podľa vyplnených údajov tiež stredisko, činnosť a zákazku. Prázdne stredisko znamená chýbajúce členenie, nie automaticky administratívu.

Číslo faktúry nemusí jednoznačne označovať riadok denníka. Jeden doklad môže vytvoriť viac zápisov. Pre uloženie použite kľúč zahŕňajúci firmu, konkrétnu databázu, účtovný rok a ID zápisu. Rovnaké ID v inej databáze nesmie prepísať cudzie údaje.

Zachovajte aj väzbu na zdrojový doklad. Podnikateľ tak pri vysvetlení rastu nájomného dostane konkrétnu faktúru, ktorú môže účtovník overiť. Význam analytických účtov pomôže doplniť účtová osnova POHODA pre AI.

Najskôr určite, ktorý dátum rozhoduje

Účtovný mesiac, dátum vystavenia dokladu a dátum zdaniteľného plnenia predstavujú rozdielne pohľady. Pre analýzu nákladov vyberte pravidlo účtovného obdobia. Pri kontrole DPH použite pravidlá príslušnej evidencie. Dátum platby zase patrí do otázky o pohybe peňazí.

dateFrom a dateTill sú elementy XML filtra, nie parametre URL mServera. Rovnako sa v XML zadáva názov uloženého výberu userFilterName alebo podmienka queryFilter. Samotný názov „dátum od“ ešte nepotvrdzuje, že výber zodpovedá požadovanému účtovnému dátumu.

Overte správanie na doklade s účtovným dátumom 31. januára, vystavením 3. februára a daňovým dátumom 5. februára. Januárový účtovný prehľad ho má zahrnúť podľa zvoleného pravidla, výber februárových vystavení podľa iného. Otestujte tiež 1. január, 31. január a 1. február, aby ste potvrdili hranice intervalu. Potrebný dátum prípadne doplňte zo zdrojového dokladu; nevytvárajte ho odhadom.

Prvé načítanie musí prejsť celý výber

Úvodný export vytvorí základ, s ktorým budú ďalšie zmeny pracovať. Požiadavka listAccountancyRequest umožňuje blok limit s elementmi idFrom a count. Veľkosť stránky môže byť od 1 do 10 000 záznamov; praktický začiatok je napríklad 500.

Stránku ukladajte podľa jedinečných ID. Ak má posledná prijatá stránka najvyššie ID 8242, ďalšiu žiadajte od 8243. Medzery v číslovaní neznamenajú chybu. Sledujte, že maximum postupuje, a ukončenie potvrďte úspešnou prázdnou stránkou pri rovnakom výbere.

HTTP odpoveď 200 sama nestačí. Skontrolujte výsledok spracovania XML aj jednotlivých požiadaviek a dokončite všetky stránky. Výpadok uprostred exportu nesmie vytvoriť prehľad označený ako úplný. Dovtedy môže aplikácia používať poslednú overenú verziu s jasným časom aktualizácie.

Ďalšie behy načítajú nové a zmenené zápisy

Filter lastChanges vyberá záznamy zmenené od zadaného dátumu a času. Je to vstup do požiadavky. Neznamená, že každý exportovaný riadok obsahuje vlastné pole updated_at, ani nenahrádza históriu všetkých úprav.

V návrhu synchronizácie si pred behom zaznamenajte čas jeho začiatku. Nasledujúci beh môže začať päť minút pred posledným úspešne uloženým bodom. Takéto prekrytie pomáha zachytiť zmeny na hranici behov; jeho dĺžku treba prispôsobiť prevádzke a zosúladiť časové pásmo aj hodiny systémov.

Opakovane prijatý zápis podľa rovnakého kľúča aktualizujte. Nepripočítavajte jeho sumu znova. Pri oprave účtu alebo obdobia nahraďte pôvodné hodnoty a prepočítajte dotknuté súčty. Tento postup musí byť idempotentný: opakovanie rovnakej dávky nemení výsledok.

Kontrolný bod posuňte až po úspešnom spracovaní všetkých stránok a uložení údajov. Pri chybe zostáva pôvodný bod a beh možno zopakovať. Čas začiatku, nie ľubovoľný čas po skončení, pomáha nepreskočiť úpravy vykonané počas prenosu.

Zmeny nehľadajte iba v aktuálnom mesiaci

Účtovník môže v októbri opraviť januárový doklad. Ak integrácia vyberá len október, táto zmena sa do porovnania ročných nákladov nedostane. Priebežný výber zmien preto nemá byť obmedzený iba na posledný mesiac, ale má pokrývať sledovanú databázu a účtovný rok.

Príklad: náklad 600 € sa pôvodne nachádzal v januári. Po oprave účtovného dátumu patrí do februára. Januárové náklady klesnú o 600 € a februárové stúpnu o rovnakú sumu. Ročný súčet zostane rovnaký. Otázka „prečo sa zmenil január?“ potrebuje vysvetlenie presunu, nie tvrdenie, že firma ušetrila.

Pri prechode do novej ročnej databázy vytvorte samostatný kontext a prvé úplné načítanie. Starší rok môže naďalej vyžadovať aktualizácie počas uzávierky.

Pravidelne porovnávajte aj celý súbor ID

Priebežné zmeny doplňte úplným kontrolným načítaním sledovaného obdobia. Porovnanie aktuálnych a uložených ID odhalí zápisy, ktoré už vo výbere nie sú. Práve tieto prípady samotný zoznam nových a zmenených položiek nemusí spoľahlivo vyriešiť.

Chýbajúce ID však nie je automaticky dôkaz vymazania. Zápis mohol prejsť do iného obdobia, prestať vyhovovať filtru alebo sa stať nedostupným po zmene práv. Najskôr overte rovnakú firmu, databázu, používateľa a definíciu výberu. Až úspešný úplný beh poskytuje podklad na vyhodnotenie rozdielu.

Vlastná reportingová integrácia môže sporné zápisy označiť na kontrolu a overiť ich mimo pôvodného obdobia. Interval kontrol určite podľa objemu opráv a požadovanej aktuálnosti. Po väčších úpravách alebo uzávierke má zmysel mimoriadna kontrola.

Súbežné úpravy potrebujú ďalšiu kontrolu

Stránkovaný export počas práce účtovníka nie je automaticky atomický snímok databázy. Medzi prvou a poslednou stránkou môže vzniknúť alebo sa zmeniť doklad.

Preto si uschovajte čas začiatku úplného načítania a následne spracujte zmeny od tohto času s prekrytím. Pri dôležitom uzávierkovom porovnaní zvoľte pokojnejší čas, zopakujte kontrolu a porovnajte výsledok so zostavou POHODY. Označenie „aktualizované o 10:20“ vyjadruje stav synchronizácie, nie záruku, že odvtedy nikto nič neupravil.

Ako AI vysvetlí rast nákladov

Predstavme si nájomné 1 200 € mesačne, ktoré od marca stúplo na 1 350 €. Nárast je 150 €, teda 12,5 %. AI môže ukázať prvý vyšší doklad, porovnať nadväzujúce mesiace a oddeliť pravidelný rast od jednorazovej opravy.

Ak v jednom mesiaci pribudlo aj vyúčtovanie energií 400 €, celkový rozdiel nemožno celý pripísať nájmu. Potrebujeme rozlíšiť analytické účty, texty a zdrojové doklady. Výsledok môže znieť: „Zvýšenie o 550 € tvorí vyšší nájom 150 € a vyúčtovanie energií 400 €.“

Výpočty vykonávajte podľa overených pravidiel: správna strana MD/Dal, znamienka, mena a mapovanie účtov. Nesčítavajte mechanicky obe strany účtovania ako dva náklady. AI potom vysvetľuje vypočítaný výsledok a uvádza podklady, obdobie aj čas poslednej úspešnej synchronizácie. Vzťah k oficiálnym zostavám rozoberá článok o finančných výkazoch a DPH z POHODY.

Otázky, ktoré pomôžu podnikateľovi aj účtovníkovi

Podnikateľ môže začať konkrétnym porovnaním:

  • „Porovnaj náklady na prenájom za január až september. Ukáž pravidelné zmeny a jednorazové položky.“
  • „Prečo sa januárové náklady zmenili od minulého prehľadu? Oddeľ nové doklady, opravy a presuny.“
  • „Ktoré strediská vysvetľujú najväčšiu časť rastu nákladov? Nezaradené zápisy ukáž samostatne.“

Účtovník potrebuje skôr kontrolovateľný zoznam:

  • „Pri každom rozdiele uveď ID zápisu, zdrojový doklad, účty a použitý dátum.“
  • „Porovnaj obraty vybraného účtu so zostavou POHODY za rovnaké obdobie a rovnaký výber.“
  • „Ukáž zápisy, ktoré zmizli z januárového výberu, a prever, či sa presunuli do februára.“

Dobrá odpoveď tiež prizná chýbajúce údaje. Z nevyplnenej zákazky sa nedá spoľahlivo odvodiť náklad konkrétneho projektu.

ÚčtoMost ako hotové pripojenie k AI

ÚčtoMost je hotové riešenie. Pripojte AI asistenta ChatGPT/Claude k svojmu účtovnému programu POHODA, Money S3, KROS OMEGA, ALFA plus alebo MRP-K/S bez migrácie a bez výmeny programu. Pridajte trochu samoobsluhy a ušetrite účtovníkovi čas.

Pripojenie sprístupňuje podporované údaje a operácie podľa oprávnení. Samostatný reportingový sklad, plánované synchronizačné behy a vlastné pravidlá porovnávania predstavujú možné návrhy ďalšej integrácie. Ich rozsah a prevádzku treba dohodnúť podľa potrieb firmy; tento článok ich nepredstavuje ako automatickú súčasť každého pripojenia.

Začnite jedným overiteľným prehľadom

Vyberte jednu firmu, jeden nákladový účet a dva mesiace. Skontrolujte dátumy, úplnosť stránok a súčty oproti POHODE. Potom opravte testovací doklad, presuňte ho medzi mesiacmi a zopakujte načítanie. Výsledok musí zohľadniť opravu bez zdvojenia sumy.

Takýto pilot rýchlo ukáže, či údaje poskytujú dostatočný základ pre odpovede AI. Nastavenie pripojenia a práv opisuje sprievodca ÚčtoMost a POHODA. Až po overení jedného prehľadu rozšírte rovnaké pravidlá na ďalšie účty, obdobia a firmy.