Pascal-Unit zum Erzeugen von ZUGFeRD XML

[MmVisual]

Erledigt (gelöscht). Vielen Dank dass du die Lizenz auf LGPL machst, damit kann wirklich jeder die Datei verwenden.

[Jorg3000]

Ich hatte leider erst nachträglich bemerkt, dass die Beispieldaten in Version 2024-12-30 den Validator-Test nicht mehr bestehen.
Die Spezifikation und ich waren unterschiedlicher Ansicht wie mit Nettobeträgen von steuerfreien Leistungen umzugehen ist.

Die Version 2024-12-31 behebt das Problem.
Download siehe ersten Post auf Seite 1.

[Jorg3000]

Da es nun funktioniert (zumindest der enthaltene Testfall mit 5 Positionen und 3 Steuersätzen)
... habe ich mir überlegt, dass es zukünftig ein guter Unit-Test wäre, wenn ich eine Lese-Funktion für fertige ZUGFeRD-XML-Dateien einbauen würde - und die interpretierten Daten im gleichen AllData-Record speichere, der auch für die XML-Erzeugung verwendet wird.
Dann könnte man eine fremde Rechnung einlesen, interpretieren und wieder neu speichern - und anschließend vergleichen, ob es einen Unterschied gibt, der dann auf einen Fehler hinweisen würde.
Im Januar werde ich aber dafür wohl keine Zeit finden.

Wer wäre an einer Lese-Funktion interessiert?
Und wer würde sich für die Ausgabe einer Rechnung als HTML-Seite interessieren?

Grüße, Jörg

[W126]

Moin, Moin,

das hört sich alles sehr gut an! Ich bin gespannt und warte gerne die Unit zu testen.
Vielen Dank für Deine Arbeit.

Gruß Jörg

[kirchfritz]

Hallo Jörg,

ich möchte Dir nochmals gratulieren zur tollen Leistung, wie Du so "zwischen den Jahren" schnell mal eine Routine zur Erstellung von ZUGFeRD-XMLs auf die Füße stellst.
Hut ab!

Mich persönlich würde interessieren:
a) Aus dem gleichen Datensatz (Testfall mit 5 Positionen und 3 Steuersätzen) anstelle einer ZUGFeRD-XML eine XRechnung-XML erstellen.

b) Aus dem gleichen oder einen eventuell erweiterten Datensatz (Testfall mit 5 Positionen und 3 Steuersätzen) anstelle einer BASIC-ZUGFeRD-XML eine COMFORT bzw. EXTENDED ZUGFeRD-XML erstellen.

c) EIne ZUGFeRD-XML mit Pascal-Bordmittel validieren. XSLT, XSD und Schematron sind ja ganz nützlich, aber eine FreePascal Lösung wäre mir lieber. Ich möchte einfach im Pascal Universum bleiben, und nicht zum Validieren eine Web-Anwendung starten oder zur Visualisierung eine JAVA-Anwendung starten müssen. Geht beides sehr gut mit der Apache Mustang Bibliothek. Ist aber wie gesagt, ein Ausflug in das JAVA-Universum.

d) An einer Lese-Funktion habe ich grundsätzliches Interesse. Frage: Wo nimmst Du fertige ZUGFeRD-XML-Dateien her, die nicht von Dir selbst erstellt wurden?

Guten Rutsch und viel Erfolg in 2025
Fritz

[Soner]

Vielen Dank für die Unit.
Es gibt aber ein Manko, gerade bei B2B-Bereich sind die Preise mehr als 2-stellig. Ich habe den Preis als 0,9345 übergeben die Unit hat es auch so richtig gerechnet aber am Endeffekt die Preise als 2-stellig angezeigt:

preisflasch.png (9.69 KiB) 691 mal betrachtet

Bei der Validierung wird auch gewarnt, auch wenn es validiert wird:

nachkommastellenwarnung.png (39.03 KiB) 691 mal betrachtet

Ich habe für Preisangabe die Funktion geändert:

Code: Alles auswählen

function FormatDecimalPreis(const Value: Double): String;  // instead of FloatToStr()
begin
  //soner ## hinzugefügt, wird nur für Preis aufgerufen.
  Result := FormatFloat('0.00##', Value, FormatSettingsUSA); //'0.00'
end;

//....

  // price
  //....
  makeNode(n, 'ram:ChargeAmount', FormatDecimalPreis(Item.NetSinglePrice));

Danach gab es keine Warnung mehr.

Edit:
Also die Funktion FormatDecimalPreis wurde zusätzlich zu FormatDecimal hinzugefügt und nur für Preis aufgerufen. Die Summen sollen 2-stellig sein, sonst gibt es keine Validierung.

[Soner]

Ich habe zugferd_xml.pas für minimale Zugferd-Version d.h. ohne Rechnungspositionen angepaßt. Mann muss dafür TZUGFeRD_XML.Minimum auf true setzen. Ich habe meine Ergenzungen mit "//soner" gekennzeichnet, sucht danach falls ihr wissen wollt, was ich gemacht habe.

Einige Validatoren geben an, dass es nicht gültig ist, aber es ist gültig, nur so etwas soll nicht als richtige E-Rechnung gelten. Sie sollen als Buchungshilfe gelten.
Hier sind einige Validatoren:
https://erechnungs-validator.de/
https://app.b2brouter.net/de/validation

[Jorg3000]

habe den Preis als 0,9345 übergeben die Unit hat es auch so richtig gerechnet aber am Endeffekt die Preise als 2-stellig angezeigt

Hi Soner!

Danke für die Ergänzungen!
Deine Änderungen lade ich gerne auf die Startseite hoch, aber erst am Wochenende.

Rein aus Interesse: Wann im Büroalltag braucht man eine Buchungshilfe-Datei? (Minimum-Profil)

[Soner]

...
Rein aus Interesse: Wann im Büroalltag braucht man eine Buchungshilfe-Datei? (Minimum-Profil)

Ich stelle mir als Buchungshilfe vor, dass die Rechnungssummen korrekt erkannt werden, z.B. bei DATEV werden die gescannten oder normale PDF-Rechnungen ziemlich gut erkannt, aber man muss trotzdem kontrollieren. Bei E-Rechnungen sind die Summen dann 100% richtig. Wenn irgendwann irgendeine E-Rechnung doch falsch war, dann kann man es durch offene Posten erkennen.
Eigentlich reicht normale Format auch als Buchungshilfe. Jemand wollte es ohne Positionen haben und ich hatte das minimale Format damals im Beispielordner gesehen und jetzt als Option im Programm angeboten, man kann Formate in Einstellungen umschalten.
Ich habe noch keine Zeit gehabt, das ganze mit verschiedenen Steuersätze zu kontrollieren. Ich mache es und falls es zu melden gibt, dann tue ich es hier.

[Jorg3000]

Habe die neue Version, jetzt inkl. Minimum-Profil, wieder auf Seite 1 oberster Beitrag hochgeladen.
Damit der Validator beim Minimum-Profil aufhörte zu meckern, habe ich für das Minimum-Profil einen weiteren XML-Teil ausgeklammert (Umsatzsteueraufschlüsselung). Jetzt wird es als valide gemeldet.

Die Hinweise kriegt man wohl nicht ganz weg, weil es teilweise widersprüchlich zu sein scheint.
Nimmt man z.B. das Lieferdatum beim Minimum-Profil mit rein, wird gemeckert, dass es bei Minimum nicht erlaubt ist (Fehler). Nimmt man es dann raus, erscheint der Hinweis, dass der Mutter-Knoten nicht leer sein sollte (nur Hinweis, kein Fehler). Nimmt man den leeren Mutter-Knoten auch noch raus, wird aber gemeckert, dass er mindestens 1x enthalten sein muss (Fehler).
Habe es nun so gemacht, dass nur der widersprüchliche Hinweis erscheint (kein Fehler).

[Sieben]

Es scheint sich um eine richtig gut gemachte Richtlinie zu handeln. Was bin ich froh, dass ich in Rente bin...

[Jorg3000]

Danke für den Aufhänger.
Das verleitet mich zu einem Kommentar zu XML, wobei ich wenigstens anfangs versuchen möchte, einen positiven Satz zu formulieren:
Dadurch, dass ein abschließender XML-Tag genauso heißen muss wie der Start-Tag, ist XML sehr robust, denn man würde Übertragungsfehler und Formatfehler leicht entdecken. Und bei der Interpretation (manuell oder per Software) ist fast ausgeschlossen, dass man sich z.B. verspringt und in einer abschließenden Klammer irrt.

Schaut man sich als Mensch ein ZUGFeRD-XML-Beispiel an, erkennt man zunächst gar keine Daten. Aber ging es nicht darum? Die Rechnungsdaten machen nur ungefähr 1% aus, die XML-Tags 99 Prozent.
Es sieht aus wie der wahrgewordene, feuchte Traum eines Bürokraten. Es ist so stark verklausuliert, dass niemand zu widersprechen wagt. Quasi die Digitalisierung von Amtsdeutsch.

In den letzten Tagen ist mir dieses schöne Beispiel aufgefallen, das lediglich ein Lieferdatum definiert.

Code: Alles auswählen

    <ram:ApplicableHeaderTradeDelivery>
      <ram:ActualDeliverySupplyChainEvent>
        <ram:OccurrenceDateTime>
          <udt:DateTimeString format="102">20241231</udt:DateTimeString>
        </ram:OccurrenceDateTime>
      </ram:ActualDeliverySupplyChainEvent>
    </ram:ApplicableHeaderTradeDelivery>

Ganz schlank hat man im Datum auf die Trennstriche verzichtet, um 2 Bytes zu sparen - aber es war offenbar nicht zu peinlich, drumherum ein 300 Byte "Konstrukt" anzuhäufen, das keinen anderen Sinn hat, als dieses eine Lieferdatum zu beinhalten. Chapeau!
Wenn die deutschen Macher der Spezifikation vorhatten, damit beim Verkomplizierungswettbewerb anzutreten - also meine Stimme hätten sie!

Die 90er haben angerufen und wollen ihr Datenformat zurück.
Heute, längst in der Zeit eines schlanken JSON-Formats, hat es mich zuerst ein bisschen wütend gemacht, dass ausgerechnet das verstaubte und aufgeblähte XML jetzt in 2025 zu einer gesetzlichen Pflicht erhoben wird und somit digital zementiert wird.
Um einen Autovergleich zu bemühen: Es ist wie Brötchenholen mit einem SUV. Um ein paar Gramm Teig auf den Tisch zu bekommen, werden jedesmal zwei Tonnen Stahl durch die Stadt getrieben.

Aber ... es ist sicher! Wenn die Brötchen (die interpretierten Nutzdaten) nach dem ganzen Aufwand wirklich vorliegen, darf man sich relativ sicher sein, dass sie nicht unter die Räder gekommen waren.
Und somit kann ich mich wieder abregen: Trotz des Format-Overheads können wir nun erstmals die Rohdaten als solche gemäß einem gemeinsamen Standard (Namespace) digital übertragen.

Auch wenn z.B. 12 kb XML eigentlich etwas viel Verpackung ist für wenige hundert Bytes Nutzdaten, so ist es dennoch besser, als gemailte Rechnungs-PDFs nochmal von Hand zu erfassen.
Und es ist sowieso erheblich besser als Blätter Papier einzuscannen, mit OCR lediglich auf das Beste zu hoffen und es manuell nachbearbeiten zu müssen.

Man darf nicht vergessen, dass wir heute nur knapp der Zeit entronnen sind, wo man Unterlagen ausdruckte (sehr hübsch), dann faxte (sehr praktisch), dort einscannte (muss ja), vielleicht nochmal mailte (sehr modern), dann manuell übertrug (erforderlich), dann wieder ausdruckte (Aufbewahrungspflicht) - und vielleicht nochmal faxte.

Schönen Sonntag, Jörg

[KoBraSoft]

Es sieht aus wie der wahrgewordene, feuchte Traum eines Bürokraten. Es ist so stark verklausuliert, dass niemand zu widersprechen wagt. Quasi die Digitalisierung von Amtsdeutsch.

Zugferd ist dann

der wahrgewordene, feuchte Traum eines Bürokraten

im Quadrat.
Die Doku hat 129 Seiten dazu 153 Seite Technischer Anhang
Der Inhalt ist eine Mischung aus Bürokratendeutsch und Politikerfloskeln

Hier ein Ausschnitt aus der Zugferd Dokumentation

1. FACTUR-X 1.0.06 DE.pdf Kaptel 5 Informationskonsistenz zwischen lesbarer und strukturierter Repräsentanz,
Prüfpfad und gute Praktiken

•Die Verwendung eines Visualisierungstools für strukturierte Datendateien, wie es bei vollständig
strukturierten elektronischen Rechnungen der Fall ist, ermöglicht die Sichtprüfung der Kohärenz
von Informationen zwischen strukturierter Datendatei und PDF-Repräsentanz.
•Die Verwendung eines Tools zur Validierung der Kohärenz von Informationen zwischen
strukturierter Datendatei und PDF-Repräsentanz. Dies könnte beispielsweise die Überprüfung
einschließen, ob jedes Datenelement in der strukturierten Datei auch in der PDF-Darstellung
enthalten ist.

Die haben sehrwohl gemerkt, dass die pdf und die xml ggf. nicht zusammenpassen. Die meinen ernsthaft der Rechnungsempfänger sollte in jeder Zugferdrechnung die pdf mit der xml vergleichen und prüfen.
Ein Tool " zur Validierung der Kohärenz von Informationen zwischen strukturierter Datendatei und PDF-Repräsentanz" kann es gar nicht geben da jede Firma sein eigenes pdf Layout hat.
Ich überlege ernsthaft die Annahme und den Versand von Zugferdrechnungen zu verweigern (und dies auch meinen Kunden zu empfehlen) da laut https://www.bundesfinanzministerium.de/ ... onFile&v=1
Randzahl 24

E-Rechnungen können sowohl in einem rein strukturierten als auch in einem hybriden Format
erstellt werden.

und Randzahl 27

Welches – zulässige – Format verwendet wird, ist eine zivilrechtliche Frage, die nur zwischen
den Vertragsparteien zu entscheiden ist.

[kirchfritz]

E-Rechnungen können sowohl in einem rein strukturierten als auch in einem hybriden Format
erstellt werden.

Das heißt übersetzt:
Eine E-Rechnung ist entweder eine reine XML-Datei(also eine X-Rechnung) oder eine ZUGFeRD-PDF-Datei mit eingebettetem XML.

Wenn Du jetzt der ZUGFeRD-PDF-Datei wegen mangelnder Kohärenz nicht vertraust, und sogar die Annahme grundsätzlich verweigern würdest, wie kannst Du dann der reinen XML-Datei ohne Sichtprüfung vertrauen?

[charlytango]

Ich habe mit stetig wachsendem Grauen mitgelesen und gottseidank muss ich mich nicht mehr damit auseinandersetzen

Wenn Du jetzt der ZUGFeRD-PDF-Datei wegen mangelnder Kohärenz nicht vertraust, und sogar die Annahme grundsätzlich verweigern würdest, wie kannst Du dann der reinen XML-Datei ohne Sichtprüfung vertrauen?

Gar nicht, aber darum geht es @KoBraSoft wohl nicht. Sein Argument zielt eher in Richtung Geschäftsprozess und Aufwand.
Formal kann man das XML ja automatisiert prüfen, inhaltlich aber nie.
(Außer man kann es mit internen Bestelldaten aus der Warenwirtschaft vergleichen, aber selbst da wird es ohne menschliche Kontrolle eng)

Wenn also jede PDF-Rechnung mit eingebettetem XML manuell auf Kohärenz überprüft werden muss, dann steigt der Personal-Aufwand dramatisch. Von der korrekten Aufbewahrung der Daten einmal ganz abgesehen. Papier liegt die gesetzliche Aufbewahrungsfrist ohne weitere Wartung nur herum. Bei Daten geht das nicht mehr so einfach.

Es geht also IMHO gar nicht um die Vereinfachung der Kommunikation zwischen Firmen sondern um die mögliche automatisierte Kontrolle.