Pagina-vergelijking

STAN-1037

XSDValidation

Aanpassen XSDValidation (VX) ten behoeve van het toevoegen van brondata statusmeldingen

STAN-408

Generiek

Ketenafspraak over requestVersion via platform afdwingen

STAN-23

Generiek

Verwijderen XML-Header

STAN-63

Generiek

Aanscherping patroon Email

STAN-1101

Generiek

Wijziging omschrijving van veldnaam LeningLopendJN

STAN-2230

Generiek

LandType updaten

STAN-293

Generiek

Naamsverbetering nieuwbouw

STAN-2068

Minder verplichte velden voor OfferteBericht Verzekeren

STAN-958

Opschonen niet gebruikte velden OfferteBericht

STAN-88

Waarden toevoegen DocSoortTypeKlantbeeld en dubbele woonlastenformulier ondersteunen in Offerte en Documentberichten

STAN-1308

Uitbreiding Documenten “Verklaring van gemoedsbezwaren”

STAN-923

Verwijderen Document Soort ‘024 Kopie identiteitsbewijs’

STAN-1036

Herinrichting DocumentBericht t.b.v. meegeven brondatasleutel

STAN-162

Herinrichten entiteit Object

STAN-647

ArrangementNr vervangen voor Arrangement

STAN-510

Verwijderen niet gebruikte velden OfferteAanvraag HDN25

STAN-93

Verwijderen AanvullendeVerzendwijze

STAN-94

Klantbeeld mee kunnen geven in OfferteAanvraag

STAN-2058

NHG termen kortingsconstructie en kortingsdeel wijzigen naar koperssteun en ondersteuningsdeel

STAN-1035

Herinrichting meegeven sleutel bronbericht dataleverancier in OfferteAanvraag

STAN-1060

Verbeteren ketenafspraken leningdelen en/of schema

STAN-59

Ondersteuning digitale ondertekening

STAN-2361

Legitimatiegeslacht LegitimatieGeslacht X generieke ondersteuning in OfferteAanvraag

STAN-2360

Ondersteunen BAG-ID

STAN-716

Uitbreiding financieringsopzet

STAN-791

Beschrijven attributen "Verplicht maken toestaan" Binnen PartijNAWData

STAN-1402

Serviceprovider toevoegen aan generiek schema

STAN-915

Structuurwijziging LevenAanvraag IdentificatieVerificatieJN

STAN-920

DoelVerzekering generiek verplicht maken

STAN-1604

Verwijderen niet gebruikte velden LevenAanvraag HDN25

STAN-719

GeweigerdRedenOmschr en UitsluitingRedenOmschr in LevenAanvraag organisatiespecifiek maken

STAN-2095

Nieuwe verplichte velden in LevenAanvraag

STAN-2094

Optimalisatie van velden in de LevenAanvraag

STAN-57

Beëindigingsbrief bij afwijzing meesturen via StatusMelding

STAN-1216

Kenmerk verplichten bij statusmelding Polis Verzonden

STAN-567

Geslacht LegitimatieGeslacht 'X' Waarborgbericht toevoegen

STAN-1025

Bedrijfsnaam verplichten bij rechtspersonen

STAN-293988

Dataminimalisatie InformatieAanvraag- en Informatie bericht plus optimaliseren bericht- Versie HDN25

STAN-9882045

STAN-

Optionele of verwijderen klantdata in het Informatiebericht

STAN-2045

Informatiebericht uitbreiden met beheersignaal

Informatiebericht uitbreiden met beheersignaal

STAN-1160

Tariefklasse verplicht veld geven

STAN-1179

Uitbreiding t.b.v. Bouwdepot Declaraties

STAN-1346

BrondataBerichten

Dataminimalisatie doormiddel van beperking op entiteiten Hypotheekgever & PartijNAWData

STAN-1040

Brondataberichten

DocSoort en SoortDocument scheiden

STAN-2320

Herinrichten schema VoorafIngevuldeAangiftebericht (VIA)

STAN-1349

Uitbreiden met ontbrekende velden

STAN-408

Generiek

Ketenafspraak over requestVersion via platform afdwingen

Wijziging:

De validatie van de requestVersion vindt plaats op het platform. Op het moment dat de meegegeven requestVersion meegegeven wordt, leeg of 0 is, wordt er geen record gemaakt in het dossier en wordt deze beantwoordt met, HTTP foutcode ‘400’, met de foutmelding ‘Invalid request body.header.requestVersion does not match allowed format of 1 to 3 digits and must be greater than 0”’

Samenvatting:

Door het afdwingen van ketenafspraken op het platform, kunnen wij een hogere kwaliteit van het berichtenverkeer garanderen. Het afdwingen van een gedeelte van de ketenafspraak over requestVersion geeft eenieder de mogelijkheid om te wennen aan deze manier van valideren.

STAN-23

Generiek

Verwijderen XML-Header

Wijziging:

De //Header met onderliggende velden wordt verwijderd uit alle berichtschema’s waarin deze nog is opgenomen.

Samenvatting:

In 2023 is de APIv2 versie neergezet waarin de Header in de XML, die stuurinformatie bevat, overbodig is geworden. Stuurinformatie is sindsdien onderdeel van de JSON en daarom niet meer nodig in de XML berichtenstructuur.

Na uitvraag bij onze leden en gebruikers, over het gebruik van de Header op XML niveau, konden we concluderen dat niemand de Header nog nodig heeft met de HDN25 versie. Daarom wordt de Header dan ook verwijderd uit alle berichtschema’s waar deze nog onderdeel van uitmaakt.

STAN-63

Generiek

Aanscherping patroon Email

Wijziging:

Het patroon voor het datatype EmailType wordt gewijzigd naar: [a-zA-Z0-9._%+-]{1,64}@[A-Za-z0-9.-]{0,255}[A-Za-z0-9]{1}\.[A-Za-z]{1,63}

Samenvatting:

Door het patroon aan te passen, wordt het emailadres wat verzonden wordt via de XML berichten betrouwbaarder.

STAN-1101

Generiek

Wijziging omschrijving veldnaam LeningLopendJN

Wijziging:

De omschrijving van het veld LeninglopendJN wordt gewijzigd naar: ‘Betreft het een lening waar een actieve of toekomstige betaalverplichting voor geldt?’

Samenvatting:

Er wordt een wijziging in de omschrijving doorgevoerd zodat het duidelijker is waarvoor dit veld dient.

STAN-2230

Generiek

LandType updaten

Wijziging:

Aan de waardelijst LandType wordt de waarde XK Kosovo toegevoegd.

Samenvatting:

Met HDN24 is de waardelijst aangepast aan de ISO landenlijst, daarbij was Kosovo verwijderd omdat deze niet op de ISO landenlijst voorkomt als geaccepteerd land. Nederland heeft Kosovo echter wel geaccepteerd.

Bij de jaarlijkse analyse zal voortaan naast de ISO landenlijst ook gekeken worden naar de door Nederland geaccepteerde landen.

STAN-

293

Generiek

Naamsverbetering nieuwbouw

Minder verplichte velden voor OfferteBericht Verzekeren

Wijziging:

Het veld BouwPlanNr wordt vervangen voor Bouwplan

Het veld SituatieNr wordt vervangen door Bouwnummer

Samenvatting:

Het was onduidelijkheid hoe en welke velden gevuld moeten worden in het geval van nieuwbouw. Om deze reden vervangen we een aantal velden. Hiermee zou het doel van deze velden duidelijker moeten zijn. Deze velden zijn tevens in lijn met de inrichting van het OfferteAanvraag bericht.

STAN-2068

Minder verplichte velden voor OfferteBericht Verzekeren

Wijziging:

//OfferteData/VerleningingMogelijkJNis verplicht als //OfferteData/ResponsOpBerichtSoort heeft waarde (AX OfferteAanvraag, MX BeheerVerzoek of WX WaarborgBericht heeft. Dit veld was nu altijd verplicht.

/OfferteData/FinancieleDekking/Fiscaal​Geruisloze​Voortzetting​J​N wordt optioneel.

Samenvatting:

De werkgroep verzekeren heeft aangegeven dat bij het versturen van de Offerte teveel verplichte velden moesten worden gevuld terwijl de informatie niet altijd beschikbaar is. Daarom is gekeken welke velden optioneel gemaakt kunnen worden in geval van een LevenAanvraag.

STAN-958

Opschonen niet gebruikte velden OfferteBericht

Wijziging:

De entiteit Hypotheekgever wordt verwijderd, inclusief alle onderliggende velden en entiteiten. Dit betreft het veld Hypotheekgever/RefPartijNAWData en de sub entiteiten Verplichtingen, GeregistreerdeLening, OverigeLening en alle velden in deze entiteiten.

Samenvatting:

Jaarlijks wordt gekeken naar velden die niet gebruikt worden. De te verwijderen entiteiten en onderliggende velden werden niet gebruikt. In samenspraak met de werkgroep is besloten deze te verwijderen.

STAN-88

Waarden toevoegen DocSoortType

Wijziging:

• Uitbreiding waardelijst, binnen documentberichten, SoortDocumentType met de waarde ‘(code) Klantbeeldformulier’ en ‘(code) Dubbele woonlastenformulier’. Ook wordt de entiteit Hypotheekgever verplicht wanneer SoortDocument heeft de waarde ‘(code) Klantbeeldformulier’

• Uitbreiding waardelijst, binnen Offerte, DocSoortType met de waarde ‘(code) Klantbeeldformulier ’ en ‘(code) Dubbele woonlastenformulier’.

Samenvatting:

Gebruikers hebben aangegeven bij de Offerte ook een klantbeeldformulier en/of dubbele woonlastenformulier mee te sturen. Er is gevraagd om de waardelijst DocSoortType uit te breiden zodat deze documenten gestandaardiseerd meegestuurd kunnen worden. Ook is het nodig om deze documenten ingevuld en/of ondertekend te retourneren. Daarom worden ook de documentberichten uitgebreid met deze waarde.

STAN-1308

Uitbreiding Documenten “Verklaring van gemoedsbezwaren”

Wijziging:

Uitbreiding waardelijst SoortDocumentType met de waarde ‘(code) Verklaring van gemoedsbezwaren’. De uitbreiding geldt voor het DocumentBericht en het DocumentAanvraagBericht.

Samenvatting:

Met een ‘Verklaring van gemoedsbezwaar’, van het SVB, heeft een consument de mogelijkheid om aantoonbaar te maken dat deze zich vanuit levensovertuiging niet hoeft te verzekeren. Meer informatie hierover is te vinden op:

• https://wetten.overheid.nl/BWBR0019150/2024-01-01/#Hoofdstuk4

• https://www.rijksoverheid.nl/wetten-en-regelingen/productbeschrijvingen/ontheffing-verzekeringsplicht-sociale-verzekeringen-bij-gemoedsbezwaren

STAN-923

Verwijderen Document Soort ‘024 Kopie identiteitsbewijs’

Wijziging:

Waarde ‘024 Kopie identiteitsbewijs’ wordt verwijderd uit de waardelijst SoortDocument.

Samenvatting:

Met de HDN23 zijn er twee documenten geïntroduceerd ‘267 Kopie identiteitsbewijs zonder BSN’ en 268 Kopie identiteitsbewijs met BSN'. Het doel hiervan is om duidelijker onderscheid te kunnen maken in het aan te leveren document. Na een overgangsperiode van twee jaar wordt het oude document verwijderd.

STAN-162

Herinrichten entiteit Object

Wijziging:

De entiteit //Objectwordt heringericht. Een deel van de bestaande velden zijn in nieuwe subentiteiten geplaatst: BestaandeBouw, Nieuwbouw, Adres, Verbouwing, Meerwerk en Erfpacht.

Zie Overzicht nieuwe Object-entiteit m.i.v. HDN25 voor alle wijzigingen. Er is ook een Mappingtabel Object wijzigingen gemaakt.

Samenvatting:

De entiteit //Object bestaat uit veel velden. Dit zorgt ervoor dat, de entiteit onoverzichtelijk is, er fouten ontstaan in het verplichten van velden, stellen van regels en het doorgeven/mappen van de data. Ook ontvangen aanbieders niet altijd alle informatie die benodigd is en/of foutieve informatie. Met de vernieuwde inrichting is de entiteit veel overzichtelijker en duidelijker wat er ingevuld moet worden in specifieke situaties.

Met deze change zijn adviespakketten veel beter in staat gestructureerde data te versturen en ontvangen aanbieders betrouwbaardere data.

STAN-647

ArrangementNr vervangen voor Arrangement

Wijziging:

Binnen de entiteit Lening wordt het veld ArrangementNr vervangen door Arrangement

Samenvatting:

Het veld ArrangementNr en Arrangement werden met hetzelfde doel gebruikt. In het kader van eenduidigheid is besloten het veld Arrangement te behouden.

STAN-510

Verwijderen niet gebruikte velden OfferteAanvraag HDN25

Wijziging:

De volgende velden worden verwijderd uit het de entiteit //Leningdeel : KortingsBedrag, ComplexProductJN, RefDebiteurNAWData. Ook wordt verwijderd uit de entiteit //object: EnergieEfficientiewaardeBerekenMethode, EnergieEfficientieWaarde en EnergieEfficientieWaardeEindDt.

Samenvatting:

Jaarlijks wordt gekeken naar velden die niet gebruikt worden. De te verwijderen velden werden niet gebruikt. In samenspraak met de werkgroep is besloten deze velden te verwijderen.

STAN-93

Verwijderen AanvullendeVerzendwijze

Wijziging:

Het veld AanvullendeVerzendwijze wordt verwijderd uit de OfferteAanvraag.

Samenvatting:

Het veld AanvullendeVerzendwijze is niet meer benodigd en wordt daarom verwijderd.

STAN-94

Klantbeeld mee kunnen geven in OfferteAanvraag

Wijziging:

De volgende velden worden organisatiespeficiek toegevoegd binnen de entiteit //Hypotheekgever, KVKinschrijvingJN, AantalOnroerendGoedObjectenBox3, Woonsituatie en TijdelijkeHuurwoningJN.

De waardelijst WoonsituatieType wordt toegevoegd en bevat de volgende waardes: 01 Inwonend, 02 Huurwoning en 03 Koopwoning.

Het veld EindDt binnen de entiteit //Hypotheekgever/Verplichtingen wordt conditioneel verplicht indien //Hypotheekgever/Verplichtingen/Verplichting heeft waarde 11 Bruto huurlasten en //Hypotheekgever/TijdelijkeHuurwoningJN heeft waarde Ja.

Samenvatting:

Er bovenstaande velden worden toegevoegd om het hypotheek aanvraagproces verder te optimaliseren. Aanbieders kunnen hiermee in een vroegtijdig stadium bepalen of de aanvrager aan de voorwaarden voldoet en de juiste documenten opvragen.

STAN-791

Beschrijven attributen "Verplicht maken toestaan" Binnen PartijNAWData

Wijziging:

Verplicht maken toestaan wordt voor de volgende velden in de entiteit PartijNAWData in het schema uitgezet: VoorNamen, GeboorteAchternaam, GeboorteTussenvoegsels, CorrespondentieVoornaam , CorrespondentieNaam, CorrespondentieTussenvoegsels, Nationaliteit, GeboortePlaats, GeboorteLand, VoorLetters, GeboorteDt, HuisNrToevoeging, VoorTitel en RekeningNr.

Dit betekend dat het alleen mogelijk is om het veld Land te verplichten.

Samenvatting:

Het kunnen leggen van de restrictie op het schema vanuit een basisschema heeft als doel dat de kwaliteit van de berichtschema’s omhoog gaat. Afgelopen jaren hebben wij meermaals incidenten gehad waarbij invalide schema’s ontstonden door het verplichten van velden binnen de entiteit PartijNAWData. Daarom is nu kritisch gekeken welke velden binnen deze entiteit nooit verplicht kunnen zijn. Daarvoor wordt nu de restrictie ‘Verplicht maken toestaan’ uitgezet.

STAN-2058

NHG termen kortingsconstructie en kortingsdeel wijzigen naar koperssteun en ondersteuningsdeel

Wijziging:

Verwijderde velden worden vervangen door:

• ErfpachtofKortingsConstructieAnders → ErfpachtconstructieOfKoperssteunAnders

• BedragKortingsdeel → BedragOndersteuningsdeel

• VolledigeAfbetalingKoringsdeel → VolledigeAfbetalingOndersteuningsdeel

Verwijderde waardelijst wordt vervangen door:

• ErfpachtOfKortingsConstructieAndersType → ErfpachtconstructieOfKoperssteunAndersType

Verwijderde enum’s worden vervangen door:

• 01 Kortingsconstructie met vermogensrisico → 01 Koperssteun met vermogensrisico

• 02 Erfpachtconstructie met vermogensrisico → 02 Erfpachtconstructie met vermogensrisico

• 03 Kortingsconstructie zonder vermogensrisico → 03 Koperssteun zonder vermogensrisico

• 04 Erfpachtconstructie zonder vermogensrisico → 04 Erfpachtconstructie zonder vermogensrisico

Verwijderde enum in de waardelijst MutatieType:

• 36 Volledige afbetaling van het kortingsdeel → 37 Volledige afbetaling van het ondersteuningsdeel

Samenvatting:

NHG heeft de termen Kortingsconstructie en Kortingsdeel gewijzigd naar Koperssteun en Ondersteuningsdeel. Om aansluiting te houden bij de NHG terminologie, hebben wij op verzoek van de leden ook de termen aangepast.

STAN-1035

Herinrichting meegeven sleutel bronbericht dataleverancier in OfferteAanvraag

Wijziging:

Verwijderd wordt de entiteit //ExterneIdentificatie met de daaronder liggende velden RefDataleveranciers en PersoonsID

De entiteit //Dataleverancier wordt uitgebreid met de velden: RefPartijNAWData, RefHuidigObject, RefObject en DataleverancierSleutel.

De entiteit krijgt de volgende structuur:

//Dataleverancier → voorkomens 0-99

/RefPartijNAWData → Optioneel

/RefHuidigObject –> Optioneel

/RefObject → Optioneel

/DataleverancierNaam → Verplicht

/DataleverancierID → Optioneel

/DataleverancierSleutel → Verplicht

Samenvatting:

Ter ondersteuning van de uitbreiding van brondata wordt de benodigde informatie gecentraliseerd in het berichtschema opgenomen. De wijziging maakt het mogelijk om niet alleen voor de aanvrager maar ook voor het object brondata aan te leveren. Hiermee kan bijvoorbeeld het taxatierapport in een vroegtijdig stadium worden aangeleverd waarmee verwezen wordt naar het object en/of de koopovereenkomst. Op termijn kan met een relatief kleine aanpassing ‘het product’ worden toegevoegd waarmee gerichter brondata kan worden meegegeven.

STAN-57

Beëindigingsbrief bij afwijzing meesturen via StatusMelding

Wijziging:

De entiteit //Printdoc met daarin de velden: DocSoort, BestandType, Encoding en EncodedData wordt toegevoegd aan het schema. Op de entiteit //Printdoc wordt een regel geplaatst dat deze alleen mag wordt gevuld als de statusmelding 11 Offerteaanvraag afgewezen wordt verstuurd als reactie op de OfferteAanvraag.

Daarnaast wordt de waardelijst DocSoortType uitgebreid met de waarde ‘(code) Afwijsbrief’. De uitbreiding geldt voor de Statusmelding en is de enige waarde die in de Statusmelding wordt aangeboden.

Samenvatting:

Een afwijsbrief van een hypotheekaanvraag wordt op dit moment door veel aanbieders per mail verstuurd. Om te zorgen dat deze brief veilig verstuurd kan worden is in overleg met de werkgroep hypotheken besloten om om de afwijsbrief als bijlage bij de bijbehorende StatusMelding via HDN te versturen. Er is een overgangsperiode tot HDN26 besproken om dit te ondersteunen. Afgesproken is dat partijen de periode tussen HDN25 en HDN26 dit kunnen inregelen. Dit betekend dat er gedurende deze periode twee processen actief zijn.

STAN-2361

Legitimatiegeslacht X generieke ondersteuning in OfferteAanvraag

Wijziging:

Het is niet meer toegestaan om regels te leggen op het veld Legitimatiegeslacht.

Samenvatting:

De werkgroep hypotheken is voor het generiek ontvangen van alle mogelijke waarden die aanwezig kunnen zijn bij het geslacht op het identiteitsbewijs. Het voorkomt dat een financieel adviseur voor een moeilijke keuze komt te staan wanneer een LegitimatieGeslacht ‘X’ niet kan worden meegegeven. Bovendien zijn, zodra de systemen de waarde 'X' voor LegitimatieGeslacht wel ondersteunen, dan al bekend welke consumenten dit betreft. Het volledig ondersteunen van alle waarden van Geslacht op het legimatiebewijs maakt geen onderdeel uit van deze wijziging, maar het kunnen ontvangen van deze informatie wel.

STAN-2360

Ondersteunen BAG-ID

Wijziging:

Er wordt een nieuw veld BagID* toegevoegd aan het schema onder Object.

Samenvatting:

Met het Bag-ID kan verschillende brondata worden geraadpleegd zoals, EP-online, KadastraleKaart, WOZ-waardeloket. Dit biedt aanbieders de mogelijkheid om versneld brondataprocessen te doorlopen en onderpanddata te verifiëren.

STAN-1402

Serviceprovider toevoegen aan generiek schema

Wijziging:

De entiteit //Tussenpersoon/Serviceprovider/, met de daarin behorende velden Ref​Contact​Persoon​Data, ServiceproviderNaamen Service​Provider​A​F​M​Registratie​Nr, wordt toegevoegd aan het generieke berichtschema.

Samenvatting:

De entiteit Serviceprovider binnen Tussenpersoon was organisatiespeficiek en niet in lijn met de ketenafspraak: KET-001: Het doorgeven van intermediair en serviceprovider informatie en wijzigingen door tussenstations. Ook liep hier een serviceprovider tegenaan dat zij aanvragen niet volgens deze ketenafspraak konden doorsturen. Met deze wijziging wordt de inconsistentie gecorrigeerd.

STAN-915

Structuurwijziging LevenAanvraag IdentificatieVerificatieJN

Wijziging:

Het veld IdentificatieVerificatieJN wordt verplaatst naar //PartijNAWData/Identificatie.

Samenvatting:

Het veld IdentificatieVerificatieJN was initieel geplaatst in de entiteit Tussenpersoon, echter kon de tussenpersoon hiermee niet aangeven voor elke aanvrager of de Identificatie is uitgevoerd. Door het veld te verplaatsen naar //PartijNAWData/Identificatie, kan per aanvrager aangegeven worden of de identificatie is uitgevoerd.

STAN-920

DoelVerzekering generiek verplicht maken

Wijziging:

Het veld DoelVerzekering wordt generiek verplicht gemaakt binnen //FinancieleDekking/ProductCategorie/Overlijdensrisicoverzekering

Samenvatting:

Het veld DoelVerzekering is voor elke organisatie verplicht wanneer er sprake is van een overlijdensrisicoverzekering, daarom wordt deze nu in het basis berichtschema verplicht gemaakt.

STAN-1604

Verwijderen niet gebruikte velden LevenAanvraag HDN25

Wijziging:

Verwijdering van niet gebruikte entiteiten en velden:

• //TekstRegels/ (gehele entiteit met onderliggende velden)

• HandenArbeidOmschr binnen //FinancieleDekking/ProductCategorie/Overlijdensverzekering/Verzekerde/

• OpleidingsNiveau binnen //FinancieleDekking/ProductCategorie/Overlijdensverzekering/Verzekerde/

• PctVerzekerdeDekking binnen //FinancieleDekking/ProductCategorie/Lastenverzekering/Verzekerde/VerzekerdeBedragen/

• RekenRentePct binnen //FinancieleDekking/ProductCategorie/Overlijdensrisicoverzekering/Verzekerde/VerzekerdeBedragen/

• VerplichtingInMnd binnen //FinancieleDekking/ProductCategorie/Kredietbeschermer/Verzekerde/VerzekerdeBedragen/

• EindDt binnen //FinancieleDekking/ProductCategorie/Kredietbeschermer/Verzekerde/VerzekerdeBedragen/

• Verzekerde binnen //FinancieleDekking/

• WWDekkingJN binnen //FinancieleDekking/Verzekerde/

• VerzekerdeBedragen binnen //FinancieleDekking/Verzekerde/

• SoortVerzekerdKap binnen //FinancieleDekking/Verzekerde/VerzekerdeBedragen/

• CodeUitkering binnen //FinancieleDekking/Verzekerde/VerzekerdeBedragen/

Samenvatting:

In het kader van dataminimalisatie wordt jaarlijks gekeken welke velden binnen berichtschema’s niet gebruikt worden.

STAN-719

GeweigerdRedenOmschr en UitsluitingRedenOmschr in LevenAanvraag organisatiespecifiek maken

Wijziging:

De velden GeweigerdRedenOmschr en UitsluitingRedenOmschr worden organisatiespecifiek gemaakt.

Samenvatting:

Deze velden worden door veel partijen niet gebruikt. Daarnaast zijn dit vrije tekst velden die gevoelige data kunnen bevatten. Door de velden organisatiespecifiek te maken kan de aanbieder kiezen of hij deze velden wil ontvangen.

STAN-791

Beschrijven attributen "Verplicht maken toestaan" Binnen PartijNAWData

Wijziging:

Verplicht maken toestaan wordt voor de volgende velden in de entiteit PartijNAWData in het schema uitgezet: VoorNamen, GeboorteAchternaam, GeboorteTussenvoegsels, CorrespondentieVoornaam , CorrespondentieNaam, CorrespondentieTussenvoegsels, Nationaliteit, GeboortePlaats, GeboorteLand, VoorLetters, GeboorteDt, HuisNrToevoeging, VoorTitel, RekeningNr, BedrijfsNaam en BurgerlijkeStaat.

Dit betekend dat het alleen mogelijk is om de volgende velden in de entiteit PartijNAWData te verplichten: Land, TelefoonNr en E-mailadres.

Samenvatting:

Het kunnen leggen van de restrictie op het schema vanuit een basisschema heeft als doel dat de kwaliteit van de berichtschema’s omhoog gaat. Afgelopen jaren hebben wij meermaals incidenten gehad waarbij invalide schema’s ontstonden door het verplichten van velden binnen de entiteit PartijNAWData. Daarom is nu kritisch gekeken welke velden binnen deze entiteit nooit verplicht kunnen zijn. Daarvoor wordt nu de restrictie ‘Verplicht maken toestaan’ uitgezet.

STAN-2094 *

Optimalisatie van velden in de LevenAanvraag

Optimalisatie van velden in de LevenAanvraag

Wijziging:

Het schema van de LevenAanvraag optimaliseren door de velden:

• DigitaleCommunicatieKlantJN en PremieDepotJN organisatiespecifiek te maken.

• PremieBetalingAan en PremieBetaalWijze te verwijderen.

• PremieBetaalWijze te vervangen door BetaalWijze. Deze wordt organisatiespecifiek en bevat de waardelijst BetaalWijzeType. Deze bevat de volgende waardes: 01 Incasso, 02 Overschrijven, 03 Acceptgiro, 04 Ideal.

Samenvatting:

In het kader van dataminimalisatie heeft de werkgroep Verzekeren gekeken welke velden niet (voor alle aanbieders) noodzakelijk zijn. Op basis daarvan worden enkele velden verwijderd of organisatiespecifiek gemaakt zodat de aanbieder zelf kan bepalen of deze het veld wil ontvangen.

STAN-2095

Nieuwe verplichte velden in LevenAanvraag

Wijziging:

De volgende velden worden verplicht:

• StrafrechterlijkVerledenJN in //FinancieleDekking/ProductCategorie/Overlijdensrisicoverzekering/Verzekerde/Acceptatie/

• CodeWelkeVerzekeraar in //FinancieleDekking/ProductCategorie/Overlijdensrisicoverzekering/VerzekeringNemer/Geweigerd/

• MaatschappijPolisLopend en PolisNr in //FinancieleDekking/PolisLopend/

• HypotheekBedrag en PasseerDt in //Lening/

• DuurInMnd , LeningDeelBedrag, RentePct en AflossingsVorm in //Lening/Leningdeel

• LegitimatieSoort, LegitimatieGeslacht in //PartijNAWData/Identificatie

• ServiceProviderNr in //TussenPersoon/ServiceProvider

Samenvatting:

Er wordt regelmatig een LevenAanvraag verstuurd met lege entiteiten. Dit kan tot onverwachte fouten en onduidelijkheid leiden. Daarom wordt in de entiteiten minimaal 1 veld verplicht in niet verplichte entiteiten. Dit betekend dat wanneer de entiteit wordt opgenomen er een veld gevuld moet zijn.

STAN-1216

Kenmerk verplichten bij statusmelding Polis Verzonden

Wijziging:

De entiteit //Status/Kenmerk wordt verplicht als //Status/LXBerichtStatusSpecificatie/StatusLXBericht heeft waarde (10 Levenaanvraag in behandeling genomen, of 08 Polis verzonden).

Deze afspraak wordt ook toegevoegd aan de ketenafspraak: /wiki/spaces/HW/pages/2558034003

Samenvatting:

Het is gewenst om altijd een kenmerk te ontvangen wanneer er een polis wordt verzonden. Daarom wordt het veld bij deze status verplicht gesteld.

STAN-567*

Geslacht LegitimatieGeslacht 'X' Waarborgbericht toevoegen

Wijziging:

Waarde 'X' in LegitimatieGeslacht wordt toegevoegd aan het berichtschema.

Samenvatting:

Met de HDN24 release wordt LegitimatieGeslacht ‘X' ondersteund binnen verschillende domeinen. Binnen het bankgarantie domein is deze wijziging nog niet doorgevoerd. Hiermee wordt LegitimatieGeslacht 'X’ ook ondersteund binnen het bankgarantie domein.

STAN-1025

Bedrijfsnaam verplichten bij rechtspersonen

Wijziging:

BedrijfsNaam wordt toegevoegd aan de entiteit //PartijNAWData en deze wordt conditioneel verplicht als //PartijNAWData/SoortPartij heeft waarde (02 Rechtspersoon).

Samenvatting:

De BedrijfsNaam werd wanneer er sprake was van een rechtspersoon niet in alle gevallen meegegeven. Door BedrijfsNaam te verplaatsen en een regel te leggen, wordt dit opgelost.

STAN-293

Naam verbetering nieuwbouw

Wijziging:

Het veld BouwPlanNr wordt vervangen voor Bouwplan

Het veld SituatieNr wordt vervangen door Bouwnummer

Samenvatting:

Het was onduidelijkheid hoe en welke velden gevuld moeten worden in het geval van nieuwbouw. Om deze reden vervangen we een aantal velden. Hiermee zou het doel van deze velden duidelijker moeten zijn. Deze velden zijn tevens in lijn met de inrichting van het OfferteAanvraag bericht.