Verwerking vraagbericht voor een Vestiging met unbounded elements

Dag Frank,

Ik vrees dat je voor het vraagbericht van Vestiging in het verkeerde schema kijkt.
In de bijlage zie je een screenprint van de structuur van het vesLv01 bericht.
Zoals je ziet kunnen de handelsnaam en activiteitcode maar 1 keer voorkomen.

• Wat vraag 1 betreft raak je denk ik echter toch een goed punt. De sortering geeft aan dat er gesorteerd moet worden op handelsnaam en activiteitcode maar niet op welk voorkomen van deze elementen in de antwoordberichten indien deze meer dan 1 keer voorkomen. In een antwoordbericht mogen deze elementen immers wel vaker dan 1 keer voorkomen. Moeten dan de hoogste waardes van deze elementen in de berichten gebruikt worden als basis voor de sortering of juist de laagste of nog geheel anders?
  In de StUF standaard kan ik daarover niets vinden. Ik zal daarom m.b.t. dit punt een onderhoudsverzoek inschieten.
• Vraag 2 komt in een ander daglicht te staan. Er kan dus maar 1 de activiteitcode in het 'gelijk' element van de vraagSelectie worden gespecificeerd. Daarmee worden alleen vestigingen in het antwoord opgenomen waarvan de activiteitcode gelijk is aan de gespecificeerde activiteitcode. Ook bij vanaf en totEnMet kan maar 1 activiteitcode gespecificeerd worden waarmee vestigingen worden opgevraagd die een activiteitcode hebben die valt binnen de daarmee bepaalde range.
• Wat vraag 3 betreft heeft John gelijk.

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

Hoi Frank,

In de komende patch kan een wijziging n.a.v. het onderhoudsverzoek niet meer mee.
Deze patch wordt als het goed is volgende week woensdag goedgekeurd.
De eerstvolgende patch wordt volgens plan op 1 april gepubliceerd.
Daar zou een eventuele correctie in mee kunnen gaan.
Eventueel kan Ton Timmermans deze discussie nog in de StUF Expertgroep aanzwengelen.
 

Tijdens de StUF Expertgroep van 16 maart 2016 gaf Ton nogmaals aan dat nu niet goed gedefinieerd is hoe te sorteren. Maarten zei daarop dat je vrij bent om te sorteren zoals je goeddunkt. Het is nu niet gedefinieerd maar op basis van een RFC zouden we het in de toekomst wel kunnen definiëren. Ton gaf aan toch graag te horen hoe dit nu moest worden toegepast. De StUF Expertgroep heeft uiteindelijk echter toch besloten dit onderhoudsverzoek om te zetten naar een RFC (RFC0417).

Tijdens de StUF Expertgroep van 19 oktober 2016 is voorgesteld om het sorteren op meervoudige velden niet meer toe te staan.
Daar werden echter nog wat haken en ogen aan geconstateerd. Uitwerking van dit RFC legt echter allerlei lasten bij
leveranciers neer. Uiteindelijk is besloten dit issue op de agenda van de komende StUF Expertgroep te zetten.

Bij de LV WOZ hebben we dit sorteren gewoon geïmplementeerd door sommige antwoorden meervoudig op te nemen. Bijvoorbeeld we moeten WOZ-objecten opleveren, gesorteerd op eigenaar. Dan wordt een WOZ-object met drie eigenaren driemaal in het antwoord opgenomen, namelijk op iedere plek waar de eigenaar in de correcte sorteervolgorde moet voorkomen.

Het kunnen werken met deze sorteringen die tot meervoudige plaatsen in de sorteervolgorde is voor ons wel belangrijk. Wij willen dus wel graag dat deze werkwijze "toegestaan" blijft.

Tijdens de StUF Expertgroep van 21 december 2016 is dit RFC besproken en zijn de EG-leden het er over eens dat de kaders van de oplossing van het probleem in de onderlaag moeten worden geschetst. Maarten is gevraagd met een voorstel te komen.

Ruud Kathmann noemt als voorbeeld van een sortering op meervoudig voorkomende criteria het tonen van WOZ-objecten met een sortering op eigenaar, een gerelateerde van het WOZ-object die onderdeel is van het sectormodel bg0310. Het WOZ-object is onderdeel van het sectormodel woz0312. Dit voorbeeld is een goed uitgangspunt voor de analyse.

Omdat de gerelateerde eigenaar en het WOZ-object in verschillende sectormodellen zitten, is het gevaarlijk om te vooronderstellen dat ze beide in dezelfde database zijn opgeslagen. Voor het sectormodel zkn0310 speelt dit ook met zijn relaties naar entiteiten in het sectormodel bg0310. Het sectormodel bg0310 wordt ondersteund door het gegevensmagazijn basisgegevens en het sectormodel zkn0310 door het gegevensmagazijn zaken. Volgens de GEMMA architectuur zijn dit twee verschillende referentiecomponenten die onafhankelijk van elkaar geïmplementeerd moeten kunnen worden. Bij onafhankelijke implementatie kan niet verondersteld worden dat de twee gegevensmagazijnen elkaars database via SQL kunnen benaderen. De gegevensmagazijnen kunnen elkaar wel bevragen met StUF vraag/antwoordberichten.

In het voorbeeld van Ruud Kathmann zal je eerst een aantal natuurlijke personen ophalen met de gespecificeerde sortering voor de gerelateerde eigenaar. Je kunt de selectie niet beperken tot natuurlijke personen die eigenaar zijn van een WOZ-object, omdat deze eigenschap niet voorkomt in het RSGB bij een natuurlijk persoon. Voor de opgehaalde personen kijk je vervolgens of ze eigenaar van een WOZ-object zijn en zo ja, dan voeg je dat WOZ-object toe aan de lijst met terug te geven WOZ-objecten. Je haalt net zo lang personen op tot je het gevraagde aantal WOZ-objecten hebt gevonden.

In het eerste antwoord zou je nog kunnen nagaan of een WOZ-object dubbel voorkomt en dit eventueel kunnen verwijderen, maar in een vervolgvraag weet je niet welke WOZ-objecten er al eerder zijn teruggegeven en is het dus mogelijk, dat een WOZ-object dat al eerder is teruggegeven opnieuw wordt teruggegeven in het antwoord bij een andere eigenaar. Met StUF vraag/antwoord is het dus niet mogelijk om een WOZ-object dat meer dan één eigenaar heeft, slechts één keer terug te geven.

Dit gedrag gaat in tegen de uitgangspunten van SQL: Je vraagt om een verzameling WOZ-objecten en in de teruggegeven verzameling mag een element (= WOZ-object) maar één keer voorkomen. Mijn gevoel is dat dit niet ingaat tegen de verwachting die je hebt van een lijst in de gebruikersinterface. Daar verwacht je toch dat je bij een volgende eigenaar in de lijst het WOZ-object ziet, waar deze eigenaar van is en het maakt je niet uit dat dezelfde WOZ-object al eerder bij een andere eigenaar voorkwam.

Het lijkt me dan ook verstandig om het door Ruud beschreven gedrag voor te schrijven vanaf StUF 0302 voor sorteringen op relaties en gerelateerden die meervoudig kunnen voorkomen.

Een volgende vraag is nu hoe om te gaan met sorteringen op elementen die meervoudig kunnen voorkomen binnen het gevraagde object. Dit is de oorspronkelijk door Frank van Luijk gestelde vraag. Voor een lijst met maatschappelijke activiteiten lijkt het voor een gebruiker weer het meest intuïtieve om per handelsnaam de maatschappelijke activiteit eventueel dubbel op te nemen. Bij enkelvoudig opnemen sta je voor de vraag op welke van de meervoudige handelsnamen je sorteert. Het principe van dubbel opnemen maakt ook de implementatie van selecties op de handelsnaam het eenvoudigst.

Tijdens de StUF Expertgroep van 18 januari 2017 is dit RFC goedgekeurd. In een lijst met resultaten mag een object dus meerdere keren voorkomen.

Hierbij de uitwerking van dit RFC ter goedkeuring tijdens de StUF Expertgroep van 15 februari 2017.

Tijdens de StUF Expertgroep van 15 februari 2017 is de uitwerking van dit RFC goedgekeurd.