-
VDA Datenfernübertragung von CAD/CAM Daten 4951
Part 2: VDA-ENGPART V4.1 P 2
Die unverbindliche VDA-Empfehlung 4951 beschreibt Absprachen
hinsichtlich Verfahren, Formaten und Inhalten von Dateien, die den
Austausch von CAD/CAM - Daten und der dazugehörenden
administrativen Informationen standardisieren und dadurch
zuverlässig und sicher machen.
Aufgrund der Vielzahl der Themen im Aufgabengebiet des
CAD/CAM-Datenaustausches ist die Empfehlung in einzelne
Teildokumente gegliedert, die sich jeweils einem Thema widmen,
teilweise aber auch aufeinander verweisen oder aufbauen. Die
Nummerierung der Teildokumente sagt nichts über den Zusammenhang
oder eine Priorität aus, sie ist lediglich historisch bedingt.
Dieser Teil: "Part 2: VDA-ENGPART V4.1" beschreibt das Format
zum Austausch der Information, die zur Einrichtung der
Kommunikationswege zwischen Endbenutzern notwendig ist.
Version 4.1 vom November 2009
ersetzt Version 2.2 vom Oktober 2005
Abteilung Logistik - Arbeitskreis "PLM"
Herausgeber: Verband der Automobilindustrie Copyright
Westendstraße 61 Nachdruck und jede sonstige Form Postfach 17 05
63 der Vervielfältigung ist nur mit
60079 Frankfurt Angabe der Quelle gestattet. Telefon
069/97507-284 Telefax 069/97507-300 Internet: www.vda.de
mailto:[email protected]
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 2 von
50
Copyright: VDA
Haftungsausschluss
Die VDA-Empfehlungen sind Empfehlungen, die jedermann frei zur
Anwendung stehen. Wer sie anwendet, hat für die richtige Anwendung
im konkreten Fall Sorge zu tragen. Sie berücksichtigen den zum
Zeitpunkt der jeweiligen Ausgabe herrschenden Stand der Technik.
Durch das Anwenden der VDA-Empfehlungen entzieht sich niemand der
Verantwortung für sein eigenes Handeln. Jeder handelt insoweit auf
eigene Gefahr. Eine Haftung des VDA und derjenigen, die an den
VDA-Empfehlungen beteiligt sind, ist ausgeschlossen. Jeder wird
gebeten, wenn er bei der Anwendung der VDA-Empfehlungen auf
Unrichtigkeiten oder die Möglichkeit einer unrichtigen Auslegung
stößt, dies dem VDA umgehend mitzuteilen, damit etwaige Mängel
beseitigt werden können.
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 3 von
50
Copyright: VDA
Inhaltsverzeichnis
1 Allgemein
......................................................................................................................
4
1.1 Anwendung
...........................................................................................................
4
1.2 Ziele der Empfehlung
............................................................................................
5
1.3 Änderungen gegenüber der Vorversion
................................................................
5
1.4 Kompatibilität zu Vorversionen
..............................................................................
6
1.5 Abkürzungen, Begriffe, Definitionen
......................................................................
7
2 Die ENGPART-Message
..............................................................................................
8
2.1 Zielsetzung
............................................................................................................
8
2.2 Inhalt und Struktur der ENGPART-Message
......................................................... 9
2.3 Varianten der ENGPART-Message
.....................................................................
12
2.4 Die Extensible Markup Language (XML) als Datenformat
................................... 13
2.5 Syntax-Beispiele der ENGPART-Message
......................................................... 14 2.5.1
Beispiel (A) einer kompletten/vollständigen ENGPART-Message
................ 14 2.5.2 Syntax-Beispiele für ENGPART-Updates
.................................................... 16
2.6 Verfahren
............................................................................................................
22 2.6.1 Übermittlung
.................................................................................................
22 2.6.2 Erzeugung und Empfang
.............................................................................
22 2.6.3 Automatische Verarbeitung
..........................................................................
23 2.6.4 Manuelle Verarbeitung
.................................................................................
24
Anhang A Inhalt der Partnerdaten
................................................................................
25
Anhang B XML-Schema (XSD) einer vollständigen ENGPART-Message
.................... 31
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 4 von
50
Copyright: VDA
1 Allgemein
1.1 Anwendung
Der Produktentstehungsprozess in der Automobil- und
Automobilzulieferindustrie ist wesentlich geprägt durch den Einsatz
moderner Informations- und Kommunikations-Technologien wie
Computer-Aided-Design- (CAD), Computer-Aided-Manufacturing-Systeme
sowie Produktdaten-Management-Systeme. Im Rahmen ausgedehnter
Kooperationspartnerschaften werden die Daten dieser Systeme meist
über weite Entfernungen zwischen den Kooperationspartnern
ausgetauscht.
Ein solcher Austausch erfolgt zunehmend über (öffentliche)
Netzwerke. Diese Art der Datenübertragung wird Datenfernübertragung
(DFÜ) genannt. Die Vorzüge von DFÜ sind der geringe Zeitverlust und
eine Automatisierung von Prozessen. Beides funktioniert aber nur
dann zuverlässig, wenn gemeinsam festgelegte Regeln eingehalten
werden.
Um dies zu ermöglichen werden in dieser Empfehlung Inhalt,
Struktur und Format einer maschinell lesbaren
Partner-Profilbeschreibung (Engineering-Partner-Data, kurz
„ENGPART“) definiert.
ENGPART Version 4.1 ist als Ergänzung zum geltenden
ENGDAT-Standard (Engineering-Data-Message) Version 3.1 der Exchange
and Management Group of Technical Data (XMTD) Work Group der
Stategic Automotive product data Standards Industry Group (SASIG)
zu betrachten.
Der ENGDAT-Standard definiert einen elektronischen Lieferschein,
die ENGDAT-Message, mit dessen Hilfe ein umfangreicher, weltweiter
Austausch technischer Daten zwischen Kooperationspartnern
automatisch abgewickelt und administriert werden kann.
Die durch eine ENGPART-Message ausgetauschten
Partnerinformationen werden dazu verwendet, die bei einem
Sendeauftrag zu generierende ENGDAT-Message mit korrekten
Informationen über beteiligte Kommunikationspartner zu
befüllen.
Diese Empfehlung stellt eine Ergänzung zu folgenden für den
CAD/CAM - Datenaustausch erarbeiteten Empfehlungen und Normen
dar:
Datenfernübertragung von ODETTE - Nachrichten (EDIFACT -
Nutzdatenrahmen) VDA 4900
File-Transfer-Protokoll (OFTP) VDA 4914/2
Vereinbarungen zum CAD/CAM Datenaustausch VDA 4950
Umfang und Qualität von CAD/CAM-Daten VDA 4955
Flächenschnittstelle VDAFS 1.0 / 2.0 DIN 66301
Regeln für den CAD - Datenaustausch VDMA / VDA 66318
VDAIS (IGES - Subset) VDMA / VDA 66319
EDIFACT - Syntax Regeln DIN ISO 9735
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 5 von
50
Copyright: VDA
1.2 Ziele der Empfehlung
Ziel der Empfehlung ist es den Einsatz der ENGPART - Datei als
verbindliches Verfahren beim CAD/CAM-Datenaustausch zu etablieren
und die Entwicklung dafür notwendiger Software zu fördern.
1.3 Änderungen gegenüber der Vorversion
Version Änderung Kapitel Seite
1 keine, es erfolgte lediglich die Aufteilung in
Teildokumente
2.0 Die ENGPART Version 4 stellt gegenüber den
Vorgängerversionen 1-3, d.h. der Dokumentversion 1 eine
signifikante Veränderung und Erweiterung dar.
Die wesentlichen Änderungen werden im Anschluss an diese Tabelle
aufgelistet.
Alle Alle
2.1 Schema und XML-Beispiele korrigiert 2.5
2.2 Neues Layout, Haftungsausschluss hinzugefügt Alle Alle
2.3 Update gemäß SASIG ENGPART V4.1 vom Dez. 2007 2.2 11
Datenformat: Die Veränderungen in ENGPART zwischen dieser
Version (4.*) und den vorhergehenden Versionen sind enorm. Diese
neue Version führt eine neue Implementierungsmethode ein: XML.
Daher ist es nicht praktikabel die Kompatibilität mit den
Vorgängerversionen der ENGPART zu fordern. Die folgenden Kommentare
sind daher eher informativ als kritisch bezüglich der
Interoperabilität. Falls Interoperabilität zu vorhergehenden
Versionen gefordert werden und Implementoren feststellen, dass ein
Mapping von V3 zu V4.* grundsätzlich möglich ist, aber in
umgekehrter Richtung viele Attribute kein Gegenstück finden.
ENGPART Version 3 war kompatibel zu den ENGDAT Versionen 1 und 2
verfasst. ENGPART Version 4 ist kompatibel zu ENGDAT Version 3, die
ebenso die neue Implementierungsmethode XML einführt und alle
EDIFACT Notationen eliminiert. ENGPART wurde darüberhinaus vom
Deutschen ins Englische übersetzt und, nach der Analyse von
Unstimmigkeiten mit ENGDAT, korrigiert. Schließlich wurde, auf
Basis der Version 4.1 der ENGPART, die ENGDAT Version 3.1 auf
Einflüsse zur ENGPART untersucht und notwendige Ergänzungen und
kleinere Änderungen vorgenommen.
Update-Mechanismus:
Mit Version 4 der ENGPART ist ein weitgehend beliebiger
Austausch von Teilumfängen der Partnerinformationen
(Partnerdaten-Deltas) möglich. Um dabei die Konsistenz und
Redundanzfreiheit der Partnerdatenbestände zu sichern, beinhaltet
Version (V) 4 einen Mechanismus, durch den sowohl die
Kommunikationspartner als auch ausgetauschte Partnerinformationen
einheitlich und zuverlässig mit Hilfe eindeutiger Kennungen
identifiziert werden können.
Zur Identifikation der Kommunikationspartner wird in ENGPART V4
die DUNS-Number (Dun & Bradstreet – Data Universal Numbering
System) genutzt. Dies ist eine weltweit eindeutige, kostenlose,
zentral verwaltete 9-stellige Nummer. Über diese Nummer kann jeder
Kommunikationspartner oder Organisationseinheit eines Partners
eindeutig
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 6 von
50
Copyright: VDA
identifiziert werden. Voraussetzung ist, dass die beteiligten
Partner diese Nummer beantragt haben.
Die Identifizierung eines Austauschpartners in ENGPART V4.1
wurde erweitert um nicht nur die DUNS-Nummer, sondern auch Nummern
anderer Identifizierungssysteme zu erlauben. Dennoch bleibt die
DUNS-Nummer das bevorzugte System. Das DUNS-Nummer-Feld wurde
umbenannt und vergrößert sowie ein neues Feld hinzugefügt um das
Nummerierungssystem anzugeben. Für DUNS lautet die
Identifizierungsnummer: 16.
Alle Informationsblöcke innerhalb einer ENGPART werden ebenfalls
durch eindeutige Identifier gekennzeichnet, für die der Erzeuger
einer ENGPART verantwortlich ist. Gliederung der
Informationsblöcke:
Zahlreiche Neuerungen wurden an der thematischen Gliederung der
ENGPART-Message gegenüber der Vorgängerversion vorgenommen. Dies
betrifft zum einen die Neugruppierung und Umbenennung einzelner
ENGPART-Abschnitte und zum anderen die Überarbeitung darin
enthaltener Informationen.
Die bisherige Reihenfolge der Einzelinformationen wurde
dahingehend geändert, dass zusammengehörende Datenelemente nun
sinngemäß zu abgeschlossenen ENGPART-Informationsblöcken
zusammengefasst werden. Damit wird für eine einfach verständliche,
realitätsnahe Abbildung von Organisationsstrukturen und der beim
Kooperationspartner angesiedelten IuK-technischen Infrastruktur
gesorgt.
In der ENGPART V4 wurde darauf verzichtet, der „Information über
Empfänger“ wie bisher ein eigenes Kapitel zu reservieren. Außerdem
sind nun im ENGPART-Abschnitt „Information über Kommunikation“
ENGPART-Informationsblöcke zu den Themen
Odette-File-Transfer-Protokoll (OFTP), File-Transfer-Protokoll
(FTP) und Offline-Medium vorgesehen. Das Kapitel
„Nutzdatenspezifische Informationen“ wurde in die
ENGPART-Abschnitte „Information über Austauschformat“ und
„Information über Systeme“ untergliedert, um jede Art Daten
verarbeitender IuK-Systeme sowie beliebige Formate zu beschreiben.
Ein Kapitel „ENDE ENGPART“ wird nicht unterstützt. Feldinhalte:
Die Überarbeitung der in ENGPART enthaltenen Einzelinformationen
betrifft vor allem bisher wenig genutzte oder veraltete
Datenelemente. Sie wurden aus dem ENGPART-Umfang entfernt.
Andererseits wurde die ENGPART durch neue, notwendig gewordene
Datenelemente ergänzt.
1.4 Kompatibilität zu Vorversionen
Mit Veröffentlichung dieser Version wird empfohlen, auch die
vorherige Version sowohl als Sender als auch als Empfänger zu
unterstützen.
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 7 von
50
Copyright: VDA
1.5 Abkürzungen, Begriffe, Definitionen
Abstract-Datei
Die Abstract-Datei enthält die entsprechend der
ENGDAT-Definition (siehe VDA4951/1) für die Zustellung und
Verarbeitung eines ENGDAT-Paketes notwendigen Informationen.
ENGDAT-Paket
Unter ENGDAT-Paket wird die Gesamtheit der Dateien verstanden,
die entsprechend der ENGDAT-Definition (siehe VDA4951/1) versendet
werden, also die Abstract-Datei sowie alle über die
Namenskonvention zum Paket assoziierten Nutzdateien.
ENGPART-Message
Die ENGPART-Message ist sowohl eine maschinell als auch für
Menschen einfach lesbare Partner-Profilbeschreibung, die den
vollständigen Umfang oder einen Teilumfang aller für den
Nutzdatenaustausch notwendigen Partnerinformationen beinhaltet.
ENGPART-Abschnitte
Die in einer ENGPART-Message enthaltenen Partnerinformationen
werden themenspezifisch in so genannte ENGPART-Abschnitte
untergliedert. Ähnlich wie ein Kapitel, enthält jeder
ENGPART-Abschnitt Informationen zu einem bestimmten Themenbereich
der Partnerinformationen wie z. B. Information über Sender oder
Information über Austauschformate.
ENGPART-Informationsblöcke
ENGPART-Informationsblöcke bündeln innerhalb von
ENGPART-Abschnitten zusammengehörende Informationen. So sind
beispielsweise im ENGPART-Abschnitt "Information über
Austauschformate" alle Daten eines bestimmten Austauschformats zu
einem ENGPART-Informationsblock zusammengefasst.
ENGPART-Einzelinformationen
ENGPART-Einzelinformationen beschreiben einzelne, in der
ENGPART-Message enthaltene Partnerinformationen. Diese werden zu
Informationsblöcken zusammengefasst. Jede ENGPART-Einzelinformation
setzt sich zusammen aus einem XML-Datenelementbezeichner (TAG) und
dem Datenelement selbst, welches die eigentliche Partnerinformation
repräsentiert.
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 8 von
50
Copyright: VDA
2 Die ENGPART-Message
2.1 Zielsetzung
Der vermehrte Einsatz des elektronischen Datenaustausches hatte
zur Folge, dass der Austausch von Informationen zur Einrichtung und
Pflege der administrativen Daten für die Datenaustauschbeziehungen
manuell und damit zeitintensiv über Fax oder Telefon zwischen den
unterschiedlichsten Stellen und Abteilungen der beteiligten Firmen
erfolgte. Dieser Umstand war der Anstoß dafür, Inhalt und Format
einer Datei zu definieren, mit der diese Informationen
automatisiert übertragen werden können.
Ziel ist, den mündlichen oder schriftlichen Austausch von
Information zur Einrichtung oder auch Veränderung neuer oder
bestehender Partner-Beziehungen zu ersetzen. Unter Partnern sind
dabei jeweils die Personen oder Stellen zu verstehen, die den
Austausch von Daten anstoßen. Nur zur Einrichtung einer ersten
DFÜ-Verbindung wird evtl. Telefon, Fax oder E-Mail benötigt.
Unternehmen A
Informationssystem
Unternehmen B
Informationssystem
Kommunikationsmedium
ENGPART-Message
Administrative Informationen
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 9 von
50
Copyright: VDA
2.2 Inhalt und Struktur der ENGPART-Message
Inhalt der ENGPART-Message
In einer ENGPART-Message teilt eine Firma/Firmenguppe jeweils
einer anderen Firma/Firmenguppe folgende Informationen mit:
In den Datenaustausch involvierte Organisationseinheiten
(Abteilungen, Personen)
Für die Übertragung sowie die Weiterverarbeitung von
Informationen notwendige Parameter der IuK-Infrastruktur
verschiedener Firmenstandorte
Endbenutzer der entsprechenden Standorte, die jeweils Daten von
der betreffenden Partnerfirma erhalten dürfen
Diese Informationen stehen größtenteils in Relation zu
entsprechenden Informationen in der ENGDAT-Message.
Mit diesem bilateralen Austausch von Informationen wird
sichergestellt, dass jeweils nur die für einen bestimmten Partner
relevanten Informationen in einer Datei enthalten sind und somit
nicht ungewollt Informationen an Unbefugte übermittelt werden. Für
die Einhaltung dieser Regelung ist jeweils der Sender der
ENGPART-Message verantwortlich.
Das Verfahren der Erstellung kann jeder Sender selbst wählen
(Editor, selbst geschriebene Programme, Software im Rahmen von
EDI-Systemen...), wesentlich ist die Einhaltung des in dieser
Empfehlung definierten neutralen Formates der ENGPART-Message.
Durch den Einsatz von XML als Datenformat ist eine unkomplizierte
manuelle Erstellung sowie Auswertung einer ENGPART-Message
möglich.
Struktur der ENGPART-Message
Durch eine gezielte Modellierung des XML-Datenformates ist es
möglich, die in einer ENGPART-Message enthaltenen
Partnerinformationen klar zu strukturieren. Alle
Partnerinformationen werden themenbereichsspezifisch in so genannte
ENGPART-Abschnitte (z. B. Sender Company Details) untergliedert.
Zusammengehörende Einzelinformationen werden darin außerdem zu
ENGPART-Informationsblöcken zusammengefasst, die einmal oder
mehrmals je ENGPART-Abschnitt vorkommen können (z. B. Company
Site).
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 10 von
50
Copyright: VDA
ENGPART-Message
Message Identifier (Status der Austauschdaten)
Sender Company Details (Information über Sender)
Sender Communication System (Information über Kommunikation)
Exchange File Format (Information über Austauschformat)
Exchange File Generating System (Information über Systeme)
Receiver Company Details
Company Site
Company Contact
Communication System OFTP
Communikation System Offline
File Format
Generating System
Destination Address
Sender Destination Address (Zieladressen)
ENGPART-Abschnitt ENGPART-Informationsblock aus
Einzelinformationen
Communication System FTP
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 11 von
50
Copyright: VDA
Identifikation von Kommunikationspartnern und
Partnerinformationen
Zur Identifikation der Kommunikationspartner wird die durch das
Projekt Unique Partner Identifikation Key (UPIK) des VDA
überarbeitete Dun&Bradstreet DUNS-Number favorisiert, aber
Identifikatoren anderer Systeme sind ebenso zulässig. Damit ist
sichergestellt, dass die durch die ENGPART-Message ausgetauschten
Informationen innerhalb der Partnerdatenbanken den beteiligten
Kooperationspartnern korrekt zugeordnet werden können.
Durch Verwendung des XML-Datenformates ist es außerdem möglich,
ein erheblich vereinfachtes System eindeutiger Kennungen zur
Identifikation der Partnerinformationen zu verwenden.
So besitzt jeder in den ENGPART-Abschnitten enthaltene
ENGPART-Informationsblock einen firmenweit eindeutigen Identifier.
Die hierarchische Struktur des XML-Datenformates sowie die
eindeutigen und aussagekräftigen XML-Datenelementbezeichner (Tags)
der ENGPART-Einzelinformationen erlauben eine eindeutige und klare
Identifikation aller enthaltenen Partnerinformationen ohne den
Einsatz weiterer Kennungen.
Standort A
Standort B
ID
ID
ID
Datenelement
…
Ansprechpartner 1
Weltweit eindeutige FirmenID DUNS-Nr. (oder äquivalent)
Informationsblöcke
CompanySite
Company Contact
Mustermann Heinz
…
…
Bsp-Einzelinformationen
von
ID Ansprechpartner 2
Ansprechpartner 1
ENGPART-Abschnitt SenderCompanyDetails
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 12 von
50
Copyright: VDA
2.3 Varianten der ENGPART-Message
Grundsätzlich können Partnerinformationen mit Hilfe zweier
unterschiedlicher ENGPART-Varianten ausgetauscht werden. Dies sind
eine komplette/vollständige ENGPART-Message, die den gesamten
Informationsumfang einer Partnerbeziehung beschreibt, oder ein
ENGPART-Update, das nur einen Teilumfang aller Partnerinformationen
enthält. Komplette/vollständige ENGPART-Message
Eine komplette/vollständige ENGPART-Message enthält
grundsätzlich alle ENGPART-Abschnitte und darin jeweils mindestens
einen ENGPART-Informationsblock. Neben einem gewissen Mindestumfang
administrativer Informationen müssen alle als obligatorisch
definierten Einzelinformation sowie evtl. alle als optional
definierten Einzelinformationen in einer kompletten/vollständigen
ENGPART-Message enthalten sein.
Die komplette/vollständige ENGPART-Message eignet sich damit
besonders für den initialen Informationsaustausch zu Beginn einer
Partnerbeziehung. Beim Einpflegen einer kompletten/vollständigen
ENGPART-Message wird das Prinzip der Fortschreibung von
Informationen in den Partnerdatenbanken nicht eingehalten. So kann
mit dem Austausch einer kompletten/vollständigen ENGPART-Message
ein Informationsreset einer Kommunikationsbeziehung durchgeführt
werden, indem alle bisher vorhandenen Informationen eines Partners
aus der Datenbank gelöscht werden und durch die in der
ENGPART-Message enthaltenen ersetzt werden. Damit wird
sichergestellt, dass die Informationen in den Systemen der
Kommunikationspartner im Laufe der Zeit nicht divergieren.
ENGPART-Update
Das ENGPART-Update dagegen dient dem gezielten Austausch
bestimmter Teilumfänge von Partnerinformationen. Neben dem
Mindestumfang an Informationen, die jede ENGPART-Message aus
administrativen Gründen enthalten muss, kann es sich dabei entweder
um vollständige ENGPART-Informationsblöcke handeln und/oder nur um
bestimmte obligatorische bzw. optionale Einzelinformationen.
Das ENGPART-Update sieht folgende Modifizierungsmöglichkeiten
der Partnerinformationen in der Datenbank des ENGPART-Empfängers
vor:
Neuanlage vollständiger Informationsblöcke oder
Einzelinformationen
Löschung vollständiger Informationsblöcke und/oder
Einzelinformationen
Editieren/Überschreiben von Informationsblöcken und/oder
Einzelinformationen
Das Löschen von obligatorischen Informationsblöcken ist nicht
erlaubt, ebenso wenig das Löschen obligatorischer
Einzelinformationen.
Von einer Modifikation ausgeschlossen sind alle
identifizierenden Datenelemente. Das heißt zwar, dass im Rahmen
eines Updates identifizierende Datenelemente verschwinden können
(Löschen von Informationsblöcken; Beispiel B.2.b) oder hinzugefügt
werden können (Einfügen / Neu anlegen von Informationsblöcken;
Beispiel B.1). Ein vorhandener Informationsblock darf aber während
seiner "Lebensdauer" seine Identität nicht verändern.
Besondere Sorgfalt erfordert die Veränderung von Referenzen. Ein
Update wie bei Einzelinformationen ist hier nicht möglich, da sie
nicht eindeutig identifizierbar sind. Um eine Referenz zu
modifizieren, zu löschen oder hinzuzufügen muss immer der gesamte
Block an Referenzen übermittelt werden, in dem die zu verändernde
Referenz auftritt. Zusätzlich hat der Erzeuger darauf zu achten,
dass die beim Empfänger nach einem Update vorliegende
Gesamtinformation in sich konsistent und aktuell ist.
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 13 von
50
Copyright: VDA
Grundsätzlich ist der Sender der Partnerdaten jeweils für den
aktuellen Stand seiner Informationen verantwortlich, d. h. bei
Änderungen seines eigenen Datenbestandes ist jeweils der neue Stand
an die von den Änderungen betroffenen Partnerfirmen zu
versenden.
2.4 Die Extensible Markup Language (XML) als Datenformat
Die ENGPART-Message ist im XML-Format codiert. Mit Hilfe einer
gezielten Modellierung des XML-Layouts ist es möglich, die in einer
ENGPART-Message enthalten Partnerinformationen eindeutig, für den
Menschen direkt lesbar und hierarchisch zu strukturieren.
XML-Schema-Definitionssprache
Zur Definition des XML-Layouts der ENGPART-Message wird die
XML-Schema-Definitionssprache verwendet.
Im Rahmen des XML-Schemas sind die in der ENGPART-Message
enthaltenen Einzelinformationen global als einfache Datentypen
definiert. Deren Wertebereich, Länge und Format wird aus
bestehenden, vordefinierten, einfachen Datentypen abgeleitet oder
auf eine definierte Menge zugelassener Werte beschränkt.
Sowohl die Informationsblöcke einer ENGPART-Message als auch die
ENGPART-Abschnitte werden jeweils durch global definierte, komplexe
Typen im XML-Schema repräsentiert. Die darin aufgeführten
Elementdeklarationen und –referenzen bilden die Struktur der
ENGPART-Message im XML-Format ab. So kann die Häufigkeit des
Vorkommens sowie die Reihenfolge der enthaltenen
Einzelinformationen festgelegt werden, ebenso wie die Häufigkeit
und Reihenfolge der ENGPART-Abschnitte und der Informationsblöcke
selbst. Der Einsatz abstrakter Typen/Elemente erzwingt an
geeigneter Stelle die Verwendung von Ersatzgruppen. Auf die
Verwendung von Attributen wurde beim Layout des XML-Formates
verzichtet.
Sprach-/Namenskonventionen
Die Bezeichnungen aller XML-Elemente und –Typen leiten sich ab
vom Datenelementbezeichner der jeweiligen Partnerinformation. Jedes
komplexe ENGPART-Element erhält bei seiner Definition die
Erweiterung „type“.
Falls sich der Titel aus mehreren Wörtern zusammensetzt,
entfallen die Leerzeichen und jedes neue Wort beginnt mit einem
Großbuchstaben.
Daten-Typen von Aufzählungs-Listen (enumeration data types)
erhalten die Erweiterung „…“.
Einfache Datentypen mit Längenbeschränkungen werden
folgendermaßen beschrieben:
Datentyp String mit bis zu n Zeichen: String..n
Datentyp String mit einer Länge von m bis n Zeichen: String
m..n
Datentyp String mit genau n Zeichen: String n
Entsprechend wird auch die Anzahl der Zeichen für die Datentypen
Integer und Dezimal festgelegt.
Wird das Abstraktionsprinzip im XML-Schema verwendet, wird die
Bezeichnung des Elementes durch eine weitere „type“-Erweiterung
ergänzt.
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 14 von
50
Copyright: VDA
Entsprechend der ODETTE XML Work group lautet die Bezeichnung
des allgemeinen Einsprungpunktes des XML-Schemas „Electronic
Document Type“. Daraus wird als Instanz das ENGPART-Dokument
abgeleitet.
XML-Syntax
Die ENGPART-Message verwendet den Zeichensatz UTF-8. Die
XML-Syntax sieht vor, jedem Datenelement öffnende und schließende
Tags zuzuordnen.
ENGPART-Abschnitte, die einen oder mehrere
ENGPART-Informationsblöcke enthalten können, werden mit
umschließenden Tags gegeneinander abgegrenzt.
ENGPART-Informationsblöcke mit zusammengehörenden
Partnerinfor-mationen werden außerdem durch umschließende Tags
zusammengefasst.
2.5 Syntax-Beispiele der ENGPART-Message
2.5.1 Beispiel (A) einer kompletten/vollständigen
ENGPART-Message
(Beispiel ohne XML-Schema-Referenz)
004 00 031230145959 ISO 10646 DE 90-231-1224 Empfängerfirma
67-293-1928 Senderfirma ...
Der durch den inneren Rahmen markierte Bereich stellt den
Mindestumfang an Informationen der ENGPART-Message dar. Dabei
handelt es sich vor allem um administrative Daten der
Kommunikationspartner.
Im Anschluss folgen alle für eine komplette/vollständige ENGPART
als obligatorisch definierten Partnerinformationen sowie zur
einfacheren Lesbarkeit einige optionale Partnerinformationen.
Min
de
stu
mfa
ng
an
EN
GP
AR
T-In
form
atio
nen
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 15 von
50
Copyright: VDA
Sind in einem ENGPART-Informationsblock lediglich optionale
Referenz-Einzelinformationen vorgesehen (vgl. CompanySite), und
diese werden nicht genutzt, brauchen auch die
„Reference“-Datenelementbezeichner nicht verwendet zu werden.
… CompanySite_ID_1 Standort Eins Beispielstr. 1 Beispielstadt DE
003.1 Format_ID_1 System_ID_1 OFTP_ID_1 Contact_ID_1
Destination_ID_1 OFTP_ID_1 TCP/IP O0013000011SEND311
O0013000011SEND311 196.145.200.1 3305 CompanySite_ID_1 Format_ID_1
STEP AP 214 …
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 16 von
50
Copyright: VDA
… System_ID_1 CATIA RS 6000 Format_ID_1 Destination_ID_1
Mustermann +497031-555-55 [email protected]
adr.code_muster CompanySite_ID_1
2.5.2 Syntax-Beispiele für ENGPART-Updates
Mit Hilfe eines ENGPART-Updates ist es möglich, die
Partnerinformationen in der Datenbank des ENGPART-Empfängers auf
unterschiedliche Weise zu modifizieren. Die jeweilige Art der
Modifikation der Partnerdaten in der Datenbank des
ENGPART-Empfängers ist bestimmend für die Syntax der
ENGPART-Message.
Das nachfolgende Schema gliedert die möglichen Alternativen:
Funktion des
ENGPART-Updates Betroffener Informationsumfang
Einzelinformationen Informationsblöcke
Neuanlage - Beispiel B.1
Löschung Beispiel B.2a Beispiel B.2b
Editierung/Überschreiben Beispiel B.3
Das Datenelement mit dem Bezeichner „UpdateMode“ legt in der
ENGPART-Message mit dem Wert 01 fest, dass es sich um ein
ENGPART-Update handelt. Auch das ENGPART-Update muss die als
Mindestumfang definierten Informationen enthalten.
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 17 von
50
Copyright: VDA
004 01 031111143000 ISO 10646 DE 90-231-1224 Empfängerfirma
67-293-1928 Senderfirma …
Der ENGPART-Abschnitt Sender Company Details schließt lediglich
die Informationen über Name und DUNS-Number (oder äquivalenter,
eindeutiger Nicht-DUNS-Identifikator) des Senders ein, es sei denn,
es sind Modifikationen an den ENGPART-Informationsblöcken Company
Site und Company Contact vorgesehen.
Alle Update-Informationen werden sowohl von den Tags des
betroffenen ENGPART-Abschnitts umschlossen als auch von denen des
ENGPART-Informationsblockes, in dem die Partnerinformationen
modifiziert werden sollen. Um den Informationsblock eindeutig
identifizieren zu können, muss ebenfalls dessen firmenweit
eindeutiger Identifier immer enthalten sein.
Min
de
stu
mfa
ng
an
EN
GP
AR
T-In
form
atio
nen
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 18 von
50
Copyright: VDA
2.5.2.1 Beispiel (B.1) Neuanlage von Informationsblöcken
(Beispiel ohne XML-Schema-Referenz)
Die in der Partnerdatenbank des ENGPART-Empfängers bestehenden
Informationsblöcke werden durch neue ergänzt, indem die eindeutigen
Identifier der neuen Informationsblöcke zusammen mit allen
dazugehörigen Einzelinformationen an den Empfänger der ENGPART
geschickt werden.
Alle als obligatorisch definierten Einzelinformationen müssen im
entsprechenden ENGPART-Abschnitt enthalten sein.
004 01 031111143000 ISO 10646 DE 90-231-1224 Empfängerfirma
67-293-1928 Senderfirma Destination_ID_1 Mustermann
+497031-555-55 [email protected] adr.code_muste
CompanySite_ID_1
Die Zieladresse mit der ID „Destination_ID_1“ ist in der
Partnerdatenbank des ENGPART-Empfängers noch nicht enthalten und
wird dort, mit allen dazugehörigen Einzelinformationen, neu
angelegt.
Up
da
te-In
form
atio
nen
Min
de
stu
mfa
ng
an
EN
GP
AR
T-In
form
atio
nen
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 19 von
50
Copyright: VDA
2.5.2.2 Beispiel (B.2.a) Löschung von Einzelinformationen
(Beispiel ohne XML-Schema-Referenz)
Die in der Partnerdatenbank des ENGPART-Empfängers bestehenden
Einzelinformationen werden gelöscht, indem die eindeutigen
Identifier der Informationsblöcke versandt werden, in denen die
betroffenen Informationen enthalten sind.
Hinzu kommen lediglich die Datenelementbezeichner (Tags) der zu
löschenden Einzelinformationen ohne die dazugehörigen Datenelemente
selbst. Grundsätzlich ist keine Löschung obligatorischer
Datenelemente erlaubt.
004 01 031111143000 ISO 10646 DE 90-231-1224 Empfängerfirma
67-293-1928 Senderfirma Destination_ID_1 Mustermann
+497031-555-55 [email protected] adr.code_muste
CompanySite_ID_1
Das optionale Datenelement mit dem Datenelementbezeichner
„FaxNumber“ ist in der Partnerdatenbank des Empfängers im
Zieladressinformationsblock „Destination_ID_1“ vorhanden und soll
dort gelöscht werden.
Up
da
te-
Info
rma
tion
en
Min
des
tum
fan
g
an
EN
GP
AR
T-In
form
atio
nen
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 20 von
50
Copyright: VDA
2.5.2.3 Beispiel (B.2.b) Löschung von Informationsblöcken
(Beispiel ohne XML-Schema-Referenz)
Die in der Partnerdatenbank des ENGPART-Empfängers bestehenden
Informationsblöcke werden gelöscht, indem die Identifier der zu
löschenden Informationsblöcke mit „leeren“ obligatorischen
Einzelinformationen gesendet werden.
004 01 031111143000 ISO 10646 DE 90-231-1224 Empfängerfirma
67-293-1928 Senderfirma Destination_ID_1
Der Zieladressinformationsblock mit dem Identifier
„Destination_ID_1“ ist in der Partnerdatenbank des
ENGPART-Empfängers vorhanden und soll dort vollständig gelöscht
werden.
Min
de
stu
mfa
ng
an
EN
GP
AR
T-In
form
atio
nen
Up
da
te-
Info
rma
tion
en
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 21 von
50
Copyright: VDA
2.5.2.4 Beispiel (B.3) Editieren/Überschreiben von
Einzelinformation oder Informationsblöcken (Beispiel ohne
XML-Schema-Referenz)
Die in der Partnerdatenbank des ENGPART-Empfängers bestehenden
Einzelinformationen oder Informationsblöcke werden editiert bzw.
überschrieben, indem die eindeutigen Identifier der
Informationsblöcke gesendet werden, denen die Einzelinformationen
zugeordnet sind.
Hinzu kommen die neuen, editierten Einzelinformationen selbst,
bestehend aus Datenelementbezeichner (Tags) und den neuen
Datenelementen, die anstelle der alten eingepflegt werden.
004 01 031111143000 ISO 10646 DE 90-231-1224 Empfängerfirma
67-293-1928 Senderfirma Destination_ID_1 Mustermann
+497031-555-56 [email protected] adr.code_muste
CompanySite_ID_1
Das Datenelement mit dem Datenelementbezeichner „PhoneNumber“
ist in der Partnerdatenbank des ENGPART-Empfängers im
Zieladressinformationsblock mit dem Identifier „Destination_ID_1“
enthalten und wird durch das in der ENGPART-Message enthaltene
Datenelement überschrieben.
Min
de
stu
mfa
ng
an
EN
GP
AR
T-In
form
atio
nen
Up
da
te-
Info
rma
tion
en
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 22 von
50
Copyright: VDA
2.6 Verfahren
2.6.1 Übermittlung
Der Normalfall für die Übermittlung ist die Nutzung eines
ENGDAT-Paketes. In diesem Fall wird ein ENGDAT-Paket der
Conformance Class 2/3 (s. ENGDAT V3.*) erzeugt, zu dem als
Nutzdaten-Datei eine ENGPART-Message assoziiert ist. Zur
Kennzeichnung, dass es sich bei den übermittelten Nutzdaten um
ENGPART-Daten handelt, wird in der ENGDAT-Message im EFC-Segment
das Datenelement Exchanged File Purpose mit dem Wert ENGPART
belegt. In allen anderen Fällen muss die Vorgehensweise, wie die
Informationen zu übermitteln sind, jeweils bilateral vereinbart
werden. Es wird in dieser Empfehlung davon ausgegangen, dass für
die Übertragung der Informationen Datenleitungen verwendet werden.
Auch hier können andere Übermittlungswege vereinbart werden.
2.6.2 Erzeugung und Empfang
ENGPART- Message
Partner-Datenbank
ENGDAT-
Generator
ENGDAT-Paket
ENGDAT Message
ENGPART- Message
Erstellung eines ENGDAT-Paketes
ENGPART-
Generator Erstellung der
ENGPART-Message
Partnerinformationen
Erzeugung der ENGPART-Message bei der Senderfirma
Versand
ENGPART- Message
Partner-Datenbank
ENGPART-
Interpreter
ENGDAT-Paket
ENGDAT Message
ENGPART- Message
ENGDAT-
Interpreter Isolierung der ENGPART
Einpflegen der ENGPART- Informationen Auswertung des ENGDAT-
Paketes
Empfang
Empfang der ENGPART-Message bei der Empfängerfirma
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 23 von
50
Copyright: VDA
2.6.3 Automatische Verarbeitung
Durch die formale Struktur der ENGPART-Message können die darin
enthaltenen Informationen automatisch in die proprietären
EDI-Systeme des Empfängers übernommen werden. Der Ablauf der
automatischen Verarbeitung beim Empfang einer ENGPART-Message hängt
wesentlich davon ab, ob es sich um eine komplette/vollständige
ENGPART-Message handelt oder um ein ENGPART-Update.
Bei einer kompletten/vollständigen ENGPART wird der gesamte
Umfang an Informationen einer speziellen Partnerbeziehung aus der
Partnerdatenbank des ENGPART-Empfängers gelöscht. Anschließend
werden die in der empfangenen ENGPART-Message enthaltenen
Partnerinformationen dort neu eingepflegt.
Da durch ein ENGPART-Update die Partnerinformationen auf
unterschiedliche Weise modifiziert werden können, muss beim Empfang
des ENGPART-Updates ausgewertet werden, um welche Art der
Modifikation es sich dabei handelt. Anschließend werden der
XML-Syntax entsprechend die Änderungen der Partnerinformationen in
der Datenbank des ENGPART-Empfängers vorgenommen.
ENGPART-Update
Mindestumfang an Infos
ID 2 Zieladresse b
Informationsblock
Handelt es sich um ein
ENGPART-Update? Nein Ja
Informationsblock ID 2 vollständig
löschen
Identifikation der Update-
Informationen anhand der IDs
Ist der in der ENGPART ent-haltene Informationsblock auch in der
Partnerdatenbank
des Empfängers vorhanden?
Identifikation des Senders
anhand seiner DUNS-Nr.
Ja
Nein
Sind im Informations-block ID 2 Einzelinformationen
enthalten?
Ja Nein
Ja
Nein
Bestehen die Einzelinformationen aus Datenelement-bezeichner
(Tag)
und Datenelement?
Informationsblock
ID 2 neu anlegen
Einzelinformation löschen
Einzelinformationen im Informationsblock ID 2 in der
Partnerdatenbank durch die aus der ENGPART überschreiben
Alle Informationen für diesen Partner neu einpflegen;
Vorhandene
löschen
Zieladresse a ID 1
Partnerdatenbank des
Empfängers Informationsblock
- Zieladressen-
Einzelinfo zu Zieladr. a
Zieladresse b ID 2
Einzelinfo zu Zieladr. b
Zieladresse b ID 2
Einzelinfo zu Zieladr. b
Zieladresse b ID 2
Einzelinfo zu Zieladr. b
Zieladresse b ID 2
Einzelinfo zu Zieladr. b
Bsp. A
Bsp. B.1
Bsp. B.2.a
Bsp. B.2.b
Bsp. B.3
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 24 von
50
Copyright: VDA
2.6.4 Manuelle Verarbeitung
Die formale Struktur der ENGPART-Message sowie die einfache
Lesbarkeit durch den Einsatz von XML erlauben neben einer
automatisierten, maschinellen Verarbeitung eine manuelle Erstellung
und Auswertung.
Hinzu kommt die Unterstützung des XML-Formates durch XML-fähige
Standard-Browser. Damit ist es möglich, sowohl die XML-codierte
ENGPART-Message korrekt abzubilden als auch unter Verwendung von
Stylesheets Informationen selektiv aus einer ENGPART-Message in
HTML darzustellen.
ENGPART-
Message
Stylesheet HTML-Darstellung im Standard-Browser
Verknüpfung über URL
Manuelle Auswertung einer ENGPART-Message
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 25 von
50
Copyright: VDA
Anhang A Inhalt der Partnerdaten
VDA ENGPART Version 4 Standard
EN
GP
AR
T-A
bsch
nit
te
Info
rmati
on
sb
löck
e/
Un
tera
bs
ch
nit
te
Date
nele
men
t-N
um
mer
Datenelement-bezeichnung
XML-Tag (Datenelement-
bezeichner) Sta
tus
Fo
rmat
Datenelement- beschreibung
Beispiel- daten-
element
Mess
ag
e Id
en
tifi
er
(Sta
tus d
er
Au
sta
us
ch
date
n)
1 ENGPART-Version m x..5 004.1
2 Update-Modus m n2 00: vollständige ENGPART; 01:
ENGPART-Update
00
3 Datum/Zeit m n12 Format 'JJMMTThhmmss', CET bzw. CEST
031212135534
4 Zeichensatz m an..25 ISO 10646, alternativ ISO 6947/2-1983 od.
ISO-2022
ISO 10646
5 Sprachversion m a2 Laut ISO 639: 2002 DE
Receiv
er
Co
mp
an
y D
eta
ils
6 Eindeutiger Empfänger-Firmen-Schlüssel
m x..5
Identifikator der Firma oder Organisation die das System
verwaltet oder wartet aus dem der folgende Identifikator erzeugt
wurde
16
7 Eindeutige Empfängerfirmen-ID
< CompanyInternalIDNumber >
m x..50
Dun&Bradstreet DUNS-Nummer (oder äquivalenter, eindeutiger
Nicht-DUNS-Identifikator) der ENGPART-Empfängerfirma
90-231-1224
8 Firmenname Empfänger
m x..100 Name der Empfängerfirma der ENGPART
Empfänger-firma
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 26 von
50
Copyright: VDA
9 Eindeutiger Empfänger-Firmen-Schlüssel
< CompanyInternalIDCode >
m x..5
Identifikator der Firma oder Organisation die das System
verwaltet oder wartet aus dem der folgende Identifikator erzeugt
wurde
16
10 Weltweit eindeutige Firmen-ID (DUNS-Nummer)
< CompanyInternalIDNumber >
m x..50
Dun&Bradstreet DUNS-Nummer (oder äquivalenter, eindeutiger
Nicht-DUNS-Identifikator) der ENGPART-Sender- firma
67-293-1928
11 Firmenname m x..100 Name der Senderfirma der ENGPART
Senderfirma
ENGPART-MINDESTUMFANG
Sen
de
r C
om
pan
y D
eti
ls
(In
form
ati
on
üb
er
Sen
de
r)
Co
mp
an
y S
ite
1 Firmenweit eindeutige Standort-ID
m x..100
Beliebige Kennung zur Identifikation eines Standortes, ggf.
Standort-DUNS
CompanySite_ID_1
2 Name Standort m x..100 Standort Eins
3 Straße m x..50 Straßenname Beispielstr.
4 Nummer k x..25 Hausnummer 1
5 Ort m a..50 Beispielstadt
6 Bundesland / State k x..50 Hessen
7 Ländercode m a2 Codierte Form laut ISO 3166-1
DE
8 Postleitzahl (Ort) k x..25 99999
9 Kommentar k x..50 Adresszusätze Gewerbepark
10 Funktion k x..35 Funktion des ENGPART-Senders
Sender
11 ENGDAT-Versionen m x..5 Angabe der unterstützten
ENGDAT-Versionen
003.1
12 Kompression k x..25 mehrere möglich gzip
13 Verschlüsselung k x..50 mehrere möglich none
k
Refe
re
nce
11 Referenz zu Austauschformat
k x..100 Format_ID_1
12 Referenz zu Systeme
k x..100 System_ID_1
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 27 von
50
Copyright: VDA
13 Referenz zu Kommunikations- medium OFTP
k x..100 OFTP_ID_1
14 Referenz zu Kommunikations- medium FTP
k x..100 FTP_ID_1
15 Referenz zu Kommunikations- medium Offline
k x..100 Offline_ID_1
Co
mp
an
y C
on
tact
1 Firmenweit eindeutige Ansprechpartner-ID
m x..100 Beliebige Kennung zur Identifikation eines
Ansprechpartners
Contact_ID_1
Refe
rence
m
2 Referenz zu Zieladresse
m x..100 Destination_ID_1
3 Referenz zu Werk/Standort
k x..100 CompanySite_ID_1
Sen
de
r C
om
mu
nic
ati
on
Syste
m (
Info
rmati
on
üb
er
Ko
mm
un
ikati
on
)
Co
mm
un
icati
on
Syste
m O
FT
P
1 Firmenweit eindeutige OFTP-System-ID
m x..100 Beliebige Kennung zur Identifikation eines
OFTP-Systems
OFTP_ID_1
2 Verbindungsart
m x..6 DSS1 oder TCP/IP TCP/IP
3 ODETTE-Kennung: SSIDCODE
m x..25 O0013000011 SEND311
4 ODETTE-Kennung: SFIDDEST
m x..25 O0013000011 SEND311
5 DFÜ-Rufnummer (m) n..25 alternativ zu 6 07303155511
6 OFTP-Server-IP-Adresse (numerisch)
(m) x..15 alternativ zu 5
196.145.200.1
7 IP - Port Nummer k n..5 Default-Port 3305 wenn keiner
angegeben
1976
Refe
ren
ce
m
8 Referenz zu Werk/Standort
m x..100 CompanySite_ID_1
Co
mm
un
icati
on
Syste
m F
TP
1 Firmenweit eindeutige FTP-System-ID
m x..100 Beliebige Kennung zur Identifikation eines
FTP-Systems
FTP_ID_1
2 FTP-Server-IP-Adresse (numerisch)
m x..15 53.110.324.10
3 FTP-Server-IP-Adresse (Hostname)
k x..100 OFTPANET
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 28 von
50
Copyright: VDA
4 FTP-User-ID m x..50 xxx
5 FTP-User- Passwort
m x..50 xxx
6 Daten-Directory m x..1024 /mailbox R
efe
ren
ce
m
7 Referenz zu Werk/Standort
m x..100 CompanySite_ID_1
Co
mm
un
icati
on
Syste
m
Off
lin
e
1 Firmenweit eindeutige Offlinemedium-ID
m x..100 Beliebige Kennung zur Identifikation eines
Offline-Mediums
Offline_ID_1
2 Offline-Medium m x..50 CDROM
Refe
ren
ce
m
3 Referenz zu Werk/Standort
m x..100 CompanySite_ID_1
Exch
an
ge F
ile
Fo
rmat
(In
form
ati
on
üb
er
Au
sta
usch
form
at)
File F
orm
at
1 Firmenweit eindeutige Austauschformat-ID
m x..100 Beliebige Kennung zur Identifikation eines
Austauschformates
Format_ID_1
2 Austauschformat m x..25 Freier Text STEP AP 214
3 Version Austauschformat
k x..25 IS (2003) TC2
4 Austauschformat k an3 Codierte Form laut ODDC 77
STP
5 Zeichensatz k x..25 Freier Text US ASCII 7BIT
6 Zeichensatz codiert
k x..25 Codierte Form laut ODDC 78
646
7 Kompression k x..25 none
Exch
an
ge F
ile
Gen
era
tin
g
Syste
m
(In
form
ati
on
üb
er
Syste
me)
Gen
era
tin
g S
yste
m
1 Firmenweit eindeutige System-ID
m x..100 Beliebige Kennung zur Identifikation eines Systems
System_ID_1
2 Eingesetztes System
m x..25 Freier Text CATIA RS 6000
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 29 von
50
Copyright: VDA
3 Version System
k x..25 V5R17
Refe
ren
ce
m
4 Referenz zu Austauschformat
m x..100 Format_ID_1
Sen
de
r D
esti
nati
on
Ad
dre
ss
(Zie
lad
ress
en
)
Desti
nati
on
Ad
dre
ss
1 Firmenweit eindeutige Zieladress-ID
m x..100 Beliebige Kennung zur Identifikation einer
Zieladresse
Destination _ID_1
2 Nachname m x..50 Mustermann
3 Vorname k x..50 Manfred
4 Abteilung k x..100 Abteilung 1
5 Telefonnummer m x..50 +497031-555-55
6 Handynummer k x..50 +49172-555-66
7 Faxnummer k x..50 +497031-555-56
8 Electronic-Mail- Adresse
m x..100
M.Mustermann@ senderfirma.com
9 Adresscode m x..50 rout.code_ muster
Refe
ren
ce
m
10 Referenz zu Werk/Standort
m x..100 Company Site_ID_1
11 Referenz zu Austauschformat
k x..100 Format_ID_1
12 Referenz zu System
k x..100 System_ID_1
13 Referenz zu Kommunikations- medium OFTP
k x..100 OFTP_ID_1
14 Referenz zu Kommunikations- medium FTP
k x..100 FTP_ID_1
15 Referenz zu Kommunikations- medium Offline
k x..100 Offline_ID_1
Format Notation:
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 30 von
50
Copyright: VDA
Struktur der Referenzen einer ENGPART-Message
an8 alphanumerisches Format (Buchstaben plus Zahlen), exakt 8
Zeichen
a..30 alphabetisches Format, bis zu 30 Buchstaben
n..10 numerisches Format, bis zu 10 Einzelzahlen
x..100 bis zu 100 beliebige Zeichen (Buchstaben plus Zahlen plus
interpunktion plus multibyte Zeichen wie Umlaute etc.)
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 31 von
50
Copyright: VDA
Anhang B XML-Schema (XSD) einer vollständigen
ENGPART-Message
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 32 von
50
Copyright: VDA
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 33 von
50
Copyright: VDA
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 34 von
50
Copyright: VDA
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 35 von
50
Copyright: VDA
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 36 von
50
Copyright: VDA
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 37 von
50
Copyright: VDA
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 38 von
50
Copyright: VDA
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 39 von
50
Copyright: VDA
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 40 von
50
Copyright: VDA
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 41 von
50
Copyright: VDA
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 42 von
50
Copyright: VDA
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 43 von
50
Copyright: VDA
ISO 3166-1 alpha 2 (2000)
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 44 von
50
Copyright: VDA
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 45 von
50
Copyright: VDA
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 46 von
50
Copyright: VDA
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 47 von
50
Copyright: VDA
ISO 639-1 alpha 2 (2002)
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 48 von
50
Copyright: VDA
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 49 von
50
Copyright: VDA
-
VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 50 von
50
Copyright: VDA