IDR (Intelligent Document Recogniser) automaticky rozpoznáva kľúčové údaje na PDF faktúre a premieňa ich na štruktúrované polia v e-faktúre. Ktoré polia sa rozpoznávajú, závisí od vášho predplatného a konfigurácie.

Pri každej konverzii PDF sa automaticky rozpoznávajú tieto polia:

Niektoré formáty dodávateľov môžu spôsobiť, že IDR zachytí iné pole ako číslo faktúry, napríklad ID transakcie namiesto skutočného čísla faktúry. Dobre známym príkladom sú faktúry Meta (Facebook), kde číslo faktúry sa nachádza v dolnej časti neskoršej stránky PDF a ID transakcie je rozpoznané prominentnejšie. Rovnaký vzor platí, keď IDR namiesto čísla faktúry prevezme IČO dodávateľa, číslo objednávky/PO alebo bankovú/platobnú referenciu (napríklad bankovú referenciu, IBAN alebo časť IBAN/čísla účtu), čo vedie k nesprávnemu číslu faktúry smerom do Coda alebo ERP systému. Tento posledný variant môže tiež spôsobiť, že dobropis je nesprávne blokovaný ako duplicitná faktúra (pozri Duplicitná faktúra). Ide o chybu výberu poľa v rozpoznávaní, odlišnú od správneho rozpoznania platobnej referencie ako samostatného poľa PaymentID (pozri Inkaso a účet G): tam platobná referencia neprepisuje číslo faktúry, tu je omylom rozpoznaná na jeho mieste.

To možno pre daný formát dodávateľa zlepšiť. Rozpoznávanie čísla faktúry nie je zákazníkom konfigurovateľné, ale je interne optimalizované členom tímu podpory prostredníctvom detekcie odľahlých hodnôt, regulárnych výrazov a nápovied pre konkrétneho dodávateľa alebo formát. Žiadna zmena roadmapy nie je potrebná; ide o cielenú optimalizáciu existujúcej funkcionality. Nahláste takýto prípad podpore — na základe hlásenia tím pridá nápovedu špecifickú pre dodávateľa, aby budúce faktúry v tomto formáte dostali správne číslo faktúry.

Ako funguje rozpoznávanie v pozadí (SampleStore)? IDR na to používa SampleStore: databázu vzorov rozpoznávania pre každého dodávateľa. Proces prebieha v troch krokoch: (1) hľadanie čísel zodpovedajúcich vzoru RegEx v SampleStore, (2) porovnanie s predchádzajúcimi príkladmi rovnakého dodávateľa (dĺžka, štruktúra, pomlčky, bodky, podtržítka, konzistentnosť), (3) samoučiace sa nastavenie na základe nových faktúr. Podpora po hlásení doplní SampleStore o príklady a prípadne RegEx.

Krátke alebo iné číslo namiesto dlhšieho vzoru s predponou. Ak faktúry dodávateľa majú zvyčajne pevnú predponu a pevnú dĺžku, IDR niekedy rozpozná kratšie alebo iné číslo bez tejto predpony. Je-li vzor (predpona, dĺžka, štruktúra) z hlásenia už jasný, prvým krokom je priama úprava SampleStore alebo RegEx pre tohto dodávateľa; príklad PDF alebo XML potom slúži ako dôkaz, nie ako povinný prvý krok. Ak rozpoznávanie predtým fungovalo správne a v priebehu času sa opäť stalo chybným, platí rovnaký prístup: skontrolovať a upraviť SampleStore pre tohto dodávateľa, čo nie je príznak chyby produktu.

Na vyšetrovanie je XML z platformy z doručenej pošty vhodný súbor: obsahuje stopu rozpoznávania IDR. XML, ktoré si sami exportujete zo svojho ERP systému (napr. AFAS) potom, čo bolo číslo faktúry už ručne opravené, zvyčajne postrádá tento IDR blok a zobrazuje iba už opravené číslo — tento súbor potom nie je vhodný na analýzu chyby rozpoznávania.

Skrytý alebo priehľadný text v PDF (opätovné použitie šablóny). Niektorí dodávatelia znova používajú starý PDF faktúry ako šablónu pre nové faktúry. Staré dátumy alebo čísla faktúr môžu zostať ako neviditeľný alebo priehľadný zvyškový text vo vrstve textu PDF. IDR používa hybridné OCR: okrem viditeľného obrazu sa číta aj textová vrstva PDF. Na snímke obrazovky alebo na monitore vidíte iba viditeľné riadky, ale rozpoznávanie vidí celú textovú vrstvu vrátane skrytého zvyškového textu. To môže byť príčinou, keď sa staré a nové číslo faktúry alebo dátum v rozpoznávaní pomiešajú. Ak podozrievate tento vzor, vždy si vyžiadajte originálny PDF: snímka obrazovky nestačí, pretože postrádá textovú vrstvu. Potom skopírujte text zo súboru do editora prostého textu a skontrolujte odchýlku oproti viditeľnému zobrazeniu.

Sekundárny príznak: faktúra chybne označená ako duplikát. Následná faktúra môže byť chybne označená ako duplikát, pretože IDR znovu použije alebo porovná nesprávne (skryté) číslo faktúry. Ide o dôsledok základnej chyby rozpoznávania, nie o samostatný problém: najprv opravte rozpoznávanie textovej vrstvy, ako je opísané vyššie, namiesto toho, aby ste riešili detekciu duplikátov izolovane (pozri Duplikátna faktúra).

Varianty vyhľadávania: „iné IČO v XML", „IČO faktúra vs XML", „IČO odosielateľa sa líši", „IČO dodávateľa nesprávne v XML", „IČO dodávateľa XML iné ako faktúra", „ID subjektu odosielateľa XML PDF", „AccountingSupplierParty IČO".

Niekedy sa IČO dodávateľa (alebo iné ID subjektu, ako IČ DPH) v bloku odosielateľa XML líši od toho, čo je uvedené na originálnom PDF, alebo rozpoznávanie priradí faktúru k nesprávnemu dodávateľovi. Ide o chybu rozpoznávania poľa na identifikátore dodávateľa, rovnako ako pri sumách, mene alebo čísle faktúry.

Pozor — nie je to to isté ako „IČO prečítané ako číslo faktúry". V tomto inom prípade (pozri vyššie) je IČO omylom rozpoznané v poli čísla faktúry. Tu ide o ID subjektu priamo v bloku odosielateľa, ktoré nezodpovedá PDF. Ide o dve samostatné otázky rozpoznávania.

Čo môžete urobiť? Neexistuje možnosť samoobslužnej úpravy XML. Zhromaždite originálny PDF a pridružený XML (na stiahnutie pri dokumente v doručenej pošte) a/alebo ID dokumentu konverznej úlohy a nahláste to podpore. Na tomto základe tím upraví rozpoznávanie alebo zhodu dodávateľa. Rovnako ako pri iných chybách rozpoznávania sa tu neuplatňuje žiadna pevná lehota.

Varianty vyhľadávania: „mena nebola správne rozpoznaná", „mena bola nesprávne rozpoznaná", „zlá mena IDR", „SEK namiesto NOK", „currency wrong PDF", „rozpoznávanie meny faktúra", „PDF mena chyba", „mena prečítaná chybne", „mena", „nesprávna mena", „mena OCR", „OCR mena", „CZK", „Kč", „koruna", „česká koruna", „EUR namiesto CZK", „EUR namiesto Kč", „EUR namiesto koruny".

Mena je štandardne rozpoznávané pole (pozri tabuľku vyššie) a spadá pod rovnaké generické chyby rozpoznávania PDF→XML ako číslo faktúry alebo suma: IDR môže nesprávne rozpoznať kód meny ISO v porovnaní s PDF (napríklad EUR namiesto Kč/CZK, alebo SEK namiesto NOK). Nejde o samostatnú funkciu ani o izolovaný problém, ale o rovnakú otázku rozpoznávania ako pri iných poliach. Zákaznícky pojem „OCR“ je tu vyhľadávacie slovo pre rozpoznávanie dokumentov/IDR; názov produktu zostáva IDR/rozpoznávanie PDF.

Čo môžete urobiť? Nahláste odchýlku podpore a doložte originálny PDF spolu s pridrûženým XML (z doručenej pošty) alebo ID dokumentu konverznej úlohy. Na tomto základe tím optimalizuje rozpoznávanie pre daný formát dodávateľa. Rovnako ako pri iných chybách rozpoznávania sa tu neuplatňuje žiadna pevná lehota.

S predplatným Professional sa rozpoznávajú ďalšie polia:

Varianty vyhľadávania: "americký dátum", "americký dátum faktúry", "dátum dodávateľa z USA", "dátum faktúry USA", "dátum faktúry MDY", "MDY namiesto DMY", "formát dátumu Spojené štáty", "dátum faktúry nesprávne rozpoznaný americký dodávateľ", "American date format invoice date", "US supplier date format MDY".

IDR rozpoznáva dátumy na PDF faktúrach a konvertuje ich do štandardného formátu dátumu UBL (YYYY-MM-DD). Pretože zápisy dátumov sa v krajinách líšia, IDR podľa krajiny dodávateľa určuje, ako interpretovať nejednoznačné dátumy:

• Spojené štáty: MDY (mesiac-deň-rok). Dátum 03/11 sa interpretuje ako 11. marec.
• Všetky ostatné krajiny: DMY (deň-mesiac-rok). Dátum 03/11 sa interpretuje ako 3. november.

Vidíte u dodávateľa zo Spojených štátov dátum faktúry, ktorý bol podľa vás rozpoznaný nesprávne? Najprv skontrolujte toto pravidlo pre danú krajinu, než to nahlásite ako chybu rozpoznávania poľa: u amerického dodávateľa je 03/11 napríklad 11. marec, nie 3. november. Ak zápis dátumu nie je vysvetlením, ide o inú otázku rozpoznávania (pozri vyššie).

Ak automatická detekcia krajiny nestačí, dá sa pre dodávateľa pridať konkrétna nápoveda pre formát dátumu cez mechanizmus hints.

Tip: nesprávne interpretované dátumy (napríklad 03/11 ako 11. marec namiesto 3. novembra) sú takmer vždy otázkou rozpoznávania, nie platformy. Platforma vždy zobrazuje dátum tak, ako je v UBL.

S predplatným Professional sa rozpoznaný IBAN porovnáva s verification store: databázou skôr manuálne overených čísel IBAN na dodávateľa. Ak sa IBAN na faktúre líši od skôr overeného, je to signalizované. Pomáha to odhaľovať fiktívne faktúry alebo zmenené bankové údaje.

Poznámka: podľa európskej normy EN16931 slúži IBAN na faktúre predovšetkým na identifikáciu dodávateľa, nie ako platobná inštrukcia. Zmenený IBAN musí byť vždy najprv overený v master dátach vášho finančného systému pred platbou.

Okrem štandardných referencií (číslo objednávky, číslo zmluvy, číslo projektu) sa dajú ďalšie referencie konfigurovať špecificky pre dodávateľa, napríklad rozpočtové kódy, kódy rozpočtových zodpovedných alebo interné referencie. Ide o prácu na mieru nastavenú na báze prúžkových kariet.

Rozpoznávanie konfigurovateľných referencií používa trojvrstvový mechanizmus:

1. Regex: validácia formátu, aby extrahovaná referencia presne zodpovedala očakávanému formátu
2. Outlier detection: štatistická detekcia odchýlok pre nepravdepodobné hodnoty
3. Hints: automaticky generované tréningové údaje na základe opráv tímu QC

Tip: číslo objednávky je najčastejšie používaná referencia a väčšina dodávateľov ho uvádza na faktúre. Ak dodávateľ nemôže vyplniť určité referenčné pole vo svojom softvéri, málo zmyslu ho požadovať. V tom prípade použite číslo objednávky ako primárnu referenciu.

Upozornenie: číslo objednávky, číslo zmluvy a číslo projektu sú štandardné polia Professional, ale rozpoznávanie sa aktivuje až po jednorazovom nastavení podporou pre klienta/dodávateľa (na základe aspoň 5 vzorových faktúr, prípadne doplnenom o regex). Kontaktujte podporu a poskytnite najlepšie vzorovú faktúru.

Dostávate cez API informatívnu odpoveď Order Reference detection skipped as Sample store is empty alebo Contract Reference detection skipped as Sample store is empty? Nejde o chybu spracovania. IDR vyplní tieto referencie až keď Customer Sample Store pre váš endpoint obsahuje vzorové referencie na porovnanie. Ak je store prázdny, preskočí sa iba toto rozpoznávanie referencie; ostatné polia a funkcie sa rozpoznávajú normálne.

Riešenie: poskytnite niekoľko vzorových čísel objednávok alebo referencií zmluvy (aspoň 3 znaky na vzorku) presne tak, ako sa objavujú na faktúrach, aby ich podpora mohla nakonfigurovať v Customer Sample Store. Potom najprv platí shoda podľa popisku (napr. „Your order number“), s regexom ako zálohou. Na nastavenie rozpoznávania PO čísla je tiež k dispozícii Remote Starter cez obchodný tím.

Nie, nie priamo na platforme. Customer Sample Store, formátovacie pravidlá alebo RegEx pre rozpoznávanie čísla objednávky si nespravujete sami; to nastavuje podpora eConnect.

Nepriamo však môžete:

• nechať dodávateľov fakturovať s jasným, jednotným formátom referenčného čísla objednávky (pozri osvedčený postup nižšie);
• podeliť sa o znalosť formátu (prefix, pevná dĺžka, štruktúra) s podporou;
• po neúspešnom rozpoznaní poskytnúť originálne PDF alebo ID dokumentu spolu so správnym číslom objednávky, aby podpora mohla aktualizovať Sample Store.

Osvedčený postup pre formát referenčného čísla objednávky na PDF:

• uveďte referenčné číslo objednávky pokiaľ možno raz na faktúre, nie opakovane na viacerých miestach;
• použite bežný popisok, napríklad Číslo objednávky, PO number, Č. obj. alebo Your order number;
• oddelte popisok a číslo medzerou alebo interpunkčným znamienkom, napríklad Číslo objednávky: 420000007 namiesto PO420000007;
• udržujte pevnú štruktúru a pokiaľ možno pevné umiestnenie na faktúre.

Pozri tiež Chyby odoslania pri blokovanej alebo zamietnutej faktúre v dôsledku nesprávne rozpoznaného čísla objednávky.

Varianty vyhľadávania: "viacero čísel PO", "viacero čísel objednávky jedna faktúra", "viacero referencii objednávky PDF", "OrderReference hlavička", "PO na riadku faktúry", "rozpoznávanie riadkov PO", "rozpoznávanie viacerých čísel PO".

• Úroveň hlavičky: maximálne jedno číslo objednávky (OrderReference) na hlavičke faktúry. Viacero čísel PO na jednom PDF automaticky nevypĺňa viacero referencii objednávky hlavičky.
• Úroveň riadku ako text: dalšie čísla PO na PDF môžu skončiť v popise riadku (textový fragment) prostredníctvom rozpoznávania riadkov — to samo o sebe nie je štrukturovaná referencia riadku objednávky.
• Skutočná referencia objednávky na úrovni riadku: iba ak má príjemca nastavenie na úrovni riadku; nie je to štandardné "viacero PO → viacero referencii objednávky".

Neočakávajte automatické spojenie viacerých čísel PO s viacerými referenciami objednávky hlavičky. Pri layoute s viacerými PO najprv skontrolujte nastavenie Professional a Sample Store pre jedno PO hlavičky; dalšie čísla PO skončia ako text riadku, nie ako samostatná referencia riadku objednávky, pokiaľ si to príjemca sam nenastavil. Pozri tiež Rozpoznávanie riadkov pre referenčné polia na riadok.

Podľa európskej normy EN16931 je referencia (buyer reference) povinná na elektronickej faktúre; často ide o číslo objednávky alebo inú referenciu príjemcu. Odosielateľ môže do tohto poľa umiestniť neplatnú hodnotu.

eConnect štandardne neodmieta faktúru na základe referencie. Faktúra nespĺňa základné pravidlá európskej normy iba vtedy, keď nie je prítomná žiadna referencia. To, či je faktúra odmietnutá z dôvodu neznámej alebo neplatnéj referencie, závisí od konfigurácie príjemcu: v konkrétnej konfigurácii príjemcu môže byť faktúra odmietnutá, ak je referencia neznáma. Ide teda o vlastnosť príjímajúcej konfigurácie, nie štandardného spracovania eConnect.

Tip: ak chcete odmietať faktúry s chýbajúcimi alebo neznámymi referenciami, nastavte to cez RBE (Rule Based Enrichment) na príjemcom endpoint.

Číslo faktúry (UBL pole cbc:ID, BT-1) je povinné v EN 16931, UBL BIS Billing 3.0 a NLCIUS pre bežné faktúry. IDR však spracováva zmiesaný tok dokumentov: bežné faktúry, dobropisy, účtenky výdavkov a paragony. Paragony spadajú pod zjednodušený režim fakturácie (transakcie do ca. 100 € vrátane DPH), pre ktorý daňový úrad nestanovuje číslo faktúry ako zákonnú požiadavku. Odmietanie kvôli chûbajúcemu číslu faktúry by vylúčilo všetky paragony a účtenky výdavkov zo spracovania.

Preto IDR pipeline automaticky generuje náhradné číslo, ked' pri rozpoznávaní nemožno z dokumentu extrahovať žiadne číslo faktúry. Pole cbc:ID (BT-1) sa potom vyplní štruktúrou:

YYYYMMDDHHmmss-NOTFOUND

Časová značka je okamih spracovania pipeline IDR, nie dátum na dokumente. Príklad: 20240315143022-NOTFOUND.

Filtrovanie je možné na dvoch úrovniach:

1. RBE (Rule Based Enrichment): nakonfigurujte pravidlo, ktoré kontroluje, či BT-1 (cbc:ID) končí na -NOTFOUND. Na základe toho možno dokument zadržať na ručnú kontrolu, presmerovať do samostatnéj schránky alebo automaticky odmietnuť.
2. Vlastné systémy (ERP/účtonný software): priame vyhľadávanie reťazca alebo regulárny výraz na -NOTFOUND v poli cbc:ID postačí.

S rozpoznávaním riadkov sa rozpoznávajú aj jednotlivé riadky faktúry: popis, jednotková cena, množstvo, suma riadku a referenčné polia na riadok. Ide o samostatnú funkciu, ktorú môžete aktivovať sami v Mojom prostredí.

Chcete vedieť, ako rozpoznávanie funguje technicky? Prečítajte si Ako funguje Scan & Rozpoznávanie (IDR/OCR)?.