Umfrage: Besteht Bedarf an weiterer Java-Library?
Gerrit Staab
Mich interessiert ein kurzes Stimmungsbild der Community.
Zum Hintergrund: wir haben uns für die Java-Implementierung unseres Rechnungssystems nach sorgfältiger Analyse unserer Bedarfe/Anforderungen für eine Eigenentwicklung der Validierung und Visualisierung von eRechnungen entschieden (unter Verwendung der Schema- und Schematron-Regeln, die zur Norm 16931 und den Standards XRechnung und ZUGFeRD öffentlich herausgegeben werden sowie der KosIT XSLT Transformation).
Wir überlegen aktuell, ob wir unseren Code als Open Source Library zur Verfügung stellen. Die Frage, die sich uns dabei aktuell stellt: welche Funktionen/Features wären überhaupt für euch/Sie interessant? Was müsste eine solche Library mitbringen? Welche Qualitäten sollte sie haben?
Viele Grüße,
Gerrit Staab
jochen...@gmail.com
Thomas Sporbeck
Gerrit Staab
Ich möchte eigentlich keinen Vergleich mit Mustang anstellen sondern ein Gefühl dafür bekommen, ob unser Code Wert für andere darstellen kann, bevor wir uns die Mühe machen, ihn so zu verallgemeinern, dass er bereit für öffentliche Repos und Github ist.
Wir haben uns aus diversen Gründen für eine Eigenentwicklung entschieden, hier die relevantesten:
- Der Code soll Standard-agnostisch sein: wir unterstützen ZUGFeRD und XRechnung gleichberechtigt, haben also eine einheitliche Lösung, die über denselben Eingang und auf dieselbe Weise sowohl ZUGFeRD-PDFs als auch XRechnung-XMLs entgegen nimmt (als byte[]) und am Ende der Verarbeitung dasselbe Ergebnis-Objekt ausgibt, was wiederum eine einheitliche Folgeverarbeitung möglich macht.
- Standard-Treue ist uns sehr wichtig: ZUGFeRD bspw. wird exakt nach den Vorgaben aus der Dokumentation des FeRD validiert. Die Erfahrungen aus den ersten eRechnungen, die uns erreicht haben, zeigt, dass nicht jede Lösung darauf prüft, ob der PDF Standard eingehalten wird oder ob der strukturierte Teil xrechnung.xml im Profil XRECHNUNG und factur-x.xml in den anderen Profilen heißt oder ob Metadaten im richtigen Schema vorhanden sind.
- Da sich die Standards entwickeln (ZF 2.1, 2.2.,2.3 ...) ist es uns wichtig, dass unsere Lösung bei der Validierung den verwendeten Standard erkennt und den Anwender im Validierungsergebnis zum einen darüber informiert, dass es eine neue Version des Standards gibt, wie das Validierungsergebnis im erkannten Standard und der erkannten Version ausfällt, sowie, wie das Validierungsergebnis in der neuesten Version des Standards ausfällt.
Viele Grüße!
Gerrit Staab
Andreas Reichmann
Warum habt Ihr euch dagegen entschieden eine offene Lösung z.B. Mustang voranzubringen ? (das ist keine Kritik sondern eine wertfreie Frage).
Gerrit Staab
Hallo Andreas,
eine sehr berechtigte Frage!
In der Analysephase zu unserer eRechnungsanwendung sind wir mit der Hypothese ins Rennen gegangen, dass wir unsere Implementierung auf der Mustang Library und dem KoSIT Validator aufsetzen können. Nachdem unsere fachlichen Anforderungen geklärt waren, haben wir uns den Zustand und den Code der Libraries näher angesehen und sind dabei zu dem Schluss gekommen, dass sie nicht als Grundlage für unsere Implementierung geeignet sind.
Den KoSIT Validator haben wir sehr schnell ausgeschlossen, da das letzte Update 2022 war, was für uns ein deutliches Signal ist, dass wir dort keine Updates erwarten können. Wenn niemand diese Library aktiv pflegt, ist es nur eine Frage der Zeit, bis bspw. neu erkannte Sicherheitslücken zum Problem werden (Referenz: log4shell) oder Updates der eigenen Anwendung durch veraltete Java-Abhängigkeiten erschwert werden.
Mustang wird aktiv gepflegt und hat eine ausreichend große Community. Allerdings haben wir nach intensiver Betrachtung des Codes ermittelt, dass die Library nicht den Qualitätsansprüchen entspricht, die wir an unsere Software haben. Da das eRechnungsthema ein langfristiges ist, ist uns vor allem die langfristige Wartbarkeit unserer Anwendung ein hohes Anliegen. Daher haben wir nicht nur Anforderungen bezüglich der Funktion des Codes, sondern auch zu seiner Qualität. Ich möchte dies an dieser Stelle explizit nicht als Kritik an Mustang oder dessen Entwicklern verstanden wissen, sondern als eine auf unsere Anforderungen bezogene Feststellung.
Ich möchte keine einzelnen Codebeispiele öffentlich diskutieren, da dies schnell in eine unproduktive Diskussion ausarten kann. Falls es dich oder einen Leser dieses Beitrags genauer interessiert, was ich meine, kann ich empfehlen, den Code von Mustang auszuchecken und einfach eine statische Codeanalyse drüber laufen zu lassen (bspw. FindBugs, SonarQube; jeweils mit Standard-Ruleset). Das genügt schon, um ein objektives Bild zu bekommen. Das beantwortet dann auch die Frage, warum wir uns dagegen entschieden haben, zu Mustang beizutragen. Der nötige Aufwand wäre für uns nicht wirtschaftlich gewesen.
Zu der Frage, wie wir die ZUGFeRD-Version ermitteln: Wir matchen über den ExchangeDocumentContext die im Standard der jeweiligen Version definierte URI des Erweiterungsschemas für Factur-X und überprüfen dann, ob die Validierung erfolgreich ist. Validiert das Dokument mit mehreren ZUGFeRD-Versionen, geben wir im Validierungsergebnis aus, dass das Dokument mit der neuesten erkannten Version compliant ist.
Ich muss dir ein wenig bei der Aussage "ab dem 01.01.2025 ist nicht relevant, ob es PDF oder PDF/A ist" widersprechen: Es ist korrekt, dass im Schreiben des Bundesfinanzministeriums steht, dass der strukturierte Teil der eRechnung führend ist. Allerdings ist das nur die fachliche Ebene. Auf der technischen Ebene gibt es mit ZUGFeRD einen definierten Standard, der genaue Vorgaben darüber macht, was ein wohlgeformtes, korrektes ZUGFeRD-Dokument darstellt und was nicht. Dort steht deutlich, dass es sich um ein PDF/A-3 Dokument handeln muss (Dokumentation des FeRD, 1. FACTUR-X 1.0.07, Kapitel 6). Viele Grüße, Gerrit
Andreas Reichmann
Wg. den ZUGFeRD Versionen ... ja mehr wie ein Matching welche höchste Version fehlerfrei validiert geht ja im Zweifel nicht.
Zum Thema PDF und ZUGFeRD, in der letzten Version 2.3.2 steht:
Ab dem 01.01.2025 ist in Deutschland das in das Hybriddokument eingebettete XML die Rechnung. Wenn das XML gültig ist (erfolgreiche Validierung aller Geschäftsregeln, die für die nationale Anforderungen in Deutschland gelten) und aus dem PDF extrahiert werden kann, handelt es sich um eine gültige E-Rechnung. Technische Fehler in Bezug auf den PDF/A-Standard sind lediglich als Warnung zu beachten und sind keine schwerwiegenden Fehler. Dennoch KANN der Empfänger der Rechnung den Absender auffordern, eine aktualisierte und korrigierte Version zu liefern, die dem PDF/A-Standard entspricht.
Andreas Reichmann
BR-FX-DE-03
Gerrit Staab
Gefühlt führt das den ZUGFeRD-Standard ad absurdum, aber es ist wohl, wie es ist.
Viele Grüße,