Herausforderungen bei der Implementierung der EN16931

Nun ist die EN16931 vollständig veröffentlicht: Das semantische Datenmodell steht, die Syntaxen zur Umsetzung sind definiert. Das Mapping zwischen Fachwelt (Semantik) und Technik (Syntax) ist definiert.
Dank der E-Rechnungs-Verordnung sind auch die Termine für den Livebetrieb in Deutschland klar. Somit steht einer Umsetzung nichts mehr im Weg, sollte man meinen. Doch leider ist dem noch nicht so. Die technischen Dokumente lassen insbesondere im Hinlick auf Codelisten noch einige Fragen offen. Und das kann bei der Implementierung zu nicht unerheblichen Herausforderungen führen.

Unklare Codelisten

Dies beginnt schon bei einem der wesentlichsten Elemente: Dem Code zur Identifizierung der Dokumentenart. Im semantischen Datenmodell sind hier sämtliche Ausprägungen der Codeliste UNTDID 1001 zugelassen, die Rechnungen, Rechnungskorrekturen oder Gutschriften abbilden. Welche dies jedoch genau sind, ist weder im semantischen Datenmodell, noch in den Mappingdokumenten erwähnt. Damit bleibt zurzeit nur zu spekulieren, welche Codes tatsächlich gültig sind. Schaut man in die Codeliste UNTDID 1001, so kommen eine Vielzahl möglicher Codewerte in Betracht. Einige davon sind unstrittig: 380 für die normale Rechnung, 381 für eine Rechnungskorrektur. Zumindest, wenn die letztere nicht als negative Rechnung dargestellt wird. Dies ist bei ZUGFeRD 1.0, sowie einigen europäischen Mitgliedstaaten (z.B. den Niederlanden) der Fall.

Für die anderen Codes ist eine Implementierung schwieriger. Mit ihnen sind oftmals abweichende Prozesse verknüpft. Das empfangende System muss diese unterstützen, wenn es zum Beispiel den Code für die Proformarechnung, oder eine Rechnung empfängt, in der ausschließlich Umsatzsteuer berechnet wird.

Helfen die Validierungsartefakte?

Anhaltspunkte für die Umsetzung könnten die in den technischen Dokumenten erwähnten Validierungsartefakte bieten. Hierbei handelt es sich um ein Paket von Schematron-Dateien. Mit deren Hilfe lassen sich XML Instanzen gegenüber einem Satz von Geschäftsregeln prüfen. Zu diesen Prüfungen gehören neben Prüfungen der Struktur und der im semantischen Datenmodell definierten Geschäftsregeln auch die korrekte Anwendung der technischen Codelisten. Es wird als Quelle für diese Validierungsartefakte auf den FTP-Server des CEN verwiesen, dort befinden sich zum heutigen Tag jedoch keine Dateien.

Undefinierte Codelisten

Eine weitere Herausforderung bei der Implementierung ergibt sich dadurch, dass im semantischen Datenmodell auf zwei Codelisten verwiesen wird, die bis heute noch gar nicht existieren. Eine Codeliste, um eine elektronische Addresse zu qualifizieren (z.B. als E-Mail-Adresse, Webseite, etc.) und eine Codeliste um die Ausnahmegründe der Umsatzsteuer zu definieren. Zwar gibt es für beide Codelisten bereits heute einzelne Organisationen oder Anwendergruppen, die hierfür eigene Definitionen erarbeitet haben, jedoch nicht beim EU-Projekt Connecting Europe Facility, auf das die Norm hierfür referenziert. Es ist also schon jetzt abzusehen, dass die Dokumente einer Aktualisierung oder zumindest einer Klarstellung bedürfen.

Doch so ein Aktualisierungsprozess innerhalb der Standardisierung ist langwierig. Er bedarf in der Regel Phasen zur Kommentierung und zur Qualitätssicherung, für die jeweils Mindestdauern vorgesehen sind. Somit ist mit einer kurzfristigen Veröffentlichung kaum zu rechnen.

Pragmatischer Ansatz für die Implementierung

Wie sollte man am besten vorgehen? Abwarten kommt eigentlich nicht in Frage, da die Fristen zur Umsetzung bereits laufen. Die eigentliche Herausforderung bei der Umsetzung besteht auch nicht in der technischen Umsetzung, sondern die Prozesse der öffentlichen Auftraggeber effizient anzupassen. Nur dann lassen sich die elektronischen Rechnungen auch medienbruchfrei und effizient empfangen und verarbeiten.

Was die Codelisten angeht, sollte zunächst mit einfachen Fällen begonnen werden: Für den Dokumententyp zum Beispiel mit den Standardtypen 380 und 381, sowie noch 389, falls auch eine Gutschrift nach dem Gutschriftsverfahren (selbst ausgestellte Rechnung) implementiert werden soll. Das Fehlen der Codeliste für die Ausnahmebegründungen bei der Umsatzsteuer ist zwar unschön, jedoch in den meisten Fällen nicht wesentlich, da die wenigsten Systeme heute mit allen in den europäischen Gesetzen und deren nationalen Umsetzungen vorgesehenen Fällen automatisiert umgehen können. Die Angabe des Ausnahmegrundes in menschenlesbarer Form unterstützt hier den Buchhalter, der dann ggf. den korrekten Steuerfall manuell nachtragen muss.

Lediglich das Fehlen der Codeliste zur Qualifizierung elektronischer Addressen kann in der Praxis zu Herausforderungen führen. Dies trifft insbesondere dann zu, wenn zur Übertragung der elektronischen Rechnungen ein System verwendet wird, dass genau dieses Feld verwendet, um die technischen Systeme für Versand und Empfang zu identifizieren. In der Regel haben diese Systeme dann zwar eigene Codelisten für diesen Zweck, der Aspekt der Standardisierung entfällt jedoch. Der Sender müsste im schlimmsten Fall mehrere Codelisten für diesen Zweck pflegen. Jedoch müssen dann auch die Systeme für die Rechnungserstellung diese unterstützen – und zwar abhängig vom Empfänger. Es bleibt also zu hoffen, dass hier möglichst schnell eine Klärung herbeigeführt wird.

Andreas Pelekies

Andreas Pelekies ist Senior Manager Consulting & Sales bei GEFEG mbH. GEFEG Lösungen bieten Produktivitätssteigerungen und optimierte Entwicklung von Datenschnittstellen, um Geschäftsprozesse zu verbinden und deren Fachinhalte zu planen, abzubilden und während des gesamten Anwendungszyklus zu managen. Zu den Lösungen gehören die Software GEFEG.FX für Entwicklung und Management von Datenmodellen, eStandards und Schnittstellen. Andreas Pelekies ist aktives Mitglied in nationalen und internationalen Gremine, wie z.B. DIN, CEN, UN/CEFACT. Er leitet im Forum elektronische Rechnung Deutschland (FeRD) die Entwicklung des ZUGFeRD Formats. Nach 18 Jahren Softwareentwicklung für kaufmännische software war er als Manager für globale XML Standards bei GS1 Germany tätig und betreute die Themen Bargeldlogisik und Elektronische Rechnung auf nationaler und internationaler Ebene. Er studierte Wirtschaftsinformatik an der Hochschule für Ökonomie und Management.

4 Gedanken zu „Herausforderungen bei der Implementierung der EN16931

  • 24. November 2017 um 19:14
    Permalink

    Könnten Sie zu all Ihren Erlaueterungen Beispiele hinzufügen, dann waeren Ihre Ausführungen nicht so verwirrend. Ausserdem waeren Bezugsquellennachweise sehr hilfsreich: zB. woher sollen wir die EN16931 dokumente bekommen?

    Antwort
    • 30. November 2017 um 11:09
      Permalink

      Vielen Dank für den Kommentar. Die Links zu den Bezugsquellen der EN16931 können hier gefunden werden.
      Bitte spezifizieren Sie für was Sie genau ein Beispiel benötigen.

      Antwort
  • 18. Januar 2018 um 12:22
    Permalink

    Unerfahrener Programmierer mit kleinen Budget. Ich versuche gerade eine XRechnungskonforme UBL Invoice zu erstellen und habe Probleme mit dem richtigen Mapping. So nebenbei, invoice.fans, vielen Dank, ohne euch würde ich noch immer im dunklen tappen. Aber hier noch schnell die Frage: Reicht es die DIN EN 16931-1 zu kaufen um das komplette nötige Mapping zu erfahren oder werden noch mehr Teile der Norm benötigt?

    Antwort
    • 18. Januar 2018 um 12:38
      Permalink

      Hallo Herr Freimuth,

      vielen Dank für Ihr Lob!
      Die offiziellen Mappings finden Sie in CEN/TS 16931-3-2 für UBL, CEN/TS 16931-3-3 für CrossIndustryInvoice und CEN/TS 16931-3-4 für EDIFACT. Darüber hinaus können Sie auch hier auf der Seite einfach auf Dokumentation klicken. Dort finden Sie dann entsprechende technische Informationen.
      Viel Erfolg bei der Umsetzung!

      Antwort

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.