Die Umstellung auf E-Rechnungen in den Formaten ZUGFeRD/Factur-X und XRechnung stellt FileMaker-Anwendungen vor große Herausforderungen. Die Gründe dafür sind vor allem technischer Natur: Ohne Plug-ins oder externe Unterstützung ist FileMaker bei der Erzeugung, Verarbeitung und Validierung von XML- und PDF-Dokumenten stark eingeschränkt.
Die einzige native Möglichkeit zur XML-Erzeugung in FileMaker ist ein XSLT-Prozessor der Version 1.0 – eine Technologie aus dem November 1999. Weiterentwicklungen wie XSLT 2.0 (Januar 2007) und XSLT 3.0 (Juni 2017) wurden nicht in FileMaker integriert. In der Version FileMaker 2024 wurde der XSLT-Prozessor zwar aktualisiert, blieb jedoch bei der Spezifikation 1.0. Das ist bedauerlich, da für die inhaltliche Validierung von E-Rechnungen modernere Schematron-Regeln benötigt werden. Zudem ist die Validierung durch eine XSD nativ nicht möglich. Eine verlässliche, vollständig native Erzeugung von CII für ZUGFeRD/Factur-X sowie CII oder UBL für XRechnung ist mir deshalb nicht bekannt.
Hinzu kommt ein grundsätzliches Strukturproblem: Der native XML-Export von FileMaker liefert mit FMPXMLRESULT im Wesentlichen einen flachen relationalen Ergebnissatz. Datensätze werden als ROW, Felder als COL und deren Inhalte als DATA ausgegeben. Wiederholungen und Bezugsdaten lassen sich damit zwar exportieren, die mehrstufige fachliche Baumstruktur einer E-Rechnung kann jedoch so unmöglich abgebildet werden.
Einige FileMaker-Entwickler nutzen Textfunktionen, um XML zu erzeugen. Auch wenn XML technisch gesehen in Textdateien gespeichert wird, handelt es sich dabei nicht um normalen Text, sondern um eine Auszeichnungssprache zur strukturierten Darstellung von Inhalten. Überspitzt gesagt: XML ist kein Text! Die Erstellung von XML mithilfe von Textfunktionen ist problematisch und sollte vermieden werden:
Ausführlicher behandle ich dieses Thema im Blogbeitrag „Warum man E‑Rechnungs‑XML niemals mit Textfunktionen zusammenbauen sollte“ →
Das sind alles in allem keine guten Voraussetzungen für die Umsetzung der neuen Technologie.
Ein Blick auf die PDF-Ausgabe von FileMaker zeigt schnell, dass es kaum Anpassungsmöglichkeiten gibt. Daher überrascht es nicht, dass FileMaker die Ausgabe im PDF/A-3-Format nicht unterstützt. Für eine hybride ZUGFeRD-/Factur-X-Rechnung ist jedoch genau diese Ausgabe als PDF/A-3 mit eingebettetem Rechnungs-XML erforderlich.
PDF/A-3 ist ein spezielles PDF-Format, das nach einer ISO-Norm für die Langzeitarchivierung entwickelt wurde. Es gewährleistet, dass Rechnungen auch nach vielen Jahren noch lesbar bleiben.
Während andere Anwendungen, wie zum Beispiel LibreOffice, diese Funktionalität bieten, fehlt sie bei FileMaker. Das sind keine guten Voraussetzungen, um hybride ZUGFeRD-/Factur-X-Rechnungen direkt mit FileMaker-Bordmitteln zu erstellen.
XML ist eine Auszeichnungssprache, die Dokumente in einer Baumstruktur beschreibt. Das Abbilden solcher Baumstrukturen in einer relationalen Datenbank wie FileMaker ist jedoch aufwändig. Die Informatik bietet hierfür eine passende Lösung: NoSQL-Datenbanken.
Glücklicherweise verfügt FileMaker über Funktionen, die es ermöglichen, solche Strukturen abzubilden: die JSON-Funktionen. Diese Funktionen bieten eine praktikable Alternative, um Daten in hierarchischen Strukturen zu speichern. Es liegt daher nahe, E-Rechnungen in einem JSON-Format zu speichern, um von den Vorteilen einer flexiblen und strukturierten Datenrepräsentation zu profitieren.
Meine Lösungen zeigen, dass sich trotz der schwierigen Ausgangslage ZUGFeRD-/Factur-X-Rechnungen und XRechnungen aus FileMaker heraus erstellen lassen. Dafür sind moderne Technologien erforderlich, die FileMaker selbst nicht bereitstellt. Dazu gehören ein fortschrittliches XML-Parsing, aktuelle XSLT-Prozessoren sowie eine schema-basierte Ein- und Ausgabe über strukturierte JSON-Daten. Um diese Lücken zu schließen, greife ich auf andere Programmiersprachen wie Python, Java und Rust zurück.