🤝 Ketenafspraak

...

Regel: Wanneer een partij een bericht met een nieuwe requestVersion heeft ontvangen mogen er geen nieuwe records met de oude requestVersion op het platform worden gezet.

• Er mag dus ook geen SX worden verstuurd met bijv. Aanvraag beëindigd.

Regel: Een partij dient bij te houden wat de laatste requestVersion is die hij succesvol op het platform heeft geplaatst: wanneer er berichten binnen komen met een lagere requestVersion, dan moeten deze genegeerd worden (genegeerd: = niet opgehaald worden?). Ze mogen dus ook niet worden doorgestuurd

...

Regel:

Probleem: wat als serviceprovider AX aanpast en daarmee versie 2 introduceert? dan kan adviespakket dit nooit weten, want die AX wordt nooit opgestuurd → mag dat?

Wijziging op lopende aanvragen verwerken als link

Vereisten voor rol 1 Softwarepakketten (voorkant)

Vereisten voor rol 1 Softwarepakketten (voorkant)

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

• 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 van de volgende messageType

  • AX OfferteAanvraag

  • KX KredietAanvraag

  • LX LevenAanvraag

• Het is verplicht de SX XX met daarin het veld XX te kunnen verwerken

• Wanneer er wordt gekozen om requestVersion te wijzigen moet de nieuwe waarde bepaald worden door de volgende informatie op te halen:

  1. De

  waarde in in het veld

  1. Verzenddatum (JSON naam) van de laatste SX XX die is binnen gekomen.

  Het

  1. De Verzenddatum (JSON naam) van het laatst verstuurde bericht van dezelfde messageType in het dossier.
     

• 1 hoger zijn dan de waarde van requestVersion gebaseerd op:

• Wanneer

• Het is alleen toegestaan een nieuwe requestVersion in een dossier te introduceren wanneer het messageType=AX, KX, LX of BX van zowel het eerste record als het nieuwe record.

  • Het is niet toegestaan om in een dossier waar een AX met requestVersion=1 is opgenomen een LX te plaatsen met requestVersion=2. Deze

Vereisten voor Rol 2: Tussenstations zonder aanpassingen

• 1. 
     

  Het

  1. Van a en b moet het nieuwste bericht gekozen worden. De nieuwe requestVersion moet dan als volgt worden berekend:

     1. In het geval de SX XX het laatste bericht is, moet de waarde in het veld XXX uit de SX XX worden opgehaald en worden verhoogd met 1.

     2. In het geval het laatst verstuurde bericht van dezelfde messageType de laatste is, moet de requestVersion van dat bericht worden verhoogd met 1.

• 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 XX ontvangen 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 DocumentBericht DX te versturen op een DA met een verouderde requestVersion. Om documenten te versturen moet gewacht worden op een DA met de nieuwe requestVersion.

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

• Het is verplicht een aanvraag met een requestversion > 1 te kunnen verwerken.

• 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 kan betekenen:

    • via SX XX ontvangen 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 DocumentBericht DX te versturen op een DA met een verouderde requestVersion. Om documenten te versturen moet gewacht worden op een DA met de nieuwe requestVersion.

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

• Het is verplicht een aanvraag met een requestversion > 1 te kunnen verwerken

• Wanneer er wordt gekozen om requestVersion te wijzigen moet de nieuwe waarde 1 hoger zijn dan de waarde van requestVersion in het laatst bekende bericht in dit dossier voor deze partij.

• Het is alleen toegestaan een nieuwe requestVersion in een dossier te introduceren wanneer het messageType=AX, KX, LX of BX van zowel het oorspronkelijke record als het nieuwe record.

Vereisten voor Rol 3: Tussenstations met aanpassingen

• Het is verplicht een aanvraag met een requestversion > 1 te kunnen verwerken

Vereisten voor Rol 4a: Aanbieder: Hypotheken/Verzekeren?

• Het is niet toegestaan de requestVersion te verhogenbepaald worden door de volgende informatie op te halen:

  1. De Verzenddatum (JSON naam) van de laatste SX XX die is binnen gekomen.

  2. De Verzenddatum (JSON naam) van het laatst verstuurde bericht van dezelfde messageType in het dossier.

  3. De Verzenddatum (JSON naam) van het laatst ontvangen bericht van dezelfde messageType in het dossier.

     
     Van a en b en c moet het nieuwste bericht gekozen worden. De nieuwe requestVersion moet dan als volgt worden berekend:

     1. In het geval de SX XX het laatste bericht is, moet de waarde in het veld XXX uit de SX XX worden opgehaald en worden verhoogd met 1.

     2. In het geval het laatst verstuurde bericht van dezelfde messageType de laatste is, moet de requestVersion van dat bericht worden verhoogd met 1.

     3. In het geval het laatst ontvangen bericht van dezelfde messageType de laatste is, moet de requestVersion van dat bericht worden verhoogd met 1.
        wat als deze onterecht nog 1 is… → indien

• Wanneer er een nieuwe requestVersion wordt geïntroduceerd is het verplicht dit aan rol 1 en rol 2 te laten weten. Dit moet gedaan worden door een SX XX te versturen naar deze partij met daarin in het veld XX de waarde van de nieuwe requestVersion.

  • De requestVersion die opgevoerd wordt bij deze SX is de oude requestVersion

  • Het geldt dus niet als Rol 1 of Rol 2 deze requestVersion heeft geïntroduceerd.

• 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 XX ontvangen of

    • 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 DocumentBericht DX te versturen op een DA met een verouderde requestVersion. Om documenten te versturen moet gewacht worden op een 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 DocumentBericht (DX)) naar Rol 4 te versturen.

Vereisten voor Rol 4: Aanbieder

...

• 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 (verwerken hoeft niet )

• Wanneer een aanbieder niet om kan gaan met een hogere versie moet de volgende SX worden teruggestuurd.

• Mag niet zelf ophogen

Aanleiding en achtergrond

• SX) verstuurt worden:

  • In geval van een binnenkomende OfferteAanvraag (AX)

    • StatusAXBerichtType moet gevuld zijn met 14 Offerteaanvraag niet te verwerken, zie toelichting

    • In de tekstregels moet zijn opgenomen dat de genoemde requestVersion niet wordt ondersteund.

    • De requestVersion van dit bericht moet de requestVersion bevatten van het binnenkomende bericht.

  • In geval van een een binnenkomende LevenAanvraag:

    • StatusLXBerichtType moet gevuld zijn met 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 de requestVersion bevatten van het binnenkomende bericht.

  • In geval van een binnenkomende KredietAanvraag:

    • StatusKXBerichtType moet gevuld zijn met 03 Kredietaanvraag niet te verwerken, zie toelichting

    • In de tekstregels moet zijn opgenomen dat de ingestuurde requestVersion niet wordt ondersteund.

    • De requestVersion van dit bericht moet de requestVersion bevatten van het binnenkomende bericht.

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

• 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 XX ontvangen of

    • een bericht met daarin de nieuwe requestVersion ontvangen te hebben of

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

  • 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 DocumentBerichten (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.

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