Antwoordberichten bevatten te weinig historieFormeel-elementen

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

9 reacties / 0 nieuw
Sid Brouwer
Antwoordberichten bevatten te weinig historieFormeel-elementen

In de antwoordberichten van StUF-BG is steeds maar één historieFormeel-element opgenomen binnen het object en binnen de historieFormeel-elementen. Dit kan tot problemen leiden, waarbij niet alle historie kan worden opgenomen in het bericht.

Een voorbeeld.

  • Een object wordt opgevoerd met waarde 1 (ingangsdatum M1)
  • Waarde 1 wordt gewijzigd naar waarde 2 (ingangsdatum M3)
  • Waarde 2 wordt gewijzigd naar waarde 3 (ingangsdatum M4)
  • Van waarde 3 wordt de ingangsdatum gecorrigeerd naar M2 (ergens tussen M1 en M3, of gelijk aan M3)

In een Lk09-antwoordbereicht zou in het eerste voorkomen van het object (diem et de waarde M3) een historieFormeel-voorkomen moeten staan waarin de ingangsdatum wordt gecorrigeerd. Daarnaast is er een historieMaterieel-object met waarde 1. Dit historieMaterieel-voorkomen heeft een historieFormeel-element waarin de oude situatie met waarde 1 wordt genoemd, omdat de einddatum geldigheid gegevens gecorrigeerd is. Nergens is nu nog ruimte om de situatie met waarde 2 op te nemen.

Door meerdere historieFormeel-elementen toe te staan (wat ook is beschreven in de StUF-standaard), kan het huidige voorkomen (waarde 3) ook een verwijzing hebben naar de situatie met waarde 2. Immers ook deze situatie wordt gecorrigeerd met de uiteindelijke situatie. Hiermee kan de historie weer volledig worden doorgegeven in het antwoordbericht.

Robert Melskens

Sid,

Voor de duidelijkheid heb ik even de situatie proberen te visualiseren (zie bijlage).

Ik neem aan dat je hier La09 bedoeld i.p.v. Lk09 (die bestaat immers niet) waarvoor op een moment na M4 een vraagbericht is verstuurd (op een moment voor M4 is er immers nog geen sprake van de waarde 3), in de bijlage gevisualiseerd met de rode punt.
Verder kan met een La bericht natuurlijk niets gecorrigeerd worden maar wel de in het verleden verrichte correctie van gegevens worden meegestuurd.

Aan de hand van de visualisatie kun je volgens mij al redelijk bepalen wat er waar in het bericht moet worden opgenomen.
Volgens mij bevat het object element voor dit specifieke voorkomen 2 historieMaterieel elementen en 1 historieFormeel element.

Eerst maar even de historieMaterieel elementen. We hebben er een met de waarde 1 en een met de waarde 3.
In het eerste historieMaterieel element moeten volgens mij 2 historieFormeel elementen worden opgenomen.
Een waarin de situatie van F1 t/m F2 wordt beschreven en een waarin de situatie van F2 t/m F4 wordt beschreven.
In het tweede historieMaterieel element hoeft volgens mij geen historieFormeel element te worden opgenomen.
Ter hoogte van de rode punt bestaan er naar links toe immers 3 vlakken

Dan het historieFormeel element, de standaard zegt daarover:

'Als het gaat om een correctie van de laatst opgevoerde gegevens, dan worden <historieFormeel> elementen opgenomen in het element met de laatst opgevoerde gegevens.'

Er is in dit geval slechts 1 correctie uitgevoerd om tot de laatst opgevoerde gegevens te komen nl. de waarde 3 is weer gecorrigeerd naar 2. Dat betekent dat er slechts 1 historieFormeel element opgevoerd hoeft te worden.
De bovenstaande tekst uit de standaard is in mijn ogen wat ongelukkig omdat lijkt dat het om een correctie van de laatst opgevoerde gegevens gaat. Dat is volgens mij niet het geval. Het gaat er hier volgens mij om correcties die zijn uitgevoerd om tot de laatste status van de gegevens te komen.
Het aantal correcties met verschillende tijdstipRegistratie om tot die laatste status te komen bepalen volgens mij het aantal historieFormeel elementen die in het element met de laatst opgevoerde gegevens moeten worden geplaatst.
Dat betekent dat er inderdaad meerdere 'historieFormeel' elementen moeten kunnen worden opgevoerd in het 'object' element.

Bijlage

visualisatie-antwoordberichten-bevatten-te-weinig-historieformeel-elementen.pdf
Robert Melskens

Dit onderhoudsverzoek is opgevoerd in de onderhoudsverzoeken als ONV0355.
De lijst met onderhoudsverzoeken vind je op: 
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten

Sid Brouwer

Ik bedoelde inderdaad een La09 en gevraagd op het door Robert geschetste moment. Het plaatje dat ik ingedachten had zag er iets anders uit, maar blijkbaar is onze conclusie hetzelfde. Hierbij toch nog even 'mijn' plaatje. De rode pijlen in het plaatje geven de historieFormeel-elementen weer zoals ze volgens het huidige schema zouden moeten worden gelegd. De paarse zou volgens mij moeten worden toegevoegd. De zwarte pijl geeft historieMaterieel weer. Overigens ben ik het niet helemaal eens met de door Robert geschetste structuur van het bericht. Dat zou ook kunnen komen door de verschillende situatieschetsen. Volgens mij is er een root-element met waarde 3 (de actuele situatie), met één historieMaterieel element met waarde 1. Dit historieMaterieel-element (waarde 1) heeft zelf weer een historieFormeel, waarin de oude einddatum wordt opgenomen (van waarde 1). Op het hoogste niveau is er dan nog een historieFormeel-element waarin de oude ingangsdatum van waarde 3 vermeld is. Een element verwijzend naar waarde 2 zou moeten worden toegevoegd, maar daarvoor zijn dus meerdere historieFormeel-elementen noodzakelijk.

Bijlage schetst een situatie waarin meerdere historieFormeel-elementen zouden moeten zijn opgenomen bij een object-element. De structuur van een La09-bericht (na alle mutaties/correcties zoals in hety plaatje geschetst) wordt weergegeven met de pijlen. Het blok rechtsboven vormt de 'root' van het bericht, de zwarte pijl geeft een historieMaterieel-element weer en de rode pijlen de historieFormeel-elementen zoals in de huidige berichtdefinitie. De paarse pijl (een tweede historieFormeel-element binnen hetzelfde object) is noodzakelijk om ook de situatie met waarde 2 in het bericht op te kunnen nemen.

Bijlage

historieFormeel.PNG
Robert Melskens

Tijdens de StUF Expertgroep van 18 februari 2015 gaf Maarten van de Broek aan dat hij het idee had dat dit issue al opgelost zou worden in patch 21. KING heeft hierover contact gehad met Maarten en daarbij is gebleken dat dit niet het geval was. Maarten gaf daarbij aan dat een check op AOA uitwees dat het daar niet is doorgevoerd. Zowel in XXX-antwoord als in in XXX-historieFormeel moet de maxOccurs van het element historieFormeel dus worden gezet op 'unbounded'. Hetzelfde probleem speelt waarschijnlijk in zkn0310.

Tijdens de StUF Expertgroep va 15 april gaf Sid Brouwer aan te denken dat hier indertijd nog wat onduidelijkheid over was en dat het daarom nog niet was doorgevoerd. In de LV-WOZ is dit wel doorgevoerd. KING gaat het in ieder geval meenemen in de volgende patch (22).

Robert Melskens

Probleem
In een 'historieMaterieel' element blijken niet meerdere historieFormeel elementen voor te mogen komen.
Dit had op basis van ERR0355 in patch 22 aangepast moeten worden. Deze situatie is echter over het hoofd gezien.

Oplossing
In 'XXX-historieMaterieel' moeten de 'historieFormeel' elementen volgens mij ook een maxOccurs unbounded krijgen. Ik vermoed dat dit binnen 'XXXYYY-historieMaterieel' en 'XXXYYYZZZ-historieMaterieel' ook geldt.

Robert Melskens

Dit onderhoudsverzoek is opgevoerd in de onderhoudsverzoeken als ONV0408.
De lijst met onderhoudsverzoeken vind je op: 
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten

Robert Melskens

In de bijgaande zip file heb ik in de bestanden 'bg0310_ent_vraagAntwoord.xsd' en 'zkn0310_ent_vraagAntwoord.xsd' bij een aantal XXX-historieMaterieel complexTypes de maxOccurs van het historieFormeel element ingesteld op 'unbounded'.

Bijlage

ONV0408.zip
Robert Melskens

Tijdens de StUF Expertgroep van 17 februari 2016 is het voorstel goedgekeurd.
Het onderhoudsverzoek is omgezet naar een erratum (ERR0408).