DIAS Assurantie / DIAS Cloud – versie 4.1.5.1

1. Provinciaal en volmacht

1.1. Brieven en e-mails

1.1.1. Nieuw veld Type PDF-generatie bij Externe documentopmaak

(4.1.4.5)

In het venster Run (via Bureau > groep Correspondentie > Uitgaand > Externe documentopmaak) maak je runs aan of wijzig je bestaande runs. Dit venster wordt meestal gebruikt om voorbeeld-XML te genereren, maar je kunt er ook echte PDF-documenten mee laten opmaken. Linksboven in dit venster is het veld Type PDF-generatie toegevoegd. Dit veld bepaalt hoe de PDF-bestanden worden gegenereerd:

Waarde

Betekenis

Leeg (standaard) Direct

Gebruik deze waarde voor voorbeeld-XML. De documenten worden direct opgemaakt. Het verzoek om PDF's te genereren komt in een wachtrij en wordt uitgevoerd zodra het systeem eraan toe is. Dit is toekomstige functionaliteit.

Bulk

Laat je het veld leeg, dan kies je in het veld Doel zelf de uitvoermap voor de XML, zoals je gewend bent. Kies je Direct of Bulk, dan kun je geen Doel opgeven: het systeem bepaalt dan waar de bestanden terechtkomen.

Het veld Type PDF-generatie staat los van het veld Verwerking. Met Verwerking bepaal je hoe de gegevens worden verzameld. Met Type PDF-generatie bepaal je hoe daar PDFbestanden van worden gemaakt. Impact voor jou Gebruik je dit venster alleen om voorbeeld-XML te genereren, dan hoef je niets te doen: laat Type PDF-generatie leeg en werk verder zoals voorheen. Zie ook (zie "Doelmappen voor documentgeneratie inrichten in Scenario.Enterprise (4.1.4.5)" op pagina 45) voor het inrichten van de mappen waar de documenten terechtkomen.

1.2. Contractbeheer

1.2.1. Melding bij conversie naar VoordeelPakket opgelost (4.1.4.5)

Bij het omzetten van contracten naar het VoordeelPakket met het hulpprogramma HCVVGD03 Voogd/Alpina Conversie naar VoordeelPakket kon tijdens het uitvoeren op het venster een melding over de contractstatus verschijnen. Deze melding verschijnt niet meer.

1.2.2. Object Acceptatievragen verwijderen bij muteren (4.1.5.1)

Zet je een verzekering via muteren over naar een ander product, dan gaan de objecten van de verzekering mee. Kent het nieuwe product een object niet meer, dan hoort dat object uit de verzekering verwijderd te kunnen worden. Voor het object Acceptatievragen kon dat niet: het bleef in de verzekering staan, ook als het in de inrichting van het nieuwe product niet meer voorkwam. Dit speelt vooral bij volmachtproducten, zoals SUIV-producten. Je kunt het object Acceptatievragen nu verwijderen zodra het niet meer voorkomt in de inrichting van het product. Dat doe je in de box Objecten op het tabblad Indeling van de verzekering. Komt het object nog wél in de inrichting voor, dan blijft het verplicht en kun je het niet verwijderen. Impact voor jou Zet je verzekeringen over naar een nieuw product waarin het object Acceptatievragen niet meer is opgenomen, dan houd je geen verzekeringen meer over met een object dat bij dat product niet hoort.

1.3. Financiële administratie

1.3.1. Lege transactieregel bij inlezen bankbestand opgelost (4.1.4.5)

Je leest een bankbestand in via Financieel > groep Betalingsverkeer > Importeren bankbestand. Daarbij kon in het ingelezen bestand soms een lege transactieregel ontstaan. Dit is opgelost: het bankbestand wordt nu ingelezen zonder lege transactieregels.

1.4. Inrichting en beheer

1.4.1. Achtergebleven eigen gegevensgroepen opruimen (4.1.4.4)

Met eigen gegevensgroepen leg je gegevens vast die niet in de standaardvelden passen. Welke groepen er zijn, bepaal je in de inrichting. Verwijder je daar een groep, dan hoorde ook de verwijzing ernaar te verdwijnen. Dat gebeurde niet. Bij relaties, verzekeringen en schades bleef de verwijzing naar de verwijderde groep staan. Daar liep DIAS Cloud Backend op vast: bij het opvragen van een relatie, een verzekering of een schade met zo'n verwijzing ging het mis. Er is daarom een herstelprogramma bijgekomen dat die verwijzingen opruimt. Het herstelprogramma uitvoeren 1. Open het venster Hulpprogrammatuur via Autorisatie > groep Tools > Hulpprogrammatuur. 2. Selecteer het hulpprogramma HTPCGP09 Verwijderen eigen gegevens zonder voorkomen in Tpcgp. 3. Klik op OK.

Let op het verschil met HTPCGR09, dat er in de lijst vlak onder staat. Dat programma herstelt filterrubrieken en doet iets anders. Impact voor jou Je voert het programma zelf uit, één keer. Het ruimt op wat er in het verleden is blijven staan; nieuwe gevallen ontstaan niet meer. Zolang je het niet hebt uitgevoerd, kunnen relaties, verzekeringen en schades met zo'n verwijzing fouten blijven geven in DIAS Cloud.

1.4.2. Retentieperiode en opschonen van scenario's (4.1.5.1)

In de bedrijfsgegevens leg je vast hoe lang je gegevens bewaart. Tot nu toe kon dat voor contracten, schades en letselschades. Een scenario kende geen eigen bewaartermijn, terwijl ook een scenario persoonsgegevens bevat en altijd aan een relatie hangt. Dit is alleen van belang als je met het portaal werkt: daar ontstaan scenario's. Daarvoor is het veld Retentieperiode scenario's in mnd toegevoegd, op het tabblad Instellingen van de bedrijfsgegevens (Beheer > groep Organisatie > Bedrijfsgegevens). Het staat bij de bestaande velden Retentieperiode contracten in mnd, Retentieperiode schades in mnd en Retentieperiode letselschades in mnd. Je vult het aantal maanden in dat je een scenario wilt bewaren. Een scenario krijgt daarmee een eigen retentiedatum. Het opschoon- en archiveerproces verwijdert scenario's waarvan die datum is bereikt, net zoals het dat doet voor contracten en schades. Retentiedatum vullen bij scenario's De retentiedatum van scenario's vul je met het hulpprogramma HINIDR03. Dat open je in het venster Hulpprogrammatuur, via Autorisatie > groep Tools > Hulpprogrammatuur. Het programma berekent de retentiedatum aan de hand van de retentieperiode die je hebt ingesteld. Herhaal dit periodiek, zodat ook scenario's die sindsdien zijn bijgekomen een retentiedatum krijgen. Impact voor jou Bepaal welke bewaartermijn je voor scenario's wilt aanhouden en vul die in. Houd er daarbij rekening mee dat een scenario meerdere verzekeringen en zelfs meerdere pakketten kan bevatten, en dat de bewaartermijn van contracten doorgaans langer is dan die van scenario's. Een scenario zonder retentiedatum wordt niet opgeschoond; het hulpprogramma is dus nodig om scenario's daadwerkelijk uit de administratie te laten verdwijnen.

1.5. Prolongatie

1.5.1. Geen nieuwe pakketversie meer bij termijnprolongatie (4.1.5.1)

Bij een termijnprolongatie wordt gecontroleerd of er iets aan het pakket verandert. Onder meer wordt vergeleken of de assurantiebelasting anders uitkomt dan bij de vorige termijn. Is er een verschil, dan maakt DIAS Assurantie een nieuwe versie van het pakket aan. Door een afrondingsverschil kon die vergelijking een verschil opleveren terwijl de bedragen in werkelijkheid gelijk waren. Er ontstond dan een nieuwe pakketversie zonder dat er iets was gewijzigd. Bij het vergelijken van de bedragen wordt nu rekening gehouden met afronding, zodat gelijke bedragen ook als gelijk gelden. Impact voor jou Een pakket krijgt bij een termijnprolongatie alleen nog een nieuwe versie als er daadwerkelijk iets is veranderd. De versiehistorie van een pakket blijft daardoor overzichtelijk en geeft beter weer wanneer er echt iets is gewijzigd.

1.6. Relatiebeheer

1.6.1. Leeg setmail-scherm bij afsluiten relatie hersteld (4.1.4.3)

Bij het gebruik van setmailen in combinatie met EDO (DevExpress) bleef het venster Productaanvraag setmail verschijnen bij het afsluiten van een relatie, ook wanneer er geen nieuwe productaanvraag was gedaan. Dit deed zich voor bij de medewerker die eerder een document via EDO had aangemaakt. Het venster was leeg en kon alleen worden gesloten via Annuleren.

Het venster Productaanvraag setmail verschijnt nu alleen nog wanneer er daadwerkelijk nieuwe productaanvragen zijn aangemaakt bij de relatie. Impact Het venster Productaanvraag setmail verstoort de werkstroom bij het afsluiten van een relatie niet langer wanneer er geen nieuwe productaanvragen zijn.

1.6.2. BIC-codes toegevoegd aan de SEPA BIC-lijst (4.1.4.3)

De SEPA BIC-lijst is bijgewerkt. De volgende betaaldienstverleners zijn toegevoegd:

Naam betaaldienstverlener

BIC

Identifier

YabandPay B.V. XTransfer B.V.

YABNNL22 XTAFNL2A

YABN XTAF

Impact Bij het invoeren van een YABNNL22 of XTAFNL2A IBAN-rekeningnummer in het venster Bankrekening (via het venster Relatiegegevens, tabblad Financieel) wordt de BIC-code nu automatisch bepaald.

1.6.3. BIC-codes toegevoegd aan de SEPA BIC-lijst (4.1.5.1)

De SEPA BIC-lijst is bijgewerkt. De volgende betaaldienstverleners zijn toegevoegd:

Naam betaaldienstverlener

BIC

Identifier

Shine Payments NL ABN AMRO Bank N.V. h/o BUX

SNNNNL2A BUXANL22

SNNN BUXA

Impact voor jou Voer je een IBAN-rekeningnummer met SNNNNL2A of BUXANL22 in het venster Bankrekening (via het venster Relatiegegevens, tabblad Financieel), dan wordt de BIC-code nu automatisch bepaald. Je hoeft die niet meer handmatig in te vullen.

1.7. Schade-administratie

1.7.1. Onnodige melding bij beëindigen schade opgelost (4.1.5.1)

Een schade beëindig je door de schade te wijzigen, op het tabblad Algemeen het veld Datum afgehandeld te vullen en op Bewaar te klikken. DIAS Assurantie controleert dan of alle taken en notities bij die schade zijn afgehandeld. Staat er nog iets open, dan verschijnt de melding “Er staan nog taken en/of notities open. Zolang deze niet afgehandeld zijn is het niet mogelijk om een schade af te handelen.” Bij een schade konden taakgegevens achterblijven waar geen taak of notitie meer bij hoorde. De controle telde die mee, waardoor de melding verscheen terwijl er niets meer openstond. Zoeken naar de bijbehorende taak of notitie leverde dan niets op. Bij het wijzigen van een schade blijft die melding nu uit als er alleen nog zulke losse taakgegevens zijn. Die gegevens worden dan meteen opgeruimd, zodat ze bij een volgende keer niet opnieuw meetellen.

Impact voor jou Je beëindigt een schade zonder eerst te zoeken naar taken of notities die niet meer bestaan. Staan er wel echte taken of notities open, dan krijg je de melding zoals je gewend bent en handel je die eerst af.

2. Volmacht

2.1. Buitenlandse assurantiebelasting

2.1.1. Assurantiebelasting gebruikte niet altijd de tariefdatum (4.1.4.4)

Bij het berekenen van de assurantiebelasting werd niet altijd de tariefdatum gebruikt om de geldende versie van de assurantiebelastingtabel te bepalen. Hierdoor kon een oudere versie van de tabel worden toegepast, ook als de wijzigingsdatum van de mutatie al onder een nieuwere versie viel. Dit is hersteld: voor het bepalen van de geldende versie van de assurantiebelastingtabel wordt nu altijd de tariefdatum gebruikt. Impact voor jou Bij een mutatie met een wijzigingsdatum die al onder een nieuwere tabelversie viel, kon een verkeerd bedrag aan assurantiebelasting worden berekend: te laag of te hoog, afhankelijk van of het nieuwe percentage hoger of lager was dan het oude. Ook bij een contract dat al was geprolongeerd op de ingangsdatum van de nieuwe versie, kon een latere wijzigingsdatum binnen diezelfde periode nog terugvallen op de oude versie. Na deze correctie wordt in beide gevallen het percentage van de juiste tabelversie berekend.

2.2. Contractbeheer

2.2.1. Accorderen aangepast (4.1.4.3)

Het accorderen van contractmutaties was ondergebracht in één venster met twee tabbladen: één voor te accorderen mutaties en één voor afgekeurde mutaties. Bij het beoordelen van een mutatie moest worden doorgesprongen naar een apart venster. Dit zorgde voor traagheid en veel klikhandelingen. Het accorderen is gesplitst in twee afzonderlijke onderdelen, beide bereikbaar via Contracten > groep Contracten > Accorderen: Accordeer voor het accorderen zelf en Niet akkoord mutaties voor het overzicht van afgekeurde mutaties.

• Het accordeervenster bevat geen scrollend blok meer, maar een infobox waaruit je een mutatie kiest.

• Naast het pakket worden nu ook de betrokken pakketonderdelen getoond.
• Na het kiezen van een contract worden in de overige boxen de bijbehorende gegevens

direct weergegeven, zodat de beoordeling sneller kan verlopen.

• Vanuit dit venster selecteer je in het veld Accordeer de status Akkoord of Niet akkoord en klik je op Verwerk.

Het venster Niet akkoord mutaties is inhoudelijk niet veranderd. Het tabblad met te accorderen mutaties is hieruit vervallen; dat is vervangen door het nieuwe accordeervenster hierboven. Het vierogenprincipe blijft van kracht: de opsteller van een mutatie kan deze niet zelf accorderen. Een collega met volmachtrechten voert de beoordeling uit. Impact Het accorderen verloopt sneller doordat de beoordelingsgegevens direct zichtbaar zijn en minder handelingen nodig zijn. Geen inrichting vereist. Zie ook (zie "Accordeercontrole GA-producten hersteld (4.1.4.3)" op pagina 19)

2.2.2. Deelobject_Volgnummer hersteld na koppelen (4.1.4.3)

Bij het automatisch koppelen van deelobjecten aan een hoofdobject wordt de rubriek Deelobject_Volgnummer van het hoofdobject nu automatisch gevuld met de waarde 1, als deze rubriek nog niet gevuld was. Je vindt de koppelfunctionaliteit via het product in DIAS: open het tabblad Onderdelen, klik in de box Objecten om het venster Muteren object van product te openen en schakel over naar de mode Wijzigen. Selecteer het hoofdobject en klik op de knop Opnemen deelobjecten.

Impact Je hoeft Deelobject_Volgnummer na het koppelen van deelobjecten niet meer handmatig in te vullen bij het hoofdobject.

2.3. Dynamiekregels

2.3.1. Nieuwe dynamiekregels (4.1.5.1)

Onderstaand overzicht toont alle nieuwe dynamiekregels die in versie 4.1.5.1 zijn opgenomen. Motorrijtuigen (AFD branche 020) – motorrijtuigproducten van Unigarant

ID

Dynamiekregel Bij Motorrijtuigen wordt de partij Regelmatige bestuurder getoond zodra de regelmatige bestuurder een ander is dan de verzekeringnemer. Je moet deze partij dan verplicht invullen. Bij Motorrijtuigen moet je de rubrieken Postcode en Geboortedatum verplicht invullen bij de partij Regelmatige bestuurder, zodra je voor die partij hebt gekozen.

Motorrijtuigen (AFD branche 020) – autoproduct van Ominimo

ID

Dynamiekregel

Bij Motorrijtuigen moet je de rubriek Soort relatie verplicht invullen bij de partij Bestuurder, als de bestuurder een ander is dan de verzekeringnemer.

Zie ook Ominimo wordt met deze release aangesloten als volmachtverzekeraar (zie "Nieuwe licentie voor Productservice Ominimo (4.1.5.1)" op pagina 31). Of de verzekeringnemer zelf de regelmatige bestuurder is, leg je vast met een eigen label (zie "Verzekeringnemer als regelmatige bestuurder ondersteund (4.1.4.5)" op pagina 30). Dit laatste onderwerp staat in de release notes van een eerdere versie. Je vindt het ook in het online handboek of via Quinn, de digitale assistent in DIAS Assurantie.

2.4. e-ABS

2.4.1. Afhandelen voorlopige schadeboeking toegevoegd in e-ABS

(4.1.4.3)

Wanneer je een betaling meldt bij e-ABS, worden de bijbehorende schadeboekingen als voorlopig aangemaakt en ter beoordeling aangeboden aan e-ABS. e-ABS keurt deze

boekingen vervolgens goed of af. Je kunt het resultaat van die beoordeling nu direct vanuit de schadegebeurtenis verwerken. Automatische taak als bewaking Als er een planning bestaat met de exacte naam eABS Betal, wordt bij het aanmaken van de schadegebeurtenissen voor de voorlopige schadeboeking automatisch een taak aangemaakt bij de schade. Deze taak dient als bewaking voor de beoordeling door e-ABS. Via het gekoppelde gegeven Voorlopige schadeboeking in de taak kun je direct naar de bijbehorende schadegebeurtenis navigeren. De planning eABS Betal maak je aan via Beheer > groep Inrichting > Workflow > Muteren planningen (venster Muteren planning). De automatisch aangemaakte taak vind je terug via het venster Activiteitenoverzicht. Selecteer de taak en kies Wijzigen of Raadplegen om het venster Muteren taakonderdeel van taak te openen. Op het tabblad Historie zie je de taakhistorie, inclusief omschrijving, afdeling, afhandeldatum, afhandelaar en taakresultaat. Voor schadetaken kun je taken, notities en dossierinformatie ook terugvinden via het lint van het venster Schadegegevens (Bestand > groep Hulpmiddelen) of via het lint van het venster Overzicht contracten. Taken die bij een schade horen, worden bij afhandeling opgeslagen in het dossier van die schade. Boeking afronden via knop Afronden boeking

Nadat e-ABS de voorlopige schadeboeking heeft beoordeeld, is de Status Fiat van de schadegebeurtenis gewijzigd in Goedgekeurd of Afgekeurd. Open de schadegebeurtenis vanuit het tabblad Historie van het venster Schadegegevens. In het venster Schade gebeurtenis is de knop Afronden boeking dan aanwezig en actief. Het resultaat van klikken op Afronden boeking:

• Bij Goedgekeurd: de voorlopige schadeboeking wordt gefiatteerd (definitief gemaakt).

De Status Fiat wordt bijgewerkt naar Afgerond na goedkeuring.

• Bij Afgekeurd: de voorlopige schadeboeking wordt verwijderd. De Status Fiat wordt bijgewerkt naar Afgerond na afkeuring.

Alternatief: afronden via Fiatteren Je kunt de boeking ook definitief maken of verwijderen via Financieel > groep Boeken > Fiatteren, tabblad Koppeling. Dit is alleen mogelijk als de Status Fiat Goedgekeurd of Afgekeurd is. Impact Je kunt de beoordeling van een voorlopige schadeboeking door e-ABS nu direct vanuit de schadegebeurtenis verwerken, zonder dat je daarvoor naar het fiatteerscherm hoeft te navigeren. De optionele taak biedt een extra bewakingsmogelijkheid zolang de beoordeling nog niet heeft plaatsgevonden.

2.5. Fraudechecks

2.5.1. Beschikbaarheid FishExtract-meldingen bij instanties hersteld

(4.1.4.3)

In het venster Overzicht fraude checks (via het lint van het venster Relatiegegevens, Hulpmiddelen > Opties > Overzicht fraude checks), tabblad CC/FE, was het scrollende blok met FishExtract-meldingen bij instanties soms uitgeschakeld. Dit is gecorrigeerd: het blok is nu altijd beschikbaar.

2.6. Inrichting en beheer

2.6.1. Financieel advies verwijderd (4.1.4.4)

Breaking change De functionaliteit voor financieel advies is verwijderd uit DIAS Assurantie. Dit onderdeel was bedoeld voor de koppeling met DIAS Advies en is daarmee al langere tijd overbodig. Impact voor jou Het is niet meer mogelijk om dossiers in te zien of aan te maken die betrekking hebben op een financieel advies.

2.6.2. Accordeercontrole GA-producten hersteld (4.1.4.3)

Bij het op Geaccordeerd zetten van een GA-product werd de controle op licenties niet altijd correct uitgevoerd. De controle is aangepast zodat beide licentietypen worden meegewogen.

Je stelt een product in op Geaccordeerd via het venster Inrichting verzekeraar van de volmachtverzekeraar, tabblad Product. Selecteer het gewenste product en voer eventueel een wijziging door. Kies vervolgens in het venstermenu voor Bewaar. Het venster Muteren producthistorie wordt geopend. Selecteer in het veld Nieuwe status product de optie Geaccordeerd en sla de wijziging op. Nieuwe controlelogica Bij het accorderen van een GA-product geldt voortaan de volgende controle:

• Is de licentie Eigen producten actief? Dan is accorderen altijd toegestaan, ongeacht de licentie van de leader van de verdeling.

• Is de licentie Eigen producten niet actief? Dan wordt gecontroleerd of er een licentie aanwezig is voor de leader van de verdeling. Is die aanwezig, dan is accorderen toegestaan. Is die er niet, dan wordt accorderen geblokkeerd.

Voor producten waarbij een maatschappij 100% van de verdeling in handen heeft, geldt: accorderen is toegestaan als er een licentie is voor die maatschappij. Impact GA-producten met een volledige maatschappijverdeling zonder licentie Eigen producten kunnen weer correct op Geaccordeerd worden gezet, mits een licentie voor de betreffende maatschappij aanwezig is. Geen inrichting vereist. Zie ook (zie "Accorderen aangepast (4.1.4.3)" op pagina 15)

2.6.3. Tabblad Verdelingen bij dekking aangepast (4.1.4.4)

Bij een dekking van een product kun je in het tabblad Verdelingen afwijkende verdelingen opgeven. Tot nu toe was dit tabblad niet beschikbaar zodra het product was ingericht met cumulatierisico (veld Meetellen voor cumulatie risico aangevinkt bij het product), ongeacht of het om een gevolmachtigde of om De Onderlingen ging. Dit is aangepast. Het tabblad Verdelingen bij de dekking is nu zichtbaar volgens onderstaande regels:

Relatie Gevolmachtigde (niet De Onderlingen) De Onderlingen De Onderlingen

Meetellen voor cumulatie risico

Tabblad Verdelingen

Aangevinkt of niet aangevinkt

Altijd zichtbaar

Niet aangevinkt Aangevinkt

Zichtbaar Niet zichtbaar

Impact voor jou Bij producten van een gevolmachtigde kun je nu altijd afwijkende verdelingen op dekkingniveau opgeven, ook als cumulatierisico van toepassing is. Bij De Onderlingen blijft dit alleen mogelijk als het product niet is ingericht voor cumulatierisico.

2.6.4. Default verdeling aanwijzen bij een product (4.1.5.1)

Aan een product van de gevolmachtigde kun je meerdere verdelingen koppelen, zolang die dezelfde leader hebben. Tot nu toe legde je daarbij niet vast wélke van die verdelingen de standaard is. Bij een product met meer dan één actieve verdeling was daardoor niet eenduidig welke verdeling gebruikt moet worden. Je wijst nu per product één verdeling aan als default verdeling. Dat doe je op het tabblad Verdelingen van het venster Producten, via Beheer > groep Inrichting > Administratie > Assurantiën > Verzekeraar: kies Wijzigen, selecteer de gevolmachtigde, ga naar het tabblad Producten, selecteer het product en kies opnieuw Wijzigen. Selecteer de verdeling en klik op Zet als default. In de kolom Is Default Verdeling zie je welke verdeling het is. Wanneer een verdeling default wordt

• Koppel je de eerste verdeling aan een product, dan wordt die automatisch de default

verdeling. Koppel je daarna nog een verdeling, dan wordt ook die automatisch de default, tenzij er al een andere verdeling als default is gemarkeerd. Markeer je zelf een verdeling als default, dan vervalt de markering bij de verdeling die dat eerder was. Er kan er maar één tegelijk default zijn. Alleen actieve verdelingen tellen mee. Daarbij kijkt DIAS Assurantie naar twee datums: de Datum Einde van de verdeling zelf en de Einddatum bij Product. Is een van beide verstreken, dan verschijnt het venster Einddatum verdeling bereikt met de melding “Deze verdeling is niet meer actief en kan niet als default gezet worden.” Een datum die niet is ingevuld, telt niet mee. Is bij een product geen enkele actieve verdeling als default gemarkeerd, dan krijg je daarvan bij het bewaren een melding en kun je niet bewaren.

Impact voor jou Bij het aanbrengen van de release worden bestaande producten met precies één actieve verdeling automatisch voorzien van een default; daar hoef je niets voor te doen. Heeft een product meerdere actieve verdelingen, dan wijs je zelf aan welke de standaard is. Zolang dat niet is gebeurd, kun je het product niet bewaren.

Zie ook Een verdeling die voor één product niet meer geldt, kun je daar beëindigen zonder gevolgen voor de andere producten (zie "Verdeling per product of dekking beëindigen (4.1.5.1)" op pagina 22).

2.6.5. Verdeling per product of dekking beëindigen (4.1.5.1)

Een verdeling die aan een product is gekoppeld, kon je niet uit dat product verwijderen zodra hij in gebruik was. Gold de verdeling voor dat product niet meer, dan bleef hij toch kiesbaar. Een einddatum op de verdeling zelf bood geen uitkomst: die geldt voor álle producten die dezelfde verdeling gebruiken. Je geeft nu een einddatum op bij de koppeling tussen het product en de verdeling. De verdeling zelf blijft ongewijzigd en blijft beschikbaar voor de andere producten die hem gebruiken. Dat doe je op het tabblad Verdelingen van het venster Producten, via Beheer > groep Inrichting > Administratie > Assurantiën > Verzekeraar: kies Wijzigen, selecteer de gevolmachtigde, ga naar het tabblad Producten, selecteer het product en kies opnieuw Wijzigen. Selecteer de verdeling en klik op Zet einddatum bij Product. De opgegeven datum staat daarna in de kolom Einddatum bij Product. Hetzelfde kan bij een afwijkende verdeling op dekkingniveau, op het tabblad Verdelingen bij de dekking van het product. Impact voor jou Bij het kiezen van een verdeling in een verzekering of een verzekeringsdekking zie je alleen nog de verdelingen waarvan de einddatum bij dat product of die dekking niet is verstreken. Een verdeling die voor één product is beëindigd, blijft gewoon werken bij de andere producten waaraan hij is gekoppeld. Je hoeft daarvoor dus geen afwijkende verdeling op dekkingniveau meer in te richten. Bij het product zelf kun je zo'n verdeling ook niet meer als default aanwijzen. Zie ook Op hetzelfde tabblad wijs je ook de standaardverdeling aan (zie "Default verdeling aanwijzen bij een product (4.1.5.1)" op pagina 21). Het tabblad Verdelingen is bij een dekking niet altijd beschikbaar (zie "Tabblad Verdelingen bij dekking aangepast (4.1.4.4)" op pagina 20). Dit laatste onderwerp staat in de release notes van een eerdere versie. Je vindt het ook in het online handboek of via Quinn, de digitale assistent in DIAS Assurantie.

2.7. NVGA

2.7.1. NVGA polisrapportage 2.0: aanlevering volger pool gecorrigeerd

(4.1.4.3)

Bij het rapporteren van een verzekering die in een pool zit, werd bij aanlevering aan een volger ten onrechte de productdefinitie van die volger gebruikt. Dit is gecorrigeerd: aanlevering aan een volger gebeurt voortaan conform de minimale productdefinitie. Situatie Een verzekering in een pool wordt gerapporteerd aan zowel de leader als de volgers. Bij rapportage aan de leader wordt de productdefinitie van de leader gebruikt — dit was en blijft correct. Bij rapportage aan een volger moet de minimale productdefinitie worden gebruikt, maar werd tot nu toe de productdefinitie van die volger gebruikt. Correctie Als de te rapporteren verzekeraar een participant in de verdeling is maar niet de leader, worden de volgende labels gevuld conform de minimale productdefinitie:

• PP_AFDDEFN: Minimale AFD-definitie
• PP_ADEFVRS: 003.00

Impact

• Verzekeringen in een pool worden voortaan correct aangeleverd aan volgers, conform de minimale productdefinitie.
• Systemen of koppelingen die de waarden van PP_AFDDEFN en PP_ADEFVRS bij volgers verwerken, moeten rekening houden met de gewijzigde waarden.
• Geen inrichting vereist.

2.7.2. NVGA polisrapportage 2.0: buitenlandse postcode en kenteken

toegevoegd (4.1.4.3)

Buitenlandse postcodes en buitenlandse kentekens werden niet aangeleverd in de NVGA polisrapportage 2.0. Dit is gecorrigeerd: de waarden worden voortaan via de officiële AFDlabels aangeleverd. Achtergrond De SIVI-datacatalogus kent één label voor postcode (YY_PCODE) en één label voor kenteken (YY_KENTEKE), bedoeld voor zowel binnenlandse als buitenlandse waarden. In DIAS worden buitenlandse postcodes en kentekens vastgelegd in afzonderlijke rubrieken (YY_XXPCBUI respectievelijk YY_XXKEBUI). Dit zijn zogeheten pseudo AFD-rubrieken die niet als officieel AFD-label in de NVGA-rapportage mogen worden aangeleverd. Buitenlandse postcode Als de rubriek Radrs_Postcode_Buitenland gevuld is, of als YY_XXPCBUI gevuld is in het objectfilter van de betreffende entiteit, wordt YY_PCODE voortaan gevuld met de buitenlandse postcode. De binnenlandse postcode wordt in dat geval niet gebruikt (die is leeg).

Buitenlands kenteken Als het Nederlandse kenteken niet gevuld is in het filter, wordt YY_KENTEKE voortaan gevuld met het buitenlandse kenteken uit YY_XXKEBUI. Impact

• Verzekeringen met een buitenlands adres of buitenlands kenteken worden voortaan correct opgenomen in de NVGA polisrapportage 2.0.
• De pseudo AFD-rubrieken YY_XXPCBUI en YY_XXKEBUI worden niet aangeleverd in de rapportage; de waarden worden overgebracht naar de officiële labels YY_PCODE en YY_KENTEKE.
• Geen inrichting vereist.

2.7.3. NVGA polisrapportage 2.0: entiteit WM toegevoegd (4.1.4.3)

De entiteit WM (Waardemeter) werd niet aangeleverd in de NVGA polisrapportage 2.0. Dit is gecorrigeerd: WM wordt voortaan meegeleverd voor verzekeringen waarbij waardemeter van toepassing is. Aangeleverde labels De volgende labels worden geschreven binnen de entiteit WM, mits aanwezig in het objectfilter van de betreffende verzekering:

WM_INKHKW WM_GBDTHKW WM_AANTGEZ WM_INHWHS

Impact Verzekeringen met waardemeter worden voortaan correct opgenomen in de NVGA polisrapportage 2.0. Systemen en koppelingen die de rapportage verwerken, kunnen de entiteit WM nu ontvangen waar dat voorheen niet het geval was.

2.7.4. NVGA polisrapportage 2.0: label AFDDTAG gecorrigeerd (4.1.4.3)

In de NVGA polisrapportage 2.0 is de vulling van het label AFDDTAG gecorrigeerd. Het label komt voor in twee blokken in de rapportageoutput: AL (één overkoepelend blok per aanlevering) en PP (één blok per polis). AL_AFDDTAG: entiteit AL alleen aan het begin De entiteit AL verscheen voorheen bij elke polis en schade in de output. Voortaan wordt AL alleen nog aan het begin van de output opgenomen. AL_AFDDTAG wordt gevuld met de waarde NVGA. PP_AFDDTAG: correcte vulling per producttype De vulling van PP_AFDDTAG is aangepast op basis van het producttype:

• Bij verzekeringen gebaseerd op een niet-SUIV productdefinitie: PP_AFDDTAG wordt

gevuld met NVGA. Dit was al correct en blijft ongewijzigd.

• Bij verzekeringen gebaseerd op een SUIV productdefinitie: PP_AFDDTAG wordt gevuld met de waarde uit de nieuwe rubriek Asvpr_SUIV_Tag. Mogelijke waarden zijn

SUIV, SUIV-EP, SUIV-BIJ en SUIV-COMBI. Voorheen werd hier ten onrechte NVGA ingevuld.

Nieuwe rubriek Asvpr_SUIV_Tag Om de correcte waarde voor PP_AFDDTAG bij SUIV-producten te kunnen bepalen, is de nieuwe rubriek Asvpr_SUIV_Tag toegevoegd bij het DIAS-product. Deze rubriek wordt automatisch gevuld bij het importeren van een SUIV-product via de SUIV-importmodule. De rubriek is niet zichtbaar in het DIAS-scherm bij het product. Herstelprogramma voor bestaande producten De rubriek Asvpr_SUIV_Tag wordt automatisch gevuld bij het importeren of updaten van een SUIV-product via de SUIV-importmodule. Voor bestaande producten die niet opnieuw zijn geïmporteerd, is een herstelprogramma beschikbaar in DIAS on premise. Dit programma loopt alle productversies (Asvpr) af en vult Asvpr_SUIV_Tag met de juiste waarde op basis van de productserver-id. Na uitvoering van het herstelprogramma levert de NVGA polisrapportage voor alle producten een correcte waarde in AFDDTAG. Impact

• De entiteit AL verschijnt niet meer bij elke polis en schade, maar alleen aan het begin van de output.

• Bij SUIV-gebaseerde verzekeringen bevat PP_AFDDTAG voortaan de correcte SUIVclassificatie in plaats van NVGA. Systemen of koppelingen die verwachten dat

PP_AFDDTAG bij SUIV-producten altijd de waarde NVGA heeft, moeten worden aangepast.

• De rubriek Asvpr_SUIV_Tag wordt automatisch gevuld bij SUIV-import. Geen handmatige inrichting vereist.

Zie ook (zie "NVGA polisrapportage 2.0: labels gecorrigeerd en uitgebreid (4.1.4.3)" op pagina 25)

2.7.5. NVGA polisrapportage 2.0: labels gecorrigeerd en uitgebreid

(4.1.4.3)

In de NVGA polisrapportage 2.0 zijn zes aanpassingen doorgevoerd in de aanlevering van labels. RC_COLOMS toegevoegd bij raamcontract Het label RC_COLOMS wordt nu meegeleverd wanneer het label RC_NUMMER gevuld is. RC_COLOMS bevat de omschrijving van het raamcontract (collectiviteit) dat bij het contract is vastgelegd. Aanlevering PP_SCHDVRY gecorrigeerd Het label PP_SCHDVRY (schadevrije jaren) wordt voortaan alleen aangeleverd als dat inhoudelijk van toepassing is. Het label wordt meegenomen als:

• de waarde van schadevrije jaren ongelijk is aan 0, of
• de waarde gelijk is aan 0 én de verzekering een dekking WA, Casco of Beperkt casco bevat met een kortingsregeling.

In alle overige gevallen wordt PP_SCHDVRY niet aangeleverd.

PO_VBDRAGA en PO_VBDRAGB vervangen De labels PO_VBDRAGA en PO_VBDRAGB bestaan niet in het AFD-model (de branchestandaard voor uitwisseling van verzekeringsgegevens) en worden niet meer aangeleverd. De waarden zijn voortaan beschikbaar in de correcte labels PO_VWAVPA en PO_VWAVPB. CP_VBDRAGA, CP_VBDRAGB, DA_VBDRAGA en DA_VBDRAGB vervangen Dezelfde correctie is doorgevoerd voor de entiteiten CP en DA. De labels VBDRAGA en VBDRAGB bestaan niet in het AFD-model en worden vervangen door de correcte labels:

• CP_VBDRAGA → CP_NWSTACA
• CP_VBDRAGB → CP_NWTRACA
• DA_VBDRAGA → DA_VRZSOPA
• DA_VBDRAGB → DA_VRZSOMJ

PP_CVS gevuld met unieke sleutel Het label PP_CVS werd gevuld met alleen het versienummer van het contract, wat kon leiden tot dubbele waarden binnen een administratie. Voortaan wordt PP_CVS gevuld met het contractregistratienummer gecombineerd met het versienummer, zodat de waarde uniek is binnen de GA-administratie. PP_INGDTW toegevoegd Het label PP_INGDTW (mutatiedatum van de verzekering) werd niet aangeleverd in de rapportage. Dit is gecorrigeerd: PP_INGDTW wordt voortaan bij elke verzekering meegeleverd met de bijbehorende mutatiedatum. Impact

• Bij contracten met een raamcontract wordt RC_COLOMS automatisch meegeleverd.

Geen inrichting vereist. PP_SCHDVRY verschijnt niet meer bij verzekeringen waarbij schadevrije jaren niet van toepassing zijn. Systemen of koppelingen die gebruikmaken van PO_VBDRAGA of PO_VBDRAGB moeten worden bijgewerkt: gebruik voortaan PO_VWAVPA respectievelijk PO_VWAVPB. Systemen of koppelingen die gebruikmaken van CP_VBDRAGA, CP_VBDRAGB, DA_VBDRAGA of DA_VBDRAGB moeten worden bijgewerkt naar de vervangende labels. De waarde van PP_CVS wijzigt in formaat. Systemen of koppelingen die de oude waarde van PP_CVS verwerken, moeten worden bijgewerkt. PP_INGDTW wordt voortaan bij elke verzekering meegeleverd. Geen inrichting vereist.

Zie ook (zie "NVGA polisrapportage 2.0: label AFDDTAG gecorrigeerd (4.1.4.3)" op pagina 24)

2.7.6. NVGA polisrapportage 2.0: structuur gecorrigeerd (4.1.4.3)

De XML-structuur van de NVGA polisrapportage 2.0 is gecorrigeerd. De output had een onjuiste opbouw waarbij entiteiten op de verkeerde positie stonden en het label Contractdocument ontbrak.

Correcte structuur De output heeft voortaan de volgende opbouw: <AL> ... </AL> <VE> ... </VE> <VL> ... </VL> <BX> <Contractdocument> <AL/> <RC> ... </RC> <PK> ... </PK> <PP> <TP> ... </TP> <VP> ... </VP> <BS> ... </BS> <WA> ... </WA> ... </PP> </Contractdocument> </BX>

Doorgevoerde correcties

• Subentiteiten zoals BS en WA hingen ten onrechte naast PP in plaats van eronder. Dit is gecorrigeerd: deze entiteiten vallen nu correct binnen PP.
• Het label Contractdocument ontbrak in de output. Dit label is toegevoegd als omsluitend element binnen BX.
• Entiteiten RC en PK stonden ten onrechte binnen PP. Ze vallen nu correct binnen BX, buiten PP.
• Entiteiten VE en VL worden niet meer herhaald binnen PP; ze worden alleen bovenin de output aangeleverd.

Impact Systemen en koppelingen die de NVGA polisrapportage 2.0 verwerken, moeten rekening houden met de gewijzigde structuur. De entiteiten staan op andere posities dan voorheen en het element Contractdocument is nieuw toegevoegd.

2.7.7. NVGA polisrapportage 2.0: VP en IK gecorrigeerd (4.1.4.3)

In de aanlevering van de entiteiten VP en IK zijn twee onjuistheden gecorrigeerd. IK niet meer aangeleverd Het label IK_BEROMS staat niet in de AFD-definitie en mag niet worden aangeleverd. De entiteit IK wordt daarom niet meer opgenomen in de rapportage. VP_RELNUM op juiste positie Het label VP_RELNUM stond ten onrechte na de entiteit IK in de XML. Alle VP-labels worden voortaan bij elkaar geplaatst, vóór het openen van een andere entiteit. De correcte volgorde is: <VP> <VP_PARZAKC>...</VP_PARZAKC> <VP_GESLACH>...</VP_GESLACH>

<VP_PCODE>...</VP_PCODE> <VP_GEBDAT>...</VP_GEBDAT> <VP_RELNUM>...</VP_RELNUM> </VP>

Impact

• De entiteit IK wordt niet meer aangeleverd in de rapportage.
• Het label VP_RELNUM staat voortaan op de juiste positie binnen VP. Systemen of

koppelingen die de positie van VP_RELNUM verwerken, moeten hier rekening mee houden.

2.8. Slotvragen

2.8.1. Nieuwe slotvragen (4.1.4.3)

De volgende nieuwe slotvragen zijn opgenomen:

ID

Omschrijving Was de onderneming en/of één van de te verzekeren personen in de afgelopen 5 jaar betrokken bij een verkeersongeval met letselschade? Was de onderneming en/of één van de te verzekeren personen in de afgelopen 5 jaar betrokken bij een arbeids- of huurconflict, een conflict met de overheid of ander conflict? Verwacht u binnen 12 maanden saneringen, fusies, reorganisaties, bedrijfsaankopen of overheidsmaatregelen waardoor er ingrijpende veranderingen in uw onderneming of praktijk gaan plaatsvinden? Heeft de onderneming of een van de te verzekeren personen vaste contacten met een advocaat?

Bij deze slotvragen treedt uitval op wanneer het antwoord Ja is.

2.8.2. Nieuwe slotvragen (4.1.4.4)

De slotvragen zijn uitgebreid met vier nieuwe vragen en drie nieuwe subvragen.

ID

Omschrijving

Is de verzekeringnemer of een andere belanghebbende bij de verzekering de laatste 5 jaar een verzekering van welke aard dan ook opgezegd, geweigerd of aangeboden op beperkte en/of verzwarende voorwaarden? Is er een beroeps- en/of bedrijfsaansprakelijkheidsverzekering afgesloten/aanwezig? 155 Bent u merkdealer en/of aangesloten bij de BOVAG?

Gedrag bij antwoord Uitval bij Ja Uitval bij Nee (zonder toelichting) Uitval bij Nee (zonder toelichting)

ID

Omschrijving

Gedrag bij antwoord

Heeft u eerder een soortgelijke verzekering gehad? Indien ja, dan Subvraag bij Ja svp toelichten. (geen uitval)

Nieuwe subvragen Bij de volgende slotvragen zijn nieuwe subvragen toegevoegd:

ID

Omschrijving

Bij slotvraag

Vervaldatum van de eerder genoten soortgelijke verzekering Naam van de maatschappij waar de eerdere verzekering heeft gelopen Toelichting bijstand door advocaat

Impact voor jou Slotvraag 152 (vaste contacten met een advocaat) is uitgebreid: bij het antwoord Ja verschijnt nu de nieuwe subvraag Toelichting bijstand door advocaat, in plaats van uitval. Zie ook (zie "Nieuwe slotvragen (4.1.4.3)" op pagina 28) Dit onderwerp staat in de release notes van een eerdere versie. Je vindt het ook in het online handboek of via Quinn, de digitale assistent in DIAS Assurantie.

2.9. SUIV

2.9.1. SUIV: ondersteuning voor Klaverblad bij GIM-objecten hersteld

(4.1.4.4)

Bij het uitvoeren van de SUIV-conversie op een Klaverblad-product dat gekoppeld is aan een GIM-object kon de eigenaar van het GIM-object niet worden bepaald. Dit leidde tot de melding "Er kan geen owner id voor de gim object id [nummer] bepaald worden." In de lijst waarin de eigenaar van een GIM-object wordt bepaald, ontbrak Klaverblad. Deze is nu toegevoegd. Impact voor jou De SUIV-conversie van Klaverblad-producten die gekoppeld zijn aan een GIM-object verloopt nu zonder deze melding.

2.9.2. SUIV: verkeerde rubriek in partijfilter bij gelijknamige attributen

hersteld (4.1.4.4)

Sommige SUIV-productdefinities hebben een entiteit (partij) waaronder een subentiteit kan voorkomen, waarbij beide een attribuut met dezelfde naam kunnen bevatten. Bijvoorbeeld:

een product heeft partij OG (Organisatie), waaronder de subentiteit AC kan voorkomen, en beide kennen een attribuut met dezelfde naam. Bij het importeren van zo'n productdefinitie in DIAS Assurantie kon het verkeerde attribuut in het partijfilter belanden. In het filter van de hoofdentiteit kwam dan het gelijknamige attribuut van de subentiteit te staan, terwijl de productdefinitie alleen dat van de hoofdentiteit bevat. In het voorbeeld hierboven: in het filter van partij OG kwam het attribuut van AC te staan. Oplossing Dit is generiek hersteld voor alle entiteiten met subentiteiten die gelijknamige attributen kunnen bevatten: bij het importeren wordt nu altijd de rubriek gekoppeld die daadwerkelijk bij de betreffende entiteit hoort. Impact voor jou Bij het importeren van SUIV-productdefinities met dit soort entiteit/subentiteit-structuren komt het partijfilter nu overeen met de daadwerkelijke productdefinitie.

2.9.3. Rechtsvorm toegevoegd aan SUIV-product NN ZPZ Geld (4.1.4.5)

Bij het zakelijke SUIV-product NN ZPZ Geld is de rechtsvorm van de instantie verplicht voor acceptatie. De rubriek Rechtsvorm bestond al bij de instantie, maar was nog niet gekoppeld aan het bijbehorende label VP_RECHTSV. Daardoor kon een aanvraag of premieberekening stranden op een ontbrekende waarde. Oplossing De rubriek Rechtsvorm is gekoppeld aan het label VP_RECHTSV en gaat mee in de VPIpremieberekening. Impact voor jou Het aanvragen en wijzigen van dit product loopt niet meer vast op een ontbrekende rechtsvorm. Zorg er wel voor dat de rechtsvorm bij de instantie is gevuld, want de acceptatie vraagt die waarde. Je legt de rechtsvorm vast bij de instantie in DIAS Assurantie, of via de relatie-WebAPI met RechtsvormId.

2.9.4. Verzekeringnemer als regelmatige bestuurder ondersteund

(4.1.4.5)

Bij een aantal producten is het label VP_VPBSJN verplicht. Dat label legt vast of de verzekeringnemer ook de regelmatige bestuurder is. Het is premiebepalend voor de VPIberekening en wordt gebruikt bij de VPI-acceptatie. Verzekeraar Unigarant stelt het onder meer verplicht bij motorproducten. Deze waarde was nog niet beschikbaar. Elk contract bevat wel een contractpartij Verzekeringnemer, maar het gaat hier om een overige partij op basis van de verzekeringnemer, en die is bijna nooit aanwezig. Daarvoor is nu een oplossing gemaakt. Wat er gebeurt bij het importeren van een product De SUIV-tooling controleert bij het importeren of het label VP_VPBSJN in het product voorkomt. Is dat zo, dan voegt de tooling een partij verzekeringnemer (VP) toe aan de productdefinitie, met dit ene veld erin.

Zowel DIAS Assurantie als DCB gebruiken die partij vervolgens om het VPI-sjabloon te vullen voor de VPI-acceptatie. Impact voor jou Producten die dit label verplicht stellen, kun je nu premieberekenen en accepteren. Bij producten waarin het label niet voorkomt verandert er niets: daar wordt ook geen partij verzekeringnemer aan de productdefinitie toegevoegd.

2.9.5. Nieuwe licentie voor Productservice Ominimo (4.1.5.1)

Ominimo is als volmachtverzekeraar toegevoegd. Er is een nieuwe licentie beschikbaar voor de productservice van Ominimo, waarmee je AFD-productdefinities van Ominimo kunt importeren en gebruiken in DIAS Assurantie en DCB. Er horen twee POR-codes bij: O731 voor Ominimo Netherlands, de gevolmachtigd agent, en D514 voor DA Deutsche Allgemeine Versicherung, de risicodragende maatschappij. Deze licentie is niet standaard inbegrepen. Je kunt de productservice pas gebruiken nadat je de licentie hebt aangeschaft en geactiveerd. Wil je de licentie aanschaffen, neem dan contact op met je accountmanager, of met Accountmanagement via relatie-vh@blinqx.tech. De onderstaande instructie is alleen van toepassing wanneer de licentie beschikbaar is in jouw omgeving. Impact voor jou Na aanschaf en activatie van de licentie kun je productdefinities van Ominimo rechtstreeks importeren, zonder handmatige invoer of aanvullende configuratie. Korte instructie SUIV-import

1. Controleer of je een geldige licentie hebt. 2. Open de inventarisatietool via Beheer > Inrichting > Administratie >

3. 4.

5. 6.

7. 8.

Productconversie > Inventarisatie. Selecteer het gecertificeerde product. Koppel de juiste verzekeraar. Koppel of maak de benodigde dekkingcodes. Ververs het product. Importeer het product. Controleer bij de verzekeraar of het product is toegevoegd.

Zie ook Bij het autoproduct van Ominimo geldt een nieuwe dynamiekregel (zie "Nieuwe dynamiekregels (4.1.5.1)" op pagina 17). In het portaal is ook het logo van Ominimo opgenomen (zie "Logo Ominimo toegevoegd (4.1.5.1)" op pagina 64).

2.10. Volmachtadministratie

2.10.1. Weergave verwerkt regresbericht hersteld (4.1.4.4)

Als je een regresbericht verwerkt vanuit het venster Verwerken Regresberichten, start je door naar het venster Muteren Schade, waar het bericht direct wordt verwerkt. Tot nu toe was dit zojuist verwerkte bericht niet meteen te zien in het tabblad Regresberichten van Muteren Schade. Pas na het opslaan en opnieuw openen van de schade werd het bericht getoond. Impact voor jou Een verwerkt regresbericht is nu direct zichtbaar in het tabblad Regresberichten, zonder dat je de schade eerst hoeft op te slaan en opnieuw te openen.

2.10.2. Handmatig akkoord voor RDW-berichten toegevoegd (4.1.4.5)

Zolang de terugmelding van de RDW niet in DIAS Assurantie is verwerkt, blijft een RDWbericht staan met de verzendstatus Wacht op terugmelding. Ook wanneer je de melding buiten DIAS Assurantie om alsnog bij de RDW hebt laten verwerken, blijft die status staan. Controleer eerst op de website van de RDW of de oorspronkelijke aan-, af- of wijzigingsmelding daar daadwerkelijk is verwerkt. Geef pas daarna handmatig akkoord. Zet je een bericht op Geaccepteerd door RDW terwijl de RDW de melding niet heeft verwerkt, dan lijkt het in DIAS Assurantie afgehandeld terwijl het voertuig bij de RDW niet is aan- of afgemeld. In het venster Overzicht RDW berichten (via Contracten > Volmacht (Koppelingen) > Overzicht RDW berichten) is daarom op het tabblad Bestand in de groep Hulpmiddelen de knop Handmatig accoord toegevoegd. Selecteer eerst het RDW-bericht in het overzicht en klik daarna op Handmatig accoord. Je handelt één bericht tegelijk af. De knop is alleen beschikbaar als de Verzendstatus van het geselecteerde bericht Wacht op terugmelding is.

Het venster Raadplegen definitieve RDW-meldingen opent met de gegevens van het geselecteerde bericht. Onder in dit venster staan de velden voor het handmatig akkoord:

Veld Handmatig accoord Medewerker handmatig Datum handmatig Tijd handmatig Toelichting handmatig

Toelichting Aangevinkt, om aan te geven dat het bericht handmatig wordt afgehandeld. De medewerker die het akkoord geeft. De datum waarop het akkoord wordt gegeven. Het tijdstip waarop het akkoord wordt gegeven. Vrij tekstveld waarin je vastlegt waarom het bericht handmatig is afgehandeld. Dit veld is niet verplicht.

Alleen Toelichting handmatig vul je zelf in; de andere velden zijn al vooringevuld. Het veld Status verzending staat in dit venster al op Geaccepteerd door RDW. Klik op Bewaar om het

akkoord vast te leggen. Het bericht krijgt dan ook in het venster Overzicht RDW berichten de verzendstatus Geaccepteerd door RDW.

Voor Handmatig accoord is geen aparte licentie nodig: iedereen die met het venster Overzicht RDW berichten werkt, kan de knop gebruiken. Wil je het handmatig akkoord beperken tot bepaalde medewerkers, dan kun je daar zelf een autorisatie op inrichten. Impact voor jou Een RDW-bericht dat je buiten DIAS Assurantie om bij de RDW hebt afgehandeld, kun je nu zelf op Geaccepteerd door RDW zetten. Zulke berichten blijven niet langer op Wacht op terugmelding staan in het venster Overzicht RDW berichten. Bij elk handmatig akkoord wordt

vastgelegd welke medewerker het akkoord heeft gegeven, wanneer dat is gebeurd en welke toelichting daarbij hoort.

3. DIAS Cloud

3.1. DCB

3.1.1. Beveiliging en toegangsbeheer

3.1.1.1. DiasLinkToken-beveiliging hersteld (4.1.4.3) Breaking change DiasLinkTokens worden voortaan gekoppeld aan de specifieke tenant en omgeving waarvoor ze zijn aangemaakt. Tokens zijn daardoor niet meer bruikbaar buiten de context waarvoor ze zijn uitgegeven. Impact Bestaande DiasLinkTokens die zijn aangemaakt vóór deze update zijn niet meer geldig. Nieuwe tokens worden automatisch correct aangemaakt. Er is geen aanvullende inrichting vereist.

3.1.1.2. Bijzonderheden bij verzekering afgeschermd met permissie (4.1.4.5) Breaking change Het veld Bijzonderheden bij een verzekering bevat vaak interne informatie die niet voor iedereen bestemd is. Tot nu toe kon iedereen die de verzekering mocht opvragen ook de bijzonderheden lezen. Op de aanroep GET contract/api/v1/contracten/verzekeringen/{id}/versies/{versienummer}/bijzonderheden geldt daarom vanaf deze versie de nieuwe permissie VerzekeringInzienBijzonderheden:

Licentie: geen Rollen: Medewerker, Agent en Relatie Autoriseerbaar: ja Standaard aan voor de rol Medewerker, standaard uit voor de rol Agent

De permissie geldt alleen voor het inzien van de bijzonderheden, niet voor het wijzigen ervan. Impact voor jou Voor medewerkers verandert er niets. Agenten en relaties kunnen de bijzonderheden van een verzekering niet meer opvragen. Wil je dat zij daar wél bij kunnen, zet de permissie VerzekeringInzienBijzonderheden dan open voor de betreffende rol. Zie ook (zie "Bijzonderheden bij verzekering alleen zichtbaar met permissie (4.1.4.5)" op pagina 59) voor wat dit betekent in het portaal.

3.1.2. Functionele en technische verbeteringen

3.1.2.1. HangFire verwijderd uit Scenario.Enterprise (4.1.4.4) Breaking change Achtergrond Bij de migratie naar .NET 8 is de HangFire-service al verwijderd uit de .NET 8-versie van Scenario.Enterprise (versie 4.1.4.2). De niet-.NET 8-versie van Scenario.Enterprise bevatte HangFire echter nog wel. Dat verschil leidde tot verwarring en problemen, met name wanneer eerst de .NET 8-versie werd geïnstalleerd en vervolgens - vanwege resterende problemen in die versie - werd teruggeschakeld naar de niet-.NET 8-versie. Wijziging HangFire is nu ook verwijderd uit de niet-.NET 8-versie van Scenario.Enterprise. Beide versies zijn hiermee weer gelijk wat betreft deze functionaliteit. Impact voor jou Bulk vervaardiging van documenten is niet langer beschikbaar. Wordt er toch een run van het type Bulk gestart, dan verschijnt een systeemlogmelding dat dit niet langer wordt ondersteund. Gebruik voor documentvervaardiging voortaan een ander type run.

3.1.2.2. Ophalen codering beroep hersteld (4.1.4.5) Breaking change De aanroep GET codering/api/v1/coderingen/beroepen/{id} gaf de codering van de burgerlijke staat terug in plaats van het beroep. Vanaf deze versie levert deze aanroep het beroep dat bij het opgegeven id hoort. Daarmee verandert ook de structuur van het antwoord: je krijgt nu een Beroep-object met BeroepId en de bijbehorende beroepsomschrijving, in plaats van een BurgerlijkeStaat-object met BurgerlijkeStaatId. Impact voor jou Roep je deze ingang aan, controleer dan wat je met het resultaat doet. Het antwoord op dezelfde aanroep is nu een ander gegeven dan voorheen. Gebruikte je deze ingang om een burgerlijke staat op te halen, dan werkt dat niet meer. Haal de burgerlijke staat op via de coderingen voor burgerlijke staat: codering/api/v1/coderingen/burgerlijkestaten. Gaf je een id uit de coderingen voor burgerlijke staat mee aan de beroepen-ingang, dan levert dat geen bruikbaar resultaat meer op. Gebruik voortaan een id uit de coderingen voor beroepen.

3.1.2.3. Acceptatieregel bij muteren verzekering in pakket hersteld (4.1.4.3) Bij het muteren van een verzekering in een pakket via DCB werd een overtreden acceptatieregel ten onrechte niet geblokkeerd. De blokkade werd geplaatst op de eerste

verzekering in het pakket; bij het muteren van een andere verzekering in hetzelfde pakket kon het mutatieproces ten onrechte worden voortgezet. De blokkade wordt nu correct toegepast op de gemuteerde verzekering, ongeacht de volgorde in het pakket. Impact Acceptatieregels blokkeren bij muteren van verzekeringen in een pakket nu correct, ook als het niet de eerste verzekering in het pakket betreft. Dit geldt alleen bij muteren, niet bij aanvragen.

3.1.2.4. Financiële posten API uitgebreid (4.1.4.3) De API voor financiële posten is op twee manieren uitgebreid: posten kunnen worden gefilterd op extern boeking-id, en de detailresultaten bevatten drie nieuwe velden. Zoeken op extern boeking-id De volgende endpoints ondersteunen een nieuwe optionele query-parameter externboekingid:

Endpoint

Parameter

Type

Toelichting

financieel/api/v1/posten

externboekingid

string (optioneel)

Alleen posten met exact dit extern boeking-id worden geretourneerd. Een lege waarde retourneert posten zonder extern boeking-id.

financieel/api/v1/posten/detail

externboekingid

string (optioneel)

Zie boven.

Nieuwe velden in de response De volgende endpoints retourneren drie nieuwe velden:

• financieel/api/v1/posten/detail
• financieel/api/v1/posten/{id}

Veld

Type

Omschrijving

ExternBoekingId

string

Extern boeking-id van de post.

IsRegres

bool

Geeft aan of de post een regrespost betreft.

IsContant

bool

Geeft aan of de post een contante betaling betreft.

3.1.2.5. GET schades uitgebreid met IsSchaderegelingsbevoegd (4.1.4.3) Het endpoint GET /api/v1/schades/{id} is uitgebreid met de property IsSchaderegelingsbevoegd. Dit is een ja/nee-veld dat aangeeft of er schaderegelingsbevoegdheid van toepassing is bij de betreffende schade. Opmerking Dit veld heeft geen relatie met DCB-permissies. Het betreft uitsluitend een informatief veld op de schade.

3.1.2.6. Landingspagina-e-mail opnieuw versturen toegevoegd (4.1.4.3) Het nieuwe endpoint PUT scenarios/opnieuwaanbieden maakt het mogelijk een landingspagina-e-mail opnieuw te versturen. Dit is bedoeld voor situaties waarbij de klant de oorspronkelijke e-mail is kwijtgeraakt of de link niet meer werkt. Gedrag bij opnieuw versturen Bij het opnieuw versturen gelden de volgende regels:

• De klant ontvangt een nieuwe link en een nieuwe verificatiecode.
• De aanbod-datum (DatumAanbod) blijft ongewijzigd — het origineel wordt behouden.
• De geldigheid van het nieuwe token loopt tot de oorspronkelijke vervaldatum van de offerte (DatumOfferte + VervalDagenOfferte). De looptijd wordt niet opnieuw gestart vanaf vandaag.
• Als de offerte al verlopen is, wordt het opnieuw versturen geweigerd.

Voorwaarden

• Het scenario moet de status Offerte hebben.
• Het scenario moet eerder zijn aangeboden via de landingspagina (AangebodenViaLandingspagina). Bij handmatig aangeboden scenario's wordt geen e-mail verstuurd.
• Bij de relatie moet een e-mailadres bekend zijn.

Impact Adviseurs kunnen een verlopen of verloren landingspagina-link opnieuw aanbieden zonder een nieuw scenario te hoeven aanmaken. De oorspronkelijke offertedatum en vervaltermijn blijven leidend.

3.1.2.7. Royeren uitgebreid met gebeurteniscode (4.1.4.3) Bij het royeren van een verzekering kon je nog geen specifieke gebeurteniscode opgeven. De code die bij het royement werd vastgelegd was altijd de standaard royement-gebeurtenis, ongeacht de reden van opzegging. Daardoor was het niet mogelijk om op basis van royementsgegevens in de database te analyseren waarom verzekeringen worden geroyeerd. Aan de royeer-aanroep is het optionele veld GebeurtenisId toegevoegd. Hiermee geef je de code aan die bij het royement wordt vastgelegd. Je kiest een gebeurteniscode van het type Royement. Beschikbare codes zijn op te vragen via het GET-endpoint in de tabel hieronder. Gedrag Het GebeurtenisId is optioneel. Als je geen GebeurtenisId opgeeft, werkt het royement op dezelfde manier als voorheen: de standaard royement-gebeurtenis wordt vastgelegd. Als je

een geldig GebeurtenisId opgeeft, wordt die gebeurteniscode in de contractgebeurtenis opgeslagen. Bij een ongeldig GebeurtenisId — een niet-bestaande code of een code van een ander type dan Royement — wordt het royement geweigerd met een foutmelding. Betrokken endpoints

Endpoint

Gebruik

PUT levensverzekeringmaatschappijen Royeren van een losse verzekering PUT Royeren van een of meer verzekeringen binnen contract/api/v1/contracten/pakketten/wijzig een pakket en GET Opvragen van beschikbare gebeurteniscodes, codering/api/v1/coderingen/gebeurtenisse inclusief type n

Impact Royementen zonder GebeurtenisId werken ongewijzigd. Wil je per royement vastleggen wat de reden van opzegging is, dan kun je voortaan een gebeurteniscode van het type Royement meegeven. Dit maakt het mogelijk om achteraf per royement te zien wat de reden van opzegging was.

3.1.2.8. VPI-premieberekening uitgebreid met deadlock-herpoging (4.1.4.3) Bij het uitvoeren van een VPI-premieberekening kon de rekenbox in een deadlock terechtkomen. In dat geval mislukte de berekening en kreeg de gebruiker een foutmelding, ook al was de deadlock van tijdelijke aard. DIAS detecteert nu of er tijdens de VPI-premieberekening een deadlock optreedt. Omdat een deadlock meestal niet herhaalbaar is, wordt de berekening in dat geval automatisch opnieuw geprobeerd, tot maximaal vijf keer. Slaagt een van de herpogingen, dan wordt de premieberekening alsnog succesvol afgerond. Impact Tijdelijke deadlocks leiden niet langer direct tot een mislukte VPI-premieberekening. Gebruikers merken hier niets van: de herpoging verloopt automatisch op de achtergrond.

3.1.2.9. Provisieschuif met korting per dekking hersteld (4.1.4.4) Bij het wijzigen van een verzekering via DCB kun je in de provisieschuif kiezen of de provisiekorting geldt voor alle dekkingen samen of per dekking. Bij de keuze Per dekking werd de korting niet goed doorgegeven aan de premieberekening. Dat leidde tot twee situaties:

• Bij een verzekering met één dekking bleef de premie gelijk aan de oorspronkelijke premie. De ingevulde provisiekorting had geen effect.

• Bij een verzekering met meerdere dekkingen mislukte de premieberekening met de

melding De provisies zijn niet gelijk over alle dekkingen, ook als je bij elke dekking hetzelfde kortingspercentage had ingevuld. Bij een deel van de dekkingen werd namelijk het ongekorte provisiepercentage gebruikt.

Bij de keuze Alle dekkingen werd de korting wel correct verwerkt. Verbetering De provisiekorting per dekking wordt nu op elke dekking toegepast en met het juiste percentage doorgegeven aan de premieberekening. De uitkomst is daarmee gelijk aan die van de keuze Alle dekkingen wanneer je bij alle dekkingen hetzelfde percentage opgeeft. Impact voor jou Je kunt de provisieschuif weer per dekking gebruiken. De premie wordt berekend met de korting die je hebt ingevuld, en de premieberekening wordt niet meer afgewezen omdat de provisies over de dekkingen zouden verschillen.

3.1.2.10. Scenario-ophalen uitgebreid met IsLaatsteVersie (4.1.4.4) Bij het ophalen van een scenario met de onderliggende pakketten en verzekeringen is een nieuw veld IsLaatsteVersie (boolean) toegevoegd aan PakketVersieHuidig en VerzekeringVersieHuidig. Dit veld geeft aan of de opgehaalde versie van het pakket of de verzekering de meest actuele versie is. De waarde van dit veld wordt dynamisch bepaald, op vergelijkbare wijze als het bestaande veld IsMutatieMogelijk. Impact voor jou Met dit veld kun je bepalen of er een nieuwere versie van een pakket of verzekering beschikbaar is, zonder hiervoor een aanvullende WebAPI-aanroep te hoeven doen. Dit beperkt onnodige aanvullende aanroepen en daarmee de belasting op de WebAPI.

3.1.2.11. Aanpasbare clausules bij aanvragen en wijzigen (4.1.4.5) Clausules bij een verzekering bevatten tekst die een beperking aangeeft, bijvoorbeeld dat oorlogsschade is uitgesloten. In DIAS Assurantie kon je de tekst van zo'n clausule al per verzekering aanpassen. Vanaf deze versie kan dat ook via de WebAPI, bij het aanvragen en wijzigen van een verzekering. Zo kun je maatwerk leveren binnen de ruimte die de verzekeraar toestaat. Voor welke clausules geldt dit Aanpassen kan alleen bij clausules die in de productinrichting als aanpasbaar zijn aangemerkt. Dat leg je vast met het veld Aanpassen toegestaan in het venster Muteren Beperking (via het venster Inrichting verzekeraar), bij een beperking van het type Clausule. Het aanpassen geldt voor alle soorten clausules: automatisch bepaalde, verplichte en handmatig gekoppelde. Clausulebladen en voorwaarden kun je niet aanpassen, en clausules onder een pakket ook niet: clausules horen bij een verzekering, niet bij een pakket.

Of een clausule aanpasbaar is, zie je aan het nieuwe veld IsAanpasbaar (true of false). Dit veld staat in:

• de response van alle clausule-opvragen bij een verzekering of een dekking;
• de response van een preview en van een premieberekening, bij zowel aanvragen als wijzigen;
• de productdefinitie van een verzekeringsproduct, bij HandmatigeClausules.

Bij clausulebladen, voorwaarden en clausules onder een pakket is de waarde altijd false. Een clausule aanpassen Bij het aanvragen of wijzigen van een verzekering geef je in de request-body de lijst ClausuleAanpassingen mee. Per aanpassing geef je twee gegevens op:

Veld

Toelichting

ClausuleId Tekst

De clausule die je wilt aanpassen. De nieuwe tekst, die de oorspronkelijke tekst overschrijft.

De lijst bestaat op twee niveaus: op verzekeringsniveau voor clausules die aan de verzekering hangen, en per dekking voor clausules die aan die dekking hangen. Er is één werkwijze voor alle situaties: of de clausule nu automatisch is bepaald, handmatig is gekoppeld of al aan de verzekering hing, je geeft altijd het ClausuleId met de nieuwe tekst op. Koppel je een clausule handmatig én pas je de tekst aan, dan geef je dus twee dingen op: de koppeling en de aanpassing. Gaat het om een automatisch bepaalde clausule die nog niet aan de verzekering hangt, voer dan eerst een preview of een premieberekening uit. In dat resultaat zie je welke clausules gekoppeld gaan worden en wat hun ClausuleId is. Voor handmatig te koppelen clausules is dat niet nodig: daarvoor staat IsAanpasbaar al in de productdefinitie. Ook de pakket-ingangen ondersteunen clausule-aanpassingen, omdat verzekeringen binnen een pakket via die ingangen worden aangevraagd en gewijzigd. Wat er met de oorspronkelijke clausule gebeurt De standaardtekst van de clausule verandert niet. Bij een aanpassing wordt een eigen versie van de clausule aangemaakt die alleen voor deze verzekering- of dekkingversie geldt. Elke aanpassing staat dus los van andere verzekeringen. Pas je binnen dezelfde, nog niet definitieve verzekeringversie de clausule nog een keer aan, dan wordt die eigen versie overschreven. Er ontstaat dan geen reeks ongebruikte clausuleversies. Permissie Clausules aanpassen mag alleen met de nieuwe permissie VerzekeringWijzigenAanpassenClausules:

• Licentie: Volmacht

• Rol: Medewerker
• Autoriseerbaar: ja

Zonder deze permissie wordt ClausuleAanpassingen in de request genegeerd. Je krijgt dan geen foutmelding, maar de aanpassing wordt ook niet doorgevoerd. Foutmeldingen Bij een onjuiste aanpassing volgt een Bad Request met een van deze foutcodes. De foutgegevens bevatten in elk geval het VerzekeringId of VerzekeringResourceId, en waar van toepassing het DekkingId of DekkingResourceId.

Foutcode

Melding

Situatie

ClausuleOngeldig

Ongeldige clausule: {ClausuleId}

Het opgegeven ClausuleId is niet gekoppeld aan de verzekering of dekking, en wordt er ook niet aan gekoppeld.

Het is niet toegestaan om ClausuleOngeldig Clausule {ClausuleId} aan te De clausule is niet aanpasbaar. passen. Het is niet toegestaan om Hetzelfde ClausuleId is meer dan één keer ClausuleOngeldig meer dan één aanpassing van opgegeven. een clausule op te geven. Het is verplicht een ClausuleId Bij een aanpassing is geen ClausuleId ClausuleVerplicht op te geven bij een clausuleopgegeven. aanpassing. Het is verplicht een tekst op te Bij een aanpassing is geen tekst TekstVerplicht geven bij een clausuleopgegeven. aanpassing.

Pas je een automatisch bepaalde clausule aan die door dezelfde wijziging juist vervalt, dan geldt die clausule als niet gekoppeld en krijg je ClausuleOngeldig. Dat is bewust: zo'n aanpassing kan juridische betekenis hebben en mag niet ongemerkt wegvallen. Impact voor jou Je kunt een acceptant nu ook via de WebAPI per verzekering laten afwijken van de standaardtekst van een clausule, zonder gevolgen voor andere verzekeringen of voor de clausule zelf. De verzekeraar bepaalt via de productinrichting welke clausules die ruimte krijgen. Zie ook Handmatige beperkingen bij aanvragen en wijzigen (4.1.3.5) voor het toevoegen en verwijderen van clausules, clausulebladen en voorwaarden. Dit onderwerp staat in de release notes van een eerdere versie. Je vindt het ook in het online handboek of via Quinn, de digitale assistent in DIAS Assurantie.

3.1.2.12. Documentgeneratie-API uitgebreid met terugmelden van het generatieresultaat (4.1.4.5) Processen die documenten of rapporten genereren buiten de Scenario-WebAPI om, kunnen het resultaat van die generatie nu op een vaste manier terugmelden. Daarvoor zijn drie ingangen toegevoegd aan de documentgeneratie-API:

URL

Toelichting

PUT document/api/v1/docgen/generatie/zetbezig

Meldt dat een documentgeneratie bezig is.

PUT document/api/v1/docgen/generatie/zetmislukt

Meldt dat een documentgeneratie is mislukt, inclusief foutinformatie.

POST document/api/v1/docgen/generatie/zetdocument?generatie id={generatieid}

Levert het gegenereerde document aan.

Alle drie de ingangen werken op basis van het generatie-id dat aan het generatieproces is meegegeven. Een mislukte generatie melden Bij zetmislukt geef je naast het generatie-id een ResourceId mee. Dat is verplicht en zorgt ervoor dat je de aanroep kunt herhalen zonder dat de fout dubbel wordt verwerkt. Daarnaast geef je de foutgegevens mee:

Veld Foutdomein Foutmelding Foutinformatie

Toelichting Systeembeheer of Applicatiebeheer. Geef je niets op, dan wordt het Systeembeheer. Korte, leesbare tekst voor de gebruiker. Langer dan 254 tekens wordt afgekapt, zonder melding aan de aanroeper. Houd de tekst dus kort en gericht op de eindgebruiker. Uitgebreide toelichting voor de applicatie- of netwerkbeheerder.

De uitgebreide foutinformatie blijft minimaal vier dagen beschikbaar. Daarna wordt die opgeruimd en levert het opvragen ervan de tekst "Het log is verwijderd. Er is geen verdere foutinformatie beschikbaar." Onderzoek een mislukte generatie dus binnen die termijn.

Het gegenereerde document aanleveren Bij zetdocument geef je het generatie-id mee als query-parameter. Het document zelf gaat als bestandsupload mee in de body, inclusief de bestandsnaam. Een gewone JSON-body wordt afgewezen. De bestandsnaam is verplicht: uit de extensie wordt het documenttype afgeleid, bijvoorbeeld PDF of DOCX. Ontbreekt de extensie of is die onbruikbaar, dan wordt het document niet geaccepteerd. Geldigheid van het generatie-id Het generatie-id is vluchtig. Zodra de generatie is afgesloten, geslaagd of mislukt, vervalt het. Voor een volgende generatie moet de container eerst worden gereset. Bij een aanroep op een id dat niet meer bruikbaar is, krijg je een Bad Request met een van deze foutcodes:

Foutcode

Situatie

Het generatie-id is vervallen of heeft nooit bestaan. Deze twee situaties zijn voor de aanroeper niet te onderscheiden. OpmaakStatusOngeldig Het generatie-id is nog geldig, maar de generatie is al afgerond. BestaatNiet

Opslag van de documenten De gegenereerde documenten worden bewaard in de nieuwe map Dossier\DGCons\Verlopend. Deze map wordt automatisch aangemaakt en is opgenomen in de diagnose op het bestandssysteem. Impact voor jou Er zijn alleen ingangen en foutcodes toegevoegd; bestaand gedrag en bestaande contracten zijn ongewijzigd. Voor eindgebruikers verandert er niets. Deze uitbreiding is bedoeld voor processen die documentgeneratie buiten de Scenario-WebAPI om uitvoeren en het resultaat willen terugmelden.

3.1.2.13. Doelmappen voor documentgeneratie inrichten in Scenario.Enterprise (4.1.4.5) De documentgeneratie via Scenario.Enterprise levert XML-bestanden af in een map. XMLbestanden in een map die door EDODocMon en EDODocGen wordt gemonitord, worden automatisch omgezet naar PDF-documenten. XML-bestanden in andere mappen gelden als voorbeeld-XML, waarmee je in de documentdesigner EDODesign een preview kunt maken. Tot nu toe werden deze mappen altijd in DIAS Assurantie ingericht, via Beheer > Inrichting > Coderingen > Beheer > Productvervaardiging export doel. Vanaf deze versie kan een netwerkbeheerder de gemonitorde mappen rechtstreeks opgeven bij Scenario.Enterprise. Het is dan niet meer nodig om die mappen in DIAS Assurantie te beheren. Dat heeft drie voordelen:

• De ingevoerde mappen zijn niet in te zien of te wijzigen door de gebruiker.
• Op acceptatieomgevingen wordt vaak een kopie van de productiedatabase gezet, inclusief de daarin ingerichte mappen. Zonder aanpassing kunnen vanuit de

acceptatieomgeving documenten in de productieomgeving terechtkomen. Met de nieuwe inrichting is dat niet meer mogelijk.

• Voor het beheer van deze mappen hoeft een netwerkbeheerder niet meer als gebruiker in DIAS Assurantie in te loggen.

De oude manier van inrichten blijft voorlopig ondersteund. Je kunt dus zelf het moment kiezen waarop je overstapt; de installatie van deze versie dwingt daar niets in af. Wij raden aan om over te stappen. De map voor voorbeeld-XML blijft vooralsnog wel in DIAS Assurantie beheerd worden. Inrichting in Scenario.Enterprise Neem de mappen op bij de tenantgegevens van de tussenpersoon bij Scenario.Enterprise. Let op: dit zijn niet de tenantgegevens van Scenario.WebApi. Het gaat om twee instellingen onder document:

Instelling exportTargetDirect exportTargetBulk

Toelichting Verwijst naar de DirectDir-map uit de configuratie van EDODocMon. Verwijst naar de BulkDir-map uit diezelfde configuratie. Deze instelling heeft nu nog weinig betekenis binnen het systeem, maar dat verandert in de toekomst.

Neem het pad naar de BulkDir-map niet letterlijk over uit de configuratie van EDODocMon. Daar staat doorgaans een lokaal pad, terwijl je hier vrijwel altijd een pad naar een andere server nodig hebt. De inrichting controleren Of de nieuwe inrichting actief is en goed werkt, controleer je met de diagnose-ingang in Swagger, onder Scenario WebApi – Gateway. De diagnose controleert nu ook de twee mappen die in de tenant van Scenario.Enterprise zijn ingericht. Is een van de mappen niet opgegeven, dan volgt een waarschuwing dat de documentgeneratie in plaats daarvan de doelmap uit de database van DIAS Assurantie gebruikt. Dat is een legacy-optie die op termijn waarschijnlijk verdwijnt. Is de map wel opgegeven, dan controleert de diagnose of er bestanden in gelezen en geschreven kunnen worden en volgt bij problemen een foutmelding. Overstappen op de nieuwe inrichting Zijn de mappen nu correct ingericht in DIAS Assurantie, dan blijft dat voorlopig werken. Ga als volgt te werk als je overstapt: 1. Zoek het huidige doel op via Beheer > Inrichting > Administratie > Externe Documentopmaak > Instellingen Externe Documentopmaak. Achter het opgegeven doel ligt het pad naar de DirectDir-map van EDODocMon. Je bekijkt dat pad door met de rechtermuisknop op het veld te klikken en te kiezen voor Raadplegen. 2. Neem dat pad over in exportTargetDirect bij de tenantgegevens van Scenario.Enterprise, en vul exportTargetBulk met het pad naar de BulkDir-map.

3. Maak in hetzelfde venster het veld Selecteer het doel voor de dagverwerking leeg en sla de wijziging op. De PDF-generatie verloopt dan via de instelling in Scenario.Enterprise. 4. Voer een documentgeneratie uit vanuit een relatie of verzekering, voor een tekstlay-out die is ingericht voor Externe Documentopmaak. Slaagt die, dan is de inrichting in Scenario.Enterprise juist uitgevoerd.

Mappen verwijderen uit DIAS Assurantie De twee mappen die nu in de tenant van Scenario.Enterprise staan, hoeven niet langer in DIAS Assurantie te staan. Verwijder ze niet meteen. Voor de documentgeneratie worden productaanvraag-runs in de database aangemaakt, en runs van vóór de nieuwe inrichting verwijzen nog naar de mappen in DIAS Assurantie. Verwijder je die mappen, dan werken zulke runs niet meer. Wacht daarom enkele dagen tot de openstaande runs zijn uitgevoerd. Wil je extra zeker zijn, wacht dan een of twee maanden. Daarna verwijder je de mappen via Beheer > Inrichting > Coderingen > Beheer > Productvervaardiging export doel. Verwijder alleen de mappen die je in de tenant hebt opgenomen; de overige doelen zijn bedoeld voor voorbeeld-XML en moeten blijven bestaan. Als de inrichting niet klopt

• Krijg je bij documentgeneratie een foutmelding van de Microsoft Visual C++ Runtime

Library, dan zijn exportTargetDirect in de tenant én de Direct-map in DIAS Assurantie allebei niet ingericht. Gebruik je documentgeneratie via DCB, dan moet minimaal een van de twee zijn opgegeven.

• Blijft de documentgeneratie hangen op Bezig met opmaken documenten, dan komt het gegenereerde XML-bestand mogelijk niet in een map terecht die EDODocMon monitort.

Gebruik bij elke fout die uit de inrichting kan voortkomen de diagnose-ingang om te bepalen wat er misgaat. Impact voor jou Voor de eindgebruiker verandert er niets zolang de mappen correct zijn ingericht, op de oude of de nieuwe manier. Na de overstap zijn de doelmappen niet meer zichtbaar of aanpasbaar in DIAS Assurantie. Zie ook (zie "Nieuw veld Type PDF-generatie bij Externe documentopmaak (4.1.4.5)" op pagina 8) voor de keuze tussen directe en bulkgeneratie in een run.

3.1.2.14. Zoeken naar documentgeneratie-runs uitgebreid met statusfilter (4.1.4.5) Documentgeneratie wordt asynchroon uitgevoerd in runs. Met GET document/api/v1/runs vraag je de productaanvraag-runs op die aan de opgegeven criteria voldoen. Tot nu toe kon je daarbij filteren op de ouderrun (ouderrunid) en het aantal resultaten beperken (limit).

Deze aanroep is uitgebreid met de optionele query-parameter statusRunId. Geef je die mee, dan worden alleen de runs met die status geretourneerd, bijvoorbeeld alleen de runs met de status Mislukt. Laat je de parameter weg, dan verandert er niets aan het resultaat.

URL GET document/api/v1/runs

Parameter

statusRunId

Type

Toelichting

string (optioneel)

Alleen runs met deze status worden geretourneerd. Zonder deze parameter worden de runs met alle statussen geretourneerd.

Je geeft de naam van de status mee. De mogelijke waarden zijn:

NotSet Initieel BezigMetVerzamelenGegevens KlaarMetVerzamelenGegevens BezigMetOpmakenDocumenten KlaarMetOpmakenDocumenten Mislukt BezigMetStartenRun KlaarVoorAfdrukkenVerzenden BezigMetOnderliggendeRuns

Impact voor jou Je kunt runs nu gericht opvragen op status, bijvoorbeeld om alleen de mislukte runs op te halen. Je hoeft daarvoor niet meer alle runs op te vragen en die zelf te filteren.

3.1.2.15. Machtiging bij wijzigen rekeningnummer hersteld (4.1.4.5) Bij automatische incasso worden de machtigingsgegevens vastgelegd bij het scenario. Wijzigde je daarna het rekeningnummer, dan werden die machtigingsgegevens niet in alle situaties bijgewerkt. Dit speelde bij scenario's in de fase Advies. Oplossing De machtigingsgegevens bij het scenario worden nu ook bijgewerkt als het rekeningnummer wijzigt in de fase Advies. De machtiging hoort daarmee altijd bij het rekeningnummer dat op dat moment in het scenario staat. Zie ook (zie "Machtigen-knop bij automatische incasso hersteld (4.1.4.4)" op pagina 55) (zie "Blokkerende controle bij akkoord automatische incasso hersteld (4.1.4.4)" op pagina 55) Deze onderwerpen staan in de release notes van een eerdere versie. Je vindt ze ook in het online handboek of via Quinn, de digitale assistent in DIAS Assurantie.

3.1.2.16. Notatie versienummer bij opvragen omgeving hersteld (4.1.4.5) Bij een standalone-installatie gaf de aanroep GET /api/v1/systeem/omgeving het versienummer terug zonder punt tussen de patchversie en het buildnummer, bijvoorbeeld 4.144.10170011. Het buildnummer zat daardoor vastgeplakt aan de patchversie. Oplossing Het versienummer heeft nu overal dezelfde notatie, met een punt tussen de patchversie en het buildnummer: 4.144.10.170011. Dit speelde alleen bij een standalone-installatie. Bij een installatie via Service Fabric was de notatie al juist, net als bij /systeem/status en in het NVGA-portefeuillerapport. Impact voor jou Lees je het versienummer uit deze aanroep uit, controleer dan hoe je het verwerkt. Werkte je met een eigen oplossing om patchversie en buildnummer uit elkaar te halen, dan is die niet meer nodig.

3.1.2.17. Aanpasbare clausule bij een nieuwe verzekering (4.1.5.1) Een clausule waarvan de verzekeraar de tekst aanpasbaar heeft gemaakt, kun je zelf aan een verzekering toevoegen en daarna aanpassen. Bij een verzekering die nog nieuw is in het scenario lukte dat niet: zowel het toevoegen als het verwijderen van zo'n handmatige, aanpasbare clausule leverde de melding op dat aanpasbare clausules nog niet werden ondersteund. Bij een bestaande verzekering ging het wel goed. Beide handelingen werken nu ook bij een nieuwe verzekering. Impact voor jou Je voegt een aanpasbare clausule toe zodra je de verzekering samenstelt, in plaats van te wachten tot ze bestaat. Bestaande aanroepen blijven werken; er vervallen alleen twee foutsituaties. Zie ook De verzekeraar bepaalt via de productinrichting welke clausules aanpasbaar zijn (zie "Aanpasbare clausules bij aanvragen en wijzigen (4.1.4.5)" op pagina 41). Dit onderwerp staat in de release notes van een eerdere versie. Je vindt het ook in het online handboek of via Quinn, de digitale assistent in DIAS Assurantie.

3.1.2.18. Gewijzigde instelling direct overal actief (4.1.5.1) Instellingen worden in het geheugen bewaard, zodat ze niet bij elke aanroep opnieuw hoeven te worden opgehaald. Wijzig je een instelling, dan wordt dat geheugen geleegd en halen de onderdelen de nieuwe waarde op. Dat legen kwam niet overal aan. Een onderdeel kon daardoor met de oude waarde blijven werken totdat het opnieuw was gestart. Dat is verholpen: een gewijzigde instelling geldt nu meteen voor alle onderdelen.

Impact voor jou Pas je een instelling aan, dan werkt die direct door. Je hoeft niet te wachten tot een onderdeel opnieuw is gestart om het effect te zien.

3.1.2.19. Mislukte documentgeneratie als beheerdersmelding (4.1.5.1) Meld je via de WebAPI dat een documentgeneratie is mislukt, dan wordt dat nu ook vastgelegd als beheerdersmelding. Je ziet die bij de systeemmeldingen in DIAS Assurantie en je kunt hem opvragen met GET beheer/api/v1/beheerdersmeldingen en GET beheer/api/v1/beheerdersmeldingen/{id}. Daarmee blijft een mislukte generatie zichtbaar voor de beheerder, ook als degene die de generatie startte er niets meer mee doet. Wat de beheerder te zien krijgt Dat hangt af van het foutdomein dat bij de melding is opgegeven. Bij Applicatiebeheer komt de opgegeven foutinformatie in de melding te staan. Bij Systeembeheer staat er in plaats daarvan een vaste tekst: “Er is een probleem met de installatie of programmatuur van de documentgeneratie. Neem contact op met uw netwerkbeheerder. Het probleem is gelogd.” Gewijzigd gedrag bij een onbekend foutdomein Gaf je bij het melden van een mislukking een foutdomein op met een waarde die niet in de lijst voorkomt, dan leverde dat een serverfout op en ging de vastlegging van de fout verloren. Dat wordt nu gewoon verwerkt, met de verwijzing naar de netwerkbeheerder. Dit geldt ook bij het zetten van een foutstatus op een productaanvraag-run. Impact voor jou Een mislukte documentgeneratie komt voortaan bij de beheerder terecht in plaats van alleen in het antwoord van de aanroep. Het formulier en de antwoorden van de ingang zelf veranderen niet, dus bestaande aanroepen blijven werken. Zie ook Het melden van een mislukte generatie en de bijbehorende foutgegevens staan beschreven in (zie "Documentgeneratie-API uitgebreid met terugmelden van het generatieresultaat (4.1.4.5)" op pagina 44). Dit onderwerp staat in de release notes van een eerdere versie. Je vindt het ook in het online handboek of via Quinn, de digitale assistent in DIAS Assurantie.

3.1.2.20. Mutatie vóór voorlaatste hoofdvervaldatum valt uit (4.1.5.1) Wijzigingen die een adviseur invoert, worden in de acceptatiefase waar mogelijk automatisch geaccepteerd. Ligt de ingangsdatum van zo'n wijziging ver in het verleden, dan is automatisch accepteren ongewenst: de wijziging raakt dan contractjaren die al zijn geprolongeerd. Daarom is er een controle bijgekomen. Ligt de mutatiedatum, de ingangsdatum van de nieuwe versie, vóór de voorlaatste hoofdvervaldatum, dan valt de wijziging uit met de melding “De mutatiedatum ligt vóór de voorlaatste hoofdvervaldatum.” De wijziging wordt niet automatisch geaccepteerd, maar aangeboden voor handmatige beoordeling.

Welke datum wordt vergeleken De voorlaatste hoofdvervaldatum wordt bepaald aan de hand van de meest recente prolongatie waarbij de hoofdvervaldatum daadwerkelijk opschoof, en de hoofdvervaldatum van de verzekeringversie zoals die vóór die prolongatie was. Is de hoofdvervaldatum bijvoorbeeld 01-08-2026, dan is de voorlaatste 01-08-2025; een wijziging met een ingangsdatum vóór 01-08-2025 valt uit. Een wijziging met een ingangsdatum precies óp de voorlaatste hoofdvervaldatum valt niet uit; de controle geldt alleen voor datums die daar strikt vóór liggen. Bij een verzekering die nog nooit is geprolongeerd, is er geen voorlaatste hoofdvervaldatum en treedt de controle niet in werking. De controle draait alleen in de acceptatiefase. Bij het berekenen van premies en bij tussentijdse herberekeningen verandert er niets. Impact voor jou Wijzigingen met een ingangsdatum die verder terug ligt dan het vorige contractjaar komen voortaan altijd bij de acceptant terecht. Je beoordeelt ze dan zelf in plaats van dat ze ongemerkt worden verwerkt. Voor wijzigingen binnen het lopende of het vorige contractjaar verandert er niets. Zie ook Bij royementen gelden daarnaast eigen vaste acceptatieregels, beschreven in Vaste acceptatieregels voor royementen (4.1.4.2). Dit onderwerp staat in de release notes van een eerdere versie. Je vindt het ook in het online handboek of via Quinn, de digitale assistent in DIAS Assurantie.

3.1.2.21. Omschrijving bij opvragen verdelingsversie (4.1.5.1) Met GET contract/api/v1/verdelingen/{id}/versies/{versienummer} vraag je de gegevens van een verdelingsversie op. Het antwoord bevatte tot nu toe alleen het verdelingsnummer, het versienummer en de ingangsdatum van die versie. Daar is de property Omschrijving aan toegevoegd. Dat is de herkenbare beschrijving die bij de verdeling zelf is vastgelegd, bijvoorbeeld de naam waaronder een poolverdeling bekendstaat. Impact voor jou Je kunt een verdeling nu bij naam tonen in plaats van alleen met een nummer, zonder daarvoor een tweede aanroep te doen. Bestaande aanroepen blijven werken; er is alleen een property bijgekomen.

3.1.2.22. Presentatiestatus en offertegeldigheid (4.1.5.1) Om te bepalen in welke fase een scenario zich bevindt, moest je tot nu toe zelf een aantal velden combineren: de status van het scenario, of er een offertedocument is, hoe de offerte is aangeboden en wat de klant heeft geantwoord. Elke afnemer bouwde die logica apart, en moest hem apart bijhouden.

Het scenario levert die uitkomst nu zelf, in twee nieuwe velden: PresentatieStatusId en OfferteGeldigheidId. Beide komen als tekst terug, net als bijvoorbeeld StatusAanbodId. De velden zitten in het antwoord van deze ingangen:

GET contract/api/v1/scenarios GET contract/api/v1/scenarios/{id} PUT contract/api/v1/scenarios/starten PUT contract/api/v1/scenarios/starten/preview

Presentatiestatus PresentatieStatusId geeft de fase van het scenario in gebruikerstermen. De mogelijke waarden zijn:

Waarde

Omschrijving

InOntwikkeling

In ontwikkeling

Offerte

Offerte

OffertedocumentGegenereerd

Offertedocument gegenereerd

AangebodenHandmatig

Aangeboden handmatig

AangebodenDigitaal

Aangeboden digitaal

GeaccepteerdDoorKlantHandmatig

Geaccepteerd door klant

GeaccepteerdDoorKlantDigitaal

Geaccepteerd door klant

AfgekeurdDoorKlantHandmatig

Afgekeurd door klant

AfgekeurdDoorKlantDigitaal

Afgekeurd door klant

Geaccepteerd

Geaccepteerd

Afgewezen

Afgewezen

Beoordelen

(Her)beoordelen

Controleren

Controleren

Twee paren waarden hebben dezelfde omschrijving: bij Geaccepteerd door klant en Afgekeurd door klant zie je aan de waarde of de offerte handmatig of digitaal is aangeboden, en aan de omschrijving niet. Gebruik dus de waarde en niet de omschrijving als je dat onderscheid nodig hebt. Staat een scenario in een fase waarvoor geen presentatiestatus is bepaald, bijvoorbeeld Doorgevoerd, dan krijg je NotSet terug. Offertegeldigheid OfferteGeldigheidId geeft aan hoever een offerte is in haar geldigheidstermijn:

Waarde

Omschrijving

Geldig

Geldig

BijnaVerlopen

Bijna verlopen

Verlopen

Verlopen

DefinitiefVerlopen

Definitief verlopen

De grenzen tussen deze waarden volgen uit de termijnen die je inricht bij Digitaal offreren: de geldigheidstermijn van de offerte, de intrekkingstermijn en het aantal overgebleven dagen waarbij een offerte als bijna verlopen geldt. Heeft een scenario geen offertedatum, dan is OfferteGeldigheidId leeg. Omschrijvingen opvragen De omschrijvingen staan in de tabel hierboven, maar je kunt ze ook ophalen. Daarvoor zijn vier ingangen toegevoegd:

GET codering/api/v1/aanduidingen/presentatiestatussen GET codering/api/v1/aanduidingen/presentatiestatussen/{id} GET codering/api/v1/aanduidingen/offertegeldigheden GET codering/api/v1/aanduidingen/offertegeldigheden/{id}

De lijstvariant levert per waarde een Id en een Omschrijving, de detailvariant levert die van één waarde. Een onbekend id geeft een Not Found. Impact voor jou Je kunt de fase van een scenario nu rechtstreeks uit het antwoord halen, zonder zelf statusvelden te combineren. Bestaande velden zijn ongewijzigd, dus je hoeft niets aan te passen; de nieuwe velden komen er alleen bij.

3.2. DDO

3.2.1. Productkenmerk beschikbaar in DDO-designer (4.1.4.5)

Het veld Productkenmerk van een product is nu beschikbaar in de DDO-designer. Je kunt dat kenmerk gebruiken als label om documentsjablonen in te richten voor een groep producten in plaats van per product. Waarvoor je het gebruikt Geef je meerdere producten hetzelfde productkenmerk, dan kun je die producten in de DDOdesigner in één keer aanspreken. Dat werkt ook over verzekeraars heen. Zo geef je bijvoorbeeld alle vrachtwagenproducten binnen de branche motorrijtuig hetzelfde kenmerk, en richt je de bijbehorende rubrieken één keer in voor die hele groep.

Waar je het kenmerk vastlegt Het veld Productkenmerk staat op het tabblad Algemeen van een product, dat je inricht bij de verzekeraar. Het kenmerk ken je als bedrijf zelf toe; het staat los van de naam die de maatschappij of volmachtgever gebruikt.

Het productkenmerk verwijst naar een codering die je zelf inricht. De omschrijving daarvan is maximaal 30 tekens lang. Waar je het kenmerk terugvindt in de DDO-designer In de DDO-designer staat het kenmerk onder de node Verzekering, in de onderliggende node Product. Daar heet het Kenmerk en niet Productkenmerk. Het is geen los veld maar een node met twee onderliggende velden: CodeProductkenmerkId met de code, en Omschrijving met de omschrijving die je zelf hebt vastgelegd. <Verzekering> <Product> <Kenmerk> <CodeProductkenmerkId>12</CodeProductkenmerkId> <Omschrijving>Vrachtwagen</Omschrijving> </Kenmerk> ... </Product> ... </Verzekering>

Wil je het kenmerk in een document tonen, gebruik dan Omschrijving. Wil je erop selecteren of vergelijken, dan is CodeProductkenmerkId de stabiele waarde: die verandert niet als je de omschrijving later aanpast. Impact voor jou Je hoeft documentsjablonen niet meer per product in te richten wanneer een groep producten dezelfde behandeling nodig heeft. Producten zonder productkenmerk werken ongewijzigd.

3.3. Front-end

3.3.1. Scenario's en offreren

3.3.1.1. Blokkerende controle bij akkoord automatische incasso hersteld (4.1.4.4) Bij een handmatige offerte of directe aanvraag met automatische incasso, waarbij nog geen doorlopende machtiging aanwezig is op het opgegeven rekeningnummer, moet je het vinkveld Bent u akkoord met het automatisch incasseren van de verschuldigde bedragen van de aangegeven rekening aanvinken voordat je het scenario naar DIAS Assurantie kunt insturen. Door een latere aanpassing voor scenario's met alleen royementen werkte deze controle niet meer correct: het scenario kon ook worden ingestuurd zonder dat het vinkveld was aangevinkt. Oplossing De controle is hersteld. Zolang het vinkveld niet is aangevinkt, verschijnt bij het insturen een blokkerende foutmelding dat dit veld verplicht moet worden aangevinkt. Zie ook Directe aanvragen: automatische incasso en machtiging (4.1.3.4) Dit onderwerp staat in de release notes van een eerdere versie. Je vindt het ook in het online handboek of via Quinn, de digitale assistent in DIAS Assurantie.

3.3.1.2. Incassowijze bij terugbladeren in de flow hersteld (4.1.4.4) Als je in het portaal een nieuwe verzekering toevoegt aan een bestaand pakket, kom je in de flow op de pagina Administratieve gegevens. Daar staat de Incassowijze, bijvoorbeeld Nota of Elektronisch. Ging je vanuit een volgende stap met Vorige terug naar Administratieve gegevens, dan viel de incassowijze terug op Nota. Dit gebeurde zowel bij de incassowijze die het systeem zelf had gezet als bij een incassowijze die je zelf had gekozen. Verbetering De incassowijze blijft nu staan als je in de flow met Vorige en Volgende heen en weer bladert. Impact voor jou De incassowijze wordt niet meer overschreven terwijl je door de flow loopt. Daarmee is de kans kleiner dat een verzekering met een andere incassowijze wordt aangevraagd dan bedoeld. Zie ook (zie "Weergave datum bij slotvragen na heropenen scenario hersteld (4.1.4.4)" op pagina 56)

3.3.1.3. Machtigen-knop bij automatische incasso hersteld (4.1.4.4) Bij het toevoegen van een verzekering voor een relatie zonder rekeningnummer, of met een rekeningnummer zonder geldige doorlopende machtiging, verscheen in het slotscherm ten

onrechte een knop Machtigen zodra je koos voor Automatische incasso. Dit gebeurde ook bij Handmatige offerte (en bij het verwerken van de reactie) en bij Directe aanvraag. Na het klikken op deze knop verscheen een SEPA-formulier, bedoeld om digitaal te ondertekenen. Dat is bij een handmatige offerte of directe aanvraag niet mogelijk: de medewerker kan geen handtekening van de eindklant zetten. Voor deze offertetypen gebruik je hiervoor de optie Offerte uploaden om een ondertekend machtigingsformulier vast te leggen. Oplossing De knop Machtigen met bijbehorend SEPA-formulier verschijnt nu alleen nog bij een digitale offerte (landingspagina), waarbij de eindklant het formulier zelf digitaal invult en ondertekent. Bij een handmatige offerte of directe aanvraag verschijnt deze knop niet meer.

3.3.1.4. Weergave datum bij slotvragen na heropenen scenario hersteld (4.1.4.4) Bij een aantal slotvragen vul je in een subvraag een datum in. Antwoord je bijvoorbeeld bij de slotvraag Was u (of degene die tot uw huishouden behoren) eerder voor rechtsbijstand verzekerd? met Ja, dan vul je de subvragen Naam verzekeraar en Wat was de ingangsdatum van de eerdere verzekering? in. Zolang je binnen het scenario bleef werken en met Vorige en Volgende heen en weer ging, bleef de ingevulde datum correct staan. Verliet je het scenario en pakte je het op een later moment weer op met Wijzigen, dan stonden de cijfers van de datum in de verkeerde volgorde in het veld. Een datum die je als 01-04-2007 had ingevuld, werd bijvoorbeeld weergegeven als 20-07-0401. Verbetering De datum bij een slotvraag wordt nu ook na het opnieuw openen van het scenario weergegeven in de notatie dd-mm-jjjj, zoals je hem hebt ingevuld. Impact voor jou De datums die je bij slotvragen hebt ingevuld komen ongewijzigd terug als je een scenario later weer oppakt. Je hoeft ze niet meer te corrigeren of opnieuw in te voeren voordat je het scenario verder afhandelt. Zie ook (zie "Incassowijze bij terugbladeren in de flow hersteld (4.1.4.4)" op pagina 55) Verbeterpunten beantwoorden slotvragen (4.1.4.2) Dit laatste onderwerp staat in de release notes van een eerdere versie. Je vindt het ook in het online handboek of via Quinn, de digitale assistent in DIAS Assurantie.

3.3.1.5. Melding bij nieuwere versie van pakket of verzekering (4.1.4.5) Van pakketten en verzekeringen bestaan versies. Werk je in het portaal met een scenario waarin van een pakket of een verzekering inmiddels een nieuwere versie beschikbaar is, dan krijg je dat nu meteen te zien: in plaats van het scenario opent eerst het venster met de versieverschillen.

Wanneer je de melding krijgt De controle op een nieuwere versie gebeurt op drie momenten:

• Bij het openen van een scenario.
• Bij Aanpassen van een onderhanden of geparkeerd scenario, vanuit het dashboard bij

Onderhanden werk, bij de geparkeerde scenario's en vanuit het dashboard van een relatie.

• Bij het accepteren van een klantreactie op een verstuurde offerte.

Een verschil wordt gevonden op een losse verzekering, op een pakket en ook op een verzekering binnen een pakket. Staat een pakket zelf op de laatste versie, maar een verzekering in dat pakket niet, dan krijg je de melding dus ook. Staan alle onderdelen op de laatste versie, dan verschijnt het venster niet en opent het scenario direct zoals je gewend bent. Bij onderdelen van een nieuwe aanvraag, waarvoor nog geen eerdere versie bestaat, verschijnt het venster ook niet. Wat je kunt doen In het venster met de versieverschillen heb je twee keuzes:

• Annuleren: het scenario wordt niet geopend en er verandert niets.
• Aanpassen: er wordt een kopie van het scenario aangemaakt waarin de onderdelen op de nieuwste versies staan. Je herkent die kopie aan (kopie) achter de naam. Die kopie opent direct; het oorspronkelijke scenario blijft ongewijzigd bestaan. Open je de kopie later opnieuw, dan krijg je de melding niet meer.

Pas je een onderhanden of geparkeerd scenario aan, dan volgt na Aanpassen het scherm waarin je de reden van de aanpassing opgeeft. Kies je daar Annuleren, dan ga je terug naar het venster met de versieverschillen. Bij een afgekeurd scenario is de reden van afkeuring al ingevuld; je vult die aan en bevestigt, waarna de kopie wordt aangemaakt. Impact voor jou Je ziet nu direct dat een scenario onderdelen bevat waarvan een nieuwere versie bestaat, en je kunt in één stap doorgaan met een kopie op de nieuwste versies. Dat een nieuwere versie bestaat, verandert op zichzelf niets aan de vraag of je een pakket of verzekering mag muteren. Zie ook (zie "Scenario-ophalen uitgebreid met IsLaatsteVersie (4.1.4.4)" op pagina 41) Dit onderwerp staat in de release notes van een eerdere versie. Je vindt het ook in het online handboek of via Quinn, de digitale assistent in DIAS Assurantie.

3.3.1.6. Weergave berekende rubrieken bij wijzigen verzekering hersteld (4.1.4.5) Bij een nieuwe aanvraag staan de automatisch berekende rubrieken, zoals reken- en waardebepalingsrubrieken, meteen gevuld in het samenvattingsscherm. Opende je daarna diezelfde verzekering vanuit het scenario om die te wijzigen, dan werden die rubrieken in het

samenvattingsscherm niet direct getoond. Het leek daardoor alsof de waarden verdwenen waren. Oplossing De berekende rubrieken staan nu ook bij het wijzigen van een verzekering direct in het samenvattingsscherm. Impact voor jou Het ging om de weergave: de waarden waren wel aanwezig en zijn nooit verloren gegaan. Je ziet ze nu alleen ook meteen terug bij het wijzigen.

3.3.1.7. Status van pakket en verzekering in het scenario (4.1.5.1) In het venster Verzekeringsscenario staat bij elk pakket en elke verzekering een gekleurde aanduiding aan de linkerkant van de kaart. Daaraan zie je meteen wat er met dat onderdeel gebeurt ten opzichte van de bestaande situatie, zonder dat je het hoeft te openen. Bestaand betekent dat het pakket of de verzekering ongewijzigd blijft, Gewijzigd dat je het in dit scenario aanpast en Toegevoegd dat het er nieuw bij komt. Daarnaast zie je een oranje uitroepteken bij elk pakket en elke verzekering waarvan een versie bestaat die nog niet definitief is. Beweeg je de muis over dat teken, dan lees je dat het onderdeel een niet-definitieve versie heeft en daarom niet gewijzigd kan worden. Die aanduiding verschijnt nu telkens als dat aan de orde is, ook bij het pakket zelf.

Impact voor jou Bij een scenario met meerdere pakketten en losse producten zie je in één oogopslag welke onderdelen je aanpast en welke ongemoeid blijven. Dat scheelt zoeken bij het nalopen van

een scenario voordat je het aanvraagt. En loop je tegen een onderdeel aan dat je niet kunt wijzigen, dan zie je aan het uitroepteken meteen waarom.

3.3.2. Contractbeheer en relatiebeheer

3.3.2.1. Bijzonderheden bij verzekering alleen zichtbaar met permissie (4.1.4.5) Breaking change In het portaal zie je de gegevens van een verzekering op het tabblad Details. In het blok Administratief staat daar het veld Bijzonderheden, onder de drie verzendwijzevelden.

Dit veld bevat vaak interne informatie die niet voor iedereen bestemd is. Tot nu toe kon iedereen die de verzekering mocht inzien ook de bijzonderheden lezen. Vanaf deze versie geldt daarvoor de nieuwe permissie VerzekeringInzienBijzonderheden. Die staat standaard aan voor medewerkers en uit voor agenten. Zonder de permissie wordt er niets van de bijzonderheden getoond: ook het veld Bijzonderheden zelf verdwijnt uit het blok Administratief. Er blijft dus geen lege regel staan. Impact voor jou Voor medewerkers verandert er niets. Agenten en relaties zien het veld Bijzonderheden niet meer bij een verzekering. Moeten zij daar wel bij kunnen, zet de permissie VerzekeringInzienBijzonderheden dan open voor de betreffende rol. Zie ook (zie "Bijzonderheden bij verzekering afgeschermd met permissie (4.1.4.5)" op pagina 36) voor het opvragen van de bijzonderheden via de WebAPI.

3.3.2.2. Mutatieverzoek toegevoegd voor niet-muteerbare producten (4.1.4.3) Voor producten waarbij de productrechten zijn ingesteld op Niet (muteren niet toegestaan), is het nu mogelijk een mutatieverzoek in te dienen via het portaal. Hiermee vervalt de noodzaak om mutaties per e-mail aan te vragen bij de gevolmachtigde administratie. Mutatieverzoek indienen De productrechten bepalen of een verzekering muteerbaar is. Deze zijn zichtbaar in de productinrichting via het tabblad Overige van het product in DIAS:

In het scenariooverzicht verschijnt bij verzekeringen waarvoor de productrechten zijn ingesteld op Niet de optie Mutatieverzoek in plaats van Verzekering wijzigen. Voorheen verscheen bij dergelijke producten pas na het invoeren van wijzigingen de volgende blokkerende melding:

Klikken op Mutatieverzoek opent een nieuw scherm met de volgende onderdelen:

• Het veld Gewenste wijzigingen: een verplicht memo-veld waarin de gewenste mutatie wordt omschreven.

• Een optioneel veld voor het uploaden van één of meer bijlagen.
• De knoppen Annuleren en Indienen.

Automatische taakopvolging Na het indienen wordt automatisch een taak aangemaakt in DIAS op basis van het planningnummer dat is ingesteld in het venster Instellingen van het portaal. Welk planningnummer wordt gebruikt, is afhankelijk van het type verzekering (Particulier of Bedrijfsmatig), zoals ingesteld op het tabblad Overige van het product:

• Planningnummer voor taak bij muteren zakelijk
• Planningnummer voor taak bij muteren particulier

Je vindt deze instellingen in het portaal via het menu-pictogram in het dashboard, menuoptie Instellingen, onder de nieuwe categorie Contracten. Je moet daarvoor in DIAS Assurantie zijn aangemerkt als Beheerder in DPM, via Beheer > Medewerkers in het venster

Muteren medewerkers. Eventuele bijlagen worden als document gekoppeld aan de taak. De taak wordt ook gekoppeld aan het bijbehorende contract en opgenomen in het standaard contractdossier. Na het succesvol indienen ontvangt de adviseur een bevestigingsmelding. Inrichting vereist Vul het juiste planningnummer in het venster Instellingen in, onder Contracten. Als geen planningnummer is ingevuld, wordt de optie Mutatieverzoek niet getoond in het scenariooverzicht. Impact Mutatieverzoeken voor niet-muteerbare producten verlopen voortaan via het portaal in plaats van via e-mail. De taak komt direct gestructureerd binnen in DIAS, wat de verwerking door de gevolmachtigde administratie vereenvoudigt.

3.3.2.3. Adresopzoeking bij huisnummer 0 hersteld (4.1.4.4) Bij het invoeren van een postcode werd de adresopzoeking op basis van postcode en huisnummer ten onrechte ook uitgevoerd wanneer het huisnummer nog op 0 stond. Voorbeelden waar dit voorkwam

• Bij het invoeren van een nieuwe relatie (huisnummer staat standaard op 0)
• Bij het invoeren van een nieuwe relatie, nadat je het huisnummer eerst had gewijzigd en vervolgens weer op 0 had gezet
• Bij het invoeren van een nieuw postadres of bezoekadres met huisnummer 0
• Bij het wijzigen van een bestaand postadres of bezoekadres naar huisnummer 0

Oplossing De adresopzoeking wordt nu niet meer uitgevoerd zolang het huisnummer op 0 staat.

3.3.2.4. Duidelijkere melding bij muteren verzekering in niet-definitief pakket (4.1.4.4) Als je een verzekering wilt wijzigen die deel uitmaakt van een pakket waarvan de laatste pakketversie niet definitief is (bijvoorbeeld omdat een andere verzekering in hetzelfde pakket nog niet definitief is), kon je het wijzigingsformulier eerst gewoon openen en invullen. Pas helemaal aan het einde, bij het opslaan van de wijziging, verscheen een technische foutmelding dat niet de laatste pakketversie werd gebruikt. Verbetering Dit wordt nu al herkend op het moment dat je kiest om de verzekering te wijzigen. Je krijgt direct de volgende melding: "Verzekeringen in dit pakket kunnen momenteel niet worden gemuteerd, omdat de laatste versie van het pakket niet definitief is."

Impact voor jou Je hoeft het wijzigingsformulier niet meer volledig in te vullen om pas bij het opslaan te ontdekken dat de mutatie niet mogelijk is. Je ziet dit nu direct bij het kiezen van de wijzigactie.

3.3.2.5. Oprichtingsdatum bij wijzigen relatie niet langer verplicht (4.1.4.4) Bij het wijzigen van een zakelijke relatie vroeg het portaal ten onrechte om de oprichtingsdatum verplicht in te vullen. Bij het aanmelden van een relatie was dit veld al niet verplicht, en ook DCB vereist het niet bij wijzigen. Impact voor jou De oprichtingsdatum is bij het wijzigen van een relatie nu, net als bij het aanmelden, optioneel.

3.3.2.6. Verplichte velden bij wijzigen van een relatie (4.1.5.1) Bij het invoeren van een nieuwe relatie in het portaal zijn bepaalde velden verplicht. Bij het wijzigen van een bestaande relatie werden diezelfde velden niet altijd gecontroleerd, waardoor een relatie kon worden opgeslagen zonder dat die gevuld waren. In DIAS Assurantie zijn diezelfde velden wel verplicht, wat tot verschillen tussen het portaal en DIAS Assurantie leidde. Het portaal controleert nu bij het wijzigen van een relatie op dezelfde verplichte velden als bij het invoeren:

Soort relatie

Verplichte velden

Persoon Instantie

Voorletters, Achternaam, Geboortedatum en Geslacht Bedrijfsnaam 2e deel en KvK-nummer

Bij een instantie gaat het om het tweede deel van de bedrijfsnaam. Het eerste deel blijft optioneel en mag leeg blijven. Impact voor jou Ontbreekt bij het wijzigen van een relatie een van deze velden, dan vul je het eerst aan voordat je kunt opslaan. Dat kan ook gebeuren bij relaties die al langer bestaan en waarin een veld nooit is ingevuld: je merkt het op het moment dat je zo'n relatie wijzigt. De gegevens in het portaal en in DIAS Assurantie blijven daarmee gelijk.

3.3.3. Documenten en weergave

3.3.3.1. Dubbele scrollbar in offerteformulier hersteld (4.1.4.4) Bij het genereren of bekijken van een offerte via een scenario dat nog niet aan de klant is aangeboden, toonde het formulier twee verticale scrollbars: één voor de offerte zelf, en één voor het formulier eromheen. Door de scrollbar van het formulier te gebruiken, scrolden de knoppen mee buiten beeld en was slechts een deel van de offerte zichtbaar, waardoor het leek alsof de offerte niet compleet was.

Oplossing Het formulier toont nu nog maar één verticale scrollbar, waarmee je door de offerte kunt scrollen om deze te bekijken.

3.3.4. Gebruikerservaring en interface

3.3.4.1. Dynamiekregels per object hersteld bij herhalende objecten (4.1.4.3) Bij producten met herhalende objecten (bijvoorbeeld meerdere voertuigen binnen één verzekering) werkten dynamiekregels niet correct per object afzonderlijk. Een keuze in het ene object beïnvloedde de veldweergave in een ander object, waardoor velden ten onrechte wel of niet zichtbaar waren. Dynamiekregels worden nu per object onafhankelijk toegepast. Elke keuze in een object heeft alleen effect op de velden van dat specifieke object. Impact Bij het invoeren van gegevens voor producten met herhalende objecten worden velden per object correct getoond of verborgen op basis van de ingevulde waarden in dat object.

3.3.4.2. Kolomuitlijning in contractenoverzicht hersteld (4.1.4.3) Bij het weergeven van geneste gegevens in een lijstoverzicht liepen de kolommen buiten het scherm, waardoor de knop Meer opties (de drie puntjes rechts in de rij) over de inhoud van aangrenzende kolommen heen viel. Dit probleem deed zich voor bij scrollen door rijen met ingesprongen subregels. De kolomuitlijning is gecorrigeerd zodat alle kolommen correct binnen het schermkader blijven en de knop Meer opties altijd zichtbaar en klikbaar is, ook bij geneste rijen. Impact In lijstoverzichten met geneste rijen worden de kolommen correct uitgelijnd weergegeven. De knop Meer opties overlapt niet langer met kolominhoud.

3.3.4.3. Tabbladtekst actieve tab hersteld bij toelichting en pakketkeuze (4.1.4.3) Bij het invullen van een toelichting op een scenario (tabbladen Consument en Volmacht) en bij het slepen van een verzekering naar een pakket (tabbladen Nieuw pakket en Bestaand pakket) was de tekst van het actieve tabblad niet zichtbaar. Dit werd veroorzaakt door een kleurconflict: zowel de tekstkleur als de achtergrondkleur van het actieve tabblad waren wit. De tekstkleur van het actieve tabblad is gecorrigeerd zodat de geselecteerde keuze altijd leesbaar is. Impact Bij het opgeven van een toelichting en bij pakketkeuzes is het actieve tabblad nu altijd zichtbaar en leesbaar.

3.3.4.4. Sorteren op relatie in Onderhanden werk uitgeschakeld (4.1.4.5) Op het tabblad Onderhanden werk van het dashboard in het Adviseursportaal staan je lopende scenario's, activiteiten en notities bij elkaar. De relatienamen in dit overzicht worden opgehaald voor de regels die op dat moment in beeld staan. Zodra je verder bladert, worden de namen bij de volgende regels opgehaald. Tot nu toe kon je het overzicht ook sorteren op de kolom Relatie. Bij een groot aantal regels onderhanden werk kon het verversen van het scherm daardoor lang duren. Sorteren op de kolom Relatie is daarom niet meer mogelijk. Sorteren op de overige kolommen werkt ongewijzigd. Impact voor jou Het tabblad Onderhanden werk blijft ook bij veel regels snel reageren. Je kunt het overzicht niet meer op relatienaam sorteren. Bladeren, filteren met de knop Filter en sorteren op de overige kolommen blijven gewoon beschikbaar.

3.3.4.5. Logo Ominimo toegevoegd (4.1.5.1) Het logo van verzekeraar Ominimo is opgenomen in het portaal. Je ziet het op de plaatsen waar ook de logo's van de andere verzekeraars worden getoond. Zie ook Voor het importeren van productdefinities van Ominimo is een aparte licentie nodig (zie "Nieuwe licentie voor Productservice Ominimo (4.1.5.1)" op pagina 31).

3.4. Prolongatie

3.4.1. Prolongatie in het portaal beschikbaar (4.1.4.5)

Je kunt de volmachtprolongatie nu uitvoeren vanuit het portaal. Dat geldt zowel voor de prolongatie op hoofdvervaldatum als voor termijnprolongaties. De verwerking draait op de achtergrond in DIAS Cloud Backend, waardoor je tijdens een prolongatie gewoon kunt doorwerken. Je doorloopt drie stappen: de prolongatie doorrekenen en het resultaat beoordelen, daarna de nieuwe verzekeringversies en boekingen aanmaken, en tot slot de prolongatie afsluiten en de financiële administratie bijwerken. Tot je de prolongatie definitief maakt, verandert er niets aan de verzekeringen zelf, dus je collega’s kunnen ondertussen gewoon doorwerken. Gaat er één verzekering mis, dan lopen de andere door en los je alleen die ene op.

Licentie en beschikbaarheid Voor deze functie heb je de nieuwe licentie Cloud prolongatie nodig. De prolongatie in het portaal is bovendien nog niet voor alle kantoren beschikbaar. Heb je hier belangstelling voor, neem dan contact op met je accountmanager. Impact voor jou Werk je nog niet met de prolongatie in het portaal, dan verandert er niets: de prolongatie in DIAS Assurantie blijft gewoon werken. Dit topic is een aankondiging, geen werkinstructie. De volledige beschrijving van de prolongatie, voorbereiding, uitvoering, licentie en permissies, staat in de aparte handleiding Prolongatie in het portaal. Die is op aanvraag beschikbaar bij DIAS Software.

Growth Builders.