Einen MIG lesen und in der Marktkommunikation anwenden

Kurzantwort

Ein MIG (Message Implementation Guide) ist die Nachrichtenbeschreibung für eine EDIFACT-Nachrichtenfamilie. Er zeigt, welche Segmente und Datenelemente in welcher Reihenfolge vorkommen können, wie oft Gruppen wiederholt werden und welche technischen Datentypen gelten. Ein MIG erklärt damit die mögliche Struktur – nicht automatisch den vollständigen fachlichen Ablauf.

Für eine produktive Marktkommunikationsnachricht braucht man mindestens vier Dinge: die Prozessfestlegung, den gültigen Nachrichtentyp samt Version, das passende AHB mit Anwendungsfall und Prüfidentifikator sowie die relevanten Codelisten. Der MIG ist der Strukturplan, das AHB die fachliche Bauanleitung. Der Transportweg, etwa AS4, ist davon getrennt.

MIG, AHB, EDIFACT und Prozess

EDIFACT ist die Syntaxebene. Eine Nachricht besteht aus Segmenten, die durch definierte Trennzeichen verbunden sind; Datenelemente und Komponenten tragen die Werte. EDI@Energy verwendet diese Syntax in einer energiewirtschaftlich präzisierten Ausprägung. Der MIG beschreibt die Struktur eines Nachrichtentyps wie UTILMD, MSCONS, INVOIC oder ORDERS.

Der MIG beantwortet Fragen wie: In welcher Reihenfolge kommt BGM? Welche Segmentgruppe folgt auf NAD? Wie oft kann eine Gruppe wiederholt werden? Welche Länge und welcher Datentyp ist technisch erlaubt? Er beantwortet nicht vollständig: Darf dieser Lieferant dieses Datum senden? Welche Rolle steht in diesem Prozess an dieser Stelle? Welche Kombination von Codes ist fachlich zulässig?

Diese Fragen beantwortet das AHB. Es verknüpft den Prozess mit einer konkreten Nachrichtenanwendung und enthält Muss-/Kann-Regeln, Bedingungen, Hinweise und Codelistenreferenzen. Der Prüfidentifikator identifiziert diesen Anwendungsfall.

Einen MIG systematisch lesen

Zuerst sollte die Kopfseite geprüft werden: Nachrichtentyp, Version, Herausgeber und Gültigkeit. Eine alte MIG-Version kann syntaktisch ähnlich aussehen und trotzdem nicht zum Umsetzungstermin passen. Die Mitteilungen der Bundesnetzagentur veröffentlichen Versionen mit verbindlichem Starttermin; diese Information gehört in die Projekt- und Systemkonfiguration.

Danach wird die Hierarchie gelesen. Ein Segment ist nicht automatisch eine einzelne Zeile im fachlichen Sinn. Segmentgruppen werden als zusammengehörige Blöcke wiederholt. Die Einrückung und Gruppennummern zeigen, welche Segmente zusammengehören. Ein RFF innerhalb einer Gruppe hat seine Bedeutung aus dieser Position und nicht nur aus dem Namen RFF.

Im nächsten Schritt werden die Markierungen für Pflicht, optional und wiederholbar erfasst. Technisch optional bedeutet nicht, dass das Feld im konkreten Prozess weggelassen werden darf; dafür ist das AHB maßgeblich. Ebenso bedeutet „Muss“ im AHB nicht, dass ein Segment global in jedem Anwendungsfall verpflichtend ist.

Anschließend werden Datenelemente und Komponenten gelesen. Ein zusammengesetztes Element kann Qualifier und Wert enthalten. Der Qualifier sagt, was der folgende Wert bedeutet. Ein Datum ohne Qualifier, eine ID ohne Rollenbezug oder ein Betrag ohne Einheit ist daher nicht sicher interpretierbar.

Segment, Qualifier und Code

Ein Segment wie NAD benennt eine Partei, aber erst ein Qualifier unterscheidet die fachliche Rolle. Ein RFF-Segment transportiert eine Referenz, deren Art über einen Qualifier bestimmt wird. CUX, DTM, QTY und andere Segmente folgen demselben Prinzip: Der Code im Kontext macht aus einer technischen Position eine fachliche Aussage.

Beim Lesen sollten drei Ebenen notiert werden: die Segmentposition, der Qualifier und die erlaubte Codeliste. Freitext ist fast nie ein Ersatz für einen erforderlichen Code. Wenn ein AHB auf eine Codeliste verweist, muss der dort definierte Wert übernommen werden; interne Abkürzungen aus SAP oder einem ERP dürfen nicht direkt in EDIFACT landen.

Eine gute Mapping-Tabelle enthält deshalb mindestens:

Vom Anwendungsfall zur Nachricht

Der korrekte Ablauf beginnt nicht im MIG. Ein Team beschreibt zuerst den Geschäftsvorfall und die beteiligten Marktrollen. Danach wird die Prozessregel gewählt, etwa GPKE für Stromlieferantenwechsel oder WiM für Messwerte. Aus dieser Regel ergibt sich der Nachrichtentyp und die gültige Version. Erst jetzt wird im AHB der Anwendungsfall samt Prüfidentifikator ausgewählt.

Das AHB liefert nun die konkrete Sicht auf den MIG: Welche Segmente sind Muss, welche Bedingungen gelten, welche Codes sind zugelassen und aus welcher vorherigen Nachricht werden Werte übernommen? Das Mapping überträgt anschließend Quellsystemdaten in genau diese Struktur. Zum Schluss erzeugt der EDIFACT-Serializer die Nachricht und die AS4-Komponente übernimmt Signatur, Verschlüsselung und Versand.

Ein Beispiel aus SAP IS-U

Ein Lieferant verarbeitet einen Lieferbeginn. Im SAP-IS-U-Quellsystem liegen Geschäftspartner, Vertragskonto, Marktlokation, Lieferbeginn und Bilanzkreiszuordnung in unterschiedlichen Objekten. Das Mapping darf diese Werte nicht einfach in der Reihenfolge der Datenbankfelder ausgeben. Es muss die Prozesssicht des AHB herstellen.

Die MP-ID des Absenders kommt aus dem Rollenstamm, die Marktlokations-ID aus dem energiewirtschaftlichen Stammdatensatz, der Zeitpunkt aus dem Prozessereignis. Eine interne Anlagen- oder Vertragskontonummer ist nicht automatisch eine zulässige Markt-ID. Die Middleware validiert Format, Länge, Gültigkeit und Rollenbezug, bevor sie die Nachricht serialisiert.

Bei einer eingehenden Nachricht werden zunächst Syntax und Version geprüft. Danach liest die Anwendung Prüfidentifikator und AHB-Kontext, löst Marktpartner und Lokationen auf und führt fachliche Prüfungen durch. Ein Fehler im EDIFACT-Aufbau kann zu CONTRL führen; ein fachlicher Fehler wird nach den einschlägigen Prozessregeln behandelt, beispielsweise mit APERAK oder einer fachlichen Antwort. Das Log sollte Originalnachricht, Version, Prüfi, Korrelation und Validierungsergebnis revisionssicher zusammenhalten.

Tests und Fehleranalyse

Ein Testfall sollte jeweils einen fachlichen Anwendungsfall und nicht nur ein Segment abdecken. Für jeden Fall werden gültige Minimalnachricht, gültige Vollnachricht, fehlender Pflichtwert, unzulässige Codekombination, falsche Rolle, falsches Datum und falsche Version getestet. Zusätzlich gehört ein Negativtest für eine syntaktisch korrekte, aber fachlich unzulässige Nachricht dazu.

Bei einem Fehler wird von außen nach innen analysiert: Ist die Nachricht technisch angekommen? Ist die EDIFACT-Syntax gültig? Passt die Version? Wurde der richtige Prüfi gesetzt? Stimmen Rollen und IDs? Sind AHB-Bedingungen und Codelisten erfüllt? Erst danach wird das Quellsystem untersucht. CONTRL und APERAK dürfen dabei nicht als austauschbare Fehlermeldungen behandelt werden.

Formatwechsel werden mit einem Stichtags-Test abgesichert. Nachrichten vor und nach dem Umsetzungstermin müssen reproduzierbar dem richtigen Mapping zugeordnet werden. Alte Nachrichten dürfen für Korrekturen weiterhin nach den jeweils geltenden Regeln verarbeitet werden; das ist eine Prozessfrage, keine pauschale MIG-Regel.

Dokumentation für Betrieb und Audit

Ein MIG-Mapping ist erst wartbar, wenn die fachliche Begründung neben dem technischen Pfad dokumentiert ist. Für jede befüllte Position gehören Quelle, Transformation, Qualifier, Codeliste, AHB-Referenz und Beispielwert in die Mappingdokumentation. Für bewusst leere optionale Positionen wird festgehalten, warum sie im Anwendungsfall nicht gelten. So kann ein Fachteam eine Nachricht lesen, ohne den gesamten Quellcode der Middleware zu kennen.

Im Betrieb hilft ein strukturiertes Fehlerprotokoll mehr als „MIG invalid“. Sinnvoll sind Fehlerstufe (Syntax, Struktur, AHB, Codeliste, Prozess oder Partnerstamm), Segmentposition, Datenelement, Originalwert, erwarteter Wertebereich, Nachrichtenversion und Korrelations-ID. Ein Replay muss kontrolliert und idempotent sein, damit keine doppelte Prozessaktion entsteht.

Bei einer neuen EDI@Energy-Version wird zuerst eine Dokumentendifferenz erstellt. Danach werden betroffene Anwendungsfälle, Qualifier und Codelisten ermittelt, Testnachrichten mit Marktpartnern abgestimmt und Monitoringregeln angepasst. Erst nach Stichtagstests wird die neue Version aktiviert. Interne Kopien sollten Quelle und Abrufdatum tragen.

Minimal- und Vollbeispiele richtig verwenden

Ein Minimalbeispiel zeigt die kleinste nach AHB gültige Anwendung; es ist keine allgemeine Vorlage für jeden Fall. Ein Vollbeispiel zeigt optionale Angaben, kann aber den Kern verdecken. Gute Schulungsunterlagen stellen beide nebeneinander und markieren je Segment: technisch möglich, im AHB verpflichtend, bedingt verpflichtend oder im konkreten Fall nicht zulässig.

Beispieldaten müssen konsistent sein. Marktlokations-ID, Rollen, Zeitraum und Lieferrichtung müssen zusammenpassen; Referenzen müssen in Antworten wiedergefunden werden können. Zufällig zusammenkopierte Werte sind zwar parserseitig gültig, aber fachlich irreführend. Automatisierte Tests formulieren syntaktische und fachliche Erwartungen getrennt.

Warum die Lesart des AHB Vorrang hat

Ein häufiger Implementierungsfehler besteht darin, zuerst ein XML-Schema oder einen generischen EDIFACT-Parser zu bauen und die Fachlogik später „dazuzuschalten“. Das führt zu Nachrichten, die technisch gut geformt sind, aber den falschen Anwendungsfall ausdrücken. Der MIG ist bewusst generisch genug, mehrere Anwendungen zu tragen. Erst die AHB-Spalten zur konkreten Geschäftssituation machen aus einer möglichen Struktur eine zulässige Nachricht.

Beim Review sollte deshalb jede technische Entscheidung auf eine fachliche Quelle zurückverweisen. Ein Segment wird nicht deshalb übertragen, weil es im Parser verfügbar ist, sondern weil der gewählte AHB-Fall es fordert oder zulässt. Eine zusätzliche Information ist nicht automatisch hilfreich; sie kann gegen eine bedingte Regel verstoßen oder den Empfänger zu einer falschen Interpretation führen. „Mehr Daten“ ist in der Marktkommunikation nicht gleichbedeutend mit „bessere Nachricht“.

Auch der Empfänger verarbeitet nicht zwingend nach derselben internen Datenstruktur wie der Sender. Maßgeblich ist die standardisierte Bedeutung aus AHB, Qualifiern und Codelisten. Interne Feldnamen wie supplierStartDate oder anlage_id sind nur Mappingquellen. In der Nachricht müssen sie in standardisierte Marktrolle, ID und Zeitangabe übersetzt werden. Diese Übersetzung sollte fachlich getestet und im Release dokumentiert sein.

Typische Missverständnisse

„Der MIG sagt, was ich senden muss.“

Er zeigt die mögliche Struktur. Was im konkreten Geschäftsvorfall verpflichtend oder verboten ist, steht im AHB und in der Prozessfestlegung.

„Wenn ein Segment im MIG optional ist, kann ich es immer weglassen.“

Nein. Ein AHB-Anwendungsfall kann es verpflichtend machen oder eine Bedingung daran knüpfen.

„Ein Segmentname bestimmt die Bedeutung.“

Nein. Position, Qualifier, Komponentencode und AHB-Kontext bestimmen die Bedeutung gemeinsam.

„EDIFACT und AS4 sind dasselbe.“

Nein. EDIFACT ist die Nutzdatenstruktur; AS4 ist ein Übertragungs- und Absicherungsweg.

„Ein Parser ersetzt fachliche Tests.“

Nein. Ein Parser erkennt Syntaxfehler. Rollen, Fristen, Marktpartnerbeziehungen und Prozesslogik brauchen zusätzliche AHB- und Prozessprüfungen.

Quellen und Pflegehinweis

Für die tägliche Arbeit sind die aktuelle EDI@Energy-/BDEW-MaKo-Veröffentlichung, der passende MIG, das passende AHB, die Codelisten und die einschlägige BNetzA-Prozessfestlegung gemeinsam zu verwenden. Die Bundesnetzagentur veröffentlicht Versionen und Umsetzungstermine in Mitteilungen; diese sind gegenüber alten Kopien zu bevorzugen. Dieser Artikel wurde am 08.09.2026 geprüft. Vor jedem Mapping- oder Releasewechsel sind Version, Gültigkeitsbeginn und betroffene Anwendungsfälle erneut zu kontrollieren.