Einfluss der hierarchischen EDIFACT-Segmentstruktur auf die prozessuale Verantwortungszuordnung bei Fehlerbehandlung und Meldungsanerkennung
1. Grundlagen der hierarchischen Segmentstruktur in EDIFACT
EDIFACT-Nachrichten folgen einer streng hierarchischen Struktur, die durch Segmentgruppen (SG) und deren Untersegmente definiert wird. Die Position eines Segments innerhalb dieser Hierarchie bestimmt nicht nur dessen semantische Bedeutung, sondern auch die prozessuale Verantwortung für die korrekte Verarbeitung, Fehlererkennung und Anerkennung zwischen den Marktpartnern.
Im vorliegenden Kontext sind zwei zentrale Segmentgruppen relevant:
- SG2/RFF (Referenzinformationen): Enthält transaktionsbezogene Referenzdaten (z. B. Vorgangsnummern).
- SG3/NAD (Name and Address): Identifiziert die beteiligten Parteien (z. B. Absender, Empfänger, Dokumentenaussteller).
Die hierarchische Anordnung impliziert eine logische Abhängigkeit:
- SG3/NAD ist der übergeordneten Ebene zugeordnet und definiert die Rahmenbedingungen der Kommunikation (z. B. wer die Nachricht ausstellt).
- SG2/RFF ist untergeordnet und enthält transaktionsspezifische Details, die auf der Basis der NAD-Informationen validiert werden.
2. Verantwortungszuordnung bei der Fehlerbehandlung
Die Hierarchie beeinflusst, welcher Marktpartner für die Fehlererkennung und -behebung zuständig ist:
a) Fehler in SG3/NAD (z. B. falsche MP-ID des Absenders)
- Verantwortung: Empfänger der Nachricht
- Da NAD-Segmente die Grundlage für die Identifikation der Kommunikationspartner bilden, muss der Empfänger prüfen, ob die übermittelten Daten (z. B.
3035=MSfür den Nachrichtenaussteller) mit den vertraglich vereinbarten Partnern übereinstimmen. - Fehlerfolgen:
- Eine falsche MP-ID führt zur Ablehnung der gesamten Nachricht, da die Authentizität des Absenders nicht verifiziert werden kann.
- Der Empfänger muss eine Fehlermeldung (z. B. CONTRL-ACK mit Status "Rejected") generieren und den Absender zur Korrektur auffordern.
- Prozessuale Konsequenz:
- Der Absender trägt die primäre Verantwortung für die korrekte Pflege seiner Stammdaten (z. B. in Partnerprofilen).
- Der Empfänger hat eine sekundäre Prüfpflicht, kann aber bei offensichtlichen Fehlern (z. B. unbekannte MP-ID) die Nachricht pauschal ablehnen.
- Da NAD-Segmente die Grundlage für die Identifikation der Kommunikationspartner bilden, muss der Empfänger prüfen, ob die übermittelten Daten (z. B.
b) Fehler in SG2/RFF (z. B. inkonsistente Vorgangsnummer)
- Verantwortung: Absender der Nachricht
- RFF-Segmente enthalten transaktionsspezifische Referenzen, die der Absender generiert und verantwortet.
- Fehlerfolgen:
- Inkonsistenzen (z. B.
1154verweist auf eine nicht existierende Vorgangsnummer) führen zu partiellen Ablehnungen oder Warnungen, da die Nachricht selbst (NAD-Ebene) gültig bleibt. - Der Empfänger kann die Nachricht teilweise verarbeiten (z. B. Stammdaten akzeptieren, aber die Transaktion ablehnen) oder eine spezifische Fehlermeldung (z. B. "Referenz nicht gefunden") zurücksenden.
- Inkonsistenzen (z. B.
- Prozessuale Konsequenz:
- Der Absender muss die Konsistenz seiner Referenzdaten sicherstellen (z. B. durch Plausibilitätsprüfungen vor dem Versand).
- Der Empfänger hat das Recht, nur die fehlerhaften Teile zurückzuweisen, ohne die gesamte Nachricht zu verwerfen.
3. Auswirkungen auf die Anerkennung von Meldungen
Die hierarchische Struktur definiert auch, welche Segmente für die Anerkennung einer Nachricht kritisch sind:
| Segmentgruppe | Anerkennungsrelevanz | Verantwortlicher Partner | Beispiel für Nichtanerkennung |
|---|---|---|---|
| SG3/NAD | Muss (kritisch) | Empfänger | Falsche MP-ID → Nachricht wird abgelehnt. |
| SG2/RFF | Bedingt (transaktionsabhängig) | Absender | Inkonsistente Vorgangsnummer → Transaktion wird abgelehnt, Nachricht bleibt gültig. |
- NAD-Segmente sind mandatorisch für die Anerkennung der gesamten Nachricht:
- Eine fehlerhafte NAD-Information führt zur vollständigen Ablehnung, da die Identität des Absenders oder Empfängers nicht verifiziert werden kann.
- Beispiel: Fehlt das Segment
3035=MS(Nachrichtenaussteller), ist unklar, wer die Nachricht verantwortet → automatische Ablehnung.
- RFF-Segmente sind transaktionsspezifisch und beeinflussen nur die inhaltliche Verarbeitung:
- Fehler hier führen nicht zur Ablehnung der Nachricht, sondern nur zur Nichtverarbeitung der betroffenen Transaktion.
- Beispiel: Eine falsche
1154-Referenz führt dazu, dass der Empfänger die Transaktion nicht zuordnen kann → Fehlermeldung an den Absender, aber die Nachricht selbst bleibt gültig.
4. Praktische Implikationen für die Prozessgestaltung
Klare Schnittstellenvereinbarungen:
- Die Marktpartner müssen explizit regeln, welche Segmente (NAD vs. RFF) für die Anerkennung kritisch sind und welche Fehler zu einer vollständigen Ablehnung führen.
- Beispiel: Eine Vereinbarung könnte festlegen, dass NAD-Fehler immer zur Ablehnung führen, während RFF-Fehler nur eine Warnung auslösen.
Automatisierte Validierung:
- Empfänger sollten zweistufige Prüfungen implementieren:
- Stufe 1 (NAD): Prüfung der Absenderidentität und Nachrichtenstruktur.
- Stufe 2 (RFF): Validierung der transaktionsspezifischen Referenzen.
- Tools wie EDI-Mapper oder Validierungsregeln in Middleware können diese Hierarchie abbilden.
- Empfänger sollten zweistufige Prüfungen implementieren:
Fehlerkommunikation:
- Fehlermeldungen müssen hierarchiekonform sein:
- Bei NAD-Fehlern: CONTRL-ACK mit Status "Rejected" (vollständige Ablehnung).
- Bei RFF-Fehlern: APERAK-Nachricht mit spezifischem Fehlercode (z. B. "Referenz nicht gefunden").
- Fehlermeldungen müssen hierarchiekonform sein:
Dokumentation der Verantwortlichkeiten:
- In EDI-Richtlinien sollte festgelegt werden:
- Wer für die Pflege der NAD-Stammdaten verantwortlich ist (i. d. R. der Absender).
- Wer RFF-Referenzen generiert und validiert (i. d. R. der Absender, mit Plausibilitätsprüfung durch den Empfänger).
- In EDI-Richtlinien sollte festgelegt werden:
5. Fazit
Die hierarchische Struktur von EDIFACT-Segmenten (SG3/NAD vs. SG2/RFF) hat direkte Auswirkungen auf die Verantwortungszuordnung zwischen Marktpartnern:
- NAD-Segmente definieren die Rahmenbedingungen der Kommunikation und sind kritisch für die Anerkennung der gesamten Nachricht. Fehler hier führen zur vollständigen Ablehnung und liegen primär in der Verantwortung des Empfängers (Prüfung) und des Absenders (Datenpflege).
- RFF-Segmente enthalten transaktionsspezifische Details und sind nur für die inhaltliche Verarbeitung relevant. Fehler hier führen zu partiellen Ablehnungen und liegen primär in der Verantwortung des Absenders.
Eine klare Prozessdokumentation, automatisierte Validierung und hierarchiekonforme Fehlermeldungen sind essenziell, um Konflikte bei der Fehlerbehandlung zu vermeiden und die reibungslose Abwicklung von EDI-Prozessen sicherzustellen.