Release notes
Toelichting release notes
Wij maken onderscheid tussen twee verschillende onderdelen waarop wij verbeteringen doorvoeren:
Het Nextlogic Informatie Platform: de webomgeving van de integrale planning: http://www.nextlogic-planning.com
De ‘optimizer’: het algoritme dat de integrale planning berekent.
Ga naar:
Release notes - 2026
In de releases hebben we een aantal belangrijke verbeteringen doorgevoerd die bijdragen aan een stabielere, betrouwbaardere en beter voorspelbare planning. Daarnaast zijn er functionele uitbreidingen en aanpassingen die de gebruikservaring en operationele nauwkeurigheid verbeteren.
Release notes Nextlogic Informatie Platform week 18 – 2026
Fixed windows niet als eerste in restrictie
Deze functionaliteit wordt aangezet vanaf maandag 4 mei
De afgelopen tijd is er veel gesproken over het gebruik van restricties in combinatie met fixed windows. Hierbij is gebleken dat dit tot oneerlijke of zelfs onuitvoerbare planningssituaties kan leiden. Bijvoorbeeld: een andere call kan de plek innemen van jouw fixed window call, jouw fixed window call wordt te laat ingepland of er is een oneerlijke verdeling van reguliere calls. Zulke situaties zijn ongewenst.
Vanuit de gebruikers is aangegeven dat een fixed window call binnen zijn marges plannen belangrijker is dan een restrictie die gehonoreerd wordt. Daarom hebben jullie ervoor gekozen om een fixed window call die (niet als eerste) in een restrictie staat niet meer mee te nemen in de planning tenzij het de eerste call is in de restrictie.
Wat houdt dit precies in?
Restricties worden ingevoerd in MCA of in de eigen BOS. Daarom blijft het technisch mogelijk om een restrictie in te voeren van een reguliere call voor een fixed window call. Maar deze fixed window call wordt niet meer meegenomen in de restrictie bij het maken van de planning.
Ons advies is: Zet een fixed window call niet meer achteraan in een restrictie. Dit helpt namelijk voor het eigen overzicht. In het Nextlogic platform zal een operationele waarschuwing worden gegeven dat de fixed window call niet wordt meegenomen in de restrictie.
Mocht er echter toch nog een fixed window in een restrictie ingevoerd worden, dan geven onderstaande voorbeelden weer hoe wij de restrictie meenemen in de planning.
Een fixed window call kan alleen nog in de eerste groep van een restrictie staan. De aanhalingstekens geven een groep aan.
Ingevoerd door barge operator | Meegenomen in de planning |
‘FW’ → ‘A’ | ‘FW’ → ‘A’ |
‘A’ → ‘FW’ | - |
‘FW en A’ → ‘B en C’ | ‘FW en A’ → ‘B en C’ |
‘A en B’ → ‘FW en C’ | ‘A en B’ → ‘C’ |
‘FW’ → ‘FW’ | - |
‘A en B’ → ‘C’ → ‘FW’ | ‘A en B’ → ‘C’ |
Kan ik nog een call voor mijn fixed window afhandelen?
Dat kan nog steeds, maar alleen als er genoeg tijd is tussen de aankomst (scope-in) en het begin van het fixed window, én als er plek is op de terminal. Let op: dit is niet gegarandeerd.
Wil je zeker weten dat een reguliere call vóór je fixed window call wordt uitgevoerd? Dan kun je de fixed window code verwijderen. In dat geval wordt de restrictie wél meegenomen in de planning. De fixed window call wordt dan als reguliere call gepland en er zal geen rekening worden gehouden met de window tijden.
Omdat de marges (aan de voorkant) van de fixed windows op veel terminals verruimd zijn, kan het een keuze zijn om een vroegste start BO in je fixed window call te zetten zodat er meer ruimte is op een call voor je fixed window call. Realiseer hierbij echter wel dat dit geen garantie geeft dat er ook daadwerkelijk een andere call voor je fixed window call gepland wordt.
Wij adviseren om je rotaties zo in te richten dat:
de fixed window call aan het begin van de rotatie zit, of
de volgorde binnen de rotatie niet uitmaakt voor de fixed window.
Overboekte fixed windows verlengen aan het eind
Fixed window calls die overboekt worden en waarvan de overboeking is geaccepteerd door de terminal krijgen een langere callduur dan de initiële fixed window call groot is. Dit kan betekenen dat de marge van 2 uur na de fixed window eindtijd al is bereikt en daarom kan het soms moeilijk zijn om een window goed in te plannen. Vanaf nu wordt de fixed window eindtijd verlaat op basis van het aantal moves dat het window overboekt is en de gemiddelde kraansnelheid. Dus stel dat een fixed window van 200 moves wordt overboekt met 40 moves en de gemiddelde kraansnelheid op de betreffende terminal is 20, dan wordt de fixed window eindtijd twee uur later. Als er meerdere calls in één fixed window worden aangemeld, wordt de fixed window eindtijd voor beide calls verlengd.
Negeren fixed window marges bij dummy calls
De marges op fixed window calls zijn per terminal verschillend. Op RWG en APM2 zijn recent de marges aan de voorkant verlengd naar 24 uur zodat de fixed window calls flexibeler ingepland kunnen worden. Echter is het doel van de dummy calls om de exacte tijden te reserveren voor fixed window calls die nog niet zijn aangemaakt. Daarom worden vanaf nu de dummy calls ingepland binnen het afgesproken fixed window venster zonder de marges.
Barge operator kan ook niet deelnemende terminal tijden updaten
Als de afgesproken tijden van een niet deelnemende terminal veranderen, is het noodzakelijk om dit ook direct te verwerken in Nextlogic omdat het effect heeft op de planning van de gehele rotatie. Momenteel zijn hier twee mogelijkheden voor; een nieuw verzoek inschieten in Portbase of de ‘Schipper afgesproken aankomsttijd/vertrektijd’ invullen in de “bargeacties” pagina in Nextlogic. Dit laatste kon voorheen alleen gedaan worden door schippers. Vanaf nu zijn deze velden in de “bargeacties” pagina ook zichtbaar en aanpasbaar voor barge operators. In de call details worden de velden weergegeven maar zijn ze niet aanpasbaar.
Verbeteringen in de barge acties pagina voor schippers
Afgelopen februari is er weer een online schipperssessie geweest. Daar werd besproken of het barge actie scherm in het Nextlogic Informatie Platform helemaal naar wens functioneert. Hierin kwam naar boven dat de automatische refresh setting binnen deze pagina als default uit staat. Vanaf nu staat voor iedereen de default op 10 minuten.
Daarnaast gaven de schippers aan dat de rotatie die als laatst geopend is niet geselecteerd blijft als de pagina gerefresht wordt. Dit is ook verholpen, vanaf nu blijft de laatst geopende rotatie geselecteerd na refreshen.
Release notes Nextlogic Informatie Platform week 12 – 2026
Sluitingstijden per kade
Voorheen kon een terminal alleen aangeven of de héle terminal een incidentele sluiting had. Vanaf nu kan een terminal hier ook per kade aangeven of de incidentele sluiting van toepassing is. Bijvoorbeeld alleen DDE, maar DDN blijft in bedrijf.
Een aanvullende handleiding zal met de terminals gedeeld worden, omdat deze functionaliteit op nieuwe locatiepagina’s is gebouwd welke visueel aangepast zijn.
Het verbergen van alle niet actieve operationele waarschuwingen
Voorheen werden op de pagina van operationele waarschuwingen alle waarschuwingen laten zien, ook van calls die al waren uitgevoerd. Vanaf nu worden hier ook alleen de waarschuwingen laten zien van calls die nog niet zijn uitgevoerd en waar dus wellicht naar gehandeld moet worden. Binnen de call en rotatie details pagina's was dit al het geval, dus nu bevatten alle pagina's dezelfde informatie.
Je kan op twee manieren naar de pagina met operationele waarschuwingen:
De mogelijkheid tot het uitzetten van fixed window dummy calls per terminal of fixed window
In het geval dat bij een terminal voor een langere periode het reguliere fixed window programma niet (volledig) uitgevoerd kan worden, kan er per terminal gekozen worden om de dummy calls uit te schakelen.
Ook kan een barge operator het aanmaken van dummy calls voor een specifieke fixed window code uitzetten als hij voor langere periode niet van plan is zijn fixed window code te gebruiken. Op deze manier wordt er geen plek gereserveerd voor een call die niet plaats zal vinden.
De uitleg over de dummy calls is te vinden in de release notes van week 48 in 2025.
Verbetering selectie calls in iteraties
De gehele planningspuzzel is heel ingewikkeld en onmogelijk om in één keer te optimaliseren. Daarom doet de optimizer steeds stapjes in de puzzel, iteraties genoemd. Per iteratie wordt er steeds een groepje calls van de planning geselecteerd om de planning te verbeteren. Er is een verbetering doorgevoerd in het bepalen welke calls samen opgepakt worden in een iteratie.
Overgang zomertijd en wintertijd
De overgang tussen zomer en wintertijd werd niet goed berekend voor de uitrol van pauzes en ploegwissels. Daardoor konden calls niet optimaal worden gepland rondom de overgang van wintertijd naar zomertijd en andersom. Door de aanpassing sluiten pauzes en ploegwissels en geplande afhandelcapaciteit tijdens de overgang van winter naar zomertijd op elkaar aan. Hierdoor kunnen calls over de sluiting heen worden gepland. De call start dan voor de sluiting en eindigt na de sluiting waarbij de sluitingstijd aan de call duur wordt toegevoegd. Grote calls zullen op de kade gepland blijven en beschikbare afhandelcapaciteit wordt optimaal gebruikt.
Betere vergelijking laat geplande calls
De optimizer rekent zoveel mogelijk opties door om de planning te verbeteren. Bij iedere iteratie van de optimizer berekent de optimizer duizenden scenario’s op zoek naar de beste planning. In een aantal scenario’s werd de beste planning van calls niet goed berekend. Daardoor werden laat geplande calls in de planning niet altijd gewisseld met minder laat geplande calls. Door de aanpassing is de kans groter dat een laat geplande call in de planning wordt gewisseld met een minder laat geplande call.
Bugfix
Er werden onterecht foutmeldingen gegeven op fixed window afspraken bij niet deelnemende terminals, hier is een oplossing voor gevonden.
Release notes Nextlogic Informatie Platform week 7 – 2026
Terminal operators kunnen ATD verwijderen
Soms krijgt een call onterecht een ATD (Actual Time of Departure) als de barge bijvoorbeeld tijdelijk net buiten het geofence vaart en daardoor als afgesloten wordt beschouwd. Voorheen kon in deze gevallen alleen Nextlogic hier de ATD verwijderen waarna de call weer geactiveerd werd. Vanaf nu hebben ook terminal operators de mogelijkheid om via de kadeplanning of de call details de geregistreerde ATD te verwijderen.
Hulpteksten toegevoegd aan knoppen in de kadeplanning
In de kadeplanning was er eerst geen duidelijke omschrijving waar de individuele knoppen op bijvoorbeeld calls of beschikbaarheden voor dienden. Wij hebben dit nu toegevoegd als hulptekst die verschijnt wanneer je met je cursor over de knoppen heen beweegt.
Dit geeft bijvoorbeeld de volgende uitleg:
Aangepaste barge lengte wordt ook correct in de call details getoond
Er zijn situaties waarbij de barge operator een aangepaste barge lengte opgeeft in Portbase. In de kadeplanning wordt dit ook correct getoond op basis van de gebruikte bolders. Maar wanneer de call details werden geopend dan werd de originele barge lengte getoond. Dit zorgde ervoor dat er onduidelijkheid was bij de terminals over de aangemelde lengte van de barge. Nu wordt de correcte barge lengte getoond wanneer deze afwijkt van de originele barge lengte.
Operationele waarschuwing als onbeschikbaarheid conflicteert met prio venster
Er werd al rekening gehouden met de onbeschikbaarheid van barges in combinatie met fixed windows. Dit was nog niet het geval voor de onbeschikbaarheid van een barge in combinatie met een opgegeven prio window. Vanaf nu is daar de onderstaande melding voor zichtbaar. Terminal operator en barge operator kunnen zo zien dat er een reden is dat de call niet binnen zijn prio venster gepland wordt.
Bugfix
Er is een verbetering doorgevoerd voor het invoeren van tijden door de schippers. Dit kon eerst in sommige talen alleen per half uur, nu kan het weer op de minuut nauwkeurig.
Ter info: Voorbereiding En/Of restrictie
De voorbereidingen voor de En/Of restrictie zijn gedaan in het platform. Dit is al zichtbaar aan het kenmerk van de “En” restrictie. De “Of” restrictie zal zodra alle aanpassingen en implementaties aan de kant van Portbase uitgevoerd zijn in gebruik genomen worden. Wij zullen dit op een later moment uitgebreider toelichten.
Release notes - 2025
Release notes Nextlogic Informatie Platform en Optimizer week 50 – 2025
Aanpassen van beschikbaarheden makkelijker
Beschikbaarheden in het Nextlogic Informatie Platform zijn makkelijker aan te passen door de terminal operator. Dit zorgt ervoor dat er minder herplanningen nodig zijn als gevolg van het aanpassen van een beschikbaarheid. Terminal operators hebben hier een aparte handleiding van ontvangen.
Indicatie waar de vroegste start op gebaseerd is
In het Nextlogic Informatie Platform is vanaf nu te zien waar de vroegste start op gebaseerd is. Dit is te zien wanneer je over de infoknop heen beweegt met je muis. Dit kan in de Call details van de kadeplanning en in de Call details zelf.
De vroegste start kan bepaald worden door:
Vroegste start BO/TO
Scope-in
Voorgaande call
ATAT (wanneer de call al bij de terminal is)
ATSO (wanneer de call al in operatie is)
FW start
Prio window
Verplichte beschikbaarheid
Voorbereidingstijd
Fixed window marges per terminal
Momenteel staan de fixed window marges voor alle terminals gelijk; 4 uur voor het window en 2 uur na het window. Dit betekent dat de fixed window call 4 uur eerder mag beginnen en maximaal 2 uur later mag eindigen. Vanaf nu kunnen de marges per terminal ingesteld worden. De standaard blijft nog steeds 4 uur en 2 uur. Wanneer een terminal besluit hier een aanpassing in te doen zal dat tijdens het wekelijkse BO/TO overleg aangekondigd worden. Grotere marges in de integrale planning geven meer ruimte om problemen te voorkomen en meer mogelijkheid om reguliere calls te plannen tussen fixed windows.
Kleine verbeteringen
Incidentele sluiting van TO wordt meteen opgeslagen. Voorheen moesten terminals na het opgeven van de sluiting ook nog de onderliggende beschikbaarheden opslaan, dat is nu niet meer nodig.
Verbeteringen doorgevoerd in de zichtbaarheid van de geplande tijden van de hele rotaties.
Bugfix voor het invoeren van tijden van de schippers. Dit kon eerst in sommige talen alleen per half uur, nu kan het weer op de minuut nauwkeurig.
Release notes Nextlogic Informatie Platform en Optimizer week 48 – 2025
Accuratere scope-in berekening
Om realistischer te plannen en dynamiek te voorkomen berekent Nextlogic een verwachte aankomsttijd op basis van de actuele locatie van de barge. Deze geeft beter weer wanneer een barge in de praktijk kan worden verwacht, vooral binnen de korte termijn.
Momenteel wordt de verwachte aankomsttijd 3 uur voor de opgegeven gewenste aankomsttijd berekend en wordt de daadwerkelijke aankomsttijd bepaald door de scope-in locatie. Vanaf nu start de berekening 96 uur voor de gewenste aankomsttijd en wordt voortdurend geupdated. Voor elke barge wordt de locatie berekend via AIS. Deze update zal de kijkhorizon en de rekenfrequentie dus aanzienlijk uitbreiden.
De verwachte aankomsttijd zal nooit voor de opgegeven aankomsttijd zijn, dus een barge operator kan nog steeds zelf zijn gewenste scope-in opgeven en alleen vertragingen daarop worden doorgerekend.
Icoon voor het aantal kranen in een beschikbaarheid
In de kadeplanning is vanaf nu een icoon te zien op beschikbaarheden die aangeeft hoeveel kranen op de beschikbaarheid staan. Dit is niet te zien op het ‘Binnenlandse calls’ overzicht, maar alleen door het ‘Beschikbaarheden’ overzicht te selecteren in de kadeplanning.
Per beschikbaarheid zie je nu linksboven in elke beschikbaarheid hoeveel kranen er beschikbaar zijn.
Dummy fixed window calls
Een paar weken geleden is de planhorizon voor fixed windows verlengd naar 7 dagen. Dit is gedaan zodat er geen reguliere calls op de plekken van een fixed window gepland worden. Hierdoor is er minder herplanning nodig en wordt er dus een stabielere planning gecreëerd. Echter, niet alle fixed windows worden al 7 dagen van tevoren aangemeld. Daarom introduceren wij Dummy calls die het plekje van het fixed window reserveren totdat de fixed window daadwerkelijk aangemeld wordt. Deze calls zijn te herkennen aan de naam ‘Dummy’ en het icoon rechtsboven.
Hoe werkt dit precies?
De dummy calls worden voor elke fixed window code aangemaakt en 7 dagen van tevoren ingepland. Elke dummy call heeft een lengte gebaseerd op het aantal moves zoals vastgelegd in het window. Deze call wordt in het fixed window gepland. Op het moment dat er een call wordt aangemeld met deze fixed window code wordt de dummy call uit de planning gehaald. Mocht de aangemelde call dus korter of langer duren, kan dat nog zorgen voor wat dynamiek, maar velen malen minder dan zonder de dummy call.
Als er nog geen call is aangemeld op de fixed window code, 3 dagen van tevoren, wordt de dummy call alsnog uit de planning gehaald en komt die capaciteit vrij voor andere calls. Het is dus belangrijk om de fixed window calls op tijd aan te melden. Wanneer aanmeldingen later gedaan worden dan 3 dagen van tevoren moet de terminal beoordelen of het fixed window nog ingedeeld kan worden wat kan leiden tot dynamiek in de planning.
Highlight overboekte/laat aangemelde fixed windows
In de lijst van de overboekte/laat aangemelde fixed windows is nu een zaklamp icoon te zien, die kan je gebruiken om meteen naar de bijbehorende call op de kade te gaan.
Daarnaast kan het ook de andere kant op. De calls in de kadeplanning hebben een vergrootglas icoon gekregen en als je daarop klikt dan wordt de juiste fixed window in het linker paneel gehighlight. Let op: dit werkt alleen voor de calls die ook echt in het linker paneel voorkomen.
Laatste vroegste start BO/TO is leidend
Voorheen kon de vroegste start BO niet ingevuld worden wanneer de vroegste start TO was ingevuld en andersom. Vanaf nu kan dat wel en zal er een checkmark te zien zijn in de call details om duidelijk te tonen welke vroegste start leidend is op dat moment.
De logica voor het bepalen van de leidende vroegste start is als volgt:
De vroegste start TO is leidend, behalve als de vroegste start BO later is ingevuld én later in de tijd ligt. Indien de laatst ingevulde waarde ongeldig is, door bijvoorbeeld de voorbereidingstijd of Los-/laad lijst-sluiting, wordt de vorige geldige waarde behouden en krijgt de gebruiker een foutmelding getoond dat het nieuwe tijdstip ongeldig is.
In bovenstaand voorbeeld is de vroegste start BO dus eerder ingevuld dan de vroegste start TO.
Kleine verbeteringen
Operationele waarschuwing 403 ‘Er is geen of onvoldoende beschikbaarheid voor de fixed window call’ werd voorheen getoond wanneer de fixed window niet volledig in één enkele beschikbaarheid paste. Vanaf nu controleert het systeem ook aangrenzende beschikbaarheden.
Het is niet langer mogelijk om handmatig een ‘Desired time of arrival’ (DTAS) in het verleden in te vullen.
De naam ‘Vroegste start voorgaande call’ in de Call details is gewijzigd naar ‘Vroegste start’. Na de volgende release wordt ook zichtbaar waarop deze waarde is gebaseerd.
De zoekfunctie in de kadeplanning is verbeterd: de gebruiker kan nu blijven typen, zelfs wanneer er vertraging zit tussen toetsaanslagen.
Na het zoeken naar een barge wordt deze automatisch bovenop weergegeven als deze gepland staat in een overlap, zodat de gebruiker deze direct kan aanklikken.
Release notes Nextlogic Informatie Platform en Optimizer week 41 – 2025
Fixed windows eerder ingepland
Om te voorkomen dat reguliere calls op de plek van een fixed window terechtkomen, worden fixed windows voortaan verder vooruit ingepland.
Voorgaande situatie: rotaties met een scope-in binnen nu en 3,5 dag worden in zijn geheel ingepland.
Nieuwe situatie: rotaties met een scope-in binnen nu en 3,5 dag worden in zijn geheel ingepland, maar voor fixed windows geldt een aparte planhorizon van 7 dagen.
Dit betekent dat fixed windows die plaatsvinden tussen nu en 7 dagen al ingepland worden, ook als de scope-in van de bijbehorende rotatie nog buiten de 3,5 dag valt. De reguliere calls in de bijbehorende rotatie worden nog niet ingepland.
Hiermee streven we naar meer rust en stabiliteit in de lange termijn planning.
Beter aansluiten van calls op een kade
Het systeem lost overlappende calls meestal op door calls lineair door te schuiven, dat betekent dat als er uitloop op de call voor jou is, jouw starttijd wordt mee geschoven. Hierdoor blijft er soms ongebruikte ruimte op de kade over. Met een nieuw mechanisme worden calls nu automatisch meer naar voren geschoven als de call eerder beschikbaar is, zodat de beschikbare ruimte op de kade beter benut wordt.
Vroegste start wordt weergegeven in de kadeplanning
In de call details in de kadeplanning wordt nu de vroegste start weergegeven.
Dit kan gebaseerd zijn op de vorige call (eindtijd van de vorige call + vaartijd), of op de opgegeven vroegste start van de BO of TO.
Het systeem gebruikt deze waarde in de planning.
Zie onderstaand screenshot voor de exacte locatie.
Uitbreiding in de fixed window validatie e-mail
E-mails over de validatie van de overboekte fixed windows bevatten nu ook de betreffende kade, de terminal en het MCA call ID.
Terminal kan nu de bolderposities aanpassen
Terminal operators kunnen voortaan de bolderpositie van een barge aanpassen wanneer een call al in operatie is en op een andere positie wordt afgehandeld dan oorspronkelijk gepland.
Dit kan door op een call die in operatie is in de kadeplanning te klikken en dan op het potloodje te klikken van het ‘Planning’ segment.
Hier kun je de velden ‘Actuele van bolder’ en/of ‘Actuele tot bolder’ aanpassen.
Als één van deze waarden wordt gewijzigd, past het systeem de andere automatisch aan.
Een call geldt als “in operatie” zodra er een first move is gedaan en dus de ATFM in de call details is ingevuld.
Release notes Nextlogic Informatie Platform en Optimizer week 37 – 2025
Dual Berthing
We hebben een belangrijke verbetering toegevoegd aan het systeem: Dual Berthing.
Wat is Dual Berthing?
Bij Dual Berthing wordt een lange kade efficiënter gebruikt. Aanmeren, afmeren, voorbereiding en afronding van een lichter kunnen gedaan worden tegelijk met de operatie van een andere call. In plaats van dat een lichter moet wachten met aanmeren totdat de kraan beschikbaar is, kan deze alvast naast een lichter in operatie aanmeren op andere bolder posities. Zodra de kraan klaar is met de eerste lichter, verplaatst de kraan naar de andere lichter.
Snellere afhandeling: aan- en afmeer tijd wordt gewonnen in de planning.
Toe te passen bij onderhoud: dit zal vooral voorkomen wanneer een terminal tijdelijk minder kranen op een lange kade beschikbaar heeft.
Automatische herkenning
Het systeem herkent automatisch wanneer Dual Berthing mogelijk is en plant dit vervolgens in, zonder dat daar extra handelingen van de gebruiker voor nodig zijn. Dit zal terug te zien zijn in de kadeplanning als calls om en om op bolderposities worden gepland. Dit is dus alleen het geval als de kade lang genoeg is om twee lichters naast elkaar te hebben liggen en er maar 1 kraan op dat stuk kade is. Dual Berthing is aan/uit te zetten per terminal. Mocht je hier als terminal interesse in hebben, neem dan contact op met Nextlogic.
Aansluiten van calls
We hebben een verbetering van de optimizer doorgevoerd met betrekking tot het aansluiten van calls. Hierdoor zullen calls minder snel in overlap gepland worden.
Release notes Nextlogic Informatie Platform en Optimizer week 32 – 2025
Te laat aangemelde fixed window calls
Volgens de werkafspraken moeten fixed window calls uiterlijk 5 dagen voor de start van het window aangemeld worden, echter gebeurt dit niet altijd. Daarom hebben we hier een validatie op gemaakt; vanaf nu zal een aangemelde fixed window die start binnen de validatiehorizon eerst moeten worden beoordeeld door de terminal. Wel zullen we deze validatie gefaseerd invoeren. We zetten de validatiehorizon vanaf komende maandag (11 augustus) eerst op 2 dagen, twee weken later (25 augustus) op 3 dagen en daarna besluiten we wanneer we het naar 4 en 5 dagen zetten.
Voorbeeld:
Fixed window afspraak is woensdag 12:00 - 16:00.
Validatiehorizon staat op 2 dagen.
BO meldt op maandag op 17:00 fixed window call aan voor woensdag.
Deze wordt eerst ingepland als regulier. De terminal kan beoordelen of deze call alsnog als fixed window gepland moet worden.
Ben je barge operator? Lees dit:
Zorg dat je fixed window call minimaal 2 dagen voor de starttijd van het window is aangemeld via MCA. Meld je later een window aan of voeg je een window toe aan een bestaande call dan wordt deze ingepland als reguliere call. Jij krijgt dan een operationele waarschuwing:
“Deze fixed window call wordt momenteel niet als FW behandeld in de planning.”
Het is aan de terminal om te bepalen of de call als fixed window of als reguliere call wordt gepland. Zij kunnen dit beoordelen in de kadeplanning.
Zolang dit nog niet gedaan is door de terminal zal de operationele waarschuwing op de call blijven staan en de call als reguliere call gepland blijven. Het kan wellicht nuttig zijn om de terminal te bellen om te vragen of ze een beslissing hierover kunnen maken.
Nadat de terminal besloten heeft dat de call als fixed window gepland mag worden, verdwijnt de operationele waarschuwing en wordt de call als fixed window gepland. Mocht de terminal besluiten dat het niet meer mogelijk is om de call als fixed window in te plannen, blijft de operationele waarschuwing actief en zal de call ingepland blijven als reguliere call.
Ben je terminal operator? Lees dit:
Nadat een barge operator een fixed window call aanmeldt binnen de validatiehorizon verschijnt de call in het platform in de ‘Kadeplanning'. Jij als terminal operator kan hier beoordelen of deze call nog als fixed window gepland gaat worden. Gebruik hiervoor de groene knop ‘Als FW’. Is dit niet mogelijk in de huidige planning, gebruik dan de rode knop ‘Als regulier’ waarna de call als reguliere call ingepland blijft.
Let op! Last minute toevoegen van fixed windows zal resulteren in onrust in de planning omdat er hoogstwaarschijnlijk al andere calls ingepland zijn. Fixed windows hebben altijd voorrang op reguliere calls dus de calls die daar gepland liggen worden naar een later moment herpland.
Aangevraagde start- en eindtijden verborgen als plantijd bekend
Voor calls op deelnemende terminals zullen de aangevraagde start- en eindtijden verborgen zijn zodra er een plantijd bekend is. Dit is omdat wij voor deelnemende terminals niet plannen op basis van deze waarden en daarom kunnen en verkeerde conclusies uitgetrokken worden. Mocht het gebeuren dat een call uitgepland wordt, dan worden de aangevraagde tijden wel weer zichtbaar. Voor niet-deelnemende terminals zullen de aangevraagde tijden altijd zichtbaar blijven.
Drop-down voor reden wijziging van beschikbaarheid
Als de beschikbaarheid van een terminal wordt gewijzigd binnen 24 uur voor start van de beschikbaarheid, dient de terminal momenteel al een reden voor de wijziging opgeven. Tot nu toe was dit vrije input door middel van een pop up, maar die werd niet altijd correct ingevuld. Daarom is de pop up veranderd in een drop-down waar een keuze uit gemaakt moet worden.
Verbeteringen in de Optimizer
Achter de schermen is er weer hard gewerkt aan verbeteringen in de Optimizer. Denk aan het oplossen van kleine bugs en het verbeteren van de performance.
Release notes Nextlogic Informatie Platform en Optimizer week 29 - 2025
Verbetering van planning met meerdere kranen
ECT en Euromax werken met kraanbeschikbaarheid. Soms werken er na elkaar twee verschillende kranen op (deels) dezelfde bolderposities. Tot nu toe werden deze als twee losse kraanbeschikbaarheden gezien. Daardoor kon een call niet over beide periodes worden ingepland. Af en toe leidde dit tot gevolgen in de planning.
Vanaf nu kan een call wel over meerdere kraanbeschikbaarheden worden gepland, ook als de kranen verschillende ID’s hebben. Zo gaat er minder kraancapaciteit verloren.
De Optimizer ziet kranen die (deels) op dezelfde bolderpositie liggen nu als één aaneengesloten beschikbaarheid. Dit maakt het plannen flexibeler en zorgt voor een efficiënter gebruik van de kraancapaciteit.
Aanpassingen bevries periode
Met de bevries periode bedoelen we de periode van het huidige moment tot een aantal uur in de toekomst waarin het niet meer mogelijk is dat geplande calls van volgorde op de kade veranderen.
De regels rond de bevries periode zijn aangescherpt en uitgebreid. Dit maakt de planning voorspelbaarder en stabieler, maar kan in sommige situaties ten koste gaan van efficiëntie. Dit kan bijvoorbeeld voorkomen als een lichter vertraging op loopt op terminal A en daarna gepland ligt op terminal B. Op terminal B kan er dan een gat in de kadeplanning ontstaan waar niemand gepland wordt.
Wat verandert er:
De bevries periode is verlengd van 6 uur naar 10 uur.
Zodra een call ooit binnen de bevries periode is geweest, blijft deze voor de optimizer ‘bevroren’. Ook als hij later buiten de periode valt.
Tot nu toe was de bevries periode alleen van toepassing op de eerste of eerstvolgende call uit een rotatie, maar vanaf nu geldt de bevries periode voor alle calls die in de bevries periode gepland staan.
Ook Fixed Windows vallen voortaan onder de bevries periode, zolang ze op tijd gepland zijn.
Als gevolg wordt de planning consistenter en betrouwbaarder, met minder onverwachte wijzigingen bij updates of herplanning.
Signalering van overlap tussen calls van verschillende rotaties op dezelfde barge
Het komt soms voor, met name bij vletwerk operators, dat de laatste call van een rotatie later wordt ingepland dan de eerste call van de volgende rotatie. Daardoor is de scope in van de tweede rotatie voor de scope uit van de eerste, met als gevolg dat calls van verschillende rotaties elkaar kunnen overlappen.
Als dit voorkomt krijgen wij hier vanaf nu intern signalering van. Dit zal erin resulteren dat ons support team vaker de bijbehorende BO hierover op de hoogte zal brengen. Verder krijg je als BO nu een operationele waarschuwing als twee calls op deelnemende terminals van verschillende rotaties tegelijk zijn gepland.
Verbetering omgang met TEU-problemen bij rotaties
Tijdens de vorige release hebben we aangepast dat calls met TEU-problemen niet meer uitgepland worden. Voor specifieke scenario's hebben we verscheidene kleine verbeteringen doorgevoerd, met als effect een stabielere planning.
Restrictie BTM afspraken
Momenteel worden BTM calls bij uitzondering op de DDN ingepland als er niet voldoende BTM beschikbaarheid is. Maar vanaf nu mogen BTM calls alleen nog gepland worden op kades die over BTM capaciteit beschikken. Hiermee voorkomen we operationele problemen.
Extra testmogelijkheden
We hebben onze interne testmogelijkheden uitgebreid zodat we beter in staat zijn de impact van onze aanpassingen te bepalen.
Verbetering intern controle mechanisme
Net als in de vorige release hebben we weer verbeteringen doorgevoerd aan het controlemechanisme van de Optimizer. Dit zorgt ervoor dat de Optimizer sneller goede planningen creëert.
Bugfix: Omhangen call
We hebben recent een probleem opgelost dat optrad bij calls die werden omgehangen (move visit in MCA). Dankzij vele voorbeelden konden we dit goed onderzoeken en met hoge urgentie oplossen. Dit probleem is nu verholpen.
Release notes Optimizer week 23 - 2025
De planning nog betrouwbaarder maken – met jullie ervaringen als basis
De afgelopen maanden hebben we het systeem op veel punten verbeterd, met als doel: een betrouwbare en voorspelbare planning, die beter doet wat je ervan verwacht. Daarbij nemen we jullie praktijkervaringen als belangrijkste vertrekpunt. In deze release lees je hoe we dat concreet hebben gedaan.
Stabielere planning ondanks TEU-problemen
Bij TEU-problemen worden calls voortaan niet meer automatisch uitgepland. Dit betekent dat de calls in de planning blijven liggen, waardoor de planning stabieler wordt. Planningen blijven hierdoor gebaseerd op het volledige plaatje, en we voorkomen dat calls tijdelijk verdwijnen en later opnieuw moeten worden toegevoegd. Wat vaak leidt tot extra conflicten, verschuivingen of inefficiënte oplossingen.
Deze wijziging brengt rust in het planningsproces: calls blijven op hun plek terwijl het onderliggende probleem wordt aangepakt door de BO. Tegelijkertijd benadrukken we dat het oplossen van TEU-problemen door de BO noodzakelijk blijft.
Belangrijk te melden is dat zolang een TEU-probleem bestaat, de volgorde van calls binnen een rotatie namelijk niet meer kan worden aangepast. Dit beperkt de optimalisatiemogelijkheden van het systeem en kan leiden tot een minder efficiënte inzet van capaciteit.
Let op: wanneer een TEU-probleem ontstaat doordat de BO een restrictie aanpast, kan het nog steeds voorkomen dat calls wél worden uitgepland.
In dat geval is het belangrijk direct te controleren of de TEU-aantallen nog kloppen. Zijn die niet correct? Los dit dan meteen op, zodat langdurig ongeplande calls en onnodige verschuivingen worden voorkomen.
Meer grip op waarom een planning verandert
We hebben het afgelopen half jaar veel verbeteringen doorgevoerd om de betrouwbaarheid en voorspelbaarheid van de planning te vergroten. Tegelijkertijd zien we dat er nog steeds situaties zijn waarin onverwachte verschuivingen optreden.
Om beter te begrijpen waarom deze verschuivingen plaatsvinden, hebben we nu uitgebreidere analysemogelijkheden toegevoegd. Deze geven ons meer inzicht in het planningsgedrag. Hiermee kunnen we gerichter op zoek gaan naar de grondoorzaken van verstoringen die zich nog voordoen. Dit helpt ons om het systeem verder te verfijnen, invoer beter te sturen en toekomstige knelpunten te voorkomen.
Verfijning van blokkeringen in de planning
We hebben verschillende verbeteringen doorgevoerd om te voorkomen dat berekeningen de planning onnodig blokkeren.
In situaties met overlap op lange kades werd soms een blokkering berekend voor het gebruik van kranen, terwijl dit in de praktijk geen probleem vormde. Deze blokkering wordt nu alleen nog toegepast wanneer er daadwerkelijk maar één kraan beschikbaar is en calls direct boven elkaar gepland worden.
De planning werd eerder geblokkeerd wanneer een verplichte beschikbaarheid te kort was voor de lengte van een call (verkeerde invoer). Dit is nu aangepast: het systeem houdt hier rekening mee en blokkeert in zulke gevallen de planning niet meer.
Let op, wanneer een call niet in een verplichte beschikbaarheid past is het nog steeds nodig om of de call aan te passen of de verplichte beschikbaarheid.
Automatisch plannen op vaste positie bij kraanbeschikbaarheid
Bij het plannen van calls op kraanbeschikbaarheid (zoals bij ECT en HPD2) kiest het systeem voortaan automatisch de eerste bolder. Dit voorkomt variatie en versnelt de verwerking van dit soort calls.
Ook achter de schermen werken we aan verbetering
De Optimizer werkt met een intern controlemechanisme dat beoordeelt of een nieuwe planning echt beter is dan de vorige. Dit controlemechanisme hebben we flink verbeterd. Daardoor kan de Optimizer nu sneller rekenen én vaker een betere planning maken. Je merkt dit misschien niet direct als gebruiker, maar het effect ervan is dat de optimizer gemiddeld genomen sneller en beter kan plannen.
Tenslotte hebben we ook enkele technische aanpassingen gedaan, die het voor het interne team makkelijker maken om inzicht te krijgen in de planning en efficiënter te werken.
Release notes Nextlogic Informatie Platform en Optimizer week 22 - 2025
Voor het correct weergeven van de nieuwe onderdelen van deze release adviseren wij om de cache van je browser te verwijderen:
Druk op Ctrl + Shift + Delete
Kies daar de optie om je cache te verwijderen
TEU-verandering per call zichtbaar in rotatieoverzicht
Voorheen kon je per call alleen zien hoeveel containers en TEU er geladen en gelost zouden worden. Wat ontbrak, was duidelijk inzicht in de daadwerkelijke verandering in TEU per bezoek en hoeveel lading op dat moment aan boord is.
Verkeerd ingegeven TEU-aantallen zorgen voor een verstoring van de planning. Je rotatie wordt uitgepland totdat het TEU-probleem is opgelost. Hierdoor is het heel belangrijk dat de invoer goed staat!
Vanaf nu tonen we in het rotatieoverzicht per call een extra kolom met de TEU-verandering. Hiermee krijg je als gebruiker een beter beeld waar TEU-problemen ontstaan en wat je moet doen om dit op te lossen. Dit maakt het makkelijker om actie te ondernemen. Je ziet in één overzicht of de oorzaak en oplossing bij de teu at entry, capaciteit lichter of de hoeveelheid aan teu lossing of lading liggen.
Voorbeelden van situaties die hiermee inzichtelijk worden:
Rotatie zonder TEU-probleem
Rotatie waarbij de max TEU-capaciteit van de barge wordt overschreden.
Hierbij ga je meer laden dan dat er op je barge past.
Mogelijke acties:Pas de capaciteit van je barge omhoog aan
Pas je “TEU at entry” omlaag aan
Verwijder laad proforma aantallen
Voeg los proforma aantallen toe
Kijk of je de juiste containergrote hebt aangemeld 20’/40’
Rotatie waarbij de TEU-aantallen van een barge onder nul TEU eindigt
Mogelijke acties:Verhoog je “TEU at entry”
Voeg laad proforma aantallen toe
Verwijder los proforma aantallen
Meer inzicht en informatie in overboekte Fixed Windows in de kadeplanning
We hebben, op basis van feedback van gebruikers, de informatie rondom overboekte Fixed Windows in de kadeplanning uitgebreid. Vanaf nu wordt duidelijker weergegeven:
Hoeveel moves er zijn aangemeld per Fixed Window én per individuele call
Hoeveel moves op dat moment worden gepland
Wat het standaard limiet is van een Fixed Window zonder overboekingen (inclusief eventuele marge)
Hoeveel moves de terminal heeft goedgekeurd
Dankzij deze verbeteringen kun je als gebruiker beter beoordelen welke keuzes zijn gemaakt door de terminal operators en wat eventuele vervolgstappen zijn.
Overboekte Fixed Windows nu zichtbaar voor alle Barge Operators
In de vorige situatie was informatie over overboekte Fixed Windows in de kadeplanning alleen zichtbaar voor de terminal operator die het verzoek moest beoordelen. Dit is nu aangepast. Barge operators kunnen voortaan ook deze informatie inzien. Hiermee verbeteren we de transparantie en samenwerking in de planning.
In de kadeplanning klik je op “FW” om al jouw aangevraagde Fixed Windows in te zien.
Zoals hieronder te zien is, is de keuze van de terminal aangegeven door de tekst in de blokken en is de kleur feller. Als beide velden lichter van kleur zijn dan ligt het verzoek nog ter beoordeling bij de terminal.
Validatie op de gefixeerde calls bij niet deelnemende terminals
In de vorige release hebben wij de optie toegevoegd om calls bij niet deelnemende terminals te fixeren op een specifiek tijdstip.
Hierbij nogmaals de voorwaarden waar deze calls aan moet voldoen, als deze voorwaarden worden geschonden dan zal het vinkje uit worden gezet en krijgt de gebruiker een operationele waarschuwing.
Kan niet in een restrictie staan, of alleen op de eerste plek in de restrictie.
Moet een haalbare planning opleveren:
Afspraaktijd moet na de Scope-in + vaartijd naar de terminal liggen
Vaartijden tussen de calls worden meegenomen in de planning naar andere niet deelnemende terminals
Geen conflicterende tijden met een andere call uit de rotatie op een verplichte beschikbaarheid, Prio Call, Fixed Window Call
Geen conflicterende tijden met afspraken bij andere niet deelnemende terminal calls
Als de call niet voldoet aan een van bovenstaande voorwaarden is het niet mogelijk om de niet deelnemende terminal “vast te klikken”. Doe dit alleen als je de afspraak kosten wat kost wil halen op de door jou aangegeven tijd.
Als Barge Operator klik ik in de pagina van de “Call details” op het potlood om de velden te kunnen wijzigen.
Daarna vink ik het blok achter “Vast afgesproken tijd met de terminal” aan om de call te fixeren.
Dan klik ik (onderaan de pagina) op opslaan om deze wijzigingen door te voeren.
Bugfix: Call verdween bij omhangen tussen rotaties
Er is een fout opgelost waarbij een call uit de planning verdween wanneer deze werd verplaatst van Rotatie A naar Rotatie B en daarna weer terug naar A. Dit probleem is verholpen. Vanaf nu verdwijnen calls niet meer uit de planning, ook niet bij meerdere keren omhangen tussen rotaties.
Release notes Nextlogic Informatie Platform en Optimizer week 19 - 2025
Nieuwe Functionaliteiten
TEU-berekening met CODECO-gegevens
Voorheen gebruikten we voor alle calls de proforma aantallen om een TEU-berekening te maken. Dit gebruiken we om een planning te maken. Hierbij houden we rekening dat de TEU-aantallen niet onder 0 eindigen (door eerst meer te lossen dan te laden) of boven je maximale capaciteit van de barge uitkomen. Door het gebruik van alleen proforma aantallen konden fouten ontstaan wanneer er een verschil zat in het proforma aantal aangemelde containers en het daadwerkelijk aantal containers op de los- laadlijst.
Zodra je een extra call aanmaakte om de lege barge capaciteit op te vullen ontstond er een probleem. Om dit op te lossen was het nodig om de capaciteit van de barge te verhogen, terwijl deze capaciteit er eigenlijk niet was.
Nu hebben we geïmplementeerd dat bij de deelnemende terminals tot het sluiten van de loslaadlijst de proforma aantallen worden gebruikt voor TEU berekening. Daarna worden de daadwerkelijke containers op de los- laadlijst gebruikt, en na afsluiting van de call wordt de TEU-berekening gebaseerd op de containers met een CODECO. Hiermee wordt de TEU-verandering nauwkeuriger en eerlijker vastgesteld.
Meerdere Barge Operators op één barge
Er zijn situaties waarbij een barge voor verschillende rotaties door meerdere Barge Operators wordt ingezet. Tot nu toe kon alleen de eigenaar van de barge de rotatie aanpassen. Vanaf deze release kan de barge operator die de rotatie heeft aangemaakt ook de planning en tijden van zijn/haar eigen rotatie inzien en aanpassen, zelfs als de operator niet de eigenaar is van de barge in Nextlogic. Zo bieden we meer flexibiliteit en kunnen de rotaties beter worden beheerd. Belangrijk is wel dat één rotatie niet door meerdere Barge Operators tegelijk aangepast kan worden.
Werktijden en onbeschikbaarheid barges zichtbaar voor Terminal Operators
Voorheen was het niet duidelijk zichtbaar wanneer een barge tijdelijk niet beschikbaar was. Nu kunnen terminal operators dit eenvoudig inzien via de kadeplanning. Wanneer je in de kadeplanning op een barge klikt en vervolgens in de zijbalk bij call details op de naam van de barge klikt, verschijnt een pop-up. Hier zie je de werktijden en uitzonderingen van de betreffende barge. Zo kunnen terminals beter inzicht krijgen op welke barges zij kunnen benaderen of waarom barges niet op een specifieke tijd gepland kunnen worden.
Calls bij niet deelnemende terminals kunnen door de Barge Operator gefixeerd worden in de planning om rekening mee te houden door het systeem
Bij calls op niet deelnemende terminals komt het voor dat Nextlogic een voorstel doet voor een afspraak tijd. Deze komt dan beter uit in de planning, rekening houdend met alle andere afspraken. Echter, als barge operator zijn er afspraken bij niet deelnemende terminal die je kosten wat kost wel moet of wil halen.
Vanaf nu kan een Barge Operator bij een call van een niet deelnemende terminal aangeven dat deze op een specifiek tijdstip afgehandeld wil worden. Als je dit aangeeft plant Nextlogic de call altijd op het afgesproken tijdstip.
Belangrijk is dat de call bij de niet deelnemende terminal aan een aantal voorwaarden moet voldoen:
Kan niet in een restrictie staan, of alleen op de eerste plek in de restrictie.
Moet een haalbare planning opleveren:
Afspraaktijd moet na de Scope-in + vaartijd naar de terminal liggen
Vaartijden tussen de calls worden meegenomen in de planning naar andere niet deelnemende terminals
Geen conflicterende tijden met een andere call uit de rotatie op een verplichte beschikbaarheid, Prio Call, Fixed Window Call
Geen conflicterende tijden met afspraken bij andere niet deelnemende terminal calls
Als de call aan een van bovenstaande voorwaarden niet voldoet is het niet mogelijk om de niet deelnemende terminal “vast te klikken”. Doe dit alleen als je de afspraak kosten wat kost wil halen op de door jou aangegeven tijd.
Vanuit Nextlogic wordt strak gemonitord op de functionaliteit, levert het te veel onmogelijkheden op in de planning dan zullen we hier altijd over in gesprek treden voordat er verandering plaatsvindt.
Als Barge Operator klik ik in de pagina van de “Call details” op het potlood om de velden te kunnen wijzigen.
Daarna vink ik het blok achter “Vast afgesproken tijd met de terminal” aan om de call te fixeren.
Dan klik ik (onderaan de pagina) op opslaan om deze wijzigingen door te voeren.
Berekening met restricties
We gebruiken onder andere slack percentages om te bepalen hoe lang we over een rotatie mogen doen. Dit is extra tijd op de callduur + vaartijd die we meenemen in de berekening van de duur van de rotatie. Op basis daarvan wordt beoordeeld of een call als laat wordt gezien.
Voorheen telden ook restricties mee in deze berekening.
Vanaf nu worden restricties niet meer meegenomen in het bepalen van de normduur.
Dit hebben we gedaan om geen extra tijd te rekenen wanneer je restricties in moet voeren door stuwage-technische redenen. Het ingeven heeft vanaf nu geen consequentie meer op de tijd die we berekenen over je rotatie te doen. Geef restricties daarom altijd op tijd door, zo voorkomen we dat het systeem een onmogelijke planning maakt. Daarnaast voorkomen we last-minute veranderingen door een verandering in de ingegeven restrictie.
Verbeteringen
Vroegste starttijd BO direct doorgestuurd
Het is een aantal keer voorgekomen dat de vroegste start BO niet goed werd gehandhaafd, waardoor los- en laadlijsten onnodig vroeg werden gesloten. Met deze wijziging wordt de vroegste starttijd van een Barge Operator altijd direct doorgestuurd naar het platform. Hierdoor worden foutmeldingen voorkomen en sluit de planning beter aan op de realiteit.
Beter overzicht in overboekte Fixed Window lijst
De lijst met overboekte Fixed Window verzoeken is aangepast. Nieuwe verzoeken die nog beoordeeld moeten worden, staan nu bovenaan. De overige verzoeken zijn gesorteerd op starttijd van het window. Dit zorgt voor een beter overzicht en maakt het makkelijker om te zien welke verzoeken nog aandacht nodig hebben.
Betere berekening aankomsttijd haven
We zien steeds vaker dat barge operators en schippers hun gewenste aankomsttijd aanpassen als deze afwijkt van de vooraf aangemelde tijden. Voor de planning is dit positief!
Er zat een fout in de berekening van de aankomsttijd in de haven als deze berekend was en daarna de gewenste aankomsttijd werd veranderd. Dit is opgelost en maakt de planning accurater en betrouwbaarder.
Wijzigingen in kade- of kraanbeschikbaarheid binnen 24 uur
Wijzigingen in kade- of kraanbeschikbaarheid zijn voortaan alleen zichtbaar als ze binnen 24 uur effect hebben. In het vorige model werden wijzigingen getoond als ze effect hadden op een beschikbaarheid die binnen de komende 24 uur begint, ook al had de wijziging invloed na de eerste 24 uur. Door alleen wijzigingen te tonen die binnen 24 uur impact hebben, houden we de focus op de meest actuele veranderingen.
Vul een reden in bij een verandering van de beschikbaarheid, zodat iedereen op de hoogte is van de actuele situatie.
Verbeteringen in voorspel- en betrouwbaarheid
Het verhogen van voorspel- en betrouwbaarheid van de planning heeft de meeste aandacht binnen Nextlogic. We hebben twee aanpassingen gedaan:
Grace periode blijft behouden, dit is de periode in de eerste 8 uur voor start operatie waarin barges 30/45 minuten in overlap mogen liggen zonder dat dit veel consequenties heeft in de planning.
Bij automatisch schuiven wordt nu rekening gehouden met de grace periode in de eerste 8 uur.
Hierdoor blijven toegestane overlappen tussen calls bestaan, in plaats van dat alles strak tegen elkaar aan gepland wordt.
Beter omgaan met beperkte beschikbaarheid
Als een call niet binnen de beschikbare tijd op dezelfde bolderpositie gepland kan worden, blijft deze staan op de originele plek.
Het systeem zoekt dan automatisch naar een betere oplossing binnen de juiste beschikbaarheid. In plaats van door te schuiven naar de eerstvolgende beschikbaarheid op dezelfde bolderposities.
Verbetering oplossen overlappen
Eerder is ingesteld dat overlappen met fixed windows zwaarder meetellen dan overlappen met reguliere calls. Dit blijft zo, maar:
De weging van overlappen met fixed windows is iets verlaagd.
Hierdoor ontstaan er minder situaties waarbij meerdere reguliere calls over elkaar heen worden gelegd om een overlap met een fixed window op te lossen.
Het resultaat is een betere balans in de planning en minder langdurige en ongewenste[LB11] overlappen.
Bugfixes
Operationele waarschuwing bij Fixed Window correct verwijderd
Tijdens de eerste week van het beoordelen van overboekte Fixed Windows kwamen we enkele verbeterpunten tegen, vooral dankzij input van gebruikers. Een bug die nu is opgelost, betrof operationele waarschuwingen die onterecht actief bleven, ook nadat de Barge Operator de aantallen al had aangepast en er dus geen sprake meer was van een overboeking. Vanaf nu wordt de operationele waarschuwing correct verwijderd zodra de call weer binnen het Fixed Window limiet valt. De waarschuwing verdwijnt zodra je iets aan je call hebt aangepast.
Optimizer
Foutmelding bij aanmelding afspraak op deelnemende terminal opgelost.
o In MCA kan je de knop “has appointment” gebruiken. Bij gebruik van deze knop bij deelnemende terminals ontstond er een foutmelding. Deze foutmelding komt niet meer voor.
o Voor deelnemende terminals is het niet nodig om de knop “has appointment” te gebruiken, daar gebeurt niks mee.
Fixed window onterecht als laat aangemerkt