ZUGFeRD mit altem DataFlex-System und KI-Unterstützung

Ein Praxisbericht …

Stand: 8. September 2026

Ausgangslage

Ein seit vielen Jahren produktiv eingesetztes DataFlex-ERP-System erzeugt Rechnungen über textgesteuerte Formulare und den vorhandenen F2P-Druckprozessor. Die sichtbare Rechnung als PDF funktionierte bereits.

Neu benötigt wurde eine strukturierte elektronische Rechnung nach EN 16931, eingebettet als factur-x.xml in ein ZUGFeRD-/Factur-X-PDF.

Die Erweiterung musste sich dabei in die vorhandene Architektur einfügen.

Beteiligte Rollen

• Frigyes brachte die Kenntnis des DataFlex-Systems, der Kundenvarianten, der Formulare und des produktiven Ablaufs ein. Er führte außerdem die Tests im echten Kundensystem über TeamViewer durch.
• Codex für DataFlex untersuchte die vorhandenen Programme und Formulare, implementierte die XML-Seite, kompilierte die lokalen Programme und prüfte die erzeugten Dateien.
• Claude/F2P-Agent bearbeitete in einer getrennten Entwicklungsumgebung die PDF-Seite: PDF/A-3, Einbettung der XML, XMP-Metadaten und Fehlerbehandlung.

Die Arbeit bestand damit nicht aus einem einzelnen Prompt, sondern aus einer Zusammenarbeit zwischen Fachwissen, mehreren spezialisierten KI-Arbeitssträngen und realen Tests.

Der erste Entwicklungsstrang: XML aus DataFlex

Ausgewählte Kommunikation

Frigyes

Wir wollen mit dem Programm RNDXDE eine in PDF integrierbare XML-Datei erstellen.
Wir arbeiten nur mit der Version FELD in C:\DEV.
Zur Erstellung von XML haben wir bereits in AUSLSN eine Hintertür eingebaut:
Wenn das Formular mit X startet, springen wir zu xrechtest, schau dort.

Codex

Die vorhandene Druckarchitektur wird nicht ersetzt. Für den Test entstehen ein eigenes XML-Formular und eine getrennte Rechnungsvorlage. Erst wenn XML und PDF stabil sind, wird der Ablauf in die bestehende Formularauswahl eingebunden.

Frigyes

go

Codex

Der produktionsnahe Einstieg ist vorhanden. Entscheidend war nun, RNDXDE und das X-Formular so zu ergänzen, dass die normale Rechnung weiterhin über RNDD und das R-Formular läuft.

Der zweite Entwicklungsstrang: F2P und PDF/A-3

Die PDF-Erweiterung wurde bewusst an einen getrennten F2P-Agenten übergeben. Dafür entstand ein reproduzierbares Übergabepaket mit:

• einer genauen technischen Anforderung,
• dem vollständigen Rechnungsformular,
• einer real erzeugten EN16931-Test-XML,
• klaren Abnahmekriterien.

Der F2P-Agent implementierte und prüfte:

• PDF/A-3b,
• den Anlagenamen factur-x.xml,
• den MIME-Typ text/xml,
• den PDF-Namensbaum EmbeddedFiles,
• den Eintrag /AF im PDF-Katalog,
• /AFRelationship /Alternative,
• Factur-X-XMP-Metadaten mit Profil EN 16931.

Die Rückmeldung aus diesem Arbeitsstrang war besonders wertvoll: Die PDF-Seite war fertig, aber die Profilkennung in der DataFlex-XML war für EN 16931 noch falsch.

Die eingesetzten Prüfwerkzeuge

Die beiden Prüfprogramme waren nicht von Frigyes vorgegeben. Der F2P-Agent suchte selbstständig nach geeigneten, etablierten Werkzeugen, richtete sie in seiner Entwicklungsumgebung ein und verwendete sie für reproduzierbare Prüfungen:

• veraPDF ist ein unabhängiger Open-Source-Validator für PDF/A. Er untersucht nicht nur, ob eine PDF geöffnet werden kann, sondern kontrolliert die technischen Regeln des Archivstandards. Im Projekt wurde damit insbesondere PDF/A-3b geprüft – die Variante, die das Einbetten der Rechnungs-XML in die PDF erlaubt.
• Mustangproject beziehungsweise Mustang-CLI ist ein Open-Source-Werkzeug zur Erzeugung und Validierung elektronischer Rechnungen. Es prüft bei einer Factur-X-/ZUGFeRD-Datei sowohl den PDF-Container als auch die eingebettete XML gegen Schema, Profil und Geschäftsregeln von EN 16931.

Gerade die Kombination beider Werkzeuge war wichtig. So konnte die DataFlex-Seite gezielt korrigiert werden.

Integration beim Kunden

Beim Kunden lag das aktuelle Rechnungsformular in \df\forms\r.1. Daraus wurde das produktionsnahe renr.all durch Codex erstellt.

Archiv-, Versand- und PDF-Ausgaben wurden für den Test in neutrale Verzeichnisse umgeleitet:

C:\dev\umi\pdf
C:\dev\umi\archiv
C:\dev\umi\versand

Der Datenaustausch sowie das Anlegen von Dateien und Ordnern im echten Kundensystem wurden durch Frigyes durchgeführt.

Die KI-Agenten hatten zu keinem Zeitpunkt direkten Zugriff auf das Kundensystem.

Mengeneinheiten: von ST und M zu UNECE-Codes

Im sichtbaren Formular stehen Einheiten wie ST, KG, M oder L. EN 16931 erwartet im Attribut unitCode jedoch standardisierte UNECE-Codes.

Die Analyse des bestehenden DataFlex-Codes zeigte:

ARTIKEL.VERKEINH enthält den stabilen internen Schlüssel. MEINHEITM wird über die kundenspezifische MYERRS.DAT in den sichtbaren Text übersetzt.

Die XML-Ausgabe verwendet dafür XUNITCODE. Unbekannte oder noch nicht eindeutig zugeordnete Einheiten fallen zunächst auf C62 zurück.

Die Kurzbezeichnung P muss vor einer endgültigen Zuordnung fachlich geklärt werden. Sie könnte beispielsweise „Paar“ oder „Packung“ bedeuten.

Nachdem Codex gemeldet hatte, dass seine Arbeit erledigt war

Ausgewählte Kommunikation

Frigyes

Ich arbeite mit TeamViewer auf dem echten System. Aber probieren wir zuerst lokal in
dev. Mit Rechnung 47R6428/01 habe ich selbst einen Testlauf gestartet; die Ergebnisse
liegen in \dev\umi.

Codex

Der lokale Test war erfolgreich: 14 Positionen wurden als wohlgeformte XML erzeugt, alle Mengen waren numerisch und alle verwendeten Stück-Einheiten hatten C62. Die XML war in Archiv-, Versand- und Endkunden-PDF bytegleich eingebettet.

Frigyes

Jetzt habe ich die Programme und die Formulare beim Kunden installiert und dort auch
einen Test gestartet.
Kannst du das echte 66r8879_08.pdf testen?

Codex

Die neue echte Ausgabe 66R8879_08.pdf enthielt eine wohlgeformte XML mit elf Positionen. Mengen und C62 waren korrekt. Die eingebettete factur-x.xml war bytegleich zur separaten XML; PDF/A-3b-, Factur-X- und /AFRelationship-Metadaten waren vorhanden.

Wichtige Dateien der aktuellen Lösung

• C:\dev\feld\auslsn.FRM – Umschaltung auf den XML-Ablauf
• C:\dev\feld\rndXde.FRM – tatsächlich gestartetes XML-Programm
• C:\dev\feld\drincf2X.fri – Formular- und XML-Ausgabe
• C:\dev\pkgold\DOCf2x.FRI – Aufbereitung der Rechnungspositionen
• C:\dev\forms\xenr.all – EN16931-XML-Formular
• C:\dev\forms\renr.all – sichtbares Rechnungsformular und F2P-Steuerung

Warum der KI-Einsatz hier interessant ist

Das Projekt zeigt eine Form von KI-Unterstützung, die weit über das reine Generieren von neuem Code hinausgeht:

• Ein altes, kaum dokumentiertes System wurde aus Quellcode, Formularen und echten Ausgabedateien rekonstruiert.
• Fachliche Hinweise des Entwicklers wurden unmittelbar mit technischen Befunden verbunden.
• Änderungen wurden über DataFlex, Formularsprache, F2P, PDF-Struktur und externe Validatoren hinweg verfolgt.
• Ein zweiter KI-Agent konnte anhand eines Übergabepakets unabhängig am F2P-Teil arbeiten und eine strukturierte Rückmeldung liefern.
• Reale Testrechnungen ersetzten Annahmen durch überprüfbare Ergebnisse.

Die KI ersetzte dabei nicht die Erfahrung des Entwicklers. Erst die Kombination aus Systemkenntnis, gezielter Codeanalyse, getrennten Agentenaufgaben und Tests im echten Arbeitsablauf führte zu einem belastbaren Ergebnis.

Alle Arbeitsschritte wurden dokumentiert und nachvollziehbar versioniert auf GitHub abgelegt, damit sich spätere Entwickler möglichst schnell in die Arbeit einarbeiten. Wobei ich inzwischen überzeugt bin, dass dieser Code künftig überwiegend von KI-Agenten weiterentwickelt wird.

Die Qualität der geleisteten Arbeit war sehr gut. Besonders beeindruckend war jedoch die enorme Zeitersparnis gegenüber einer vergleichbaren Umsetzung ohne KI-Unterstützung.

Wir haben bereits XML-Rechnungen sowohl für Italien als auch für Polen implementiert. Der damalige Arbeitsaufwand war im Vergleich etwa 10- bis 100-fach höher.

Besonders beeindruckt hat mich, dass Claude selbstständig geeignete Werkzeuge zur PDF- und XML-Prüfung gesucht und eingesetzt hat.

Codex wiederum hat die Formulare und Programme so lange weiter analysiert und geändert, bis das erzeugte Ergebnis tatsächlich korrekt war.