EDIFACT: CONTRL & APERAK in Fehlerprozessen optimieren

Einfluss der parallelen Nutzung von CONTRL- und APERAK-Nachrichten auf Fehlerbehandlungsprozesse in der EDIFACT-Kommunikation zwischen Netzbetreibern und Lieferanten

1. Grundlegende Funktionsweise von CONTRL und APERAK

Die EDIFACT-Nachrichten CONTRL (Syntax- und Strukturprüfung) und APERAK (Anwendungsfehlerrückmeldung) dienen unterschiedlichen, aber komplementären Zwecken in der elektronischen Datenkommunikation:

• CONTRL (Control Message):

  • Überprüft die syntaktische Korrektheit einer eingehenden EDIFACT-Nachricht gemäß den definierten Standards (z. B. UN/EDIFACT, branchenspezifische Subsets).
  • Erkennt formale Fehler wie fehlende Segmente, ungültige Codes oder strukturelle Abweichungen.
  • Wird automatisiert generiert und zurückgesendet, sobald eine Nachricht empfangen wird.
  • Keine inhaltliche Prüfung – lediglich technische Validierung.

• APERAK (Application Error and Acknowledgement Message):

  • Dient der inhaltlichen Fehlerrückmeldung auf Anwendungsebene (z. B. ungültige Vertragsnummern, falsche Zählerstände, nicht zuordenbare Referenzen).
  • Wird manuell oder teilautomatisiert erstellt, nachdem eine Nachricht inhaltlich verarbeitet wurde.
  • Enthält detaillierte Fehlermeldungen mit Referenzen auf die betroffenen Datenelemente.

2. Auswirkungen auf die Fehlerbehandlung bei paralleler Nutzung

Die Kombination beider Nachrichten führt zu einem zweistufigen Fehlerbehandlungsprozess, der die Eskalationsstufen und Verantwortlichkeiten klar strukturiert:

a) Technische Fehler (CONTRL-Ebene)

• Erkennung: Syntaktische Fehler (z. B. falsche Segmentreihenfolge, ungültige Zeichensätze) werden sofort durch CONTRL identifiziert.
• Reaktion:
  • Die fehlerhafte Nachricht wird abgelehnt und nicht weiterverarbeitet.
  • Der Absender erhält eine CONTRL-Nachricht mit Fehlercodes (z. B. UNS für ungültige Segmentreihenfolge).
  • Keine inhaltliche Bearbeitung – der Fehler muss vom Absender korrigiert und neu übermittelt werden.
• Eskalation:
  • Bei wiederholten technischen Fehlern kann eine manuelle Prüfung durch den IT-Support beider Parteien erforderlich werden.
  • Regulatorisch relevant: Gemäß § 47 EnWG (Energiewirtschaftsgesetz) müssen Netzbetreiber sicherstellen, dass Daten korrekt übermittelt werden. Technische Fehler können daher zu Verzögerungen in der Abrechnung führen, was ggf. eine Meldung an die Bundesnetzagentur (BNetzA) nach sich zieht.

b) Inhaltliche Fehler (APERAK-Ebene)

• Erkennung: Nach erfolgreicher CONTRL-Prüfung wird die Nachricht inhaltlich verarbeitet. Fehler wie falsche Stammdaten oder logische Inkonsistenzen (z. B. negative Verbrauchswerte) werden via APERAK gemeldet.
• Reaktion:
  • Der Empfänger sendet eine APERAK-Nachricht mit spezifischen Fehlerhinweisen (z. B. Fehlercode 501: Ungültige Zählernummer).
  • Der Absender muss die Daten korrigieren und eine neue, fehlerfreie Nachricht übermitteln.
• Eskalation:
  • Bei wiederholten inhaltlichen Fehlern (z. B. mehrfache Falschmeldungen von Zählerständen) kann eine prozessuale Eskalation erfolgen:
    • Stufe 1: Automatisierte Warnung via APERAK.
    • Stufe 2: Manuelle Klärung zwischen den Fachabteilungen (z. B. Abrechnung des Lieferanten und Marktkommunikation des Netzbetreibers).
    • Stufe 3: Einbindung der Bundesnetzagentur (BNetzA) oder des Bundesverbands der Energie- und Wasserwirtschaft (BDEW), falls die Fehler zu Abrechnungsverzögerungen oder Marktstörungen führen (vgl. MaBiS – Marktregeln für die Durchführung der Bilanzkreisabrechnung Strom).
  • Regulatorische Abhängigkeiten:
    • GPKE (Geschäftsprozesse zur Kundenbelieferung mit Elektrizität) und GeLi Gas (Geschäftsprozesse Lieferantenwechsel Gas) definieren Fristen für die Fehlerbehebung (z. B. 2 Werktage für die Korrektur von Stammdaten).
    • Bei Nichteinhaltung drohen Vertragsstrafen oder Ausschluss aus dem Marktkommunikationsprozess.

3. Prozessuale und regulatorische Abhängigkeiten

Die parallele Nutzung von CONTRL und APERAK führt zu folgenden Abhängigkeiten und Anforderungen:

a) Zeitliche Synchronisation

• CONTRL muss vor der inhaltlichen Verarbeitung erfolgen, um sicherzustellen, dass nur syntaktisch korrekte Nachrichten weitergeleitet werden.
• APERAK darf erst nach erfolgreicher CONTRL-Prüfung und inhaltlicher Validierung gesendet werden.
• Fristen:
  • Gemäß GPKE/GeLi muss eine APERAK innerhalb von 2 Werktagen nach Fehlererkennung versendet werden.
  • Die Korrektur durch den Absender hat innerhalb von 5 Werktagen zu erfolgen.

b) Dokumentationspflichten

• Beide Parteien müssen Fehlerprotokolle (CONTRL- und APERAK-Nachrichten) für mindestens 3 Jahre archivieren (vgl. § 257 HGB, GoBD).
• Bei Streitfällen dienen diese als Beweismittel für die Einhaltung der Marktregeln.

c) Eskalationsstufen und regulatorische Konsequenzen

4. Empfehlungen für die Praxis

1. Automatisierung der Fehlerbehandlung:

   • CONTRL-Prüfungen sollten vollautomatisiert ablaufen, um manuelle Eingriffe zu minimieren.
   • APERAK-Nachrichten können teilautomatisiert generiert werden, um die Bearbeitungszeit zu verkürzen.

2. Schulung der Mitarbeiter:

   • Fachabteilungen müssen in der Interpretation von APERAK-Fehlermeldungen geschult werden, um schnelle Korrekturen zu ermöglichen.

3. Monitoring und Reporting:

   • Ein zentrales Fehler-Logging hilft, wiederkehrende Probleme zu identifizieren und proaktiv zu lösen.
   • Regelmäßige Audits durch die BNetzA oder interne Revisionen stellen die Einhaltung der Marktregeln sicher.

4. Klare Verantwortlichkeiten:

   • Netzbetreiber und Lieferanten sollten SLA (Service Level Agreements) für die Fehlerbehebung vereinbaren, um Eskalationen zu vermeiden.

Fazit

Die parallele Nutzung von CONTRL und APERAK ermöglicht eine effiziente, zweistufige Fehlerbehandlung, die technische und inhaltliche Validierung trennt. Während CONTRL syntaktische Fehler sofort erkennt und abweist, dient APERAK der detaillierten Rückmeldung von Anwendungsfehlern. Die Einhaltung der regulatorischen Vorgaben (EnWG, GPKE/GeLi, MaBiS) ist dabei verpflichtend, um Abrechnungsverzögerungen, Vertragsstrafen oder Marktausschlüsse zu vermeiden. Eine automatisierte, gut dokumentierte Fehlerbehandlung ist daher essenziell für die reibungslose EDIFACT-Kommunikation zwischen Netzbetreibern und Lieferanten.