Konverter-Software entwickeln

Wann Sie Konverter-Software entwickeln lassen sollten

Eine einmalige Umwandlung löst ein Problem von gestern. Ein Konverter löst ein Problem, das jeden Monat wiederkommt.

Sinnvoll wird das, sobald einer dieser Punkte auf Sie zutrifft:

• Ihr Vorsystem lässt sich absehbar nicht ändern, erzeugt aber keine E-Rechnungen.
• Regelmäßig kommen Rechnungsdaten von Dritten herein, etwa von Subunternehmern oder Filialen.
• Die Daten sind zu sensibel, um die Umwandlung extern einzukaufen.
• Gegenüber einer Prüfung müssen Sie jederzeit zeigen können, wie aus Quelle A das Ergebnis B wurde.

Trifft nichts davon zu, reicht meist die einfachere Umwandlung Ihrer Rechnungen als Dienstleistung. Auch das sage ich Ihnen offen.

Die vier Stufen einer sauberen Pipeline

Jeder Konverter besteht aus denselben vier Stufen. Ob daraus ein brauchbares oder ein ärgerliches Werkzeug wird, entscheidet sich daran, wie klar diese Stufen getrennt sind.

Einlesen

Zuerst wird die Quelldatei gelesen und in eine einheitliche Zwischenstruktur überführt. Diese Trennung zahlt sich später aus: Kommt ein zweites Quellformat dazu, erweitern wir nur diese Stufe. Alles Übrige bleibt unangetastet.

Zuordnen

Anschließend wird festgelegt, welches Quellfeld welchem Element der EN 16931 entspricht. Diese Regeln gehören nicht in den Code, sondern in eine Konfiguration, die Sie selbst lesen und ändern können. Neben einfachen Zuordnungen sind dabei auch Umrechnungen, Standardwerte und Bedingungen möglich.

Prüfen

Danach validiert die Pipeline gegen die offiziellen Regeln. Zusätzlich prüfe ich fachlich nach: Stimmen die Summen? Passt der Steuerbetrag zum Satz? Ist die Leitweg-ID plausibel? Diese zweite Ebene fängt Fehler ab, die formal korrekt und trotzdem falsch sind.

Ausgeben und protokollieren

Zum Schluss landen die fertigen Dateien dort, wo sie hinsollen. Parallel entsteht ein Protokoll mit Eingangsdatei, Ergebnis, Zeitpunkt und Hinweisen. Bei Rückfragen aus einer Betriebsprüfung ist dieses Protokoll oft wertvoller als die Rechnungen selbst.

Fehlermeldungen, die man wirklich lesen kann

Der offizielle Validator meldet Fehler in einer Sprache, die für Entwickler gemacht ist. Eine typische Meldung besagt sinngemäß, dass die Regel BR-DE-15 verletzt sei. Was das bedeutet, weiß in Ihrem Haus niemand.

Deshalb übersetze ich diese Meldungen. Aus BR-DE-15 wird dann der Hinweis, dass die Leitweg-Identifikationsnummer fehlt, die bei Rechnungen an öffentliche Auftraggeber Pflicht ist und die Ihr Kunde Ihnen mitteilen muss. Die zugrundeliegenden Regelwerke veröffentlicht die KoSIT im XÖV-Portal.

Das klingt nach einer Kleinigkeit. In der Praxis entscheidet es darüber, ob Ihre Fachabteilung mit dem Werkzeug arbeitet oder ob jedes Problem bei der IT landet.

Formatänderungen ohne Umbau

Die Regeln der XRechnung ändern sich zweimal im Jahr. Wer Konverter-Software entwickeln lässt, sollte das von Anfang an einplanen, sonst wird jede Anpassung zum Projekt.

Meine Antwort darauf ist eine klare Trennung: Die Normlogik liegt getrennt von Ihrer Mapping-Logik. Ein neuer Stand wird eingespielt, Ihre Regeln bleiben unberührt. Damit können Sie eine Aktualisierung selbst einspielen, ohne mich anzurufen.

Betrieb, Rechte und Quellcode

Der Konverter läuft bei Ihnen. Als Dienst auf einem Server im Haus, in Ihrer Cloud oder als kleines Programm auf einem Arbeitsplatz – je nachdem, was zu Ihrer Umgebung passt. Rechnungsdaten müssen dafür an niemanden herausgehen.

Am Ende bekommen Sie vier Dinge:

• den vollständigen Quellcode, der Ihnen gehört
• die Mapping-Regeln in lesbarer Konfigurationsform
• eine Dokumentation zum Ergänzen neuer Felder und Formate
• Testfälle, mit denen Sie nach jeder Änderung prüfen, ob noch alles stimmt

Diese Testfälle unterschätzen viele. Sie sind der Grund, warum Sie später ohne Angst etwas ändern können.

Welche Quellformate möglich sind

Praktisch alle, sofern das Format dokumentiert ist oder Beispieldateien vorliegen. Häufig sehe ich CSV-Dateien und feste Satzlängen, dazu XML in beliebiger Struktur, JSON, Excel-Tabellen sowie direkte Datenbankabfragen.

Schwierig wird es nur bei Formaten, die niemand mehr beschreiben kann und für die es auch keine verlässlichen Beispiele gibt. Dann klären wir das zuerst, bevor ein Angebot entsteht.

Aufwand und nächster Schritt

Ein Konverter für ein Quellformat mit überschaubaren Sonderfällen ist meist in drei bis fünf Wochen einsatzbereit. Mehrere Quellformate oder viele Ausnahmen verlängern das entsprechend.

Sinnvoll ist es außerdem, gleich mitzudenken, wohin die geprüften Dateien anschließend gehen. Häufig schließt sich die revisionssichere Ablage direkt an, manchmal auch der Versand über Ihr ERP. Wer Konverter-Software entwickeln lässt und beides von Beginn an berücksichtigt, spart sich einen zweiten Umbau.

Betrieb im Alltag

Ein Konverter wird nur dann genutzt, wenn er im Alltag nicht auffällt. Deshalb lege ich Wert auf drei Dinge, die selten in Anforderungslisten stehen.

Wiederholbarkeit. Derselbe Eingang muss dasselbe Ergebnis liefern, auch nach einem Neustart. Klingt selbstverständlich, scheitert in der Praxis oft an Zeitstempeln oder Zufallsnummern.

Wiederaufnahme. Bricht ein Lauf ab, darf er nicht von vorn beginnen. Er merkt sich, was fertig ist, und macht dort weiter.

Benachrichtigung. Läuft etwas schief, erfährt es jemand. Eine Mail an die richtige Adresse genügt meist und verhindert, dass Fehler tagelang unbemerkt bleiben.

Übergabe und Einarbeitung

Zum Abschluss zeige ich Ihrem Team, wie das Werkzeug arbeitet. Dabei geht es weniger um Bedienung als um Verständnis: Was passiert bei einem Fehler? Wo ändere ich eine Regel? Wie prüfe ich, ob eine Änderung etwas kaputt gemacht hat?

Danach können Sie eigenständig arbeiten. Genau darin liegt der Unterschied, wenn Sie Konverter-Software entwickeln lassen statt eine Dienstleistung einzukaufen: Sie sind anschließend nicht auf mich angewiesen.

Melden Sie sich trotzdem, wenn ein neues Quellformat dazukommt oder sich die Norm ändert. Beides lässt sich meist in wenigen Tagen erledigen.

Woran Sie einen guten Konverter erkennen

Bevor Sie Konverter-Software entwickeln lassen, lohnt ein Blick auf die Kriterien, an denen sich ein solches Werkzeug messen lassen muss. Vier davon halte ich für entscheidend.

Er erklärt sich selbst. Wer eine Regel sucht, findet sie ohne Handbuch. Die Konfiguration ist so benannt, dass ein Fachanwender sie versteht.

Er schweigt nie. Jede Datei, die nicht durchläuft, taucht in einer Liste auf. Stille Fehler sind gefährlicher als laute.

Er lässt sich testen. Nach jeder Änderung zeigt ein Testlauf, ob die bisherigen Fälle noch stimmen. Ohne diese Absicherung traut sich später niemand an die Regeln.

Er altert langsam. Normänderungen betreffen nur die Formatschicht, nicht Ihre Logik. Sonst wird jede Aktualisierung zum Projekt.

Diese vier Punkte kosten in der Entwicklung wenig zusätzliche Zeit. Sie entscheiden aber darüber, ob das Werkzeug in drei Jahren noch benutzt wird oder ob es längst durch eine Excel-Liste ersetzt wurde.