DIAS Assurantie / DIAS Cloud – versie 4.1.3.5

1. Release 4.1.3.5 – Voorbereiding

De onderwerpen in dit hoofdstuk zijn relevant voor iedereen die verantwoordelijk is voor het beheer en de technische werking van DCB- en EDO-omgevingen. Voor versie 4.1.3.5 wijzigen meerdere minimale systeemeisen voor DIAS Cloud Backend (DCB) en voor de EDO-componenten. Je moet deze systeemeisen vóór installatie van de update controleren en toepassen. Als de vereiste software-onderdelen ontbreken, kunnen DCB-processen of EDO-functionaliteit tijdelijk stoppen met werken totdat de juiste versies zijn geïnstalleerd.

1.1. Scenario Enterprise naar .NET 8 (ASP.NET Core) (4.1.3.5)

Breaking change Consequenties wanneer je deze systeemeisen niet vooraf installeert Als de vereiste .NET 8 Runtime én ASP.NET Core Runtime 8.0.22 of hoger (binnen de 8.0.xreeks) of de juiste Service Fabric-versie niet aanwezig zijn op het cluster, stoppen Enterpriseprocessen direct met werken zodra je de update naar versie 4.1.3.5 installeert. Dit kan leiden tot:

• het stilvallen van achtergrondprocessen zoals batchverwerking, documentgeneratie en prolongatie
• foutmeldingen bij scenario’s en productinrichting
• tijdelijk niet-beschikbare Enterprise-endpoints
• verstoringen in geautomatiseerde taken die pas herstellen nadat de juiste systeemeisen alsnog zijn geïnstalleerd

Deze gevolgen treden onmiddellijk op na installatie van de update. Daarom moet je vóór de update controleren of alle vereiste onderdelen aanwezig zijn. Wat is Enterprise? Enterprise is de backend-omgeving binnen DIAS Cloud Backend (DCB) die achtergrondprocessen uitvoert, zoals batchverwerking, documentgeneratie, prolongatie en andere geautomatiseerde taken. Deze omgeving draait naast WebAPI en vormt een vast onderdeel van de DCB-architectuur. Deze wijziging heeft betrekking op DCB en niet op DIAS Assurantie. Wijziging De Enterprise-services zijn gemigreerd naar .NET Core 8. Hierdoor verandert de technische basis waarop deze achtergrondprocessen draaien. De functionaliteit van de Enterpriseendpoints blijft gelijk, maar de runtimevereisten wijzigen. Nieuwe minimale systeemeisen

• .NET 8 Runtime
• .ASP.NET Core Runtime 8.0.22 of hoger (binnen de 8.0.x-reeks)

Beide runtimes zijn vereist voor het correct functioneren van de Enterprise-services.

Deze onderdelen moeten naast de bestaande .NET Framework 4.7.2-installatie worden geplaatst. Het vervangt de huidige .NET Framework-versie niet.

• Microsoft Azure Service Fabric 11.3.365.1 of hoger

Deze versie vervangt de oudere Service Fabric-versie die nu wordt gebruikt. Gedrag na de wijziging Na installatie van de nieuwe systeemeisen blijven alle Enterprise-endpoints werken zoals voorheen. De migratie verandert geen functionele logica, maar zorgt ervoor dat de Enterpriseprocessen op een moderne en ondersteunde runtime draaien. Impact Je moet voorafgaand aan release 4.1.3.5 controleren of:

de juiste .NET 8 Runtime en ASP.NET Core Runtime beschikbaar zijn op het cluster de Service Fabric-versie is bijgewerkt naar minimaal 11.3.365.1 alle Enterprise-endpoints na de update blijven functioneren zoals voorheen het wijzigen van productinrichting in DIAS Assurantie correct blijft werken

Deze voorbereidingen zijn noodzakelijk om verstoringen tijdens of na de update te voorkomen.

1.2. Scenario EDO-componenten naar .NET Framework 4.8

(4.1.3.5)

Breaking change De minimale systeemeisen voor de EDO-componenten wijzigen. EDO-Design, EDO-DocGen en EDO-DocMon hebben vanaf versie 4.1.3.5 .NET Framework 4.8 nodig in plaats van .NET Framework 4.5.2. Als deze versie niet is geïnstalleerd op de documentserver waarop de EDO-software draait, kunnen EDO-processen tijdelijk stoppen met werken totdat de juiste versie is geïnstalleerd. Wat zijn de EDO-componenten? EDO-Design, EDO-DocGen en EDO-DocMon worden gebruikt voor documentgeneratie en documentmonitoring. Deze software draait op een eigen documentserver en maakt geen onderdeel uit van de DCB-clusterservers. Wijziging De EDO-componenten zijn bijgewerkt naar .NET Framework 4.8. Hierdoor verandert de minimale runtimevereiste op de documentserver. De functionaliteit van de EDO-software blijft gelijk, maar de onderliggende .NET-versie moet worden bijgewerkt. Impact wanneer .NET Framework 4.8 ontbreekt Als .NET Framework 4.8 niet aanwezig is op de documentserver, werkt het volgende niet:

• documentgeneratie via Externe Documentopmaak (EDO)
• het genereren van offertedocumenten vanuit scenario’s

Zodra de juiste versie is geïnstalleerd, worden deze processen hervat.

Nieuwe minimale systeemeisen

• .NET Framework 4.8

Deze versie vervangt de eerdere vereiste .NET Framework 4.5.2-installatie. Gedrag na de wijziging Na installatie van .NET Framework 4.8 blijven de EDO-componenten functioneren zoals voorheen. De wijziging heeft geen invloed op de documentlogica, maar alleen op de technische basis waarop de software draait. Impact Je moet voorafgaand aan release 4.1.3.5 controleren of:

• .NET Framework 4.8 is geïnstalleerd op de documentserver waarop EDO-Design,

EDO-DocGen en EDO-DocMon draaien Deze voorbereiding is noodzakelijk om verstoringen tijdens of na de update te voorkomen.

2. Provinciaal en volmacht

2.1. Relatiebeheer

2.1.1. SEPA BIC-lijst uitgebreid met nieuwe BIC-registraties (4.1.3.5)

De SEPA BIC-lijst is uitgebreid met nieuwe registraties voor meerdere betaaldienstverleners. Hierdoor wordt de juiste BIC automatisch ingevuld wanneer je een rekeningnummer toevoegt van een van deze partijen. Toegevoegde BIC-registraties

• Qonto
• Goldman Sachs Bank Europe SE, Amsterdam Branch
• Pay.nl

Impact voor jou Je hoeft de BIC niet meer handmatig op te zoeken of in te voeren bij rekeningnummers van deze betaaldienstverleners. Dit verkleint de kans op fouten en versnelt het toevoegen van nieuwe rekeningnummers.

3. Volmacht

3.1. SUIV

3.1.1. Nieuwe licentie voor Productservice Chubb (4.1.3.5)

Er is een nieuwe licentie beschikbaar voor de productservice van Chubb. Hiermee kun je SUIVproductdefinities van Chubb importeren binnen DIAS Assurantie. De POR-code voor Chubb is C505.

Deze licentie is niet standaard inbegrepen. Je kunt de productservice pas gebruiken nadat je de licentie hebt aangeschaft en geactiveerd. 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 Chubb 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.

3.2. Aplaza

3.2.1. Aplaza-gebruikersnaam niet uniek genoeg (4.1.3.5)

Door een aanscherping van het beveiligingsbeleid bij Aplaza is het noodzakelijk geworden dat een Aplaza-gebruikersnaam binnen de volledige DIAS-omgeving uniek is. Eerder kon dezelfde gebruikersnaam bij meerdere bedrijven worden geregistreerd, waardoor berichten die voor het ene bedrijf bedoeld waren, per ongeluk bij een ander bedrijf konden binnenkomen. Verbetering DIAS controleert nu of een Aplaza-gebruikersnaam al bij een ander bedrijf voorkomt. Een gebruikersnaam kan alleen nog worden aangemaakt wanneer deze uniek is binnen de hele omgeving. Hiermee sluit DIAS aan op het aangescherpte beveiligingsbeleid van Aplaza.

Impact voor jou Het risico dat berichten van Aplaza bij het verkeerde bedrijf terechtkomen is hiermee uitgesloten. Je voldoet automatisch aan de nieuwe beveiligingseisen en voorkomt dat berichten onbedoeld door een ander bedrijf worden opgehaald.

3.2.2. Geen diensten beschikbaar bij Toegang Aplaza (4.1.3.5)

In het venster Toegang Aplaza werden geen diensten meer getoond wanneer je een transactie startte vanuit DIAS Assurantie. Dit werd veroorzaakt door een wijziging in het Aplaza-register, waardoor DIAS de beschikbare diensten niet meer correct kon inlezen. Herstel Bij het starten van DIAS Assurantie wordt nu eenmalig een herstelprogramma uitgevoerd dat het Aplaza-register opnieuw inleest. Hierdoor worden de beschikbare diensten weer correct geladen en weergegeven. Impact voor jou Je kunt de Aplaza-diensten weer gebruiken zoals je gewend bent. De diensten worden opnieuw correct geladen bij het openen van Toegang Aplaza.

4. DIAS Cloud

4.1. Front-end

4.1.1. Aanpassingen - kort

Scenario’s en relatiebeheer

• Direct scenario openen vanuit ander pakket o Je kunt nu vanuit een ander pakket, zoals Elements, direct het scenariovenster openen voor een relatie. Er wordt automatisch een voorlopig scenario gestart, zodat je niet eerst handmatig een scenario hoeft aan te maken. Dit voorlopige scenario wordt nog niet opgeslagen in de database.

• Verbeteringen in kolom Personenauto

In de kolom Personenauto zijn twee weergaveproblemen opgelost:

o In het veld Meldcode werd eerder een reeks x-tekens getoond wanneer er nog geen waarde was ingevuld. Dit is vervangen door de tekst Vul meldcode in. o In het veld Kenteken werden niet alle streepjes van het kenteken weergegeven. Dit wordt nu correct getoond.

4.2. DCB

4.2.1. Functionele en technische verbeteringen

4.2.1.1. Handmatige beperkingen bij aanvragen en wijzigen (4.1.3.5) Bij het aanvragen en wijzigen van een verzekering (los of onder een pakket) kun je nu handmatige beperkingen beheren. Het gaat hierbij om clausules, clausulebladen en voorwaarden die je handmatig kunt toevoegen of verwijderen. Verbetering

• Je kunt handmatige beperkingen toevoegen bij het aanvragen van een verzekering.
• Je kunt handmatige beperkingen toevoegen én verwijderen bij het wijzigen van een verzekering.

• Beperkingen kunnen worden toegevoegd op verzekeringsniveau of dekkingsniveau, maar niet op beide niveaus tegelijk.

• Een beperking mag niet meerdere keren op hetzelfde niveau worden toegevoegd.
• Dezelfde beperking mag wel op verschillende dekkingen binnen dezelfde verzekering

voorkomen. De beperking moet onderdeel zijn van de productdefinitie en geldig zijn op de ingangsdatum van de aanvraag of wijziging. Alleen niet-aanpasbare beperkingen mogen worden toegevoegd of verwijderd. Je kunt in één wijziging niet dezelfde beperking verwijderen op het ene niveau en toevoegen op het andere niveau. Alleen medewerkers met de permissie VerzekeringToevoegenHandmatigeBeperking mogen handmatige beperkingen beheren. Handmatige beperkingen kunnen niet worden gewijzigd; alleen toegevoegd of verwijderd.

API-aanpassingen De ondersteuning voor handmatige beperkingen is toegevoegd aan alle API-aanroepen voor aanvragen, wijzigen, previews en premieberekeningen van verzekeringen en pakketten. Impact voor jou Je kunt nu volledig handmatig beperkingen beheren bij het aanvragen en wijzigen van verzekeringen. Dit maakt het mogelijk om clausules, clausulebladen en voorwaarden flexibel toe te voegen of te verwijderen, binnen de grenzen van de productdefinitie en met de juiste permissies.

4.2.1.2. Fraudechecks voor relaties, instanties en schades (4.1.3.5) De fraudecheck-functionaliteit voor relaties, instanties en schades is technisch bijgewerkt. De ingangen werken nu op een uniforme manier en het formulier is opgesplitst in aparte formulieren per ingang, zodat elke ingang een eigen request body heeft. Verbetering Alle fraudecheck-ingangen gebruiken dezelfde queryparameters:

• Bedrijf (verplicht)

• Medewerker (verplicht)
• Kantoor (optioneel)

Ondersteunde ingangen Relaties

PUT /api/v1/relaties/personen/aanmelden/fraudechecks PUT /api/v1/relaties/personen/wijzigen/fraudechecks PUT /api/v1/relaties/instanties/aanmelden/fraudechecks PUT /api/v1/relaties/instanties/wijzigen/fraudechecks Schade

• PUT /api/v1/schades/melden/fraudechecks

Boeking schade

• PUT /api/v1/boekingen/schadeboeken/fraudechecks

Verplichte rubrieken

• RelatieId (DIAS-relatie)
• SchadeId (bij schade- en boeking-ingangen)
• Minimaal één persoon of instantie
• ResourceId

Hoe meer gegevens je meegeeft bij personen of instanties, hoe groter de kans op een volledig resultaat. Resultaat (output) { "Id": "", "Indicatie": "NotSet", "Melding": "string" }

Toelichting

• Id: kan later gebruikt worden om detailinformatie op te vragen (nog niet beschikbaar).
• Indicatie kan de volgende waarden hebben: o Geaccepteerd o Bevindingen (er zijn bevindingen op minimaal één fraudecheck) o NietUitgevoerdOfMislukt (minimaal één fraudecheck is niet uitgevoerd of mislukt)
• Melding: omschrijving van de indicatie of reden waarom de fraudecheck niet is uitgevoerd.

Impact voor jou

De fraudecheck-ingangen werken nu op een uniforme manier en hebben duidelijke validatieregels. Je kunt fraudechecks uitvoeren voor personen, instanties, schades en schadeboekingen met een consistente structuur en voorspelbare resultaten.

4.2.1.3. Leeftijdsbepaling voertuigen in acceptatieregels gecorrigeerd (4.1.3.5) Acceptatieregels voor motorvoertuigverzekeringen maken gebruik van de leeftijd van het voertuig. Die leeftijd werd niet altijd correct berekend. Hoewel eerder al is aangepast dat de ingangsdatum van de verzekeringsversie gebruikt moet worden, bleek de leeftijdsbepaling zelf nog steeds onjuist te werken. Verbetering De leeftijd van het voertuig wordt nu correct bepaald. De berekening gebruikt de ingangsdatum van de verzekeringsversie en vergelijkt deze met de bouwdatum van het voertuig. Daarbij wordt de bouwdatum als volgt vastgesteld:

• Als een bouwdatum aanwezig is, wordt die gebruikt.
• Als alleen bouwmaand en bouwjaar aanwezig zijn, wordt de leeftijd bepaald op basis van bouwmaand en bouwjaar.
• Als alleen bouwjaar aanwezig is, wordt de leeftijd bepaald op basis van het bouwjaar.

De leeftijdsfunctie gebruikt nu een correcte datumvergelijking. De eerdere methode, waarbij de datum werd omgerekend naar een getal, veroorzaakte afrondingsfouten waardoor voertuigen ouder leken dan ze waren. Impact voor jou Acceptatieregels die afhankelijk zijn van de leeftijd van het voertuig werken nu correct. Een aanvraag wordt alleen geblokkeerd wanneer de berekende leeftijd daadwerkelijk voldoet aan de ingestelde grenswaarden.

4.2.1.4. Premieberekening negeert lock op verzekering bij scenario’s (4.1.3.5) Bij het kopiëren van een scenario kon een foutmelding ontstaan tijdens de premieberekening wanneer een verzekering in het scenario op dat moment openstond. De kopie werd wel gemaakt, maar de premieberekening retourneerde een fout. Ook wanneer in DIAS Assurantie een verzekering werd gemuteerd terwijl DCB tegelijkertijd een premieberekening uitvoerde, werd ten onrechte een lock-melding getoond. Een lock hoort alleen relevant te zijn voor mutaties, niet voor het berekenen van premie. Verbetering Premieberekeningen en previews houden voortaan geen rekening meer met een lock op een verzekering of pakket. Hierdoor worden onnodige lock-meldingen voorkomen en kan een scenario zonder foutmelding worden gekopieerd, ook wanneer een verzekering elders tijdelijk openstaat. Impact voor jou Je kunt scenario’s kopiëren en premies berekenen zonder dat een lock op een verzekering dit proces onderbreekt. Premieberekeningen verlopen hierdoor stabieler en voorspelbaarder.

4.2.1.5. Machtigen beschikbaar in adviesfase van scenario’s (4.1.3.5) Verbetering Het invoeren van een machtiging via een scenario is nu ook mogelijk wanneer het scenario nog de status Advies heeft. Voorheen kon dit alleen in latere fasen. Door deze uitbreiding kun je machtigingen eerder in het proces vastleggen en controleren. Gedrag De machtigingsfunctionaliteit werkt in de adviesfase op dezelfde manier als in de overige fasen. Tijdens de testfase wordt gecontroleerd of deze uitbreiding geen ongewenste effecten heeft op bestaande scenario’s of machtigingsstromen. Impact voor jou Je kunt machtigingen nu al tijdens de adviesfase toevoegen of wijzigen. Dit maakt het mogelijk om eerder in het proces een volledig en correct scenario op te bouwen.

4.2.1.6. Aangepaste werking permissie SEPA-machtiging in scenario’s (4.1.3.5) Verbetering Wanneer de permissie ScenarioMachtigingSepaformulierOptioneel is ingeschakeld, kun je een machtiging via een scenario nu ook indienen zonder SEPA-formulier. In dat geval zijn de velden Plaats ondertekening en Datum ondertekening eveneens optioneel. Deze gegevens zijn alleen verplicht wanneer een SEPA-formulier wordt gebruikt. Gedrag Zonder SEPA-formulier zijn plaats en datum ondertekening optioneel. Wanneer wél een SEPA-formulier wordt toegevoegd, blijven beide velden verplicht. Impact voor jou Je kunt een machtiging nu flexibeler indienen tijdens het scenario, ook wanneer er geen SEPA-formulier wordt gebruikt. Dit voorkomt onnodige blokkades en sluit beter aan op situaties waarin een SEPA-formulier niet nodig is.

4.2.1.7. Controles muteren dekkingen met gekoppeld object verbeterd (4.1.3.5) Bij het toevoegen en wijzigen van een dekking worden verschillende controles uitgevoerd, waaronder controles die bepalen of je het verzekerde bedrag op dekkingsniveau mag wijzigen. Dit bedrag kan direct via de dekking worden aangepast of via een dekkingsrubriek die aan het verzekerde bedrag is gekoppeld. Verbetering Wanneer een dekking gekoppeld is aan een verzekeringsobject van dezelfde verzekering, werd een wijziging van het verzekerde bedrag altijd afgekeurd. Dit was niet terecht. De wijziging mag namelijk worden uitgevoerd zolang het verzekerde bedrag in het gekoppelde object niet gevuld is (0). De controle is daarom aangepast:

De wijziging wordt alleen afgekeurd wanneer de rubriek Hoort bij gevuld is en het verzekerde bedrag in het gekoppelde object ongelijk 0 is.

• In alle andere gevallen mag je het verzekerde bedrag op de dekking wijzigen.

Impact voor jou Je kunt nu het verzekerde bedrag van een dekking wijzigen wanneer het gekoppelde object geen eigen verzekerde som heeft. De wijziging wordt correct verwerkt en leidt niet langer onterecht tot een foutmelding.

4.2.1.8. Indexeren van deelobjecten verbeterd (4.1.3.5) Wanneer je een object met deelobjecten indexeerde, werd eerder een NotImplementedException gegeven. De indexering van deelobjecten was nog niet volledig geïmplementeerd. Dit is nu opgelost. Verbetering De verzekerde som van een deelobject wordt nu correct geïndexeerd. Daarbij wordt de gewijzigde verzekerde som automatisch naar boven doorgegeven: alle bovenliggende objecten, inclusief het hoofdobject, worden bijgewerkt. Het bestaande indexeringsmechanisme blijft daarbij leidend; er vindt geen aparte indexatie op het hoofdobject plaats. Impact voor jou Je kunt nu zonder foutmeldingen deelobjecten indexeren. De verzekerde som wordt consistent doorgezet naar bovenliggende objecten, waardoor de waardeketen van objecten volledig en correct wordt bijgewerkt.

4.2.1.9. RelatieInstantieSbi toegevoegd aan EDMX (4.1.3.5) De tabel RelatieInstantieSbi (RINST) bestond al in de database, maar was nog niet opgenomen in het EDMX-model. Het EDMX-model is de technische beschrijving van alle database-entiteiten die door de DIAS Cloud Backend worden gebruikt. Dit model bepaalt welke tabellen en velden beschikbaar zijn voor de datalaag van DCB. Verbetering Het EDMX-model bevat nu ook de entiteit RelatieInstantieSbi. Hierdoor sluit het datamodel weer volledig aan op de bestaande database en zijn de gegevens uit deze tabel beschikbaar voor interne processen die gebruikmaken van het EDMX-model. Impact voor jou Je merkt geen functionele wijzigingen. De datalaag is technisch bijgewerkt zodat deze overeenkomt met de database en volledig aansluit op de beschikbare gegevens.

4.2.1.10. Royeren in combinatie met overvoeren via de WebAPI (4.1.3.5) Bij het royeren van een verzekering kon je eerder niet aangeven dat het royement onderdeel was van een overvoer. Hierdoor werden de acceptatieregels voor royementen altijd toegepast, waardoor royementen bij overvoer onterecht konden uitvallen.

Verbetering De API-aanroep voor het royeren van verzekeringen is uitgebreid met de property IsOvervoeren. Je kunt nu aangeven dat het royement onderdeel is van een overvoer. Als IsOvervoeren is ingesteld op true, dan worden de acceptatieregels voor royementen genegeerd door de acceptatie-engine. Voorbeeld van de API-aanroep PUT /api/v1/contracten/verzekeringen/royeren { "VerzekeringId": 0, "VerzekeringVersie": 0, "DatumIngangVersie": "string", "Reden": "string", "IsOvervoeren": true, "ResourceId": "00000000-0000-0000-0000-000000000000" }

Impact voor jou Je kunt nu royementen die onderdeel zijn van een overvoer automatisch laten verwerken zonder dat deze uitvallen op acceptatieregels. Dit voorkomt handmatige controles en versnelt het overvoerproces.

4.3. EDO-software

4.3.1. Minimale systeemeisen voor EDODesign (4.1.3.5)

Breaking change De minimale systeemeisen voor EDODesign, EDODocGen en EDODocMon zijn gewijzigd. De volledige beschrijving van deze wijziging staat in hoofdstuk 1.2 (zie "Scenario

EDO-componenten naar .NET Framework 4.8 (4.1.3.5)" op pagina 6). In dat hoofdstuk lees je welke .NET-versie je moet installeren en wat de impact is wanneer .NET Framework 4.8 ontbreekt op de documentserver. Deze paragraaf bevestigt dat deze systeemeis onderdeel is van de EDO-software in release

4.1.3.5. 17

Growth Builders.