In der Ankündigung steht, dass ZUGFeRD 2.3 unterstützt wird.
Ich finde in der Doku aber nur 2.1 und kein Wort von 2.3.
Ist es doch nicht enthalten?
Hallo,
wir sind gerade noch dabei vereinzelnd Seiten dahingehend zu aktualisieren. Aber in der Dokumentation für die Option PDF.ZUGFeRDXmlPath ist es nicht mehr erforderlich eine Version mit anzugeben, da dies aus der XML-Datei automatisch ermittelt wird.
Diese Änderung in der Version 31 hatten wir auch bei den Update-Hinweisen aufgenommen.
Grüße,
Daniel Stein
vielen Dank, ich werde das testen, komme aber leider nicht so ganz klar.
Einerseits finde ich:
“Hinweis: Der Dateiname muss dabei der eingestellten ZUGFeRD-Version entsprechen”
Andererseits steht da:
”PDF.ZUGFeRDXmlPath: Gibt den Pfad einer ZUGFeRD-konformen XML-Datei an, die in das Ergebnis-PDF eingebettet werden soll. Der ZUGFeRD-Conformance Level und die ZUGFeRD-Version werden dabei automatisch aus der übergebenen XML-Datei ausgelesen.”
Und zu dem Dateinamen finde ich keine Angaben - wenn er wirklich irgendwie in der Art “ZUGFeRD_2.1.xml” oder ähnlich heißen soll/muss.
Wie der Dateiname bei der Einbettung in das PDF-Dokument heißen muss, bestimmt der ZUGFeRD-Standard. In der Spezifikation dazu finden sich einige Stellen die auf factur-x.xml für ZUGFeRD und auf xrechnung.xml verweisen, wenn es um XRECHNUNG geht.
Ob ein Validator das PDF-Dokument mit der XML-Einbettung anhand eines anderen Dateinamnes anerkennt, können wir nicht bestimmen. Aus Sicht von List & Label können wir die Spezifikation nicht vorgeben und der zugrundeliegende Standard sollte hierzu im Zweifel berücksichtig werden.
Ich habe die neue Implementierung ausführlich getestet und bin zu dem Schluss gekommen, dass sie noch nicht vollständig ausgereift ist.
Vorheriges Verhalten:
Die XML-Datei konnte mit einem beliebigen Dateinamen übergeben werden (in meinem Fall enthält der Dateiname die ID des Datensatzes), beispielsweise: 1380-20251020111526.xml
Durch die Option:
exportConfiguration.ExportOptions.Item(LlExportOption.PdfZUGFeRDVersion) = "2.1"
wurde daraus automatisch und korrekt eine factur-x.xml im PDF eingebettet.
Aktuelles Verhalten:
Die Quelldatei muss nun zwingend factur-x.xml heißen, damit im PDF entsprechend factur-x.xml eingebettet wird. (Hinweis: Es gibt übrigens keine Versionsnummer in den ZUGFeRD-XML-Dateien selbst.)
Verwende ich beispielsweise den Dateinamen 1380-20251020111526.xml, wird dieser Name unverändert im PDF verwendet, was nicht dem Standard entspricht.
Beobachtung:
Ich habe festgestellt, dass ich eine ZUGFeRD 2.3.3 XML-Datei (mit dem Dateinamen 1380-20251020111526.xml) übergeben und dennoch die alte Version 2.1 setzen kann – es funktioniert und erzeugt eine factur-x.xml. Allerdings ist unklar, ob diese Unterstützung für die veraltete Option langfristig bestehen bleibt.
Problematik der neuen Implementierung:
Die Datei muss zwingend factur-x.xml heißen. Auf einem System, das parallel mehrere hundert Rechnungen verarbeitet, bedeutet dies, dass für jede Rechnung ein separater Ordner angelegt und nach der Verarbeitung wieder gelöscht werden muss.
Lösungsvorschlag:
Es wäre wesentlich eleganter, wenn es zwei separate Optionen gäbe:
-
PdfZUGFeRDXmlPath(für den Input mit beliebigem Dateinamen) -
PdfZUGFeRDXmlPathOutput(für den Namen im PDF, z.B.factur-x.xml) → falls nicht gesetzt → Dateiname ausPdfZUGFeRDXmlPath
Dies würde eine deutlich flexiblere und effizientere Handhabung ermöglichen.
Vielen Dank für die Beobachtungen.
Im Automatik-Modus (PDF.ZUGFeRDVersion=0) sollte auch der einzubettenden Dateiname korrekt gesetzt werden - egal welcher XML-Dateiname über PDF.ZUGFeRDXmlPath definiert wurde. Wir haben dazu nun eine Anpassung vorgenommen, die im eigenen combit Konto mit dem Latest Prerelease Service Pack - voraussichtlich ab morgen verfügbar - bezogen werden kann.
Bitte noch ein wenig gedulden… ich gebe hier nochmal gesondert Bescheid, wenn ein aktualisiertes Latest Prerelease Service Pack im Download-Bereich verfügbar ist, dass die angekündigten Änderungen auch enthält.
@joXjo Das Latest Prerelease Service Pack für Version 31 steht nun im Downloadbereich bereit mit den angekündigten Anpassungen. Vielen Dank für eine kurze Rückmeldung.
1 Like
Mein Code - per Haltepunkt sichergestellt, dass er es auf “0” setzt.
Egebniss:
Das ganze ist jetzt sogar noch schlechter als ohne den “Servicepack”. Denn hab ich vorher die Version auf 2.1 gestellt, kam es richtig, das geht jetzt auch nicht mehr.
Das sollte natürlich nicht so sein und tut mir leid. Damit wir das nun weiter untersuchen können würden wir aber auch gerne die verwendete XML-Datei einsehen müssen, um den Mechanismus des Auto-Modes dahingehend ggf. weiter zu verbessern. Hierzu würde es sich anbieten, einen Support-Case in unserem Supportportal zu erstellen, damit wir die sensiblen Daten austauschen können.
Leider ist es momentan nicht ganz einfach, ein Support-Ticket zu erstellen. Entschuldigung für die Umstände – die Herausforderung liegt darin, dass ich dort Informationen angeben muss, auf die ich kurzfristig keinen Zugriff habe, da ich aktuell keine Version 31 in Betrieb habe und erst wieder ein projekt erzeugen oder laden müsste.
Ist mir jetzt auch egal, ich werde die Version 31 erst mal als unbrauchbar ignorieren.
Der Fall wird nun weiter in der Entwicklung untersucht. Sobald sich Neuigkeiten ergeben, werden wir diese hier dazu ebenso abschließend bereistellen.