Project

Profile

Help

ERR #488351

closed

Support #488350: Compliancy testsets ZDS 1.2

Fout in schema ZDS 1.2 voor actualiseerZaakstatus_ZakLk01

Added by Frank Samwel over 7 years ago. Updated about 7 years ago.

Status:
Gesloten
Priority:
Normal
Category:
opgenomen in patch
Sprint/Milestone:
Start date:
02/19/2017
Due date:
02/21/2017
% Done:

100%

Estimated time:
(Total: 0:00 h)
Behandeld in overleg:

Description

In de schema’s voor ZDS 1.2 staat voor actualiseerZaakstatus_ZakLk01:
<complexType name="ActualiseerZaakstatus-ZAK-Lk01">
<sequence>
<element name="stuurgegevens" type="StUF:ZAK-StuurgegevensLk01"/>
<element name="parameters" type="StUF:ParametersLk01"/>
<element name="object" type="ZKN:ActualiseerZaakstatus-ZAK-kennisgeving" nillable="true"/>
</sequence>
</complexType>

Dit betekent dat er in dit bericht maar één voorkomen van object mag zijn. Dat klopt denk ik niet. Dit betekent m.i. dat alleen mutatiesoort en verwerkingssoort “T” mogelijk is. En dat zou betekenen dat een nieuwe zaak (niet een zaaktype) wordt toegevoegd, niet een nieuwe zaakstatus.

Zie ik dit verkeerd? Of moet dit worden aangepast in de schema’s?


Sub-issues 1 (0 open1 closed)

ERR #488598: actualiseerZaakstatus heeft geen kerngegevens en geen metagegevensGeslotenMichiel Verhoef02/19/201702/21/2017

Actions
Actions #1

Updated by Michiel Verhoef over 7 years ago

  • Status changed from Nieuw to In behandeling

Zo te zien kon je wel eens gelijk hebben. Alleen is het bericht dan gewoon van een compleet verkeerd type want het doel van dit bericht is volgens mij een compact bericht waarmee een nieuwe status van een zaak doorgegeven wordt.

Ik ga dit eens met Jan bespreken, ik ben benieuwd hoe hij dit indertijd bedacht heeft.

Actions #2

Updated by Frank Samwel over 7 years ago

Graag zou ik ook zien dat het schema alleen relevante elementen voor de actualiseerZaakstatus toestaat. Nu zijn alle zaak-elementen toegestaan in het bericht. Dus kan via actualiseerZaakStatus_ZakLk01 van alles aan de zaak worden gewijzigd, zoals ander zaakobject, heeft betrekking op, heef als belanghebbende, enz.

Actions #3

Updated by Michiel Verhoef over 7 years ago

  • Sprint/Milestone set to ZDS 1.2 Patch (2017 Q1)

Reactie Jan:

"ActualiseerZaakstatus in inderdaad bedoeld als ‘simpel’ bericht om snel een statuswijziging door te geven. Op dit punt heeft natuurlijk in middels voortschrijdend inzicht plaatsgevonden. Dat bleek ook in afgelopen werkgroep met discussie over functionaliteit slechts op één manier toestaan.

Ik vraag mij af of bericht daadwerkelijk fout is. Feitelijk moet je namelijk geen STA object wijzigen maar, moet je een nieuw STA object toevoegen en relateren aan ZAK. Dan is mutatiesoort volgens mij wel een T?"

Actions #4

Updated by Frank Samwel over 7 years ago

Naar mijn idee is het bericht wel fout (zoals we net hebben besproken). Bij mutatiesoort="T" gaat het om toevoegen van een object, in het geval van een zakLk01 bericht dus om het toevoegen van een zaak. We willen hier niet een zaak toevoegen, maar een relatie naar een status toevoegen aan de zaak. Voor het toevoegen van een relatie wordt mutatiesoort="W" gebruikt, met op de relatie verwerkingssoort="T".

Dus zou ik graag zien dat het schema afdwingt dat:
1. parameters/mutatiesoort="W"
2. object@verwerkingssoort="W"
3. object/heeft@verwerkingssoort="T"

Actions #5

Updated by Michiel Verhoef over 7 years ago

  • Private changed from No to Yes
Actions #6

Updated by Michiel Verhoef over 7 years ago

  • Private changed from Yes to No
Actions #7

Updated by Michiel Verhoef over 7 years ago

Roel de Bruin schreef:

"In principe moet het StUF-ZKN schema de specificaties volgen. Volgens mij zou het schema dus moeten worden aangepast in een patch. Het probleem is echter veel groter want ik zie dat in de schema's van zowel StUF-ZKN als StUF-BG de gerelateerde onder een relatie altijd verplicht is. Dat zou dus een systematische afwijking van de specificaties zijn, tenzij ik de specificaties verkeerd interpreteer.

Wellicht is dit dus iets dat met de beheerders van deze schema's c.q. met de StUF expertgroep moet worden opgenomen. "

Dit heb ik doorgestuurd aan Henri en Robert met de vraag of de bevinding van Roel correct is en StUF ZKN dus niet aan StUF voldoet.

Actions #8

Updated by Michiel Verhoef over 7 years ago

Robert Melskens schreef:
_Dit issue is al eerder opgevoerd in deze discussie en ook toen is vastgesteld dat het probleem ook bij de andere sectormodellen speelt en op basis daarvan in het onderhoudsverzoek ONV0377 opgevoerd. Tijdens de StUF Expertgroep van 20 januari 2016 is echter besloten dat onderhoudsverzoek af te voeren omdat je de gerelateerde wel weg kunt laten als je het attribute xsi:nil="true" toevoegt zoals het onderstaande fragment aantoont:

<ZKN:heeftBetrekkingOp StUF:entiteittype="ZAKOBJ" StUF:verwerkingssoort="E" StUF:noValue="geenWaarde" xsi:nil="true"/>_

Roel de Bruin schreef:
_Mee eens. Ik had over het hoofd gezien dat de relatie nillable is.

Er is dus op dit punt geen probleem. En de conclusie van Michiel is juist dat de schema's moeten afdwingen dat er twee objecten zijn (oud en nieuw) en dat:

1. parameters/mutatiesoort="W"
2. object@verwerkingssoort="W"
3. object/heeft@verwerkingssoort="T"
_

Actions #9

Updated by Michiel Verhoef over 7 years ago

Bovenstaande wijziging geldt dan ook voor het updateZaak_zakLk01 bericht

Actions #10

Updated by Michiel Verhoef over 7 years ago

  • Status changed from In behandeling to Oplossing uitgewerkt
Actions #11

Updated by Michiel Verhoef about 7 years ago

  • Category set to opgenomen in patch
Actions #12

Updated by Michiel Verhoef about 7 years ago

  • Tracker changed from Bug to ERR
Actions #13

Updated by Michiel Verhoef about 7 years ago

  • Status changed from Oplossing uitgewerkt to Gesloten

Also available in: Atom PDF