Willi Mako
┌ ┐ └ ┘
// PROTOCOL:

EDIFACT: CONTRL vs. APERAK – Aktivitätsdiagramme im Vergleich

ID#F56-1E
STATUSREAD_ONLY
AUTHORSYS_ADMIN
TAGS [EDIFACT][PROZESS]

Differenzierung der Aktivitätsdiagramme für CONTRL und APERAK in der EDIFACT-Verarbeitung

Die Aktivitätsdiagramme für CONTRL (Syntax- und Strukturprüfung) und APERAK (Anwendungsrückmeldung) bilden unterschiedliche Phasen der EDIFACT-Nachrichtenverarbeitung ab. Während beide Diagramme im CONTRL-Anwendungshandbuch dokumentiert sind, unterscheiden sie sich in Zweck, Ablauf und praktischer Relevanz für den Nachrichtenaustausch. Nachfolgend werden die zentralen Unterschiede sowie Quellen für vertiefende Informationen dargestellt.

1. CONTRL: Syntax- und Strukturprüfung

Zweck: CONTRL dient der technischen Validierung eingehender EDIFACT-Nachrichten. Das Aktivitätsdiagramm bildet den Prozess der Syntaxprüfung ab, bei dem die Nachricht auf formale Korrektheit gemäß den EDIFACT-Regeln (ISO 9735) überprüft wird. Dies umfasst:

  • Segmentstruktur (Reihenfolge, Pflichtsegmente, Wiederholungen)
  • Datenelement-Syntax (Format, Länge, Codes)
  • Kontrollnummern (z. B. UNB/UNZ-Segmente)

Ablauf im Aktivitätsdiagramm:

  1. Empfang der Nachricht (z. B. per AS2, SFTP).
  2. Vorprüfung (z. B. Zeichensatz, Segment-Trennzeichen).
  3. Tiefenprüfung (Segment für Segment, inkl. Referenzintegrität).
  4. Ergebnisgenerierung:
    • Bei Fehlern: CONTRL-Nachricht mit Fehlercodes (z. B. ERR 5 für ungültiges Datenelement).
    • Bei Erfolg: Weiterleitung an die Anwendungsverarbeitung (z. B. APERAK oder fachliche Logik).

Praktische Relevanz: CONTRL ist mandatorisch für jeden EDIFACT-Prozess, da fehlerhafte Nachrichten ohne Syntaxprüfung nicht verarbeitet werden können. Die Diagramme zeigen typischerweise eine lineare Abfolge mit klaren Entscheidungspunkten (z. B. "Fehler ja/nein").

2. APERAK: Anwendungsrückmeldung

Zweck: APERAK (Application Error and Acknowledgement) ist eine fachliche Rückmeldung auf eine zuvor empfangene EDIFACT-Nachricht (z. B. ORDERS, INVOIC). Das Aktivitätsdiagramm beschreibt den Prozess der inhaltlichen Prüfung und der Generierung einer Antwortnachricht. Typische Anwendungsfälle:

  • Bestätigung der korrekten Verarbeitung (z. B. "Rechnung akzeptiert").
  • Fehlermeldung bei fachlichen Problemen (z. B. "Lieferadresse ungültig").
  • Statusupdates (z. B. "Zahlung veranlasst").

Ablauf im Aktivitätsdiagramm:

  1. Empfang der geprüften Nachricht (nach CONTRL).
  2. Fachliche Validierung (z. B. Plausibilitätsprüfung von Preisen, Lieferterminen).
  3. Entscheidung:
    • Bei Erfolg: Generierung einer APERAK-Nachricht mit Akzeptanzcode (z. B. APERAK+AA für "Accepted").
    • Bei Fehlern: Generierung einer APERAK-Nachricht mit Fehlerdetails (z. B. APERAK+AE für "Application Error" + Segment ERC mit Fehlerbeschreibung).
  4. Versand der Rückmeldung an den Absender.

Praktische Relevanz: APERAK ist optional, aber essenziell für transparente Prozesse (z. B. im Bestellwesen). Die Diagramme zeigen oft verzweigte Pfade, da die Rückmeldung von der Art des Fehlers abhängt (z. B. technisch vs. fachlich).

3. Vergleich der Diagramme

Kriterium CONTRL APERAK
Zweck Technische Prüfung Fachliche Rückmeldung
Trigger Empfang jeder EDIFACT-Nachricht Empfang einer geprüften Nachricht
Prüfungstiefe Syntax, Struktur Inhalt, Geschäftsregeln
Ergebnis Fehlercodes (z. B. ERR) Akzeptanz-/Fehlercodes (z. B. AA)
Diagrammstruktur Linear, wenige Verzweigungen Verzweigt, abhängig von Fehlerart
Verpflichtend? Ja Nein (aber empfohlen)

4. Vertiefende Informationen

Die Aktivitätsdiagramme sind in folgenden offiziellen Quellen detailliert beschrieben:

  1. UN/EDIFACT-Standards

    • UN/CEFACT: Offizielle Dokumentation zu CONTRL und APERAK, inkl. Nachrichtentypen und Segmentbeschreibungen.
      • UN/EDIFACT Directory (UNECE)
      • Spezifisch: CONTRL-Nachricht (Syntaxprüfung) und APERAK-Nachricht (Rückmeldung) in den jeweiligen Versionen (z. B. D.23A).

  2. CONTRL-Anwendungshandbuch

    • Enthält die identischen Aktivitätsdiagramme wie im Kontext erwähnt.
    • Verfügbar über:

  3. Branchenspezifische Leitfäden

    • GS1: EDIFACT-Implementierungsrichtlinien für Handel (z. B. EANCOM).
    • Automobilindustrie (ODETTE): Spezifische APERAK-Anwendungen für Lieferketten.

  4. Technische Literatur

    • "EDIFACT: Theorie und Praxis" (Buch von Klaus-Dieter Naujok) – Erläutert CONTRL/APERAK im Kontext.
    • "Electronic Data Interchange" (Buch von David Chappell) – Praktische Beispiele für Rückmeldungsprozesse.

  5. Software-Dokumentation

    • EDI-Konverter (z. B. IBM Sterling B2B Integrator, Seeburger) enthalten oft angepasste Diagramme für die Implementierung.
    • Open-Source-Tools wie EDIReader (Java) oder PyEDI (Python) bieten Code-Beispiele für CONTRL-Prüfungen.

5. Praktische Empfehlungen

  • CONTRL vor APERAK: Die Syntaxprüfung muss immer der fachlichen Prüfung vorgeschaltet sein.
  • Fehlercodes interpretieren: CONTRL-Fehler (z. B. ERR 6 = ungültiges Segment) erfordern technische Korrekturen, APERAK-Fehler (z. B. AE = fachlicher Fehler) betriebliche Anpassungen.
  • Testumgebungen nutzen: Viele EDI-Anbieter stellen Testnachrichten für CONTRL/APERAK bereit (z. B. EDI Academy).

Für eine vollständige Implementierung empfiehlt sich die Kombination aus:

  1. Offiziellen UN/EDIFACT-Standards (für die Syntax),
  2. Branchenspezifischen Leitfäden (für fachliche Regeln),
  3. Praktischen Tools (für die technische Umsetzung).
RELATED_NODES