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.
Navraag leert dat ActualiseerZaakstatus bedoeld is als ‘simpel’ bericht om snel een statuswijziging door te geven.
Feitelijk moet je namelijk geen STA object wijzigen maar moet je een nieuw STA object toevoegen en relateren aan ZAK. Dan is mutatiesoort wel een T?
Bij mutatiesoort="T" gaat het om toevoegen van een object, in het geval van een zakLk01 bericht dus om het toevoegen van een zaak (ZAK). We willen hier niet een zaak toevoegen, maar een relatie naar een status toevoegen aan de zaak. Voor het toevoegen van een relatie wordt voor het ZAK object mutatiesoort="W" gebruikt, met op de relatie verwerkingssoort="T".
Dus dan zou het schema moeten afdwingen dat:
1. parameters/mutatiesoort="W"
2. object@verwerkingssoort="W"
3. object/heeft@verwerkingssoort="T"
Klopt. En er moeten dus ook twee objecten zijn. Bovendien schrijven de StUF specificaties hier voor:
"Een nieuwe relatie is relevant geworden binnen de topfundamenteel. In het 'oude' <object> element wordt de relatie-entiteit opgenomen met de attributes StUF:entiteittype, StUF:verwerkingssoort=”T” en StUF:noValue=”geenWaarde” en met een lege elementinhoud. De relevant geworden relatie wordt met StUF:verwerkingssoort=”T” opgenomen in het 'huidige' <object> element."
Maar dit voorschrift wordt momenteel niet ondersteund in de STUF-ZKN schema's. Het bericht valideert alleen als in het 'oude' object een relatie-entiteit wordt opgenomen met daarin een lege gerelateerde. Het is dus de vraag of de nieuwe ZDS 1.2 schema's de StUF-specificaties gaan volgen of de praktijk van de huidige StUF-ZKN schema's.
Dit is een lastige: oorspronkelijk zijn de Zaak- Documentservices natuurlijk een toepassing van StUF-ZKN maar ik zou eigenlijk verwachten dat de berichten dan ook de StUF regels zouden moeten volgen.
Voor beide richtingen is iets te zeggen.
Een derde oplossing zou kunnen zijn het bericht actualiseerZaakstatus te laten vervallen en het bijwerken van een zaak status via een updateZaak bericht te doen.
Wat zou de voorkeur van de werkgroep hebben dan wel wat sluit het beste aan op de praktijk?
Edit: ik realiseer me dat optie 3 een heel radicale breuk met voorgaande versies lijkt maar door het gebruik van specifieke berichten is dit mijns inziens toch al het geval.
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 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"/>
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"
Bovenstaande wijziging geldt ook voor het updateZaak_ZakLk01 bericht.
Zojuist is een blokkerende fout geconstateerd: het hoofdobject (de zaak) kan volgens het xsd schema geen tijdvakGeldigheid en tijdstipRegistratie bevatten terwijl dit volgens de StUF regels wel nodig is.
Aangepaste schema's zullen zsm. op GEMMA Online gepubliceerd worden.
De schema's waarin bovenstaande fout opgelost is staan gepubliceerd op GEMMA Online