Naar aanleiding van vragen over het gebruik van attribuut verwerkingssoort en de vulling van de waarden T of I in de zaak- documentservices is een overzicht gemaakt ter aanvulling op de bestaande regels uit de StUF standaard en de koppelvlak specificatie.
Let op, in een aantal kolommen staat "T of I". In dat geval geldt:
De geldende StUF regels zijn van toepassing en de TSA moet een I sturen als hij zeker kan weten dat het gerelateerde item al bestaat in het zaaksysteem, en anders een T. Overigens blijft nog steeds de regel van kracht dat wanneer een T gestuurd wordt terwijl het gerelateerde item al bestaat deze als een I moet worden behandeld. Daar mag een bericht dus niet op afgekeurd worden.
Onderstaande vuistregel is van toepassing voor de Zaak- Documentservices/Zaakgericht werken en de kennisgevingsberichten. Mogelijk ook voor andere berichten maar daar is niet naar gekeken en er kunnen dan ook geen rechten aan ontleend worden.
De simpele vuistregel is wanneer een consumer een gegeven zelf al aan de provider heeft aangeboden of wanneer dat gegeven bijvoorbeeld uit een geldende zaaktypecatalogus komt dit gegeven bekend moet worden verondersteld bij de provider. In dat geval moet een I gebruikt worden.
Het overzicht is zowel voor versie 1.1.x als versie 1.2 van toepassing. Gaarne van alle belanghebbenden reacties en commentaar, voor 15 maart 2019. Daarna zal dit document als addendum, aanvulling op de bestaande 1.1.x en 1.2 versies van de Zaak- Documentservices en de StUF standaard op GEMMA Online geplaatst worden.
Hierbij de reactie vanuit PinkRoccade Samenlevingszaken:
Tabblad creeerZaak en updateZaak
Tabblad updateZaak
Tabblad actualiseerZaakstatus
Tabblad voegZaakdocumentToe
Tabblad maakZaakdocument
Tabblad updateZaakdocument
Met vriendelijke groeten,
Julian Cissen en John Rooijakkers.
PS1: wellicht goed om op te merken dat soms ook andere verwerkingssoorten dan alleen "T" en/of "I" zijn toegestaan (bv "R" voor het vervangen van een relatie.
PS2: mogelijk dat er vanuit andere PinkRoccade units nog aanvullingen volgen.
Reactie op bijdrage John Rooijakkers
"De object.heeft (statustype) relatie bij de creeerZaak en updateZaak operaties is niet logisch. Deze relatie hoort niet bij deze operaties thuis maar bij actualiseerZaakstatus."
-> Zaakstatus is in creerZaak en updateZaak wel toegestaan volgens de standaard ("Elementen die niet zijn opgenomen in de tabellen, mogen wel voorkomen in een kennisgevingsbericht zolang dat bericht voldoet aan de StUF-ZKN-schema’s"). Aangezien onze applicaties de zaakststatus versturen in creeer- en updateberichten is het wel heel zinnig ook over dit element duidelijkheid te hebben in dit addendum.
"De relatie object.heeftAlsInitiator heeft nu “T of I” maar kan alleen “I” zijn. Waarde “T” impliceert dat het voor kan komen dat een zaak zonder een initiator mag worden toegevoegd.".
-> Ik heb hier twee vraagtekens bij. Belangrijkste is of je de verplichtheid van een element moet afdwingen via verwerkingssoort. De meeste zaaksystemen maken de zaak terecht niet aan als er geen initiator is in creeerZaak. En als de zaak wel is aangemaakt met initiator wordt "T of I" geinterpreteerd als "I". De door John voorgestelde aanscherping lost dus geen probleem op maar creeert wel een nieuw probleem omdat wij onze software weer moeten aanpassen. Mijn tweede vraagteken: is het mogelijk een inititiator te wijzigen door tegelijk in één updateZaakbericht de oude initiator te verwijderen en de nieuwe toe te voegen? Dan zou T hoe dan ook moeten kunnen.
"Tabblad voegZaakdocumentToe Verwerkingssoort bij object moet “T” zijn."
-> Dit was ons ontwikkelteam ook al opgevallen. Moet inderdaad gewijzigd worden.
> Tabblad creeerZaak en updateZaak
> De object.heeft (statustype) relatie bij de creeerZaak en updateZaak operaties is niet logisch. Deze relatie hoort niet bij deze operaties thuis maar bij actualiseerZaakstatus.
Het is toegestaan de status op te nemen in de berichten, zowel volgens het specificatie document als in de xsd schema's. Voor providers die aangeven het volledige RGBZ te ondersteunen is het ondersteunen van de status een verplichting. Voor de volledigheid is dit dan ook uitgewerkt.
> Tabblad updateZaak
> Bij diverse relaties staat als verwerkingssoort alleen “T” maar dit moet “T of I” zijn. Met uitzondering van object.isVan en object.heeftAlsInitiator (zie ook de volgende opmerking).
> De relatie object.heeftAlsInitiator heeft nu “T of I” maar kan alleen “I” zijn. Waarde “T” impliceert dat het voor kan komen dat een zaak zonder een initiator mag worden toegevoegd.
Het is mogelijk dat een initiator gewijzigd wordt. In dat geval moet een nieuwe initiator toegevoegd kunnen worden. Nergens wordt gesuggereerd dat een zaak zonder initiator mag worden toegevoegd. Initiator is een verplicht gegeven in creeerZaak. Volgens mij is dit ook wat Johannes aangeeft.
> Tabblad actualiseerZaakstatus
> Bij de relatie object.heeft.gerelateerde is nu alleen “I” toegestaan. Gezien vanuit een centrale ZTC waarin per zaaktype alle statussen (vooraf) zijn gedefinieerd is dit correct. In de praktijk zien we regelmatig dat een statustype wordt aangeleverd dat (nog) niet in de ZTC is opgenomen omdat niet alle zaak afhandelende applicaties een koppeling hebben met de centrale ZTC. Het toestaan van waarde “T” biedt hier daarom flexibiliteit en robuustheid. Als alleen waarde “I” wordt toegestaan zal dit in de praktijk regelmatig leiden tot uitval van berichten omdat het statustype (nog) onbekend is in de ZTC.
Het op deze manier mogen toevoegen van een zaaktype kan potentieel leiden tot fouten (ad hoc toevoegen van een zaaktype vanwege een typefout) en ook functioneel vind ik het raar. Dat de zaakafhandelende applicatie geen toegang heeft tot een centrale ZTC betekent in mijn ogen alleen dat het relevante deel van de centrale ZTC in kopievorm in de vakapplicatie bekend is. Maar inhoudelijk zouden die zaaktypen overeen moeten komen. In ieder geval zouden in het zaaksysteem en in de afhandelapplicatie geen zaaktypen voor mogen komen die niet in de ZTC (of de in het ZS of afhandelapplicatie ingerichte zaaktypen) staan.
De ZTC is dus de bron waar de zaaktypen in staan beschreven die gebruikt mogen worden. Het is geen registratiesysteem van zaaktype gegevens die ooit eens door een afhandelapplicatie aangeboden zijn. Dat het om technische redenen niet altijd mogelijk is om alle afhandel applicaties de zaaktypen uit een ZTC te laten halen betekent niet dat het zaaktype aan het zaaksysteem toegevoegd mag worden door de afhandelapplicatie. Dat moet bij de inrichting door beheer gebeuren, niet door een kennisgevingsbericht van een afhandelapplicatie.
> De relatie isGezetDoor moet “T of I” zijn. Datzelfde geldt voor de gerelateerde (medewerker of organisatorischeEenheid).
> De waarde "I" bij de relatie heeft en bij de relatie isGezetDoor lijkt niet logisch binnen de context van het actualiseren van de zaakstatus.
Het bericht actualiseerZaakstatus is een zakLk01 kennisgeving en volgens de StUF regels moet bij een wijziging de oude en nieuwe situatie meegegeven worden. De oude, voorgaande statussen van een zaak moeten dan ook met "I" worden meegegeven. De nieuwe, huidige status van een zaak wordt met een "T" toegevoegd.
> Tabblad voegZaakdocumentToe
> Verwerkingssoort bij object moet “T” zijn.
Wanneer een relatieklasse zaakdocument aangemaakt wordt waarin een reeds bestaand document gekoppeld wordt aan een reeds bestaande zaak (anders dan de zaak waar het document al aan gekoppeld is, het document hoort dus bij twee zaken) is er volgens mij sprake van verwerkingssoort ="I"
> Tabblad maakZaakdocument
> Verwerkingssoort bij object moet “T” zijn.
Zie de reactie bij voegZaakdocumentToe
> Tabblad updateZaakdocument
> De relatie object.isRelevantVoor heeft nu “T of I” maar kan alleen “I” zijn. Waarde “T” impliceert dat het voor kan komen dat een document zonder een zaak mag worden toegevoegd.
Het idee was te beschrijven dat een bestaand document wat al gekoppeld is aan een zaak ook aan een andere zaak gekoppeld wordt. Maar nu ik er zo over nadenk moet je dan een nieuwe relatieklasse zaakdocument toevoegen waarin verwezen wordt naar een bestaande zaak en een al bestaand document. Dan is verwerkingssoort "I" van toepassing, het document bestaat immers al in het DMS en er wordt alleen een relatieklasse zaakdocument (= koppeling tussen Zaak en Document) aangemaakt.
Dit pas ik dus aan.
Tav: Het bericht actualiseerZaakstatus is een zakLk01 kennisgeving en volgens de StUF regels moet bij een wijziging de oude en nieuwe situatie meegegeven worden. De oude, voorgaande statussen van een zaak moeten dan ook met "I" worden meegegeven. De nieuwe, huidige status van een zaak wordt met een "T" toegevoegd.
Het betreft hier wel het wijzigen van de zaak (topfundamenteel) maar het toevoegen van de status relatie. Hierbij moet in de oude tak een lege relatie met verwerkingssoort T worden opgenomen en in de nieuwe tak de nieuwe status met verwerkingssoort T. Als je een status wil vervangen (maar dat speelt hier m.i. niet) dan gebruik je verwerkingssoort R.
Volgens het schema is het opnemen van de status in een creeerZaak en updateZaak inderdaad toegestaan. Maar als dat ook volgens het ZS-DMS koppelvlak wordt toegestaan, vraag ik me af waarom daarin überhaupt het actualiseerZaakstatus bericht is opgenomen. De bedoeling van het ZS-DMS koppelvlak was toch om een scherper koppelvlak te bieden dan het sectormodel Zaken?
Dit is absoluut een heel valide vraag waar ik helaas alleen naar het antwoord kan gissen. Mogelijk was het idee om een klein, compact bericht te gebruiken voor die situaties waarin alleen de zaakstatus bijgewerkt moest worden. Aan de andere kant, het is vrij onzinnig om wanneer een zaak toch bijgewerkt moet worden met updateZaak in dit bericht niet de status mee te geven als die ook aangepast is. Om daar een extra updateZaakstatus bericht voor te moeten gebruiken geeft alleen maar extra nodeloos berichtenverkeer.
De bedoeling was ongetwijfeld goed maar StUF is niet het goede vehikel gebleken om kleine, scherpe standaarden te maken voor dit soort toepassingen. We kunnen hier discussie over gaan voeren maar we zijn het er allemaal denk ik wel over eens dat op dat vlak Zaak- Documentservices niet heeft kunnen bieden wat iedereen voor ogen had. Met de nieuwe Zaakgerichtwerken API's lijkt dit wel goed te gaan. Tenminste, dat zijn de geluiden die ik hoor.
Naar aanleiding van de opmerkingen van zowel Pink Roccade als Roxit is de verwerkingssoort in de berichten voegZaakdocumentToe en maakZaakdocument aangepast. Het overzicht is vanaf vandaag te vinden op GEMMA Online bij de documentatie van de Zaak- Documentservices.
Zoals altijd geldt dat niets in beton gegoten is dus mochten er nog fouten of omissies in staan, laat dit vooral weten!