Zoals belend is Vicrea bij een aantal gemeenten druk bezig met de implementatie van het BAG WOZ koppelvlak waarmee afnemende WOZ applicaties de BAG gegevens willen synchroniseren. Daarbij lopen we aan tegen een beperking in het koppelvlak. Binnen het koppelvlak is strak gedefinieerd wat er in een bericht mag zitten bij een bepaalde gebeurtenis. Wat er in een bericht mag zitten lijkt sterk afgeleid te zijn van de voorbeelden in het processenhandboek. Nu is het processenhandboek slechts een leidraad als het gaat om welke attributen er bij een bepaalde gebeurtenis gemuteerd mogen worden. Als voorbeeld neem ik de gebeurtenis "Beschikbaar komen ingemeten geometrie". Veel BAG beheerders combineren deze gebeurtenis met het aanpassen van de oppervlakte. In het bijbehorende bericht mag echter alleen geometrie verzonden worden en geen oppervlakte. Gevolg is dat de aangepaste oppervlakte niet bij de WOZ bekend is. De twee databases zijn op dat moment niet meer synchroon en er is ook geen manier meer om dat te verhelpen. Dit is slechts een voorbeeld maar er zijn veel meer gebeurtenissen waarin meer gegevens gewijzigd kunnen zijn dan in het bericht past. Je zou er aan kunnen denken om de BAG applicatie aan te passen zodat bij een bepaalde gebeurtenis alleen de attributen gewijzigd kunnen worden zoals in het processenhandboek worden aangegeven maar daar wordt een BAG beheerder niet blij van. Daarbij zijn de gebeurtenissen dan weer niet dekkend. (aanpassen bouwjaar, oppervlakte, etc). Anderzijds zouden we kunnen afwijken van de standaard en de gegevens toch doorsturen maar dat willen we liever niet. De laatste oplossing zou zijn om de gebeurtenissen volledig te negeren en alles te verzenden als BAG-MUT. Dat is echter ook geen optie omdat juist de gebeurtenis belangrijk is bij de verwerking van het bericht.
zo, 21-09-2014 - 21.39u
#1
BAG - WOZ
Dit onderhoudsverzoek is opgevoerd in de onderhoudsverzoeken als ONV0349.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Wij zijn geen voorstander om maar meer verschillende mutaties in één bericht te stoppen, omdat deze mutaties toevallig bij de beheerder in eenzelfde werkproces aan het licht komen. Het structureren van de mutaties in gebeurtenissen is vooral gedaan vanuit het afnemersperspectief. Uit de aard van de gebeurtenis kunnen zij direct zien wat de aard is van de mutatie en of dit wel of niet voor hen van belang is. Een afnemer van de BAG die bijvoorbeeld niet geïnteresseerd is in de geometrie, kan dus alle gebeurtenissen over ingemeten geometrie negeren. Wanneer jij in die gebeurtenissen nu ineens oppervlakte mutaties gaat (ver)stoppen, zal deze afnemer toch al deze geometrie-gebeurtenissen moeten gaan bekijken. Niet doen dus is onze opvatting. De wijziging van de oppervlakte is dan gewoon een andere gebeurtenis. Er is volgens ons nog een reden om het niet te doen. Wanneer de geometrie wordt ingemeten is dat een mutatie met ingangsdatum de dag van meten. Wanneer op dat moment geconstateerd wordt dat de oppervlakte fout is, zal dat geen mutatie zijn met die ingangsdatum, maar meestal een correctie met terugwerking naar de ingangsdatum van de nu geregistreerde oppervlakte. Een bericht waarin zowel geometrie als oppervlakte zit, wordt dan heel complex omdat het een mutatie en een correctie bevat met ook nog eens verschillende ingangsdata. Niet doen dus. Wat moet je wel doen. We juichen het natuurlijk toe dat gemeenten bij het inmeten gelijk de andere gegevens controleren. Als daarin iets wijzigt (correctie) dan moet dat natuurlijk ook aan de afnemers (aan de midoffice, aan de WOZ, maar ook aan de LV BAG) geleverd worden. Maar dat is dan wel een afzonderlijke gebeurtenis, zodat de afnemers direct zien wat er aan de hand is. In dit voorbeeld gaat er dan na de meting naast een bgrBIG bericht ook direct een bagCOR (correctie) naar de afnemers.
Tijdens de StUF Expertgroep van 20 januari 2016 is besloten dit onderhoudsverzoek af te voeren.