Einfluss hierarchischer Muss- und Kann-Felder in EDIFACT auf die prozessuale Risikoverteilung bei der Fehlerbehandlung
Die hierarchische Struktur von Muss- und Kann-Feldern in EDIFACT-Nachrichten (z. B. im Segment SG5/RFF und SG5/FTX) definiert nicht nur technische Anforderungen, sondern prägt auch die prozessuale Risikoverteilung zwischen Netzbetreibern, Lieferanten und Marktpartnern. Diese Differenzierung führt in der Praxis häufig zu impliziten Verantwortungslücken, da sie klare Zuweisungen von Handlungs- und Nachweispflichten erschwert. Im Folgenden wird analysiert, wie diese Struktur die Fehlerbehandlung beeinflusst und warum sie systematische Schwachstellen verursacht.
1. Technische Hierarchie und ihre prozessuale Wirkung
a) Muss-Felder: Klare Verantwortung, aber begrenzte Flexibilität
Muss-Felder wie die Transaktionsreferenz (RFF+TN) oder die Vorgangsnummer (RFF+1154) sind verbindlich und dienen der eindeutigen Identifikation von Vorgängen. Ihre Nichtbefüllung führt zu automatischen Ablehnungen durch das EDI-System, was eine hohe Compliance erzwingt. Aus prozessualer Sicht hat dies folgende Konsequenzen:
- Netzbetreiber können sich auf die Vollständigkeit dieser Felder verlassen und bei Fehlern direkt auf den Absender verweisen (z. B. bei fehlender Referenz).
- Lieferanten tragen die primäre Verantwortung für die korrekte Befüllung, da Fehler hier sofort erkennbar sind und zu Rückweisungen führen.
- Marktpartner (z. B. Messstellenbetreiber) profitieren von einer standardisierten Fehlerlokalisierung, da Muss-Felder eine maschinelle Vorprüfung ermöglichen.
Problem: Muss-Felder decken nur formale Aspekte ab (z. B. Referenzierung), nicht jedoch inhaltliche Fehler (z. B. falsche Zählpunktbezeichnung). Hier greifen Kann-Felder – mit gravierenden Folgen für die Risikoverteilung.
b) Kann-Felder: Flexibilität mit Verantwortungsdiffusion
Kann-Felder wie die Fehlerbeschreibung (FTX+AAO) oder Ortsangabe (FTX+4440) sind optional, werden aber in der Praxis oft genutzt, um kontextuelle Informationen zu übermitteln. Ihre Nichtbefüllung führt nicht zu einer Ablehnung, kann jedoch manuelle Nachbearbeitung erfordern. Dies hat folgende Auswirkungen:
- Netzbetreiber können Kann-Felder ignorieren, ohne gegen den Standard zu verstoßen. Fehlt eine Fehlerbeschreibung, wird der Vorgang zwar bearbeitet, aber ohne klare Handlungsanweisung.
- Lieferanten nutzen Kann-Felder häufig, um Zusatzinformationen (z. B. "Zählerstand fehlerhaft") zu übermitteln – allerdings ohne Garantie, dass diese vom Empfänger ausgewertet werden.
- Marktpartner stehen vor dem Problem, dass fehlende Kann-Felder zu längeren Bearbeitungszeiten führen, da Rückfragen nötig werden. Gleichzeitig gibt es keine Sanktion für das Weglassen dieser Felder.
Kritischer Punkt: Kann-Felder schaffen eine Grauzone, in der keine Partei verpflichtet ist, sie zu nutzen oder auszuwerten. Dies führt zu impliziten Verantwortungslücken, da:
- Netzbetreiber sich auf Muss-Felder beschränken und Kann-Felder als "Nice-to-have" behandeln.
- Lieferanten Kann-Felder zwar nutzen, aber keine Gewissheit haben, dass diese berücksichtigt werden.
- Marktpartner bei unklaren Fehlern keinen Anspruch auf zusätzliche Informationen haben, da diese nicht verpflichtend sind.
2. Prozessuale Risikoverteilung und ihre Schwachstellen
a) Automatisierte vs. manuelle Fehlerbehandlung
- Muss-Felder ermöglichen eine vollautomatisierte Vorprüfung. Fehler hier führen zu sofortigen Rückweisungen, was die Verantwortung klar beim Absender belässt.
- Kann-Felder erfordern manuelle Intervention, da sie keine standardisierte Auswertung zulassen. Dies führt zu:
- Verzögerungen, wenn Netzbetreiber Kann-Felder nicht auswerten und stattdessen Rückfragen stellen.
- Mehrdeutigkeiten, wenn Fehlerbeschreibungen (FTX+AAO) unpräzise sind (z. B. "Daten fehlerhaft" statt "Zählerstand außerhalb des Toleranzbereichs").
- Nachweisschwierigkeiten, da Kann-Felder keine rechtliche Verbindlichkeit haben. Ein Lieferant kann nicht nachweisen, dass er eine Fehlerbeschreibung übermittelt hat, wenn der Netzbetreiber diese ignoriert.
b) Implizite Verantwortungslücken durch fehlende Eskalationsmechanismen
Die EDIFACT-Struktur sieht keine hierarchische Eskalation vor, wenn Kann-Felder fehlen oder unzureichend sind. Dies führt zu:
- Vermeidungsstrategien der Netzbetreiber:
- Da Kann-Felder keine Ablehnungsgrundlage darstellen, werden sie oft nicht priorisiert – selbst wenn sie für die Fehlerbehebung entscheidend wären.
- Beispiel: Ein Netzbetreiber bearbeitet eine Reklamation ohne Ortsangabe des Fehlers, obwohl diese die Lösung beschleunigen würde.
- Unklare Haftung bei Folgefehlern:
- Wenn ein Kann-Feld (z. B. eine detaillierte Fehlerbeschreibung) nicht genutzt wird, kann keine Partei nachträglich zur Verantwortung gezogen werden.
- Beispiel: Ein Lieferant übermittelt eine unklare Fehlermeldung ("Daten inkonsistent"), der Netzbetreiber korrigiert den Fehler falsch, und der Marktpartner trägt die Kosten – ohne dass eine Partei haftbar gemacht werden kann.
- Fehlende Anreize für präzise Fehlerkommunikation:
- Da Kann-Felder keine unmittelbaren Konsequenzen haben, besteht kein Druck, sie präzise zu befüllen. Dies führt zu oberflächlichen Fehlerbeschreibungen, die die Fehlerbehebung erschweren.
3. Warum führt diese Struktur zu systematischen Problemen?
Die hierarchische Differenzierung zwischen Muss- und Kann-Feldern in EDIFACT ist technisch sinnvoll, aber prozessual unzureichend, weil:
- Keine dynamische Verantwortungszuweisung:
- Muss-Felder sind statisch (z. B. Referenznummer), während Kann-Felder kontextabhängig sind (z. B. Fehlerbeschreibung). Die EDIFACT-Struktur sieht keine bedingte Pflicht vor (z. B. "Wenn Fehlercode X, dann muss FTX+AAO befüllt werden").
- Fehlende Standardisierung der Kann-Felder:
- Kann-Felder wie FTX+AAO erlauben freien Text, was zu uneinheitlichen Formulierungen führt. Eine maschinelle Auswertung ist damit unmöglich, und manuelle Bearbeitung wird nötig.
- Keine Sanktionierung von Nichtnutzung:
- Da Kann-Felder keine Ablehnungsgrundlage sind, gibt es keinen Mechanismus, der ihre Nutzung erzwingt – selbst wenn sie für die Fehlerbehebung kritisch sind.
- Asymmetrische Informationsverteilung:
- Der Lieferant kennt den Fehler oft besser als der Netzbetreiber, hat aber keine Garantie, dass seine Kann-Feld-Informationen berücksichtigt werden. Der Netzbetreiber wiederum kann sich auf Muss-Felder zurückziehen, selbst wenn diese für die Fehlerlösung nicht ausreichen.
4. Lösungsansätze zur Schließung der Verantwortungslücken
Um die prozessualen Risiken zu minimieren, wären folgende Anpassungen erforderlich:
- Bedingte Pflichtfelder einführen:
- Beispiel: "Wenn Fehlercode ERC+Z29 (Dateninkonsistenz) übermittelt wird, muss FTX+AAO mit einer detaillierten Beschreibung befüllt werden."
- Dies würde automatische Prüfungen ermöglichen und manuelle Rückfragen reduzieren.
- Standardisierte Fehlerbeschreibungen vorgeben:
- Statt freien Texts (FTX+4440) könnten vordefinierte Fehlerkategorien (z. B. "Zählerstand außerhalb Toleranz", "Falsche Zählpunkt-ID") verwendet werden, die maschinell auswertbar sind.
- Eskalationsmechanismen für Kann-Felder:
- Wenn ein Kann-Feld nicht befüllt wird, könnte das System eine automatische Rückfrage an den Absender senden, bevor der Vorgang weiterbearbeitet wird.
- Verbindliche Auswertungsregeln für Netzbetreiber:
- Netzbetreiber sollten verpflichtet werden, Kann-Felder innerhalb einer Frist zu prüfen und bei Unklarheiten aktiv nachzufragen – ähnlich wie bei Muss-Feldern.
Fazit
Die hierarchische Struktur von Muss- und Kann-Feldern in EDIFACT führt zu einer asymmetrischen Risikoverteilung, bei der:
- Muss-Felder klare Verantwortlichkeiten schaffen, aber nur formale Fehler abdecken,
- Kann-Felder zwar inhaltliche Fehler beschreiben könnten, aber keine Verbindlichkeit haben.
Dies resultiert in impliziten Verantwortungslücken, da keine Partei verpflichtet ist, Kann-Felder zu nutzen oder auszuwerten. Die Folge sind verzögerte Fehlerbehebungen, unklare Haftungsfragen und ineffiziente manuelle Nachbearbeitungen. Eine Reform der EDIFACT-Struktur – etwa durch bedingte Pflichtfelder oder standardisierte Fehlerbeschreibungen – wäre notwendig, um diese Schwachstellen zu beseitigen und die prozessuale Risikoverteilung zwischen den Marktpartnern zu verbessern.