Pagina-eigenschappen

id

Samenvatting Geïntroduceerd in HDN-versie Geldig vanaf datum Impact op / // / / / / / / / / / / /// / / / / / / / / / Relevant voor rollen Rol 1: Softwarepaketten (voorkant) Rol 2: Tussenstations zonder aanpassingen Rol 3: Tussenstations met aanpassingen Rol 4: Aanbieder: Hypotheken Rol 4: Aanbieder: Verzekeren Rol 4: Aanbieder: Kredieten Rol 4: Aanbieder: Externe bron Rol 5: Intermediar Type ketenafspraak Inrichting schema’s Vulling berichten Procesafspraak Verduidelijking omgaan met vulling van velden Gerelateerde velden Veldnaam Gerelateerde entiteiten Entiteitnaam

Samenvatting

Deze ketenafspraak regelt hoe het veld requestVersion in de HDN-API moet worden gevuld bij het plaatsen van HDN-berichten op het platform. De requestVersion wordt gebruikt om een gewijzigde aanvraag door te geven. Ook wordt er per rol ingegaan op wat er moet gebeuren indien een nieuwe requestVersion wordt geïntroduceerd en wat er moet gebeuren als deze binnen komt.

Geïntroduceerd in HDN-versie

Status

colour	Green
title	HDN-XX24

Geldig vanaf datum

25 mei 2024

Impact op

Status

colour	Blue
title	OfferTeaanvraag (AX)

/

Status

colour	Blue
title	Beheerverzoek KredietAanvraag (MXKX)

/

Status

colour	Blue
title	BRONAAnvraagLevenaanvraag (lx)

/

Status

colour	Blue
title	BRON BRP

/

	WaarborgBERICHT (wx)

Relevant voor rollen

Rol 1: Softwarepakketten (voorkant)
Rol 2: Tussenstations zonder aanpassingen
Rol 3: Tussenstations met aanpassingen
Rol 4a: Aanbieder: Hypotheken
Rol 4b: Aanbieder: Verzekeren
Rol 4c: Aanbieder: Kredieten
Rol 4e: Aanbieder: Waarborgen

Type ketenafspraak

Procesafspraak

Van toepassing op de velden

API:

AanvraagVersie/ requestVersion (JSON veld)

Van toepassing op de entiteiten

-

🤝 Ketenafspraak

Vereisten voor rol 1 Softwarepakketten (voorkant)

Een requestVersion gaat over de versie van de gehele aanvraag in een dossier op het platform. Het groepeert daarbij meerdere typen berichten.
Dit betekent dat bij bijvoorbeeld het opnieuw opsturen van een document via een
Status
colour Blue
title Document (DX)
er geen nieuwe requestVersion wordt geïntroduceerd.
Het is niet toegestaan binnen een dossier twee maal een HDN-bericht van hetzelfde messageType, receiver, sender enrequestVersion op het platform te plaatsen.
1. Dit geldt alleen voor de volgende messageType
  Status
  colour Blue
  title

...

1. OfferTeaanvraag (AX)
  /
  Status
  colour Blue
  title KredietAanvraag (KX)
  Status
  colour Blue
  title

...

1. Levenaanvraag (lx)
  /
  Status
  colour Blue
  title WaarborgBERICHT (wx)
Het is verplicht in het eerste bericht in een dossier het veld requestVersion in de JSON met 1 te vullen
Het is alleen toegestaan een nieuwe requestVersion te introduceren bij het plaatsen van een bericht met één van de volgende messageType
Status
colour Blue
title

...

OfferTeaanvraag (AX)
/
Status
colour Blue
title

...

KredietAanvraag (KX)
/
Status
colour Blue
title

...

Levenaanvraag (lx)
/
Status
colour Blue
title

...

WaarborgBERICHT (wx)
Wanneer er wordt gekozen om requestVersion te wijzigen moet de nieuwe waarde bepaald worden door het laatste bericht in het dossier te pakken en de requestVersion van dat bericht te verhogen met 1.
Ter verduidelijking: dit kan een bericht zijn van elk messageType, dus ook
Status
colour Blue
title

...

Documentaanvraag (DA)
,
Status
colour Blue
title

...

Offerte (OX)
en
Status
colour Blue
title

...

StatusMelding (SX)
. Zodoende kan de situatie worden ondersteund dat een HDN-bericht verderop in de keten wordt verhoogd en er daardoor meerdere keren dezelfde requestVersion wordt gemaakt.
Voorbeeld: Een adviespakket (rol 1) stuurt requestVersion=1 naar een serviceprovider (rol 3). Deze maakt een wijziging en introduceert requestVersion=2. De aanbieder stuurt daarop een
Status
colour Blue
title

...

StatusMelding (SX)
met requestVersion=2terug. De serviceprovider stuurt deze weer terug naar het adviespakket. Wanneer je in het adviespakket een nieuwe requestVersion wilt introduceren moet dit de waarde 3 hebben. Deze moet gebaseerd zijn het op het laatste bericht dat het adviespakket heeft ontvangen, de
Status
colour Blue
title StatusMelding (SX)

...

(

...

2) + 1=3
Wanneer een nieuwe requestVersion bekend is bij de partij mag er niet meer gereageerd worden op berichten van de oude requestVersion.
Ter verduidelijking: Het is niet toegestaan nog een
Status
colour Blue
title

...

Document (

...

DX)

...

te versturen op een
Status
colour Blue
title

...

Documentaanvraag (

...

DA)

...

met een verouderde requestVersion. Om documenten te versturen moet gewacht worden op een
Status
colour Blue
title

...

Documentaanvraag (

...

DA)
met de nieuwe requestVersion.
1. Uitzondering: Dit geldt niet indien de nieuwe requestVersion niet geaccepteerd is bij de aanbieder, zie daarvoor punt 3 bij Aanbieder. In dat geval mogen berichten met de oude versie worden blijven uitgewisseld.
Het is verplicht een bericht dat ontvangen wordt met een requestVersion die niet bekend is te verwerken.
Achtergrond: Deze regel is noodzakelijk omdat het mogelijk is dat ook rol 3 een nieuwe requestVersion kan introduceren. Daarmee kan in Rol 1 dus ook retourberichten ontvangen op een requestVersion die nog niet bekend is.

Vereisten voor Rol 2: Tussenstations zonder aanpassingen

Een requestVersion gaat over de versie van de gehele aanvraag in 1 dossier op het platform. Het groepeert daarbij meerdere typen berichten.
Dit betekent dat bij bijvoorbeeld het opnieuw opsturen van een document via een
Status
colour Blue
title

...

Document (

...

DX)
er geen nieuwe requestVersion wordt geïntroduceerd.
Het is verplicht een aanvraag met een requestversion > 1 te kunnen herkennen en verwerken.
Het is niet toegestaan binnen een dossier 2x een HDN-bericht van hetzelfde messageType, receiver, sender enrequestVersion op het platform te plaatsen.
1. Dit geldt alleen voor de volgende messageType
  Status
  colour Blue
  title

...

1. OfferTeaanvraag (AX)
  /
  Status
  colour Blue
  title

...

1. KredietAanvraag (

...

1. KX)
  /
  Status
  colour Blue
  title

...

1. WaarborgBERICHT (wx)
  /
  Status
  colour Blue
  title LevenAanvraag (LX)
Het is niet toegestaan een nieuwe requestVersion in het dossier te introduceren.
Wanneer een nieuwe requestVersion bekend is bij de partij mag er niet meer gereageerd worden op berichten van de oude requestVersion.
Bekend zijn betekent er is een bericht met nieuwe requestVersion opgehaald door deze partij.

Voorbeeld: Het is niet toegestaan nog een
Status
colour Blue
title Document (DX)
te versturen op een
Status
colour Blue
title Documentaanvraag (DA)
met een verouderde requestVersion. Om documenten te versturen moet gewacht worden op een
Status
colour Blue
title Documentaanvraag (DA)

...

met de nieuwe requestVersion.
1. Uitzondering: Dit geldt niet indien de nieuwe requestVersion niet geaccepteerd is bij de aanbieder, zie daarvoor punt 3 bij Aanbieder. In dat geval mogen berichten met de oude versie worden blijven uitgewisseld.
Het is verplicht een bericht dat ontvangen wordt met een requestVersion die niet bekend is te verwerken.
Achtergrond: Deze regel is noodzakelijk omdat het mogelijk is dat ook rol 3 een nieuwe requestVersion kan introduceren. Daarmee kan in Rol 2 dus ook retourberichten ontvangen op een requestVersion die nog niet bekend is.

Vereisten voor Rol 3: Tussenstations met aanpassingen

Een requestVersion gaat over de versie van de gehele aanvraag in 1 dossier op het platform. Het groepeert daarbij meerdere typen berichten.
Dit betekent dat bij bijvoorbeeld het opnieuw opsturen van een document via een
Status
colour Blue
title Document (DX)
er geen nieuwe requestVersion wordt geïntroduceerd.
Het is niet toegestaan binnen een dossier 2x een HDN-bericht van hetzelfde messageType, receiver, sender enrequestVersion op het platform te plaatsen.
1. Dit geldt alleen voor de volgende messageType
  Status
  colour Blue
  title OfferTeaanvraag (AX)
  /
  Status
  colour Blue
  title

...

1. KredietAanvraag (

...

1. KX)
  /
  Status
  colour Blue
  title

...

1. WaarborGBERICHT (

...

1. wx)
  /
  Status
  colour Blue
  title

...

Relevant voor rollen

...

Rol 1: Softwarepakketten (voorkant)

...

Rol 2: Tussenstations zonder aanpassingen

...

Rol 3: Tussenstations met aanpassingen

1. LevenAanvraag (LX)
Het is verplicht een aanvraag met een requestversion > 1 te kunnen herkennen en verwerken.
De partij is verplicht de requestVersion te wijzigen in het bericht wat wordt doorgestuurd wanneer er aanpassingen worden gedaan in het ontvangen HDN-bericht en deze niet tot de uitzonderingen behoren zoals gedefinieerd https://hdnstandaarddocumentatie.wikipage.io/c/2267021563/tussenpersoon+en+serviceprovidergegevens .
Wanneer een aanvraagbericht ontvangen wordt met een requestVersion welke al bekend is, is het verplicht dit bericht door te sturen met een ge-update requestVersion, welke 1 hoger is dan de requestVersion die bekend is.
Voorbeeld: rol 3 verhoogt de requestVersion van een ontvangen aanvraag naar 2 en stuurt deze door. Als op een later moment ook een partij in rol 1 de requestVersion verhoogt en hierbij ook 2 gebruikt, moet de partij in rol 3 deze requestVersion verhogen naar 3.
Wanneer er wordt gekozen om requestVersion te wijzigen moet de nieuwe waarde bepaald worden door de volgende informatie op te halen:
1. De verzenddatum en tijd van het laatst verstuurde bericht van dezelfde messageType in het dossier.
2. De verzenddatum en tijd van het laatst ontvangen bericht van dezelfde messageType in het dossier.
  
  Van a en b moet het nieuwste bericht gekozen worden. De nieuwe requestVersion moet dan als volgt worden berekend:
  1. In het geval het laatst verstuurde bericht van dezelfde messageType de laatste is, moet de requestVersion van dat bericht worden verhoogd met 1.
  2. In het geval het laatst ontvangen bericht van dezelfde messageType de laatste is, moet de requestVersion van dat bericht worden verhoogd met 1.
Wanneer een nieuwe requestVersion bekend is bij de partij mag er niet meer gereageerd worden op berichten van de oude requestVersion. Bekend zijn betekent: een bericht met daarin de nieuwe requestVersion ontvangen te hebben of door zelf een nieuw bericht met nieuwe requestVersion op het platform geplaatst te hebben.

Voorbeeld: Het is dus niet toegestaan nog een
Status
colour Blue
title Document (DX)
te versturen op een
Status
colour Blue
title Documentaanvraag (DA)
met een verouderde requestVersion. Om documenten te versturen moet gewacht worden op een
Status
colour Blue
title Documentaanvraag (DA)
met de nieuwe requestVersion.

Ter verduidelijking Dit betekent ook dat zodra een nieuwe requestVersion door partij in Rol 1 of Rol 2 wordt aangeleverd de communicatie met een partij in Rol 4 komt stil te liggen. Het bericht met deze requestVersion zal eerst moeten worden doorgestuurd alvorens het weer toegestaan is berichten (bijvoorbeeld
Status
colour Blue
title Document (DX)
) naar Rol 4 te versturen.

a. Uitzondering: Dit geldt niet indien de nieuwe requestVersion niet geaccepteerd is bij de aanbieder, zie daarvoor punt 3 bij Aanbieder. In dat geval mogen berichten met de oude versie worden blijven uitgewisseld.

Vereisten voor Rol 4a: Aanbieder: Hypotheken

...

, Rol 4b: Aanbieder: Verzekeren

...

, Rol 4c: Aanbieder: Kredieten

...

, Rol

...

Rol 4e: Aanbieder: Waarborgen

...

Type ketenafspraak

...

Inrichting schema’s
Vulling berichten
Procesafspraak
Verduidelijking omgaan met vulling van velden

...

Van toepassing op de velden

...

Veldnaam

...

Van toepassing op de entiteiten

Entiteitnaam

🤝 Ketenafspraak

...

Regel: Wanneer een partij een bericht met een nieuwe requestVersion heeft ontvangen mogen er geen nieuwe records met de oude requestVersion op het platform worden gezet.

Er mag dus ook geen SX worden verstuurd met bijv. Aanvraag beëindigd.

Regel: Een partij dient bij te houden wat de laatste requestVersion is die hij succesvol op het platform heeft geplaatst: wanneer er berichten binnen komen met een lagere requestVersion, dan moeten deze genegeerd worden (genegeerd: = niet opgehaald worden?). Ze mogen dus ook niet worden doorgestuurd

...

Regel:

Probleem: wat als serviceprovider AX aanpast en daarmee versie 2 introduceert? dan kan adviespakket dit nooit weten, want die AX wordt nooit opgestuurd → mag dat?

Vereisten voor rol X

Aanleiding en achtergrond

Tips (blok verwijderen in definitieve versie)

Achtergrond waarom deze ketenafspraak er gekomen is (en wat zijn doel verantwoord, en wanneer hij dus ook weer kan worden afgeschaft). Een voorbeeld is ook wanneer negatieve condities kunnen worden toegevoegd.

...

4e: Aanbieder: Waarborgen

Het is niet toegestaan een nieuwe requestVersion in het dossier te introduceren.
Het is verplicht een aanvraag met een requestversion > 1 op te kunnen halen.
Indien er niet omgaan kan worden met een verhoogde requestVersion moet er een
Status
colour Blue
title Statusmelding (Sx)
verstuurd worden.
1. Deze
  Status
  colour Blue
  title Statusmelding (Sx)
  moet gevuld worden met de volgende informatie:
  1. In geval van
    Status
    colour Blue
    title OfferTeaanvraag (AX)
    : StatusAXBericht: 25 Offerte aanvraag technisch niet te verwerken
  2. In geval van
    Status
    colour Blue
    title KredietAanvraag (KX)
    : StatusKXBericht: 25 Kredietaanvraag technisch niet te verwerken
  3. In geval van
    Status
    colour Blue
    title WaarborgBERICHT (wx)
    : StatusWXBericht: 03 Bankgarantieaanvraag niet te verwerken, zie toelichting
  4. In geval van
    Status
    colour Blue
    title LevenAanvraag (LX)
    : StatusLXBericht: 13 Levenaanvraag niet te verwerken, zie toelichting
    Ter verduidelijking: Dit scenario kan optreden wanneer een aanbieder geen gewijzigde aanvraag meer mag ontvangen (bijvoorbeeld de scenario’s uit Wijziging op lopende aanvragen ) of wanneer de aanbieder in het geheel geen gewijzigde aanvragen ondersteunt.
2. In de StatusTekstRegels entiteit van deze
  Status
  colour Blue
  title Statusmelding (Sx)
  moet minimaal een tekst opgenomen worden met de volgende strekking: “Aanvraagversie wordt niet ondersteund”.
Wanneer een nieuwe requestVersion bekend is bij de partij mag er niet meer gereageerd worden op berichten van de oude requestVersion.
Bekend zijn betekent: een bericht met daarin de nieuwe requestVersion ontvangen te hebben
Voorbeeld: Het is dus niet toegestaan nog een
Status
colour Blue
title Statusmelding (Sx)
te versturen waarin bijvoorbeeld de vorige requestVersion wordt beëindigd.
Ter verduidelijking: Dit betekent ook dat de rest van de keten bijvoorbeeld geen documenten meer mag insturen. Dit kan pas weer als er een nieuw
Status
colour Blue
title Documentaanvraag (DA)
bericht is opgestuurd, waarin de nieuwe requestVersion staat.
1. Uitzondering: Deze regel geldt niet indien de nieuwe requestVersion niet geaccepteerd wordt, zie daarvoor punt 3. In dat geval mogen berichten met de oude versie worden blijven uitgewisseld.

Aanleiding en achtergrond

Deze ketenafspraak is ontstaan naar aanleiding van onduidelijkheden over hoe partijen om moeten gaan met een gewijzigde aanvraag. Het was niet duidelijk met welke berichten je een wijziging mocht introduceren: zo konden niet alle partijen omgaan met het binnenkomen van

Status

colour	Blue
title	Document (DX)

met een andere versie dan de bijbehorende

Status

colour	Blue
title	OfferTeaanvraag (AX)

. Dit is nu in deze afspraak bepaald dat dit niet toegestaan is.

Ook was er onduidelijkheid over wie in het proces de een nieuwe requestVersion mogen maken wijzigen. Door expliciet dit aan Rol 1 en Rol 3 toe te wijzen wordt hier duidelijkheid in gegeven.

Out of scope

Deze ketenafspraak bepaalt niet in welke gevallen een gewijzigde requestVersion wel of niet mag worden aangeboden, zie daarvoor Wijziging op lopende aanvragen. De ketenafspraak “Gebruik van requestVersion in HDN-berichten” is gemaakt om te bepalen hoe met een gewijzigde requestVersion moet worden omgegaan en welke waarde requestVersion moet hebben.

Als gevolg van bovenstaande is er ook geen afspraak hoe om te gaan met een nieuwe major HDN-versie. Bij het ingaan van een nieuwe versie mag een partij zelf weten of zij hierbij nog gewijzigde aanvragen wil kunnen aanmaken. Het is wel verplicht deze te verwerken als ontvangende partij conform deze ketenafspraak.

Versies vergeleken

Oude versie 1

Nieuwe versie Huidige

Sleutel

🤝 Ketenafspraak

Vereisten voor rol 1 Softwarepakketten (voorkant)

Vereisten voor Rol 2: Tussenstations zonder aanpassingen

Vereisten voor Rol 3: Tussenstations met aanpassingen

Vereisten voor Rol 4a: Aanbieder: Hypotheken

, Rol 4b: Aanbieder: Verzekeren

, Rol 4c: Aanbieder: Kredieten

, Rol

🤝 Ketenafspraak

Vereisten voor rol X

Aanleiding en achtergrond

4e: Aanbieder: Waarborgen

Aanleiding en achtergrond

Out of scope

Pagina-vergelijking

Versies vergeleken

Oude versie 1

Nieuwe versie Huidige

Sleutel

🤝 Ketenafspraak

Vereisten voor rol 1 Softwarepakketten (voorkant)

Vereisten voor Rol 2: Tussenstations zonder aanpassingen

Vereisten voor Rol 3: Tussenstations met aanpassingen

Vereisten voor Rol 4a: Aanbieder: Hypotheken

, Rol 4b: Aanbieder: Verzekeren

, Rol 4c: Aanbieder: Kredieten

, Rol

🤝 Ketenafspraak

Vereisten voor rol X

Aanleiding en achtergrond

4e: Aanbieder: Waarborgen

Aanleiding en achtergrond

Out of scope