🤝 Ketenafspraak

Vereisten voor Rol 1: Softwarepakketten (voorkant), Rol 3: Tussenstations met aanpassingen, Rol 5: Intermediair

1. Bij het versturen van een OFFERTEAANVRAAG (AX), LEVENAANVRAAG (LX) ofKREDIETAANVRAAG (KX)met een requestVersion > 1 (in de Json) of //Header/AanvraagVersie>1) is het niet toegestaan de volgende velden te wijzigen tov het bericht waar requestVersion met 1 gevuld is:

   1. ReceiverCode (in de Json)/ //Header/OntvangerCode,

   2. //Tussenpersoon//TussenpersoonNr.

      1. Voor Rol 3: Tussenstations met aanpassingen: Een uitzondering hierop is de aanpassing die in KET-001: Het doorgeven van intermediair en serviceprovider informatie en wijzigingen door tussenstations staat beschreven.

2. Wanneer een STATUSMELDING (SX) is ontvangen waarin het veld //Status/AXBerichtSpecificatie//StatusAXBericht is gevuld met de waarde SX23 Bindende offerte verzonden is het niet toegestaan een nieuwe OFFERTEAANVRAAG (AX) te versturen

   1. waarin de gegevens in de entiteit //Object/ afwijken t.o.v. de eerder verstuurde OFFERTEAANVRAAG (AX),

   2. waarin de waarde van het veld //Lening/CodeLeningMijafwijkt t.o.v. de eerder verstuurde OFFERTEAANVRAAG (AX).
      

Aanleiding en achtergrond

In de keten is behoefte om gewijzigde aanvragen te ondersteunen. Echter, er zit wel een beperking op wat inhoudelijk mag wijzigen. Dit kan ook gedurende het proces wijzigen. Door hierover eenduidige afspraken te maken, scheppen we duidelijkheidwelke wijzigingen (automatisch) door de aanbieder moeten worden verwerkt (en waarvoor het intermediair dus een wijziging kan doorvoeren op het bestaande dossier) en in welke gevallen de aanbieder een geheel nieuwe aanvraag wenst (en de adviseur hiervoor ook in zijn pakket voor een nieuwe aanvraag moet kunnen kiezen). Hierdoor scheppen we helderheid in wat adviseur en aanbieder van elkaar verwachten, verminderen we de uitval en het aantal dubbele aanvragen.

Versiegeschiedenis