search

VNG-Realisatie / StUF-Standaarden

Repository met de issues uit en in de oude Drupal community omgeving en de nieuwe issues
https://vng-realisatie.github.io/StUF-Standaarden/
6 stars 3 forks source link

Pas StUF-BG aan zodat nieuwe BRP-gegevens (Tijdelijk verblijfsadres en contactgegevens) meegestuurd kunnen worden #31

Open melsk-r opened 4 months ago

melsk-r commented 4 months ago

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.

melsk-r commented 4 months ago

Dit onderhoudsverzoek is opgevoerd in de onderhoudsverzoeken als ONV0526. De lijst met onderhoudsverzoeken vind je hier.

melsk-r commented 4 months ago

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. Dat zou nl. betekenen dat de XML-Schema's niet aangepast worden waardoor ook niet alle software aangepast hoeft te worden. Het enige verschil tussen de voor ONV0525 gekozen oplossing en die voor dit onderhoudsverzoek zou het aantal extraElementen zijn. Het gaat daarbij om de volgende LO BRP gegevens:

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:

  1. Kan iedereen zich vinden in de door mij geschetste oplossingsrichting? Zo niet dan hoor ik graag welke oplossingsrichting wel je voorkeur heeft.
  2. Welke van de bovenstaande gegevens moeten als extraElement opgenomen worden? Dat deze gegevens in de gemeentelijke systemen zijn geïmplementeerd betekent nl. nog niet dat ze ook met StUF-BG geleverd moeten kunnen worden.
timmerto commented 4 months ago

Binnen de distributiesystemen kunnen we de verblijf gegevens in Nederland natuurlijk toevoegen maar dan is er wel de vraag welke afnemers dit gaan ondersteunen! Los van die vraag zou ik een alternatieve oplossing willen voorstellen die veel minder ingrijpend is: gebruik als alternatief, voor het tijdelijke verblijf adres in Nederland, het al aanwezige correspondentie adres van BG0310. Bij een RNI persoon komt nu namelijk geen correspondentieadres voor. Ook zijn email adres en telefoonnummer bestaande elementen die nu niet gebruikt worden vanuit de BRP bron.

rbruin commented 4 months ago

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. Mogelijk zijn er aanvullend nog enkele extra elementen nodig. Ik denk bijvoorbeeld aan de gemeente van het tijdelijk adres. En wellicht is het dan ook wenselijk om de enumeratie van element 'typering' uit te breiden met de waarde 'Tijdelijk adres'. Welke gegevens aanvullend nodig zijn is vooral ook afhankelijk van de behoefte van de gebruikers en daar hebben wij hebben geen zicht op.

melsk-r commented 3 months ago

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'.

extraElementen

Er 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.

  1. M.b.t. tijdelijk verblijfadres
  • Gemeente van inschrijving
  • Datum inschrijving in de gemeente
  • Aanduiding bij huisnummer
  • Identificatiecode verblijfplaats
  • Identificatiecode nummeraanduiding
  • Einddatum geldigheid
  • Omschrijving van de aangifte adreshouding
  • Indicatie onjuist
  • Ingangsdatum geldigheid met betrekking tot de elementen van de categorie Tijdelijk verblijfadres
  • Datum van opneming met betrekking tot de elementen van de categorie Tijdelijk verblijfadres
  • RNI-deelnemer
  • Omschrijving verdrag
  1. M.b.t. contactgegevens
  • Verificatie-indicatie telefoonnummer
  • Telefoonnummer geldig vanaf
  • Verificatie-indicatie e-mailadres
  • E-mailadres geldig vanaf

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 gegevens

Blijven nog de volgende gegevens over:

  • Datum ingang onderzoek
  • Datum einde onderzoek
  • Aanduiding gegevens in onderzoek

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:

Een uitgegeven elementnaam wordt geregistreerd samen met de aanvrager en desgewenst een definitie of omschrijving. Een dergelijke elementnaam mag niet een tweede keer worden uitgegeven.

als volgt aanpassen:

Een uitgegeven extraElementnaam wordt geregistreerd samen met de aanvrager en desgewenst een definitie of omschrijving. Een dergelijke extraElementnaam mag niet gelijk zijn aan de naam van een in het sectormodel gedefinieerd element. Dat laatste heeft ook tot gevolg dat de naam van een nieuw aan het sectormodel toe te voegen element ook niet gelijk mag zijn aan bestaande extraElementnamen. Daarnaast mag een dergelijk extraElementnaam ook niet voor een tweede keer worden uitgegeven.

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.

timmerto commented 3 months ago

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.

melsk-r commented 3 months ago

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.

melsk-r commented 3 months ago

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.

rbruin commented 3 months ago

Ik stel voor dat we StUF-BG 2.04 niet meer gaan aanpassen om deze functionaliteit te ondersteunen.

timmerto commented 3 months ago

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 GitHubhttps://github.com/VNG-Realisatie/StUF-Standaarden/issues/31#issuecomment-2037504038, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AC7RXDGHML6QYBK7HBFD7PDY3VVYFAVCNFSM6AAAAABFDA3E5KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZXGUYDIMBTHA. You are receiving this because you commented.Message ID: @.**@.>>

JohnRooijakkers commented 3 months ago

Vanuit het sociaal domein, deel ik de voorkeur van Pink en Centric

markpaanakker commented 3 months ago

GouwIT heeft voorkeur voor het door Ton aangegeven alternatief (hergebruik correspondentie adres/email+telefoon velden).

MarcoBaars commented 3 months ago

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.

melsk-r commented 2 months ago

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:

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.

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.

melsk-r commented 1 month ago

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:

melsk-r commented 1 month ago

Bijna vergeten nog enkele vragen te stellen.

  1. Ik heb nu zo'n beetje de namen van alle nieuwe extraElementen voorzien van het achtervoegsel Arbeidsmigrant. Nadeel is dat de namen daardoor lang zijn, voordeel is dat duidelijk is in welke situatie ze gebruikt moeten worden. De vraag is echter of het toch handiger is de namen wat generieker te houden en dus zonder dit achtervoegsel.
  2. In bg0310 mappen we een groot deel van de benodigde elementen op elementen binnen BG:sub.correspondentieAdres terwijl het eigenlijk om een verblijfsadres gaat.
    In bg0204 zouden we er voor kunnen kiezen juist te mappen op elementen binnen BG:PRSADRVBL wat recht doet aan de semantiek. De vraag is echter of we consistentie tussen bg0204 en bg0310 verkiezen boven correctheid en net als in bg0310 mappen op het correspondentieadres en dus op BG:PRSADRCOR.
  3. StUF 2.04 kent geen voorziening voor in Onderzoek en bg0302 dus ook niet. Willen we die functionaliteit desondanks wel voor de Tijdelijk Verblijfsadres elementen?
  4. In StUF 2.04 komt tijdstipRegistratie niet voor. De vraag is dus of we daarvoor speciaal voor Tijdelijk Verblijfsadres dan wel een voorziening moeten creëren.
  5. Er is nu een extraElement aangemaakt voor het LO BRP gegeven Identificatiecode nummeraanduiding is dat ok of moet dit gegeven gekoppeld worden met het element //BG:PRSADRCOR/BG:ADR/BG:locatieadresnummer?
rbruin commented 1 month ago

Onderstaand de reactie van Centric:

  1. Wij denken dat de toevoeging ‘Arbeidsmigrant’ een verstandige keuze is. Daarmee wordt voorkomen dat de extra elementen worden gebruikt in situaties waarin dat niet de bedoeling is.

  2. Als we in StUF-BG 3.10 niet mappen op het verblijfsadres, dan moeten we dat naar onze mening in StUF-BG 2.04 ook niet doen. Bovendien neem ik aan dat daar het buitenlandse adres van de arbeidmigrant wordt vastgelegd. Of heb ik dat mis?

  3. Om consequent te blijven kunnen we die functionaliteit in 2.04 beter weglaten.

  4. Ook hier kunnen we naar onze mening beter geen extra element voor opnemen om consequent te blijven.

  5. Element locatieadresnummer is maximaal 12 posities lang. De nummeraanduiding past daar dus niet in.

rbruin commented 1 month ago

Ik zit nog met de mapping van de volgende elementen uit het LO. Heb je daar een idee over:

categorie 16: 18.10 Einddatum geldigheid 72.10 Omschrijving van de aangifte adreshouding 83.20 Datum ingang onderzoek 83.30 Datum einde onderzoek 85.10 Ingangsdatum geldigheid met betrekking tot de elementen van de categorie Tijdelijk verblijfsadres 86.10 Datum van opneming met betrekking tot de elementen van de categorie Tijdelijk verblijfsadres

categorie 17: 16.30 Geldig vanaf 17.30 Geldig vanaf

Volgens mij kunnen we tijdvakGeldigheid en tijdstipRegistratie niet gebruiken omdat die in een NPS bericht betrekking hebben op categorie 1.

melsk-r commented 3 weeks ago

Bovendien neem ik aan dat daar het buitenlandse adres van de arbeidmigrant wordt vastgelegd. Of heb ik dat mis?

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.

  1. Element locatieadresnummer is maximaal 12 posities lang. De nummeraanduiding past daar dus niet in.

Ok, duidelijk. Dan is het extraElement terecht aangemaakt.

melsk-r commented 3 weeks ago

Ik zit nog met de mapping van de volgende elementen uit het LO. Heb je daar een idee over:

Heel terecht dat je hierover deze vragen stelt.

72.10 Omschrijving van de aangifte adreshouding

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.

83.20 Datum ingang onderzoek 83.30 Datum einde onderzoek

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 doe vraag bestaan.

Volgens mij kunnen we tijdvakGeldigheid en tijdstipRegistratie niet gebruiken omdat die in een NPS bericht betrekking hebben op categorie 1.

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.

rbruin commented 2 weeks ago

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.

timmerto commented 5 days ago

"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." 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?

melsk-r commented 3 days ago

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.

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

  1. geslachtsnaam
  2. voorvoegselGeslachtsnaam
  3. voorletters
  4. geslachtsnaamPartner
  5. voorvoegselGeslachtsnaamPartner
  6. overlijdensdatum
  7. inp.overlijdenplaats
  8. inp.overlijdenLand

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.

melsk-r commented 3 days ago

"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." 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?

Ik zal het RvIG vragen zelf op je opmerking te reageren.

martetendam commented 3 days ago

"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)). De autorisatie voor spontaan en de bijbehorende gegevensset moet nog worden vastgesteld.

Marte ten Dam (RvIG)

timmerto commented 3 days ago

Ik stel dan voor dat we wachten totdat de autorisatie is vastgesteld zodat we een duidelijk beeld hebben welke gegevens een gemeente mag ontvangen. Ik ga hierbij uit van de spontaan set omdat die de meest geknepen set zal zijn en deze bepalend is voor de mutaties die een gemeente kan ontvangen als de persoon gevolgd gaat worden.. Het heeft dan geen zin om overige gegevens in BG op te nemen die buiten deze set gaan vallen.

mvdbro commented 3 days ago

Binnengemeentelijk lijkt de gemeente me niet afhankelijk van de autorisatie door de RvIG. Buitengemeentelijk verwacht ik niet dat veel arbeidsmigranten relevant zijn voor een gemeente.

Ik vraag me daarom af of er gewacht moet worden op de autorisatieregel.

timmerto commented 3 days ago

De nieuwe categorieen worden alleen bijgehouden in de RNI.

martetendam commented 3 days ago

Het klopt dat de gegevens alleen in de RNI worden bijgehouden, waarbij het uitgangspunt is dat de gemeente de gegevens gaat ontvangen van personen (niet-ingezetenen) met een Tijdelijk Verblijfsadres (Cat.16) binnen de betreffende gemeente.

timmerto commented 3 days ago

de migranten die binnen de gemeente werkzaam zijn, worden alleen in de RNi bijgehouden, niet in de gemeentelijke BRP

rbruin commented 3 days ago

Wat dat betreft is het waarschijnlijk niet verstandig om voor de gemeente van inschrijving in categorie 16 het bestaande element inp.gemeenteVanInschrijving te gebruiken. In dat element wordt nu de code 1999 opgenomen om aan te geven dat het om een RNI registratie gaat. Als we daar de code van de gemeente van inschrijving in categorie 16 in gaan opnemen, dan onstaat er mogelijk verwarring.