Pas StUF-BG aan zodat nieuwe BRP-gegevens (Tijdelijk verblijfsadres en contactgegevens) meegestuurd kunnen worden #31
Comments
|
Dit onderhoudsverzoek is opgevoerd in de onderhoudsverzoeken als ONV0526. |
|
Ik neig er naar om dit onderhoudsverzoek op dezelfde wijze op te lossen als waarop we ONV0525 hebben opgelost. Het toevoegen van extraElementen aan zowel StUF-BG 2,04 als StUF-BG 3.01. M.b.t. tijdelijk verblijfadres
M.b.t. contactgegevens
Er vanuit gaand dat al deze gegevens ook geleverd mogen worden heb ik de volgende vragen:
|
|
Binnen de distributiesystemen kunnen we de verblijf gegevens in Nederland natuurlijk toevoegen maar dan is er wel de vraag welke afnemers dit gaan ondersteunen! |
|
Het alternatieve voorstel van Ton om het correspondentie adres en de bestaande elementen voor email adres en telefoonnummer te gebruiken spreekt ons (Centric) wel aan. Dit lijkt ons zeker een oplossingsrichting die de moeite van nader onderzoek waard is. |
|
Het voorstel van Ton spreekt ook mij aan. Veel beter dan een hele bups aan extraElementen introduceren. In eerste instantie had ik nog wel wat bedenkingen tegen het uitbreiden van de enumeratie van het element 'typering' zoals @rbruin voorstelt omdat dat een schema wijziging inhoudt en dus eigenlijk tot een nieuwe versie van StUF-BG zou moeten leiden. Tot ik in de patch historie van StUF-BG dook en zag dat in patch 25 de enumeratie van het element 'aanduidingInhoudingVermissing' is uitgebreid met de waarde 'R'. Als we het toen met een patch op hebben kunnen lossen dan moet dat nu ook kunnen. Ik stel wel voor om als nieuwe enumeratiewaarde niet 'Tijdelijk adres' maar 'Tijdelijk verblijfadres' te definiëren. Daarmee voorkomen we dat het element 'sub.correspondentieAdres' in de toekomst geïnterpreteerd wordt als 'Tijdelijk correspondentieadres'. extraElementenEr van uitgaand dat er niet een nog beter voorstel wordt geöpperd blijft mijn vraag staan voor welke van de gegevens een extraElement zou moeten worden opgenomen. Hieronder daarom wederom de lijst met gegevens maar nu ontdaan van de in 'sub.correspondentieAdres' reeds voorkomende elementen.
Wat betreft het gegeven 'Datum inschrijving in de gemeente' vraag ik me af of we daar niet van het al bestaande element 'inp.datumInschrijving' gebruik kunnen maken? In Onderzoek gegevensBlijven nog de volgende gegevens over:
Helaas kunnen we hier geen gebruik maken van het 'BG:inOnderzoek' element omdat de attributen 'groepsnaam' en 'elementnaam' vaste sets aan enumeraties bevatten. Tenzij we vinden dat we die enumeraties in 'StUF:NPSElementen' mogen aanpassen. Overigens denk ik dat het 'inOnderzoek' element helemaal niet bedoelt is voor gebruik met 'extraElementen' al kan ik een verbod daartoe niet in de StUF standaard vinden. Willen we dat toestaan dan moeten we n.m.m. in de StUF standaard opnemen dat dat is toegestaan maar ook de volgende zinnen op pagina 27 van de StUF standaard:
als volgt aanpassen:
Willen we de StUF standaard liever niet zoals hierboven beschreven aanpassen dan betekent dit dat de drie inOnderzoek gegevens eveneens als extraElement moeten worden gedefinieerd als we daarover willen kunnen beschikken. De vraag is dan of het extraElement 'Aanduiding gegevens in onderzoek' uit een array van waardes mag bestaan. Zo niet dan heeft dat tot gevolg dat we niet meerdere van de onder 1 en 2 genoemde gegevens tegelijkertijd op inOnderzoek kunnen zetten. |
|
Ik denk dat voordat we hier mee verder gaan, eerst moeten weten wie dit gaat gebruiken. Als distributiesysteem zijn wij een doorgeefluik van data. Ik wil wel graag weten wie de afnemers zijn van deze nieuwe gegevens voordat we dit gaan inbouwen. In mei komt onze productgroep van gebruikers weer bij elkaar. Daar zal ik dit onderwerp weer ter discussie stellen. Maar graag hoor ik ook hier van andere volgers hun opvattingen! Er is nog geen reactie op dit issue anders dan van PinkRoccade en Centric. |
|
Nee, jullie zijn tot noch toe de enigste die een reactie hebben gegeven. Ik heb nog wel contact gehad met Maarten vd Broek en hij gaf aan zich goed te kunnen vinden in jouw suggestie. Ik ga nog kijken hoe ik meer reacties kan genereren op dit issue. |
|
Overigens moeten we ook bepalen of we StUF-BG 2.04 ook moeten voorzien van mogelijkheden om een tijdelijk verblijfadres in het bericht op te nemen. Zo ja, dan zal dat op een geheel andere manier moeten als de hierboven geschetste wijze voor StUF-BG 3.10. |
|
Ik stel voor dat we StUF-BG 2.04 niet meer gaan aanpassen om deze functionaliteit te ondersteunen. |
|
We hebben nog steeds Bg0204 afnemers bij onze klanten. We moeten daarom eerst weten welke afnemers op deze gegevens zitten wachten!
From: rbruin ***@***.***>
Sent: donderdag 4 april 2024 17:22
To: VNG-Realisatie/StUF-Standaarden ***@***.***>
Cc: Timmermans, Ton ***@***.***>; Comment ***@***.***>
Subject: Re: [VNG-Realisatie/StUF-Standaarden] Pas StUF-BG aan zodat nieuwe BRP-gegevens (Tijdelijk verblijfsadres en contactgegevens) meegestuurd kunnen worden (Issue #31)
LET OP! Deze e-mail is afkomstig van buiten PinkRoccade. Controleer voor je doorklikt eerst of de afzender klopt en de bijlagen veilig zijn.
Ik stel voor dat we StUF-BG 2.04 niet meer gaan aanpassen om deze functionaliteit te ondersteunen.
—
Reply to this email directly, view it on GitHub<#31 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AC7RXDGHML6QYBK7HBFD7PDY3VVYFAVCNFSM6AAAAABFDA3E5KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZXGUYDIMBTHA>.
You are receiving this because you commented.Message ID: ***@***.******@***.***>>
|
|
Vanuit het sociaal domein, deel ik de voorkeur van Pink en Centric |
|
GouwIT heeft voorkeur voor het door Ton aangegeven alternatief (hergebruik correspondentie adres/email+telefoon velden). |
|
Vanuit Vicrea geven we de voorkeur aan de minst ingrijpende oplossing. Ik denk dat hergebruik van het correspondentieadres dan een logische is. Stuf 2.04 met rust laten heeft ook onze voorkeur. |
|
Gezien de bovenstaande reacties lijkt me de oplossingsrichting (voor StUF-BG 3.10) inmiddels wel duidelijk. Ik sta daarom in de startblokken om daar een patch voor te gaan vervaardigen waarmee dit issue wordt opgelost. De door Ton gestelde vraag die n.m.m. echter nog onvoldoende is beantwoord is:
Zoals Ton al aangeeft komt deze maand de productgroep van gebruikers van Pink Roccade weer bij elkaar waar hij dit onderwerp ter discussie zal stellen en ik neem aan dat dan ook duidelijk wordt of voor hen een patch op StUF-BG 2.04 noodzakelijk is. Het is echter fijn om ook van andere volgers te horen wie deze gegevens af zal gaan nemen. Daarom het verzoek aan eenieder om ook die vraag even te beantwoorden. Ik heb overigens begrepen dat inmiddels een flink aantal gemeenten geautoriseerd zijn voor deze gegevens, met name voor de toezicht- en handhavingstaken. |
|
Helaas heb ik geen feedback meer ontvangen van de productgroep of van andere partijen. Echter, voor het oplossen van het in dit issue benoemde probleem maken een aantal gemeenten op dit moment zeer waarschijnlijk gebruik maken van een door het RvIG geboden tijdelijke service die z.s.m. vervangen gaat worden door levering via gewenste verstrekkingsvormen. Wij, VNG Realisatie, zien ons dan ook genoodzaakt voor de in dit issue besproken probleem een patch uit te brengen op zowel StUF-BG 3.10 als StUF-BG-2.04. In de bijgaande pre-patches is het probleem opgelost zoals hier afgesproken. Mochten hierover vragen, opmerkingen dan wel bezwaren zijn dan zien we die graag hieronder binnen 1,5 maand gepost. Indien er in die periode geen bezwaren naar voren komen dan zullen wij deze pre-patches als patches publiceren evenals de patches voor StUF-ZKN 3.10 en StUF-ZTC 3.10 waarin dezelfde wijzigingen zullen zijn aangebracht. Eveneens zullen wij Enable-U dan vragen de patches te implementeren in het StUF Test Platform. In de pre-patch 33 voor StUF-BG 3.10 zijn de volgende bestanden aangepast:
In pre-patch 14 voor StUF-BG 2.04 zijn de volgende bestanden aangepast:
|
|
Bijna vergeten nog enkele vragen te stellen.
|
|
Onderstaand de reactie van Centric:
|
|
Ik zit nog met de mapping van de volgende elementen uit het LO. Heb je daar een idee over: categorie 16: categorie 17: Volgens mij kunnen we tijdvakGeldigheid en tijdstipRegistratie niet gebruiken omdat die in een NPS bericht betrekking hebben op categorie 1. |
Nee, het ging bij de commissie Roemer om de omstandigheden waarin arbeidsmigranten in Nederland worden behandeld en gehuisvest. Het Nederlandse adres dus. Vandaar mijn vraag.
Ok, duidelijk. Dan is het extraElement terecht aangemaakt. |
Heel terecht dat je hierover deze vragen stelt.
Ik heb hierover contact gehad met RvIG en zij geven aan dat dit gegeven geen onderdeel is van de gegevensset waarvoor de gemeenten geautoriseerd worden. Er hoeft n.m.m. dus ook voorziening worden getroffen voor dit gegeven in StUF-BG.
Ik heb gekeken of de StUF 3.01 standaard (voor StUF 2.04 is het nl. (vooralsnog) niet van toepassing) iets zegt over het in onderzoek plaatsen van extraElementen. Ik heb nergens kunnen vinden dat het 'inOnderzoek' element hiervoor gebruikt mag worden maar er wordt ook nergens aangegeven dat dat niet mag. Als die er zijn dan hoor ik graag argumenten om dit niet te doen. Zijn die steekhoudend (bijv. als er dan met andere extraElementen problemen te verwachten zijn) dan zal ik ook voor deze gegevens extraElementen op gaan voeren, zo niet dan stel ik voor het standaard 'inOnderzoek' element te gebruiken. In dat geval bevat het attribuut 'elementnaam' de naam van het extraElement dat in onderzoek is. Natuurlijk zal ik dat dan in de documentatie opnemen. De vraag is nog wel wat te doen als meerdere extraElementen in onderzoek worden geplaatst maar ook als we extraElementen voor de inOnderzoek gegevens gaan opvoeren blijft die vraag bestaan.
Mij lijkt dat we deze elementen juist wel kunnen gebruiken. Deze elementen hebben nu nl. niet alleen betrekking op categorie 01 (Persoon) maar ook op categorieën zoals bijv. 02 (Ouder1), 05 (Huwelijk/geregistreerd partnerschap), 08 (Verblijfplaats) en 09 (Kind). Ik heb hiervoor dan ook geen extraElementen opgevoerd. De volgende gegevens mappen n.m.m. dan ook op de daaronder in vet vermeldde StUF elementen:
Ook dit ga ik natuurlijk documenteren. |
|
Dat het tijdvakGeldigheid in StUF betrekking heeft op de gegevens in meerdere categorieën terwijl de BRP in iedere categorie apart een element 'Ingangsdatum geldigheid' heeft opgenomen, heb ik nooit begrepen. Maar nu introduceren we dat probleem zelfs binnen een categorie (17). Het praktische probleem is bijvoorbeeld dat, als in een kennisgeving zowel het telefoonnummer als het e-mailadres worden doorgegeven, er slechts één tijdvakGeldigheid beschikbaar is en dus niet twee verschillende waarden voor de elementen 16.30 en 17.30 (Geldig vanaf) kunnen worden doorgegeven. |
|
"Ik heb hierover contact gehad met RvIG en zij geven aan dat dit gegeven geen onderdeel is van de gegevensset waarvoor de gemeenten geautoriseerd worden." |
Goed dat je hier zo kritisch naar kijkt maar ik vrees dat het principe dat één element 'ingangsdatum geldigheid' betrekking kan hebben op gegevens uit meerdere categorieën al volop wordt toegepast in StUF. Neem het complexType 'NPSNINING-basis' in het schema 'bg0310_ent-basis.xsd'. Daarin komen o.a. de volgende elementen voor
Deze gegevens zijn in de BRP over 3 verschillende categorieën verdeeld. 1 t/m 3 staan in de categorie 01, 4 en 5 komen uit de categorie 05 en 6 t/m 8 uit de categorie 06. Wil je dus verschillende waarden voor 16.30 en 17.30 dan zul je dus twee verschillende berichten moeten sturen. |
Ik zal het RvIG vragen zelf op je opmerking te reageren. |
|
"Is er al vanuit RvIG informatie hoe deze nieuwe gegevens aan gemeenten worden doorgegeven? Wordt hiervoor de tabel 35 (autorisatietabel) uitgebreid en dan met name in de kolom 'spontaan'? Het kan dan ook nog zo zijn dat sommige van de elementen daar niet in terecht komen. Kan RvIG daar iets meer over zeggen?" Gemeenten kunnen voor cat. 16/17 worden geautoriseerd voor elk van de verstrekkingsvormen; ad-hoc (adres)vraag, spontaan. Dit verloopt inderdaad via een autorisatietabelregel in tabel 35 waar technisch gezien elk element onderdeel van kan uitmaken. De autorisatie bepaalt uiteindelijk hoe en welke gegevens worden verstrekt. De ad-hoc (adres)vraag is meegenomen in de GABA-herziening waarover gemeenten onlangs zijn geïnformeerd (zie https://www.rvig.nl/gemeente-als-buitengemeentelijke-afnemer-gaba, bijbehorende toelichting en gegevensset in de GABA-matrix (https://www.rvig.nl/media/355)). Marte ten Dam (RvIG) |
|
Dat zou schelen, ware het niet dat dat
|
|
Hmmm, dan vraag ik me af waarom in het schema bg0310_ent_basis.xsd de kardinaliteit wel 2 is en dat in een vraag-antwoord bericht (zoals Ton aangeeft) wel ondersteund wordt:
Je zou zeggen dat het dan ook mogelijk moet zijn dat beide adressen naast elkaar bestaan. Misschien kan je beide niet tegelijkertijd in 1 npsLk01 bericht opvoeren maar waarschijnlijk wel middels 2 opeenvolgende berichten. Ik snap overigens wel wat je schrijft over de problemen die je krijgt als je in 1 bericht twee buitenlandse of twee binnenlandse adressen op zou kunnen geven maar die kardinaliteit van 2 in vraagberichten zit er niet voor niets. Daar moet een reden voor zijn geweest. Ik ga maar even door met vragen stellen zodat we uiteindelijk tot de beste keuze komen...😉 |
|
in een npslv01 moet je om beide opties kunnen vragen aangezien je niet weet welke voorkomt bij een op te vragen persoon |
Ah ja. natuurlijk. |
|
Dat laatste verbiedt het Logisch Ontwerp wel. Op bladzijde 126 van LO BRP 2024.Q1_2 staat "Voor categorie 08 geldt: of groep 13 komt voor of de groepen 10 en 11 komen voor" Had dit wel gemogen, dan was categorie 16 wellicht niet nodig geweest. |
|
Ah, die had ik niet gezien. Ik ben nog even wat dieper in het LO gedoken en zie het volgende staan:
Uit met name de laatste alinea blijkt volgens mij dat de opmerking die Sid enkele comment terug plaatst:
niet van toepassing. Het is echter goed om even te kijken naar de situatie waarop die wel van toepassing wordt. De opmerking van Sid dat er behoefte zou kunnen bestaan aan beide adressen lijkt me immers niet ver gezocht en zou best wel eens in een toekomstig LO BRP terecht kunnen komen. N.m.m. blijft in dat geval echter mijn opmerking:
staan. |
|
Ik denk dat die passage slaat op een adres als in groep 10/11 van categorie 08. Groep 13 is geen adres zoals die in groep 11 of categorie 16 zijn opgenomen (met losse elementen voor straatnaam, huisnummer, etc.). Voor het buitenlands adres heb je de drie adresregels (en landcode), zodat die sowieso niet in een adresvraag kan worden gebruikt. |
|
De betreffende tekst uit het LO gaat over de adhoc adresvraag. Daarmee kun je alleen zoeken op binnenlandse adressen. De tekst "geen enkele PL heeft een adres in beide categorieën" slaat dus op het binnenlandse adres. En dat klopt want personen die een adres hebben in categorie 16 hebben geen gegevens in groep 08.11. |
|
Ok, duidelijk. Ik geef me nog niet helemaal gewonnen (😉) want daarmee pas ik mijn opmerking aan naar:
|
|
Ik denk niet dat dat gaat werken. Het verblijfsadres is als attribuutgroep in een NPS bericht opgenomen. Een tweede npsLk01 bericht wordt dus als een nieuwe toevoeging van dezelfde persoon geinterpreteerd. En dat resulteert in een foutmelding omdat de persoon al bestaat. In sommige implementaties interpreteert men de toevoeging in dat geval als een wijziging en dat leidt dan tot het verwijderen van het buitenlands adres en het opnemen van het tijdelijke verblijfsadres. Volgens de regels mogen immers niet beide gevuld zijn. Een tweede probleem is dat bij het beantwoorden van een vraag niet beide adressen in het npsLa01 bericht kunnen worden opgenomen. |
Klopt dat een tweede npsLk01 als een nieuwe toevoeging of een wijziging van dezelfde persoon wordt geïnterpreteerd. Maar als dat i.c.m. met het extraElement 'arbeidsmigrant' met de waarde 'true' zou gebeuren dan zou dat geïnterpreteerd kunnen worden als een toevoeging voor categorie 16. Dat zou n.m.m. dan niet in een foutmelding moeten resulteren. Tenzij ook de groepen 08.13 en 16.11 niet tegelijkertijd voor mogen komen.
In een npsLa01 mogen tegelijkertijd 'BG:verblijfsadres' en 'BG:sub.verblijfBuitenland' voorkomen. Zie hier:
Indien in dat bericht tevens het extraElement 'arbeidsmigrant' met de waarde 'true' voorkomt weet je dat het bij 'BG:verblijfsadres' om een tijdelijk verblijfsadres gaat. |
|
In een npsLv01 bericht mogen beide wel voorkomen om de reden die Ton ook al eerder aangaf. Maar in een npsLa01 bericht mag dat niet. En wat de npsLk01 betreft: Alles kan, maar dit grijpt wel erg in in de uitgangspunten van StUF. Wat aangaat geef ik de voorkeur aan het gebruik van het correspondentie adres. |
|
Daar heb je een punt. Nu geef ik me gewonnen. Geeft niets, we weten nu i.i.g. dat de eerder gekozen optie de juiste is. Ik zal de nieuwe pre-patch z.s.m. weer hier publiceren. Ik heb toch nog enkele onvolkomenheden gezien die ik weer eerst ga repareren. |
|
Voorlopig moeten we nog afwachten welke elementen van categorie 16 rn 17 uiteindelijk doorgegeven mogen worden. Dat lijkt voor nu opgeschort te zijn! Deze informatie komt van de RvIG! Als ik kijk naar het eerdere lijstje wil ik daar wel alvast een reactie op geven: Algemeen; de titel "VerblijfplaatsArbeidsmigrant' is verwarrend. verblijfplaats is namelijk het adres in categorie 8, het adres iin het buitenland! De naam van categorie 16 luidt 'tijdelijk verblijfadres'. dat moeten we gaan hanteren, vind ik. 'Arbeidsmigrant' als tekst toevoegen lijkt me dan wat redundant aangezien we toch al weten waar het over gaat. Per element:
M.b.t. contactgegevens
|
|
Wat bedoel je precies met de opmerking dat we voorlopig moeten afwachten? Dat we moeten wachten met het publiceren van de patch? De opmerking in het lijstje op basis waarvan jij concludeert dat we voorlopig moeten afwachten is de volgende: NB: de verstrekking van de gegevens uit categorie 16/66 (Tijdelijk verblijfsadres) en categorie 17 (Contactgegevens) en de ad hoc adresverstrekking tijdelijk verblijfadres is opgeschort totdat gemeenten en RvIG dit technisch hebben ingeregeld. Ik weet niet waarop ze hier doelen met 'totdat gemeenten en RvIG dit technisch hebben ingeregeld' maar als dat de publicatie en implementatie van de patch is dan lopen we het gevaar dat we op elkaar gaan zitten wachten. Ik heb het RvIG al gevraagd hierop te reageren. Ik ben het eens dat de namen van de extraElementen moeten worden gewijzigd. O.a. ook omdat de registratie van tijdelijke verblijfadressen niet alleen voor arbeidsmigranten geldt maar voor alle niet-ingezetenen. Hieronder ga ik nog even op een aantal van je opmerkingen m.b.t. individuele elementen in.
|
|
Met de opmerking tav opschorting in de 'GABA-matrix.xls' is bedoeld dat er pas voor cat. 16/17 geautoriseerd kan worden in de herziene GABA autorisatie nadat de applicaties bij gemeenten hierop zijn aangepast en deze gegevens kunnen ontvangen/bevragen. Onderhanden uitbreiding van StUF-BG is hiertoe randvoorwaardelijk geven de leveranciers aan. Ofwel zeker niet gaan wachten met deze aanpassing! Daarnaast voor de volledigheid; de autorisatie en daarmee de gegevensset voor ad-hoc is vastgesteld. Daarin genoemde gegevens kan de gemeente dus gaan opvragen en ontvangen. |
|
Ad hoc breft een eenmalige foto. Gemeente abonneert zich juist via VOA spontaan om mutaties door te krijgen. Als dan enkele gegevens niet bijgewerkt blijken te worden, moet de gemeente dan periodiek de RNI alsnog bevragen? Dan heeft het geen zin om VOA Spontaan aan te passen voor de STUF stroom.
|
|
@timmerto in antwoord op jouw vraag; nee, het is zeker niet zo dat ad-hoc benodigd is omdat de gegevens niet actueel zouden zijn vanuit de spontane levering. |
|
Ik heb gisteren de feedback vanuiit onze gemeenten gekregen en daaruit blijkt dat de oplossing via het correspondentieadres niet werkbaar is, de argumentatie daarvoor is:
Daarom wordt gevraagd om ook extra elementen te gebruiken voor de adresgegevens ipv het correspondetieadres te gebruiken |
|
Na druk overleg met zowel het RvIG als enkele van de deelnemers aan deze discussie en n.a.v. de voorgaande reactie van @timmerto heb ik voor zowel StUF-BG 2.04 als StUF-BG 3.10 een nieuwe pre-patch gemaakt. Daarin zijn op een paar uitzonderingen na voor bijna alle benodigde gegevens extraElementen gedefinieerd. Grote verschil met de voorgaande pre-patches is dan ook dat er dit keer geen XML-schema wijzigingen zijn aangebracht. Tevens is voor StUF 3.01 een kleine aanpassing in de documentatie van de StUF standaard aangebracht. In pre-patch 33.1 voor StUF-BG 3.10 zijn de volgende bestanden aangepast:
In pre-patch 14.1 voor StUF-BG 2.04 zijn de volgende bestanden aangepast:
Mochten hierover vragen, opmerkingen dan wel bezwaren zijn dan zien we die graag hieronder voor 1 februari gepost. |
Nog een paar tekstuele puntjes:
|
Reactie mbt patch 33.1 voor Bg0310
|
Reactie mbt Patch 14.1 voor Bg0204
|
|
Jullie verzoeken beide om extraElementen te creëren voor begin- en einddatumTijdelijkVerblijfadres. Ik zal hieronder nogmaals proberen te beargumenteren waarom n.m.m. de extraElementen niet nodig zijn maar ditmaal wat uitgebreider. Zoals timmerto ook al aangeeft bevat categorie 16 wel degelijk elementen voor de datum aanvang en einde, nl. 16.85.10 en 16.18.10.
In bovenstaand image zie je rechts de vereenvoudigde versie van het complexType 'NPSNINING-basis'. Links zie je elementen van de LO-BRP waarmee de elementen van deze versie van 'NPSNINING-basis' mappen. Met de rode pijltjes heb ik de mapping nog wat explicieter gemaakt. Zoals je links ziet worden voor de mapping naar de versimpelde versie elementen uit 7 categorieën gebruikt. In de volgende image zie je dat desondanks aan het complexType niet per categorie elementen voor beginGeldigheid zijn toegevoegd.
Alle groepen gebruiken dezelfde beginGeldigheid daarvoor. De eindGeldigheid wordt niet direct gemapt maar afgeleid van een voorgaand voorkomen. Indien meerdere elementen van meerdere categorieën op hetzelfde moment wijzigen is dat ook geen probleem. Ze hebben dan immers ook echt dezelfde datum. Als elementen van een categorie toch op een ander moment gewijzigd is dan moet een nieuw bericht gestuurd worden. Ik zie geen reden dit principe voor extraElementen te wijzigen. Het volgende image illustreert deze situatie (waarbij ik de afzondelijke extraElementen voor het gemak even als normale elementen heb weergegeven).
Sterker nog als we hadden besloten om er geen extraElementen van te maken en toch wijzigingen in het schema in het complexType 'NPSNINING-basis' aan te brengen was de situatie hetzelfde geweest, zie weer het volgende image. Tenzij we er voor hadden gekozen om van tijdelijk verblijfadres een gerelateerde te maken maar ik zie geen reden om van tijdelijk verblijfadres een afzonderlijke entiteit te maken.
|
timmerto geeft aan de toegevoegde waarde van RNI-deelnemer ook niet te zien, tenzij iemand daar bezwaar tegen aantekent, ga ik dit extraElement daarom verwijderen uit de patch van zowel bg0310 als bg0204.
timmerto schrijft daarover inOnderzoek: een enumeratie wijziging veroorzaakt een compatibiliteits probleem omdat deze nieuwe waarde consequenties heeft voor de XSD! Ik meen me te herinneren dat we in onze laatste meeting al hadden besloten om vvor inOnderzoek een extra element zouden opnemen. En in onze eerste bijeenkomst hebben we inderdaad besloten om voor Bg0310 twee extraElementen op te nemen 'inOnderzoekTijdelijkVerblijfsadres' en 'inOnderzoekContactgegevens'. Voor de waarde conformeren we aan wat er in het reguliere element 'inOnderzoek' staat (J/N). Ik stel voor deze nu inderdaad op te nemen in de patch van bg0310. Voor bg0204 zouden Ton en ik samen kijken of inOnderzoek wel ondersteund wordt. Ik neem hierover nog even contact op met timmerto. Ik zie echter alleen een drietal al bestaande inOnderzoek extraElementen voor bg0204 wat n.m.m. onderschrijft dat er in bg0204 geen voorzieningen voor zijn. Ik stel voor de hierboven genoemde 2 dus ook toe te voegen aan de extraElementen voor bg0204.
timmerto schrijft hierover: aandudingbijHuisnummmer bestaat, zoals eerder besproken, niet in Bg0310. Deze wordt meegenomen in het element “aoa.huisnummertoevoeging". dit extra element moet vervallen Dit was volgens mij inderdaad het geval en ik stel dan ook voor dit extraElement te verwijderen uit bg0310. Hij schrijft ook Hierbij is echter aanduidingbijHuisnummmer relevant om op te nemen omdat toevoeging en aanduiding in Bg0204 wel aparte elementen zijn. In bg0204 blijft dit extraElement daarom bestaan.
Ik ga kijken waar dit bij de andere extraElementen ook van toepassing is. |
|
Na mijn post van gisteren heb ik nog even nagedacht over het verzoek van @rbtuin en @timmerto om extraElementen te creëren voor de elementen 18.10 Einddatum geldigheid en 85.10 Geldigheid. Gisteravond realiseerde ik me dat er in het 2e image van deze post alleen pijlen lopen naar 'StUF:beginGeldigheid'. Dat is ook logisch want LO-BRP kent voor de in dat image genoemde categorieën geen elementen 18.10 Einddatum geldigheid. De periodes zijn in die categorieën aansluitend en de begin datum voor een nieuw voorkomen is tevens de einddatum van het voorgaande voorkomen. Dat betekent echter niet dat we ook in een extraElement voor 85.10 Geldigheid moeten voorzien. Daarvoor kan volgens mij nog steeds gebruik worden gemaakt van 'StUF:beginGeldigheid' waarmee we consistentie in de mapping tussen LO BRP en StUF-BG behouden. |
|
Ik ben het wel eens met deze redenering. Ik denk dat de verwarring is ontstaan door het feit dat element 18.10 als omschrijving 'einddatum geldigheid' heeft. De omschrijving 'einddatum verblijf' zou mijns inziens beter zijn geweest. De behoefte aan een extra element voor datum aanvang verblijf is er nog steeds, maar daar is element 85.10 inderdaad niet voor bedoeld. Het lijkt mij dus bij nader inzien correct om deze te mappen op het StUF element beginGeldigheid. Het probleem met datum aanvang verblijf zit in het feit dat dit element feitelijk ontbreekt in categorie 16. In catagorie 8 zijn de elementen 10.30 (datum aanvang adreshouding) en 13.20 (datum aanvang adres buitenland) opgenomen. Een vergelijkbaar element ontbreekt in categorie 16. Maar dat is een keuze van RvIG geweest en dat probleem moeten we inderdaad niet proberen op te lossen in de mapping naar StUF. |
|
hjet gebruik van beginGeldigheid lijkt mij niet handig. Deze is onderdeel van tijdvakGeldigheid bij NPS en die is vluchtig conform StUF. tijvakGeldigehid geeft aan wanneer een set van gegevens actueel wordt. Dat houdt in dat, wanneer een volgende mutatie moet worden verwerkt, de beginGeldigheid weer wijzigt. |
Door deze reactie realiseer me ineens dat de wijze van vastlegging in de databases van de leverancier natuurlijk heel anders is dan de wijze van vastlegging in de BRP. Daardoor begrijp ik nu ook de behoefte om voor het element 18.10 Einddatum geldigheid een extraElement te creëren. |
Het RvIG heeft bij mij aangegeven dat bovenstaande de geldende situatie goed verwoord. |
Mede naar aanleiding van de commissie Roemer inzake de omstandigheden waarin arbeidsmigranten in Nederland worden behandeld en gehuisvest, heeft de Tweede Kamer bij amendement bepaald dat gegevens omtrent de bereikbaarheid van tijdelijke arbeidsmigranten (tijdelijk verblijfadres, e-mailadres en telefoonnummer) moeten worden bijgehouden bij niet-ingezetenen.
De LO BRP is naar aanleiding daarvan al aangepast (zie W154 LO BRP en W154 Opleg). Ook binnen de gemeentelijke systemen zijn deze nieuwe BRP-gegevens geïmplementeerd. Deze gegevens kunnen echter nog niet met StUF-BG geleverd worden. Breng daarvoor in StUF-BG voorzieningen aan.
The text was updated successfully, but these errors were encountered: