De controle op de ingevoerde wijzigingsdatum tegenover de eerstvolgende prolongatiedatum van de verzekering is opgeheven. De enige situatie waarin een toekomstige wijzigingsdatum nog wordt geblokkeerd, is als de wijzigingsdatum voorbijgaat aan de prolongatiedatum waarvoor de verzekering al in de prolongatie is mee gelopen. Een toekomstige mutatie terwijl de verzekering al meeloopt in het prolongatieproces, kan dus niet.

Prolongatiedatum

Voorheen werd bij het bepalen van de prolongatiedatum in de verzekering ook rekening gehouden met de maand en de status van de prolongatie uit de inrichting van de verzekeraar. Deze controle is komen te vervallen, anders is een toekomstige mutatie in principe nooit mogelijk. De prolongatiedatum wordt nu bepaald op basis van de wijzigingsdatum in combinatie met de betaaltermijn en hoofdvervaldatum.

De enige correctie op de zo gevonden prolongatiedatum in de verzekering op basis van de prolongatiegegevens uit de inrichting van de verzekeraar vindt nog plaats als:

• de gevonden prolongatiemaandverzekering kleiner is dan de prolongatiemaandverzekeraar.
• de gevonden prolongatiemaandverzekering gelijk is aan de prolongatiemaandverzekeraar en de status van de prolongatie bij de verzekeraar ongelijk initieel is.

De prolongatiemaand van de verzekering zal minstens de initiële prolongatiemaand van de verzekeraar moeten bevatten. In het geval van de status ongelijk initieel wordt het de prolongatiemaandverzekeraar + 1.

Het mutatieproces

Een verzekering heeft als eerstvolgende prolongatiedatum 01-10-2018 en er wordt een wijzigingsdatum 15-10-2018 ingevoerd. Vanaf 15-10-2018 geldt de nieuwe situatie, het gevolg van de door te voeren wijziging. Met de periode 01-10-2018 tot 15-10-2018 moet echter ook iets gebeuren. De verzekering zou normaal gesproken een prolongatie van 01-10-2018 hebben gehad. Bij het verlaten van tabblad Verzekering verschijnt de volgende melding.

Voor deze tussenliggende periode wordt voor de verzekering op de achtergrond een prolongatie uitgevoerd. In het geval de wijzigingsdatum zelfs bijvoorbeeld 15-11-2018 is en er wordt per maand betaald, dan worden er zelfs twee prolongaties uitgevoerd. Vanuit elke prolongatie ontstaat een contractgebeurtenis en zo nodig een nieuwe versie van de verzekering. Of een nieuwe versie moet worden aangemaakt, wordt bepaald op basis van exact dezelfde condities als in het reguliere prolongatieproces (hoofdvervaldatum, gewijzigde voorwaarden of beloning etc.).

De tussengevoegde gebeurtenissen zijn herkenbaar aan hun nieuwe type gebeurtenis.

De eventueel aangemaakte extra nieuwe versies worden tussengevoegd. Dat wil zeggen, het versienummer wordt opgehoogd vanaf de laatst hoogste versie. Het versienummer van de toekomstige mutatie komt achteraan. De tussengevoegde versies ondergaan net als vanuit het reguliere prolongatieproces een eventuele wijziging van NCBM, indexering, voorwaarden, beloning, verdeling etc.. De data van de onderhanden zijnde toekomstige mutatie wordt opnieuw geladen vanuit de laatst tussengevoegde versie, dus die is op dat moment actueel.

Mocht het zo zijn dat de wijzigingsdatum opnieuw wordt aangepast, dan worden alle acties ook opnieuw uitgevoerd. Eventueel eerder toegevoegde versies worden opgeruimd en nieuwe worden aangemaakt indien nodig. Het gevolg hiervan is wel, dat de data van de onderhanden zijnde toekomstige mutatie ook wederom opnieuw wordt geladen vanuit de laatste versie. Eventuele wijzigingen die al in de toekomstige mutatie waren doorgevoerd gaan daarmee dus verloren en moeten opnieuw worden gedaan.

Bovenstaand mechanisme is ook de reden voor het benoemen van de premieronde in bovenstaande melding. Het toepassen van de premieronde heeft invloed op de tussen te voegen versie en dus ook weer op de data van de onderhanden zijnde toekomstige mutatie.

De werking van het tussenvoegen van prolongaties en versies speelt uiteraard alleen in geval van een mutatie op een actieve verzekering. Als met een toekomstige mutatie een inactieve verzekering actief wordt gemaakt, dan wordt niets tussengevoegd. Er ontstaat alleen een mutatie vanaf de (toekomstige) wijzigingsdatum.

De boeking

De boeking die met het uitvoeren van de premieberekening wordt gegenereerd bevat regels voor zowel de eventueel tussengevoegde prolongaties als voor de toekomstige mutatie. Het laatste gebeurt uiteraard niet in het geval van een toekomstig royement of schorsing, dan is de toekomstige wijzigingsdatum de datum van inactief worden.

Vanuit het pakket

Als verzekeringen zijn opgenomen in een pakket, dan is de bovenstaande werking ongewijzigd van toepassing. Het enige verschil is dat de instelling ‘gelijke betaaltermijn en hoofdvervaldatum’ bij de pakketinrichting van invloed kan zijn op het bepalen van de prolongatiedatum in de verzekering.

Na het wijzigen van de betaaltermijn en/of hoofdvervaldatum in het pakket wordt, als de instelling ‘gelijke betaaltermijn en hoofdvervaldatum’ in de pakketinrichting aan staat, de prolongatiedatum in het pakket leeg gemaakt.

Voor de actieve pakketonderdelen ontstaat een voorlopige mutatie. Je bent daardoor verplicht om deze wijziging ook in de onderdelen door te voeren, waarna de prolongatiedatum van het pakket opnieuw kan worden bepaald. Deze wordt namelijk bepaald vanuit de prolongatiedatums van de onderliggende actieve onderdelen. De oudste prolongatiedatum uit de onderdelen is bepalend.

Annuleren (laatste) mutatie

Het annuleren van de laatste niet definitieve mutatie is aangepast zodat ook hier rekening wordt gehouden met de tussengevoegde gebeurtenissen en versies.

Tegenboeken gebeurtenis

De tegenboeken gebeurtenis is aangepast zodat ook hier rekening wordt gehouden met de tussengevoegde gebeurtenissen en versies. Hier speelt natuurlijk ook mee dat met de tegen te boeken mutatie de prolongatiedatum was gewijzigd en ook die moet dan weer terug naar af.

Wijzigen betaaltermijn en/of hoofdvervaldatum met niet definitieve mutatie

Voorheen konden deze velden niet worden gewijzigd met een niet definitieve mutatie. Vanwege de sterke samenhang hiervan met de gewijzigde manier van bepaling van de prolongatiedatum vanwege de toekomstige mutaties, is het nu wel mogelijk om de betaaltermijn en/of hoofdvervaldatum aan te passen en als niet definitieve wijziging op te slaan.