5.1 Definition von UN/EDIFACT

UN/EDIFACT:
Regelungen der Vereinten Nationen für den Elektronischen Datenaustausch in Verwaltung, Handel und Transport
(United Nation's Directories for Electronic Data Interchange for Administration, Commerce and Transport)

Diese Regelungen 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/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business) genehmigt, im UNTDID (United Nations Trade Data Interchange Directory) veröffentlicht und innerhalb festgelegter Vorgehensweisen gepflegt.

UNTDID enthält:

- EDIFACT - Syntax-Regeln auf Anwendungsebene (Syntax-Versionsnummer: 4)
- Nachrichtenentwicklungsrichtlinien
- Syntax-Implementierungsrichtlinien
- EDIFACT-Verzeichnis der Datenelemente, EDED
- EDIFACT-Verzeichnis der Datenelementgruppen, EDCD
- EDIFACT-Verzeichnis der Standardsegmente, EDSD
- EDIFACT-Verzeichnis der Standardnachrichten, EDMD
- EDIFACT-Codeliste, EDCL
- Einheitliche Handhabungsregeln für den Austausch von Handelsdaten durch Teletransmission (UNCID)
- Entsprechende erläuternde Unterlagen

Aktuelle Informationen sind unter den nachfolgenden Link abrufbar:

5.2 Überblick über die UN/EDIFACT-Syntax 3+4

Dieser Abschnitt ist eine Zusammenfassung des Dokuments ISO 9735 "EDIFACT Syntax-Regeln auf Anwendungsebene (Syntax-Versionsnummern: 3+4)".

Die EDIFACT-Syntaxregeln beschreiben die Regeln zur Strukturierung von Daten zu Segmenten, Segmenten zu Nachrichten und Nachrichten zu einer Übertragungsdatei.

5.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 UN/EDIFACT-Nachrichten.

Nutzdatensegmente beinhalten die eigentliche Information in einem für jeden Nachrichtentyp spezifischen Format.

5.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:

Kopf-Teil

Ein Segment in diesem Abschnitt bezieht sich auf die ganze Nachricht.

Positions-Teil

Ein Segment in diesem Teil bezieht sich nur auf die Positionsinformationen.

Summen-Teil

In diesem Teil gibt es nur Segmente, die Summen- oder Kontrollwerte enthalten, z. B. Rechnungsgesamtbetrag, Anzahl der Bestellpositionen usw.

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 Muss - 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.

5.2.3 Segmentstruktur

Ein Segment besteht aus:

- einem Segment-Bezeichner zur Identifikation des Segmenttyps
- Datenelement-Trennzeichen
- einfachen Datenelementen und/oder Datenelementgruppen
- einem Segment-Endezeichen

Datenelemente können mit fester oder variabler Länge definiert sein.

Datenelementgruppen enthalten zwei oder mehr einzelne Gruppendatenelemente.

Gruppendatenelemente sind einfache Datenelemente, die in Datenelementgruppen genutzt werden.

Beispiel für eine Datenelementgruppe:

Die Datumsqualifizierer: Funktion und Wert sind die Komponenten der Datenelemente.

Ein Datenelement kann durch ein anderes qualifiziert werden, d. h. es werden Codewerte vergeben, die Daten eine bestimmte Bedeutung geben.

Die Werte solcher "Qualifier" werden dem Codeverzeichnis entnommen.

Mehrfaches Auftreten von eigenständigen einfachen oder zusammengesetzten Daten.

Nur Syntax 4:

Innerhalb der Syntax 4 ist es auch möglich, Datenelemente oder Datenelementgruppen entsprechend den in der Norm angegebenen Wiederholungsmöglichkeiten zu wiederholen. Das Sternchen ( * ) wird als Wiederholungstrennzeichen verwendet.

Dieses Merkmal wird nur in der KEYMAN-Nachricht (USA, S503) verwendet. Dieses Merkmal wird NICHT in anderen Nachrichten oder Segmenten innerhalb der EANCOM® 2002-Syntax 4 verwendet.

5.2.4 Trennzeichen

In EANCOM® haben vier Sonderzeichen (extrahiert aus UNOA) eine besondere Bedeutung und dienen als Standard-Trennzeichen (Default) für EANCOM®:

In EANCOM® 2002, Syntax 4, kann das UNA-Segment verwendet werden.

Wenn Handelspartner sich einigen, einen der Zeichensätze von B bis F (incl.) und die Standardtrennzeichen aus UNOA zu nutzen, muss das UNA-Segment bereit gestellt werden, um die Standardwerte explizit zu bestätigen.

Beispiel anhand eines EDIFACT-Segmentes:

5.2.5 Komprimierung von Daten

Bei Datenelementen, die im Datenelementverzeichnis mit variabler Länge ohne sonstige Restriktionen angegeben sind, sollen nicht-signifikante Zeichen (d. h. führende Nullen oder nachfolgende Leerzeichen) unterdrückt werden.

Verwendete Abkürzungen:

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.

- Auslassen von Datenelementen durch Abschneiden

Kann-Datenelemente am Ende eines Segments können durch Verwendung des Segment-Endezeichens ausgelassen werden.

- Auslassen von Gruppendatenelementen

Kann-Gruppendatenelemente, denen andere GDs folgen, können bei Verwendung des Gruppendatenelement-Trennzeichens ausgelassen werden.

- Auslassen von Gruppendatenelementen durch Abschneiden

Kann-Gruppendatenelemente am Ende einer Datenelementgruppe können unter Verwendung des Datenelement-Trennzeichens oder des Segment-Endezeichens abgeschnitten werden.

- Auslassen von Gruppendatenelementen

Die Position des Auftretens eines sich wiederholenden Datenelements kann in einigen Fällen von Bedeutung sein (z. B. bei der Übertragung von Array-Daten). Wird in einem solchen Fall das Auftreten eines sich wiederholenden Datenelements ausgelassen und folgt darauf ein weiteres Auftreten desselben sich wiederholenden Datenelements, so wird seine Position durch Beibehaltung des normalerweise folgenden Wiederholungsseparators angegeben.

- Auslassen von Gruppendatenelementen durch Abschneiden

Kann-Gruppendatenelemente am Ende einer Datenelementgruppe können unter Verwendung des Datenelement-Trennzeichens oder des Segment-Endezeichens abgeschnitten werden.

5.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. Obwohl ein Abzug vom Begriff her negativ ist, wird dieser als positiver Wert dargestellt, z. B. sind in einer Gutschrift alle Werte positiv. Die Anwendungssoftware wird jedoch aufgrund des codierten Nachrichtennamens (DE 1001) alle Werte ins Negative umwandeln. Zusätzlich weisen Kombinationen von Datenelementen und Codewerten darauf hin, dass 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, muss ihm unmittelbar ein Minuszeichen vorangestellt werden, z. B. -112. Das Minuszeichen wird bei der Ermittlung der maximalen Länge eines Datenelements nicht mitgezählt.

Beispiel 1 (INVOIC)

Beispiel 2 (INVOIC)

Es wird empfohlen, je eine Nachricht für eine Handelsrechnung und eine Nachricht für die Gutschrift zu erstellen. Da dies nicht immer möglich ist (z. B. bei einer Rechnung für Getränke mit einem negativen Pfandsaldo im Positionsteil), kann das Minuszeichen im DE 6060 des QTY-Segmentes und im DE 5004 des MOA-Segmentes benutzt werden.

Diese Regelung ist gültig für Belastungspositionen in Gutschriften und für Gutschriftspositionen in Rechnungen bzw. Lastschriften.

Wenn Zu- oder Abschläge rückwärts kalkuliert werden (Gutschrift zu einer vorher gesendeten Rechnung), wird der Codewert im DE 5463 des ALC-Segmentes nicht geändert.

5.2.7 Zeichensatz und Syntax-Bezeichner (Syntax 3 und Syntax 4)

Unterstützte Zeichensätze

In der Syntax-Version 3 werden die Zeichensätze A, B, C, D, E und F unterstützt.

In der Syntax-Version 4 werden die Zeichensätze A, B, C, D, E, F, G, H, I, J, K, X und Y unterstützt.

Ebenso unterstützt wird die Code Extensions Technik der ISO 2022 (mit bestimmten Restriktionen des Gebrauchs in einer Übertragungsdatei), und teilweise der Gebrauch der Technik aus ISO/IEC 10646-1.

In EANCOM® wird die Verwendung des Zeichensatzes A empfohlen.

Jedem Anwender, der einen anderen Zeichensatz als A verwenden will wird empfohlen, zuerst mit dem Partner eine entsprechende Vereinbarung zu schließen, um die korrekte Verarbeitung der Daten bei der empfangenden Applikation sicherzustellen.

Zeichensatz-Level A

Der Zeichensatz Level A (ISO 646 7-bit Code, mit Ausnahme der Kleinbuchstaben und bestimmter grafischer Zeichen) enthält die folgenden Zeichen:

Zeichensatz-Level B

Der Zeichensatz Level B (ISO 646 7-bit Code, mit Ausnahme bestimmter grafischer Zeichen) enthält die gleichen Zeichen wie Level A und zusätzlich die Kleinbuchstaben "a" bis "z".

Zeichensätze Level C bis F (nur Syntax 3)

Die Zeichensätze Level C bis F (ISO 8859 - 1,2,5,7 8-bit einzelbytecodierte Schriftzeichen¬sätze) decken die lateinischen Alphabete 1 und 2 sowie das kyrillische und griechische Alphabet ab.

Zeichensätze Level C bis K (nur Syntax 4)

Die Zeichensätze Level C bis K (ISO 8859 - 1,2,5,7,3,4,6,8,9 8-bit single byte coded graphic character sets) umfassen das Lateinische 1 - 5, Kyrillische, Arabische, Griechische und Hebräische Alphabet.

Für beide Snytaxen ist es wichtig darauf hinzuweisen, dass EANCOM®-Anwender oft zusätzlich zum empfohlenen Zeichensatz A die folgenden Zeichen aus der ISO 8859-1 benötigen:

Zeichensatz-Level X  (nur Syntax 4)

Zeichensatz, der aus der Anwendung der Extensions Technik resultiert, wie definiert in ISO 2022, nutzt die „escape sequence technique“ und entspricht ISO 2375.

Weitere Details siehe” ISO/ICE International Register of Coded Character Sets to be used with Escape Sequences”.

Zeichensatz-Level Y (nur Syntax 4)

Zeichensatz aus ISO 10646 – 1 8-bit-Zeichen ohne die Anwendung der Extensions Technik. 

Weitere Details in ISO 10646 –1.

Syntax-Bezeichner, Zeichensätze und unterstützte Sprachen

Die folgende Tabelle enthält die Codewerte für den Syntaxbezeichner und erklärt, welche Sprachen mit welchem Teil der ISO 8859 abgedeckt werden.

Bitte beachten Sie, dass das letzte Zeichen des Syntax-Bezeichners (Datenelement 0001) den benutzten Zeichensatz angibt.

- Syntax 3

- Syntax 4

5.3 Status, Version und Release eines Directories

Alle EANCOM® 2002-Nachrichtentypen basieren auf dem UN/EDIFACT-Verzeichnis (Directory) D.01B, das in 2001 von UN/CEFACT veröffentlicht wurde. 

Alle Nachrichtentypen in diesem Verzeichnis sind als Standard-Nachrichten der Vereinten Nation (United Nations Standard Messages (UNSM)) freigegeben.

5.4 EANCOM®-Nachrichtenversion

Jede EANCOM®-Nachricht beinhaltet ihre eigene Versionsnummer, die es erlaubt, die verschiedenen Versionen derselben EANCOM®-Nachricht eindeutig zu identifizieren. Die EANCOM®-Versionsnummer wird im DE 0057 des UNG- und UNH-Segmentes angegeben.

Sie ist folgendermaßen strukturiert:

EANnnn

wobei:

EAN = die Organisation ist, die das Subset pflegt (EAN ist der frühere Name von GS1) 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 jeder Folgeversion eines Nachrichtentyps jeweils um 1 erhöht.

5.5 Dokumentationskonventionen

5.5.1 Format und Darstellung von Datenelementen

Folgende Konventionen gelten für die vorliegende Dokumentation:

Art des Zeichens:

a                    alphabetische Zeichen
n                    numerische Zeichen
an                  alphanumerische Zeichen

Feldlänge:

Fest                Alle Stellen müssen gefüllt werden.
Variabel          Die Stellen können bis zu einem festgelegten Maximum genutzt werden.

Beispiele:

a3                   3 alphabetische Zeichen fester Länge
n3                   3 numerische Zeichen fester Länge
an3                 3 alphanumerische Zeichen fester Länge
a..3                 bis zu 3 alphabetische Zeichen
n..3                 bis zu 3 numerische Zeichen
an..3               bis zu 3 alphanumerische Zeichen

5.5.2 Indikatoren

Segmentlayout

Dieses Kapitel beschreibt den Aufbau der Segmentbeschreibung in EANCOM®-Nachrichten. Die Segmentbeschreibungen des EDIFACT-Originals werden angegeben. Relevante Kommentare zum EANCOM®-Subset werden ebenfalls angegeben.

Die Segmente werden in der gleichen Reihenfolge aufgelistet, in der sie auch in der Nachricht erscheinen. Jedem Segmentbezeichner bzw. jeder Segmentgruppe folgt ein (K)ann/(M)uss-Indikator, die maximale Anzahl der Wiederholmöglichkeiten und eine Segmentbeschreibung.

Von links nach rechts enthält die erste Spalte die Datenelementbezeichner und Beschreibungen, gefolgt von einer zweiten Spalte mit Angabe des EDIFACT-Status (Kann oder Muss), dem Datenformat sowie der Länge des Datenelements. Diese ersten Informationen bilden die Original-EDIFACT-Beschreibung ab.

Der EDIFACT-Beschreibung folgen in der dritten, vierten und fünften Spalte spezifische EANCOM®-Informationen. In der dritten Spalte ist ein Statusindikator für die Benutzung von (K)ann-EDIFACT-Datenelementen enthalten (siehe nachfolgend), in der vierten Spalte eine Kennzeichnung für restriktive Codewerte (siehe nachfolgend) und in der fünften Spalte Bemerkungen und verwendete Codewerte für spezielle Datenelemente der Nachricht.

Statusindikatoren

(M)uss

(M)uss-Datenelemente oder Datenelementgruppen aus EDIFACT-Segmenten behalten ihren Status in EANCOM®.

(K)ann

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.

[R] - ERFORDERLICH

R - Gibt an, daß der Gebrauch dieses Elements erforderlich ist und es verwendet werden muss.

[A] - EMPFOHLEN

A - Gibt an, daß der Gebrauch dieses Elements empfohlen wird.

[D] - ABHÄNGIG

D - Gibt an, daß der Gebrauch dieses Elements von bestimmten Bedingungen abhängt, die in entsprechenden Hinweisen beschrieben sind.

[O] - OPTIONAL

O - Gibt an, daß der Gebrauch dieses Elements optional ist und die Verwendung dem Ermessen des Anwenders unterliegt.

[N] - NICHT BENUTZT

N - Gibt an, daß dieses Element nicht benötigt wird und ausgelassen werden muss.

Wenn eine Datenelementgruppe mit N, NICHT BENUTZT, gekennzeichnet ist, gilt die Angabe für alle enthaltenen Datenelemente. Die einzelnen Datenelemente sind dann nicht mit einer separaten Kennzeichnung versehen.

Angabe von Restriktionen bei Datenelementen

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 (kein Stern in der vierten Spalte). Die möglichen Codes sind im Datenelemente- und Codeverzeichnis (Teil 3 dieses Handbuchs) angeführt. Codewerte können als Beispiele angegeben sein oder es wird eine Beschreibung des Formats oder Typs des zu verwendenden Codes angeführt.

In der Segmentbeschreibung werden unterschiedliche Farben für die Codewerte verwendet. Beschränkt verwendbare Codes sind rot und offene sind blau.

5.6 Nachrichtenstruktur und Nachrichtendiagramme

In jedem EANCOM® Nachrichtentyp werden zwei Diagramme präsentiert, die die Struktur und die Sequenz der Nachricht erklären. Diese Diagramme werden Nachrichtenstruktur- und Nachrichten-(Branching-)diagramme genannt.

Die Nachrichtenstruktur ist eine sequenzielle 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, dass es sich hier nur um eine Beispielnachricht handelt, die keinen Bezug zu einer realen EANCOM®-Nachricht 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 muss, wenn man die Nachricht abarbeitet.

5.7 Struktur der Übertragungsdatei 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 (service characters) 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, dass 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:

Nur Syntax 3:

Der Status des UNA-Segmentes hängt vom verwendeten Zeichensatz und den verwendeten Trennzeichen ab. Wenn Zeichensatz Level A und die Standardtrennzeichen verwendet werden, ist die Nutzung des UNA-Segmentes in EANCOM® nicht notwendig. Wenn aber die Partner die Verwendung eines der Zeichensätze Level B bis F vereinbaren und die Standardtrennzeichen benutzen, muss das UNA-Segment angegeben werden.

Die Segmente UNB..UNZ und UNH..UNT sind Muss-Angaben.

Die Segmente UNG..UNE sind Kann-Angaben. Innerhalb von EANCOM® sollten die Segmente UNG..UNE nicht zur Gruppierung unterschiedlicher Nachrichtentypen in einer Übertragungsdatei verwendet werden, weil es nicht für eine gute Praxis gehalten wird. Jedoch können sie von Organisationen benutzt werden, um eigene, identifizierbare Umschläge um Anwendungsebenen zu erstellen, die von der Ursprungsabteilung bis zur Abteilung des Empfängers adressiert werden können, d.h. mehrere Rechnungssteller in einer Übertragungsdatei mit Rechnungen zu gruppieren.

Werden UNG..UNE benutzt, muss beachtet werden, dass es nicht möglich ist, mit der CONTRL-Nachricht einen Syntax-Report zu einer funktionellen Gruppe zu erstellen.

Die eigentliche Nachricht wird in Kopf-, Positions-, und Summenteil gegliedert. In den 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 nachfolgend beschrieben. Das Abschnittskontrollsegment (UNS) wird hier nicht gezeigt. Seine Verwendung ist in den EANCOM®-Nachrichten definiert, in denen das Segment tatsächlich verwendet wird.

Nur Syntax 4:

In der EANCOM®-Syntax 4-Version ist die Verwendung des UNA-Segments nicht erforderlich.
Das UNA-Segment ist abhängig von dem verwendeten Zeichensatz. Wenn der EANCOM®-Standardzeichensatz A verwendet wird, ist das UNA-Segment nicht erforderlich.

Die Segmente UNB..UNZ und UNH..UNT sind Muss-Angaben.

Die Segmente UNG..UNE sind Kann-Angaben. Innerhalb von EANCOM® sollten die Segmente UNG..UNE nicht zur Gruppierung unterschiedlicher Nachrichtentypen in einer Übertragungsdatei verwendet werden, weil es nicht für eine gute Praxis gehalten wird. Jedoch können sie von Organisationen benutzt werden, um eigene, identifizierbare Umschläge um Anwendungsebenen zu erstellen, die von der Ursprungsabteilung bis zur Abteilung des Empfängers adressiert werden können, d.h. mehrere Rechnungssteller in einer Übertragungsdatei mit Rechnungen zu gruppieren.

Werden UNG..UNE benutzt, muss beachtet werden, dass es nicht möglich ist, mit der CONTRL-Nachricht einen Syntax-Report zu einer funktionellen Gruppe zu erstellen.

Die eigentliche Nachricht wird in Kopf-, Positions-, und Summenteil gegliedert. In den 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 nachfolgend beschrieben. Das Abschnittskontrollsegment (UNS), der Antikollisionssegmentgruppen-Header (UGH) und der Antikollisionssegmentgruppen-Trailer (UGT) werden hier nicht gezeigt. Ihre Verwendung ist in den EANCOM®-Nachrichten definiert, in denen die Segmente tatsächlich verwendet werden.

Segment Layout - UNA-Segment

Dokumentation zum UNA-Segment:

Dieses Segment wird benutzt, um den Empfänger der Übertragungsdatei darüber zu informieren, dass andere Trennzeichen als die Standardtrennzeichen benutzt werden.

Bei Verwendung der Standard-Trennzeichen muss das UNA-Segment nicht gesendet werden. Wenn es gesendet wird, muss es dem UNB-Segment unmittelbar vorangehen und die vier Trennzeichen (Positionen UNA1, UNA2, UNA4 und UNA6) enthalten, die vom Sender der Übertragungsdatei ausgewählt wurden.

Unabhängig davon, ob ein oder mehrere Trennzeichen geändert wurden, müssen alle Datenelemente dieses Segments gefüllt werden (d. h. wenn Standardwerte zusammen mit anwenderdefinierten Werten verwendet werden, müssen sowohl Standard- als auch anwenderdefinierte Werte angegeben werden).

Die Angabe der Trennzeichen im UNA-Segment erfolgt ohne Verwendung von Trennzeichen zwischen den Datenelementen.

Die Anwendung des UNA-Segments ist erforderlich, wenn andere Zeichensätze als Zeichensatz A verwendet werden.

Beispiel:
UNA:+.?*'

Segment Layout - UNB-Segment

Dokumentation zum UNB-Segment:

Dieses Segment dient sowohl als Umschlag für die Übertragungsdatei als auch zur Identifikation des Empfängers und des Senders der Übertragungsdatei. Das Prinzip des UNB-Segments ist gleich dem eines physischen Umschlags, der einen oder mehrere Briefe oder Dokumente umschließt und angibt, an wen er gesendet werden soll bzw. von wem der Umschlag gekommen ist.

DE 0001: Der empfohlene (Standard-) Zeichensatz zur Anwendung von EANCOM® im internationalen Datenaustausch ist der Zeichensatz A (UNOA). Sollten Anwender andere Zeichensätze als Zeichensatz A verwenden wollen, sollte eine Vereinbarung diesbezüglich vor Beginn des Datenaustausches auf bilateraler Basis geschlossen werden.

DE 0004 und DE 0010: In EANCOM® wird die Verwendung der globalen Lokationsnummer / Global Location Number (GLN) zur Identifikation des Senders und Empfängers der Übertragungsdatei empfohlen.

DE 0008: Die Adresse für Rückleitung stellt der Sender bereit, um den Empfänger der Übertragungsdatei über die Adresse im System des Senders zu informieren, an die die Antwortdateien gesendet werden müssen. Es wird empfohlen, die GLN für diesen Zweck zu verwenden.

DE 0014: Die Weiterleitungsadresse, die ursprünglich vom Empfänger der Übertragungsdatei bereitgestellt wurde, wird vom Sender benutzt, um dem Empfänger die Adresse im System des Empfängers mitzuteilen, an die die Übertragungsdatei geleitet werden soll. Es wird empfohlen, die GLN für diesen Zweck zu verwenden.

DEG S004: Datums- und Zeitangaben in dieser Datenelementgruppe entsprechen dem Datum und der Uhrzeit, an dem der Sender die Übertragungsdatei erstellt hat. Diese Datums- und Zeitangaben müssen nicht notwendigerweise mit den Datums- und Zeitangaben der enthaltenen Nachrichten übereinstimmen.

DE 0020: Die Datenaustauschreferenznummer wird vom Sender der Übertragungsdatei generiert und dient der eindeutigen Identifikation jeder Übertragungsdatei. Sollte der Sender der Übertragungsdatei Datenaustauschreferenzen wiederverwenden wollen, wird empfohlen, jede Nummer für mindestens drei Monate nicht zu verwenden, bevor sie wieder benutzt wird. Zur Sicherstellung der Eindeutigkeit sollte die Datenaustauschreferenz immer mit der Absenderidentifikation (DE 0004) verbunden werden.

DEG S005: Die Anwendung eines Passwortes muss von den Datenaustauschpartnern vorab bilateral vereinbart werden.

DE 0026: Dieses Datenelement wird zur Identifikation des Anwendungsprogramms im System des Empfängers benutzt, an das die Übertragungsdatei geleitet wird. Dieses Datenelement darf nur benutzt werden, wenn die Übertragungsdatei nur einen Nachrichtentyp enthält (z. B. nur Rechnungen). Die verwendete Referenz in diesem Datenelement wird vom Sender der Übertragungsdatei festgelegt.

DE 0031: Dieses Datenelement wird benutzt, um anzugeben, ob eine Bestätigung gefordert wird. Zur Bestätigung des Erhalts einer Übertragungsdatei sollten die EANCOM®-Nachrichten APERAK oder CONTRL verwendet werden. Die EANCOM®-Nachricht CONTRL kann zusätzlich benutzt werden, um anzugeben, dass eine Übertragungsdatei wegen Syntaxfehlern zurückgewiesen wurde.

DE 0032: Dieses Datenelement wird zur Identifikation aller zugrunde liegender Vereinbarungen benutzt, die den Datenaustausch kontrollieren. In EANCOM® muss die Identifikation solcher Vereinbarungen mit den Buchstaben 'EANCOM' beginnen, und die verbleibenden Zeichen innerhalb des Datenelements werden entsprechend der bilateralen Vereinbarung gefüllt.

Beispiel:
UNB+UNOC:4+5412345678908:14+8798765432106:14+20020102:1000+12345555+++++EANCOMREF 52'

Segment Layout - UNG-Segment

Dokumentation zum UNG-Segment:

Innerhalb von EANCOM® wird die Anwendung der Segmente UNG..UNE nicht empfohlen, weil dem Gruppieren von Nachrichten desselben Typs nicht so hohe Bedeutung beigemessen wird, wie dem Zusammenfassen mehrerer Nachrichten desselben Typs in einer Übertragungsdatei, d. h. zwischen UNB..UNZ.

Beispiel:
UNG+INVOIC+5412345678908:14+8798765432106:14+20020102:1000+471123+UN+D:01B:EAN010'

Segment Layout - UNH-Segment

Dokumentation zum UNH-Segment:

Dieses Segment dient dazu, eine Nachricht zu eröffnen, zu identifizieren und zu spezifizieren.

DE 0062: Es gilt als best practise die Nachrichtenreferenznummer eindeutig und aufsteigend zu vergeben.

DEG S009: Identifikation der EANCOM®-Nachricht

Der Inhalt der Datenelemente 0065, 0052, 0054 und 0051 muss den Vorgaben der UN/EDIFACT-Standardnachrichten entsprechen. Der Inhalt des DE 0057 wird von GS1 im Rahmen der Pflege des EANCOM®-Standards vergeben.

DE 0065: Datenelement 0065 identifiziert eine UN/EDIFACT-Nachricht, wobei die genaue Verwendung der Nachricht im DE 1001 des BGM-Segmentes angegeben wird. Zum Beispiel entspricht die Nutzung der UN/EDIFACT-Nachricht INVOIC als Gutschrift: UNH DE 0065 = INVOIC, BGM DE 1001 = 381.

DE 0110: Dieses Datenelement kann von den Geschäftspartnern zur Identifikation der EANCOM® Codeliste benutzt werden, falls diese von der EANCOM® Codeliste 2002 abweicht. Dies muss in der Datenaustauschvereinbarung bilateral festgelegt werden.

Die Kombination der Werte im Datenelement 0062 und der Datenelementgruppe S009 sollte genutzt werden, um eine Nachricht im Rahmen des Datenaustausches für eine Bestätigung eindeutig zu identifizieren (vgl. UNB, DE 0031).

Beispiel:
UNH+1+INVOIC:D:01B:UN:EAN010'

Segment Layout - UNT-Segment

Dokumentation zum UNT-Segment:

Dieses Segment wird benutzt, um den Empfänger der Übertragungsdatei darüber zu informieren, dass andere Trennzeichen als die Standardtrennzeichen benutzt werden.

Bei Verwendung der Standard-Trennzeichen muss das UNA-Segment nicht gesendet werden. Wenn es gesendet wird, muss es dem UNB-Segment unmittelbar vorangehen und die vier Trennzeichen (Positionen UNA1, UNA2, UNA4 und UNA6) enthalten, die vom Sender der Übertragungsdatei ausgewählt wurden.

Unabhängig davon, ob ein oder mehrere Trennzeichen geändert wurden, müssen alle Datenelemente dieses Segments gefüllt werden (d. h. wenn Standardwerte zusammen mit anwenderdefinierten Werten verwendet werden, müssen sowohl Standard- als auch anwenderdefinierte Werte angegeben werden).

Die Angabe der Trennzeichen im UNA-Segment erfolgt ohne Verwendung von Trennzeichen zwischen den Datenelementen.

Die Anwendung des UNA-Segments ist erforderlich, wenn andere Zeichensätze als Zeichensatz A verwendet werden.

Beispiel:
UNA:+.?*'

Segment Layout - UNE-Segment

Dokumentation zum UNE-Segment:

Innerhalb von EANCOM® wird die Anwendung der Segmente UNG..UNE nicht empfohlen, weil dem Gruppieren von Nachrichten desselben Typs nicht so hohe Bedeutung beigemessen wird, wie dem Zusammenfassen mehrerer Nachrichten desselben Typs in einer Übertragungsdatei  d. h. zwischen UNB..UNZ.

Beispiel:
UNE+25+471123'

Segment Layout - UNZ-Segment

Dokumentation zum UNZ-Segment:

Dieses Segment dient der Anzeige des Endes der Übertragungsdatei.

DE 0036: Falls Nachrichtengruppen verwendet werden, wird hier deren Anzahl in der Übertragungsdatei angegeben. Wenn keine Nachrichtengruppen verwendet werden, steht hier die Anzahl der Nachrichten in der Übertragungsdatei.

Beispiel:
UNZ+5+12345555'

Beispiel einer Übertragungsdatei

Die Übertragungsdatei enthält zwei Typen von Nachrichten: drei Liefermeldungen und zwei Rechnungen.
Die Datei wird am 02. Januar 2002 von einem Unternehmen, das sich durch die GLN 5412345678908 identifiziert, an ein Unternehmen mit der GLN 8798765432106 geschickt.

UNB+UNOA:4+5412345678908:14+8798765432106:14+20020102:1000+12345555+++++EANCOMREF 52'
....
UNH+66025+DESADV:D:01B:UN:EAN007'
.....
.....
UNT+35+66025'
UNH+66420+DESADV:D:01B:UN:EAN007'
.....
.....
UNT+26+66420'
UNH+1588+INVOIC:D:01B:UN:EAN010'
....
....
UNT+46+1588'
UNH+2063+INVOIC:D:01B:UN:EAN010'
....
....
UNT+87+2063'
UNH+67020+DESADV:D:01B:UN:EAN007'
.....
.....
UNT+102+67020'
....
UNZ+5+12345555'

5.8.1 Einleitung

Ökonomische Tendenzen den elektronischen Geschäftsverkehr über nicht sichere Netzwerke (wie das Internet) durchzuführen, erfordern zusätzliche Maßnahmen zum Schutz gesendeter und empfangener Informationen. Um jegliche Geschäftsaktivität erfolgreich über das Internet abwickeln zu können,sollte ein Unternehmen von seinen Kunden als vertrauenswürdige Einheit geprüft sein, welches Identität und persönliche Daten schützt (Heimatadresse, Kreditkartennummer, usw.). Die Anwendung der digitalen Signatur in Geschäftsbeziehungen und -aktivitäten - einer optionalen Verschlüsselungstechnik - gilt als Mehrwert-Werkzeug und -Service, welches Endanwender mit einem ausreichenden Grad an Vertrauen bezüglich der Transaktionen versorgt, in die sie involviert sind.

Üblicherweise werden Signaturen verwendet, um Dokumente zu authentifizieren. Gleichermaßen werden digitale Signaturen verwendet, um den Inhalt elektronischer Dokumente (EDI-Nachrichten, PDF-Dateien, Emails und Dokumente aus der Textverarbeitung) zu authentifizieren. Um ein Dokument digital signieren zu können, muss man ein digitales Zertifikat haben, welches bei verschiedenen Zertifizierungsstellen erhältlich ist. Verfügt man über ein digitales Zertifikat, kann die digitale Signatur mit entsprechender Software generiert werden.

Die digitale Signatur ist einfach ein kleiner Block an Daten, der an die Dokumente angehängt wird. Sie wird durch das digitale Zertifikat erzeugt, welches sowohl einen privaten als auch einen öffentlichen Schlüssel enthält. Der private Schlüssel wird genutzt, um die digitale Signatur am Dokument anzubringen, während der öffentliche Schlüssel mit der Datei verschickt wird. Der öffentliche Schlüssel dient zur Prüfung der Integrität des Inhaltes.

5.8.2 Vorteile

Die Anwendung der digitalen Signaturtechnik in EANCOM® erbringt verschiedene Mehrwertservices. Betrachtet man den elektronischen Datenaustausch über das Netz, repräsentiert die Technik eine wahre Gegenmaßnahme und Sicherheitslösung zum Schutz der Informationen gegen die meisten drohenden Gefahren. Die Anwendung der digitalen Signatur verhindert:

- Unversehrtheit des Inhalts

Diese Lösung schützt gegen Änderungen an den ausgetauschten Daten. Der Sender wendet einen Algorithmus auf die Nachricht an, bevor er sie versendet, um eine Integritätskontrolle zu erhalten, die in der Nachricht integriert ist. Der Empfänger wendet den selben Algorithmus auf die erhaltene Nachricht an (den entsprechenden Instruktionen folgend) und das Ergebnis muss dem übersendeten Integritätswert entsprechen.

- Echtheit des Ursprungs

Diese Lösung schützt den Empfänger gegen die Verarbeitung von Daten eines Unternehmens, welches vorgibt, ein anderes zu sein. Authentifikationscodes werden mit der Nachricht an den Empfänger transportiert, um die Identität des Senders sicher zu stellen. Diese Authentifikationscodes (Digitales Zertifikat) werden durch einen authorisierten und vertrauenswürdigen Dritten (Zertifizierungsstelle) generiert und sollten vor der ersten Übertragung zwischen den Handelspartnern ausgetauscht werden.

- Unleugbarkeit des Ursprungs

Diese Lösung schützt den Empfänger gegen die Verleugnung des Senders, die Nachricht verschickt zu haben. Der Sender signiert die Nachricht digital. Der Empfänger verwendet den Prüfcode in der digitalen Signatur und das dem Sender zugewiesene Zertifikat, um die Nachricht zu validieren. Demzufolge muss der Sender die Nachricht verschickt haben, wenn sie valide ist. Es gibt keine Möglichkeit, dass ein anderer die Nachricht generiert hat, ohne im Verifikationsprozess eine Fehlermeldung zu erhalten.

- Unleugbarkeit des Empfangs (wenn eine Antwortnachricht implementiert ist)

Diese Lösung schützt den Sender gegen die Verleugnung des Empfängers, die Nachricht erhalten zu haben. Der Sender muss vom Empfänger eine Bestätigung verlangen, dass die Nachricht empfangen wurde. Der Empfänger sollte eine digitale Signatur in die Bestätigung einfügen, um die Integrität der Bestätigung zu garantieren und die Empfänger-Identität zu beweisen.

5.8.3 Implementation Guideline

GS1 hat eine Richtlinie zur Absicherung von EANCOM®-Nachrichten entwickelt, die einige mögliche Sicherheitsmaßnahmen im UN/EDIFACT-Standard beleuchten. Die Entscheidung, Sicherheitslösungen in einer EDI-Umgebung einzusetzen, hängt von den ausgetauschten Daten ab und von den möglichen Verlusten, die durch zufällige oder bösartige Verfälschung einer Nachricht entstehen können.

Eine umfassende Beschreibung und Implementierungsrichtlinie der digitalen Signatur in EANCOM® ist frei verfügbar (englischsprachig)

5.9 Objekt Segmente (nur Syntax 4)

EANCOM® bietet die Möglichkeit mit Hilfe der UNO-UNP-Segmente, ein Objekt (ein Bild, einen Bericht, oder ein digitales Zertifikat) an jede Nachricht anzuhängen.

Das UNO-Segment bildet den Kopf, es identifiziert und spezifiziert ein Objekt. Das Segment UNP beendet ein Objekt und prüft seine Vollständigkeit.

Segment Layout - UNO-Segment

Dokumentation zum UNO-Segment:

Dieses Segment dient dazu, ein Objekt zu eröffnen, zu identifizieren und zu spezifizieren.

Das digitale Zertifikat wird im PKCS#7-Format beigefügt, weil es den Einschluss von mehr als einem digitalen Zertifikat erlaubt (Anwender Zertifikat und Zertifikationskette).
Diese Datei wird mit dem EDC- oder Hexadezimalen Filter gefiltert.

Sobald die Datei gefiltert ist, wird die Gesamtanzahl Bytes des beigefügten Objekts ermittelt und in DE0810 angegeben.

Beispiel:
UNO+OB00001+1:CER123+46:EDC*62:PKCS7+1238'

Segment Layout - UNP-Segment

Dokumentation zum UNP-Segment:

Dieses Segment dient dazu, die Vollständigkeit eines Objekts zu prüfen, und es zu beenden.

Beispiel:
UNP+1238+OB000001'