Willi Mako
// PROTOCOL:

Fehlerort im AHB der APERAK-Nachricht korrekt übertragen

ID#F1D-1E
STATUSREAD_ONLY
AUTHORSYS_ADMIN
TAGS [EDIFACT]

Übertragung der Ortsangabe eines Fehlers im Application Header Block (AHB) in der APERAK-Nachricht

Die korrekte Übermittlung der Ortsangabe eines Fehlers im Application Header Block (AHB) innerhalb einer APERAK-Nachricht (Application Error and Acknowledgment Message, EDIFACT-Segmentgruppe) erfordert die präzise Verwendung definierter Segmente und Datenelemente gemäß den Vorgaben der UN/EDIFACT-Standards sowie branchenspezifischer Richtlinien (z. B. VDA, Odette, GS1). Nachfolgend werden die zwingend erforderlichen Informationen und deren strukturierte Übertragung dargestellt.


1. Grundlegende Struktur der APERAK-Nachricht

Die APERAK-Nachricht dient der Meldung von Fehlern in vorangegangenen EDI-Nachrichten (z. B. ORDERS, DESADV) und enthält:

  • Nachrichtenkopf (UNH-Segment): Identifikation der APERAK-Nachricht.
  • Referenzierung der fehlerhaften Nachricht (Segmentgruppe 1): Verweis auf die ursprüngliche Nachricht (z. B. über BGM und RFF).
  • Fehlerbeschreibung (Segmentgruppe 2): Detaillierte Angaben zum Fehler, einschließlich der Ortsangabe im AHB.

2. Zwingend erforderliche Informationen für die Ortsangabe

Um den Fehler im AHB exakt zu lokalisieren, müssen folgende Daten übertragen werden:

a) Referenz auf die ursprüngliche Nachricht

  • Segment: RFF (Reference)
    • Datenelement 1153 (Reference qualifier): Muss den Wert "ACD" (Application error context) enthalten.
    • Datenelement 1154 (Reference number): Enthält die eindeutige Referenznummer der fehlerhaften Nachricht (z. B. die UNH-Referenznummer der ursprünglichen Nachricht).
    • Datenelement 1156 (Line number): Optional, falls der Fehler in einer bestimmten Zeile der Nachricht auftrat.

b) Fehlerlokalisierung im AHB

Der AHB ist Teil des UNB/UNH-Headers einer EDI-Nachricht. Zur genauen Ortsangabe sind folgende Segmente und Datenelemente erforderlich:

  • Segment: ERC (Application error information)

    • Datenelement 9321 (Error code): Enthält den Fehlercode (z. B. "1" für Syntaxfehler, "2" für semantische Fehler).
    • Datenelement 1049 (Error point indicator): Gibt an, ob der Fehler im Header (AHB) oder im Nachrichtenkörper liegt.
      • Wert "1": Fehler im Header (AHB).
      • Wert "2": Fehler im Nachrichtenkörper.
  • Segment: FTX (Free text)

    • Datenelement 4451 (Text subject qualifier): Muss den Wert "AAI" (Error description) enthalten.
    • Datenelement 4440 (Free text): Detaillierte Beschreibung des Fehlers, z. B.:

      "Fehler im AHB: Ungültiges Format des Datenelements 0002 (Syntaxversion) in UNB-Segment."

    • Optional: Datenelement 3453 (Language code) zur Angabe der Sprache (z. B. "DE").
  • Segment: LOC (Place/location identification)

    • Datenelement 3227 (Location function code qualifier): Muss den Wert "19" (Error location) enthalten.
    • Datenelement 3225 (Location identification code): Gibt die exakte Position im AHB an, z. B.:
      • "UNB+0002" (Fehler im Syntaxversion-Feld des UNB-Segments).
      • "UNH+0062" (Fehler im Nachrichtenreferenznummer-Feld des UNH-Segments).
      • "S009+0057" (Fehler in einem spezifischen Datenelement des AHB).

c) Zusätzliche Kontextinformationen (empfohlen)

  • Segment: DTM (Date/time/period)

    • Datenelement 2005 (Date/time/period qualifier): Wert "137" (Error occurrence date/time).
    • Datenelement 2380 (Date/time/period): Zeitstempel des Fehlers (Format: CCYYMMDDHHMM).
  • Segment: NAD (Name and address)

    • Datenelement 3035 (Party qualifier): Wert "MS" (Message sender) oder "MR" (Message recipient), um den Absender/Empfänger der fehlerhaften Nachricht zu identifizieren.

3. Beispiel einer APERAK-Nachricht mit AHB-Fehlerlokalisierung

UNH+1+APERAK:D:96A:UN'
BGM+23+REF12345+9'
DTM+137:202405151430:203'
RFF+ACD:ORD123456789'
ERC+1++1'
FTX+AAI+++Fehler im AHB: Ungültiges Format des Datenelements 0002 (Syntaxversion) in UNB-Segment'
LOC+19+UNB+0002'
NAD+MS+++Sender GmbH'
UNT+8+1'

Erläuterung:

  • RFF+ACD: Verweist auf die fehlerhafte ORDERS-Nachricht mit der Referenz "ORD123456789".
  • ERC+1++1: Fehlercode "1" (Syntaxfehler) im Header (AHB).
  • LOC+19+UNB+0002: Der Fehler liegt im UNB-Segment, Datenelement 0002 (Syntaxversion).
  • FTX+AAI: Freitextliche Fehlerbeschreibung.

4. Branchenspezifische Besonderheiten

  • Automobilindustrie (VDA/ODETTE):
    • Verwendung des VDA 4938-2-Standards für APERAK-Nachrichten.
    • Zusätzliche Segmente wie CUX (Currencies) oder MOA (Monetary amount) bei finanziellen Fehlern.
  • Handel (GS1/EANCOM):
    • Strengere Vorgaben für Fehlercodes (z. B. GS1-spezifische Codes in ERC).
    • Empfehlung zur Nutzung des GS1-Codeverzeichnisses für LOC-Angaben.

5. Häufige Fehler und Lösungsansätze

Problem Lösung
Unklare Ortsangabe (z. B. nur "UNB") Präzisierung durch Datenelement-Nummer (z. B. "UNB+0002").
Fehlender Fehlercode in ERC Nutzung standardisierter Codes (z. B. EDIFACT-Fehlercodes nach UNTDID).
Fehlende Referenz auf Ursprungsnachricht Immer RFF+ACD mit korrekter Nachrichten-ID verwenden.
Mehrdeutige FTX-Beschreibung Strukturierte Formulierung (z. B. "Fehler in [Segment]+[Datenelement]").

6. Rechtliche und technische Rahmenbedingungen

  • Compliance: Die APERAK-Nachricht muss den UN/EDIFACT-Syntaxregeln (ISO 9735) entsprechen.
  • Protokollierung: Empfänger sollten APERAK-Nachrichten automatisiert verarbeiten und in Fehlerlogs dokumentieren.
  • Rückmeldung: Bei kritischen Fehlern (z. B. im AHB) ist eine manuelle Prüfung durch den Nachrichtensender erforderlich.

Zusammenfassung der zwingend erforderlichen Informationen

Segment Datenelement Inhalt
RFF 1153 (Qualifier) "ACD" (Application error context)
1154 (Reference number) Referenznummer der fehlerhaften Nachricht
ERC 9321 (Error code) Standardisierter Fehlercode (z. B. "1" für Syntaxfehler)
1049 (Error point indicator) "1" (Fehler im Header/AHB)
LOC 3227 (Qualifier) "19" (Error location)
3225 (Location code) Exakte Position (z. B. "UNB+0002")
FTX 4451 (Qualifier) "AAI" (Error description)
4440 (Free text) Präzise Fehlerbeschreibung

Durch die Einhaltung dieser Struktur wird sichergestellt, dass der Empfänger den Fehler im AHB eindeutig identifizieren und korrigieren kann.