info-efaktura logoinfo-efaktura

E-faktúra pre vývojárov – EN 16931, UBL a Peppol BIS

Technický sprievodca elektronickou fakturáciou pre softvérové firmy: sémantický model EN 16931, syntax UBL 2.1, Peppol BIS Billing 3.0, slovenské CIUS pravidlá, validácia a integrácia s doručovacou službou.

Snímka 1 z 14

Krátky prehľad toho, ako vznikla norma EN 16931

Vo svete výmeny elektronických dokumentov vznikli dva významné štandardy s cieľom zjednotiť význam, štruktúru a pravidlá obchodných dokumentov. Stali sa nimi Universal Business Language (UBL) od OASIS a Cross Industry Invoice (CII) od UN/CEFACT. Problém implementácie kompletného štandardu UBL spočíva v tom, že síce vytvorenie platného dokumentu je viac-menej jednoduché, problémom je jeho spracovanie na strane prijímateľa. Prijímateľ na to, aby zabezpečil správne, automatické a presné spracovanie musí pripraviť automatizáciu pre každý jeden, aj ten posledný nepovinný element dokumentu. A to je problém, ktorý sa čiastočne vyriešil takzvanými customizáciami. Customisation je element v XML, ktorý definuje, že toto XML používa iba podmnožinu vybraných elementov alebo špecifické požiadavky či pravidlá na obsah elementov, a tým pádom zjednodušuje rozsah potrebného vývoja spracovania dokumentu prijímateľom. Ďalším problémom je, že vzniklo veľké množstvo takýchto customizácií, čo spôsobuje fragmentáciu a tým sa znižuje úžitok zo štandardizácie. Jedného dňa na úrovni EÚ vznikla iniciatíva, aby aspoň na úrovni faktúr, ktoré sa vymieňajú medzi podnikmi a štátom, bola používaná iba jedna jediná norma pre faktúru, a tak sa zrodila EN 16931. Norma popisuje význam elementov, ich kardinalitu a pravidlá či obmedzenia obsahu elementov, ktoré musia byť dodržané. EN 16931 povoľuje využitie syntaxe nielen modelu UBL, ale aj CII a EDIFACT.

Kľúčové body:

Zobraziť celý text sprievodcu (na prečítanie alebo tlač)

1.Krátky prehľad toho, ako vznikla norma EN 16931

Vo svete výmeny elektronických dokumentov vznikli dva významné štandardy s cieľom zjednotiť význam, štruktúru a pravidlá obchodných dokumentov. Stali sa nimi Universal Business Language (UBL) od OASIS a Cross Industry Invoice (CII) od UN/CEFACT. Problém implementácie kompletného štandardu UBL spočíva v tom, že síce vytvorenie platného dokumentu je viac-menej jednoduché, problémom je jeho spracovanie na strane prijímateľa. Prijímateľ na to, aby zabezpečil správne, automatické a presné spracovanie musí pripraviť automatizáciu pre každý jeden, aj ten posledný nepovinný element dokumentu. A to je problém, ktorý sa čiastočne vyriešil takzvanými customizáciami. Customisation je element v XML, ktorý definuje, že toto XML používa iba podmnožinu vybraných elementov alebo špecifické požiadavky či pravidlá na obsah elementov, a tým pádom zjednodušuje rozsah potrebného vývoja spracovania dokumentu prijímateľom. Ďalším problémom je, že vzniklo veľké množstvo takýchto customizácií, čo spôsobuje fragmentáciu a tým sa znižuje úžitok zo štandardizácie. Jedného dňa na úrovni EÚ vznikla iniciatíva, aby aspoň na úrovni faktúr, ktoré sa vymieňajú medzi podnikmi a štátom, bola používaná iba jedna jediná norma pre faktúru, a tak sa zrodila EN 16931. Norma popisuje význam elementov, ich kardinalitu a pravidlá či obmedzenia obsahu elementov, ktoré musia byť dodržané. EN 16931 povoľuje využitie syntaxe nielen modelu UBL, ale aj CII a EDIFACT.

2.EN 16931 - Ako čítať sémantický model

Sémantický alebo inak povedané významový model obsahuje označenie elementov faktúry: • BT (Business Term) - jednotlivé dátové elementy • BG (Business Group) - skupiny súvisiacich elementov Model definuje ich význam, kardinalitu (t. j. ako často sa musia alebo môžu objaviť v štruktúre faktúry), ďalšie pravidlá a reštrikcie a ako majú byť dáta v elementoch spracované a aký majú vzťah k obchodnému procesu.

  • BT = Business Term (jednotlivý dátový element)
  • BG = Business Group (skupina elementov)
  • Kardinalita určuje povinnosť a počet výskytov
  • Model definuje význam a vzťahy medzi elementmi
  • Obsahuje validačné pravidlá a reštrikcie

3.EN 16931 - Kardinalita elementov

Ako často sa musia alebo môžu objaviť elementy vo faktúre. DÔLEŽITÉ: Pravidlo kardinality elementu platí iba vo vnútri svojho rodičovského elementu.

  • 0..1 = Nepovinný element, môže sa objaviť iba raz
  • 1..1 = Povinný element, môže sa objaviť iba raz
  • 0..n = Nepovinný element, môže sa objaviť niekoľkokrát
  • 1..n = Povinný element, môže sa objaviť niekoľkokrát
  • 1..2 = Povinný element, môže sa objaviť iba dvakrát
  • Kardinalita platí len v rámci rodičovského elementu

4.EN 16931 - Mapovanie syntaxe

Namapovanie business terms na názvy elementov podľa UBL, CII či EDIFACT. DÔLEŽITÉ: Syntax tiež určuje poradie elementov, v akom majú byť usporiadané vo faktúre.

  • Mapovanie prevádza business terms na konkrétnu syntax
  • UBL, CII a EDIFACT majú odlišné mapovania
  • Syntax definuje aj poradie elementov
  • Správne poradie je dôležité pre validáciu

5.EN 16931 a jeho Customizácia

EN povoľuje vytváranie špecifickejších variantov EN tiež nazývaných CIUS (Core Invoice Usage Specification). Čo CIUS môže: • Nepoužívať nepovinné elementy • Nepovinné elementy vyhlásiť za povinné • Zaviesť striktnejšie pravidlá • Zaviesť podmnožinu číselníkov Čo CIUS nemôže: • Rozšíriť číselníky • Pridať elementy • Povinné elementy vyhlásiť za nepovinné • Uvoľniť existujúce pravidlá To znamená, že každý dokument podľa CIUS je platný voči EN norme.

  • CIUS môže sprísniť, ale nemôže uvoľniť pravidlá
  • Každý CIUS dokument je platný voči EN 16931
  • CIUS nemôže pridávať nové elementy
  • CIUS nemôže rozšíriť číselníky

6.Peppol BIS 3.0 ako CIUS

Peppol BIS 3.0 je CIUS EN a preto každý platný dokument Peppol BIS 3.0 je v súlade s EN 16931 a rešpektuje ju.

  • Peppol BIS 3.0 je špecifická implementácia EN 16931
  • Každý Peppol BIS 3.0 dokument je EN kompatibilný
  • Peppol BIS 3.0 je povinný pre sieť Peppol

7.Ako čítať Peppol BIS špecifikáciu

Peppol BIS dokumentácia sa skladá z troch hlavných častí: 1. BIS - Špecifikácia Opisuje procesy a pravidlá a tiež množstvo príkladov použitia s konkrétnymi príkladmi. 2. Syntax - Dokumentácia Vlastné mapovanie vylistovaním všetkých povolených XML elementov, ich kardinalitu, význam a validačné pravidlá relevantné pre daný element. 3. Pravidlá Zoznam validačných pravidiel s popisom významu pravidla a vlastnú definíciu v Schematrone.

8.Validácia faktúr - Nástroje a štandardy

Peppol neurčuje, akými nástrojmi máte validovať faktúry. Určuje iba pravidlá EN a CIUS Peppol BIS 3.0, ktoré musia byť dodržané. Peppol vydáva takzvané validačné artefakty vo forme Schematron súborov.

9.XML schéma a Schematron

XML schéma, ktorá je použitá pre Peppol BIS dokument je samotná UBL 2.1. Neexistuje nejaká špeciálna definícia XSD pre Peppol BIS alebo EN 16931. Pre viaceré validačné pravidlá nestačí mechanizmus kontroly XSD schémou, pretože niektoré pravidlá vyžadujú výpočty alebo informácie o hodnotách iných elementov. Napríklad, že celková suma faktúry sa musí rovnať súčtu všetkých súm na riadkoch faktúry. Práve na tento účel sa používa vývojový jazyk založený na Schematrons.

  • Používa sa štandardná UBL 2.1 XSD schéma
  • Neexistuje špeciálna XSD pre Peppol BIS
  • Schematron validuje komplexné pravidlá s výpočtami
  • XSD nestačí pre všetky validačné pravidlá

10.Tri kroky validácie Peppol BIS faktúry

DÔLEŽITÉ: Je potrebné si uvedomiť, že Schematron validácie predpokladajú, že už prebehla štandardná validácia XSD. Ďalej si treba uvedomiť, že pravidlá EN a Peppol BIS sú distribuované zvlášť, čiže pri kontrole je potrebné skontrolovať obe samostatne. Kontrola Peppol BIS teda prebieha v troch krokoch: 1. Validácia samotnej štruktúry použitím UBL 2.1 XSD 2. Validácia pravidiel podľa EN 16931 pomocou súboru Schematron 3. Validácia pravidiel podľa Peppol BIS pomocou súboru Schematron

  • Krok 1: UBL 2.1 XSD validácia štruktúry
  • Krok 2: EN 16931 Schematron validácia
  • Krok 3: Peppol BIS Schematron validácia
  • Všetky tri kroky sú povinné a samostatné

11.Ako začať s implementáciou - Komplexný prístup

Ak ste dodávateľom systému na tvorbu faktúr a plánujete vyhotovovať Peppol BIS faktúry, tak najkomplexnejší prístup by spočíval v: 1. Detailnom oboznámení sa so špecifikáciami 2. Počnúc UBL a EN normou 3. Mapovaním štruktúr dát vášho systému na syntax elementov podľa špecifikácií 4. Následne skontrolovať toto mapovanie na požiadavky noriem a ich pravidiel

  • Začnite detailným štúdiom špecifikácií
  • Pochopte UBL a EN 16931 normu
  • Namapujte vaše dátové štruktúry na syntax
  • Skontrolujte mapovanie voči pravidlám

12.Ako začať s implementáciou - Agilný prístup

V prípade potreby rýchlej implementácie alebo agilnejšieho prístupu sa odporúča: 1. Stiahnuť si príklady existujúcich validných faktúr 2. Mať k dispozícii validačný nástroj na kontrolu správnosti faktúr 3. Mať po ruke špecifikácie, aby ste vedeli rýchlo reagovať na validačné chyby a nájsť v špecifikáciách správne pravidlá či požiadavky

  • Stiahnite si príklady validných faktúr
  • Pripravte si validačný nástroj
  • Majte prístup k špecifikáciám
  • Reagujte rýchlo na validačné chyby

13.Tvorba prvých faktúr - Agilný prístup pokračovanie

V tomto momente môžete začať tvoriť prvé faktúry. Na príkladoch správnych faktúr si pozrite, aké údaje z vášho systému sú minimálne potrebné na vygenerovanie najjednoduchšej Peppol BIS faktúry. Následne zvalidujte výstup a rôzne varianty hodnôt údajov, ktoré váš systém generuje. Kľúčové otázky: • Sú všetky povinné elementy faktúry vždy vytvorené? • Môžu elementy, ktoré sú číselníkové, nadobudnúť hodnoty mimo daného číselníka? To by vyvolalo validačnú chybu.

  • Začnite s najjednoduchšou validnou faktúrou
  • Testujte rôzne varianty údajov
  • Overte, že povinné elementy sú vždy vytvorené
  • Kontrolujte číselníkové hodnoty

14.Integrácia validácie do produkcie

Veľmi odporúčame zakomponovať validačné pravidlá podľa špecifikácií aj do samotného generovania faktúr v produkčnom systéme, aby ste eliminovali generovanie nesprávnych, nevalidných faktúr na začiatku, ktoré by nebolo možné odoslať cez digitálneho poštára. Za týchto predpokladov váš systém dokáže produkovať validné Peppol BIS faktúry. Teraz môžete začať pridávať ďalšie elementy, pre ktoré váš systém dokáže generovať údaje a pridávať ich ako nepovinné. S každým pridaním elementu je nevyhnutné otestovať rôzne možnosti vyskytujúcich sa hodnôt v elementoch.

Najčastejšie otázky

Ktorá syntax je v Peppol sieti predvolená a povinná?

UBL (Universal Business Language)

Čo znamená kardinalita 1..n v EN 16931?

Povinný element, môže sa objaviť niekoľkokrát

Môže CIUS pridať nové elementy mimo EN 16931?

Nie, CIUS môže iba sprísniť pravidlá, nie pridávať elementy

Kde platí pravidlo kardinality elementu?

Iba vo vnútri svojho rodičovského elementu

Koľko krokov má úplná validácia Peppol BIS faktúry?

3 kroky: UBL XSD, EN 16931 Schematron, Peppol BIS Schematron

Existuje špeciálna XSD schéma pre Peppol BIS?

Nie, používa sa štandardná UBL 2.1 XSD schéma

Prečo nestačí iba XSD validácia pre Peppol BIS faktúry?

Niektoré pravidlá vyžadujú výpočty a informácie o hodnotách iných elementov

Čo určuje syntax okrem mapovania elementov?

Poradie elementov, v akom majú byť usporiadané vo faktúre

Je každý platný Peppol BIS 3.0 dokument v súlade s EN 16931?

Áno, pretože Peppol BIS 3.0 je CIUS EN 16931

Prečo integrovať validáciu do produkčného systému?

Aby sa eliminovalo generovanie nevalidných faktúr, ktoré by nebolo možné odoslať

Test pre vývojárov - Technický kvíz!

10 otázok – overte si, čo ste si zo sprievodcu zapamätali.