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

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

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 , en . 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 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 (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 te versturen als reactie te versturen op een met een verouderde requestVersion. Om documenten te versturen is een 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 messageType// /.

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 te versturen als reactie te versturen op een met een verouderde requestVersion. Om documenten te versturen is een 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 messageType// /.

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 te versturen als reactie op een met een verouderde requestVersion. Om documenten te versturen woordt gewacht op een 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 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 versturen.

   1. Deze moet de volgende informatie bevatten:

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

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

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

      4. In geval van : //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 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 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 een te sturen. Dit kan pas weer als er een nieuw 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