B0780 - Creatiedatum, mutatiedatum en indiendatum worden niet vastgelegd.

Besluit

Naar aanleiding van het onderstaande vraagstuk is besloten om de genoemde datum-velden niet op te nemen. Dit wordt in issue #5 nader toegelicht voor het verzoek en is in het algemeen gebaseerd op het besluit in B8694

Vraagstuk

In issue #5 wordt de suggestie gedaan om bij verzoeken een creatiedatum, mutatiedatum en indiendatum vast te leggen.

Deze oude issue kan vertaald worden naar de vraag of deze datums bij een klantcontact moeten worden vastgelegd. Nu zijn er in het klantcontavt een registratiedatum (vergelijkbaar met een creatiedatum) en een datum plaatsgevonden (vergelijkbaar met een indiendatum) opgenomen.

Is het gewenst en nodig om de mutatiedatum op te nemen bij een klantcontact. Het karakter van het klantdontact is dat het niet gewijzigd wordt. Er kan echter een reden zijn om één (of meerdere) correcties door te voeren.

  • Wat is het functionele belang van vastleggen van de mutatiedatum (of beter correctiedatum)?
  • Heb je het dan alleen over de laatste correctiedatum?
  • Is de correctie zelf dan ook van belang?
  • Hier komen veel meer vragen rondom historie bij kijken

Als een klantcontact vastgelegd is door een medewerker en (bv na het direct doorverbinden) daarna wordt aangepast door een 2e medewerker dan is dat weliswaar technsch een mutatie, maar functioneel betreft het één klantcontact. In dit geval is er geen noodzaak om een mutatiedatum vast te leggen.

Voorbeeld: De relatie tussen een klantcontact en een partij wordt (via de klantcontactBetrokkene) gelegd op basis van de ID. Stel dat ik het klantcontact en de gerelateerde klantcontactBetrokkene heb opgevraagd, dan heb ik de ID van de gerelateerde partij tot mijn beschikking. Ik kan echter volgens beschrijving F0138 - Vraag partij op niet de ID gebruiken om de betreffende partij op te halen.

Ik snap dat er vanuit de gebruiker behoefte is om op basis van het nummer of de externe identificatie een partij te kunnen vinden, maar dat is technisch gezien in mijn beleving een zoek-functie en geen opvraag functie.

Uiteraard geldt dit vraagstuk niet alleen voor de partij, maar voor de architectuur van de hele API.