Aufbau einer EDIFACT-Datei
Veröffentlicht am von

Wer sich heute mit dem Thema elektronischer Datenaustausch näher beschäftigt, wird über kurz oder lang nicht um das Thema EDIFACT herumkommen. Obwohl es seit der Einführung von XML Mitte der 1990er Jahre zu einem rasanten Anstieg von XML-basierten Geschäfts­dokumenten­standards gekommen ist, bleibt EDIFACT nach wie vor das Arbeitspferd des elektronischen Datenaustausches. In diesem Beitrag analysieren wird den schematischen Aufbau einer EDIFACT-Datei genauer.

EDI-Standards

Eine EDI-Datei mag auf den ersten Blick wie ein wahlloses Wirrwarr von Zeichen erscheinen. Beim genauerem Hinsehen offenbart sich jedoch ein durchdachter schematischer Aufbau, der die Verarbeitung der Nachricht durch Computerprogramme erst ermöglicht. Hinter einer EDI-Datei liegt ein bestimmter EDI-Standard, der vorschreibt wie die Datei aufgebaut sein muss. Typische Standardformate die hierbei zur Anwendung kommen können sind beispielsweise EDIFACT, XML, CSV-Dateien oder Flatfile-Formate.

Ein EDI-Standard baut dabei üblicherweise auf den folgenden vier Prinzipien auf:

Regeln für die Syntax

Die Regeln für die Syntax definieren die erlaubten Zeichen und die erlaubte Reihenfolge, in der die einzelnen Zeichen verwendet werden dürfen.

Codes

Innerhalb einer EDI-Datei wird die meiste Information mit Hilfe von Codes genauer identifiziert - beispielsweise Währungscodes, Ländercodes, aber auch Codes zur Identifikation eines bestimmten Datumsformates, etc.

Nachrichtendesign

Das Nachrichtendesign definiert die Struktur eines bestimmten Nachrichtentyps. Nachrichtentypen sind beispielsweise Bestellungen, Lieferscheine, Rechnungen, usw.

Identifikation von Werten in einer EDI-Nachricht

Je nach verwendetem Standard gibt es drei Möglichkeiten, wie ein Wert in einer EDI-Datei identifiziert werden kann:

a) Implizit durch die Position in der Nachricht. Diese Technik kommt bei Flatfile Formaten und bei CSV zum Einsatz. Im Rahmen einer begleitenden Dokumentation wird hier genau angegeben, was wo steht. Beispielsweise: Eine Zeile die mit den Zeichen “100” beginnt, steht für die Headerzeile. Die Zeichen von Position 4 - 17 in einer Zeile die mit “100” beginnt stehen für die GLN des Senders, usw.

b) Implizit durch die Verwendung von Trennzeichen. Im Rahmen der Standarddefinition wird dabei festgelegt, welche Arten von Segmenten in einer Nachricht erlaubt sind und mit Hilfe von welchen Zeichen diese Segmente getrennt sind. Diese Technik kommt im Rahmen von EDIFACT-Dateien zur Anwendung.

c) Explizit durch die Anwendung von Metadaten. Mit Hilfe von zusätzlichen Daten wird dabei die Bedeutung der einzelnen Informationsfragmente in einer Datei genauer spezifiziert. Diese Technik kommt beispielsweise bei XML zu Anwendung, wobei hier die eigentliche Information mit Hilfe von Markup-Elementen und Attributen umschlossen wird - z.B.:

 <InvoiceRecipient id="IV4394">Rechnungsempfänger</InvoiceRecipient>

UN/EDIFACT - Ein Standard der Vereinten Nationen

UN/EDIFACT ist die Abkürzung für United Nations Electronic Data Interchange for Administration, Commerce and Transport. Die Standardisierungs­organisation hinter UN/EDIFACT ist UN/CEFACT (United Nations Center for Trade Facilitation and Electronic Business). UN/EDIFACT ist heute neben ANSI ASC X.12 einer der am weitesten verbreiteten EDI-Standards. ANSI ASC X.12 ist vor allem am nordamerikanischen Markt sehr verbreitet, während man in Europa vorrangig auf UN/EDIFACT (bzw. einen der verschiedenen Subdialekte) setzt.

Wie die folgende Abbildung zeigt, ist der UN/EDIFACT Standard auf vier verschiedenen Säulen aufgebaut.

Säulen des EDIFACT-Standards

Säulen des EDIFACT-Standards

Syntax

Die Syntax definiert die genauen Regeln für den Nachrichtenaufbau, sowie die Zeichen, welche für die Trennung von einzelnen Nachrichtensegmenten und -elementen verwendet werden.

Datenelemente

Ein Datenelement ist die kleinste Einheit in einer EDIFACT-Datei.

Segmente

Gruppen von gleichartigen Datenelementen bilden sogenannte Segmente.

Nachrichten

Nachrichten stellen eine geordnete Sequenz von Segmenten dar - beispielsweise stellt eine DESADV Datei einen Lieferschein dar.

Zusätzlich definiert der EDIFACT-Standard Vorgaben für die Nachrichtenübermittlung. Beispielsweise den genauen Aufbau eines konkreten Nachrichtenaustausches, der wiederum mehrere EDIFACT-Dateien enthalten kann.

EDIFACT-Standards

Der genaue Aufbau einer EDIFACT-Nachricht wird in offiziellen Standarddokumenten festgehalten, die auch online verfügbar sind. Pro Jahr werden von UN/CEFACT zwei EDIFACT Standardversionen verabschiedet, die jeweils durch die Jahreszahl gefolgt von A (für das erste Release eines Jahres) und B (für das zweite Release eines Jahres) gekennzeichnet werden. D01B ist daher die zweite Standardversion aus dem Jahr 2001.

Zusätzlich existieren für die verschiedenen Industriesparten und -domänen eigene Subsets des offiziellen UN/EDIFACT-Standards. Im Bereich der Konsumgüterwirtschaft ist dies der EANCOM-Standard, der auch für das Beispiel dieses Beitrages herangezogen wird. EANCOM ist der global am weitesten verbreitete Standard für den elektronischen Datenaustausch. Die dabei am häufigsten eingesetzten EANCOM-Nachrichtenarten sind die Bestellung (ORDERS), der Lieferavis (DESADV) und die Rechnung (INVOIC).

Aufbau einer EDIFACT-Datei

Eine EDIFACT-Datei folgt einer genauen Hierarchie, die für die automatisierte Verarbeitung der Nachricht notwendig ist.

Aufbau einer EDIFACT-Datei

Aufbau einer EDIFACT-Datei

Die oberste Einheit einer EDIFACT-Nachricht ist der Interchange (UNB), den man sich wie einen Briefumschlag vorstellen kann. Der Interchange definiert den Nachrichtenempfänger, den Nachrichtensender, die Nachrichtennummer, das Nachrichtendatum, usw.

Ein Interchange kann wiederum mehrere einzelne Groups (UNG) beinhalten, die Nachrichtengruppen darstellen. Alternativ kann eine Interchange auch einzelne Messages (konkrete Nachrichten) enthalten. Ein Vermischen von einzelnen Nachrichten und Nachrichtengruppen innerhalb eines Interchanges ist nicht zulässig.

Eine Nachricht selbst wird durch ein Header- (UNH) und ein Trailersegment (UNT) umschlossen. Eine Nachrichtengruppe wird durch ein UNG und UNE Segment umschlossen.

Innerhalb einer Nachricht finden sich mehrere Segmente und Segmentgruppen, die einzelne zusammengehörige Nachrichtenteile darstellen (zum Beispiel Informationen zum Rechnungssteller, eine konkrete Rechnungszeile, usw.). Eine Segmentgruppe wird durch ein sogenanntes Triggerelement eingeleitet.

Segmente bestehen wiederum aus Datenelementen (Data Elements) und zusammengesetzten Datenelementen (Composite Data Elements).

Die kleinste Einheit einer EDIFACT-Datei sind Simple Data Elements.

Simple Data Elements

Simple Data Elements bilden die Grundbausteine einer EDIFACT-Datei und stellen einfache Datenwerte dar.

Beispiel

3164 - City Name

Beschreibung: Name of a city (a town, a village) for addressing purposes.

Darstellung: an..35

Beispiel:

 München

Die Abkürzung ‘an..35’ bedeutet dabei, dass für die Darstellung maximal 35 alphanummerische Zeichen verwendet werden dürfen.

Simple Data Element mit Codeliste

Bei einem Simple Data Element mit Codeliste darf kein Freitext verwendet werden, sondern es muss auf eine Liste von vordefinierten Werten (= Codes zurückgegriffen werden).

Beispiel

3207 - Country, codes

Beschreibung: Identification of the name of a country or other geographical entity as specified in ISO 3166. Note: Use ISO 3166 two alpha country code.

Darstellung: an..3

Beispiel:

AD  =   ANDORRA
AE  =   UNITED ARAB EMIRATES
AF  =   AFGHANISTAN
AG  =   ANTIGUA AND BARBUDA
AL  =   ALBANIA
AM  =   ARMENIA
AO  =   ANGOLA
…

Composite Data Element

Ein Composite Data Element besteht aus einzelnen Simple Data Elements und stellt Daten mit zusätzlichen Metadaten (= zusätzliche, die eigentlichen Daten beschreibende Daten) dar.

Die einzelnen Komponenten innerhalb eines Composite Data Elements (typischerweise Simple Data Elements und Simple Data Elements mit Codelisten) werden mit Hilfe des : Zeichen getrennt.

Beispiel

C516 - Monetary Amount

Aufbau:

5025 Monetary amount type code qualifier M an..3
5004 Monetary amount C n..35
6345 Currency identification code C an..3
6343 Currency type code qualifier C an..3
4405 Status description code C an..3

Beispiel:

Das folgende Beispiel zeigt einen exemplarischen Monetary Amount.

23:235.43:ARS:11:5

23 = Charge Amount
235.43 = Betrag
ARS = Argentinische Pesos
11 = Payment Currency
5 = Subject to final payment

Segmente

Segmente bestehen aus Simple Data Elements und Composite Data Elements und stellen zusammengesetzte Daten, wie beispielsweise eine Adresse dar.

Die einzelnen Datenelemente in einem Segment werden durch das + Zeichen getrennt. Ein Segment beginnt mit dem dreistelligen Segmentidentifier (bestehend aus drei Buchstaben) und endet mit dem ' Zeichen.

Der genaue Aufbau eines Segments wird mit Hilfe von sogenannten Segmenttabellen beschrieben. Die folgende Segmenttabelle beschreibt den Aufbau des NAD (Name and address) Segments.

010    3035 PARTY FUNCTION CODE QUALIFIER              M    1 an..3

020    C082 PARTY IDENTIFICATION DETAILS               C    1
       3039  Party identifier                          M      an..35
       1131  Code list identification code             C      an..17
       3055  Code list responsible agency code         C      an..3

030    C058 NAME AND ADDRESS                           C    1
       3124  Name and address description              M      an..35
       3124  Name and address description              C      an..35
       3124  Name and address description              C      an..35
       3124  Name and address description              C      an..35
       3124  Name and address description              C      an..35

040    C080 PARTY NAME                                 C    1
       3036  Party name                                M      an..35
       3036  Party name                                C      an..35
       3036  Party name                                C      an..35
       3036  Party name                                C      an..35
       3036  Party name                                C      an..35
       3045  Party name format code                    C      an..3

050    C059 STREET                                     C    1
       3042  Street and number or post office box
             identifier                                M      an..35
       3042  Street and number or post office box
             identifier                                C      an..35
       3042  Street and number or post office box
             identifier                                C      an..35
       3042  Street and number or post office box
             identifier                                C      an..35

060    3164 CITY NAME                                  C    1 an..35

070    C819 COUNTRY SUB-ENTITY DETAILS                 C    1
       3229  Country sub-entity name code              C      an..9
       1131  Code list identification code             C      an..17
       3055  Code list responsible agency code         C      an..3
       3228  Country sub-entity name                   C      an..70

080    3251 POSTAL IDENTIFICATION CODE                 C    1 an..17

090    3207 COUNTRY NAME CODE                          C    1 an..3

M steht in diesem Fall für “mandatory”, d.h. das Simple Data Element oder Composite Data Element muss angeben werden. C steht für “conditional” und bedeutet, dass das Datenelement optional angegeben werden kann. Die Werte “an..3”, “an..17”, usw. stehen wiederum für die maximale Anzahl an zulässigen alphanummerischen Zeichen.

Beispieldaten:

Käufer:
ecosio GmbH
Lange Gasse 30
A-1080 Wien, Österreich

Verkäufer:
Computerzubehör GmbH
Dresdner Straße 54
A-1200 Wien, Österreich

Resultierende EDIFACT-Segmente:

 NAD+BY++ecosio GmbH+Lange Gasse 30+Wien+W+1080+AT'
 NAD+SU++Computerzubehör GmbH+Dresdner Straße 54+Wien+W+1200+AT'

Wie bereits in früheren Beiträgen ausgeführt, eignet sich die Angabe von regulären Adressinformationen nur sehr schlecht für die automatisierte Verarbeitung durch Computerprogramme. Aus diesem Grund wird für die eindeutige Identifikation von beteiligten Unternehmen auf eindeutige Identifikationsschema und -nummern zurückgegriffen.

Beispielsweise:

 NAD+BY+8532145695214::9'
 NAD+SU+5326598754587::9'

für die eindeutige Beschreibung mit Hilfe von GLNs. Wie aus der Segmenttabelle für NAD ersichtlich, ist 9 ein Wert der im Simple Data Element 3055 hinterlegt ist und der darauf hinweist, dass der verwendete Code eine GLN ist.

Segmentgruppen

Segmentgruppen dienen zur Aggregation von mehreren einzelnen Segmenten zu Gruppen von zusammengehörigen Segmenten.

Die folgende Segmentgruppe erlaubt beispielsweise die Angabe einer eindeutigen Referenz, indem die Segmente RFF (Reference) und DTM (Date/time/period) kombiniert werden. Dadurch ist es mit Hilfe der Segmentgruppe möglich eine Referenz und ein dazugehöriges Datum anzugeben.

 0160       ----- Segment group 3  ------------------ C   99---------+|
 0170   RFF Reference                                 M   1          ||
 0180   DTM Date/time/period                          C   5----------+|

Einige mögliche Segmentabfolgen wären zum Beispiel:

 RFF-RFF-RFF-DTM-DTM-DTM-DTM-RFF
 RFF
 RFF-DTM-RFF-RFF-DTM-RFF-RFF

Wie die Angabe von C 99 zeigt, ist die Segmentgruppe selbst optional und darf maximal 99 Mal vorkommen. Eingeleitet wird die Segmentgruppe durch ein sogenanntes Trigger-Segment. Dies ist das erste Element innerhalb der Segmentgruppe, das üblicherweise die Kardinalität M 1 hat (also genau ein Mal vorkommen muss).

Nachrichten

Eine Nachricht stellt eine zusammengehörige Abfolge von Segmenten dar und repräsentiert ein konkretes Geschäftsdokument - beispielsweise eine ORDERS Nachricht. Der nachfolgende Ausschnitt zeigt den ersten Teil einer ORDERS Definition.

0010   UNH Message header                            M   1
0020   BGM Beginning of message                      M   1
0030   DTM Date/time/period                          M   35
0040   PAI Payment instructions                      C   1
0050   ALI Additional information                    C   5
0060   IMD Item description                          C   999
0070   FTX Free text                                 C   99
0080   GIR Related identification numbers            C   10
0090       ----- Segment group 1  ------------------ C   9999--------+
0100   RFF Reference                                 M   1           |
0110   DTM Date/time/period                          C   5-----------+
0120       ----- Segment group 2  ------------------ C   99----------+
0130   NAD Name and address                          M   1           |
0140   LOC Place/location identification             C   99          |
0150   FII Financial institution information         C   5           |
                                                                     |
0160       ----- Segment group 3  ------------------ C   99---------+|
0170   RFF Reference                                 M   1          ||
0180   DTM Date/time/period                          C   5----------+|
                                                                     |
0190       ----- Segment group 4  ------------------ C   5----------+|
0200   DOC Document/message details                  M   1          ||
0210   DTM Date/time/period                          C   5----------+|
                                                                     |
0220       ----- Segment group 5  ------------------ C   5----------+|
0230   CTA Contact information                       M   1          ||
0240   COM Communication contact                     C   5----------++
...

EDIFACT-Beispiel für eine Bestellung

Das Beispiel zeigt nun aufbauend auf den vorangegangenen Konzepten eine konkrete EDIFACT-Nachricht für eine Bestellung. Um die Lesbarkeit zu erhöhen, wurde nach jedem Segment ein Zeilenumbruch eingefügt. In einer regulären EDIFACT-Datei sind keine Zeilenumbrüche enthalten.

UNA:+.? '
UNB+UNOA:3+1234567890123:14+1234567890124:14+140516:1552+MSGNR111++++++1'
UNH+1+ORDERS:D:01B:UN:EAN008'
BGM+220+DOCNR1234'
DTM+137:20140519:102'
DTM+2:20140520:102'
NAD+BY+5682357469542::9'
NAD+DP+3839204839274::9'
NAD+SU+0293083940382::9'
LIN+1++1122334455667:EN'
QTY+21:11.00:PCE'
UNS+S'
CNT+2:1'
UNT+12+1'
UNZ+1+MSGNR111'

Im Folgenden wollen wir nun den Aufbau der einzelnen Segmente im Detail beleuchten.

UNA Segment

 UNA:+.? '

Das UNA Segment steht für den “Service String Advice” und beschreibt die in der Nachricht verwendeten Trennzeichen. Üblicherweise werden die folgenden Trennzeichen verwendet.

: Composite-Element Trennzeichen
+ Datenelement Trennzeichen
. Zeichen für das Dezimalkomma
? Release Zeichen (Escape Zeichen)
reserviert, bleibt leer
' Segmenttrennzeichen

UNB Segment

UNB+UNOA:3+1234567890123:14+1234567890124:14+140516:1552+MSGNR111++++++1'

Das UNB Segment stellt den Interchange Header dar, und beinhaltet Informationen über den Nachrichtensender, den Nachrichtenempfänger, das Nachrichtendatum usw.

UNOA steht beispielsweise für den verwendeten Zeichensatz

UNOA = UN/ECE level A; entspricht dem ISO 646 – auch genannt Internationales Alphabet Nr. 5 – außer Kleinbuchstaben.
UNOB = UN/ECE level B; wie UNOA jedoch auch zusätzlich Kleinbuchstaben.
UNOC = UN/ECE level C; entspricht ISO8859-1
UNOD = UN/ECE level D; entspricht ISO8859-2
UNOE = UN/ECE level E (Kyrillisch)
UNOF = UN/ECE level F (Griechisch)

3 steht für die UN/EDIFACT Syntax Version. Insgesamt gibt es vier verschiedene UN/EDIFACT Syntax Versionen, wobei in der Praxis vor allem die Versionen 3 und 4 zur Anwendung kommen.

1234567890123:14 entspricht dem Sender der Nachricht.

1234567890124:14 entspricht dem Empfänger der Nachricht.

Der Identifier 14 weist jeweils darauf hin, dass es sich bei der Nummer um eine GLN handelt.

140516:1552 steht für den 16. Mai 2014, 15:52 Uhr.

MSGNR111 ist die eindeutige Nummer des Interchanges. Diese wird insbesondere im Rahmen des Nachrichtenroutings für die eindeutige Identifikation einer Nachrichtenübermittlung verwendet.

Die letzte 1 zeigt an, dass der Testindikator gesetzt ist und es sich bei dem vorliegenden Interchange um eine Testnachricht handelt. Auch diese Information ist vor allem beim Routing von Nachrichten wichtig, da der Empfänger dadurch Produktivnachrichten von Testnachrichten unterscheiden kann und diese entsprechend unterschiedlich verarbeitet werden können.

UNH Segment

 UNH+1+ORDERS:D:01B:UN:EAN008'

Das UNH Segment stellt den Header einer Nachricht dar. 1 steht in diesem Fall für die eindeutige Nummer der Nachricht innerhalb des Interchanges. Diese Nummer wird durch den Sender vergeben.

ORDERS:D:01B:UN weist darauf hin, dass es sich um einer Bestellung handelt und der Nachrichtentyp aus dem UN/EDIFACT Directory D01B ist. EAN008 deutet darauf hin, dass es sich um einen EANCOM Nachrichtentyp handelt und identifiziert die verwendete EANCOM version des D01B EANCOM Standards.

BGM Segment

BGM+220+DOCNR1234'

Das BGM (Beginning of message) Segment leitet die eigentliche Nachricht ein.

220 entspricht dem konkreten Nachrichtensubtyp. Zulässige Werte sind zum Beispiel:

220 = Order
221 = Blanked order
23B = Standing order

DOCNR1234 ist die eindeutige Nummer der Nachricht, vergeben durch den Sender.

DTM Segment

DTM+137:20140519:102'
DTM+2:20140520:102'

Das DTM Segment dient zur Angabe von Datums- und Zeitinformationen.

Der erste Teil diese Composite Data Elements identifiziert den Typ der Datums (Date/time/period qualifier). Beispielsweise:

137 = Document/message date/time. Date/time when a document/message is issued. This may include authentication.
2 = Delivery date/time, requested date on which buyer requests goods to be delivered

Der zweite Teil stellt den eigentlichen Datumswert dar:

20140519 zum Beispiel den 19. Mai 2014.

Der dritte Teil gibt vor in welchem Muster das Datum an der zweiten Stelle angegeben wurde (Date/time/period format qualifier).

102 entspricht beispielsweise CCYYMMDD

NAD Segment

NAD+BY+5682357469542::9'
NAD+DP+3839204839274::9'
NAD+SU+0293083940382::9'

Das NAD Segment dient zur Angabe der Namen und Adressen der beteiligten Unternehmen. Anstatt Namen und Adressen wird jedoch in den meisten Fällen auf die eindeutige Identifikation mit Hilfe von Nummern, wie beispielsweise der GLN, zurückgegriffen.

Der erste Teil des Composite Data Element identifiziert den konkreten Typ des Geschäftspartners (Party qualifier).

BY = Buyer
DP = Delivery Party
SU = Supplier
WH = Warehouse keeper

Der zweite Teil stellt die 13-stellige GLN dar und im dritten Teil weist die 9 darauf hin, dass es sich bei der Nummer im dritten Teil um eine Nummer der EAN (International Article Numbering Association). EAN ist heute unter dem Namen GS1 bekannt - in der EDI-Standarddefinition wird teilweise noch die alte Bezeichnung verwendet.

LIN Segment

LIN+1++1122334455667:EN'

Das LIN Segment stellt eine konkrete Listenposition innerhalb der Bestellung dar.

Die 1 ist die “line item number”, die durch den Sender vergeben wird, üblicherweise bei 1 beginnt und fortlaufend ist.

Die nachfolgende Nummer 1122334455667 stellt die “item number” dar, wobei in diesem Beispiel eine GTIN verwendet wurde. Der dritte Teil EN weist wieder darauf hin, dass die Nummer im zweiten Teil von der “International Article Numbering Association (EAN)” vergeben wurde. Sprich, also eine GTIN ist.

QTY Segment

QTY+21:11.00:PCE'

Das Quantity Segment dient zur Mengenangabe.

Der erste Teil des Composite Data Elements gibt an um welche Art von Menge es sich handelt.

21 = Ordered quantity
52 = Quantity per pack
164 = Delivery batch

Der zweite Teil gibt die konkrete Menge an - in diesem Fall 11.00.

Der dritte Teil gibt an um welche Art von Mengenangabe es sich handelt. Es dürfen dabei nur bestimmte Codes verwendet werden:

PCE = Piece
KGM = Kilogram
PND = Pound
…

UNS Segment

UNS+S'

Das UNS Segment dient zur Abtrennung einer einzelnen Sektion innerhalb der Nachricht. In diesem Fall handelt es sich um den Beginn der “Detail/summary” Sektion.

CNT Segment

CNT+2:1'

Das CNT Segment dient zur Angabe von Kontrollwerten, anhand der die Anzahl von vorhandenen Segmenten in der Nachricht beim Empfang geprüft werden kann.

Die 2 steht beispielsweise für “Number of line items in message”. Wie ersichtlich, ist der Kontrollwert 1 für die Anzahl der Line Items korrekt, da die Nachricht tatsächlich nur ein Line Item Element enthält.

UNT Segment

UNT+12+1'

Das UNT Segment steht für den Message Trailer, also den Abschluss einer Nachricht.

Die erste Zahl 12 gibt die Anzahl der Segmente in der Nachricht vom UNH bis zum UNT Segment an und ist somit auch eine Kontrollziffer. Die Zahl 1 muss wiederum dieselbe Nachrichtennummer sein, die auch im UNH Segment verwendet wird. Auch dies dient zur Integritätskontrolle der EDI-Nachricht.

UNZ Segment

UNZ+1+MSGNR111'

Das UNZ Segment stellt den Interchange Trailer dar, und bildet den Abschluss eines EDI-Interchanges.

Die erste Zahl 1 steht für die Anzahl der im Interchange enthaltenden Messages. Die zweite Angabe MSGNR111 ist dieselbe Interchangenummer, wie im UNB-Segment und dient auch zur Integritätskontrolle der Nachricht.

Zusammenfassung

Obwohl auf den ersten Blick unverständlich, zeigt ein genauerer Blick auf eine EDIFACT-Nachricht die darin verborgene Information. Im Gegensatz zu markup-basierten Ansätzen wie beispielsweise XML, ist die Größe einer EDIFACT-Nachricht sehr klein, da nur die tatsächlich benötigte Information übermittelt wird und auf platzintensives Markup verzichtet werden kann.

Obwohl man meinen könnte, dass Platz bei den heute vorhandenen Speicherkapazitäten und Internetbandbreiten keine Rolle spielt, kann die Nachrichtengröße bei EDI sehr wohl eine Rolle spielen. So rechnet die Deutsche Telekom X.400 Verkehr beispielsweise noch auf Kilobytebasis ab.

EDIFACT und vor allem das EDIFACT-Subset EANCOM ist heute das am meisten verwendete EDI-Datenaustauschformat von Unternehmen in der DACH Region. Als Zulieferer von Großunternehmen oder als Abnehmer von Großunternehmen bleibt Ihnen daher oftmals auch gar nichts anderes übrig, als EDIFACT einzusetzen.

Bei weiteren Fragen zum Einsatz von EDIFACT helfen wir Ihnen gerne weiter.


Teile diesen Blog-Post:


Themen: EDIFACT  EANCOM 

Ähnliche Artikel: