Keď odošlete faktúru do eConnect, dokument prejde radom spracovateľských krokov. Ako presne spracovanie prebieha, závisí od typu súboru (XML alebo PDF) a kvality dodaného súboru. Tento článok vysvetľuje, čo sa deje v zákulisí.

eConnect pozná dve zásadne odlišné spracovateľské trasy:

XML spracovanie (priama trasa): ak odošlete platnú UBL faktúru (SI-UBL 2.0, Peppol BIS Billing 3.0 alebo iný podporovaný XML formát), táto sa spracuje priamo. Platforma prečíta štruktúrované údaje z XML, validuje ich a smeruje dokument k príjemcovi. Toto je najrýchlejšia a najspoľahlivejšia trasa.

PDF spracovanie (konverzia cez IDR): ak odošlete PDF faktúru, táto sa spracuje prostredníctvom Intelligent Document Recogniser (IDR). IDR extrahuje údaje faktúry cez OCR a rozpoznávanie vzorov a vytvorí UBL faktúru na základe rozpoznaných údajov. Tento proces je inherentne menej spoľahlivý ako priame XML spracovanie, pretože závisí od kvality PDF.

Tip: Dodanie UBL má vždy prednosť pred PDF. Je to rýchlejšie, lacnejšie a spoľahlivejšie. Opýtajte sa svojho dodávateľa alebo softvérového balíka, či je dostupný UBL export.

Pri odoslaní XML súboru eConnect vykoná nasledujúce kroky:

Platforma automaticky rozpozná, aký formát súbor sleduje, na základe CustomizationID a XML schémy. Podporované formáty zahŕňajú okrem iného NLCIUS, BIS Billing V3, XRechnung, CII a Factur-X.

Faktúra sa validuje voči pravidlám rozpoznaného profilu. To zahŕňa:

• Validácia schémy: zodpovedá XML štruktúre schémy UBL 2.1 alebo CII?
• Obchodné pravidlá: sedia výpočty? Sú povinné polia vyplnené? Zodpovedajú hodnoty zoznamov kódov?
• Pravidlá špecifické pre krajinu: sú dodržané správne NL-R-, DK-R- alebo iné pravidlá pre krajiny?

Tip: Dostávate hlásenie, že neboli nájdené "žiadne validačné pravidlá"? Zvyčajne to znamená, že CustomizationID vo Vašom XML chýba alebo nie je rozpoznaný. Bez rozpoznateľného profilu nemôže validátor aplikovať obchodné pravidlá. Overte, či Vaša faktúra obsahuje platný CustomizationID, napríklad NLCIUS alebo BIS Billing V3.

Nápadnou vlastnosťou spracovania eConnect je automatická oprava XML súborov. Prostredníctvom XSL transformácií sa opravujú známe chyby. Platforma v princípe akceptuje každé UBL; chýbajúce nepodstatné polia sa vyplnia štandardnými hodnotami. Táto opravná funkcia sa priebežne vyvíja na základe spätnej väzby od zákazníkov a je produkčne pripravená.

Príklady automatických opráv:

• Chýbajúce voliteľné polia sa doplnia správnymi štandardnými hodnotami
• Známe chyby formátu v poliach identifikátorov sa opravia
• Nekompletné kontaktné údaje sa doplnia (ak je pole ElectronicMail dodávateľa prázdne, eConnect automaticky vyplní support@econnect.eu, aby odmietnuté faktúry boli doručené odosielateľovi)

Ak príjemca podporuje iný formát ako zdrojový formát, PSB automaticky transformuje dokument. Faktúra NLCIUS sa môže napríklad transformovať na XRechnung, ak je príjemca nemecký orgán verejného sektora. To je možné vďaka tomu, že všetky podporované formáty sú založené na rovnakom sémantickom modeli (EN 16931).

Technické: Pri sťahovaní faktúry cez API môžete parametrom targetDocumentTypeId zadať požadovaný formát prijatia. PSB potom dokument transformuje do tohto formátu.

eConnect nikdy nerozpoznáva predajnú objednávku (dokument objednávky) ako fakturu a automaticky ju na fakturu neprevádza. Ak odešlete predajnú objednávku tam, kde sa očakáva faktura, dokument bude odmietnutý.

Dodavateľ musí sám dodať správny fakturačný dokument: UBL Invoice so správnym InvoiceTypeCode. eConnect zdrojový dokument neméni a túto konverziu nevykonáva.

Výnimka — orderflip: prostredníctvom funkcie orderflip môžu dáta objednávky slúžiť ako základ na prípravu konceptu faktúry (draft). Ide o samostatnú akciu používateľa, nie o automatické prevedenie predajnej objednávky na konečnú faktúru. Dodávateľ musí tento koncept faktúry sám dokončiť a predložiť ho ako konečný fakturačný dokument (UBL Invoice + InvoiceTypeCode).

Pozor: nezamáňajte rozpoznávanie typu dokumentu s rozpoznávaním referencii. Číslo predajnej objednávky, ktoré má byť rozpoznané na fakturu (ako OrderReference alebo order_reference), je referenčné pole, nie typ dokumentu. eConnect to číslo objednávky z faktury načíta a pripojí ho ako referenciu, bez zmeny typu dokumentu.

ZUGFeRD a Factur-X sú hybridné formáty faktúr: súbor PDF/A-3 s vloženou CII XML faktúrou. Pri týchto dokumentoch sa platforma najprv pokúsi extrahovať vloženú XML z PDF. Ak je XML platná, spracuje sa priamo, rovnako ako bežná XML faktúra. Iba ak sa vložená XML ukáže ako neplatná, systém prejde na OCR spracovanie cez IDR.

Faktúra ZUGFeRD, ktorá v externých validátoroch prejde, ale v eConnect sa spracuje cez OCR, poukazuje na problém s vloženou XML v procese validácie eConnect. V takom prípade kontaktujte podporu.

Technické: Staršia platforma dokáže ukladať výlučne platné UBL faktúry. Keď sa faktúra ZUGFeRD spracuje cez IDR ako PDF, výstup IDR sa musí najprv transformovať na platné UBL (BIS Billing V3 alebo NLCIUS). Ak táto transformácia zlyhá, pretože zdrojové údaje neobsahujú dostatočné polia pre platnú UBL faktúru, platforma faktúru nemôže uložiť. V PSB/Control to je menej problematické, pretože faktúry sa tam ukladajú v pôvodnom formáte a transformujú sa až pri doručení.

Ak odošlete XML súbor, ktorý nie je platný, systém automaticky prejde na priloženú PDF. Funguje to takto:

1. Platforma sa najprv pokúsi spracovať XML komponent.
2. Ak UBL nie je platné, priložený PDF sa vezme ako záloha.
3. PDF sa spracuje cez IDR trasu (OCR a rozpoznávanie vzorov).

Tento mechanizmus zabezpečuje, že faktúra sa vždy spracuje, aj keď XML obsahuje chyby. Je to však drahšia a pomalšia trasa ako priame XML spracovanie.

Ak je UBL odmietnutý (pretože nie je platný), eConnect naďalej spracuje ostatné prílohy z rovnakého e-mailu, napríklad PDF. Odosielateľ dostane e-mail s:

• oznámením, že faktúra UBL nebude spracovaná, vrátane chybového hlásenia;
• oznámením, že prípadné ďalšie prílohy v e-maili budú spracované.

Pozor: toto chybové hlásenie k XML faktúre nie je možné potlačiť, kým sú spracovávané iné prílohy v rovnakom e-maili.

Príklad -- BR-AE-10 (Prenos daňovej povinnosti): UBL s kategóriou DPH AE (Prenos daňovej povinnosti) bez BT-121 (kód dôvodu oslobodenia od DPH) alebo BT-120 (text dôvodu oslobodenia od DPH) aktivuje validačné pravidlo BR-AE-10. Pri kategórii AE musí byť prítomný aspoň jeden z týchto položiek. UBL je odmietnutý, priložené PDF sa spracuje cez IDR fallback a chybové hlásenie týkajúce sa UBL zostane viditeľné v e-maili odosielateľovi.

SI-UBL 1.2 (Simplerinvoicing 1.2) bol definitívne vyradený k 1. januáru 2024. Faktúry v tomto formáte sú v sieti Peppol odmietané. eConnect dokáže zastarané SI súbory, ktoré prichádzajú cez e-mail, niekedy ešte transformovať na platné NLCIUS, za predpokladu, že sú prítomné podstatné údaje. Pri chýbajúcich údajoch môže validácia zlyhať.

Pozor: Dostávate chybové hlásenia pri odosielaní faktúr? Skontrolujte, či Váš softvérový balík ešte negeneruje SI-UBL 1.2. Ak áno, požiadajte svojho dodávateľa o aktualizáciu na NLCIUS/SI-UBL 2.0 alebo BIS Billing V3.

Spracovanie sa mierne líši medzi staršou platformou a PSB/Control:

• Staršia platforma: faktúra sa vždy najprv transformuje na platné UBL (BIS Billing V3 alebo NLCIUS) pred uložením. Ak táto transformácia zlyhá, faktúra sa nemôže uložiť.
• PSB/Control: faktúra sa pri prijatí validuje a uloží. Transformácia sa vykoná až neskôr, keď je to potrebné, napríklad pri doručení do ERP systému. To znamená, že faktúra sa v PSB môže uložiť, ale neskôr sa môže vyskytnúť chyba transformácie, ak sa cieľový formát nedá vygenerovať.

eConnect spracúva polia UBL pri prijatí tak, ako boli doručené v zdrojovom UBL, a ich obsah nemení. Neexistuje žiadne zákazníkom konfigurovateľné mapovanie polí na strane príjemcu na prepísanie doručených hodnôt. Chýbajúce alebo nesprávne hodnoty musí opraviť odosielateľ v zdrojovom UBL. eConnect opravuje iba známe technické formátové chyby a dopĺňa nepodstatné voliteľné polia štandardnými hodnotami (pozri automatická oprava XML vyššie).

Konkrétny príklad pri prichádzajúcej intrakomunitárnej dobropise (polia doručenia):

Oba polia eConnect pri prijatí spracúva tak, ako boli doručené. BT-80 je povinné iba vtedy, keď faktúra obsahuje skupinu Deliver-to-address (BG-15). eConnect neposkytuje mapovanie na strane príjemcu na prepísanie BT-72 alebo BT-80. Opravy chýbajúcich alebo nesprávnych hodnôt vykoná odosielateľ v zdrojovom UBL.

Príklad -- miešanie domovej adresy a P.O. Boxu (PostalAddress) na zobrazení faktúry: adresa na zobrazení faktúry, ktorá zobrazuje zmiešané údaje domovej adresy a P.O. Boxu, nie je miešaním, ktoré vytvára eConnect pri prijatí. eConnect odovzdáva adresné polia UBL (cac:PostalAddress) 1:1 a adresy neprepisuje ani nenormalizuje. Ak zdrojové UBL mieša komponenty domovej adresy a P.O. Boxu v jednom bloku PostalAddress, zobrazenie sa riadi týmto zdrojom.

Typický vzor miešania v zdrojovom UBL:

• cbc:StreetName = ulica a číslo domu (domová adresa)
• cbc:AdditionalStreetName = PSČ domovej adresy, v nesprávnom poli
• cbc:BuildingName = P.O. Box N (kanonickým poľom pre P.O. Box v UBL je cbc:Postbox)
• cbc:PostalZone = PSČ P.O. Boxu

Zobrazenie faktúry potom často ukazuje riadok ulice spolu s PostalZone/CityName, čo vytvára vizuálne "zmiešanú adresu", bez toho aby eConnect polia kombinoval alebo opravoval. Obe adresné komponenty môžu byť samy o sebe správne, ale ich spojenie v zdieľanom adresnom bloku s prehodenými PSČ je chybou mapovania v zdrojovom UBL.

Akcia: otvorte zdrojové UBL a skontrolujte podriadené prvky PostalAddress príslušnej strany. Dodávateľ opraví mapovanie: buď konzistentnú domovú adresu (StreetName so zodpovedajúcim PostalZone), alebo P.O. Box v správnom poli pre P.O. Box (Postbox) so zodpovedajúcim PSČ -- nie obe naraz s prehodenými PSČ. Po oprave zdrojového UBL sa zobrazenie automaticky zosúladí.

Zákazková oprava prostredníctvom poradenstva (nie samoobsluha): eConnect môže na základe poradenstva nakonfigurovať RBE (rule/business engine) pre automatické opravy v toku. Ide o zákazkové riešenie prostredníctvom poradenstva eConnect, nie o funkciu, ktorú si zákazník konfiguruje sám. Neexistuje žiadne zákazníkom konfigurovateľné self-service prepisovanie doručených polí UBL na strane príjemcu.

Príklad -- kreditná faktúra „Payee/príjemca = vlastná organizácia": pri kredite verzus debete si AccountingSupplierParty a AccountingCustomerParty nevymieňajú miesta. Smer (na zaplatenie alebo na príjem) je v type dokumentu a znamienku PayableAmount, nie v obrátených stranách. eConnect neupravuje role strán a automaticky neaplikuje predchádzajúcu opravu Payee, ak je zdrojový UBL už správny -- rovnaký passthrough princíp ako vyššie. Spracované s príkladom: Varianty dobropisu.

Varianty vyhľadávania: "kreditná faktúra Payee", "kreditná faktúra Payee vlastná organizácia", "Supplier Customer zameniť kredit".

Chcete skontrolovať, či sa Váš XML súbor správne spracuje? Použite bezplatný eConnect Validátor na otestovanie faktúry vopred.