/
KET-041: Het gebruik van requestversion in HDN-berichten

KET-041: Het gebruik van requestversion in HDN-berichten

Samenvatting

Deze ketenafspraak beschrijft hoe om te gaan met een gewijzigde aanvraag en requestVersion te vullen bij het versturen van HDN-berichten. Dit voorkomt onduidelijkheden wanneer en voor wie het mogelijk is om een wijziging in de requestVersion door te voeren, en wat er nog toegestaan is nadat er een nieuwe requestVersion is.

Ingangsdatum huidige versie

May 25, 2024

Laatst gewijzigd per HDN-versie

status:HDN-24

Impact op

status:OfferTeaanvraag (AX)/status:KredietAanvraag (KX)/ status:Levenaanvraag (lx)/status:WaarborgBERICHT (wx) / status:DocumentBericht (DX) / status:Doc.aanvraagBericht (DA)

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

  • Proces

Van toepassing op de velden

API

  • AanvraagVersie/ requestVersion (JSON veld)

status:Statusmelding (Sx)

  • //Status/AXBerichtStatusSpecificatie/StatusAXBericht

  • //Status/KXBerichtStatusSpecificatie/StatusKXBericht

  • //Status/LXBerichtStatusSpecificatie/StatusLXBericht

  • //Status/WBerichtStatusSpecificatie/StatusWXBericht

Van toepassing op de entiteiten

status:Statusmelding (Sx)

  • //StatusTekstRegels/

Ketenafspraak

Vereisten voor rol 1 Softwarepakketten (voorkant)

  1. Bij het versturen van een het eerste bericht in een dossier is het verplicht het veld requestVersion in de JSON met 1 te vullen.

  2. Het is alleen toegestaan een nieuwe requestVersion te introduceren bij het versturen van een bericht met één van de volgende messageType status:OfferTeaanvraag (AX)/status:KredietAanvraag (KX)/ status:Levenaanvraag (lx)/ status:WaarborgBERICHT (wx).

  3. Het is niet toegestaan binnen een dossier twee keer een HDN-bericht van hetzelfde messageType, receiver, sender enrequestVersion te versturen.

    1. Dit geldt alleen voor de volgende messageType status:OfferTeaanvraag (AX)/status:KredietAanvraag (KX)status:Levenaanvraag (lx) /status:WaarborgBERICHT (wx).

  4. Wanneer er een nieuwe aanvraag ingediend wordt is het verplicht de huidige requestVersion met 1 te verhogen.
    Ter verduidelijking: ‘huidige' betekent een bericht van elk messageType, dus ook status:Doc.aanvraagBericht (DA), status:Offerte (OX)en status:StatusMelding (SX) . Hiermee wordt voorkomen dat een HDN-bericht verderop in de keten wordt verhoogd en er daardoor meerdere keren dezelfde requestVersion wordt gemaakt.
    Voorbeeld: Rol 1: Softwarepakketten stuurt requestVersion 1 naar een Rol 3: Tussenstations met aanpassingen. Deze maakt een wijziging en introduceert requestVersion 2. De aanbieder stuurt daarop een status:StatusMelding (SX) met requestVersion 2terug. De serviceprovider stuurt deze weer terug naar het adviespakket. Wanneer een intermediair een wijziging in de aanvraag wil doorvoeren moet de nieuwe requestVersion de waarde 3 hebben. Deze moet gebaseerd zijn het op het laatste bericht dat het adviespakket heeft ontvangen, de status:StatusMelding (SX)(2) + 1=3.

  5. Wanneer een nieuwe requestVersion bekend is, is het niet toegestaan om te reageren op berichten van de oude requestVersion.
    Ter verduidelijking: Het is niet toegestaan nog een status:DocumentBericht (DX) te versturen als reactie te versturen op een status:Doc.aanvraagBericht (DA) met een verouderde requestVersion. Om documenten te versturen is een status:Doc.aanvraagBericht (DA) met de nieuwe requestVersion nodig.

    1. Uitzondering: Dit geldt niet indien de nieuwe requestVersion niet geaccepteerd is bij de aanbieder, zie daarvoor punt 3 bij Rol 4: Aanbieder. In dat geval moet de oude requestVersion gehandhaaft blijven.

  6. Het is verplicht een ontvangen bericht met een onbekende requestVersion te verwerken.
    Achtergrond: Deze regel is noodzakelijk omdat het mogelijk is dat ook Rol 3: Tussenstations met aanpassingen een nieuwe requestVersion kan introduceren. Rol 1: Softwarepakketten kan dus ook retourberichten ontvangen op een requestVersion die nog niet bekend is.

 

Vereisten voor Rol 2: Tussenstations zonder aanpassingen

  1. Het is niet toegestaan een nieuwe requestVersion in het dossier te introduceren.

  2. Het is verplicht een aanvraag met een requestversion >1 te kunnen herkennen en verwerken.

  3. Het is niet toegestaan binnen een dossier twee keer een HDN-bericht van hetzelfde messageType, receiver, sender enrequestVersion te versturen.

    1. Dit geldt alleen voor de volgende messageTypestatus:OfferTeaanvraag (AX)/status:KredietAanvraag (KX)/ status:WaarborgBERICHT (wx)/status:LevenAanvraag (LX).

  4. Wanneer een nieuwe requestVersion bekend is, is het niet toegestaan om te reageren op berichten van de oude requestVersion.
    Ter verduidelijking: Het is niet toegestaan nog een status:DocumentBericht (DX) te versturen als reactie te versturen op een status:Doc.aanvraagBericht (DA) met een verouderde requestVersion. Om documenten te versturen is een status:Doc.aanvraagBericht (DA) met de nieuwe requestVersion nodig.

    1. Uitzondering: Dit geldt niet indien de nieuwe requestVersion niet geaccepteerd is bij de aanbieder, zie daarvoor punt 3 bij Rol 4: Aanbieder. In dat geval moet de oude requestVersion gehandhaaft blijven.

  5. Het is verplicht een ontvangen bericht met een onbekende requestVersion te verwerken.
    Achtergrond: Deze regel is noodzakelijk omdat het mogelijk is dat ook Rol 3: Tussenstations met aanpassingen een nieuwe requestVersion kan introduceren. Rol 2: tussenstations zonder aanpassing kan dus ook retourberichten ontvangen op een requestVersion die nog niet bekend is.

Vereisten voor Rol 3: Tussenstations met aanpassingen

  1. Het is verplicht de requestVersion te wijzigen wanneer een bericht wordt doorgestuurd waarin afwijkingen zitten ten opzicht van het ontvangen HDN-bericht.

    1. Hierop zijn uitzonderingen, zie KET-027: Niet toegestane wijzigingen op een lopende aanvraag , Rol 3, punt 4.

  2. Het is niet toegestaan binnen een dossier twee keer een HDN-bericht van hetzelfde messageType, receiver, sender enrequestVersion te versturen.

    1. Dit geldt alleen voor de volgende messageTypestatus:OfferTeaanvraag (AX)/status:KredietAanvraag (KX)/ status:WaarborGBERICHT (wx)/status:LevenAanvraag (LX).

  3. Het is verplicht een aanvraag met een requestversion > 1 te kunnen herkennen en verwerken.

  4. Wanneer een aanvraagbericht wordt ontvangen 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: Tussenstations met aanpassingen verhoogt de requestVersion van een ontvangen aanvraag naar 2 en stuurt deze door. Als op een later moment ook een organisatie in Rol 1: Softwarepakketten de requestVersion verhoogt en hierbij ook 2 gebruikt, moet de organisatie in Rol 3: Tussenstations met aanpassingen deze requestVersion verhogen naar 3.

  5. Wanneer er gekozen wordt om requestVersion te wijzigen wordt deze bepaald door het laatste verstuurde of ontvangen bericht van hetzelfde messageType in het dossier. Dit wordt als volgt berekend: de requestVersion van het bericht van hetzelfde messageType die als laatste ontvangen of verstuurd is wordt verhoogd met 1.

  6. Wanneer een nieuwe requestVersion bekend is, is het niet toegestaan om te reageren op berichten van de oude requestVersion.
    Voorbeeld: Het is dus niet toegestaan nog een status:Documentbericht (DX) te versturen als reactie op een status:Doc.aanvraagBericht (DA) met een verouderde requestVersion. Om documenten te versturen woordt gewacht op een status:Doc.aanvraagBericht (DA) met de nieuwe requestVersion.
    Ter verduidelijking: Dit betekent ook dat zodra een nieuwe requestVersion door een organisatie in Rol 1: Softwarepakketten of Rol 2: tussenstations zonder aanpassing is aangemaakt het alleen nog toegestaan is om het bericht door te sturen. Het is dus niet toegestaan nog een status:Documentbericht (DX) te versturen met de oude requestVersion.
    Uitzondering: Dit geldt niet indien de nieuwe requestVersion niet geaccepteerd is bij de aanbieder, zie daarvoor punt 3 bij Rol 4: Aanbieder. In dat geval is het toegestaan om berichten met de oude requestVersion uit te wisselen.

 

Vereisten voor Rol 4a: Aanbieder: Hypotheken, Rol 4b: Aanbieder: Verzekeren, Rol 4c: Aanbieder: Kredieten, Rol 4e: Aanbieder: Waarborgen

  1. Het is niet toegestaan een nieuwe requestVersion in het dossier te introduceren.

  2. Het is verplicht een aanvraag met een requestversion > 1 op te kunnen halen.

  3. Indien een verhoogde requestVersion niet acceptabel is moet de aanbieder een status:Statusmelding (Sx) versturen.

    1. Deze status:Statusmelding (Sx) moet de volgende informatie bevatten:

      1. In geval van status:OfferTeaanvraag (AX)://Status/AXBerichtStatusSpecificatie/StatusAXBericht gevuld met 25 Offerteaanvraag technisch niet te verwerken.

      2. In geval van status:KredietAanvraag (KX): //Status/KXBerichtStatusSpecificatie/StatusKXBerichtgevuld met 25 Kredietaanvraag technisch niet te verwerken.

      3. In geval van status:WaarborgBERICHT (wx): //Status/WXBerichtStatusSpecificatie/StatusWXBerichtgevuld met 03 Bankgarantieaanvraag niet te verwerken, zie toelichting.

      4. In geval van status:LevenAanvraag (LX): //Status/LXBerichtStatusSpecificatie/StatusLXBericht gevuld met 13 Levenaanvraag niet te verwerken, zie toelichting.

        Ter verduidelijking: Dit scenario kan optreden wanneer een aanbieder geen gewijzigde aanvraag kan ontvangen (bijvoorbeeld de scenario’s uit Wijziging op lopende aanvragenarchived ) of wanneer de aanbieder in het geheel geen gewijzigde aanvragen ondersteunt.

    2. In de //StatusTekstRegels/ entiteit van deze status:Statusmelding (Sx) moet minimaal een tekst staan met de volgende strekking: “Aanvraagversie wordt niet ondersteund”.

  4. Wanneer een nieuwe requestVersion bekend is bij de organisatie is het niet toegestaan om te reageren op berichten van de oude requestVersion.
    Voorbeeld: Het is dus niet toegestaan nog een status:Statusmelding (Sx) te versturen waarin bijvoorbeeld de vorige requestVersion wordt beëindigd.
    Ter verduidelijking: Dit betekent ook dat het voor de de rest van de keten bijvoorbeeld niet toegestaan is om eenstatus:documentBericht (DX) te sturen. Dit kan pas weer als er een nieuw status:Doc.aanvraagBericht (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 is het toegestaan berichten met de oude versie te blijven versturen.

Aanleiding en achtergrond

Deze ketenafspraak beschrijft hoe om te gaan met een gewijzigde aanvraag. Dit voorkomt onduidelijkheden wanneer en voor wie het mogelijk is om een wijziging in de requestVersion door te voeren, en wat er nog toegestaan is nadat er een nieuwe requestVersion is.

Versiegeschiedenis

Versie

Wijzigingen

Datum

HDN Versie

Versie

Wijzigingen

Datum

HDN Versie

1.0

 Initiële ketenafspraak

May 25, 2024

status:HDN-24

 

Related content