EDIFACT (Dokumentenart)
EDIFACT-Daten sind bereits in einer Baumstruktur angelegt. Deshalb ist es sehr einfach, EDIFACT-Dateien in Quellstrukturen zu parsen. Der Benutzer muss lediglich die Zeichencodierung angeben und entscheiden, ob die Daten gezippt sind.
Wichtiger Hinweis: Häufig werden die EDIFACT-Strukturen von Unternehmen für ihre Zwecke verändert. Die Quellstruktur aus einer Vorlage (oder manuell erzeugt) kann in diesem Fall vom Benutzer angepasst werden. Allerdings ist darauf zu achten, dass Namen von Segmenten nicht beliebig angepasst werden können, sondern immer der Syntax SG<Nummer><Beliebiges Suffix> entsprechen müssen, damit sie für den Parser erkennbar sind. Sie können also nicht das Segment SG2 in Positionen umbenennen, allerdings wäre SG2-Positionen möglich. Hinweis: Siehe allgemein auch den Abschnitt Arbeiten mit Vorlagen.
Einstellungen
(1) Eingangsformat prüfen: Wenn diese Checkbox gesetzt wird, dann werden die Quellstrukturfelder beim Parsen auf die dort hinterlegten Format-Vorlagen geprüft. Wenn ein Wert die Format-Vorlage des Feldes verletzt oder die Feldlänge überschreitet oder ein Pflichtfeld leer ist, wird ein Fehler erzeugt. Im Fehlerfall wird nicht sofort in Phase 2 abgebrochen, sondern erst am Ende von Phase 2 oder bei 50 Fehlern. Achtung: Die Verwendung der Formatprüfung belastet die Performance und sollte nur wenn unbedingt nötig verwendet werden.
(2) Min/Max Eingangs-Angaben prüfen: Wenn gesetzt, dann werden die Minimum- und Maximum-Werte von Knoten in der Quellstruktur überprüft. Zudem werden folgende Segmente überprüft: UNT (Anzahl Segmente), UNZ (Counter), UNE (Counter).
(9) Semantische Prüfung ausführen: Eingehende Dateien können mit semantischen Regeln überprüft werden. Siehe Abschnitt Semantische Prüfung.
Splitten von EDIFACT-Dateien
Wenn mehrere EDIFACT-Dokumente (Segmente UNB-UNZ) in einer Datei enthalten sind, kann diese Datei in die einzelnen Dokumente aufgeteilt werden. Für jedes EDIFACT-Dokument wird dann ein eigener Job gestartet. Voraussetzung ist, dass es sich bei den EDIFACT-Dokumenten um Dokumente desselben Typs handelt. Setzen Sie dazu die Checkbox (3) "Dateien splitten".
Falls diese Checkbox nicht gesetzt ist, dann entsteht nur ein Job.
Prüfung von EDIFACT-Dateien
Allgemeine Strukturprüfung, die immer stattfinden:
UNA-Segment, wenn vorhanden, muss korrekte Länge aufweisen, Auswertung von UNA (Trenner, etc.).
Vorkommen von UNH und UNZ.
UNG-Behandlung.
Quellstruktur-Definitionen (Anzahl Felder in einer Komponente, Segmente müssen SGxxxx lauten).
Hinweis: Siehe auch (1) und (2).
(4) EDIFACT Envelope prüfen: Folgende Segmente werden überprüft: UNT (Anzahl Segmente, UNT/UNH-Vergleich), UNZ (Counter, Referenz Feld UNB.0020), UNE (Counter, Referenz Feld 0048, Referenz Feld 0060).
(5) Feld UNB/0001 Encoding verwenden: Statt dem eingestellten Profil-Encoding wird das angegebene Encoding der Nachricht verwendet.
(6) Encoding mit Profileinstellung vergleichen: Es wird ein Fehler gemeldet, wenn das eingestellte Profil-Encoding nicht dem Encoding der Nachricht entspricht.
(7) Bei UNOA und UNOB Encoding Werte prüfen: Ist das Encoding der Nachricht UNOA bzw. UNOB, werden die Werte der Nachricht auf die erlaubten Zeichen des Encodings geprüft (z. B. a-Z, 0-9 etc.).
EDIFACT-CONTRL-Mitteilungen bei Fehler erzeugen
Wenn beim Parsen einer EDIFACT-Nachricht ein Fehler auftritt, kann eine CONTRL-Mitteilung an ein angegebenes Profil geschickt werden, siehe Checkbox (8) "EDIFACT CONTRL-Mitteilung bei Fehler erzeugen". Die EDIFACT-CONTRL-Mitteilung wird für Version D03A nur bei Fehlern in Phase 2 erzeugt.
Anmerkungen zur EDIFACT-Syntax
EDIFACT-Dateien bestehen aus
Segmenten,
Feldern und
Komponenten.
Segmente kann man sich als Zeilen vorstellen, Felder als Spalten und Komponenten als Teil einer Spalte. Ein Segment wird immer mit einer Segmentkennung begonnen und mit einem Endzeichen abgeschlossen. Beispiel: DTM+200:20060414:102'
Die Zeichenkette DTM ist die Segmentkennung, das einfache Anführungszeichen das Endzeichen. Nach einem Segment-Ende muss wieder ein neues Segment beginnen oder es dürfen keine weiteren Daten folgen.
Die Felder in einem Segment werden durch ein Metazeichen getrennt. Standardmäßig ist dies das Pluszeichen (+). Beispiel: GID+2+00000005+00000005'
Das Segment besteht aus folgenden vier Feldwerten: GID, 2, 00000005 und 00000005.
Die Komponenten eines Feldes werden durch ein Metazeichen getrennt. Standardmäßig ist dies der Doppelpunkt (:). Beispiel: UNH+IFTMIN:D:95B:UN:SUTC+1'
Das zweite Feld im Segment besteht aus den folgenden 5 Komponenten IFTMIN, D, 95B, UN und SUTC.
Die Zeichen für Segment-Ende, Feldtrenner und Komponententrenner können in einer EDIFACT-Datei definiert werden. Dazu dient das Segment UNA. Das Segment UNA ist ein Sonderfall. Es beschreibt die Zeichen, mit denen Segmente und Daten innerhalb der Segmente unterteilt bzw. maskiert werden. Dieses Segment ist optional, wird es weggelassen, gelten die Definitionen des Standards. Existiert das UNA-Segment, muss es immer am Anfang des Dokuments stehen.
Um die Größe der Dateien klein zu halten, wurden in EDIFACT folgende Komprimierungsmöglichkeiten festgelegt.
Leere Felder werden angegeben, indem einfach ein weiterer Feldtrenner eingefügt wird. Beispiel: GID+++00000005'
Das Segment besteht aus 4 Feldern, die Felder 2 und 3 sind leer, und werden übersprungen. Der gleiche Mechanismus wird auch bei Komponenten angewendet.
Leere Felder am Ende eines Segments werden angegeben, indem das Segment-Ende nach dem letzten, nicht leeren Zeichen, angegeben wird. Beispiel: GID+2'
Das Segment besteht eigentlich aus 4 Feldern, die Felder 3 und 4 sind aber leer. Das Segment-Ende nach dem zweiten Feld gibt an, dass alle weiteren Felder des Segmentes leer sind.
Anmerkungen zum EDIFACT-Parser
Der EDIFACT-Parser verfährt mit Segmenten ähnlich wie mit Zeilen in CSV- oder Feste-Länge-Dateien. Der Parser zerlegt die Datei in Segmente, indem er alles zwischen einer Segmentkennung und dem Segmentende als Zeile betrachtet. Diese Zeile kann, analog zu CSV- oder Feste-Länge-Dateien, als Meta-Spalte angesehen werden. Dabei kommt der EDIFACT-Parser mit Zeilenumbrüchen am Segmentende oder innerhalb des Segmentes zurecht.
Jedes Segment wird vom Parser einem Knoten auf oberster Ebene der Quellstruktur zugeordnet. Die Zuordnung der Segmentnamen zu den Knoten wird über die Satzarterkennung vorgenommen. Im Unterschied zum Feste-Länge- oder CSV-Parser, werden die Segmente nicht starr dem ersten Knoten zugeordnet. Der Parser merkt sich den zuletzt betretenen Knoten und nimmt keine Zuordnungen oberhalb dieses Knotens vor! Grund dafür ist die EDIFACT-Syntax. Die Segmente dürfen nicht in wahlfreier Reihenfolge angeordnet werden, die Reihenfolge ist festgelegt.
Die folgende Abbildung zeigt die Zuordnung von Segmenten zu Knoten der Quellstruktur.
(1) Das BGM-Segment wird dem Knoten über die Satzarterkennung zugeordnet.
(2) Die DTM-Segmente werden dem Knoten über die Satzarterkennung zugeordnet. Da zwei Segmente vorhanden sind, wird der Knoten zweimal wiederholt.
(3) Das DTM-Segment wird dem Knoten über die Satzarterkennung zugeordnet. Das Segment wird nicht (2) zugeordnet, da der Parser bereits den FTX-Knoten betreten hatte.
Die folgende Abbildung zeigt die Zuordnung von Segmenten zu Feldern der Quellstruktur.
(1) Das UNH-Segment wird dem Knoten über die Satzarterkennung zugeordnet.
(2) Das Segment-Feld in UNH wird dem Baum-Feld über die Reihenfolge zugeordnet. Der Wert im Beispiel für das Baum-Feld ist UNH.
(3) Das Segment-Feld in UNH wird dem Baum-Feld über die Reihenfolge zugeordnet. Der Wert im Beispiel für das Baum-Feld ist 67061107514198. Sind mehr Baum-Felder als Segment-Felder vorhanden, bleiben die letzten Baum-Felder leer.
Die folgende Abbildung zeigt die Zuordnung von Komponenten zu Feldern der Quellstruktur.
(1) Das DTM-Segment wird dem Knoten über die Satzarterkennung zugeordnet.
(2) Das Segment-Feld in DTM wird dem Baum-Feld über die Reihenfolge zugeordnet. Der Wert im Beispiel für das Baum-Feld ist DTM.
(3) Der Knoten in der Quellstruktur wird benötigt, da das zweite Feld im DTM-Segment aus mehreren Komponenten besteht. Eine Zuordnung über Satzarterkennung findet nicht statt. Der EDIFACT-Parser geht bei Knoten ohne eingetragene Satzarterkennung immer von einem Feld mit Komponenten aus!
(4) Die Komponente aus dem Segment-Feld wird dem Baum-Feld über die Reihenfolge zugeordnet. Der Wert im Beispiel ist 200.
(5) Die Komponente aus dem Segment-Feld wird dem Baum-Feld über die Reihenfolge zugeordnet. Sind mehr Baum-Felder als Komponenten vorhanden, bleiben die letzten Baum-Felder leer.
EDIFACT-Strukturen können Subsegmente enthalten. Das sind Segmente, die unterhalb von Segmenten angeordnet sind. Diese Subsegmente werden, analog zu normalen Segmenten, ebenfalls als Knoten abgebildet. Der Knoten des übergeordneten Segmentes muss in der Satzarterkennung alle Namen der Subsegmente enthalten, andernfalls kann ein Subsegment nicht dem Segment zugeordnet werden.
Die folgende Abbildung zeigt die Zuordnung von Subsegmenten zu Knoten und Feldern der Quellstruktur.
(1) Das SG1-Segment hat die Subsegmente LOC und DTM. Damit diese Subsegemente korrekt zugeordnet werden können, muss die Satzarterkennung in SG1 die Zeichenketten LOC und DTM enthalten.
(2) Das Subsegment LOC wird wie ein normales Segment über die Satzarterkennung LOC zugeordnet. Das erste Auftreten eines LOC Subsegmentes erzeugt das Segment SG1. Die LOC-Subsegmente werden wiederholt, bis ein DTM Subsegment auftritt. Alle diese Subsegmente werden dem gleichen Segment zugeordnet, bis nach einem DTM-Subsegment wieder ein LOC-Subsegment auftritt. Dieses Auftreten erzeugt ein neues SG1-Segment.
(3) Alle DTM-Subsegmente werden dem gleichen Segment zugeordnet, bis nach einem DTM-Subsegment wieder ein LOC-Subsegment auftritt. Dieses Auftreten erzeugt ein neues SG1-Segment.
(4) Nach dem Auftreten eines nachfolgenden Segments (FTX, DTM-2, ...) erzeugt ein neues LOC-Segment natürlich kein SG1-Segment mehr.