UBL vs CII: kterou syntaxi XML faktury zvolit?
Dvě syntaxe XML mohou reprezentovat elektronickou fakturu kompatibilní s EN16931: UBL 2.1 a UN/CEFACT Cross Industry Invoice (CII). Obojí je správné. Obojí je přijímáno EN16931. A obojí se strukturálně natolik liší, že kód napsaný pro jednu nemůže parsovat druhou bez oddělené implementace.
Pokud v Evropě budujete fakturační pipeline v roce 2026, pravděpodobně narazíte na obojí. Zde je, co potřebujete vědět, abyste zvolili správnou syntaxi a zvládli tu druhou.
Co mají společného
Obě syntaxe UBL i CII jsou serializace téhož sémantického modelu: EN16931. Název prodávajícího je název prodávajícího. Výše DPH je výše DPH. Obchodní termíny (BT) a obchodní skupiny (BG) jsou identické v obou syntaxích.
EN 16931-2 definuje oficiální mapování z každého BT na jeho cestu XML v obou syntaxích. Dokument je zdarma od CEN/TC 434 a je autoritativní referencí, pokud potřebujete implementovat obojí.
Oba formáty jsou založeny na mezinárodních standardech a přijímány validátory EN16931. Oba produkují strojově čitelné strukturované faktury.
Jak se strukturálně liší
Rozdíly jsou výrazné a prostupují celý formát. Názvy elementů, prefixy jmenných prostorů, struktury vnoření a konvence atributů jsou všechny odlišné.
Název prodávajícího (BT-27)
UBL 2.1:
<cac:AccountingSupplierParty>
<cac:Party>
<cac:PartyName>
<cbc:Name>Acme GmbH</cbc:Name>
</cac:PartyName>
</cac:Party>
</cac:AccountingSupplierParty>
CII:
<rsm:SupplyChainTradeTransaction>
<ram:SellerTradeParty>
<ram:Name>Acme GmbH</ram:Name>
</ram:SellerTradeParty>
</rsm:SupplyChainTradeTransaction>
UBL používá hluboké vnoření s jmennými prostory agregátní (cac:) a základní (cbc:) komponenty. CII je plošší, s jmennými prostory ram: (Reusable Aggregate Module) a rsm: (Reusable Schema Module).
Částka řádku faktury (BT-131)
UBL 2.1:
<cac:InvoiceLine>
<cbc:LineExtensionAmount currencyID="EUR">250.00</cbc:LineExtensionAmount>
</cac:InvoiceLine>
CII:
<ram:IncludedSupplyChainTradeLineItem>
<ram:SpecifiedLineTradeSettlement>
<ram:SpecifiedTradeSettlementLineMonetarySummation>
<ram:LineTotalAmount>250.00</ram:LineTotalAmount>
</ram:SpecifiedTradeSettlementLineMonetarySummation>
</ram:SpecifiedLineTradeSettlement>
</ram:IncludedSupplyChainTradeLineItem>
Kódy měn v CII jsou v některých místech atributy elementů a jinde chybí (s měnou deklarovanou na úrovni záhlaví). UBL je konzistentnější: currencyID se objevuje na každém elementu peněžní hodnoty.
Kořenový element a jmenné prostory
UBL 2.1 používá tři jmenné prostory:
<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
CII používá tři odlišné jmenné prostory:
<rsm:CrossIndustryInvoice
xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100"
xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100"
xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100">
Mezi oběma sadami jmenných prostorů není žádný překryv. Parser cílující na jeden formát nemůže zpracovat druhý.
Který formát je kde nařizován
Volba je zřídka na vás. Formát určuje cílová země, doručovací kanál a rámec shody.
| Formát | Nařizuje |
|---|---|
| UBL 2.1 | Peppol BIS Billing 3.0 (přenos po síti) |
| CII | Factur-X, ZUGFeRD, XRechnung (přijímá CII i UBL) |
| CII nebo UBL | Francie (Portail Public de Facturation: přijímá obojí) |
Peppol BIS Billing 3.0 je pouze UBL. Pokud přenášíte přes síť Peppol, musíte produkovat UBL.
Factur-X a ZUGFeRD jsou CII. Příloha factur-x.xml uvnitř PDF/A-3 je vždy CII.
XRechnung přijímá CII i UBL, ale CII (CrossIndustryInvoice) je běžněji testováno validátory německých vládních portálů.
Konverze mezi formáty
Mezi UBL a CII neexistuje bezztrátová automatická konverze. Sémantický obsah je identický, ale:
- Některá pole mapují na atributy v jednom formátu a na elementy v druhém
- Hloubka vnoření se liší, což ovlivňuje způsob čtení sekvenčních položek jako řádky faktury
- Umístění kódů měn se liší mezi formáty (některé implementace CII předpokládají, že měna záhlaví platí pro všechny řádky)
- Formáty dat se liší: UBL používá
YYYY-MM-DD, CII používáYYYYMMDDs atributemformat="102"
Konverze je možná, ale vyžaduje dedikovanou mapovací vrstvu. Běžně se používá XSLT; komunita OpenPEPPOL poskytuje referenční mapování.
Výkonnost a nástroje
UBL je šířeji podporován v knihovnách .NET a Java. OASIS UBL existuje od roku 2006 a většina podnikových XML nástrojů pro něj má explicitní podporu.
CII je méně obvyklý v evropských vývojářských nástrojích mimo Francii a Německo. Knihovny parserů existují, ale bývají specializovanější.
Saxon HE zpracovává Schematron validaci pro obojí. Předkompilované soubory XSLT z vydání Peppol BIS na GitHubu zahrnují oddělené soubory XSLT:
peppol-en16931-ubl.xsl (for UBL invoices)
peppol-en16931-cii.xsl (for CII invoices)
Každý spusťte vůči příslušnému vstupnímu formátu.
Který implementovat jako první
Pro většinu vývojářů zahájení nové evropské fakturační integrace v roce 2026 je UBL lepším výchozím bodem:
- Přenos přes síť Peppol vyžaduje UBL
- Většina zemí EU přijímá UBL na národních portálech
- Nástroje .NET a Java jsou zralejší
- Specifikace UBL je konzistentnější ve umístění atributů
Pokud působíte konkrétně ve Francii nebo Německu, CII se stává nezbytným pro Factur-X a ZUGFeRD. Jde o druhou implementační vrstvu, nikoli náhradu.
Pro archivní účely je PDF/A-3 s vloženým CII standardem. Většina pipelines, které přenáší Peppol UBL po síti, také generuje CII PDF Factur-X pro archiv kupujícího. Obojí slouží různým funkcím a koexistují.
Poznámka k validaci
Bez ohledu na to, kterou syntaxi použijete, validujte vůči schematron pravidlům správného profilu. Faktura, která je platná UBL, může selhat pravidla Peppol BIS 3.0, pokud jí chybí povinné elementy specifické pro Peppol. Faktura, která je platná CII, může selhat profil EN 16931 Factur-X, pokud chybí volitelná pole, která tento profil vyžaduje.
Hlubší problém je ten, že většina pipelines potřebuje obojí. Doručení přes Peppol vyžaduje UBL. Archiv kupujícího vyžaduje PDF Factur-X s vloženým CII. Udržování dvou nezávislých generačních cest XML, dvou validačních průchodů a dvou sad souborů schematron pravidel zdvojuje plochu pro chyby správnosti.
SealDoc generuje obojí ze stejného vstupu. Jediné volání API s vašimi fakturačními daty produkuje dokument UBL pro přenos Peppol a PDF/A-3 s vloženým CII pro archiv kupujícího. Schematron validace běží vůči oběma výstupům dříve, než je kterýkoli vrácen. Nemusíte udržovat ani jednu cestu generování XML ani sledovat vydání Peppol BIS.
Pro kontrolu existujících souborů veřejný validátor SealDoc přijímá UBL i CII a hlásí selhání podle čísla BT a kódu obchodního pravidla. Užitečné pro diagnostiku dokumentů obdržených od obchodních partnerů nebo pro kalibraci exportu faktur třetí strany vůči požadavkům EN16931.