Nieuwe cycles voor AOA's na update OPR

[ProcessPatrick]

Wij stuiten op een confilct bij de ontvanger tijdens uitsturen van een nullevering.

De ingelezen gegevens van Kadaster bevatten een straat die later hernoemd is, waardoor die openbare ruimte dus een x aantal cycles heeft. Bij het uitsturen van de 0-stand, komt de meest recente versie van de openbare ruimte er uit (lees: geen historie). Wanneer vervolgens de nummeraanduidingen aan bod komen geeft de ontvanger een fout: 'de begingeldigheid ligt voor de begingeldigheid (van die cycle) van de openbareruimte'. Dit impliceert dat voor een correcte afhandeling een mutatie van de openbare ruimte ook direct leidt tot een mutatie (nieuwe cycle) van adresseerbaarobject aanduidingen. De enige aanpassing aan de getroffen aoa's is dan begingeldigheid, wat authentiek is.

Dit lijkt ons niet de bedoeling. Het is ook niet terug te lezen in de praktijkhandleiding van Kadaster dat adresseerbaarobject aanduidingen geraakt worden, tenzij de referentie naar openbare ruimte aangepast moet worden. Straks wordt er verwacht dat wanneer de woonplaats wijzigt alle entiteiten met een referentie naar die woonplaats een nieuwe cycle krijgen, omdat hun ingangsdatum dan ook voor de ingangsdatum (van die cycle) van de woonplaats ligt.

Graag krijgen wij uitsluitsel om een volgende nullevering zonder verrassingen uit te kunnen sturen.

[melsk-r]

Patrick,

Ik heb bovenstaande situatieschets nog enkele keren goed doorgelezen en geprobeerd te interpreteren. Het resultaat daarvan heb ik hieronder in mijn eigen woorden beschreven.

• Een ontvanger ontvangt een nullevering waarmee zij beetje bij beetje een registratie opbouwen;
• In die registratie wordt daarmee ook een OPR entiteit vastgelegd, eentje die in het verleden enkele malen hernoemd is. Daardoor is naast de naam ook de begingeldigheid van die entiteit gewijzigd. De laatste maal dat deze hernoemd is, is bijv. 1-8-2021 geweest, en dat is dan ook de huidige waarde van de begingeldigheid;
• Aan die OPR entiteit zijn een aantal AOA entiteiten gekoppeld. De wijziging van de gerelateerde OPR heeft nooit gevolgen gehad voor deze AOA entiteiten, de identificatie van de OPR is immers gelijk gebleven. De AOA entiteiten zijn zelf dus ongewijzigd gebleven en daarom is ook de begingeldigheid van die AOA’s ongewijzigd gebleven. Deze hebben bijv. nog allemaal de waarde 1-1-2020.
• Op het moment dat de opbouw van de registratie zover is dat de eerste van de betreffende AOA entiteiten wordt geïmporteerd wordt een foutmelding gegenereerd. Deze geeft aan dat de begingeldigheid van de AOA entiteiten niet ouder mag zijn dan de begingeldigheid van de gerelateerde OPR entiteit.

Jouw vraag gaat er eigenlijk om hoe je deze foutmeldingen kunt voorkomen. Een van de opties, het muteren van de AOA’s n.a.v. een mutatie van de gerelateerde OPR (waarbij alleen de begingeldigheid van de AOA’s wordt aangepast), lijkt jou niet de gewenste.

Klopt bovenstaande interpretatie?

[ProcessPatrick]

Bovenstaande interpretatie klopt.

Inmiddels hebben wij een tweede melding gekregen, waar ze toevallig dezelfde ESB gebruiken als de klant van eerste melding.

Dat het plaatsvindt in een nullevering was ter context, de tweede melding gaat over het hernoemen van een OPR. De afnemende applicatie blijft de oude staat/straatnaam van de nummeraanduiding tonen. Het oprLk01 W-bericht leidt daar niet tot het tonen van de nieuwe/juiste openbare ruimte naam bij de gerelateerde AOA’s.

[melsk-r]

Dit issue gaat meer over de wijze waarop de gegevens van de entiteiten die met StUF berichten verstuurd worden verwerkt moeten worden in de applicaties (een proces issue dus) dan dat het daadwerkelijk over de StUF berichten gaat. Vraag aan de andere StUF community leden is dan ook of er iemand is die ervaring heeft in de wijze waarop met dit probleem moet worden omgegaan.

[sbrouwer71]

Beste Patrick,

Naar aanleiding van jouw eerste post hierboven: Wanneer een afnemer geen historie registreert, zou ik zeggen dat deze volgens jouw verhaal de verkeerde data met elkaar vergelijkt: de datum ingang van de nummeraanduidingsgegevens zouden natuurlijk best vóór de ingangsdatum van de openbare-ruimtegegevens kunnen liggen. Je zou moeten vergelijken met de ingangsdatumObject. Het feit dat de huidige gegevens van de openbare ruimte later zijn ingegaan dan de gegevens van de nummeraanduiding, wil natuurlijk niet zeggen dat de openbare ruimte niet al eerder bestond. De oplossing zoh hiervoor dus feitelijk moeten zijn dat de afnemende applicatie de datums juist interpreteerd (en zich dan geen zorgen maakt over de situatie van vóór de nullevering), óf je moet de nullevering van historie voorzien.

Maar het antwoord op jouw feitelijke vraag over de cycli lost dit probleem waarschijnlijk ook al op. In StUF-BG is de naam van de openbare ruimte opgenomen in de nummeraanduiding-entiteit (die in StUF Adresseerbaar-Objectaanduiding wordt genoemd). Dit is mede gedaan voor applicaties die behoefte hebben aan de nummeraanduidingen (eigenlijk aan adressen in de vorm van straatnaam, huiisnummer etc.), maar niet aan openbare ruimten, woonplaatsen etc. Deze applicaties hoeven dan niet alle onderliggende entiteiten te volgen om tóch over adressen te beschikken. Het gevolg is dat binnen StUF-BG wijzigingen in openbare-ruimtenamen (en ja, ook in woonplaatsnamen) leiden tot wijzigingen (en bijbehorende berichten) in de aoa-entiteiten. Voor de aoa leidt dit dus tot een nieuwe begindatum geldigheid gegevens (dus een nieuwe cyclus).

Voor een BAG-applicatie betekent dit dat je dus helaas met twee cycli te maken hebt voor één en hetzelfde object. Als nummeraanduiding (richting BAG LV) wijzigt er niets bij een openbare-ruimtenaam- of woonplaatsnaamwijziging, maar als adresserbaar-objectaanduiding binnen StUG-BG krijg je wél een nieuwe datum begin geldigheid. Volgens mij volgt dit overigens rechtstreeks uit de StUF-specificaties en is het geen implementatie-issue. Daarin ben ik het dus niet eens met Robert.