EDI-Grundlagen (B&N Software) - FH Flensburg

Definition: EDI (Elektronic Data Interchange): 

EDI ist der elektronische Austausch von strukturierten Geschäftsdaten zwischen verschiedenen 

Applikationen auf autonomen Systemen.. EDI ist unabhängig von Hardware, Software und 

Transportmedium. 

Motivation zum Einsatz von EDI 

Die Motivation zum Einsatz von EDI resultiert aus den allgemeinen Vorteilen der elektronischen 

Automatisierung. Neben der Verringerung von Übertragungs-, Verarbeitungs- und Antwortzeiten 

kann auch eine Senkung der Fehlerrate erreicht werden. Als konkrete Ausprägungen dieser 

grundlegenden Vorteile können durch den konsequenten Einsatz von EDI unter anderem folgende 

Ziele erreicht werden: 

• engere Bindung von Geschäftspartnern 

• Verringerung von Lagerbeständen (Kapitalbindung) 

• Erhöhung der Markttransparenz (Angebotsausstellung und –einholung) 

• höhere Kundenzufriedenheit durch schnellere Abwicklung 

• bessere Auswertbarkeit der elektronischen Informationen (Statistiken) 

• Mitarbeitermotivation durch Entlastung von Routinetätigkeiten 

Insgesamt entsteht ein Wettbewerbsvorteil für das Unternehmen. Neben "freiwilligen" Motivationen 

sind auch entsprechende Forderungen von Kunden oder Lieferanten denkbar, die ein 

Unternehmen zur Einführung von EDI drängen. 

Geschichte 

Entwicklung von branchenspezifischen Standards (regional und national) 

Ende der 60er Jahre: 

Die US. amerikanische Transportbranche entwickelt erste Standards für EDI Nachrichten 

70er und 80er Jahre: 

Auch andere Branchen praktizieren EDI z.B. das Bankwesen (Swift) oder die Automobilindustrie 

(Odette) auf regionaler Ebene. 

Auf nationaler Ebene vereinbaren Industrieverbände gültige EDI Nachrichten mit fester 

Satzstruktur. In Deutschland waren dies vor allem SEDAS Nachrichten in der 

Konsumgüterwirtschaft und VDA Nachrichten in der Automobilindustrie. 

Copyright 2001 by B&N Software AG 

1 von 1

Branchenübergreifende Standards (nationale Bedeutung) 

Zu Beginn der 80er Jahre entwickelte sich in Amerika der branchenunabhängige ASC X12 

Standard der 1983 vom ANSI verbindlich festgelegt wird (ANSI X12) und noch heute der am 

meisten verbreitete EDI Standard in Amerika ist. 

In Europa spielte England die Vorreiterrolle und führte ebenfalls in den 80er Jahren TRADACOMS 

als branchenübergreifende Lösung ein. 

Branchenübergreifender und international gültiger Standard 

Da für immer mehr Unternehmen das "Global Marketing" zu einem normalen Geschäftsfeld wurde, 

wurde die Forderung nach einem branchenneutralen internationalen Standard gestellt.1987 legte 

die UN/ECE einen branchenübergreifenden und internationalen Standard vor: UN/EDIFACT. 

Verschiedenste Branchen hatten das Ziel, UN/EDIFACT zu fördern und entwickelten bis heute ca. 

300 EDIFACT - Nachrichten und stabilisierten diese, wie auch die EDIFACT - Syntax, als ISO- 

Standard. 

Damit lassen sich praktisch alle üblichen Geschäftsvorgänge weltweit elektronisch abbilden. 

Tabelle 1: Klassifizierung und Beispiele von EDI Standards. 

Standard branchenabhängig branchenunabhängig 

international UN/EDIFACT 

regional ODETTE (Automobilindustrie Europa) 

SWIFT (Bank Europa) 

national VDA (Automobilindustrie Deutschland) 


SEDAS (Handel Deutschland) 

2 von 2 

ANSI X.12 (USA) 

TRADACOM (England)

UN/EDIFACT 

UN/EDIFACT ist also ein internationaler und branchenunabhängiger dynamischer EDI-Standard, 

der einen permanenten Entwicklungsprozess durchläuft. 

EDIFACT stellt keinen einzelnen Standard dar, sondern ist eine Sammlung von Standards und 

Regeln, die von den Vereinten Nationen im sog. UNTDID (United Nations Trade Data Interchange 

Directory) verwaltet werden. Die Grundlage für den internationalen, systemunabhängigen 

Geschäftsdatenaustausch bilden die EDIFACT - Syntaxregeln, die 1988 als ISO-Standard 9735 

(EDIFACT - Application level syntax rules) veröffentlicht wurden. 

EDIFACT ist... 

herstellerunabhängig 

unabhängig von der Art der Übertragung 

unabhängig von der verwendeten Hardware 

unabhängig von der Betriebssystemsoftware 

unabhängig von der Landessprache 

branchenunabhängig 

Eine EDIFACT Geschäftstransaktion ist im wesentlichen nichts anderes als eine Textdatei mit 

einer festgelegten Struktur und Syntax der darin übermittelten Daten. Überdies in einer Syntax, 

resp. einer elektronischen Sprache, die weltweit einheitlich ist. Die Syntax hat die Aufgabe, jedes 

Feld und alle Einzelheiten der Inhalte so darzustellen, dass alle Systeme, über welche mittels 

UN/EDIFACT elektronischen Datenaustausch betrieben wird, immer exakt das gleiche verstehen. 

Die Weiterentwicklung des EDIFACT - Standards erfolgt unter der Schirmherrschaft der Vereinten 

Nationen (UN), die den Auftrag an die Wirtschaftskommission für Europa weitergibt, diese 

wiederum gibt sie an Unterkomitees weiter. Die UN/ECE ist eine regionale Wirtschaftskommission 

der Vereinten Nationen und beinhaltet die Länder Ost- und Westeuropas, wie auch die Vereinigten 

Staaten und Kanada. Andere Mitglieder der UN dürfen an Sitzungen teilnehmen, dies betrifft u.a. 

Australien, Japan, Korea, Neuseeland, Singapur und Gabun. Die folgende Abbildung gibt die 

Struktur der internationalen Gremien wieder, die für die EDIFACT - Nachrichten verantwortlich 

sind. 


3 von 3

Abb. 1: UN/EDIFACT :Die organisatorische Struktur der Nachrichtenentwicklung und – 

Verabschiedung 


4 von 4

Nutzung von EDI insbesondere EDIFACT in Unternehmen und die Vision von XML 

EDI 

Trotz anerkannter Nutzungspotentiale hat sich der elektronische Austausch von Daten bzw. 

Electronic Data Interchange (EDI) nicht in der Breite durchsetzen können, wie vor einigen Jahren 

prophezeit wurde. Zwar möchten marktstarke EDI-Anwender in möglichst kurzer Zeit mit vielen 

Geschäftspartnern elektronischen Datenaustausch betreiben, aber nach Schätzungen der 

"Gesellschaft für Kommunikationskonzepte und -Lösungen mbH" nutzen lediglich 5-10% der 

Unternehmen, für die der Einsatz vorteilhaft wäre, bereits heute das Potential dieser Technologie - 

und dies oft primär aufgrund des Drucks ihrer Geschäftspartner. 

Häufig werden hohe Implementierungs- und Betriebskosten als Grund dafür angeführt, dass 

Unternehmen - vor allem kleine und mittelständische Unternehmen- von einer EDI-Einführung 

absehen. Zudem sind viele existierende Lösungen heute plattformabhängig, so dass der EDI- 

Einsatz weitere Investitionen für Hard- und Software nach sich zieht. EDI ist "unbeliebt", da es 

Unternehmen häufig von ihren Geschäftspartnern aufgedrängt bekommen. Weiterhin können 

wenige Unternehmen alle Vorteile eines automatisierten Datenaustauschprozesses ausnutzen, da 

für einige Partner, die nicht an dem EDI Prozess teilnehmen wollen/können, alte Prozesse 

fortgeführt werden müssen und dadurch die Einsparungen erheblich geringer ausfallen. 

EDIFACT 

Hat der EDIFACT Standard, wie oben beschrieben, einige Vorteile, gibt es jedoch auch die andere 

Seite der Medaille für Unternehmen. 

Müssen diese auch noch andere Standards außer EDIFACT unterstützen (VDA, Odette...) so 

können rasch höhere Kosten anfallen, da die Software für jeden Standard neu produziert werden 

muss, oder Zusatzmodule hinzugekauft werden müssen. 

Um nicht bei jedem Geschäftsprozess den gesamten EDIFACT Standard beschreiben und 

abbilden zu müssen, gibt es die Bildung von Subsets für bestimmte Branchen. Es wird also nur 

eine definierte Untermenge von Nachrichtenarten, Datenelementen und Codes aus der 

Gesamtheit von EDIFACT verwendet und implementiert. Mit der Definition von EDIFACT - Subsets 

ergeben sich wiederum Kompatibilitätsprobleme, da nicht sichergestellt ist, dass jeder 

Kommunikationspartner dieselben Teilmengen des Gesamtstandards benutzt und/oder in seinem 

Anwendungsprogrammen implementiert hat. Ganz zu schweigen von Partnern, die sich nicht an 

die vorgegebene Struktur von EDIFACT halten, jedoch durch ihre "Stellung am Markt" den 

Partnern ihre falsche Prozedur aufzwingen können. 

Ein weiterer Punkt liegt darin, dass es zwar einen riesigen Verwaltungsapparat für die 

Weiterentwicklung des EDIFACT Standards gibt, der ein umfangreiches "Know-how" 

gewährleistet, auf der anderen Seite aber jahrelange Wartezeiten für die Standardisierung einer 

Transaktion in sich birgt. 


5 von 5

(Electronic Data Interchange For Administration, Commerce and Transport) 

Beispielnachricht des TESTUSER: 

UNA:+.? ' 

UNB+UNOA:3+1234567890123+3456789012345+030519:1552+1 

1+++++EANCOM+1'UNH+1+ORDERS:D:93A:UN:EAN007'BGM+2 

20+1234567'DTM+137:20030519:102'DTM+2:20030530:102'NAD+ 

BY+5678901234567::9'NAD+DP+6789012345678::9'NAD+SU+789 

0123456789::9'LIN+1++1122334455667:EN'QTY+21:11.00:PCE'U 

NS+S'CNT+2:1'UNT+12+1'UNZ+1+11' 

Legende: 

Separatoren ( :+.? ) zwischen den Datenelementen und Datengruppen. 

: = Trennung innerhalb einer Datengruppe unter den Datengruppenelementen. 

+ =Trennung der Datenelemente innerhalb eines Segmentes. 

. = (Punkt) Dezimaltrennzeichen 

? =Separator für unbekannte oder unerlaubte Zeichen (z.B. Separatoren innerhalb der Informationen). 

 

Separatoren ( ' ) zwischen den Segmenten. 

‘ = (Hochkomma) Trennung der Segmente 

Die Anzahl der in einer EDI-Nachricht befindlichen Segment – Separatoren wird im UNT - Segment durch die gewellt 

unterstrichene Linie dargestellt. 

Bei einer Einzelnachricht kann man die Hochkommas z.B. durch einen Editor zählen lassen. Für die Nachricht selbst 

sind nur die Hochkommas ab UNH – UNT (vor dem UNZ) relevant. 

Syntax einer Nachricht. 

Mit der Syntax einer Nachricht wird folgendes festgelegt: 

UNOA:2 = verwendeter Zeichensatz UNOA = nur Großbuchstaben innerhalb der Nachricht, 

UNOB = Groß- u. Kleinbuchstaben, 

UNOC = Groß- / Klein- u. Umlaute sind erlaubt (Siehe Anhang II) 

ORDERS = Nachrichtentyp ( z.B. ORDERS = Bestellung) 

D = Version 

93A = Freigabe 

UN = Organisation 

1 gibt die Gesamtanzahl der Nachrichten an. 

20000305083059 ist die Datenaustauschreferenznummer einer Nachricht. 

Diese Nummer taucht im Kopfteil jeder Nachricht im UNB - Segment sowie im Fußteil im UNZ - Segment auf, dabei 

müssen beide identisch sein. 

Auch bei einer Mehrfachnachricht sind UNB- und UNZ - Segmente nur einmal vorhanden. Sie bilden quasi den 

Briefumschlag jeder EDI-Nachricht. 

1 sind die Nachrichtenreferenznummern 

Diese Nummer taucht im UNH- und im UNT - Segment auf und muß in beiden Segmenten identisch sein. 

Die eigentlichen Nachrichten (auch in Mehrfachnachrichten!) gehen immer vom UNH – Segment bis zum 

UNT – Segment. Die Segmente UNA, UNB und UNZ bilden den Umschlag einer EDIFACT – Nachricht. 


6 von 6


Bevor es zu irgendeinem Datenaustausch per EDIFACT kommt, muss eine Absprache getroffen werden, mit welcher 

SYNTAX der Austausch stattfinden soll. 


Mit der Syntax einer Nachricht wird folgendes festgelegt: 

UNOA:2 = verwendeter Zeichensatz UNOA = nur Großbuchstaben, 

UNOB = Groß- u. Kleinbuchstaben 

UNOC = Groß- / Klein- u. Umlaute erlaubt (Siehe Anhang II) 

ORDERS = Nachrichtentyp ( z.B. ORDERS = Bestellung) 

D = Version 

93A = Freigabe 

UN = Organisation 


Abgesprochene Syntax 

UNA:+.? ' 

UNB+UNOA:3+1234567890123+3456789012345+030519:1552+1 


20+1234567'DTM+137:20030519:102'DTM+2:20030530:102'NAD+ 

BY+5678901234567::9'NAD+DP+6789012345678::9'NAD+SU+789 

0123456789::9'LIN+1++1122334455667:EN'QTY+21:11.00:PCE'U 

NS+S'CNT+2:1'UNT+12+1'UNZ+1+11' 

7 von 7

Prüfung der Nachricht auf Korrektheit I 

Die eigentlichen Nachrichten (auch in Mehrfachnachrichten!) gehen immer vom UNH – Segment bis zum UNT – 

Segment. Die Segmente UNA, UNB und UNZ bilden den Umschlag einer EDIFACT – Nachricht. Auch bei einer 

Mehrfachnachricht sind diese Segmente nur einmal vorhanden. 

Die Datenaustauschreferenznummer einer Nachricht taucht im Kopfteil jeder Nachricht im UNB - Segment sowie im 

Fußteil im UNZ – Segment auf, dabei müssen beide identisch sein. 

1 sind die Nachrichtenreferenznummern. Diese Nummer taucht im UNH- und im UNT- Segment auf und muss in beiden 

Segmenten identisch sein. 

Die Segmente UNT (innerhalb der Nachricht) und UNZ (am Ende jeder Einzel- oder Gesamtnachricht) werden auch als 

Prüfsegmente bezeichnet. Die Zahl im UNT - Segment vor der Nachrichtenreferenznummer (im Bsp. Die 11) gibt die 

Anzahl der Segmente innerhalb der eigentlichen Bestellung an. 

Nachrichtenumschlag 

UNA:+.? ' 

UNB+UNOA:3+1234567890123+3456789012345+030519:1552+1 


20+1234567'DTM+137:20030519:102'DTM+2:20030530:102'NAD+ 

BY+5678901234567::9'NAD+DP+6789012345678::9'NAD+SU+789 

0123456789::9'LIN+1++1122334455667:EN'QTY+21:11.00'UNS+S 

'CNT+2:1'UNT+12+1'UNZ+1+11' 

Bestellung mit einer Position 


Nachrichtenreferenznummer 

Datenaustauschreferenznummer 

8 von 8

Prüfung der Nachricht auf Korrektheit 

Das UNT – Segment ist folgendermassen aufgebaut: 

Bsp.: UNT+12 + 1' 

UNT+Anzahl der in der Nachricht ( UNH – UNT) befindlichen Segmente. + 1’ 

UNT+ 12 + Nachrichtenreferenznummer ’ 

Die Anzahl der in einer EDI-Nachricht befindlichen Segment – Separatoren wird im UNT - Segment durch die gewellt 

unterstrichene Linie dargestellt. 

Das UNZ – Segment ist folgendermaßen aufgebaut: 

Bsp.: UNZ+1 +11' 

UNZ+ Anzahl der Nachrichten innerhalb einer Mehrfachnachricht +11' 

UNZ+1 + Datenaustauschreferenznummer (identisch mit der aus dem UNB – Segment) ' 

Nachrichtenreferenznummer 

UNA:+.? ' 

UNB+UNOA:3+1234567890123+3456789012345+030519:1552+1 


20+1234567'DTM+137:20030519:102'DTM+2:20030530:102'NAD+ 

BY+5678901234567::9'NAD+DP+6789012345678::9'NAD+SU+789 

0123456789::9'LIN+1++1122334455667:EN'QTY+21:11.00:PCE'U 

NS+S'CNT+2:1'UNT+12+1'UNZ+1+11' 

Anzahl der in der Nachricht ( UNH – UNT) 

befindlichen Segmente. 


9 von 9 

Anzahl der Nachrichten innerhalb einer Mehrfachnachricht

Testnachricht : 

Die aufgeführte Testnachricht dient in dieser Unterlage als Basis für die Empfangs – und Sende – 

Template Beispiele. 

UNA:+.? 

'UNB+UNOA:3+1234567890123+3456789012345+030519:1552+11+++++EANCOM+1'UNH+1+O 

RDERS:D:93A:UN:EAN007'BGM+220+1234567'DTM+137:20030519:102'DTM+2:20030530:102' 

NAD+BY+5678901234567::9'NAD+DP+6789012345678::9'NAD+SU+7890123456789::9'LIN+1++ 

1122334455667:EN'QTY+21:11.00:PCE'UNS+S'CNT+2:1'UNT+12+1'UNZ+1+11 ' 

UNA:+.? ' Angabe der Nachrichtenseparatoren 

UNB+UNOA:3+1234567890123+3456789012345+030519:1552+11+++++EANCOM+1' Angabe 

Zeichensatz, Adressaten und Ref.Nummer 

UNH+1+ORDERS:D:93A:UN:EAN007' Nachrichten-Kopfsegment 

BGM+220+1234567' Bestellnummer 1234567 

DTM+137:20030519:102' Datum der Nachricht 19.05.2003 

DTM+2:20030530:102' Lieferdatum 30.05.2003 

NAD+BY+5678901234567::9' Der Käufer wird durch die ILN 5678901234567 identifiziert. 

NAD+DP+6789012345678::9' Die Lieferanschrift wird durch die ILN 6789012345678 

identifiziert. 

NAD+SU+7890123456789::9' Der Lieferant wird durch die ILN 7890123456789 

identifiziert. 

LIN+1++1122334455667:EN' Erste Bestellposition durch EAN 1122334455667 

QTY+21:11.00:PCE' Es werden 11 Einheiten bestellt 

UNS+S' Abschnitts-Kontrollsegment 

CNT+2:1' Abstimmsumme 

Die Nachricht enthält 1 Position 

UNT+12+1' Nachrichten - Endesegment 

Die Nachricht enthält 12 Segmente 

UNZ+1+11 ' Gesamtnachricht - Endesegment 


10 von 10

RCV - Template zur Beispielnachricht des TESTUSER (alter Standard): 


1 -HEAD- UNB S002 0004 UNOA 3 1234567890123 PrtNum 100000000 Absender ILN 

2 -HEAD- UNB S003 0010 UNOA 3 3456789012345 a35#01 100000000 Empfaenger ILN 

3 -HEAD- UNB S004 0017 UNOA 3 030519 a8#1 100000000 Erstellungsdatum 

4 -HEAD- UNB S004 0019 UNOA 3 1552 a6#1 100000000 Erstellungszeit 

5 -HEAD- UNB 0020 UNOA 3 11 MsgCtl 100000000 Datenaustauschreferenznummer 

6 -HEAD- UNB 0032 UNOA 3 EANCOM 100000000 

7 -HEAD- UNB 0035 UNOA 3 1 a1#1 100000000 Testkennzeichen 

8 ORDERS UNH 0062 1 AppRef 100000000 Nachrichtenreferenznummer 

9 ORDERS UNH S009 0057 ORDERS D 93A UN EAN007 100000000 

10 ORDERS BGM 1004 220 1234567 MaiKey 100000000 Auftragsnummer 

11 ORDERS DTM C507 2380 137 20030519 a35#02 100000000 Auftragsdatum 

12 ORDERS DTM C507 2379 137 102 100000000 

13 ORDERS DTM C507 2380 2 20030530 a35#03 100000000 Lieferdatum 

14 ORDERS DTM C507 2379 2 102 100000000 

15 ORDERS G02 NAD C082 3039 BY 5678901234567 a17#1 100000000 ILN Besteller 

16 ORDERS G02 NAD C082 3055 BY 9 100000000 

17 ORDERS G02 NAD C082 3039 DP 6789012345678 a17#2 100000000 ILN Warenempfaenger 

18 ORDERS G02 NAD C082 3055 DP 9 100000000 

19 ORDERS G02 NAD C082 3039 SU 7890123456789 a17#3 100000000 ILN Lieferant 

20 ORDERS G02 NAD C082 3055 SU 9 100000000 

11 von 11 

21 ORDERS G25 LIN 1082 1 n6#1 111110000 POSITIONSNUMMER 

22 ORDERS G25 LIN C212 7140 1122334455667 a35#01 111110000 EAN Waren-/Artikelnummer 

23 ORDERS G25 LIN C212 7143 EN a3#01 111110000 Artikelnummertyp, codiert 

24 ORDERS G25 QTY C186 6060 21 11.00 np2#1 111110000 Menge 

25 ORDERS G25 QTY C186 6411 21 PCE a3#02 111110000 Artikelmasseinheit 

26 ORDERS CNT C270 6066 2 1 n18#1 100000000 Anzahl der Nachrichtenartikel 

Das oben dargestellte Template ist aus der Testnachricht ORDERS.EDI des Testusers generiert worden. Anstelle der Daten stehen, wie in den 

nächsten beiden Spalten dargestellt, die Mapping - Felder und der Hierarchielevel aus der STANDARD-DATEI.

RCV - Template zur Beispielnachricht des TESTUSER (neuer Standard): 


1 -HEAD- UNB S001 0001 UNOA 100000000 (Verwendeter Nachrichtenzeichensatz) 

2 -HEAD- UNB S001 0002 3 100000000 (Syntax Version) 

3 -HEAD- UNB S002 0004 1234567890123 PrtNum 100000000 Absender ILN 

4 -HEAD- UNB S003 0010 3456789012345 a35#01 100000000 Empfaenger ILN 

5 -HEAD- UNB S004 0017 030519 a8#1 100000000 Erstellungsdatum 

6 -HEAD- UNB S004 0019 1552 a6#1 100000000 Erstellungszeit 

7 -HEAD- UNB 0020 11 MsgCtl 100000000 Datenaustauschreferenznummer 

8 -HEAD- UNB 0032 EANCOM 100000000 

9 -HEAD- UNB 0035 1 a1#1 100000000 Testkennzeichen 

10 ORDERS UNH 0062 1 AppRef 100000000 Nachrichtenreferenznummer 

11 ORDERS UNH S009 0057 ORDERS D 93A UN EAN007 100000000 

12 ORDERS BGM 1004 220 1234567 MaiKey 100000000 Auftragsnummer 

13 ORDERS DTM C507 2380 137 20030519 a35#02 100000000 Auftragsdatum 

14 ORDERS DTM C507 2379 137 102 100000000 

15 ORDERS DTM C507 2380 2 20030530 a35#03 100000000 Lieferdatum 

16 ORDERS DTM C507 2379 2 102 100000000 

17 ORDERS G02 NAD C082 3039 BY 5678901234567 a17#1 100000000 ILN Besteller 


19 ORDERS G02 NAD C082 3039 DP 6789012345678 a17#2 100000000 ILN Warenempfaenger 

20 ORDERS G02 NAD C082 3055 DP 9 100000000 

21 ORDERS G02 NAD C082 3039 SU 7890123456789 a17#3 100000000 ILN Lieferant 


12 von 12 


24 ORDERS G25 LIN C212 7140 1122334455667 a35#01 150000000 EAN Waren- /Artikelnummer 


26 ORDERS G25 QTY C186 6060 21 11.00 np2#1 150000000 Menge 

27 ORDERS G25 QTY C186 6411 21 PCE a3#02 150000000 Artikelmasseinheit 

28 ORDERS CNT C270 6066 2 1 n18#1 100000000 Anzahl der Nachrichtenartikel 

Das oben dargestellte Template ist aus der Testnachricht ORDERS.EDI des Testusers generiert worden. Anstelle der Daten stehen, wie in den 

nächsten beiden Spalten dargestellt, die Mapping - Felder und der Hierarchielevel aus der STANDARD-DATEI. Der Unterschied zur alten 

Version ist, dass in diesem Fall in der Regelwerksdatei ( *.XRL oder *.RUL) die Codelisten der Syntax UNB S001 0001 / - 0002 gelöscht wurden. 

Der Vorteil dieses Verfahren liegt darin, dass bei einem Wechsel des Zeichensatzes und der Syntax – Version einer Nachricht, nicht mehr das 

ganze Template geändert werden muss.

SND - Template zur Beispielnachricht des TESTUSER I: 

0 C:\MagicApp\Eddy\1_PARTNER.XRL 

1 -HEAD- UNB S002 0004 1234567890123 a35#01 100000000 Absender ILN 

2 -HEAD- UNB S003 0010 3456789012345 PrtNum 100000000 Empfaenger ILN 

3 -HEAD- UNB 0020 11 F_DAREF 100000000 Datenaustauschreferenznummer 

4 -HEAD- UNB 0032 EANCOM K#EAN007 100000000 

5 -HEAD- UNB 0035 1 a1#1 100000000 Testkennzeichen 

6 ORDERS UNH 0062 1 F_NAREF 100000000 Nachrichtenreferenznummer 

7 ORDERS UNH S009 0057 EAN007 K#EAN007 100000000 

8 ORDERS BGM C002 1001 220 K#220 100000000 

9 ORDERS BGM 1004 1234567 MaiKey 100000000 Auftragsnummer 

10 ORDERS DTM C507 2005 137 K#137 100000000 

11 ORDERS DTM C507 2380 20030519 a35#02 100000000 Auftragsdatum JJJJMMDD 

12 ORDERS DTM C507 2379 102 K#102 100000000 

13 ORDERS DTM C507 2005 2 K#2 100000000 

14 ORDERS DTM C507 2380 20030530 a35#03 100000000 Lieferdatum JJJJMMDD 

15 ORDERS DTM C507 2379 102 K#102 100000000 

16 ORDERS G02 NAD 3035 BY K#BY 100000000 

17 ORDERS G02 NAD C082 3039 5678901234567 a17#1 100000000 ILN Besteller 

18 ORDERS G02 NAD C082 3055 9 K#9 100000000 

19 ORDERS G02 NAD 3035 DP K#DP 100000000 

20 ORDERS G02 NAD C082 3039 6789012345678 a17#2 100000000 ILN Warenempfaenger 

21 ORDERS G02 NAD C082 3055 9 K#9 100000000 

22 ORDERS G02 NAD 3035 SU K#SU 100000000 

23 ORDERS G02 NAD C082 3039 7890123456789 a17#3 100000000 ILN Lieferant 

24 ORDERS G02 NAD C082 3055 9 K#9 100000000 


13 von 13 


26 ORDERS G25 LIN C212 7140 1122334455667 a35#01 150000000 EAN Waren-/ Artikelnummer 


28 ORDERS G25 QTY C186 6063 21 K#21 150000000 

29 ORDERS G25 QTY C186 6060 11.00 np2#1 150000000 Menge 

30 ORDERS G25 QTY C186 6411 PCE a3#02 150000000 Artikelmasseinheit 

31 ORDERS UNS 0081 S K#S 100000000 

32 ORDERS CNT C270 6069 2 K#2 100000000 

33 ORDERS CNT C270 6066 1 n18#1 100000000 Anzahl der Nachrichtenartikel 

Die Sende-Templates geben in Zeile = 0 die Regelwerksdatei (*.XRL) an. Ständig benutzte Informationen können mit K# als konstante 

Werte über das Template versorgt werden. Diese Methode erspart das Füllen von Feldern der STDDAT. Über integrierte Funktionen F_ 

können z.B. die Datenaustauschreferenznummer oder die Absenderreferenz automatisiert versorgt werden. Sende - Templates sind i.d.R. 

immer einige Zeilen länger als die RCV – Ausführung. Ein weiteres Merkmal ist, dass für die Positionen anstelle der 

Hierarchielevel 111110000 die Zahl 150000000 verwendet wird.

SND - Template zur Beispielnachricht des TESTUSER II: 

Für einige Fälle können in den Templates Sonderzeichen eingefügt werden ( N 2 # < * ). Ihr Einsatz wird in dem folgendem Beispiel eines Sende- 

Templates dargestellt. Hierbei handelt es sich nur um einen Ausschnitt des Positionssatzes. 


Feld: 1 2 3 4 5 6 7 

N 2 # * Beispielmöglichkeiten 

90 INVOIC G25 IMD 7077 K#C 150000000 # . 

91 INVOIC G25 IMD C273 7009 a3#09 150000000 < * falls Leergut : RC 

92 INVOIC G25 QTY C186 6063 K#47 150000000 47 bestellte Menge 

93 INVOIC G25 QTY C186 6060 np5#1 150000000 N 4 berechnete Menge 

94 INVOIC G25 QTY C186 6411 a3#01 150000000 Maßeinheit Menge 

95 INVOIC G25 G26 MOA C516 5025 K#203 150000000 # . 

96 INVOIC G25 G26 MOA C516 5004 np2#2 150000000 J < * Artikel - Bruttobetrag 

97 INVOIC G25 G26 MOA C516 5025 K#131 150000000 . 

98 INVOIC G25 G26 MOA C516 5004 np2#3 150000000 Betrag Art. - Gesamtrabatt 

. 7 = leer . 

6 = leer . 

5 = Bedingungsfeld hier ist ein (*) . 

zu setzen wenn das Feld Bedingungs- . 

feld ist. . . 

4 = wenn in diesem Feld ein (#) steht 

werden die Inhalte nur übertragen, 

wenn Feld 5 gefüllt ist. Alle zugehörigen 

Zeilen sind mit (#) zu kennzeichnen. 

In der letzten Zeile des 

Segments steht ein (

Auswahl der STDDAT – Befüllung über die empfangenen Suffix-Qualifier 

Befüllung der STDDAT in Abhängigkeit übertragener Suffix - Qualifier in den RCV - Nachrichten 

17 ORDERS DTM C507 2380 137 a35#02 100000000 Nachrichtendatum (CCYYMMDD) 

18 ORDERS DTM C507 2379 137 102 100000000 

19 ORDERS DTM C507 2380 64 SQ_a3#10;102=a35#12;401=a6#2 100000000 Lieferdatum/-zeit, fruehestes 

20 ORDERS DTM C507 2379 64 a3#10 100000000 Qual. Lieferdatum/-zeit, fruehestes 

21 ORDERS DTM C507 2380 63 SQ_a3#11;102=a35#11;401=a6#3 100000000 Lieferdatum/-zeit, spaetestes 

22 ORDERS DTM C507 2379 63 a3#11 100000000 Qual. Lieferdatum/-zeit, spaetestes 

23 ORDERS DTM C507 2380 2 a35#03 100000000 Liefertermin, gefordert (CCJJMMTT) 

24 ORDERS DTM C507 2379 2 102 100000000 


Bedingt durch das EDIFACT Format werden manche Informationen übermittelt, bei denen sich erst später entscheidet, welcher Art sie sind. 

Die Kennzeichnung der Information erfolgt über einen Suffix-Qualifier. Der Receive-Teil des Konverters arbeitet in der Regel sequenziell. 

Über das spezielle Receive-Template werden die Informationen aus der Edifact Nachricht einzeln auf die Felder der Standard-Datei 

(STDDAT) gemappt. Um es zu ermöglichen, die Informationen auf einen einzigen Hierarchielevel der Standard-Datei zu mappen, die nicht 

allein durch Ihren Edifact Pfad spezifiziert werden, sondern zusätzlich von einem Suffix-Qualifier abhängig sind, wurde diese zusätzliche 

Funktionalität im Receive-Template entwickelt. Hierbei wird die Information aus der EDIFACT-Nachricht zwischengespeichert und erst nach 

dem Auftreten des im SQ-Ausdrucks definierten Mapping-Feldes aufgelöst. 

15 von 15 

Bei dem hier gezeigten Ausschnitt einer RCV ORDERS werden in Zeile 21 in Abhängigkeit der Befüllung von Feld a3#11 aus Zeile 22, die 

Felder a35#11 oder a6#3 befüllt. 

In Zeile 22 kann das Feld a3#11 die Information 102 = CCYYMMDD oder 401 = HHMM enthalten. 

Enthält das Feld den Wert 102, handelt es sich in diesem Fall um das Lieferdatum und wird in Zeile 21 in das Feld a35#11 der STDDAT 

geschrieben. 

Steht dort der Wert 401, handelt es sich um eine Zeitangabe in Stunden und Minuten, die Im Feld a6#3 der STDDAT geschrieben wird.

Syntax 

Der Suffix-Qualifier wird an Stelle des Mapping-Feldes im Receive-Template eingefügt. Die Syntax ist wie folgt aufgebaut. 

SQ_{Mapping-Feld mit Qualifier Inhalt}[;{Qualifier}={Mapping-Feld}...] 


Allgemeine Hinweise 

Es ist darauf zu achten, dass das Mapping-Feld mit Qualifier-Inhalt unter dem SQ-Ausdruck im Template steht. Die Auflösung 

des SQ-Ausdrucks geschieht innerhalb eines Hierarchie-Levels. Es können beliebig viele SQ-Ausdrücke im Template eingearbeitet 

werden. Fehler bei der Auflösung des SQ-Ausdrucks werden in der Convert.log Datei dokumentiert. 1 

16 von 16

Umsetzungstabelle PartnerID für RCV und SND - Nachrichten 

Bsp.01: 

22 ORDERS G02 NAD C082 3039 SU P_a35#06_I 100000000 ILN/BBN des Lieferanten 


24 ORDERS G02 NAD C082 3039 BY P_a35#07_I 100000000 ILN der Niederlassung 


26 ORDERS G02 NAD C082 3039 IV P_a35#08_I 100000000 ILN BAHAG AG /(Rechnungsempfänger) 

27 ORDERS G02 NAD C082 3055 IV 9 100000000 


Bei dem hier gezeigten Beispiel wird die STDDAT in den rot markierten Feldern nicht direkt durch die Übergabeprogramme des Kunden 

versorgt, sondern durch den Konverter. Dazu muss bei gestartetem m@gic EDDY über den Menüpunkt Einstellungen die 

Umsetztabelle PartnerID manuell versorgt werden. 

Diese Funktion wird z.B. genutzt, wenn es bei der Programmierung der Inhouse – Versorgung nicht möglich ist, ILN – Nummern für die 

EDIFACT – Nachrichten auszugeben oder aber auch zu empfangen. 

Empfangene ILN können über die Umsetztabelle in Systemnummern umgesetzt werden und umgekehrt. 

17 von 17

Umsetzungstabelle für die EAN für RCV und SND - Nachrichten 

33 ORDERS G25 LIN 1082 n6#1 150000000 Positionsnummer 

34 ORDERS G25 LIN C212 7140 P_a35#01_E 150000000 EAN-Nummer 

35 ORDERS G25 LIN C212 7143 EN 150000000 

Wenn es Probleme mit den ILN gibt, gibt es oft auch Probleme mit den EAN. Auch dieser Nummernkreis lässt sich über die Umsetztabellen 

im Konverter auf einen systemeigenen Nummernkreis umsetzen. 

Die Umsetzung erfolgt, wenn Einträge über die Einstellungen; Umsetztabelle; Artikelliste vorgenommen wurden. 

Auch in diesem Fall funktioniert eine Umsetzung in beide Richtungen. Es müssen lediglich die Einträge in der Artikelliste vorhanden sein 

und RCV- wie SND – Templates mit der rot markierten Kennzeichnung versehen werden. 


18 von 18

Umsetzungstabelle Masseinheiten für RCV und SND - Nachrichten 

Befüllung der STDDAT durch Umsetztabellen 

Bsp.01: 

99 INVOIC G25 QTY C186 6063 K#47 150000000 # 

100 INVOIC G25 QTY C186 6060 np5#1 150000000 J4#* berechnete Menge 

101 INVOIC G25 QTY C186 6411 P_a3#01_M 150000000 < Masseinheit der berechneten Menge, Qual.z.B. PCE=Stueck 

102 INVOIC G25 QTY C186 6063 K#59 150000000 # 

103 INVOIC G25 QTY C186 6060 np5#4 150000000 J4#* falls Upos: Anzahl der Verbrauchereinheiten 

104 INVOIC G25 QTY C186 6411 P_a3#02_M 150000000 < falls Upos: Masseinheit der Verbrauchereinheit 

105 INVOIC G25 QTY C186 6063 K#192 150000000 # 

106 INVOIC G25 QTY C186 6060 np5#5 150000000 J4#* Menge ohne Berechnung 

107 INVOIC G25 QTY C186 6411 P_a3#11_M 150000000 < Masseinheit der Menge ohne Berechnung, z.B. PCE=Stuec 


Bsp.02: 

112 INVOIC G25 G28 PRI C509 5125 K#AAB 150000000 # 

113 INVOIC G25 G28 PRI C509 5118 np5#2 150000000 J4#* Artikel-Bruttopreis 

114 INVOIC G25 G28 PRI C509 5284 n9#1 150000000 J # Preisbasis-Menge 

115 INVOIC G25 G28 PRI C509 6411 P_a3#01_M 150000000 < Masseinh der Preisba.-Menge, Qual.z.B. PCE=Stueck 

19 von 19 

Bsp.03: 

168 INVOIC G15 ALC 5463 P_a3#01_M 140000000 A-Abschlag / C-Zuschlag 

169 INVOIC G15 ALC C552 1230 a35#01 140000000 Zu- oder Abschlag, Nummer / Bilateral zu vereinbaren 

170 INVOIC G15 ALC 1227 n8#1 140000000 J Kalkulations-Folge-Anzeiger, (Rabattstufe) 

171 INVOIC G15 ALC C214 7161 a3#02 140000000 DI-Abzug(Rabatt)/EAB-Skonto/FC-Frachtgebuehren/IN-Vers. 

Bei den hier gezeigten Beispielen einiger SND - Templates wird die STDDAT in den rot markierten Feldern nicht direkt durch die 

Übergabeprogramme des Kunden versorgt, sondern durch den Konverter. Dazu muss bei gestartetem m@gic EDDY über den Menüpunkt 

Einstellungen die Umsetztabelle Masseinheiten manuell versorgt werden. Diese Funktion wird z.B. genutzt, wenn es bei der 

Programmierung der Inhouse – Versorgung nicht möglich ist, EDIFACT konforme Qualifier einzusetzen. 

Wie in diesen Beispielen beschrieben, wird häufig für Mengenangaben das Kürzel Stk verwendet, welches in den EDIFACT – Nachrichten 

in das Kürzel PCE umgesetzt werden muss. 

Das bedeutet, wir erhalten vom Kunden STK und setzen diese Information in der Nachricht in PCE um.

EDIFACT – Schulung: 

KOPFINFORMATIONEN: 

UNA : + . ? ' 

UNB + UNOA : 2 + 1234567890123 + 3456789012345 


+ 030519 : 1552 + 11 + + + + + EANCOM + 1 ' 

UNH + 1 + ORDERS : D : 93A : UN : EAN007 ' 

20 von 20 

BGM + 220 + 1234567 ' 

DTM + 137 : 20030519 : 102 ' 

DTM + 2 : 20030530 : 102 ' 

NAD + BY + 5678901234567 : : 9 '

NAD + DP + 6789012345678 : : 9 ' 

NAD + SU + 7890123456789 : : 9 ‘ 


POSITIONSINFORMATIONEN : 

LIN + 1 + + 1122334455667 : EN ' 

21 von 21 

QTY + 21 : 11.00 : PCE ' 

UNS + S ' 

CNT + 2 : 1 ’ 

UNT + 11 + 1 ' 

UNZ + 1 + 11 '

Anhang I 

Verzeichnis der Abkürzungen 

ANSI American National Standards Institute 

CCG Centrale für Coorganisation 

CEN/ISSS Centre for European Normalisation/Information Society Standardization System 

CSS Cascade Style Sheet 

DOM Document Object Model 

DTD Document Type Definition 

EDI Elektronic Data Interchange 

HTML Hypertext Markup Language 

ODETTE Organisation for Data Exchange by Teletransmission in Europe 

SEDAS Standardregelungen Einheitlicher Datenaustauschsysteme 

SGML Standardized General Markup Language 

SWIFT Society for Worldwide Interbank Financial Telecommunication 

TRADACOMS Trading Data Communications Standards 

UN/CEFACT United Nations/Centre for Facilitation of Procedures and Practices for 

Administration, Commerce and Transport 

UN/ECE United Nations/Economic Comission for Europe 

UN/EDIFACT United Nations/Electronic Data Interchange for Administration, Commerce and 

Transport 

VDA Verband der Automobilindustrie 

W3C World Wide Web Consortium 

XML Extensible Markup Language 

XSL Extensible Style Sheet 

XLL Extensible Link Language 


22 von 22

Anhang II 

ISO-Tabelle 8859-1/Teil 1 

Nach 9735 deklariert: UNOC ist definiert in 

ISO 8859-1/Teil 1, Latein Alphabet Nr. 1. 

A 

B 

C 

D 

E 

F 

Unerlaubter Bereich 


ANSI-Zeichensatz OEM-Code EBCDIC-Code (AS/400) 

F C 

ü = 1111 11ØØ = Ø252 81 DØ 

D C 

Ü = 11Ø1 11ØØ = Ø22Ø 9A 5A 

liegt im erlaubten Bereich, 

ß = 11Ø1 1111 = Ø223 jedoch unlesbar A1 

F 6 

ö = 1111 Ø11Ø = Ø246 94 6A 

D 6 

Ö = 11Ø1 O11Ø = Ø214 99 EØ 

E 4 

ä = 111Ø Ø1ØØ = Ø228 84 CØ 

C 4 

Ä = 11ØØ Ø1ØØ = Ø196 8E 4A 

Umlaute müssen generell mit einem Font nach ANSI-Code erzeugt werden und nicht nach OEM (DOS)-Code! 

23 von 23 

ü 

ä ö 

Ä 

Ö 

Ü 

A B C D E F

Anhang III 

Prüfzifferberechnung zur ILN oder EAN 

Ab dem 01.Januar 1997 sind die Prüfziffern für alle ILN weltweit genormt. Ab diesem Datum werden alle 

Prüfziffern unter Verwendung der Formel für Modulo 10, Gewichtungsfaktoren 3,1 , berechnet, welche zur 

Zeit für Produkte verwendet werden. Die Prüfziffer ist immer die 13. Zahl einer ILN. D.h. eine ILN besteht aus 

12 Zahlen + Prüfziffer. 

Beispiel-Nr1: 

ILN Karstadt AG 4 3 3 4 4 0 0 0 0 0 0 0 8 

Gewichtungsfaktoren x3 3 

x1 4 

Beispiel-Nr2: 


3 

4 

4 

32 + 8 = 40 

ILN Markant 4 3 0 4 4 4 9 0 0 0 0 0 0 

Gewichtungsfaktoren x3 3 

x1 4 

Beispiel-Nr3: 

4 

4 

4 

9 

50 + 0 = 50 

ILN HAGEBAU 9 0 0 7 4 7 0 0 4 0 4 0 7 

Gewichtungsfaktoren x3 

x1 9 

7 

4 

7 

4 

24 von 24 

4 

63 + 7 = 70 

= 21 

= 11 

32 

= 33 

= 17 

50 

= 42 

= 21 

63 

Bei der Prüfziffer handelt es sich um die Differenz der Summe der Gewichtungsfaktoren zum nächsten 

Vielfachen von 10. Im Beispiel 1 war es die " 8 ", im Beispiel 2 die " 0 " und im Beispiel 3 die Zahl " 7 ".

Anhang IV 

Liste aller EDIFACT Nachrichtentypen 

In Anhang II dieses Handbuches sollen die Möglichkeiten der verschiedenen Nachrichten beschrieben werden, die zur 

Zeit mit dem EDIFACT - Standard realisiert werden können. 

Eventuell dient diese Beschreibung als Anregung für eine Erweiterung bestehender Systeme. Sollten Fragen über 

spezielle Nachrichtentypen auftreten, steht Ihnen die Firma B & N Software AG jederzeit zur Verfügung. 

Bezeichner Nachrichtentyp 

APERAK Anwendungsfehler- und 

Bestätigungs-Nachricht 

AUTACK Sicherheits-Authentisierung und 

-Bestätigung 

AUTHOR Autorisierungs-Nachricht 

BALANC Rohbilanz 

BANSTA Bank-Status-Nachricht 

BAPLIE Ladeplan über leere und besetzte 

Zellen 

BAPLTE Ladeplan über Gesamtzahl 

BOPBNK Meldungen über Außenwirtschaftstransaktionen 

und den Auslandsstatus 

der Banken an die Zentralbank 

BOPCUS Weiterleitung von Meldungen über 

Auslandszahlungen der Bankkunden 

an die Zentralbank 

BOPDIR Zahlungsbilanzmeldungen von 

Nichtbanken direkt an die Zentralbank 

BOPINF Meldung über eingehende Auslandszahlungen 

von Bankkunden an ihre 

Geschäftsbank 

BOPSTA Austausch von Zahlungsbilanzstatistiken 

zwischen Zentralbank und 

internationalen Organisationen 

CALINF Schiffsinformation 

CASINT Antrag auf gerichtliches Tätigwerden 

in Zivilprozessen 

CASRES Stellungnahme des Gerichts in 

Zivilprozessen 

CHACCO Kontenrahmen 

CHAMAP Zuordnungstabelle 

CNTCND Vertragsbedingungen 

COARRI Container - Lösch-/Ladebericht 

CODECO Container-Terminal-Eingangs-/ 

Ausgangsmeldung 

CODENO Bescheid über Ablauf der 

Genehmigung/Zollfreigabe 

COEDOR Container-Bestandsbericht 

COHAOR Auftrag zur besonderen Behandlung 

eines Containers 

COLADV Avisierung eines Dokumenteninkasso 


25 von 25 


COLREQ Auftrag für ein Dokumenteninkasso 

COMDIS Handelsunstimmigkeit 

CONAPW Ankündigung von beabsichtigten 

Bauarbeiten 

CONDRA Zeichnungsverwaltung 

CONDRO Zeichnungsorganisation 

CONDPY Verkürzte Baurechnung 

CONEST Auftragserteilung 

CONIT Angebotsaufforderung 

CONPVA Baurechnung 

CONQVA Bauleistungsstand 

CONRPW Antwort auf die Ankündigung von 

beabsichtigten Bauarbeiten 

CONTEN Angebotsangabe 

CONTR Syntax- und Servicebericht 

CONWQD Mengenermittlung 

COPARN Container-Ankündigung 

COPINO Container-Voranzeige 

COPRAR Container - Lösch-/Ladeauftrag 

COREOR Container-Freistellungsanweisung 

COSTCO Bestätigung über das Be-/Entladen 

von Containern 

COSTOR Auftrag zum Be-/Entladen von 

Containern 

CREADV Gutschriftanzeige 

CREEXT Erweiterte Gutschriftanzeige 

CREMUL Multiple Gutschriftanzeige 

CUSCAR Zoll-Gestellungsmitteilung 

CUSDEC Zollanmeldung 

CUSEXP Zollanmeldung für Expressgut 

CUSPED Sammelzollmeldung 

CUSREP Zoll-Beförderungsmitteilung 

CUSRES Zollantwort 

DEBAV Belastungsanzeige 

DEBMUL Multiple Belastungsanzeige 

DELFOR Lieferabruf/-plan 

DELJIT Feinabruf 

DESADV Liefermeldung 

DESTIM Ausrüstungsschäden und 

Reparaturvoranschlag 

DGRECA Gefahrgutliste 

DIRDEB Lastschrift


DIRDEF Verzeichnis-Definition 

DOCADV Avisierung eines Dokumentenakkreditives 

DOCAMA Avisierung einer Änderung eines 

Dokumentenakkreditives 

DOCAMI Information über die Änderung eines 


DOCAMR Beantragung einer Änderung eines 


DOCAPP Antrag zur Eröffnung eines 


DOCARE Rückantwort zu einer Änderung eines 


DOCINF Information über die Eröffnung eines 


ENTREC Buchungssatz 

FINCAN Storno-Nachricht 

FINPAY Multipler Interbank - Zahlungsauftrag 

FINSTA Bankkontoauszug 

GENRAL Allgemeine Nachricht 

GESMES Allgemeine Statistische Nachricht 

HANMOV Nachricht für den Ladungs-/ 

Güterumschlag und transport 

IFCSUM Speditions- und Sammelladungs- 

Nachricht 

IFTCCA Speditions- und Transport- 

Sendungskosten-Kalkulation 

IFTDGN Gefahrengutanmeldung 

IFTFCC Transport-Frachtkosten und andere 

Gebühren 

IFTIAG Gefahrgutliste 

IFTMAN Ankunftsmeldung 

IFTMBC Buchungs-/Reservierungsbestätigung 

IFTMBF Buchung/Reservierung 

IFTMBP Buchungs-/Reservierungsanfrage 

IFTMCS Auftragsbestätigung/Statusmeldung 

IFTMIN Transport-/Speditionsauftrag 

IFTRIN Speditions- und Transportraten- 

Information 

IFTSAI Speditions- und Transportzeitplan und 

Verfügbarkeits-Information 

IFTSTA Multimodaler Statusbericht 

IFTSTQ Anforderung eines multimodalen 

Statusberichts 

IMPDEF EDI Anwendungsrichtlinien-Definition 

INFENT Unternehmensinformation 

INSDES Lieferanweisung 

INSPRE Versicherungsprämien-Nachricht 

INSREQ Prüfaufforderung 

INSRPT Prüfbericht 

INVOIC Rechnung INVRPT Lagerbestandsbericht 

ITRRPT Bericht über Ware im Transit 


26 von 26 


JAPRES Bewerbungsergebnis 

JIBILL Abrechnung für Anteilseigner 

JINFDE Anfrage nach Stelleninformation 

JOBAPP Bewerbungsvorschlag 

JOBCON Empfangsbestätigung und 

Stellenangebote 

JOBMOD Änderung von Stellenangeboten 

JOBOFF Stellenangebot 

LEDGER Hauptbuch/Handelsbuch 

LREACT Lebens-Rückversicherungsaktionsnachricht 

MEDPID Personenidentifikation 

MEDREQ Anforderung einer medizinischen 

Leistung 

MEDRPT Bericht medizinischer 

Leistungserbringer 

MEDRUC Inanspruchnahme medizinischer 

Leistungen und deren Kosten 

MEQPOS Nachrichten zur Angabe der Position 

eines Transportmittels und einer 

Equipments 

MOVINS Stauanweisung 

MSCONS Bericht über den Verbrauch messbarer 

Dienstleistungen 

ORDCHG Bestelländerung 

ORDERS Bestellung 

ORDRSP Bestellantwort 

OSTENQ Bestellstatusanfrage 

OSTRPT Bestellstatusbericht 

PARTIN Partnerstammdaten 

PAXLST Passagier-/Besatzungsliste 

PAYDUC Gehaltsabzugsavis 

PAYEXT Erweiterter Zahlungsauftrag 

PAYMUL Multipler Zahlungsauftrag 

PAYORD Zahlungsauftrag 

PRDSRC Produktherkunftsinformation 

PRICAT Preisliste/Katalog 

PRIHIS Preisentwicklung 

PRODAT Produktstammdaten 

PRODEX Nachrichten zur Abstimmung von 

Produktüberlassung 

PROINQ Produktdatenanfrage 

PRPAID Versicherungsprämie- 

Zahlungsnachrichten 

QALITY Qualitätsdaten 

QLSPEC Spezifikation 

QUOTES Angebot 

RDRMES Fragebogendaten-Nachricht 

REBORD Rückversicherungsaufstellung 

RECADV Wareneingangsmeldung 

RECALC Rückversicherungsberechnung


RECECO Kreditrisikoübernahme 

RECLAM Rückversicherungsanspruch 

REMADV Zahlungsavis 

REPREM Rückversicherungsprämie 

REQDOC Dokumentenanforderung 

REQOTE Anfrage 

RESETT Rückversicherungsregulierung 

RETACC Rückversicherungskonto 

RETANN Ankündigung der Warenrückgabe 

RETINS Anweisung zur Warenrückgabe 

SAFHAZ Sicherheitsdaten 

SANCRT Verwaltungsnachrichten für 

internationalen Warenverkehr 

SLSFCT Verkaufsprognose 

SLSRPT Verkaufsdatenbericht 

SOCADE Sozialverwaltungs-Nachricht 

SSIMOD Änderung von Identifizierungsmerkmalen 

SSRECH Versicherungshistorie des 

Arbeitnehmers 

SSREGW Mitteilung über die Registrierung eines 

Arbeitnehmers 

STATAC Kontoauszug 

STLRPT Transaktion - Abstimmungsbericht 

SUPCOT Beitragsmeldung zur 

Rentenversicherung 

SUPMAN Nachricht zur Pflege des Pensions-/ 

Rentenbestands 

TANSTA Tank-Statusbericht 

TAXCON Steuernachweis 

VATDEC Mehrwertsteueranmeldung 

VESDEP Abfahrt des Schiffes 

WASDIS Müllentsorgungs-Information 

WKGRDC Bescheid über Arbeitserlaubnis 

WKGRRE Antrag auf Arbeitserlaubnis 


27 von 27

NOTIZEN: 


28 von 28

EDI-Grundlagen (B&N Software) - FH Flensburg

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?