Pagina-eigenschappen | ||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||
|
🤝 Ketenafspraak
...
Vereisten voor rol 1 Softwarepakketten (voorkant)
Een
requestVersion
gaat over de versie van de gehele aanvraag in 1 een dossier op het platform. Het groepeert daarbij meerdere typen berichten.
Dit betekent dat bij bijvoorbeeld het opnieuw opsturen van een document via een DocumentBericht
er geen nieuweStatus colour Blue title Document (DX) requestVersion
wordt geïntroduceerd.Het is niet toegestaan binnen een dossier 2x 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 AX OfferteAanvraag
KX KredietAanvraag
LX LevenAanvraag
WX WaarborgBericht
/title OfferTeaanvraag (AX) Status colour Blue title KredietAanvraag (KX)
/Status colour Blue title 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 1 één van de volgende messageType
Het is verplicht de SX 40 Gewijzigde aanvraag ingestuurd
met daarin het veld NieuweAanvraagVersie
te kunnen verwerken.
AX OfferteAanvraag
KX KredietAanvraag
LX LevenAanvraag
WX WaarborgBericht
Status | ||||
---|---|---|---|---|
|
Status | ||||
---|---|---|---|---|
|
Status | ||||
---|---|---|---|---|
|
Status | ||||
---|---|---|---|---|
|
Wanneer er wordt gekozen om requestVersion
te wijzigen moet de nieuwe waarde bepaald worden door de volgende informatie op te halen:
De verzenddatum en tijd van de laatste SX 40 Gewijzigde aanvraag ingestuurd
die is binnen gekomen.
messageType
in het dossier.Van a en b moet het nieuwste bericht gekozen worden. De nieuwe
requestVersion
moet dan als volgt worden berekend:In het geval de SX 40 Gewijzigde aanvraag ingestuurd
het laatste bericht is, moet de waarde in het veld NieuweAanvraagVersie
uit deze SX worden opgehaald en worden verhoogd met 1.
messageType
de laatste is, moet de requestVersion
van dat bericht worden verhoogd met 1.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 | ||||
---|---|---|---|---|
|
Status | ||||
---|---|---|---|---|
|
Status | ||||
---|---|---|---|---|
|
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 | ||||
---|---|---|---|---|
|
requestVersion
=2
terug. 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 | ||||
---|---|---|---|---|
|
1
=3
Wanneer een nieuwe requestVersion
bekend is bij de partij mag er niet meer gereageerd worden op berichten van de oude requestVersion
.
SX 40 Gewijzigde aanvraag ingestuurd
ontvangen of door zelf een nieuw bericht met nieuwe requestVersion
.
Ter verduidelijking:
Het is niet toegestaan nog een
DocumentBericht DXStatus | ||||
---|---|---|---|---|
|
Status | ||||
---|---|---|---|---|
|
requestVersion
. Om documenten te versturen moet gewacht worden op een Status | ||||
---|---|---|---|---|
|
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 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 DocumentBericht
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
AX OfferteAanvraag
KX KredietAanvraag
LX LevenAanvraag
WX WaarborgBericht
Dit betekent ook dat als een bericht ontvangen wordt dat hier niet aan voldoet, deze niet mag worden verwerkt.
/Status colour Blue title OfferTeaanvraag (AX)
/Status colour Blue title KredietAanvraag (KX)
/Status colour Blue title 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
via SX 40 Gewijzigde aanvraag ingestuurd
ontvangen of
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
.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 DocumentBericht
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 AX OfferteAanvraag
KX KredietAanvraag
LX LevenAanvraag
WX WaarborgBericht
Dit betekent ook dat als een bericht ontvangen wordt dat hier niet aan voldoet, deze niet mag worden verwerkt.
/colour Blue title OfferTeaanvraag (AX)
/Status colour Blue title KredietAanvraag (KX)
/Status colour Blue title 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-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:
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.
In het geval de
Van a en b en c moet het nieuwste bericht gekozen worden. De nieuwerequestVersion
moet dan als volgt worden berekend:SX 40 Gewijzigde aanvraag ingestuurd
het laatste bericht is, moet de waarde in het veldNieuweAanvraagVersie
uit deze SX worden opgehaald en worden verhoogd met 1.In het geval het laatst verstuurde bericht van dezelfde
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.
requestVersion
wordt geïntroduceerd door deze partij is het verplicht dit aan rol 1
SX 40 Gewijzigde aanvraag ingestuurd
te versturen naar deze partij met daarin in het veld NieuweAanvraagVersie
de waarde van de nieuwe requestVersion
.
- De
requestVersion
die opgevoerd wordt bij deze SX is de ouderequestVersion
Wanneer een nieuwe requestVersion
bekend is bij de partij mag er niet meer gereageerd worden op berichten van de oude requestVersion
. Bekend zijn kan betekenen:
via 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 StatusMelding (SX) verstuurt worden
verstuurd worden.Status colour Blue title Statusmelding (Sx) Deze
moet gevuld worden met de volgende informatie:Status colour Blue title Statusmelding (Sx) In geval van
In geval van een binnenkomende KredietAanvraag (KX):
Status colour Blue title OfferTeaanvraag (AX) StatusAXBerichtType
moet gevuld zijn met 14 Offerteaanvraag :StatusAXBericht
:25 Offerte aanvraag technisch niet te verwerken, zie toelichting
In de tekstregels moet zijn opgenomen dat de genoemde requestVersion niet wordt ondersteund.
De
requestVersion
van dit bericht moet derequestVersion
bevatten van het binnenkomende bericht.
In geval van een een binnenkomende LevenAanvraag (LX):
StatusLXBerichtType
moet gevuld zijn met13 Levenaanvraag niet te verwerken, zie toelichting
In de tekstregels moet zijn opgenomen dat de ingestuurde requestVersion niet wordt ondersteund.
De
requestVersion
van dit bericht moet derequestVersion
bevatten van het binnenkomende bericht.
StatusKXBerichtType
moet gevuld zijn met 03 KredietaanvraagIn 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 de tekstregels moet zijn opgenomen dat de ingestuurde requestVersion niet wordt ondersteund.
De
requestVersion
van dit bericht moet derequestVersion
bevatten van het binnenkomende bericht.
In geval van een binnenkomende WaarborgBericht (WX):
StatusWXBerichtType
moet gevuld zijn met 14 Bankgarantieaanvraag geval van
:Status colour Blue title LevenAanvraag (LX) StatusLXBericht
:13 Levenaanvraag niet te verwerken, zie toelichting
In de tekstregels moet zijn opgenomen dat de ingestuurde requestVersion niet wordt ondersteund.
De
requestVersion
van dit bericht moet derequestVersion
bevatten van het binnenkomende bericht.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)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
StatusMelding (SX)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 DocumentAanvraag
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 DocumentBerichten
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 StatusMelding (SX) is dit verholpen.
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. Deze afspraak 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.
...