EDIFACT-Feldstrukturen: Risikoverteilung bei Lieferantenwechsel

Einfluss hierarchischer Feldstrukturen in EDIFACT auf die Risikoverteilung bei Lieferantenwechseln und Netzanschlussprozessen

1. Hierarchische Feldtypen in EDIFACT und ihre rechtliche Relevanz

EDIFACT-Nachrichten (z. B. im Rahmen der GPKE für Strom oder GeLi Gas) basieren auf einer klaren Unterscheidung zwischen Muss- (M), Bedingungs- (C) und Optional-Feldern (O/D). Diese Hierarchie bestimmt die Verantwortungs- und Risikoverteilung zwischen Marktpartnern (Lieferanten, Netzbetreibern, Messstellenbetreibern) bei Prozessen wie:

• Lieferantenwechsel (z. B. Wechselmeldungen via UTILMD),
• Netzanschlussprozesse (z. B. CONTRL- oder APERAK-Nachrichten),
• Störungsmanagement (z. B. MSCONS-Ablehnungen).

1.1 Muss-Felder (Mandatory – M)

• Definition: Pflichtangaben, deren Fehlen oder fehlerhafte Befüllung zur automatischen Ablehnung der Nachricht führt (z. B. BGM+313 für eine Wechselmeldung).
• Risikoverteilung:
  • Der Sender trägt das volle Risiko für die korrekte Übermittlung. Fehlt ein Muss-Feld, gilt die Nachricht als nicht empfangen (vgl. § 4 Abs. 2 GPKE).
  • Der Empfänger ist berechtigt, die Nachricht ohne weitere Prüfung zurückzuweisen, was zu Verzögerungen im Prozess (z. B. verspätete Lieferantenwechsel) oder Vertragsstrafen führen kann.
• Beispiel: Das DTM-Segment mit Qualifier 137 (Dokumentendatum) ist in vielen MIGs als R (Required) eingestuft. Fehlt es, scheitert die Validierung bereits auf syntaktischer Ebene.

1.2 Bedingte Felder (Conditional – C)

• Definition: Felder, deren Pflichtcharakter von vorherigen Segmenten oder Geschäftsregeln abhängt (z. B. DTM+137 nur bei bestimmten Nachrichtentypen).
• Risikoverteilung:
  • Interpretationsspielraum: Bedingte Felder führen häufig zu unterschiedlichen Auslegungen der Marktpartner. Beispiel:
    • Ein Netzbetreiber interpretiert ein C-Feld als implizit erforderlich, während der Lieferant es als optional behandelt.
    • Dies kann zu manuellen Nachbearbeitungen oder Ablehnungen führen, obwohl die Nachricht technisch korrekt ist.
  • Haftungsfrage: Bei fehlerhafter Befüllung liegt das Risiko beim Sender, sofern die Bedingung (z. B. ein vorheriges RFF-Segment) erfüllt war. Fehlt die Bedingung, ist das Feld irrelevant.
• Beispiel: Das DTM-Segment mit Qualifier 361 (Ablehnungsdatum) ist nur erforderlich, wenn zuvor ein APERAK-Segment mit Ablehnungsgrund (ERC+12) gesendet wurde.

1.3 Optionale Felder (Optional – O / Dependent – D)

• Definition: Felder, die freiwillig oder nur in bestimmten Kontexten genutzt werden (z. B. FTX für Freitextkommentare).
• Risikoverteilung:
  • Keine direkte Haftung, aber prozessuale Risiken:
    • Fehlende optionale Felder können zu Nachfragen führen, die den Prozess verzögern.
    • Bei regulatorischen Anforderungen (z. B. Nachweispflichten nach EnWG) kann die Nichtnutzung optionaler Felder als mangelnde Sorgfalt ausgelegt werden.
  • Beispiel: Ein NAD-Segment mit Lieferantenreferenz (3035=SU) ist oft optional, aber für die eindeutige Identifikation im Störungsfall relevant.

2. Prozessuale Sicherheitsmechanismen zur Compliance-Sicherung

Um regulatorische Vorgaben (GPKE, GeLi Gas, MaBiS) trotz unterschiedlicher Feldinterpretationen einzuhalten, sind mehrstufige Validierungs- und Eskalationsprozesse erforderlich:

2.1 Technische Validierungsebenen

2.2 Organisatorische Maßnahmen

1. Klare MIG-Dokumentation

   • Verbindliche Festlegung der Feldabhängigkeiten in den Message Implementation Guides (MIGs).
   • Beispiel: Im BDEW-MIG muss explizit definiert sein, unter welchen Bedingungen ein DTM-Segment mit Qualifier 137 als R (Required) gilt.

2. Automatisierte Plausibilitätsprüfungen

   • Regelbasierte Systeme (z. B. EDI-Gateways) müssen Bedingungslogiken abbilden.
   • Beispiel: Ein DTM+137 darf nicht älter als 3 Tage sein, wenn es in einer UTILMD-Nachricht für einen Lieferantenwechsel verwendet wird.

3. Eskalationsprozesse bei Abweichungen

   • Stufenweise Bearbeitung:
     1. Automatische Ablehnung bei Muss-Feld-Fehlern.
     2. Manuelle Prüfung bei Bedingungsfeld-Abweichungen (z. B. durch ein Clearing-Center).
     3. Fristgebundene Klärung (z. B. innerhalb von 2 Werktagen nach § 5 GPKE).

4. Audit-Trails und Nachweispflichten

   • Protokollierung aller Validierungsschritte (z. B. in CONTRL-Nachrichten).
   • Beispiel: Bei einer Ablehnung muss der Netzbetreiber den genauen Grund (APERAK+ERC) dokumentieren, um Beweispflichten nach § 44 EnWG zu erfüllen.

5. Marktpartner-übergreifende Testverfahren

   • Pilotphasen vor der Einführung neuer MIG-Versionen, um Interpretationskonflikte frühzeitig zu identifizieren.
   • Beispiel: Der BDEW führt vor der Veröffentlichung einer MIG-Änderung Round-Trip-Tests mit ausgewählten Marktpartnern durch.

3. Regulatorische Compliance und Haftungsfragen

Die Einhaltung der GPKE (Strom) und GeLi Gas erfordert:

• Eindeutige Verantwortungszuweisung:
  • Der Sender haftet für die korrekte Befüllung aller Muss- und bedingten Felder.
  • Der Empfänger muss automatisierte Validierungen durchführen und darf Nachrichten nur bei technischen Fehlern ablehnen (vgl. § 6 Abs. 2 GPKE).
• Dokumentationspflichten:
  • Alle Prozessschritte (Validierung, Ablehnung, Klärung) müssen revisionssicher protokolliert werden.
  • Beispiel: Bei einer Ablehnung wegen eines fehlenden DTM-Segments muss der Netzbetreiber dies im Marktkommunikationssystem vermerken.
• Fristenmanagement:
  • Verzögerungen durch manuelle Nachbearbeitung müssen vermieden werden, da sie zu Vertragsstrafen führen können (z. B. bei verspäteten Lieferantenwechseln).

4. Fazit und Handlungsempfehlungen

Die hierarchische Struktur von EDIFACT-Feldern führt zu komplexen Risikoverteilungen, die nur durch technische und organisatorische Sicherheitsmechanismen beherrschbar sind. Marktpartner sollten:

1. MIGs präzise umsetzen und Feldabhängigkeiten eindeutig dokumentieren.
2. Mehrstufige Validierungen (syntaktisch, semantisch, geschäftsregelbasiert) etablieren.
3. Eskalationsprozesse für Bedingungsfeld-Abweichungen definieren.
4. Regelmäßige Tests durchführen, um Interpretationskonflikte zu minimieren.
5. Audit-Trails für regulatorische Nachweise nutzen.

Durch diese Maßnahmen lässt sich die Compliance mit GPKE, GeLi Gas und EnWG sicherstellen, während gleichzeitig Prozessrisiken zwischen den Marktpartnern fair verteilt werden.