E-Rechnung aus FileMaker: die ZUGFeRD Suite
Ab dem 1. Januar 2027 müssen Unternehmen in Deutschland ihre Rechnungen an andere Unternehmen elektronisch stellen, ab 2028 ausnahmslos alle. Wer seine Rechnungen aus FileMaker schreibt, braucht dafür keinen Umbau seiner Lösung. Die ZUGFeRD Suite hängt sich daneben, liest den Beleg über eine Zuordnung und liefert ZUGFeRD-PDF oder XRechnung zurück. Ein Aufruf, zwei Formate, alles auf dem eigenen Server.
Die Frist
Seit 2025 muss jedes Unternehmen elektronische Rechnungen empfangen können. Für das Ausstellen gilt eine Staffel: ab 1. Januar 2027 für Unternehmen mit mehr als 800.000 Euro Vorjahresumsatz, ab 1. Januar 2028 für alle. Eine PDF per Mail zählt dann nicht mehr als Rechnung. Gefordert ist ein strukturiertes Format nach der europäischen Norm EN 16931, in Deutschland in zwei Ausprägungen:
- ZUGFeRD (international Factur-X): eine PDF, wie man sie kennt, mit dem XML im Anhang. Der Mensch liest die PDF, das Buchhaltungsprogramm das XML.
- XRechnung: reines XML, die Form, die Behörden und viele Konzerne verlangen.
Beide beschreiben dieselbe Rechnung. Was sich unterscheidet, ist die Verpackung.
Was die Suite macht
Die ZUGFeRD Suite ist eine FileMaker-Datei plus eine kleine Serverkomponente in PHP. Das Rechnungsprogramm ruft ein Script auf, mit drei Angaben: Belegart, Belegnummer, Format.
Der Aufruf ist ein Script ausführen auf ZF_Beleg_erzeugen in der Suite, der Parameter ein kleines JSON: "beleg" : "Rechnung", "nr" : "RE100001", "format" : "zugferd".
Die Suite sucht den Beleg, liest die Werte, schickt sie an den Server, holt das Ergebnis ab und legt es in einen Container am Beleg. Für die XRechnung derselbe Aufruf mit "format" : "ubl". Gutschriften sind eine eigene Belegart mit Typcode 381 und werden als Gutschrift gebaut, in der XRechnung als CreditNote.
Das Ergebnis läuft vor der Ausgabe gegen die Prüfregeln der Norm. Was die Suite herausgibt, hat die Schematron-Prüfung der EN 16931 und für die XRechnung zusätzlich die Regeln der KoSIT bestanden. Das Profil ist EN 16931, also der volle Umfang: Positionen mit Rabatt, Versandkosten, Gesamtrabatt, mehrere Steuersätze, innergemeinschaftliche Lieferung, Export.
Die Zuordnung: einmal einrichten
Die Verbindung zur eigenen Lösung heißt Zuordnung. Sie sagt der Suite, wo jeder Wert der E-Rechnung steht. Eingerichtet wird sie auf einer Seite im Webviewer, ein Reiter je Belegart, die Werte in fünf Bereichen: Beleg, Verkäufer, Käufer, Zahlung, Positionen.
Jeder Wert ist ein FileMaker-Ausdruck, der im Kontext des Belegs ausgewertet wird:
- Belegnummer:
RECHNUNG::#RechnungNr - Straße:
Trim ( GLOBAL::Straße & " " & GLOBAL::Hausnummer ) - Währung:
If ( IsEmpty ( RECHNUNG::Währung ) ; "EUR" ; RECHNUNG::Währung ) - USt-IdNr. des Kunden:
ADRESSEN::#UStID_Nr - Einheit:
'C62'
Ein Feld, eine Formel, eine Konstante, derselbe Mechanismus. Bezugsfelder gehen, weil FileMaker sie in einem Ausdruck ohnehin auflöst. Hilfsfelder in der eigenen Lösung braucht es nicht, Layouts mit Objekten auch nicht: je Belegart ein leeres Layout auf dem Beleg, mehr nicht. Die Positionen kommen aus einer SQL-Abfrage, die die Seite aus der Zuordnung zusammensetzt und unter der Tabelle anzeigt.
Der KI-Vorschlag nimmt der Zuordnung die Fleißarbeit ab. Ein Knopf schickt die Namen und Typen der Felder an den eigenen Server, der fragt ein Sprachmodell, und je Wert kommt ein Ausdruck mit Begründung zurück. Bei einer Warenwirtschaft mit mehr als dreihundert Feldern waren das im Test 29 Vorschläge von der KI, 14 über den Namen entschieden, 5 offen, in neun Sekunden. Was sich gegenüber dem gespeicherten Stand ändert, trägt die Marke „Neu" oder „Geändert", daneben der alte Wert und ein Knopf „zurück". Belegdaten verlassen dabei das Haus nicht, nur Feldnamen. Der API-Schlüssel gehört dem Kunden.
Die Vorschau zeigt je Zeile den Wert des echten Belegs, grün wenn gefüllt, rot wenn leer. Belegnummer eintragen, Vorschau, dann „Test PDF" und „Test UBL": das ist der Weg von der Zuordnung bis zur ersten E-Rechnung, in einer Sitzung.
Wo die Daten bleiben
Die Serverkomponente läuft beim Kunden, auf dem eigenen Webserver oder beim eigenen Hoster. Es gibt keinen Server des Herstellers, keine Cloud dazwischen, keine Telemetrie. Der Lizenzschlüssel wird auf dem Server des Kunden geprüft, ohne Verbindung nach außen. Wer eine Testversion nutzt, bekommt einen Schlüssel mit Ablaufdatum; danach bleibt die Zuordnung erhalten, nur das Bauen hört auf.
Das ist bewusst so. Rechnungen enthalten Personendaten, und der einfachste Weg, damit sauber umzugehen, ist der, bei dem sie den Betrieb nicht verlassen.
Der Einbau
Was ein FileMaker-Entwickler dafür tut, passt auf eine Hand:
- Das PHP-Paket auf den Webserver legen, die Adresse im Reiter Info eintragen.
- Die Kundendatei als externe Datenquelle anbinden, die Tabellenauftreten in den Graphen der Suite ziehen.
- Je Belegart ein leeres Layout.
- Zuordnung: KI-Vorschlag, durchsehen, Vorschau, speichern.
- Ein Knopf auf der Rechnung, der das Script ruft.
Die Anleitung dazu liegt in der Suite selbst, als Reiter neben der Zuordnung, mit einer Fehlertabelle für den Fall, dass eine Meldung kommt. Ein Teil davon ist so geschrieben, dass man ihn an die Buchhaltung weitergeben kann.
Für wen
Für Unternehmen, die ihre Rechnungen aus FileMaker schreiben und die Frist einhalten wollen, ohne ihr Rechnungsprogramm anzufassen. Für FileMaker-Entwickler, die das für ihre Kunden einbauen; dafür gibt es eine Entwicklerlizenz. Und für alle, die bei der E-Rechnung wissen wollen, wo ihre Daten sind.
Testversion und Lizenz: info@maro-programmierung.de, https://filemaker-experts.de