Porozumění EN16931: evropský datový model faktury

EN16931 je evropský standard definující, co musí elektronická faktura obsahovat. Není to formát XML. Je to sémantický datový model. Každý hlavní evropský formát elektronické fakturace, ať už Peppol BIS Billing 3.0, Factur-X, ZUGFeRD nebo XRechnung, je implementací EN16931 v konkrétní syntaxi XML.

Pochopení EN16931 šetří čas při ladění validačních selhání, vysvětlování integračních požadavků dodavatelům ERP nebo implementaci nového profilu faktury od nuly.

Co EN16931 ve skutečnosti specifikuje

EN16931 se skládá ze dvou částí:

EN 16931-1 definuje sémantický datový model: jaké datové elementy faktura může obsahovat, které jsou povinné a jaká jsou obchodní pravidla
EN 16931-2 definuje vázání syntaxe: jak se sémantický model mapuje na UBL 2.1 XML a UN/CEFACT CII XML

Výsledkem je, že faktura UBL Peppol BIS Billing 3.0 a faktura CII Factur-X mohou reprezentovat tutéž obchodní fakturu. Sémantický obsah je identický. Syntaxe XML je zcela odlišná.

Obchodní termíny a obchodní skupiny

EN16931 organizuje data faktury do obchodních skupin (BG) a obchodních termínů (BT).

Obchodní skupina je sbírka příbuzných termínů. Obchodní termín je jediný datový element s definovaným identifikátorem, názvem, kardinalitou a datovým typem.

Nejdůležitější skupiny na nejvyšší úrovni:

Skupina	Obsah
BG-2 Řízení procesu	Identifikátor specifikace (BT-24), typ obchodního procesu (BT-23)
BG-4 Prodávající	Název, adresa, číslo DPH, právní registrace
BG-7 Kupující	Název, adresa, referenční identifikátor, elektronická adresa
BG-22 Celkové hodnoty dokumentu	Základ daně, celková faktura, výše DPH, splatná částka
BG-25 Řádek faktury	Množství, jednotková cena, sazba DPH, čistá částka řádku

Úplný model obsahuje přes 150 BT ve všech skupinách. Většina implementací potřebuje pouze podmnožinu, ale validace dokumentu vyžaduje znát, které BT jsou pro cílový profil povinné.

Obchodní termíny, na které vývojáři narážejí

Většina validačních selhání pochází z malé sady BT, které jsou buď špatně pochopeny nebo špatně zdokumentovány v implementačních příručkách.

BT-24: Identifikátor specifikace

Musí to být specifické URI identifikující, kterému profilu faktura tvrdí, že odpovídá. Pro Peppol BIS Billing 3.0:

urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1

Chyba v tomto poli způsobí, že validátor příjemce fakturu odmítne dříve, než zkontroluje jakékoli obsahové pole. Každý profil (základní EN16931, Peppol BIS 3.0, Peppol BIS 3.0 s národním rozšířením) má jiné URI.

BT-10: Reference kupujícího

Používá se různě napříč zeměmi. V Německu nese Leitweg-ID, povinný směrovací identifikátor pro B2G faktury. Ve většině ostatních zemí jde o interní referenci objednávky nebo je pole prázdné. Pole je volitelné v základu EN16931, ale povinné v německém národním profilu.

BT-49: Elektronická adresa kupujícího

Identifikátor účastníka Peppol kupujícího. Formát: schéma:identifikátor. Pro belgickou společnost identifikovanou číslem podniku:

<cbc:EndpointID schemeID="0208">0468863455</cbc:EndpointID>

Povinné při přenosu přes síť Peppol. Mnoho implementací ho pro B2B faktury mimo Peppol vynechává, což je v základním EN16931 přijatelné, ale v profilech Peppol BIS neplatné.

BT-131: Čistá částka řádku faktury

Čistá částka pro jeden řádek, vypočítaná jako množství krát jednotková cena minus jakékoli slevy na úrovni řádku. Obchodní pravidlo EN16931 BR-CO-10 vyžaduje, aby součet všech hodnot BT-131 rovnal se BT-106 (součet čistých částek řádků faktury).

Na zaokrouhlování záleží. Standard očekává, že aritmetika se provede na surových hodnotách a zaokrouhlí se na úrovni agregátu, nikoli po řádcích. Zaokrouhlení každého řádku nezávisle a poté sečtení produkuje nesrovnalosti, které selžou BR-CO-10 pro velká množství.

BT-110: Daňová částka kategorie DPH

Výše DPH pro daňovou kategorii. Pravidlo EN16931 BR-CO-15 vyžaduje, aby celková faktura minus základ daně rovnala součtu všech BT-117 (výše DPH pro daňové kategorie). Chyby zde jsou často způsobeny aritmetikou s plovoucí desetinnou čárkou nebo předčasným zaokrouhlením.

Obchodní pravidla: validační vrstva

Obchodní pravidla (BR) jsou formální omezení vyjádřená v Schematron. Existují dvě kategorie.

Strukturální pravidla vynucují přítomnost a formát polí:

BR-01: An Invoice shall have a Specification identifier (BT-24).
BR-02: An Invoice shall have an Invoice number (BT-1).
BR-04: An Invoice shall have an Invoice currency code (BT-5).

Výpočetní pravidla vynucují aritmetickou konzistenci:

BR-CO-10: Sum of Invoice line net amount (BT-106) = sum of all BT-131 values.
BR-CO-15: Invoice total VAT amount (BT-110) = sum of all BT-117 values.
BR-CO-16: Amount due for payment (BT-115) = Invoice total with VAT (BT-112)
          - Paid amount (BT-113) + Rounding amount (BT-114).

Peppol BIS 3.0 přidává pravidla národního rozšíření nad rámec základních pravidel EN16931. Příklady:

BR-DE-TMP-32: Delivery date (BT-72) is required for German B2G invoices.
BR-DE-18:     VAT identifier of the seller (BT-31) or tax registration (BT-32)
              shall be present.

Tato pravidla rozšíření se liší podle profilu země a jsou publikována s každým vydáním Peppol BIS.

Jak se EN16931 mapuje na UBL a CII

Obě syntaxe XML zpracovávají stejné BT, ale používají zcela různé názvy elementů a struktury. Proto kód parsující UBL faktury nemůže parsovat CII faktury bez oddělené implementace, přestože obojí je kompatibilní s EN16931.

Název prodávajícího (BT-27) v obou syntaxích:

UBL 2.1:

<cac:AccountingSupplierParty>
  <cac:Party>
    <cac:PartyName>
      <cbc:Name>Acme GmbH</cbc:Name>
    </cac:PartyName>
  </cac:Party>
</cac:AccountingSupplierParty>

UN/CEFACT CII:

<ram:SellerTradeParty>
  <ram:Name>Acme GmbH</ram:Name>
</ram:SellerTradeParty>

Obojí mapuje na BT-27. Sémantický obsah je identický. Cesta XML se zcela liší.

Peppol BIS 3.0 používá UBL. Factur-X a ZUGFeRD používají CII. XRechnung podporuje obojí. Mapovací dokument EN16931-2 (zdarma od CEN/TC 434) uvádí obě cesty pro každý BT a stojí za to ho mít otevřený při implementaci.

Schematron validace

Validace EN16931 je implementována jako pravidla Schematron předkompilovaná do XSLT 2.0. Oficiální sady pravidel jsou publikovány s každým vydáním Peppol BIS:

github.com/OpenPEPPOL/peppol-bis-invoice-3/releases

Artefakty obsahují zkompilované soubory XSLT:

peppol-en16931-ubl.xsl    (for UBL invoices)
peppol-en16931-cii.xsl    (for CII invoices)

Spuštění obou vůči faktuře vrátí SVRL (Schematron Validation Report Language). Selhané pravidlo vypadá takto:

<svrl:failed-assert test="..." location="/Invoice/...">
  <svrl:text>
    [BR-CO-10]-Sum of Invoice line net amount (BT-106) = 
    sum of Invoice line net amount (BT-131).
  </svrl:text>
</svrl:failed-assert>

Je vyžadován procesor XSLT 2.0. V .NET je Saxon HE (open source, bez enterprise licence) standardní volbou. V Javě fungují Saxon nebo Xerces.

Časté implementační chyby

Míchání cest elementů UBL a CII. Vývojáři pracující s oběma formáty vkládají názvy elementů ze špatného vázání. Tomuto zabraňuje mapovací dokument EN16931-2.

Předpoklad, že pravidla přítomnosti jsou stejná napříč profily. Pole, které je volitelné v základním EN16931, může být povinné v Peppol BIS 3.0 nebo v národním rozšíření. Validujte vůči cílovému profilu, nikoli základnímu standardu.

Zaokrouhlování na špatné úrovni. Počítejte surové aritmetické součty přes všechny řádky, pak zaokrouhlete agregát. Zaokrouhlení každého řádku nezávisle a sečtení zaokrouhlených hodnot produkuje aritmetické nesrovnalosti, které selžou BR-CO-10, často o pár centů na velkých fakturách s mnoha řádky.

Špatný BT-24 pro cílový profil. Každý profil má specifické URI identifikátoru specifikace. Použití základního URI EN16931 na faktuře Peppol BIS 3.0 způsobí, že validace na úrovni profilu dokument okamžitě odmítne.

Hardcoding kódů kategorií DPH. EN16931 definuje specifické hodnoty kódů pro kategorie DPH (S, Z, E, AE, K, G, O, L, M). Mnoho implementací hardcodeuje “S” (standardní sazba) a selže při zpracování faktur s přenesenou daňovou povinností nebo nulovou sazbou.

EN16931 je znalost infrastruktury

EN16931 stojí za každým mandátem elektronické fakturace v Evropě. Jak se požadavky zavádějí v Belgii, Francii, Německu a Polsku, pochopení sémantického modelu se stává stále důležitějším pro vývojáře budující nebo udržující fakturační pipelines.

Pochopení struktury BT/BG, výpočetních pravidel a vázání syntaxe vás staví do pozice, kde dokážete ladit validační selhání, která by jinak vyžadovala hodiny čtení specifikace, čistě implementovat nové profily a jasně komunikovat s dodavateli ERP a týmy pro shodu.

Praktický problém není naučit se EN16931 jednou. Jde o udržování implementací správných při aktualizaci sad pravidel s každým vydáním Peppol BIS, při přidávání nových povinných polí národními rozšířeními a při vynořování se okrajových případů zaokrouhlování v produkci s reálnými fakturačními daty z reálných ERP systémů.

SealDoc je dodáván se sadami pravidel sledujícími vydání Peppol BIS. Při generování faktury prostřednictvím API SealDoc je dokument validován vůči správnému profilu dříve, než opustí systém. BR-CO-10 a BR-CO-15 jsou vynucovány na straně serveru, takže chyby zaokrouhlování nedorazí k vašim kupujícím. Když obdržíte validační selhání od obchodního partnera, veřejný validátor SealDoc přijme dokument a namapuje každé selhání zpět na konkrétní BT a BR, které bylo porušeno, čímž zkrátí dobu diagnózy z hodin na minuty.

Pokud implementujete EN16931 od nuly, validátor je užitečný kalibrační nástroj: vygenerujte kandidátní dokument, spusťte ho přes validátor, opravte, co zpráva identifikuje, opakujte.