Wijzigingsvoorstel LO BRP 4.6 W180 Oplossen verschillen BAG-BRP

[timmerto]

Er komt een nieuwe LO wijziging aan waarin de identificatienummeraanduiding bij het adres komt te vervallen. Er is besloten om de identificatie van de verblijfplaats (TGO) aan te houden. Dit houdt in dat de identificatienummeraanduiding in een AOA in Bg0310 en de overeenkomende extra elementen in Bg0204 niet meer worden aangeleverd vanuit de BRP bron.

Ik zie al meteen een aantal mogelijke issues:

• Als er nog een BAG leverancier aangesloten is op het distributiesysteem zal deze voor binnengemeentelijke adressen, waar personen op verblijven, de identificatienummeraanduiding nog wel aanvullen. Voor adressen waar buitengemeenteljke personen op verblijven is dat zeker niet het geval.
• Er zal rekening gehouden moeten worden met de BAG gebeurtenissen splitsing/samenvoeging op adressen waar personen op verblijven. Zonder de identificatienummeraanduiding wordt het moeilijker om te matchen als het beëindigd- en nieuwe- adres vanuit de BRP dezelfde waarden hebben.
• Vraag is of afnemers en bevragers van personen door het ontbreken van de identificatienummeraanduiding in de problemen komen. Wij hebben in ieder geval voorbeelden gezien van bevraging op identificatienummeraanduiding.

Vanuit PinkRoccade Local Government geven we al aan bij de RVIG dat de identificatienummeraanduiding gebruikt wordt maar kan VNG REA dit verder onderzoeken en met RVIG contact opnemen om ook de consequenties voor de keten aan te kaarten?

W180 Opleg v0.4 - Oplossen verschillen BAG-BRP.docx

[melsk-r]

Ton,

Onze eerste indruk is dat er in StUF-BG 3.10 zowel als 2.04 geen wijzigingen noodzakelijk zijn en dat dit door jou opgevoerde issue vooral als doel heeft het RvIG ervan te doordringen dat het wijzigingsvoorstel van invloed is op de applicaties die draaien binnen de gemeente en hen daar rekening mee te laten houden. Dat laatste is niet iets waar ik en mijn collega’s van het team Architectuur & Standaarden een rol in kunnen spelen maar wij zullen wel onze collega’s van VNG Beleid vragen hier actie op te ondernemen.

Wat het eerste betreft willen we toch graag even onderzoeken of die eerste indruk terecht is.

Volgens mij heeft ‘identificatienummeraanduiding’ o.a. betrekking op het ‘num.identificatie’ element in het type ‘AdrGrp-basis’ binnen ‘bg0310_ent_basis.xsd‘. Zie hieronder de grafische weergave daarvan:

‘num.identificatie’ is optioneel en er is dus tot zover geen redenen om iets te wijzigen, we zouden ‘num.identificatie’ uit de schema’s kunnen verwijderen maar dat levert geen voordelen op.

Het verStUFfingsdocument geeft ook nog aan dat in de entiteit NPS een choice is opgenomen met: • een groepselement met daarbinnen de platgeslagen elementen van NUMMERAANDUIDING plus het element locatieomschrijving • een groepselement voor een buitenlands adres.

Aangezien AOA een generalisatie is van zowel NUM als OAO is 'aoa.identificatie' ook de generalisatie van zowel 'num.identificatie' als 'oao.identificatie'. De 'num.identificatie' wordt in de toekomst niet meer geleverd en dus blijft in die gevallen de 'num.identificatie' achterwege. Aanpassing van het schema levert in mijn ogen ook hier niets op.

Je stelt in je issue ook nog het volgende:

Dit houdt in dat de identificatienummeraanduiding in een AOA in Bg0310 en de overeenkomende extra elementen in Bg0204 niet meer worden aangeleverd vanuit de BRP bron.

Hier geldt eigenlijk hetzelfde als hierboven beschreven. Aangezien AOA een generalisatie is van zowel NUM als OAO is 'aoa.identificatie' ook de generalisatie van zowel 'num.identificatie' als 'oao.identificatie'. De 'num.identificatie' wordt in de toekomst niet meer geleverd en dus blijft 'num.identificatie' ook hier achterwege.

Ook hier levert het dus geen voordelen op om het schema te wijzigen.

We hebben ook nog even naar de BAG berichtencatalogus gekeken en daar lijken op het eerste gezicht wel wijzigingen noodzakelijk. Bijv. in het bericht ‘bagMUT_Lk04’

Zoals je ziet kan zich daarbinnen een situatie voordoen waarin ‘num.identificatie’ verplicht is en wel als het element ‘ligStaLk02’ wordt geïnstantieerd en 'oao.identificatie' niet van toepassing is. Nadere bestudering van het complexType ‘AdrGrp-bag-wijzigingAanduiding’ (het complexType waarin het element ‘num.identificatie’ hierboven zich bevindt)

leert ons echter dat dit element nillable is wat betekent dat als in de genoemde situatie niet meer wordt voorzien in een waarde voor ‘num.identificatie’ deze leeg mag blijven. Een wijziging in de schema’s is hier dus ook niet noodzakelijk.

Conclusie: Onze eerste indruk dat er geen wijzigingen noodzakelijk zijn in de StUF-BG 3.10 schema’s was terecht.

[timmerto]

Het klopt dat de standaard hier geen hinder van ondervindt. Het gaat mij om de toepassing van dit element binnen de huidige uitwisseling van data. Het is daarom al fijn dat jullie je collega's kunnen inschakelen! Ik hoor natuurlijk ook graag van andere leveranciers of zij mogelijke gevaren zien!

[fransrijkers]

PinkRoccade heeft dit probleem ingebracht in de Werkgroep Implementatie Toekomst BRP. Het oorspronkelijke voorstel is daarop aangepast. In het LO-voorstel zoals dat op 1 juni in het Gebruikersoverleg is besproken, is geen sprake meer van het vervallen van de identificatiecode Nummeraanduiding. Op termijn is nog steeds wel de bedoeling om deze rubriek uit te faseren omdat het een overbodige rubriek is. Maar dat zal ruim van tevoren opnieuw besproken worden in de werkgroep Implementatie.