Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
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