Fehlerbehandlungslogik in der Marktkommunikation bei fehlender Persistenz von Original-EDIFACT-Dateien
1. Auswirkungen auf die Fehlerbehandlungslogik
Die fehlende Persistenz von Original-EDIFACT-Dateien beim Empfänger führt zu grundlegenden Änderungen in der Fehlerbehandlungslogik, insbesondere bei asynchronen Prüfverfahren. Da die CONTRL-Prüfung (z. B. Syntaxvalidierung) auf der Originaldatei basiert, entfällt bei deren Verlust die Möglichkeit, Fehler durch Segment- oder Datenelementzählung exakt zu lokalisieren. Dies hat folgende Konsequenzen:
Verlust der Fehlerpräzision: Ohne die Originaldatei können Fehler nicht mehr durch direkte Referenzierung (z. B. „Segment UNH an Position X“) identifiziert werden. Stattdessen müssen Fehlerbeschreibungen auf Basis von Metadaten (z. B. Prüfprotokolle, Hash-Werte) oder rekonstruierten Inhalten erfolgen, was die Nachvollziehbarkeit erschwert.
Abhängigkeit von Prüfprotokollen: Die Fehlerbehandlung muss sich auf persistente Prüfprotokolle (z. B. CONTRL-Antworten, Log-Einträge) stützen, die jedoch nur begrenzte Informationen enthalten (z. B. Fehlertyp, betroffene Nachrichtentypen). Eine detaillierte Rekonstruktion des Fehlers ist nur möglich, wenn diese Protokolle strukturiert und langfristig gespeichert werden.
Asynchrone Fehlererkennung: Da Prüfungen zeitversetzt erfolgen können, muss die Fehlerbehandlung so gestaltet sein, dass sie auch ohne Zugriff auf die Originaldatei funktioniert. Dies erfordert eine Entkopplung der Fehlererkennung von der physischen Datei und eine stärkere Fokussierung auf persistente Referenzdaten.
2. Prozessuale Anpassungen für konsistente Nachvollziehbarkeit
Um trotz fehlender Originaldateien eine lückenlose Fehlerbehandlung zu gewährleisten, sind folgende Anpassungen notwendig:
2.1 Persistente Speicherung von Prüfmetadaten
Prüfprotokolle mit Referenzdaten: Neben der CONTRL-Antwort müssen zusätzliche Metadaten gespeichert werden, z. B.:
- Hash-Werte der Originaldatei (z. B. SHA-256) zur späteren Identifikation.
- Zeitstempel der Prüfung und des Dateieingangs.
- Strukturierte Fehlermeldungen mit eindeutigen Fehlercodes (z. B. nach EDIFACT-Standard) und Kontextinformationen (z. B. betroffene Nachrichtentypen wie ORDERS, INVOIC).
- Extrahierte Schlüsselwerte (z. B. Referenznummern, Geschäftspartner-IDs), um Fehler auch ohne Originaldatei zuordnen zu können.
Langfristige Archivierung: Prüfprotokolle und Metadaten müssen für die gesetzliche Aufbewahrungsfrist (z. B. 10 Jahre) revisionssicher gespeichert werden. Dies kann durch zentrale Datenbanken oder dokumentenorientierte Speichersysteme (z. B. Archivsysteme mit WORM-Funktionalität) erfolgen.
2.2 Rekonstruktion von Fehlern ohne Originaldatei
Fehlerbeschreibung über persistente Attribute: Statt auf Segmentpositionen zu verweisen, sollten Fehlerbeschreibungen auf semantische Referenzen umgestellt werden, z. B.:
- „Fehlendes Pflichtfeld BGM+380 in INVOIC-Nachricht“ (statt „Segment BGM an Position 5 fehlt“).
- „Ungültiges Format in Datenelement DTM+137:20240230“ (statt „Datenelement an Position X ungültig“).
Nutzung von Referenznachrichten: Falls möglich, sollten Muster- oder Referenznachrichten (z. B. aus Testumgebungen) herangezogen werden, um Fehlerstrukturen zu vergleichen. Dies setzt voraus, dass solche Referenzen versioniert und dokumentiert sind.
2.3 Asynchrone Fehlerbehandlung mit Statusverfolgung
Statusmanagement für Prüfungen: Jede Prüfung muss einen eindeutigen Status erhalten (z. B. „in Prüfung“, „fehlerhaft“, „korrigiert“), der in einem zentralen System (z. B. Workflow-Engine) nachverfolgt wird. Dies ermöglicht eine spätere Zuordnung von Fehlern, auch wenn die Originaldatei nicht mehr verfügbar ist.
Automatisierte Eskalationsmechanismen: Bei kritischen Fehlern (z. B. Syntaxverstöße, die die Weiterverarbeitung blockieren) müssen automatisierte Benachrichtigungen an die zuständigen Stellen (z. B. Sender, Clearingstelle) erfolgen, bevor die Originaldatei gelöscht wird. Hierfür können Trigger in den Prüfprozessen implementiert werden.
2.4 Dokumentation und Schulung
Prozessdokumentation: Die geänderte Fehlerbehandlungslogik muss in Verfahrensanweisungen festgehalten werden, insbesondere:
- Wie Fehler ohne Originaldatei rekonstruiert werden.
- Welche Metadaten für die Nachvollziehbarkeit erforderlich sind.
- Verantwortlichkeiten für die Archivierung und Fehlerbearbeitung.
Schulung der Beteiligten: Mitarbeiter in der Marktkommunikation müssen für die neuen Prozesse geschult werden, insbesondere:
- Umgang mit Prüfprotokollen und Metadaten.
- Interpretation von Fehlermeldungen ohne Segmentreferenzen.
- Nutzung von Statusverfolgungssystemen.
3. Technische Umsetzung
Integration in bestehende Systeme: Die Anpassungen sollten in bestehende EDI-Gateways oder Marktkommunikationsplattformen integriert werden, z. B. durch:
- Automatische Generierung und Speicherung von Prüfprotokollen.
- Schnittstellen zu Archivsystemen für Metadaten.
- Workflow-Engines für die Statusverfolgung.
Schnittstellen zu Geschäftspartnern: Falls Geschäftspartner ebenfalls von der fehlenden Persistenz betroffen sind, sollten standardisierte Fehlermeldungen (z. B. über EDIFACT-CONTRL oder XML-basierte Protokolle) vereinbart werden, die auch ohne Originaldatei verständlich sind.
4. Fazit
Die fehlende Persistenz von Original-EDIFACT-Dateien erfordert eine Abkehr von der segmentbasierten Fehlerlokalisierung hin zu einer metadaten- und protokollgestützten Fehlerbehandlung. Durch persistente Speicherung von Prüfprotokollen, strukturierte Fehlermeldungen und asynchrone Statusverfolgung kann die Nachvollziehbarkeit dennoch sichergestellt werden. Die Anpassungen betreffen sowohl technische Systeme als auch organisatorische Prozesse und erfordern eine enge Abstimmung zwischen allen Beteiligten in der Marktkommunikation.