Ende der 60er Jahre: Die US. amerikanische Transportbranche entwickelt erste Standards für EDI Nachrichten

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. 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) ANSI X.12 (USA) TRADACOM (England) 2 von 2

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). <Leerzeichen> 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

Syntax einer Nachricht. Bevor es zu irgendeinem Datenaustausch per EDIFACT kommt, muss eine Absprache getroffen werden, mit welcher SYNTAX der Austausch stattfinden soll. Syntax einer Nachricht. 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 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' 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 Nachrichtenreferenznummer 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'UNS+S 'CNT+2:1'UNT+12+1'UNZ+1+11' Bestellung mit einer Position 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 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' Anzahl der in der Nachricht ( UNH UNT) befindlichen Segmente. Anzahl der Nachrichten innerhalb einer Mehrfachnachricht 9 von 9

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' Zeichensatz, Adressaten und Ref.Nummer Angabe 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' UNS+S' CNT+2:1' UNT+12+1' UNZ+1+11 ' Es werden 11 Einheiten bestellt Abschnitts-Kontrollsegment Abstimmsumme Die Nachricht enthält 1 Position Nachrichten - Endesegment Die Nachricht enthält 12 Segmente 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 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. 11 von 11

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 18 ORDERS G02 NAD C082 3055 BY 9 100000000 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 22 ORDERS G02 NAD C082 3055 SU 9 100000000 23 ORDERS G25 LIN 1082 1 n6#1 150000000 POSITIONSNUMMER 24 ORDERS G25 LIN C212 7140 1122334455667 a35#01 150000000 EAN Waren- /Artikelnummer 25 ORDERS G25 LIN C212 7143 EN a3#01 150000000 Artikelnummertyp, codiert 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. 12 von 12

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 25 ORDERS G25 LIN 1082 1 n6#1 150000000 POSITIONSNUMMER 26 ORDERS G25 LIN C212 7140 1122334455667 a35#01 150000000 EAN Waren-/ Artikelnummer 27 ORDERS G25 LIN C212 7143 EN a3#01 150000000 Artikelnummertyp, codiert 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. 13 von 13

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 (<) 3 = soll in einem Feld mit Nachkomma-. stellen nur eine bestimmte Anzahl der Nachkommastellen übertragen werden. wird hier die gewünschte Anzahl ein-. getragen... 2 = Null-Werte übertragen. ö. J = Nullwerte werden unterdrückt.. N = Nullwerte werden übertragen.. 1 = leer. 14 von 14

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. 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. 15 von 15

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 23 ORDERS G02 NAD C082 3055 SU 9 100000000 24 ORDERS G02 NAD C082 3039 BY P_a35#07_I 100000000 ILN der Niederlassung 25 ORDERS G02 NAD C082 3055 BY 9 100000000 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 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. 19 von 19

EDIFACT Schulung: KOPFINFORMATIONEN: UNA : +.? ' UNB + UNOA : 2 + 1234567890123 + 3456789012345 + 030519 : 1552 + 11 + + + + + EANCOM + 1 ' UNH + 1 + ORDERS : D : 93A : UN : EAN007 ' BGM + 220 + 1234567 ' DTM + 137 : 20030519 : 102 ' DTM + 2 : 20030530 : 102 ' NAD + BY + 5678901234567 : : 9 ' 20 von 20

NAD + DP + 6789012345678 : : 9 ' NAD + SU + 7890123456789 : : 9 POSITIONSINFORMATIONEN : LIN + 1 + + 1122334455667 : EN ' QTY + 21 : 11.00 : PCE ' UNS + S ' CNT + 2 : 1 UNT + 11 + 1 ' UNZ + 1 + 11 ' 21 von 21

Anhang I Verzeichnis der Abkürzungen ANSI CCG CEN/ISSS CSS DOM DTD EDI HTML ODETTE SEDAS SGML SWIFT TRADACOMS American National Standards Institute Centrale für Coorganisation Centre for European Normalisation/Information Society Standardization System Cascade Style Sheet Document Object Model Document Type Definition Elektronic Data Interchange Hypertext Markup Language Organisation for Data Exchange by Teletransmission in Europe Standardregelungen Einheitlicher Datenaustauschsysteme Standardized General Markup Language Society for Worldwide Interbank Financial Telecommunication Trading Data Communications Standards UN/CEFACT United Nations/Centre for Facilitation of Procedures and Practices for Administration, Commerce and Transport UN/ECE UN/EDIFACT VDA W3C XML XSL XLL United Nations/Economic Comission for Europe United Nations/Electronic Data Interchange for Administration, Commerce and Transport Verband der Automobilindustrie World Wide Web Consortium Extensible Markup Language Extensible Style Sheet 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 ü ä ö 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

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 4 = 21 x1 4 3 4 = 11 32 32 + 8 = 40 Beispiel-Nr2: ILN Markant 4 3 0 4 4 4 9 0 0 0 0 0 0 Gewichtungsfaktoren x3 3 4 4 = 33 x1 4 4 9 = 17 50 50 + 0 = 50 Beispiel-Nr3: ILN HAGEBAU 9 0 0 7 4 7 0 0 4 0 4 0 7 Gewichtungsfaktoren x3 7 7 = 42 x1 9 4 4 4 = 21 63 63 + 7 = 70 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 ". 24 von 24

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 Bezeichner Nachrichtentyp APERAK AUTACK AUTHOR BALANC BANSTA BAPLIE BAPLTE BOPBNK BOPCUS BOPDIR BOPINF BOPSTA CALINF CASINT CASRES CHACCO CHAMAP CNTCND COARRI CODECO CODENO COEDOR COHAOR COLADV Anwendungsfehler- und Bestätigungs-Nachricht Sicherheits-Authentisierung und -Bestätigung Autorisierungs-Nachricht Rohbilanz Bank-Status-Nachricht Ladeplan über leere und besetzte Zellen Ladeplan über Gesamtzahl Meldungen über Außenwirtschaftstransaktionen und den Auslandsstatus der Banken an die Zentralbank Weiterleitung von Meldungen über Auslandszahlungen der Bankkunden an die Zentralbank Zahlungsbilanzmeldungen von Nichtbanken direkt an die Zentralbank Meldung über eingehende Auslandszahlungen von Bankkunden an ihre Geschäftsbank Austausch von Zahlungsbilanzstatistiken zwischen Zentralbank und internationalen Organisationen Schiffsinformation Antrag auf gerichtliches Tätigwerden in Zivilprozessen Stellungnahme des Gerichts in Zivilprozessen Kontenrahmen Zuordnungstabelle Vertragsbedingungen Container - Lösch-/Ladebericht Container-Terminal-Eingangs-/ Ausgangsmeldung Bescheid über Ablauf der Genehmigung/Zollfreigabe Container-Bestandsbericht Auftrag zur besonderen Behandlung eines Containers Avisierung eines Dokumenteninkasso COLREQ COMDIS CONAPW CONDRA CONDRO CONDPY CONEST CONIT CONPVA CONQVA CONRPW CONTEN CONTR CONWQD COPARN COPINO COPRAR COREOR COSTCO COSTOR CREADV CREEXT CREMUL CUSCAR CUSDEC CUSEXP CUSPED CUSREP CUSRES DEBAV DEBMUL DELFOR DELJIT DESADV DESTIM DGRECA DIRDEB Auftrag für ein Dokumenteninkasso Handelsunstimmigkeit Ankündigung von beabsichtigten Bauarbeiten Zeichnungsverwaltung Zeichnungsorganisation Verkürzte Baurechnung Auftragserteilung Angebotsaufforderung Baurechnung Bauleistungsstand Antwort auf die Ankündigung von beabsichtigten Bauarbeiten Angebotsangabe Syntax- und Servicebericht Mengenermittlung Container-Ankündigung Container-Voranzeige Container - Lösch-/Ladeauftrag Container-Freistellungsanweisung Bestätigung über das Be-/Entladen von Containern Auftrag zum Be-/Entladen von Containern Gutschriftanzeige Erweiterte Gutschriftanzeige Multiple Gutschriftanzeige Zoll-Gestellungsmitteilung Zollanmeldung Zollanmeldung für Expressgut Sammelzollmeldung Zoll-Beförderungsmitteilung Zollantwort Belastungsanzeige Multiple Belastungsanzeige Lieferabruf/-plan Feinabruf Liefermeldung Ausrüstungsschäden und Reparaturvoranschlag Gefahrgutliste Lastschrift 25 von 25

Bezeichner Nachrichtentyp Bezeichner Nachrichtentyp DIRDEF DOCADV DOCAMA DOCAMI DOCAMR DOCAPP DOCARE DOCINF ENTREC FINCAN FINPAY FINSTA GENRAL GESMES HANMOV Verzeichnis-Definition Avisierung eines Dokumentenakkreditives Avisierung einer Änderung eines Dokumentenakkreditives Information über die Änderung eines Dokumentenakkreditives Beantragung einer Änderung eines Dokumentenakkreditives Antrag zur Eröffnung eines Dokumentenakkreditives Rückantwort zu einer Änderung eines Dokumentenakkreditives Information über die Eröffnung eines Dokumentenakkreditives Buchungssatz Storno-Nachricht Multipler Interbank - Zahlungsauftrag Bankkontoauszug Allgemeine Nachricht Allgemeine Statistische Nachricht Nachricht für den Ladungs-/ JAPRES JIBILL JINFDE JOBAPP JOBCON JOBMOD JOBOFF LEDGER LREACT MEDPID MEDREQ MEDRPT MEDRUC MEQPOS MOVINS MSCONS Bewerbungsergebnis Abrechnung für Anteilseigner Anfrage nach Stelleninformation Bewerbungsvorschlag Empfangsbestätigung und Stellenangebote Änderung von Stellenangeboten Stellenangebot Hauptbuch/Handelsbuch Lebens-Rückversicherungsaktionsnachricht Personenidentifikation Anforderung einer medizinischen Leistung Bericht medizinischer Leistungserbringer Inanspruchnahme medizinischer Leistungen und deren Kosten Nachrichten zur Angabe der Position eines Transportmittels und einer Equipments Stauanweisung Bericht über den Verbrauch messbarer Dienstleistungen IFCSUM IFTCCA IFTDGN IFTFCC IFTIAG IFTMAN IFTMBC IFTMBF IFTMBP IFTMCS IFTMIN IFTRIN IFTSAI IFTSTA IFTSTQ IMPDEF INFENT INSDES INSPRE INSREQ INSRPT INVOIC ITRRPT Güterumschlag und transport Speditions- und Sammelladungs- Nachricht Speditions- und Transport- Sendungskosten-Kalkulation Gefahrengutanmeldung Transport-Frachtkosten und andere Gebühren Gefahrgutliste Ankunftsmeldung Buchungs-/Reservierungsbestätigung Buchung/Reservierung Buchungs-/Reservierungsanfrage Auftragsbestätigung/Statusmeldung Transport-/Speditionsauftrag Speditions- und Transportraten- Information Speditions- und Transportzeitplan und Verfügbarkeits-Information Multimodaler Statusbericht Anforderung eines multimodalen Statusberichts EDI Anwendungsrichtlinien-Definition Unternehmensinformation Lieferanweisung Versicherungsprämien-Nachricht Prüfaufforderung Prüfbericht Rechnung INVRPT Lagerbestandsbericht Bericht über Ware im Transit ORDCHG ORDERS ORDRSP OSTENQ OSTRPT PARTIN PAXLST PAYDUC PAYEXT PAYMUL PAYORD PRDSRC PRICAT PRIHIS PRODAT PRODEX PROINQ PRPAID QALITY QLSPEC QUOTES RDRMES REBORD RECADV RECALC Bestelländerung Bestellung Bestellantwort Bestellstatusanfrage Bestellstatusbericht Partnerstammdaten Passagier-/Besatzungsliste Gehaltsabzugsavis Erweiterter Zahlungsauftrag Multipler Zahlungsauftrag Zahlungsauftrag Produktherkunftsinformation Preisliste/Katalog Preisentwicklung Produktstammdaten Nachrichten zur Abstimmung von Produktüberlassung Produktdatenanfrage Versicherungsprämie- Zahlungsnachrichten Qualitätsdaten Spezifikation Angebot Fragebogendaten-Nachricht Rückversicherungsaufstellung Wareneingangsmeldung Rückversicherungsberechnung 26 von 26

Bezeichner RECECO RECLAM REMADV REPREM REQDOC REQOTE RESETT RETACC RETANN RETINS SAFHAZ SANCRT SLSFCT SLSRPT SOCADE SSIMOD SSRECH SSREGW STATAC STLRPT SUPCOT SUPMAN TANSTA TAXCON VATDEC VESDEP WASDIS WKGRDC WKGRRE Nachrichtentyp Kreditrisikoübernahme Rückversicherungsanspruch Zahlungsavis Rückversicherungsprämie Dokumentenanforderung Anfrage Rückversicherungsregulierung Rückversicherungskonto Ankündigung der Warenrückgabe Anweisung zur Warenrückgabe Sicherheitsdaten Verwaltungsnachrichten für internationalen Warenverkehr Verkaufsprognose Verkaufsdatenbericht Sozialverwaltungs-Nachricht Änderung von Identifizierungsmerkmalen Versicherungshistorie des Arbeitnehmers Mitteilung über die Registrierung eines Arbeitnehmers Kontoauszug Transaktion - Abstimmungsbericht Beitragsmeldung zur Rentenversicherung Nachricht zur Pflege des Pensions-/ Rentenbestands Tank-Statusbericht Steuernachweis Mehrwertsteueranmeldung Abfahrt des Schiffes Müllentsorgungs-Information Bescheid über Arbeitserlaubnis Antrag auf Arbeitserlaubnis 27 von 27

NOTIZEN: 28 von 28