Verwerking vraagbericht voor een Vestiging met unbounded elements

15 reacties / 0 nieuw
Frank van Luijk
Verwerking vraagbericht voor een Vestiging met unbounded elements

Voor een vestiging zijn handelsnamen en activiteitcodes elementen die meerdere keren voor kunnen komen.
Bij een vraagbericht kunnen deze elementen bij de vraagSelectie in zowel gelijk als ook bij vanaf en totEnMet meerdere keren worden gespecificeerd.
Daarnaast is er een sorteeroptie 11 voor vestiging welke aangeeft de vestigingen in het antwoordbericht te sorteren op activiteitcode en handelsnaam.

Vraag 1: Hoe wordt activiteitcode/activiteitcodes en handelsnaam/handelsnamen gebruikt bij het sorteren van vestigingen als sorteeroptie 11 is gespecificeerd?
Vraag 2: Wanneer meerdere activiteitcodes in 'gelijk' van de vraagSelectie worden gespecificeerd, worden dan vestigingen in het antwoord opgenomen indien minimaal 1 activiteitcode aanwezig is bij de vestiging of moeten alle activiteitscodes uit de vraagSelectie bij de vestiging aanwezig zijn?
Aanvullend: Hoe hiermee om te gaan indien meerdere activiteitcodes bij de vanaf en totEnMet zijn gespecificeerd in de vraagSelectie?
Vraag 3: Wanneer één of meerdere activiteitscodes zijn gespecificeerd in de vraagSelectie, worden dan in het antwoord bij de vestigingen alle activiteiten vermeld die bij de vestiging zijn geregistreerd?

Extra:
Mening van John Rooijakkers heb ik ontvangen; die is als volgt:
Vraag 1: Vreemd om te kunnen sorteren op elementen met cardinaliteit >1.
Vraag 2 aanvullend: als minimaal een activiteitcode voldoet aan de vraagSelectie wordt de vestiging meegenomen in het antwoordbericht.
Vraag 3: alle activiteiten van een vestiging moeten vermeld worden omdat de scope losstaat van de vraagSelectie.

Frank van Luijk

Graag zou ik een reactie op het bovenstaaande zien van KING.
Aanvullend ben ik erg benieuwd hoe dit in BG 03.20 aanwezig is.
Kan iemand mij hier informatie over verschaffen?

Robert Melskens

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.

Bijlage

vesLv01.png
Robert Melskens


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

Frank van Luijk

Hallo Robert,

Fijn dat er m.b.t. vraag 1 een onderhoudsverzoek is opgevoerd. Mijn dank!
Enig idee wanneer hierover meer bekend zal zijn?
Antwoord op vraag 3 is duidelijk. Ook daarvoor bedankt.
Voor vraag 2 vemoed ik dat ik toch in de 'restricted' definitie heb gekeken. Is duidelijk dat er per gelijk, vanaf en totEnMet maar 1 specificatie mogelijk is.

Robert Melskens

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.
 

Frank van Luijk

Hoi Robert,

heel fijn! Nogmaals bedankt!

Robert Melskens

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).

Robert Melskens

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.

Ruud Kathmann

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.

Robert Melskens

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.

Maarten van den...

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.

Robert Melskens

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

Robert Melskens

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

Bijlage

stuf0302-rev2959-2016-12-03_RFC0417.pdf
Robert Melskens

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