Toekomstige mutaties in RSGB

Dit is een statische kopie van het eerdere discussie.kinggemeenten.nl.
Nieuwe discussies kunnen in de GitHub repository 'StUF standaarden' als issue worden opgevoerd.

3 reacties / 0 nieuw
René Kok
Toekomstige mutaties in RSGB

Voor de BAG is het noodzakelijk om toekomstige mutaties te kunnen verwerken. Binnengemeentelijk moet deze informatie uitgewisseld kunnen worden. Nu begrijp ik dat de StUF standaard dit ondersteund (berichttype LK05) maar het sectormodel nog niet. Kan dit opgepakt worden?

Maarten van den...

Bij de introductie van de toekomstmutaties was de perceptie bij mijn weten dat het zinnig was om systemen niet te belasten met het verwerken hiervan. Er is daarom voor gekozen om toekomstmutaties niet op te nemen in bg0310. Het leveranciersoverleg rond de koppeling GBA en BAG heeft geconcludeerd dat deze toekomstmutaties voor de BAG-objecten TGO, AOA, OPR en WPL toch nodig zijn. Gaarne de visie van de leveranciers vertegenwoordigd in de expertgroep op de introductie van toekomstmutaties voor deze entiteittypen in bg0310.

Met vriendelijke groet,

Maarten

Anoniem

De noodzakelijkheid voor de binnengemeentelijke distributie van toekomstige wijzigingen, is mij nog niet gebleken. Sterker nog, ik lees in een verslag van een van de deelnemers aan het BAG-GBA overleg:

"de GBA heeft geen behoefte aan toekomst-situaties"

Het lijkt mij niet wenselijk om alle afnemers van (adres)gegevens te verplichten om te kunnen gaan met toekomstige wijzigingen. Ik moet er niet aan denken dat in het gemeentebrede magazijn dat ook gebruikt wordt binnen de e-Dienstverlening een formulier geprefilled wordt waarop gegevens staan die (nog) niet geldig zijn.

Indien een leverancier mutaties in de toekomst wil aanleveren (Lk05), dan kan dat alleen indien deze zelfde leverancier ook een mutatie aanlevert (Lk01) op het moment dat de eerder verstrekte wijziging actueel geldig wordt.