Modul- und API-Referenz — datev-exporter

Vertiefende Referenzen

Vier Seiten behandeln die Teile des DATEV-Vertrags, die die meisten Fragen auslösen. Jede wird aus der Bibliothek erzeugt, sodass die Tabellen zu dem passen, was die Exporter tatsächlich schreiben.

Feldreferenz

Alle 125 Buchungsstapel-Spalten in Ausgabereihenfolge, mit amtlichen Überschriften, Prüfprogramm-Typen, Längen und Verfügbarkeit in Version 12.

Validierungsfehler

Die sechs stabilen Fehlercodes, ihre Auslöser, die Feldpaare und die drei Prüftiefen.

EXTF-Header

Der Verwaltungssatz mit 31 Feldern: feste Kennungen, Datums- und Zeitformate, Quoting-Regeln und die kodierten Felder.

Kodierung und Umlaute

Windows-1252, CRLF, Semikolon und Quoting — welche Zeichen überstehen und wie Exporte nachträglich beschädigt werden.

Artefakte

Modulübersicht

Veröffentlichte Maven-Artefakte in Release 0.2.0
Artefakt	Runtime-Abhängigkeiten	Verantwortung
`datev-exporter`	Keine (Plattform-POM)	BOM zur Ausrichtung aller Module auf eine Version. Enthält keine Runtime-API.
`datev-exporter-core`	Keine	Kanonische Schemata, Felddefinitionen, Metadaten, Überschriften, CSV-Codec und Validierungsmodell.
`datev-exporter-plain`	`core`	Feste v13/v12-Datei mit Speicherung und Forward-only-Writer. Empfohlenes Ausgabemodul.
`datev-exporter-field-validator`	`core`	Optionaler semantischer Validator-Callback für den Plain-Exporter.
`datev-exporter-advanced`	`core`	Speichernde Dateien mit individuellen/umbenannten/umgeordneten Überschriften und integrierten Validierungsmodi.
`datev-exporter-advanced-univocity`	`advanced` + Univocity	Adapter für Anwendungen mit bereits festgelegter Univocity-`CsvWriter`-Pipeline.

datev-exporter-verification und datev-exporter-benchmarks sind interne Build-Module; sie gehören weder zur BOM noch zur Maven-Central-Veröffentlichung.

Entscheidungstabelle

Plain, Advanced oder Univocity?

Abwägungen zwischen Exportern
Bedarf	Plain	Advanced	Univocity-Adapter
Vollständige feste v13/v12-EXTF	empfohlen	ja mit exakter offizieller Überschrift, Strict-Modus und passenden Metadaten	kein Verwaltungssatz
Forward-only-Zeilen	ja `DatevStreamWriter`	nein Zeilen werden behalten	Schreibt gespeicherte Advanced-Zeilen über Drittanbieter-Writer
Überschriften umbenennen/-ordnen	nein	ja	ja über Advanced-Datei
Eigener Zeichensatz	nein Byte-Pfad ist Windows-1252	Nur für metadatenfreie individuelle Folgeverträge	Zeichensatz der Advanced-Datei; strikte Encoder-Hülle bereitgestellt
Drittanbieter-Runtime-Abhängigkeit	Keine außer Core	Keine außer Core	Univocity
Byte-Form der offiziellen Überschrift	Kanonische unmaskierte Überschrift	Kanonisch im integrierten Writer mit offizieller Überschrift	Textüberschriften werden abweichend maskiert

Standardempfehlung

Plain verwenden, solange kein konkreter Bedarf für individuelle Überschriften benannt werden kann. Speichernde DatevFile für Prüfung/Wiederholung, DatevStreamWriter für einmalige Produktion.

Prüfung in Schichten

Validierung findet technische Fehler, nicht fachliche Wahrheit

In integrierter Ausgabe immer aktiv

Struktur- und Kodierungssicherheit

Spaltenbreite/-reihenfolge, bekannte Überschriften, CSV-Syntax/Steuerzeichen, Zeilenlimit und strikte Windows-1252-Darstellbarkeit auf Byte-Ausgabe.

Optionale Plain-Abhängigkeit

`DatevValidator`

Callback mit Formatversion und unveränderlicher Zeile. Mit Kontenlänge, Wirtschaftsjahresbeginn und Periode bauen, um kontextbezogene Konto-/Datumsregeln zu prüfen.

Advanced-Konfiguration

`DatevValidationMode`

STRICT ergänzt Pflichtfelder und Abhängigkeiten; FIELD_LEVEL prüft gelieferte bekannte Felder; NONE behält strukturelle CSV-/Überschriftsprüfungen.

Immer Sache der Anwendung

Buchhaltung und Stammdaten

Kontenauswahl, Steuerbehandlung, Gültigkeit im Ziel und mandantenspezifische Anforderungen müssen außerhalb der Bibliothek validiert werden.

Das bloße Einbinden von datev-exporter-field-validator verändert nichts. Der Validator wird an Plain-Builder/-Factory übergeben. Offizielle Advanced-Schemata nutzen standardmäßig STRICT; individuelle Überschriften NONE, weil ihre Fachsemantik unbekannt ist.

Interoperabilität, kein Ersatz

Der Univocity-Adapter löst genau ein enges Problem

datev-exporter-advanced-univocity nur wählen, wenn die umgebende Anwendung CSV-Ausgabe bereits in Univocity zentralisiert und Überschrift plus Buchungszeilen die beabsichtigte Grenze sind.

CsvWriter writer = DatevUnivocityWriters.newCsvWriter(file, outputStream);
DatevUnivocityWriters.writeTo(file, writer);

Ein CsvWriter gibt gleichförmige Sätze aus und kann daher den anders aufgebauten EXTF-Verwaltungssatz mit 31 Feldern nicht erzeugen.
writeTo lehnt eine Datei mit Metadaten ab. Für eine vollständige Datei den integrierten Advanced-Pfad DatevFile.writeTo(OutputStream) verwenden.
writeDataTo schreibt ausdrücklich nur Überschrift und Zeilen – selbst wenn Metadaten vorhanden sind.
Mit unveränderten offiziellen v12/v13-Einstellungen entsprechen Buchungszeilen der integrierten Ausgabe, Textüberschriften werden aber anders maskiert. Keine Aussage über Byte-Gleichheit der Gesamtdatei.
Das bereitgestellte newCsvWriter meldet nicht darstellbare Zeichen und lässt den Stream offen. Rohe Univocity-Konstruktoren vermeiden, die unzulässige Zeichen durch ? ersetzen können.

Verantwortungsregeln

Das Ausgabeziel bleibt beim Aufrufer

Integrierte Writer leeren, aber schließen einen gelieferten OutputStream oder Writer nicht.
Für kanonische Windows-1252-Bytes den OutputStream-Pfad verwenden. Ein Zeichen-Writer ist nur ein Zeichenvertrag; sein finaler Encoder bleibt Aufgabe des Aufrufers.
Ungepufferte Datei-/Netzwerkausgabe einmalig puffern. Die Bibliothek wählt bewusst keine dauerhafte Puffergröße.
Plain und Advanced DatevFile behalten angenommene Zeilen. DatevStreamWriter übergibt jede angenommene Zeile und verwirft ihren Zusammenstellungsspeicher.
Alle mutablen Exporter-Instanzen sind bewusst single-threaded.

Vor einer volumenbasierten Auswahl das Beispiel für gepuffertes Streaming und den Benchmarkbericht lesen.

Referenz auf Symbolebene

Versionierte Javadocs für exakte Signaturen

Dieser Leitfaden erklärt Verträge und Entscheidungen. Die generierte API-Seite ist die Quelle für öffentliche Klassen, Methoden und Lebenszyklusdetails:

Kompatibilität vor 1.0

Das Projekt verwendet Semantic Versioning, öffentliche APIs können sich bis 1.0.0 jedoch zwischen Minor-Versionen ändern. BOM-Version fixieren und beim Upgrade die Release Notes lesen.