Tijdens een implementatie van de koppeling tussen een ZSDMS service consumer en provider, is een discussie ontstaan over de vraag wat voor de consumer en provider het criterium is dat een zaak daadwerkelijk is afgesloten en dat geen wijzigingen meer mogen worden aangebracht in de zaak (en zaakdocumenten) en het proces van archiveren vervolgens kan starten.
Bij de huidige implementaties sluiten wij als consumer een zaak af via een updateZaak met daarin de einddatum en het resultaat van de zaak. Eventueel mag het resultaat ook eerder worden doorgegeven dan de einddatum van de zaak. Na deze updateZaak kunnen geen gegevens meer worden gewijzigd in de zaak en kan dus ook geen status meer worden gewijzigd. Het zetten van een einddatum is in deze werkwijze dus het criterium om de zaak af te sluiten en het proces van archiveren in gang te zetten.
Het zaak-document koppelvlak beschrijft een werkwijze om een zaak af te sluiten door het zetten van een eindstatus. Bij actualiseerZaakstatus staat op pagina 25: "Indien de nieuwe status gelijk is aan de eindstatus (zoals vastgelegd in de ZTC van de gemeente) dient het ZS de betreffende zaak af te sluiten." En op pagina 26 staat dat het zaaksysteem “aan de hand van informatie uit de ZTC moet bepalen of een status een eindstatus van een zaak is en indien een zaak een eindstatus bereikt, het proces in gang te zetten om de zaak af te sluiten. Het gaat hierbij onder meer om archivering van zaakgegevens." Het Zaak Document koppelvlak beschrijft niet de samenhang tussen het vastleggen van de einddatum en het resultaat bij de zaak en het zetten van de eindstatus.
De twee genoemde werkwijzen zijn niet verenigbaar omdat enerzijds, na het zetten van de einddatum en het resultaat via een updateZaak bericht, door de consumer geen actualiseerZaakstatus bericht meer kan worden verzonden met daarin de eindstatus. Anderzijds kan na het zetten van de eindstatus via een actualiseerZaakstatus bericht, door de provider geen updateZaak bericht meer worden verwerkt met daarin de einddatum en het resultaat.
De consumer en provider willen bij voorkeur niet meerdere implementatievormen ondersteunen en zoeken dus naar de correcte cq beoogde werkwijze. Indien er niet één correcte werkwijze is, is het de vraag of (alle) consumers beide werkwijzen moeten ondersteunen of dat (alle) providers beide werkwijzen moeten ondersteunen.
De concrete vragen zijn daarom:
- zegt het RGBZ informatiemodel wellicht iets over het criterium dat bepaalt dat een zaak is afgesloten?
- op welke werkwijze(n) kan een zaak worden afgesloten volgens de standaard: met actualiseerZaakstatus, met updateZaak of allebei?
- kan een zaak volgens de standaard eerst naar een eindstatus worden gezet en daarna nog een update krijgen met daarin de einddatum (en resultaat)?
- kan een zaak volgens de standaard eerst een einddatum (en resultaat) krijgen en daarna een eindstatus?
Dit onderwerp is op de agenda voor de komende teleconferentie van 17 november 2016 geplaatst. Om alvast wat voer voor discussie te hebben reageer ik op de vragen van John:
Dit ga ik nog na maar mijn gevoel zegt me dat een zaak afgesloten is wanneer deze de eindstatus heeft bereikt zoals deze in de ZTC van de gemeente is vastgelegd.
Wanneer het afsluiten van een zaak alleen het aanpassen van de status betreft kan allebei. Wanneer er ook andere attributen van de zaak aangepast moeten worden kan dat alleen met updateZaak.
Wanneer een zaak afgesloten is kan deze niet meer gewijzigd worden.
Ik zou niet weten waarom niet alleen de vraag is of dat handig is. Het afsluiten van een zaak zou ik liefst in één bericht doen zodat alle wijzigingen op hetzelfde moment doorgegeven worden. Dus met een updateZaak bericht.
Persoonlijk zie ik het bijwerken van de zaakstatus ook als updateZaak en zou ik liever dat bericht gebruiken om de zaakstatus aan te passen in plaats van hiervoor apart het actualiseerZaakstatus bericht. Hoe ziet de werkgroep dit?
Groeten,
Michiel
Het RGBZ doet geen expliciete uitspraken over de laatste zaakstatus. Maar, een status geeft een bereikte mijlpaal weer, niet een onderhanden fase oid. Na de laatste status is er geen volgende meer. Met de laatste status is dus de laatste mijlpaal bereikt: de finish. Einde zaak. Niet voor niets maakt in diverse zaaktypen het archiveren van de zaak deel uit van het traject naar de laatste status. Bij het bereiken van die status is alles keurig afgehecht, ook het archiveren.
N.a.v. de door John aangehaalde tekst op bladzijden 25 en 26, ik vind het vreemd dat een applicatie waar zaken in behandeld worden een bericht met status 'Einde zaak' oid stuurt en dat dan het zaaksysteem nog moet gaan archiveren. Het lijkt mij één van tweeën:
- met de zaakbehandelende applicatie wordt gearchiveerd waarna de status 'Einde zaak' wordt bereikt en verstuurd;
- met het zaaksysteem wordt gearchiveerd na het bereiken van een daartoe triggerende status of ander bericht vanuit de zaakbehandelende applicatie, niet zijnde de laatste status, waarna het zaaksysteem de laatste status zet.
V.w.b. de laatste vraag van John, kan een zaak volgens de standaard eerst een einddatum (en resultaat) krijgen en daarna een eindstatus, m.i. niet. Laatste status bereikt betekent zaak beeindigd. Einddatum kan dus niet liggen na het bereiken van de laatste status. Interessant is of het omgekeerde wel mogelijk is: het een week later (na einde zaak) melden van het bereiken van de laatste status. Het RGBZ stelt (nog) geen eisen aan zaakeinddatum versus datum laatste status gezet.
Zoals ik er naar kijk helpen de huidige standaarden bij het kunnen uitwisselen van data tussen verschillende applicaties. Maar terecht wordt er hier en daar opgemerkt dat niet alles (zeker niet de procesgang na berichtontvangst) tot in detail wordt voorgeschreven ("Het RGBZ is niet bedoeld als uitputtend voorschrift"). Wanneer en hoe je een zaak afsluit, en wat dit precies voor gevolgen heeft voor evt. verdere uitwisseling kan verschillen; per gemeente, per zaaktype, per situatie. Los van de vraag of je het zou moeten willen denk ik dat het niet gaat lukken om daar "1 uitputtend voorschrift" voor te ontwikkelen. Op het moment dat een gemeente besluit om een eigen DMS (voor een deel) te vervangen door een eDepot-toepassing kan het proces van afsluiten best wel eens anders gaan verlopen.
Het belangrijkste doel om na te streven lijkt me om zo neutraal mogelijk betrouwbaar berichten uit te kunnen wisselen waarbij aan de provider flexibel genoeg is om in verschillende scenario's daarmee om te gaan. En ja, dat betekent o.a. dat je, zoals John zich terecht afvraagt, dan meerdere implementatievormen moeten (blijven) ondersteunen.
Er staat me bij dat eerder gesteld is dat het wijzigen van een status niet via een updateZaak bericht maar via een actualiseerZaakstatus bericht moet worden gecommuniceerd. Als de eindstatus via een updateZaak bericht mag worden gecommuniceerd, wat betekent dat voor de huidige implementaties. En mag dit dan ook voor andere status overgangen?
Er staat nergens in de standaard dat het afsluiten van een zaak middels een actualiseerZaakstatus bericht moet worden gedaan. Het enige wat wel in de standaard staat is het volgende (ZDS 1.2, paragraaf 4.1.3, pagina 30):
Indien de nieuwe status gelijk is aan de eindstatus (zoals vastgelegd in de ZTC van de gemeente) dient het ZS de betreffende zaak af te sluiten.
Dit kan geïnterpreteerd worden als dat een zaak via dit bericht afgesloten moet worden maar dit staat er niet. Er staat alleen hoe een zaaksysteem om moet gaan met die betreffende nieuwe status. Logic dictates dat deze regel ook geldt wanneer deze eindstatus gezet wordt door het updateZaak bericht. Het is immers geen regel die gebaseerd is op een specifiek bericht maar op het behalen van een bepaalde status door een zaak.
Gezien de onduidelijkheid die blijkbaar voorkomt zou ik willen voorstellen een specifiek sluitZaakAf bericht te maken waarin alle gegevens van de af te sluiten zaak doorgegeven kunnen worden. Dus ook einddatum, resultaat etc.
Ik denk dat de vraag of het archiveren al dan niet onderdeel is van de behandeling van een zaak in deze discussie niet relevant is. Het gaat er hier om op welke wijze je een zaak afsluit. In RGBZ komt het woord afsluiten niet voor. Ik lees echter wel:
Einddatum: De datum waarop de uitvoering van de zaak afgerond is.
Afronden en afsluiten ligt dermate dicht bij elkaar dat ik wel durf te beweren dat de einddatum bedoeld is om aan te geven dat een zaak is afgesloten.
Bovendien staat in RGBZ als toelichting bij statustype:
Zaken van eenzelfde zaaktype doorlopen alle dezelfde statussen, tenzij de zaak voortijdig beeindigd wordt. Met STATUSTYPE worden deze statussen benoemd bij het desbetreffende zaaktype.
Dat lijkt er op te duiden dat met de status juist niet kan worden aangegeven dat een zaak is afgesloten. Immers. Als alle zaken van hetzelfde type allemaal dezelfde statussen doorlopen, dan kun je met een status een zaak dus niet voortijdig afsluiten.
Al vanaf het eerste begin, dus bij implementatie van het GFO Zaken hebben wij (Centric) de einddatum gehanteerd om aan te geven dat een zaak is afgesloten. Daarnaast kennen wij ook het principe van de eindstatus. Maar het bereiken van die status is voor ons een trigger om de statusdatum over te nemen als einddatum van de zaak. Daarmee is die status op zich dus geen indicatie dat de zaak is afgesloten maar wel een trigger om de zaak af te sluiten. En dat is ook dat de Zaak- en Documentservice specificaties zeggen:
Indien de nieuwe status gelijk is aan de eindstatus (zoals vastgelegd in de ZTC van de gemeente) dient het ZS de betreffende zaak af te sluiten.
Als de betreffende status zelf zou impliceren dat de zaak is afgesloten, dan zou het zaaksysteem dat niet meer hoeven doen. Ook hieruit kunnen we dus afleiden dat niet de status maar de gevulde einddatum bedoeld is om aan te geven dat de zaak is afgesloten.
In een poging om deze discussie samen te vatten en te kunnen gaan besluiten:
Opmerking: omdat het resultaat van de zaak niet verstrekt mag worden in het actualiseerZaakstatus bericht (ZS-DMS specificatie versie 1.2) kan de ZS-DMS consumer dit via een voorafgaand updateZaak bericht verstrekken.
Verzoek aan de ZS-DMS werkgroep om hierover te besluiten en hierover verder te communiceren.
Gezien de discussies in de werkgroep en de manier hoe bepaalde functionaliteit geinterpreteerd is door leveranciers vreees ik dat een korte beschrijving zoals hierboven niet afdoende is.
Begin volgende maand (in verband met vakanties ed.) zal bij KING vanuit de GEMMA architectuur een beschrijving van het afsluiten van een zaak beschikbaar komen. Aan de hand daarvan wordt de invulling hiervan door berichten in een best practice beschreven die in de werkgroep besproken zal worden.
Excuus voor het reageren op een oude discussie. Is er inmiddels een beschrijving (online) beschikbaar?
In ZDS 2.0 wordt dit getackled:
https://github.com/VNG-Realisatie/gemma-zaken/blob/master/docs/content/d...
Duidelijk, maar ook wat impliciete keuzes. Consumer geeft "datumStatusGezet" door waaruit de provider besluit om "eindDatum" met die waarde te vullen. Om meerdere redenen vind ik dat je zo min mogelijk bedrijfslogica in de provider onder moet brengen. In dit geval zou dat betekenen dat de consumer zelf doorgeeft wat de "eindDatum" is. (Sterker nog: je kunt de consumer zien als houder van een bronregistratie die ook een eenmaal doorgegeven einddatum aan moet kunnen passen (om wat voor reden dan ook), maar ik weet dat ik daarmee afwijk van rondom zsdms gemaakte afspraken).
Hi Joeri, deze keuze lijkt duidelijkheid te verschaffen, maar roept ook diverse vragen op:
Ter aanvulling:
De beschrijving op github suggereert dat alleen "het laatste STATUSTYPE binnen dit ZAAKTYPE" een eindstatus is. Dit lijkt me een te strikte beperking omdat een zaak beëindigd moet kunnen worden met diverse "eindstatussen".
Uitgangspunt bij die keuze is geweest: Een zaak heeft slechts één eindstatus, dat zal een equivalent zijn van "afgehandeld". Er zijn wel meer manieren om bij de status "afgehandeld" te komen (bijvoorbeeld "vergunning verleend" of "vergunning afgewezen" ) maar uiteindelijk is de zaak afgehandeld, ongeacht de uitkomst van de zaak.
Het lijkt er op dat eindstatus verward wordt met uitkomst van de zaak maar dat is iets totaal anders.
Ik blijf het een vreemde oplossing vinden. Waarom komt er geen operatie voor het "afsluiten van een zaak"?
Daarin kunnen dan de voor archiveren relevante eigenschappen worden meegegeven zoals de einddatum en het resultaat.
Het is mij onduidelijk wat de reden is om een "eindstatus" toe te kennen. Dit lijkt handhaving van oude keuzen.
Wat mij betreft moeten er 2 dingen geregeld worden:
1/ Het algoritme waarmee een zaak afgesloten kan worden moet bepaald worden (dit is nu gebeurd).
2/ Om het voor de ontwikkelaar (met name van de consumerapplicaties maar uiteindelijk ook de ontwikkelaar van de provider) makkelijker te maken moet in een proces of experience API een operatie "afsluiten van een zaak" opgenomen worden.
Voor degenen die niet weten wat ik bedoel met een proces of experience API, dat zijn de bovenste twee lagen uit dit plaatje:
https://blogs.mulesoft.com/wp-content/uploads/2017/07/api-led-connectivity.png
Afkomstig uit dit artikel.
Wat we geanalyseerd hebben is hoe een zaak behandeld wordt, qua proces. Kern daarvan is het successievelijk toewerken naar opeenvolgende mijlpalen. Een bereikte mijlpaal leggen we vast met een status. Het bereiken van de laatste mijlpaal betekent dat de behandeling van de zaak afgerond en dus beeindigd is. Een einddatum van een zaak is daarmee een afgeleid gegeven. Die einddatum is er niet opeens en vul je niet zomaar in, die is er omdat de laatste mijlpaal bereikt is.
Ik ben het dan ook oneens dat dit "handhaving van oude keuzen" zou zijn. In het RGBZ en dientengevolge in de ZDS is het niet eenduidig hoe de informatie over het einde van een zaak gestructureerd is. Vandaar dat er twee werkwijzen in de praktijk gehanteerd worden. Dit hebben we nu eenduidig gemaakt door slechts één werkwijze toe te staan. Een werkwijze die geënt is op de wijze waarop zaken behandeld worden.