| Element | Bemerkung |
|---|---|
| Zeitmarkenfelder | Alle Zeitmarken werden im DateTime-Format nach ISO 8601 ohne Millisekunden und Zeitzonenangabe übermittelt.
Als Bezugspunkt für die Zeit gilt HAMBURG (DEHAM), d.h. alle Zeitangaben repräsentieren die lokale Zeit am Terminal. Formatbeispiel: 2013-07-13T13:40:00 (YYYY-MM-DD"T"hh:mm:ss) |
| Attribut agencyID | Alle hier angebotenen Code-Verzeichnissewerden wenn nichts anderes angegeben ist unter der agencyID
DAKOSYgeführt Alle teilnehmeridentifizierenden Codesverwenden die individuelle, von DAKOSY vergebene agencyID |
| gleiche Elemente auf verschiedenen Hierarchieebenen | Werden fachlich gleiche Elemente auf verschiedenen Ebenen übermittelt (Beispielelement:
<TransportMode>) so haben die spezielleren Angaben Vorrang vor den allgemeineren Angaben: Beispiel: <Header><Load><TransportMode> hat Vorrang vor <Header><TransportMode> |
| Versionierung in der Kommunikation Versionsnummer zum Element ReferenceID |
1. Eine Neuanlage hat die Version 1 Wird eine Neuanlage wg. Fehlern abgelehnt, so |
| Nachrichtenbündelung | In einer XML-Datei können mehrere Messages eines Typs gemeinsam übertragen werden. Das Mischen unterschiedlicher Nachrichtentypen ist nicht zulässig. |
| Regel | Erläuterung |
|---|---|
| Significance | Es werden nur 'statusRequest' und 'transportBooking' genutzt. |
| ParticipantInformation | Es wird nur eine ParticipantInformation in der TransportCoordination übermittelt, die die Daten des Fuhrunternehmens enthält. |
| Version | Neuanlagen haben immer Version '1' und müssen vor einer Änderung bekannt sein. |
| Vollständigkeit | Eine Änderung muss nicht alle Load-Elemente der vorhergehenden Versionen beinhalten. (Beispielsweise Update wenn einzelne Container bereits 'Ingate/Outgate' erhalten haben) |
| Löschung | Ein 'statusRequest' muss - wenn er nicht mit einem 'transportBooking' verplant wird, mit einer 'Deletion'
storniert werden. Ein vollständiger 'statusRequest' oder eine Ladeeinheit aus einem 'statusRequest' kann erst storniert werden, wenn die Ladeeinheiten in keinem 'transportBooking' enthalten sind. Ein ggf. existierendes 'transportBooking' ist ggf. vorher mit der 'Deletion' zu stornieren. |
| Gültigkeit | Eine 'TransportCoordination' hat eine Gültigkeit von 21 Tagen seit der letzen erfolgreichen Änderung.
Danach
wird die 'TransportCoordination' auf Terminalseite gelöscht. |
| Änderungen | Änderungen können so lange gesendet werden, wie die 'TransportCoordination' nicht storniert wurde oder das 'transportBooking' nicht im Status 'aktiv' ist. |
| Regel | Erläuterung |
|---|---|
| DeletionType | Über den DeletionType wird unterschieden, ob eine gesamte TransportCoordination storniert werden soll oder
nur ein Load-Element. Sofern das letzte Load-Element storniert werden soll, unabängig ob dies als Einzelstorno oder als
Mehrfachstorno von mehreren Load-Elementen passiert, muss eine Deletion auf Coordination-Ebene erfolgen. |
| Regel | Erläuterung |
|---|---|
| Antwort | Nach dem Empfang einer 'TransportCoordination' wird immer eine StatusInformation gesendet |
| aktives Senden | Bei jeder Änderung des Status am Terminal wird eine aktualisierte 'StatusInformation' an den Trucker gesendet. |
| Vollständigkeit | Eine 'StatusInformation' muss nicht alle Statusmeldungen für alle Ladeeinheiten der 'TransportCoordination' enhalten. |
| Storno am Terminal | Wurde ein 'transportBooking' vollständig am Terminal storniert (bspw. wg. manueller Abfertigung) oder ein Container aus einer Tour gelöscht so wird dies mit einem entsprechendem Status an den Trucker kommuniziert. |
| Storno am Terminal | Ein 'transportBooking' muss immer mindestens einen Container referenzieren. Findet ein Terminalseitiges Storno statt und wird dabei der letzte Container von einem 'transportBooking' storniert, so muss der Terminalseitige Storno auf Header/Terminal/TpStatus-Ebene erfolgen um das gesamte 'transportBooking' zu stornieren. |
| Dispatchattribute | Die Abfertigungsmerkmale werden vom Terminal gesendet, wenn der ProcessingStatus für die TransportCoordination keine Fehler aufweist. |
| Bewertung Verarbeitungsstatus | Der Verarbeitungsstatus <Header/Terminal/ProcessingStatus> bewertet die TransportCoordination (mit
allen enthaltenen Containern) a) syntaktisch gemäß der Implementierungsvorgaben b) gemäß dem fachlichen Status am Terminal (bspw. Aktiv) c) gemäß der Definition für den Nachrichtenaustausch (bspw. Versionierung) |
| Regel | Erläuterung |
|---|---|
| Arrival | Das Element Arrival wird von den Terminals an den InfoHUB übermittelt und dient ausschließlich statistischen Zwecken. Es erfolgt keine Weiterleitung dieser Information an die Fuhrunternehmen. |
| Regel | Erläuterung |
|---|---|
| ResponseType | Eine Response ist eine technische Quittung, so dass als ResponseType nur 'technical' zugelassen ist |