Het komt voor dat in een initiële vulling zaken als pandscheiding niet goed zijn meegekomen.
Om dit te corrigeren heeft de BAG beheerder de mogelijkheid om in de applicatie panden aan te maken of juist af te voeren, verblijfsobject-pand relaties te verleggen, etc. Dit alles wordt dan op basis van 1 brondocument gedaan en is binnen de applicatie 1 gebeurtenis.
Omdat bovenstaande gebeurtenis niet in het processenhandboek beschreven staat zal in het berichtenverkeer gekozen moeten worden uit de generieke gebeurtenissen "BAG-MUT Muteren naar aanleiding van signalering" en "BAG-COR Correctie". Punt is echter dat bij deze gebeurtenissen er geen mogelijkheid bestaat om objecten op te voeren of te verwijderen. De enige oplossing die er nu is, is het uitsplitsen van de gebeurtenis, waardoor het aan de ontvangende kant niet duidelijk is dat zaken bij elkaar horen.
Mijn voorstel is om het opvoeren en verwijderen van objecten mogelijk te maken in de generieke gebeurtenissen.
Een andere oplossing is om een extra gebeurtenis BAG-ADHOC toe te voegen die aangeeft dat er willekeurig wat veranderd is.
Dit Erratum is opgevoerd in de onderhoudsverzoeken als ERR296.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Ik begrijp de functionele behoefte, maar ik heb niet zo'n goed gevoel bij het toevoegen van een ADHOC gebeurtenis. Bovendien is er al een bagMUT gebeurtenis. Kan die gebruikt worden voor deze situatie?
Tijdens de StUF Expertgroep van 18 juni 2014 gaf Hans Orbaan aan dit issue graag te willen bespreken omdat dit al een issue uit 2011 is. Annemiek Droogh vroeg zich af of dit wel bij de StUF Expertgroep thuis hoort. Henri Korver had inderdaad ook het gevoel dat dit een koppelvlak discussie was. Sid Brouwer zei dat het koppelvlak BAG-WOZ niet meer bij de waarderingskamer in beheer is en ook niet meer bestaat.
Er ontstond een discussie over de status van de berichtencatalogus BAG. Sid Brouwer concludeerde dat er dan een apart koppelvlak zou moeten komen dat gebruik maakt van de berichtencatalogus. Er bleek onduidelijkheid te bestaan over de termen koppelvlak, sectormodel en berichtencatalogus. Ik zei dat het landschap wel duidelijker wordt als je berichtencatalogi en sectormodellen aan de ene kant en koppelvlakken aan de andere kant heel duidelijk scheidt.
Sid Brouwer zei dat je langzamerhand ziet gebeuren dat er steeds meer koppelvlakken worden gedefinieerd om duidelijkheid te krijgen wat en hoe er gebruik gemaakt moet worden van de berichtencatalogi. Henri Korver gaf aan er altijd vanuit te zijn gegaan dat wij berichtencatalogi beheren en niet koppelvlakken. Er is in ieder geval niet duidelijk hoe de initiële vulling moet gebeuren en dat moet wel beschreven worden in een apart document.
Een berichtencatalogus moet een bibliotheek zijn van componenten die door meerdere koppelvlakken kan worden gebruikt. Jan Campschroer constateerde dat er op dit punt onduidelijkheid is en dat we daar duidelijkheid in moeten verschaffen.
Henri orver pleitte er voor om het koppelvlak en berichtencatalogus uit elkaar te halen.
Sid Brouwer gaf aan persoonlijk liever geen nieuw koppelvlak gedefinieerd te zien, tenminste niet in de zin van een BAG-WOZ koppelvlak. Als we daar een koppelvlak voor nodig hebben dan is dat prima maar dan wel in de zin van een koppelvlak vanuit de BAG ongeacht wie daar de ontvanger van is. Henri Korver zei dat we dus een koppelvlak BAG moeten hebben.
Nog even op het daadwerkelijke probleem ingaand vroeg Henri Korver hoe we het probleem nu moeten gaan oplossen. Hans Orbaan lichtte nog even toe wat de onderliggende wens is. Henri Korver dacht dat je dit met de standaard berichten kunt oplossen. Sid Brouwer zei dat iedereen nu juist gebeurtenis gestuurd wil werken.
Er zijn twee vragen: hoe doen we de initiële vulling en hoe lossen we problemen op die bij de initiële vulling zijn ontstaan.
Henri Korver beschouwde dit issue als een RFC. Hij gaf aan er nog even over na te gaan denken.