ERR #488351
closed
Support #488350: Compliancy testsets ZDS 1.2
Fout in schema ZDS 1.2 voor actualiseerZaakstatus_ZakLk01
100%
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?
Updated by Michiel Verhoef almost 8 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.
Updated by Frank Samwel almost 8 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.
Updated by Michiel Verhoef almost 8 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?"
Updated by Frank Samwel almost 8 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"
Updated by Michiel Verhoef almost 8 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.
Updated by Michiel Verhoef almost 8 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"
_
Updated by Michiel Verhoef almost 8 years ago
Bovenstaande wijziging geldt dan ook voor het updateZaak_zakLk01 bericht
Updated by Michiel Verhoef almost 8 years ago
- Status changed from In behandeling to Oplossing uitgewerkt
Updated by Michiel Verhoef almost 8 years ago
- Category set to opgenomen in patch
Updated by Michiel Verhoef over 7 years ago
- Status changed from Oplossing uitgewerkt to Gesloten
.