PPF: od příchozí faktury k připraveným datům pro schválení

Faktura přichází e-mailem. Účetní data vznikají v souvislostech.

Přijmout PDF je začátek. Pro další zpracování faktury je potřeba určit dodavatele a odběratele, získat částky a termíny a doplnit údaje, které na dokladu často vůbec nejsou: název v používaném formátu, nákladové středisko nebo rozpočtové zařazení.

Pro PPF jsme dodali automatizované zpracování příchozích faktur, které kombinuje čtení dokumentů s historickými účetními vztahy. Řešení navazuje na existující příjem faktur a připravuje strukturovaný výstup pro interní systém LiveFlow a navazující schvalovací proces.

Jak do sebe řešení zapadá

Azure Logic Apps sleduje e-mailovou schránku, uloží přílohy a předá požadavek do Azure Service Bus. Invoice Processor zpracuje dokument, dohledá související údaje a uloží výsledek jako XML do Azure Blob Storage. Fronta odděluje příchod e-mailu od samotného zpracování a umožňuje opakovat požadavky při přechodné chybě.

Zjednodušený tok faktury podle dodané dokumentace. Výstup pro LiveFlow vzniká v úložišti; konečné schválení je součástí navazujícího procesu.

Najít správnou přílohu a přečíst její obsah

Jeden e-mail může obsahovat fakturu, objednávku i další přílohy. Processor nejprve vybírá dokument pro zpracování. Přednost má PDF s vloženým ISDOC; u ostatních příloh kombinuje pravidla pro názvy souborů s vyhodnocením pomocí jazykového modelu.

Strukturovaný ISDOC se čte parserem. U PDF získává potřebné informace AI agent z obrazové podoby prvních tří stran. Obě cesty převádějí údaje do stejného datového modelu. Pokud se fakturu nepodaří najít, vrací se odpovídající stav místo zdánlivě dokončeného výsledku.

Propojit doklad s účetní historií

Dalším krokem je určení dodavatele a odběratele. Systém hledá nejprve podle IČO, následně DIČ a názvu. Pokud jednoznačná shoda chybí, využije podobnost záznamů ve znalostní bázi a posouzení kandidátů jazykovým modelem.

Historie vztahu mezi oběma stranami pomáhá i s doplněním účetních údajů. Jeden agent navrhne název faktury podle jejího obsahu, další jej sjednotí s dříve používaným formátem. Podobné historické faktury poskytují podklady pro nákladové středisko, projekt nebo rozpočtový kód.

Například opakovaná služba od známého dodavatele může navázat na stejné účetní zařazení jako dříve. Pokud ale historie obsahuje více možností, výstup zachová alternativy pro následné posouzení.

Nejistota je součástí výsledku

Processor předává vedle hodnot také dostupná skóre jistoty a alternativy. U účetních dimenzí se skóre odvozuje z četnosti v historii: jestliže se stejná hodnota objevila v sedmi z deseti relevantních případů, odpovídá tomu skóre 70. Jde o vodítko pro kontrolu, nikoli o změřenou pravděpodobnost správnosti.

Výstup rozlišuje tři stavy:

• FullyProcessed: všechny kroky zpracování byly dokončeny.
• PartiallyProcessed: chybí například jednoznačné určení partnera nebo dostatečná historie pro účetní zařazení.
• InvoiceNotFound: mezi přílohami nebyla nalezena faktura.

Dokončené zpracování tak znamená připravená data. Konečné schválení zůstává v navazujícím procesu.

Provoz, ve kterém lze dohledat konkrétní fakturu

Invoice Processor je aplikace v Pythonu, provozovaná v Docker kontejneru na virtuálním serveru v Azure. Zprávy čekají v Service Bus a výsledky zůstávají navázané na zdrojový dokument. Identifikátor požadavku umožňuje dohledat průběh konkrétní faktury v Application Insights.

Technologie a naše role

Co spolupráce přináší

PPF získalo produkčně nasazený základ pro automatizaci od e-mailu po strukturovaná účetní data. Ruční práce se může soustředit na kontrolu, výjimky a schválení. Řešení propojuje obsah faktury s účetní historií a předává i informace potřebné k posouzení výsledku.