Mittwoch, 11. November 2020, 10:18
e-Rechnung gemäß EN 16931 (Factur-X, ZUGFeRD)
Seit heute haben wir (noch rechtzeitig für die Deadline am 24.11.2020) automatisch für alle Rechnungen und Gutschriften die e-Rechnung gemäß EN 16931 (auch Factur-X oder ZUGFeRD) implementiert. Sprich alle PDF-Rechnungen enthalten eine Datei "factur-x.xml" mit den nötigen Angaben, wie sie öffentliche Auftraggeber etc. künftig zwingend erfordern.
Klingt ersteinmal unspannend, ist es vermutlich auch. Wäre da nicht dieses - und jetzt lehne ich mich einmal weit aus dem Fenster - dämliche XML-Format, was sich vermutlich nur viel zu gut bezahlte Berater ausgedacht haben können, die niemals auch nur eine Zeile Code erstellt haben.
Was die Ausgedenkt-Habenden sich da zusammengebastelt haben, mag zwar wie ein brauchbares und wunderbar auf hunderten Seiten dokumentiertes Format aussehen, es geht in meinen Augen jedoch an der üblichen Praxis vorbei. Nicht, dass ich XML nicht mag (ich mag es nicht!).
Aber dass man im Jahr 2020 (fast 2021), wo es nicht unbedingt auf ein paar Zeichen ankommt, z.B. Zahlungsweisen in Codes angibt, tut meinem Programmierer-Herz weh. Wäre eine Angabe wie "sepa_directdebit" statt "49" nicht vielleicht doch besser (aka intuitiver) gewesen?
Ganz zu schweigen von den vorhandenen Validatoren, die zwar inoffiziell sind, aber allesamt gerade bei Fehlern oft wenig aussagekräftig sind (eine Nennung der Verletzung des XML-Schemas bringt einen da selten weiter), und selbst nicht mit allem klarkommen, was sogar teilweise in der offiziellen Dokumentation als Beispiel-PDFs mitgeliefert wird. Hmpf.
Ganz zu schweigen davon, dass das Format bestimmte Spezialfälle (unterschiedliche MwSt-Sätze in einer Rechnung für mehr als 1 Land) so gar nicht abbilden kann. Aber das ist dann wohl Sorge des Empfängers, das verbuchen zu können.
Ich glaube, man hätte sich ein für den "Normal-Fall" einfacheres Format in einer zeitgemäßen Notation (ich präferiere ja JSON) einfallen lassen können, das im Endeffekt lesbarer und vermutlich nur halb so groß gewesen wäre. Aber das hätte ja den großen Playern der Branche, die Abrechnungs-Leistungen anbieten, nicht in die Hände gespielt.
Klingt ersteinmal unspannend, ist es vermutlich auch. Wäre da nicht dieses - und jetzt lehne ich mich einmal weit aus dem Fenster - dämliche XML-Format, was sich vermutlich nur viel zu gut bezahlte Berater ausgedacht haben können, die niemals auch nur eine Zeile Code erstellt haben.
Was die Ausgedenkt-Habenden sich da zusammengebastelt haben, mag zwar wie ein brauchbares und wunderbar auf hunderten Seiten dokumentiertes Format aussehen, es geht in meinen Augen jedoch an der üblichen Praxis vorbei. Nicht, dass ich XML nicht mag (ich mag es nicht!).
Aber dass man im Jahr 2020 (fast 2021), wo es nicht unbedingt auf ein paar Zeichen ankommt, z.B. Zahlungsweisen in Codes angibt, tut meinem Programmierer-Herz weh. Wäre eine Angabe wie "sepa_directdebit" statt "49" nicht vielleicht doch besser (aka intuitiver) gewesen?
Ganz zu schweigen von den vorhandenen Validatoren, die zwar inoffiziell sind, aber allesamt gerade bei Fehlern oft wenig aussagekräftig sind (eine Nennung der Verletzung des XML-Schemas bringt einen da selten weiter), und selbst nicht mit allem klarkommen, was sogar teilweise in der offiziellen Dokumentation als Beispiel-PDFs mitgeliefert wird. Hmpf.
Ganz zu schweigen davon, dass das Format bestimmte Spezialfälle (unterschiedliche MwSt-Sätze in einer Rechnung für mehr als 1 Land) so gar nicht abbilden kann. Aber das ist dann wohl Sorge des Empfängers, das verbuchen zu können.
Ich glaube, man hätte sich ein für den "Normal-Fall" einfacheres Format in einer zeitgemäßen Notation (ich präferiere ja JSON) einfallen lassen können, das im Endeffekt lesbarer und vermutlich nur halb so groß gewesen wäre. Aber das hätte ja den großen Playern der Branche, die Abrechnungs-Leistungen anbieten, nicht in die Hände gespielt.
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
Simon
Das einzig sinnvolle ist json. Gut strukturiert, einfach lesbar, einfach verständlich, gut programmierbar...
Martin
Holger
xRechnung und ZUGFeRD sind nicht identisch, sondern grundsätzlich erstmal Konkurrenz (!). Da wurde nur solange rumgebastelt, bis beides irgendwie zusammen passt (Lobby-Arbeit).
Ich war in einem Erprobungsraum (geografisches Gebiet, in dem eine rechtliche Ausnahme geschaffen wird, um Testläufe zu ermöglichen) in verschiedenen Projektgruppen involviert und habe mich schon mit der Frage der Verschlüsselung unbeliebt gemacht. Zitat der Antwort: " Eine Verschlüsselung ist bei Rechnungen nicht notwendig". Das war zu einem Zeitpunkt, als das noch leicht hätte implementiert werden können. Die Rechnungen vom Betriebsarzt mit Patientendaten können/dürfen also nicht per xRechnung verschickt werden, wie auch viele andere auch.
Irgendwann hiess es dann, dass dafür dann ein sicherer Übertragungsweg genutzt werden muss. Also wird einfach neben de.mail noch was neues verpflichtend, nennt sich PEPPOL ...
Dann gibt es noch die Leitweg ID ... oder eben nicht ..
Das lässt sich jetzt beliebig fortführen, aber dafür reicht der Platz hier nicht.
Hätten sie doch nur mal jemanden gefragt, der (oder die) sich damit auskennt!
Lou Garden
Holger
ZUGFeRD sieht aber weiterhin ein pdf vor.
Für xRechnung gibt es dann geklöppelte Visualisierer, die aus dem xml wieder ein pdf machen, damit der Sachbearbeiter was zum ausdrucken und wegheften hat ...