feat: nationaliteit op peildatum #85
Conversation
| Scenario: actueel en ongewijzigde nationaliteit | ||
| Gegeven de ingeschreven persoon met burgerservicenummer 000009830 kent de volgende nationaliteiten: | ||
| | Stapel | Categorie | nationaliteit (05.10) | reden opnemen (63.10) | reden beëindigen (64.10) | bijzonder Nederlanderschap (65.10) | onjuist (84.10) | datum ingang geldigheid (85.10) | | ||
| | 1 | 4 | 0001 | 001 | | | | 19750707 | | ||
| Als de nationaliteithistorie met burgerservicenummer 000009830 wordt geraadpleegd | ||
| Dan bevat het nationaliteithistorie-item met nationaliteit.code "0001" het gegeven "datumIngangGeldigheid" met datum "1975-07-07" | ||
|
|
||
| # Vervangt bovenstaande scenario | ||
| # kolommen zijn weggelaten die niet toedoen of niet relevant zijn voor deze scenario. Bijv. stapel, categorie, reden opnemen en lege velden | ||
| # wat wordt bedoeld met actueel? |
There was a problem hiding this comment.
Op dit moment (van raadplegen)
| # wat wordt bedoeld met actueel? | ||
| # Wat wordt bedoeld met ongewijzigd? Wordt 'geen historische gegevens' bedoeld? | ||
| # zou in dit geval 'persoon heeft op peildatum een nationaliteit zonder historische gegevens' geen betere titel zijn? | ||
| # in de response is 'nationaliteiten' gebruikt als veld naam ipv nationaliteitHistorie zoals gespecificeerd in de OAS |
There was a problem hiding this comment.
wat wordt hiermee bedoeld? Moet de OAS worden aangepast?
|
|
||
| # Vervangt bovenstaande scenario | ||
| # hier is categorie wel toegevoegd om te weten welke datum ingang geldigheid actueel is en welke historisch | ||
| # vraag: niet duidelijk of het relevant is om de onjuist kolom op te nemen in de historische rij. Voor het bepalen van de gegevens die voor de nationaliteit moet worden geretourneerd lijkt het niet relevant |
There was a problem hiding this comment.
Eens, dit is formele historie en niet relevant.
| | fields | nationaliteiten.nationaliteit.code,nationaliteiten.datumIngangGeldigheid | | ||
| Dan heeft de response de volgende 'nationaliteiten' | ||
| | type | nationaliteit.code | datumIngangGeldigheid.type | datumIngangGeldigheid.datum | datumIngangGeldigheid.langFormaat | | ||
| | Nationaliteit | 0100 | Datum | 2020-07-27 | 27 juli 2020 | |
There was a problem hiding this comment.
Ik kan mij voorstellen dat de vraag ontstaat of er nu twee voorkomens van de nationaliteit moeten worden getoond als wordt bevraagd met periode van 20200712 tot 20200731.
| | type | nationaliteit.code | datumIngangGeldigheid.type | datumIngangGeldigheid.datum | datumIngangGeldigheid.langFormaat | datumTot.type | datumTot.datum | datumTot.langFormaat | | ||
| | Nationaliteit | 0131 | Datum | 1975-05-01 | 1 mei 1975 | Datum | 2005-01-31 | 31 januari 2005 | | ||
|
|
||
| # indicatieNationaliteitBeeindigd komt niet voor in de OAS. Is dit nog nodig? | ||
| Rule: In het antwoord wordt indicatieNationaliteitBeeindigd opgenomen met de waarde true, wanneer in de actuele nationaliteit (categorie 04) GEEN nationaliteit (05.10) en GEEN bijzonder Nederlanderschap (65.10) is opgenomen. |
There was a problem hiding this comment.
ik begrijp de regel niet goed. Bespreken in overleg.
|
@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. |
| | type | RaadpleegMetPeildatum | | ||
| | burgerservicenummer | 000009830 | | ||
| | peildatum | <peildatum> | | ||
| | fields | nationaliteiten.nationaliteit.code,nationaliteiten.nationaliteit.datumIngangGeldigheid | |
There was a problem hiding this comment.
moet dit voor datumIngangGeldigheid niet zijn nationaliteiten.datumIngangGeldigheid? Dus zonder "nationaliteit" ertussen.
|
@KayodeBakker @MelvLee @JohanBoer @melsk-r @CathyDingemanse ik heb een feature toegevoegd voor het vullen van de gegevens van een nationaliteit |
| Als consumer van de BRP | ||
| Wil ik de nationaliteiten van een persoon met alle geldige gegevens | ||
|
|
||
| In de bron worden gegevens over een nationaliteit of bijzonder Nederlanderschap opgeslagen in één categorievoorkomen met de actuele gegevens (categorie 4) en optioneel in een of meerdere categorievoorkomens met "historische" gegevens (categorie 54). |
There was a problem hiding this comment.
Ik weet niet of het duidelijk is hoe de actuele en historische gegevens in de Gegeven stappen wordt beschrijven. Is het niet beter om aan te geven dat in de tabel van een Gegeven stap de eerste rij de actuele gegevens bevat en de andere rijen de historische gegevens?
There was a problem hiding this comment.
Dat kan, maar dan moet je in de Gegeven stappen bij meerdere nationaliteiten (met eventuele historie) per nationaliteit een aparte Gegeven stap maken.
Het lijkt mij ook goed om dit dan te beschrijven in de feature zelf (een soort readme aan het begin van de feature. (edit: laatste zin te snel getypt. Zie nu dat dat netjes is beschreven)
There was a problem hiding this comment.
Ik denk dat je bij meerdere nationaliteiten inderdaad voor elke nationaliteit een aparte Gegeven stap moet maken. Anders is niet duidelijk dat het een andere nationaliteit betreft en niet een wijziging/correctie op dezelfde nationaliteit
There was a problem hiding this comment.
Ik zal in de features een toelichting toevoegen over de volgorde in de Gegeven stappen
| Scenario: persoon heeft een niet-beëindigde nationaliteit | ||
| Gegeven de persoon met burgerservicenummer '000009830' heeft een 'nationaliteit' met de volgende gegevens | ||
| | nationaliteit (05.10) | reden opnemen (63.10) | datum ingang geldigheid (85.10) | | ||
| | 0001 | 001 | 19750707 | | ||
| Als nationaliteithistorie wordt geraadpleegd met de volgende parameters | ||
| | naam | waarde | | ||
| | type | RaadpleegMetPeildatum | | ||
| | burgerservicenummer | 000009830 | | ||
| | peildatum | 2022-08-16 | | ||
| | fields | nationaliteiten.nationaliteit.code,nationaliteiten.redenOpname.code,nationaliteiten.datumIngangGeldigheid | | ||
| Dan heeft de response de volgende 'nationaliteiten' | ||
| | type | nationaliteit.code | redenOpname.code | datumIngangGeldigheid.type | datumIngangGeldigheid.datum | datumIngangGeldigheid.langFormaat | | ||
| | Nationaliteit | 0001 | 001 | Datum | 1975-07-07 | 7 juli 1975 | | ||
|
|
There was a problem hiding this comment.
Is het niet beter om in de dev scenario's maar één veld tegelijk te valideren? Nu kan deze scenario om drie redenen falen, namelijk 'nationaliteit' en/of 'reden opnemen' en/of 'datum ingang geldigheid' worden niet goed gemapt. Deze scenario kan je als volgt beschrijven:
Abstract Scenario: persoon heeft een niet-beëindigde nationaliteit
Gegeven de persoon met burgerservicenummer '000009830' heeft een 'nationaliteit' met de volgende gegevens
| nationaliteit (05.10) | reden opnemen (63.10) | datum ingang geldigheid (85.10) |
| 0001 | 001 | 19750707 |
Als nationaliteithistorie wordt geraadpleegd met de volgende parameters
| naam | waarde |
| type | RaadpleegMetPeildatum |
| burgerservicenummer | 000009830 |
| peildatum | 2022-08-16 |
| fields | <field> |
Dan heeft de response de volgende 'nationaliteiten'
| type | <naam> |
| Nationaliteit | <waarde> |
Voorbeelden:
| field | naam | waarde |
| nationaliteiten.nationaliteit.code | nationaliteit.code | 0001 |
| nationaliteiten.redenOpname.code | redenOpname.code | 001 |
Scenario: persoon heeft een niet-beëindigde nationaliteit
Gegeven de persoon met burgerservicenummer '000009830' heeft een 'nationaliteit' met de volgende gegevens
| nationaliteit (05.10) | reden opnemen (63.10) | datum ingang geldigheid (85.10) |
| 0001 | 001 | 19750707 |
Als nationaliteithistorie wordt geraadpleegd met de volgende parameters
| naam | waarde |
| type | RaadpleegMetPeildatum |
| burgerservicenummer | 000009830 |
| peildatum | 2022-08-16 |
| fields | nationaliteiten.datumIngangGeldigheid |
Dan heeft de response de volgende 'nationaliteiten'
| type | datumIngangGeldigheid.type | datumIngangGeldigheid.datum | datumIngangGeldigheid.langFormaat |
| Nationaliteit | Datum | 1975-07-07 | 7 juli 1975 |
There was a problem hiding this comment.
Ik zit waarschijnlijk niet in de doelgroep voor deze vraag, maar waarom is dat beter ? Heeft dat met geautomatiseerd testen te maken ? Ik wil niet zozeer een discussie starten, maar het vooral begrijpen. Als dat teveel effort kost, gewoon mag je deze opmerking ook negeren.
There was a problem hiding this comment.
ik ben nog verder gegaan en heb per veld een eigen feature gemaakt. Dan kan het ook per veld geïmplementeerd en getest worden.
There was a problem hiding this comment.
Ik zit waarschijnlijk niet in de doelgroep voor deze vraag, maar waarom is dat beter ? Heeft dat met geautomatiseerd testen te maken ? Ik wil niet zozeer een discussie starten, maar het vooral begrijpen. Als dat teveel effort kost, gewoon mag je deze opmerking ook negeren.
In de scenario worden meerdere velden gevalideerd. Als de scenario faalt, moet er worden uitgezocht (ook al is het minimale check) bij welke van de velden het fout gaat en wat eigenlijk de fout veroorzaakt. Is het de mapping? Of de parameters in de Als stap? Wordt er maar één veld gevraagd en gevalideerd, dan is sneller te zien waar de fout zit.
| | fields | nationaliteiten.nationaliteit.code,nationaliteiten.redenOpname.code,nationaliteiten.datumIngangGeldigheid | | ||
| Dan heeft de response de volgende 'nationaliteiten' | ||
| | type | nationaliteit.code | redenOpname.code | datumIngangGeldigheid.type | datumIngangGeldigheid.datum | datumIngangGeldigheid.langFormaat | | ||
| | Nationaliteit | 0131 | 301 | Datum | 1975-05-01 | 1 mei 1975 | |
There was a problem hiding this comment.
Wat vinden jullie ervan om deze scenario als volgt te schrijven?
Scenario: verlies bijzonder Nederlanderschap
Gegeven de persoon met burgerservicenummer '555550001' heeft een 'nationaliteit' met de volgende gegevens
| bijzonder Nederlanderschap (65.10) | reden opnemen (63.10) | datum ingang geldigheid (85.10) |
| B | 310 | 20010319 |
En de 'nationaliteit' is bewijzigd met de volgende gegevens
| reden beëindigen (64.10) | datum ingang geldigheid (85.10) |
| 410 | 20190604 |
Als nationaliteithistorie wordt geraadpleegd met de volgende parameters
| naam | waarde |
| type | RaadpleegMetPeriode |
| burgerservicenummer | 555550001 |
| peildatum | 2018-01-01 |
| fields | nationaliteiten.redenOpname.code,nationaliteiten.datumIngangGeldigheid |
Dan heeft de response de volgende 'nationaliteiten'
| type | redenOpname.code | datumIngangGeldigheid.type | datumIngangGeldigheid.datum | datumIngangGeldigheid.langFormaat |
| BehandeldAlsNederlander | 310 | Datum | 2001-03-19 | 19 maart 2001 |
Ik denk dat dit veel duidelijker beschrijft wat een beëindigde nationaliteit is/hoe een beëindigde nationaliteit tot stand is gekomen. En omdat het een betere functionele beschrijving is (geen impliciete aannames) kan deze scenario verhuizen van dev naar de functionele specs
There was a problem hiding this comment.
Ik snap ze allebei. Wat mij betreft geen voorkeur.Misschien een semantisch zeurvraagje, maar is de 'nationaliteit' gewijzigd met de volgende gegevens of is de 'nationaliteit' beeindigd met de volgende gegevens...
There was a problem hiding this comment.
@MelvLee ik heb ook situaties met meerdere wijzigingen (op verschillende momenten) op dezelfde nationaliteit. Wil je dan voor elke wijziging een aparte Gegeven stap?
Ik ben het met je eens dat dit inderdaad duidelijker is. Wordt wel een lang verhaal bij meerdere nationaliteiten met elk wijzigingen.
Gegeven de persoon met burgerservicenummer '555550001' heeft een 'nationaliteit' met de volgende gegevens
| nationaliteit (05.10) | reden opnemen (63.10) | reden beëindigen (64.10) | onjuist (84.10) | datum ingang geldigheid (85.10) |
| 0131 | 301 | | | 20210604 |
| | | 404 | | 20190516 |
| 0131 | 301 | | | 20010319 |
En de persoon met burgerservicenummer '555550001' heeft een 'nationaliteit' met de volgende gegevens
| nationaliteit (05.10) | reden opnemen (63.10) | reden beëindigen (64.10) | onjuist (84.10) | datum ingang geldigheid (85.10) |
| | | 192 | | 20210604 |
| 0001 | 017 | | | 20190516 |
wordt dan:
Gegeven de persoon met burgerservicenummer '555550001' heeft een 'nationaliteit' met de volgende gegevens
| nationaliteit (05.10) | reden opnemen (63.10) |datum ingang geldigheid (85.10) |
| 0131 | 301 |20010319 |
En de 'nationaliteit' is gewijzigd met de volgende gegevens
| reden beëindigen (64.10) | datum ingang geldigheid (85.10) |
| 404 | 20190516 |
En de 'nationaliteit' is gewijzigd met de volgende gegevens
| nationaliteit (05.10) | reden opnemen (63.10) | datum ingang geldigheid (85.10) |
| 0131 | 301 | 20210604 |
En de persoon met burgerservicenummer '555550001' heeft een 'nationaliteit' met de volgende gegevens
| nationaliteit (05.10) | reden opnemen (63.10) | datum ingang geldigheid (85.10) |
| 0001 | 017 | 20190516 |
En de 'nationaliteit' is gewijzigd met de volgende gegevens
| reden beëindigen (64.10) | onjuist (84.10) | datum ingang geldigheid (85.10) |
| 192 | | 20210604 |
There was a problem hiding this comment.
de beschrijving zoals je voorstelt is m.i. duidelijker, maar bij meerdere wijzigingen wel minder overzichtelijk.
There was a problem hiding this comment.
Ik snap de onderste veel beter dan de bovenste. Ik ben inmiddels op de hoogte van de volgorde in de BRP, maar begrip van bovenste veronderstelt kennis van de BRP implementatie. De onderste is voor iedereen goed te begrijpen, of je nou BRP expert bent (RvIG) of niet. Daarnaast hoef je in de onderste niet uitsluitend gegevens te interpreteren om te bevatten wat er is gebeurd. Ik heb daarom een hele sterke voorkeur voor de onderste.
There was a problem hiding this comment.
Ik snap ze allebei. Wat mij betreft geen voorkeur.Misschien een semantisch zeurvraagje, maar is de 'nationaliteit' gewijzigd met de volgende gegevens of is de 'nationaliteit' beeindigd met de volgende gegevens...
Initieel zag de stap er ook als volgt uit: En de 'nationaliteit' is beëindigd met de volgende gegevens. Maar ik heb het veranderd naar gewijzigd (bewijzigd in dit geval), omdat ik zag dat in een ander scenario een beëindigd nationaliteit nog kan worden gewijzigd. Ik vond toen dat in dit geval wijzigen beter is dan beëindigen, maar het is zoals je aangeeft meer een semantische keuze.
There was a problem hiding this comment.
de beschrijving zoals je voorstelt is m.i. duidelijker, maar bij meerdere wijzigingen wel minder overzichtelijk.
klopt, maar dat hangt dan ook af van de scenario. Wat wordt er met de scenario beschreven? Als het een edge case is, dan denk ik dat het makkelijker accepteren dat de scenario minder overzichtelijk is. Je zou ook een aparte gegeven stap kunnen definieren om een geval te specificeren, zodat het wel overzichtelijk wordt. Bijv.
Gegeven de persoon met burgerservicenummer '555550001' heeft een beëindigde 'nationaliteit' met datum ingang geldigheid '20190516' en datum tot '20210604'
Met deze stap wordt dan aangenomen dat het niet relevant is wat de nationaliteit, de opname reden en de reden van beëindigen zijn. Alleen de datums zijn relevant in de scenario
| | type | redenOpname.code | datumIngangGeldigheid.type | datumIngangGeldigheid.datum | datumIngangGeldigheid.langFormaat | | ||
| | BehandeldAlsNederlander | 310 | Datum | 2001-03-19 | 19 maart 2001 | | ||
|
|
||
| Scenario: persoon heeft een beëindigde nationaliteit met gecorrigeerde reden beëindigen |
There was a problem hiding this comment.
En deze scenario kan als volgt worden geschreven:
Scenario: persoon heeft een beëindigde nationaliteit met gecorrigeerde reden beëindigen
Gegeven de persoon met burgerservicenummer '999994657' heeft een 'nationaliteit' met de volgende gegevens
| nationaliteit (05.10) | reden opnemen (63.10) | datum ingang geldigheid (85.10) |
| 0100 | 301 | 19890301 |
En de 'nationaliteit' is gewijzigd met de volgende gegevens
| reden beëindigen (64.10) | datum ingang geldigheid (85.10) |
| 401 | 19940601 |
En de 'nationaliteit' is vervolgens gewijzigd met de volgende gegevens
| reden beëindigen (64.10) | datum ingang geldigheid (85.10) |
| 404 | 20140601 |
Als nationaliteithistorie wordt geraadpleegd met de volgende parameters
| naam | waarde |
| type | RaadpleegMetPeriode |
| burgerservicenummer | 999994657 |
| peildatum | 2000-01-01 |
| fields | nationaliteiten.nationaliteit.code,nationaliteiten.redenOpname.code,nationaliteiten.datumIngangGeldigheid |
Dan heeft de response de volgende 'nationaliteiten'
| type | nationaliteit.code | redenOpname.code | datumIngangGeldigheid.type | datumIngangGeldigheid.datum | datumIngangGeldigheid.langFormaat |
| Nationaliteit | 0100 | 301 | Datum | 1975-05-01 | 1 mei 1975 |
|
@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. 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 |
| | type | nationaliteit.code | redenBeeindigen.code | | ||
| | Nationaliteit | 0100 | 404 | | ||
| | type | redenBeeindigen.code | | ||
| | Nationaliteit | 404 | |
There was a problem hiding this comment.
Hier moet volgens mij de peildatum of het resultaat aangepast worden. Als de peildatum na 01-06-2022 ligt klopt het resultaat.
There was a problem hiding this comment.
na 01-06-2022 is er volgens dit testgeval helemaal geen nationaliteit meer, dus zou je die niet krijgen.
vraag hier is hoe we historie weergeven
- alleen gegevens tonen die op peildatum of in periode geldig waren,
- peildatum/periode bepaalt alleen welke nationaliteit je te zien krijgt, elke nationaliteit geleverd inclusief alles wat daarna aan die nationaliteit is gewijzigd.
Dat laatste is hoe het nu beschreven staat en ook in v1.3 in de features stond.
| situatie | leveren bij 1 | leveren bij 2 |
|---|---|---|
| peildatum ligt voor beëindigen | nationaliteit zonder redenBeeindigen en datumTot | nationaliteit inclusief redenBeeindigen en datumTot |
| peildatum ligt na beëindigen | geen nationaliteit | geen nationaliteit |
| periode ligt voor beëindigen | nationaliteit zonder redenBeeindigen en datumTot | nationaliteit inclusief redenBeeindigen en datumTot |
| periode ligt na beëindigen | geen nationaliteit | geen nationaliteit |
| einddatum ligt binnen periode | nationaliteit inclusief redenBeeindigen en datumTot | nationaliteit inclusief redenBeeindigen en datumTot |
There was a problem hiding this comment.
In neig met terugwerkende kracht naar 1. Heb je user stories er op na geslagen. Er is geen behoefte aan het leveren van een historische nationaliteit inclusief allen wat aan deze nationaliteit gewijzigd is.
Het gaat er alleen maar om: wat was op dat moment de situatie (en heeft iemand terecht of onterecht een uitkering, ondersteuning oid gekregen).
Volgens mij is je eerste voorstel duidelijker dan het alternatief. |
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? |
Interessant hoe dit zou moeten werken: |
Bij een correctie gebeuren er tegelijkertijd 2 dingen:
Bijvoorbeeld de nationaliteit wordt gecorrigeerd. Voor de correctie:
Na de correctie:
Ik stel voor dit te beschrijven als: |
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 |
…binnen gevraagde periode
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?