Ontwikkeling

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.

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.

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.

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.