Codelisten und Entscheidungsbaumdiagramme

Kurzantwort

Codelisten und Entscheidungsbaumdiagramme (EBD) sind die Regeln, die bestimmen, ob eine eingehende Marktnachricht fachlich korrekt ist. Codelisten definieren, welche Werte für ein Feld zulässig sind (z. B. „01” für „Lieferbeginn” in einem Prüfidentifikator). Entscheidungsbaumdiagramme zeigen, welcher Pfad eine Nachricht gehen muss – abhängig von ihrem Inhalt und dem Code. Ist ein Code ungültig oder ein Pfad nicht zulässig, wird die Nachricht abgelehnt oder eine Klärung ausgelöst. Damit sind Codelisten und EBD nicht nur Nachschlagewerke, sondern die ausführbare Fachlogik der Marktkommunikation.

Wozu Codelisten und Entscheidungsbaumdiagramme dienen

Marktnachrichten sind strukturiert und kodiert. Jedes Feld einer UTILMD oder MSCONS trägt einen Wert, dessen Bedeutung durch seinen Code festgelegt ist. Ein Prüfidentifikator „01” bedeutet etwas anderes als „02” – und wenn ein Empfänger einen Code „99” sieht, für den es keine Definition gibt, kann er die Nachricht nicht verarbeiten.

Codelisten sind deshalb kein optionales Nachschlagewerk. Sie sind die verbindliche Spezifikation für jeden Wert, den eine Nachricht enthalten darf. Sie legen fest:

• Welche Codes existieren überhaupt.
• Welche Bedeutung jeder Code hat.
• In welchem Kontext ein Code zulässig ist.
• Ab welchem Datum ein Code gültig oder ungültig wird.

Entscheidungsbaumdiagramme gehen einen Schritt weiter. Sie beschreiben die Logik: Wenn eine Nachricht diesen Code hat und jene Bedingung erfüllt ist, dann muss diese Antwort folgen. Sie verbinden Code, Kontext und Folgeaktion zu einer Entscheidungskaskade. Zusammen bilden Codelisten und EBD die ausführbare Spezifikation, nach der ein System Nachrichten prüft und verarbeitet.

Aufbau und Versioning von Codelisten

Codelisten werden von der Bundesnetzagentur in Mitteilungen zu Datenformaten veröffentlicht. Aktuell gültig (Stand 9. September 2026) ist die Version 4.2, die seit dem 1. April 2026 bindend ist. Am 1. Oktober 2026 tritt Version 4.3 in Kraft. Jede neue Version enthält erweiterte, überarbeitete oder entfernte Codes.

Eine Codeliste enthält typischerweise:

Die Codelisten sind als Excel-, XML- und AWT-Dateien verfügbar. Sie unterliegen einer strikten Versionierung: Eine Änderung an einem Code, eine neue Kodierung oder ein Gültigkeitsdatum ist ein Versionssprung. Wer ein älteres Verzeichnis verwendet, akzeptiert möglicherweise Codes, die längst ungültig sind – oder lehnt neue Codes ab, die gerade wirksam wurden.

Häufige Codelisten in der Marktkommunikation sind:

• Prüfidentifikatoren: Beschreiben den Geschäftsvorfall (z. B. Liiferbeginn, Liiferende, Stammdatenänderung).
• Antwortcodes: Sind Gründe für die Ablehnung oder Bestätigung einer Nachricht.
• Statuscodes: Beschreiben den Zustand eines Messwerts (z. B. „geschätzt”, „kalibriert”, „korrigiert”).
• OBIS-Kennzahlen: Identifizieren Messwertarten (z. B. 1.8.0 für Gesamtenergie, Verbrauch).
• Grundcodes: Dienen der Abrechnung und Bilanzierung (z. B. Grund für eine Lieferende).

Entscheidungsbaumdiagramme: Fachlogik im Flussdiagramm

Während Codelisten einzelne Codes aufzählen, zeigen Entscheidungsbaumdiagramme den Weg einer Nachricht durch die Verarbeitung. Ein EBD ist eine grafische Darstellung, die liest: „Wenn die Nachricht diesen Code hat UND diese Bedingung erfüllt ist, DANN folgt diese Aktion.”

Ein vereinfachtes Beispiel für einen Liiferbeginn nach GPKE könnte lauten:

1. Eingehende UTILMD mit Prüfidentifikator „Liiferbeginn”.
2. Ist die Marktlokation im Netz des Netzbetreibers?
   • Ja → Weiter zu Schritt 3.
   • Nein → Ablehnung mit Antwortcode „Marktlokation nicht im Netz”.
3. Ist der angeforderte Liiferbeginn fachlich zulässig?
   • Ja → Zuordnung bestätigen.
   • Nein → Ablehnung mit Grund für Zurückweisung.

Die EBD macht diese Logik visuell explicit, sodass Entwickler, Tester und Qualitätssicherer nachvollziehen können, in welchem Fall eine Antwort erwartet wird. Sie sind die Brücke zwischen den Anwendungshandbüchern (AHB) und der Systemimplementierung.

Prüfidentifikatoren als Routing-Logik

Ein kritischer Code in jeder UTILMD ist der Prüfidentifikator (auch „Geschäftsvorfall-Code”). Er legt fest, welcher Prozess gemeint ist. Der Empfänger liest den Prüfidentifikator und entscheidet darauf, welche EBD er anwendet.

Ein vereinfachtes Beispiel:

Die Codeliste der Prüfidentifikatoren wird von der Bundesnetzagentur zentral gepflegt und mit jeder neuen Formatversion aktualisiert. Ein Code „99”, der nicht in der Liste existiert, wird von einem korrekten Empfängersystem nicht verarbeitet.

Für SAP-IS-U-Berater ist dies zentral: Der Prüfidentifikator ist nicht nur ein Datenfeld. Er ist der Schlüssel zum Routing. Ein System, das den Prüfidentifikator nicht konsequent nutzt, um die passende Verarbeitung zu wählen, wird alle UTILMD-Nachrichten gleich behandeln – und damit Lieferbeginne als Liifferenden verarbeiten oder umgekehrt.

Ungültige und veraltete Codes: Was passiert?

Ein Szenario aus der Praxis: Ein Lieferant sendet eine Nachricht mit einem Code „A7”, den er aus einer alten Codeliste kennt. Die aktuelle Codeliste (Version 4.2, gültig ab 1. April 2026) hat diesen Code nicht mehr. Was passiert?

Ein korrekter Empfänger wird:

1. Den Code gegen die gültigen Codelisten prüfen.
2. Feststellen, dass der Code nicht existiert.
3. Eine Fehlerantwort (APERAK oder CONTRL) senden.
4. Die Nachricht nicht verarbeiten.

Manche Systeme sind so konfiguriert, dass sie ungültige Codes in einen Standardwert umwandeln oder Warnmeldungen erzeugen. Das ist aus Fachsicht problematisch. Eine Nachricht mit einem ungültigen Code ist potenziell nicht richtig verstanden worden. Sie sollte abgelehnt werden, bis die Fehlerursache geklärt ist.

Ähnlich wird es problematisch, wenn ein Unternehmen zu früh mit einer neuen Codelisten-Version arbeitet. Wenn Version 4.3 erst am 1. Oktober 2026 bindend ist, aber ein Sender sie schon am 15. September nutzt, lehnt der Empfänger ab, weil der Code „noch nicht gültig” ist. Der Stichtag ist nicht verhandelbar.

Zuordnung im Anwendungshandbuch

Die Bundesnetzagentur und BDEW veröffentlichen Anwendungshandbücher (AHB) für jeden Nachrichtentyp und Prozess. Das AHB beschreibt Feld für Feld, welche Codes zulässig sind und wann sie passen. Es verweist auf die Codelisten und wird mit jeder neuen Codelisten-Version aktualisiert.

Wer eine Nachricht verarbeitet, sollte sie nicht nur gegen die Codelisten, sondern gegen das AHB prüfen:

• Ist das Feld erforderlich oder optional?
• Welche Codes sind in diesem Kontext zulässig?
• Welche Kombinationen von Codes sind nicht erlaubt?
• Welche EBD beschreibt die Verarbeitung, wenn der Code vorhanden ist?

Ein AHB ist typischerweise über 1000 Seiten lang. Es dokumentiert den kompletten Nachrichtentyp mit allen möglichen Prozessausprägungen. Nur mit dem AHB kann ein Entwickler sicherstellen, dass er die Codes korrekt und vollständig umsetzt.

SAP-IS-U-Perspektive: Validierung eingehender Nachrichten

In einem SAP-IS-U-System werden eingehende Nachrichten über Integrationsbaustein- oder EDIFACT-Eingangspuffer verarbeitet. Ein kritischer Verarbeitungsschritt ist die Validierung:

1. Syntaxprüfung: Ist die Nachricht strukturell gültig EDIFACT?
2. Codelisten-Prüfung: Sind alle Codes in den Codelisten enthalten?
3. AHB-Prüfung: Erfüllen die Felder und Codes die Anforderungen des Anwendungshandbuchs?
4. EBD-Prüfung: Folgt die Nachricht dem für ihren Geschäftsvorfall erwarteten Pfad?
5. Geschäftsregel-Prüfung: Sind alle fachlichen Bedingungen erfüllt (z. B. Marktlokation vorhanden, Zeitpunkt zulässig)?

Ein System, das nur die Syntaxprüfung macht, akzeptiert ungültige Codes. Ein System, das nur Codes prüft, aber nicht das AHB anwendet, verarbeitet möglicherweise Nachrichten in einem falschen Kontext.

Für die Qualitätssicherung sollte deshalb ein Prüfprotokoll dokumentieren:

• Welche Codelisten-Version wurde verwendet?
• Welches AHB wurde angewendet?
• Welche EBD-Prüfung hat stattgefunden?
• Bei Ablehnung: Welcher Prüfschritt hat die Nachricht gestoppt?

Ein Fehler in diesem Protokoll – etwa weil ein anderes AHB verwendet wurde – führt zu Fehlverarbeitungen oder zu Ablehnungen, die eigentlich zu Bestätigungen hätten führen sollen.

Typische Missverständnisse

„Ein Code ist universell gültig.“
Nein. Ein Code gilt nur in seinem Kontext. Antwortcode „01” kann „Liiferbeginn bestätigt” bedeuten, hat aber in einer MSCONS keinen Platz. Das AHB definiert, wo jeder Code zulässig ist.

„Wenn der Code in der Codeliste existiert, kann ich ihn verwenden.“
Nein. Der Code muss zusätzlich im richtigen Feld, in der richtigen Nachrichtentyp-Version und in der richtigen Prozessausprägung verwendet werden. Das AHB ist verbindlich.

„Ein ungültiger Code kann ich durch einen ähnlichen Code ersetzen.“
Nein. Das System muss die Nachricht ablehnen. Stille Ersetzungen führen zu falschen Zuordnungen und unerkannten Fehlern.

„Entscheidungsbaumdiagramme sind optional – sie sind nur zur Veranschaulichung.“
Nein. Die EBD beschreiben die bindenden Verarbeitungsregeln. Wer nicht nach der EBD verarbeitet, verletzt die Marktkommunikations-Spezifikation.

„Alte Codelisten sind rückwärtskompatibel.“
Nein. Alte Codes werden entfernt oder geändert. Ein Stichtag ist nicht verhandelbar. Ab dem Gültigkeitsdatum einer neuen Version gilt die neue Codeliste für alle Sender und Empfänger verbindlich.

Quellen und Pflegehinweis

Codelisten und Entscheidungsbaumdiagramme sind zentrale, sich ständig weiterentwickelnde Fachspezifikationen. Neue Versionen treten an definierten Stichtagen in Kraft. Bei der Umsetzung und beim Betrieb müssen die zum Stichtag gültigen Versionen verwendet werden.

Die aktuell gültige Version (Stand 9. September 2026) ist 4.2, gültig seit 1. April 2026. Die nächste Version 4.3 tritt am 1. Oktober 2026 in Kraft. Die Versionshistorie und Änderungshinweise sind in den Mitteilungen der Bundesnetzagentur dokumentiert.

• Bundesnetzagentur: Mitteilung Nr. 54 zu Datenformaten (gültig ab 01.04.2026)
• Bundesnetzagentur: Mitteilung Nr. 56 zu Datenformaten (gültig ab 01.10.2026)
• BDEW: Marktkommunikation und EDI@Energy-Dokumente
• BDEW-MaKo-Plattform: Zentrales Dokumentenportal
• Hochfrequenz: Entscheidungsbaumdiagramme als interaktives Visualisierungstool

Prüfhinweise zur Pflege dieses Artikels:

• Codelisten-Version: Bis zum 30. September 2026 ist Version 4.2 gültig; ab 1. Oktober 2026 gilt Version 4.3. Diese Aussage muss zum nächsten Wartungstermin nach Anfang Oktober überprüft werden.
• AHB-Versionen: Die Anwendungshandbücher werden zeitgleich mit neuen Codelisten-Versionen aktualisiert. Die aktuelle AHB-Version sollte auf der BDEW-MaKo-Plattform überprüft werden.
• Neue Prozessgebiete: Falls GPKE, WiM oder MaBiS durch neue Regelwerke ergänzt oder ersetzt werden, muss dieser Artikel um die neuen Codelisten erweitert werden.

Abrufdatum aller Quellen: 9. September 2026.