Prüfidentifikatoren in der Marktkommunikation verstehen

Kurzantwort

Ein Prüfidentifikator (Prüfi) ist eine fachliche Kennung für eine konkrete Ausprägung eines Marktprozesses. Er sagt einem System, welchen Anwendungsfall es in einer Nachricht prüfen und verarbeiten soll. Der Prüfi ist damit kein allgemeiner Nachrichtentyp und auch kein Fehlercode. Ein Nachrichtentyp wie UTILMD oder ORDERS beschreibt die technische Familie; der Prüfi grenzt innerhalb dieser Familie den Geschäftsvorgang ein. Die verbindliche Zuordnung steht in der jeweils gültigen Anwendungsübersicht der Prüfidentifikatoren und im passenden Anwendungshandbuch (AHB).

Die Reihenfolge ist entscheidend: Zuerst wird aus dem Prozess die benötigte Nachricht und ihre Version bestimmt, danach der Prüfi, anschließend werden die im AHB geforderten Segmente und Codes aufgebaut. Ein plausibel aussehender Prüfi macht eine Nachricht nicht automatisch fachlich richtig. Gültigkeit hängt immer von Nachrichtentyp, Version, Marktrolle, Richtung, Prozess und Gültigkeitsdatum ab.

Die vier Ebenen sauber trennen

EDIFACT ist zunächst eine international definierte Syntax: Segmente, Datenelemente, Trennzeichen und Nachrichtenstruktur. EDI@Energy präzisiert diese Syntax für die deutsche Energiewirtschaft. Ein MIG (Message Implementation Guide) beschreibt, welche EDIFACT-Segmente und Datenelemente grundsätzlich in einer Nachricht vorkommen können und wie sie strukturell angeordnet sind. Der MIG ist keine vollständige Prozessbeschreibung.

Das AHB (Anwendungshandbuch) beschreibt dagegen eine konkrete Anwendung innerhalb dieser Nachricht: Rollen, Bedingungen, Muss-/Kann-Regeln, Codes, Abhängigkeiten und Hinweise. Es beantwortet die Frage, was in einem bestimmten Geschäftsvorfall tatsächlich gesendet wird. Der Prüfidentifikator ist das Bindeglied, mit dem diese konkrete AHB-Anwendung ausgewählt wird.

Der Marktprozess ist die fachliche Regelwelt darüber: GPKE, GeLi Gas, WiM oder MaBiS legen fest, wer wem welche Information wann übermittelt. Ein Transportweg wie AS4 ist wiederum nur der sichere technische Kanal. Er ersetzt weder den Prozess noch die AHB-Prüfung.

Was der Prüfidentifikator leistet

Eine EDIFACT-Nachricht kann dieselben Segmente in mehreren fachlichen Situationen verwenden. Ein NAD-Segment kann etwa Beteiligte in unterschiedlichen Rollen kennzeichnen; ein RFF-Segment kann verschiedene Referenzen tragen. Erst der konkrete AHB-Anwendungsfall legt fest, welche Bedeutung und welcher Code an dieser Stelle zulässig ist. Der Prüfi steuert deshalb Validierung und Routing im Empfängersystem.

In vielen Implementierungen wird der Prüfi aus dem Kopfbereich der Nachricht gelesen und gegen die Formatversion sowie die Kommunikationsrichtung geprüft. Die exakte Position und Schreibweise folgt dem aktuellen AHB; sie darf nicht aus einer alten Nachricht oder einem Screenshot abgeleitet werden. Prüfidentifikatoren sind keine frei erfundenen Prozessnamen und auch nicht die MP-ID eines Marktpartners.

Ein Prüfi kann fachlich nahe verwandte Fälle unterscheiden, beispielsweise Anfrage und Antwort, Beginn und Ende einer Zuordnung oder unterschiedliche Wertebedarfe. Die Nummer allein ist jedoch nicht selbsterklärend. Ihre Bedeutung muss aus der gültigen Anwendungsübersicht gelesen werden. Ändert sich eine Version, können Nummern entfallen, ergänzt oder anders beschrieben werden.

Mit der Anwendungsübersicht arbeiten

Die Anwendungsübersicht ist eine Zuordnungstabelle. In der Praxis werden mindestens Nachrichtentyp, Formatstand, Kurzbeschreibung, Prozess, Senderrolle, Empfängerrolle und Gültigkeit geprüft. Erst wenn alle Spalten zum Vorgang passen, ist die Auswahl belastbar.

Ein sicherer Leseworkflow sieht so aus:

1. Den fachlichen Vorgang in einem Prozessdokument identifizieren.
2. Sender- und Empfängerrolle sowie Strom/Gas festhalten.
3. Die für den Umsetzungstermin gültige Formatversion bestimmen.
4. In der Übersicht nach Prozess und Nachrichtentyp filtern.
5. Den Prüfi auswählen und seine Beschreibung gegen den Vorgang lesen.
6. Im AHB genau diesen Anwendungsfall öffnen und Pflichtfelder, Bedingungen und Codelisten übernehmen.
7. Die fertige Nachricht syntaktisch und fachlich testen; eine positive CONTRL allein genügt nicht.

Die bei der Bundesnetzagentur veröffentlichte Mitteilung Nr. 55 zeigt, dass Formatstände für konkrete Umsetzungstermine konsultiert und veröffentlicht werden. Deshalb ist „der aktuelle Prüfi“ ohne Stichtag keine ausreichende Aussage. Für produktive Systeme müssen Version und Gültigkeitsbeginn in der Konfiguration nachvollziehbar sein.

Beispiel: Lieferbeginn als fachliche Kette

Angenommen, ein Lieferant möchte einen neuen Stromkunden an einer Marktlokation anmelden. Die fachliche Aktion ist nicht „eine UTILMD senden“, sondern ein Lieferbeginn in einem bestimmten Prozess, zu einem bestimmten Bilanzierungs- und Vertragskontext. Der Lieferant ermittelt den passenden AHB-Anwendungsfall, setzt den dazugehörigen Prüfi und befüllt nur die dort verlangten Informationen.

Der Netzbetreiber liest die Nachricht nicht nur anhand des Prüfidentifikators. Er prüft zusätzlich Identifikatoren, Zeitpunkte, Rollen, Marktlokationsdaten und die zulässigen Codes. Bei einem fachlichen Fehler kann eine APERAK folgen. Eine CONTRL kann dagegen lediglich bestätigen, dass die EDIFACT-Syntax oder der technische Empfang verarbeitet wurde. Die Antworten sind jeweils eigene Nachrichten mit eigenen Regeln.

Umsetzung in SAP IS-U und Middleware

In SAP IS-U beginnt die Verarbeitung typischerweise mit einer eingehenden oder ausgehenden Prozessanforderung. Stammdaten, Geschäftspartner, Vertragskonto, Anlage, Markt- und Messlokation werden in den Kontext des Vorgangs gesetzt. Die Marktkommunikationsschicht ordnet diesem Kontext Prozess, Nachrichtentyp und Formatversion zu. Der Prüfi sollte aus dieser fachlichen Konfiguration entstehen, nicht aus einer hart codierten Zeichenkette im Mapping.

Ein robustes Mapping speichert mindestens Prüfi, AHB-Version, Prozess, Richtung und Stichtag. Vor dem Versand prüft es, ob die verwendeten Codes und Pflichtsegmente zum AHB-Anwendungsfall passen. Nach dem Empfang werden Prüfi und Version mit der Nachricht protokolliert; so lässt sich später erklären, warum ein Mapping gewählt wurde. Bei Formatwechseln wird eine neue Version parallel getestet und erst zum vorgesehenen Termin aktiviert.

Typische Fehler entstehen, wenn ein Middleware-Mapping nur den Nachrichtentyp betrachtet. Dann wird eine formal gültige UTILMD in den falschen Prozess geroutet. Ebenso gefährlich ist das Kopieren einer alten Nachricht: Der Prüfi kann noch existieren, aber eine Bedingung oder Codeliste kann sich geändert haben.

Version, Stichtag und Änderungsmodus

Ein Prüfi ist immer in einen Formatstand eingebettet. Die Bundesnetzagentur veröffentlicht Formatdokumente mit Umsetzungsterminen. In einer Übergangsphase können alte und neue Stände nebeneinander vorkommen. Die Systementscheidung muss deshalb nicht nur „welcher Prüfi?“, sondern auch „für welchen Stichtag und welche Richtung?“ beantworten.

Der Änderungsmodus einer Prozessfestlegung erklärt, welche Passagen geändert wurden. Er ersetzt aber nicht die vollständige Lesefassung. Besonders bei Korrekturen, Antwortnachrichten und Fristen ist der Gültigkeitsbeginn entscheidend. Eine gute Releaseverwaltung hält je Formatstand ein unveränderliches Paket aus MIG, AHB, Prüfidentifikatoren und Codelisten vor. Mapping und Tests referenzieren dieses Paket, damit Produktionsnachrichten später reproduzierbar bleiben.

Prüfidentifikator und technische Antworten

Prüfidentifikatoren begegnen auch bei Rückmeldungen, allerdings mit anderer Funktion als in einer Geschäftsnachricht. CONTRL bestätigt die technische Verarbeitung der Syntax; APERAK meldet Fehler oder Hinweise nach den dafür vorgesehenen Anwendungsregeln. Eine Antwort hat ihre eigene Kennung und ist nicht bloß die Wiederholung des ursprünglichen Prüfis.

Für die Korrelation braucht ein System daher mehrere Schlüssel: ursprüngliche Nachrichten-ID, eigene Nachrichten-ID, Absender, Empfänger, Zeitstempel, Nachrichtentyp, Version und – falls vorgesehen – den ursprünglichen Prüfi. Ein System, das nur nach einer Prüfi-Nummer sucht, kann Antworten paralleler Vorgänge verwechseln. Im Audit sollten Originalnachricht, ausgewähltes AHB, Version und Validierungsergebnis gemeinsam auffindbar sein.

Kontrollliste für die Fachprüfung

Vor einer Freigabe hilft ein Vier-Augen-Check:

Die Liste trennt Auswahlentscheidung, Mapping und Transport. Ein falscher Prüfi ist ein Auswahlfehler, ein fehlendes Segment ein AHB-/Mappingfehler und ein nicht zugestelltes Dokument ein Transport- oder Partnerproblem.

Was ein Prüfi nicht entscheidet

Der Prüfi entscheidet nicht, ob ein Vertrag zustande gekommen ist, ob eine Marktlokation tatsächlich beliefert werden darf oder ob eine Rechnung sachlich richtig ist. Er ist ein technischer und fachlicher Selektor für den Nachrichtenfall. Die zugrunde liegende Geschäftsentscheidung bleibt im Prozesssystem. Ein Lieferbeginn kann etwa wegen fehlender Voraussetzungen abgelehnt werden, obwohl Prüfi und EDIFACT-Syntax korrekt waren.

Ebenso bestimmt ein Prüfi keine Berechtigung zur Datenweitergabe. Marktrollen, Zuordnungen und der zugrunde liegende Prozess bestimmen, welcher Partner Daten erhalten darf. Die Nachricht muss daher neben dem Prüfi immer den korrekten Absender, Empfänger und die fachlichen Identifikatoren enthalten. Diese Trennung verhindert, dass eine Nummer als Freigabe oder Autorisierung missverstanden wird.

Für Schulung und Übergabe sollte ein Team jeden Prüfi mit einem sprechenden internen Namen dokumentieren, aber niemals diesen Namen als offizielle Bedeutung ausgeben. Neben dem internen Namen gehören Originalbezeichnung, Quelle, Version, Richtung, Prozess und Beispielgeschäftsvorfall in die Dokumentation. So bleibt sie auch bei mehreren Formatständen verständlich.

Bei der Übergabe an den Betrieb lohnt außerdem ein expliziter Hinweis auf die fachliche Reichweite. Ein Prüfi kann für Anfrage, Antwort, Storno oder Berichtigung gelten; ähnliche Kurztexte sind kein Ersatz für die vollständige Beschreibung. Die Fachstelle sollte deshalb einen Beispielablauf mit Eingang, Verarbeitung und Antwort dokumentieren. Daran lassen sich Routing, Korrelation und Fehlerbehandlung gemeinsam prüfen.

Das Ergebnis sollte außerdem die verantwortliche Marktrolle und den fachlichen Auslöser eindeutig benennen. So bleibt auch bei ähnlichen Anwendungsfällen klar, welcher Prüfi tatsächlich gemeint ist. Das gilt für den jeweiligen Prozessfall.

Typische Missverständnisse

„Der Prüfi ist der Prozess.“

Nein. Der Prozess definiert die Geschäftsregel und Fristen; der Prüfi identifiziert eine konkrete Nachrichtenanwendung innerhalb dieser Regelwelt.

„Eine positive CONTRL bedeutet fachliche Zustimmung.“

Nein. CONTRL betrifft die technische/syntaktische Bestätigung. Fachliche Annahme oder Ablehnung wird nach den jeweiligen Prozessregeln verarbeitet, häufig über APERAK oder eine fachliche Antwort.

„MIG und AHB sind dasselbe.“

Nein. Der MIG beschreibt die mögliche Nachrichtensyntax; das AHB konkretisiert die Anwendung mit Bedingungen, Rollen und Pflichtangaben.

„Eine Prüfi-Nummer bleibt dauerhaft gleich.“

Nein. Formatstände und Umsetzungstermine können Änderungen bringen. Nummer, Beschreibung und Gültigkeit müssen aus der aktuellen Veröffentlichung stammen.

„Der Prüfi ersetzt die Validierung.“

Nein. Er wählt den Prüfkontext. Werte, IDs, Zeiträume, Codes, Reihenfolge und fachliche Plausibilität müssen weiterhin geprüft werden.

Quellen und Pflegehinweis

Maßgeblich sind die zum Umsetzungstermin gültige Anwendungsübersicht der Prüfidentifikatoren, das zugehörige AHB und die Prozessfestlegung der Bundesnetzagentur. EDI@Energy- beziehungsweise BDEW-MaKo-Dokumente liefern die technische Ausprägung; der MIG darf nicht als Ersatz für das AHB verwendet werden. Dieser Artikel wurde am 08.09.2026 geprüft. Vor produktiven Änderungen sind die neuesten Veröffentlichungen und Mitteilungen der Bundesnetzagentur zu kontrollieren, insbesondere angekündigte Formatwechsel.