Ontwikkeling


Zoeken

Snel naar

Veelgestelde vragen

Overige

Ontwikkelpunt: Voormeldingen loopt vast door afwijkende ISO-type containers tussen manifest en terminal

Scenario:

  • Rederij registreert op import manifest een containertype ‘2210’
  • De rederij verstuurt release, de keten wordt opgezet en de Inland Operator ontvangt automatisch een ‘status request’ voor bij de terminal.
  • De terminal registreert bij lossing containertype ‘2200’
  • De Inland Operator maakt van de ‘status request’ een voormelding bij de terminal, welke wordt afgewezen wegens afwijkend container type.
    • De Inland Operator kan deze wijzigen, echter niet alle terminals accepteren updates en een nieuwe voormelding is nodig.
    • De Inland Operator creeert een nieuwe voormelding met een aangepast containertype ‘2200’, echter die wordt na voormelden direct overschreden met ‘2210’ zolang het manifest niet is bijgewerkt.

Rollen:

  • Rederij
  • Terminal
  • Inland Operator(s)

Services:

  • MLI
  • MCA

Resultaat:

  • Voormelding wordt afgewezen.
  • Rederij heeft geen zicht op container type afwijkingen tussen manifest en terminal, release heeft geen impact op container type. Rederij moet actief worden benaderd door Release-to party voor bijwerken manifest.

Workaround:

  • De Inland Operator moet zijn voormelding intrekken en opnieuw versturen nadat het manifest is aangepast indien de terminal in kwestie geen updates accepteert op een voormelding.
  • Alle partijen wachten tot het manifest bijgewerkt is door de rederij.
  • De Inland Operator kan een nieuwe voormelding indienen, of bestaande updaten (indien mogelijk), met het aangepaste container type.

Planning oplossing:

  • Dit scenario bestond al in de havenlogistiek voor de introductie van de Vertrouwensketen. Portbase en de Vertrouwensketen zijn in gesprek met alle aangesloten partijen om hier een technische oplossing voor uit te werken. Q4 2024.

Heeft u gevonden wat u zocht?

Ontwikkelpunt: Dubbele releases (met en zonder pincode)

Scenario:

  • Rederij verstuurd zowel een pincode release als Vertrouwensketen release uit.
  • Rederij ontvangt een rejection melding op de Vertrouwensketen release van de terminal. Rejection reason ‘Duplicate Error’ doordat er al reeds een pincode release is geregistreerd voor deze container.
  • Portbase heeft geen invloed op de pincode release
  • Portbase registreert Vertrouwensketen release als de enige waarheid
  • Inland Operator kan geen voormelding maken wegens afwijkende ‘Accept reference’

Rollen:

  • Rederij
  • Terminal
  • Inland Operator(s)

Services:

  • Melding Lading Import
  • Melding Container Achterland

Resultaat:

  • Voormelding wordt afgewezen.
  • Rederij heeft geen zicht op container type afwijkingen tussen manifest en terminal, release heeft geen impact op container type. Rederij moet actief worden benaderd door Release-to party voor bijwerken manifest.
  • Het corrigeren van een pincode release naar een Verrtouwensketen release

Workaround:

  • Rederij moet de ‘rejection reason’ verhelpen en opvolgen met een passende update.
    • De rederij moet de pincode release verwijderen via het webportaal van de terminal.
    • De rederij moet de release opnieuw versturen (update) via Vertrouwensketen nadat de release verwerkt is. Het verwerken van deze update kan tussen de 20 min en 1 uur duren. Dit is afhankelijk van alle partijen en de wijze waarop zij technisch zijn aangesloten.
  • De Inland Operator moet zijn voormelding intrekken en opnieuw versturen indien de terminal in kwestie geen updates accepteert op een voormelding.

Planning oplossing:

Als alle releases via de Vertrouwensketen verlopen zal dit scenario verdwijnen. Medio 2025.

Heeft u gevonden wat u zocht?

Ontwikkelpunt: Meerdere releases voor (groupage) container

Scenario:

  • Meerdere B/L’s zijn actief voor 1 container, rederij releast voor alle B/L’s op 1 container.
    • De Vertrouwensketen is ingericht voor 1 unieke release per B/L en container combinatie.
    • Portbase verstuurt alleen de eerste release door naar de terminal. De overige releases worden geweigerd: ‘Duplicate error’.

Rollen:

  • Rederij
  • Release-to Party

Services:

  • MLI

Resultaat:

  • Release-to Party’s krijgen voor alle B/L combinaties een 'Delivery note' vanuit de rederij, maar er is maar 1 B/L actief met een commerciële release binnen de Vertrouwensketen.

Workaround:

  • De rederij moet alle overbodige releases verwijderen

Planning oplossing:

  • Per rederij verschilt de voortgang, de meeste rederijen hebben een oplossing hiervoor actief. Medio oktober 2024.

Heeft u gevonden wat u zocht?

Ontwikkelpunt: Losterminal gewijzigd na release

Scenario:

  • Losterminal wijzigt nadat rederij release heeft verstuurd.

Rollen:

  • Rederij
  • Terminal
  • Release-to Party
  • Cargo Director(s)
  • Inland Operator(s)

Services:

  • MLI
  • Cargo Controller
  • Cargo Release Manager
  • MCA

Resultaat:

  • Een eerder geaccepteerde voormelding bij de terminal is niet meer geldig.
  • Rederijen moeten alle releases intrekken en opnieuw verstrekken naar de nieuwe terminal.
  • Alle ketenpartners verliezen hun release totdat de nieuwe release beschikbaar is gekomen.

Workaround:

  • De Inland Operator moet zijn voormelding intrekken.
  • Alle partijen wachten tot de nieuwe release beschikbaar is. Het verwerken van de update van releases kan tussen de 20 min en 1 uur duren.
  • De Inland Operator kan een nieuwe voormelding indienen als de keten is hersteld bij de nieuwe terminal.

Heeft u gevonden wat u zocht?

Ontwikkelpunt: Release wordt geweigerd door terminal

Scenario:

  • Een release kan worden afgewezen door de terminal 
  • Een release termijn kan verlopen en na de release deadline worden afgewezen door de terminal 

Rollen:

  • Rederij
  • Terminal

Services:

  • MLI
  • MCA

Resultaat:

  • Bestaande ketens met Vertrouwensketen releases blijven actief, de release is echter niet meer geldig bij de terminal
  • De voormelding in MCA geeft een rode bol bij commerciele release met de melding COR 
  • De release is niet verwerkt door de terminal, de rederij moet hier actie in ondernemen. 

Workaround:

  • Een release termijn kan verlopen, waarbij een update gestuurd kan worden met een nieuwe datum. De terminal kan deze update weigeren met een ‘rejection’ melding als gevolg.
    • Rederij moet de ‘rejection reason’ verhelpen en opvolgen met een passende update.
  • Een release is door de rederij bij de terminal gewijzigd via het webportaal van de terminal of de eerdere release is nog buiten Portbase verlopen.
    • Indien de release buiten Portbase (PCS) om is verlopen moet de rederij de pincode release bijwerken via het webportaal van de terminal.
    • Indien de release via Portbase (PCS) had moeten verlopen, moet de pincode release ingetrokken worden bij de terminal. Daarna een PCS-release verwerken.
  • Indien de release via Portbase (PCS) is verlopen, maar daarna in de terminal webportal is bijgewerkt moet de volledige release ingetrokken worden.
    • Dit stopt de volledige actieve keten tot de release opnieuw is verstrekt.
    • Een nieuwe release verstoord de een voormelding van de Inland Operator bij een terminal. Deze zal opnieuw voorgemeld moeten worden volgens de regels die bij de terminal in kwestie gelden.

Planning oplossing:

  • Als alle releases via de Vertrouwensketen verlopen zal dit scenario minder voorkomen. Medio 2025.

Heeft u gevonden wat u zocht?

Ontwikkelpunt: Onterechte ‘niet genomineerd’ melding bij voormelding ECT

Scenario:

  • Containers die eerder via de Vertrouwensketen zijn doorlopen en afgehandeld zijn bij een ECT terminal kunnen vastlopen op een nieuwe voormelding.
  • ECT meldt onterecht aan de Inland Operator dat deze niet is geautoriseerd om de container voor te melden bij de terminal.
  • Scenario is bij Portbase Customer Service bekend als ‘Sticky container’

Rollen:

  • Rederij
  • Inland Operators

Services:

  • MCA

Resultaat:

  • Voormelding wordt geweigerd wegens openstaande nominatie van eerdere release proces.

Workaround:

  • De openstaande release moet afgesloten worden door Portbase via een Customer Service ticket.

Planning oplossing:

  • De oplossing is live sinds Juli 2024.
  • Dit scenario kan alleen nog voorkomen bij containers die voor juli zijn gereleased.

Heeft u gevonden wat u zocht?

Ontwikkelpunt: De Vertrouwensketen bevat maximaal 2 Cargo Directors

Scenario:

Indien een keten met meerdere partijen actief is, is de maximale keten binnen Cargo Controller of Cargo Release Manager beperkt tot 3 partijen:

  • Release-to Party
    De klant van de rederij en de first release to party in de keten ontvangt automatisch deze rol zodra de rederij de vertrouwensketen heeft opgestart. De release to party kan een volgende partij in de keten autoriseren: deze wordt de Cargo Director.
  • Cargo Director
    Deze partij kan nu een vervoerder nomineren of een volgende partij, bijvoordeeld een expediteur aanwijzen als Cargo Director. 
  • Cargo Director
    Deze partij moet nu een vervoerder nomineren.

Rollen:

  • Rederij
  • Release-to Party
  • Cargo Director(s)

Services:

  • Cargo Controller
  • Cargo Release Manager

Resultaat:

  • De laatste Cargo Director loopt vast in de keten en kan nu alleen nog een Inland Operator nomineren.
  • Dit vindt plaats op minder dan 1% van alle releases die via de Vertrouwensketen plaats vinden.

Workaround:

  • Optie 1: De keten slaat een partij over in de vertrouwensketen, de laatste geautoriseerde Cargo Director moet een Inland Operator nomineren.  

Planning oplossing:

  • Er wordt gewerkt aan een technische oplossing om een langere keten toe te staan binnen de Vertrouwensketen.
  • Medio oktober 2024

Heeft u gevonden wat u zocht?