UNH, UNT und die EDIFACT-Nachrichtenstruktur

Kurzantwort

UNH und UNT begrenzen eine einzelne EDIFACT-Nachricht. UNH ist ihr Anfangssegment und enthält unter anderem eine Nachrichtenreferenz sowie die Kennung des Nachrichtentyps, etwa UTILMD oder MSCONS. UNT ist das Ende derselben Nachricht und enthält die Anzahl der Segmente einschließlich UNH und UNT sowie die Nachrichtenreferenz aus UNH. Diese beiden Werte ermöglichen dem Empfänger, eine Nachricht strukturell zu prüfen und eindeutig zuzuordnen.

Eine Übertragungsdatei ist eine größere Klammer: Sie beginnt mit UNB und endet mit UNZ. Zwischen diesen beiden Segmenten liegt ein UNH–Fachdaten–UNT-Block; bei zulässigen Multi-UNH-Dateien können mehrere solcher Blöcke folgen. UNA kann als optionales Service-Segment die verwendeten Trennzeichen ankündigen. Die Klammern sind nicht bloße Dekoration: Eine falsche Referenz oder Segmentanzahl kann dazu führen, dass die Datei technisch abgelehnt oder eine Rückmeldung falsch zugeordnet wird.

UNA (optional) → UNB → UNH → Fachdaten → UNT → [UNH → Fachdaten → UNT] → UNZ

Die Hierarchie: Datei, Nachricht und Geschäftsvorfall

Beim Lesen muss man drei Ebenen auseinanderhalten. Die Übertragungsdatei ist der technische Container für einen Austausch zwischen zwei Marktpartnern. UNB identifiziert diesen Austausch, UNZ schließt ihn ab. Eine Datei kann – abhängig von den jeweils gültigen Allgemeinen Festlegungen und der Nachrichtentypregel – eine oder mehrere Nachrichten enthalten.

Die Nachricht ist der mit UNH und UNT begrenzte EDIFACT-Inhalt. Ihr Nachrichtentyp wird in UNH, Composite S009, angegeben. Innerhalb dieses Typs liegen Segmentgruppen, Segmente und Datenelemente. Ob eine Nachricht einen oder mehrere Geschäftsvorfälle transportieren darf, ergibt sich nicht allein aus UN/EDIFACT, sondern aus den geltenden EDI@Energy-Dokumenten und dem AHB des Nachrichtentyps.

Der Geschäftsvorfall ist schließlich die fachliche Bedeutung: beispielsweise eine Stammdatenänderung, ein Lieferbeginn oder ein Messwertaustausch. Mehrere Geschäftsvorfälle können in manchen Nachrichten in einer Datei oder Nachricht vorkommen, in anderen ist die Übermittlung eingeschränkt. Deshalb darf ein Parser nicht aus der bloßen Anzahl von UNH-Segmenten auf die Anzahl fachlicher Vorgänge schließen. Die fachliche Zuordnung erfolgt über die im AHB beschriebenen Prüfidentifikatoren, Qualifier und Beziehungen.

UNH: der Nachrichtenkopf

UNH (Message Header) eröffnet jede einzelne Nachricht. Das Segment hat eine feste Funktion, aber seine Datenelemente werden nach der einschlägigen MIG gelesen. Das erste Datenelement ist die Nachrichtenreferenz, häufig als fortlaufende Referenz des Senders geführt. Sie wird in UNT wiederholt. Der Empfänger kann dadurch prüfen, ob Anfang und Ende tatsächlich zu derselben Nachricht gehören.

Im Composite S009 stehen die Nachrichtenkennung und ihre Version. Dort finden sich typischerweise der Nachrichtentyp (zum Beispiel UTILMD, MSCONS, INVOIC oder APERAK), die vom Sender verwendete Versionsnummer und die für die Nachricht geltende Organisations- beziehungsweise Branchenkennung. Die konkrete Ausprägung ist versionsabhängig; ein Entwickler sollte daher nie nur nach dem Text „UTILMD“ suchen, sondern die gesamte S009-Struktur nach MIG auswerten.

UNH ist kein Ersatz für UNB. UNB beschreibt den Transportaustausch – wer sendet an wen und unter welcher Austauschreferenz. UNH beschreibt die darin enthaltene Nachricht. In einer Datei mit mehreren Nachrichten besitzt jede Nachricht ihr eigenes UNH und ihre eigene Nachrichtenreferenz, während die Datei eine gemeinsame UNB- und UNZ-Klammer hat.

UNT: der Nachrichtenabschluss und seine Prüfungen

UNT (Message Trailer) beendet den UNH-Block. Das erste Datenelement enthält die Zahl der Segmente in der Nachricht. Gezählt werden UNH und UNT selbst sowie jedes Segment dazwischen; Trennzeichen zählen nicht als Segmente. Das zweite Datenelement wiederholt die Nachrichtenreferenz aus UNH. Der Empfänger vergleicht daher mindestens drei Dinge: Ist die Segmentfolge nach MIG zulässig, stimmt die Segmentanzahl, und passt die Referenz in UNT zu UNH?

Ein Beispiel macht die Zählung sichtbar:

UNH+4711+UTILMD:D:11A:UN:SWE:5.2e'
BGM+E01+VORGANG-2026-001'
DTM+92:20260908:102'
UNT+4+4711'

In diesem vereinfachten Beispiel sind UNH, BGM, DTM und UNT vier Segmente. Die tatsächliche Segmentfolge und Version richtet sich nach der gültigen MIG; das Beispiel ist keine vollständige fachliche UTILMD. Würde im UNT die Zahl 3 stehen, wäre die Nachricht strukturell inkonsistent. Würde dort 9999 statt 4711 stehen, gehörte der Abschluss nicht zum eröffneten Nachrichtenblock.

Die Segmentzählung ist eine technische Integritätsprüfung, keine fachliche Vollständigkeitsprüfung. Eine Nachricht kann die korrekte Anzahl Segmente besitzen und dennoch den falschen Prüfidentifikator, eine unzulässige Marktlokation oder einen fachlich falschen Zeitpunkt enthalten. Dafür sind AHB- und Prozessprüfungen zuständig.

UNB, UNZ und mehrere Nachrichten in einer Datei

UNB (Interchange Header) eröffnet den Austausch. UNZ (Interchange Trailer) beendet ihn. UNZ enthält unter anderem die Anzahl der Nachrichten beziehungsweise Nachrichtengruppen, die der Datei zugeordnet sind, und die Austauschreferenz aus UNB. Welche Zählgröße und welche Mehrfachverwendung für den konkreten Nachrichtentyp gilt, ist nach den Allgemeinen Festlegungen zu prüfen.

Bei einer Multi-UNH-Datei wiederholt sich die Folge UNH–Fachdaten–UNT innerhalb derselben UNB/UNZ-Klammer. Das spart technische Umschläge und kann die Übertragung bündeln. Es erhöht aber die Anforderungen an die Verarbeitung: Ein Fehler in einem Block darf nicht automatisch die Referenzen der übrigen Blöcke überschreiben. Der Parser muss jeden Block isoliert zählen, speichern und fachlich verarbeiten.

Eine Datei kann zudem fachlich nicht einfach als „Sammelmappe“ beliebiger Nachrichten verstanden werden. Marktregeln und Formatdokumente bestimmen, welche Nachrichten gemeinsam oder getrennt übertragen werden dürfen. Die aktuelle Fassung der Allgemeinen Festlegungen enthält dazu eine Übersicht für Single- und Multi-UNH-Verwendung. Bei einem Releasewechsel ist diese Tabelle erneut zu lesen, denn eine frühere Regel ist kein dauerhafter Vertrag.

Segment, Datenelement und Composite

Innerhalb von UNH und UNT liegen Datenelemente, die durch das Elementtrennzeichen voneinander getrennt werden. Ein Composite – also ein zusammengesetztes Datenelement – enthält Komponenten, die durch das Komponententrennzeichen getrennt werden. Das Segmentende markiert ein Segment. Die Zeichen werden durch UNA oder die Standardbelegung bestimmt und dürfen nicht mit fachlichen Inhalten verwechselt werden.

Ein Segment wie DTM+137:20260908:102' enthält nach dem Segmenttag DTM ein Composite. 137 ist ein Qualifier, das Datum folgt in der zweiten Komponente, 102 beschreibt das Format. Erst MIG und AHB sagen, ob genau dieser Qualifier und dieses Format an dieser Stelle zulässig sind. Der gleiche technische Mechanismus kann in verschiedenen Segmenten unterschiedliche fachliche Bedeutungen tragen.

Wiederholungen und Segmentgruppen sind ebenfalls strukturell relevant. Ein Segment darf nur so oft vorkommen, wie MIG und AHB es erlauben. Segmentgruppen bilden fachliche Beziehungen ab, beispielsweise Kopf-, Lokations- und Messwertdaten. Ein flacher „Split an jedem Pluszeichen“ reicht daher nicht, wenn das System Zusammenhänge, Wiederholungen oder Escape-Regeln erhalten muss.

Praxisbeispiel: Eine MSCONS im SAP-IS-U-Eingang

Ein Messstellenbetreiber sendet eine MSCONS an einen Lieferanten. Der technische Eingang liest zuerst die Datei-Referenz aus UNB und die Nachrichtenreferenz aus UNH. Er prüft, ob der Nachrichtentyp und die Version zum erwarteten Formatprofil passen. Danach zählt er die Segmente bis zum passenden UNT und vergleicht Referenz und Anzahl.

Ist diese Prüfung erfolgreich, übersetzt das Mapping die fachlichen Segmente in die EDM-Strukturen von SAP IS-U: Lokationsbezug, Messprodukt, Einheit, Zeitintervall, Wert und Status. Die Nachricht wird nicht deshalb fachlich gültig, weil UNT „passt“. Das System muss zusätzlich prüfen, ob die Marktlokation bekannt ist, die Zeitreihe zum Messprodukt passt und der Absender für den Vorgang die richtige Rolle besitzt.

Bei einer Multi-UNH-Datei legt die Eingangsschicht pro UNH–UNT-Block ein eigenes technisches Dokument an oder führt eine gleichwertige Blockreferenz. Eine negative Syntaxprüfung wird mit der korrekten Austausch- und Nachrichtenreferenz protokolliert. Fachliche Ablehnungen werden anschließend in der für den Prozess vorgesehenen Rückmeldung behandelt. Diese Trennung erleichtert Klärfälle: Betriebsteams suchen bei einer falschen Segmentanzahl am Parser, Fachbereiche bei einem unzulässigen Messprodukt im AHB-Mapping.

Implementierung und Betrieb

Ein stabiler Parser arbeitet in Stufen. Zuerst werden Transport- und Zeichensatzregeln bestimmt. Danach wird die Datei in UNB/UNZ und Nachrichtenblöcke zerlegt. Für jeden Block folgen Strukturprüfung, Referenzprüfung und Segmentzählung. Erst dann startet das MIG-Mapping und anschließend die AHB-/Prozessprüfung. Fehler werden mit Position, Referenz, Regelwerk und Version gespeichert.

Für Monitoring und Wiederanlauf sind idempotente Schlüssel wichtig. Die Nachrichtenreferenz allein ist nicht zwingend weltweit eindeutig; in der Praxis wird sie zusammen mit Absender, Empfänger und Austauschreferenz beziehungsweise den marktpartnerspezifischen Identifikatoren betrachtet. Ein erneut zugestellter Block darf nicht versehentlich doppelt gebucht werden. Welche Dublettenlogik fachlich zulässig ist, muss der Prozessverantwortliche festlegen.

Auch die Reihenfolge der Prüfungen ist für die Diagnose entscheidend. Erkennt der Parser das Segmentende nicht, ist jede spätere Position unsicher; eine Meldung „Pflichtfeld im DTM fehlt“ kann dann nur ein Folgefehler sein. Deshalb sollte die Fehleranzeige die erste erkannte Abweichung priorisieren und zusätzlich die erwartete sowie die tatsächlich gelesene Zeichenfolge nennen. Bei einem UNT-Fehler werden Nachrichtenreferenz und Segmentposition aus dem Rohbeleg übernommen, nicht aus einem bereits unvollständig gemappten Geschäftsdokument.

Für die Aufbewahrung empfiehlt sich eine klare Korrelation: technische Eingangs-ID, UNB-Austauschreferenz, UNH-Nachrichtenreferenz, Nachrichtentyp und Formatversion werden gemeinsam gespeichert. So kann ein Supportteam einen Marktpartnerfall von der Transportquittung bis zum SAP-IS-U-Geschäftsvorfall verfolgen. Die Korrelation ist besonders wichtig, wenn ein Austausch mehrere Nachrichten enthält oder eine fachliche Antwort sich auf einen einzelnen Vorgang innerhalb einer Nachricht bezieht. Die Sichtbarkeit dieser Daten muss dabei dem Berechtigungskonzept und den Datenschutzvorgaben entsprechen.

Bei Releases sollte ein Testset mindestens eine gültige Single-UNH-Datei, eine zulässige Multi-UNH-Datei, falsche Segmentzählungen, eine abweichende UNT-Referenz, fehlende UNH/UNT-Klammern sowie fachlich ungültige Pflichtfelder enthalten. Die technische Prüfung und die fachliche Prüfung sind getrennt zu bewerten. Ein Test gilt nicht als bestanden, nur weil eine Nachricht parserseitig lesbar ist.

Typische Missverständnisse

„UNH und UNT umschließen die ganze Datei.“
Nein. Sie umschließen genau eine Nachricht. Die Datei wird mit UNB und UNZ begrenzt.

„Die UNT-Zahl zählt Zeichen oder Datenelemente.“
Nein. Sie zählt Segmente der Nachricht einschließlich UNH und UNT.

„Eine korrekte Segmentzahl beweist fachliche Richtigkeit.“
Nein. Sie beweist nur einen Teil der strukturellen Integrität.

„Jede Datei enthält genau ein UNH.“
Nein. Die zulässige Single- oder Multi-UNH-Verwendung steht in den geltenden Formatvorgaben.

„Die Referenz aus UNT wird neu vergeben.“
Nein. Sie muss die Nachrichtenreferenz aus UNH wiederholen.

„UNB und UNH sind austauschbar.“
Nein. UNB identifiziert den Austausch, UNH die einzelne Nachricht.

Quellen und Pflegehinweis

Die Syntax stammt aus UN/EDIFACT beziehungsweise ISO 9735. Für die deutsche Energiewirtschaft sind jedoch die von EDI@Energy bereitgestellten und von der Bundesnetzagentur veröffentlichten Fassungen maßgeblich. Vor einer Implementierung sind die aktuelle Allgemeine Festlegung, die Nachrichtentypbeschreibung und das zugehörige AHB gemeinsam zu prüfen. Die Version 6.1d ist zum Stand dieses Artikels eine Konsultationsfassung für den Umsetzungstermin 01.10.2026; daraus folgt keine Aussage, dass sie bereits die verbindliche Produktivfassung ist.

• Bundesnetzagentur: Allgemeine Festlegungen 6.1d
• Bundesnetzagentur: Mitteilung Nr. 55
• EDI@Energy: Datenformate
• UN/CEFACT: UN/EDIFACT
• Bundesnetzagentur: Mitteilung Nr. 31

Abrufdatum: 8. September 2026.