Sicherstellung der selektiven Verarbeitung von Geschäftsvorfällen bei Syntaxfehlern in Übertragungsdateien
Bei der elektronischen Übermittlung von Geschäftsvorfällen (z. B. im Rahmen von Steuererklärungen, Meldungen an Behörden oder Finanztransaktionen) kann es zu Syntaxfehlern in der Übertragungsdatei kommen. Standardmäßig führen solche Fehler oft zur vollständigen Ablehnung der Datei, was die Verarbeitung aller enthaltenen Geschäftsvorfälle blockiert – selbst wenn nur einzelne Datensätze fehlerhaft sind. Um dies zu vermeiden und eine selektive Verarbeitung zu ermöglichen, sind technische und organisatorische Maßnahmen erforderlich. Die folgenden Empfehlungen basieren auf gängigen Standards und bewährten Verfahren.
1. Technische Voraussetzungen für selektive Fehlerbehandlung
a) Strukturierte Dateiformate mit granularer Fehlererkennung
Die Übertragungsdatei sollte ein Format verwenden, das eine separate Validierung einzelner Datensätze ermöglicht. Geeignete Formate sind:
- XML (mit Schema-Validierung, z. B. XSD)
- Ermöglicht die Definition von Regeln für einzelne Elemente.
- Fehlerhafte Datensätze können isoliert werden, während valide Datensätze verarbeitet werden.
- JSON (mit JSON-Schema)
- Ähnlich wie XML, aber mit geringerer Dateigröße und besserer Lesbarkeit.
- CSV mit strikten Trennzeichen und Escape-Regeln
- Weniger robust als XML/JSON, aber bei klaren Spezifikationen möglich.
- Nachteil: Fehlende hierarchische Struktur erschwert die Fehlerlokalisierung.
Empfehlung: XML oder JSON mit einer validierenden Schema-Definition (XSD/JSON-Schema) verwenden, die vom Empfänger bereitgestellt wird.
b) Logische Trennung von Datensätzen
Die Datei sollte so strukturiert sein, dass jeder Geschäftsvorfall als eigenständiger Block (z. B. <Geschäftsvorfall> in XML oder ein JSON-Array-Element) abgebildet wird. Beispiel:
<Übertragungsdatei>
<Geschäftsvorfall id="1">
<!-- Daten -->
</Geschäftsvorfall>
<Geschäftsvorfall id="2">
<!-- Fehlerhafter Datensatz -->
</Geschäftsvorfall>
</Übertragungsdatei>
- Der Empfänger kann dann nur die fehlerhaften Blöcke zurückweisen und die restlichen verarbeiten.
c) Eindeutige Identifikatoren für Geschäftsvorfälle
Jeder Datensatz sollte einen eindeutigen Schlüssel (z. B. id, Referenznummer) enthalten, um:
- Fehlerhafte Datensätze im Fehlerprotokoll präzise zu referenzieren.
- Korrekturen gezielt zu ermöglichen (z. B. durch erneute Übermittlung nur des fehlerhaften Datensatzes).
2. Validierungsprozess auf Empfängerseite
a) Zweistufige Prüfung
Der Empfänger sollte die Datei in zwei Schritten prüfen:
- Syntaxprüfung (technische Validität):
- Wird die Datei korrekt geparst (z. B. XML-Wohlgeformtheit)?
- Entspricht die Struktur dem Schema?
- Inhaltsprüfung (fachliche Validität):
- Sind Pflichtfelder vorhanden?
- Entsprechen Werte den definierten Formaten (z. B. Datumsangaben, Beträge)?
Fehlerbehandlung:
- Bei Syntaxfehlern in der Gesamtdatei (z. B. fehlende schließende Tags) wird die gesamte Datei abgelehnt.
- Bei Fehlern in einzelnen Datensätzen werden nur diese zurückgewiesen, während valide Datensätze verarbeitet werden.
b) Detaillierte Fehlerprotokolle
Der Empfänger muss ein maschinenlesbares Fehlerprotokoll bereitstellen, das:
- Die exakte Position des Fehlers angibt (z. B. Zeilennummer, XPath in XML).
- Den Fehlertyp beschreibt (z. B. "Ungültiges Datumsformat in Datensatz 42").
- Eine Referenz zum betroffenen Geschäftsvorfall enthält (z. B.
id="123").
Beispiel-Fehlerprotokoll (XML):
<Fehlerprotokoll>
<Fehler>
<Typ>Syntaxfehler</Typ>
<Position>//Geschäftsvorfall[@id='42']/Betrag</Position>
<Beschreibung>Ungültiges Format: Betrag muss numerisch sein.</Beschreibung>
</Fehler>
</Fehlerprotokoll>
3. Maßnahmen auf Senderseite
a) Vorab-Validierung der Datei
Vor der Übermittlung sollte der Sender die Datei mit denselben Regeln prüfen, die der Empfänger anwendet. Tools hierfür:
- XML:
xmllint(Linux), Oxygen XML Editor (kommerziell). - JSON:
ajv(JavaScript),json-schema-validator(Python). - CSV: Eigenentwickelte Skripte mit regulären Ausdrücken.
Empfehlung: Automatisierte Prüfung in den Übermittlungsprozess integrieren (z. B. als Pre-Commit-Hook oder CI/CD-Pipeline).
b) Testumgebung nutzen
Viele Empfänger (z. B. Finanzbehörden) bieten Testumgebungen an, in denen Dateien ohne reale Konsequenzen validiert werden können. Nutzen Sie diese, um:
- Die Struktur der Datei zu verifizieren.
- Fehlerprotokolle zu analysieren.
- Korrekturen vor der finalen Übermittlung vorzunehmen.
c) Fehlerhafte Datensätze separat nachreichen
Falls der Empfänger nur fehlerhafte Datensätze zurückweist:
- Korrigieren Sie die betroffenen Datensätze.
- Reichen Sie nur diese in einer separaten Datei nach (z. B. mit einem Hinweis wie
<KorrekturZu id="42">). - Vermeiden Sie die erneute Übermittlung der gesamten Datei.
4. Rechtliche und organisatorische Rahmenbedingungen
a) Vereinbarungen mit dem Empfänger
Klären Sie mit dem Empfänger (z. B. Behörde, Bank) vorab:
- Welche Dateiformate und Schemata unterstützt werden.
- Ob eine selektive Fehlerbehandlung möglich ist.
- Wie Fehlerprotokolle strukturiert sind und wie lange sie bereitgestellt werden.
b) Dokumentation und Protokollierung
- Sender: Dokumentieren Sie alle Übermittlungen (Datum, Dateiname, Prüfsumme) und Fehlerprotokolle.
- Empfänger: Fordern Sie eine Bestätigung der verarbeiteten Datensätze an (z. B. mit einer Liste der akzeptierten
id-Werte).
c) Fristen und Nachreichungen
Achten Sie auf Fristen für Korrekturen. Manche Empfänger erlauben nur eine begrenzte Anzahl von Nachreichungen oder verlangen eine vollständige Neuübermittlung nach Ablauf einer Frist.
5. Beispielhafter Ablauf bei einem Fehler
- Sender übermittelt eine XML-Datei mit 100 Geschäftsvorfällen.
- Empfänger prüft die Datei und stellt fest:
- Datensatz 42 enthält ein ungültiges Datumsformat.
- Die restlichen 99 Datensätze sind valide.
- Empfänger verarbeitet die 99 korrekten Datensätze und sendet ein Fehlerprotokoll zurück:
<Fehlerprotokoll> <Fehler> <Typ>Inhaltsfehler</Typ> <Position>//Geschäftsvorfall[@id='42']/Datum</Position> <Beschreibung>Ungültiges Format: Erwartet 'YYYY-MM-DD'.</Beschreibung> </Fehler> </Fehlerprotokoll> - Sender korrigiert Datensatz 42 und reicht ihn separat nach:
<Korrektur> <Geschäftsvorfall id="42"> <Datum>2024-05-15</Datum> <!-- Weitere korrigierte Daten --> </Geschäftsvorfall> </Korrektur> - Empfänger verarbeitet die Korrektur und bestätigt die erfolgreiche Übernahme.
6. Grenzen der selektiven Fehlerbehandlung
Nicht alle Systeme unterstützen eine selektive Verarbeitung. Mögliche Einschränkungen:
- Legacy-Systeme: Ältere Empfängersysteme lehnen die gesamte Datei ab, wenn ein Fehler auftritt.
- Transaktionssicherheit: Bei finanziellen Transaktionen (z. B. SEPA-Lastschriften) kann eine teilweise Verarbeitung zu Inkonsistenzen führen.
- Rechtliche Vorgaben: Manche Vorschriften (z. B. GoBD) verlangen die vollständige Nachvollziehbarkeit aller Übermittlungen, was separate Korrekturen erschweren kann.
Lösung: Klären Sie im Vorfeld mit dem Empfänger, ob und unter welchen Bedingungen eine selektive Verarbeitung möglich ist.
Zusammenfassung der Maßnahmen
| Bereich | Maßnahme |
|---|---|
| Dateiformat | XML/JSON mit Schema-Validierung und granularer Datensatzstruktur. |
| Validierung | Zweistufige Prüfung (Syntax + Inhalt) mit detaillierten Fehlerprotokollen. |
| Senderseitige Prüfung | Vorab-Validierung mit Tools, Testumgebungen nutzen. |
| Korrekturprozess | Nur fehlerhafte Datensätze nachreichen, nicht die gesamte Datei. |
| Dokumentation | Alle Übermittlungen und Fehlerprotokolle protokollieren. |
| Abstimmung mit Empfänger | Klären, ob selektive Verarbeitung unterstützt wird. |
Durch die Kombination dieser Maßnahmen lässt sich sicherstellen, dass bei Syntaxfehlern nur die tatsächlich fehlerhaften Geschäftsvorfälle betroffen sind, während valide Datensätze erfolgreich verarbeitet werden.