Pagina-eigenschappen | |||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||||
|
🤝 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
er geen nieuweStatus colour Blue title Document (DX) 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.Dit geldt alleen voor 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 Waarborg WaarborgBERICHT (wx)
Het is verplicht in het eerste bericht in een dossier het veld
requestVersion
in de JSON met1
te vullenHet is alleen toegestaan een nieuwe
requestVersion
te introduceren bij het plaatsen van een bericht met één van de volgendemessageType
/Status colour Blue title OfferTeaanvraag (AX)
/Status colour Blue title KredietAanvraag (KX)
Het is verplicht de /Status colour Blue title Waarborg Levenaanvraag (wxlx) Status colour Blue title Statusmelding WaarborgBERICHT (Sx) 40 Gewijzigde aanvraag ingestuurd
met daarin het veldNieuweAanvraagVersie
te kunnen verwerken.wx) Wanneer er wordt gekozen om
De verzenddatum en tijd van de laatsterequestVersion
te wijzigen moet de nieuwe waarde bepaald worden door de volgende informatie op te halen:het laatste bericht in het dossier te pakken en de
requestVersion
van dat bericht te verhogen met1
.
Ter verduidelijking: dit kan een bericht zijn van elkmessageType
, dus ook
,Status colour Blue title Documentaanvraag (DA)
enStatus colour Blue title Offerte (OX)
StatusmeldingStatus colour Blue title
SxStatusMelding ( SX) 40 Gewijzigde aanvraag ingestuurd
die is binnen gekomen.De verzenddatum en tijd van het laatst verstuurde bericht van dezelfde
In het geval demessageType
in het dossier.
Van a en b moet het nieuwste bericht gekozen worden. De nieuwerequestVersion
moet dan als volgt worden berekend:. 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) stuurtrequestVersion
=1
naar een serviceprovider (rol 3). Deze maakt een wijziging en introduceertrequestVersion
=2
. De aanbieder stuurt daarop een
StatusmeldingStatus colour Blue title
Sx)StatusMelding ( 40 Gewijzigde aanvraag ingestuurd
het laatste bericht is, moet de waarde in het veldNieuweAanvraagVersie
uit deze worden opgehaald.In het geval het laatst verstuurde bericht van dezelfdemessageType
de laatste is, moet derequestVersion
van dat bericht worden verhoogd met 1.
metSX) requestVersion
=2
terug. De serviceprovider stuurt deze weer terug naar het adviespakket. Wanneer je in het adviespakket een nieuwerequestVersion
wilt introduceren moet dit de waarde3
hebben. Deze moet gebaseerd zijn het op het laatste bericht dat het adviespakket heeft ontvangen, de
(2) +Status colour Blue title StatusMelding (SX) 1
=3
Wanneer een nieuwe
Bekend zijn kan betekenen: viarequestVersion
bekend is bij de partij mag er niet meer gereageerd worden op berichten van de ouderequestVersion
.Status colour Blue title Statusmelding (Sx) 40 Gewijzigde aanvraag ingestuurd
ontvangen of door zelf een nieuw bericht met nieuwe
op het platform geplaatst te hebbenrequestVersion
.
de verplichting geldt pas als het bericht op het platform geplaatst is, enkel het aanmaken maar nog niet op het platform gezet telt hierin niet mee.
Ter verduidelijking:Het is niet toegestaan nog een
te versturen op eenStatus colour Blue title Document (DX)
met een verouderdeStatus colour Blue title Documentaanvraag (DA) requestVersion
. Om documenten te versturen moet gewacht worden op een
met de nieuweStatus colour Blue title Documentaanvraag (DA) requestVersion
.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 nieuwerequestVersion
kan introduceren. Daarmee kan in Rol 1 dus ook retourberichten ontvangen op eenrequestVersion
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
er geen nieuweStatus colour Blue title Document (DX) 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.Dit geldt alleen voor de volgende
messageType
/Status colour Blue title OfferTeaanvraag (AX)
/Status colour Blue title KredietAanvraag (KX)
Dit betekent ook dat als een bericht ontvangen wordt dat hier niet aan voldoet, deze niet mag worden verwerkt.Status colour Blue title Waarborg WaarborgBERICHT (wx)
/Status colour Blue title LevenAanvraag (LX)
Het is niet toegestaan een nieuwe
requestVersion
in het dossier te introduceren.Wanneer een nieuwe
kan betekenen:requestVersion
bekend is bij de partij mag er niet meer gereageerd worden op berichten van de ouderequestVersion
.
Bekend zijnvia
Status colour Blue title Statusmelding (Sx) 40 Gewijzigde aanvraag ingestuurd
ontvangen of door een nieuw 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 nieuwerequestVersion
kan introduceren. Daarmee kan in Rol 2 dus ook retourberichten ontvangen op eenrequestVersion
die nog niet bekend is.
betekent er is een bericht met nieuwe requestVersion
opgehaald
door deze partij.
Voorbeeld: Het is niet toegestaan nog een
Status | ||||
---|---|---|---|---|
|
Status | ||||
---|---|---|---|---|
|
requestVersion
. Om documenten te versturen moet gewacht worden op een Status | ||||
---|---|---|---|---|
|
requestVersion
.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
er geen nieuweStatus colour Blue title Document (DX) 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.Dit geldt alleen voor de volgende
messageType
/Status colour Blue title OfferTeaanvraag (AX)
/Status colour Blue title KredietAanvraag (KX)
Dit betekent ook dat als een bericht ontvangen wordt dat hier niet aan voldoet, deze niet mag worden verwerkt.Status colour Blue title Waarborg WaarborGBERICHT (wx)
/Status colour Blue title 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-updaterequestVersion
, welke 1 hoger is dan derequestVersion
die bekend is.
Voorbeeld: rol 3 verhoogt derequestVersion
van een ontvangen aanvraag naar 2 en stuurt deze door. Als op een later moment ook een partij in rol 1 derequestVersion
verhoogt en hierbij ook 2 gebruikt, moet de partij in rol 3 dezerequestVersion
verhogen naar 3.Wanneer er wordt gekozen om
De verzenddatum en tijd van de laatsterequestVersion
te wijzigen moet de nieuwe waarde bepaald worden door de volgende informatie op te halen:Status colour Blue title Statusmelding (Sx) 40 Gewijzigde aanvraag ingestuurd
die is binnen gekomen.De verzenddatum en tijd van het laatst verstuurde bericht van dezelfde
messageType
in het dossier.De verzenddatum en tijd van het laatst ontvangen bericht van dezelfde
messageType
in het dossier.
Van a en b en c moet het nieuwste bericht gekozen worden. De nieuwerequestVersion
moet dan als volgt worden berekend:In het geval de
Status colour Blue title Statusmelding (Sx) 40 Gewijzigde aanvraag ingestuurd
het laatste bericht is, moet de waarde in het veldNieuweAanvraagVersie
uit deze
worden opgehaald.In het geval het laatst verstuurde bericht van dezelfdeStatus colour Blue title Statusmelding (Sx) messageType
de laatste is, moet derequestVersion
van dat bericht worden verhoogd met 1.In het geval het laatst ontvangen bericht van dezelfde
messageType
de laatste is, moet derequestVersion
van dat bericht worden verhoogd met 1.
Wanneer er een nieuwe
requestVersion
wordt geïntroduceerd door deze partij is het verplicht dit aan rol 1 en rol 2 te laten weten. Dit moet gedaan worden door eenStatus colour Blue title Statusmelding (Sx) 40 Gewijzigde aanvraag ingestuurd
te versturen naar deze partij met daarin in het veldNieuweAanvraagVersie
= huidigerequestVersion
+ 1 enrequestVersion
in de JSON = huidigerequestVersion
.
Optioneel kan met de entiteitTekstRegels
opgegeven worden wat de inhoudelijke wijzigingen zijn.Wanneer een nieuwerequestVersion
bekend is bij de partij mag er niet meer gereageerd worden op berichten van de ouderequestVersion
. Bekend zijn kan betekenen:via
Status colour Blue title Statusmelding (Sx) 40 Gewijzigde aanvraag ingestuurd
ontvangen of
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
te versturen op eenStatus colour Blue title Document (DX)
met een verouderdeStatus colour Blue title Documentaanvraag (DA) requestVersion
. Om documenten te versturen moet gewacht worden op een
met de nieuweStatus colour Blue title Documentaanvraag (DA) requestVersion
.
Ter verduidelijking Dit betekent ook dat zodra een nieuwerequestVersion
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 dezerequestVersion
zal eerst moeten worden doorgestuurd alvorens het weer toegestaan is berichten (bijvoorbeeld
) naar Rol 4 te versturen.Status colour Blue title Document (DX)
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 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
verstuurd worden. De melding hierin is afhankelijk van de procesflow van het berichttype ProcesbeschrijvingenStatus colour Blue title Statusmelding (Sx) Deze
moet gevuld worden met de volgende informatie:Status colour Blue title Statusmelding (Sx) In geval van
:Status colour Blue title OfferTeaanvraag (AX) StatusAXBericht
:25 Offerte aanvraag technisch niet te verwerken
In geval van
:Status colour Blue title KredietAanvraag (KX) StatusKXBericht
:25 Kredietaanvraag technisch niet te verwerken
In geval van
:Status colour Blue title WaarborgBERICHT (wx) StatusWXBericht
:03 Bankgarantieaanvraag niet te verwerken, zie toelichting
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.
Uitzoekpunt: bij rol 1, 2, 3 is dan de oude
requestVersion
niet meer geldig. Deze kunnen dan dus ook geen Documenten hier meer op versturen. De aanvraag kan in dat geval dus alleen nog door de aanbieder verwerkt worden (SX en OX kunnen verstuurd blijven worden). Hoe willen we hier mee omgaan?In deStatusTekstRegels
entiteit van deze
moet minimaal een tekst opgenomen worden met de volgende strekking: “Aanvraagversie wordt niet ondersteund”.Status colour Blue title Statusmelding (Sx)
Wanneer een nieuwe
kan betekenenrequestVersion
bekend is bij de partij mag er niet meer gereageerd worden op berichten van de ouderequestVersion
.
Bekend zijnbetekent:
een bericht met daarin de nieuwe
requestVersion
ontvangen te hebben
Voorbeeld: Het is dus niet toegestaan nog een
te versturen waarin bijvoorbeeld de vorigeStatus colour Blue title Statusmelding (Sx) 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
bericht is opgestuurd, waarin de nieuweStatus colour Blue title Documentaanvraag (DA) requestVersion
staat.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 | ||||
---|---|---|---|---|
|
Status | ||||
---|---|---|---|---|
|
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.Tot slot was er geen manier om als tussenstation door te geven aan de aanleverende partij dat de aanvraag is aangepast. Hierdoor kon een partij in Rol 1 niet meer een aanvraag wijzigen, omdat het een tussenstation dit al gedaan had. Met het introduceren van een nieuwe status in de
Status | ||||
---|---|---|---|---|
|
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.
...