feat: nationaliteit op peildatum

[MelvLee]

rewrite van nationaliteithistorie.feature met als doel een betere beschrijving/documentatie van de nationaliteithistorie functionaliteit. Dit is dus een end-to-end beschrijving (dit staat in de BRP en dan is dit wat een consumer krijgt) en niet wat de proxy api en wat de rvig api moet teruggeven.

Waarom is datumTot als veldnaam gekozen? Is datumEindeGeldigheid geen betere naam?

[fsamwel]

@melsk-r heeft in #80, #81 en #83 een voorstel gedaan waarbij de features van een eindpoint in een mapje komen en per functionaliteit (zoals periode filtering of sortering) een feature wordt gemaakt. Dat lijkt mij een goed idee, want dan kunnen we het ook per functionaliteit bouwen en testen. Bijkomend voordeel is dat voor een eindgebruiker bijvoorbeeld periodefiltering wel interessant is, en de manier waarop uit de bron de gegevens worden verzameld niet (dat is meer technische documentatie).

[fsamwel]

@KayodeBakker @MelvLee @JohanBoer @melsk-r @CathyDingemanse ik heb een feature toegevoegd voor het vullen van de gegevens van een nationaliteit

[fsamwel]

@MelvLee @CathyDingemanse @JohanBoer ik heb in een feature een situatie waarin een eerder geregistreerde wijziging onjuist wordt gezet. Dit (onjuist) is de enige situatie waarin een eerder geregistreerd voorkomen wordt gewijzigd zonder dat er hiervoor een nieuw voorkomen voor wordt gemaakt. Hoe geven we dit aan in de feature?

Ik stel voor een andere Gegeven stap definitie voor onjuist maken: "En de vorige wijziging van 'nationaliteit' is onjuist en gecorrigeerd met de volgende gegevens": automation code moet uit "onjuist en gecorrigeerd" weten dat vorige voorkomen onjuist is geworden.

Alternatief is bij "En de 'nationaliteit' is gewijzigd met de volgende gegevens" direct onjuist opnemen: suggereert dat dit vanaf de eerste wijziging/registratie direct onjuist was, terwijl het onjuist maken gebeurt is tegelijk met de volgende wijziging

[JohanBoer]

@MelvLee @CathyDingemanse @JohanBoer ik heb in een feature een situatie waarin een eerder geregistreerde wijziging onjuist wordt gezet. Dit (onjuist) is de enige situatie waarin een eerder geregistreerd voorkomen wordt gewijzigd zonder dat er hiervoor een nieuw voorkomen voor wordt gemaakt. Hoe geven we dit aan in de feature?

Ik stel voor een andere Gegeven stap definitie voor onjuist maken: "En de vorige wijziging van 'nationaliteit' is onjuist en gecorrigeerd met de volgende gegevens": automation code moet uit "onjuist en gecorrigeerd" weten dat vorige voorkomen onjuist is geworden.

Alternatief is bij "En de 'nationaliteit' is gewijzigd met de volgende gegevens" direct onjuist opnemen: suggereert dat dit vanaf de eerste wijziging/registratie direct onjuist was, terwijl het onjuist maken gebeurt is tegelijk met de volgende wijziging

Volgens mij is je eerste voorstel duidelijker dan het alternatief.

[MelvLee]

@MelvLee @CathyDingemanse @JohanBoer ik heb in een feature een situatie waarin een eerder geregistreerde wijziging onjuist wordt gezet. Dit (onjuist) is de enige situatie waarin een eerder geregistreerd voorkomen wordt gewijzigd zonder dat er hiervoor een nieuw voorkomen voor wordt gemaakt. Hoe geven we dit aan in de feature?

Ik stel voor een andere Gegeven stap definitie voor onjuist maken: "En de vorige wijziging van 'nationaliteit' is onjuist en gecorrigeerd met de volgende gegevens": automation code moet uit "onjuist en gecorrigeerd" weten dat vorige voorkomen onjuist is geworden.

Alternatief is bij "En de 'nationaliteit' is gewijzigd met de volgende gegevens" direct onjuist opnemen: suggereert dat dit vanaf de eerste wijziging/registratie direct onjuist was, terwijl het onjuist maken gebeurt is tegelijk met de volgende wijziging

Ik weet niet of ik het helemaal goed begrijp, maar zegt je dat een correctie de update is van de rij met volg_nr 0? En niet een insert van een nieuwe rij?

[CathyDingemanse]

@MelvLee @CathyDingemanse @JohanBoer ik heb in een feature een situatie waarin een eerder geregistreerde wijziging onjuist wordt gezet. Dit (onjuist) is de enige situatie waarin een eerder geregistreerd voorkomen wordt gewijzigd zonder dat er hiervoor een nieuw voorkomen voor wordt gemaakt. Hoe geven we dit aan in de feature?

Ik stel voor een andere Gegeven stap definitie voor onjuist maken: "En de vorige wijziging van 'nationaliteit' is onjuist en gecorrigeerd met de volgende gegevens": automation code moet uit "onjuist en gecorrigeerd" weten dat vorige voorkomen onjuist is geworden.

Alternatief is bij "En de 'nationaliteit' is gewijzigd met de volgende gegevens" direct onjuist opnemen: suggereert dat dit vanaf de eerste wijziging/registratie direct onjuist was, terwijl het onjuist maken gebeurt is tegelijk met de volgende wijziging

Interessant hoe dit zou moeten werken: In het raadpleegmodel zou het onjuiste voorkomen niet meer moeten voorkomen, en wordt het overschreven met het juiste voorkomen. In het registratiemodel is het onjuiste voorkomen nog wel zichtbaar. De vraag is: hoe doe je dat?

[fsamwel]

Ik weet niet of ik het helemaal goed begrijp, maar zegt je dat een correctie de update is van de rij met volg_nr 0? En niet een insert van een nieuwe rij?

Bij een correctie gebeuren er tegelijkertijd 2 dingen:

1. de actuele rij wordt historisch EN krijgt indicatie onjuist
2. er wordt een nieuw actueel voorkomen toegevoegd met de juiste gegevens

Bijvoorbeeld de nationaliteit wordt gecorrigeerd.

Voor de correctie:	Volgnr	nationaliteit (05.10)	datum ingang geldigheid (85.10)	Onjuist
0	0400	20210516

Na de correctie:	Volgnr	nationaliteit (05.10)	datum ingang geldigheid (85.10)	Onjuist
0	0071	20210516
1	0400	20210516	O

Ik stel voor dit te beschrijven als:

      Gegeven de persoon met burgerservicenummer '000000127' heeft een 'nationaliteit' met de volgende gegevens
      | nationaliteit (05.10) | datum ingang geldigheid (85.10) |
      | 0400                  | 20210516                        |
      En de vorige wijziging  van 'nationaliteit' is onjuist en gecorrigeerd met de volgende gegevens
      | nationaliteit (05.10) | datum ingang geldigheid (85.10) |
      | 0071                 | 20210516                        |

[MelvLee]

Ik weet niet of ik het helemaal goed begrijp, maar zegt je dat een correctie de update is van de rij met volg_nr 0? En niet een insert van een nieuwe rij?

Bij een correctie gebeuren er tegelijkertijd 2 dingen:

1. de actuele rij wordt historisch EN krijgt indicatie onjuist

2. er wordt een nieuw actueel voorkomen toegevoegd met de juiste gegevens

Bijvoorbeeld de nationaliteit wordt gecorrigeerd.

Voor de correctie: Volgnr nationaliteit (05.10) datum ingang geldigheid (85.10) Onjuist 0 0400 20210516

Na de correctie: Volgnr nationaliteit (05.10) datum ingang geldigheid (85.10) Onjuist 0 0071 20210516
1 0400 20210516 O

Ik stel voor dit te beschrijven als:

      Gegeven de persoon met burgerservicenummer '000000127' heeft een 'nationaliteit' met de volgende gegevens
      | nationaliteit (05.10) | datum ingang geldigheid (85.10) |
      | 0400                  | 20210516                        |
      En de vorige wijziging  van 'nationaliteit' is onjuist en gecorrigeerd met de volgende gegevens
      | nationaliteit (05.10) | datum ingang geldigheid (85.10) |
      | 0071                 | 20210516                        |

Ok. Nu begrijp ik het. Jouw voorstel is wat mij betreft akkoord, maar ik zou het nog simpeler maken. Volgens mij volsta je al met En de 'nationaliteit' is gecorrigeerd met de volgende gegevens. In de en de 'nationaliteit' is gewijzigd met de volgende gegevens stap worden volg_nrs gewijzigd en dat wordt niet expliciet in de stap benoemd. Dus zou ik het in de correctie stap ook niet doen.