Spring naar het einde van metadata
Ga nar het begin van metadata

Je bekijkt een oude versie van deze pagina. Bekijk de huidige versie.

Vergelijk met huidige Toon pagina geschiedenis

« Vorige Versie 14 Volgende »

Pagina-eigenschappen ID mag maximaal 256 tekens zijn.

🤝 Ketenafspraak

Vereisten voor rol 1 Softwarepakketten (voorkant)

  1. 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 DOCUMENT (DX) er geen nieuwe requestVersion wordt geïntroduceerd.

  2. 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 OFFERTEAANVRAAG (AX)/KREDIETAANVRAAG (KX)LEVENAANVRAAG (LX) /WAARBORG (WX)

  3. Het is verplicht in het eerste bericht in een dossier het veld requestVersion in de JSON met 1 te vullen

  4. Het is alleen toegestaan een nieuwe requestVersion te introduceren bij het plaatsen van een bericht met één van de volgende messageType OFFERTEAANVRAAG (AX)/KREDIETAANVRAAG (KX)/ WAARBORG (WX)

  5. 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.

    1. Ter verduidelijking: dit kan een bericht zijn van elk messageType, dus ook DOCUMENTAANVRAAG (DA), OFFERTE (OX)en STATUSMELDING (SX) .

  6. Wanneer een nieuwe requestVersion bekend is bij de partij mag er niet meer gereageerd worden op berichten van de oude requestVersion.

    1. Ter verduidelijking: Het is niet toegestaan nog een DOCUMENT (DX) te versturen op een DOCUMENTAANVRAAG (DA) met een verouderde requestVersion. Om documenten te versturen moet gewacht worden op een DOCUMENTAANVRAAG (DA) met de nieuwe requestVersion.

  7. Het is verplicht een bericht dat ontvangen wordt met een requestVersion die niet bekend is te verwerken.
    Achtergrond: Bovenstaande regels sluiten niet uit dat meerdere partijen in de keten dezelfde requestVersion introduceren in een dossier, bijvoorbeeld in het geval van een serviceprovider die een versie verhoogd. Het is dus van belang dat ook berichten die ontvangen worden met een requestversion die niet bekend is, ook verwerkt kunnen worden. Een voorbeeld is een OFFERTE (OX) met een requestversion die niet bekend is omdat een Rol 3 een wijziging gedaan heeft.

Vereisten voor Rol 2: Tussenstations zonder aanpassingen

  1. 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 DOCUMENT (DX) er geen nieuwe requestVersion wordt geïntroduceerd.

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

  3. 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 messageTypeOFFERTEAANVRAAG (AX)/KREDIETAANVRAAG (KX)/ WAARBORG (WX)/LEVENAANVRAAG (LX)

      Dit betekent ook dat als een bericht ontvangen wordt dat hier niet aan voldoet, deze niet mag worden verwerkt.

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

  5. Wanneer een nieuwe requestVersion bekend is bij de partij mag er niet meer gereageerd worden op berichten van de oude requestVersion.

    1. Bekend zijn betekent er is een bericht met nieuwe requestVersion opgehaald door deze partij.

      Het is niet toegestaan nog een DOCUMENT (DX) te versturen op een DOCUMENTAANVRAAG (DA) met een verouderde requestVersion. Om documenten te versturen moet gewacht worden op een DOCUMENTAANVRAAG (DA) met de nieuwe requestVersion.

  6. Het is verplicht een bericht dat ontvangen wordt met een requestVersion die niet bekend is te verwerken.
    Achtergrond: Bovenstaande regels sluiten niet uit dat meerdere partijen in de keten dezelfde requestVersion introduceren in een dossier, bijvoorbeeld in het geval van een serviceprovider die een versie verhoogd. Het is dus van belang dat ook berichten die ontvangen worden met een requestversion die niet bekend is, ook verwerkt kunnen worden. Een voorbeeld is een OFFERTE (OX) met een requestversion die niet bekend is omdat een Rol 3 een wijziging gedaan heeft.

Vereisten voor Rol 3: Tussenstations met aanpassingen

  1. 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 DOCUMENT (DX) er geen nieuwe requestVersion wordt geïntroduceerd.

  2. 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 messageTypeOFFERTEAANVRAAG (AX)/KREDIETAANVRAAG (KX)/ WAARBORG (WX)/LEVENAANVRAAG (LX)

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

  4. 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 .

  5. Wanneer een aanvraagbericht ontvangen wordt met een requestVersion welke al bekend is bij deze rol, is het verplicht dit bericht door te sturen met een geupdate 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.

  6. 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.

  7. 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.

Ter verduidelijking: 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.

Het is dus niet toegestaan nog een DOCUMENT (DX) te versturen op een DOCUMENTAANVRAAG (DA) met een verouderde requestVersion. Om documenten te versturen moet gewacht worden op een DOCUMENTAANVRAAG (DA) met de nieuwe requestVersion.

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 DOCUMENT (DX)) naar Rol 4 te versturen.

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 er niet omgaan kan worden met een verhoogde requestVersion moet er een STATUSMELDING (SX) verstuurd worden met de requestVersion gevuld met de net binnengekomen requestVersion. De melding hierin is afhankelijk van de procesflow van het berichttype Procesbeschrijvingen

    1. 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?

  4. Wanneer een nieuwe requestVersion bekend is bij de partij mag er niet meer gereageerd worden op berichten van de oude requestVersion.

    1. Bekend zijn kan betekenen:

      1. een bericht met daarin de nieuwe requestVersion ontvangen te hebben

    2. Het is dus niet toegestaan nog een STATUSMELDING (SX) te versturen waarin bijvoorbeeld de vorige requestVersion wordt beëindigd.

    3. Dit betekent ook dat de rest van de keten bijvoorbeeld geen documenten meer mag insturen. Dit kan pas weer als er een nieuw DOCUMENTAANVRAAG (DA) bericht is opgestuurd, waarin de nieuwe requestVersion staat.

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 DOCUMENT (DX) met een andere versie dan de bijbehorende 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.

  • Geen labels