...
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
| Status |
|---|
| colour | Blue |
|---|
| title | Document (DX) |
|---|
|
er geen nieuwe requestVersion wordt geïntroduceerd.Het is niet toegestaan binnen een dossier twee maal een HDN-bericht van hetzelfde messageType, receiver, sender enrequestVersion op het platform te plaatsen.
Dit geldt alleen voor de volgende messageType
| Status |
|---|
| colour | Blue |
|---|
| title | OfferTeaanvraag (AX) |
|---|
|
/| Status |
|---|
| colour | Blue |
|---|
| title | KredietAanvraag (KX) |
|---|
|
| Status |
|---|
| colour | Blue |
|---|
| title | Levenaanvraag (lx) |
|---|
|
/| Status |
|---|
| colour | Blue |
|---|
| title | Waarborg WaarborgBERICHT (wx) |
|---|
|
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 één van de volgende messageType
| Status |
|---|
| colour | Blue |
|---|
| title | OfferTeaanvraag (AX) |
|---|
|
/| Status |
|---|
| colour | Blue |
|---|
| title | KredietAanvraag (KX) |
|---|
|
/ | Status |
|---|
| colour | Blue |
|---|
| title | Waarborg | Levenaanvraag (lx) |
|---|
|
/ | Status |
|---|
| colour | Blue |
|---|
| title | WaarborgBERICHT (wx) |
|---|
|
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.
Ter verduidelijking: dit kan een bericht zijn van elk messageType, dus ook
| Status |
|---|
| colour | Blue |
|---|
| title | Documentaanvraag (DA) |
|---|
|
, | Status |
|---|
| colour | Blue |
|---|
| title | Offerte (OX) |
|---|
|
en | Status |
|---|
| colour | Blue |
|---|
| title | StatusMelding (SX) |
|---|
|
. Zodoende kan de situatie worden ondersteund dat een HDN-bericht verderop in de keten wordt verhoogd en er daardoor meerdere keren dezelfde requestVersion wordt gemaakt.
Voorbeeld: Een adviespakket (rol 1) stuurt requestVersion=1 naar een serviceprovider (rol 3). Deze maakt een wijziging en introduceert requestVersion=2. De aanbieder stuurt daarop een | Status |
|---|
| colour | Blue |
|---|
| title | StatusMelding (SX) |
|---|
|
met requestVersion=2terug. De serviceprovider stuurt deze weer terug naar het adviespakket. Wanneer je in het adviespakket een nieuwe requestVersion wilt introduceren moet dit de waarde 3 hebben. Deze moet gebaseerd zijn het op het laatste bericht dat het adviespakket heeft ontvangen, de | Status |
|---|
| colour | Blue |
|---|
| title | StatusMelding (SX) |
|---|
|
(2) + 1=3Wanneer een nieuwe requestVersion bekend is bij de partij mag er niet meer gereageerd worden op berichten van de oude requestVersion.
Ter verduidelijking: Het is niet toegestaan nog een
| Status |
|---|
| colour | Blue |
|---|
| title | Document (DX) |
|---|
|
te versturen op een | Status |
|---|
| colour | Blue |
|---|
| title | Documentaanvraag (DA) |
|---|
|
met een verouderde requestVersion. Om documenten te versturen moet gewacht worden op een | Status |
|---|
| colour | Blue |
|---|
| title | Documentaanvraag (DA) |
|---|
|
met de nieuwe requestVersion.Uitzondering: Dit geldt niet indien de nieuwe requestVersion niet geaccepteerd is bij de aanbieder, zie daarvoor punt 3 bij Aanbieder. In dat geval mogen berichten met de oude versie worden blijven uitgewisseld.
Het is verplicht een bericht dat ontvangen wordt met een requestVersion die niet bekend is te verwerken.
Achtergrond: Deze regel is noodzakelijk omdat het mogelijk is dat ook rol 3 een nieuwe requestVersion kan introduceren. Daarmee kan in Rol 1 dus ook retourberichten ontvangen op een requestVersion die nog niet bekend is.
...