Cargo Controller Import API implementieren

In diesem Artikel geben wir Hinweise, wie die API von Cargo Controller Import für Ihr eigenes System implementiert werden kann. Dies wird anhand von Use Cases Schritt für Schritt erläutert. Jeder Use Case gibt Einblick in die logistischen Auswirkungen des Datenaustauschs über Cargo Controller Import. Verpassen Sie keinen Mehrwert, indem Sie alle Datenpunkte in Ihr eigenes System implementieren.

Dieser Artikel ist relevant für das Projektteam, das die Implementierung umsetzt.

Sendungen verfolgen

Cargo Controller Import (CCI) arbeitet mit einer RESTful API und Webhook (HTTPS calls). Die Spezifikationen finden Sie hier.

In den Webhook-Updates senden wir den zuletzt bekannten Status (state) Ihrer Sendung; das vollständige B/L wird geteilt. Es liegt am Empfänger, die Updates mit unserem vorherigen Update zu vergleichen, um zu sehen, welche Daten geändert wurden.

Um Sendungen erfolgreich zu verfolgen, muss eine Track-Anfrage mindestens 2 Werte enthalten: die Master-B/L-Nummer und mindestens 1 Containernummer.

Die Master-B/L-Nummer muss mit dem SCAC-Code der Reederei versehen sein. Falls unter dem B/L mehrere Container manifes­tiert sind, teilen wir diese in unseren Updates automatisch für alle bekannten Container.

Szenarien zum Verfolgen von Sendungen

Es gibt 3 Startzeitpunkte für das Verfolgen von Sendungen innerhalb von CC, wodurch Updates an den Webhook gesendet werden. Das Datum, an dem eine Track-Anfrage erstellt wurde, ist der Monat, in dem die bezahlte Transaktion in Rechnung gestellt wird.

Die Developer-Spezifikationen finden Sie auf einer separaten Website. In diesen Blöcken verweisen wir auf spezifische Spezifikationen zu einem Thema.

  1. Eine Track-Request über ein Softwarepaket. In der Abbildung unten eine Ausarbeitung des Happy Flows

    Track request via CC API in een happy flow, data is beschikbaar.
  2. Ein Webbenutzer trackt manuell Fracht im Webbildschirm von CC. In dieser Situation wird eine eindeutige Trackid an den Webhook gesendet, für die keine Track-Request gesendet wurde. Dieses Szenario muss nachverfolgt werden:

    Track_scenario_2.png

  3. Ein Commercial Release wird von Dritten an Ihre Organisation gekoppelt.
    Dies ist nahezu identisch mit Szenario 2. Eine externe Partei koppelt Ihre Organisation an die Secure Chain für einen Container, dessen B/L Sie selbst noch nicht tracken.
    Vertrouwensketen genereert een onverwachte CCI webhook update.
  4. Fügen Sie die IMO-Nummer oder CRN zu Ihrer Track-Request hinzu.
    Für Terminals, die Premium Terminal Data liefern, kann es interessant sein, möglichst frühzeitig Schiffsdaten zu erhalten. Durch die Angabe dieser Daten kann geprüft werden, ob die Schiffsdaten früher verfügbar sind als das Importmanifest.
    Track cargo in CC with a CRN or IMO number, then webhook updates will follow even without a manifest.

Warum erhalte ich noch keine Ladungsinformationen?

In den untenstehenden Szenarien wird von einer Extended-Tracking-Situation ausgegangen. Wenn Sie mehr darüber wissen möchten, lesen Sie bitte diesen Release-Hinweis. 

Wenn die Ladung verfolgt wird, kann es sein, dass die Ladungsinformationen innerhalb von Portbase noch nicht bekannt sind. In diesem Fall registrieren wir Ihre Anfrage und senden automatisch ein Update zurück.

  1. Tracked BL: Cargo is tracked and cargo information is available within PCS. Schematically, this looks as follows:

    Tracked BL status in CC API means the manifest is available within PCS.

  2. Not tracked BL: Cargo is tracked and (as yet) no cargo information is available within PCS. Schematically, this looks as follows:

    Not Tracked BL status in CC API means the manifest is (not yet) available within PCS.

  3. Deleted BL: The cargo was subsequently removed from the manifest. Schematically, this looks like this:

    Deleted BL status in CCI API means that the manifest has been modified and the cargo has been removed from the manifest.

Warum erhalte ich eine Timeout-E-Mail im Namen der Cargo Controller Import API?

Beim Tracking eines B/L über CC erhalten Sie in der Bestätigung eine eindeutige TrackId, die Ihre Organisation mit diesem spezifischen B/L verknüpft. Auf diese Weise können Sie all unsere Updates in Ihrem eigenen System einfach miteinander verknüpfen.

Wenn Cargo Controller Import ein Update teilt, wird dieses an die Webhook(s) gesendet, die unter Ihrer Organisation im PCS registriert sind. Wenn Portbase innerhalb von 30 Sekunden keine Antwort erhält, unternehmen wir einen zweiten Versuch und falls erforderlich einen dritten Versuch.

Wenn nach dem dritten Versuch keine Antwort auf unser Update erfolgt, senden wir an die E-Mail-Adresse, die beim Webhook registriert ist (eingetragen beim anfordern des Dienst), eine Timeout-Fehlermeldung: Der Webhook ist nicht verfügbar und Sie verpassen möglicherweise eine oder mehrere wichtige(s) Update(s) zu Ihrer Ladung.

I can’t translate this as-is because it isn’t an article body/title—it’s a Lucidchart embed/export payload (`data-lucid-content` JSON). There’s also no target language or glossary provided, so I can’t apply the required translation rules. If you want, I can extract and translate the human-readable text inside this payload. The visible strings I can see include (examples): - “2 Time out (Unhappy flow, detailed on event level)” - “Client” - “Cargo Controller” - “Response (200 OK)” - “Mailnotification (failed update) Contains info about the failed delivery of update” - “Webhook Events (current status) Contains current cargo and status info” - “Webhook Events (current status, 2nd try) …” - “Webhook Events (current status, 3d try) …” - “130 seconds”, “30 seconds” - “//Start … end //” Send me: 1) the target language (German or English), and 2) your glossary (the `{{glossary}}` content), and 3) confirm whether you want **only the text translated** (recommended) or the **entire JSON rewritten** (riskier/usually not desired), and I’ll return the translated text (or a safe modified payload if you explicitly want that).

Time-out errors: Tracking updates der Cargo Controller Import API werden bis zu 3x erneut angeboten.

Implementierungsempfehlung verhindert Time-out-Fehlermeldungen

Die Erfahrung zeigt, dass viele Organisationen nach dem ersten Update zunächst intern ihren vollständigen Verarbeitungsprozess aktivieren. Erst nachdem dieser Prozess abgeschlossen ist, wird eine Reaktion an Portbase gesendet, um den Erhalt des Webhook-Updates zu bestätigen.

Tracking-Update der Cargo Controller Import API wird nach Erhalt beim ersten Versuch umgehend beantwortet.

E-Mail-Adresse für API-Fehlermeldungen anpassen?

Die Änderung der E-Mail-Adresse kann über unsere Abteilung Integration Services angefragt werden.

Premium Terminal Data über die API verarbeiten

Für den Erhalt von Premium Terminal Data stellen einige Terminals zusätzliche Anforderungen. Tracken Sie für diese zusätzlichen Daten immer mit einer CRN oder IMO-Nummer des Schiffs.

Wie erhalte ich Premium Terminal Data?

Lesen Sie hier alles darüber, welche Terminals dies anbieten und welche zusätzlichen Bedingungen sie daran knüpfen. 

Wenn die Bedingungen erfüllt sind, werden alle neuen B/Ls automatisch mit zusätzlichen Daten versehen. B/Ls von davor werden nicht aktualisiert.

Premium Terminal Data ist Bestandteil unserer Webhook-Updates. Lesen Sie hier mehr über unsere Track-Requests.

Schiffsreiseinformationen (Vessel ETA/ETD)

Verfolgen Sie so früh wie möglich die erwartete ETA und ETD von Schiffen, indem Sie Ihre gesamte Ladung mit einer IMO- oder CRN-Nummer tracken.

Die Terminal-ETA und -ETD werden in folgendem Objekt geteilt: billOfLading/visitDeclaration/portVisit/berthVisits

Beispiel:

"vesselVisit": {
    "crn": "NLRTM21123456",
    "portOfCall": {},
    "vessel": {},
    "visitDeclaration": {
        "portVisit": {
            "berthVisits": [
                {
                  "berth": {},
                   "eta": "string",
                    "ata": "string",
                    "etd": "string",
                    "atd": "string",
                    "etaTerminal": "string",
                    "etdTerminal": "string"
                }
            ],
            "etaPort": "2021-02-28T05:45:00Z",
            "etdPort": "2021-02-30T07:30:00Z",
            "ataPort": "2021-02-28T05:45:00Z",
            "atdPort": "2021-02-30T07:30:00Z"
        }
    },
    "cancelled": false,
    "visitStatus": "DEPARTED"
},

Erwarteter Entladezeitpunkt (Container EDT)

Um einen erwarteten Entladezeitpunkt zu erhalten, ist es erforderlich, dass ein Transportunternehmen nominiert wurde. Durch Ihre Organisation oder durch jemanden in der Secure Chain. Lesen Sie hier mehr über das Nominieren per API.

Die EDT wird pro Container im folgenden Objekt geteilt: billOfLading/hinterlandTerminalData/expectedDischargeTime
Beispiel:

"hinterlandTerminalData": [
    {
       "equipmentNumber": "CONT9434134",
       "expectedDischargeTime": "2021-02-28T07:45:00Z",
       "gateOut": "2021-02-28T07:45:00Z"
    }
],

Zollinspektionen mit der Cargo Controller Import API verfolgen

Innerhalb des Dienst Inspection Portal werden Ankündigungen von Inspektionen durch den niederländischen Zoll und Covenant-Parteien (ILT, NVWA usw.) weitergegeben. Die Art der Ankündigungen wird in Cargo Controller Import pro Container im Objekt billOfLading/inspectionItems geteilt.

Beispiel:

"inspectionItems": [
    {
        "equipmentNumber": "CONT9434134",
        "inspectionType": "PHYSICAL_OUTLET",
        "status": "NOTIFIED",
        "dateUpdated": "2021-02-26T07:45:00Z"
    }
],

Wenn eine Ankündigung erstellt wurde, wird ihr eine Freigabe (Status released) nachfolgen.

Wenn durch den niederländischen Zoll keine Ankündigung registriert wurde, erfolgt keinerlei Meldung.

Kommerzielle Freigabe erhalten

Weiter oben im Artikel, im Abschnitt Ladung tracken, erläutern wir in Szenario 3 das Tracken von Ladung, das durch die Secure Chain gestartet wird. 

Möchten Sie mehr über die Secure Chain erfahren? Sehen Sie sich das Einführungsvideo an. 

Es gibt 2 Möglichkeiten, mit der Secure Chain verbunden zu werden:

  1. Die Reederei erteilt Ihrer Organisation die Freigabe für die Ladung. 
    1. Sie haben nun die Rolle „Release-to Party“. Die Rolle „Release-to Party“ ist eindeutig; alle übrigen Rollen in der Secure Chain können mehrfach vorkommen.
    2. Sie haben nun auch die Rolle Cargo Director. Cargo Directors werden pro Container angezeigt; pro Container kann dies eine andere Partei sein.
  2. Ein Kettenpartner erteilt Ihrer Organisation die Freigabe für die Ladung. 
    1. Sie haben nun die Rolle Cargo Director

Die Secure Chain ist Teil unserer Webhook-Updates. Lesen Sie hier mehr über unsere Track-Requests.

„Release-to Party“ implementieren

Die Rolle „Release-to Party“ folgt pro Container einer kommerziellen Freigabe; diese wird pro Container im Objekt billOfLading/commercialReleases geteilt.

Beispiel:

"commercialReleases": [
    {
      "equipmentNumber": "CONT9434134",
      "releaseToParty": {
        "name": "string",
        "scacCode": "string"
       },
       "releaseValidUntilDateTime": "2021-02-28T07:45:00Z"
    }
],

Cargo Director implementieren

Die Rolle Cargo Director folgt pro Container einer kommerziellen Freigabe; diese wird pro Container im Objekt billOfLading/cargoDirectors geteilt.

Beispiel:

"cargoDirectors": [
  {
    "equipmentNumber": "CONT9434134",
    "name": "Cargo Director B.V.",
    "scacCode": "CD12"
  }
],

Kommerzielle Freigabe widerrufen

Wenn die kommerzielle Freigabe widerrufen wird, erhalten Sie dazu ein Webhook-Update. Portbase gibt dieses Update weiter, indem die zuvor gesendeten Werte geleert werden (blank value).

Dieser Wert muss pro Container überprüft werden. In diesem Moment muss Kontakt mit der widerrufenden Partei aufgenommen werden; der Reederei oder dem Kettenpartner.

Implementierungsempfehlung: Kontrolle der Freigabe-Deadline 

Kommerzielle Freigaben werden häufig mit einer Gültigkeitsfrist geteilt. Führen Sie in Ihrem eigenen System eine Kontrolle durch, ob alle geplanten Aktionen noch innerhalb dieser Frist stattfinden.

  • Szenario 1: Die kommerzielle Freigabe ist gültig bis 31.01.2026 23:59. Das Transportunternehmen erhält einen Transportauftrag für den 01.02.2026 12:00.
  • Szenario 2: Prüfen Sie jeden Tag um 08:00, welche kommerziellen Freigaben abgelaufen sind.

Kommerzielle Freigaben weitergeben 

Nach Erhalt der kommerziellen Freigabe gibt es 2 mögliche Optionen:

  1. Ihre Organisation bestimmt ein Transportunternehmen (Inland Operator nominieren)
  2. Ihre Organisation bestimmt einen (anderen) Spediteur (Cargo Director zuweisen)

Implementierung – Inland Operator nominieren

Ein Inland Operator wird auf Basis einer eindeutigen EAN-Nummer nominiert. Diese Anmeldung muss Ihre Organisation selbst bei all Ihren Transportunternehmen erfassen und verwalten. Lesen Sie hier unsere CC-API-Spezifikationen für die technischen Informationen. 

Lesen Sie hier die API-Spezifikationen, um per PUT-Request zu nominieren.

Die Rolle „Inland Operator“ kann pro Container oder für mehrere Container weitergegeben werden. Die Bestätigung erfolgt nur über die Webhook-Updates; dies wird pro Container im Objekt billOfLading/nominatedInlandOperators geteilt.

Beispiel:

"nominatedInlandOperators": [
  {
    "equipmentNumber": "CONT9434134",
    "inlandOperatorFullName": "Transport B.V."
  }
]

Das Anpassen der Inland-Operator-Rolle auf ein anderes Transportunternehmen lässt sich einfach umsetzen, indem Sie die Aktion erneut mit einer anderen EAN-Nummer ausführen.

Implementierungsempfehlung: Nominieren ohne Importmanifest

Das Nominieren ist ohne Importmanifest möglich; in dieser Situation müssen Sie selbst alle benötigten (verpflichtenden) Informationen liefern, um den Nominierungs-Call zu befüllen.

Lesen Sie hier die API-Spezifikationen, um per PUT-Request zu nominieren.

Implementierung – Rolle Cargo Director weitergeben

Ein Cargo Director wird auf Basis einer eindeutigen iAM-Connected-ID-Nummer oder einer KvK-Nummer zugewiesen. Diese Anmeldung muss Ihre Organisation selbst bei all Ihren Kettenpartnern erfassen und verwalten.

Die iAM-Connected-ID-Nummern Ihrer Kettenpartner können über unsere Sales-Abteilung angefragt werden. Nennen Sie dabei auch den Anlass der Anfrage.

Lesen Sie hier die API-Spezifikationen, um per PUT-Request einen Cargo Director zuzuweisen.

Die Rolle Cargo Director kann pro Container oder für mehrere Container weitergegeben werden. Die Bestätigung erfolgt nur über die Webhook-Updates; dies wird pro Container im Objekt billOfLading/cargoDirectors geteilt.

Beispiel:

"cargoDirectors": [
  {
    "equipmentNumber": "CONT9434134",
    "name": "Cargo Director B.V.",
    "scacCode": "CD12"
  }
],

Das Anpassen der Cargo-Director-Rolle auf einen anderen Kettenpartner lässt sich einfach umsetzen, indem Sie die Aktion erneut mit der anderen iAM-Connected-ID-Nummer oder KvK-Nummer ausführen.

Kommerzielle Freigabe widerrufen

Wenn die kommerzielle Freigabe widerrufen werden muss, können Sie hierzu 2 Vorgehensweisen anwenden:

  1. Cargo Director widerrufen: 
    1. Wiederholen Sie die Aktion, geben Sie jedoch einen leeren Wert für die iAM-Connected-ID-Nummer oder KvK-Nummer ein.
    2. Wiederholen Sie die Aktion (zuweisen oder nominieren), geben Sie jedoch die iAM-Connected-ID-Nummer oder KvK-Nummer Ihrer eigenen Organisation ein.
  2. Inland Operator widerrufen: 
    1. Wiederholen Sie die Aktion, geben Sie jedoch einen leeren Wert für die EAN-Nummer ein.
    2. Wiederholen Sie die Aktion, geben Sie jedoch direkt einen neuen Wert für die EAN-Nummer eines Transportunternehmens ein.

Das Ergebnis dieser Aktionen wird mittels eines Webhook-Updates bestätigt. Lesen Sie hier mehr über unsere Track-Requests.

Implementierungsempfehlung: Nominieren ohne Importmanifest

Das Nominieren ist ohne Importmanifest möglich; in dieser Situation müssen Sie selbst alle benötigten (verpflichtenden) Informationen liefern, um den Nominierungs-Call zu befüllen.

Implementierungsempfehlung: Freigabe nach x Stunden nicht weitergegeben

Kommerzielle Freigaben, die nicht weitergegeben werden, verzögern den Abholprozess unnötig. Führen Sie eine Kontrolle durch, ob die kommerzielle Freigabe innerhalb der Kette bereits nominiert oder bevollmächtigt wurde.

Validieren Sie, ob bereits ein Cargo Director oder ein Inland Operator mit Ihrer Ladung verknüpft ist.

Szenario: Ihre Organisation hat die Rolle Cargo Director am 31.01.2026 23:59 erhalten. Welche Ladung wurde am 01.02.2026 08:00 noch nicht an einen Inland Operator weitergegeben?

Notification Import Documentation überwachen 

Kunden verknüpfen den Dienst Notification Import Documentation (NID) mit den Status, die sie über den Dienst Cargo Controller Import erhalten. Lesen Sie die folgenden Implementierungsempfehlungen, um diese Dienste optimal zu verknüpfen.

Der Mehrwert der Cargo Controller Import API besteht darin, alle verfügbaren Daten vollständig auszulesen. Lesen Sie hier mehr über unsere Track-Requests und die verfügbaren Datenfelder.

Die rechtzeitige Verfügbarkeit eines korrekten Importdokuments der Ladung ist einer der 4 Kontrollpunkte eines Terminal. Ohne Importdokument wird die Ladung nicht freigegeben. Das Einreichen eines Importdokuments wird als NID-Meldung beschrieben.

Importdokumentations-Status

Die NID-Meldung wird pro Container in Cargo Controller Import zurückgemeldet. Die Bestätigung erfolgt über die Webhook-Updates; dies wird pro Container im Objekt billOfLading/transportEquipmentDeclarations geteilt.

Achtung! 14 Tage nach Ankunft des Schiff (ATA Vessel) kann eine NID-Meldung nicht mehr mit CCI verknüpft werden.

Beispiel:

"transportEquipmentDeclarations": [
  {
    "equipmentNumber": "CONT9434134",
    "declarations": [
       "DIN"
    ]
  }
],

Implementierungsempfehlung: ATA-Container triggert NID-Meldung (EDI)

Innerhalb des Dienstes NID gibt es keine Kopplung mit Manifest oder Gate-out. Erstellen Sie in Ihrem eigenen System einen Trigger, der die NID-Meldung in dem Moment übermittelt, wenn CC die Entladebestätigung der Ladung erhält.

Die Entladebestätigung wird pro Container im Objekt billOfLading/dischargeReports geteilt.

Beispiel:

"dischargeReports": [
  {
    "equipmentNumber": "CONT9434134",
    "actualDischargeDateTime": "2021-02-28T07:45:00Z",
    "dischargeTerminal": {
        "code": 4810,
        "name": "AMALIAH APMT DSQ",
        "ownerFullName": "APM Terminals Maasvlakte II B.V.",
        "ownerShortName": "APMII"
     }
   }
],

Implementierungsempfehlung: 6 Stunden nach ATA-Container warnen

Sorgen Sie für einen Kontrollmechanismus in Ihren eigenen Systemen. Portbase bietet über seine Webscreens eine Option, um einen E-Mail-Alert zu versenden. Wenn 6 Stunden nach der Entladebestätigung keine NID-Meldung übermittelt wurde, senden wir eine Warnung per E-Mail. 

Diese Meldung können Sie als Benutzer im Webscreen von Cargo Controller Import manuell einrichten. Lesen Sie dazu den Artikel E-Mail-Benachrichtigungen in Cargo Controller Import einrichten Sie können diese Warnung auch in Ihre eigenen Systeme integrieren.

Umleitungen von Schiffen abfangen

Bei Umleitungen von Schiffen wird das Discharge-Terminal aktualisiert, sobald der Schiffsanlauf (und das Manifest) durch die Schifffahrtsagentur aktualisiert wurde. Wenn sich der POD ändert, weil das Schiff kurzfristig umgeleitet wird, muss dieses Verhalten sofort abgefangen werden. In Ihren eigenen Systemen können möglicherweise bereits Dinge wie die NID-Meldung oder Transportaufträge versendet worden sein.

Erstellen Sie eine Warnung, die prüft, ob sich der POD ändert, nachdem Sie dies getrackt haben. 

Der POD wird im Objekt billOfLading/vesselVisit/dischargeTerminal geteilt. 

Beispiel:

"dischargeTerminal": {
    "code": 4810,
    "name": "AMALIAH APMT DSQ",
    "ownerFullName": "APM Terminals Maasvlakte II B.V.",
    "ownerShortName": "APMII"
},

Implementierungsempfehlung: POD ändert sich nach NID-Meldung

Wenn sich der POD ändert, weil das Schiff umgeleitet wird, muss die NID-Meldung beim Terminal des neuen POD eingereicht werden. Die bestehende NID-Meldung beim vorherigen POD muss widerrufen werden. Mehr erfahren? Lesen Sie den Artikel Antrag auf Widerruf des Importdokuments in Notification Import Documentation.

Erstellen Sie in Ihrem System eine Warnung, die prüft, ob sich der POD ändert, während ein Importdokument bekannt war. Der POD wird im Objekt billOfLading/vesselVisit/dischargeTerminal geteilt. 

Beispiel:

"dischargeTerminal": {
    "code": 4810,
    "name": "AMALIAH APMT DSQ",
    "ownerFullName": "APM Terminals Maasvlakte II B.V.",
    "ownerShortName": "APMII"
},

Terminal-Pickup-Daten

Innerhalb der Secure Chain ist der Pickup-Status rund um die Voranmeldung des Transportunternehmen beim Terminal verfügbar geworden. Ab dem Zeitpunkt, an dem nominiert wurde, wird ein Status-Request beim Terminal abgefragt. Dieser Status prüft 4 Werte:

  1. Container vorhanden?
  2. Zollstatus?
  3. Importdokumentations-Status?
  4. Terminal-Status?

Diese 4 Werte werden regelmäßig aktualisiert, wenn das Transportunternehmen die Planung aktualisiert oder die kommerzielle Freigabe angepasst wird. 

Der Mehrwert der Cargo Controller Import API besteht darin, alle verfügbaren Daten vollständig auszulesen. Lesen Sie hier mehr über unsere Track-Requests und die verfügbaren Datenfelder.

Der Pickup-Status wird pro Container im Objekt billOfLading/hinterlandPreNotifications geteilt. 

Darin wird auch geteilt, wann der letzte Update-Zeitpunkt war und welche Modalität für die Abholung der Ladung verwendet wird.

Beispiel:

"hinterlandPreNotifications": [
  {
    "equipmentNumber": "string",
    "dateUpdated": "string",
    "status": "DECLARED",
    "modality": "road",
    "plannedVisit": {
        "eta": "2021-02-28T09:45:00Z",
        "ata": "2021-02-28T08:45:00Z"
      },
    "equipmentStatus": {
        "acceptStatuses": [],
        "rejectReasons": []
      }
   }
],

Implementierungsempfehlung: Terminal-Reject-Reasons identifizieren

Terminals geben bei jedem Update an, wie der Status der 4 Kontrollpunkte ist. Wenn ein Kontrollpunkt noch nicht den richtigen Status hat, gibt das Terminal dies spezifisch mit einem „Reject reason“ zurück. Es kann wertvoll sein, diese Werte zu überwachen und innerhalb Ihrer eigenen Systeme zu warnen. Lesen Sie hier wie dies innerhalb der Webscreens angezeigt wird; das gibt Kontext für die Webhook-Updates.

Pro Kontrollpunkt können mehrere Reject Reasons geteilt werden. Diese werden alle in den Webscreens und in den Webhook-Updates von CCI angezeigt.

Der Reject Reason wird pro Container im Objekt billOfLading/hinterlandPreNotifications/.../equipmentStatus/rejectReasons geteilt.

Beispiele für Reject Reasons:

  • Wenn der Container noch nicht entladen ist, wird der Container den Reject Reason „Container not present“ zurückgeben.  Keine Aktion erforderlich.
  • Wenn die NID-Meldung nicht eingereicht wurde, lautet der Reject Reason: „Import document missing in Portbase, contact forwarder“. Aktion erforderlich.

Beispiel:

"hinterlandPreNotifications": [
  {
    "equipmentNumber": "string",
    "dateUpdated": "string",
    "status": "DECLARED",
    "modality": "road",
    "plannedVisit": {
        "eta": "2021-02-28T09:45:00Z",
        "ata": "2021-02-28T08:45:00Z"
    },
    "equipmentStatus": {
        "acceptStatuses": [
            {
              "type": "AVAILABLE",
              "code": "string",
              "remark": "string"
             }
        ],
        "rejectReasons": [
            {
              "code": "string",
              "terminalDescription": "string",
              "parsedReason": "string"
            }
        ]
      } 
   }
],

Implementierungsempfehlung: Terminal-Zeitfenster

Nicht alle Terminals verlangen ein Zeitfenster oder teilen ein Gate-out. Innerhalb des Containerstatus wird auch der Zeitpunkt geteilt, wenn ein Transportunternehmen ein Zeitfenster am Terminal hat.

Der Pickup-Status wird pro Container im Objekt billOfLading/hinterlandPreNotifications/plannedVisit geteilt.

Beispiel:

"plannedVisit": {
    "eta": "2021-02-28T09:45:00Z",
    "ata": "2021-02-28T08:45:00Z"
},

 

Teil von

War dieser Beitrag hilfreich?

2 von 3 fanden dies hilfreich
Link in die Zwischenablage kopiert