DATEV Datenformate: Das Ziel wählt das Format, nicht Sie

DATEV veröffentlicht drei Dateiformate mit eigenen Spezifikationen, und die verbreitete Annahme darüber ist auf eine bestimmte Weise falsch. Sie sind keine drei Wege, dieselben Daten zu senden. Jedes gehört zu einem anderen Ziel, und das Ziel wählt es aus.

Lesen Sie die mittlere Spalte, und die praktische Folge steht da. Ein Format zu wählen ist dieselbe Entscheidung wie ein DATEV-Produkt zu wählen, und damit ist sie schon gefallen, bevor Sie bei der Datei ankommen: was Ihr Produkt erzeugt, entscheidet über das Ziel, und das Ziel entscheidet über das Format.

Zu welchem Produkt die Daten gehören, ist das Thema im Vergleich zwischen Unternehmen Online und Rechnungswesen, und die Formatfrage beantwortet sich dort nebenbei.

Es ist die Datei, die die DATEV Rechnungswesen Schnittstelle annimmt: eine CSV mit festem Dateinamenpräfix, EXTF_, und einer dreiteiligen Struktur, über die die meisten Teams einmal stolpern. Zeile eins ist ein Kopf mit den Metadaten, die DATEV zur Verarbeitung der Datei braucht. Zeile zwei ist die Überschriftenzeile der Nutzdaten. Die Datensätze beginnen in Zeile drei.

Diese erste Zeile ist die Falle, denn sie sieht aus wie eine Spaltenzeile und ist keine. Wer sie als Spaltennamen liest, bekommt DATEVs Verarbeitungsmetadaten statt der Felder, und der Fehler zeigt sich erst nach dem Upload.

Der Buchungsstapel ist 125 Spalten breit, und 56 davon sind die nummerierten Paare, die DATEV für Zusatzangaben reserviert: 40 Spalten Zusatzinformation und 16 Spalten Beleginfo. Der Rest ist die Buchung selbst, von Umsatz und Soll/Haben-Kennzeichen über Konto, Gegenkonto und BU-Schlüssel bis Festschreibung.

Vier Regeln der Kodierung entscheiden darüber, ob eine richtige Buchung auch richtig gelesen wird, und alle vier gehen aus einer Sprache mit anderen Voreinstellungen leicht daneben. Felder werden durch Semikolon getrennt, jede Zeile endet mit CR/LF, Textfelder stehen in Anführungszeichen, und ein Anführungszeichen darin wird verdoppelt.

Die Zahlenformatierung ist die Regel, die stillen Schaden anrichtet. Das Dezimaltrennzeichen ist das Komma, und Tausendertrennzeichen werden in der Regel nicht benutzt. Ein nach Locale formatierter Betrag läuft hier durch und bucht eine andere Zahl.

Die XML-Schnittstelle online ist UTF-8-kodiert und trägt Rechnungs- und Kassendaten in die DATEV Unternehmen Online Schnittstelle. Strukturell ist sie das Gegenstück zum CSV-Weg: sie verschachtelt, wo die CSV flach ist, und ein Schema prüft sie, wo die CSV auf Treu und Glauben angenommen wird.

Diese Validierung ist der Tausch. Sie ist Arbeit im Voraus, denn ein Dokument muss DATEVs Schema erfüllen, bevor es irgendwohin geht, und sie ist der Grund, warum ein XML-Fehler billiger ist: er scheitert in Ihrer Pipeline und nicht in den Büchern Ihrer Kunden.

Es gibt dabei noch eine Ebene, die sich beim Lesen der Vorgaben leicht übersehen lässt, und sie ist wörtlich gemeint: DATEV veröffentlicht zwei Sätze von Schnittstellenvorgaben je Datenservice, einen für den Service und einen für das Dateiformat. Der Buchungsdatenservice hat seinen eigenen plus einen für das DATEV-Format, der Rechnungsdatenservice 1.0 seinen eigenen plus einen für das DXSO-Format. Wer den ersten erfüllt, hat damit den zweiten nicht erfüllt, und deshalb ist das Format in diesem Ökosystem ein eigenes Thema und kein Feld an einem Request.

ASCII ist das Format von DATEVs Lohnimportdatenservice. Eine ASCII-Importdatei trägt Lohnstammdaten oder Bewegungsdaten aus einem externen System in das DATEV-Rechenzentrum, von wo sie nach DATEV LODAS oder DATEV Lohn und Gehalt übernommen wird.

Es liegt damit auf einer anderen Achse als die beiden anderen. CSV und XML liefern Buchhaltungsdaten an Buchhaltungsanwendungen, ASCII liefert Lohndaten an Lohnanwendungen, über einen eigenen Service und einen eigenen Scope, hr:files.

Für eine Buchhaltungsintegration ist es damit das Format, das Sie nicht brauchen, und das früh zu wissen spart einen Umweg. Es heißt auch, dass eine Lohnfunktion ein eigenes Projekt ist, mit einem anderen Service, einem anderen Ziel und einer eigenen Freigabe.

Diese Grenze zieht man früh. Die Lohnbuchhaltung liegt heute außerhalb des Datenmodells. Was Sie über maesn erreichen, ist die Buchhaltungsseite, und beide Buchhaltungsformate liegen darin.

Keine der beiden Dateien geht an einen Endpunkt, der mit einem Ergebnis antwortet. Beide laufen über einen Job, und der Job hat vier Schritte: Sie legen ihn mit der Datei an, Sie starten ihn, Sie fragen seinen Status ab und Sie werten aus, was er zurückgibt.

Die Service-Namen folgen dem Format. Der XML-Weg läuft als DXSO-Job auf accounting:dxso-jobs, dem Rechnungsdatenservice 1.0. Der CSV-Weg läuft als EXTF-Job auf accounting:extf-files, dem Buchungsdatenservice.

Daraus folgen drei Entwurfsentscheidungen. Es gibt keine sofortige Antwort, Ihre Oberfläche braucht also einen Zustand für Ausstehendes. Das Ergebnis kann teilweise ausfallen, ein erfolgreicher Job bedeutet also nicht, dass jeder Datensatz darin erfolgreich war. Und die Einzelheiten zum Fehlschlag liegen im Job-Ergebnis, Ihr Logging muss die Job-Referenz also neben dem Dokument führen, zu dem sie gehört.

Über maesn ist diese Schleife nicht Ihre. Sie senden das Common Data Model, und die Dateierzeugung, die Regeln der Kodierung und der Job liegen auf unserer Seite. Deshalb gibt es Asynchronous Processing als eigenes Thema: die Warteschlange entsteht aus den Systemen dahinter und nicht aus unserer Schnittstelle.

Die Entscheidung folgt dem Ziel, und das Ziel folgt dem, was Ihr Produkt erzeugt. Lesen Sie die Tabelle von der ersten Spalte aus.

Die letzte Zeile ist die, die bei der Formatfrage meist vergessen wird. Ein Lesezugriff berührt keines der drei Formate: er läuft über den Export-Service, und zurück kommen Daten und keine Datei. Der Leitfaden zum DATEV Datenservice Export Rechnungswesen behandelt, was das für die Aktualität bedeutet, und der Leitfaden zum Anbinden von DATEV Rechnungswesen beschreibt die eine Verbindung, die liest und schreibt.

Drei Dinge gehören nicht mehr Ihnen:

• Die Datei. Eine CSV mit 125 Spalten, richtigem Präfix, Trennzeichen, Zeilenende, Anführungszeichen und Dezimalkomma zu erzeugen, oder ein schemagültiges XML-Dokument, passiert hier.
• Der Job. Ihn anzulegen, zu starten, abzufragen und das Ergebnis zu lesen, ist eine Schnittstelle für beide Formate.
• Die Zuordnung des Service. Über welchen Datenservice die Daten laufen, leitet sich daraus ab, was Sie senden.

Zwei Dinge bewegen sich nicht:

• Was das Ziel annimmt. Eine Buchung, die gegen eine Buchhaltungsregel verstößt, wird abgewiesen, gleich was die Datei erzeugt hat, und keine Abstraktion bringt ein Ziel dazu, etwas anzunehmen, das es ablehnt.
• Die Lohnbuchhaltung. Der ASCII-Weg bedient eine andere Familie von DATEV-Anwendungen und gehört nicht zum Objektmodell der Buchhaltung, bleibt also ein eigenes Projekt.