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

Versie 1 Volgende »

Pagina-eigenschappen ID mag maximaal 256 tekens zijn.

🤝 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 OFFERTEAANVRAAG (AX)/KREDIETAANVRAAG (KX)/ LEVENAANVRAAG (LX)/ 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 OFFERTEAANVRAAG (AX)/KREDIETAANVRAAG (KX)LEVENAANVRAAG (LX) /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 DOC.AANVRAAGBERICHT (DA), OFFERTE (OX)en 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 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 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 DOCUMENTBERICHT (DX) te versturen als reactie te versturen op een DOC.AANVRAAGBERICHT (DA) met een verouderde requestVersion. Om documenten te versturen is een 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 messageTypeOFFERTEAANVRAAG (AX)/KREDIETAANVRAAG (KX)/ WAARBORGBERICHT (WX)/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 DOCUMENTBERICHT (DX) te versturen als reactie te versturen op een DOC.AANVRAAGBERICHT (DA) met een verouderde requestVersion. Om documenten te versturen is een 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 messageTypeOFFERTEAANVRAAG (AX)/KREDIETAANVRAAG (KX)/ WAARBORGBERICHT (WX)/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 DOCUMENTBERICHT (DX) te versturen als reactie op een DOC.AANVRAAGBERICHT (DA) met een verouderde requestVersion. Om documenten te versturen woordt gewacht op een 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 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 STATUSMELDING (SX) versturen.

    1. Deze STATUSMELDING (SX) moet de volgende informatie bevatten:

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

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

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

      4. In geval van 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 aanvragen ) of wanneer de aanbieder in het geheel geen gewijzigde aanvragen ondersteunt.

    2. In de //StatusTekstRegels/ entiteit van deze 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 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 eenDOCUMENTBERICHT (DX) te sturen. Dit kan pas weer als er een nieuw 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.

  • Geen labels