Budowa standardów e-faktur: od modelu semantycznego EN 16931, przez wiązania składniowe (UBL, CII), po specyfikacje krajowe.
Fakturowanie elektroniczne to znacznie więcej niż samo wysyłanie pliku XML. Za każdą e-fakturą kryje się starannie skonstruowany system ustaleń, od pytania, jakie informacje powinna zawierać faktura, po pytanie, jak te informacje są dokładnie ustrukturyzowane. Niniejszy artykuł wyjaśnia tę budowę krok po kroku.
Fundamentem każdej e-faktury jest model semantyczny. Model ten opisuje znaczenie danych na fakturze, niezależnie od formy technicznej. Chodzi o: dostawcę, odbiorcę, numer faktury, datę wystawienia, kwoty, stawki VAT. Istotna jest treść, a nie forma.
W Europie jest to uregulowane w normie EN 16931, europejskim standardzie fakturowania elektronicznego. EN 16931 precyzyjnie określa, jakie elementy informacyjne musi zawierać e-faktura (obowiązkowe) oraz jakie są opcjonalne. Rezultatem jest abstrakcyjny, technologicznie neutralny model opisujący, czym jest e-faktura, bez określania, jak informacje są technicznie przechowywane.
EN 16931 została opracowana na zlecenie Komisji Europejskiej przez CEN (Europejski Komitet Normalizacyjny) i jest prawnie zakotwiczona w Dyrektywie UE 2014/55/UE. Każda e-faktura uznawana za ważną w Europie musi być zgodna z tym modelem semantycznym.
Sam model semantyczny nie wystarczy. Komputery potrzebują konkretnego formatu pliku, aby odczytać i przetworzyć dane. Ten konkretny format nazywany jest składnią lub wiązaniem składniowym.
EN 16931 uznaje dwie oficjalne składnie:
Obie składnie wyrażają te same informacje semantyczne, ale w różnej strukturze XML. Faktura w UBL wygląda technicznie inaczej niż faktura w CII, ale zawiera te same dane.
UBL jest najczęściej używaną składnią w Europie i sieci Peppol. Większość e-faktur wysyłanych przez Peppol to faktury UBL. CII jest stosowana głównie w Niemczech i Francji, między innymi jako podstawa formatu Factur-X/ZUGFeRD.
Składnia taka jak UBL opisuje strukturę, ale nie mówi nic o regułach obowiązujących w ramach konkretnej sieci. Dlatego istnieją profile, które dodają dodatkowe reguły walidacyjne do składni.
Najważniejszym profilem dla sieci Peppol jest Peppol BIS Billing 3.0. Profil ten przyjmuje UBL (lub CII) jako podstawę i dodaje setki reguł biznesowych:
Faktura zgodna z Peppol BIS Billing V3 jest automatycznie zgodna z EN 16931. Profil stanowi doprecyzowanie, a nie odchylenie.
Więcej o tym profilu można przeczytać w artykule o Peppol BIS Billing V3.
Poszczególne kraje mogą dalej doprecyzowywać model europejski dla własnego rynku. Odbywa się to za pomocą CIUS (Core Invoice Usage Specification). CIUS dodaje reguły i wymagania specyficzne dla danego kraju, ale nigdy nie może być sprzeczna z podstawowym modelem EN 16931.
Znane przykłady:
Faktura zgodna z CIUS jest automatycznie zgodna również z Peppol BIS Billing i EN 16931. Relacja jest ściśle hierarchiczna: każda warstwa opiera się na poprzedniej.
Podczas gdy BIS Billing i warianty CIUS zostały zaprojektowane dla Europy, PINT (Peppol International Invoice) rozszerza zasięg na resztę świata. PINT jest osobnym profilem, również opartym na EN 16931, ale z wariantami specyficznymi dla regionu:
Więcej o PINT można przeczytać w artykule o PINT.
Wszystkie warstwy razem tworzą piramidę, od abstrakcji do konkretu:
EN 16931 (model semantyczny, co musi znajdować się na fakturze?)
│
├── Wiązania składniowe (jak dane są przechowywane?)
│ ├── UBL 2.1
│ └── CII (UN/CEFACT)
│
├── Profile (jakie reguły obowiązują?)
│ ├── Peppol BIS Billing 3.0 (europejski profil Peppol)
│ └── PINT (międzynarodowy profil Peppol)
│ ├── PINT EU
│ ├── PINT A-NZ
│ ├── PINT Japan
│ └── ...
│
└── CIUS (specyfikacje krajowe)
├── NLCIUS (Holandia)
├── XRechnung (Niemcy)
├── Svefaktura (Szwecja)
├── ebInterface (Austria)
└── France CIUS (Francja)
Najwyższa warstwa jest najbardziej abstrakcyjna (wyłącznie znaczenie), najniższa warstwa najbardziej konkretna (konkretne pola XML i reguły walidacji dla danego kraju).
Oprócz czystych standardów XML istnieją również formaty hybrydowe, które łączą wizualny plik PDF z danymi XML czytelnymi maszynowo w jednym pliku. Zasada techniczna jest zawsze taka sama: dokument PDF/A-3 z osadzonym załącznikiem XML. Odbiorca może obejrzeć fakturę wizualnie (jako PDF), a jednocześnie przetworzyć dane automatycznie (poprzez XML).
Najbardziej znanym przykładem jest Factur-X/ZUGFeRD, który osadza XML CII i jest szeroko stosowany w Europie. Ponadto istnieje ISDOC.PDF, czeski wariant osadzający własny krajowy schemat XML zamiast CII. Oba formaty dzielą koncepcję hybrydową, ale różnią się osadzonym XML i stopniem zgodności z EN 16931.
Formaty hybrydowe są szczególnie praktyczne w fazie przejściowej do pełnej e-fakturacji: stanowią pomost między tradycyjnym PDF a w pełni ustrukturyzowaną fakturą XML. Szczegółowe porównanie, w tym struktura techniczna i komplikacje przy przetwarzaniu, znajduje się w artykule Hybrydowe formaty faktur: PDF z osadzonym XML.
Poniższa tabela zestawia najważniejsze standardy e-faktur. W ten sposób można na pierwszy rzut oka zobaczyć, jak odnoszą się do siebie i do europejskiej normy EN 16931.
EN 16931 stanowi fundament semantyczny, na którym opierają się wszystkie pozostałe standardy. UBL i CII to dwa oficjalnie uznane wiązania składniowe. Specyfikacje CIUS (Peppol BIS, NLCIUS, XRechnung) doprecyzowują model dodatkowymi restrykcjami lub obowiązkami, nie zmieniając modelu bazowego. ZUGFeRD/Factur-X łączy wizualny PDF z osadzonym plikiem XML CII. ISDOC to czeski format krajowy z własnym wariantem hybrydowym. PINT jest następcą BIS dla międzynarodowej fakturacji Peppol, z wariantami specyficznymi dla regionu, między innymi dla Australii, Japonii i Singapuru.
Jako użytkownik eConnect nie muszą Państwo samodzielnie zarządzać tą hierarchią. Platforma automatycznie dokonuje transformacji między wszystkimi obsługiwanymi formatami. Jeśli wysyłają Państwo fakturę UBL do odbiorcy oczekującego XRechnung, faktura zostanie przekształcona. Jeśli otrzymają Państwo fakturę CII, podczas gdy system księgowy oczekuje UBL, eConnect skonwertuje dokument.
Hierarchia standardów jest tym, co to umożliwia: ponieważ wszystkie formaty opierają się na tym samym modelu semantycznym (EN 16931), bezstratna konwersja między formatami jest technicznie możliwa.
Wskazówka: chcą Państwo dowiedzieć się więcej o konkretnym formacie? Prosimy zapoznać się z artykułami w kategorii Formaty, gdzie każdy format jest opisany wraz z jego cechami.
Pobierz pliki przykładowe