Když odešlete fakturu do eConnect, dokument projde řadou zpracovatelských kroků. Jak přesně zpracování probíhá, závisí na typu souboru (XML nebo PDF) a kvalitě dodaného souboru. Tento článek vysvětluje, co se děje v zákulisí.

eConnect zná dvě zásadně odlišné zpracovatelské trasy:

XML zpracování (přímá trasa): pokud odešlete platnou UBL fakturu (SI-UBL 2.0, Peppol BIS Billing 3.0 nebo jiný podporovaný XML formát), tato se zpracuje přímo. Platforma přečte strukturované údaje z XML, validuje je a směruje dokument k příjemci. Toto je nejrychlejší a nejspolehlivější trasa.

PDF zpracování (konverze přes IDR): pokud odešlete PDF fakturu, tato se zpracuje prostřednictvím Intelligent Document Recogniser (IDR). IDR extrahuje údaje faktury přes OCR a rozpoznávání vzorů a vytvoří UBL fakturu na základě rozpoznaných údajů. Tento proces je inherentně méně spolehlivý než přímé XML zpracování, protože závisí na kvalitě PDF.

Tip: Dodání UBL má vždy přednost před PDF. Je to rychlejší, levnější a spolehlivější. Zeptejte se svého dodavatele nebo softwarového balíku, zda je dostupný UBL export.

Při odeslání XML souboru eConnect provede následující kroky:

Platforma automaticky rozpozná, jaký formát soubor sleduje, na základě CustomizationID a XML schématu. Podporované formáty zahrnují mimo jiné NLCIUS, BIS Billing V3, XRechnung, CII a Factur-X.

Faktura se validuje vůči pravidlům rozpoznaného profilu. To zahrnuje:

• Validace schématu: odpovídá XML struktuře schématu UBL 2.1 nebo CII?
• Obchodní pravidla: sedí výpočty? Jsou povinná pole vyplněna? Odpovídají hodnoty číselníků?
• Pravidla specifická pro zemi: jsou dodržena správná NL-R-, DK-R- nebo jiná pravidla pro země?

Tip: Dostáváte hlášení, že nebyly nalezeny "žádná validační pravidla"? Obvykle to znamená, že CustomizationID ve Vašem XML chybí nebo není rozpoznán. Bez rozpoznatelného profilu nemůže validátor aplikovat obchodní pravidla. Ověřte, zda Vaše faktura obsahuje platný CustomizationID, například NLCIUS nebo BIS Billing V3.

Nápadnou vlastností zpracování eConnect je automatická oprava XML souborů. Prostřednictvím XSL transformací se opravují známé chyby. Platforma v principu akceptuje každé UBL; chybějící nepodstatná pole se vyplní standardními hodnotami. Tato opravná funkce se průběžně vyvíjí na základě zpětné vazby od zákazníků a je produkčně připravená.

Příklady automatických oprav:

• Chybějící volitelná pole se doplní správnými standardními hodnotami
• Známé chyby formátu v polích identifikátorů se opraví
• Nekompletní kontaktní údaje se doplní (pokud je pole ElectronicMail dodavatele prázdné, eConnect automaticky vyplní support@econnect.eu, aby odmítnuté faktury byly doručeny odesílateli)

Pokud příjemce podporuje jiný formát než zdrojový formát, PSB automaticky transformuje dokument. Faktura NLCIUS se může například transformovat na XRechnung, pokud je příjemce německý orgán veřejného sektoru. To je možné díky tomu, že všechny podporované formáty jsou založeny na stejném sémantickém modelu (EN 16931).

Technické: Při stahování faktury přes API můžete parametrem targetDocumentTypeId zadat požadovaný formát přijetí. PSB pak dokument transformuje do tohoto formátu.

eConnect nikdy nerozpoznává prodejní objednávku (dokument objednávky) jako fakturu a automaticky ji na fakturu neprevodí. Pokud odešlete prodejní objednávku tam, kde se očekává faktura, dokument bude odmítnut.

Dodavatel musí sám dodat správný fakturační dokument: UBL Invoice se správným InvoiceTypeCode. eConnect zdrojový dokument nemění a tuto konverzi neprovádí.

Výjimka — orderflip: prostřednictvím funkce orderflip mohou data objednávky sloužit jako základ pro přípravu konceptu faktury (draft). Jde o samostatnou akci uživatele, nikoli o automatické převedení prodejní objednávky na konečnou fakturu. Dodavatel musí tento koncept faktury sám dokončit a předložit jej jako konečný fakturační dokument (UBL Invoice + InvoiceTypeCode).

Pozor: nezaměňujte rozpoznávání typu dokumentu s rozpoznáváním referencí. Číslo prodejní objednávky, které má být rozpoznáno na faktuře (jako OrderReference nebo order_reference), je referenční pole, nikoliv typ dokumentu. eConnect to číslo objednávky z faktury načte a připojí ho jako referenci, aniž by tím měnil typ dokumentu.

ZUGFeRD a Factur-X jsou hybridní formáty faktur: soubor PDF/A-3 s vloženou CII XML fakturou. U těchto dokumentů se platforma nejprve pokusí extrahovat vloženou XML z PDF. Pokud je XML platná, zpracuje se přímo, stejně jako běžná XML faktura. Pouze pokud se vložená XML ukáže jako neplatná, systém přejde na OCR zpracování přes IDR.

Faktura ZUGFeRD, která v externích validátorech projde, ale v eConnect se zpracuje přes OCR, poukazuje na problém s vloženou XML v procesu validace eConnect. V takovém případě kontaktujte podporu.

Technické: Starší platforma dokáže ukládat výhradně platné UBL faktury. Když se faktura ZUGFeRD zpracuje přes IDR jako PDF, výstup IDR se musí nejprve transformovat na platné UBL (BIS Billing V3 nebo NLCIUS). Pokud tato transformace selže, protože zdrojové údaje neobsahují dostatečná pole pro platnou UBL fakturu, platforma fakturu nemůže uložit. V PSB/Control to je méně problematické, protože faktury se tam ukládají v původním formátu a transformují se až při doručení.

Pokud odešlete XML soubor, který není platný, systém automaticky přejde na přiložené PDF. Funguje to takto:

1. Platforma se nejprve pokusí zpracovat XML komponent.
2. Pokud UBL není platné, přiložené PDF se vezme jako záloha.
3. PDF se zpracuje přes IDR trasu (OCR a rozpoznávání vzorů).

Tento mechanismus zajišťuje, že faktura se vždy zpracuje, i když XML obsahuje chyby. Je to však dražší a pomalejší trasa než přímé XML zpracování.

Pokud je UBL odmítnut (protože není platný), eConnect přesto zpracuje ostatní přílohy ze stejného e-mailu, například PDF. Odesílatel obdrží e-mail s:

• oznámením, že faktura UBL nebude zpracována, včetně chybové zprávy;
• oznámením, že případné další přílohy v e-mailu budou zpracovány.

Pozor: tuto chybovou zprávu k XML faktuře nelze potlačit, dokud jsou zpracovávány jiné přílohy ve stejném e-mailu.

Příklad -- BR-AE-10 (Přenos daňové povinnosti): UBL s kategorii DPH AE (Přenos daňové povinnosti) bez BT-121 (kód důvodu osvobození od DPH) nebo BT-120 (text důvodu osvobození od DPH) aktivuje validační pravidlo BR-AE-10. Při kategorii AE musí být přítomno alespoň jedno z těchto polí. UBL je odmítnut, přiložené PDF je zpracováno přes IDR fallback a chybová zpráva týkající se UBL zůstává viditelná v e-mailu odesílateli.

SI-UBL 1.2 (Simplerinvoicing 1.2) byl definitivně vyřazen k 1. lednu 2024. Faktury v tomto formátu jsou v síti Peppol odmítány. eConnect dokáže zastaralé SI soubory, které přicházejí přes e-mail, někdy ještě transformovat na platné NLCIUS, za předpokladu, že jsou přítomny podstatné údaje. Při chybějících údajích může validace selhat.

Pozor: Dostáváte chybová hlášení při odesílání faktur? Zkontrolujte, zda Váš softwarový balík ještě negeneruje SI-UBL 1.2. Pokud ano, požádejte svého dodavatele o aktualizaci na NLCIUS/SI-UBL 2.0 nebo BIS Billing V3.

Zpracování se mírně liší mezi starší platformou a PSB/Control:

• Starší platforma: faktura se vždy nejprve transformuje na platné UBL (BIS Billing V3 nebo NLCIUS) před uložením. Pokud tato transformace selže, faktura se nemůže uložit.
• PSB/Control: faktura se při přijetí validuje a uloží. Transformace se provede až později, když je to potřeba, například při doručení do ERP systému. To znamená, že faktura se v PSB může uložit, ale později se může vyskytnout chyba transformace, pokud se cílový formát nedá vygenerovat.

eConnect zpracovává pole UBL při přijetí tak, jak jsou odeslána ve zdrojovém UBL, a nijak je nemění. Neexistuje žádné zákazníkem konfigurovatelné mapování polí na straně příjemce pro přepisování odeslaných hodnot. Chybějící nebo nesprávné hodnoty musí opravit odesílatel ve zdrojovém UBL. eConnect opravuje pouze známé technické chyby formátu a doplňuje nepodstatná volitelná pole výchozími hodnotami (viz automatická oprava XML výše).

Konkrétní příklad s příchozí intrakomunitární dobropisy (pole doručení):

Obě pole eConnect při přijetí zpracuje tak, jak byla odeslána. BT-80 je povinné pouze tehdy, pokud faktura obsahuje skupinu Deliver-to-address (BG-15). eConnect neposkytuje mapování na straně příjemce pro přepisování BT-72 nebo BT-80. Opravy chybějících nebo nesprávných hodnot provádí odesílatel ve zdrojovém UBL.

Příklad -- míchání domovní adresy a P.O. Boxu (PostalAddress) na zobrazení faktury: adresa na zobrazení faktury, která zobrazuje smíšené údaje domovní adresy a P.O. Boxu, není mísením, které vytváří eConnect při přijetí. eConnect předává adresní pole UBL (cac:PostalAddress) 1:1 a adresy nepřepisuje ani nenormalizuje. Pokud zdrojové UBL míchá komponenty domovní adresy a P.O. Boxu v jednom bloku PostalAddress, zobrazení se řídí tímto zdrojem.

Typický vzor míchání ve zdrojovém UBL:

• cbc:StreetName = ulice a číslo domu (domovní adresa)
• cbc:AdditionalStreetName = PSČ domovní adresy, v nesprávném poli
• cbc:BuildingName = P.O. Box N (kanonickým polem pro P.O. Box v UBL je cbc:Postbox)
• cbc:PostalZone = PSČ P.O. Boxu

Zobrazení faktury pak často ukazuje řádek ulice společně s PostalZone/CityName, což vytváří vizuálně "smíchanou adresu", aniž by eConnect pole kombinoval nebo opravoval. Obě adresní komponenty mohou být samy o sobě správné, ale jejich spojení ve sdíleném adresním bloku s prohozenými PSČ je chybou mapování ve zdrojovém UBL.

Akce: otevřete zdrojové UBL a zkontrolujte podřízené prvky PostalAddress příslušné strany. Dodavatel opraví mapování: buď konzistentní domovní adresu (StreetName s odpovídajícím PostalZone), nebo P.O. Box ve správném poli pro P.O. Box (Postbox) s odpovídajícím PSČ -- ne obojí prohozeně. Po opravě zdrojového UBL se zobrazení automaticky srovná.

Zakázková oprava prostřednictvím poradenství (ne samoobsluha): eConnect může prostřednictvím poradenských služeb nakonfigurovat RBE (rule/business engine) pro automatické opravy v toku. Jedná se o zakázkovou práci prostřednictvím poradenství eConnect, nikoli o funkci, kterou si zákazník konfiguruje sám. Neexistuje zákazníkem konfigurovatelné samoobslužné přepisování polí UBL na straně příjemce.

Příklad -- kreditní faktura „Payee/příjemce = vlastní organizace": při kreditu versus debetu si AccountingSupplierParty a AccountingCustomerParty nevyměňují místa. Směr (k zaplacení nebo k příjmu) je v typu dokumentu a znaménku PayableAmount, nikoli v obrácených stranách. eConnect neupravuje role stran a automaticky znovu neaplikuje předchozí opravu Payee, pokud je zdrojový UBL již správný -- stejný passthrough princip jako výše. Zpracováno s příkladem: Varianty dobropisu.

Varianty vyhledávání: "kreditní faktura Payee", "kreditní faktura Payee vlastní organizace", "Supplier Customer vyměnit kredit".

Chcete zkontrolovat, zda se Váš XML soubor správně zpracuje? Použijte bezplatný eConnect Validátor k otestování faktury předem.

• Struktura UBL faktury
• Jaký je rozdíl mezi XML, UBL, BIS Billing V3 a NLCIUS?
• Důležitá pole pro odesílání v UBL
• SEEF: standard pro energetické faktury
• Stáhnout vzorové XML soubory
• Od sémantiky k syntaxi