Verwerken van kenmerk in een update van een zaak (zakLk01)?

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
Michiel Verhoef
Verwerken van kenmerk in een update van een zaak (zakLk01)?

In het bericht zakLk01 (en daarvan afgeleide berichten als updateZaak_zakLk01 uit de zaak- documentservices) staat onder het zaakobject onder andere het groepselement kenmerk met daarin het kenmerk en de bron.

Er staat echter geen attribuut verwerkingssoort of een element tijdvakGeldigheid of iets dergelijks bij waardoor niet aangegeven kan worden wat met het kenmerk gedaan moet worden. Bij het aanmaken van een zaak is dit vrij eenvoudig, dan moeten de kenmerken toegevoegd worden aan de zaak. Maar hoe werkt dit bij een update? Worden alle bestaande kenmerken verwijderd en alleen de kenmerken die in de "wordt" situatie gegeven worden (het tweede zaak-object dus) opgenomen? Of worden de bestaande kenmerken aangevuld met de huidige? Wordt een reeds bestaand kenmerk overschreven wanneer het in de "wordt" situatie opgenomen is of wordt een tweede kenmerk met dezelfde waarde toegevoegd?

 

 

Mark Paanakker

Bij groepelementen geldt altijd de verwerkingssoort van de omsluitende entiteit (in dit geval die van de zaak). Bij het wijzigen van de zaak moeten dus:

- de kenmerken die in de 'was-situatie' zijn opgenomen en niet meer zijn opgenomen in de 'wordt-situatie' worden beëindigd / verwijderd

- elementen die niet in de 'was' zijn opgenomen maar wel in de 'wordt' worden dus toegevoegd

- elementen die in zowel de 'was' als de 'wordt' zijn opgenomen worden gewijzigd.

- elementen die niet in de 'was' of de 'wordt' zijn opgenomen maar wel in de eigen database aanwezig zijn worden dus niet geraakt.

Michiel Verhoef

Hoi Mark,

Dat is heel erg duidelijk, bedankt voor je antwoord!

 

Maarten van den...

De uitleg van Mark is strijdig met de tweede bullet van paragraaf 5.2.6 Aanvullende regels, waar staat dat als een element meervoudig voorkomt alle voorkomens moeten worden opgenomen. Het laatste gedachtenstreepje in de post van Mark mag dus niet voorkomen. De situatie in huidig bevat alle waarden voor kenmerk. Wat niet in oud voorkomt, maar wel in de database moet dus ook verwijderd worden, zodat de database na afloop uitsluitend de waarden in huidig bevat. Een verschil tussen oud en de database kanaanleiding zijn om het object te synchroniseren.

Alexander Schrijver

Voor de duidelijkheid, in versie 25 van StUF 3.01 staat dit stukje tekst in paragraaf 5.2.4 Het vullen van de <object> elementen, het kopje "Overige regels", daar de tweede bullet.

Alexander Schrijver

Hoe moet het zaaksysteem omgaan met de genoemde situatie, die niet is toegestaan? En waar staat dit beschreven?

Joeri Bekker

Maarten van den Broek schreef:

Het laatste gedachtenstreepje in de post van Mark mag dus niet voorkomen. De situatie in huidig bevat alle waarden voor kenmerk. Wat niet in oud voorkomt, maar wel in de database moet dus ook verwijderd worden, zodat de database na afloop uitsluitend de waarden in huidig bevat.

Volgens mij moeten "huidig" en "oud" worden omgewisseld in de alinea hierboven, waardoor het gelezen moet worden als:

De situatie in oud bevat alle waarden voor kenmerk. Wat niet in huidig voorkomt, maar wel in de database moet dus ook verwijderd worden, zodat de database na afloop uitsluitend de waarden in huidig bevat.

Michiel Verhoef

Volgens mij gaat die uitleg van Maarten over het laatste puntje van Mark en moeten de huidig en oud wel zo gelezen worden als Maarten ze beschreef:

- elementen die niet in de 'was' of de 'wordt' zijn opgenomen maar wel in de eigen database aanwezig zijn worden dus niet geraakt.

'was' is in dit geval 'oud', 'wordt' is in dit geval 'huidig'. Het gaat dus om kenmerken die niet in oud of huidig staan maar wel in de database zijn opgenomen. Deze horen volgens Maarten ook verwijderd te worden. Omdat wanneer je die waarden niet verwijdert de 'huidig' in het ontvangende systeem alsnog afwijkt van de 'huidig' in het verzendende systeem en de gegevens niet overeenkomen.

Joeri Bekker

@Michiel. We praten over hetzelfde :)

Mocht je gelijk hebben, dan vind ik dat redelijk ambigue en gevaarlijk. En, zo kan ik de bewuste paragraaf ook niet interpreteren.