TR02-v14 - Transaktionen-Wiki

• 1 Änderungshistorie
• 2 TR02-Regeln
• 3 Nachrichtenelemente TR02-XML
• 4 Nachrichtenadressierung
  • 4.1 Transaction
  • 4.2 Interchange
  • 4.3 MessageHeader
• 5 technische Nachrichtenberschreibung
  • 5.1 Adressierung und Referenzierung der Nachrichten
  • 5.2 TransportCoordination
    • 5.2.1 Header
    • 5.2.2 ReferencedLoad
    • 5.2.3 Load
  • 5.3 StatusInformation
    • 5.3.1 Header
    • 5.3.2 Load
  • 5.4 VesselInformation
    • 5.4.1 Header
    • 5.4.2 Voyage
  • 5.5 IngateOutgate
    • 5.5.1 Header
    • 5.5.2 Load
  • 5.6 Deletion
  • 5.7 Response

Die im TR02-Wiki gemachten Änderungen finden Sie in der Änderungshistorie

Wenn Sie per E-Mail über Änderungen informiert werden möchten, dann schicken Sie ein Nachricht an kostka@dakosy.de

Für die Nutzung der TR02-Nachricht sind zusätzlich zu den hier beschriebenen technischen Nachrichtendefinitionen noch weitere Vorgaben zu berücksichtigen, die die fachliche Nutzung der TR02 regeln.

Dazu gehören

• die allgmeinen Abläufe
  

Die allgemeinen Abläufe erläutern die vereinbarten Prozesse bei der Nutzung der TR02-XML

• die Kommunikationsszenarien
  

Die Kommunikationsszenarien stellen die unterschiedlichen Szenarien dar, die für den jeweiligen Datenaustausch genutzt werden.

• die fachlichen Implementierungsvorgaben
  

Die Implementierungsvorgaben geben vor, unter welchen Voraussetzungen die jeweiligen Datenfelder gefüllt werden müssen.

• die geltenden Regeln
  

Die Regeln beschreiben die allgemeinen Festlegungen für den Datenaustausch in der TR02-XML

• die mitgeltenden Codelisten
  

Die Codeliste definieren die Wertebereiche für die entsprechenden Elemente

TR02-XML besteht aus den folgenden Nachrichtenelementen:

• TransportCoordination - Statusanfrage und Abstimmung des Transport mit dem Terminal (Zusammenfasung der TR02-Feldnummerformat Informationseinheiten TV und TP)
• Statusinformation - Rückmeldung von Statusinformationen
• Vesselinformation - Segelliste der Terminals
• IngateOutgate - Kommunikation des In- oder Outgates
• Deletion - Nachricht zum Stornieren einer kompletten TransportCoordination oder einzelner Ladeeinheiten (Container und Stückgut)
• Response - Quittungsnachricht
• SlotStatus - Übermittlung der Zeitfensterauslastung (Bereitstellung als WebService)

TR02-XML umfasst folgende zusätzliche XSDs

• TR02_MessageEnvelope - übergreifende Definition der Elemente zur Adressierung der Nachrichten
• Core - Definition gemeinsam genutzter XML-Elemente und Strukturen
  
  

Die Beschreibung des XML-Nachrichtensets orientiert sich am UNeDoc Standard der Vereinten Nationen und den Nachrichtenstrukturen des ISETEC II Projekts LPM - Lean Port Management, um eine möglichst einfache Integration in die entsprechenden Kommunikationsprozesse zu erlauben. Wo es möglich ist, werden innerhalb der TR02XML Nachrichten einheitliche Strukturen zur Kommunikation gleicher Inhalte verwendet. Die Definition der Nachrichtenstrukturen erfolgt über XSDs für die einzelnen Nachrichten.

Als Hilfe für die Migration von Version 13 steht eine [Migrationsanleitung] zur Verfügung.

Nachricht	Version 14.3	Version 14.3.1
ReleaseNotes	ReleaseNotesTR02v14.3.pdf	ReleaseNotesTR02v14.3.1.pdf
TR02_MessageEnvelope	TR02_MessageEnvelope.xsd [Dokumentation]	nicht mehr vorhanden
TR02_Core	TR02_Core.xsd [Dokumentation]	TR02_Core.xsd [Dokumentation]
TransportCoordination	TransportCoordination.xsd [Dokumentation] [Beispieldatei]	TransportCoordination.xsd [Dokumentation] []
StatusInformation	StatusInformation.xsd [Dokumentation] [Beispieldatei]	StatusInformation.xsd [Dokumentation] []
VesselInformation	VesselInformation.xsd [Dokumentation] [Beispieldatei]	nicht mehr vorhanden
IngateOutgate	IngateOutgate.xsd [Dokumentation] [Beispieldatei]	IngateOutgate.xsd [Dokumentation] []
Deletion	Deletion.xsd [Dokumentation] [Beispieldatei]	Deletion.xsd [Dokumentation] []
Response	Response.xsd [Dokumentation] [Beispieldatei]	Response.xsd [Dokumentation] []
SlotStatus (Wird nicht als Nachricht verschickt!)	SlotStatus.xsd [Dokumentation] [WebserviceSlotauslastung DE (deprecated)] [WebserviceSlotauslastung v2 DE (deprecated)] [WebserviceSlotstatus EN (deprecated)] [WebserviceSlotstatus v2 EN (deprecated)] [WebserviceSlotstatus v3 Dokumentation(Test)] [WebserviceSlotstatus v3 Swagger-Dokumentation(Test)] [WebserviceSlotstatus v3 Dokumentation] [WebserviceSlotstatus v3 Swagger-Dokumentation]	[WebserviceSlotauslastung DE (deprecated)] [WebserviceSlotauslastung v2 DE (deprecated)] [WebserviceSlotstatus EN (deprecated)] [WebserviceSlotstatus v2 EN (deprecated)] [WebserviceSlotstatus v3 Dokumentation(Test)] [WebserviceSlotstatus v3 Swagger-Dokumentation(Test)] [WebserviceSlotstatus v3 Dokumentation] [WebserviceSlotstatus v3 Swagger-Dokumentation]

¹EOL: End of Life, Außerbetriebnahme der TR02-Versionen < 14.3 erfolgt am 01. Oktober 2016

Die einzelnen XML-Nachrichten haben eine einheitliche Struktur zur Identifikation und Adressierung der Nachrichten. Die Identifikation der Transaktion erfolgt zusätzlich zur technischen Referenzierung des XSD innerhalb der Nachricht durch das Element <Transaction>.

Für TR02-XML Version 14 werden die Attribute mit den folgenden Werten gefüllt:

Element	Attribut	Werte
<Transaction>	code	TR02XML
<Transaction>	version	14
<Transaction>	type	TransportCoordination StatusInformation VesselInformation IngateOutgate Response Deletion

Die Nachrichten werden durch ein <Interchange> geklammert, das eine oder mehrere Nachrichten enthalten kann. Grundsätzlich werden jedoch in einem Interchange nur Dokumente desselben Nachrichtentyps aufgenommen. Ein Interchange enthält also nur Nachrichten von Typ 'TransportCoordination', 'StatusInformation', u.s.w.

Element	Attribut	Werte
<Interchange><CreationTime>		Zeitmarke der Dateierstellung im Format 2000-01-01T13:40:00 Es wird immer die aktuelle Zeit der Erstellung der kommunizierten Datei übermittelt.
<Interchange><ExchangeNumber>		Vom Sender vergebene eindeutige Referenznummer des Datenaustausches. Jede ExchangeNumber wird von den Empfängersystemen nur einmal verarbeitet.
<Interchange><TestIndicator>		Kennzeichen für Testnachrichten.
<Interchange><MessageCount>		Anzahl der Nachrichten (Message-Elemente) die im Interchange übertragen werden.
<Interchange><Sender>		Die Struktur enthält in dem Element <ParticipantCode> den EDI-Code des Absenders der XML-Nachricht. Das Interchange erlaubt damit einem EDI-Teilnehmer in der Rolle eines Providers die Bündelung von Nachrichten verschiedener Absender für einen Empfänger. Der eigentliche Absender ist weiterhin in den EDI-Adressdaten der Nachricht in der Struktur <MessageHeader> enthalten.
<Interchange><Recipient>		Die Struktur enthält in dem Element<ParticipantCode> den EDI-Code des Empfängers der XML-Nachricht. Für alle Teilnehmer ist der Empfänger der InfoHUB.

Die Struktur <MessageHeader> enthält die Adressierungsdaten der eigentlichen Nachricht.
Neben den Strukturen <MessageSender> und <MessageRecipient> mit den EDI-Codes des Absenders und Empfängers in den Elemente <ParticipantCode>, enthält der <MessageHeader> im Element <MessageReferenceNumber> die Nachrichtenreferenz. In Kombination mit dem EDI-Code des Absenders erlaubt diese die eindeutige Identifikation der Nachricht. Sie wird in der Nachricht 'Response' zur Identifikation der quittierten Nachricht verwendet.

Element	Attribut	Werte
<MessageHeader><MessageFunction>		Definition der Nachricht als Original (Wert = 9) oder Änderung (Wert = 4) nach UN/EDIFACT 1225
<MessageHeader><MessageReferenceNumber>		Eindeutige Referenz zur Identifzierung einer Nachricht. Ein Interchange bzw. Übertragungsdatei kann mehrere Nachrichten enthalten. Jede MessageReferenz wird im Empfängersystem nur einmal verarbeitet.
<MessageHeader><PreviousMessageReferenceNumber>		Angabe einer Referenz einer vorangegangenen Nachricht. In TR02XML nicht genutzt
<MessageHeader><MessageSender>		Angabe der Daten des tatsächlichen Absenders dieser Nachricht (kann sich vom Absender des Interchanges unterscheiden). Bei der Responsemuss hier der Interchange-Teilnehmercode stehen!
<MessageHeader><MessageRecipient>		Angabe der Daten des tatsächlichen Empfängers dieser Nachricht. Bei der Response muss hier der Interchange-Teilnehmercode stehen!
<MessageHeader><AdditionalValue>		Code-Name-Felder für die Übermittlung weiterer bidirektional abzustimmender Daten.

Die folgende Beschreibung der Nachricht ist technischer Natur und definiert die zur Verfügung stehenden Elemente, deren Nutzung und Bedeutung. Ergänzend zu der technischen Beschreibung gelten die fachlichen Implementierungsvorgaben für die jeweiligen Transportrichtungen und Beladezustände.

Alle ausgetauschten Nachrichten enthalten innerhalb des <header>-Elements die Angaben der Beteiligten Transportunternehmen und Terminals und die fachliche Referenz eines Vorgangs.

Element	Attribut	Werte
<ParticipantInformation><Companny>		Struktur für Angaben des beteiligten Fuhrunternehmens
<ParticipantInformation><Companny><CompanyCode>		Teilenehmercode des Fuhrunternehmens
<ParticipantInformation><Companny><CompanyCode>	codeListIdentification	lt. DAKOSY-Codeliste, DAKCC
<ParticipantInformation><Companny><Companytype>		Typ der Company. Nicht verwendet
<ParticipantInformation><Companny><CompanyName>		Name des Fuhrunternehmens
<ParticipantInformation><Reference>		Struktur für die fachliche Referenz des Vorgangs. Bei einer TransportCoordination die fachliche Referenz des Fuhrunternehmens. StatusInformation, IngateOutgate und Deletion übernehmen diese Referenz um den Bezug zur TransportCoordination herzustellen. Über dieses Element wird eine Abstimmung in Kombination mit dem <CompanyCode> eindeutig identifiziert. Bei einer VesselInformation eine beliebige Referenz des Terminals.
<ParticipantInformation><Reference><ReferenceID>		Fachliche Referenz.
<ParticipantInformation><Reference><ReferenceId>	version	Fachliche Version der Vorgangs-Referenz. Für eine Neuanlage (insbesondere von einer TransportCoordination) wird die Version 1 erwartet. Eine Version > 1 wird als Änderung interpretiert - wobei die Änderung eine größere Version als die letzte erfolgreiche Kommunikation der Nachricht haben muss. (Versionssprünge > 1 sind zulässig). TransportCoordination:Vor einer Änderung muss eine Version 1 erfolgreich kommuniziert worden sein. Deletion: Eine Deletion nutzt die Versionierung der TransportCoordniation, auf die sie sich bezieht, mit. StatusInformation, IngateOutGate, VesselInformation: Bei jedem Senden wird die Version inkrementiert.
<ParticipantInformation><Reference><TypeCode>		Typ der Referenz. Nicht verwendet
<ParticipantInformation><Reference><TypeCode>	codeListIdentification	nicht definiert
<ParticipantInformation><Reference><Position>		Position der Ladung. Innerhalb des <ParticipantInformation>-Element nicht verwendet.
<TerminalLocation>		Struktur zur Identifikation des beteiligten Terminals
<TerminalLocation><LocationIdentification>		Angabe des UNLOCODEs des Ladeortes
<TerminalLocation><LocationName>		Name des Ladeortes
<TerminalLocation><LocationType>		Typ des Ladeortes
<TerminalLocation><LocationType>	codeListIdentification	nicht definiert
<TerminalLocation><PlaceOfLoading>		Teilnehmercode des Terminals
<TerminalLocation><PlaceOfLoading><Code>	codeListIdentification	lt. DAKOSY-Codeliste, DAKTC
<TerminalLocation><PlaceOfLoading><Name>		Name des Terminals

Die 'TransportCoordination' dient zur Abstimmung des Transports zwischen Trucker und Terminal und wird vom Trucker an das Terminal kommuniziert.

Das TR02-XML Nachrichtenelement 'Transportcoordination' kann im Rahmen des Abstimmungsprozesses zwischen Trucker und Terminal in zwei unterschiedlichen Ausprägungen oder Bedeutungen verwendet werden. Diese wird mit Hilfe des Elements <Significance> kommuniziert.

Statusanfrage (statusRequest) Die Statusanfrage stellt die erste Stufe der 'TransportCoordination' dar. Bei ihr handelt es sich um eine unverbindliche Anfrage nach einem Containerstatus. Das Terminal sendet solange Statusmeldungen auf die Statusanfrage, wie der Container sich am Terminal befindet oder der Container für einen Export noch nicht angeliefert worden ist. Dabei sendet das Terminal automatisch mit jeder Statusänderung des Containers (auf Seite des Terminals) eine aktualisierte Statusmeldung an den Trucker. Ein statusRequest muss entweder manuell durch ein Storno wieder gelöscht werden oder er wird durch eine IngateOutgate-Nachricht auf ein transportBooking zu dem statusRequest beendet.

Transportbuchung (transportBooking) Für ein transportBooking sind die Angaben des Slot-Booking-Elements erforderlich. Es ist auf den Verkehrsträger Truck beschränkt. Mit dem transportBooking wird dem Terminal mitgeteilt, wann das Truckunternehmen den Container anliefern / abholen wird.

Eine TransportCoordination wird im Nachrichtenszenario auf technischer Ebene vom Terminal mit einer Quittung (Nachrichtenelement 'Response') und auf fachlicher Ebene mit Statusinformationen (Nachrichtenelement 'StatusInformation') beantwortet. Bei der Anlieferung oder Abholung der abgestimmten Ladung, wird das Terminal an den Trucker ein Ingate, bzw. ein Outgate (Nachrichtenelement 'IngateOutgate') kommunizieren. Mit dem Ingate, bzw. Outgate ist der Abstimmungsprozess aus Sicht des Terminals abgeschlossen.

Die XML-Struktur der TransportCoordination veranschaulicht die generelle Struktur der Nachricht mit <Interchange> und <MessageHeader>. Die fachlichen Daten der 'Transportcoordination' sind in der Struktur <Header> enthalten.

Element	Attribut	Werte
<TransportCoordinationMessage>	messageType	TransportCoordination
<TransportCoordinationMessage>	messageVersionID	14

Die Kopfinformationen beinhalten die Ladeinheiten übergreifenden Informationen.

Element	Attribut	Werte
<TransportMeans>		Identifikation des Verkehrsträgers
<TransportMeans>	codeListIdentification	lt. DAKOSY-Codeliste, 'TRAME'
<Significance>		Angabe der Nachrichtenbedeutung: Statusanfrage (statusRequest) oder Transportbuchung (transportBooking)
<TransportMode>		Übergeordnete Angabe der Transortart (Auslieferung, Abholung, ...). Angabe auf Load-Ebene hat Vorrang.
<TransportMode>	codeListIdentification	lt. DAKOSY-Codeliste, 'TRAMO'
<ReferenceStatusRequest>		Komplexe Struktur mit Angaben der Bezugsreferenzen im 'transportBooking': Hier werden in einem transportBooking die Ladeeinheiten aus den statusRequest's referenziert.
<Load>		Komplexe Struktur der Ladeeinheitendaten
<SlotBooking><TimeSlot>		Angaben für den geplanten Zeitpunkt der Anlieferung bzw. Abholung. Angabe auf Load-Ebene hat Vorrang.
<Legitimation>		Angabe von Legitimationsdaten für die Berechtigungsprüfung.
<Comment>		Allgemeiner Kommentar
<TruckerTpNumber>		Im Falle einer Konvertierung von vorhergehenden Versionen enthält dieses Element die von Trucker vergebene Tourenplannummer.

Das Element beinhaltet in der Ausprägung 'transportBooking' die Referenzen und Positionsangaben der 'statusRequest's, auf die Bezug genommen wird.

Element	Attribut	Werte
<Position>		Eindeutige Positionsnummer der Ladeeinheit innerhalb dieses 'transportBooking' Die Position darf nach einem Storno nicht wiederverwendet werden
<ReferenceStatusRequest><ReferenceID>		Referenz des 'statusRequest'
<ReferenceStatusRequest><ReferenceID>	version	Wird vom Terminal nicht ausgewertet. Die Referenzierung findet ausschließlich über die <ReferenceID> unabhängig von der Version statt.
<ReferenceStatusRequest><TypeCode>		Typ der Referenz. Nicht verwendet
<ReferenceStatusRequest><Position>		Position der Ladeeinheit aus dem bezugnehmenden 'statusRequest'

Die Ladeeinheiteninformationen beinhalten die Ladeinheit-spezifischen Informationen.

Element	Attribut	Werte
<Position>		Eindeutige Positionsnummer der Ladeeinheit Die Position darf nach einem Storno nicht wiederverwendet werden
<SlotBooking><TimeSlot>		Angaben für den geplanten Zeitpunkt der Anlieferung bzw. Abholung. Angabe hat Vorrang gegenüber der Header-Angabe.
<ContainerLoad>		Angaben der Containerdaten
<ContainerLoad><LoadingIndicator>		Angabe des Beladungszustands (Voll / Leer)
<ContainerLoad><Container>		Angaben der Containerdaten
<ContainerLoad><Container><Length>	codeListIdentification	lt. DAKOSY-Codeliste, CTRLE
<ContainerLoad><Container><Height>	codeListIdentification	lt. DAKOSY-Codeliste, CTRHE
<ContainerLoad><Container><Type>	codeListIdentification	lt. DAKOSY-Codeliste, CTRTY
<ContainerLoad><Oversized>		Angabe von Übermaßen
<ContainerLoad><Oversized>*	unitCode	cm für Zentimeter
<ContainerLoad><ClipOnUnit>		Angaben zu einem ClipOnUnit-Aggregat
<ContainerLoad><Temperature>		Temeraturangaben des Containers
<ContainerLoad><Temperature>	unitCode	CEL für Celsius
<ContainerLoad><GrossWeight>		Bruttogewicht des Containers
<ContainerLoad><GrossWeight>	unitCode	KGM für Kilogramm
<ContainerLoad><EmptyQuality>		Qualitätsanforderung für Leercontainer
<ContainerLoad><EmptyQuality>	codeListIdentification	lt. DAKOSY-Codeliste, CTREQ
<ContainerLoad><NonOperatingReefer>		Kennzeichen für nicht aktiven Reefercontainer
<ContainerLoad><IReference)		I-Referenz der IMP - Import Message Platform for the Port of Hamburg (LPM)
<ContainerLoad><Accounting>		Angabe der Kai-Konto-Daten für die Buchung von Gebühren
<ContainerLoad><Accounting><ConsignorCode>	codeListIdentification	lt. DAKOSY-Codeliste, DAKCC
<TransportMode>	codeListIdentification	lt. DAKOSY-Codeliste, TRAMO Angabe der Transortart (Auslieferung, Abholung, ...). Angabe hat Vorrang gegenüber Header-Angabe.
<Carrier>		Struktur für Angaben zum Reeder und den Legitimations bzw. Buchungsdaten
<Carrier><Code>	codeListIdentification	lt. DAKOSY-Codeliste, CARCO
<Voyage>		Struktur für die Angaben der Schiffsreise und Hafendaten
<Voyage><Vessel><TransportMeansTypeCode>	codeListIdentification	nicht definiert
<Voyage><Vessel><AdditionalTransportMeansID>	codeListIdentification	nicht definiert
<Voyage><Vessel><TransportMeansOwner><PartyIdentification>	codeListIdentification	nicht definiert
<DangerousGoodsIndicator>		Kennzeichen für Gefahrgut
<DangerousGoods>		Gefahrgutdaten
<GegisReference>		Referenz für die Gefahrgutdaten im GEGIS-System
<CustomsIndicator>		Kennzeichen für Zollgut (T1)
<Customs>		Angabe der Zollregistriernummern für T1
<Customs><RegistrationNumber><Code>	codeListIdentification	lt. DAKOSY-Codeliste, REGTY
<Comment>		Kommentar zur Ladung

Das Nachrichtenelement 'StatusInformation' wird vom Terminal an den Trucker kommuniziert und bezieht sich auf die Ladeeinheiten einer zuvor gesendeten 'TransportCoordination'.

Für containerisierte Ladung enthalten die gemeldeten Statusinformationen neben den beim Terminal vorliegenden Ist-Daten des Containers - wie z.B. Containertyp, -länge und -höhe, Gewichte, etc. - auch den für den eigentlichen Transport relevanten Status der Ladeeinheit. Für Stückgüter wird der Status im Element <Load><ConventionalLoad><Status> übermittelt. Für Container wird der Status in Form von Statuscodes im Element <Load><ContainerLoad><Terminal><DispatchInformation><DispatchAttribute> geliefert.

Die XML-Struktur der StatusInformation veranschaulicht die generelle Struktur der Nachricht mit <Interchange> und <MessageHeader>. Die fachlichen Daten der 'StatusInformation' sind in der Struktur <Header> enthalten.

Element	Attribut	Werte
<StatusinformationMessage>	messageType	StatusInformation
<StatusinformationMessage>	messageVersionID	14

Die Kopfinformationen beinhalten die Ladeinheiten übergreifenden Informationen.

Element	Attribut	Werte
<ConventionalLoad>		Kennzeichen für Statusinformationen auf konventionelle Ladung
<Load>		Statusdaten der Ladeeinheiten
<Terminal><ProcessingStatus>		Verarbeitungsstatus der vom Fuhrunternehmen empfangenen Nachricht lt. DAKOSY-Codeliste, PROST
<Terminal><ProcessingStatusInformation>		optional: Zusätzliche Freitextinformationen zum ProcessingStatus
<Terminal><TpReference>		Tourenplanreferenz als Antwort auf ein transportBooking
<Terminal><TpStatus>		Status des Tourenplans (transportBooking) lt. DAKOSY-Codeliste, TPSTA

Die Ladeeinheiteninformationen beinhalten die Ladeinheit-spezifischen Informationen.

Element	Attribut	Werte
<Position>		Eindeutige Positionsnummer der Ladeeinheit. Entspricht der Position in der TransportCoordination.
<SlotBooking><TimeSlot>		bestätigter Zeitpunkt der Anlieferung bzw. Abholung.
<SlotBooking><DischargeStart>		Auslieferungsbeginn der Ladeeinheit beim Terminal
<SlotBooking><EarliestDelivery>		frühester Anlieferungszeitpunkt für die Ladeeinheit beim Terminal
<ContainerLoad>		Angaben der Containerdaten
<ContainerLoad><LoadingIndicator>		Angabe des Beladungszustands (Voll / Leer)
<ContainerLoad><Container>		Angaben der Containerdaten
<ContainerLoad><Container><Length>	codeListIdentification	lt. DAKOSY-Codeliste, CTRLE
<ContainerLoad><Container><Height>	codeListIdentification	lt. DAKOSY-Codeliste, CTRHE
<ContainerLoad><Container><Type>	codeListIdentification	lt. DAKOSY-Codeliste, CTRTY
<ContainerLoad><Oversized>		Angabe von Übermaßen
<ContainerLoad><Oversized>*	unitCode	CMT für Zentimeter
<ContainerLoad><ClipOnUnit>		Angaben zu einem ClipOnUnit-Aggregat
<ContainerLoad><Temperature>		Temeraturangaben des Containers
<ContainerLoad><Temperature>	unitCode	CEL für Celsius
<ContainerLoad><GrossWeight>		Bruttogewicht des Containers
<ContainerLoad><GrossWeight>	unitCode	KGM für Kilogramm
<ContainerLoad><NonOperatingReefer>		Kennzeichen für nicht aktiven Reefercontainer
<ContainerLoad><Carrier)		Struktur für Reederdaten
<ContainerLoad><IReference)		I-Referenz der IMP - Import Message Platform for the Port of Hamburg (LPM)
<Comment>		Kommentar zur Ladung
<ContainerLoad><Accounting>		Angabe der Kai-Konto-Daten für die Buchung von Gebühren
<ContainerLoad><Accounting><ConsignorCode>	codeListIdentification	lt. DAKOSY-Codeliste, DAKCC
<ContainerLoad><Terminal>		Statusmeldungen vom Terminal
<ContainerLoad><Terminal><DispatchInformation><DispatchAttribute>		Abfertigungsmerkmale (fachliche Statuscodes) lt. DAKOSY-Codeliste, CONST
<ContainerLoad><Terminal><DispatchInformation><DispatchArea>		Abfertigungsbereich
<ContainerLoad><Terminal><TpStatus>		Tourenplanstatus für Ladeeinheit lt. DAKOSY-Codeliste, TPPST
<ContainerLoad><Terminal><MissingElements>		Aufzählung fehlender Pflichtelemente (gemäß der Implementierungsvorgaben)
<ContainerLoad><Terminal><InvalidElements>		Aufzählung von Elementen mit ungültigem Inhalt (gemäß der Codelisten)

Im Nachrichtenelement 'VesselInformation' werden vom Termnal die Schiffsdaten (Segelliste) an den Trucker kommuniziert. Die Schiffsdaten können in einer TransportCoordination-Nachricht für eine Anlieferung bei noch nicht bekannter Buchungsnummer verwendet werden.

Die XML-Struktur der VesselInformation veranschaulicht die generelle Struktur der Nachricht mit <Interchange> und <MessageHeader>. Die fachlichen Daten der 'VesselInformation' sind in der Struktur <Header> enthalten.

Element	Attribut	Werte
<VesselInformationMessage>	messageType	VesselInformation
<VesselInformationMessage>	messageVersionID	14

Die Kopfinformationen beinhalten die adressierenden Informationen. Die jeweiligen Schiffsdaten sind der Struktur Voyage enthalten.

Element	Attribut	Werte
<VoyageNumber>		Reisenummer. Eindeutiges Schlüsselkriterium für die Schiffsmeldung.
<Vessel>		Struktur zur Übermittlung der Schiffsdaten
<Vessel><TransportMeansIdentification>		Schiffsnummer
<Vessel><AdditionalTransportMeansID>		CallSign des Schiffes
<Vessel><AdditionalTransportMeansID>	codeListIdentification	CSL
<Vessel><AdditionalTransportMeansID>	agencyID	Terminalcode gemäß Teilnehmercodeliste
<Vessel><TransportMeansName>		Schiffsname
<Vessel><IMO>		IMO-Nummer des Schiffs
<VesselSchedules>		Struktur zur Übermittlung der Schiffsreisedaten
<VesselSchedules><VesselSchedule><ScheduleId>		ID der Zeitangabe
<VesselSchedules><VesselSchedule><ScheduleId>	codeListIdentification	Zeitplanidentifikation lt. DAKOSY-Codeliste, SCHID
<VesselSchedules><VesselSchedule><ScheduleDate>		Zeitpunkt am Terminal
<DeletionIndicator>		Kennzeichen für Löschung der Schiffsreise
<DispatchArea>		Angabe des Abfertigungsbereichs
<VoyageMeans>		Klassifizierung der Reise als Import(Lösch)- oder Export(Lade)-Reise

Das Nachrichtenelement 'IngateOutgate' wird vom Terminal an den Trucker kommuniziert, wenn die Ladeeinheit das Interchange passiert hat.

Eine 'IngateOutgate' Nachricht bezieht sich immer auf eine 'TransportCoordination' mit der Bedeutung 'transportBooking'. Die Nachricht enthält neben dem Zeitpunkt des Interchanges auch die Ist-Daten der Ladeeinheit (z.B. Typ der Ladung/Ladeeinheit, Abmessungen und Gewichte, Beschädigungen) zum Zeitpunkt des Gefahrenübergangs zwischen Trucker und Terminal.

Die XML-Struktur der IngateOutgate veranschaulicht die generelle Struktur der Nachricht mit <Interchange> und <MessageHeader>. Die fachlichen Daten der 'IngateOutgate' sind in der Struktur <Header> enthalten.

Element	Attribut	Werte
<IngateOutgateMessage>	messageType	IngateOutgate
<IngateOutgateMessage>	messageVersionID	14

Die Kopfinformationen beinhalten die adressierenden Informationen. Die jeweiligen Ist-Daten sind der Struktur Load enthalten.

Element	Attribut	Werte
<ConventionalLoad>		Kennzeichen für konvetionelle Ladung
<VehicleRegistration>		Identifikationsdaten des transportdurchführenden Trucks

Die Ladeeinheiteninformationen beinhalten die Ladeinheit-spezifischen Informationen.

Element	Attribut	Werte
<Position>		Eindeutige Positionsnummer der Ladeeinheit. Entspricht der Position in der TransportCoordination(transportBooking).
<Interchage>		Zeitpunkt des physischen Interchanges
<ContainerLoad>		Angaben der Containerdaten
<ContainerLoad><Seal>		Struktur für die am Container angebrachten Siegel(nummern)
<ContainerLoad><Seal><SealType>	codeListIdentification	lt. DAKOSY-Codeliste SEATY
<Damage>		Beschreibung von ggf. vorhandenen Beschädigungen

Das Nachrichtenelement 'Deletion' dient zur Stornierung einer 'TransportCoodination' und wird vom Trucker an das Terminal kommuniziert.

Sie ermöglicht die Stornierung einer vollständigen 'TransportCoordination' oder die Stornierung einzelner Ladeeinheiten einer 'TransportCoordination'. Eine 'Deletion'-Nachricht bezieht sich dabei immer auf genau eine 'TransportCoordination'. Diese Beziehung wird über das Element <ParticipantInformation><Reference> der 'TransportCoordination' hergestellt.

Die XML-Struktur der Deletion veranschaulicht die generelle Struktur der Nachricht mit <Interchange> und <MessageHeader>. Die fachlichen Daten der 'Deletion' sind in den folgenden Elementen enthalten.

Element	Attribut	Werte
<DeletionMessage>	messageType	Deletion
<DeletionMessage>	messageVersionID	14

Element	Attribut	Werte
<DeletionType>		Angabe der Deletion-Art: 'Coordination' für die Stornierung einer gesamten TransportCoordination oder 'Load' für den Storno einer einzelnen Ladeeinheit einer TransportCoordination
<Load><Position>		Beim Storno einer Ladeeinheitposition angabe der Position aus der entsprechenden Transportcoordination Die Position darf nach einem Storno nicht wiederverwendet werden.
<Dispatcher>		Struktur für Angaben zum Sachbarbeiter
<Comment>		Bemerkungen

Das Nachrichtenelement 'Response' dient der technischen Quittierung der übrigen TR02-XML Nachrichtenelemente. Jede kommunizierte Datei wird von dem Empfänger mit einer Quittung beantwortet. Eine 'Response'-Nachricht wird nicht quittiert.

Die Beziehung zwischen ursprünglicher Datei und Quittung wird mit Hilfe der ExchangeNumber hergestellt. Die Quittung beinhaltet im Element <OriginalExchangeNumber> die ExchangeNumber(Element<Interchange><ExchangeNumber>) der zu quittierenden Datei.

XML-Struktur Response veranschaulicht die generelle Struktur der Nachricht mit 'Interchange' und 'MessageHeader'. Die fachlichen Daten der 'Response' sind in den folgenden Elementen enthalten.

Element	Attribut	Werte
<ResponseMessage>	messageType	Response
<ResponseMessage>	messageVersionID	14

Element	Attribut	Werte
<ResponseType>		Definition des Quittungstyps. In TR02-XML ist die Response eine technische ('technical') Quittung
<OriginalMessageDate>		Datum an dem die Datei zu der eine Response gehört empfangen wurde.
<OriginalExchangeNumber>		Referenz der Originalnachricht, die mit dieser Response beantwortet wird. Diese Referenz ist die 'ExchangeNumber' der Originalnachricht.
<InformationContact>		Struktur mit den Kontaktinformationen des beim Absender der Response zuständigen Sachbearbeiters
<Reference>		Wird nicht verwendet
<Error>		Das Error-Element beschreibt einen bei der Verarbeitung einer EDI-Nachricht aufgetretenen Fehler.
<Error><ErrorCode>		codierter Fehler; bei einer positiven Quittung wird der Code '0' übertragen
<Error><ErrorInformation>		Freitextinformationen zum aufgetretenen Fehler.