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

Aanpassing StUF-BG standaard voor deelresultaat adresonderzoek (agv LO3.14 W15) #25

Closed lindamertensclaessen closed 2 years ago

lindamertensclaessen commented 2 years ago

Bij deze het verzoek vanuit de Gebruikersvereniging PinkRoccade om de StUF-BG standaard(en) zodanig aan te passen dat het 'deelresultaat adresonderzoek' ook gedistribueerd kan worden naar binnengemeentelijke afnemers bij de invoering van het nieuwe (GBA) LO 3.14 (W15). Het betreft hier de tussenwaarde die vertegenwoordigt dat een onderzoek nog loopt, maar dat wel al bekend is dat de betreffende persoon niet meer op het bestaande adres verblijft.

melsk-r commented 2 years ago

Ter info LO 3.14 - W15 behelst een oplossing voor de met name bij de G4 gemeenten gehanteerde praktijk om bewoners die niet meer verblijven op hun inschrijvingsadres op een 'punt' adres te zetten. RvIG wil graag af van deze praktijk en wil graag dat betrokken personen op de persoonslijst een speciale waarde in het element krijgen dat aangeeft welke rubrieken in onderzoek zijn (zie ook https://www.rvig.nl/brp/wijzigingen-logisch-ontwerp-gba-3.14).

Op dit moment is het echter niet mogelijk om die speciale waarde met een StUF-BG bericht mee te sturen wat betekent dat deze informatie niet opgevraagd/verstrekt kan worden via een StUF bericht.

Wij zien voor dit probleem 2 opties:

De eerste optie vergt een aanpassing aan StUF-BG al beperkt deze zich tot de lijst met extraElementen en het toevoegen van een korte uitleg m.b.t. de toepassing van het extraElement. Hiervoor moet echter wel nieuwe StUF patch gepubliceerd worden wat helaas tijd kost vanwege de zorgvuldigheid die we in dat traject betrachten. Voor de laatste optie is geen aanpassing aan StUF-BG nodig en ook geen nieuwe StUF patch. Leveranciers kunnen dus na keuze voor deze optie direct beginnen met het aanpassen van hun software. Leveranciers zijn hiermee niet meer afhankelijk van aanleverende StUF-systemen die de aanpassing nog niet doorgevoerd hebben.

Bij beide opties is het probleem niet meteen opgelost omdat leveranciers de wijziging natuurlijk nog in hun software moeten doorvoeren. Zolang nog niet iedereen overgeschakeld is zou je daarom kunnen afspreken het ‘punt’ adres nog te blijven gebruiken.

Ik hoor graag waar de voorkeur naar uitgaat. In geval de voorkeur uitgaat naar de eerste optie hoor ik graag welk formaat gehanteerd zou moeten worden (hou daarbij rekening met eventuele toekomstige waarden) en welke waarde we in deze specifieke situatie zouden moeten hanteren.

melsk-r commented 2 years ago

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

lindamertensclaessen commented 2 years ago

Optie 2 is mijns inziens niet afdoende, omdat:

A) in het (huidige) GABA autorisatiebesluit is opgenomen dat rubriek 08.83.10 (zelfs de hele rubrieksgroep 08.83) niet verstrekt wordt. Dit geldt voor zowel 'spontaan' als 'adhoc'. De GBA-V bevragen levert dus niet de gewenste gegevens. Hiervoor moet eerst landelijk het GABA autorisatiebesluit aangepast worden. (In het LO 3.14 W15 wijzigingsvoorstel was volgens mij slechts opgenomen dat de nieuwe waarde 08999 onder dezelfde voorwaarden als de waarde 08000 verstrekt moet worden. De waarde 08000 wordt echter niet verstrekt door de GBA-V volgens het GABA autorisatiebesluit.)

B) Zelfs als landelijk het GABA autorisatiebesluit wordt aangepast en de betreffende elementen 08.83.10 en 08.83.20/08.83.30 worden toegevoegd, biedt de 2de optie geen oplossing bij de uitvoering van gemeentelijke taken die niet in het GABA autorisatiebesluit zijn opgenomen, maar wel in de (gemeentelijke) Algemene verordening. Bijvoorbeeld de uitvoering van taken van de kredietbank. Gemeenten kunnen in hun gemeentelijke Algemene Verordening opnemen dat hiervoor de (lokale/binnengemeentelijke) BRP geraadpleegd mag worden. Gemeenten mogen dan niet de GBA-V bevragen, maar wel de eigen BRP. Ook in zulke gevallen dienen binnengemeentelijke afnemers conform (StUF-BG-)standaarden deze nieuwe waarde te kunnen raadplegen/ontvangen.

Mijn voorkeur gaat dus naar de eerste optie.

michielverhoef commented 2 years ago

Ik heb dit issue opnieuw geopend om eventuele reacties/discussie hier te kunnen voeren.

NB. Alleen het opnemen van een verzoek in de lijst met onderhoudsverzoeken is geen reden een issue te sluiten. Het issue is immers nog niet opgelost en het kan zijn dat er nog vragen zijn naar aanleiding van eerdere bijdragen.

lindamertensclaessen commented 2 years ago

Bedankt Michiel. Had per ongeluk op de verkeerde knop geklikt.

sbrouwer71 commented 2 years ago

In plaats van optie 1, zouden wij (Centric) een variant daarvan willen voorstellen: Al in bg0204 hebben wij een extraElement Aanduidingonderzoekadres geïntroduceerd (numeriek, lengte 6) waarin het in onderzoek staande element kan worden opgenomen (conform de methodiek van GBA). Hierin kunnen we dus ook de nieuwe waarde 089999 opnemen. Voordeel van deze methodiek is dat de ontvanger sowieso meer informatie krijgt over het onderzoek. Bijvoorbeeld als alleen de ingangsdatum in onderzoek staat, kan dit zo worden aangegeven.

Ons voorstel is dan ook om dit extraElement of een vergelijkbaar element te gaan gebruiken. Hiermee sluit je dan ook nauw aan bij de werkwijze die GBA/BRP hanteert. Mochten hier in de toekomst vergelijkbare nieuwe toepassingen worden verzonnen, dan zal dit hoogst waarschijnlijk op vergelijkbare wijze worden opgelost en is StUF hierop voorbereid. Bovendien lost het dit probleem op én levert (voor wie hierin is geïnteresseerd) extra informatie die tot nu toe verloren ging in de StUF-standaard.

timmerto commented 2 years ago

Vanuit Pinkroccade Local Government heb ik twee vragen hierbij:

Vervolgens hebben we ook te maken met Bg0204 afnemers voor wie dit ook interessant kan zijn. Bg0204 wordt dan weliswaar niet meer officieel onderhouden maar wordt nog dagelijks toegepast.

melsk-r commented 2 years ago

Wij zijn op zoek naar het LO GBA 3.14 maar kunnen deze niet vinden. We kunnen wel de wijzigingen in die versie ophalen maar niet het complete LO. Weet iemand waar we dat kunnen vinden?

melsk-r commented 2 years ago

Dag Ton,

je schrijft:

Ik wil voorkomen dat als een dergelijk element officieel wordt benoemd, ......

en meteen daarna:

Mocht dit element vast gesteld worden, wil ik dit wel expliciet opgenomen hebben.

Ik begrijp niet wat je hiermee wil zeggen. De zinnen lijken in tegenspraak met elkaar. Zo zal je het waarschijnlijk niet bedoelt hebben dus kan je dit nog iets beter uitleggen? Wat is het verschil tussen 'een element officieel benoemen' en 'een element vaststellen'?

sbrouwer71 commented 2 years ago

Hallo Ton,

timmerto commented 2 years ago

@melsk-r, met officieel benoemen en vaststellen bedoel ik hetzelfde. Met mocht bedoelde ik: Mocht het voorstel van Sid aangenomen worden, dan mag het niet de consequentie hebben dat voor , alle al lopende onderzoeken in het gegevens magazijn dit element alsnog bijgewerkt zouden moeten worden. Gerekend vanaf implementatie in de software!

@Sid Brouwer , je hebt gelijk dat soortgelijke toekomstige wijzigingen kunnen worden doorgevoerd zonder aanpassingen op StUF BG met je voorstel en kan ik mee gaan in je voorstel met inachtneming van mijn bovengenoemde opmerking.
In de uitleg zal dan wel specifiek moeten worden beschreven dat het extra element aanvullend is opgenomen voor het kunnen doorgeven van 'deelresultaat adresonderzoek' Voor onderzoek is er namelijk al een regulier element in Bg0310.

Algemeen: Wat ik me dan nog wel afvraag is hoe dan om te gaan met toekomstige wijzigingen als we dit voorstel doorvoeren! Voor distributiesystemen en gegevensmagazijnen is er dan geen trigger meer. Een eventuele 089998 wordt dan impliciet al ondersteund. Afnemers en bevragers weten dat echter nog niet en zullen de nieuwe waarde (in het beste geval) negeren. Wie is er dan verantwoordelijk voor het doorgeven van de wijzigingen vanuit GBA? Is dat dan een aanpassing in de uitleg en blijft het daarmee een taak voor VNG REA?

lindamertensclaessen commented 2 years ago

Wij zijn op zoek naar het LO GBA 3.14 maar kunnen deze niet vinden. We kunnen wel de wijzigingen in die versie ophalen maar niet het complete LO. Weet iemand waar we dat kunnen vinden?

Wellicht op te vragen bij de RvIG?

melsk-r commented 2 years ago

Om wat meer duidelijkheid te geven m.b.t. de voorstellen die Ton en Sid doen heb ik beide voorstellen uitgewerkt. Daarnaast doe ik na die uitwerking ook nog een nieuw voorstel.

Ton staat de volgende structuur voor:

<BG:object StUF:entiteittype="NPS">
    ...
    <BG:verblijfsadres>
        <BG:gor.straatnaam>Kerkstraat</BG:gor.straatnaam>
        <BG:aoa.huisnummer>5</BG:aoa.huisnummer>
    </BG:verblijfsadres>
    ...
    <BG:inOnderzoek StUF:metagegeven="true" groepsnaam="Verblijfsplaats">J</BG:inOnderzoek>
    ...
    <StUF:extraElementen>
        <StUF:extraElement naam="verblijfsadresVerlaten">Ja</StUF:extraElement>
    </StUF:extraElementen>
    ...
</BG:object>

Daarbij kan voor de naam 'verblijfsadresVerlaten' natuurlijk nog een geheel andere naam gekozen worden. Een oplossing die heel specifiek het probleem van de 'punt' adressen oplost, heel duidelijk is maar geen mogelijkheden biedt om in de toekomst nog andere informatie te verstrekken.

De oplossing van Sid:

<BG:object StUF:entiteittype="NPS">
    ...
    <BG:verblijfsadres>
        <BG:gor.straatnaam>Kerkstraat</BG:gor.straatnaam>
        <BG:aoa.huisnummer>5</BG:aoa.huisnummer>
    </BG:verblijfsadres>
    ...
    <BG:inOnderzoek StUF:metagegeven="true" groepsnaam="Verblijfsplaats">J</BG:inOnderzoek>
    <BG:inOnderzoek StUF:metagegeven="true" groepsnaam="Nationaliteit">J</BG:inOnderzoek>
    ...
    <StUF:extraElementen>
        <StUF:extraElement naam="Aanduidingonderzoekadres">089999</StUF:extraElement>
    </StUF:extraElementen>
    ...
</BG:object>

maakt gebruik van het extraElement dat Centric al sinds StUF-BG 2.04 gebruikt. Deze oplossing is veel generieker aangezien er in het extraElement ook andere waarden dan 089999 verstuurd kunnen worden. Op het moment dat daar in de toekomst behoefte aan is dan is StUF-BG daar al op voorbereid. Ook kan daarmee nu al heel exact worden aangegeven welk GBA gegeven precies in onderzoek staat. Tenminste voor zover het een gegeven in het Verblijfsadres betreft. Wil je voor de gegevens in bijvoorbeeld Nationaliteit ook deze functionaliteit bieden dan zul je weer een ander extraElement moeten introduceren.

N.m.m. kan het nog generieker en dat illustreer ik in het volgende fragment:

<BG:object StUF:entiteittype="NPS">
    ...
    <BG:verblijfsadres>
        <BG:gor.straatnaam>Kerkstraat</BG:gor.straatnaam>
        <BG:aoa.huisnummer>5</BG:aoa.huisnummer>
    </BG:verblijfsadres>
    ...
    <BG:inOnderzoek StUF:metagegeven="true" groepsnaam="Verblijfsplaats">J</BG:inOnderzoek>
    <BG:inOnderzoek StUF:metagegeven="true" groepsnaam="Nationaliteit">J</BG:inOnderzoek>
    ...
    <StUF:extraElementen>
        <!-- Heeft betrekking op de categorie Verblijfplaats. -->
        <StUF:extraElement naam="aanduidingInOnderzoekNPS">089999</StUF:extraElement>
        <!-- Heeft betrekking op de categorie Nationaliteit. -->
        <StUF:extraElement naam="aanduidingInOnderzoekNPS">040500</StUF:extraElement>
    </StUF:extraElementen>
    ...
</BG:object>

Het extraElement heeft hier de naam 'aanduidingInOnderzoekNPS' gekregen. Een extraElement dat te gebruiken is voor alle Persoonsgegevens in het GBA. Doordat een extraElement meerdere keren met dezelfde naam voor mag komen heb je de mogelijkheid om voor meerdere gegevens of dit in onderzoek is of (mocht dat in de toekomst spelen) voor meerdere gegevens aan te geven wat de reden van het in onderzoek plaatsen is.

De 3 voorstellen gaan dus van specifiek naar generiek met de optie van Sid daar tussenin.

melsk-r commented 2 years ago

Algemeen: Wat ik me dan nog wel afvraag is hoe dan om te gaan met toekomstige wijzigingen als we dit voorstel doorvoeren! Voor distributiesystemen en gegevensmagazijnen is er dan geen trigger meer. Een eventuele 089998 wordt dan impliciet al ondersteund. Afnemers en bevragers weten dat echter nog niet en zullen de nieuwe waarde (in het beste geval) negeren. Wie is er dan verantwoordelijk voor het doorgeven van de wijzigingen vanuit GBA? Is dat dan een aanpassing in de uitleg en blijft het daarmee een taak voor VNG REA?

Het voornemen is om net zoals we dat voor de berichtencatalogus bg0310\bag doen te voorzien in een uitleg voor de berichtencatalogus bg0310\gba. Daarin zullen we net als bij die voor de BAG een uitleg opnemen van het extraElement waarin we aangeven wat 089999 betekent. Mochten er in de toekomst aan een nieuwe versie van het LO GBA waarden worden toegevoegd dan zal VNG Realisatie ook de betekenis van die waarden beschrijven en een nieuwe patch uitbrengen.

Om te voorkomen dat een wijziging net als nu (te) laat in StUF-BG wordt doorgevoerd willen we de RvIG vragen ons te mailen zodra er een wijziging is aangebracht aan het LO GBA.

melsk-r commented 2 years ago

Wij zijn op zoek naar het LO GBA 3.14 maar kunnen deze niet vinden. We kunnen wel de wijzigingen in die versie ophalen maar niet het complete LO. Weet iemand waar we dat kunnen vinden?

Wellicht op te vragen bij de RvIG?

Om verwarring over geldende voorschriften te voorkomen, worden documenten als het Logisch Ontwerp en de Handleiding Uitvoeringsprocedures blijkbaar altijd pas kort voor of na het moment waarop ze in werking zijn getreden gepubliceerd. Tot die tijd moeten de externe gebruikers het met de beschrijving van de wijzigingen doen.

melsk-r commented 2 years ago

Als VNG kiezen wij voor de 3e variant (de meest generieke). Deze variant gaan we uitwerken tenzij jullie daar uiterlijk maandag 29-11-2021 een bezwaar tegen hebben ingediend.

timmerto commented 2 years ago

Optie 1 heeft de beste naamgeving: verblijfsadresVerlaten Optie 2 heeft als voordeel dat Centric en overige applicaties die al met de Centric variant werken geen nieuw element hoeven op te nemen. Dan hoeft alleen de 9999 herkend te worden. M.b.t. optie 3 is het dubbel voorkomen van een extra elementnaam een probleem aangezien we niet toestaan dat deze dubbel mag voorkomen. Dit is in lijn met de StUF 0301 en 0204 documentatie die aangeeft dat een exta elementnaam niet een tweede keer uitgegeven mag worden.

Optie 1 en 2 zijn, wat mij betreft, allebei toepasbaar

melsk-r commented 2 years ago

Hoi Ton,

Het klopt dat in de in zowel de StUF 2.04 als de 3.01 standaard staat dat een extraElement-naam niet een tweede keer uitgegeven mag worden. Dat gaat volgens mij echter niet over het aantal keer dat een extraElement met dezelfde naam voor mag komen in een bericht.

De VNG registreert de namen van de extraElement die door de diverse leveranciers zijn bedacht en ook de namen die in de sectormodellen/koppelvlakken worden gebruikt. De zin in de standaard geeft aan dat een eenmaal geclaimde naam niet ook nog eens een keer door een andere leverancier met een ander doel (en dus definitie of omschrijving) in de registratie van de VNG mag worden opgenomen. Elk extraElement mag door elke leverancier worden gebruikt maar dan wel met hetzelfde doel.

Wil je met dit in het achterhoofd optie 3 nog eens overwegen?

timmerto commented 2 years ago

De beschrijving in de documentatie refereert inderdaad naar de uitleg die jij geeft. Maar vanaf het moment dat Bg0204 wordt ondersteund was er ook de opvatting dat een extra element maar één keer kan worden opgenomen. Waarschijnlijk ingegeven door het feit dat je geen kardinaliteit kunt opnemen bij een extra element. Voor optie 3 zul je moeten inventariseren welke systemen in staat zijn om dubbele voorkomens te ondersteunen. Dat lijkt me reden genoeg om deze optie nu niet in te zetten.

melsk-r commented 2 years ago

Je argumenten lijken me steekhoudend en worden ook door niemand tegengesproken. Ondanks dat n.m.m. optie 3 meer felixibiliteit biedt hebben we nu niet de tijd om te onderzoeken of invoering van die optie mogelijk is wat voor mij reden is om te kiezen voor optie 2. Ik ga deze uitwerken in een pre-patch die ik hier zal posten. Na goedkeuring van de pre-patch zal ik de patch publiceren.

timmerto commented 2 years ago

Hoe wordt voor Bg0204 bepaald dat onder de entiteit PRS dit 'nieuwe' element mag worden opgenomen? naamgeving zal hier ook zijn 'Aanduidingonderzoekadres'

melsk-r commented 2 years ago

In tegenstelling tot wat ik eerder zei ga ik voor StUF-BG 3.10 in het verStUFfingsdocument aangeven hoe er omgegaan moet worden met het extraElement 'Aanduidingonderzoekadres'. Er is immers geen gba berichtencatalogus.

Voor StUF-BG 2.04 wil ik dat in het document 'Sectormodel StUF-BG: Berichtdefinities' gaan doen. Daar is het overigens nog de vraag of het extraElement moet worden opgenomen in alle entiteiten waar Centric dit extraElement al in opnam (PRSADRCOR, PRSADRVBL, PRSADRINS) of kunnen we ons beperken tot een van deze 3?

timmerto commented 2 years ago

Ik zou dit element liever rechtstreeks onder PRS opnemen, dan is het meer in lijn met Bg0310 en is het ook toe te passen bij transformaties tussen bg0204 naar bg0310.

melsk-r commented 2 years ago

Ik zou dit element liever rechtstreeks onder PRS opnemen, dan is het meer in lijn met Bg0310 en is het ook toe te passen bij transformaties tussen bg0204 naar bg0310.

Ik hoor het graag als dit voor anderen een probleem is.

melsk-r commented 2 years ago

Bijgaand vinden jullie een 3-tal zip bestanden met de pre-patch 32 voor zowel StUF-BG 3.10, StUF-ZKN 3.10 als StUF-ZTC 3.10. De laatste 2 zijn voor de volledigheid bijgevoegd maar bevatten geen andere wijzigingen dan de pre-patch voor StUF-BG 3.10 bevat. Tevens vind je 1 zip bestand met de pre-patch 13 voor StUF-BG 2.04.

In deze pre-patches is onderhoudsverzoek ONV0525 dat gerelateerd is met deze discussie opgelost.

Aan jullie de vraag te beoordelen of de aangebrachte wijzigingen het onderhoudsverzoek op een afdoende wijze oplost. In de zip bestanden vind je tevens een lijst met de in deze pre-patch verwerkte onderhoudsverzoeken, daarin is aangegeven welke componenten er precies zijn aangepast.

Ik ontvang graag voor 10 december jullie opmerkingen in de gerelateerde discussie waarvan hierboven de link is opgenomen.

Indien er geen opmerkingen zijn zal ik daarna z.s.m. de officiële patches publiceren op GEMMA Online en daarvan dan alle stakeholders op de hoogte brengen.

melsk-r commented 2 years ago

Dit issue is inmiddels m.b.v. patch 32 opgelost en kan gesloten worden.