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) |
|
Ik stel dan voor dat we wachten totdat de autorisatie is vastgesteld zodat we een duidelijk beeld hebben welke gegevens een gemeente mag ontvangen. |
|
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. |
|
De nieuwe categorieen worden alleen bijgehouden in de RNI. |
|
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. |
|
de migranten die binnen de gemeente werkzaam zijn, worden alleen in de RNi bijgehouden, niet in de gemeentelijke BRP |
|
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. |
|
Deze week heb ik gewerkt aan een nieuwe versie van de pre-patch. Daarin zijn alle opmerkingen die n.a.v. de voorgaande pre-patch zijn gemaakt verwerkt naast nog enkele bevindingen die ik zelf heb gedaan. Voordat ik die echter weer aan jullie voorleg wil ik nog graag een andere optie aan jullie voorleggen. Gisteren sprak ik nl. met mijn collega Henri Korver en kwam de volgende optie voor deze patch uit de hoge hoed rollen. In deze optie maken we gewoon gebruik van de elementen in het element 'BG:verblijfsadres' i.p.v. die in 'BG:correspondentieAdres'.
Welke van die twee extraElementen het wordt hangt af van het antwoord op de vraag of een verblijfsadres bij een arbeidsmigrant altijd tijdelijk is. Deze optie kent naar ons idee de volgende voordelen:
Ik hoor graag van jullie of deze nieuwe variant de voorkeur heeft of toch de oude variant. |
|
Bij gebruik van het verblijfsadres kun je niet meer het buitenlandse inschrijvingsadres van de migrant opnemen (die hangen samen achter één choice). Het betreft hier geen ingezetenen van Nederland en die hebben dus nog steeds een adres in het buitenland waarop ze daadwerkelijk zijn ingeschreven, naast het tijdelijke adres hier in Nederland. Ik ben dus bang dat dit geen optie is. Een buitenlands adres kan in de BRP niet als briefadres worden aangemerkt, waardoor in de basisregistratie geen correspondentieadres kan worden geregistreerd bij een arbeidsmigrant. Daarom is dát element (vanuit de basisregistratie gezien) wél nog beschikbaar. Let wel: het gaat om gegevens die alleen in de RNI worden bijgehouden. Het gaat dus om personen die niet in Nederland zijn ingeschreven. Verblijft iemand langere tijd in Nederland, dan wordt deze ingeschreven en de BRP met een Nederlands adres in een gemeente. Op dat moment zijn het tijdelijke verblijfsadres en de contactgegevens binnen de basisregistratie niet meer beschikbaar omdat de PL verhuist van RNI naar gemeente (waar beide categorieën niet mogen voorkomen aldus het LO). |
|
Voor StUF-BG 2.04 heb je denk ik gelijk. In StUF-BG 3.10 geldt echter voor die choice een kardinaliteit van 0..2 waardoor je dus zowel een buitenlands adres als een Nederlands verblijfadres kunt opnemen. Verandert dat gegeven nog iets aan je betoog? |
|
Vanuit vraag-antwoord klopt dat, vanuit de BRP stroom kennisgeving niet. Daar is (tot nu) altijd maar één optie mogelijk. Zo is het ook geïmplementeerd door (alle) partijen.
From: Robert Melskens ***@***.***>
Sent: vrijdag 23 augustus 2024 12:57
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.
Voor StUF-BG 2.04 heb je denk ik gelijk. In StUF-BG 3.10 geldt echter voor die choice een kardinaliteit van 0..2 waardoor je dus zowel een buitenlands adres als een Nederlands verblijfadres kunt opnemen.
Verandert dat gegeven nog iets aan je betoog?
—
Reply to this email directly, view it on GitHub<#31 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AC7RXDEVZJE4P2GCFUJW25DZS4IOBAVCNFSM6AAAAABFDA3E5KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBWHAZTSMZQGQ>.
You are receiving this because you commented.Message ID: ***@***.******@***.***>>
|
|
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 |
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: