Mustang 2.14 und ZUGFeRD 2.3.0

[Gerrit Staab]

Hallo zusammen,

ich bin neu in dem Thema eRechnung und gerade im Begriff, für unsere Rechnungssoftware (Java) die Validierung von ZUGFeRD Rechnungen einzuführen. Dafür möchte ich das Mustang Project verwenden. Bei der Beschäftigung mit ZUGFeRD im Zusammenspiel mit Mustang sind mir nun mehrere Dinge aufgefallen, die mir merkwürdig vorkommen:

1. Die FeRD-Beispieldateien enthalten in Version 2.3 ein Sonderzeichen in den XMP-Metadaten, das sorgt für Exceptions in den Versionen 2.13 und 2.14 des Mustang Project. Sollte die Library nicht von allein damit umgehen können?

2. Die FeRD-Beispieldateien im Profil XRECHNUNG werden von Mustang 2.13 und 2.14 (nachdem ich mich um die Sonderzeichen gekümmert habe) als invalide validiert. Version 3.0 von XRECHNUNG wird noch nicht als valide erkannt. Außerdem führen die Metadaten den Dateinamen xrechnung.xml, der Anhang heißt aber factur-x.xml. Sollten die Referenzdateien nicht korrekt sein?

3. Mustang Project hat ZUGFeRD-Version 2.3.0 zur Validierung hart verdrahtet, es wird also immer gegen den neuesten Standard validiert. Bedeutet das im Umkehrschluss, dass nur ZUGFeRD-Rechnungen, die dem neuesten Standard folgen als valide angesehen werden dürfen? Ich hätte angenommen, dass alle ZUGFeRD Versionen, die der Norm EN 16931 genügen, als valide ausgegeben werden sollten.

Haben andere auch diese Beobachtungen gemacht? Wie soll man damit umgehen, wann bspw. eine ZUGFeRD-Datei ablehnen (Beispiel aus Nr.2: DocumentFileName = xrechnung.xml, Attachment aber factur-x.xml)? 

Viele Grüße,

Gerrit Staab

[Bernd Wild]

Hallo Gerrit,

das stimmt, der erste Wurf der offiziell veröffentlichten Beispieldateien hatte u.a. noch das Problem mit dem "&" in den XMP-Strings. Mea culpa, da geht auf meine Kappe, wobei ich auch nicht wusste, dass so etwas die XMP-Parser aus dem Tritt bringen kann. Dies ist nun behoben. 

Ferner war noch die Benennung der Datei inkonsistent, es muss im Profil XRECHNUNG eben xrechnung.xml heißen und nicht factur-x.xml.

Daniel Vinz von der AWV wird die korrigierten Beispieldateien heute oder spätestens morgen veröffentlichen.

Grüße

Bernd Wild

[Gerrit Staab]

Hallo Bernd,

vielen Dank für die schnelle Reaktion und die Bereitstellung neuer Referenzdateien!

@Community: gibt es eine Art Leitfaden oder Orientierungshilfe, welche Kombinationen aus Standards und Versionen von einer Unternehmung akzeptiert bzw. abgelehnt werden müssen? Bspw. validiert Mustang 2.14 eine ZUGFeRD 2.3 Rechnung im Profil XRECHNUNG mit einem XRECHNUNG 3.0 Attachment als invalide, obwohl die Datei den Angaben in "Factur-X Version 1.0.07 (ZUGFeRD v. 2.3) | September 18. 2024" entspricht.

Viele Grüße,

Gerrit Staab

[jochen...@gmail.com]

>@Community: gibt es eine Art Leitfaden oder Orientierungshilfe, welche Kombinationen aus Standards und Versionen von einer Unternehmung akzeptiert bzw. abgelehnt werden müssen?

Ich gehe davon aus, dass bei Factur-X das Dateiformat, aus bestimmten Gründen beim Entwurf des Schreibens FatturaPA aber nur die CIUS gemeint war. Das bedeutet CII und UBL und FX in den EN16931-Profilen wie konkret verbeispielt .

> Bspw. validiert Mustang 2.14 eine ZUGFeRD 2.3 Rechnung im Profil XRECHNUNG mit einem XRECHNUNG 3.0 Attachment als invalide, obwohl die Datei den Angaben in "Factur-X Version 1.0.07 (ZUGFeRD v. 2.3) | September 18. 2024" entspricht.

Das ist vermutlich ein Fehler, gerne mit Beispiel als issue melden mit Beispieldatei.

[Gerrit Staab]

Das Beispiel ist die Datei XRECHNUNG_Reisekostenabrechnung.pdf aus dem korrigierten Info-Paket zu ZUGFeRD 2.3 des FeRD. Die Datei führt unter Version den Eintrag "3.0", der in PDFValidator.java als invalide erkannt wird:

        boolean versionValid = false;

        for(int i = 0; i < nodes.getLength(); ++i) {
          String[] valueArray = new String[]{"1.0", "2p0", "1.2", "2.0", "2.1"};
          if (stringArrayContains(valueArray, nodes.item(i).getTextContent())) {
            versionValid = true;
          }
        }

        if (!versionValid) {
          this.context.addResultItem((new ValidationResultItem(ESeverity.error, "XMP Metadata: Version contains invalid value")).setSection(16).setPart(EPart.pdf));

[jochen...@gmail.com]

Habe ich gerade korrigiert, danke, kommt in der nächsten Mustang-Version