Contactgegegevens tonen uit de klantenregisters

[sytskevanhasselt]

Description

Als er meerdere klant registers zijn, wil ik de contactgegevens uit het default register tonen. Wanneer daar geen contactgegevens instaan wil ik de gegevens uit het fallback register zien.

Estimate

No response

Acceptance criteria

• Via een environment variabele stel je in welk register het default register is voor contactgegevens.
• Als er helemaal geen contactgegevens te vinden zijn voor die klant in het default register dan halen we contactgegevens op uit de andere registers. (we gaan ervan uit dat er in de praktijk niet meer dan twee registers gebruikt zullen worden. voor de uitzonderlijke situatie dat het er meer zijn, maken we het voor nu maar zo dat je een voor een de regeisers afgaat en stopt tot je ergens contactgegevens gevonden hebt. de volgorde is onbepaald)

Specific details

in de praktijk zullen gemeentes esuite en daarnaast openklant gebruiken. in eerste instantie is openklant (het default register) leeg en zal alle info uit de estuite (het fallback register) komen. Van de contactgegevens die in openklant komen mag je uitgaan dat die nieuw en recent zijn. dus als er wel iets in openklant staat dan is dat leidend.
nb. met de geplande/gerealiseerde aanpassingen van oip en e-suite zullen contactgegevens die vanuit die systemen bewrkt worden, altijd in beide registers opgeslagen worden. meestal zullende gegevens dus gelijk zijn in beide registers, of in slechts een register aanwezig zijn.
nb. het gebruik van contactgegevens voor het automatisch invullen van terugbelverzoeken blijft ongewijzigd.
todo: story aanmaken om vanuit KISS te contactgegevens te syncen bij het opslaan van contactmomenten <-- doen. dit is wenselijk

----------------------------------------------------OUD niet verder lezen ----------------------------

VRAAG: bij KISS schrijven we deze story's niet beperkt op twee registers te weten OK2 en e-Suite, maar gaan we uit van één of meer gekoppeld klantregister. In hoeverre moeten we hier beperkingen instellen? In geval van e-Suite gaan we Contactgegevens uit Klanten API moeten gaan vergelijken met DigitaleAdressen-bij-een-Partij uit OpenKlant.

• We zoeken klanten primair via BRP of Handeslregister
• We zoeken in alle gekoppelde klantregisters naar bijbehorende contactgegevens.
• Deze contactgegevens moeten we vergelijken:
  • uit e-Suite komen terug: lanten.emailadres, klanten.telefoonnummer en klanten.telefoonnummerAlternatief
    • LET OP: in de Echte Klanten API staat maar 1 telnr en 1 e-mailadres. Het property klanten.telefoonnummerAlternatief is een e-Suite-specifieke uitbreiding: gaan we daar rekening meehouden?
  • uit OK2 kunnen 1 of meer digitaleAdressen terugkomen van de types telnr of email (NB: als Soorten digitaal adres aanpassen naar gebruik enums #891 nog niet is gedaan)
  • We hebben altijd maar 1 register dat Klanten API praat: we kunnen denk ik wel stellen dat we daarin alléén de e-Suite nog ondersteunen.
  • In hoeverre moeten we rekening houden met 1 of meer OK2-instanties?
• We tonen de digitale adressen uit het defaultregister. Digitale adressen die NIET in het defaultregister staan, markeren we. [nog uitwerken, hoe?]

nb. Meerdere registers met gegevens over dezelfde klant zorgt voor complicaties en zou altijd slechts een tijdelijke transitie situatie moeten zijn, met en visie op een oplossing, om tot 1 systeem te komen.

• route 1: klant in register A met contactgegevens en klant in register B zonder contactgegevens
  KISS zou hem dan automatisch de contactgegevens kunnen overzetten (maar alleen als je ook een klantcontact in dat register aanmaakt). Dit zou dan wel een aparte story worden
  voor het tonen/selecteren van contactgegevens in KISS hoeven we hiervoor niets te doen, je hebt maar 1 setje contactgegevens

• route 2: klant in register A met contactgegevens en klant niet in register B
  KISS zou hem dan automatisch aan kunnen maken en de contactgegevens overzetten (maar alleen als je ook een klantcontact in dat register aanmaakt) Dit zou dan wel een aparte story worden
  voor het tonen/selecteren van contactgegevens in KISS hoeven we hiervoor niets te doen, je hebt maar 1 setje contactgegevens

• route 3: klant in register A met contactgegevens en klant in register B met dezelfde contactgegevens
  Als KISS op de achtergrond ontdubbelt dan hoeft de KCM er niets van te merken. Die ziet/gebruikt gewoon 1 set contactgegevens.

• route 4: klant in register A met contactgegevens en klant in register B met (deels) andere contactgegevens
  Er is geen mogelijkheid om te bepalen welke gegevens juist/recenter zijn.
  We kunnen alles tonen in het klantbeeld, maar hoe bepalen we wat wordt gebruikt bij het aanmaken van een contactverzoek?
  -- We kunnen de KCM een selectie optie bieden, maar dat ondermijnt de convenience van het automatisch voorinvullen van het contactverzoek. (als er half overlappende sets zijn (telnr in A, email in B), dan zou er weer logica toegepast kunnen worden om automatische voorinvul keuzes te maken, maar maakt KISS wel extra complex en ontransparant)
  -- We kunnen een default afdwingen en alleen die gegevens tonen en/of gebruiken bij het voorinvullen van het contactverzoek

• route 4: klant niet in register A en klant niet in register B
  voor contactgegevens maakt dit niet uit. voor het aanmaken van de klant in dit geval is al een story

• route 5 er zijn meer dan 2 registers en meer dan twee verschillende setjes contactgegevens
  Is momenteel nog niet actueel. negeren we nog?

Schatting baseren op het gegven dat #862 als is gerealiseerd.

Test plan

No response

Delivery notes

No response

[sytskevanhasselt]

@mstokericatt
Uit overleg bij Dimpact is uiteindelijk gekomen, dat e-suite en openklant niet onderling gaan syncen, maar dat de Frontends (OIP en KISS) dit gaan handelen. Namelijk:

1. Frontend-applicatie haalt contactgegevens uit beide bronnen op
2. in 95 % van de gevallen zal hier een identieke set uitkomen.
3. Als het niet zo is, dan markeren we dat in de interface

• OIP: vraag het aan de ingelogde inwoner/ondernemer
• KISS: duidelijk maken aan ingelogde KCM, die dit aan de Klant kan terugkoppelen.

4. Klant kan bevestigen wat juist is
5. Frontend slaat de juiste set in beide bronnen op.

NB: dat laatste gebeurt momenteel alléén in OIP, omdat we de optie tot bewerken van contactgegevens in KISS uit hebben gezet. Maar er is gerede kans dat dit weer terugkomt.