Einen MIG lesen und in der Marktkommunikation anwenden

Kurzantwort

Die MIG (Message Implementation Guide) ist die Nachrichtenbeschreibung eines Nachrichtentyps. Sie führt jedes Segment mit Reihenfolge, Wiederholung, Datenelementen, Format und erlaubten Codes auf, jeweils zweimal: wie UN/EDIFACT es im Standard vorsieht und wie die BDEW-Anwendung es für die Energiewirtschaft festlegt. Sie sagt, was an einer Stelle stehen darf. Ob es in einem Anwendungsfall stehen muss, entscheidet das AHB. Das Beispiel hier ist die UTILMD MIG Strom S2.2 vom 01.04.2026, verbindlich ab 01.10.2026.

Aufbau des Dokuments

Die UTILMD MIG Strom hat 559 Seiten. Titelseite und Kopfzeile nennen Version (S2.2), Publikationsdatum (01.04.2026) und Autor (BDEW). Der Disclaimer stellt klar: Allein die PDF-Datei ist gültig, die Word-Fassung ist informatorisch, XML-Dateien gibt es als optionale Unterstützung gegen Entgelt (S. 2).

Danach kommen drei Teile:

1. Nachrichtenstruktur (S. 3 bis 23): alle Segmente und Segmentgruppen in Reihenfolge, je Zeile Zähler, laufende Nummer, Bezeichner, Status und Wiederholung für Standard und BDEW, Ebene und Inhalt. Dieselbe Segmentgruppe erscheint mehrfach, einmal je Verwendung, etwa SG5 für Netzlokation, Marktlokation oder Messlokation.
2. Diagramm (S. 24 bis 25): der Verzweigungsbaum. Der Baum der Gruppen steht in Segmentgruppen im EDIFACT lesen.
3. Segmentlayout (ab S. 26): je Segment eine Beschreibung mit Datenelementen. Am Ende steht die Änderungshistorie (ab S. 546).

Die Legende am Fuß jeder Seite erklärt die Abkürzungen. Sie lohnt sich, weil die MIG zwei Statussysteme mischt.

Ein Segment lesen

So liest man das Bild:

• Kopfzeile: Zähler 0110 ist die Nummer im Standard, 00008 die laufende Nummer im Guide, NAD der Bezeichner. Dann Status und höchste Wiederholung für Standard und BDEW, zuletzt die Ebene im Baum und der Name, hier „MP-ID Absender“.
• Datenelemente: Je Zeile eine Datenelementnummer (vier Ziffern), ein Name, Status und Format für beide Spalten, dazu eine Bemerkung mit Codes.
• Datenelementgruppen: Ein Name wie C082 steht für eine Gruppe, die darunter eingerückten Zeilen sind ihre Komponenten. Im Beispiel trennt : die Komponenten 3039, 1131 und 3055.
• Beispiel: NAD+MS+9900259000002::293' ist die Zeile, die später in der Nachricht steht.

Status und Format

Der Status steht in zwei Alphabeten (Legende, jede Seite):

• Standard (UN/EDIFACT): M Muss, C bedingt.
• BDEW-Anwendung: R erforderlich, O optional, D abhängig von, N nicht benutzt.

D ist der Verweis ins AHB. Die MIG sagt damit: Ob das Segment vorkommt, hängt vom Anwendungsfall ab. In der Nachrichtenstruktur ist zum Beispiel die Gruppe SG1 (Referenz auf eine vorangegangene Anfrage) im Standard C, in der BDEW-Anwendung D. Das AHB legt dann je Prüfidentifikator Muss, Soll oder Kann fest (Muss, Kann und Bedingung).

Das Format besteht aus Typ und Länge: an..35 heißt alphanumerisch bis 35 Zeichen, n11 genau elf Ziffern, a1 ein Buchstabe, n..6 numerisch bis sechs Stellen. Die Standardspalte darf weiter sein als die BDEW-Spalte: Die Marktlokations-ID im Segment LOC steht im Standard als an..35, in der BDEW-Anwendung als n11 (S. 76).

Bemerkungen und Hinweise nicht überspringen

Viele Regeln stehen in den Bemerkungen unter den Zeilen. Drei Beispiele aus dem MIG:

• BGM (S. 28): Innerhalb einer Nachricht darf nur eine Kategorie vorkommen, etwa nur Anmeldungen oder nur Änderungen. Der Grund einer Meldung steht pro Vorgang im Transaktionsgrund.
• IDE (S. 34 und 42): Vorgangs- und Listennummern müssen übergreifend eindeutig sein. Eine Nummer, die in einem IDE+Z01 (Liste) vorkam, darf in keinem IDE+24 (Vorgang) wieder auftauchen.
• UNH (S. 26): Wird eine Liste auf mehrere Nachrichten verteilt, ist unter Beachtung technischer Restriktionen die maximal mögliche Segmentanzahl zu verwenden.

Von der MIG zur Nachricht

Eine Nachricht baut man in dieser Reihenfolge:

1. Format und Version bestimmen. Die Versionen stehen in der Nachricht selbst: UNH mit Typ, Version, Freigabe und Anwendungscode (UTILMD:D:11A:UN:S2.2), siehe UNH, UNT und die Nachrichtenstruktur.
2. Anwendungsfall wählen. Das AHB nennt zu jedem Prüfidentifikator, welche Segmente Pflicht sind. Der Prüfidentifikator steht im Segment RFF mit Qualifier Z13.
3. Segmente in MIG-Reihenfolge und -Gruppen bauen, mit Codes aus den Bemerkungen der MIG und den Codelisten (Codelisten und EBD).
4. Zähler und Referenzen setzen (UNT, UNZ).

Zur Gegenprobe taugen die Beispiele des MIG, die AHB-Werkbank mit ihrer Nachrichtenanalyse und der Vergleich mit dem AHB. Ein Prozess, der auf solche Nachrichten angewiesen ist, steht im Ablaufatlas.

Fehlerfälle

• Veraltete Fassung: Formate werden zu den Terminen 01.04. und 01.10. umgestellt; maßgeblich ist, was in UNH als Anwendungscode steht und was die Bundesnetzagentur als verbindlich nennt (S2.2 ab 01.10.2026).
• Standard-Spalte gelesen statt BDEW: Der Standard erlaubt mehr, als die Energiewirtschaft zulässt. Die Wiederholung einer Gruppe im Standard ist kein Freibrief.
• D übersehen: Ein abhängiges Segment ist an Bedingungen des AHB gebunden und nicht frei optional.
• Beispiele wörtlich übernommen: Die Beispielzeilen zeigen Syntax, keine vollständigen oder fachlich gültigen Nachrichten.

Typische Missverständnisse

„Die MIG sagt, was ich senden muss.“ Sie sagt, was ich senden darf. Was ich senden muss, steht im AHB.

„Ein Segment mit Status M muss immer vorkommen.“ M gilt innerhalb der Gruppe: Ist die Gruppe selbst bedingt (C), kann sie fehlen und das M-Segment darin mit ihr.

„Der Standard und die BDEW-Spalte sind dasselbe.“ Die BDEW-Spalte ist die verbindliche Einschränkung.

Das Glossar erklärt MIG, AHB und Qualifier. Überblick: EDIFACT, AHB und MIG.