Segmentgruppen im EDIFACT lesen

Kurzantwort

Eine Segmentgruppe ist ein Block aus mehreren Segmenten, den genau ein Segment einleitet: das Trigger-Segment. Jede neue Ausprägung dieses Segments beginnt eine neue Gruppe, die alten Segmente der vorherigen Ausprägung sind abgeschlossen. Die Wiederholung entsteht durch die Wiederkehr des einleitenden Segments. Trennzeichen markieren Segmente und Datenelemente, keine Gruppen.

Im MIG erkennst du eine Gruppe am Bezeichner SG mit Nummer, etwa SG2, SG5 oder SG10. In der Strukturübersicht steht nach dieser Zeile das erste Segment der Gruppe. Dort steht auch, wie oft die Gruppe höchstens auftreten darf. Eine Gruppe trägt keine eigene Kennung in der Nachricht, nur ihr Trigger-Segment ist sichtbar.

Für das Parsen folgt daraus: Du liest Segmente in der Reihenfolge der Nachricht und öffnest bei jedem Trigger-Segment eine neue Gruppeninstanz. Die Kardinalität ist das Prüfkriterium darüber, nicht die Steuerung. Verstößt die Nachricht dagegen, ist sie syntaktisch auffällig.

Warum die Wiederholung am Trigger-Segment hängt

EDIFACT trennt Segmente durch Segmentende-Zeichen und Datenelemente durch weitere Trennzeichen. Für Gruppen existiert kein eigenes Trennzeichen. Eine Gruppe ist eine reine Strukturaussage des MIG, im übertragenen Zeichenstrom erscheint sie nur über die Reihenfolge der Segmente.

Der Trick liegt in der Eindeutigkeit des Trigger-Segments innerhalb seiner Ebene. In UTILMD öffnet NAD in der Ebene unterhalb der Nachricht die Segmentgruppe SG2 für Absender und Empfänger. LOC mit Qualifier 172 öffnet SG5 für den Meldepunkt. RFF öffnet SG6. Taucht das Trigger-Segment erneut auf, beginnt die nächste Instanz derselben Gruppe.

Manche Gruppen haben zusätzlich eine inhaltliche Ausprägung über Qualifier. Der MIG beschreibt für SG8 mit dem Trigger SEQ, dass dieses Segment die Segmentgruppe einleitet und die nachfolgenden Daten einem Meldepunkt zuordnet. Der Qualifier im SEQ, etwa Z22 für Daten der Summenzeitreihe oder Z01 für Daten der Marktlokation, sagt dann, welche Art von Inhalt die Gruppe trägt.

Daraus folgt eine praktische Konsequenz für den Parser: Der Gruppenkontext endet, sobald ein Segment auftritt, das auf derselben oder einer höheren Ebene liegt. Du musst den Kontext also nicht explizit schließen.

Die Strukturübersicht Zeile für Zeile lesen

Die Nachrichtenstruktur im UTILMD-MIG liegt als Tabelle vor. Ihre Legende benennt fünf Spalten für die Segmentzeilen. In den Gruppenzeilen tritt der Status doppelt auf, einmal für den Standard und einmal für die BDEW-Anwendung, sodass eine Gruppenzeile sechs Werte führt:

Eine Zeile wie 0100 SG2 C R 99 1 1 MP-ID Absender liest du damit so: Im Standard ist die Gruppe bedingt und bis zu 99-mal wiederholbar, in der energiewirtschaftlichen Anwendung ist sie erforderlich und tritt genau einmal je Ebene auf.

Lies eine Gruppenzeile deshalb immer in dieser Reihenfolge: Gruppenbezeichner, Standardstatus, Anwendungsstatus, beide Wiederholungsgrenzen, nachfolgendes Segment. Die genaue Spaltenzahl und Reihenfolge kann zwischen MIG-Fassungen abweichen. Prüfe sie an der Legende deiner Fassung, statt dich auf die Zeilenzahl zu verlassen. Alles ab der nächsten Gruppenzeile mit gleicher Einrückungsebene gehört nicht mehr zur vorherigen Gruppe.

Schachtelung und Kardinalität in UTILMD

Der UTILMD-MIG 5.2c zeigt die Hierarchie zusätzlich als Branchingdiagramm mit Spalten Ebene 0 bis Ebene 4. Die Ebenen sind die Verschachtelungstiefe. Auf Ebene 0 stehen UNH, BGM, DTM und UNT. Auf Ebene 1 folgt SG1 mit RFF, dann SG2 mit NAD, darunter auf Ebene 2 SG3 mit CTA und COM.

Dieselbe Struktur wiederholt sich in der Vorgangsverarbeitung. SG4 mit dem Trigger IDE liegt auf Ebene 1 und darf bis zu 99.999-mal auftreten. Darin liegt auf Ebene 2 SG5 mit Trigger LOC für den Meldepunkt, dort wiederum SG6 mit Trigger RFF, und darunter auf Ebene 3 SG8 mit Trigger SEQ, auf Ebene 4 schließlich SG9 und SG10.

Diese Zahl ist keine Nebensache. Innerhalb einer UTILMD-Nachricht darf SG5 999.999-mal auftreten, innerhalb eines Vorgangs in der BDEW-Anwendung aber nur einmal. Der Standard erlaubt also massiv mehr, als die Anwendung zulässt. Wer die MaxWdh-Spalte des Standards als Freibrief liest, baut Nachrichten, die den Empfänger ablehnt.

Das folgende Schema zeigt eine solche verschachtelte Struktur mit zwei Meldepunkten und je zwei Referenzgruppen.

Beispiel: eine Meldepunktgruppe mit zwei Referenzen

Vereinfachtes Beispiel für den Aufbau nach dem UTILMD-MIG. Die Segmente sind auf das für die Gruppenlogik Nötige gekürzt.

UNH+1+UTILMD:D:11A:UN:5.2e'
BGM+E01+...'
SG4  IDE+24+Vorgang-1'
     SG5  LOC+172+DE00014545768S0000000000000003054'
          SG6  RFF+Z13:11112'
          SG6  RFF+TN:64739202'
     SG5  LOC+172+DE00014545768S0000000000000003055'
          SG6  RFF+Z13:11112'
UNT+9+1'

Das zweite LOC beginnt die zweite SG5-Instanz. Alles, was danach an RFF folgt, gehört zum zweiten Meldepunkt. Das erste RFF+TN liegt noch in der ersten SG6-Instanz des ersten Meldepunkts, weil RFF als Trigger ein weiteres SG6 aufspannt, nicht eine Fortsetzung derselben Referenz. Jedes SG6 trägt damit genau eine Referenzart.

Bei SG10 mit Trigger CCI verhält es sich genauso. Der MIG listet dieselbe Gruppenzeile mehrfach mit unterschiedlichem Inhalt, weil jeweils ein anderer CCI-Qualifier die Instanz öffnet: Netznutzung, Bilanzkreis, Lieferrichtung, Verbrauchsaufteilung. In der Nachricht siehst du nur die CCI-Segmente in Folge, die Gruppenzugehörigkeit ergibt sich aus dem Qualifier.

Folgen und Fehlerfälle

Die verbreitetste Fehlannahme beim Parsen ist, eine Gruppe sei über einen expliziten Anfangs- und Endmarker erkennbar. Es gibt keinen Endmarker. Wer den Kontext beim nächsten Segment derselben oder einer höheren Ebene schließt, verarbeitet die Segmente richtig. Wer auf ein schließendes Segment wartet, hängt fest.

Ein zweiter Fehler ist das Überlesen der Doppelspalte. Eine Nachricht kann dem Standard entsprechen und trotzdem gegen die BDEW-Anwendung verstoßen, weil dort eine strengere Kardinalität oder ein anderer Status gilt. Wenn eine Anwendungsregel im AHB sagt, dass eine Segmentgruppe oder ein Segment genau einmal je Vorgang anzugeben ist, hat dieser Hinweis Vorrang vor der MaxWdh-Spalte des Standards. Pflichtangaben und Bedingungen des Anwendungsfalls stehen im AHB, nicht im MIG.

Ein dritter Fehler entsteht beim flachen Einlesen. Wer alle Segmente einer Nachricht in eine Liste schreibt und danach nach Segmentnamen gruppiert, verliert die Zugehörigkeit. Zwei Meldepunkte mit je einer Referenz sehen dann wie vier gleichrangige Segmente aus. Du brauchst einen Baum oder mindestens einen Kontextstapel mit Ebene und Trigger-Segment.

Typische Missverständnisse

Ein häufiges Missverständnis lautet, Segmentgruppen trügen eigene Kennungen in der Nachricht. Sie erscheinen dort nicht. SG5 ist eine Beschriftung im MIG und im Branchingdiagramm, kein übertragenes Feld.

Ein zweites lautet, die Zahl hinter SG sei die Wiederholungszahl. Die Nummer identifiziert die Gruppe im MIG und sagt nichts über ihre Häufigkeit. Die Häufigkeit steht ausschließlich in der MaxWdh-Spalte. In UTILMD trägt dieselbe Nummer an verschiedenen Stellen unterschiedliche Wiederholungen, wie SG2 mit 99 und SG4 mit 99.999 zeigen.

Ein drittes lautet, die MaxWdh des Standards gelte für alle. Die Anwendung kann strenger sein. Prüfe deshalb beide Spalten, sobald die Strukturübersicht deiner MIG-Fassung sie getrennt ausweist.

Ein viertes lautet, eine Gruppe könne ohne ihr Trigger-Segment beginnen. Eine bedingte Gruppe ohne Trigger-Segment existiert nicht. Fehlt das Trigger-Segment, fehlt die Gruppe, und alle Folgeinformationen entfallen.

Ein fünftes lautet, Verschachtelung sei unbegrenzt. Der MIG führt die Ebenen explizit, in UTILMD 5.2c von Ebene 0 bis Ebene 4. Tiefere Ebenen sind keine Freiheitsgrade, sondern Teil der Festlegung.

Quellen und Pflegehinweis

Für die Struktur, die Legende und das Branchingdiagramm sind die Originaldokumente maßgeblich:

• EDI@Energy: UTILMD MIG 5.2c (BNetzA, Mitteilung 19): Strukturübersicht mit Zähler, Nr, Bez, St und MaxWdh, die Segmentgruppen SG2 bis SG10 und das Branchingdiagramm der Ebenen 0 bis 4.
• EDI@Energy: UTILMD MIG 5.2a (BNetzA, Mitteilung 8): Gegenprobe derselben Legendentexte und Wiederholungsgrenzen in einer älteren Fassung.
• BNetzA: UTILMD Anwendungshandbuch 1.1e (Mitteilung 26): anwendungsseitige Statuswerte und die Bedingungen, die eine Segmentgruppe je Vorgang auf genau eine Instanz festlegen.
• BNetzA: Allgemeine Festlegungen zu den Datenformaten (Mitteilung 4): Aufteilung zwischen Formatbeschreibung und Anwendungshandbuch.

Prüfe bei jedem Releasewechsel zuerst die Legende der Strukturübersicht und die Ebenen des Branchingdiagramms. Änderungen an Gruppen, Triggern und MaxWdh treffen jede Implementierung, die den Nachrichtenaufbau fest verdrahtet hat. Wer seinen Parser aus der Legende ableitet, muss bei einem Versionswechsel weniger nachziehen. Die Zahl der Status- und Wiederholungsspalten kann zwischen MIG-Fassungen abweichen; maßgeblich ist die Legende der Fassung, gegen die du entwickelst.