EANCOM-Handbuch

EANCOM-Handbuch
Einleitung
1 EINLEITUNG ..................................................................................................... 1-7
1.1 EDI - der elektronische Datenaustausch........................................................................1-7
1.2 Einführung und Grundlagen...........................................................................................1-8
1.3 UN/EDIFACT als strategisches Instrument ....................................................................1-8
1.4 Kriterien für eine UN/EDIFACT Implementierung ..........................................................1-9
1.5 Entwicklung und aktuelle Situation .............................................................................1-10
2 WAS IST EDI ? ................................................................................................ 2-12
2.1 Was ist EDI nicht ? ........................................................................................................2-12
2.2 Entstehungsgeschichte ................................................................................................2-13
2.3 Nutzen von EDI ..............................................................................................................2-14
2.3.1 Operationeller Nutzen:..............................................................................................2-14
2.3.2 Strategischer Nutzen: ...............................................................................................2-14
2.4 Risiken von EDI .............................................................................................................2-15
2.5 Hat EDI eine strategische Bedeutung? ........................................................................2-15
2.5.1 Welche Technologie wird benötigt? ..........................................................................2-16
2.5.2 Konverter.................................................................................................................. 2-16
2.5.3 Enabling-Software ....................................................................................................2-16
2.5.4 Verfügbare Schulung und Unterstützung...................................................................2-17
2.6 Wie beeinflusst EDI das Geschäft? ..............................................................................2-17
2.7 Welche Kosten entstehen? ...........................................................................................2-18
2.8 Wie wird EDI eingeführt? ..............................................................................................2-18
3 STANDARDS................................................................................................... 3-20
3.1 UN/EDIFACT................................................................................................................... 3-20
3.2 ANSI X.12 .......................................................................................................................3-20
3.3 EANCOM ........................................................................................................................ 3-21
4 DAS PROJEKT EANCOM-CH ........................................................................ 4-22
4.1 Umfang und Ziele ..........................................................................................................4-23
4.1.1 Message Design .......................................................................................................4-23
4.1.2 Ablauf Design ...........................................................................................................4-23
4.1.3 Datenbanken ............................................................................................................4-23
4.2 Projektorganisation.......................................................................................................4-23
4.2.1 Arbeitsgruppen .........................................................................................................4-23
4.2.2 Messagedesign.........................................................................................................4-24
4.2.3 EDIFICAS.................................................................................................................4-24
4.2.4 Stammdaten.............................................................................................................4-24
4.2.5 Kommunikation.........................................................................................................4-24
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 1-1

EANCOM-Handbuch
Einleitung
4.2.6 EANCOM-CH UserGroup (EUG)...............................................................................4-24
4.3 Dokumentation ..............................................................................................................4-24
4.4 Die Ansprechpartner .....................................................................................................4-25
4.4.1 EAN (Schweiz, Suisse, Svizzera)..............................................................................4-25
4.4.2 EANCOM-CH Projektleitung .....................................................................................4-25
4.4.3 EANCOM-CH UserGroup .........................................................................................4-25
4.5 EANCOM-CH Ausbildung..............................................................................................4-26
4.5.1 Grundausbildung ......................................................................................................4-26
4.5.2 Informationstagungen ...............................................................................................4-26
5 DIE CLEARING-HOUSES ............................................................................... 5-27
6 DER ENTSCHEID............................................................................................ 6-28
6.1 Unternehmensstrategie.................................................................................................6-28
6.2 Voraussetzungen...........................................................................................................6-28
6.2.1 Geschäftsleitung.......................................................................................................6-29
6.2.2 Mitarbeiter ................................................................................................................ 6-29
6.2.3 Informatik ................................................................................................................. 6-29
6.3 Erfolgsfaktoren.............................................................................................................. 6-29
6.3.1 Wettbewerbsvorteile .................................................................................................6-29
6.3.2 Rationalisierungspotential .........................................................................................6-29
6.3.3 Neue Struktur der Geschäftsabläufe .........................................................................6-30
6.4 Erweiterte Überlegungen ..............................................................................................6-30
6.4.1 Einkauf ..................................................................................................................... 6-30
6.4.2 Verkauf..................................................................................................................... 6-30
7 DAS PROJEKT................................................................................................ 7-32
7.1 Die Partner-Organisation ..............................................................................................7-32
7.2 Analyse der betroffenen Geschäftsabläufe..................................................................7-32
7.3 Analyse der betroffenen Anwendungen.......................................................................7-32
7.3.1 Evaluation der Hilfsmittel..........................................................................................7-32
7.4 Clearing-House..............................................................................................................7-33
7.5 Netzwerk.........................................................................................................................7-36
7.6 EDI-Konverter ................................................................................................................7-36
7.7 Übermittlungs-Software ................................................................................................7-36
8 REALISIERUNG .............................................................................................. 8-38
8.1 Zeitplan ..........................................................................................................................8-38
8.2 Checkpoints................................................................................................................... 8-38
8.3 Koordination.................................................................................................................. 8-39
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 1-2

EANCOM-Handbuch
Einleitung
8.4 EDI-Umgebung - Eigenentwicklung .............................................................................8-39
8.5 Anwendungsanpassung ...............................................................................................8-40
8.6 Enabling-Applikation.....................................................................................................8-41
8.7 Test.................................................................................................................................8-41
8.8 Sicherheit.......................................................................................................................8-42
8.9 Schulung und Dokumentation......................................................................................8-42
8.10 Produktion .....................................................................................................................8-43
9 DIE EDIFACT-SERVICESEGMENTE.............................................................. 9-45
9.1 Ausgangslage................................................................................................................9-45
9.2 Identifikation Datenaustausch......................................................................................9-45
9.3 Identifikation Nachrichten.............................................................................................9-46
9.4 Identifikation Anwendung (Geschäftsfall)....................................................................9-46
9.5 Strukturierung Datenaustausch....................................................................................9-47
9.6 Strukturierung Nachricht ..............................................................................................9-48
9.7 Kommunikation und EDIFACT......................................................................................9-48
9.8 Zeichensätze.................................................................................................................. 9-48
10 DIE MESSAGES CONTROL UND GENRAL.............................................. 10-49
10.1 Ausgangslage.............................................................................................................. 10-49
10.2 Die Control-Message (CONTRL) ................................................................................. 10-49
10.3 Die General-Message (GENRAL)................................................................................. 10-50
10.4 Anwendung der Messages CONTRL und GENRAL................................................... 10-50
10.4.1 Anwendung 1: Bereitschaftskontrolle („Are you alive?“) .......................................... 10-50
10.4.2 Anwendung 2: Annahme/Abweisung eines Datenaustauschs .................................. 10-51
10.4.3 Anwendung 3: Syntax-Kontrolle der Nachrichten eines Datenaustauschs................ 10-51
10.4.4 Anwendung 4: Annahme/Abweisung eines Datenaustauschs mit Syntax-Kontrolle der
Nachrichten .......................................................................................................................... 10-51
11 BESTELLUNGEN....................................................................................... 11-52
11.1 Bestellung (PURCHASE ORDER)................................................................................ 11-52
11.2 Bestellantwort (ORDER RESPONSE) ......................................................................... 11-53
11.3 Bestelländerung oder Bestellstornierung (ORDER CHANGE).................................. 11-54
12 RECHNUNGEN .......................................................................................... 12-55
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 1-3

EANCOM-Handbuch
Einleitung
12.1 EDI und Mehrwertsteuer.............................................................................................. 12-55
12.1.1 Zu diesem Dokument.............................................................................................. 12-55
12.1.2 Grundlagen............................................................................................................. 12-55
12.1.3 Grundsätzliche Anforderungen aus Sicht der Steuerverwaltung .............................. 12-56
12.1.4 Welche Lösungsvarianten erfüllen die Anforderungen der Steuerverwaltung? ........ 12-56
12.1.5 Aufzeichnung auf Papier oder Mikrofiche................................................................ 12-56
12.1.6 Nachweis mittels Journal auf Papier oder Mikrofiche .............................................. 12-57
12.1.7 Nachweis mittels elektronisch gesichert übermitteltem Journal ............................... 12-57
12.1.8 Übermittlung der einzelnen Belege mit gesicherter EDI-Übertragung...................... 12-57
12.1.9 Anforderungen der Steuerverwaltung an die elektronische Datenübermittlung ........ 12-58
12.1.10 Anforderungen der Steuerverwaltung an die elektronische Buchführung ............. 12-58
13 MEHRWERTSTEUER: PAPIERLOSER RECHNUNGSDATENAUSTAUSCH13-59
14 ZAHLUNGSVERKEHR............................................................................... 14-60
14.1 Grundsatz .................................................................................................................... 14-60
14.2 Vorteile......................................................................................................................... 14-60
14.3 Anwendungsrichtlinien............................................................................................... 14-61
14.3.1 Directory................................................................................................................. 14-61
14.3.2 Dokumentreferenzen .............................................................................................. 14-61
14.3.3 REMADV - Remitance Advice ................................................................................ 14-61
14.4 EANCOM im Umfeld der Banken ................................................................................ 14-62
14.4.1 Location Numbers................................................................................................... 14-63
14.4.2 Bankkonto .............................................................................................................. 14-63
14.5 Kommunikation ........................................................................................................... 14-64
14.6 Sicherheit..................................................................................................................... 14-64
14.7 Financial Messages..................................................................................................... 14-65
15 EDI UND TRANSPORT .............................................................................. 15-66
15.1 Zu diesem Dokument .................................................................................................. 15-66
15.1.1 D.96A ..................................................................................................................... 15-66
15.2 Geschäftsfälle.............................................................................................................. 15-66
15.3 UN/EDIFACT Referenzen für den Transport............................................................... 15-68
15.4 Begriffe / Definitionen ................................................................................................. 15-69
15.4.1 Prinzipien / Regeln ................................................................................................. 15-72
16 BETRIEB .................................................................................................... 16-73
16.1 Ablaufdesign................................................................................................................ 16-73
16.1.1 Plausibilisierung...................................................................................................... 16-73
16.1.2 Verfolgung von EDI-Nachrichten............................................................................. 16-73
16.1.3 Vollständigkeitskontrollen ....................................................................................... 16-74
16.1.4 Rückmeldungsfunktionen........................................................................................ 16-76
16.2 Absprachen mit dem EDI-Partner ............................................................................... 16-77
16.2.1 EAIN - EAN ............................................................................................................ 16-77
16.2.2 Behandlung von Fehlern in der Übermittlung .......................................................... 16-77
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 1-4

EANCOM-Handbuch
Einleitung
16.2.3 Behandlung von Fehlern in den Dokumenten.......................................................... 16-77
16.2.4 Verantwortung für den Empfang von Nachrichten ................................................... 16-78
16.2.5 Wartung, Versionen, Releases................................................................................ 16-78
16.2.6 Was geschieht mit Testübermittlungen ................................................................... 16-78
16.3 Absprachen mit dem Clearinghouse.......................................................................... 16-79
16.4 Benutzerrichtlinien ...................................................................................................... 16-79
16.5 Operating-Richtlinien .................................................................................................. 16-80
16.6 Wiederholungen .......................................................................................................... 16-81
17 EDIFACT MELDUNGSVERMITTLUNG UND -KONTROLLE........................ 17-83
17.1 Ausgangslage.............................................................................................................. 17-83
17.1.1 OFTP .....................................................................................................................17-83
17.1.2 X.400 IPM............................................................................................................... 17-83
17.1.3 SNA........................................................................................................................ 17-83
17.2 Schwächen von OFTP, P2/Tedis und SNA................................................................. 17-84
17.2.1 Schwächen von OFTP............................................................................................ 17-84
17.2.2 Schwächen von P2/Tedis........................................................................................ 17-84
17.2.3 Schwächen von SNA .............................................................................................. 17-84
17.2.4 Schwächen bei Gateway-Funktionen von Clearing-Centers .................................... 17-84
17.3 Vorteile von X.435........................................................................................................ 17-85
17.4 Meldungskontrolle....................................................................................................... 17-85
17.4.1 Verwendung von EDI-Notifikationen ....................................................................... 17-86
17.4.2 Verwendung von EDI-Notifikationen bei Gateway-Systemen .................................. 17-86
17.4.3 Grundregeln für das Internetworking ....................................................................... 17-87
17.5 Regeln für die EDI-Meldungskontrolle ....................................................................... 17-87
17.5.1 ................................................................................................................................... 17-88
17.5.2 Direktkommunikation über X.435 (ohne Clearing-Center)........................................ 17-88
17.5.3 Homogene X.435-Umgebung mit Clearing-Center .................................................. 17-92
17.5.4 Heterogene Umgebung mit einem Clearing-Center................................................. 17-96
17.5.5 Heterogene Umgebung mit zwei Clearing-Centers, X.435 -> FT ......................... 17-101
17.5.6 Heterogene Umgebung mit zwei Clearing-Centers, FT -> X.435 ......................... 17-105
17.5.7 Heterogene Umgebung mit CONTRL-Message..................................................... 17-106
17.6 Anhang A ................................................................................................................... 17-110
17.6.1 Non-Delivery Reason Codes gemäss X.400 (1988), Anhang A.1........................... 17-110
17.6.2 Non-Delivery Diagnostic Codes gemäss X.400 (1988), Anhang A.2 ...................... 17-111
17.6.3 Negative Notification Reason Codes gemäss X.435 (1991), Anhang A.3 .............. 17-113
17.6.4 Negative Notification Diagnostic Codes gemäss X.435 (1991), Anhang A.4.......... 17-114
18 DATA INTERCHANGE AGREEMENT (DIA)............................................ 18-115
18.1 Gegenstand................................................................................................................ 18-116
18.2 Nachrichtenstandard................................................................................................. 18-116
18.3 Nachrichtenstruktur .................................................................................................. 18-116
18.4 Verantwortung ........................................................................................................... 18-116
18.5 Verbindlichkeit........................................................................................................... 18-117
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 1-5

EANCOM-Handbuch
Einleitung
18.6 Datenschutz ............................................................................................................... 18-117
18.7 Aufbewahrungsvorschriften ..................................................................................... 18-117
18.8 Datensicherung ......................................................................................................... 18-117
18.9 Verfahrensänderungen.............................................................................................. 18-117
18.10 Verfügbarkeit.......................................................................................................... 18-117
18.11 Störungen............................................................................................................... 18-118
18.12 Logische Prüfung von Reihenfolge und Vollständigkeit..................................... 18-118
18.13 Kosten..................................................................................................................... 18-118
18.14 Dauer der Vereinbarung......................................................................................... 18-118
18.15 Schlussbestimmungen .......................................................................................... 18-118
18.16 Anwendbares Recht............................................................................................... 18-119
18.17 Anhänge ................................................................................................................. 18-119
18.17.1 ANHANG 1 Vereinbarung der Nachrichtentypen und Standard.......................... 18-119
18.17.2 ANHANG 2 Nachrichtenstrukturen ORDERS, ORDRSP, INVOIC...................... 18-119
18.17.3 ANHANG 3 Behandlung von Fehlern und Störungen......................................... 18-121
18.17.4 ANHANG 4 Partnererkennungen, Adressangaben und Locationcodes............... 18-122
18.17.5 ANHANG 5 Kontaktpersonen und Adressangaben der beteiligten Partner ......... 18-123
18.17.6 ANHANG 6 Uebertragungswiederholungen ....................................................... 18-124
18.17.7 ANHANG 7 Message-Typ unabhängige Prüfungen............................................ 18-124
18.17.8 ANHANG 8 Weitere Vereinbarungen................................................................. 18-125
19 CHECKLISTEN......................................................................................... 19-126
19.1 Aktivitätenliste Basiseinführung .............................................................................. 19-126
20 ADRESSEN .............................................................................................. 20-128
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 1-6

EANCOM-Handbuch
Einleitung
1 Einleitung
1.1 EDI - der elektronische Datenaustausch
Mit der Deregulierung und Globalisierung der Märkte, der Öffnung des Ostens und
durch den europäischen Binnenmarkt wachsen Beschaffungsmärkte und Absatzmärkte
in zunehmendem Masse, wodurch der Wettbewerb neue Impulse erhält.
Ob wir das wollen oder nicht, auch wir in der Schweiz sind davon betroffen und haben
uns mit diesen neuen Gegebenheiten auseinanderzusetzen.
Mit dem immer grösser werdenden Konkurrenzdruck wird internationale Wettbewerbsfähigkeit
schon heute als Voraussetzung für langfristigen Erfolg angesehen.
Von Unternehmen werden erhöhte Flexibilität und kurze Reaktionszeit gefordert
(Stichwort ECR), wodurch die exakte und zeitgerechte Bereitstellung von Informationen
zu einem entscheidenden Wettbewerbsfaktor wird. Diesen Anforderungen
können Unternehmen nur durch den Einsatz moderner Kommunikations- und Informationstechnologie
gerecht werden. Unternehmen sind gezwungen, zur Stärkung
ihrer Wettbewerbsfähigkeit ihre Kommunikationsbeziehungen zu ihren Geschäftspartnern
zu optimieren.
Eine reduzierte Bürokratie soll die zügigere und rationellere Abwicklung des Warenverkehrs
ermöglichen. Dadurch gewinnt auch der elektronische Datenaustausch
in starkem Masse an Bedeutung. Gerade die ungeheure Papierflut von Verträgen,
Lieferbedingungen und Rechnungen ist für den nationalen und internationalen
Handel ein bisher viel zu wenig beachteter Kostenfaktor. Im Durchschnitt (Zahlen
aus Deutschland, bei uns werden sie jedoch nicht gross abweichen) gehen Fr.
600.- pro Warenladung bei der Abwicklung von Zollformalitäten verloren. Die Herstellung
eines 13-Tonnen-Flugzeuges verschlingt 20 Tonnen Formulare und Dokumente.
Bei einem internationalen Handelsgeschäft erstellen durchschnittlich 27
verschiedene Parteien rund 40 Originaldokumente, von denen wiederum rund 300
Kopien produziert werden. 200 verschiedene Daten werden festgehalten, 30 davon
tauchen rund 620mal in den verschiedenen Dokumenten wieder auf. 30% der gesamten
Dokumentation betreffen ausschliesslich den Warentransport. Insgesamt
entfallen somit ca. 7% der Gesamtkosten eines fertigen Produkts auf unnötigen
Papieraustausch. 1
Der elektronische Austausch von Handelsdokumenten ist jedoch noch immer durch
zahlreiche Schwierigkeiten behindert. Neben rechtlichen Problemen (Mehrwertsteuer)
sind es vor allem hard- und softwaretechnische Systemunterschiede, die
einer reibungslosen Kommunikation im Wege stehen. Offene Märkte verlangen offene
Kommunikation. Keine der bisherigen Bemühungen um die Standardisierung
des elektronischen Geschäftsverkehrs überschritten regionale oder nationale
Grenzen. UN/EDIFACT setzt in diesem Kontext neue Massstäbe. Mit UN/EDIFACT
wurde Ende der 80-er Jahre ein Regelwerk für den elektronischen Austausch von
Handelsdokumenten geschaffen, das weltweit Gültigkeit besitzt.
Betrachtet man die momentane Situation vieler Unternehmen, so zeigt sich ein erheblicher
Nachholbedarf im Bereich des elektronischen Geschäftsverkehrs. Viele
Betriebe werden mit Fragen des genormten elektronischen Datenaustauschs erst
dann konfrontiert, wenn marktstarke Unternehmen die Fähigkeit zum genormten
1 Schlieper / Einführung / 1-2; Geiser / UN/EDIFACT / 7-5
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 1-7

EANCOM-Handbuch
Einleitung
elektronischen Datenaustausch als unabdingbare Voraussetzung für die Fortsetzung
der Geschäftsbeziehungen voraussetzen.
Lassen Sie es uns klar aussprechen: EDI ist eine Managementaufgabe, denn die
Geschäftsprozesse zwischen zwei oder mehreren Partnern sind davon betroffen.
Es handelt sich hier um eine weitere grosse Rationalisierungswelle, nach der Rationalisierung
im Produktionsbereich und im Büro, welche die zwischenbetrieblichen
Aktivitäten erfasst. Das Unternehmen, welches hier den Anschluss verpasst,
stellt sich ins wettbewerbliche Abseits.
1.2 Einführung und Grundlagen
Unter EDI wird der interventionsfreie Austausch strukturierter
Daten zwischen den Applikationen der Partner verstanden.
Strukturierte Daten zeichnen sich durch eine genaue Festlegung ihrer Zusammensetzung
aus . Die auszutauschende Information muss, damit eine Verständigung
zwischen den Partnern zustande kommt, sowohl bezüglich der Ordnung der Zeichen
und Zeichenverbindungen innerhalb einer Nachricht (Syntax), als auch hinsichtlich
Bedeutung und Inhalt einer Zeichenfolge (Semantik), festgelegt sein.
Hierdurch sind die Voraussetzungen für die automatische Weiterverarbeitung der
ausgetauschten Daten realisiert. Aus technischer Sicht stellt UN/EDIFACT folglich
einen kontrollierten File-Transfer zwischen zwei EDV-Systemen dar.
Im weiteren muss ein international verwendbarer Standard folgende Kriterien erfüllen:
• 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, branchenübergreifend
Als einziger Standard für den nationalen und internationalen branchenübergreifenden
elektronischen Datenaustausch der all diese Anforderungen erfüllt, steht heute
UN/EDIFACT zur Verfügung.
1.3 UN/EDIFACT als strategisches Instrument
Die sich verschärfende Wettbewerbssituation und die zunehmende Globalisierung
der Märkte gehen für Unternehmen im allgemeinen und mittelständischen Unternehmen
im besonderen mit einer Bedrohung der Marktposition einher, so dass die
Nutzung der Chancen im Rahmen neuer Technologien notwendig wird.
Ziel der Unternehmensführung muss die Verbesserung der strategischen Position
sein, um durch qualifizierte, zum Geschäftspartner geöffnete Informationssysteme
Aktions- und Reaktionszeiträume zu verkürzen, neue Dienste für Partnerunternehmen
anzubieten und damit die Wettbewerbsvorteile zu sichern oder zu verbessern.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 1-8

EANCOM-Handbuch
Einleitung
Ohne eine solche strategische Neukonzeption der Unternehmensziele laufen insbesondere
mittelständische Unternehmen Gefahr, dem verschärften Wettbewerbsdruck
nicht standhalten zu können.
Viele Unternehmen laufen Gefahr, den internationalen Anschluss beim standardisierten
elektronischen Datenaustausch zu versäumen, obwohl die EDI-Fähigkeit
schon in naher Zukunft zum K.O.-Kriterium im Wettbewerb wird. Ein Grund für die
Zurückhaltung vieler Unternehmen liegt unter anderem im Informationsdefizit potentieller
EDI-Anwender.
Für Sie als Hersteller bietet UN/EDIFACT z.B. folgende strategische Vorteile:
• schnellere und genaue Bestellerfassung, dadurch Verbesserung der Lieferfrist
und -qualität
• Anbindung Ihrer Handelspartner
• Zurverfügungstellung immer aktueller Artikeldaten, dadurch Verbesserung der
Bestellqualität
• Schnellere und genauere Rechnungsstellung (vielleicht erhalten Sie sogar Ihr
Geld schneller!)
Für Sie als Handelsunternehmen bietet UN/EDIFACT z.B. folgende strategische
Vorteile:
• Verbesserung der Liefergenauigkeit Ihrer Lieferanten
• schnellere Bestellabwicklung, kürzere Durchlaufzeiten
• besseres Cash-Management
Allgemeingültige strategische Vorteile:
• Schaffung von Verständnis für die eigenen Probleme beim Geschäftspartner
• Vereinfachung des Datenflusses und der Informationsauswertung
• Steigerung von Effizienz und Produktivität
• Just-in-Time kommt erst durch UN/EDIFACT zum Tragen
• Steigerung des Dienstleistungsgrades
• Schnellere Anpassung an Veränderungen der Märkte
• Engere Bindung der vor- und nachgelagerten Geschäftspartner und dadurch
Verminderung des Aufwandes zur Suche und Einbeziehung neuer Lieferanten
und Abnehmer
• Modernisierung und Qualitätssteigerung beim Kontakt mit dem Partner
• Die Anpassung an künftige technologische Entwicklungen im Bereich Informationstechnologie
kann besser gemeistert werden
• Reduktion der Lagerkosten und -verzinsung
1.4 Kriterien für eine UN/EDIFACT Implementierung
Für den Einsatz von UN/EDIFACT sind in erster Linie Geschäftsbeziehungen mit
zeitkritischer Bedeutung, starkem Routinecharakter und hohem Volumen geeignet.
Insbesondere strukturierte Aufgabenstellungen, deren Vorgehensweisen festste-
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 1-9

EANCOM-Handbuch
Einleitung
hen (beispielsweise Auftragsabwicklung), eignen sich für eine informationstechnische
Unterstützung durch UN/EDIFACT. Auch muss darauf geachtet werden, nicht
nur einzelne Papierformulare durch elektronische abzulösen, sondern ganze Geschäftsabläufe
zu betrachten. Es bringt relativ wenig, mit einem Partner nur Bestellungen
auszutauschen, der gesamte Geschäftsablauf 'Auftragsabwicklung'
sollte einbezogen werden. Dies umfasst also die Übermittlung von Artikelstammdaten,
die Bestellung, die Bestellantwort, die Bestelländerung, den Lieferschein,
die Rechnung und die Zahlung.
Dass UN/EDIFACT Eingriffe in die interne Organisation eines Unternehmens mit
sich bringt, liegt auf der Hand. Nicht umsonst wird bei der Einführung von
UN/EDIFACT die 20/80-Regel zitiert: 20% technischer Aufwand, 80% organisatorischer
Aufwand.
Bei unstrukturierten Aufgaben (z.B. Produktgestaltung und Konstruktion) hingegen
unterstützt UN/EDIFACT lediglich den partiellen Informationsabgleich mehrerer
Partner und verbessert damit die Entscheidungsqualität. Es sind weitere Kommunikationsformen
wie Sprach- und Bildkommunikation erforderlich, die durch
UN/EDIFACT nicht abgedeckt werden.
Denken Sie vor allem immer daran: UN/EDIFACT ist keine Einzelaufgabe die im
stillen Kämmerlein zu lösen ist. Sie brauchen dazu strategische Entscheide aus Ihrer
Geschäftsleitung, Partner für die Integration sowie die Unterstützung einer
Gruppe.
1.5 Entwicklung und aktuelle Situation
Die Einführung und Gewährleistung des internationalen Identifikations-Standards
EAN in der Schweiz ist der ursprüngliche Verbandszweck der Schweizerischen Artikelcode-Vereinigung
(EAN (Schweiz, Suisse, Svizzera)). Im Bestreben, den aktuellen
technischen Veränderungen Rechnung zu tragen und dabei die zusätzlichen
Nutzungschancen einer solchen Standardisierung wahrzunehmen, hat sich die
EAN (Schweiz, Suisse, Svizzera) in den letzten Jahren über die Thematik von EAN
hinaus mit weiteren Problemkreisen beschäftigt:
• elektronischer Handelsdaten-Austausch
• zentrale Artikel-Stammdatenbank
• Marktdaten-Austausch
Gemeinsames Ziel dieser Projekte ist es, auf dem EAN-System basierend, den Informations-Austausch
zwischen Handelspartnern zu vereinfachen und qualitativ zu
verbessern. Sie enthalten alle die folgenden Komponenten:
• die EAN (Schweiz, Suisse, Svizzera) als Koordinationsstelle
• das EAN-System als weltweit eindeutige Artikel-, Dienstleistungs- und Teilnehmeridentifikation
• eine zentrale Kommunikations-Drehscheibe (Clearing-House)
Im Hinblick auf zukünftige und bereits in Arbeit befindliche parallele Entwicklungen
sind noch weitere Aspekte berücksichtigt:
• Datenaustausch mit Transporteuren und Spediteuren
• Datenaustausch mit Verwaltungen und Behörden
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 1-10

EANCOM-Handbuch
• Datenaustausch mit Banken und Versicherungen
• Sicherheitsaspekte, elektronische Unterschrift
Einleitung
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 1-11

EANCOM-Handbuch Was ist EDI ?
2 Was ist EDI ?
EDI steht für "Electronic Data Interchange" - elektronischer Datenaustausch - der
Austausch von Routinetransaktionen zwischen Geschäftspartnern, wie zum Beispiel
Bestellungen, Lieferanzeigen, Rechnungen usw., in einem standardisierten
Format. Die Bezeichnung EDI wirkt technisch und könnte irreführen. EDI ist vielmehr
ein äusserst effizientes Konzept zur Vereinfachung von Geschäftsbeziehungen.
EDI verbessert die gesamte Warenverteilung durch:
• Verminderung oder Eliminierung der damit verbundenen Papierdokumente
• Reduktion der Durchlaufzeiten
• Erhöhung der Datenqualität
• Verbesserung der Transparenz der traditionellen Geschäftsabläufe
• richtige Ware zum richtigen Zeitpunkt am richtigen Ort
Beispielsweise Bestellungen müssen nach ihrem Eintreffen per Post, Fax oder Telefon
nicht mehr manuell aufbereitet und für die Auftragsbearbeitung erfasst werden.
Papierdokumente werden nicht mehr ausgedruckt und in Umschläge verpackt
und frankiert dem Partner zugesandt.
EDI - auch in einer einfachen Form - eliminiert nicht nur die dargestellten Abläufe,
sondern beschleunigt gleichzeitig die Abläufe und steigert die Produktivität innerhalb
der gesamten Versorgungslogistik. Besonders hervorzuheben ist, dass alle
Beteiligten davon profitieren, sowohl Handel, wie Lieferanten.
EDI ist das Ergebnis der nahezu universellen Einsetzbarkeit von Computersystemen
in Handel und Industrie, verbunden mit den Möglichkeiten der Telekommunikation.
EDI erlaubt damit völlig neue Dialogformen zwischen Geschäftspartnern
und auch innerhalb von Firmengruppen.
Der Unterschied von EDI zu traditionellen Computerlösungen liegt darin, dass hier
nicht die Automatisierung alter oder existierender Geschäftsprozesse stattfindet.
Vielmehr erlaubt dieses Instrument die Überarbeitung dieser Prozesse, in technischer
und insbesondere in organisatorischer Hinsicht.
EDI wurde bereits in einer grossen Anzahl von Firmen in der Schweiz eingeführt,
sowohl in grossen Detailhandelsunternehmen, wie in kleinen Lieferantenbetrieben,
in Spedition, Banken, Versicherungen, Verwaltung etc.. EDI wird aktiv sowohl von
nationalen und internationalen Standardisierungsorganisationen als auch von
staatlichen Einrichtungen, wie beispielsweise der Zollverwaltung gefördert .
2.1 Was ist EDI nicht ?
EDI ist kein Zaubermittel, um unproduktiven Organisationsformen zum Überleben
zu verhelfen. Der Schritt zu EDI ist unumkehrbar und wird im vollen Bewusstsein
unternommen, dass die Beziehung zu den Geschäftspartnern eine neue Form erhält.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 2-12

EANCOM-Handbuch Was ist EDI ?
EDI hat nicht einen zyklischen Erneuerungsbedarf, wie andere Informatik-
Anwendungen, da es alle Aspekte der Betriebsorganisation und der Art und Weise
der Geschäftsbeziehungen umfassen kann.
Aus dem selben Grund wird ein EDI-Prozess zu Beginn nicht zwingend einen hohen
Return-on-Investment aufweisen. Der Ausbau von elektronischen Prozessen
zu Geschäftspartnern bedarf einiger Zeit.
EDI sollte von technologischen Überlegungen weder gesteuert noch eingeengt
werden, ungeachtet der Tatsache, dass EDI meistens durch die Informatik- / Organisationsabteilung
eingeführt und unterhalten wird. Um erfolgreich zu sein verlangt
ein EDI-Projekt interessierte und kreative Teilnehmer aus den Bereichen Vertrieb,
Marketing und Finanz; in erster Linie aber einen klaren strategischen Entscheid der
obersten Geschäftsleitung.
EDI wird nicht immer freiwillig eingeführt. Häufig wird der Entscheid durch äussere
Einflüsse herbeigeführt: einflussreiche Geschäftspartner, Wettbewerbsüberlegungen,
usw.. Dies sollte eine Geschäftsleitung nicht davon abhalten, dieses Projekt
zum Vorteil der Firma zu nutzen und von der langen Lebensdauer von EDI zu profitieren.
2.2 Entstehungsgeschichte
Der elektronische Datenaustausch wird seit Mitte der 70er Jahre angewendet. Eine
der ersten Anwendungen, welche bereits einen hohen Entwicklungsgrad erreichte,
war das SWIFT-Netzwerk der Banken.
Der eigentliche Anstoss für die Verbreitung von EDI ging jedoch in den 80er Jahren
von der Automobilindustrie und dem Detailhandel aus. Beiden Branchen ist gemeinsam,
dass sie einen starken Einfluss auf zahlreiche Lieferanten haben. Dies
ist besonders deutlich bei den Automobilherstellern, wo viele Lieferanten exklusiv
für einen Hersteller arbeiten. Diese Machtverhältnisse vereinfachten die Durchsetzung
von Standards, Verfahren und Vereinbarungen, welche Voraussetzung für ein
effizientes, strukturiertes EDI sind. Es wurden sehr schnell Einsparungen in den
Einkaufsabteilungen der Firmen erreicht, insbesondere im Bereich der Lageroptimierung
und der administrativen Kosten.
Etwas später begann auch die Elektronikindustrie (insbesondere die Computer-
Hersteller) die Vorteile von EDI für sich zu nutzen. Aus den selben, bereits erwähnten,
Gründen.
1987 begann die Standardisierung unter dem Dach von UN/UN/EDIFACT. Inzwischen
sind Projekte aller Branchen zum Teil realisiert oder in Entwicklung. Alle Bereiche
des Geschäftsverkehrs können heute oder in absehbarer Zukunft, dank dieser
Entwicklung, papierlos, schneller und mit einer deutlich gesteigerten Zuverlässigkeit
abgewickelt werden.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 2-13

EANCOM-Handbuch Was ist EDI ?
2.3 Nutzen von EDI
Im Hinblick auf den zunehmenden Druck des Detailhandels auf die Lieferanten
wächst die Bedeutung von EDI von einem Rationalisierungsinstrument hin zur unabdingbaren
Dienstleistung für die Kunden. Untersuchungen der verschiedensten
Hochschulen zeigen die Gefahr für die Existenz einer Firma auf, welche sich gegen
die Einführung von EDI auf die Dauer wehrt.
Die Vorteile von EDI lassen sich in zwei Kategorien gliedern:
2.3.1 Operationeller Nutzen:
• Keine Fehler infolge Mehrfacherfassung
• Reduktion von Papierverbrauch und Bearbeitungskosten
• Erhöhte Geschwindigkeit der Geschäftsabläufe und signifikante Verbesserung
der Korrektheit der Daten kritischer Vorgänge
• Verkürzung der Reaktionszeiten (Lieferbereitschaft, Zahlungseingang)
• Einsparungen bei der Lagerhaltung und beim Transport der Waren
2.3.2 Strategischer Nutzen:
• Veränderung von Struktur und Mentalität in der gesamten Logistikkette. Schaffung
von Verständnis für die eigenen Probleme beim Geschäftspartner.
• Vereinfachung des Flusses und der Informationsauswertung von Verkaufs- und
Marketing-Daten
• Steigerung von Effizienz und Profitabilität
• Steigerung des Dienstleistungsgrades
• Schnellere Reaktionsfähigkeit auf Veränderungen des Marktes
Viele der aufgezählten Vorteile können bereits in einem frühen Stadium der Anwendung
von EDI realisiert werden. Mit zunehmenden Einsatz dieser Prozesse für
die gesamte Organisation sind offensichtlich noch weitere Vorteile erreichbar:
• Integrierte Geschäftsprozesse
• Insgesamt vereinfachter und aussagefähigerer Datenfluss
• Voraussetzung für effiziente Planungssysteme für die Produktion und die Verteilung
• Potential zur Verbesserung des Cash Flow, durch Verkürzung der Abwicklungsdauer
eines Geschäfts
• Just-in-time Lieferungen
Diese Aufzählung ist bei weitem nicht vollständig. Je nach Charakteristik des Geschäfts
kann sie beliebig erweitert werden.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 2-14

EANCOM-Handbuch Was ist EDI ?
Wie mit anderen Systemen, welche Telekommunikations-Einrichtungen benutzen
(z.B. Datenträgeraustausch, File Transfer), hängt auch der Erfolg von EDI wesentlich
vom Verbreitungsgrad ab. Eine universale Verbreitung hängt daher im Wesentlichen
von Geschäftspartnern ab, welche bereit sind im Bereich von EDI zusammenzuarbeiten.
Ist eine EDI-Verbindung erfolgreich eingeführt, sollten daher
die EDI-Anwender nach weiteren Partnern suchen, welche ihnen eine Vervielfältigung
des Nutzens erlauben.
2.4 Risiken von EDI
Ein operatives EDI-System birgt keine grösseren Risiken in sich, als sonst eine
Anwendung innerhalb des Betriebes. Hingegen muss in der konzeptionellen Phase
besondere Rücksicht auf die Tatsache genommen werden, dass EDI die direkte
(von Applikation zu Applikation) Verbindung zu der oder den Partnerorganisationen
schafft. Fehler im Konzept können auch Investitionen des Geschäftspartners betreffen
und im Extremfall die mühsam erarbeiteten guten Geschäftsbeziehungen
empfindlich stören. Obwohl der gut strukturierte EDI-Prozess mit bewährten Informatik-
und Telekommunikations-Mitteln betrieben wird, setzt er doch ein neues
Verständnis für die Beziehungen zum Geschäftspartner voraus.
EDI entstand, wegen der inzwischen nahezu vollständigen Verfügbarkeit von Computersystemen
in allen Firmen und der einfachen und erschwinglichen Benutzung
von Telekommunikationseinrichtungen. Die Risiken dieser Komponenten der Informationstechnologie,
können auch Risiken von EDI sein. Ohne die gewohnten
Absicherungen, wie Katastrophenplan, Anti-Virus-Funktionen, Netzwerk-
Redundanzen, Backup-Verfahren etc. kann EDI nicht mit der gewünschten und benötigten
Zuverlässigkeit betrieben werden.
EDI ist weder ein Garant für neue Kunden noch für neue Produktaufnahmen von
bestehenden Kunden. Ausschlaggebend dafür sind in der Regel Qualität der Produkte
sowie das Preis-/Leistungsverhältnis.
Das grösste Risiko für ein Unternehmen dürfte jedoch darin liegen, die Herausforderung
von EDI zu ignorieren oder gar abzulehnen.
2.5 Hat EDI eine strategische Bedeutung?
Wie bereits geschildert, kann ein korrekt eingeführtes EDI bedeutenden Nutzen in
der gesamten Logistikkette erbringen. Die Art des Geschäftes bestimmt, wo diese
Nutzen erzielt werden, und ob damit eine Steigerung der Effizienz der eigenen Organisation
oder eine Verbesserung der Geschäftsbeziehungen mit Kunden oder
Lieferanten angestrebt wird.
Die Erfahrungen der Automobilindustrie, der Elektronikhersteller und der grossen
Detailhandelsketten zeigen substantielle Einsparungen durch EDI auf. Diese Organisationen
sind mächtige Kunden vieler Zulieferindustrien. Den Zulieferern bieten
sich aber ebenfalls substantielle Nutzen an; sei es um ihre Position bei ihren Kunden
zu stärken, aber auch durch direkte Einsparungen in ihrer Organisation.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 2-15

EANCOM-Handbuch Was ist EDI ?
Ein weiteres Argument ist, dass jede Effizienzverbesserung immer auch strategischen
Wert für einen Betrieb hat, da damit immer eine Steigerung der Dienstleistungsqualität
einher geht. Diese kann sich auswirken in:
• Schnellere Reaktion auf Veränderungen am Markt
• Konkurrenzfähigere Preisgestaltung
• Just-in-time Fähigkeit
• Vermeidung von Out-of-stock Situationen
• etc.
Der Druck für den Einsatz von EDI kommt häufig von Kundenseite. Die Zielsetzung
für den Lieferanten kann daher nur heissen: Verbesserung des Dienstes am Kunden.
Bei multinationalen Unternehmen, vor allem in der Elektronikbranche, kommt der
Druck jedoch immer häufiger von Lieferantenseite als Druckmittel für das Beibehalten
von Generalvertretungen.
2.5.1 Welche Technologie wird benötigt?
EDI wurde auf Grund der scheinbar universellen Einsetzbarkeit von Computern
und von Kommunikationsinfrastrukturen in der Geschäftswelt ermöglicht . Für Firmen,
welche EDI betreiben wollen gibt es keine Alternative zum Computer. EDI
verlangt jedoch keine komplexe Informationstechnologie. Wird EDI für alle Geschäftsvorgänge
und alle Partner einer Firma eingesetzt, kann eine Erhöhung der
Rechenleistung und anderer Computerressourcen notwendig werden. EDI verlangt
aber in einem aktuellen Informatikumfeld niemals den Wechsel von Hardware oder
Betriebssystem, oder der betroffenen Anwendungen.
EDI setzt den Einsatz von Telekommunikations-Diensten voraus. Dies ist für viele
mittlere und kleinere Betriebe ein neues Instrument. In den meisten Fällen wird
man diese Dienstleistungen von einem Netzwerkbetreiber beziehen, ähnlich wie
das Telefon oder der Fax. Diese liefern in der Regel auch die für die Übermittlung
benötigte Software und Hardware.
Die für EDI benötigte Technologie beschränkt sich daher auf Software, namentlich
ein Konverter und die sogenannte Enabling-Software.
2.5.2 Konverter
Diese Software ist in verschiedensten Angeboten auf dem Markt verfügbar. Sie ist
verantwortlich dafür, das hausinterne Format von Dateien in den EANCOM-
Standard zu übersetzen oder umgekehrt. Auf der Partnerseite sorgt wiederum ein
Konverter für die Übersetzung in dessen hausinternes Format.
2.5.3 Enabling-Software
Diese muss in wesentlichen Teilen durch den EDI-Anwender oder dessen EDI-
Berater selbst entwickelt werden. Ihre Funktion ist es, die Verbindung zwischen der
EDI-Umgebung und den vorhandenen Anwendungen herzustellen. Dazu gehören
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 2-16

EANCOM-Handbuch Was ist EDI ?
Prüfungs- und Umsetzfunktionen der ankommenden Nachrichten, Aufbereitungsund
ebenfalls Umsetzfunktionen für die abgehenden Dokumente. Immer mehr sind
Anwendungspakete auf dem Markt verfügbar, welche bereits über entsprechende
Schnittstellen verfügen.
2.5.4 Verfügbare Schulung und Unterstützung
Normalerweise werden sich Firmen, welche ein EDI-Projekt durchführen wollen, mit
Netzwerk- und Clearingservice- Anbietern in Verbindung setzen. Diese bieten im
Allgemeinen neben den erwähnten Diensten, auch Übermittlungssoftware und
Konverter an. Für die Analyse und Realisierung der Enabling-Software können
Dienstleistungen von EDI-Beratungsfirmen bezogen werden. Häufig sind diese Berater
mit Netzwerkanbietern in Verbindung, sodass sie in der Lage sind, die Gesamtverantwortung
für ein EDI-Projekt zu übernehmen. (siehe Adressverzeichnis
am Ende dieses Handbuches)
Die EAN (Schweiz, Suisse, Svizzera) und verschiedene Veranstalter bieten Ausbildung
im EDI-Umfeld an. Ausserdem ist bei der EAN (Schweiz, Suisse, Svizzera)
auch Beratung im Bereich von EANCOM- und EANSYS-Anwendung erhältlich.
Die Anbieter von Konvertern bieten alle Ausbildung im Umgang mit ihren Produkten
an.
2.6 Wie beeinflusst EDI das Geschäft?
Im Verlaufe der Zeit haben sich die Rolle und die Auswirkungen der Informatik gewandelt.
In der heutigen Zeit stellt die Informatik eine Informationsquelle für alle
Managementebenen einer Firma dar. Insbesondere die Geschäftsleitung wird
durch konzentrierte und konsolidierte Information immer besser im Erreichen ihrer
Ziele unterstützt. EDI leitet nun eine weitere Phase in der Evolution der Informationstechnologie
ein: Firmen-übergreifende Organisationssysteme. Durch die Ausdehnung
über Firmengrenzen hinweg erhält EDI augenblicklich eine strategische
Bedeutung. Die Fähigkeit einer Firma, sich leicht auf Veränderung des Marktes
einzustellen, kann an ihrer Bereitschaft, auf die EDI-Herausforderung zu antworten,
gemessen werden.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 2-17

EANCOM-Handbuch Was ist EDI ?
2.7 Welche Kosten entstehen?
Den Hauptanteil an den Kosten einer EDI-Einführung hat der Einkauf oder Aufbau
von eigenem EDI-Know-how. Dieses ist in der Firma kaum vorhanden. Ein Beratungsaufwand
von ein bis zwei Monaten oder entsprechende Ausbildung von eigenen
Mitarbeitern ist daher in die Überlegungen einzubeziehen.
EDI verlangt am Anfang keine zusätzliche Hardware, es sei denn ein Modem.
Ausserdem sind noch die Kosten des PTT-Anschlusses (X.25 oder X.28) zu berücksichtigen.
Auf der Software-Seite muss minimal eine Übermittlungssoftware und ein Konverter
(Übersetzungs-Software) beschafft werden. Die heutigen Angebote bewegen sich
im Durchschnitt zwischen Fr. 5'000 und Fr. 18'000. Bei den billigsten Angeboten ist
jedoch ein mit den Anwendungen integrierter EDI-Betrieb nicht möglich.
Daneben entstehen Kosten für das Netzwerk und den Clearingservice. Hier bewegen
sich die Kosten im Bereich von Fr. 4'000 bis Fr. 6'000 im Jahr, wobei diese
Werte von Anzahl Partnern, Übermittlungen und Grösse der Datenmenge stark variiert
werden.
Es fehlt noch der Aufwand für die Enabling Software. Die Kosten für diese Entwicklung
sind im wesentlichen abhängig von den verfügbaren System- und Programmierungsressourcen
im eigenen Unternehmen und den Eigenschaften und
Schnittstellen der vorhandenen Anwendungsprogramme.
2.8 Wie wird EDI eingeführt?
Ein wichtiger Aspekt von EDI-Einführungen ist die Tatsache, dass es sich hier nicht
um einen endlichen Prozess handelt, der vorübergehend die zur Verfügungstellung
von Ressourcen, Zeit und Geld bedeutet.
EDI heisst Re-engineering der Geschäftsabläufe, das für die betroffenen Mitarbeiter
eine bleibende Veränderung ihrer gewohnten Aufgaben mit sich bringt.
Da es sich bei EDI um einen externen Prozess handelt, welcher Kunden, Lieferanten,
Transporteure, Banken, usw. mit einschliesst, muss es als eine fortlaufende
Managementaufgabe betrachtet werden. Es kann davon ausgegangen werden,
dass jeder EDI-Schritt Verhandlungen, juristische Aspekte, Vereinbarungen mit
Partnern erfordert. Diese Punkte verlangen eindeutig die direkte Trägerschaft des
Managements einer Firma.
Die Abstützung auf neue Geschäftsprozesse verlangt auch die Überarbeitung der
Kontrollabläufe. Die Reduktion oder Eliminierung des Papierbedarfs im Geschäftsverkehr
braucht entsprechend geänderte Kontrollverfahren.
Am Anfang wird ein EDI-Projekt meistens von der Informatik- / Organisationsabteilung
getragen. Es sollte jedoch möglich sein, dass im Verlaufe des Projektes die
Verantwortung aus der Informatik- / Organisationsabteilung heraus an mehr anwenderorientierte
Fachabteilungen übertragen wird. Ein EDI Administrator tritt an
die Stelle des Informatik- / Organisationsleiters. Er vertritt die Interessen der betei-
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 2-18

EANCOM-Handbuch Was ist EDI ?
ligten Stellen - Verkauf, Marketing, Finanz, Produktion, Vertrieb - sowohl intern, als
auch gegenüber den EDI-Partnern.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 2-19

EANCOM-Handbuch
Standards
3 Standards
3.1 UN/EDIFACT
UN/EDIFACT steht für United Nations / Electronic Data Interchange For Administration,
Commerce and Transport und definiert das weltweite ratifizierte Regelwerk
für den elektronischen Austausch von Handelsnachrichten im Rahmen des branchen-
und firmenübergreifenden Geschäftsverkehrs. Ziel von EDIFACT ist die Substitution
des Papieraufkommens bei geschäftlichen Transaktionen durch standardisierte
elektronische Geschäftsnachrichten. Die Hard- und Softwareneutralität von
EDIFACT ist als Einmaligkeit in der Geschichte weltweiter Normungsarbeit von
zentraler Bedeutung.
Elektronische Informationen können somit erstmals weltweit verständlich erstellt,
ausgetauscht und weiterverarbeitet werden. Mit EDIFACT ist die Möglichkeit der
Durchgängigkeit von Geschäftsnachrichten in der gesamten Wertschöpfungskette
gegeben, angefangen von der Angebotseinholung, der Angebotserstellung, Bestellung
und Beschaffung von Rohstoffen, Halb- und Fertigerzeugnissen von Zulieferern
bis hin zur Produktion, Lieferung und Kundenbetreuung, einschliesslich
der Kontakte zu Banken, Versicherungen und der öffentliche Verwaltung, speziell
den Zoll.
Grundsätzlich kann jede Standardnachricht, welche unter Zuhilfenahme eines
Foirmulars zusammengestellt und übermittelt wird, im EDIFACT-Format abgebildet
werden. Dies allein weist auf die zahlreichen Einsatzmöglichkeiten der Norm hin.
Konstitutiv für EDIFACT sind:
• die EDIFACT-Syntax-Regeln (ISO 9735, CEN EN29735)
• das EDIFACT-Handbuch der Datenelemente, EDED (ISO 7372)
• die EDIFACT-Code-Liste, EDCL
• das EDIFACT-Handbuch der Datenelementgruppen, EDCD
• das EDIFACT-Handbuch der einheitlichen Segmente, EDSD
• das EDIFACT-Handbuch der einheitlichen Nachrichtentypen, EDMD
• die Richtlinien der Nachrichtenentwicklung und Anwendung der Syntax-Regeln
• die einheitlichen Durchführungsregeln für den Handelsdatenaustausch via Telekommunikation
3.2 ANSI X.12
Parallel zu den Standardisierungsarbeiten von UN/EDIFACT wurden in verschiedenen
Ländern Projekte zur Einführung von EDIFACT auf nationaler Ebene gestartet.
Hierzu gehört auch ANSI X.12, welches in den USA vom American National
Standards Institute (ANSI) entwickelt wurde. Wie auch der UN/EDIFACT-Standard
basiert er auf ISO-Syntaxregeln. Dies zeigt sich bei der Verwendung des gleichen
Codes, jedoch werden unterschiedliche Trennzeichen und Kennungen für die einzelnen
Segmente verwendet.
ANSI X.12 findet im nordamerikanischen Raum grosse Verwendung, wogegen er in
Europa nicht eingesetzt wird.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 3-20

EANCOM-Handbuch
Standards
ANSI X.12 wird voraussichtlich als Standard bis 1997 eigenständig weiterentwickelt
und dann durch UN/EDIFACT ersetzt werden.
3.3 EANCOM
Aufgrund der Organisation von EAN-International und den angeschlossenen nationalen
EAN-Organisationen, sowie der definierten Strukturen und Regeln welche
eine Eindeutigkeit der Identifikationsnummern gewährleisten, haben die EAN-
Organisationen einen ersten Schritt in Richtung firmenübergreifende Kommunikation
realisiert.
Die meisten EAN-Organisationen hatten Anfangs der 80er Jahre Standards, denen
das EAN-System zugrundeliegt, für den elektronischen Datenaustausch definiert.
Diese Standards wie zum Beispiel TRADACOM, SEDAS oder ALLEGRO haben jedoch
allen den Nachteil, dass es sich hierbei nur um nationale Standards handelt,
die untereinander nicht kompatibel sind.
Ende der 80er Jahre mit dem Erscheinen der ersten UN/EDIFACT Nachrichten war
die Basis für internationale Standards geschaffen. 1990 erschien das erste
EANCOM-Manual basierend auf UN/EDIFACT. Beim Einsatz von EANCOM-
Nachrichten werden sowohl die Partner als auch die Waren durch eine 13-stellige
EAN-Nummer weltweit eindeutig identifiziert. Somit werden die Nachrichten von
der Grösse her kurz gehalten und zusätzliche Fehlerquellen werden weitestgehend
eliminiert.
Eine exakte Anwendung des EAN-Identifikationssystems sowie die korrekte Interpretation
der EANCOM-Nachrichten sind wichtige Voraussetzungen für einen erfolgreichen
Start mittels EANCOM.
EANCOM kommt jedoch nicht nur im Bereich Detailhandel zum Einsatz. Auch in
den Bereichen Gesundheitswesen, Elektrobranche, Baumaterialhandel, Spedition,
Verlagswesen etc. gibt es mittlerweile EDI-Projekte die auf EANCOM basieren. In
einigen Ländern, wie zum Beispiel Deutschland, ist man bestrebt, vom nationalen
Standard SEDAS eine Migration auf EANCOM zu vollziehen.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 3-21

EANCOM-Handbuch
Das Projekt EANCOM-CH
4 Das Projekt EANCOM-CH
Im Verlauf des Jahres 1989 diskutierte der Vorstand der EAN (Schweiz, Suisse,
Svizzera) über die Notwendigkeit, im Rahmen der EAN-Ziele die Einführung des
elektronischen Datenaustausches zwischen Handelspartnern in der Schweiz zu
fördern. Das Projekt EANCOM-CH entstand aus diesen Diskussionen. Es wurden
interessierte Mitglieder und Anbieter von EDI-Dienstleistungen eingeladen, aktiv an
diesem nationalen Standard mitzuarbeiten. An der ersten Projektsitzung Anfang
Januar 1990 nahmen folgende Firmen teil:
• EAN (Schweiz, Suisse, Svizzera), Basel (Patronat)
• COOP Schweiz, Basel
• Denner Discount AG, Zürich
• IBM (Schweiz), Zürich
• Knorr-Nährmittel AG, Thayngen
• Société des Produits Nestlé SA, Vevey
• Swisscos AG, Zürich
Für die Überprüfung der EANCOM-CH-Qualität wurde ein Pilotbetrieb zwischen der
Denner AG und der Knorr-Nährmittel AG eingerichtet.
Der wachsende Umfang der Aufgaben für die Projektleitung erforderte eine Neuorganisation
und eine Erweiterung der Teilnehmer am Projekt EANCOM-CH. Diese
zur Zeit aktuelle Organisation wurde Mitte 1993 eingeführt und hat sich bewährt. Im
Zuge der Neuorganisation wurde ein Projektleiter eingestellt, der heute die Aufgaben
der ehemaligen Projektleitung wahrnimmt.
Organigramm EANCOM-CH http://www.ean.ch/EANCOM/task.htm
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 4-22

EANCOM-Handbuch
4.1 Umfang und Ziele
Das Projekt EANCOM-CH
4.1.1 Message Design
Die Message-Beschreibung ist eine der Aufgaben, die im EANCOM-CH-Projekt
gelöst wird. Dabei werden die Regeln und die Syntax von UN/EDIFACT bzw.
EANCOM eingehalten, d.h. EANCOM-CH ist 100-prozentig UN/EDIFACT-konform.
Der EANCOM-Standard wird durch Arbeitsgruppen innerhalb EAN-International erarbeitet
und gepflegt. Die Dokumentation und Veröffentlichung erfolgt durch das
EAN-Generalsekretariat in Brüssel in direkter Absprache mit den UN/EDIFACT-
Gremien. In EANCOM-CH werden aus EANCOM diejenigen Messages, Messagesegmente
und Datenelemente definiert, die den schweizerischen Bedürfnissen entsprechen.
4.1.2 Ablauf Design
Das EANCOM-CH-Projekt beschäftigt sich neben der reinen Message-
Beschreibung besonders mit Fragen des Ablaufs. Dabei werden Verfahren definiert,
die den Anwendern den Umgang mit EANCOM-CH vereinfachen und für die
notwendige Transparenz sorgen.
Ist eine Verbindung zu einem Partner etabliert, ist jeder weitere Partner-Anschluss,
dank diesen ablauforganisatorischen Regeln, mit einem Minimum an Aufwand realisierbar
(Vervielfältigung), da sich die Unterschiede bei neuen EDI-Partnern auf
wenige bilaterale Abmachungen beschränken.
4.1.3 Datenbanken
Der EANCOM-Standard bedient sich des EAN-Numerierungs-Systems. Dieses beinhaltet
zum Beispiel die Verwendung von EAN-Nummern für Artikel, Dienstleistungen
oder für die Identifikation von Firmen und Organisationen. Da in EANCOM nur
die Nummern ohne Text ausgetauscht werden, muss der Partner mit den entsprechenden
Daten versorgt werden. Um diese Informationen immer auf einem aktuellen
Stand für alle EANCOM-Teilnehmer zur Verfügung zu halten, ohne die Netzwerke
unnötig zu belasten, werden national zentrale Datenbanken eingerichtet.
Diese können zu einem späteren Zeitpunkt auch noch anderen Verwendungszwekken
zugeführt werden (z.B. Marktdatenaustausch). Um missbräuchliche Verwendung
der gespeicherten Daten zu verhindern, werden strikte Datenschutz-
Massnahmen realisiert. Seit 1995 ist die Schweizerische Stammdatenbank (Edb,
EAN Datenbank) in Betrieb.
4.2 Projektorganisation
4.2.1 Arbeitsgruppen
Zu Beginn des Projektes erledigten die Mitglieder der Projektleitung alle anfallenden
Aufgaben. Die unerwartet schnelle Entwicklung verlangte eine Aufteilung der
Arbeiten. Deshalb wurde auf den Beginn 1991 die heute gültige Projektorganisation
eingeführt, die 1993 entsprechend erweitert wurde. Im Folgenden finden Sie eine
kurze Aufgabenbeschreibung der einzelnen Arbeitsgruppen.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 4-23

EANCOM-Handbuch
4.2.2 Messagedesign
Das Projekt EANCOM-CH
Die Arbeitsgruppe Messagedesign mit ihren Taskforces entwickelt auf der Basis
UN/EDIFACT und EANCOM die EANCOM-CH-Beschreibung und die Ablaufvorschriften.
Sie veranlasst die Freigabe der Messages.
Die Auswahl der einzuführenden Messages erfolgt ausschliesslich nach den Anforderungen
der EANCOM-CH-Benutzer. Über die UserGroup hat das einzelne Mitglied
die Möglichkeit, diesen Auswahlprozess direkt zu beeinflussen.
4.2.3 EDIFICAS
Die Arbeitsgruppe EDIFICAS unter der Leitung der ATAG, Ernst & Young beschäftigt
sich mit den revisionstechnischen Aspekten von EDI und den speziell damit zusammenhängenden
Messages. Ausserdem gehören auch Thematiken wie 'EDI und
Mehrwertsteuer' zu ihren Aufgaben.
4.2.4 Stammdaten
Die Arbeitsgruppe Stammdaten erarbeitet den Umfang und Inhalt der zentralen
Datenbanken. Sie überwacht die Abwicklung der Realisierung und den laufenden
Betrieb dieser Datenbanken.
4.2.5 Kommunikation
Die Arbeitsgruppe Kommunikation mit ihren Taskforces erarbeitet die Grundlagen
für die Kommunikation zwischen EANCOM-CH-Partnern unter sich, sowie
EANCOM-CH-Partnern und Clearing-Houses. Ihr Aufgabenbereich erstreckt sich
dabei, von wenigen Ausnahmen abgesehen, vom Inhouse-File des Absenders bis
zum Inhouse-File des Empfängers. Die Arbeitsgruppe verfolgt die Entwicklung im
internationalen Bereich bezüglich zukünftiger Protokolle und Übermittlungsstrategien,
um den reibungslosen Datenaustausch national und international auch in Zukunft
sicherzustellen.
Die Zertifizierung weiterer Clearing-Houses und Netzwerke wird durch die Arbeitsgruppe
initiiert und durch EAN (Schweiz, Suisse, Svizzera) ausgeführt.
4.2.6 EANCOM-CH UserGroup (EUG)
Die EUG's werden geleitet von Herrn M. Wunderlin, COOP Schweiz (für die
Deutschschweiz) und von Herrn J. Fernandez, Uhlmann-Eyraud (für die französischsprechende
Schweiz). Die Adressen finden Sie im Adressverzeichnis.
An den Tagungen werden in der Form von Referaten und Workshops die Teilnehmer
mit EANCOM-CH und den benachbarten Fachgebieten vertraut gemacht. Die
EUG hat auch die Möglichkeit, auf Grund von praktischen Erfahrungen mit
EANCOM-CH, Verbesserungsvorschläge und Änderungsanträge an die Projektleitung
zu richten. Damit ist die Gefahr einseitiger Optik seitens der Projektleitung und
der Arbeitsgruppen weitgehend eliminiert.
Seit 1995 existieren zwei EUG's: die deutschsprachige EUG und die französischsprachige
EUG (EUG Romandie).
4.3 Dokumentation
Die EANCOM-Dokumentation umfasst zwei Handbücher:
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 4-24

EANCOM-Handbuch
Das Projekt EANCOM-CH
• Das EANCOM-Manual mit den von EAN International freigegebenen Messages
(englisch).
• Das EANCOM-CH Handbuch beschreibt die zur Einführung und zum Betrieb
von EANCOM-CH notwendigen Verfahren und Abläufe und enthält die minimalanforderungen
an Messages. Weitergehende Informationen finden sich in
den Veröffentlichungen von EANCOM und UN/EDIFACT.
Darüber hinaus informiert die EAN (Schweiz, Suisse, Svizzera) regelmässig in
Form von Bulletins über den Stand und Fortschritt des Projektes, sowie über Ausbildungsmöglichkeiten.
4.4 Die Ansprechpartner
4.4.1 EAN (Schweiz, Suisse, Svizzera)
Für Fragen im Zusammenhang mit dem EAN-System, EANCOM-CH-
Dokumentation, Mitgliedschaft EAN (Schweiz, Suisse, Svizzera) und EANCOM-CH
UserGroup stehen die Mitarbeiter der EAN (Schweiz, Suisse, Svizzera) zur Verfügung.
Den Mitgliedern werden vielfältige Dienstleistungen, insbesondere im Zusammenhang
mit dem EAN-System, angeboten.
Als Koordinationsstelle zwischen EANCOM-CH und den nationalen und internationalen
Gremien und Organisationen, sowie durch aktive Mitarbeit in den EANCOM
übergeordneten Standardisierungsarbeitsgruppen, sichert die EAN (Schweiz, Suisse,
Svizzera) die Qualität des EANCOM-Standards.
4.4.2 EANCOM-CH Projektleitung
Alle Informationen zum Projekt EANCOM-CH - Ablauf, Stand, Arbeitsgruppentätigkeit,
usw. - sind bei der Projektleitung verfügbar. In einem beschränkten Rahmen
steht die Projektleitung für Vorabklärungen bei der Einführung von EANCOM-CH-
Anwendungen zur Verfügung. Für Beratung und Unterstützung eines Projektes
muss jedoch bei Bedarf ein Beratungsauftrag an ein entsprechendes Unternehmen
erteilt werden. Siehe auch Kapitel Adressen.
4.4.3 EANCOM-CH UserGroup
Jeder Anwender von EANCOM ist automatisch auch Mitglied der entsprechenden
EUG. Damit die Informationen auch zielgerichtet verteilt werden können, ist die
Projektleitung über weitere Anwender zu informieren.
Über die laufenden und die geplanten Aktivitäten sind Auskünfte bei der Leitung
der EUG's erhältlich. Dies gilt ebenso für Fragen in Zusammenhang mit dem Änderungsantrags-Prozess
sowie für Anregungen und Wünsche für alle Belange der
EUG.
4.4.3.1 Ziele
Für die Einführung von EDI liegen heute bereits Erfahrungen vor. Jedoch sind die
auf dem Markt verfügbaren Ausbildungsmöglichkeiten in der Regel zu allgemein
gehalten, um echte Hilfe bei der Realisierung eines EDI-Projektes zu bieten. Die
EUG bietet daher dem Entscheidungsträger und dem Projektmitarbeiter die Gelegenheit,
aus erster Hand über EANCOM-CH informiert zu werden. Erfahrungen aus
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 4-25

EANCOM-Handbuch
Das Projekt EANCOM-CH
den Pilotinstallationen von EANCOM-CH, Berichte über das Angebot im EDI-
Bereich, sowie Diskussionsrunden sollen den Einstieg in EDI-Projekte erleichtern.
4.4.3.2 Veranstaltungen
Es werden jährlich vier Veranstaltungen, zwei in Deutsch und zwei in Französisch
organisiert. Die Themenwahl folgt dabei einerseits dem Entwicklungsstand
EANCOM-CH, andererseits haben die Mitglieder die Möglichkeit, das Angebot zu
steuern.
Grundsätzlich werden immer die folgenden Themen behandelt:
• Bericht des Projektleiters EANCOM-CH
• Bericht der Arbeitsgruppen
• Erfahrungen Pilotinstallationen
Dazu kommen Workshops für neue Messages, Präsentationen von Projekten oder
Angeboten etc.
4.4.3.3 Anträge
Um einen möglichst stabilen Standard zu erreichen, müssen die freigegebenen
Messages für drei Jahre eingefroren werden. Die EUG hat aber die Möglichkeit,
Änderungen an den Messages zu beantragen. Die Anträge werden durch die Arbeitsgruppe
MD geprüft und zu Handen der EUG beantwortet. Nach Ablauf der
Sperrfrist werden die akzeptierten Änderungen in die Messages implementiert.
4.5 EANCOM-CH Ausbildung
4.5.1 Grundausbildung
Die EAN (Schweiz, Suisse, Svizzera) bietet seit 1992 Lehrgänge für die Einführung
von EDI mit EANCOM-CH an. Ebenso wird mit dem Ausbildungsprogramm, wie
bisher, das notwendige Wissen um das EAN-Numerierungs-System vermittelt.
4.5.2 Informationstagungen
EAN (Schweiz, Suisse, Svizzera) organisiert jährlich zwei Informationstagungen
(eine in Deutsch, eine in Französisch) für Firmen, die sich grundsätzlich über EDI
informieren möchten oder die sich mit dem Gedanken tragen, EDI einzuführen.
Auskunft über Kurse und Kursdaten sind bei der Geschäftsstelle der EAN (Schweiz, Suisse,
Svizzera) erhältlich.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 4-26

EANCOM-Handbuch
Die Clearing-Houses
5 Die Clearing-Houses
EDI wird schon aus wirtschaftlichen Gründen sinnvollerweise nicht nur mit einem
Partner durchgeführt. Schon bei der Realisation der ersten Verbindung sollte man
weitere Partner ins Auge gefasst haben. Werden mehrere Verbindungen in traditioneller
Weise (Point-to-Point) etabliert, entsteht ein grosser technischer und administrativer
Aufwand. Das Clearing-House erlaubt, alle Verbindungen über eine
einzige Leitung und mit einer einheitlichen Prozedur herzustellen. Das Clearing-
House wird zur Dokumentverteilstelle und ist verantwortlich, dass die Messages
den richtigen Adressaten erreichen.
Dies muss nach bestimmten Regeln geschehen. Insbesondere ist es wichtig, dass
ein Geschäftspartner nicht unbedingt am selben Clearing-House angeschlossen
sein muss, d.h. die verschiedenen Clearing-Houses müssen in der Lage sein, EDI-
Messages ihrer Kunden untereinander auszutauschen (Internetworking). Die Einhaltung
dieser und weiterer, durch EANCOM-CH definierter, Anforderungen wird in
einem Zertifizierungsverfahren geprüft.
Folgende Clearinghäuser sind per Dezember 1998 zertifiziert:
• IBM Schweiz
• SWISSCOM
• Telekurs
• GEIS
• multilateral
Die Adressen und Ansprechpartner befinden sich im Adressverzeichnis.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 5-27

EANCOM-Handbuch
Der Entscheid
6 Der Entscheid
Die Freigabe für ein EDI-Projekt ist oft nicht einfach zu erreichen. Insbesondere,
wenn nur eine einzige Verbindung in der Projektplanung enthalten ist, wird es
schwierig, einen ROI nachzuweisen. Sehr viele Firmen warten daher auf den Zeitpunkt,
wo sie von einem wichtigen Geschäftspartner dazu gedrängt werden. Da
dies meist in einem ungünstigen Zeitpunkt geschieht, und das Projekt unter Zeitdruck
realisiert werden muss, ist dringend von einer solchen Abwartehaltung abzuraten.
Ein aktives Engagement für EDI erlaubt die Durchführung des Projektes zu einem
der eigenen Firma genehmen Zeitpunkt.
6.1 Unternehmensstrategie
EDI beginnt man in der Regel nicht wegen eines einzigen Partners. Ein solches
Projekt muss deshalb Teil der mittelfristigen Unternehmensstrategie sein. Diese
sollte den Kreis der potentiellen EDI-Partner definieren, den Umfang des zukünftigen
Dokumentenaustausches und die Geschäftsbereiche, welche durch die strategische
Bedeutung von EDI möglicherweise reorganisiert werden müssen.
Das erhebliche Rationalisierungpotential, welches durch den Einsatz von EDI zur
Verfügung steht, kann nur genutzt werden, wenn die Unternehmensstrategie den
Betrieb darauf ausrichtet. Allein die signifikanten Kosteneinsparungen, die bei
mehreren Partnern ohne weiteres zu realisieren sind, sollten für eine Geschäftsleitung
Ansporn genug sein, um EDI in eine unternehmensweite Strategie einzubinden.
6.2 Voraussetzungen
Die folgenden Ausführungen basieren auf den Erfahrungen aus dem Pilotbetrieb
und konnten in vielen produktiven Installationen verifiziert werden.
Das Schwergewicht bei einer EDI-Einführung liegt mit Sicherheit im Bereich von
Analyse und Organisation. Wesentlich sind dabei eine mittel- und langfristige Optik,
um eine EDIFAX-Lösung zu vermeiden, da eine solche nur zusätzliche Kosten
verursacht und keinerlei Rationalisierungswirkung hat. Ausserdem erlaubt eine
längerfristige Betrachtungsweise die Ausrichtung des EDI-Projektes für mehrere
Partner. Werden diese bei der Analyse und Organisation bereits berücksichtigt, reduziert
sich der Aufwand für jeden weiteren Anschluss wesentlich. Das bedeutet
eine signifikante Verminderung des Fixkostenanteils je Verbindung und macht aus
einem EDI-Projekt eine betriebswirtschaftlich äusserst erfolgreiche Anwendung.
Bei der Analyse der möglichen Einsatzgebiete sind die in Entwicklung befindlichen
Nachbarprojekte ebenfalls zu berücksichtigen. So ist nicht nur der Dokumentenaustausch
im Bereich Handel - Hersteller möglich. Die Abwicklung des Geldverkehrs
über die PTT oder die Banken oder der gesamte Bereich von Transport und
Zoll sind weitere interessante Einsatzmöglichkeiten. Eine strategische Ausrichtung
des EDI-Projektes unter Einbezug aller Möglichkeiten ist deshalb notwendig, auch
wenn in einem ersten Schritt nur ein Teilbereich realisiert werden kann.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 6-28

EANCOM-Handbuch
6.2.1 Geschäftsleitung
Der Entscheid
Die strategische Bedeutung für das Unternehmen, sowie insbesondere der, in jedem
Fall, bereichsübergreifende Charakter eines EDI-Projektes verlangt das direkte
Engagement der Geschäftsleitung. Die Erfahrung zeigt, dass im Verhältnis
Kunde - Lieferant neue partnerschaftliche Beziehungen auf Grund dieser Projekte
aufgebaut werden konnten. Da eine gegenseitige organisatorische Abstimmung
notwendig wird, schafft EDI engere Beziehungen zum Geschäftspartner, welche
auf gegenseitigem Verständnis und Vertrauen basieren.
6.2.2 Mitarbeiter
Das erhebliche Rationalisierungspotential von EDI schafft natürlich auch Skepsis
bei den betroffenen Mitarbeitern im Unternehmen. Eine rechtzeitige Einbindung der
Abteilungen, die mit EDI in Berührung kommen, ist daher absolut notwendig. Die
offene Information verhindert den Aufbau von Defensivpositionen und garantiert
den weitgehend reibungslosen Ablauf des Projektes.
6.2.3 Informatik
Die Mitarbeiter der Informatik sind gefordert bei der Realisierung der "Enabling Applikation"
und bei Test und Betrieb der EDI-Verbindungen. Es ist jedoch wenig
sinnvoll, und auch nicht besonders wirtschaftlich, die eigentliche EDI-Umgebung
selbst entwickeln zu wollen. Die Ausbildung von hauseigenen Spezialisten ist kostenintensiv
und wird in der Regel nur für die erste EDI-Verbindung gebraucht. Eine
EDI-Umgebung kann heute bei verschiedenen Lieferanten (siehe Kapitel Adressen)
praktisch ab der Stange eingekauft werden. Ebenso sind heute genügend
kompetente Beratungsunternehmen vorhanden, die bei der Analyse und Organisation
unterstützen können. Wesentlich ist darauf zu achten, dass die Produkte
EANCOM-CH-tauglich sind, und dass die Berater bereits praktische Erfahrung bei
der Einführung von EDI in der Branche vorweisen können.
6.3 Erfolgsfaktoren
Ob ein EDI-Projekt erfolgreich in Betrieb geht, hängt in erster Linie vom Bereitschaftsgrad
des Unternehmens ab, sich organisatorisch an die neuen Gegebenheiten
anzupassen. Die übrigen Erfolgsfaktoren sind sicher erwähnenswert, haben
aber nur dann ein Gewicht, wenn diese Grundvoraussetzung erfüllt ist.
6.3.1 Wettbewerbsvorteile
Unzählig sind die Vorteile, welche an Fachtagungen aufgezählt werden, oder in
Zeitungen nachzulesen sind. Mit Sicherheit ergibt sich aus einem, mit dem Geschäftspartner
gemeinsam erarbeiteten, EDI-Projekt eine intensivere Geschäftsbeziehung,
die für beide Seiten Vereinfachungen ihrer Geschäftsabläufe mit sich
bringt. Dies ist der Wettbewerbsvorteil gegenüber Mitbewerbern, welche noch nicht
soweit sind.
6.3.2 Rationalisierungspotential
Sicherlich hat zuerst der Empfänger von EDI-Dokumenten die grossen Erleichterungen,
da der Datenerfassungsaufwand entfällt und eine weitgehend fehlerfreie
Übermittlung sichergestellt werden kann. Wissenschaftliche Untersuchungen zeigen
aber auch für beide Seiten eine signifikante Einsparungsmöglichkeit beim
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 6-29

EANCOM-Handbuch
Der Entscheid
Übermitteln von Geschäftsdokumenten, welche gegenüber traditionellen Versandarten
(Brief, Fax, Telefon) bis zu 90% erreichen kann.
6.3.3 Neue Struktur der Geschäftsabläufe
Der Einsatz von EDI ermöglicht die Anpassung der traditionellen linienorientierten
Organisationen in flexiblere, kooperative Modelle. Diese Chance sollte unbedingt
genutzt werden, auch wenn damit über das EDI-Projekt hinaus Aufwand betrieben
wird. Die laufende Entwicklung in die Richtung von elektronischen Märkten und der
immer fühlbarer werdende Konkurrenzdruck verlangen ergänzende Dienstleistungen
zum reinen Verkaufsablauf. Eine dieser Dienstleistungen gegenüber dem Geschäftspartner
ist EDI. Das Schlagwort vom Anbinden des Geschäftspartners hat
hier mit Sicherheit seine Wirkung.
6.4 Erweiterte Überlegungen
6.4.1 Einkauf
Pos Sender Nachrichtentyp Empfänger O.K
1 Firma ORDERS (Bestellungen) Lieferant
2 Lieferant ORDRSP (Bestellantwort) Firma
3 Firma ORDCHG (Bestelländerung) Lieferant
4 Lieferant IFTMIN (Transportauftrag) Transporteur
5 Lieferant DESADV (Lieferavis) Firma
6 Firma RECADV (Warenempfang) Lieferant
7 Lieferant INVOIC (Rechnung) Firma
8 Firma PAYORD (Zahlungsauftrag) Bank
9 Bank DEBADV (Belastungsanzeige) Firma
10 Bank CREADV (Gutschriftanzeige) Lieferant
6.4.2 Verkauf
Pos Sender Nachrichtentyp Empfänger O.K.
1 Kunde ORDERS (Bestellungen) Firma
2 Firma ORDRSP (Bestellantwort) Kunde
3 Kunde ORDCHG (Bestelländerung) Firma
4 Firma IFTMIN (Transportauftrag) Transporteur
5 Firma DESADV (Lieferavis) Kunde
6 Kunde RECADV (Warenempfang) Firma
7 Firma INVOIC (Rechnung) Kunde
8 Kunde PAYORD (Zahlungsauftrag) Bank
9 Bank DEBADV (Belastungsanzeige) Kunde
10 Bank CREADV (Gutschriftanzeige) Firma
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 6-30

EANCOM-Handbuch
Der Entscheid
11 Transporteur INVOIC (Rechnung) Firma
12 Firma PAYORD (Zahlungsauftrag) Bank
13 Bank DEBADV (Belastungsanzeige) Firma
14 Bank CREADV (Gutschriftanzeige) Transporteur
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 6-31

EANCOM-Handbuch
Das Projekt
7 Das Projekt
Die Einführung von EDI unterscheidet sich grundsätzlich von anderen Informatikund
Logistikprojekten. EDI kann ein Unternehmen nicht für sich allein einführen, es
braucht dazu einen Partner. Neu ist daher, dass ein solches Projekt zusammen mit
dem Geschäftspartner realisiert werden muss. Dies hat Einfluss auf die Projektteam-Zusammensetzung
und auf die Entwicklungsvorhaben in beiden Firmen.
7.1 Die Partner-Organisation
Der gegenseitige Einblick in die Organisation des Partners ist eine grundsätzliche
Voraussetzung für die Einführung von EDI. Die zum Einsatz gelangenden Messages
sind festzustellen, die Besonderheiten der Datenhandhabung müssen identifiziert
werden, Ablaufregeln und Fehlerbehandlung müssen abgesprochen werden.
Der Zeitplan für das ganze Projekt inkl. Tests und die Übernahme in die Produktion
sind abzustimmen. Ausserdem sind die Anschlüsse an ein Netzwerk und an ein
Clearing-House zu organisieren und zu testen. Es ist unerlässlich, alle Absprachen,
welche über die EANCOM-CH-Regeln hinausgehen, in einem Vertrag, dem
Data Interchange Agreement (DIA), festzuhalten.
7.2 Analyse der betroffenen Geschäftsabläufe
In diesem Analysebereich werden erfahrungsgemäss die meisten Fehler gemacht.
Gerade diese haben aber meist zur Folge, dass später kein vollautomatischer EDI-
Betrieb möglich wird. Die hier aufgewendete Sorgfalt bestimmt somit direkt den
Erfolg der EDI-Einführung.
Grundregel für diese Analyse ist, dass alle Erhebungen auf der Stufe Sachbearbeiter
durchzuführen sind. Bei einer gut eingespielten Geschäftsbeziehung werden
von Sachbearbeitern auf beiden Seiten sehr oft Erleichterungen geschaffen, die
nicht ohne weiteres bei der Umstellung auf EDI übernommen werden können, welche
aber als Dienstleistungen erhalten bleiben sollten. Auf Grund einer Analyse auf
dieser Ebene auf beiden Seiten finden sich aber in den meisten Fällen einvernehmliche
Lösungen, welche den Standard nicht durchlöchern.
7.3 Analyse der betroffenen Anwendungen
Die Definition, welche Anwendungen von EDI betroffen sind, ist nicht einfach.
Grundsätzlich kann davon ausgegangen werden, dass alle Anwendungen des Einkaufs,
der Kundenauftragsbearbeitung, der Buchhaltung sowie der Logistik betroffen
sind. Das schnellere Eintreffen der Daten hat auch gesteigerte Anforderungen
an Lieferbereitschaft, Disposition, Vertrieb, usw. zur Folge.
Bei der Analyse der betroffenen Anwendungen sind auf beiden Seiten daher nicht
nur die unmittelbar berührten Ein- oder Ausgangsapplikationen, sondern auch die
darauf Folgenden zu untersuchen.
7.3.1 Evaluation der Hilfsmittel
Um einen möglichst grossen Rationalisierungsgrad in einem EDI-Projekt zu erreichen,
ist es von grosser Wichtigkeit, die eigentliche EDI-Umgebung den Anforderungen
entsprechend auszuwählen.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 7-32

EANCOM-Handbuch
Zu dieser EDI-Umgebung zählen:
Das Projekt
• der Konverter
• die Kommunikationssoftware
• das Clearing-House
• die entsprechende Hardware
• die Kommunikationseinrichtung
Diese Komponenten sollten möglichst modular aufgebaut sein, das heisst, es sollte
möglich sein, dass einzelne Komponenten unabhängig von den anderen ausgetauscht
werden können. Bei der Auswahl der EDI-Umgebung ist dieser Anforderung
besonders hohes Gewicht einzuräumen. Im Gegensatz zur Enabling-
Applikation, welche eine ähnliche Lebensdauer wie andere Anwendungen hat, ist
der eigentliche EDI-Teil häufigen Änderungen (Kommunikation, internationale
Standards, usw.) unterworfen. Eine hohe Flexibilität dieser Komponenten, ist daher
unabdingbar.
Der Nutzen von EDI liegt im Umstand, dass soviel wie möglich automatisch, das
heisst ohne menschliche Eingriffe, abläuft. Dies gilt in ganz besonderem Masse für
die EDI-Umgebung. Mit den heutigen technischen Mitteln ist es ohne weiteres
möglich, eine entsprechende Automatisierung zu erreichen. Die nötigen Produkte
sind heute in vielfältiger Anzahl auf dem Markt zu kaufen. Die Unterstützung dieser
Produkte wird auf dem Markt ebenfalls vielfältig angeboten, es besteht also keine
Notwendigkeit wegen EDI eine eigene Telekommunikationsabteilung zu unterhalten.
Besonderer Augenmerk ist auf die Überwachung der EDI-Umgebung zu legen. Da
normalerweise keine Eingriffe nötig sind, und die Zuverlässigkeit der heute verfügbaren
Produkte in einem zufriedenstellenden Masse vorhanden ist, wird man erst
spät, eventuell zu spät, auf einen Fehler aufmerksam. Um dies zu verhindern, müssen
entsprechende Kontrollmechanismen entwickelt werden, welche die Überwachung
und Benachrichtigung der zuständigen Stellen übernehmen.
Die meisten Organisationen welche EDI betreiben, werden sofort oder mit Zunahme
des Integrationsgrades von EDI sowohl zum Empfänger als auch zum Sender
von EDI-Dokumenten. Am Ablauf des elektronischen Bestellvorganges kann dies
deutlich aufgezeigt werden: So wird die Message 'Purchase Order' (für Bestellung),
vom Besteller an den Lieferanten geschickt, die 'Order Response' (für Bestellbestätigung
und Fehler) wird vom Lieferanten an den Besteller geschickt, und die
'Order Change' Message (für Bestelländerung) wird wiederum vom Besteller abgeschickt.
Es ist daher bei der Evaluierung und Auslegung der EDI-Umgebung darauf
zu achten, dass diesem Umstand Rechnung getragen wird. Es müssen also sowohl
Daten abgeschickt als auch empfangen werden können, auch wenn die EDI-
Dokumente am Anfang vielleicht nur in eine Richtung laufen.
7.4 Clearing-House
Mit den heutigen Kommunikationseinrichtungen ist es möglich alle nötigen Verbindungen
zu den potentiellen EDI-Partnern herzustellen. Die Daten werden durch
das Standard-Format UN/EDIFACT von der Hardware unabhängig. Warum also
noch ein Clearing-House?
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 7-33

EANCOM-Handbuch
Das Projekt
Trotz des grossen Fortschritts in der Kommunikationstechnik ist der Datenaustausch
mit mehreren Partnern mit grossem Überwachungs- und Verwaltungsaufwand
verbunden. Dieser Umstand, sowie die Einrichtung von zentralen Datenbanken
rechtfertigen den Einsatz von Clearing-Houses. Hier die wichtigsten Funktionen,
welche ein Clearing-House erfüllen muss:
• Drehscheibenfunktion. Das Clearing-House vermittelt die eingehenden EDI-
Files an die adressierten Partner.
• Aufheben der Zeitabhängigkeit für die Benutzer. Ein EDI-File kann jederzeit
ans Clearing-House gesendet werden, auch wenn der Zielpartner nicht empfangsbereit
ist.
• Eine Verbindung zu allen Partnern. Für die EDI-Teilnehmer ist nur eine Verbindung
zu seinem Clearing-House notwendig, um alle EANCOM-CH-Partner
an allen Clearing-Houses zu erreichen.
• Logging, Auditing. Nachweis des Datenverkehrs zwischen den EDI-Partnern
und dem Clearing-House. Der EDI-Datenverkehr kann nach verschiedenen Kriterien
überprüft und im Fehlerfall nachvollzogen werden.
• Speichern von Messages. Die Möglichkeit EDI-Messages für eine wählbare
Zeit speichern zu lassen. Es darf keine Message verloren gehen!
• Ansprechpartner. Die Clearing-Houses fungieren als Ansprechpartner in vielfältigen
EDI-Belangen.
Im Rahmen des EANCOM-CH-Projekts werden Empfehlungen für Clearing-Houses
abgegeben. Die Clearing-Houses, welche dabei empfohlen werden, haben eine
Prüfung durchlaufen und wurden von EANCOM-CH zertifiziert. So wird Ihnen die
Wahl ein wenig leichter gemacht. Weitere Dienstleistungen sogenannte 'added
values' werden von EANCOM-CH nicht beurteilt, können bei der Wahl des Clearing-Houses
aber eine nicht unbedeutende Rolle spielen. Verlangen Sie in jedem
Falle eine Referenzliste und sprechen Sie mit den Ihnen bekannten Firmen.
Neben den eigentlichen Clearingfunktionen werden von EANCOM-CH-Clearing-
Stellen noch weitere Services gefordert: Diese Punkte sollten vor der Wahl des
Clearing-Houses überprüft werden.
• Betriebszeiten. Es wird eine Betriebszeit von 24 Stunden an 7 Tagen der Woche
gefordert. Jährlich werden maximal 2 grössere Servicefenster bis 6 Stunden
toleriert, welche aber mindestens 4 Wochen im voraus bekannt gegeben werden
müssen.
• Verfügbarkeit. Es wird eine minimale Verfügbarkeit von 99% der oben genannten
Betriebszeiten gefordert. Auf Anfrage muss dokumentiert Auskunft gegeben
werden. Ausserdem haben EANCOM-CH-Teilnehmer, via UserGroup, die Möglichkeit
auf die Nichteinhaltung der Betriebszeiten aufmerksam zu machen.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 7-34

EANCOM-Handbuch
Das Projekt
• Hot Line (Help-Desk). Es soll ein Help-Desk während der Betriebszeiten verfügbar
sein. Der Help-Desk behandelt eventuelle Störungen und soll schnell und
zuverlässig funktionieren. Die Hot Line soll während der Betriebszeiten verfügbar
sein.
• Query Desk. An den Query Desk sind Anfragen zu richten, welche über den
Help-Desk hinaus gehen. Der Query Desk ist während den normalen Bürozeiten
verfügbar.
• Zustellzeit. Die EANCOM-CH-Clearing-Houses verpflichten sich eine maximale
Übertragungszeit von 15 Minuten je beteiligtem Clearing-House zu garantieren.
• Restart und Recovery. Für den Störungsfall müssen die Wiederanlaufverfahren
definiert und allen beteiligten Personen bekannt sein.
• Ausfallplanung. EANCOM-CH fordert eine Massnahmenplanung für den Ausfall
der Clearing-House-Funktionen. Darin sind die Massnahmen zur Wiederherstellung
der Clearingfunktionen nach Unterbrüchen enthalten.
• Internetworking. Die zertifizierten Clearing-Houses haben untereinander etablierte
Verbindungen, damit Sie sich frei für ein Clearing-House entscheiden
können. Das heisst Ihre EDI-Dokumente erreichen auch Partner an den anderen
Clearing-Houses, ohne dass Sie zu diesem anderen Clearing-House eine weitere
Verbindung haben müssen. Dieses Internetworking ist bei den zertifizierten
Clearinghäusern zumindest für EANCOM-Anwender kostenlos.
• Datenschutz. Die Dokumente müssen vor Missbrauch und unerlaubtem Zugriff
geschützt werden. Der EDI-Teilnehmer muss eindeutig identifiziert werden.
• Datensicherheit. Die Daten müssen vor Verlust geschützt sein.
• Übertragungsbestätigung. Der Absender muss eine eindeutige Nachricht erhalten,
wenn die Daten beim Empfänger vollständig eingetroffen sind. (z.B.
EERP, ACK, delivery note).
• Identifikation und Authentizierung. Beim Aufbau einer Verbindung muss die
gegenseitige Berechtigung zum Datenaustausch erteilt werden. Die Absender-
Identifikation muss auf dem ganzen Weg mitgeführt werden. In Zukunft wird die
digitale Unterschrift eine grosse Rolle in der Frage der Authentizität, Integrität
und der Unverwechselbarkeit spielen.
Dies sind einige wichtige Anforderungen, welche das EANCOM-CH-Projekt an die
Clearing-Houses stellen. Die technische Entwicklung auf diesem Gebiet ist enorm.
Die Anforderungen werden daher von der Arbeitsgruppe Kommunikation laufend
überprüft und den neuen technischen Möglichkeiten angepasst.
Um eine optimale Integration zu ermöglichen ist bei der Auswahl des Clearing-
Houses darauf zu achten, wie die benötigte Hard- und Software in die übrige Informatiklandschaft
passt. Die Anschluss-Szenarien sind vielfältig und sollten sorgfältig
gegeneinander abgewägt werden. Als Beispiel sei hier das Frontend-Konzept
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 7-35

EANCOM-Handbuch
Das Projekt
genannt, in welchem der Konverter und die eigentliche Kommunikationsumgebung
vom Applikationsteil physisch getrennt sind, und so eine gewisse Unabhängigkeit
erreicht wird. Die Frage, ob ein Wachstum des EDI-Volumens ohne weiteres möglich
ist, muss zu gegebener Zeit beantwortet werden. Auch sollte man sich den
Schritt in Richtung neuer Übermittlungstechniken und Services offenhalten und in
die Überlegungen mit einbeziehen.
7.5 Netzwerk
Bei den Netzwerken unterscheiden wir zwischen den öffentlichen (PTT) und den
privaten Netzen (IBM, GEIS, SWISSCOS, Telekurs usw). Zwischen den grösseren
Netzwerken bestehen Gateways, die es erlauben von einem Netzwerk ins andere
zu gelangen.
Um eine Verbindung zum Clearing-House herzustellen, benutzt man öffentliche
oder private Netzwerke oder eine Kombination davon. Unter Berücksichtigung von
eventuellen bereits installierten Infrastrukturen, sollte die bestmöglichste Variante
gewählt werden. Als Faustregel gilt: Je direkter der Anschluss am Clearing-House,
desto besser und vor allem auch kostengünstiger. Zumeist wählt man mit dem
Clearing-House auch automatisch das Netzwerk.
7.6 EDI-Konverter
Der Konverter 'übersetzt' die von der Applikation zur Verfügung gestellten Daten
(Inhouse-File) in das EDI-Format und umgekehrt. Im EANCOM-CH-Projekt wird das
UN/EDIFACT-Format verwendet. Dieses UN/EDIFACT-Format ist das international
gültige Format und beschreibt Dokumente der Bereiche Administration, Handel und
Transport. Dieser Standard wird von UNO-Gremien entwickelt und veröffentlicht.
Dabei werden in Abständen neue bzw. revidierte Messages und allenfalls Directory-Versionen
herausgegeben.
Der in EANCOM-CH zum Einsatz kommende Konverter muss auf der EDI-Seite
immer 100-prozent dem UN/EDIFACT-Standard entsprechen. Damit ist auch ein
internationaler Datenaustausch mit EANCOM-CH möglich.
Neben dem Format ist bei der Auswahl des Konverters dessen Flexibilität besonders
wichtig. Dabei soll es möglich sein, verschiedene Versionen von Messages
und Directories gleichzeitig im Einsatz zu haben. Die Unterstützung des in Frage
kommenden Konverters muss durch den Lieferanten gewährleistet sein. Diese
Unterstützung muss auch die Installation und Wartung, sowie die Nachlieferung
von neuen Versionen von Messages und Directories - in einer möglichst nützlichen
Frist - umfassen.
7.7 Übermittlungs-Software
Die Anschlussmöglichkeiten und damit die Kommunikationseinrichtungen sind sehr
vielfältig. Die Entwicklung geht auch hier in Richtung allgemeiner internationaler
Standards. Diese normierten Protokolle erlauben es, verschiedene Hardware-
Plattformen einander näher zu bringen und den Datenaustausch zwischen Ihnen zu
ermöglichen.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 7-36

EANCOM-Handbuch
Das Projekt
Für den elektronischen Datenaustausch kommen vor allem die CCITT X.400 Empfehlungen
zum Tragen, aber auch die X.500-Normen werden im elektronischen
Datenaustausch eine gewisse Rolle spielen. Die Normierungsgremien haben erste
Empfehlungen herausgegeben, welche unter dem Begriff X.400(84) bekannt geworden
sind. In diesen Empfehlungen fehlen leider Funktionen, welche für den
elektronischen Datenaustausch unbedingt notwendig sind. Daraus entstanden proprietäre
Zwischenlösungen, welche natürlich von einem Standardisierungsgremium,
wie EANCOM-CH, nicht empfohlen werden dürfen. Der inzwischen freigegebene
Standard X.400(88) enthält diese fehlenden Funktionen. Zusätzlich wurde für
EDI aber auch noch die Empfehlung CCITT X.435 entwickelt. X.400 und X.435
werden für den elektronischen Datenaustausch in den nächsten Jahren von grosser
Wichtigkeit sein. In EANCOM-CH wird empfohlen, zum Zeitpunkt der Verfügbarkeit
von Produkten, welche die CCITT Empfehlungen X.400(88) und X.435 implementiert
haben, auf diesen Standard zu wechseln. Dieser Zeitpunkt ist heute erreicht.
In der Zwischenzeit wurden Übergangslösungen benutzt. So ist zum Beispiel das
ODETTE File Transfer Protokoll (OFTP) eine Möglichkeit, welche der verlangten
Funktionalität einigermassen nahe kommt und den heutigen Anspüchen genügt.
Bei der Auswahl der entsprechenden Kommunikationssoftware sollte neben Hardwarevoraussetzungen
auch die Store-and-Forward-Übermittlung, das End-zu-End-
Protokoll, das auftretende EDI-Volumen und die Call-out Funktion in die Überlegungen
miteinbezogen werden. Auf jeden Fall ist darauf zu achten, dass eine Entwicklung
in Richtung zukünftiger Kommunikationsprotokolle nicht verhindert wird.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 7-37

EANCOM-Handbuch
Realisierung
8 Realisierung
Die Realisierung einer EDI-Verbindung unterscheidet sich in einigen Punkten von
anderen Informatikprojekten. In zwei Firmen müssen gleichzeitig die Ressourcen
und Kapazitäten für ein gemeinsames Projekt bereitgestellt werden. Es muss ein
zeitlich abgestimmtes Vorgehen gefunden werden, und dies obwohl die beiden
EDI-Partner in den seltensten Fällen über identische Strukturen in der Organisation
verfügen. Dazu kommen die Unterschiede in Hardware, Software, Entwicklungswerkzeugen
und Infrastruktur.
Auch über den Umfang des Projektes können bei den EDI-Partnerfirmen unterschiedliche
Auffassungen vorliegen. An erster Stelle muss daher die strategische
Ausrichtung des Projektes definiert werden:
• Welche Geschäftsbereiche sind betroffen.
• Welche Nachrichten kommen zum Einsatz.
• In welchen Schritten wird die Einführung durchgeführt.
• Werden weitere Ausbauschritte geplant.
• usw.
Das DIA (Data Interchange Agreement) kann mit diesen Informationen bereits eröffnet
werden. Im Verlaufe der Realisierung wird das DIA bei gegebenem Anlass
vervollständigt.
8.1 Zeitplan
Ein EDI-Projekt unterscheidet sich kaum von anderen Projekten. Die Planung kann
ohne weiteres mit den bekannten Projektleitungsmethoden erfolgen.
Für den Zeitplan gilt es darauf zu achten, dass die firmenübergreifende Koordination
zu längeren Durchlaufzeiten führen kann.
8.2 Checkpoints
Die Aktivitätenliste im Anhang des Handbuches soll unter anderem eine Basis für
die Planung von Checkpoints im Verlaufe der Realisierung dienen. Insbesondere
der zeitlichen Abstimmung ist aus den bereits erwähnten Gründen besondere Aufmerksamkeit
zu schenken.
Gewisse Aktivitäten sind von externen Organisationen (Clearinghouse, PTT, Softwarehäusern,
Installateur, etc.) durchzuführen. Sehr oft sind mit diesen Arbeiten
längere Lieferfristen verbunden. Nähert sich das Projekt der Testphase, muss sichergestellt
werden, dass alle vorbereitenden Arbeiten rechtzeitig erledigt und die
einzelnen Komponenten betriebsbereit sind.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 8-38

EANCOM-Handbuch
8.3 Koordination
Realisierung
Wie aus den bisherigen Ausführungen unschwer zu erkennen ist, haben EDI-
Projekte einen erhöhten Koordinationsbedarf. Je nach geographischer Entfernung
zwischen den Partnerfirmen, kann diese Aufgabe nicht immer in der gewohnten Art
und Weise (gemeinsame Projektsitzungen, Bildung von Arbeitsgruppen) durchgeführt
werden. Die vielfältigen Abhängigkeiten verlangen trotz dieser Schwierigkeiten
eine kontinuierliche Koordinationstätigkeit. Es macht Sinn, wenn man sich darauf
verständigt, welche der involvierten Parteien die Koordination übernimmt.
Ein wichtiger Koordinationspunkt ist die Anwendung des EAN-Systems für die Artikel-
und Adressbezeichnungen. Die rechtzeitige Bereinigung der entsprechenden
Daten ist eine Grundvoraussetzung für den Einsatz des EANCOM-Standards. Häufig
werden in den Firmen nur die Verbrauchereinheiten EAN-ausgezeichnet. Für
den korrekten EDI-Betrieb nach den Vorgaben von EANCOM-CH ist es notwendig,
die Numerierung der Adressen und Handelseinheiten durchzuführen. Da diese Informationen
beiden Partnerfirmen zu Verfügung stehen müssen, ist genügend Zeit
für diese Aufgabe vorzusehen und das Ergebnis genau zu überprüfen.
Als unumgängliches Hilfsmittel hat sich in letzter Zeit die Benutzung der von EAN
(Schweiz, Suisse, Svizzera) zur Verfügung gestellten zentralen Stammdatenbank
(Edb) erwiesen.
Nähere Auskünfte darüber können jederzeit bei EAN (Schweiz, Suisse, Svizzera)
eingeholt werden.
8.4 EDI-Umgebung - Eigenentwicklung
Häufig wird in Diskussionen die Absicht geäussert, die Komponenten der EDI-
Umgebung (Konverter, Übermittlungsprogramm, Ablaufsteuerung) selbst zu realisieren.
Von einem solchen Vorhaben ist mit Nachdruck abzuraten. Am Beispiel des
Konverters lässt sich dies belegen. Folgende minimale Eigenschaften muss ein
brauchbarer Konverter aufweisen:
• die Syntax von UN/EDIFACT muss beachtet und interpretiert werden.
• mehrere Directory-Versionen müssen verarbeitet werden können.
• mehrere Message-Releases unterschiedlicher Subsets müssen verarbeitet werden
können.
• Release-Wechsel müssen mit den Partnern einzeln durchgeführt werden können.
Bei einer genügend grossen Anzahl EDI-Beziehungen wird ein Release-
Wechsel per Stichtag undurchführbar.
• die Steuerung des Umsetzungsprozesses muss abhängig vom Partner erfolgen.
• sowohl "incoming", wie "outgoing" Prozesse müssen möglich sein.
• die Inhouse-Files müssen frei programmierbar sein für die Verwendung in verschiedensten
Anwendungen (Bestellungen, Lieferungen, Fakturierung, Zahlungen,
etc.)
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 8-39

EANCOM-Handbuch
Realisierung
Ähnlich komplexe Anforderungen werden auch an die Übermittlungssoftware gestellt:
• korrektes Einhalten des EDI-Protokolls des Clearing-Houses.
• automatische Interpretation der Übermittlungsadresse aus dem Segment UNB.
• Berechtigungsprüfung bei eingehenden EDI-Nachrichten nach gültigem Partner
und vereinbarten Nachrichtentypen.
• automatische Weiterleitung an die weiteren EDI-Prozesse nach aussen und
nach innen.
• Unabhängigkeit vom Übertragungsprotokoll (X.25, SDLC, ASYNC, etc.)
Diese beiden Programme sind auf dem Markt in genügender Auswahl und Qualität
erhältlich. Die Kosten sind auf einem so tiefen Niveau, dass auch eine effiziente
Eigenentwicklung wesentlich teuerer zu stehen kommt.
Die Ablaufsteuerung überwacht und steuert den automatischen EDI-Betrieb. Für
den Einsatz der EDI-Umgebung auf Frontend-PC sind entsprechende Pakete auf
dem Markt bereits verfügbar. Auf Host-Systemen hingegen muss dieser Prozess
mit eigenen Mitteln realisiert werden. Bedingt durch den hohen Know-how- und
Erfahrungsbedarf ist eine Outsourcing-Realisierung empfehlenswert.
8.5 Anwendungsanpassung
Bei der Anpassung der Anwendungen geht es in der Regel darum, Schnittstellen
für den Input und Output von Batchdateien zu realisieren. Dabei ist besonders darauf
zu achten, dass der korrekte EDI-Betrieb vollautomatisch ablaufen soll. Die
Vollautomatik macht jedoch nur Sinn, wenn sie auch das Enabling und die betroffenen
Anwendungen umfasst und der reguläre Ablauf sowie der Fehlerfall richtig
abgewickelt werden. Dazu gehört auch die automatische Generierung von EDI-
Nachrichten und die Übergabe an die EDI-Umgebung.
Grundsätzlich sollen die Anwendungsanpassungen für den Benutzer keine Änderung
in der Applikationsbedienung ergeben. Ebenso muss ein Eingriff in die Logik
der Anwendung vermieden werden. Trotzdem werden, von Fall zu Fall, neue Funktionen
notwendig, welche für den Endbenutzer sichtbar werden. Dazu gehören zum
Beispiel:
• Verwaltung der EPIN's und EAIN's.
• Benachrichtigung über den EDI-Ablauf, z.B. Meldungen aus den Funktionen
"Vollständigkeitskontrolle" und "Nachrichtenverfolgung".
• Anzeige von Nachrichten, welche inhaltliche Fehler aufweisen.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 8-40

EANCOM-Handbuch
Realisierung
• Anzeige von Fehlermeldungen des EDI-Partners mit der Möglichkeit der direkten
Korrektur der von ihm bemängelten Nachrichten. (z.B. ORDRSP und ORDCHG).
• Weitergabe von EDI-Daten an nachgelagerte Anwendungen.
• Empfang von Daten aus vorgelagerten Anwendungen, zwecks Bearbeitung und
Übermittlung an den entsprechenden EDI-Partner.
8.6 Enabling-Applikation
8.7 Test
Die Enabling-Applikation wird sinnvollerweise möglichst modular realisiert. Eine
erfolgreiche EDI-Einführung berücksichtigt bereits bei der ersten Verbindung mögliche
weitere Message-Typen und weitere Partner. Da ein Ende der Entwicklung
zum Zeitpunkt der ersten EDI-Verbindung kaum absehbar ist, muss bei der Modularität
des Enablings besondere Sorgfalt aufgewendet werden. Damit kann verhindert
werden, dass bei Erweiterungen wieder von vorne begonnen werden muss.
Folgende Module sollten minimal vorhanden sein:
• Enabling für Vollständigkeitskontrolle und Messageverfolgung
• zeitabhängige Steuerelemente
• Enabling für incoming Messages
• Enabling für outgoing Messages
• evtl. Handling von non-EDI-Files
• evtl. Enabling für Testübermittlungen
Je nach geplantem Umfang des zukünftigen EDI-Betriebs - Anzahl Messages und
Partner - kann es auch sinnvoll sein, Module je Partner zu realisieren.
Wird einer Front-End-Lösung der Vorzug gegeben, ist die Plazierung der Enabling-
Funktionen genau zu überlegen. Eine Aufteilung in die EDI-bezogenen Funktionen
auf den Front-End und die applikatorischen Funktionen auf den Host als Faustregel
ist eine gute Ausgangslage. Dabei sind auf die Möglichkeiten des Datentransfers
mit dem Host zu achten, um den vollautomatischen Betrieb nicht zu beeinträchtigen.
UN/EDIFACT sieht im Servicesegment UNB das Testkennzeichen vor. Dieses soll
die Trennung von Test- und Produktionsübermittlungen ermöglichen. In der Regel
haben aber nur sehr grosse Rechenzentren die Möglichkeit einen getrennten Betrieb
von Test und Produktion zu unterhalten.
In jedem Fall muss im Enabling das Testkennzeichen geprüft werden, um zu verhindern,
dass Testdaten in die produktiven Verarbeitungen einfliessen.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 8-41

EANCOM-Handbuch
Realisierung
Testübermittlungen werden nicht nur während der Einführung gesendet. Versionswechsel
der EANCOM-Nachrichten, Änderungen in der EDI-Umgebung eines Partners
sind Beispiele für die Notwendigkeit weiterer Tests.
Sicherheitshalber sollte vor Testübermittlungen mit dem Partner Kontakt aufgenommen
werden.
8.8 Sicherheit
EDI öffnet die eigenen Systeme und Anwendungen für die Übermittlungspartner.
Jede Systemöffnung bringt neben allen Vorteilen auch Sicherheitsrisiken mit sich.
Diese sollen an dieser Stelle nicht unnötig dramatisiert werden. Die Kenntnis solcher
Risiken erlaubt aber für jede Installation, die angemessenen Massnahmen zu
treffen, um sie vor unerwünschten "Gästen" zu schützen.
Die folgende Aufzählung von möglichen Massnahmen ist nicht für alle Installationen
gleichermassen verbindlich. Es muss von Fall zu Fall überlegt werden, welche
Schritte zu unternehmen sind:
• Frontend-Installation, d.h. der Kommunikationsteil der EDI-Umgebung (evtl.
auch andere Komponenten) laufen auf einem von der Anwendung getrennten
Rechner. Damit wird auf einfache Art der Zugriff auf die Firmendaten über die
EDI-Verbindung verhindert.
• Mietleitung (X.28) oder Telepac (X.25) zum Kommunikationspartner. Auch hier
wird der Zugang zu Firmendaten für Dritte wirksam erschwert.
• Authorisierung, d.h. Übermittlungs-Software muss automatische Berechtigungsfunktionen
enthalten. Ein einfacher Passwortschutz ist ungenügend. Nur ein
mehrstufiger Schutzmechanismus bringt eine vernünftige Sicherheit.
• Authentizierung. Für sicherheitssensitive Bereiche muss vom Absender nicht nur
die Zugangsberechtigung nachgewiesen werden. Vielmehr muss er einen
Nachweis seiner Identität erbringen (elektronische Unterschrift), um ihn für diese
Geschäftsvorgänge zu berechtigen.
• Verschlüsselung der Daten. Zusammen mit der Authentizierung ergibt dies das
höchste Mass an Sicherheit für eine Datenübertragung.
Die Sicherheitsanforderung an eine EDI-Umgebung sind in erster Linie abhängig
von den Geschäftsvorgängen, welche über diese Verbindung abgewickelt werden.
Eine Absprache mit den Revisionsstellen der beteiligten Firmen ist unter Umständen
notwendig. Die entsprechenden Vereinbarungen müssen im DIA (Data Interchange
Agreement) festgehalten werden.
8.9 Schulung und Dokumentation
In einem vollautomatischen EDI-Betrieb wird oft die Notwendigkeit der Benutzerund
Operator-Schulung übersehen. Das Wissen um die Zusammenhänge ist aber
eine Voraussetzung für den zuverlässigen Datenaustausch. Mit zunehmender An-
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 8-42

EANCOM-Handbuch
Realisierung
zahl Nachrichten und Partner kann nur ein gutes Grundwissen für die notwendige
Transparenz sorgen.
Da sehr oft mit der Einführung von EDI auch organisatorische Änderungen durchgeführt
werden, können diese nur mit entsprechender Schulung erfolgreich implementiert
werden.
Ein weiterer Schulungsschwerpunkt müssen alle Unregelmässigkeiten des EDI-
Betriebs sein:
• Massnahmen bei Unterbrüchen der Kommunikations-Strecke
• Ansprechpartner für technische Probleme
• Ansprechpartner für applikatorische Probleme, sowohl im eigenen Haus, wie
auch beim Partner
• Meldepflicht von Problemen
• Erledigungskontrolle von Problemmeldungen
Zur Schulung gehört auch die entsprechende Dokumentation, welche dem Benutzer
im produktiven Betrieb als Referenzhandbuch nützlich ist. Ein gut eingerichteter
EDI-Betrieb läuft, wie die Praxis zeigt, äusserst stabil. Unterbrüche und Fehler sind
äusserst selten. Die Qualität der Schulung und der Dokumentation entscheiden
daher über die Reaktionsgeschwindigkeit der Organisation im Störungsfall.
Neben der Beschreibung der eigentlichen Aufgaben des Benutzers und des Operatings
muss die Dokumentation alle Daten enthalten, welche der Benutzer im Störungsfall
einem Helpdesk mitteilen muss. Dazu gehören:
• Nachrichtenverzeichnis mit den aktuellen Versionsangaben
• Netzwerkadressen und PTT-Leitungsidentifikationen
• Telefonverzeichnis nach Funktionen der Ansprechpartner
Die Dokumentation einer EDI-Verbindung ist eine dynamische Einrichtung. Im Erweiterungs-
oder Änderungsfall muss sie konsequent nachgeführt werden. Ebenso
muss der Verteiler der Dokumentation à jour gehalten werden, damit die Nachträge
immer allen Beteiligten zugestellt werden können.
In einigen Kapiteln enthält die Benutzerdokumentation naturgemäss zum DIA (Data
Interchange Agreement) redundante Informationen. Bei Nachträgen ist darauf zu
achten, dass sowohl das DIA, wie auch die Benutzer- und Operator- Dokumentation
nach geführt werden.
8.10 Produktion
Die wichtigste Aufgabe für das Operating (oder den verantwortlichen Benutzer) ist
die regelmässige Kontrolle der EDI-Umgebung, insbesondere in den Installationen,
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 8-43

EANCOM-Handbuch
Realisierung
welche keine automatische Meldungen aus Vollständigkeitskontrolle und Nachrichtenverfolgung
realisieren können. Es darf keine unerledigten Nachrichten im
System geben. Es muss darauf geachtet werden, dass diese Kontrollaufgaben mit
zunehmender Dauer des Betriebs nicht vernachlässigt werden. Solange nur ein
Partner angeschlossen ist, kann man sich eventuell darauf verlassen, dass irgend
jemand schon merkt, wenn etwas nicht läuft. Doch opfert man damit mit Sicherheit
den Zeitvorteil, den man aus einer EDI-Verbindung ziehen kann.
Ins Kontrollpflichtenheft gehören daher Aufgaben wie:
• Prüfen, ob die Verbindung zum Kommunikationspartner (in der Regel das Clearinghouse)
steht
• Prüfen, ob die Verbindung zwischen EDI-Umgebung und Anwendung steht
• Überprüfen aller relevanten Logs auf Fehlermeldungen
• Prüfen, ob alle eingetroffenen Nachrichten der Anwendung zugeführt wurden
• Prüfen, ob alle abgehenden Nachrichten vom Empfänger quittiert wurden
• Bei der Feststellung von doppelten oder fehlenden Nachrichten, sofortige Abklärung
mit den betroffenen internen Stellen und mit dem EDI-Partner
Viele dieser Funktionen können mit einfachen Mitteln und mit auf dem Markt verfügbarer
Software automatisiert werden. Aber auch automatische Funktionen bedürfen
der Überwachung.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 8-44

EANCOM-Handbuch
Die EDIFACT-Servicesegmente
9 Die EDIFACT-Servicesegmente
9.1 Ausgangslage
Die Servicesegmente identifizieren und strukturieren einen EDIFACT-
Datenaustausch (Interchange). Zudem erlauben es die Servicesegmente, Kommunikationssystem
und EDIFACT-Nachrichtensystem miteinander zu verknüpfen.
Im folgenden werden die verschiedenen Wirkungsbereiche der Servicesegmente
mit dem Blick auf zu entwickelnde Empfehlungen (Standards) beschrieben.
9.2 Identifikation Datenaustausch
Zur (technischen) Identifikation eines Datenaustauschs stehen die Servicesegmente
UNB und UNZ zur Verfügung. Einerseits wird durch das UNB/UNZ-Paar der
Datenaustausch begrenzt, andererseits enthält das UNB-Segment die Identifikation
des Datenaustauschs.
Die Identifikationselemente sind:
• Interchange Sender (Absender)
1. Definiert im DIA.
2. Der Absender ist immer einer der Vertragspartner des DIA.
3. Empfehlung: „Adress of reverse routing“ wird nicht verwendet (keine Informationen
über Bedeutung und Anwendung verfügbar).
• Interchange Recipient (Empfänger)
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 9-45

EANCOM-Handbuch
Die EDIFACT-Servicesegmente
1. Definiert im DIA.
2. Der Empfänger ist immer einer der Vertragspartner des DIA.
3. Empfehlung: „Routing address“ wird nicht verwendet (keine Informationen
über Bedeutung und Anwendung verfügbar)
• Interchange Control Reference (Datenaustausch Referenz)
1. Definiert im DIA.
2. Empfehlung: laufende Nummer des Datenaustauschs aus Sicht des Absenders
pro Empfänger (lückenlos, numerisch).
9.3 Identifikation Nachrichten
Zur (technischen) Identifikation einer Nachricht stehen die Servicesegmente UNH
und UNT zur Verfügung. Einerseits wird durch das UNH/UNT-Paar die Nachricht
begrenzt, andererseits enthält das UNH-Segment die Identifikation der Nachricht
innerhalb des Datenaustauschs.
Die Identifikationselemente sind:
• Message Reference Number (Nachrichten Referenz)
1. Definiert im DIA.
2. Empfehlung: laufende Nummer der Nachricht innerhalb des Datenaustauschs
(lückenlos, mit 1 beginnend, numerisch).
Im obigen Sinne nicht identifizierend ist der Message Identifier (Nachrichten Kennung),
der den Typ, die Version und die Herkunft der Nachricht bestimmt und somit
eine syntaxbezogene Aussage macht.
9.4 Identifikation Anwendung (Geschäftsfall)
Zur (applikatorischen) Identifikation der Nachrichten stehen verschiedene Datenelemente
aus den Servicesegmenten UNB, UNG und UNH zur Auswahl. Es sind
dies:
1. UNB: Interchange Sender/Recipient, Application Reference und Communications
Agreement Id
2. UNG: Functional Group Identification und Application Sender/Recipient
3. UNH: Message Identifier und Common Access Reference
Die Verwendung von Functional Groups (Service-Segmente UNG/UNE) ist unklar
und umstritten. Es ist ferner auch fraglich, ob sie überhaupt Bestandteil des
EDIFACT-Standards bleiben oder nicht.
Empfehlung:
Functional Groups werden nicht eingesetzt.
Ein weiteres Problem in diesem Zusammenhang ist auch das Mischen von mehreren
Nachrichtentypen innerhalb eines Datenaustauschs. Obwohl gemäss Syntax
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 9-46

EANCOM-Handbuch
Die EDIFACT-Servicesegmente
zulässig, lassen sich auch hier auf der Anwenderseite kaum befürwortenden Stimmen
ausmachen.
Empfehlung:
Kein Message-Type Mix in einem Datenaustausch; die Application
Reference im UNB definiert die im Datenaustausch enthaltenen
Nachrichtentypen.
Eine weitere Interpretationsschwierigkeit taucht bei der Common Access Reference
des UNH auf. Auch hier mangelt es an Information zu Schlagwörtern wie „subsequent
transfers of data“, „business case of file“.
Empfehlung:
Auf die Anwendung der Common Access Reference im UNH
wird verzichtet (keine Informationen über Bedeutung und Anwendung
verfügbar).
Unter Berücksichtigung der obigen Empfehlungen bleiben für die Anwendungen
von den ursprünglichen Identifikationselementen noch diejenigen des UNB übrig,
die grundsätzlich alle für die Identifikation notwendig sind:
Interchange Sender/Recipient
vgl. Abs. 11.1.2, Identifikation Datenaustaustausch.
Application Reference
Enthält den Nachrichtentyp der Nachrichten des Datenaustauschs.
Format:
:
:
Message Type Identifier, 6 Zeichen
fakultative Ergänzung, max. 8 Zeichen, bilateral
zu vereinbaren
Communications Agreement Id
Enthält die Identifikation des DIA.
Format:
EANCOM
:
:
:
EPIN des 1. Vertragspartners, 13 Zeichen
EPIN des 2. Vertragspartners, 13 Zeichen
Nummer des DIA-Anhangs, der den Inhalt
des Datenaustauschs definiert, 3 Ziffern
9.5 Strukturierung Datenaustausch
Die Struktur des EDIFACT-Datenaustauschs ist durch die UNB/UNZ-, UNG/UNEund
UNH/UNT-Segmentpaare gegeben.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 9-47

EANCOM-Handbuch
Die EDIFACT-Servicesegmente
Offen bleibt die Frage, was zu tun ist, wenn für einen periodisch erwarteten Datenaustausch
(zB. tägliche Bestellungen) keine Nachrichten vorliegen, in einem Datenaustausch
jedoch mindestens 1 Nachricht enthalten sein muss. Zur Erinnerung:
in Anwendungen taucht die „leere Menge“ hartnäckig immer wieder auf und
führt, ebenso immer wieder, zu (vermeidbaren) Fehlern und Fehlinterpretationen
(gibt’s nun tatsächlich keine Daten oder sind die Daten verlorengegangen?).
Empfehlung:
Regelung im DIA
(zB. für die Zustellung ist der Absender verantwortlich, nachher
der Empfänger)
9.6 Strukturierung Nachricht
Die Anwendung des UNS-Segments scheint, vergleicht man die Nachrichten der
verschiedenen MD-Gruppen, eher künstlerischen als logischen Gesetzen zu gehorchen.
Die Anwendung ist jedenfalls nicht einheitlich geregelt. Wir erwarten hier
eine Regelung von den Standardisierungsgremien.
Empfehlungen (Auswahl):
• Die EDIFACT-Syntax so überarbeiten, dass UNS-Segmente überflüssig werden
oder
• Das UNS-Segment markiert immer den Beginn eines Nachrichtenabschnitts
(zB. Kopf-, Detail-, Ende-Abschnitt). Beim ersten Abschnitt einer Nachricht entfällt
das Segment oder
• Das UNS-Segment markiert immer das Ende eines Nachrichtenabschnitts (zB.
Kopf-, Detail-, Ende-Abschnitt). Beim letzten Abschnitt einer Nachricht entfällt
das Segment.
9.7 Kommunikation und EDIFACT
vgl. Standard der EAN (Schweiz): EDIFACT, Meldungsvermittlung und -kontrolle in
diesem Handbuch
9.8 Zeichensätze
Der von EANCOM empfohlene Zeichensatz ist ISO-646 Level A (7-bit, keine Syntax-Zeichen,
nur grosses Alphabet).
Andere Zeichensätze, zB. ISO-646 Level B (7-bit, grosses und kleines Alphabet
plus Syntax-Zeichen (Information Separators 1, 3 und 4), oder ISO 8859 (8-bit),
ebenfalls mit integrierten Syntax-Zeichen) können eingesetzt werden, wenn sie im
DIA von den Vertragspartnern vereinbart werden. Voraussetzung ist hier allerdings,
dass die vereinbarten Zeichensätze auf der ganzen Übertragungsstrecke unterstützt
werden (Clearing Centers).
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 9-48

EANCOM-Handbuch
Die Messages CONTROL und GENRAL
10 Die Messages CONTROL und GENRAL
10.1 Ausgangslage
In der EDIFACT-Praxis treten immer wieder Datenaustausch-Probleme auf, die mit
den verfügbaren Standard-Messages nicht zu lösen sind. Es betrifft dies insbesondere
die Bereiche
• Fehlerbehandlung,
• Datenaustausch-Kontrolle (Accept/Reject),
• Test/Kontrolle der Betriebsbereitschaft beteiligter Partner,
• Austausch von Daten, für die keine Standard-Messages definiert sind,
• etc.
Für die Behandlung dieser Problemkreise stehen die Standard-Messages
CONTROL und GENRAL zur Verfügung.
10.2 Die Control-Message (CONTRL)
Die Control-Message ist im ISO-9735 Standard definiert. Sie bestätigt dem Absender
pro Datenaustausch:
• den Empfang des Datenaustauschs,
• die Annahme oder Abweisung des ganzen Datenaustauschs, einzelner Nachrichten
oder Teilen davon (mit Syntax-Kontrolle).
Die Aktivierung der Control-Message erfolgt
• für die Empfangsbestätigung
• für die Syntax-Kontrolle
über das Service-Segment UNB (Acknowledge
Request)
durch bilaterale Vereinbarung.
EDIFACT-Umgebungen, deren Kommunikation in X.435 eingebettet ist, verwenden
als Empfangsbestätigung auf der Datenaustausch-Ebene standardmässig die EDI-
Notifications (siehe Standard der EAN (Schweiz), Meldungsvermittlung und -
kontrolle), die exakt der Empfangsbestätigung via Control-Message entsprechen.
Empfehlung: EDIFACT-Umgebungen mit X.435 behandeln nur syntaxbezogene
Control-Messages.
Zu beachten ist hier ferner, dass die inhaltliche Kontrolle der Nachrichten aussschliesslich
in der Applikation erfolgt und die Annahme/Abweisung/Korrektur fehlerhafter
Daten auch nur dort abgehandelt werden kann.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 10-49

EANCOM-Handbuch
10.3 Die General-Message (GENRAL)
Die Messages CONTROL und GENRAL
Die General-Message gehört zu den Standard EANCOM-Messages und bildet dort
neben den Kategorien Stammdaten, kommerzielle Transaktionen und Statistik/Planung
eine eigene Kategorie. Die Message soll für folgende Aufgaben eingesetzt
werden:
• frühzeitiger Datenaustauschtest zwischen EDIFACT-Partnern,
• Mitteilungen über bekannte Probleme (Volltext oder codierter Text),
• Austausch von (strukturierten) Daten, für die keine Standard-Message existiert,
• Austausch von (strukturierten) Daten zur Ergänzung/Klarstellung vorgängig
übermittelter Daten.
Die Message ist nicht gedacht als Ersatz von Electronic Mail.
10.4 Anwendung der Messages CONTRL und GENRAL
Die Anwendung der beiden Messages wird im folgenden für Standardsituationen
des „täglichen Datenaustausch-Lebens“ beschrieben. Die aufgeführten Beispiele
sind als Anwendungsempfehlung zu verstehen und sollen in diesem Sinne die
Kontrollverfahren standardisieren.
10.4.1 Anwendung 1: Bereitschaftskontrolle („Are you alive?“)
Die Bereitschaftskontrolle wird hauptsächlich in grösseren, automatisch (ohne
Operating) betriebenen Netzen zum Einsatz kommen, in denen EDIFACT-
Nachrichten Teil zeitkritischer Anwendungen sind. Bei richtigem Timing erhält der
Auslöser der Kontrolle in der Regel genügend Zeit, um Systemunregelmässigkeiten
zu beheben.
Ablauf der Bereitschaftskontrolle:
1. der Auslöser der Kontrolle sendet eine GENRAL-Nachricht (Inhalt und Struktur:
zu definieren) an den Partner. Die GENRAL-Nachricht ist die einzige Nachricht
des Datenaustauschs. Im UNB wird mit dem Acknowledge-Request (Datenelement
0031) eine CONTROL-Nachricht als Antwort auf den Datenaustausch verlangt.
2. der Empfänger sendet eine CONTROL-Nachricht (Inhalt und Struktur: siehe
Handbuch) an den Absender zurück. Die CONTRL-Nachricht ist die einzige
Nachricht des Datenaustauschs. Die GENRAL-Nachricht wird als solche erkannt
und verlässt die EDIFACT-Umgebung normalerweise nicht.
3. der Absender erhält die verlangte CONTRL-Nachricht (oder eben nicht!) und
kann sich somit entsprechend verhalten.
Anmerkung:
eine CONTRL-Nachricht als Antwort auf eine CONTRL-Nachricht
kann nicht verlangt werden (dh. Bereitschaftskontrollen erfolgen
nur mit GENRAL!).
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 10-50

EANCOM-Handbuch
Die Messages CONTROL und GENRAL
10.4.2 Anwendung 2: Annahme/Abweisung eines Datenaustauschs
Bei jedem Datenaustausch von „echten“ Nachrichten kann mit dem Acknowledge-
Request des UNB (Datenelement 0031) eine CONTROL-Nachricht als Bestätigung
verlangt werden. Wenn keine weiteren Abmachungen bestehen, bestätigt die
CONTRL-Nachricht nur die Annahme/Abweisung des empfangenen Datenaustauschs.
Der Ablauf ist wie bei der Bereitschaftskontrolle, mit Ausnahme der „echten“ Nachrichten,
die die EDIFACT-Umgebung natürlich verlassen und in die betreffende
Anwendung gelangen.
10.4.3 Anwendung 3: Syntax-Kontrolle der Nachrichten eines Datenaustauschs
Syntax-Kontrollen werden bilateral vereinbart und werden nicht durch den
Acknowledge-Request des UNB-Segments ausgelöst (aktueller Stand des Irrtums).
Es werden jeweils alle Servicesegmente und Nachrichten des Datenaustauschs
geprüft und dann, je nach Vereinbarung, über die Komponenten des Datenaustauschs
mit einer einzigen CONTRL-Nachricht abschliessend berichtet.
Ablauf der Syntax-Kontrolle:
1. der Absender sendet einen Datenaustausch mit beliebig vielen Nachrichten.
2. der Empfänger prüft die empfangenen Daten und sendet eine CONTROL-
Nachricht (Inhalt und Struktur: siehe Handbuch) an den Absender zurück. Die
CONTRL-Nachricht ist die einzige Nachricht des Datenaustauschs. Die Nachrichten
verlassen die EDIFACT-Umgebung und gelangen in die betreffende Anwendung.
3. der Absender erhält die vereinbarte CONTRL-Nachricht und kann sich somit
über das Ergebnis der Syntax-Kontrolle informieren.
10.4.4 Anwendung 4: Annahme/Abweisung eines Datenaustauschs mit Syntax-
Kontrolle der Nachrichten
Hier handelt es sich um die Kombination der Anwendungen 2 und 3: nebst der bilateral
vereinbarten Syntax-Kontrolle wird auch die Annahme/Abweisungs-
Bestätigung verlangt.
Der Ablauf ist analog den Anwendungen 2 und 3, der Absender erhält jedoch
zwei CONTRL-Nachrichten (eine für den Acknowledge-Request und eine für die
Syntax-Kontrolle) in je einem Datenaustausch.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 10-51

EANCOM-Handbuch
Bestellungen
11 Bestellungen
Die Gestaltung der Enablingapplikation für Bestellungen ist anspruchsvoll. Der zyklische
Ablauf von Bestellnachrichten, Bestellantworten und Bestelländerungen
zwischen einer Einkaufsanwendung auf der Bestellerseite und einer Kundenauftragsbearbeitung
beim Lieferanten muss sorgfältig analysiert und geplant werden.
Hauptproblem ist dabei die benötigte "Antwortzeit" einer Bestellantwort (ORDRSP)
auf eine Bestellung, bzw. die verbleibende Zeit für eine Bestelländerung
(ORDCHG).
An dieser Stelle soll ein Beispiel diese Anforderungen verdeutlichen:
Lieferbereitschaft Folgetag
Der Kunde darf bis 16.00 Uhr Bestellungen für den Folgetag übermitteln.
Ungültige Bestellpositionen werden mit ORDRSP gemeldet. Mit ORDCHG besteht
die Möglichkeit Bestellungen zu korrigieren.
Da beim Lieferanten die Kommissionierung um 16.15 Uhr beginnen muss, werden
zu spät eintreffende Bestellungen automatisch dem nächsten Lieferzyklus zugeordnet.
Bestellpositionen, welche bis 16.00 Uhr nicht korrigiert sind, werden ebenfalls
auf den Folgetag verschoben.
Daraus folgt, dass die Empfangsabläufe auf beiden Seiten in sehr kurzen Abständen
durchgeführt werden müssen (z.B. alle 15 Minuten), um die Nachrichten des
Partners so schnell wie möglich zu verarbeiten. In der Enablingapplikation müssen
weitgehend alle Funktionen der Plausibilisierung und der Rückmeldung vorhanden
sein, damit die Batchverabeitungen der betroffenen Anwendungen nicht in so kurzen
Zeitabständen in der Produktion eingeplant werden müssen. In besonders kritischen
Fällen müssen Wege gefunden werden, wie der Anwender selbst den EDI-
Sendeprozess auslösen kann. Ebenso kann es zwingend sein, empfangene Nachrichten
direkt dem Benutzer weiterzureichen, um ihn sofort auf Problemsituationen
aufmerksam zu machen und ihm zu ermöglichen, noch rechtzeitig Korrekturen anzubringen.
Die folgende Beschreibung der einzelnen Nachrichten im Bestellablauf weist auf
allgemein gültige Regeln und Ausfüllanweisungen hin. Im einzelnen Projekt muss
analysiert werden, in welchem Umfang Ergänzungen notwendig sind um die Anforderungen
aus dem gesamten Bestellablauf sicherzustellen. Diese zusätzlichen
Funktionen müssen im Data Interchange Agreement zwischen den Partner schriftlich
festgehalten werden.
11.1 Bestellung (PURCHASE ORDER)
Dieser Messagetyp bildet in EANCOM die Datengrundlage für den gesamten Geschäftsablauf
mit EDI. Ziel ist, soviel Daten wie möglich für die folgenden Messagetypen
bereits bei der Bestellung mitzuerfassen. Dies vereinfacht im Gesamtablauf
die Plausibilitätsanforderungen und reduziert wesentlich den Rückmeldungs-
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 11-52

EANCOM-Handbuch
Bestellungen
aufwand. Neben den vorgeschriebenen Datenelementen ist es daher auch sinnvoll
bereits die Preisangaben je Einheit (C118) mitzusenden. Der Empfänger vergleicht
diesen Preis mit seinen eigenen Informationen und weist abweichende Preisangaben
zurück (z.B. mit ORDRSP). Wird dieser Preis akzeptiert, müssen im weiteren
Verlauf des Geschäftsvorgangs nur noch die Mengenabweichungen ergänzt werden,
um zu einer fehlerfreien Rechnung (INVOIC) zu kommen.
11.2 Bestellantwort (ORDER RESPONSE)
Der Einsatz der Nachricht "Bestellantwort" ist eine der Voraussetzungen für einen
vollautomatischen EDI-Bestellablauf. Besonders in zeitkritischen Geschäftsabläufen
können nur mit ORDRSP schnell genug Probleme mit den eingegangenen Bestellungen
dem Besteller gemeldet werden. Der Absender kann danach, falls es die
Art des Geschäftes zulässt, mit der Nachricht "Bestelländerung" seinen Auftrag
richtigstellen. ORDRSP-Messages können sowohl durch das Enabling, wie auch
durch die Anwendung (z.B. Kundenauftragsbearbeitung) selbst ausgelöst werden.
Die Erfahrung mit den produktiven EDI-Verbindungen zeigt, dass der Einsatz von
ORDRSP unumgänglich ist.
ORDRSP wird in der Regel nicht als Auftragsbestätigung eingesetzt. Die Bestellantwort
wird als Rückmeldung für fehlerhafte oder aus anderen Gründen nicht
ausführbare Bestellungen oder Bestellpositionen eingesetzt. Dieser Nachrichtentyp
kann aber selbstverständlich nur an EDI-Partner gesandt werden, welche den
Empfang und die Verarbeitung von ORDRSP eingerichtet haben. Der Besteller
zeigt dies in der Nachricht "Bestellung" an:
• BGM 4343 Bestätigungsart codiert. Wird dieser Code nicht übermittelt, ist der
Absender nicht in der Lage ORDRSP zu empfangen.
Die folgende Tabelle zeigt für die verschiedenen Plausibilitätsergebnisse den Einsatz
von ORDRSP. Dabei ist darauf zu achten, dass nicht die gesamte Bestellung
zurückgesandt wird, sondern nur die Bestellpositionen, welche nicht verarbeitet
werden können. Für die eindeutige Identifikation einer Bestellposition genügt das
DE 1082 im LIN. Die Rückmeldungen der Bestellpositionen enthalten daher neben
DE 1082 nur diejenigen Datenelemente, welche durch die Gültigkeitsprüfung beanstandet
wurden oder für die Begründung der Zurückweisung notwendig sind..
Meldungsgrund DE 1225 DE 1229 notwendiger Inhalt ORDRSP
Ungültige Location 27 Nur Kopf- und Fussteil
Lieferdatum für die 27 Nur Kopf- und Fussteil
gesamte Bestellung
nicht möglich
ORDCHG zu spät eingetroffen.
27 Nur Kopf- und Fussteil
Lieferdatum für einzelne
Bestellposition nicht
möglich
4 7 LIN 1082 aus ORDERS, zusätzlich mit
DTM auf Detailebene mögliches Lieferdatum
melden.
Ungültige EAN 4 7 LIN 1082, C 212 aus ORDERS
Bestellmenge nicht
lieferbar
4 7 LIN 1082, aus ORDERS, C 186 = lieferbare
Menge
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 11-53

EANCOM-Handbuch
Einkaufspreis nicht
akzeptiert
Bestellungen
4 7 LIN 1082 aus ORDERS, C 509 = richtiger
Preis
Auf der Empfängerseite müssen die nötigen Vorkehrungen getroffen werden um
die eintreffenden ORDRSP-Messages möglichst schnell dem zuständigen Sachbearbeiter
zur Kenntnis zu bringen. Insbesondere bei Liefererwartungen für den Folgetag
muss der Anwender die Gelegenheit bekommen, mittels ORDCHG die Bestelldaten
noch rechtzeitig zu korrigieren oder die vorgeschlagenen Änderungen zu
akzeptieren.
Wichtig dabei ist der Grundsatz, dass alle richtigen Bestellpositionen durch den
ORDERS-Empfänger verarbeitet werden. Die mit ORDRSP zurückgemeldeten Positionen
werden je nach Vereinbarung aus der Bestellung entfernt und der Besteller
übermittelt die bereinigten Bestellpositionen mit einer neuen Bestellung, oder der
ORDERS-Empfänger räumt dem Absender einen gewissen Zeitraum ein, während
welchem eine Korrektur mittels ORDCHG akzeptiert wird. Nach Ablauf dieser Zeit
muss eine neue Bestellung übermittelt werden.
11.3 Bestelländerung oder Bestellstornierung (ORDER CHANGE)
Die Bestelländerung bezieht sich, wie ORDRSP, auf eine bereits übermittelte Bestellung.
Im BGM 1004 wird immer auf die Bestellung Bezug genommen und nicht
auf ORDRSP.
Zwei Datenelement im Segment BGM sind besonders zu beachten:
• BGM 1225, Nachrichtenfunktion codiert. Hier wird angegeben ob mit dieser
ORDCHG-Message eine Änderung oder eine Stornierung gemeint ist.
• BGM 4343, Bestätigungsart codiert. Damit wird die ORDRSP-Message gesteuert.
Es gelten dieselben Regeln wie bei ORDERS.
Werden einzelne Bestellpositionen geändert, so wird, wie bei ORDRSP, die entsprechende
Positionsnummer LIN 1082 und die geänderten Werte in dieser Zeile
übertragen.
Die Bestelländerung wird in der Regel als Bestätigung oder Ablehnung einer Bestellantwort
eingesetzt. Dabei ist ein Zyklus von mehr als einer Bestellantwort und
einer Bestelländerung denkbar. Sie kann aber auch ohne vorhergegangene Bestellantwort
zur Änderung einer bereits übermittelten Bestellung verwendet werden.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 11-54

EANCOM-Handbuch
Rechnungen
12 Rechnungen
Im Gegensatz zum Bestellablauf ist die Übermittlung von Rechnungen kein zeitkritischer
Prozess. Dennoch sind auch hier einige Besonderheiten zu beachten. Die
Voraussetzung für den Ablauf sind im Kapitel "Betrieb" beschrieben. An dieser
Stelle wird hauptsächlich auf den Inhalt der INVOIC-Message eingegangen. Wie
bei allen EANCOM-Messages sind auch bei dieser Nachricht UNH und BGM vergleichbar
und müssen daher nicht besonders erläutert werden.
An der Baumstruktur der INVOIC-Message ist erkennbar, dass es sich bei diesem
Nachrichtentyp um ein komplexes Gebilde handelt. Im nationalen Geschäftsverkehr
kann dank der Abstützung auf das EAN-System jedoch häufig auf viele Segmente
verzichtet werden. Im Pilotbetrieb wurde auch darauf geachtet, möglichst einfache
Rabattstrukturen anzuwenden, um eine transparente Rechnungsnachricht sicherzustellen.
Gerade in diesem Problembereich der Fakturierung sind sehr genaue
Absprachen zwischen den EDI-Partnern wichtig, damit der Rechnungsempfänger
mit vernünftigen Mitteln seine Plausibilitäts-Prüfungen durchführen kann. Bei besonders
komplexen Rabattstaffelungen kann die Einführung der INVOIC-Message
eine Überarbeitung des Konditionenwesens notwendig machen und für beide Partner
von Nutzen sein. Ein diesbezüglicher Versuch ist in jedem Fall angezeigt.
12.1 EDI und Mehrwertsteuer
12.1.1 Zu diesem Dokument
Die in diesem Dokument vorgeschlagenen Lösungen sind im Grundsatz mit der
Steuerverwaltung besprochen.
Das Dokument ist wie folgt gegliedert:
• Grundlagen
• Grundsätzliche Anforderungen aus Sicht der Steuerverwaltung
• Welche Lösungsvarianten erfüllen die Anforderungen der Steuerverwaltung?
• Aufzeichnung auf Papier oder Mikrofiche
• Nachweis mittels Journal auf Papier oder Mikrofiche
• Nachweis mittels elektronisch gesichert übermitteltem Journal
• Übermittlung der einzelnen Belege mit gesicherter EDI-Übermittlung.
• Anforderungen der Steuerverwaltung an die elektronische Datenübermittlung
• Anforderungen der Steuerverwaltung an die elektronische Buchführung
12.1.2 Grundlagen
• Art. 41ter der Bundesverfassung.
• Art. 8 der Übergangsbestimmungen der Bundesverfassung.
• Verordnung über die Mehrwertsteuer (MWSTV). Gültig ab 1.1.1995. Relevant für
EDI:
• Art. 28: Rechnungsstellung und Überwälzung der Steuer.
• Art. 47: Buchführung. Absatz 1 bestimmt unter anderem, dass sich die für den
Vorsteuerabzug massgebenden Tatsachen leicht und zuverlässig aus der
Buchführung ermitteln lassen.
• Art. 50: Überprüfung der Steuergrundlagen durch die Steuerbehörden.
• Art. 61: Definition der Steuergefährdung.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 12-55

EANCOM-Handbuch
Rechnungen
• Wegleitung für Mehrwertsteuerpflichtige vom Herbst 1994. Relevant für EDI:
• Randziffer 781: Eine Rechnung im umsatzsteuerlichen Sinne setzt das Vorliegen
einer Urkunde voraus. Diesem Anspruch werden EDI-Meldungen nur dann gerecht,
wenn der Rechnungssteller (Lieferer, Anbieter) zuhanden des Leistungsempfängers
(Abnehmer, Nachfrager) einen Nachweis (Abrechnung) in Papierform
oder auf Mikrofiche erstellt. Inhalt des Nachweises gemäss Ziffern 739-744.
• Randziffern 938-941: Aufbewahrung der Geschäftsbücher und Belege.
• Art. 962 / 963 Obligationenrecht (OR): Regelung der Aufbewahrung von Geschäftsbüchern.
Diese Artikel werden zurzeit überarbeitet. Geplante Vernehmlassung
der Vorlage 1995, Inkraftsetzung nicht vor 1.1.97. Ziele der Revision
sind u.a.:
• Weg vom Begriff Original als Papierdokument.
• Weg von der Unterscheidung zwischen Bild- und Datenträgern.
• Gleichstellung von unmittelbar lesbaren und elektronisch dargestellten Informationen.
• Art. 14 OR: Motion von Frau Nationalrätin V. Spoerry für die Anerkennung der
elektronischen Unterschrift.
12.1.3 Grundsätzliche Anforderungen aus Sicht der Steuerverwaltung
• Die Steuerverwaltung muss zuverlässig feststellen können, dass der Beleg, mit
dem der Vorsteuerabzug geltend gemacht wird, dem für die MwSt. relevanten
Beleg des Rechnungsstellers entspricht.
• Dieser Sachverhalt muss von der Steuerverwaltung beim Steuerpflichtigen überprüft
werden können, ohne dass sie dazu auch die Bücher der Geschäftspartner
dieses Steuerpflichtigen prüfen muss.
• Das Nichterfüllen dieser Anforderungen kann beispielsweise folgende Konsequenzen
haben:
• Vorsteuerabzug kann nicht oder nicht vollständig geltend gemacht werden.
• Der Steuerpflichtige wird nach Ermessen besteuert (Art. 48 MWST-Verordnung).
• Der Steuerpflichtige wird gebüsst (Art. 60 ff MWST-Verordnung).
12.1.4 Welche Lösungsvarianten erfüllen die Anforderungen der Steuerverwaltung?
Zurzeit bestehen die folgenden, von der Steuerverwaltung akzeptierten Lösungen
für elektronisch übermittelte MWST-relevante Belege (Rechnungen, Gutschriften):
• Nachweis der übermittelten Belege durch den Lieferer mittels Aufzeichnung auf
Papier oder Mikrofiche.
• Nachweis der Rechnungen / Gutschriften durch den Lieferer mittels Journal auf
Papier oder Mikrofiche.
• Nachweis der Rechnungen / Gutschriften durch den Lieferer mittels elektronisch
gesichert übermitteltem Journal.
• Übermittlung der einzelnen Belege mit gesicherter EDI-Übertragung.
• Diese Lösungen sind nachstehend erläutert.
12.1.5 Aufzeichnung auf Papier oder Mikrofiche
Der Lieferer stellt seinem Abnehmer die elektronisch übermittelten Belege nachträglich
auf Papier oder Mikrofiche zu. Die Aufbewahrung dieser Belege erfolgt
beim Abnehmer zusätzlich zur Aufbewahrung der elektronisch übermittelten Belege.
Diese Lösung ermöglicht im Vergleich zu einer rein papierbasierten Belegübermittlung
die automatische Verarbeitung der elektronisch übermittelten Belege.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 12-56

EANCOM-Handbuch
Rechnungen
Alle übrigen mit EDI angestrebten Einsparungen (z.B. kein Papierhandling, effizientere
Aufbewahrung) fallen mit dieser Variante weg.
12.1.6 Nachweis mittels Journal auf Papier oder Mikrofiche
Der Lieferer sendet dem Abnehmer ein Journal auf Papier oder Mikrofiche, welches
die per EDI übermittelten MWST-relevanten Belege (Rechnungen, Gutschriften)
rekapituliert. Das Journal muss die folgenden Informationen enthalten:
• Vollständige Anschrift von Lieferer und Abnehmer (Wegleitung Ziffern 739, 740).
• Erstellungsdatum des Journals (Synonyme: Sammelrechnung, Abrechnungsprotokoll).
• Abrechnungszeitraum (= Zeitraum der Übermittlung der EDI-Meldung). In Frage
kommen Monat oder Quartal. Rechnet der Abnehmer monatlich ab, hat der Lieferer
das Journal monatlich zu erstellen.
• Je Einzelrechnung bzw. Einzelgutschrift sind die folgenden Angaben aufzuführen:
• Eindeutige Identifikation der Rechnung / Gutschrift durch Nummer und Datum
(dieses erlaubt die Zuweisung zur Mehrwertsteuer-Abrechnungsperiode)
• Umsatzbeträge nach Steuersatz
• Steuerbeträge nach Steuersatz
• Fakturaendbetrag
• Totalsteuerbetrag in CHF (Wegleitung Ziffer 745)
Die Steuerverwaltung geht davon aus, dass der Abnehmer das Journal mit seinen
Aufzeichnungen (Buchführung) abstimmt.
12.1.7 Nachweis mittels elektronisch gesichert übermitteltem Journal
Diese Möglichkeit entspricht im Grundsatz der Lösung unter Punkt 2. Anstatt jedoch
das Journal in Papierform bzw. auf Mikrofiche dem Abnehmer zuzuschicken,
erfolgt die Übermittlung mittels EDI. Obwohl das Papierjournal nicht unterschrieben
werden muss, verlangt die Steuerverwaltung für die elektronische Übermittlung des
Journals eine eindeutige Identifizierung des Absenders. Diese Forderung ist auf
die erhöhten Risiken zurückzuführen, welche mit einer ungesicherten elektronischen
Verarbeitung entstehen. Deshalb ist in diesem Falle die Verwendung von Sicherheitsdiensten
gemäss EDIFACT-Norm notwendig. Das heisst, dass die Übermittlung
der Journale durch einen Message Authentication Code (MAC) oder eine
elektronische Unterschrift gesichert werden muss.
12.1.8 Übermittlung der einzelnen Belege mit gesicherter EDI-Übertragung.
Die vierte Lösung geht weg vom nachträglichen Nachweis übermittelter Rechnungen
/ Gutschriften. Sie dürfte die längerfristig anzustrebende Lösung sein, erlaubt
sie doch am besten die Vorteile von EDI mit den steuerlichen Anforderungen und
denjenigen einer ordnungsgemässen Buchführung zu verbinden.
Sie basiert auf dem Prinzip, dass jeder per EDI übermittelte Beleg eindeutig dem
Absender zugewiesen werden kann. Bedingung für diese Lösung ist die Aufbewahrung
der Nachweisinformationen (z.B. Schlüssel) zusammen mit dem elektronischen
Beleg. Als Nachweisverfahren verlangt die Steuerverwaltung die Anwendung
eines der EDIFACT-Norm entsprechenden Sicherheitsdienstes. Deshalb muss jeder
elektronisch übermittelte Beleg durch einen MAC oder eine elektronische Unterschrift
gesichert und nachgewiesen werden. Auf Verlangen muss der elektronisch
gespeicherte Beleg zusammen mit dem Nachweis sichtbar gemacht werden.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 12-57

EANCOM-Handbuch
Rechnungen
12.1.9 Anforderungen der Steuerverwaltung an die elektronische Datenübermittlung
Die Steuerverwaltung hat Vorschriften erstellt, welche Informationen ein MWSTrelevanter
Beleg enthalten muss. Diese sind bei elektronischer Übermittlung in
gleicher Art und Weise umzusetzen. Damit erlaubt die Steuerverwaltung den Einsatz
von eindeutigen Identifikations-Codes (z.B. EAN-Nummer) für Artikel und für
die Identifikation von Abnehmer oder Lieferer.
12.1.10 Anforderungen der Steuerverwaltung an die elektronische Buchführung
Die elektronische Buchführung wird von der Steuerverwaltung anerkannt. Sie stützt
sich dabei auf die Vorschriften des Obligationenrechts und die dazu im Revisionshandbuch
der Schweiz präzisierten Grundsätze. Insbesondere geht es der Steuerverwaltung
darum, ordnungsgemäss aufgezeichnete Informationen in angemessener
Zeit sichtbar zu machen und effizient nachprüfen zu können.
Die Aufzeichnung von EDI-Meldungen sollte möglichst nahe beim Abgangs- bzw.
Eingangspunkt des Datenflusses erfolgen. Konversionen und Übersetzungen sollten
soweit sinnvoll erst nach der Aufzeichnung erfolgen. Die steuerliche Aufbewahrungsfrist
umfasst 6 Jahre.
Diese Anforderungen können je länger je mehr nur Mithilfe von elektronisch unterstütztem
Zugriff auf die benötigten Daten erfüllt werden. Damit die Steuerverwaltung
sich von den ordnungsgemässen Verfahren und den notwendigen ablauforganisatorischen
Regelungen überzeugen kann, soll ihr der Steuerpflichtige den Einsatz
elektronischer Datenübertragung und optischer Speichermedien anzeigen.
Dabei werden jedoch keine Zertifizierungen von Hardware oder Software vorgenommen.
Die Wahl der Mittel soll dem Steuerpflichtigen offen stehen. Grundsätze
zu Verfahren und Ablauforganisation müssen von der Steuerverwaltung noch erarbeitet
werden.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 12-58

EANCOM-Handbuch
Rechnungsdatenaustausch
Mehrwertsteuer: papierloser
13 Mehrwertsteuer: papierloser Rechnungsdatenaustausch
Datenfluss und Ablage von signierten Dokumenten unter Berücksichtigung der Anforderungen
der Eidgenössischen Steuerverwaltung.
siehe: http://www.ean.ch/EANCOM/mwst.htm#Download
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 13-59

EANCOM-Handbuch
Zahlungsverkehr
14 Zahlungsverkehr
14.1 Grundsatz
Die Arbeitsgruppe "Zahlungsverkehr" der Schweizer Bankiervereinigung hat auf
der Basis der UN/EDIFACT-Messages, die Regeln für den Zahlungsverkehr in der
Schweiz erarbeitet und eine entsprechende Dokumentation veröffentlicht. In verschiedenen
Pilotanwendungen wurden die Vorgaben getestet und für den produktiven
Betrieb freigegeben. Folgende Nachrichten stehen zur Verfügung:
• PAYORD
• PAYEXT
• PAYMUL
• DEBADV
• DEBMUL
• CREADV
• CREEXT
• CREMUL
• BANSTA
• DIRDEB
• FINSTA
Zahlungsauftrag (wird nicht mehr eingesetzt in
D96.A)
erweiterter Zahlungsauftrag (wird nicht mehr eingesetzt
in D96.A)
Mehrfach-Zahlungsauftrag
Belastungs-Anzeige (wird nicht mehr eingesetzt in
D96.A)
Mehrfach-Belastungsanzeige
Gutschriftanzeige (wird nicht mehr eingesetzt in
D96.A)
erweiterte Gutschriftanzeige (wird nicht mehr eingesetzt
in D96.A)
Mehrfach-Gutschriftanzeige
Statusmeldung
Direkt-Belastung
Finanzstatus
Da für EDI bei Banken keine branchenorientierten Subsets notwendig sind, wird
hier direkt UN/EDIFACT als Standard eingesetzt. In Gesprächen mit Bankenvertretern
konnte eine akzeptable Lösung für EANCOM-Anwender gefunden werden.
Diese wird an späterer Stelle beschrieben.
Da EAN sich jedoch als Ziel gesetzt hat, seinen Mitgliedern eine komplette Dokumentation
zur Verfügung zu stellen, werden auch die Finanz-Messages ins
EANCOM-Manual als EANCOM-Messages aufgenommen.
14.2 Vorteile
Die Vorteile des Banken-EDI sind vielfältig. Durch die Verarbeitung von eingehenden
und ausgehenden Aufträgen am selben Tag und die sofortige Benachrichtigung
des Bankkunden mit den entsprechenden Messages werden die sogenannten
passiven Gelder weitgehend eliminiert. Der Anwender ist ständig über die Verfügbarkeit
seines Geldes informiert.
Ein weiterer wesentlicher Vorteil ergibt sich aus der Art und Weise, wie die Bank
das Konto des EDI-Kunden führt. Obwohl mit EDI-Messages gesteuert, ist es bankintern
ein ganz normales Konto. Dies bedeutet, dass auch Überweisungen zu und
von Geschäftspartnern, welche noch nicht EDI betreiben möglich sind. Damit kann
der gesamte Zahlungsverkehr in einem Schritt auf EDI umgestellt werden.
Achtung: Dies funktioniert noch nicht bei jeder Bank. Erkundigen Sie sich vorher.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 14-60

EANCOM-Handbuch
14.3 Anwendungsrichtlinien
Zahlungsverkehr
Massgebend für den Einsatz von EDI mit den Banken sind selbstverständlich deren
Richtlinien. Im EANCOM-CH-Implementation Guide können daher keine detaillierten
Angaben gemacht werden. Solche sind bei Bedarf der entsprechenden Dokumentation
der Banken zu entnehmen. An dieser Stelle soll daher für den EANCOM-
Anwender nur auf die Directory-Problematik, sowie auf bestimmte Segmente und
Datenelemente eingegangen werden.
14.3.1 Directory
Die Banken-Messages bauen auf dem Directory 91.2 resp. D95A auf. Zu dem bei
EANCOM gültigen D93A resp. D96A sind dabei keine grundlegenden Änderungen
zu beachten. Mittlerweile verwenden auch die Banken das Directory D96A.
14.3.2 Dokumentreferenzen
EANCOM bezieht sich im BGM-Segment auf vorausgegange EDI-Messages.
Grundsätzlich gilt das auch beim Banken-EDI. Es ist aber zu beachten, dass dies
immer nur für Referenzen auf Messages gilt, welche mit demselben Partner vorgängig
ausgetauscht wurden. Referenzen auf INVOIC oder REMADV gehören
nicht in das BGM-Segment, da sie nicht mit der Bank, sondern mit dem Geschäftspartner
ausgetauscht wurden. Für Referenzen dieser Art ist das DOC-
Segment vorgesehen.
Siehe auch Abschnitt 11.6.7.
14.3.3 REMADV - Remitance Advice
Die Nachricht REMADV wird nicht mit der Bank, sondern mit dem EDI-
Geschäftspartner ausgetauscht. Sie dient dazu, dem Partner Details über die via
Bank getätigte Zahlung mitzuteilen, z.B. welche Rechnungen mit dieser Zahlung
beglichen werden. Grundsätzlich kann dies auch mit der Nachricht PAYEXT erfolgen.
Welche der beiden Nachrichten eingesetzt wird, hängt in erster Linie von den
heute noch nicht bekannten Bankgebühren für den EDI-Verkehr ab. Für Partner
ohne EDI-Einrichtung ist ohnehin PAYEXT einzusetzen.
Beispiele für REMADV:
PAYEXT
CREEXT
Schuldner Bank Begünstigter
DEBADV
Im PAYEXT können die Zahlungsavis-Informationen untergebracht werden. Der
REMADV kann entfallen.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 14-61

EANCOM-Handbuch
Zahlungsverkehr
PAYMUL
CREEXT
Schuldner Bank Begünstigter
DEBADV
REMADV / FAX
Werden Zahlungsinformationen nicht über die Bank an den Begünstigten vermittelt,
so dient dazu der REMADV.
Diese Lösung ist vor allem in der Übergangszeit (bis alle Begünstigten und beteiligten
Banken EDI-fähig sind) anzuwenden, die dem Schuldner die Vermittlung der
Zahlungsinformation per REMADV erlaubt wenn Banken involviert sind, die nicht
EDI-fähig sind, oder per FAX, wenn der Begünstigte noch nicht EDI-fähig ist.
Schuldner
REMADV
Begünstigter
Diese Verwendung entspricht einem Zahlungsavis.
REMADV
Begünstigter
Schuldner
Diese Verwendung ist eine Rechnungs-Rekap vorausgegangener INVOIC und
kann für die Abrechnung der MwSt. genutzt werden.
14.4 EANCOM im Umfeld der Banken
Da die Bankennachrichten auf UN/EDIFACT Ebene definiert sind, ist ein Subset,
wie es EANCOM darstellt, nicht ohne weiteres integrierbar. Für die volle Anwendung
des EAN-Systems müssten die Banken in letzter Konsequenz alle Konten mit
EAN-Nummern versehen. Dass dies nicht so einfach realisierbar ist, kann leicht
eingesehen werden. Zum einen verfügen die Schweizer Banken bereits über ein
eigenes Nummernsystem (SIC), zum anderen ist auch der S.W.I.F.T.-Standard für
internationale Verbindungen im Einsatz. Obwohl bereits einige Banken Mitglieder
von EAN Schweiz geworden sind, ist aus den erwähnten Gründen nicht mit einer
kurzfristigen Lösung zu rechnen.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 14-62

EANCOM-Handbuch
Zahlungsverkehr
Trotzdem gibt es bereits heute Möglichkeiten mit den Banken EDI-Nachrichten
auszutauschen und die Vorteile von EANCOM und des EAN-System weitgehend zu
nutzen.
Message-Fluss im Finanzbereich
ORDERS / ORDCHG / REMADV
Handel
Produktion
ORDRSP / DESADV / NVOIC
P
A
Y
E
X
T
/
P
A
Y
D
E
B
A
D
V
/
D
E
B
C
R
E
A
D
V
/
C
R
E
C
R
E
M
U
L
M
U
L
M
U
L
E
X
T
FINPAY
Bank 1
Bank 2
14.4.1 Location Numbers
1. Die EAN-Nummern im UNB-Segment identifizieren den technischen Empfänger
und Absender weltweit eindeutig.
2. Die NAD-Segmente werden verwendet, um die EAN-Nummern des Zahlenden
und des Zahlungsempfängers zu definieren.
14.4.2 Bankkonto
Die EDI-Regeln der Banken verlangen die vollständige Beschreibung des Kontos
des Auftraggebers und des Begünstigten im FII-Segment. Zu dieser Beschreibung
gehören:
• Kontonummer
• Clearingnummer der Bankfiliale
• Clearingstelle
• Name, PLZ, Ort des Kontoinhabers
Im Bereich EANCOM werden diese Informationen für die INVOIC-Message ebenfalls
benötigt. Dort wird in einem NAD-Segment das Konto und die Bankverbindung
angegeben, auf welches der Rechnungsbetrag einzuzahlen ist.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 14-63

EANCOM-Handbuch
14.5 Kommunikation
Zahlungsverkehr
Zur Zeit ist EDI nur mit den Grossbanken möglich. Projekte sind in der Realisierung
begriffen, welche EDI über Clearingstellen wie z.B. Telekurs oder Servicerechenzentren
von Regionalbanken ermöglichen.
In allen Fällen ist bei der Einrichtung von EDI-Verbindungen darauf zu achten,
dass die Bank über die bestehenden Clearingservices zu erreichen ist.
14.6 Sicherheit
Zahlungsaufträge werden von den Banken nur mit gültiger Unterschrift des Kontoinhabers
durchgeführt. Dasselbe gilt natürlich auch für die PAYORD-Nachricht. Da
die UN/EDIFACT-Normen für die elektronische Unterschrift noch nicht verfügbar
sind, haben die Schweizer Banken sich für eine Übergangslösung entschieden.
Diese Übergangslösung soll hier nicht näher beschrieben werden, da sie mittelfristig
abgelöst wird.
Als mittelfristige Lösung wird selbstverständlich die asymmetrische, digitale Unterschrift
vorgesehen (siehe auch Mehrwertsteuer).
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 14-64

EANCOM-Handbuch
Zahlungsverkehr
14.7 Financial Messages
Referencing Documents in Financial Messages
Created by Payee
INVOICE
BGM
1004 12345
DOC
Created by Payor
PAYORD
BGM
1004 AB CDE
DOC
1001 481
1004 LMNOP
DOC
1001 380
1004 12345
REMADV
BGM
1004 LMNOP
DOC
1001 380
1004 12345
Created by Payor’s Bank
DEBADV
BGM
1004 GHIKL
1153 ABO
1154 ABCDE
CREADV
BGM
1004 GHIKL
1153 AEK
1154 ABCDE
DOC
1001 481
1004 LMNOP
DOC
1001 481
1004 LMNOP
FINPAY
BGM
1004 GHIKL
RFF
1053 AEK
1054 ABCDE
DOC
1001 481
1004 LMNOP
Created by Payee’s Bank
CREADV
BGM
1004 OPQRS
1153 ACK
1154 GHIKL
DOC
1001 481
1004 LMNOP
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 14-65

EANCOM-Handbuch
EDI und Transport
15 EDI und Transport
15.1 Zu diesem Dokument
Dieses Dokument dient als Ergänzung und weiterführende Erläuterung wie Nachrichten
im Transportbereich anzuwenden sind.
Es sollte im Zusammenhang mit folgenden Dokumenten gelesen werden:
EANCOM Manual
ORDERS
IFTMIN
IFTMAN
DESADV
RECADV
HANMOV
IFTMBC
IFTSTA
Bestellung
Transportauftrag
Ankunftsmeldung
Versandmeldung / Lieferschein
Wareneingangsmeldung
Güterumschlag
Buchungsbestätigung
Statusbericht
15.1.1 D.96A
15.2 Geschäftsfälle
In folgendem Schema werden die Messages aufgezeigt, welche zwischen Auftraggeber
(Käufer oder Lieferant) und Auftragnehmer (Spediteur oder Transporteur)
ausgetauscht werden.
IFTCCA - Transport Kalkulation
IFTMIN - Transportauftrag
Auftraggeber
Käufer / Lieferant
IFTMCS - Auftragbestätigung
IFTSTQ - Anforderung Statusbericht
IFTSTA - Statusbericht
Auftragnehmer
Spediteur / Transporteur
IFTMAN - Ankunftmeldung
IFTFCC - Transportrechnung
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 15-66

EANCOM-Handbuch
EDI und Transport
Das nachfolgende Schema zeigt unterschiedliche Nachrichtentypen mit ähnlicher
Funktionalität wie sie im Handel und Transport zur Anwendung kommen.
REQOTE
QUOTES
IFTCCA
Handel
Transport
INVOIC
IFTFCC
Die Referenzierung über verschiedene Nachrichten hinweg, die sich auf einen
Transport beziehen, sollte mit folgenden Angaben in den entsprechenden Nachrichten
gemäss folgendem Schema gemacht werden.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 15-67

EANCOM-Handbuch
EDI und Transport
15.3 UN/EDIFACT Referenzen für den Transport
Buyer-A
IFTCCA
Calculation Number
ORDERS
Order-number
Contract-number
IFTMIN
Booking-number
Order-number
Contract-number
Seller-B
IFTCCA
Calculation Number
IFTMIN
Booking-number
(SSCC)
Order-number
Contract-number
Kalkulationsnr.
DESADV
Despatch-number
Contract-number
Order-number
Booking-number
SSCC
INVOIC
Invoice-number
Contract-number
Order-number
Despatch-number
SSCC
Booking-number
Forwarder-C
IFTCCA
Calculation Number
IFTFCC/INVOIC
Invoice-number
Contract-number
Order-number
Booking-number
SSCC
IFTMAN
Arrival-number
Booking-number
SSCC
Order-number
Contract-number
Buyer-A
Legende: Fluss der Dokument-Referenzen Primäre Referenzen: Kursiv gedruckte Referenzen sind immer im BGM
Messagefluss zwischen den Partnern Sekundäre Referenzen: normal gedruckte Referenzen sind immer im RFF
Primäre Referenzen (im BGM DE1004) werden immer vom Dokument-Ersteller vergeben
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 15-68

EANCOM-Handbuch
EDI und Transport
15.4 Begriffe / Definitionen
ACCEPTANCE OF GOODS WARENEMPFANG The process of receiving a
consignment from a consignor,
usually against the
issue of a receipt. AS and
from this moment the
carrier becomes responsible
for the consignment.
ADVICE NOTE ANKUNFTAVIS A document sent to a
customer advising of impending
delivery
AGENT AGENT A person or organisation
authorised to act for or on
behalf of another person or
organisation
AIR WAYBILL (AWB) LUFTFRACHTBRIEF A Document made out by
or on behalf of the carrier(s)
confirming receipt of
the goods by the carrier
and evidencing the contract
between the shipper
and the carrier(s) for the
carriage of goods by aircraft
as described therein.
ARRIVAL DATE ANKUNFTDATUM The date goods are due to
arrive at the receiving site.
ARRIVAL NOTICE ANKUNFTSMELDUNG A notice sent by a carrier
to a nominated party advising
of the arrival of a
certain shipment.
ARTICLES DANGEREUX
DE ROUTE (ADR)
GEFAHRENGUT (STRASSE)
A European agreement
concerning the international
carriage of dangerous
goods by road
AVAILABLE CAPACITY FREIE KAPAZITÄT The capacity of a particular
resource (e.g. a means
of transport, warehouse)
which for a particular period
of time is free for use
(the total capacity already
reserved).
BACK HAUL RÜCKFÖRDERUNG The return movement of a
means of transport which
has provided a transport
service in one direction.
BILL OF LADING
CONOSEMENT
BONDED WAREHOUSE FREILAGER A warehouse in which
goods not yet cleared by
the customs are stored
until duties are paid or
these goods are otherwise
properly released.
BOOKING (IN
TRANSPORT)
BUCHUNG
The offering by a shipper
of cargo for transport and
the acceptance of the
offering by the carrier or
his agent (reservation in
aircargo)
BOOKING CONFIRMATION BUCHUNGSBESTÄTIGUNG Document issued by a
carrier to confirm that
space has been reserved
for a consignment in means
of transport
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 15-69

EANCOM-Handbuch
EDI und Transport
BORDEREAU BORDERAU Document issued in road
transport, listing the cargo
carried on a road vehicle,
often referring to appended
copies of the road consignment
note.
BOX PALLET
BOX PALLET
BULK CARGO
SCHUETTGUT
BUYER
KÄUFER
CALL-OFF ORDER ABRUF
CAPTIVE PALLET
IN-HOUSE PALLET
CARGO
WARE
CARRIER
FRACHTFUEHRER
CARRIER/FORWARDER UNTERNEHMER/SPEDITEUR the party contracted by the
consignor to transport
goods.
COMMERCIAL INVOICE HANDELS-RECHNUNG
CONSIGNEE EMPFÄNGER the organisation (party)
which has the intention to
receive the goods.
CONSIGNMENT SENDUNG is a one or many points of
loading to one or many
delivery locations for a
buyer and seller.
CONSIGNMENT
SENDUNGS INSTRUKTIONEN
INSTRUCTIONS
CONSIGNMETN NOTE BORDERAU
(WAYBILL)
CONSIGNOR AUFTRAGGEBER the party ordering transport,
orders a carrier to
collect goods for transportation.
CONTAINERISED
CONTAINERISIERT
CUSTOMS CLEARANCE ZOLLAGENT
AGENT
CUSTOMS DOCUMENT ZOLLDOKUMENT
CUSTOMS DUTIES ZOLLGEBÜHREN
CUSTOMS INVOICE ZOLLRECHNUNG
CUSTOMS VALUE
ZOLLWERT
DANGEROUS GOODS GEFAHRGÜTER
DANGEROUS GOODS GEFAHRGUTDEKLARATION
DECLARATION
DELIVERY DATE
AUSLIEFERDATUM
DELIVERY INSTRUCTION LIEFERINSTRUKTIONEN
DELIVERY LOCATION AUSLIEFERORT the physical location to
which goods for transport
are delivered.
DESPATCH LOCATION VERSANDORT the physical location from
which goods for transport
are shipped.
DIRECT DELIVERY DIREKTE LIEFERUNG
DISPOSABLE PALLET EINWEGPALETTE
DISTRIBUTION CENTER VERTEILZENTRALE
DISTRIBUTOR
VERTEILER
EMBARGO
EMBARGO
EQUIPMENT: AUSRÜSTUNG material resources necessary
to facilitate the transport
and handling of cargo.
Transport equipment does
under the given circumstances
not have the ability
to move by its own
propulsion (e.g. sea container,
trailer, unit load
device, pallet).
EXPORT LICENCE AUSFUHRLIZENZ
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 15-70

EANCOM-Handbuch
EDI und Transport
FORWARDER
SPEDITEUR
FORWARDING
SPEDITION
FREIGHT COSTS
FRACHTKOSTEN
GOODS ITEM
GOODS RECEIPT
WARENEMPFANG
GROUPAGE
SAMMELLADUNG
HARMONIZED SYSTEM HS
(HS)
IMPORT LICENCE
EINFUHRGENEHMIGUNG
LINE ITEM
ARTIKELZEILE
LOAD
LADUNG
MANIFEST
MANIFEST
MEANS OF TRANSPORT: TRANSPORTMITTEL the vehicle used for the
transport of goods or persons,
e.g. aircraft, truck,
vessel.
MODE OF TRANSPORT: TRANSPORTART the method of transport
used for the conveyance of
goods or persons, e.g. by
rail, by road, by sea.
ON-CARRIAGE
WEITERTRANSPORT
PACKAGE
VERPACKUNG
PACKAGE TYPE
VERPACKUNGSART
PACKAGING
VERPACKEN
PALLET
PALLETE
PLACE OF ACCEPTANCE ORT DER AKZEPTANZ
PLACE OF DELIVERY AUSLIEFERORT
PLACE OF DEPARTURE VERSANDORT
PROOF OF DELIVERY LIEFERNACHWEIS
SEAL
PLOMBE
SHIPMENT
SENDUNG
TERMS OF DELIVERY AUSLIEFERBEDINGUNGEN
TRANSHIPMENT
UMLADUNG
TYPE OF EQUIPMENT: TRANSPOTBEHÄLTNISSE the type of material used,
e.g. 40 feet container, four
way pallet, mafi trailer.
TYPE OF MEANS OF
TRANSPORT:
ART DES
TRANSPORTMITTELS
the type of vehicle used in
the transport process, e.g.
wide body, tank truck,
passenger vessel.
WAREHOUSE
LAGERHAUS
WAREHOUSING
LAGEREI
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 15-71

EANCOM-Handbuch
EDI und Transport
15.4.1 Prinzipien / Regeln
• Für den Transportauftrag braucht es keine Kalkulation.
• Der Auftraggeber kann bestimmen. wann ein Status (IFTSTA) mitgeteilt werden
soll.
• Kalkulationen werden pro Gewicht und/oder Volumen wie auch Lademeter (Kleider
etc.) gemacht.
• Eine Rechnung bezieht sich immer auf einen Transportauftrag.
• Eine Rechnung kann richtig oder falsch sein und wird immer beim Aussteller und
nicht beim Empfangenden storniert.
• Die Transport/Handels - Rechnung löst eine Zahlung aus.
• Die Transportnummer im Transportauftrag (eindeutig) entspricht der Bestellnummer
in einer Bestellung. Bei einer Statusanfrage wie auch Ankunftmeldung
wird auf die Transportnummer verwiesen. (Bsp.: Airline = AWB Airwaybill number).
• Es sollte immer eine Rechnung pro Transportauftrag erstellt werden, d.h. von
Sammelabrechnungen ist abzusehen.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 15-72

EANCOM-Handbuch
Betrieb
16 Betrieb
16.1 Ablaufdesign
Ein wichtiges Element für eine erfolgreiche Realisierung einer EDI-Verbindung ist
die sorgfältige Planung des Ablaufs auf Seiten beider EDI-Partner. Mit Ablauf sind
alle Schritte gemeint, welche die vollautomatische Übertragung von UN/EDIFACT-
Nachrichten zwischen zwei Partnern, d.h. ihren Anwendungen ermöglichen. Dazu
gehören nicht nur die eigentlichen Übertragungsfunktionen, sondern auch alle
Elemente des Enablings, wie
• Plausibilisierung,
• Umsetzungsroutinen für die EAN-Numerierung,
• Verfolgung der EDI-Nachrichten,
• Verteilung der Daten an die richtigen Applikationen,
• applikatorische Rückmeldungsfunktionen (z.B. ORDRSP),
• Trennung von Test- und Produktionsabläufen.
Besonders zu beachten gilt, dass in einer normal funktionierenden Verbindung,
sowohl das EDV-Personal, wie auch die betroffenen Benutzer nur im Fehlerfall mit
den Problemen des Ablaufs konfrontiert werden. Daher wird, bei einer guten Verfügbarkeit
des EDI-Ablaufs, die aktive Überwachung durch diese Stellen verständlicherweise
sehr bald nachlassen. Unvollständige oder vergessene Übermittlungen
werden erst durch Reklamationen des Partners erkannt. Dasselbe gilt für fehlende
Empfangsbestätigungen. Deshalb sind im Ablauf entsprechende Überwachungsfunktionen
zu integrieren, welche eine automatische Benachrichtung der Benutzer
oder der EDV für weitgehend alle Störungsfälle sicherstellen.
Ausserdem sind im Rahmen des Ablaufdesigns alle notwendigen Massnahmen für
Wiederholungen und für den Wiederanlauf zu treffen. Dabei muss beachtet werden,
dass die Durchführung solcher Schritte in jedem Fall, der vorhergehenden
Absprache mit dem betroffenen EDI-Partner bedarf. Auch hier sind daher entsprechende
Überwachungsfunktionen in den Ablauf einzubinden.
16.1.1 Plausibilisierung
An dieser Stelle stehen keine Hinweise auf die Gültigkeitsprüfungen, welche durch
die Anwendungen verlangt werden. Mit Plausibilisierung sind hier alle Funktionen
und Prüfungen gemeint, welche den automatischen Datenaustausch ermöglichen.
Dabei bleibt es dem Anwender überlassen, ob die notwendigen Schritte softwaremässig
realisiert werden, oder ob gewisse Funktionen durch organisatorische
Massnahmen sichergestellt werden. In jedem Fall sind die folgenden Themen in jeder
EDI-Verbindung genau zu analysieren und entsprechende Massnahmen zu
treffen.
16.1.2 Verfolgung von EDI-Nachrichten
Es ist selbstverständlich zwingend, sowohl für den Sender, wie für den Empfänger
einer EDI-Verbindung, sämtliche Nachrichtenübertragungen in einem Log festzuhalten.
Dieses gibt dem Informatiker alle Möglichkeiten der Rückverfolgung des
EDI-Verkehrs. Es besteht jederzeit Auskunftsbereitschaft über alle durchgeführten
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 16-73

EANCOM-Handbuch
Betrieb
Übermittlungen. Der elektronische Datenaustausch hat aber weitergehende Informationsbedürfnisse.
In der Verbindung zwischen zwei Anwendungen besteht auch
ein Kontrollbedarf über den zeitlichen Verlauf der Übertragungen, d.h. über ausstehende
Ereignisse.
Am Beispiel der Fakturierung lässt sich dieser Themenkreis sehr anschaulich darstellen:
Nach dem Fakturierungslauf überträgt der Sender die INVOIC-Nachrichten an seinen
Partner. Nach Ablauf des Zahlungsziels ist diese Rechnung noch offen. Der
Debitorenbuchhalter möchte nun sicher wissen, ob die INVOIC beim Schuldner
eingetroffen ist, bevor er ihn mit einer Mahnung an den Ausstand erinnert. Da in
der Regel zu diesem Zeitpunkt mehr als 30 Tage seit der Rechnungsstellung verstrichen
sind, muss ein entsprechend grosses Log durchsucht werden. Einerseits
um zu prüfen, ob die Übermittlung überhaupt erfolgt ist, andererseits um prüfen ob
die Empfangsbestätigung des Partners eingetroffen ist. Eine automatische Warnung
an den Endbenutzer nach z.B. 24 Stunden, dass zu dieser Rechnung noch
keine Empfangsbestätigung eingetroffen ist, würde diesen zeitraubenden Prozess
vermeiden.
Ähnliche zeitabhängige Vorgänge finden sich auch im Bestellwesen. Einige Beispiele
sollen dies belegen
• bei Frischprodukten, wo der Bestellablauf besonders zeitkritisch ist - heute bestellt,
morgen geliefert.
• bei Direktlieferungen in Filialen, wo die bestellende Zentrale erst nach erfolgter
Lieferung eine Rückmeldung erhält
• bei Bestellungen auf einen bestimmten Zeitpunkt (Aktionen).
In all diesen Fällen ist es von entscheidender Bedeutung für den Besteller, dass er
noch rechtzeitig reagieren kann, falls in der Übertragung seiner Bestellung irgendwelche
Störungen aufgetreten sind.
Diese Anforderungen werden oft als zu aufwendig empfunden. Es muss daher mit
allem Nachdruck darauf hingewiesen werden, dass EDI nicht nur Bestellung
und/oder Rechnungen umfasst. Spätestens beim Einsatz des elektronischen Datenaustausches
für den Geldverkehr (Zahlungen, Belastungsanzeigen, Gutschriftanzeigen)
kann auf Kontrollfunktionen in diesem Umfang nicht mehr verzichtet
werden. Es ist daher sinnvoll, von Anfang in den Abläufen diesen Anforderungen
gerecht zu werden.
Dem Absender von EDI-Nachrichten wird daher empfohlen, je Verbindung und
Nachrichtentyp eine Zeitlimite zu definieren, nach welcher der absendende Anwender
über das Ausbleiben der Empfangsbestätigung informiert wird. Dies kann
mittels Software realisiert werden, oder durch einen EDI-Verantwortlichen z.B. auf
Grund des täglichen Logs erarbeitet werden.
16.1.3 Vollständigkeitskontrollen
Eine wichtige Voraussetzung für einen automatischen EDI-Betrieb ist eine einwandfreie
Vollständigkeitskontrolle der übermittelten Nachrichten. Diese erlaubt
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 16-74

EANCOM-Handbuch
Betrieb
nicht nur die Sicherstellung der vollständigen Übermittlung aller Nachrichten, sie
ermöglicht auch die Verhinderung von doppelten Übertragungen, sowie das Aufdecken
fehlender Nachrichten.
Ausserdem bilden alle diese Massnahmen die Grundlage für die kontrollierte Wiederholung
von Übermittlungen im Störungsfall.
Je nach gewähltem Übermittlungsprotokoll werden einzelne Funktionen durch die
entsprechende Software abgedeckt. Die folgende Beschreibung der zu treffenden
Vorkehrungen nimmt darauf keine Rücksicht. Es ist im einzelnen Fall zu prüfen,
welche Funktionen zusätzlich zu realisieren sind.
1. Eindeutige Identifikation einer Übermittlung (Data Interchange)
Segment UNB, Datenelement 0020.
EANCOM-CH empfiehlt die Übermittlung je technischem Partner (Zielrechner)
fortlaufend zu numerieren. Dieser Übermittlungsstempel erlaubt beiden Partnern
eine eindeutige Identifikation der Übertragungsdatei, z.B. im Falle einer notwendigen
Wiederholung.
2. Eindeutige Identifikation der Nachrichtentypen (EDI-Funktion)
Segment UNH, Datenelement 0062.
EANCOM-CH empfiehlt die fortlaufende Numerierung je Partner und Message-
Typ. In diesem Fall ist der Partner nicht der Zielrechner, sondern der Zielanwender.
Mit dieser Identifikation wird zwischen den EDI-Umgebungen der beiden
Partner sichergestellt, dass keine doppelten Übertragungen stattfinden. Andererseits
bedeutet eine Lücke in der Numerierung, dass im Übertragungsweg zwischen
den beiden EDI-Umgebungen in irgendeiner Komponente eine Störung
stattgefunden hat.
3. Eindeutige Identifikation der Nachricht (Message)
Segment BGM Datenelement 1004.
Die Dokumentnummer wird durch die sendende Applikation vergeben und unterliegt
daher auch deren Regeln. Beispiele sind: Bestellnummer, Rechnungsnummer,
usw. Sie hat daher rein applikatorischen Charakter. Trotzdem muss diese
Nummer auch für EDI-Zwecke genutzt werden.
Die in den Punkten 1. und 2. beschriebenen Identifikationen bieten noch nicht die
gewünschte Sicherheit zur Verhinderung doppelter Übermittlungen, da sie in der
EDI-Umgebung entstehen. Eine Wiederholung durch die Anwendung führt daher
zu neuen Identifikationen und somit ist die empfangende EDI-Umgebung nicht
mehr in der Lage doppelte Übermittlungen zu erkennen. Daher muss am Schluss
des Übertragungsweges, d.h. in der Applikation, die Dokumentnummer ebenfalls
auf doppelte geprüft werden.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 16-75

EANCOM-Handbuch
Betrieb
Sowohl Absender, wie Empfänger führen deshalb die entsprechende Zähler für die
drei Vollständigkeits-Prüfungs-Ebenen. Der Empfänger prüft auf allen Ebenen, ob
die übertragenen Identifikationen mit seiner "Buchhaltung" übereinstimmt. Bei Abweichungen
sind entsprechende Massnahmen einzuleiten.
16.1.4 Rückmeldungsfunktionen
Unter diesem Begriff sind alle Formen von Reaktionen auf eine Nachrichtenübermittlung
zu verstehen. Je nach Implementations-Niveau werden zu diesem Zweck
Übermittlungs-Protokoll-Funktionen, EDI-Nachrichten, oder konventionelle Mittel
(Telefon, Fax, usw.) eingesetzt. Alle Reaktionen bedürfen der gegenseitigen Absprache
zwischen den EDI-Partnern. Dabei sind nicht nur die Anlässe für die Reaktionen
abzusprechen, sondern auch genauestens die zuständigen Auslöser und
Empfänger.
Empfangsbestätigung (Responsability Acknowledgement)
Diese Rückmeldung wird durch die Übermittlungssoftware automatisch generiert.
Sie bestätigt dem Absender von EDI-Nachrichten, dass die Daten in die Verantwortung
des Empfängers übergangen sind. Die Empfangsbestätigung muss durch
den Absender der Logeintragung des entsprechenden Sendevorgangs zugeordnet
werden. Nur damit ist eine Übermittlung von Nachrichten korrekt abgeschlossen.
Ausstehende Empfangsbestätigungen sind, wie unter "Verfolgung von EDI-
Nachrichten" beschrieben, zu behandeln.
Die Praxis zeigt, dass diese Rückmeldung nicht überall korrekt genutzt wird. Es ist
jedoch offensichtlich, dass ohne eine saubere Verarbeitung der Empfangsbestätigung,
kein zuverlässiger EDI-Betrieb möglich ist. Insbesondere ist die Revisionsfähigkeit
des elektronischen Datenaustausches ohne diese Funktion nicht gegeben.
Applikatorische Fehlermeldungen.
Auf Grund der Plausibilitätsprüfungen festgestellte Datenfehler müssen dem Absender
der Nachrichten zur Kenntnis gebracht werden. Das eleganteste Verfahren
zu Rückmeldung von solchen Fehlern ist der Einsatz von EDI-Nachrichten. Dies
bedeutet allerdings, dass beide Partner entsprechende Funktionen in ihren Anwendungen
realisieren müssen. In zeitkritischen Geschäftsbeziehungen ist diese
Form der Fehlermeldung ein absolutes Muss. In anderen Fällen ist auch die Benachrichtigung
des Partners mit anderen Mitteln denkbar. In jedem Fall muss beachtet
werden, dass die Verantwortung für den korrekten Inhalt einer EDI-Nachricht
beim Absender liegt, d.h. der Empfänger darf ohne Absprache mit seinem EDI-
Partner keine Korrekturen an den Daten vornehmen.
In der Praxis hat sich gezeigt, dass die meisten Fehler durch unterlassene oder
fehlerhafte Meldungen von Artikel- oder Adressmutationen an den EDI-Partner
verursacht werden. Es ist daher besonders wichtig, dem Mutationsverfahren genügend
Beachtung zu schenken.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 16-76

EANCOM-Handbuch
16.2 Absprachen mit dem EDI-Partner
Betrieb
Die Basis für den elektronischen Datenaustausch zwischen Geschäftspartnern ist
das DIA (Data Interchange Agreement). Einen Mustervertrag finden Sie im Anhang
dieses Handbuches. Diese Vereinbarung sollte ausschliesslich den Austausch von
Dokumenten und Daten umfassen. Falsch wäre im DIA den normalen Geschäftsablauf
zu beschreiben und zu regeln, d.h. Einhaltung von Lieferbedingungen, Jahresabschlüsse,
aushandeln von besonderen Konditionen, etc.. Eine EDI-
Verbindung ist eine andere Form der Übermittlung von Dokumenten und Daten,
aber nicht eine andere Geschäftsbeziehung. Das DIA soll deshalb nur Themen behandeln,
welche sich aus dem elektronischen Datenaustausch ergeben.
In der Mustervereinbarung im Anhang sind Regeln enthalten, welche mindestens
im DIA festgeschrieben werden sollten. Im Folgenden sind weitere Themenkreise
beschrieben, die im Einzelfall analysiert und gegebenenfalls im DIA vereinbart
werden müssen.
16.2.1 EAIN - EAN
Wie bekannt, werden im elektronischen Datenaustausch nach "EANCOM-CH" für
Adressen und Artikelinformationen nur die EAN-Nummern übermittelt. Da der Partner,
für die Umsetzung in die hauseigene Form, über die entsprechenden Klartext-
Information verfügen muss, sollte das Meldeverfahren für Neueröffnungen und Änderungen
genau geregelt werden.
• Welche Stellen sind berechtigt, solche Änderungen durchzuführen?
• In welcher Form werden diese Daten übermittelt?
• An wen sind diese Mutationen zu adressieren?
16.2.2 Behandlung von Fehlern in der Übermittlung
Ein vollautomatischer, gut funktionierender EDI-Betrieb verleitet alle Beteiligten
(Operators, Endbenutzer) die Kontrollaufgaben zu vernachlässigen. Um so wichtiger
ist die Absprache über die Fehlerbehandlung bei Übermittlungsfehlern. Bei besonders
zeitkritischen Geschäften, kann unter Umständen eine softwaremässige
Überwachung und Behandlung von Übermittlungsfehlern für beide Partner zwingend
werden. Solche Prozeduren bedürfen der genauen Absprache. Besonders zu
beachten sind die Richt-linien für die Vollständigkeitskontrolle, wie sie an anderer
Stelle beschrieben wurde.
16.2.3 Behandlung von Fehlern in den Dokumenten
Grundsätzlich ist der Absender von EDI-Nachrichten verantwortlich für den korrekten
Inhalt. Der Empfänger prüft die übermittelten Daten nach seinen Bedürfnissen.
Für jeden Fehlerfall muss abgesprochen werden, in welcher Form Fehler gemeldet
werden. Dabei können sowohl die traditionellen Kommunikationsformen (Brief, Telefon
und Fax), als auch EDI-Nachrichten zum Einsatz kommen. Welche dieser
Methoden zur Benachrichtigung des EDI-Partners im Fehlerfall zum Einsatz
kommt, hängt in erster Linie von der geforderten Reaktionszeit ab. Darf der Kunde
beispielsweise bis am Abend bestellen und muss seine Ware am nächsten Vor-
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 16-77

EANCOM-Handbuch
Betrieb
mittag bei ihm eintreffen, kann nur noch die automatische Fehlermeldung mit EDI-
Nachrichten den Geschäftsvorgang sicherstellen. EDI bietet hier ein grosses Rationalisierungspotential,
welches leider oft übersehen wird.
16.2.4 Verantwortung für den Empfang von Nachrichten
Im Data Interchange Agreement (DIA) muss die Pflicht zum Empfang der EDI-
Nachrichten geregelt werden. Dies gilt insbesondere für Mailbox-Systeme, bei welchen
der Adressat seine Nachrichten abholen muss (store + collect). Es empfiehlt
sich, genau zu regeln, wie oft der Empfänger seinen "Briefkasten" leeren muss.
Für alle Systeme muss die Periodizität der Verarbeitung der Daten festgehalten
werden.
16.2.5 Wartung, Versionen, Releases
Diese Thematik verdient besondere Aufmerksamkeit, denn hier wird besonders
deutlich, dass mit EDI Anwendungen über Firmengrenzen hinaus miteinander verbunden
sind. Keine der beiden beteiligten Informatik-Organisationen kann und darf
ohne Abstimmung irgendwelche Funktionen, Daten, Codes, Abläufe ändern, ohne
dass dies mit dem Partner inhaltlich und terminlich exakt abgesprochen ist.
Hat eine Firma mehrere EDI-Partner und muss sie wegen einer Verbindung etwas
ändern, müssen alle anderen Partner ebenfalls in diesen Prozess mit einbezogen
werden. An anderer Stelle wurde bereits empfohlen, die Enablingfunktionen nach
Partner zu trennen. Nur mit einer sauberen Abgrenzung zwischen den einzelnen
EDI-Verbindungen können Änderungen aller Art schrittweise, Partner für Partner,
eingeführt werden. Dies ist mit zunehmender Verbreitung von EDI eine absolute
Voraussetzung, um Wartungsarbeiten mit einem noch vertretbaren Aufwand
durchführen zu können.
16.2.6 Was geschieht mit Testübermittlungen
Eine Trennung zwischen Produktion und Test auf der Übertragungsstrecke ist nur
möglich, wenn Absender und Empfänger über zwei getrennte Sende- und Empfangseinrichtungen
verfügen. Dies ist für grosse Organisationen eine Selbstverständlichkeit,
für die kleineren Firmen jedoch sind die Kosten einer zweiten Verbindung
für Testzwecke unvertretbar.
Aus diesem Grunde besteht im Segment UNB die Möglichkeit, Testüber-tragungen
als solche zu kennzeichnen. Es ist jedoch wenig sinnvoll, als Testdaten gekennzeichnete
EDI-Nachrichten auf der Empfangsseite zu übergehen. Insbesondere,
wenn schrittweise die EDI-Nachrichten eingeführt werden.
Beispiel: Die Bestellungen sind erfolgreich produktiv in Betrieb und nun sollen Bestellantworten
für die Rückmeldungen eingeführt werden. Der Besteller muss nun
Testbestellungen übermitteln, welche die entsprechenden Daten enthalten um
beim Empfänger die Bestellantworten auszulösen. Dies ist nur möglich, wenn die
Anwendungen auf beiden Seiten in irgendeiner Form in der Lage sind, Testdaten
welche über die produktive Verbindung übermittelt werden, ohne Beeinträchtigung
der produktiven Abläufe zu verarbeiten.
Zwischen den EDI-Partnern muss daher nach gründlicher Analyse das Testverfahren
genau abgesprochen und dokumentiert werden. Diese Dokumentation sollte
Teil des DIA sein.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 16-78

EANCOM-Handbuch
16.3 Absprachen mit dem Clearinghouse
Betrieb
In die Vereinbarungen mit dem Clearinghouse sind die Empfehlungen aus Kap. 9
einzubinden. Betriebszeiten und Servicefenster, Verfügbarkeits-garantien, Dokumentation,
Help-Desk, Supportorganisation sind ein paar Stichworte für besonders
zu regelnde Themen.
Ein ständig nachgeführtes Verzeichnis aller benötigten Ressourcen, Komponenten
und Verantwortlichkeiten ist vertraglich zu vereinbaren. Das Verzeichnis muss auf
beiden Seiten vorliegen. Es ist Grundlage für das effiziente Lösen von Problemfällen
aller Art.
In die Verzeichnisse gehören:
• Namen und Adressen, Telefonnummern, Faxnummern der beteiligten Stellen
(Help-Desk, Query-Desk, Nachtdienst, SE, usw.)
• PTT-Unterlagen mit den Leitungsnamen und allen Parametern (X.25!)
• Sende- und Empfangspasswörter unter entsprechendem Verschluss
• Betriebszeiten, Pikettdienst
• Liste der Informationen, welche im Störungsfall bereitgehalten werden müssen,
und eine Beschreibung, wie diese Informationen zum Clearinghouse gelangen.
• Liste der relevanten Dokumentation, falls nötig mit Standorten.
• bei Internetworking-Verbindungen eine Vorgehensbeschreibung für den Störungsfall.
• Vorgehen bei Restore von Daten, welche im Clearinghouse gespeichert sind.
• Art und Dauer der Speicherung im Clearinghouse, sowie Verfahren über die
Meldung über bevorstehende Löschung von Daten.
• Ablauf von allen Arten von Maintenance im Zusammenhang mit EDI-Betrieb
Diese Auflistung kann nicht vollständig sein und insbesondere keine Sonderfälle
enthalten. In der Phase des Ablaufdesigns ist zu analysieren, welche der aufgeführten
Dokumente und Listen für diese Verbindung relevant sind und wo weitere
Ergänzungen notwendig sind.
16.4 Benutzerrichtlinien
Vollautomatisches EDI verlangt vom Benutzer bestimmte Kontrollaufgaben, sofern
diese nicht durch entsprechende Software übernommen werden. Dazu gehören
insbesondere die Vollständigkeitskontrolle und die Nachrichtenverfolgung. Diese
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 16-79

EANCOM-Handbuch
Betrieb
Aufgaben muss der Benutzer aktiv betreiben. Es ist daher genau vorzugeben, welche
Checkpoints in welchen Zeitabständen durchzuführen sind.
In einer zuverlässig laufenden EDI-Verbindung wird der Benutzer sicher zur Hauptsache
mit den Dateninhalten beschäftigt sein. Die Übertragung von Geschäftsdokumenten
mit EDI stellt neue Anforderungen. Daher muss geregelt werden, wie oft
eine EDI-Sendung durchgeführt werden muss, bzw. wie oft ein EDI-Empfang verarbeitet
wird.
Ein wesentlicher Punkt ist die Information des EDI-Partners im Fehlerfall. Der Benutzer
muss angewiesen werden, welche Stellen in der eigenen Firma beim Auftreten
von Fehlern zu informieren sind und wie die entsprechenden Informationen
zum Absender der Dokumente gelangen. Es muss beschrieben sein, welche Korrekturmassnahmen
er selbst durchführen kann. Das Data Interchange Agreement
(DIA) sollte dem Benutzer ebenfalls zugänglich gemacht werden.
Aus applikatorischer Sicht ist zu prüfen, welche Transaktionen der Benutzer, wegen
der Umstellung auf EDI nicht mehr durchführen darf. Als Beispiel können
Stammdatenmutationen angeführt werden. Diese müssen im Falle des elektronischen
Datenaustausches mit den Geschäftspartnern synchron durchgeführt werden.
Die neuen Abläufe sind für den Benutzer zu dokumentieren.
Eine weitere Funktion, welche es zu organisieren gilt, ist die vorübergehende oder
endgültige Sperrung einer Geschäftsbeziehung. Gerade im Handelsumfeld kommen
solche verhandlungspolitischen Massnahmen öfter vor. Da ein solches Ereignis
ausserhalb der EDI-Umgebung ausgelöst wird, müssen entsprechende Prozeduren
vorliegen, welche den EDI-Verkehr für diesen Partner blockieren. Dasselbe
gilt selbstverständlich auch für die Wiederaufnahme der Geschäftsbeziehung.
16.5 Operating-Richtlinien
Auf dem Markt sind bereits einige Softwareangebote zu finden, welche eine weitgehende
Automatisierung der EDI-Abläufe erlauben. Sie sind in der Regel gut dokumentiert
und für das Operating transparent gestaltet.
Auch hier sind daher in erster Linie die Kontrollfunktionen - soweit nicht durch solche
Programme abgedeckt - vorzuschreiben.
Besondere Bedeutung kommt den Bedienungsanleitungen und den Ablaufbeschreibungen
der einzelnen Komponenten zu. Im Störungsfall muss der Operator
in der Lage sein, zu analysieren, in welchem Teil des Ablauf ein Unterbruch erfolgte.
Er muss sich die nötigen Informationen aus den Logs der verschiedenen
Komponenten beschaffen können. Liegt eine Störung im Kommunikationsteil vor,
muss er wissen, welche Informationen der Help-Desk benötigt, um das Problem
beseitigen zu können.
Ein wichtiges Thema ist der Start und Wiederanlauf der EDI-Umgebung. Nicht alle
dazu notwendigen Schritte können automatisiert werden. Es braucht daher genaue
Vorgaben, welche Schritte notwendig sind, um zum geordneten Betrieb in nützlicher
Frist zurückzukehren.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 16-80

EANCOM-Handbuch
Betrieb
Nicht alle Störungen können durch das Operating behoben werden. Daher muss
eine Anweisung vorliegen, wer die Ansprechpartner für die verschiedenen Komponenten
der EDI-Umgebung sind. Neben den firmeninternen Stellen, welche in der
Regel bekannt sind, sind es die PTT, das Clearinghouse und das Rechenzentrum
oder die Informatik des EDI-Partners.
16.6 Wiederholungen
Jede Form von Wiederholung von EDI-Übermittlungen birgt die Gefahr des Versandes
von doppelten Dokumenten in sich. Es ist daher besondere Vorsicht bei der
Vorbereitung von Wiederholungsprozeduren walten zu lassen. Wiederholungen
von Übermittlungen sind auf folgenden Ebenen möglich:
• Wiederholungen zwischen den Kommunikationsprogrammen beider Partner.
Diese EDI-Komponenten sind in der Lage, fehlerhafte Übermittlungen selbst
festzustellen und automatisch zu wiederholen. Die bereits empfangenen Daten
werden durch das Empfängerprogramm gelöscht und das Absenderprogramm
wird veranlasst, die gesamte Übertragung zu wiederholen. Nur in den Fällen, wo
die Übermittlungsprogramme nicht selbständig wiederholen können, sollte dies
manuell ausgelöst werden können.
• Wiederholungen zwischen Sender und Clearinghouse. Wie im ersten Fall sind
auch hier zwei Übermittlungsprogramme aktiv. Derselbe Wiederholungsmechanismus,
wie oben beschrieben ist möglich. Eine andere Form von Wiederholung
kann aus heutiger Sicht nie vorkommen.
• Wiederholung zwischen Clearinghouse und Empfänger. Neben der bereits beschriebenen
Wiederholung zwischen Übermittlungsprogrammen, ist hier ein
weiterer Fall denkbar. Der Absender hat seine Daten für eine Wiederholung
nicht mehr verfügbar. Das Clearinghouse übermittelt aus seinem Archiv die gewünschte
Datei noch einmal. Der Empfänger muss dafür sorgen, dass die
Übermittlungs- und Nachrichtenstempel korrekt nachgeführt werden, damit die
Nachrichtenverfolgung und die Vollständigkeitskontrolle revisionsfähig bleiben.
• Wiederholung zwischen den Anwendungen von Sender und Empfänger. Hier
muss auf der Empfängerseite die Prüfung auf doppelte Dokumente bewusst umgangen
werden, um eine solche applikatorische Wiederholung zu ermöglichen.
Es ist mit Sicherheit die risikovollste Form der Wiederholung und Bedarf daher
sorgfältiger Analyse und Absprache durch beide EDI-Partner.
Tritt die Notwendigkeit einer Wiederholung auf, sind die folgenden minimalen
Schritte durchzuführen:
• Mit dem EDI-Partner muss abgesprochen werden, auf welcher vorher beschriebenen
Ebene die Wiederholung durchgeführt werden soll. Dies ist wichtig, damit
die notwendigen Stempelinformationen auf beiden Seiten synchron bleiben.
• Nach erfolgter Wiederholung ist auf beiden Seiten eine Kontrolle durchzuführen.
Es muss ein Vergleich des Standes der Daten durchgeführt werden und die
Kontrollfiles (Stempel), falls notwendig synchronisiert werden.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 16-81

EANCOM-Handbuch
Betrieb
• Der gesamte Vorgang muss dokumentiert werden, um die Revisionstauglichkeit
sicherzustellen.
Weitere Massnahmen sind abhängig von der Funktionalität von EDI-Umgebung
und Anwendung auf beiden Seiten. Sie müssen im Einzelfall analysiert und realisiert
werden.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 16-82

EANCOM-Handbuch
EDIFACT Meldungsvermittlung und -kontrolle
17 EDIFACT Meldungsvermittlung und -kontrolle
Standard der EAN (Schweiz), Version 2
Dieses Arbeitspapier entstand in der Task-Force Kommunikation der EAN
(Schweiz) und ist zum heutigen Zeitpunkt (Dezember 1995) noch nicht umgesetzt.
Erste Tests werden ab Mitte 1997 durchgeführt.
17.1 Ausgangslage
Bedingt durch den Stand der Technik wurden als Transportplattformen für das
EDIFACT Messaging in den meisten Fällen OFTP, X.400 IPM (Interpersonal Mail)
oder SNA-Protokolle gewählt. Sie zeichnen sich durch folgende Eigenschaften aus:
17.1.1 OFTP
OFTP (ODETTE File Transfer Protocol) stammt aus der europäischen Automobilindustrie,
welche gemeinsam ODETTE (Organisation for Data Exchange by Tele-
Transmission in Europe) gründete. OFTP definiert eine feste Anzahl von Befehlen
und deren Anwendungsvorschriften.
OFTP unterstützt X.25 sowie X.28. Bei X.25 wird die Datenintegrität durch HDLC
garantiert. Für X.28 sind spezielle 'Error Detection and Recovery'-Prozeduren implementiert
(Special Logic Extensions, SLE).
OFTP bietet die Möglichkeit einer Empfangsbestätigung (End-to-End Response
Protocol, EERP) vom Endempfänger zum Absender.
17.1.2 X.400 IPM
Die Methode des Transports von EDIFACT Interchanges als IPM (Inter Personal
Message) ist im Standard ‘P2/Tedis’ definiert.
• In der Envelope werden nur die gemäss X.400 obligatorischen Attribute verwendet,
im wesentlichen Originator (O/R Name), Recipient Descriptor (O/R Name
und Report Request), MTS-Identifier und Content Type. Der Content Type ist 2
(IA5 Text, IPM 1984).
• Die Attribute des IPM Headings werden generell nicht verwendet.
• Der IPM Body besteht aus einem einzigen Body Part, der den EDIFACT Interchange
enthält.
17.1.3 SNA
SNA (System Network Architecture) ist eine Zusammenfassung von Hardware-
Systemen und der zur Datenübertragung notwendigen Kommunikationssoftware.
SNA wird gemäss einer Definition von IBM als 'ein Netzwerk zum Transfer von
Daten zwischen Endanwendern' beschrieben. Dabei stellt SNA die notwendigen
Protokolle für den Betrieb der Komponenten in unterschiedlichsten Netzwerkkonfigurationen
zur Verfügung.
Innerhalb des IBM VANs, das auf SNA basiert, gibt es den 'Information Exchange
Service' ('IE'), der wiederum für die Uebermittlung und Verteilung von EDIFACT-
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-83

EANCOM-Handbuch
EDIFACT Meldungsvermittlung und -kontrolle
Messages sorgt. Bei der Uebermittlung von EDIFACT-Messages wird das File an
ein 'Command File' angehängt. Das 'Command File' enthält die Adressinformationen,
die von IE aus den Service-Segmenten (u.a. UNB) genommen werden.
17.2 Schwächen von OFTP, P2/Tedis und SNA
Die Verwendung von OFTP, P2/Tedis und SNA-Protokollen als Transportplattform
von EDIFACT-Nachrichten sind Uebergangslösungen, die in einer homogenen
Welt nicht schlecht funktionieren. Die latenten Nachteile werden aber in heterogenen
Welten besonders akut.
17.2.1 Schwächen von OFTP
• nur positive Quittungen (EERP), keine Nachrichten im Negativfall oder bei Weiterleitung
von Meldungen an Dritte.
• nur eine Quittungsstufe, die wahlweise für Transport, Konversion oder Uebergabe
an die Applikation eingesetzt werden kann.
• Unsicherheit über das Schicksal von Meldungen beim Ausbleiben von Quittungen.
17.2.2 Schwächen von P2/Tedis
• Die Attribute des X.400 IPM Headings können für EDI nicht verwendet werden,
weil sie für eine andere Anwendung ausgelegt sind und ihre Semantik für EDI
nicht definiert ist. Das hat zur Folge, dass der EDIFACT Interchange in der
X.400-Message eine 'Black Box' darstellt.
• Wichtige Attribute einer EDI-Nachricht wie Message Type, Version, Interchange
Sender, Test Indicator etc. sind erst nach der Konversion der EDI Syntax ins Inhouse-Format
bekannt. Sie können damit nicht zur Steuerung der Konversion
verwendet werden.
• Weil die IPM Notifikation nicht verwendet wird, kann der Sender nicht erkennen,
ob seine Nachricht vom Empfänger verstanden und verarbeitet worden ist. Zwar
kann ein Delivery Report verlangt werden; als Element des Transportdiensts
sagt er aber wesentlich weniger aus über das Schicksal der Nachricht als eine
Notifikation.
17.2.3 Schwächen von SNA
Im IE gibt es zwei Typen von Benachrichtigungen:
• IE Delivery Acknowledgement:
Diese Bestätigung wird ausgelöst,
sobald der Empfänger eine Message aus der Mailbox abholt (gilt nur innerhalb
des IE!)
• VAN Acknowledgement:
Sie ist die Umsetzung der EERP-Quittung,
wie sie innerhalb eines OFTP-Netzwerks erzeugt wird (zwischen OFTP und IE)
Daraus ergeben sich die gleichen Schwächen, die wir bereits bei OFTP festgestellt
haben.
17.2.4 Schwächen bei Gateway-Funktionen von Clearing-Centers
Teilweise fehlende Standards und teilweise fehlende technische Möglichkeiten für
ein Mapping der unterschiedlichen Kontrollmechanismen sind dafür verantwortlich,
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-84

EANCOM-Handbuch
EDIFACT Meldungsvermittlung und -kontrolle
dass der Absender in heterogenen Welten oft keine Kontrolle darüber hat, ob seine
Meldung beim Endempfänger angekommen ist oder nicht.
17.3 Vorteile von X.435
In der Empfehlung X.435 wird - als weitere Messaging-Applikation neben Interpersonal
Mail - ein EDI Messaging Service mit den zugehörigen Dienstelementen und
Syntaxregeln definiert, der zugeschnitten ist auf die Bedürfnisse von EDI und die
Nachteile von OFTP, P2/Tedis und SNA eliminiert. Seine wichtigsten Merkmale
sind:
• Die Felder des Interchange Headers (Segmente UNA und UNB in EDIFACT)
werden im EDI Message Heading repliziert und sind damit bereits vor der Konversion
bekannt.
• Die Semantik der EDI Notifikation ist präzis definiert. Mit X.435 wird der Begriff
der 'Responsibility' eingeführt; sie wird vom Empfänger mittels Notifikation akzeptiert
bzw. abgelehnt.
• Im Gegensatz zu Interpersonal Mail kennt X.435 das Konzept des 'Message
Forwarding'. Damit kann eine Nachricht samt der 'Responsibility' an einen Dritten
weitergegeben werden. Dabei wird eine neue Form der Notifikation, die
'Forwarding Notification', definiert.
• Im Bereich Sicherheit stehen in X.435 eine Reihe von Dienstelementen zur
Verfügung, die noch weiter gehen als die Basisfunktionen von X.400. Dabei geht
es um die Beweisbarkeit der Lieferung bzw. des Empfangs von EDI Messages
und Notifikationen.
17.4 Meldungskontrolle
Zur Ueberwachung von EDIFACT-Meldungen, die mit X.435 übermittelt werden,
stehen drei Kontrollmechanismen zur Verfügung: der Delivery/Non-Delivery Report
auf Transportebene, die EDI Notifikation (PN, NN, FN) von X.435 sowie die Control-Message
auf EDIFACT-Ebene. Die drei Mechanismen stehen in einer hierarchischen
Beziehung und werden wie folgt verwendet:
Delivery Report: NEG: falls vom Transportsystem nicht zustellbar oder falls
vom Ziel-UA abgelehnt aufgrund der Attribute der
X.400 Envelope.
POS: falls zeitgerecht zustellbar und vom Ziel-UA akzeptiert.
EDI Notifikation: NEG: falls der Ziel-UA die Verantwortung für die Meldung
aufgrund der Attribute des EDIM Headings ablehnt.
POS: falls der Ziel-UA die Verantwortung für die Meldung
akzeptiert.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-85

EANCOM-Handbuch
EDIFACT CONTRL:
EDIFACT Meldungsvermittlung und -kontrolle
EDIFACT-Meldung mit dem Ergebnis der Syntaxprüfung
zu einem Datenaustausch (Interchange)
und der darin enthaltenen Meldungen (Messages).
Die applikatorische Antwortmeldung, die in der Hierarchie noch über der EDIFACT
Syntax-Prüfung und der zugehörigen Kontroll-Message liegt, wird in diesem Kontext
nicht in Betracht gezogen, da ihre Semantik applikationsspezifisch ist und nicht
ins Schema von positiven oder negativen Quittierungen passt.
Hinweis:
Die EDIFACT CONTRL-Meldung mit der Bedeutung ‘Interchange Acknowledge’,
verlangt via UNB Ack-Request, wird in der X.435-Welt nicht eingesetzt. An ihre
Stelle treten die EDI Notifikationen des X.435-Standards.
17.4.1 Verwendung von EDI-Notifikationen
Die Verwendung der EDI-Notifikationen wird im X.435-Standard für folgende Fälle
explizit beschrieben:
1. Direktkommunikation zwischen X.435-Absender und X.435-Empfänger (ohne
Forwarding)
2. Kommunikation zwischen X.435-Absender und X.435-Empfänger via ein Drittsystem,
mit oder ohne Forwarding Notifications
3. Kommunikation zwischen Absender und Empfänger über eine PDAU (Physical
Delivery Access Unit), wo der Empfänger nicht X.435-fähig ist und eine Erfolgsmeldung
der physischen Auslieferung an die PDAU zurück technisch nicht möglich
ist.
Die Anwendung der Version 3 und der entsprechenden Regeln wird von EAN nicht
empfohlen.
17.4.2 Verwendung von EDI-Notifikationen bei Gateway-Systemen
Die Verwendung von EDI-Notifikationen durch Gateway-Systeme von EDI Service-
Anbietern (VANS-Anbieter, Clearing-Centers) wird im X.435-Standard nur soweit
beschrieben, als Absender, Gateway und Empfänger X.435-fähig sind. Im Fall, wo
sich der Absender oder Empfänger ausserhalb von X.435 befindet, existiert bis
heute kein Standard und keine klare Regelung, wann und wo welche EDI-
Notifikationen erzeugt werden. Dadurch können für den Absender technische und
semantische Unklarheiten über den Status abgeschickter Meldungen entstehen.
In zeitkritischen EDI-Anwendungen (z.B. Bestellungen) ist eine präzise, möglichst
frühzeitige Signalisierung von Erfolg bzw. Misserfolg einer Uebermittlung lebenswichtig.
Zwischen Absender, Gateway und Empfänger müssen deshalb klare Vereinbarungen
bestehen, welche Notifikationen verwendet werden. Dabei muss natürlich
mitberücksichtigt werden, welche Mechanismen der Erfolgskontrolle beim
File-Transfer zwischen Absender, Gateway und Empfänger zur Verfügung stehen
und in die End-zu-End Kontrolle eingebunden werden können.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-86

EANCOM-Handbuch
EDIFACT Meldungsvermittlung und -kontrolle
Da von allen offiziellen und De Fakto-Standards X.435 das bestausgebaute Kontrollprotokoll
aufweist, wird vorausgesetzt, dass Clearing-Centers untereinander via
X.435 kommunizieren. Gegenüber den angeschlossenen Teilnehmersystemen
können sie ebenfalls über X.435 oder mit anderen Protokollen (P2/Tedis, OFTP,
SNA, FTAM etc.) arbeiten.
17.4.3 Grundregeln für das Internetworking
a) Der Absender erhält immer alle Notifikationen, die er verlangt hat. Falls der Absender
ein X.435 UA ist, kann er PN, NN und FN verlangen. In allen andern
Fällen kann er die Notifikationen verlangen, die ihm das jeweilige Transferprotokoll
anbietet.
b) Der Absender erhält nur die Notifikationen, die er verlangt hat. Es ist nicht zulässig,
nicht verlangte Notifikationen zu erzeugen. Damit kann jeder Teilnehmer
für sich entscheiden, was er implementieren will und was nicht.
c) Absender und Empfänger kennen nur das eigene Transferprotokoll und die eigenen
Kontrollmechanismen. Für das korrekte Mapping von unterschiedlichen
Transfer- und Kontrollmechanismen sind die Gateway-Systeme (Clearing-
Centers) verantwortlich.
d) Alle von EAN (Schweiz) zertifizierten Clearing-Centers sind dafür verantwortlich,
dass die ausserhalb von X.435 verwendeten Meldungskontrollmechanismen korrekt
auf die in X.435 definierten Notifikationen abgebildet werden und umgekehrt.
Die Mapping-Mechanismen müssen dokumentiert und offengelegt werden,
damit über die Qualität der Notifikationen keine Unsicherheit besteht.
e) Falls ein Empfänger bzw. sein Clearing-Center keine vollständigen Notifikationen
erzeugen kann, müssen diese funktionalen Einschränkungen vom Clearing-
Center publiziert und im Interchange Agreement zwischen Absender und Empfänger
der Meldung festgehalten werden.
17.5 Regeln für die EDI-Meldungskontrolle
Im folgenden werden anhand von Konfigurationsbeispielen die Regeln beschrieben,
die bezüglich Transportquittungen und EDI-Notifikationen in homogenen und
heterogenen X.435-Umgebungen gelten sollen.
Gruppe A: homogene X.435 Umgebungen
1. Direktkommunikation via X.435 (ohne Beteiligung eines Clearing-Centers)
2. Homogene X.435-Umgebung mit Clearing-Center
In diesen beiden Fällen wird die Verwendung von Notifikationen vollständig durch
die Standards X.400/X.435/F.435 geregelt.
Gruppe B: heterogene Umgebungen
1. Heterogene Umgebung mit einem Clearing-Center zwischen den Endsystemen
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-87

EANCOM-Handbuch
EDIFACT Meldungsvermittlung und -kontrolle
2. Heterogene Umgebung mit zwei (oder mehr) Clearing-Centers zwischen den
Endsystemen. Der Absender ist X.435-fähig, der Empfänger nicht
3. Heterogene Umgebung mit zwei (oder mehr) Clearing-Centers zwischen den
Endsystemen. Der Absender ist nicht X.435-fähig, der Empfänger ist es
In diesen Fällen entsprechen die Regeln den Anforderungen der EAN (Schweiz) an
zertifizierte Clearing-Centers.
4. Heterogene Umgebung mit CONTRL-Message
Bei den in den Fallbeispielen aufgeführten Control-Messages handelt es sich ausschliesslich
um die EDIFACT CONTRL-Meldung des Typs ‘Interchange Acknowledge’,
die via UNB Ack-Request verlangt werden kann. Falls P-EDIN / N-EDIN auf
diese CONTRL Message gemappt werden, muss das Datenelement 0083 im Segment
UCI die folgenden Werte enthalten:
Wert 8:
Wert 4:
Interchange receivedentspricht dem P-EDIN des X.435 Standards
Interchange rejected entspricht dem N-EDIN des X.435 Standards
Generelle Anmerkungen zu den Fallbeispielen:
In den nachstehenden Fallbeispielen wird generell vorausgesetzt, dass der X.435
Absender alle Reports (Delivery und Non-Delivery Reports) und alle Notifikationen
(PN, NN und FN) verlangt.
Bei den heterogenen Umgebungen wird mit 'FT' unspezifisch ein File Transfer-
Mechanismus bezeichnet und mit 'Ack' und 'Error' unspezifische positive bzw. negative
Quittierungen.
17.5.1
17.5.2 Direktkommunikation über X.435 (ohne Clearing-Center)
17.5.2.1 Ok-Fall
EDIM-Absender
EDI
UA
MTA
EDIMS
EDIM-Empfänger
MTA
ED I
UA
1
EDIM
2
Deliv
3 P-EDIN
Absender und Empfänger sind beide im X.435 EDI Messaging Environment integriert
und kommunizieren direkt miteinander. Dabei bezieht sich der Ausdruck 'direkt'
auf die Ebene von X.435 und bedeutet nicht, dass Absender und Empfänger
physisch miteinander verbunden sind. Es können weitere X.400-Knoten dazwischengeschaltet
sein, wobei sich deren Funktion aber auf den Meldungstransport,
d.h. das Routing der Messages und Notifikationen beschränkt (Ebene MTS/P1).
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-88

EANCOM-Handbuch
EDIFACT Meldungsvermittlung und -kontrolle
1. Die EDI-Meldung wird vom EDI-UA des Absenders abgeschickt und zum Empfänger
transportiert.
2. Die Auslieferung der Meldung an den EDI-UA des Empfängers wird dem Absender
in Form eines Delivery Reports bestätigt.
3. Der EDI-UA des Empfangssystems prüft den EDIM Header, akzeptiert die Meldung
und schickt eine positive EDI-Notifikation (PN) an den Absender.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-89

EANCOM-Handbuch
EDIFACT Meldungsvermittlung und -kontrolle
17.5.2.2 Fehlerfall 1: Non-Delivery Report
E D IM S
ED IM -A bsender
ED IM -E m pfänger
EDI
UA
MTA
MTA
E DI
UA
1
EDIM
2
Non-Deliv
Die Meldung wird bereits auf Transportebene negativ quittiert. Der Fehlerursprung
kann im Transportdienst liegen (Adresse unbekannt, Zeitüberschreitung etc) oder
beim UA des Empfängers (ungültiger Inhalt, Meldung zu gross etc).
1. Die EDI-Meldung wird vom EDI-UA des Absenders abgeschickt und zum Empfänger
transportiert.
2. Eine Auslieferung der Meldung an den EDI-UA des Empfängers findet nicht statt;
dem Absender wird das in Form eines Non-Delivery Reports signalisiert. Die Attribute
'Reason' und 'Diagnostic' geben die Fehlerursache an.
Eine Liste aller möglichen Reason und Diagnostic Codes für den NDR befindet
sich in Anhang A.1 bzw. A.2.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-90

EANCOM-Handbuch
EDIFACT Meldungsvermittlung und -kontrolle
17.5.2.3 Fehlerfall 2: Negative Notifikation
EDIMS
ED IM -A bsender
EDIM -Empfänger
EDI
UA
MT A
M TA
ED I
U A
1
2
3
EDIM
Deliv
N-EDIN
Die Meldung wird beim Empfänger ausgeliefert und nach Prüfung der X.400-
Envelope akzeptiert. Auf EDI-Ebene (EDIM Heading) wird aber ein Fehler festgestellt
(z.B. wegen fehlenden oder falschen UNB-Informationen in den Attributen des
EDIM Headings) und die Meldung wird mittels negativer Notifikation zurückgewiesen.
1. Die EDI-Meldung wird vom EDI-UA des Absenders abgeschickt und zum Empfänger
transportiert.
2. Die Auslieferung der Meldung an den EDI-UA des Empfängers wird dem Absender
in Form eines Delivery Reports bestätigt.
3. Bei der Prüfung des EDI Message Headings wird ein Fehler festgestellt. Der
Empfänger verweigert die Annahme der Meldung und übernimmt die Verantwortung
nicht. Dies wird dem Absender signalisiert mittels einer negativen Notifikation
(NN). Die Attribute 'Reason' und 'Diagnostic' der NN geben die Fehlerursache
an.
Eine Liste aller möglichen Reason und Diagnostic Codes für die N-EDIN befindet
sich in Anhang A.3 bzw. A.4.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-91

EANCOM-Handbuch
EDIFACT Meldungsvermittlung und -kontrolle
17.5.3 Homogene X.435-Umgebung mit Clearing-Center
17.5.3.1 Ok-Fall
EDIMS
EDIM-Absender
EDI CC
EDIM-Empfänger
EDI
UA
MTA
MTA
EDI
UA
MTA
MTA
EDI
UA
1
2
3
4
5
EDIM
Deliv
F-EDIN
EDIM
Deliv
6
P-EDIN
Absender und Empfänger sind beide im EDI Messaging Environment integriert,
kommunizieren aber nicht direkt miteinander, sondern über ein Clearing-Center.
Das Clearing-Center verwendet die Forwarding-Funktion gemäss X.435.
1. Die EDI-Meldung wird vom EDI-UA des Absenders abgeschickt und zum Clearing-Center
transportiert.
2. Die Auslieferung der Meldung an den EDI-UA des Clearing-Centers wird dem
Absender in Form eines Delivery Reports bestätigt.
3. Der EDI-UA des Clearing-Centers ermittelt den effektiven Empfänger der Meldung
und leitet sie unverändert an ihn weiter.
4. Gleichzeitig wird dem Absender die Weiterleitung in Form einer 'Forwarding Notification'
(FN) signalisiert.
5. Die Auslieferung der weitergeleiteten Meldung an den EDI-UA des Empfängers
wird dem Clearing-Center in Form eines Delivery Reports bestätigt.
6. Der EDI-UA des Empfangssystems prüft den EDIM Header, akzeptiert die Meldung
und schickt eine positive EDI-Notifikation (PN) direkt an den Absender.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-92

EANCOM-Handbuch
EDIFACT Meldungsvermittlung und -kontrolle
17.5.3.2 Fehlerfall 1: Non-Delivery Report nach Forwarding
EDIMS
EDIM-Absender
EDI CC
EDIM-Empfänger
EDI
UA
MTA
MTA
EDI
UA
MTA
MTA
EDI
UA
1
2
EDIM
Deliv
3
EDIM
4
F-EDIN
5
6
N-EDIN
Non-Deliv
Die Meldung wird vom Clearing-Center akzeptiert und an den Empfänger weitergeleitet.
Die Meldung wird auf dem Weg zum Empfänger oder vom Empfänger
selbst auf der Transportebene negativ quittiert. Für das Clearing-Center gibt es
gemäss X.435 Standard drei mögliche Reaktionen:
a) sofort N-EDIN an den Absender
b) limitierte Wiederholungsversuche, dann N-EDIN an Absender
c) keine EDIN an den Absender (Timeout). Das Clearing-Center bemüht sich, zusammen
mit dem Empfänger, um eine möglichst schnelle Lösung des Problems
und einen fehlerfreien Transport der Meldung.
In diesem Fallbeispiel wird Variante a) dargestellt.
1. Die EDI-Meldung wird vom EDI-UA des Absenders zum CC transportiert.
2. Die Auslieferung der Meldung an den EDI-UA des Clearing-Centers wird dem
Absender in Form eines Delivery Reports bestätigt.
3. Der EDI-UA des Clearing-Centers ermittelt den effektiven Empfänger der Meldung
und leitet sie unverändert an ihn weiter.
4. Gleichzeitig wird dem Absender die Weiterleitung in Form einer FN signalisiert.
5. Eine Auslieferung der Meldung an den EDI-UA des Empfängers findet nicht statt;
dem CC wird das in Form eines Non-Delivery Reports signalisiert.
6. Das CC orientiert den Absender mittels einer negativen EDI-Notifikation über
das Scheitern der Uebermittlung.
Hinweis: Die Wahl der Variante kann vom Geschäftsfall abhängen. Die
Variante a) empfehlen wir nur in Ausnahmefällen. Die Variante
c) stellt den höchsten Service-Level dar, den ein CC im obigen
Fehlerfall offerieren kann.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-93

EANCOM-Handbuch
EDIFACT Meldungsvermittlung und -kontrolle
17.5.3.3 Fehlerfall 2: Negative EDI-Notifikation durch den Empfänger
EDIMS
EDIM-Absender
EDI CC
EDIM-Empfänger
EDI
UA
MTA
MTA
EDI
UA
MTA
MTA
EDI
UA
1
2
3
4
5
EDIM
Deliv
F-EDIN
EDIM
Deliv
6
N-EDIN
Die Meldung wird vom Clearing-Center akzeptiert, an den Empfänger weitergeleitet
und an diesen ausgeliefert. Für das Clearing-Center ist die Transaktion damit abgeschlossen.
Später stellt der Empfänger aber auf der EDI-Ebene (EDIM Heading)
einen Fehler fest und weist die Meldung mittels einer negativen Notifikation an den
Absender zurück.
1. Die EDI-Meldung wird vom EDI-UA des Absenders zum Clearing-Center transportiert.
2. Die Auslieferung der Meldung an den EDI-UA des Clearing-Centers wird dem
Absender in Form eines Delivery Reports bestätigt.
3. Der EDI-UA des Clearing-Centers ermittelt den effektiven Empfänger der Meldung
und leitet sie unverändert an ihn weiter.
4. Gleichzeitig wird dem Absender die Weiterleitung in Form einer 'Forwarding Notification'
(FN) signalisiert.
5. Die Auslieferung der weitergeleiteten Meldung an den EDI-UA des Empfängers
wird dem Clearing-Center in Form eines Delivery Reports bestätigt.
6. Der EDI-UA des Empfangssystems prüft den EDIM Header, stellt einen Fehler
fest, verweigert die Annahme der Meldung und schickt eine negative EDI-
Notifikation (NN) direkt an den Absender.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-94

EANCOM-Handbuch
EDIFACT Meldungsvermittlung und -kontrolle
17.5.3.4 Fehlerfall 3: Negative EDI-Notifikation durch das Clearing-Center
EDIMS
ED IM-Absender
EDI C C
EDIM-Empfänger
EDI
UA
MTA
MT A
EDI
UA
MTA
MTA
EDI
UA
1
2
3
EDIM
Deliv
N-EDIN
Die Meldung wird vom Clearing-Center entgegengenommen, kann dann aber wegen
falscher oder fehlender Information im EDI Message Heading nicht weitergeleitet
werden. Das Clearing-Center schickt eine negative Notifikation mit entsprechenden
Parametern (Reason, Diagnostic) an den Absender zurück.
1. Die EDI-Meldung wird vom EDI-UA des Absenders zum Clearing-Center transportiert.
2. Die Auslieferung der Meldung an den EDI-UA des Clearing-Centers wird dem
Absender in Form eines Delivery Reports bestätigt.
3. Der EDI-UA des Clearing-Centers will den effektiven Empfänger der Meldung
ermitteln, stellt dabei aber fest, dass die Meldung wegen falscher oder fehlender
Informationen im EDI Message Heading nicht zustellbar ist. Er schickt deshalb
eine negative Notifikation an den Absender der Meldung zurück.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-95

EANCOM-Handbuch
EDIFACT Meldungsvermittlung und -kontrolle
17.5.4 Heterogene Umgebung mit einem Clearing-Center
17.5.4.1 Ok-Fall: EDIM-Absender an FT-Empfänger
EDIMS
Non - X.435
EDIM-Absender
EDI CC
Empfänger
EDI
UA
MTA
MTA
EDI
UA
FT
FT
1
2
3
4
5
6
EDIM
Deliv
F-EDIN
P-EDIN
FT
Ack
Der Empfänger ist nicht über X.435 erreichbar; das Clearing-Center übernimmt für
ihn die Rolle des Gateways. Dem Absender wird mittels FN signalisiert, dass ein
Forwarding stattfindet. Das Clearing-Center besorgt den Weitertransport über den
entsprechenden FT-Service zum effektiven Empfänger. Nach Abschluss des
Transfers schickt das Clearing-Center eine PN an den Absender zurück. Hinweis:
Der Service des Clearing-Centers kann allenfalls auch die EDIFACT-Konversion
beinhalten; in diesem Fall erfolgt der Datentransport zum Empfänger im Inhouse-
Format.
1. Die EDI-Meldung wird vom EDI-UA des Absenders zum CC transportiert.
2. Die Auslieferung der Meldung an den EDI-UA des Clearing-Centers wird dem
Absender in Form eines Delivery Reports bestätigt.
3. Der UA des CC prüft den EDI Message Header, ermittelt den effektiven Empfänger
und schickt dem Absender eine Forwarding Notification (FN).
4. Der UA des Clearing-Centers übergibt die Meldung dem zuständigen FT-Service
zur Uebermittlung. Der File Transfer kann über mehrere Zwischenstationen gehen
und auch einen Mailbox-Zugriff des Empfängers beinhalten.
5. Der FT-Service meldet den erfolgreichen Abschluss der Uebertragung. Die Art
der Ack-Signalisierung ist abhängig vom verwendeten FT-Mechanismus. Stellvertretend
oder ergänzend zur Ack-Signalisierung können auf der FT-Strecke
auch EERP oder EDIFACT CONTRL-Messages (Interchange Acknowledge) verwendet
werden (vergl. 7.5.6.1).
6. Der EDI-UA des Clearing-Centers schickt eine positive EDI-Notifikation an den
Absender.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-96

EANCOM-Handbuch
EDIFACT Meldungsvermittlung und -kontrolle
17.5.4.2 Fehlerfall: EDIM-Absender an FT-Empfänger
EDIMS
Non - X.435
EDIM-Absender
EDI CC
Empfänger
EDI
UA
MTA
MTA
ED I
UA
FT
FT
1
2
3
EDIM
Deliv
F-EDIN
4
5
6
N-EDIN
FT
Error
Der Empfänger ist nicht über X.435 erreichbar; das CC übernimmt für ihn die Rolle
des Gateways. Dem Absender wird signalisiert, dass ein Forwarding stattfindet.
Das CC besorgt den Weitertransport der Meldung über den entsprechenden FT-
Service zum effektiven Empfänger; der Transfer kann aber innerhalb der gesetzten
Frist nicht erfolgreich beendet werden. Analog zur X.435-Regelung (vergl. 7.5.2.2)
gibt es für das CC drei mögliche Reaktionen:
a) sofort N-EDIN an den Absender
b) limitierte Wiederholungsversuche, dann N-EDIN an Absender
c) keine EDIN an den Absender (Timeout). Das CC bemüht sich, zusammen mit
dem Empfänger, um eine möglichst schnelle Lösung des Problems und einen
fehlerfreien Transport der Meldung.
In diesem Fallbeispiel wird Variante a) dargestellt.
1. Die EDI-Meldung wird vom EDI-UA des Absenders zum CC transportiert.
2. Der UA des CC schickt einen Delivery Report an den Absender.
3. Der UA des CC schickt eine Forwarding Notification an den Absender.
4. Der UA des CC ermittelt den effektiven Empfänger der Meldung und übergibt sie
dem zuständigen FT-Service zur Uebermittlung.
5. Der FT-Service meldet mittels 'Error'-Signal das Scheitern der Uebertragung.
Die Art der Fehlersignalisierung ist abhängig vom jeweiligen FT-Mechanismus.
6. Der UA des CC schickt eine negative EDI-Notifikation an den Absender.
7. Hinweis: Die Wahl der Variante kann vom Geschäftsfall abhängen. Die Variante
a) empfehlen wir nur in Ausnahmefällen. Die Variante c) stellt den höchsten
Service-Level dar, den ein Clearing-Center im obigen Fehlerfall offerieren kann.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-97

EANCOM-Handbuch
EDIFACT Meldungsvermittlung und -kontrolle
17.5.4.3 Ok-Fall: FT-Absender an EDIM-Empfänger
Non - X.435
EDIMS
Abs ende r
EDI CC
EDIM -Em pfän ger
FT
FT
EDI
UA
MTA
MTA
EDI
UA
1
2
3
4
FT
EDIM
Deliv
P-EDIN
5 Ack
Der Absender ist nicht über X.435 angeschlossen; das Clearing-Center übernimmt
für ihn die Rolle des Gateways. Er übermittelt die Meldung über den entsprechenden
FT-Service zum Clearing-Center. Das Clearing-Center baut aus der Meldung
eine EDIM und schickt diese an den effektiven Empfänger. Dieser quittiert die Lieferung
und akzeptiert die Meldung. Nach Empfang der positiven Notifikation signalisiert
das Clearing-Center dem Absender den erfolgreichen Abschluss der Uebertragung
mittels einem entsprechenden 'Ack'.
1. Die Meldung wird vom Absender über den zuständigen FT-Service zum Clearing-Center
transportiert.
2. Das Clearing-Center schickt die Meldung als EDIM via X.435 weiter an den
Empfänger.
3. Der Empfänger quittiert die Lieferung mittels Delivery Report.
4. Der Empfänger akzeptiert die EDIM und schickt eine positive EDI-Notifikation
ans Clearing-Center.
5. Das Clearing-Center signalisiert dem Absender den erfolgreichen Abschluss der
Uebertragung mittels 'Ack'.
6. Hinweis: Die Art der Ack-Signalisierung ist abhängig vom jeweiligen FT-
Mechanismus. Ein mittels OFTP angeschlossener Absender wird im allgemeinen
den EERP-Mechanismus verwenden. Eine andere Möglichkeit besteht darin,
UNB-gesteuert eine CONTRL-Message zu verlangen (vergl. 7.5.6.3). Alle Requests
müssen aber vom Clearing-Center (Gateway-System) gegenüber dem
X.435-Empfänger in jedem Fall auf einen EDIN-Request abgebildet werden.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-98

EANCOM-Handbuch
EDIFACT Meldungsvermittlung und -kontrolle
17.5.4.4 FT-Absender an EDIM-Empfänger, Non-Delivery
Non - X.435
EDIMS
Absender
EDI CC
EDIM-Empfän ger
FT
FT
EDI
UA
MTA
MTA
EDI
UA
1
2
3
4
FT
Error
EDIM
Non-Deliv
Der Absender ist nicht über X.435 angeschlossen; das Clearing-Center übernimmt
für ihn die Rolle des Gateways. Er übermittelt die Meldung über den entsprechenden
FT-Service zum Clearing-Center. Das Clearing-Center baut aus der Meldung eine
EDIM und schickt diese an den effektiven Empfänger. Die Meldung kann aber nicht
ausgeliefert werden, das Clearing-Center erhält einen Non-Delivery Report. Der
Absender wird vom Clearing-Center mittels 'Error'-Signal über die gescheiterte Uebertragung
informiert.
1. Die Meldung wird vom Absender über den zuständigen FT-Service zum Clearing-Center
transportiert.
2. Das Clearing-Centers schickt die Meldung als EDIM via X.435 weiter an den
Empfänger.
3. Die Meldung erreicht den Empfänger nicht bzw. wird von ihm auf Transportebene
abgewiesen.
4. Das Clearing-Center signalisiert dem Absender das Scheitern der Uebertragung
mittels 'Error'.
5. Hinweis: Die Art der Error-Signalisierung ist abhängig vom jeweiligen FT-
Mechanismus. Der Absender kann beispielsweise UNB-gesteuert eine
CONTRL-Message verlangen (vergl. 7.5.6.4). Der Request muss aber vom Clearing-Center
(Gateway-System) gegenüber dem X.435-Empfänger in jedem Falle
auf einen EDIN-Request abgebildet werden. Umgekehrt muss die EDIFACT-
Notifikation des X.435-Empfängers vom Gateway-System auf die Error-
Signalisierung des Absenders konvertiert werden.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-99

EANCOM-Handbuch
EDIFACT Meldungsvermittlung und -kontrolle
17.5.4.5 FT-Absender an EDIM-Empfänger, negative EDI-Notifikation
Non - X.435
EDIMS
Abs ende r
EDI CC
EDIM -Em pfän ger
FT
FT
EDI
UA
MTA
MTA
EDI
UA
1
2
3
4
5
FT
Error
EDIM
Deliv
N-EDIN
Der Absender ist nicht über X.435 angeschlossen; das Clearing-Center übernimmt
für ihn die Rolle des Gateways. Er übermittelt die Meldung über den entsprechenden
FT-Service zum Clearing-Center. Das Clearing-Center baut aus der Meldung
eine EDIM und schickt diese an den effektiven Empfänger. Dieser quittiert die
Lieferung, weist sie aber nach Prüfung des EDIM Headings mittels negativer Notifikation
ab. Der Absender wird vom Clearing-Center mittels 'Error'-Signal über die
gescheiterte Uebertragung informiert.
1. Die Meldung wird vom Absender über den zuständigen FT-Service zum Clearing-Center
transportiert.
2. Das Clearing-Center schickt die Meldung als EDIM via X.435 weiter an den
Empfänger.
3. Der Empfänger quittiert die Lieferung mittels Delivery Report.
4. Der EDI-UA des Empfangssystems prüft den EDIM Header, stellt einen Fehler
fest, verweigert die Annahme der Meldung und schickt eine negative EDI-
Notifikation (NN) ans Clearing-Center.
5. Das Clearing-Center signalisiert dem Absender das Scheitern der Uebertragung
mittels 'Error'.
6. Hinweis: Die Art der Error-Signalisierung ist abhängig vom jeweiligen FT-
Mechanismus. Der Absender kann beispielsweise UNB-gesteuert eine
CONTRL-Message verlangen (vergl. 7.5.6.5). Der Request muss aber vom Clearing-Center
(Gateway-System) gegenüber dem X.435-Empfänger in jedem Falle
auf einen EDIN-Request abgebildet werden. Umgekehrt muss die EDIFACT-
Notifikation des X.435-Empfängers vom Gateway-System auf die Error-
Signalisierung des Absenders konvertiert werden.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-100

EANCOM-Handbuch
EDIFACT Meldungsvermittlung und -kontrolle
17.5.5 Heterogene Umgebung mit zwei Clearing-Centers, X.435 -> FT
17.5.5.1 Ok-Fall: X.435-Absender an FT-Empfänger, mit FN und PN
EDIM-Absender
EDIMS
EDI CC 1 EDI CC 2
Non - X.435
Empfänger
EDI
UA
MTA
MTA
EDI
UA
MTA
MTA
EDI
UA
FT
FT
1
EDIM
2
Deliv
ED IM
3
F-EDIN
4
Deliv
5
F-EDIN
FT
6
Ack
7
P-EDIN
Der Empfänger ist nicht über X.435 erreichbar; das Clearing-Center 2 übernimmt
für ihn die Rolle des Gateways. Dem Absender wird mittels FN signalisiert, dass
ein Forwarding stattfindet. Das Clearing-Center 2 besorgt den Weitertransport über
den entsprechenden FT-Service zum effektiven Empfänger. Nach Abschluss des
Transfers schickt das Clearing-Center 2 je nach Erfolg eine PN oder NN an den
Absender zurück. Hinweis: Der Service des Clearing-Centers 2 kann auch die
EDIFACT-Konversion beinhalten; in diesem Fall erfolgt der Datentransport zum
Empfänger im Inhouse-Format.
1. Die EDI-Meldung wird vom EDI-UA des Absenders zum CC 1 transportiert.
2. Das Clearing-Center 1 schickt einen Delivery Report an den Absender und leitet
die Meldung weiter an das Clearing-Center 2.
3. Das Clearing-Center 1 schickt eine FN an den Absender.
4. Das CC 2 schickt einen Delivery Report an das CC 1.
5. Der UA des Clearing-Centers 2 ermittelt den effektiven Empfänger der Meldung
und übergibt sie dem zuständigen FT-Service zur Uebermittlung. Der File
Transfer kann über mehrere Zwischenstationen gehen und auch einen Mailbox-
Zugriff des Empfängers beinhalten. Gleichzeitig wird dem Absender die Weiterleitung
in Form einer FN signalisiert.
6. Der FT-Service meldet den erfolgreichen Abschluss der Uebertragung. Die Art
der Ack-Signalisierung ist abhängig vom jeweiligen FT-Mechanismus; es wird
aber vorausgesetzt, dass die technische Basis vorhanden ist.
7. Der EDI-UA des CC 2 schickt eine positive EDI-Notifikation an den Absender.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-101

EANCOM-Handbuch
EDIFACT Meldungsvermittlung und -kontrolle
17.5.5.2 Ok-Fall: X.435-Absender an FT-Empfänger, mit PN nach FT
EDIMS
Non - X.435
EDIM-Absender
EDICC1
EDICC2
Empfänger
EDI
UA
MTA
MTA
EDI
UA
MTA
MTA
EDI
UA
FT
FT
1
2
3
4
EDIM
Deliv
F-EDIN
ED IM
Deliv
5
6
7
P-EDIN
FT
Ack
Der Empfänger ist nicht über X.435 erreichbar; das Clearing-Center 2 übernimmt
für ihn die Rolle des Gateways. Dem Absender wird nicht signalisiert, dass ein
Forwarding stattfindet. Das Clearing-Center 2 besorgt den Weitertransport über
den entsprechenden FT-Service zum effektiven Empfänger. Nach Abschluss des
Transfers schickt das Clearing-Center 2 je nach Erfolg eine PN oder NN an den
Absender zurück. Diese Methode vermittelt dem Absender zwar verlässliche Informationen
über das Schicksal seiner Meldungen, lässt ihn aber bei Problemen im
Ungewissen darüber, an welcher Stelle des Transportweges Meldungen steckenbleiben.
1. Die EDI-Meldung wird vom EDI-UA des Absenders zum Clearing-Center transportiert.
2. Das Clearing-Center 1 schickt einen Delivery Report an den Absender und leitet
die Meldung weiter an das Clearing-Center 2.
3. Das Clearing-Center 1 schickt eine FN an den Absender.
4. Das Clearing-Center 2 schickt einen Delivery Report an das Clearing-Center 1.
5. Der UA des Clearing-Centers 2 ermittelt den effektiven Empfänger der Meldung
und übergibt sie dem zuständigen FT-Service zur Uebermittlung. Der File
Transfer kann über mehrere Zwischenstationen gehen und auch einen Mailbox-
Zugriff des Empfängers beinhalten.
6. Der FT-Service meldet den erfolgreichen Abschluss der Uebertragung. Die Art
der Ack-Signalisierung ist abhängig vom jeweiligen FT-Mechanismus; es wird
aber vorausgesetzt, dass die technische Basis vorhanden ist.
7. Der UA des Clearing-Centers 2 schickt eine positive EDI-Notifikation an den Absender.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-102

EANCOM-Handbuch
EDIFACT Meldungsvermittlung und -kontrolle
17.5.5.3 Ok-Fall: X.435-Absender an FT-Empfänger, PN vor FT
EDIM-Absender
EDIMS
EDI CC 1 EDI CC 2
Non - X.435
Empfänger
EDI
UA
MTA
MTA
EDI
UA
MTA
MTA
EDI
UA
FT
FT
1
2
3
4
5
EDIM
Deliv
F-EDIN
ED IM
Deliv
P-EDIN
6
FT
Der Empfänger ist nicht über X.435 erreichbar; das Clearing-Center 2 übernimmt
für ihn die Rolle des Gateways. Dem Absender wird nicht signalisiert, dass ein
Forwarding stattfindet; das Clearing-Center 2 übernimmt unmittelbar die Verantwortung
für die Meldung und ist selbst besorgt für den späteren Weitertransport
über den entsprechenden FT-Service zum effektiven Empfänger. Ein Scheitern
dieses File Transfers kann dem Absender nicht mehr signalisiert werden. Dies hat
zur Folge, dass der Absender trotz PN nicht sicher sein kann, ob die Meldung wirklich
beim Empfänger angekommen ist.
1. Die EDI-Meldung wird vom EDI-UA des Absenders zum Clearing-Center transportiert.
2. Das Clearing-Center 1 schickt einen Delivery Report an den Absender und leitet
die Meldung weiter an das Clearing-Center 2.
3. Das Clearing-Center 1 schickt eine FN an den Absender.
4. Das Clearing-Center 2 schickt einen Delivery Report an das Clearing-Center 1.
5. Der EDI-UA des Clearing-Centers 2 schickt eine positive EDI-Notifikation an den
Absender.
6. Der UA des Clearing-Centers 2 ermittelt den effektiven Empfänger der Meldung
und übergibt sie dem zuständigen FT-Service zur Uebermittlung. Der File
Transfer kann über mehrere Zwischenstationen gehen und auch einen Mailbox-
Zugriff des Empfängers beinhalten.
7. Falls vorübergehend eine derartige Lösung getroffen wird, muss diese Tatsache
vom Clearing-Center 2 publiziert werden. Sie soll im Interchange Agreement
zwischen Absender und Empfänger festgehalten werden. EAN (Schweiz) empfiehlt,
auf derartige Lösungen zu verzichten.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-103

EANCOM-Handbuch
EDIFACT Meldungsvermittlung und -kontrolle
17.5.5.4 Ok-Fall: X.435-Absender an FT-Empfänger, nur FN
EDIM-Absender
EDIMS
EDI CC 1 EDI CC 2
Non - X.435
Empfänger
EDI
UA
MTA
MTA
EDI
UA
MTA
MTA
EDI
UA
FT
FT
1
2
3
4
5
EDIM
Deliv
F-EDIN
ED IM
Deliv
F-EDIN
6
FT
Der Empfänger ist nicht über X.435 erreichbar; das Clearing-Center 2 übernimmt
für ihn die Rolle des Gateways. Dem Absender wird mittels FN signalisiert, dass
ein Forwarding stattfindet. Eine PN wird nicht erzeugt, weil das Gateway-System 2
die Verantwortung nicht übernehmen will und der effektive Empfänger ausserhalb
von X.435 die PN nicht erzeugen kann.
1. Die EDI-Meldung wird vom EDI-UA des Absenders zum Clearing-Center 1
transportiert.
2. Das Clearing-Centers 1 schickt einen Delivery Report an den Absender und leitet
die Meldung weiter an das Clearing-Center 2.
3. Das Clearing-Center 1 schickt eine FN an den Absender.
4. Das Clearing-Center 2 schickt einen Delivery Report an das Clearing-Center 1.
5. Das Clearing-Center 2 speichert die Meldung (zB. in einer Mailbox des Empfängers)
und sendet eine FN an den Absender.
6. Der File Transfer an den Empfänger wird mit keiner Notifikation bestätigt.
7. Hinweis: Der P-EDIN-Request des EDIM-Absenders kann bei dieser Implementation
nicht erfüllt werden. Diese Tatsache muss vom Clearing-Center 2 offengelegt
werden. Sie soll im Interchange Agreement zwischen Absender und
Empfänger festgehalten werden.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-104

EANCOM-Handbuch
EDIFACT Meldungsvermittlung und -kontrolle
17.5.6 Heterogene Umgebung mit zwei Clearing-Centers, FT -> X.435
17.5.6.1 Ok-Fall: FT-Absender an EDIM-Empfänger
Non - X.435
EDIMS
Absender
EDI CC 1
EDI CC 2
EDIM -Empfänger
FT
FT
EDI
UA
MTA
MTA
EDI
UA
MTA
MTA
EDI
UA
1
2
FT
EDIM
3
4
5
Deliv
F-EDIN
EDIM
Deli v
6
P-EDIN
7 Ack
Der Absender ist nicht über X.435 angeschlossen; er übermittelt die Meldung über
den entsprechenden FT-Service zum Clearing-Center 1. Dieses übernimmt für ihn
die Rolle des Gateways, baut aus der Meldung eine EDIM und schickt diese ans
Clearing-Center 2. Von dort geht sie via X.435 an den effektiven Empfänger. Dieser
quittiert die Lieferung und akzeptiert die Meldung mittels positiver EDI-
Notifikation. Nach Empfang der PN signalisiert das Clearing-Center 1 dem Absender
den erfolgreichen Abschluss der Uebertragung mittels einem entsprechenden
'Ack'.
1. Die Meldung wird vom Absender über den FT-Service zum Clearing-Center 1
transportiert.
2. Das Clearing-Center 1 schickt die Meldung als EDIM via X.435 weiter zum CC 2.
3. Das Clearing-Center 2 quittiert die Lieferung mittels Delivery Report und leitet
sie weiter zum effektiven Empfänger.
4. Gleichzeitig wird dem Clearing-Center 1 die Weiterleitung in Form einer 'Forwarding
Notification' signalisiert.
5. Der Empfänger erhält die Meldung und quittiert sie mittels Delivery Report.
6. Der EDI-UA des Empfängers akzeptiert die EDIM und schickt eine positive EDI-
Notifikation direkt ans Clearing-Center 1.
7. Das Clearing-Center 1 signalisiert dem Absender den erfolgreichen Abschluss
der Uebertragung mittels 'Ack'.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-105

EANCOM-Handbuch
17.5.7 Heterogene Umgebung mit CONTRL-Message
17.5.7.1 Ok-Fall: EDIM-Absender an FT-Empfänger
EDIFACT Meldungsvermittlung und -kontrolle
EDIMS
Non - X.435
EDIM-Absender
EDI CC
Empfänger
EDI
UA
MTA
MTA
EDI
UA
FT
FT
1
2
3
EDIM
Deliv
F-EDIN
4
5
FT
Ack
6
+CONTRL
7 P-EDIN
Ack
Der Empfänger ist nicht über X.435 erreichbar; das CC übernimmt für ihn die Rolle
des Gateways. Dem Absender wird mittels FN signalisiert, dass ein Forwarding
stattfindet. Das Clearing-Center setzt im UNB den Ack-Request und schickt die
Daten über den entsprechenden FT-Service zum effektiven Empfänger. Dieser
prüft die Meldung, generiert eine CONTRL-Message und schickt sie via FT zum
Gateway. Diese bildet die CONTRL-Message ab auf eine P-EDIN und schickt sie
an den Absender zurück.
1. Die EDI-Meldung wird vom EDI-UA des Absenders zum CC transportiert.
2. Die Auslieferung der Meldung an den EDI-UA des Clearing-Centers wird dem
Absender in Form eines Delivery Reports bestätigt.
3. Der UA des CC prüft den EDI Message Header, ermittelt den effektiven Empfänger
und schickt dem Absender eine Forwarding Notification (FN).
4. Der UA des Clearing-Centers setzt im UNB den Ack Request und übergibt die
Meldung dem zuständigen FT-Service zur Uebermittlung. Der File Transfer kann
über mehrere Zwischenstationen gehen und auch einen Mailbox-Zugriff des
Empfängers beinhalten.
5. Der FT-Service meldet den erfolgreichen Abschluss der Uebertragung.
6. Der Empfänger der EDI-Message sendet eine CONTRL-Message ‘Interchange
received’ (Segment UCI, Datenelement 0083, Wert 8) zum Clearing-Center.
7. Das Clearing-Center bildet die CONTRL-Message ‘Interchange received’ auf eine
P-EDIN ab und schickt diese an den EDIM-Absender.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-106

EANCOM-Handbuch
17.5.7.2 Fehlerfall: EDIM-Absender an FT-Empfänger
EDIFACT Meldungsvermittlung und -kontrolle
EDIMS
Non - X.435
EDIM-Absender
EDI CC
Empfänger
EDI
UA
MTA
MTA
EDI
UA
FT
FT
1
2
3
EDIM
Deliv
F-EDIN
4
5
FT
Ack
6
-CONTRL
7 N-EDIN
Ack
Der Empfänger ist nicht über X.435 erreichbar; das Clearing-Center übernimmt für
ihn die Rolle des Gateways. Dem Absender wird signalisiert, dass ein Forwarding
stattfindet. Das Clearing-Center besorgt den Weitertransport der Meldung über den
entsprechenden FT-Service zum effektiven Empfänger. Dieser lehnt den ganzen
Interchange mit einer negativen CONTRL-Meldung ab. Das Clearing-Center übersetzt
die negative CONTRL-Meldung in eine N-EDIN.
1. Die EDI-Meldung wird vom EDI-UA des Absenders zum Clearing-Center transportiert.
2. Der UA des Clearing-Centers schickt einen Delivery Report an den Absender.
3. Der UA des Clearing-Center schickt eine Forwarding Notification an den Absender.
4. Das Clearing-Center ermittelt den effektiven Empfänger der Meldung und übergibt
sie dem zuständigen FT-Service zur Uebermittlung.
5. Der FT-Service meldet den erfolgreichen Abschluss der Uebertragung.
6. Der Empfänger der EDI-Message sendet eine CONTRL-Message ‘Interchange
rejected’ (Segment UCI, Datenelement 0083, Wert 4) zum Clearing-Center.
7. Das Clearing-Center bestätigt den Empfang der CONTRL-Meldung (Interchange
rejected) und sendet eine negative EDI-Notifikation an den Absender der ursprünglichen
Meldung.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-107

EANCOM-Handbuch
17.5.7.3 Ok-Fall: FT-Absender an EDIM-Empfänger
EDIFACT Meldungsvermittlung und -kontrolle
Non - X.435
EDIMS
Absender
EDI CC
EDIM-Empfänger
FT
FT
EDI
UA
MTA
MTA
EDI
UA
1
2
3
4
5
FT
Ack
EDIM
Deliv
P-EDIN
6 +CONTRL
7
Ack
Der Absender ist nicht über X.435 angeschlossen; das Clearing-Center übernimmt
für ihn die Rolle des Gateways. Er übermittelt die Meldung über den entsprechenden
FT-Service zum Clearing-Center. Das Clearing-Center baut aus der Meldung
eine EDIM und schickt diese an den effektiven Empfänger. Dieser quittiert den
Empfang und akzeptiert die Meldung. Nach Empfang der positiven Notifikation signalisiert
das Clearing-Center dem Absender den erfolgreichen Abschluss der Uebertragung
mittels einer EDIFACT CONTRL Meldung ‘Interchange received’.
1. Die Meldung wird vom Absender über den zuständigen FT-Service zum Clearing-Center
transportiert.
2. Der Transfer der Meldung wird mittels ‘Ack’ quittiert.
3. Das Clearing-Center schickt die Meldung als EDIM via X.435 weiter an den
Empfänger.
4. Der Empfänger quittiert die Lieferung mittels Delivery Report.
5. Der Empfänger akzeptiert die EDIM und schickt eine positive EDI-Notifikation
ans Clearing-Center.
6. Das Clearing-Center signalisiert dem Absender den erfolgreichen Abschluss der
Uebertragung mittels der EDIFACT CONTRL Meldung ‘Interchange received’
(Segment UCI, Datenelement 0083, Wert 8).
7. Der Transfer der CONTRL-Meldung wird mittels ‘Ack’ quittiert.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-108

EANCOM-Handbuch
EDIFACT Meldungsvermittlung und -kontrolle
17.5.7.4 FT-Absender an EDIM-Empfänger, Non-Delivery
Non - X.435
EDIMS
Absender
EDI CC
EDIM-Empfänger
FT
FT
EDI
UA
MTA
MTA
EDI
UA
1
2
3
4
5
6
FT
Ack
-CONTRL
Ack
EDIM
Non-Deliv
Der Absender ist nicht über X.435 angeschlossen; das Clearing-Center übernimmt
für ihn die Rolle des Gateways. Er übermittelt die Meldung über den entsprechenden
FT-Service zum Clearing-Center. Das Clearing-Center baut aus der Meldung
eine EDIM und schickt diese an den effektiven Empfänger. Dies Meldung kann
aber nicht ausgeliefert werden, das Clearing-Center erhält einen Non-Delivery Report
zurück. Der Absender wird vom Clearing-Center mittels der EDIFACT
CONTRL-Meldung ‘Interchange rejected’ über die gescheiterte Uebertragung informiert.
1. Die Meldung wird vom Absender über den zuständigen FT-Service zum Clearing-Center
transportiert.
2. Der Transfer der Meldung wird mittels ‘Ack’ quittiert.
3. Das Clearing-Center schickt die Meldung als EDIM via X.435 weiter an den
Empfänger.
4. Die Meldung erreicht den Empfänger nicht bzw. wird von ihm auf Transportebene
abgewiesen.
5. Das Clearing-Center signalisiert dem Absender das Scheitern der Uebertragung
mittels der EDIFACT CONTRL-Meldung ‘Interchange rejected’ (Segment UCI,
Datenelement 0083, Wert 4).
6. Der Transfer der CONTRL-Meldung wird mittels ‘Ack’ quittiert.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-109

EANCOM-Handbuch
EDIFACT Meldungsvermittlung und -kontrolle
17.5.7.5 FT-Absender an EDIM-Empfänger, negative EDI-Notifikation
Non - X.435
EDIMS
Absender
EDI CC
EDIM-Empfänger
FT
FT
EDI
UA
MTA
MTA
EDI
UA
1
2
3
4
5
6
FT
Ack
-CONTRL
EDIM
Deliv
N-EDIN
7 Ack
Der Absender ist nicht über X.435 angeschlossen; das Clearing-Center übernimmt
für ihn die Rolle des Gateways. Er übermittelt die Meldung über den entsprechenden
FT-Service zum Clearing-Center. Das Clearing-Center baut aus der Meldung
eine EDIM und schickt diese an den effektiven Empfänger. Dieser quittiert die Lieferung,
weist sie aber nach Prüfung des EDIM Headings mittels negativer Notifikation
ab. Der Absender wird vom Clearing-Center mittels der EDIFACT CONTRL-
Meldung ‘Interchange rejected’ über die abgewiesene Meldung informiert.
1. Die Meldung wird vom Absender über den zuständigen FT-Service zum Clearing-Center
transportiert.
2. Der Transfer der Meldung wird mittels ‘Ack’ quittiert.
3. Das Clearing-Center schickt die Meldung als EDIM via X.435 weiter an den
Empfänger.
4. Der Empfänger quittiert die Lieferung mittels Delivery Report.
5. Der EDI-UA des Empfangssystems prüft den EDIM Header, stellt einen Fehler
fest, verweigert die Annahme der Meldung und schickt eine negative EDI-
Notifikation (NN) ans Clearing-Center.
6. Das Clearing-Center signalisiert dem Absender die Abweisung der Meldung
durch den Empfänger mittels der EDIFACT CONTRL-Meldung ‘Interchange rejected’
(Segment UCI, Datenelement 0083, Wert 4).
7. Der Transfer der CONTRL-Meldung wird mittels ‘Ack’ quittiert.
17.6 Anhang A
17.6.1 Non-Delivery Reason Codes gemäss X.400 (1988), Anhang A.1
Die folgende Liste enthält alle möglichen Werte für das Attribut 'Non-Delivery
Reason Code', das in einem Non-Delivery Report an den Absender zurückgeht.
Der Code und der englische Text sind dem X.400 Standard entnommen; die deutsche
Uebersetzung ist inoffiziell.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-110

EANCOM-Handbuch
EDIFACT Meldungsvermittlung und -kontrolle
Code
Bedeutung
0 Meldungstransport gescheitert (transfer failure)
1 Meldungstransfer nicht möglich (unable to transfer)
2 X.400 Konversion nicht ausgeführt (conversion not performed)
3 Postalische Uebergabe nicht möglich (physical rendition not performed)
4 Postalische Auslieferung nicht möglich (physical delivery not possible)
5 Auslieferungsbeschränkung (restricted delivery)
6 Fehler beim Verzeichniszugriff (directory operation unsuccessful)
17.6.2 Non-Delivery Diagnostic Codes gemäss X.400 (1988), Anhang A.2
Die folgende Liste enthält alle möglichen Werte für das Attribut 'Non-Delivery Diagnostic
Code', das in einem Non-Delivery Report an den Absender zurückgeht. Der
Code und der englische Text sind dem X.400 Standard entnommen; die deutsche
Uebersetzung ist inoffiziell.
Code
Bedeutung
0 Empfänger unbekannt (unrecognised O/R name)
1 Empfänger nicht eindeutig (ambigous O/R name)
2 Meldungstransfersystem überlastet (MTS congestion)
3 Endlosschleife erkannt (loop detected)
4 Empfänger nicht bereit (recipient unavailable)
5 Zeitüberschreitung (maximum time expired)
6 Nachrichtformat nicht unterstützt (encoded information types unsupported)
7 Inhalt zu gross (content too long)
8 X.400 Konversion nicht machbar (conversion impractical)
9 X.400 Konversion untersagt (implicit conversion prohibited)
10 X.400 Konversion nicht verfügbar (implicit conversion not subscribed)
11 Ungültige Parameter (invalid arguments)
12 Ungültige Meldungsstruktur (content syntax error)
13 Parameterlänge ungültig (size contraint violation)
14 Protokollverletzung (protocol violation)
15 Meldungstyp nicht unterstützt (content type not supported)
16 Kritische Funktion nicht unterstützt (unsupported critical function)
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-111

EANCOM-Handbuch
Code
Bedeutung
EDIFACT Meldungsvermittlung und -kontrolle
19 X.400 Konversion nicht möglich (conversion with loss prohibited)
20 Zeile zu lang (line too long)
21 Seite zu lang (page split)
22 X.400 Konversion nicht möglich (pictorial symbol loss)
23 X.400 Konversion nicht möglich (punctuation symbol loss)
24 X.400 Konversion nicht möglich (alphabetic character loss)
25 X.400 Konversion nicht möglich (multiple information loss)
26 Umleitung nicht möglich (recipient reassignment prohibited)
27 Umleitungsschleife entdeckt (redirection loop detected)
28 Verteilerliste nicht erlaubt (DL expansion prohibited)
29 Verteilerliste nicht erlaubt (no DL submit permission)
30 Fehler in Verteilerliste (DL expansion failure)
31 Postalische Auslieferung nicht unterstützt (physical rendition attributes not
supported)
32 Postadresse ungültig (undeliverable mail, physical delivery address incorrect)
33 Ungültige oder unbekannte Poststelle (undeliverable mail, physical delivery
office incorrect)
34 Postadresse unvollständig (undeliverable mail, physical delivery address
incomplete)
35 Postempfänger unbekannt (undeliverable mail, recipient unknown)
36 Postempfänger gestorben (undeliverable mail, recipient deceased)
37 Postempfangsorganisation erloschen (undeliverable mail, organization expired)
38 Postempfang verweigert (undeliverable mail, recipient refused to accept)
39 Sendung nicht bestellt (undeliverable mail, recipient did not claim)
40 Postempfänger umgezogen (undeliverable mail, recipient changed address
permanently)
41 Postempfänger zur Zeit verreist (undeliverable mail, recipient changed
address temporarily)
42 Postempfänger abgereist (undeliverable mail, recipient changed temporary
address)
43 Postempfänger abgereist, neue Adresse unbekannt (undeliverable mail, new
address unknown)
44 Postnachsendung vom Empfänger untersagt (undeliverable mail, recipient
did not want forwarding)
45 Postnachsendung vom Absender untersagt (undeliverable mail, originator
prohibited forwarding)
46 Verletzung von Sicherheitsvorschriften (secure messaging error)
47 Kompatibilitätsproblem (unable to downgrade)
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-112

EANCOM-Handbuch
EDIFACT Meldungsvermittlung und -kontrolle
17.6.3 Negative Notification Reason Codes gemäss X.435 (1991), Anhang A.3
Die folgende Liste enthält alle möglichen Werte für das Attribut 'NN Reason Code'
in einer negativen Notifikation. Der Code und der englische Text sind dem X.435
Standard entnommen.
Code Quelle Bedeutung
0 UA/MS unspecified
1 UA/MS cannot deliver to user
2 UA/MS delivery timeout
3 UA/MS message discarded
4 UA/MS subscription terminated
5 UA/MS forwarding error
6 UA/MS security error
0 User unspecified
1 User syntax error (within EDI interchange)
2 User interchange sender unknown
3 User interchange recipient unknown
4 User invalid heading field
5 User invalid body part type
6 User invalid message type
7 User functional group not supported
8 User subscription terminated
9 User no bilateral agreement
10 User user defined reason
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-113

EANCOM-Handbuch
EDIFACT Meldungsvermittlung und -kontrolle
17.6.4 Negative Notification Diagnostic Codes gemäss X.435 (1991), Anhang A.4
Die folgende Liste enthält alle möglichen Werte für das Attribut 'NN Diagnostic
Code' in einer negativen Notifikation. Der Code und der englische Text sind dem
X.435 Standard entnommen.
Code Quelle Bedeutung
1 UA/MS protocol violation
2 UA/MS edim originator unknown
3 UA/MS edim recipient unknown
4 UA/MS edim recipient ambigous
5 UA/MS action request not supported
6 UA/MS edim expired
7 UA/MS edim obsoleted
8 UA/MS duplicate edim
9 UA/MS unsupported extension
10 UA/MS incomplete copy rejected
11 UA/MS edim too large for application
12 UA/MS forwarded edim not delivered
13 UA/MS forwarded edim delivery time out
14 UA/MS forwarding loop detected
15 UA/MS unable to accept responsibility
16 UA/MS interchange sender unknown
17 UA/MS interchange recipient unknown
18 UA/MS invalid heading field
19 UA/MS invalid body part type
20 UA/MS invalid message type
21 UA/MS invalid syntax id
22 UA/MS message integrity failure
23 UA/MS forwarded message integrity failure
24 UA/MS unsupported algorithm
25 UA/MS decryption failed
26 UA/MS token error
27 UA/MS unable to sign notification
28 UA/MS unable to sign message receipt
29 UA/MS authentification failure
30 UA/MS security context failure
31 UA/MS message sequence failure
32 UA/MS message security labelling failure
33 UA/MS repudiation failure
34 UA/MS proof of failure
any User Contains reason passed by the user when the
value of NN reason is 10 ('user defined
reason')
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 17-114

EANCOM-Handbuch
Data Interchange Agreement (DIA)
18 Data Interchange Agreement (DIA)
Auf den folgenden Seiten ist ein Muster eines DIA's eingefügt. Es soll als Beispiel
benutzt werden. Hinweise auf die Anwendung und den Inhalt eines DIA finden Sie
im Kapitel Betrieb.
Data Interchange Agreement
Vereinbarung über den elektronischen Datenaustausch
zwischen:
Kunden AG
Grabenstrasse 10
8050 Zürich
im folgenden "Partner A" genannt
und:
Liefer AG
Wilstrasse 500
9000 St. Gallen
im folgenden "Partner B" genannt
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 18-115

EANCOM-Handbuch
Data Interchange Agreement (DIA)
18.1 Gegenstand
Gegenstand der Vereinbarung ist der elektronische Datenaustausch (Electronic
Data Interchange), nachfolgend "EDI" genannt, zwischen Partner A und Partner B.
In Anhang 1 sind die vereinbarten Nachrichtentypen und Versionen festgehalten.
18.2 Nachrichtenstandard
Alle EDI-Nachrichten werden gemäss den UN/EDIFACT-Standard (ISO 9735, ISO
7372), sowie den Empfehlungen und Regeln des "EANCOM-CH" der EAN
(Schweiz, Suisse, Svizzera übermittelt.
18.3 Nachrichtenstruktur
Die Nachrichtenstruktur wird ausschliesslich durch das EANCOM-CH-Handbuch
bestimmt (Herausgeber: EAN (Schweiz, Suisse, Svizzera), Güterstrasse 133, 4053
Basel). Die für diese Verbindung gültige Nachrichtenstruktur und deren Inhalt sind
in Anhang 2 vereinbart.
18.4 Verantwortung
Die Partner sorgen in ihrem jeweiligen Zuständigkeitsbereich für Massnahmen, die
die Ordnungsmässigkeit der elektronisch ausgetauschten Daten gewährleisten und
die insbesondere Datenverluste, -verfälschungen und Verdoppelungen erkennen
lassen. Dem absendenden Partner obliegt die Ueberprüfung der "EANCOM-CH"-
Nachricht vor deren Übermittlung auf inhaltliche und formale Richtigkeit der Daten
und Vollständigkeit, gemäss den im "EANCOM-CH"-Handbuch festgehaltenen
Standards und Spezifikationen. Ausserdem hat jeder Partner dafür zu sorgen, dass
die Daten rechtzeitig zum Senden bereitgestellt bzw. die empfangenen Daten
rechtzeitig abgeholt werden. Dies gilt auch bei der Benützung von Mehrwertdiensten,
wie sie z.B. von den Clearing Houses angeboten werden. Die Verantwortung
für die Übermittlung der gesendeten "EANCOM-CH"-Nachrichten bleibt, bis zu deren
Eingang in dem vom Empfänger bezeichneten Datenspeicher, in jedem Falle
beim Absender.
Erfolgt während der Übertragung zum Datenspeicher des Empfängers eine Unterbrechung,
so ist der Absender für die Wiederholung der Übertragung bis zu deren
ordnungsgemässen Abschluss verantwortlich.
Wenn der empfangende Partner fehlerhafte Daten erkennt, hat er den sendenden
Partner unverzüglich zu verständigen. Die Behandlung von fehlerbehafteten Nachrichten
ist in Anhang 3 geregelt. Nachrichten aus technisch fehlerhaften Uebertragungen
gelten für beide Partner als nicht übertragen.
Die Kontaktpersonen, die zu Fragen der technischen Abwicklung und betriebswirtschaftlichen
Anwendung angesprochen werden können, sind in Anhang 5 benannt.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 18-116

EANCOM-Handbuch
18.5 Verbindlichkeit
Data Interchange Agreement (DIA)
Für die Verbindlichkeit der elektronisch übermittelten Daten gelten dieselben
Grundsätze wie für den übrigen Geschäftsverkehr zwischen den Vertragspartnern.
18.6 Datenschutz
Für die Vertraulichkeit der elektronisch übermittelten Daten gelten die gleichen
Grundsätze wie für den übrigen Geschäftsverkehr zwischen den Vertragspartnern.
Elektronisch übermittelte Daten dürfen nur für den Vertragszweck verwendet werden.
Die Grundsätze ordnungsgemässer Datenverarbeitung und -speicherung sind
einzuhalten. Daten, die Datenschutzgesetzen unterliegen, sind entsprechend zu
behandeln.
18.7 Aufbewahrungsvorschriften
Die gesetzlichen Aufbewahrungsvorschriften gelten mit den entsprechenden Fristen
auch für die Geschäftsvorgänge, die im elektronischen Datenaustausch übermittelt
werden.
18.8 Datensicherung
Die Ein- und Ausgabedaten müssen von den Vertragsparteien nach der vollständigen
Uebertragung wirksam gegen Verlust und /oder Ueberschreiben gesichert
werden.
Eine Wiederholungsübertragung muss gewährleistet und als solche eindeutig erkennbar
sein oder angekündigt werden. Einzelheiten sind in Anhang 6 geregelt.
18.9 Verfahrensänderungen
Anpassungen an einen neueren Stand der "EANCOM-Nachrichten" (Status-, Versions-
oder Release-Aenderungen), die Partner A auf seiner Seite durchführt, müssen
von Partner B nach Absprache mit Partner A innerhalb von sechs Monaten
seinerseits durchgeführt werden.
Aenderungen bei Hardware, Software oder Uebertragungstechnik, die sich auf EDI
auswirken, sind zwischen den Uebertragungspartnern, was Inhalt, Auswirkungen
und Einsatztermin angeht, abzustimmen und schriftlich festzuhalten. Dies gilt insbesondere
auch für die im vorangehenden Abschnitt genannten Anpassungen.
18.10 Verfügbarkeit
Ein Datenaustausch kann jederzeit stattfinden, vorbehältlich der Verfügbarkeit allfälliger
Mehrwertdienste (Clearing House) und des öffentlichen Netzes.
Geplante Stillstandzeiten des elektronischen Datenaustausches wie z.B. Wartung,
Betriebsschliessungen, Betriebsferien und lokale Feiertage sind dem Vertragspartner
so frühzeitig wie möglich mitzuteilen.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 18-117

EANCOM-Handbuch
18.11 Störungen
Data Interchange Agreement (DIA)
Der Partner, bei dem eine Störung auftritt, hat die Betroffenen sofort hierüber zu
informieren.
Die Vorgehensweise bei Störungen ist in Anhang 3 festgelegt.
18.12 Logische Prüfung von Reihenfolge und Vollständigkeit
Zur eindeutigen Indentifizierung der Partner müssen die im UNB-Segment des
"EANCOM-CH" Standards vorgesehenen Kennungen verwendet und geprüft werden.
In Anhang 4 sind die Partnerkennungen und Adressangaben, in Anhang 8 der
Zeitplan für die Übertragung von Nachrichten und relevanten Informationen festgehalten.
Die von "EANCOM-CH" vorgesehenen Felder zur Prüfung der Vollständigkeit
der Uebertragung sind zu verwenden und vom Empfänger zu prüfen. Dies gilt
insbesondere für die Segmentzahl und den Datenaustauschzähler im UNT-
Segment.
Es können Test- und Produktionsdaten gemischt übertragen werden; sie müssen
jedoch als solche entsprechend gekennzeichnet sein. Der Sender ist für das richtige
Setzen des entsprechenden Kennzeichens verantwortlich. Als Produktionsdaten
werden Daten und Aktionen verstanden, die Geschäftsvorfälle auslösen. Testdaten
dienen zum Austesten von Verbindungen, Prozeduren, Programmen, Abläufen
usw. und lösen keine Geschäftsvorfälle aus.
Weitere logische Prüfungen der Dateninhalte sind in Anhang 8 dargestellt.
18.13 Kosten
Jeder Vertragspartner trägt seine Kosten für das Uebermitteln und Empfangen von
Daten sowie für die Installation, Unterstützung und Benützung der jeweiligen
Mehrwertdienste.
18.14 Dauer der Vereinbarung
Diese Vereinbarung, die zugehörigen Anhänge und allfällige spätere Nachträge
treten mit Unterzeichnung durch beide Partner in Kraft, ist auf unbestimmte Zeit
abgeschlossen und ist von beiden Partnern mit einer Frist von 3 Monaten zum Monatsende
kündbar. Die Auflösung der Geschäftsbeziehungen zwischen den EDI-
Partnern bedeutet automatisch die Kündigung dieser Vereinbarung.
18.15 Schlussbestimmungen
Änderungen und Ergänzungen dieser Vereinbarung bedürfen der Schriftform. Alle
Änderungen und Ergänzungen haben ausschliesslich und mit Hinweis auf diese
Vereinbarung zu erfolgen; sie sind von beiden Parteien rechtsverbindliche zu unterzeichnen.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 18-118

EANCOM-Handbuch
Data Interchange Agreement (DIA)
Sollte eine Bestimmung dieser Vereinbarung unwirksam sein oder werden, wird die
Gültigkeit der übrigen Bestimmungen dadurch nicht berührt.
18.16 Anwendbares Recht
Diese Vereinbarung untersteht dem schweizerischen Recht.
Gerichtsstand im Falle von Streitigkeiten ist Zürich.
Partner A: Partner B:
Unterschrift: _____________________________
(Firmenstempel)
Unterschrift: _____________________________
(Firmenstempel)
Datum:
Zürich,
18.17 Anhänge
18.17.1 ANHANG 1 Vereinbarung der Nachrichtentypen und Standard
Vereinbarungen der Nachrichtentypen und Standard
Unterschrift:
Nachrichtentyp Standard Version
ORDERS EANCOM-CH 007
ORDRSP EANCOM-CH 006
INVOIC EANCOM-CH 006
Partner A: Partner B:
Unterschrift: _____________________________
(Firmenstempel)
Unterschrift: _____________________________
(Firmenstempel)
Datum:
Zürich,
18.17.2 ANHANG 2 Nachrichtenstrukturen ORDERS, ORDRSP, INVOIC
Gundlage für die Nachrichtenstruktur ist das EANCOM-CH-Handbuch.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 18-119

EANCOM-Handbuch
Data Interchange Agreement (DIA)
Der Inhalt, der dargestellt ist, bezieht sich auf die Informationen, welche gesendet werden.
Legende:
Seg
DE
Beschreibung
Inhalt
O
UN/EDIFACT Messagesegment
EANCOM/EANCOM-CH Datenelementnummer
Beschreibung des Datenelements laut
EANCOM-CH
vereinbarter Inhalt
M = muss / K = kann
Bestellungen (ORDERS)
Seg DE Beschreibung Inhalt O
UNH Nachrichten Kopfsegment M
0062 Nachrichten Referenznummer lückenlos numeriert M
S009 Nachrichten Kennung M
0065 Nachrichentyp Kennung ORDERS M
0052 Versionsnummer des Nachrichtentyps 90 M
0054 Freigabenummer des Nachrichtentyps 1 M
Seg DE Beschreibung Inhalt O
BGM Beginning of Message M
usw.
Bestellantwort (ORDRSP)
Seg DE Beschreibung Inhalt O
UNH Nachrichten Kopfsegment M
0062 Nachrichten Referenznummer lückenlos numeriert M
S009 Nachrichten Kennung M
usw.
Rechnung (INVOIC)
Seg DE Beschreibung Inhalt O
UNH Nachrichten Kopfsegment M
0062 Nachrichten Referenznummer lückenlos numeriert M
usw.
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 18-120

EANCOM-Handbuch
Data Interchange Agreement (DIA)
Partner A: Partner B:
Unterschrift: _____________________________
(Firmenstempel)
Unterschrift: _____________________________
(Firmenstempel)
Datum:
Zürich,
18.17.3 ANHANG 3 Behandlung von Fehlern und Störungen
Behandlung von Fehlern und Störungen.
Alle diese Fehler und Störungen sollten dokumentiert und verfolgt werden, damit solche
Fehler nicht mehr entstehen oder damit keine Beweisnot entsteht.
Fehler/Störung Verantwortlich Aktionen/Massnahmen
Unvollständige Übermittlung
Sender
Nochmaliges Senden der betreffenden
Daten
Nicht interpretierbare
Daten
Sender
Nochmaliges Senden der betreffenden
Daten
Hardwarefehler beim
Empfänger
Empfänger Sender benachrichtigen und Informationen
auf konventionellem Weg
Hardwarefehler beim
Sender
Sender
übermitteln
Empfänger benachrichtigen und Informationen
auf konventionellem
Weg übermitteln
Softwarefehler beim
Empfänger
Empfänger Sender informieren und Dokumente
auf anderem Weg übermitteln
Softwarefehler beim
Sender
Sender
Empfänger informieren und Dokumente
auf anderem Weg übermitteln
Präventive Wartung Sender/Empfänger Wenn Unterbruch nicht länger als
1.5 Std. dann keine Aktion. Falls
Applikation zeitkritisch wird, Partner
informieren und ev. Dokumente auf
traditionellem Weg senden
Inhaltliche Fehler Sender Informieren des Senders und allenfalls
korrigieren
Fehlende Nachrichten Sender Sender informieren und allenfalls
fehlende Nachrichten senden
Fehlender End-to-endresponse
usw.
Sender
Nachfragen beim Empfänger, ob die
Daten im Hause sind. Und falls nötig
nochmals senden oder auf anderem
Weg schicken
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 18-121

EANCOM-Handbuch
Data Interchange Agreement (DIA)
Partner A: Partner B:
Unterschrift: _____________________________
(Firmenstempel)
Unterschrift: _____________________________
(Firmenstempel)
Datum:
Zürich,
18.17.4 ANHANG 4 Partnererkennungen, Adressangaben und Locationcodes
Partnerkennungen, Adressangaben und Locationscodes. Kann während der Gültigkeit der
Vereinbarung Änderungen erfahren und sollte den Partner mitgeteilt werden. Bezieht sich
auf die Adressinformationen im NAD- und UNB-Segment.
Partner A
EAN Locationscode Name/Adresse
7654321000009 Kunden AG Zentrale, Käufer, Rechnungsempfänger
Kunden AG
Grabenstrasse 10
8050 Zürich
Gem. separater Liste Kunden AG Verteilzentralen und Filialen
von Kunden AG
Partner B
EAN Locationnummer Name/Adresse
7612345000008 Für alle Referenzen
Liefer AG
..................................
..................................
Unterschrift:
Partner A: Partner B:
Unterschrift: _____________________________
(Firmenstempel)
Unterschrift: _____________________________
(Firmenstempel)
Datum:
Zürich,
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 18-122

EANCOM-Handbuch
Data Interchange Agreement (DIA)
18.17.5 ANHANG 5 Kontaktpersonen und Adressangaben der beteiligten Partner
Kontaktpersonen und Adressangaben der beteiligten Partner.
Unterschrift:
Information
Artikelinformationen
Technische Fehler
Unvollständige Übermittlung
Nicht interpretierbare Daten
Inhaltliche Fehler
Fehlende Nachrichten
Fehlender End-to-endresponse
Präventive Wartung
Partner A
Name/Adresse
Kunden AG
Grabenstrasse 10
zuständiger PM
8045 Zürich
Kunden AG
Grabenstrasse 10
Hr. Müller
8050 Zürich
Kunden AG
Grabenstrasse 10
zuständiger PM
8050 Zürich
Kunden AG
Grabenstrasse 10
Hr. Müller
8050 Zürich
Kunden AG
Grabenstrasse 10
zuständiger PM
8050 Zürich
Kunden AG
zuständiger Disponent
Kunden AG
Grabenstrasse 10
Hr. Müller
8050 Zürich
Kunden AG
Grabenstrasse 10
Hr. Müller
8050 Zürich
Partner B
Name/Adresse
Liefer AG
Hr. R. Meier
..............................
..............................
Liefer AG
Hr. R. Meier
..............................
..............................
Liefer AG
Hr. R. Meier
..............................
..............................
Liefer AG
Hr. R. Meier
..............................
..............................
Liefer AG
Hr. R. Meier
..............................
..............................
Liefer AG
Hr. R. Meier
..............................
..............................
Liefer AG
Hr. R. Meier
..............................
..............................
Liefer AG
Hr. R. Meier
..............................
..............................
Partner A: Partner B:
Unterschrift: _____________________________
(Firmenstempel)
Unterschrift: _____________________________
(Firmenstempel)
Datum:
Zürich,
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 18-123

EANCOM-Handbuch
Data Interchange Agreement (DIA)
18.17.6 ANHANG 6 Uebertragungswiederholungen
Übertragungswiederholungen
Unterschrift:
Wenn Dokumente unvollständig oder überhaupt nicht beim Empfänger
eingetroffen sind oder wenn eine andere Störung vorliegt, kann es sein,
dass eine Übermittlung wiederholt werden muss. In diesem Falle wird
beim Absender das betroffene Dokument mit der gleichen Nachrichten
Referenznummer wie beim erstem Mal gesendet. Dies ermöglicht eine
lückenlose Numerierung der Uebermittlungen beim Empfänger und die
Kontrolle, ob die Dokumente genau einmal abgeschickt bzw. empfangen
wurden. Alle diesbezüglichen Fehlerfälle werden dokumentiert .
Partner A: Partner B:
Unterschrift: _____________________________
(Firmenstempel)
Unterschrift: _____________________________
(Firmenstempel)
Datum:
Zürich,
18.17.7 ANHANG 7 Message-Typ unabhängige Prüfungen
Die folgenden logischen, vom Message-Typ unabhängigen Prüfungen sind vom
Empfänger durchzuführen. Die Message-spezifischen Prüfungen sind in separaten
Anhängen beschrieben.
Testkennzeichen
Doppelt gesendet
Fehlende Nachrichten
Locationscodes
Die übermittelten Daten werden auf das Merkmal Test
oder Produktion untersucht und entsprechend behandelt
Es wird untersucht, ob die Nachrichten-
Referenznummer schon gesendet wurde.
Es wird untersucht, ob die Bestellnummer schon gesendet
wurde.
Es wird untersucht, ob die Positionsnummern doppelt
vorhanden sind.
Es wird geprüft, ob die Nachrichten-Referenznummer
lückenlos aufsteigend ist.
Es wird geprüft, ob die Positionsnummern innerhalb der
Detailzeilen lückenlos aufsteigend sind.
Es wird geprüft, ob die Informationen in den entsprechenden
Segmenten vorhanden sind.
Unterschrift:
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 18-124

EANCOM-Handbuch
Partner A: Partner B:
Data Interchange Agreement (DIA)
Unterschrift: _____________________________
(Firmenstempel)
Unterschrift: _____________________________
(Firmenstempel)
Datum:
Zürich,
18.17.8 ANHANG 8 Weitere Vereinbarungen
Weitere Vereinbarungen:
A. Terminliche Vereinbarungen
…..
…..
…..
B. Uebrige Vereinbarungen
…..
…..
…..
…..
…..
…..
…..
Unterschrift:
Partner A: Partner B:
Unterschrift: _____________________________
(Firmenstempel)
Unterschrift: _____________________________
(Firmenstempel)
Datum:
Zürich,
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 18-125

EANCOM-Handbuch
Checklisten
19 Checklisten
19.1 Aktivitätenliste Basiseinführung
No Tätigkeit Termin verantw.
Projektstart
Kick-Off Meeting
Präsentation Aufgaben und Tätigkeiten
Projektteam bestimmen
Projekt-Terminplan aufstellen
Analyse
Abklärung vorhandene Infrastruktur (HW/SW)
Auswahl des Clearinghouses
Abschluss der notwendigen Verträge
Bestellung der notwendigen HW/SW, Telecomeinrichtungen
Feststellen der EDI-Partnerinformationen
Feststellen der betroffenen Anwendungen und Abläufe
Überprüfung der Anwendung der EAN-Regeln
Feststellen von Besonderheiten in den Abläufen zwischen
EDI-Partner
Entscheid
Präsentation der Enablinganforderungen
Entscheid über Verwaltung der EAN-Nummern
Entscheid über organisatorische Änderungen
Entscheid über EDI-Abläufe
No Tätigkeit Termin verantw.
Realisierung
Definieren der neuen Geschäftsabläufe
Bereinigung des Artikelsortiments (EAN)
Definition der Inhouse-Files
Erstellen von Testdaten
Installation HW/SW
Anpassen der Konverter- und Übermittlungs-Software
Definition der neuen EDI-Anschlusses
technischer Test EP-Clearinghouse-EP
Erstellung Datenträger mit Artikeldaten für Sender
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 19-126

EANCOM-Handbuch
Checklisten
Erstellen des Testplans bis und mit Übergabe in die
Produktion
Durchführen der Tests
Einführung der betroffenen Stellen in die EDI-Abläufe
Technische Dokumentation
Übernahme in die Produktion
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 19-127

EANCOM-Handbuch
Adressen
20 Adressen
http://www.ean.ch/EANCOM/Adress.htm
Revision 10/9512/98 © EAN (Schweiz, Suisse, Svizzera) 20-128