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

Transkript

1 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

2 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

3 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

4 Abb. 1: UN/EDIFACT :Die organisatorische Struktur der Nachrichtenentwicklung und Verabschiedung 4 von 4

5 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

6 (Electronic Data Interchange For Administration, Commerce and Transport) Beispielnachricht des TESTUSER: UNA:+.? ' UNB+UNOA: : EANCOM+1'UNH+1+ORDERS:D:93A:UN:EAN007'BGM 'DTM+137: :102'DTM+2: :102'NAD+ BY ::9'NAD+DP ::9'NAD+SU ::9'LIN :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 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

7 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: : EANCOM+1'UNH+1+ORDERS:D:93A:UN:EAN007'BGM 'DTM+137: :102'DTM+2: :102'NAD+ BY ::9'NAD+DP ::9'NAD+SU ::9'LIN :EN'QTY+21:11.00:PCE'U NS+S'CNT+2:1'UNT+12+1'UNZ+1+11' 7 von 7

8 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: : EANCOM+1'UNH+1+ORDERS:D:93A:UN:EAN007'BGM 'DTM+137: :102'DTM+2: :102'NAD+ BY ::9'NAD+DP ::9'NAD+SU ::9'LIN :EN'QTY+21:11.00'UNS+S 'CNT+2:1'UNT+12+1'UNZ+1+11' Bestellung mit einer Position Datenaustauschreferenznummer 8 von 8

9 Prüfung der Nachricht auf Korrektheit Das UNT Segment ist folgendermassen aufgebaut: Bsp.: UNT ' UNT+Anzahl der in der Nachricht ( UNH UNT) befindlichen Segmente. + 1 UNT 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: : EANCOM+1'UNH+1+ORDERS:D:93A:UN:EAN007'BGM 'DTM+137: :102'DTM+2: :102'NAD+ BY ::9'NAD+DP ::9'NAD+SU ::9'LIN :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

10 Testnachricht : Die aufgeführte Testnachricht dient in dieser Unterlage als Basis für die Empfangs und Sende Template Beispiele. UNA:+.? 'UNB+UNOA: : EANCOM+1'UNH+1+O RDERS:D:93A:UN:EAN007'BGM 'DTM+137: :102'DTM+2: :102' NAD+BY ::9'NAD+DP ::9'NAD+SU ::9'LIN :EN'QTY+21:11.00:PCE'UNS+S'CNT+2:1'UNT+12+1'UNZ+1+11 ' UNA:+.? ' Angabe der Nachrichtenseparatoren UNB+UNOA: : EANCOM+1' Zeichensatz, Adressaten und Ref.Nummer Angabe UNH+1+ORDERS:D:93A:UN:EAN007' Nachrichten-Kopfsegment BGM ' Bestellnummer DTM+137: :102' Datum der Nachricht DTM+2: :102' Lieferdatum NAD+BY ::9' Der Käufer wird durch die ILN identifiziert. NAD+DP ::9' Die Lieferanschrift wird durch die ILN identifiziert. NAD+SU ::9' Der Lieferant wird durch die ILN identifiziert. LIN :EN' Erste Bestellposition durch EAN 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

11 RCV - Template zur Beispielnachricht des TESTUSER (alter Standard): 1 -HEAD- UNB S UNOA PrtNum Absender ILN 2 -HEAD- UNB S UNOA a35# Empfaenger ILN 3 -HEAD- UNB S UNOA a8# Erstellungsdatum 4 -HEAD- UNB S UNOA a6# Erstellungszeit 5 -HEAD- UNB 0020 UNOA 3 11 MsgCtl Datenaustauschreferenznummer 6 -HEAD- UNB 0032 UNOA 3 EANCOM HEAD- UNB 0035 UNOA 3 1 a1# Testkennzeichen 8 ORDERS UNH AppRef Nachrichtenreferenznummer 9 ORDERS UNH S ORDERS D 93A UN EAN ORDERS BGM MaiKey Auftragsnummer 11 ORDERS DTM C a35# Auftragsdatum 12 ORDERS DTM C ORDERS DTM C a35# Lieferdatum 14 ORDERS DTM C ORDERS G02 NAD C BY a17# ILN Besteller 16 ORDERS G02 NAD C BY ORDERS G02 NAD C DP a17# ILN Warenempfaenger 18 ORDERS G02 NAD C DP ORDERS G02 NAD C SU a17# ILN Lieferant 20 ORDERS G02 NAD C SU ORDERS G25 LIN n6# POSITIONSNUMMER 22 ORDERS G25 LIN C a35# EAN Waren-/Artikelnummer 23 ORDERS G25 LIN C EN a3# Artikelnummertyp, codiert 24 ORDERS G25 QTY C np2# Menge 25 ORDERS G25 QTY C PCE a3# Artikelmasseinheit 26 ORDERS CNT C n18# 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

12 RCV - Template zur Beispielnachricht des TESTUSER (neuer Standard): 1 -HEAD- UNB S UNOA (Verwendeter Nachrichtenzeichensatz) 2 -HEAD- UNB S (Syntax Version) 3 -HEAD- UNB S PrtNum Absender ILN 4 -HEAD- UNB S a35# Empfaenger ILN 5 -HEAD- UNB S a8# Erstellungsdatum 6 -HEAD- UNB S a6# Erstellungszeit 7 -HEAD- UNB MsgCtl Datenaustauschreferenznummer 8 -HEAD- UNB 0032 EANCOM HEAD- UNB a1# Testkennzeichen 10 ORDERS UNH AppRef Nachrichtenreferenznummer 11 ORDERS UNH S ORDERS D 93A UN EAN ORDERS BGM MaiKey Auftragsnummer 13 ORDERS DTM C a35# Auftragsdatum 14 ORDERS DTM C ORDERS DTM C a35# Lieferdatum 16 ORDERS DTM C ORDERS G02 NAD C BY a17# ILN Besteller 18 ORDERS G02 NAD C BY ORDERS G02 NAD C DP a17# ILN Warenempfaenger 20 ORDERS G02 NAD C DP ORDERS G02 NAD C SU a17# ILN Lieferant 22 ORDERS G02 NAD C SU ORDERS G25 LIN n6# POSITIONSNUMMER 24 ORDERS G25 LIN C a35# EAN Waren- /Artikelnummer 25 ORDERS G25 LIN C EN a3# Artikelnummertyp, codiert 26 ORDERS G25 QTY C np2# Menge 27 ORDERS G25 QTY C PCE a3# Artikelmasseinheit 28 ORDERS CNT C n18# 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 S / 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

13 SND - Template zur Beispielnachricht des TESTUSER I: 0 C:\MagicApp\Eddy\1_PARTNER.XRL 1 -HEAD- UNB S a35# Absender ILN 2 -HEAD- UNB S PrtNum Empfaenger ILN 3 -HEAD- UNB F_DAREF Datenaustauschreferenznummer 4 -HEAD- UNB 0032 EANCOM K#EAN HEAD- UNB a1# Testkennzeichen 6 ORDERS UNH F_NAREF Nachrichtenreferenznummer 7 ORDERS UNH S EAN007 K#EAN ORDERS BGM C K# ORDERS BGM MaiKey Auftragsnummer 10 ORDERS DTM C K# ORDERS DTM C a35# Auftragsdatum JJJJMMDD 12 ORDERS DTM C K# ORDERS DTM C K# ORDERS DTM C a35# Lieferdatum JJJJMMDD 15 ORDERS DTM C K# ORDERS G02 NAD 3035 BY K#BY ORDERS G02 NAD C a17# ILN Besteller 18 ORDERS G02 NAD C K# ORDERS G02 NAD 3035 DP K#DP ORDERS G02 NAD C a17# ILN Warenempfaenger 21 ORDERS G02 NAD C K# ORDERS G02 NAD 3035 SU K#SU ORDERS G02 NAD C a17# ILN Lieferant 24 ORDERS G02 NAD C K# ORDERS G25 LIN n6# POSITIONSNUMMER 26 ORDERS G25 LIN C a35# EAN Waren-/ Artikelnummer 27 ORDERS G25 LIN C EN a3# Artikelnummertyp, codiert 28 ORDERS G25 QTY C K# ORDERS G25 QTY C np2# Menge 30 ORDERS G25 QTY C PCE a3# Artikelmasseinheit 31 ORDERS UNS 0081 S K#S ORDERS CNT C K# ORDERS CNT C n18# 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 die Zahl verwendet wird. 13 von 13

14 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: N 2 # * Beispielmöglichkeiten 90 INVOIC G25 IMD 7077 K#C #. 91 INVOIC G25 IMD C a3# < * falls Leergut : RC 92 INVOIC G25 QTY C K# bestellte Menge 93 INVOIC G25 QTY C np5# N 4 berechnete Menge 94 INVOIC G25 QTY C a3# Maßeinheit Menge 95 INVOIC G25 G26 MOA C K# #. 96 INVOIC G25 G26 MOA C np2# J < * Artikel - Bruttobetrag 97 INVOIC G25 G26 MOA C K# INVOIC G25 G26 MOA C np2# 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

15 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 C a35# Nachrichtendatum (CCYYMMDD) 18 ORDERS DTM C ORDERS DTM C SQ_a3#10;102=a35#12;401=a6# Lieferdatum/-zeit, fruehestes 20 ORDERS DTM C a3# Qual. Lieferdatum/-zeit, fruehestes 21 ORDERS DTM C SQ_a3#11;102=a35#11;401=a6# Lieferdatum/-zeit, spaetestes 22 ORDERS DTM C a3# Qual. Lieferdatum/-zeit, spaetestes 23 ORDERS DTM C a35# Liefertermin, gefordert (CCJJMMTT) 24 ORDERS DTM C 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

16 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 von 16

17 Umsetzungstabelle PartnerID für RCV und SND - Nachrichten Bsp.01: 22 ORDERS G02 NAD C SU P_a35#06_I ILN/BBN des Lieferanten 23 ORDERS G02 NAD C SU ORDERS G02 NAD C BY P_a35#07_I ILN der Niederlassung 25 ORDERS G02 NAD C BY ORDERS G02 NAD C IV P_a35#08_I ILN BAHAG AG /(Rechnungsempfänger) 27 ORDERS G02 NAD C IV 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

18 Umsetzungstabelle für die EAN für RCV und SND - Nachrichten 33 ORDERS G25 LIN 1082 n6# Positionsnummer 34 ORDERS G25 LIN C P_a35#01_E EAN-Nummer 35 ORDERS G25 LIN C EN 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

19 Umsetzungstabelle Masseinheiten für RCV und SND - Nachrichten Befüllung der STDDAT durch Umsetztabellen Bsp.01: 99 INVOIC G25 QTY C K# # 100 INVOIC G25 QTY C np5# J4#* berechnete Menge 101 INVOIC G25 QTY C P_a3#01_M < Masseinheit der berechneten Menge, Qual.z.B. PCE=Stueck 102 INVOIC G25 QTY C K# # 103 INVOIC G25 QTY C np5# J4#* falls Upos: Anzahl der Verbrauchereinheiten 104 INVOIC G25 QTY C P_a3#02_M < falls Upos: Masseinheit der Verbrauchereinheit 105 INVOIC G25 QTY C K# # 106 INVOIC G25 QTY C np5# J4#* Menge ohne Berechnung 107 INVOIC G25 QTY C P_a3#11_M < Masseinheit der Menge ohne Berechnung, z.b. PCE=Stuec Bsp.02: 112 INVOIC G25 G28 PRI C K#AAB # 113 INVOIC G25 G28 PRI C np5# J4#* Artikel-Bruttopreis 114 INVOIC G25 G28 PRI C n9# J # Preisbasis-Menge 115 INVOIC G25 G28 PRI C P_a3#01_M < Masseinh der Preisba.-Menge, Qual.z.B. PCE=Stueck Bsp.03: 168 INVOIC G15 ALC 5463 P_a3#01_M A-Abschlag / C-Zuschlag 169 INVOIC G15 ALC C a35# Zu- oder Abschlag, Nummer / Bilateral zu vereinbaren 170 INVOIC G15 ALC 1227 n8# J Kalkulations-Folge-Anzeiger, (Rabattstufe) 171 INVOIC G15 ALC C a3# 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

20 EDIFACT Schulung: KOPFINFORMATIONEN: UNA : +.? ' UNB + UNOA : : EANCOM + 1 ' UNH ORDERS : D : 93A : UN : EAN007 ' BGM ' DTM : : 102 ' DTM + 2 : : 102 ' NAD + BY : : 9 ' 20 von 20

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

22 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

23 Anhang II ISO-Tabelle /Teil 1 Nach 9735 deklariert: UNOC ist definiert in ISO /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 ü = ØØ = Ø DØ D C Ü = 11Ø1 11ØØ = Ø22Ø 9A 5A liegt im erlaubten Bereich, ß = 11Ø = Ø223 jedoch unlesbar A1 F 6 ö = 1111 Ø11Ø = Ø A D 6 Ö = 11Ø1 O11Ø = Ø EØ E 4 ä = 111Ø Ø1ØØ = Ø 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

24 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 Gewichtungsfaktoren x3 3 4 = 21 x = = 40 Beispiel-Nr2: ILN Markant Gewichtungsfaktoren x = 33 x = = 50 Beispiel-Nr3: ILN HAGEBAU Gewichtungsfaktoren x3 7 7 = 42 x = = 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

25 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

26 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

27 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

28 NOTIZEN: 28 von 28