EDIFACT, AHB und MIG

Kurzantwort

Die Marktkommunikation in Deutschland tauscht ihre Nachrichten überwiegend als UN/EDIFACT-Dateien aus. Eine Übertragungsdatei umhüllt eine oder mehrere Nachrichten, die aus Segmenten und Datenelementen bestehen. Damit alle Marktpartner dieselbe Datei gleich verstehen, gibt es zwei Beschreibungsebenen: Die Nachrichtentypbeschreibung (MIG) legt den Aufbau einer Nachricht fest, das Anwendungshandbuch (AHB) beschreibt, wie die Nachricht in einem Prozess zu verwenden ist.

Die drei Begriffe gehören zusammen, beantworten aber unterschiedliche Fragen. EDIFACT beschreibt die Syntax, die MIG die Struktur, das AHB die Anwendung. Wer nur die Syntax kennt, kann eine Datei lesen, aber nicht wissen, ob sie fachlich richtig ist.

Für die Arbeit an Systemen ist diese Dreiteilung praktisch: Sie erlaubt es, Formatfehler von Prozessfehlern zu trennen. Ein Syntaxfehler zeigt sich in der Übertragungsprüfung, ein Strukturfehler im Mapping, ein Anwendungsfehler erst bei der fachlichen Prüfung. Jede Fehlerklasse braucht eine eigene Behandlung und eine eigene Rückmeldung an den Sender.

Wozu standardisierte Formate dienen

Energieversorger, Netzbetreiber und Messstellenbetreiber tauschen täglich tausende Nachrichten aus. Damit diese Nachrichten maschinell verarbeitet werden können, müssen alle Beteiligten dieselbe Struktur verwenden. Ein Lieferant, der einen Lieferbeginn meldet, und ein Netzbetreiber, der die Meldung prüft, müssen die Felder gleich interpretieren.

Die Standardisierung schafft diese gemeinsame Basis. Sie legt fest, welche Segmente eine Nachricht enthält, welche Codes zulässig sind und welche Felder Pflicht sind. Ohne diese Vorgaben würde jede Schnittstelle ihre eigene Interpretation entwickeln, und der Abstimmungsaufwand zwischen den Marktpartnern wäre immens.

Die Marktkommunikation setzt dabei auf einen etablierten Standard statt auf Eigenentwicklungen. UN/EDIFACT ist ein international verbreitetes Regelwerk für den elektronischen Datenaustausch. Die deutsche Energiewirtschaft nutzt davon eine eigene Ausprägung, die über EDI@Energy gepflegt wird. Diese Ausprägung bleibt kompatibel mit dem Standard, schränkt ihn aber auf die Bedürfnisse der Branche ein.

Für die Marktkommunikation sind die Formate verbindlich vorgegeben. Die Bundesnetzagentur verweist in ihren Mitteilungen auf die EDI@Energy-Dokumente, in denen die Formate beschrieben sind. Wer abweichende Formate verwendet, kann nicht am standardisierten Markt teilnehmen. EDI@Energy

Aufbau einer EDIFACT-Übertragung

Eine EDIFACT-Übertragung folgt einer festen Hierarchie. Die Übertragungsdatei beginnt mit dem Segment UNB und endet mit UNZ. Dazwischen liegen die Nachrichten, die jeweils mit UNH beginnen und mit UNT enden. Optional lassen sich Nachrichten in Gruppen fassen, die mit UNG und UNE umschlossen werden.

Die UNB-Segmente tragen die Steuerungsdaten der Übertragung: Absender, Empfänger, Zeitpunkt und Referenz. Im UNB steht auch die Marktpartner-Identifikationsnummer, also die BDEW-Codenummer für Strom. Eine Nachricht selbst beginnt mit UNH, das die Nachrichtenreferenz und den Nachrichtentyp nennt, etwa UTILMD oder MSCONS.

Innerhalb der Nachricht folgen die fachlichen Segmente. Ein Segment besteht aus Datenelementen, die durch Trennzeichen getrennt sind. Codes und Qualifier geben den Datenelementen ihre Bedeutung. Ein Beispiel: Das Segment NAD mit dem Qualifier MS nennt den Nachrichtenaussteller, das Datenelement dahinter die Marktpartner-ID. Allgemeine Festlegungen

Was die MIG beschreibt

Die Nachrichtentypbeschreibung, kurz MIG, beschreibt den Aufbau einer Nachricht. Sie legt fest, welche Segmentgruppen und Segmente eine Nachricht enthalten kann, in welcher Reihenfolge sie auftreten und welche Datenelemente Pflicht oder optional sind. Die MIG ist damit die technische Bauanleitung einer Nachricht.

Zur MIG gehören auch die zulässigen Codes und Qualifier. Für jedes Datenelement listet sie auf, welche Werte erlaubt sind. Diese Vorgaben sorgen dafür, dass alle Sender dieselben Codes verwenden und alle Empfänger sie gleich interpretieren. Eine MIG ohne Codes ließe zu viel Interpretationsspielraum.

Für die Umsetzung in Systemen ist die MIG die Grundlage des Mappings. Wer eine Nachricht verarbeiten will, muss wissen, welche Segmente er erwarten darf und wie er die Datenelemente in seine Stammdaten überführt. Die MIG beantwortet diese Fragen auf der Ebene der Nachrichtenstruktur.

Die MIG ist dabei prozessneutral. Sie beschreibt die Nachricht, nicht ihren Zweck. Derselbe Nachrichtentyp kann in mehreren Prozessen verwendet werden, und die MIG bildet alle zulässigen Ausprägungen ab. Welche Ausprägung in einem konkreten Fall gilt, entscheidet die fachliche Anwendung. Genau diese Lücke schließt das Anwendungshandbuch.

Was das AHB beschreibt

Das Anwendungshandbuch, kurz AHB, geht einen Schritt weiter. Es beschreibt, wann und wie eine Nachricht in einem Geschäftsprozess zu verwenden ist. Während die MIG sagt, was eine Nachricht enthalten kann, sagt das AHB, was sie in einem bestimmten Prozess enthalten muss.

Im AHB stehen die fachlichen Regeln: welche Werte ein Feld in einem konkreten Use-Case annimmt, welche Kombinationen zulässig sind und welche Prüfungen der Empfänger durchführt. Ein Beispiel: Eine UTILMD kann viele Geschäftsvorfälle transportieren. Ob sie einen Lieferbeginn, ein Lieferende oder eine Stammdatenänderung meldet, entscheidet der Prüfidentifikator. Das AHB erklärt, welcher Prüfidentifikator zu welchem Vorgang gehört.

Damit ist das AHB die Brücke zwischen Format und Prozess. Es verknüpft die Nachrichtenstruktur aus der MIG mit den fachlichen Regeln aus GPKE, WiM und MaBiS. Wer ein System baut, benötigt beide Dokumente: die MIG für die Struktur, das AHB für die fachliche Anwendung. Allgemeine Festlegungen

In der Praxis arbeiten Berater häufig mit Auszügen aus dem AHB, in denen einzelne Segmente mit ihren zulässigen Werten dargestellt sind. Diese Auszüge zeigen, wie ein Datenelement im konkreten Use-Case zu füllen ist. Sie ersetzen aber nicht die Gesamtsicht: Welche Segmente für einen Vorgang Pflicht sind, welche Bedingungen gelten und welche Antworten der Empfänger erwartet, ergibt sich erst aus dem vollständigen AHB-Kapitel zum jeweiligen Prozess.

Wer Testfälle entwirft, sollte sich ebenfalls am AHB orientieren. Für jeden Use-Case lassen sich aus dem AHB gültige und ungültige Ausprägungen ableiten: eine Nachricht mit fehlendem Pflichtfeld, eine mit falschem Code, eine mit nicht zulässiger Kombination. Solche Testfälle prüfen nicht nur das Mapping, sondern auch die fachliche Prüfungslogik des Empfängers.

Format, Prozess und Versionen

Ein häufiger Projektfehler besteht darin, Formate und Prozesse zu vermischen. Der Prozess bestimmt, welcher Geschäftsvorfall abläuft und welche Fristen gelten. Das Format bestimmt, wie der Vorfall in einer Nachricht abgebildet wird. Eine syntaktisch korrekte Nachricht kann fachlich falsch sein, weil sie den falschen Prüfidentifikator trägt oder den falschen Zeitpunkt nennt.

Dazu kommt die Versionslogik. Formate und Nachrichtentypen werden regelmäßig überarbeitet. Die Bundesnetzagentur veröffentlicht die neuen Versionen mit Mitteilungen, und die Marktpartner setzen sie zu festen Umsetzungsterminen um. Datenformate-Mitteilungen Ein System muss deshalb wissen, welche Version eines Formats es zu welchem Zeitpunkt verwendet.

Die Umsetzungstermine folgen einem Rhythmus. Üblich sind Termine zum 1. April und zum 1. Oktober eines Jahres. Davor konsultiert die Bundesnetzagentur die überarbeiteten Nachrichtentypversionen, danach erklärt sie ihr Inkrafttreten. Diese Mitteilungen tragen fortlaufende Nummern und sind auf der Seite zu den Datenformaten dokumentiert. Gemeinsame Mitteilungen

Für den Betrieb ergibt sich daraus ein fester Turnus. Wer die Nachrichtenverarbeitung pflegt, plant gegen die Umsetzungstermine. Zwischen Konsultation und Inkrafttreten bleibt Zeit für Analyse, Customizing und Tests. Wer diese Zeit nicht nutzt, gerät am Umsetzungstermin unter Druck.

Für SAP-IS-U-Berater heißt das: Mapping, Prüfungen und Versionierung gehören zusammen. Ein Mapping, das nur die aktuelle Version kennt, versagt bei Altbeständen. Eine Prüfung, die nur die Syntax prüft, übersieht fachliche Fehler. Erst die Kombination aus Struktur, fachlicher Prüfung und Versionsführung macht die Nachrichtenverarbeitung stabil.

Praxisbeispiel: Eine UTILMD fachlich einordnen

Ein Netzbetreiber erhält eine UTILMD. Die Syntaxprüfung läuft fehlerfrei durch, die Datei ist also technisch lesbar. Jetzt beginnt die fachliche Einordnung: Das AHB erklärt, welcher Prüfidentifikator in der Nachricht erwartet wird und welche Segmente für den jeweiligen Vorgang relevant sind.

Das System liest den Prüfidentifikator und erkennt einen Lieferbeginn. Es prüft die Marktlokation, den Zeitpunkt und die Rolle des Senders. Passt alles, verarbeitet es den Vorgang und erzeugt die Antwort. Fehlt der Prüfidentifikator oder passt er nicht zum Prozess, lehnt das System die Nachricht ab.

Im Beispiel zeigt sich die Arbeitsteilung: Die MIG beschreibt, wie die Nachricht aufgebaut ist, das AHB, wie sie zu interpretieren ist, und der Prozess, welche Antwort zu erzeugen ist. Wer nur eine der Ebenen kennt, scheitert bei der fachlichen Verarbeitung.

Bedeutung für SAP IS-U

In SAP-IS-U-Systemen laufen eingehende und ausgehende EDIFACT-Nachrichten über die Datenaustausch-Komponenten. Das Mapping übersetzt die Nachrichtenfelder in die internen Strukturen. Die Qualität dieses Mappings entscheidet darüber, ob aus einer Nachricht der richtige Geschäftsvorfall wird.

Das Mapping sollte sich an MIG und AHB orientieren. Die MIG liefert die Feldstruktur, das AHB die fachlichen Regeln. Wer das Mapping nur aus Beispielnachrichten ableitet, übersieht Randfälle. Wer die AHB-Prüfungen nicht abbildet, verarbeitet Nachrichten, die der Marktpartner ablehnen würde.

Dazu kommt die Pflege. Ändern sich Nachrichtentypen oder AHB, muss das Mapping mitziehen. Ein Versionsmanagement für die Nachrichtenverarbeitung ist deshalb keine Option, sondern Voraussetzung für den stabilen Betrieb. Wer die Zusammenhänge von EDIFACT, MIG und AHB kennt, kann diese Pflege planen und testen.

Typische Missverständnisse

„EDIFACT ist die Marktkommunikation.“
Nein. EDIFACT ist ein Nachrichtenformat. Marktkommunikation umfasst Prozesse, Rollen, Fristen und Formate.

„MIG und AHB sind austauschbar.“
Nein. Die MIG beschreibt die Struktur einer Nachricht, das AHB ihre Anwendung im Prozess.

„Eine syntaktisch korrekte Nachricht ist fachlich richtig.“
Nein. Die Syntaxprüfung sagt nichts über die fachliche Verarbeitbarkeit. Dafür sind Prozess und AHB maßgeblich.

„Ein Nachrichtentyp entspricht einem Prozess.“
Nein. Eine UTILMD kann viele Geschäftsvorfälle transportieren. Welcher gemeint ist, bestimmt der Prüfidentifikator.

„Formate ändern sich nur selten.“
Nein. Die Bundesnetzagentur veröffentlicht regelmäßig überarbeitete Nachrichtentypversionen mit festen Umsetzungsterminen.

Quellen und Pflegehinweis

Die Formate und ihre Beschreibungen veröffentlicht EDI@Energy, die Bundesnetzagentur begleitet sie mit Mitteilungen zu den Datenformaten. MIG und AHB gelten in der jeweils veröffentlichten Version. Vor jeder Umsetzung den aktuellen Stand der Formate und die gültige Fassung der Prozessfestlegungen prüfen.

• Bundesnetzagentur: Allgemeine Festlegungen zu den EDIFACT- und XML-Nachrichten
• Bundesnetzagentur: Gemeinsame Mitteilungen zu Datenformaten
• EDI@Energy: Datenformate für die Marktkommunikation
• BDEW: Marktkommunikation, Standards im Energiemarkt
• Bundesnetzagentur: Marktkommunikation 2020

Abrufdatum aller Quellen: 7. September 2026.