EDIFACT-Trennzeichen und Zeichensatz

Kurzantwort

EDIFACT ist kein zeilenorientiertes CSV-Format. Die Struktur entsteht aus drei Ebenen von Trennzeichen: Das Elementtrennzeichen trennt Datenelemente, das Komponententrennzeichen trennt Bestandteile eines zusammengesetzten Datenelements, und das Segmentendzeichen markiert das Ende eines Segments. Das Segmenttag – etwa NAD oder DTM – steht am Anfang eines Segments. Die konkrete Zeichenbelegung wird durch UNA angekündigt oder nach den geltenden Syntaxregeln verwendet.

Zusätzlich gibt es ein Freigabezeichen (Release Character). Es hebt die strukturelle Bedeutung eines nachfolgenden Zeichens auf, wenn dieses Zeichen als fachlicher Inhalt vorkommt. Ein Dezimalzeichen kann in Datenelementen ebenfalls eine Rolle spielen, ist aber kein Trennzeichen der Segmentstruktur. Zeichensatz, Bytefolge und Escape-Verarbeitung müssen zusammenpassen: Ein Parser, der nur „an Pluszeichen splittet“, kann Nachrichten mit zusammengesetzten Datenelementen oder freigegebenen Sonderzeichen beschädigen.

Für die deutsche Marktkommunikation ist immer die jeweils gültige Allgemeine Festlegung sowie die konkrete MIG maßgeblich. In einem SAP-IS-U-System müssen Transport- und Parserkonfiguration, Validierung, Mapping, Logging und Testdaten dieselbe Zeichensatz- und Trennzeichenannahme verwenden.

Die vier strukturellen Zeichen

Eine vereinfachte EDIFACT-Zeile wie NAD+MS+9900000000001::293' lässt sich von links nach rechts lesen. NAD ist das Segmenttag. Das Pluszeichen trennt die Datenelemente: MS ist das erste Element, danach folgt ein zusammengesetztes Element. Innerhalb dieses Composite trennt der Doppelpunkt die Komponenten. Das Apostroph beendet das Segment.

Die Zeichen sind keine universelle inhaltliche Konvention. Ein Sender kann im zulässigen Rahmen andere Zeichen ankündigen, sofern die Syntaxregeln und die Marktpartnervereinbarung das erlauben. Deshalb sollte eine Anwendung die Belegung nicht unkritisch aus einer Beispielnachricht fest verdrahten. Sie muss die einleitende Syntaxinformation und das gültige Formatprofil auswerten.

Das Freigabezeichen wird vor ein Zeichen gesetzt, das sonst eine strukturelle Funktion hätte. Soll ein fachlicher Text etwa ein Pluszeichen enthalten, kann es als ?+ übertragen werden; der genaue zulässige Umgang richtet sich nach den EDIFACT-Syntaxregeln und dem eingesetzten Profil. Der Parser muss das Plus dann als Inhalt und nicht als Elementtrennung behandeln. Nach der syntaktischen Interpretation wird das Escape wieder in den fachlichen Wert zurückübersetzt.

Die Tabelle zeigt die Funktion, nicht eine Garantie für jede Übertragung. Die tatsächlich verwendete Belegung muss aus dem Nachrichtenanfang beziehungsweise dem vereinbarten Syntaxprofil bestimmt werden.

UNA: Trennzeichen ankündigen

UNA ist ein Service String Advice. Es steht – sofern verwendet – am Beginn der EDIFACT-Übertragung und besteht aus sechs Zeichen, die die drei Trennzeichen, das Dezimalzeichen und das Freigabezeichen festlegen. Der Aufbau ist positionsabhängig. Ein nachfolgendes Beispiel dient nur der Illustration:

UNA:+.? '
UNB+UNOC:3+...

Das sechste Zeichen in der schematischen Darstellung ist das Segmentende. Leerzeichen sind in Beispielen deshalb besonders gefährlich: Ein sichtbares Leerzeichen kann Teil der UNA-Konfiguration sein, darf aber nicht automatisch als „Formatierung“ entfernt werden. In einer echten Datei werden die Zeichen unmittelbar und ohne Markdown-Codeformatierung übertragen.

Wenn keine UNA vorhanden ist, gelten die Default-Regeln des verwendeten Syntaxprofils. Der Empfänger darf die Belegung nicht durch Raten aus einem beliebigen späteren Segment rekonstruieren. Ein falsch angenommener Segmentabschluss verschiebt den gesamten Parserzustand; der Folgefehler kann dann als unverständliche Fachabweichung erscheinen.

Die Allgemeinen Festlegungen der deutschen Marktkommunikation dokumentieren, wie EDIFACT-Übertragungsdateien und ihre Service-Segmente verwendet werden. Für ein konkretes Projekt ist zusätzlich zu klären, ob die verwendete Datei Single- oder Multi-UNH-Nachrichten enthält und wie der jeweilige Transportweg die Datei unverändert weitergibt. AS4 oder ein anderer Transportkanal darf die Nutzdaten nicht eigenmächtig normalisieren.

Zeichensatz: Zeichen sind Bytes erst nach dem Dekodieren

Ein Zeichensatz legt fest, wie Zeichen als Bytes übertragen und wieder gelesen werden. In vielen modernen Integrationen ist UTF-8 die technische Standardannahme; sie darf im Energiedatenaustausch aber nicht bloß aus Gewohnheit angenommen werden. Das zulässige Profil und die Vorgaben des konkreten Formats sind entscheidend. Ein Parser muss außerdem unterscheiden, ob eine Datei ein Byte-Order-Mark enthält, welche Normalisierung verwendet wird und ob jedes Zeichen im erlaubten Wertebereich liegt.

Die Verwechslung von Zeichensatz und Trennzeichen ist eine häufige Fehlerquelle. Ein Pluszeichen ist in ASCII und UTF-8 zwar mit demselben Byte darstellbar, ein Umlaut oder ein Sonderzeichen kann jedoch bei falscher Dekodierung als Ersatzzeichen erscheinen. Wenn dieses Ersatzzeichen in eine Stammdaten- oder Rechnungskommunikation gelangt, ist die Nachricht zwar möglicherweise syntaktisch lesbar, der fachliche Wert aber verändert.

EDIFACT nutzt traditionell ein eingeschränktes Zeichenrepertoire. Marktformate können zusätzliche Vorgaben machen, etwa zu erlaubten Zeichen in Referenzen, Namen oder Freitexten. Das bedeutet: Nicht jedes Zeichen, das Unicode darstellen kann, ist deshalb ein zulässiges fachliches Datenelement. Die MIG beschreibt Datenelemente; Codelisten und AHB beschränken Werte zusätzlich.

Ein sauberer Eingang protokolliert deshalb die erkannte Kodierung, lehnt unzulässige Bytefolgen nachvollziehbar ab und verhindert stilles Ersetzen. „Fehler ignorieren“ ist keine Datenqualitätsstrategie. Vor einer Ablehnung sollte das System allerdings eine technische Rückmeldung mit der korrekten Austausch- oder Nachrichtenreferenz erzeugen, soweit dies auf der erkannten Syntaxebene möglich und nach dem Rückmeldeprofil vorgesehen ist.

Zahlen, Dezimalzeichen und Vorzeichen

Das Dezimalzeichen gehört zur Syntaxkonfiguration, aber nur zur Darstellung eines Zahlenwerts. Es trennt nicht Segmente oder Datenelemente. Ein Wert wie 12,50 kann in einem Profil eine Dezimalzahl sein; ob eine bestimmte Einheit, Anzahl Nachkommastellen oder Rundung erlaubt ist, bestimmt die MIG beziehungsweise das AHB. Ein System darf daher nicht jedes Komma unabhängig vom Profil in einen Punkt umwandeln.

Vorzeichen sind ebenfalls Bestandteil des Datenelements und keine EDIFACT-Strukturzeichen. Das Minus in einem Messwert oder Rechnungsbetrag darf nicht als Trennzeichen behandelt werden. Nach der Dekodierung folgen fachliche Prüfungen: Einheit, Vorzeichenkonvention, Wertebereich, Genauigkeit und gegebenenfalls Statusinformation müssen zum Messprodukt oder zur Rechnungsposition passen.

Ein typischer Fehler entsteht, wenn eine CSV-Bibliothek auf die EDIFACT-Datei angewendet wird. CSV kennt Zeilen, Spalten und häufig Anführungszeichen; EDIFACT kennt Segmente, Elemente, Komponenten und Releasezeichen. Selbst wenn eine Beispielnachricht zufällig ähnlich aussieht, ist die Semantik eine andere. Das betrifft auch Leerzeilen und Zeilenumbrüche: Sie können Transportdarstellung sein, aber keine verlässlichen fachlichen Grenzen.

Release-Verarbeitung und Sonderzeichen

Das Freigabezeichen ist kontextabhängig. Trifft der Parser auf das Freigabezeichen, muss er das unmittelbar folgende Zeichen als literal behandeln und die Paarung korrekt in den Wert übernehmen. Ein Freigabezeichen am Dateiende oder vor einem unzulässigen Zeichen ist ein Syntaxfehler. Ebenso darf ein Parser nicht bereits vor der strukturellen Zerlegung jedes Freigabezeichen entfernen; sonst verliert er die Information, ob ein Segmentende Inhalt oder Struktur war.

Für Logging braucht man zwei Repräsentationen: die unveränderte Rohdatei zur Beweissicherung und die dekodierte fachliche Sicht für Suche und Mapping. Rohdaten gehören geschützt, denn sie können personenbezogene oder abrechnungsrelevante Informationen enthalten. In der sichtbaren Fehlerdiagnose sollten Werte maskiert werden, ohne die Segment- und Zeichenposition zu verlieren.

Tests sollten Sonderzeichen gezielt abdecken: ein freigegebenes Elementtrennzeichen im Freitext, ein freigegebenes Segmentende, ein Komponententrenner im Wert, ein Umlaut im zulässigen Zeichenraum, ein ungültiges Byte und ein fehlerhaftes Escape am Ende eines Segments. Zusätzlich ist ein Roundtrip-Test sinnvoll: Nachricht einlesen, fachlich mappen, erneut serialisieren und prüfen, ob die zugelassene Struktur erhalten bleibt.

Praxisbeispiel: EDIFACT-Eingang in SAP IS-U

Ein Netzbetreiber stellt eine MSCONS bereit. Die Kommunikationsschicht übergibt die Nutzlast unverändert an den SAP-IS-U-Eingang. Zuerst wird die Bytefolge anhand der vereinbarten Kodierung dekodiert. Dann bestimmt der Parser Trennzeichen aus UNA oder dem gültigen Defaultprofil und zerlegt die Übertragung in Segmente. Erst danach werden UNB, UNH, UNT und die MSCONS-Fachdaten geprüft.

Das Mapping liest anschließend zum Beispiel Messlokation, Messprodukt, OBIS-Kennzahl, Zeitintervall, Einheit und Wert. Ein Komma im Wert wird nicht pauschal ersetzt, sondern nach dem Formatprofil interpretiert. Ein fachlicher Text mit freigegebenem Apostroph wird als ein Wert übergeben. Das Ergebnis gelangt nur dann in die EDM-Zeitreihe, wenn auch AHB-Regeln, Rollen, Zeitbezug und Datenstatus stimmen.

Bei einem Zeichensatzfehler darf SAP nicht still ein Ersatzzeichen in den Geschäftspartnernamen oder eine Referenz schreiben. Der technische Beleg erhält einen Fehlerstatus mit Byte-/Zeichenposition, Nachrichtenreferenz und verwendeter Formatversion. Das Betriebsteam kann damit zwischen Transportproblem, Parserfehler und fachlichem Klärfall unterscheiden. Bei einem Releasewechsel werden die Tests mit den dann verbindlichen EDI@Energy-Dokumenten wiederholt.

Versionswechsel und Qualitätssicherung

EDI@Energy-Dokumente und BNetzA-Mitteilungen werden versioniert veröffentlicht. Zum Stand des Artikels ist die Allgemeine Festlegung 6.1d als Konsultationsfassung für den Umsetzungstermin 01.10.2026 dokumentiert; eine Konsultationsfassung darf nicht ohne Prüfung als verbindliche Produktivregel ausgegeben werden. In der Betriebsdokumentation müssen daher Formatversion, Syntaxprofil, Zeichensatz, Codelistenstand und Umsetzungstermin zusammengeführt werden.

Für die Abnahme empfiehlt sich eine kleine, reproduzierbare Testsuite:

• gültige Nachricht mit und ohne UNA;
• alle verwendeten Trennzeichen in einer kontrollierten Minimalnachricht;
• Composite mit leerer mittlerer Komponente;
• freigegebene Strukturzeichen in einem zulässigen Textfeld;
• Zahlen mit dem vorgegebenen Dezimalzeichen und Grenzwerten;
• ungültige Bytefolge, BOM-Variante und nicht erlaubtes Zeichen;
• falsches Segmentende oder unvollständige Release-Sequenz.

Die Tests müssen nicht nur „parsebar“ oder „nicht parsebar“ messen. Sie sollten auch prüfen, dass das System die richtige Referenz protokolliert, keine Daten doppelt übernimmt, technische Rückmeldungen korrekt erzeugt und fachliche Werte unverändert beziehungsweise regelkonform normalisiert. Für SAP IS-U gehören dazu Regressionstests für IDoc-/EDI-Mapping, EDM-Zeitreihen und Klärfallmonitoring.

Typische Missverständnisse

„EDIFACT benutzt immer Plus, Doppelpunkt und Apostroph.“
Das sind häufige Belegungen, aber die tatsächliche Syntax wird durch Profil und gegebenenfalls UNA festgelegt.

„Ein Zeilenumbruch beendet ein Segment.“
Nicht zuverlässig. Maßgeblich ist das Segmentendzeichen; Zeilenumbrüche können nur Transport- oder Darstellungsmerkmale sein.

„UTF-8 erlaubt jedes Unicode-Zeichen.“
Nein. Technisch darstellbar bedeutet nicht fachlich oder formatseitig zulässig.

„Das Dezimalzeichen trennt Datenelemente.“
Nein. Es gehört zur Zahlendarstellung; Datenelemente werden durch den Elementtrenner getrennt.

„Man kann alle Sonderzeichen vor dem Parsen entfernen.“
Nein. Freigabezeichen schützen Strukturzeichen und müssen während der Zerlegung ausgewertet werden.

„Ein CSV-Parser reicht für EDIFACT.“
Nein. EDIFACT besitzt eigene Segment-, Composite- und Escape-Regeln.

Quellen und Pflegehinweis

Die internationalen Syntaxregeln werden von UN/CEFACT im Rahmen von UN/EDIFACT und ISO 9735 beschrieben. Für die Marktkommunikation in Deutschland gelten die aktuell von EDI@Energy bereitgestellten und durch die Bundesnetzagentur veröffentlichten Formatdokumente. Vor einer Produktivänderung immer die verbindliche Fassung, nicht nur eine Konsultation, sowie die konkrete MIG, das AHB und die geltenden Codelisten prüfen.

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

Abrufdatum: 8. September 2026.