Wie ist eine EDIFACT-Datei aufgebaut, welche EDIFACT-Dokumentenformate gibt es und wie kann ich EDIFACT verarbeiten?
Bei Fragen zum Einsatz von EDIFACT helfen wir Ihnen gerne weiter. Unser Blog bietet einige interessante weiterführende Artikel, z. B. über das EDIFACT PRI-Segment. Viel Spaß beim Schmökern!
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 Standardisierungsorganisation 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.
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.
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 eine 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 des Composite Data Elements identifiziert den Typ des 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 Elements 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. Unser Blog bietet einige interessante weiterführende Artikel, z. B. über das EDIFACT PRI-Segment. Viel Spaß beim Schmökern!
