| EANCOM® | TEIL I | EANCOM & EDIFACT | 01.09.1997 |
2. EDIFACT
UN/EDIFACT: Regelungen der Vereinten Nationen für den Elektronischen Datenaustausch in Verwaltung, Handel und Transport. Sie enthalten eine Reihe international anerkannter Standards, Verzeichnisse und Richtlinien für den elektronischen Austausch strukturierter Daten im besonderen die des Handels von Gütern und Dienstleistungen zwischen unabhängigen Rechnerinformationssystemen.
Wenn die Regelungen im Rahmen der Vereinten Nationen empfohlen sind, werden sie von der UN/ECE/WP.4 (Vereinte Nationen/Europäische Wirtschaftskommission/Arbeitsgruppe 4) genehmigt, im UNTDID (United Nations Trade Data Interchange Directory) veröffentlicht und mit festgelegten Prozeduren gepflegt. UNTDID enthält:
Dieser Abschnitt ist eine Zusammenfassung des ISO-Dokuments 9735 "EDIFACT Application Level Syntax Rules", erstes Release vom 15.07.1988, geändert und neu erschienen am 01.11.1990 und Änderung 1 aus 1992.
Die EDIFACT-Syntaxregeln beschreiben die Standards zur Strukturierung von Daten zu Segmenten, Segmenten zu Nachrichten und Nachrichten zu einer Übertragungsdatei.
2.2.1 Struktur einer Übertragungsdatei
Eine Übertragungsdatei besteht aus:
Segmente, die mit "UN" beginnen, werden Service-Segmente genannt. Sie bilden den Umschlag oder die "Verpackung" der EDIFACT-Nachrichten.
Nutzdatensegmente beinhalten die eigentliche Information, in einem für jeden Nachrichtentyp spezifischen Format.
2.2.2 Struktur einer Nachricht
Jedes Segment hat seinen speziellen Platz in einer Sequenz von Segmenten innerhalb der Nachricht. Sie können in einem der drei folgenden Teile einer Nachricht vorkommen:
Die Folge der drei Nachrichtenteile kann mit diesem Beispiel verdeutlicht werden:
Der gleiche Segmenttyp kann in mehreren Teilen der Nachricht vorkommen, z.B. im Kopf- und Positionsteil und/oder auch mehrfach im selben Nachrichtenteil.
Einige Segmente können sich an ihrem bestimmten Platz in der Nachricht wiederholen. Die maximale Wiederholungshäufigkeit und der Status - Kann oder Muß - wird in der Nachrichtenstruktur vorgegeben.
Innerhalb einer Nachricht können sich Gruppen funktionell zusammenhängender Segmente wiederholen; diese Gruppen nennt man "Segmentgruppen". Die maximale Anzahl der Wiederholungen von Segmentgruppen an ihrem Platz innerhalb der Nachricht wird in der Nachrichtendefinition vorgegeben.
Eine Segmentgruppe kann in anderen Segmentgruppen enthalten sein, vorausgesetzt, die innere Segmentgruppe wird vor der äußeren beendet.
2.2.3 Segmentstruktur
Ein Segment besteht aus:
Datenelemente können mit fester oder variabler Länge definiert sein.
Datenelementgruppen enthalten zwei oder mehr einzelne Datenelemente.
Ein Datenelement kann durch ein anderes qualifiziert werden, d.h. es werden Code-Werte vergeben, die Daten eine bestimmte Bedeutung geben. Die Werte solcher "Qualifier" werden dem Codeverzeichnis entnommen.
2.2.4 Trennzeichen
In EANCOM haben vier Sonderzeichen (extrahiert aus UNOA) eine besondere Bedeutung und dienen als Standard-Trennzeichen (Default) für EANCOM:
| Apostroph | ' | = | Segment-Endezeichen |
| Pluszeichen | + | = | Segment-Bezeichner- und Datenelement-Trennzeichen |
| Doppelpunkt | : | = | Gruppendatenelement-Trennzeichen |
| Fragezeichen | ? | = | Freigabezeichen; wenn das Fragezeichen unmittelbar vor einem der Servicezeichen steht, erhält dieses Zeichen seine normale Bedeutung zurück. Z.B. 10?+10=20 bedeutet 10+10=20. Ein Fragezeichen wird durch ?? dargestellt. |
Einigen sich die Handelspartner auf die Anwendung der Zeichensätze B bis F (inklusive) und die Standard-Trennzeichen, muß das UNA-Segment angewendet werden, um explizit den Gebrauch der Standard-Trennzeichen anzuzeigen. Die Syntax-Versionsnummer im Datenelement 0002 des UNB-Segments sollte eine 3 enthalten.
Beispiel eines EDIFACT-Segments:
DTM+137:19940101:102'
| DTM | = | Bezeichner für das Segment "Datum/Uhrzeit/Zeitspanne"; |
| + | = | Trennzeichen; |
| 137 | = | Qualifier
zur Festlegung, daß es sich um Datum/Zeit des Dokuments/ der Nachricht handelt; |
| : | = | Trennzeichen
innerhalb einer Datenelementgruppe (Hier: Datumqualifier und Datum); |
| 19940101 | = | Datum; |
| : | = | Trennzeichen
innerhalb einer Datenelementgruppe (Hier: Datum und Qualifier für das Format des Datums); |
| 102 | = | Qualifier, der das Format des Datums festlegt (JJJJMMTT); |
| ' | = | Segment-Endezeichen. |
2.2.5 Komprimierung von Daten
Bei Datenelementen, die im Datenelementverzeichnis mit variabler Länge ohne sonstige Restriktionen angegeben sind, sollen nicht-signifikante Zeichen unterdrückt werden. Sofern die Zeichen nicht signifikant sind, werden vorangestellte Nullen und nachfolgende Leerzeichen weggelassen.
SB = Segment-Bezeichner; DE = Datenelement; GD = Gruppendatenelement.
| - | Auslassen von Segmenten. Kann-Segmente, die keine Daten enthalten, werden einschließlich ihrer Segment-Bezeichner ausgelassen. | |
| - | Auslassen von Datenelementen. Datenelemente werden anhand ihrer Position innerhalb des Segments, wie im Segment-Verzeichnis vorgegeben, identifiziert. Wenn ein Kann-Datenelement, welchem ein anderes Datenelement folgt, ausgelassen werden soll, wird seine Position von einem Trennzeichen markiert. | |
| Beispiel: | SB+DE+DE+DE+GD:GD:GD' komplettes
Segment inklusive aller Datenelemente
|
|
| - | Auslassen von Datenelementen durch Abschneiden. Kann-Datenelemente am Ende eines Segments können durch Verwendung des Segment-Endezeichens ausgelassen werden. | |
| Beispiel: | SB+DE+DE+DE+DE'
Original
inklusive aller Datenelemente
|
|
| - | Auslassen von Gruppendatenelementen.Kann-Gruppendatenelemente, denen andere GDs folgen, können bei Verwendung des Gruppendatenelement-Trennzeichens ausgelassen werden. | |
| Beispiel: | SB+DE++DE+GD:GD:GD'
Original inklusive
aller GD´s
|
|
| - | Auslassen von Gruppendatenelementen durch Abschneiden. Kann-Gruppendatenelemente am Ende einer Datenelementgruppe können unter Verwendung des Datenelement-Trennzeichens oder des Segment-Endezeichens abgeschnitten werden. | |
| Beispiel: | SB+DE++DE+GD:GD:GD'
Original
inklusive letztem GD
|
|
2.2.6 Darstellung numerischer Inhalte
| - | Dezimalzeichen.
Das vorgesehene Dezimalzeichen ist der Punkt (.). Der
Dezimalpunkt wird bei der Ermittlung der maximalen
Feldlänge eines Datenelements nicht mitgezählt. Bei der
Übertragung eines Dezimalzeichens soll ihm mindestens
ein Zeichen vorangehen und eines folgen. Zur Unterstützung von Entwicklern von Inhouse-Files und Datenaustauschpartnern, sollten die folgenden Längen als Richtlinie verwendet werden:
|
|||||||||||||||
| - | Tausender-Kennung. Außer dem Dezimalzeichen sind keine weiteren Gliederungszeichen zugelassen. (Erlaubt: 2500000; Nicht erlaubt: 2,500,000 oder 2.500.000 oder 2 500 000). | |||||||||||||||
| - | Vorzeichen.
Numerische Datenelement-Werte werden als positiv
angenommen. Das Konzept eines Abzuges ist negativ, es
wird jedoch als positiver Wert dargestellt, z.B. sind in
einer Lastschrift alle Werte positiv, die
Anwendungssoftware wird jedoch aufgrund des
Nachrichtennamens, codiert (DE 1001) alle Werte ins
Negative umwandeln. Zusätzlich weisen Kombinationen von
Datenelementen und Codewerten darauf hin, daß Werte als
negativ verstanden werden müssen, z. B.
Datenelement 5463 mit Codewert 'A', Abschlag, in einem
ALC-Segment der Rechnung. Falls ein Wert negativ angegeben werden soll, muß ihm unmittelbar ein Minuszeichen vorangestellt werden, z.B. -112. Das Minuszeichen wird bei der Ermittlung der maximalen Länge eines Datenelements nicht mitgezählt. |
2.2.7 Zeichensatz
Für den nachfolgend dargestellten Zeichensatz ist der 7-Bit-Code nach ISO 646 zu verwenden, wenn nicht der 8-Bit-Code nach ISO 6937, ISO 8859.1, ISO 8859.2 , ISO 8859.5 und ISO 8859.7 oder andere Codes speziell zwischen zwei Partnern für den Austausch vereinbart werden. Wenn ein anderer Zeichensatz verwendet wird, muß dies in der Datenaustauschvereinbarung der Partner explizit angeführt werden.
Folgender Zeichensatz, bekannt als Zeichensatz-Level A, wird den EANCOM-Anwendern für den internationalen Datenaustausch empfohlen:
| Großbuchstaben | A bis Z |
| Ziffern | 0 bis 9 |
| Leerzeichen | |
| Punkt | . |
| Komma | , |
| Bindestrich/Minus | - |
| runde Klammer links | ( |
| runde Klammer rechts | ) |
| Schrägstrich | / |
| Gleichheitszeichen | = |
| Ausrufungszeichen | ! |
| Anführungszeichen oben | " |
| Prozentzeichen | % |
| Ampersand | & |
| Stern | * |
| Semikolon | ; |
| Kleiner-Zeichen | < |
| Größer-Zeichen | > |
Bei Verwendung des Zeichensatzes Level A (UNOA) sind die Zeichen Apostroph ('), Pluszeichen (+), Doppelpunkt (:) und Fragezeichen (?) für spezielle Verwendungen reserviert (siehe Kapitel 2.2.4).
Zusätzlich zum Vorrat des Zeichensatzes A könnten EANCOM-Anwender Bedarf nach weiteren Zeichen haben. Diese sind in der International Reference Version (IRV) der ISO 646 enthalten.
Die EAN-International empfiehlt allen EANCOM-Anwendern, die
diese zusätzlichen Zeichen nutzen wollen, zuerst das Einverständnis ihrer Austauschpartner
einzuholen, um eine fehlerfreie Verarbeitung im Anwendungsprogramm des Empfängers sicherzustellen.
Folgende Zeichen sind in der IRV enthalten:
| Nummernzeichen | # |
| Commercial at | @ |
| Eckige Klammer links | [ |
| Backslash | \ |
| Eckige Klammer rechts | ] |
| Accent circumflex | ^ |
| Accent grave | ` |
| Geschweifte Klammer links | { |
| Vertikalstrich | | |
| Geschweifte Klammer rechts | } |
Die Identifikation des verwendeten Zeichensatzes erfolgt im Datenelement 0001 des UNB-Segments.
Die folgende Tabelle erklärt, welche Sprachen von welcher Version der ISO 8859 unterstützt werden:
ISO 8859 Version |
Sprache |
1 |
Dänisch, Deutsch, Englisch, Färöisch, Finnisch, Französisch, Irisch, Isländisch, Italienisch, Niederländisch, Norwegisch, Portugiesisch, Schwedisch, Spanisch |
2 |
Albanisch, Englisch, Polnisch, Rumänisch, Serbokoatisch, Slowakisch, Slowenisch, Tschechisch, Ungarisch |
5 |
Bulgarisch, English, Mazedonisch, Russisch, Serbokroatisch, Ukrainisch, Weißrussisch |
7 |
Griechisch |
2.3 Status, Version und Release eines Directories
Alle EANCOM '97-Nachrichtentypen basieren auf dem Entwurfsdirectory D.96A, freigegeben von den Vereinten Nationen im März 1996.
Dieses Directory enthält Verfahren zur Identifikation von Status, Release und Version des Directories. Das Datenelement 0052 wird zur Angabe des verwendeten Directory-Status ("D"raft = Entwurf) genutzt. Das EDIFACT-Directory-Release ist durch ein dreistelliges alphanumerisches Datenelement (0054) identifiziert, wobei die ersten zwei Zeichen die Directory-Ausgabenummer darstellen (die equivalent zu den letzten zwei Ziffern des Jahres, in dem das Directory-Set herausgegeben wurde, sind), gefolgt von einem einzelnen Alphazeichen für den Releasestand.
Jede EANCOM-Nachricht beinhaltet ihre eigene Versionsnummer, die in Datenelement 0057 im UNG- und UNH-Segment angegeben wird und eindeutig die Identifikation der verschiedenen Versionen von EANCOM-Nachrichten enthält. Sie hat folgende Struktur:
EANnnn
wobei: EAN die Organisation, die das Subset pflegt und
nnn die dreistellige Versionsnummer des EANCOM-Subsets angibt.
Die Versionsnummern für formal freigegebene EANCOM-Nachrichtentypen starten mit der Nummer "001" und werden bei jedem Folgerelease eines Nachrichtentyps jeweils um 1 erhöht.
Außer den Nachrichten-Versionsnummern 001 und höher gibt es in EANCOM auch die Version "000" oder Pre-Release. EANCOM-Nachrichtentypen der Version 000 haben die Entwicklungsphase komplett abgeschlossen und sind zu Testzwecken für potentielle Anwender verfügbar. EANCOM-Updates kommen durchschnittlich einmal im Jahr heraus. Es ist unmöglich, jeden neu entwickelten EANCOM-Nachrichtentyp jedem EANCOM-Anwender sofort zugänglich zu machen. Die Existenz von Nachrichtentypen der Version 000 teilt EAN International den Numerierungsorganisationen mit, die diese nur auf spezielle Anfragen hin als Kopie zur Verfügung gestellt bekommen. Alle Nachrichtentypen der Version 000 werden automatisch in das nächste EANCOM-Update aufgenommen, wenn sie formal Teil des Standards werden, d. h. sie werden zur Version 001.
2.5 Dokumentationskonventionen
2.5.1 Format und Darstellung von Datenelementen
Folgende Konventionen gelten für die vorliegende Dokumentation:
| a n an a3 n3 an3 a..3 n..3 an..3 |
alphabetische
Zeichen numerische Zeichen alphanumerische Zeichen 3 alphabetische Zeichen fester Länge 3 numerische Zeichen fester Länge 3 alphanumerische Zeichen fester Länge bis zu 3 alphabetische Zeichen bis zu 3 numerische Zeichen bis zu 3 alphanumerische Zeichen |
2.5.2 Statusindikatoren
(M)uß-Datenelemente oder Datenelementgruppen aus EDIFACT-Segmenten behalten ihren Status in EANCOM.
Zusätzlich gibt es fünf Statustypen mit einem (K)ann-EDIFACT-Status für einfache Datenelemente, Gruppendatenelementen und Datenelementgruppen. Diese sind anschließend angeführt und können bei Bedarf in der Erklärungsspalte angegeben sein.
| - ERFORDERLICH | R | Gibt an, daß der Gebrauch dieses Elements erforderlich ist und es verwendet werden muß. |
| - EMPFOHLEN | A | Gibt an, daß der Gebrauch dieses Elements empfohlen wird. |
| - ABHÄNGIG | D | Gibt an, daß der Gebrauch dieses Elements von bestimmten Bedingungen abhängt, die in entsprechenden Hinweisen beschrieben sind. |
| - OPTIONAL | O | Gibt an, daß der Gebrauch dieses Elements optional ist und die Verwendung dem Ermessen des Anwenders unterliegt. |
| - Nicht benötigt | N | Gibt an, daß dieses Element nicht benötigt wird und ausgelassen werden sollte. |
Codewerte haben in EANCOM zwei Statusindikatoren:
| - | Beschränkt (*). Wird ein Datenelement in der vierten Spalte der Segmentbeschreibungen mit einem Stern (*) gekennzeichnet, sind ausschließlich die in der fünften Spalte angegebenen Codewerte für den Gebrauch in genau diesem Datenelement innerhalb dieses Segments und innerhalb dieses Nachrichtentyps verfügbar. |
| - | Offen. Alle Datenelemente, bei denen eine codierte Darstellung von Daten möglich ist und keine beschränkte Menge von Codes angegeben wird, sind offen. Die möglichen Codes sind im Datenelemente- und Codeverzeichnis angeführt (Teil III dieses Handbuchs). Codewerte können als Beispiele angegeben sein oder es wird eine Beschreibung des Formats oder Typs des zu verwendenden Codes angeführt. |
2.5.3 Temporäre Codes
Einige Codes der Codeliste von EANCOM '97 werden durch Angabe von "(EAN-Code)" oder anderen temporären Codes, wie z. B. "(EAN-Code-Buch)" oder "(SWIFT-Code)", direkt hinter dem Codewert als EAN-Codewert identifiziert. Diese Codes sind Werte, die in der UN/EDIFACT-Codeliste nicht existieren. In vielen Fällen wird dem Datenelement, das den temporären Codewert beinhaltet, das Datenelement 3055 in einer Datenelementgruppe folgen. Dieses Datenelement erlaubt die explizite Identifikation von temporären Codes.
Wenn EAN-Codes in codierten EDIFACT-Datenelementen benutzt werden, die sich in Datenelementgruppen befinden, die auch die Datenelemente 1131 und 3055 enthalten, muß der Codewert "9 = EAN" im Datenelement 3055 benutzt werden, um verwechslungsfrei klarzumachen, daß temporäre Codes benutzt wurden. Beispiel: C273 in IMD, C524 in HAN, usw.
Alle temporären Codes werden UN/EDIFACT zur offiziellen Freigabe vorgelegt. Man muß jedoch beachten, daß die von EDIFACT akzeptierten Codewerte normalerweise nicht die gleichen sind wie die temporären Codes. Daher müssen die formalen EDIFACT-Codes nachgepflegt werden.
2.6 Nachrichtendiagramme und Nachrichtenstruktur
In jedem EANCOM-Nachrichtentyp werden zwei Diagramme präsentiert, die Struktur und Sequenz der Nachricht erklären. Diese Diagramme werden Nachrichtenstruktur- und Nachrichten-(Branching-)diagramm genannt.
Die Nachrichtenstruktur ist eine sequentielle Auflistung, die den Nachrichtentyp in der Reihenfolge anzeigt, in der die Daten für die Übertragung formatiert werden müssen. Jede Nachrichtenstruktur ist in drei Teile gegliedert: Kopf-, Positions- und Summenteil. Es folgt ein Beispiel einer Nachrichtenstruktur:
Die Nachrichtenstruktur sollte immer von oben nach unten und von links nach rechts gelesen werden. (Beachten Sie bitte, daß es sich nur um eine Beispielnachricht handelt, die keinen Bezug zu realen EANCOM-Nachrichten hat.)
Das Nachrichtendiagramm ist eine illustrierte Darstellung, die die logische Abfolge und Abhängigkeit innerhalb einer Nachricht wiedergibt.
Nachrichtendiagramme sollten, beginnend beim UNH-Segment, von links nach rechts und von oben nach unten gelesen werden. Die Linien innerhalb des Nachrichtendiagramms sollten als Führungslinien betrachtet werden, denen man folgen muß, wenn man die Nachricht abarbeitet.
2.7 Datenaustauschstruktur und Servicesegmente
Die Struktur einer EDIFACT-Übertragungsdatei wird in verschiedene Gruppenebenen eingeteilt. Die Service-Segmente bilden die Klammern um die Gruppen.
Das erste mögliche Service-Segment einer Übertragungsdatei ist das UNA-Segment, welches zur Anzeige der Trennzeichen benutzt wird, die bei der Übertragung verwendet werden.
Das zweite Service-Segment, "UNB", zeigt den Beginn der Übertragung an.
Das nächste Service-Segment, "UNG", steht am Anfang einer Gruppe von Nachrichten desselben Typs, z. B. Rechnungen.
Das letzte Service-Segment, "UNH", kennzeichnet den Beginn einer Nachricht.
Zu jedem Anfangs-Service-Segment gibt es ein Ende-Service-Segment (Bitte beachten, daß UNA kein Anfangs-Segment ist).
Ankündigung der Service-Segmente
UNA
Klammer der Übertragungsdatei: UNB .... UNZ
Klammer der Gruppe: UNG .... UNE
Klammer der Nachricht: UNH .... UNT
Die Austauschstruktur kann wie folgt dargestellt werden:
Das Segment UNA ist abhängig vom benutzten Zeichensatz. Wenn der EANCOM-Standardzeichensatz A benutzt wird, ist das UNA-Segment nicht notwendig.
Die Segmente UNB..UNZ und UNH..UNT sind Muß-Angaben.
Die Segmente UNG..UNE sind Kann-Angaben. In EANCOM können die Segmente UNG..UNE immer dann als Klammer um eine Nachrichtengruppe benutzt werden, wenn unterschiedliche Nachrichtentypen in einer Übertragungsdatei enthalten sind. Wird nur ein Nachrichtentyp versandt, können UNG..UNE entfallen.
Werden UNG..UNE benutzt, muß beachtet werden, daß es nicht möglich ist, mit der EANCOM CONTRL-Nachricht einen Syntax-Report zu einer funktionellen Gruppe zu erstellen.
Die eigentliche Nachricht wird in Kopf-, Positions-, und Summenteil gegliedert. In Nachrichten, in denen Zweideutigkeiten zwischen den Teilen auftreten könnten, wird das Segment UNS zur Trennung verwendet.
Das Layout der Service-Segmente UNA, UNB..UNZ und UNG..UNE wird in diesem Kapitel beschrieben.
Die Segmente UNH, UNS und UNT sind je Nachrichtentyp unterschiedlich und werden in dem Teil dieses Handbuchs erläutert, wo die Nachrichtentypen beschrieben sind.
Beispiel einer Übertragungsdatei:
Die Übertragungsdatei enthält zwei Typen von Nachrichten: drei Liefermeldungen und zwei Rechnungen. Die Datei wird am 02. Januar 1997 von einem Unternehmen, das sich durch die ILN 5412345678908 identifiziert, an ein Unternehmen mit der ILN 8798765432106 geschickt.
UNA:+.?'
UNB+UNOA:3+5412345678908:14+8798765432106:14+970102:1000+12345555+++++EANCOMREF522'
....
UNH+66025+DESADV:D:96A:UN:EAN005'
.....
.....
UNT+35+66025'
UNH+66420+DESADV:D:96A:UN:EAN005'
.....
.....
UNT+26+66420'
UNH+1588+INVOIC:D:96A:UN:EAN008'
....
....
UNT+46+1588'
UNH+2063+INVOIC:D:96A:UN:EAN008'
....
....
UNT+87+2063'
UNH+67020+DESADV:D:96A:UN:EAN005'
.....
.....
UNT+102+67020'
....
UNZ+5+12345555'
© Copyright CCG, Köln 1997
