Er bereiken ons berichten dat enkele leveranciers de BAG berichtenspecificaties op eigen initiatief zouden gaan uitbreiden. Het betreft uitbreidingen voor de onderstaande gebeurtenissen:
- BAG-IO In onderzoek plaatsen
- BAG-OA Onderzoek afgerond
- BAG-MUT Muteren naar aanleiding van signalering
- BAG-COR Correctie
- BAG-BN Benoemen nevenadres
- BAG-IN Intrekken nevenadres
- BGR-OABSV Ontvangst aanvraag bouw-/sloopvergunning bestaand object
- BGR-VB Melding verandering voortgang bouw/sloop
- BGR-ISV Intrekken sloopvergunning
- BAG-HER Gemeentelijke herindeling/grenscorrectie
De uitbreiding zou (latente) StUF koppelproblemenen met software van andere leveranciers introduceren wat natuurlijk ongewenst is. Beter is om hier gezamenlijk een oplossing tot een oplossing te komen.
De genoemde gebeurtenissen zijn wel onderdeel van de bg0310-BAG-berichtencatalogus maar niet van het bg0204-BAG-GBA-koppelvlak.
Daarin schuilt waarschijnlijk het probleem. De Waarderingskamer heeft namenlijk een aantal gebeurtenissen toegevoegd als aanvulling op de
bekende gebeurtenissen uit het processenhandboek.
Een mogelijk oplossing is om bovenstaande gebeurtenissen toe te voegen aan het bg0204-BAG-GBA-koppelvlak als bugfix.
Een andere oplossing is dat je gedwongen overstapt van bag-gba0204 naar bg0310-BAG.
P.S.
Er is op dit forum een vergelijkbare discussie gaande die net weer iets verder gaat dan dit probleem:
Toevoegen gebeurteniscode tbv Benoemen Verblijfsobject binnen bg0310 BAG
Het document "BAG GBA Koppelvlakbeschrijving v1.2.doc" zegt in paragraaf 4.1.3: De ‘codeGebeurtenis’ is als extra element opgenomen in de binnen het Koppelvlak BAG-GBA gedefinieerde StUF-kennisgevingsberichten voor Adres (ADR), Straat (R02) en Woonplaats (R03). Een limitatieve lijst hiervan is opgenomen in bijlage A.
Het lijkt me dus duidelijk dat een leverancier niet op eigen initiatief zo maar nieuwe gebeurteniscodes mag meesturen in het BAG-GBA koppelvlak.
Ik ben het eens met de twee mogelijkheden: uitbreiden van het BAG-GBA koppelvlak of overstappen op BAG berichtencatalogus.
Daarnaast is er nog een derde mogelijkheid: BAG leverancier beperkt zich tot de gebeurteniscodes beschreven in het BAG-GBA koppelvlak. Het lijkt me wenselijk in dat geval een mapping vast te stellen van de uitgebreide lijst met codes gebeurtenissen uit de BAG berichtencatalogus naar de kortere lijst met codes gebeurtenissenuit het BAG-GBA koppelvlak.
Zie ook extra codes gebeurtenis voor bag gba koppelvlak
Hoewel ik het vanuit de gebruiker van een ontvangend systeem zeer wenselijk acht dat er een limitatieve lijst met gebeurtenissen is die allemaal door mijn applicatie automatisch kunnen worden verwerkt, denk ik dat in de huidige praktijk van de BAG dat niet realistisch is.
Niet voor niets is in het processenhandboek van de BAG de opmerking geplaatst dat de lijst met gebeurtenissen in dat handboek niet limitatief is. Het kan dus altijd voorkomen dat er in de werkelijkheid iets gebeurt dat niet in de gedefinieerde gebeurtenissen van handboek of koppelvlak kan worden vastgelegd.
Zolang er geen wet- of regelgeving is die bepaalt wat er allemaal mogelijk is aan gebeurtenissen, verwacht ik niet dat we een alomvattende lijst zullen gaan krijgen.
Het lijkt mij dan ook vooral van belang de mogelijkgheid open te laten om wijzigingen in gegevens door te voeren zonder een gekoppelde gebeurteniscode. Deze zou zo min mogelijk moeten worden gebruikt (en in de loop der tijd misschien nauwelijks), maar moet zender en ontvanger in staat stellen wijzigingen altijd op te kunnen nemen. Vaak zal hier helaas een menselijke interventie nodig zijn (vooral bij de ontvanger), maar dat lijkt mij onvermijdelijk.
Voor wat betreft het koppelvlak BAG-GBA, kunnen we besluiten hieraan gebeurteniscodes toe te voegen. De ontvangende systemen (GBA-systemen) moeten dan worden aangepast om deze berichten (automatisch) te kunnen verwerken. Op zich is dit een prima mogelijkheid, maar het lijkt me vooral toch ook nuttig om de lijst dermate flexibel te maken dat een ontvanger ook om moet kunnen gaan met een bericht waarin een voor hem onbekende gebeurteniscode is opgenomen. Hiermee wordt het eenvoudiger de lijst uit te breiden, zonder dat dit meteen een aanpassing van de standaard en alle gebruikende systemen vereist.
Aan de andere kant zijn er momenteel initiatieven om de BAG-berichtencatalogus in te gaan zetten voor het informeren van GBA-systemen. Het lijkt me een betere investering om hierin weer eens te kijken of de huidige lijst gebeurtenissen afdoende is, dan dat we in twee koppelvlakken blijven investeren.
Ik deel de mening van Sid dat de lijst van gebeurtenissen uitbreidbaar zou moeten zijn waarbij de ontvanger van berichten om moet kunnen gaan met (voor deze ontvanger) onbekende gebeurtenissen. Het element gebeurtenis zou dan beter geen enumeratie moeten kennen omdat een uitbreiding steeds een aanpassing van de schema's vereist.
Naar aanleiding van deze discussie is in de onderhoudsverzoeken erratum ERR213 opgevoerd.
In de StUF Expertgroep van 20 maart 2013 is besloten dit erratum niet te honoreren en af te voeren.
Het is nl. logisch dat bg0204 op dit punt afwijkt van bg0310. Er zijn inmiddels immers nieuwe gebeurtenissen gedefinieerd die in bg0204 niet ondersteund worden. Een gemeente zal dus een keuze moeten maken tussen bg0204 en bg0310. Die keuze heeft gevolgen voor de mogelijkheden die je hebt.
Post gesloten.