Bij het doorgeven van een vetrek uit de eigen gemeente vanuit een burgrezaken systeem is het niet mogelijk om de nieuwe gemeentecode/gemeentenaam mee te geven in een StUF-bg 03.10 bericht. Niet in NPS.verblijftin, NPS.verblijfsadre. Maar ook niet bij de AOA of OPR.
Ik denk dat er geen gemeentecode is opgenomen maar een woonplaats. En via de woonplaats is de gemeente te herleiden. Maar dan verwacht je van afnemende systemen dat ze allen nederlandse woonplaatsen kunnen herleiden naar een gemeentecode of naam.
Is deze aanname juist? Zo ja, is het dan niet versatndig om voor de gemeentecode een extra element op te nemen?
Helemaal mee eens. Lijkt me heel verstandig om een gemeentecode en gemeentenaam toe te voegen aan de AOA, voorlopig als extraElement later als attribuut. Voor het correct vastleggen in de afnemende applicatie is het feitelijk niet nodig, maar voor de mens erachter lijkt het me zeer verduidelijkend.
Tsja. Niet voor niets komt in de BAG de gemeente niet voor. En als je we 'm op zouden nemen, verplichten we dan iedereen cq. elke applicatie die een AOA wil sturen om de gemeentecode te weten? Dat lijkt me ook weer veel gevraagd. Anderzijds, de gemeente komt wel in het RSGB voor. En bij elke openbare ruimte is de relatie naar de gemeente verplicht. Dus klinkt het logisch 'm wel op te nemen ...
Er zijn systemen die bij personen graag willen weten of deze binnen- of buitengemeentelijk is. Dit omdat voor beide situaties de afhandeling anders is.
Neem je de gemeentecode niet op, dan veplicht je afnemende systemen een woonplaatsentabel bij te houden waarin is terug te vinden welke gemeente bij een woonplaats hoort. In het algemeen is zo'n woonplaatsentabel nu niet nodig voor dergelijke applicaties.
Ik ben ook voorstander om de nieuwe gemeente(code) op te nemen. Afnemers moeten zich er wel bewust van zijn dat een leverancier deze nieuwe gemeente niet altijd hoeft te kennen en niet verplicht is deze te leveren. Maar zoals gezegd, zie ik wel voordelen om de nieuwe gemeente op te nemen.
Omdat het mij niet wenselijk lijkt om deze wijziging pas beschikbaar te hebben in de volgende versie van de diverse sectormodellen en koppelvlakken, stel ik voor om gebruik te maken van een (centraal door KING vastgesteld) extraElement.
Los van dit alles wacht ik vol ongeduld op het moment dat alle bronhouders (op eigen initiatief dan wel op centrale instigatie) samen gaan werken aan een nadere onderlinge afstemming van de diverse basisregistraties.
Los van het feit dat Arjan voor het toevoegen van de gemeentecode is, de AOA is al een RSGB entiteit en niet een BAG entiteit.
Dit Erratum is opgevoerd in de onderhoudsverzoeken als ERR291.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Functioneel lijkt er behoefte te zijn om bij een NPS te kunnen specificeren naar welke een persoon vertrokken. De meest logische plaats voor het extraElement lijkt me daarom binnen NPS. We hoeven dan AOA niet uit breiden met een extraElement. Bovendien werkt de oplossing dan ook als alleen de nieuwe gemeente bekend en niet het adres of verblijfsobject.
In de StUF Expertgroep van 21 augustus 2013 is dit erratum besproken.
De StUF Expertgroep is het er mee eens dit issue eerst op te lossen m.b.v. een extraElement en later structureel.
Het is de STUF Expertgroep echter nog niet duidelijk voor welke objecten dit extraElement van toepassing is. Voor NPS, AOA, OPR of voor nog meer objecten. Er is besloten dit eerst te onderzoeken.
Daarnaast is besloten een RFC (RFC0149) op te voeren op basis van deze discussie t.b.v. een structurele oplossing.
In de StUF Expertgroep van 18 september 2013 is besloten om ERR282 uit te voeren. Daarmee wordt ook dit erratum opgelost.
Tijdens de StUF Expertgroep van 20 juli 2016 is besloten RFC0149 af te voeren. Het RFC is niet meer relevant, alles werkt immers naar behoren.