fout in business rule ZRC-22 waardoor zaken met een archiefactiedatum die afhankelijk is van de einddatum van een besluit niet kunnen worden afgesloten

[hanspluimers]

Business rule ZRC-22 hebben betrekking op het correct kunnen afsluiten en opslaan van een zaak in de ZRC.

Naar aanleiding van het doorlopen van diverse testscenario's komen we er nu achter dat we zaken waarbij de archieftermijn afhankelijk is van de vervaldatum van een besluit nu niet kunnen afsluiten.

Afsluiten is namelijk in strijd met ZRC-022.

Het is echter heel gebruikelijk dat onze klanten zaken behandelen in ons VTH-systeem (Rx.Mission) waarvan de bewaartermijn afhankelijk is van de einddatum van het besluit terwijl die einddatum ten tijde van het afsluiten van de zaak nog niet bekend is.

Voorbeelden hiervan zijn kapvergunningen, sloopvergunningen, handhavingsbeschikkingen/besluiten.

Zaken waarvan de archiefactiedatum niet bepaald kan worden (omdat de bewaartermijn afhankelijk is van de vervaldatum van het besluit) moeten eigenlijk de archiefstatus “gearchiveerd_procestermijn_onbekend” krijgen.

Die archiefstatus kunnen we wel instellen maar dat kunnen we de zaak nog steeds niet opslaan omdat dan niet voldaan wordt aan ZRC-022. De eigenschap “Zaak.archiefactiedatum” is dan namelijk leeg en dat voldoet niet aan ZRC-022.

Dit is de huidige tekst van ZRC-022

Zetten Zaak.archiefstatus (ZRC-022)
De standaardwaarde voor archiefstatus is nog_te_archiveren. Indien een andere waarde gezet wordt, dan MOETEN alle gerelateerde informatieobjecten de status gearchiveerd hebben.

De attributen Zaak.archiefnominatie en Zaak.archiefactiedatum MOETEN een waarde krijgen als de archiefstatus een waarde krijgt anders dan nog_te_archiveren.

Indien deze voorwaarden niet voldaan zijn, dan MOET het ZRC met een HTTP 400 foutbericht antwoorden.

Volgens mij moet ZRC-022 worden aangevuld met een extra voorwaarde … of Zaak.archiefstatus = “gearchiveerd_procestermijn_onbekend”, zaak.archiefnominatie = “vernietigen’ en ‘Zaak.archiefactiedatum’ = null / leeg

Graag verzoek ik u om te onderzoeken of de formulering en werking van ZRC-022 aangepast kan worden in de eerstvolgende release van de API-specificaties. Ten gevolge van de huidige formulering in ZRC-022 kunnen bepaalde zaken niet afgesloten worden en dat is zeer ongewenst.

Indien u meer informatie wenst kunt u contact met mij opnemen (Hans Pluimers, Roxit, 06-20743543/[email protected])

[hanspluimers]

Onze VTH-applicatie Rx.Mission (die gebruikmaakt van de ZGI-api's) is inmiddels in productie genomen en we krijgen nu reacties van onze klanten dat er zaken zijn behandeld die nu niet afgesloten kunnen worden omdat het de procestermijn en de archieftermijn van deze zaak afhankelijk is van de vervaldatum van het genomen besluit. Dat ik bijvoorbeeld het geval bij een tijdelijke vergunning of bij een omgevingsvergunning voor de activiteit kappen. De huidige business rule ZRC-22 staat het afsluiten van die zaak niet toe omdat de einddatum van dat besluit nog niet is ingesteld. Die einddatum is in het gevallen nog niet vast te stellen dus daarom kan de zaak nu niet gesloten worden.

Gelet op deze problematiek verzoek ik hierbij om de urgentie van de categorie van dit issue om te zetten naar een BUG. Het is nu namelijk niet mogelijk om zaken af te sluiten terwijl die zaak voldoet aan alle daaraan gestelde archief-registratie-eisen conform de selectielijst gemeenten.

[MNIJ]

Er is nog geen reactie op dit issue gekomen, maar dit is een serieus probleem. Het heeft als gevolg dat zaken niet met het correcte resultaattype afgesloten kunnen worden en dus "eeuwig" open moeten blijven staan. Hierdoor kunnen gemeenten niet voldoen aan de verplichtingen van de archiefwet.

De ZRC biedt nu geen mogelijkheid om gebruik te maken van de archiefstatus gearchiveerd_procestermijn_onbekend
Deze waarde bestaat wel in de standaard en is precies voor dit soort scenario's bedoeld, maar business rule ZRC-022 voorkomt dat het daadwerkelijk te gebruiken is.

Aanvullend daaraan hebben we de vraag welke component verantwoordelijk is voor het zetten van de correcte waarde van Zaak.archiefstatus.

Het meest logisch lijkt dat de ZRC dit zelf doet op het moment dat de zaak gesloten wordt. Op dat moment zou de status moeten veranderen naar gearchiveerd of gearchiveerd_procestermijn_onbekend, afhankelijk van het resultaattype en de data in de zaak. Dit gedrag staat nu echter niet beschreven en gebeurt dus ook niet, terwijl de ZRC bij het sluiten van de zaak wel automatisch andere archiefkenmerken zet, zoals de archiefactiedatum.

Als dat inderdaad niet door de ZRC gedaan moet worden, dan moet het dus door een afhandelcomponent gebeuren. Maar het kan dan alleen met de autorisatie-scope zaken.geforceerd-bijwerken

[michielverhoef]

Ik ga dit even opnemen met @hdksi en kom hier op terug. Als dat afstemmen niet snel genoeg (vandaag of morgen) lukt zoek ik nog even contact met je @MNIJ.

[MNIJ]

Bedankt voor de reactie. Ter info: ik ben de komende drie weken op vakantie dus als ik niet reageer is het daarom.

[michielverhoef]

Dan moet ik een beetje opschieten dus.

Edit: Dit lijkt trouwens gerelateerd aan de discussie over producten en zaken die ook speelt.

[hdksi]

Uit de regels bij Archiefactiedatum ZAAK:

Dit attribuutsoort moet van een waarde voorzien zijn als de attribuutsoort ‘Archiefstatus’ een waarde ongelijk "nog te archiveren" en "gearchiveerd (procestermijn onbekend)" heeft.

Dit betekent dat

De attributen Zaak.archiefnominatie en Zaak.archiefactiedatum MOETEN een waarde krijgen als de de archiefstatus een waarde krijgt anders dan nog_te_archiveren.

inderdaad niet klopt.

Omdat je de archiefnominatie op basis van het zaakresultaat voor zover ik weet wél, maar de archiefactiedatum níet altijd kunt bepalen op het moment dat je een zaak afsluit, stel ik in plaats van het bovenstaande het volgende voor:

Het attribuut Zaak.archiefnominatie MOET een waarde krijgen als de de archiefstatus een waarde krijgt anders dan nog_te_archiveren.

Het attribibuut Zaak.archiefactiedatum MOET een waarde krijgen als de de archiefstatus een waarde krijgt anders dan nog_te_archiveren of gearchiveerd_procestermijn_onbekend.

De vraag van @MNIJ over de verantwoordelijkheid voor het toekennen van Zaak.archiefstatus is wat ingewikkelder denk ik. Die neerleggen bij het provider klinkt goed, maar ik kan me voorstellen dat het voor die provider vanwege bijvoorbeeld ontbrekende autorisaties niet altijd mogelijk is bij een afleidingswijze als zaakobject geautomatiseerd een datumkenmerk van een in een ander register opslagen object uit te lezen om op basis daarvan te bepalen of de zaak nu de status gearchiveerd of gearchiveerd_procestermijn_onbekend moet krijgen. Die verantwoordelijkheid neerleggen bij afnemers vereist inderdaad aanpassing van de bedrijfsregels; het gebruik van de scope zaken.geforceerd-bijwerken lijkt me voor deze reguliere handeling niet gewenst.

[MNIJ]

Eens met het wijzigingsvoorstel van @hdksi , maar dat is niet de volledige oplossing. Het concrete probleem is nu namelijk dat de ZRC weigert een zaak te sluiten als het niet lukt om de archiefactiedatum te bepalen op basis van de kenmerken van het restultaat conform business rule ZRC-021. In dat verhaal speelt momenteel zaak.archiefstatus nog geen rol, omdat deze helemaal niet gezet wordt. Mijn voorstel zou dus zijn om dat veld wel automatisch door de ZRC te laten zetten, aangezien de ZRC nu bij het sluiten van de zaak ook de andere archiefkenmerken bepaalt en daarom dus ook "weet" wat de correcte waarde van zaak.archiefstatus moet worden. Als de ZRC een deel van de archiefkenmerken zet, maar de consumer moet de zaak.archiefstatus zetten, dan krijg je een onoplosbaar volgordeprobleem bij het sluiten van de zaak.

Dus het huidige gedrag is als volgt:

1. Consumer zet de laatste status bij de zaak
2. ZRC bepaalt conform ZRC-021 wat zaak.archiefactiedatum moet worden
3. Lukt dit niet omdat gegevens ontbreken -> Zetten van de laatste status wordt geweigerd door de ZRC
4. Lukt dit wel -> ZRC zet zaak.archiefnominatie = waarde op basis van zaak.resultaat en zaak.archiefactiedatum = waarde op basis van zaak.resultaat.

De meest simpele aanpassing om het probleem te verhelpen zou zijn:

1. Consumer zet de laatste status bij de zaak
2. ZRC bepaalt confrom ZRC-021 wat zaak.archiefactiedatum moet worden
3. Lukt dit niet omdat gegevens ontbreken -> ZRC zet zaak.archiefstatus = "gearchiveerd_procestermijn_onbekend" en zaak.archiefnominatie = waarde op basis van zaak.resultaat, zaak.archiefactiedatum blijft leeg.
4. Lukt dit wel -> ZRC zet zaak.archiefstatus = "gearchiveerd", zaak.archiefnominatie = waarde op basis van zaak.resultaat en zaak.archiefactiedatum = waarde op basis van zaak.resultaat.

Dit vereist aanpassingen aan ZRC-021 en ZRC-022.

Voor zaken die hierdoor zaak.archiefstatus = "gearchiveerd_procestermijn_onbekend" krijgen, zal er op een gegeven moment nabewerking nodig zijn en daarvoor is de scope zaken.geforceerd-bijwerken nodig. Maar dat zal in elke oplossing zo zijn en dat is ook precies waar archiveringssoftware voor bedoelt is, dus een archiveringsmodule zal altijd deze scope nodig hebben, dat zie ik niet als een nadeel.

Met deze oplossing kan je een zaak altijd afsluiten. Dat is een groot voordeel en lost het acute probleem op. Het nadeel is dat er ook een aantal nuttige validaties verloren gaan. Bijvoorbeeld:

• Zaak heeft een resultaat met brondatumArchiefprocedure.afleidingswijze = ingangsdatum_besluit, maar de zaak heeft helemaal nog geen besluit.
• Huidige gedrag zou zijn dat ZRC weigert deze zaak te sluiten
• Bij de bovenstaande simpele oplossing zou de zaak wel gesloten kunnen worden, met zaak.archiefstatus = "gearchiveerd_procestermijn_onbekend", terwijl in dit geval de validatie eigenlijk terecht is.

Een uitgebreidere oplossing zou zijn om de bij stap 2. een onderscheid te maken tussen het ontbreken van het object waar de brondatum op gebaseerd is en het ontbreken van een waarde in het datumveld. Als het object geheel ontbreekt (in bovenstaand voorbeeld dus het besluit), dan weigert de ZRC het sluiten van de zaak. Als het object wel bestaat maar het datumveld is leeg, dan wordt de zaak wel gesloten, maar met zaak.archiefstatus = "gearchiveerd_procestermijn_onbekend". Dat is wel een wat complexere uitbreiding van ZRC-021.

[MNIJ]

Op dezelfde manier uitgeschreven zou deze "uitgebreide" oplossing dus als volgt zijn:

1. Consumer zet de laatste status bij de zaak
2. ZRC bepaalt confrom ZRC-021 wat zaak.archiefactiedatum moet worden
3. Lukt dit niet omdat het object waarvan het datumveld gebruikt moet worden ontbreekt -> Zetten van de laatste status wordt geweigerd door de ZRC.
4. Lukt dit niet omdat het vereiste datumveld leeg is -> ZRC zet zaak.archiefstatus = "gearchiveerd_procestermijn_onbekend" en zaak.archiefnominatie = waarde op basis van zaak.resultaat, zaak.archiefactiedatum blijft leeg.
5. Lukt dit wel -> ZRC zet zaak.archiefstatus = "gearchiveerd", zaak.archiefnominatie = waarde op basis van zaak.resultaat en zaak.archiefactiedatum = waarde op basis van zaak.resultaat.

[hdksi]

Mijn voorstel zou dus zijn om dat veld wel automatisch door de ZRC te laten zetten, aangezien de ZRC nu bij het sluiten van de zaak ook de andere archiefkenmerken bepaalt en daarom dus ook "weet" wat de correcte waarde van zaak.archiefstatus moet worden.

Ik had de verantwoordelijkheden voortkomend uit ZRC-021 niet helemaal scherp bij het typen van mijn eerdere reactie. Helemaal eens met het voorstel de verantwoordelijkheid voor het zetten van archiefattributen niet te verdelen over meerdere componenten, en zaak.archiefstatus dus door de ZRC te laten vastleggen.

Het concrete probleem is nu namelijk dat de ZRC weigert een zaak te sluiten als het niet lukt om de archiefactiedatum te bepalen op basis van de kenmerken van het resultaat conform business rule ZRC-021.

In ZRC-021 lees ik dat

Indien de archiefactiedatum niet bepaald kan worden, dan MAG er geen datum gezet worden. Dit kan voorkomen als de brondatum niet bepaald kan worden of de archiefactietermijn niet beschikbaar is.

zaak.archiefactiedatum blijft dus leeg als die niet bepaald kan worden. In ZRC-007 lees ik geen regels die het afsluiten van een zaak zonder archiefactiedatum in de weg staan. Wel uiteraard in ZRC-022, maar die is hierboven al besproken en van oplossingsvoorstel voorzien. Waarschijnlijk zie ik iets over het hoofd, maar waarop (behalve ZRC-022) is de bevinding gebaseerd dat de ZRC het zetten van de laatste status weigert als de zaak.archiefactiedatum leeg is?

Met deze oplossing kan je een zaak altijd afsluiten. Dat is een groot voordeel en lost het acute probleem op. Het nadeel is dat er ook een aantal nuttige validaties verloren gaan.

[...]

Een uitgebreidere oplossing zou zijn om de bij stap 2. een onderscheid te maken tussen het ontbreken van het object waar de brondatum op gebaseerd is en het ontbreken van een waarde in het datumveld. Als het object geheel ontbreekt (in bovenstaand voorbeeld dus het besluit), dan weigert de ZRC het sluiten van de zaak. Als het object wel bestaat maar het datumveld is leeg, dan wordt de zaak wel gesloten, maar met zaak.archiefstatus = "gearchiveerd_procestermijn_onbekend". Dat is wel een wat complexere uitbreiding van ZRC-021.

Een iets eenvoudiger tussenoplossing kan nog zijn het leeglaten van zaak.archiefactiedatum en kiezen van zaak.archiefstatus = gearchiveerd_procestermijn_onbekend alleen toe te staan voor afleidingswijzen waar de procestermijn ook daadwerkelijk onbekend kan zijn, en die mogelijkheid dus uit te sluiten waar het relevante resultaattype afleidingswijzen afgehandeld, termijn en ingangsdatum_besluit kent.

[michielverhoef]

Op dezelfde manier uitgeschreven zou deze "uitgebreide" oplossing dus als volgt zijn:

1. Consumer zet de laatste status bij de zaak

2. ZRC bepaalt confrom ZRC-021 wat `zaak.archiefactiedatum` moet worden

3. Lukt dit niet omdat het object waarvan het datumveld gebruikt moet worden ontbreekt -> Zetten van de laatste status wordt geweigerd door de ZRC.

4. Lukt dit niet omdat het vereiste datumveld leeg is -> ZRC zet `zaak.archiefstatus = "gearchiveerd_procestermijn_onbekend"` en `zaak.archiefnominatie = waarde op basis van zaak.resultaat`,  `zaak.archiefactiedatum` blijft leeg.

5. Lukt dit wel ->  ZRC zet `zaak.archiefstatus = "gearchiveerd"`,  `zaak.archiefnominatie = waarde op basis van zaak.resultaat` en `zaak.archiefactiedatum = waarde op basis van zaak.resultaat`.

ven voor mijn beeld: Dit zou de nieuwe tekst van ZRC-022 worden?

[MNIJ]

ven voor mijn beeld: Dit zou de nieuwe tekst van ZRC-022 worden?

@michielverhoef Nee, zo was dit niet bedoeld. Dit is puur een simpele voorstelling van wat er gebeurt bij archiveren. Mogelijk te simpel, zie hieronder.

@hdksi

Ik had de verantwoordelijkheden voortkomend uit ZRC-021 niet helemaal scherp bij het typen van mijn eerdere reactie. Helemaal eens met het voorstel de verantwoordelijkheid voor het zetten van archiefattributen niet te verdelen over meerdere componenten, en zaak.archiefstatus dus door de ZRC te laten vastleggen.

Bij nader inzien zit hier nog wel meer aan vast. ZRC-022 vereist dat eerst alle gerelateerde informatieobjecten de status 'gearchiveerd' krijgen. Ik zou het mooi vinden als dit dan ook automatisch gedaan wordt door de ZRC (want door wie en wanneer anders?), maar zo niet dan zal bovenstaande niet zomaar kunnen.

In ZRC-007 lees ik geen regels die het afsluiten van een zaak zonder archiefactiedatum in de weg staan.

Het is in ieder geval hoe zowel Open Zaak als de Roxit ZRC implementatie nu werken: als archiefactiedatum niet bepaald kan worden, dan kan de zaak niet afgesloten worden. En dat dus zonder dat er een archiefstatus gezet wordt op dat moment. De VNG referentie-implementatie heb ik op dit punt niet kunnen testen. Maar afhankelijk van interpretatie valt dit gedrag af te leiden uit de tekst van ZRC-021:

Bij het afsluiten van een zaak MOETEN de attributen Zaak.archiefnominatie en Zaak.archiefactiedatum bepaald worden uit het Zaak.Resultaat als volgt:
...
Indien de archiefactiedatum niet bepaald kan worden, dan MAG er geen datum gezet worden. ...

Het veld MOET gezet worden, dus als dat niet MAG, dan kan de operatie dus niet plaatsvinden. Het kan natuurlijk ook een verkeerde interpretatie van de business rules zijn in de diverse implementaties.

Een iets eenvoudiger tussenoplossing kan nog zijn het leeglaten van zaak.archiefactiedatum en kiezen van zaak.archiefstatus = gearchiveerd_procestermijn_onbekend alleen toe te staan voor afleidingswijzen waar de procestermijn ook daadwerkelijk onbekend kan zijn, en die mogelijkheid dus uit te sluiten waar het relevante resultaattype afleidingswijzen afgehandeld, termijn en ingangsdatum_besluit kent.

Ja, mee eens. Mogelijk is het zelfs beter om de archiefstatus gearchiveerd_procestermijn_onbekend ALLEEN toe te staan bij de afleidingswijzen:

• ander_datumkenmerk
• gerelateerde_zaak
• hoofdzaak
• vervaldatum_besluit
• zaakobject

[hdksi]

Ja, mee eens. Mogelijk is het zelfs beter om de archiefstatus gearchiveerd_procestermijn_onbekend ALLEEN toe te staan bij de afleidingswijzen:

• ander_datumkenmerk
• gerelateerde_zaak
• hoofdzaak
• vervaldatum_besluit
• zaakobject

'Eigenschap' had ik gemist, maar dat is in feite het omgekeerde van wat ik bedoelde inderdaad :). Heb hieronder geprobeerd een en ander dan misschien niet korter maar hopelijk wel duidelijker te beschrijven.

Het veld MOET gezet worden, dus als dat niet MAG, dan kan de operatie dus niet plaatsvinden. Het kan natuurlijk ook een verkeerde interpretatie van de business rules zijn in de diverse implementaties.

Mijn interpretatie was dat het 'bepalen' ook mag resulteren in de conclusie dat (nog) geen archiefactiedatum vastgesteld kan worden - ergo: een lege archiefactiedatum. Maar ik begrijp jouw lezing ook, zeker als de bestaande oplossingen die ondersteunen. Het valt me nu bovendien op dat ZRC-022 de volgende 'mogelijkheid' omvat:

Indien Resultaat.Resultaattype.archiefactietermijn gevuld is:

1. Bepaal de brondatum van de archiefprocedure [enz]

maar geen andere scenario's ondersteunt. Een Archiefactietermijn is conform ImZTC 2.2 ook verplicht. Is er een bezwaar tegen het verplicht vastleggen van een Archiefactietermijn bij een resultaattype? Zo nee, dan zou dat deze regel wat eenvoudiger maken.

Ik doe met het bovenstaande als uitgangspunt het volgende _concept_voorstel voor het bijwerken van zrc-021 [nog even goed checken op correctheid van zowel tekst als aannames waarop die gebaseerd zijn]:

Indien de zaak geen archiefnominatie heeft, dan MOET deze overgenomen worden uit Resultaat.Resultaattype.archiefnominatie.

Indien Resultaat.Resultaattype.brondatumArchiefprocedure.afleidingswijze de waarde afgehandeld, eigenschap, ingangsdatum_besluit of termijn heeft, is het bepalen van de brondatum voor de archiefprocedure - en daarmee het vullen van Zaak.archiefactiedatum in alle gevallen mogelijk. Bij deze afleidingswijzen MOET Zaak.archiefactiedatum voor bij het afsluiten van de zaak volgens onderstaande instructie gevuld zijn:

• afgehandeld -> Zaak.archiefactiedatum = Zaak.einddatum + Resultaat.Resultaattype.archiefactietermijn.
• eigenschap -> Zaak.archiefactiedatum = de waarde van de eigenschap waar de naam overeenkomt met Resultaat.Resultaattype.brondatumArchiefprocedure.datumkenmerk + Resultaat.Resultaattype.archiefactietermijn.
• ingangsdatum_besluit -> Zaak.archiefactiedatum = Besluit.ingangsdatum bij het besluit waarvan de ingangsdatum van alle gerelateerde besluiten het verst in de toekomst ligt + Resultaat.Resultaattype.archiefactietermijn.
• termijn -> Zaak.archiefactiedatum = Zaak.einddatum + Resultaat.Resultaattype.brondatumArchiefprocedure.procestermijn + Resultaat.Resultaattype.archiefactietermijn.

Indien Resultaat.Resultaattype.brondatumArchiefprocedure.afleidingswijze de waarde ander_datumkenmerk, gerelateerde_zaak, hoofdzaak, vervaldatum_besluit of zaakobject dan MOET Zaak.archiefactiedatum gevuld zijn als de brondatum voor de archiefprocedure bepaald kan worden. Daarvan is per afleidingswijze sprake in het volgende geval:

• ander_datumkenmerk -> De brondatum kan bepaald worden als de combinatie van Resultaat.Resultaattype.brondatumArchiefprocedure.objecttype, registratie en datumkenmerk verwijst naar een attribuut dat overeenkomt met datumkenmerk en daarbij een geldige (datum)waarde is geregistreerd. Het bepalen hiervan is een handmatige handeling. Zaak.archiefactiedatum = de gevonden (datum)waarde + Resultaat.Resultaattype.archiefactietermijn.
• gerelateerde_zaak -> De brondatum kan bepaald worden als bij tenminste één van de gerelateerde zaken Zaak.einddatum geregistreerd is. Zaak.archiefactiedatum = Zaak.einddatum bij de gerelateerde zaak waarvan de einddatum van alle gerelateerde zaken het verst in de toekomst ligt +Resultaat.Resultaattype.archiefactietermijn.
• hoofdzaak -> De brondatum kan bepaald worden als Zaak.hoofdzaak.einddatum een waarde heeft. Zaak.archiefactiedatum = Zaak.hoofdzaak.einddatum + Resultaat.Resultaattype.archiefactietermijn.
• vervaldatum_besluit -> De brondatum kan bepaald worden als bij tenminste één van de gerelateerde besluiten Besluit.vervaldatum geregistreerd is. Zaak.archiefactiedatum = Besluit.vervaldatum bij het besluit waarvan de vervaldatum van alle gerelateerde besluiten het verst in de toekomst ligt +Resultaat.Resultaattype.archiefactietermijn.
• zaakobject -> De brondatum kan bepaald worden als tenminste één van de aan de zaak gerelateerde objecten van het type Resultaat.Resultaattype.brondatumArchiefprocedure.objecttype het attribuut dat overeenkomt met Resultaat.Resultaattype.brondatumArchiefprocedure.datumkenmerk een geldige (datum)waarde is geregistreerd. Zaak.archiefactiedatum = gevonden (datum)waarde bij het zaakobject waarvan de bij het datumkenmerk opgegeven datum van alle zaakobjecten van het overeenkomende type het verst in de toekomst ligt + Resultaat.Resultaattype.archiefactietermijn.

In alle andere gevallen kan de 'brondatum' niet worden bepaald en MOET Zaak.archiefactiedatum leeg blijven.

Omdat het bepalen van de brondatum, het zetten van de archiefactiedatum en het zetten van de archiefstatus zo nauw verbonden en afhankelijk zijn vraag ik me af of het niet beter en duidelijker is om ZRC-021 en ZRC-022 samen te voegen.

Bij nader inzien zit hier nog wel meer aan vast. ZRC-022 vereist dat eerst alle gerelateerde informatieobjecten de status 'gearchiveerd' krijgen. Ik zou het mooi vinden als dit dan ook automatisch gedaan wordt door de ZRC (want door wie en wanneer anders?), maar zo niet dan zal bovenstaande niet zomaar kunnen.

Hier moet ik laten nog even op terugkomen...

[MNIJ]

Ik ben aan het studeren op een iets meer inhoudelijk antwoord, dat duurt iets langer dan gehoopt, dus intussen wil ik toch vast aangeven dat ik het voorstel van @hdksi voor een heel groot deel onderschrijf. Nog een paar aandachtspunten, maar daar kom ik dus later vandaag op terug.

[MNIJ]

De uitgebreidere reactie op het voorstel van @hdksi:

Verplicht maken van Resultaattype.archiefactietermijn
Ik zie inderdaad dat dit in de ImZTC een verplicht veld is, in dat kader lijkt dat dus logisch. Echter bij de archiefnominatie Blijvend bewaren is het daadwerkelijk de bedoeling dat de zaak oneindig bewaard blijft. De betekenis van zaak.archiefactiedatum is in dat geval het moment waarop de zaak overgedragen moet worden naar een blijvend archiefsysteem. Maar ik ga er vanuit dat het blijvend archiefsysteem OOK een ZGW compatible systeem moet/kan zijn. Sterker nog, in veel gevallen zal er helemaal niet overgedragen worden, maar zal dezelfde ZRC instantie waarin de lopende zaken staan ook gebruikt worden voor het permanent bewaren van gearchiveerde zaken.
Door Resultaattype.archiefactietermijn verplicht te maken, wordt in feite uitgesloten dat een permanent archief ZGW conform kan zijn. Tenzij er een specifieke waarde komt voor 'oneindig', maar ik weet niet of dat technisch verstandig is in een veld in het ISO 8601 periode formaat, dat kent zo ver ik weet geen waarde voor oneindig.

Maar dit geldt dus alleen bij archiefnominatie Blijvend bewaren. Archiefactiedatum MAG in dat geval leeg blijven, maar dit hoeft niet (voor het geval er wel overgedragen wordt). Deze situatie kan natuurlijk ook opgenomen worden in de nieuwe business rule.

Ontbrekend object versus ontbrekende waarde in datumveld
Het voorstel maakt geen onderscheid tussen het ontbreken van een datum en het ontbreken van het object waar die datum in staat. Bijvoorbeeld bij de afleidingswijze vervaldatum_besluit zou het ZRC idealiter de archiefactiedatum leeg laten als er wel een besluit is zonder vervaldatum, maar een foutmelding geven als er helemaal geen besluit is. Dat geldt voor alle afleidingswijzen waar de datum uit een ander object dan de zaak zelf komt. Ik besef dat dit de business rule nog weer een stukje complexer maakt.

Voorkomen van interpretatieverschillen
Op bovenstaande kanttekening na kan ik me inhoudelijk helemaal vinden in de voorgestelde nieuwe business rule ZRC-021. Tekstueel kan het nog wel wat aangescherpt worden, om te voorkomen dat er interpretatieverschillen kunnen ontstaan tussen implementaties. Bijvoorbeeld dit stuk:

Bij deze afleidingswijzen MOET Zaak.archiefactiedatum voor bij het afsluiten van de zaak volgens onderstaande instructie gevuld zijn:

Dit kan op twee manieren geïnterpreteerd worden: Zaak.archiefactiedatum moet al de correcte waarde hebben (en zo niet foutmelding?) OF het ZRC moet deze waarde zetten. Dat tweede is natuurlijk de bedoeling, dus het lijkt me goed om dat ook expliciet te stellen. Daarnaast staat er niet wat er moet gebeuren als dit niet lukt of kan. Alternatief voorstel voor deze tekst:

Bij deze afleidingswijzen MOET het ZRC de Zaak.archiefactiedatum bij het afsluiten van de zaak volgens onderstaande instructie vullen. Als dit niet mogelijk is MOET het ZRC antwoorden met een HTTP 400 foutbericht.

Zetten van het veld Zaak.archiefstatus
Hier zou @hdksi nog op terugkomen, maar daar toch vast even op vooruitlopend... Volgens mij kan met de voorgestelde wijziging voor ZRC-021 het directe probleem waar dit ticket voor geopend is opgelost worden en is het daarvoor niet strikt noodzakelijk om iets met de archiefstatus te doen.

Desalniettemin is dit wel een belangrijk onderwerp: er is nu niet goed in de standaard vastgelegd hoe, wanneer en door welke component dit veld gevuld moet worden, met als consequentie dat het momenteel eigenlijk altijd op nog_te_archiveren blijft staan. Zelfs de tutorial archiveren zegt eigenlijk niks over dit veld en laat het op die waarde staan. Terwijl de correcte vulling van dit veld wel van belang is voor de werking van archiefsystemen. Mogelijk is het beter hier een losstaand ticket voor aan te maken?

[MarcoKlerks]

Dit issue is gerelateerd aan #1850 .

[hdksi]

Dit issue is gerelateerd aan #1850.

...en eigenlijk ook aan #1849 en daaraan gerelateerde user story's.

Verplicht maken van Resultaattype.archiefactietermijn
[...]
Door Resultaattype.archiefactietermijn verplicht te maken, wordt in feite uitgesloten dat een permanent archief ZGW conform kan zijn. Tenzij er een specifieke waarde komt voor 'oneindig', maar ik weet niet of dat technisch verstandig is in een veld in het ISO 8601 periode formaat, dat kent zo ver ik weet geen waarde voor oneindig.

Niet helemaal mee eens. Buiten het feit dat waarde 'oneindig' of leeg in geval van blijvend bewaren niet aansluit bij de toelichting bij het attribuut in de specificatie van de Catalogi API, is de archiefactietermijn nodig om de archiefactiedatum van een zaak te bepalen. En die is weer nodig om te bepalen wanneer er overgebracht moet worden. Overbrengen is niet alleen een 'fysieke' handeling waarbij het zaakdossier van het ene systeem naar het andere wordt overgeheveld, maar ook een juridische, omdat na overbrenging het juridisch kader van de Archiefwet geldt in plaats van het kader van de Wet Open Overheid.

Ook als je het Zakenregister als e-depot wil inzetten om zaken na overbrengen van daaruit beschikbaar te stellen moet je een indicatie hebben of de zaak is 'overgebracht' of niet. Laat je de archiefactietermijn leeg, of zet je die op oneindig, dan ontbreekt die indicatie. Dat is dus geen optie als je je archivering op orde wil hebben. Bovendien kan je een blijvend te bewaren zaak die is overgebracht is prima - vooruit, het is niet fraai - herkennen aan een gepasseerde archiefactiedatum en archiefnominatie 'Blijvend bewaren'.

Los van het bovenstaande vind ik het voorstel om van de archiefactietermijn eenvoudigweg de 'bewaartermijn' - want alleen gevuld voor te vernietigen zaken - te maken eigenlijk veel begrijpelijker dan de constructie met archiefactietermijn. Maar om hierboven beschreven redenen hebben we dan dus nog steeds een construct nodig om te weten wanneer er 'overgebracht' is of moet worden. De breaking changes die deze wijziging met zich meebrengt lijken me gewonnen begrijpelijkheid bovendien niet meteen waard.

Ontbrekend object versus ontbrekende waarde in datumveld

Klopt helemaal. Ik zou deze nuance graag aanbrengen, maar ben in dubio over of dat verstandig is. Het feit dat een aantal gemeenten al twee jaar op basis van deze standaarden werkt en we nu pas dit probleem ontdekken doet vermoeden dat de gedragsregels niet heel scherp gelezen worden. Kan me voorstellen dat een feitelijk juister/completer overzicht met alle mogelijke uitkomsten bij leveranciers leidt tot het oordeel "te complex" - waarna uiteindelijk mogelijk juist minder in plaats van meer gedrag wordt geïmplementeerd.

Zetten van het veld Zaak.archiefstatus

De oplossing hierbij moet eigenlijk onderdeel zijn van en passen binnen een bredere uiteenzetting over (systeem)rollen en verantwoordelijkheden bij informatiebeheerhandelingen in een gedistribueerd gegevenslandschap. Nu dit vraagstuk niet meteen het oplossen van het gevonden issue in de weg staat, stel ik inderdaad voor hiervoor een eigen issue te maken.

[MNIJ]

Verplicht maken van Resultaattype.archiefactietermijn
Niet helemaal mee eens. Buiten het feit dat waarde 'oneindig' of leeg in geval van blijvend bewaren niet aansluit [...]

Ik volg je, ook al zou ik hier nog even naar willen laten kijken door gebruikers of collega's die wat dieper in de archiveringsmaterie zitten dan ik.
Ik vraag me wel af wat de praktische consequenties gaan zijn als dit veld verplicht wordt: We hebben het verder over een non-breaking wijziging aan de ZRC, maar dit impliceert dat deze wijziging ook een aanpassing aan de ZTC vereist, het veld Resultaattype.archiefactietermijn zit immers in de ZTC. En wat gebeurt er dan voor bestaande zaken van zaaktypen waar al resultaattypen met Resultaattype.archiefactietermijn = null bij horen. Dat is 100% zeker in de praktijk het geval.

Ontbrekend object versus ontbrekende waarde in datumveld
[...] Ik zou deze nuance graag aanbrengen, maar ben in dubio over of dat verstandig is [...]

Mee eens. Ik dacht hetzelfde toen ik het opschreef, maar wilde niet vanuit een leverancier de simpelere maar iets minder correcte oplossing promoten :-)

Zetten van het veld Zaak.archiefstatus
[...] stel ik inderdaad voor hiervoor een eigen issue te maken [...]

Mee eens.

[MNIJ]

De archiefspecialisten van de gemeenten die ik heb geconsulteerd onderschrijven inderdaad jouw stelling @hdksi, dat archiefactietermijn ook bij blijvend_bewaren verplicht zou moeten zijn.

Daarmee blijft de vraag over de praktische consequenties natuurlijk wel staan.

[hdksi]

Bovendien kan je een blijvend te bewaren zaak die is overgebracht is prima - vooruit, het is niet fraai - herkennen aan een gepasseerde archiefactiedatum en archiefnominatie 'Blijvend bewaren'.

Ik zie trouwens dat Zaak.archiefstatus ook een toegestane waarde waarde overgebracht heeft, da's weer iets fraaier :)

Mee eens. Ik dacht hetzelfde toen ik het opschreef, maar wilde niet vanuit een leverancier de simpelere maar iets minder correcte oplossing promoten :-)

Om dit echt goed te organiseren hebben we uiteindelijk denk ik een eenvoudiger toepasbaar en minder multi-interpretabel middel dan een bedrijfs-/gedragsregel nodig. Ik weet nog niet precies hoe dat eruit moet zien, maar houd me aanbevolen voor suggesties :)

Daarmee blijft de vraag over de praktische consequenties natuurlijk wel staan.

En precies die vind ik moeilijk te overzien. Als je jouw interpretatie van ZRC-021 volgt en:

Het veld [Zaak.archiefactiedatum] gezet MOET worden, dus als dat niet MAG, dan kan de operatie dus niet plaatsvinden.

dan was Resultaattype.archiefactietermijn de facto al verplicht omdat je die zonder archiefactietermijn niet kunt bepalen. Echter hebben we al eerder gezien dat je deze regel op meerdere manieren kunt lezen...

[hdksi]

Bijgewerkt voorstel:

Afleiden van archiveringsparameters (ZRC-021 vervangt ook ZRC-022)

Indien Zaak.archiefactiedatum bij het afsluiten van de zaak geen waarde heeft, maar deze wel bepaald kan worden, dan MOET Zaak.archiefactiedatum vóór het afsluiten van de zaak gezet worden. Hiervoor is het nodig de brondatum voor de archiefprocedure te kunnen bepalen. Belangrijk hierbij is het attribuut afleidingswijze dat is geregistreerd bij het voor het resultaat van de zaak relevante resultaattype. Hieronder is per afleidingswijze beschreven in welke gevallen en op welke manier de archiefactiedatum gevonden kan worden.

1. Indien Resultaat.Resultaattype.brondatumArchiefprocedure.afleidingswijze de waarde afgehandeld, eigenschap, ingangsdatum_besluit of termijn heeft, is het bepalen van de brondatum voor de archiefprocedure - en daarmee Zaak.archiefactiedatum in alle gevallen mogelijk. Bij deze afleidingswijzen MOET Zaak.archiefactiedatum dus bij het afsluiten van de zaak volgens onderstaande instructie gevuld zijn. Indien dit niet het geval is, dan MOET de ZRC met een HTTP 400 foutbericht antwoorden. [IH: en moet de ZRC ook controleren of de juíste datum is gezet?]

   • afgehandeld -> Zaak.archiefactiedatum = Zaak.einddatum + Resultaat.Resultaattype.archiefactietermijn.
   • eigenschap -> Zaak.archiefactiedatum = de waarde van de eigenschap waar de naam overeenkomt met Resultaat.Resultaattype.brondatumArchiefprocedure.datumkenmerk + Resultaat.Resultaattype.archiefactietermijn.
   • ingangsdatum_besluit -> Zaak.archiefactiedatum = Besluit.ingangsdatum bij het besluit waarvan de ingangsdatum van alle gerelateerde besluiten het verst in de toekomst ligt + Resultaat.Resultaattype.archiefactietermijn.
   • termijn -> Zaak.archiefactiedatum = Zaak.einddatum + Resultaat.Resultaattype.brondatumArchiefprocedure.procestermijn + Resultaat.Resultaattype.archiefactietermijn.

2. Indien Resultaat.Resultaattype.brondatumArchiefprocedure.afleidingswijze de waarde ander_datumkenmerk, gerelateerde_zaak, hoofdzaak, vervaldatum_besluit of zaakobject dan MOET Zaak.archiefactiedatum gevuld zijn als de brondatum voor de archiefprocedure bepaald kan worden. Daarvan is per afleidingswijze sprake in het volgende geval: [IH: welke hiervan kunnen geautomatiseerd door de ZRC gecontroleerd worden en zouden dus kunnen moeten resulteren in een foutbericht?]

   • ander_datumkenmerk -> De brondatum kan bepaald worden als de combinatie van Resultaat.Resultaattype.brondatumArchiefprocedure.objecttype, registratie en datumkenmerk verwijst naar een attribuut dat overeenkomt met datumkenmerk en daarbij een geldige (datum)waarde is geregistreerd. Het bepalen hiervan is een handmatige handeling. Zaak.archiefactiedatum = de gevonden (datum)waarde + Resultaat.Resultaattype.archiefactietermijn.
   • gerelateerde_zaak -> De brondatum kan bepaald worden als bij tenminste één van de gerelateerde zaken Zaak.einddatum geregistreerd is. Zaak.archiefactiedatum = Zaak.einddatum bij de gerelateerde zaak waarvan de einddatum van alle gerelateerde zaken het verst in de toekomst ligt +Resultaat.Resultaattype.archiefactietermijn.
   • hoofdzaak -> De brondatum kan bepaald worden als Zaak.hoofdzaak.einddatum een waarde heeft. Zaak.archiefactiedatum = Zaak.hoofdzaak.einddatum + Resultaat.Resultaattype.archiefactietermijn.
   • vervaldatum_besluit -> De brondatum kan bepaald worden als bij tenminste één van de gerelateerde besluiten Besluit.vervaldatum geregistreerd is. Zaak.archiefactiedatum = Besluit.vervaldatum bij het besluit waarvan de vervaldatum van alle gerelateerde besluiten het verst in de toekomst ligt +Resultaat.Resultaattype.archiefactietermijn.
   • zaakobject -> De brondatum kan bepaald worden als tenminste één van de aan de zaak gerelateerde objecten van het type Resultaat.Resultaattype.brondatumArchiefprocedure.objecttype het attribuut dat overeenkomt met Resultaat.Resultaattype.brondatumArchiefprocedure.datumkenmerk een geldige (datum)waarde is geregistreerd. Zaak.archiefactiedatum = gevonden (datum)waarde bij het zaakobject waarvan de bij het datumkenmerk opgegeven datum van alle zaakobjecten van het overeenkomende type het verst in de toekomst ligt + Resultaat.Resultaattype.archiefactietermijn.

In alle gevallen dat de archiefactiedatum bij het afsluiten van de zaak bepaald kan worden, en bij Zaak.archiefactiedatum (dus) een geldige datumwaarde is gezet MOET bij Zaak.archiefstatus vóór het afsluiten van de zaak de waarde gearchiveerd gezet worden. Indien dit niet het geval is, dan MOET de ZRC met een HTTP 400 foutbericht antwoorden.

In alle andere gevallen kan de archiefactiedatum bij het afsluiten van de zaak niet bepaald worden en MOET Zaak.archiefactiedatum leeg blijven. In dit geval MOET bij Zaak.archiefstatus vóór het afsluiten van de zaak de waarde gearchiveerd_procestermijn_onbekend gezet worden. Indien dit niet het geval is, dan MOET de ZRC met een HTTP 400 foutbericht antwoorden.

Indien Zaak.archiefnominatie bij het afsluiten van de zaak geen waarde heeft, dan MOET deze vóór het afsluiten overgenomen worden uit Resultaat.Resultaattype.archiefnominatie. Indien dit niet het geval is, dan MOET de ZRC met een HTTP 400 foutbericht antwoorden.

[hdksi]

@michielverhoef, @ArjanKloosterboer, en eventueel @MarcoKlerks en @joeribekker het gaat enige tijd kosten om het bovenstaande te doorgronden, maar ik ben naarstig op zoek naar:

1. een kritische blik op het bovenstaande voorstel, én
2. reacties bij vraag of we Resultaattype.archiefactietermijn en bij nader inzien mogelijk ook Resultaattype.archiefnominatie verplicht zouden moeten stellen. Als we dat laatste niet willen moet bovenstaand voorstel daarop uiteraard nog worden aangepast.

Ik ben niet de PO, maar gezien de deadline voor de versie 1.3-release van de Zaken API lijkt me het niet haalbaar en vanuit oogpunt van zorgvuldigheid ook niet wenselijk dit voorstel of een aangepaste versie daarvan daarin nog op te nemen.

[MNIJ]

[...] dan was Resultaattype.archiefactietermijn de facto al verplicht omdat je die zonder archiefactietermijn niet kunt bepalen.

Goed punt. Dit bezwaar vervalt wat mij betreft. Betekent mogelijk een reparatieactie op bestaande data, maar dat is overkomelijk.

Verder kan ik me ook vinden in het nieuwe voorstel. Ik zie dat het zetten van Zaak.Archiefstatus er toch nog in staat ondanks de eerdere discussen hierover en daar ben ik het eerlijk gezegd wel mee eens, het zetten van dit veld hoort echt bij deze stap in het proces.
Vervalt hiermee het deel van ZRC-022 dat vereist dat alle gerelateerde informatieobjecten de status gearchiveerd moeten hebben? Of moet de ZRC dit controleren en een foutmelding geven als dit niet zo is?

Kleine terzijde: ik zie niet in hoe de afleidingswijze gerelateerde_zaak in de praktijk kan werken aangezien er allerlei verschillende zaakrelaties met verschillende functionele betekenis bij een zaak kunnen bestaan en het bij deze afleidingswijze functioneel gezien om een specifieke zaak zal gaan en niet de zaak met toevallig de laatste einddatum op moment van sluiten van de onderhavige zaak. Maar dat is een probleem dat we volgens mij niet in dit issue moeten proberen op te lossen. Enige mogelijke oplossing die ik nu zie is bij deze afleidingswijze altijd zaak.archiefstatus = gearchiveerd_procestermijn_onbekend te zetten als er meer dan 1 gerelateerde zaak is.

[MNIJ]

2. reacties bij vraag of we Resultaattype.archiefactietermijn en bij nader inzien mogelijk ook Resultaattype.archiefnominatie verplicht zouden moeten stellen. Als we dat laatste niet willen moet bovenstaand voorstel daarop uiteraard nog worden aangepast.

Resultaattype.archiefnominatie is een non-nullable Enum en daarmee al verplicht.

[ArjanKloosterboer]

Vooruit, een kritische blik op je bijgewerkte voorstel. Referentie voor mij is RGBZ 2.0. Ik weet niet zeker of alles wat daarin zit ook geïmplementeerd is in de API. Zo niet, dan leidt dat tot problemen ...

Indien Zaak.archiefactiedatum bij het afsluiten van de zaak geen waarde heeft, maar deze wel bepaald kan worden, dan MOET Zaak.archiefactiedatum vóór het afsluiten van de zaak gezet worden.
M.i. kan dat scherper, refererend aan regel 1 van de attribuutsoort Archiefactiedatum: "Dit attribuutsoort moet van een waarde voorzien zijn als de attribuutsoort ‘Archiefstatus’ een waarde ongelijk "nog te archiveren" en "gearchiveerd (procestermijn onbekend)" heeft." Aangezien bij afsluiten 'nog te archiveren" niet toegestaan is, resteren twee vragen: wanneer is sprake van 'gearchiveerd (procestermijn onbekend)' en zo niet, hoe moet de waarde van de archiefactiedatum bepaald worden? Je voorstel lijkt vooral over het tweede te gaan waarin het eerste verwerkt is. Ik twijfel of het goed leesbaar is als deze twee door elkaar lopen, en of ze juist zijn.
Van 'gearchiveerd (procestermijn onbekend)' is m.i. sprake indien de Archiefnominatie 'vernietigen' is, de Brondatum archiefprocedure - Afleidingswijze (ZTC) ongelijk 'afgehandeld' en 'termijn' is, de Brondatum archiefprocedure - Einddatum bekend (ZTC) de waarde 'nee' heeft en de datum van het desbetreffende Brondatum archiefprocedure - Datumkenmerk niet van een waarde is voorzien. Oftewel, de archiefactietermijn is afhankelijk van een ander datumveld dan de einddatum van de zaak en dat datumveld hoeft bij het afsluiten van de zaak niet persé van een waarde voorzien te zijn en heeft inderdaad geen waarde bij het afsluiten van de zaak. In alle andere gevallen moet de Archiefactiedatum wel van een waarde voorzien worden.
Wat er in de eerste zin van ad. 1 staat, klopt in dit licht niet. Alleen bij 'afgehandeld' en 'termijn' moet de Archiefactiedatum zonder meer van een waarde voorzien worden. In de andere genoemde gevallen hangt dat van de omstandigheden af. Iets vergelijkbaars geldt voor de 1e zin van ad. 2.

Als dan de Archiefactiedatum van een waarde voorzien moet worden, dan is vervolgens de vraag hoe. Je besteed geen aandacht aan de Archiefnominatie 'bewaren'. Lijkt me een gemis. Verder werk je dit mooi uit in de opsommingen onder ad. 1 en 2. Ik merk dat het bij 'ingangsdatum besluit', 'vervaldatum besluit' en 'gerelateerde zaak' niet lekker loopt. Indien er sprake is van meer dan één besluit resp. gerelateerde zaak bij de zaak, dan moet m.i. de gebruiker gevraagd worden welk besluit resp. gerelateerde zaak het betreft. Bij 'zaakobject' is het vergelijkbaar. Het betreft het aan de zaak gerelateerde (zaak)object van het objecttype dat vermeld is in Brondatum archiefprocedure - Objecttype (ZTC). Zijn er daarvan meer dan één gerelateerd aan de zaak, dan moet de gebruiker weer aangeven welke.

reacties bij vraag of we Resultaattype.archiefactietermijn en bij nader inzien mogelijk ook Resultaattype.archiefnominatie verplicht zouden moeten stellen.
In RGBZ 2 zijn beide attributen verplicht van een waarde te voorzien. Duidelijk antwoord?

Vervalt hiermee het deel van [ZRC-022](https://vng-realisatie.github.io/gemma-zaken/standaard/zaken/index#zrc-022) dat vereist dat alle gerelateerde informatieobjecten de status gearchiveerd moeten hebben?
In RGBZ 2 staat bij de attribuutsoort Archiefstatus als eis "Indien het attribuutsoort een waarde ongelijk "Nog te archiveren" heeft, dan moet van alle ENKELVOUDIGE INFORMATIEOBJECTen die via INFORMATIEOBJECT en de ZAAK-INFORMATIEOBJECT-relatie aan de zaak gerelateerd zijn, het attribuutsoort 'Status' de waarde "Gearchiveerd" hebben." Dus als antwoord zou ik zeggen: nee, die vervalt niet.

[ArjanKloosterboer]

In aanvulling en wellicht ten overvloede, in dit document is de analyse opgenomen van wat de (toen nieuwe) Selectielijst voor gevolgen heeft voor ZTC en RGBZ. Dat heeft geleid tot bovengenoemde attributen.

[hdksi]

Resultaattype.archiefnominatie is een non-nullable Enum en daarmee al verplicht.

Klopt, te snel gekeken, da's alvast een zorg minder :). Ik ben nog niet aan een reactie op de bijdrage van Arjan toegekomen, maar ben die ook niet vergeten. Begin volgende week volgt een inhoudelijke reactie.

[michielverhoef]

@michielverhoef, @ArjanKloosterboer, en eventueel @MarcoKlerks en @joeribekker het gaat enige tijd kosten om het bovenstaande te doorgronden, maar ik ben naarstig op zoek naar:

1. een kritische blik op het bovenstaande voorstel, én

2. reacties bij vraag of we `Resultaattype.archiefactietermijn` en bij nader inzien mogelijk ook `Resultaattype.archiefnominatie` verplicht zouden moeten stellen. Als we dat laatste niet willen moet bovenstaand voorstel daarop uiteraard nog worden aangepast.

Ik ben niet de PO, maar gezien de deadline voor de versie 1.3-release van de Zaken API lijkt me het niet haalbaar en vanuit oogpunt van zorgvuldigheid ook niet wenselijk dit voorstel of een aangepaste versie daarvan daarin nog op te nemen.

Dit was ook mijn conclusie. Ik verplaats dit issue naar de 1.4 release. Beter iets later een goede uitwerking dan snel iets wat niet klopt.

[hdksi]

Dankjewel @ArjanKloosterboer voor je kritische blik. Naar aanleiding daarvan zal ik nog eens kijken of ik een en ander eenvoudiger, begrijpelijker en/of bondiger kan opschrijven. Starten met de archiefstatus en archiefnominatie lijkt daarbij in ieder geval een goed idee. Maar eerst een tweetal inhoudelijke vragen bij je reactie.

Wat er in de eerste zin van ad. 1 staat, klopt in dit licht niet. Alleen bij 'afgehandeld' en 'termijn' moet de Archiefactiedatum zonder meer van een waarde voorzien worden. In de andere genoemde gevallen hangt dat van de omstandigheden af. Iets vergelijkbaars geldt voor de 1e zin van ad. 2.

Mijn redenering om ook eigenschap en ingangsdatum_besluit in deze categorie op te nemen is de volgende:

• eigenschap: het afsluiten van een zaak betekent dat die niet meer gewijzigd kan worden. Eigenschappen zijn onderdeel van de zaak. Bij het afsluiten van de zaak moet dus bij een (van de) eigenschap(pen) een geldige datumwaarde geregistreerd zijn. Is dat niet zo, dan is ergens is misgegaan. In alle 'normale' gevallen is de archiefactiedatum te bepalen.
• ingangsdatum_besluit: deze afleidingswijze kan alleen worden toegepast voor zaken waarvoor als onderdeel van het zaakdossier een besluit geregistreerd is. Dit besluit moet zijn geregistreerd voor de zaak te sluiten. Bij het registeren van een besluit is ingangsdatum een verplicht kenmerk. Is wel sprake van deze afleidingswijze, maar geen besluit geregistreerd óf wel een besluit maar geen ingangsdatum vastgelegd, dan is er iets misgegaan. In alle 'normale' gevallen is de archiefactiedatum te bepalen.

Zie ik hier ergens iets over het hoofd?

Indien er sprake is van meer dan één besluit resp. gerelateerde zaak bij de zaak, dan moet m.i. de gebruiker gevraagd worden welk besluit resp. gerelateerde zaak het betreft.

Je bedoelt bij meerdere opties de vraag welke ingangsdatum/vervaldatum/einddatum/waarde datumkenmerk bij object als uitgangspunt genomen moet worden voor het bepalen van de archiefactiedatum? Het zou me vanuit het oogpunt van automatisering een lief ding waard zijn als we een principe als "bij meerdere matches geldt de datum die het verst in de toekomst ligt" kunnen omarmen. Maar dat is misschien meer een vraag voor de Adviescommissie Archieven.

In RGBZ 2 zijn beide attributen verplicht van een waarde te voorzien. Duidelijk antwoord?

Dat was de reden voor te stellen archiefactietermijn verplicht te maken. Want als die niet bekend is loopt dit hele proces (en dus het volgen van deze bedrijfsregel) spaak...

[michielverhoef]

Zie ook #2085

[ArjanKloosterboer]

In reactie op Hdski dd. 12-7:

Mijn redenering om ook eigenschap en ingangsdatum_besluit in deze categorie op te nemen is de volgende:

• eigenschap: het afsluiten van een zaak betekent dat die niet meer gewijzigd kan worden. Eigenschappen zijn onderdeel van de zaak. Bij het afsluiten van de zaak moet dus bij een (van de) eigenschap(pen) een geldige datumwaarde geregistreerd zijn. Is dat niet zo, dan is ergens is misgegaan. In alle 'normale' gevallen is de archiefactiedatum te bepalen.
• ingangsdatum_besluit: deze afleidingswijze kan alleen worden toegepast voor zaken waarvoor als onderdeel van het zaakdossier een besluit geregistreerd is. Dit besluit moet zijn geregistreerd voor de zaak te sluiten. Bij het registeren van een besluit is ingangsdatum een verplicht kenmerk. Is wel sprake van deze afleidingswijze, maar geen besluit geregistreerd óf wel een besluit maar geen ingangsdatum vastgelegd, dan is er iets misgegaan. In alle 'normale' gevallen is de archiefactiedatum te bepalen.

Zie ik hier ergens iets over het hoofd?

Ja, maar wellicht ook 'nee'. Volgens het ImZTC kan het zo zijn dat de attribuutsoort 'Einddatum bekend' in deze gevallen de waarde 'nee' heeft oftewel die eigenschap of ingangsdatum-besluit hoeft nog geen waarde te hebben. De vraag is of dat reeel is. Nu ik dit zo lees neig ik met je mee te gaan. Oftewel 'Einddatum bekend' moet de waarde 'ja' hebben indien afleidingswijze de waarde 'eigenschap' of 'ingangsdatum-besluit' heeft. Dit kan consequenties hebben voor de bedrijfsregels in het RGBZ bij desbetreffende attribuutsoorten (die eigenschap of ingangsdatum-besluit moet dan wel van een waarde zijn voorzien).

Je bedoelt bij meerdere opties de vraag welke ingangsdatum/vervaldatum/einddatum/waarde datumkenmerk bij object als uitgangspunt genomen moet worden voor het bepalen van de archiefactiedatum? Het zou me vanuit het oogpunt van automatisering een lief ding waard zijn als we een principe als "bij meerdere matches geldt de datum die het verst in de toekomst ligt" kunnen omarmen. Maar dat is misschien meer een vraag voor de Adviescommissie Archieven.

M.i. is dat te kort door de bocht. Er zal in een praktijksituatie een specifieke gerelateerde zaak of object van belang zijn; die moet dan wel aangewezen worden. Overigens vermoed ik dat dergelijke situaties slechts incidenteel voor zullen komen. De vraag is of je ook die helemaal wilt 'wegautomatiseren'.

[hdksi]

Hier nogmaals naar gekeken. Eerst nog een paar verlate reacties bij de opmerkingen van @ArjanKloosterboer en een van @MNIJ:

M.i. kan dat scherper, refererend aan regel 1 van de attribuutsoort Archiefactiedatum: "Dit attribuutsoort moet van een waarde voorzien zijn als de attribuutsoort ‘Archiefstatus’ een waarde ongelijk "nog te archiveren" en "gearchiveerd (procestermijn onbekend)" heeft." Aangezien bij afsluiten 'nog te archiveren" niet toegestaan is, resteren twee vragen: wanneer is sprake van 'gearchiveerd (procestermijn onbekend)' en zo niet, hoe moet de waarde van de archiefactiedatum bepaald worden? Je voorstel lijkt vooral over het tweede te gaan waarin het eerste verwerkt is. Ik twijfel of het goed leesbaar is als deze twee door elkaar lopen, en of ze juist zijn.

Dit lijkt inderdaad scherper, maar ik zie niet goed hoe ik mijn eerdere voorstel hiermee kan vereenvoudigen. Immers: archiefstatus is bij sluiten zaak ≠ nog te archiveren. In de praktijk kan op dat moment zoals mijn tekstvoorstel beschrijft worden gekozen uit gearchiveerd en gearchiveerd (procestermijn onbekend) - of zijn er uitzonderingen waarin meteen vernietigd wordt? Die 'keuze' (gevolg) wordt echter bepaald door het antwoord op de vraag of de archiefactiedatum kan worden bepaald (oorzaak). Daarom begin ik met dat archiefactiedatum, en niet met archiefstatus. Maar suggesties voor hoe het beter of met name eenvoudiger kan blijven welkom.

Als dan de Archiefactiedatum van een waarde voorzien moet worden, dan is vervolgens de vraag hoe. Je besteed geen aandacht aan de Archiefnominatie 'bewaren'. Lijkt me een gemis.

De waarde bij archiefnominatie maakt voor de werking van deze bedrijfsregel toch niet uit? Bij nader inzien stel ik vanwege een ontbrekende directe relatie met archiefactiedatum en archiefstatus zelfs voor om hier een losse bedrijfsregel van te maken. Of zie ik iets over het hoofd?

Ja, maar wellicht ook 'nee'. Volgens het ImZTC kan het zo zijn dat de attribuutsoort 'Einddatum bekend' in deze gevallen de waarde 'nee' heeft oftewel die eigenschap of ingangsdatum-besluit hoeft nog geen waarde te hebben. De vraag is of dat reeel is. Nu ik dit zo lees neig ik met je mee te gaan. Oftewel 'Einddatum bekend' moet de waarde 'ja' hebben indien afleidingswijze de waarde 'eigenschap' of 'ingangsdatum-besluit' heeft. Dit kan consequenties hebben voor de bedrijfsregels in het RGBZ bij desbetreffende attribuutsoorten (die eigenschap of ingangsdatum-besluit moet dan wel van een waarde zijn voorzien).

Na herlezing denk ik nog steeds dat mijn gedachtegang klopt; ik kies dus voor 'nee' :) Dat betekent inderdaad dat we naar de bedrijfsregels bij het RGBZ moeten kijken.

Kleine terzijde: ik zie niet in hoe de afleidingswijze gerelateerde_zaak in de praktijk kan werken aangezien er allerlei verschillende zaakrelaties met verschillende functionele betekenis bij een zaak kunnen bestaan en het bij deze afleidingswijze functioneel gezien om een specifieke zaak zal gaan en niet de zaak met toevallig de laatste einddatum op moment van sluiten van de onderhavige zaak. Maar dat is een probleem dat we volgens mij niet in dit issue moeten proberen op te lossen. Enige mogelijke oplossing die ik nu zie is bij deze afleidingswijze altijd zaak.archiefstatus = gearchiveerd_procestermijn_onbekend te zetten als er meer dan 1 gerelateerde zaak is.

en

M.i. is dat te kort door de bocht. Er zal in een praktijksituatie een specifieke gerelateerde zaak of object van belang zijn; die moet dan wel aangewezen worden. Overigens vermoed ik dat dergelijke situaties slechts incidenteel voor zullen komen. De vraag is of je ook die helemaal wilt 'wegautomatiseren'.

Hiermee ben ik het wel eens. Maar dit betekent dat voor de genoemde afleidingswijzen misschien wel en misschien niet de archiefactiedatum bepaald kan worden. Ik ben bang dat de complexiteit van de regel daardoor nog groter wordt. Zal maandag evengoed een poging wagen om dit inzicht te verwerken.

[hdksi]

Vreemd, ik dacht echt dat ik al een tijd geleden een bijgewerkt voorstel had gedaan. Misschien vergeten te posten? Nieuwe poging, waarin ik:

1. de vraag of de Zaken API ook moet controleren of de juíste (archiefactie)datum is gezet negatief heb beantwoord. Dit lijkt me te complex worden. Wel heb ik een tabel ingevoegd die (hopelijk) meer inzicht geeft in toegestane combinaties archiefkenmerken.
2. het inzicht van @ArjanKloosterboer heb verwerkt dat een bij een gerelateerde zaak/besluit/object vastgelegde datumkenmerk dat het verst in de toekomst ligt niet altijd het voor archivering relevante kenmerk hoeft te zijn. Het bepalen hiervan wordt hierdoor een handmatige exercitie.
3. de gedragsregels voor het vullen archiefnominatie en archiefstatus uit eerdere voorstellen voor een aanpassing van zrc-21 heb verplaatst naar zrc-007 - waar ze omwille van hun relatie met het afsluiten van de zaak volgens mij logischer staan.
4. naar aanleiding van het overhevelen van (potentiële) validaties die te maken hebben met archiefparameters uit eerdere voorstellen voor zrc-021 naar zrc-007 de vraag stel of die eerste nog wel gezien moet worden als gedragsregel voor implementaties van de Zaken API, of dat hier in feite sprake is van een beschrijving van eventueel te automatiseren gedrag van een consumercomponent die de Zaken API bedient. Omdat ik vind dat sprake is van het laatste, stel ik voor de bijbehorende tekst elders als onderdeel van de documentatie beschikbaar te stellen.

Voorstel
Als 3. en 4. op instemming kunnen rekenen, is het resultaat van dit issue een uitbreiding van zrc-007 als hieronder omschreven en het vervallen van zrc-021 en -022. Wel nemen we elders (ik stel voor als onderdeel van https://vng-realisatie.github.io/gemma-zaken/themas/achtergronddocumentatie/archiveren) een handreiking op die toelicht of, en zo ja hoe de archiefactiedatum gevonden kan worden. Bijkomend voordeel is dat deze handreiking niet meer 'hard' is gekoppeld aan het afsluiten van een zaak; volgens mij kunnen deze handelingen immers op ieder gewenst moment worden uitgevoerd.

Afsluiten zaak (zrc-007 - huidige versie, wijzigingen in cursief)

Een Zaak MOET een Resultaat hebben voor deze afgesloten kan worden.

Indien Zaak.archiefnominatie geen waarde heeft, dan MOET deze vóór het afsluiten overgenomen worden uit Resultaat.Resultaattype.archiefnominatie. Als Resultaat.Resultaattype.archiefnominatie bij het afsluiten toch leeg is, moet de Zaken API met een HTTP 400 foutbericht antwoorden.

Bij het afsluiten van een Zaak MOET de Zaken API het Informatieobject.indicatieGebruiksrecht controleren van alle gerelateerde informatieobjecten. Deze MAG NIET null zijn, maar MOET true of false zijn. Indien dit niet het geval is, dan dient de Zaken API een validatiefout te genereren met code indicatiegebruiksrecht-unset.

Bij het afsluiten van de Zaak MOETEN alle gerelateerde informatieobjecten de status gearchiveerd hebben.

Als de archiefactiedatum van de Zaak op het moment van afsluiten bepaald is of bepaald kan worden (zie [Toelichting bij het bepalen van de archiefactiedatum] om bepalen of hiervan sprake is), MOET Zaak.archiefactiedatum zijn gevuld met een geldige waarde en MOET Zaak.archiefstatus zijn gevuld met een andere waarde dan nog_te_archiveren en gearchiveerd_procestermijn_onbekend. Als sprake is van een ongeldige combinatie van Resultaat.Resultaattype.brondatumArchiefprocedure.afleidingswijze (verticale as in onderstaande tabel), Zaak.archiefactiedatum (in cel) en Zaak.archiefstatus (horizontale as) MOET de Zaken API met een HTTP 400 foutbericht antwoorden.

Als de archiefactiedatum van de Zaak op het moment van afsluiten niet bepaald is, en ook niet bepaald kan worden (zie [Toelichting bij het bepalen van de archiefactiedatum] om bepalen of hiervan sprake is), MOET de waarde van Zaak.archiefactiedatum null zijn en MOET Zaak.archiefstatus zijn gevuld met de waarde gearchiveerd_procestermijn_onbekend. Als sprake is van een ongeldige combinatie van Resultaat.Resultaattype.brondatumArchiefprocedure.afleidingswijze (verticale as in onderstaande tabel), Zaak.archiefactiedatum (in cel) en Zaak.archiefstatus (horizontale as) MOET de Zaken API met een HTTP 400 foutbericht antwoorden.

	gearchiveerd	gearchiveerd_procestermijn_onbekend	overgedragen
afgehandeld	archiefactiedatum v.v. datumwaarde (in de toekomst)	niet toegestaan	archiefactiedatum v.v. datumwaarde (in het verleden)
termijn
ingangsdatum_besluit
eigenschap
hoofdzaak		archiefactiedatum leeg ('null')
gerelateerde_zaak
vervaldatum_besluit
zaakobject
ander_datumkenmerk

Een zaak wordt afgesloten door een eindstatus toe te kennen aan een Zaak. Elk Zaaktype MOET minimaal één Statustype kennen. De eindstatus binnen een Zaaktype is het Statustype met het hoogste volgnummer. -> IH: Ik vraag me af de cursieve laatste zinnen niet thuishoren in de gedragsregels van de Catalogi API in plaats van op deze plaats

Zaak.einddatum MOET logisch afgeleid worden uit het toekennen van de eindstatus via de Status.datumStatusGezet.

Als een Zaak een eindstatus heeft dan is de zaak afgesloten en mogen gegevens van de zaak niet meer aangepast worden (behalve om redenen van correctie). Dit MOET beveiligd worden met de scope zds.scopes.zaken.geforceerd-bijwerken. “Gegevens van de zaak” omvat hier ook de gerelateerde gegevens zoals klantcontacten, resultaat, rollen, statussen, zaakinformatieobjecten, zaakobjecten, zaakbesluiten en zaakeigenschappen.

zrc-021 en zrc-022 VERVALLEN als gedragsregel. In plaats daarvan publiceren we onderstaande toelichting bij het bepalen of en op welke manier de archiefactiedatum gevonden kan worden.

Toelichting bij het bepalen van de archiefactiedatum (GEEN GEDRAGSREGEL)

In veel gevallen kan de archiefactiedatum van de zaak bepaald worden. In dat geval is ofwel duidelijk dat het zaakdossier (eeuwig) bewaard moet blijven, ofwel duidelijk op welk moment dat vernietigd moet worden. In deze gevallen kan Zaak.archiefactiedatum worden gevuld met een geldige (datum)waarde, en is Zaak.archiefstatus voorzien van een andere waarde dan gearchiveerd_procestermijn_onbekend.

In sommige gevallen kan echter ondanks een bekende bewaartermijn niet worden bepaald hoe lang het zaakdossier moet worden bewaard, omdat het moment waarop die bewaartermijn start afhankelijk is van een gebeurtenis in de toekomst waarvan we nog niet weten wanneer die zal plaatsvinden. In dat laatste geval blijft Zaak.archiefactiedatum leeg (waarde null) omdat die niet bepaald kan worden, en wordt bij Zaak.archiefstatus de waarde gearchiveerd_procestermijn_onbekend - of als de zaak nog loopt nog_te_archiveren - geregistreerd.

Voor het bepalen van de archiefactiedatum zijn het resultaat van de zaak en het bijbehorende resultaattype bepalend. Bij dat resultaattype is de brondatum voor de archiefprocedure te vinden. Belangrijk is het daarbinnen opgenomen attribuut afleidingswijze.

Hieronder is voor ieder van de mogelijke afleidingswijzen beschreven in welke gevallen en op welke manier de archiefactiedatum voor een zaak gevonden kan worden:

1. Indien Resultaat.Resultaattype.brondatumArchiefprocedure.afleidingswijze de waarde afgehandeld, eigenschap, ingangsdatum_besluit of termijn heeft, is het bepalen van de brondatum voor de archiefprocedure - en daarmee Zaak.archiefactiedatum in alle gevallen mogelijk:

   • afgehandeld -> Zaak.archiefactiedatum = Zaak.einddatum + Resultaat.Resultaattype.archiefactietermijn.
   • eigenschap -> Zaak.archiefactiedatum = de waarde van de eigenschap waar de naam overeenkomt met Resultaat.Resultaattype.brondatumArchiefprocedure.datumkenmerk + Resultaat.Resultaattype.archiefactietermijn.
   • ingangsdatum_besluit -> Zaak.archiefactiedatum = Besluit.ingangsdatum bij het besluit dat (in het geval van meerdere besluiten) de archieftermijnen van de zaak bepaalt + Resultaat.Resultaattype.archiefactietermijn.
   • termijn -> Zaak.archiefactiedatum = Zaak.einddatum + Resultaat.Resultaattype.brondatumArchiefprocedure.procestermijn + Resultaat.Resultaattype.archiefactietermijn.

2. Indien Resultaat.Resultaattype.brondatumArchiefprocedure.afleidingswijze de waarde ander_datumkenmerk, gerelateerde_zaak, hoofdzaak, vervaldatum_besluit of zaakobject dan is het bepalen van de brondatum voor de archiefprocedure - en daarmee Zaak.archiefactiedatum in de volgende gevallen mogelijk:

   • ander_datumkenmerk -> De brondatum kan bepaald worden als de combinatie van Resultaat.Resultaattype.brondatumArchiefprocedure.objecttype, registratie en datumkenmerk verwijst naar een attribuut dat overeenkomt met datumkenmerk en daarbij een geldige (datum)waarde is geregistreerd. Het bepalen hiervan is een handmatige handeling. Zaak.archiefactiedatum = de gevonden (datum)waarde + Resultaat.Resultaattype.archiefactietermijn.
   • gerelateerde_zaak -> De brondatum kan bepaald worden als bij tenminste één van de gerelateerde zaken Zaak.einddatum geregistreerd is. Zaak.archiefactiedatum = Zaak.einddatum bij de gerelateerde zaak die (in het geval van meerdere gerelateerde zaken) de archieftermijnen van de zaak bepaalt +Resultaat.Resultaattype.archiefactietermijn.
   • hoofdzaak -> De brondatum kan bepaald worden als Zaak.hoofdzaak.einddatum een waarde heeft. Zaak.archiefactiedatum = Zaak.hoofdzaak.einddatum + Resultaat.Resultaattype.archiefactietermijn.
   • vervaldatum_besluit -> De brondatum kan bepaald worden als bij tenminste één van de gerelateerde besluiten Besluit.vervaldatum geregistreerd is. Zaak.archiefactiedatum = Besluit.vervaldatum bij het besluit dat (in het geval van meerdere besluiten) de archieftermijnen van de zaak bepaalt +Resultaat.Resultaattype.archiefactietermijn.
   • zaakobject -> De brondatum kan bepaald worden als tenminste één van de aan de zaak gerelateerde objecten van het type Resultaat.Resultaattype.brondatumArchiefprocedure.objecttype het attribuut dat overeenkomt met Resultaat.Resultaattype.brondatumArchiefprocedure.datumkenmerk een geldige (datum)waarde is geregistreerd. Zaak.archiefactiedatum = gevonden (datum)waarde bij het zaakobject dat (in het geval van meerdere gerelateerde objecten van het juist type) de archieftermijnen van de zaak bepaalt + Resultaat.Resultaattype.archiefactietermijn.

In de hierboven beschreven gevallen kan de archiefactiedatum bepaald worden,en MOET bij Zaak.archiefactiedatum de gevonden datumwaarde worden geregistreerd.

In alle andere gevallen kan de archiefactiedatum niet bepaald worden, en MOET Zaak.archiefactiedatum leeg blijven (dus zijn voorzien van waarde null).

Merk op dat ik hierboven de verwijzingen naar de 'ZRC' voor de begrijpelijkheid heb vervangen door 'Zaken API' - voorstel is die wijziging overal door te voeren.

NB 1: Ik vraag me ook vanwege ervaringen uit het verleden me af of we niet nog duidelijker moeten zijn over wanneer een zaak nu echt is 'afgesloten' en in welke volgorde de daarbij voorbereidende handelingen moeten worden uitgevoerd - ik heb daartoe al een beetje aan de volgorde in zrc-007 gesleuteld.

[hdksi]

@MNIJ en @ArjanKloosterboer Bovenstaand voorstel is geagendeerd voor de bijeenkomst van de technische gebruikersgroep aanstaande woensdag. Als het jullie lukt hierop voor die tijd nog een blik te werpen, graag!

[MNIJ]

@MNIJ en @ArjanKloosterboer Bovenstaand voorstel is geagendeerd voor de bijeenkomst van de technische gebruikersgroep aanstaande woensdag. Als het jullie lukt hierop voor die tijd nog een blik te werpen, graag!

Heb ik gedaan. Ben het met veel eens, maar heb nog wel vragen. Maar lijkt me beter om die eerst te bespreken in de gebruikersgroep i.p.v. ze nu te plaatsen.

[hdksi]

Opmerking per mail van @ArjanKloosterboer, die stelt dat:

"het lijkt mij dat dit bij [afleidingswijze vervaldatum besluit] 'gearchiveerd procestermijn onbekend' niet is toegestaan. Die vervaldatum besluit staat in een vastgesteld besluit dat is gerelateerd aan de zaak en is bij het afsluiten van de zaak bekend. Als het vervallen van een besluit afhankelijk is van een gebeurtenis in de toekomst, dan zou m.i. een daarbij passende andere afleidingswijze gekozen moeten worden."

Ik kan me voortellen dat dit inzicht klopt (en daar ben ik hieronder ook vanuit gegaan). Tegenwerpingen zijn uiteraard evengoed welkom.

Op verzoek van met name @MNIJ heb ik getracht duidelijk te maken in welke gevallen de Zaken API geautomatiseerd de archiefstatus en archiefactiedatum kan afleiden en registeren en hoe de Zaken API deze kenmerken in die gevallen berekent. Omdat hierbij relatief veel variabelen een rol spelen, én deze instructie begrijpelijk moet zijn voor ontwikkelaars, heb ik een poging gedaan een en ander in pseudocode te omschrijven. Graag een check op begrijpelijkheid door bijvoorbeeld @joerivrij.

ALS Resultaat.Resultaattype.brondatumArchiefprocedure.afleidingswijze = afgehandeld
    Zaak.archiefstatus = gearchiveerd 
    Zaak.archiefactiedatum = Zaak.einddatum + Resultaat.Resultaattype.archiefactietermijn

ANDERS ALS Resultaat.Resultaattype.brondatumArchiefprocedure.afleidingswijze = termijn
    Zaak.archiefstatus = gearchiveerd
    Zaak.archiefactiedatum = Zaak.einddatum + Resultaat.Resultaattype.brondatumArchiefprocedure.procestermijn + Resultaat.Resultaattype.archiefactietermijn

ANDERS ALS Resultaat.Resultaattype.brondatumArchiefprocedure.afleidingswijze = eigenschap
    Zaak.archiefstatus = gearchiveerd
    Zaak.archiefactiedatum = de waarde van de eigenschap waar de naam overeenkomt met Resultaat.Resultaattype.brondatumArchiefprocedure.datumkenmerk + Resultaat.Resultaattype.archiefactietermijn.

ANDERS ALS Resultaat.Resultaattype.brondatumArchiefprocedure.afleidingswijze = hoofdzaak
    EN ALS Hoofdzaak.einddatum ≠ null
        Zaak.archiefstatus = gearchiveerd
        Zaak.archiefactiedatum = Hoofdzaak.einddatum + Resultaat.Resultaattype.archiefactietermijn.
    ANDERS
        Zaak.archiefstatus = gearchiveerd_procestermijn_onbekend
        Zaak.archiefactiedatum = null

ANDERS ALS Resultaat.Resultaattype.brondatumArchiefprocedure.afleidingswijze = ingangsdatum_besluit
    EN ALS aantal besluiten bij de zaak = 1
        Zaak.archiefstatus = gearchiveerd
        Zaak.archiefactiedatum = Besluit.ingangsdatum + Resultaat.Resultaattype.archiefactietermijn
    ANDERS kunnen Zaak.archiefstatus en Zaak.archiefactiedatum niet door de Zaken API worden afgeleid en geregistreerd
        Valideer dat een geldige combinatie van archiefstatus en archiefactietermijn is vastgelegd

ANDERS ALS Resultaat.Resultaattype.brondatumArchiefprocedure.afleidingswijze = vervaldatum_besluit
    EN ALS aantal besluiten bij de zaak = 1
        Zaak.archiefstatus = gearchiveerd
        Zaak.archiefactiedatum = Besluit.vervaldatum + Resultaat.Resultaattype.archiefactietermijn
    ANDERS kunnen Zaak.archiefstatus en Zaak.archiefactiedatum niet door de Zaken API worden afgeleid en geregistreerd.
        Valideer dat een geldige combinatie van archiefstatus en archiefactietermijn is vastgelegd

ANDERS ALS Resultaat.Resultaattype.brondatumArchiefprocedure.afleidingswijze = gerelateerde_zaak
    EN ALS aantal gerelateerde zaken bij de zaak = 1
        EN ALS GerelateerdeZaak.einddatum ≠ null
            Zaak.archiefstatus = gearchiveerd
            Zaak.archiefactiedatum = Zaak.einddatum bij de gerelateerde zaak + Resultaat.Resultaattype.archiefactietermijn
        ANDERS
            Zaak.archiefstatus = gearchiveerd_procestermijn_onbekend
            Zaak.archiefactiedatum = null
    ANDERS kunnen Zaak.archiefstatus en Zaak.archiefactiedatum niet door de Zaken API worden worden afgeleid en geregistreerd
        Valideer dat een geldige combinatie van archiefstatus en archiefactietermijn is vastgelegd

ANDERS ALS Resultaat.Resultaattype.brondatumArchiefprocedure.afleidingswijze = zaakobject kunnen Zaak.archiefstatus en Zaak.archiefactiedatum niet door de Zaken API worden worden afgeleid en geregistreerd
    Valideer dat een geldige combinatie van archiefstatus en archiefactietermijn is vastgelegd

ANDERS ALS Resultaat.Resultaattype.brondatumArchiefprocedure.afleidingswijze = ander_datumkenmerk kunnen Zaak.archiefstatus en Zaak.archiefactiedatum niet door de Zaken API worden worden afgeleid en geregistreerd
    Valideer dat een geldige combinatie van archiefstatus en archiefactietermijn is vastgelegd

[MNIJ]

Opmerking per mail van @ArjanKloosterboer, die stelt dat:

"het lijkt mij dat dit bij [afleidingswijze vervaldatum besluit] 'gearchiveerd procestermijn onbekend' niet is toegestaan. Die vervaldatum besluit staat in een vastgesteld besluit dat is gerelateerd aan de zaak en is bij het afsluiten van de zaak bekend. Als het vervallen van een besluit afhankelijk is van een gebeurtenis in de toekomst, dan zou m.i. een daarbij passende andere afleidingswijze gekozen moeten worden."

Ik kan me voortellen dat dit inzicht klopt (en daar ben ik hieronder ook vanuit gegaan). Tegenwerpingen zijn uiteraard evengoed welkom.

Dit is volgens mij niet correct. In vergunningverlening is het een veelvoorkomend scenario dat de afleidingswijze vervaldatum_besluit is, maar dat die vervaldatum bij het sluiten van de zaak juist nog niet bekend is. Bijvoorbeeld een horecavergunning. Deze wordt in principe verstrekt voor onbepaalde tijd, maar kan wel op een gegeven moment in de tijd worden ingetrokken. Ofwel omdat het bedrijf ophoudt te bestaan ofwel doordat de gemeente de vergunning intrekt. Op dat moment krijgt het besluit een vervaldatum en vanaf dat moment moet de archieftermijn gaan lopen.

Sterker nog, dit scenario was de oorspronkelijke aanleiding voor mijn collega @hanspluimers om dit issue aan te maken.

Update ter aanvulling:
Een besluit heeft volgens de RGBZ drie mogelijke vervalredenen:

• Besluit met tijdelijke werking
• Besluit ingetrokken door overheid
• Besluit ingetrokken op verzoek van belanghebbende

Alleen bij de eerste van deze opties is de vervaldatum normaal gesproken bekend bij het sluiten van de zaak.

[hanspluimers]

Als aanvulling op de reactie van @MNIJ nog een aantal andere situaties waarbij de vervaldatum van het besluit wordt bepaald door een "gebeurtenis" die vooraf niet bepaald kan worden en niets te maken heeft met de levensloop van het zaakobject.

• Intrekken van een besluit door het bevoegd gezag (op verzoek of als handhavingsmaatregel;
• Het vervallen van een besluit omdat het besluit is vernietigd door een uitspraak op een ingediend bezwaar, beroep of hoger beroep;
• Het (van rechtswege) vervallen van een besluit omdat dat zo is geregeld in het kader van het overgangsrecht van een AMvB met algemene regels die de vergunningplicht voor de vergunde activiteit opheft.

Dus volgens mij voldoende reden om de redenering/conclusie van @ArjanKloosterboer iets aan te passen

[hdksi]

Helder, dank voor de toelichting. Dat genoemd uitgangspunt op gespannen voet staat met de aanleiding voor issue had ik ook al geconstateerd :) Graag had ik vermeden een nieuw vraagstuk dit issue in te trekken, maar hoe verhoudt zich een bij afsluiten van de zaak onbekende vervaldatum van een besluit tot Zrc-007, waarin wordt gesteld dat:

Als een Zaak een eindstatus heeft dan is de zaak afgesloten en mogen gegevens van de zaak niet meer aangepast worden (behalve om redenen van correctie). Dit MOET beveiligd worden met de scope zds.scopes.zaken.geforceerd-bijwerken. “Gegevens van de zaak” omvat hier ook de gerelateerde gegevens zoals klantcontacten, resultaat, rollen, statussen, zaakinformatieobjecten, zaakobjecten, zaakbesluiten en zaakeigenschappen.

Het toevoegen van een voorheen onbekende vervaldatum lijkt me geen correctie. Betekent dit dat deze gedragsregel op dit moment niet (altijd) wordt gevolgd en (ook) moet worden aangepast?

^Deze passage gaat over de resource zaakobject in Zaken API waarmee vanuit een zaak naar een besluit wordt verwezen (zaakbesluit bestaat niet). Besluiten zelf worden bij het afsluiten van de zaak niet expliciet mee-gearchiveerd en onmuteerbaar gemaakt. Volgens mij is dat óók onwenselijk, en zou je in ieder geval een aantal besluitkenmerken bij archiveren van de zaak willen 'vastzetten'.

[MNIJ]

Helder, dank voor de toelichting. Dat genoemd uitgangspunt op gespannen voet staat met de aanleiding voor issue had ik ook al geconstateerd :) Graag had ik vermeden een nieuw vraagstuk dit issue in te trekken, maar hoe verhoudt zich een bij afsluiten van de zaak onbekende vervaldatum van een besluit tot Zrc-007, waarin wordt gesteld dat:

Als een Zaak een eindstatus heeft dan is de zaak afgesloten en mogen gegevens van de zaak niet meer aangepast worden (behalve om redenen van correctie). Dit MOET beveiligd worden met de scope zds.scopes.zaken.geforceerd-bijwerken. “Gegevens van de zaak” omvat hier ook de gerelateerde gegevens zoals klantcontacten, resultaat, rollen, statussen, zaakinformatieobjecten, zaakobjecten, zaakbesluiten en zaakeigenschappen.

Het toevoegen van een voorheen onbekende vervaldatum lijkt me geen correctie. Betekent dit dat deze gedragsregel op dit moment niet (altijd) wordt gevolgd en (ook) moet worden aangepast?

Dat is inderdaad correct. Het is uiteraard te omzeilen via de scope zaken.geforceerd-bijwerken. Maar in eerdere systemen hadden we inderdaad business logica dat een besluit gerelateerd aan een gesloten zaak niet bewerkbaar is, met uitzondering van de velden vervalreden en vervaldatum (en aanvullend dat als één van deze velden gevuld is, de andere dat ook moet zijn).

Ik zou dit overigens geen onderdeel van dit issue maken, maar als een losstaand issue zien.

(ter info: ik ben intussen ook nog een uitgebreide reactie aan het schrijven op de uitwerking van de afleidingswijzen)

[hdksi]

Ik zou dit overigens geen onderdeel van dit issue maken, maar als een losstaand issue zien.

Ik was al bezig :). Zie #2130

[MNIJ]

Op verzoek van met name @MNIJ heb ik getracht duidelijk te maken in welke gevallen de Zaken API geautomatiseerd de archiefstatus en archiefactiedatum kan afleiden en registeren en hoe de Zaken API deze kenmerken in die gevallen berekent.

Bedankt voor deze uitwerking. Bij een aantal punten heb ik nog vragen / opmerkingen.

ANDERS ALS Resultaat.Resultaattype.brondatumArchiefprocedure.afleidingswijze = eigenschap
    Zaak.archiefstatus = gearchiveerd
    Zaak.archiefactiedatum = de waarde van de eigenschap waar de naam overeenkomt met Resultaat.Resultaattype.brondatumArchiefprocedure.datumkenmerk + Resultaat.Resultaattype.archiefactietermijn.

Mogelijk dit nog aanvullen met de conditie dat als deze eigenschap niet gevonden wordt of geen geen geldige datum als waarde heeft, de Zaken-API reageert met een foutbericht.

ANDERS ALS Resultaat.Resultaattype.brondatumArchiefprocedure.afleidingswijze = hoofdzaak
    EN ALS Hoofdzaak.einddatum ≠ null

Mogelijk dit nog aanvullen met ALS Zaak.hoofdzaak = null, (er is dus helemaal geen hoofdzaak) de Zaken-API reageert met een foutbericht, nu we het toch zo ver aan het dichttimmeren zijn.

ANDERS ALS Resultaat.Resultaattype.brondatumArchiefprocedure.afleidingswijze = ingangsdatum_besluit
    EN ALS aantal besluiten bij de zaak = 1
        Zaak.archiefstatus = gearchiveerd
        Zaak.archiefactiedatum = Besluit.ingangsdatum + Resultaat.Resultaattype.archiefactietermijn

De huidige werking in gedragsregel ZRC-021 is dat het besluit met de hoogste ingangsdatum wordt genomen. Dat voelt mogelijk enigszins fragiel, maar ik ken geen functioneel scenario waarin dat niet correct is (@hanspluimers, jij misschien wel?). Als tijdens de behandeling van de zaak meerdere besluiten (evt. van verschillend types) worden genomen, dan is het zo ver ik weet altijd zo dat het laatst genomen besluit het relevante besluit is voor de archieftermijn. Dat is dus anders dan bij de afleidingswijze gerelateerde_zaak, waar het niet evident is welke zaak relevant is voor de archieftermijn.

Verder dit mogelijk nog aanvullen met ALS aantal besluiten bij de zaak = 0 de Zaken-API reageert met een foutbericht.

ANDERS ALS Resultaat.Resultaattype.brondatumArchiefprocedure.afleidingswijze = vervaldatum_besluit

Zie ook de opmerkingen hierboven. De meest correct oplossing zou volgens mij zijn om hier aan te houden:
Als het gerelateerde besluit met de hoogste ingangsdatum een vervaldatum heeft, gebruik deze datum; Heeft dit besluit geen vervaldatum, zet dan Zaak.archiefstatus = gearchiveerd_procestermijn_onbekend. Is er helemaal geen besluit, dan reageert de Zaken-API met een foutbericht.

ANDERS ALS Resultaat.Resultaattype.brondatumArchiefprocedure.afleidingswijze = gerelateerde_zaak
   EN ALS aantal gerelateerde zaken bij de zaak = 1

Mogelijk nog aanvullen met ALS aantal gerelateerde zaken bij de zaak = 0 de Zaken-API reageert met een foutbericht.

ANDERS kunnen Zaak.archiefstatus en Zaak.archiefactiedatum niet door de Zaken API worden worden afgeleid en geregistreerd.
       Valideer dat een geldige combinatie van archiefstatus en archiefactietermijn is vastgelegd

Ik zou er toch voor willen pleiten om op alle plekken waar dit staat, in plaats daarvan de regel te maken dat de Zaken-API in die gevallen Zaak.archiefstatus = gearchiveerd_procestermijn_onbekend en Zaak.archiefactiedatum = null zet.
Het is dan de verantwoordelijkheid van de consumer-applicatie om te zorgen dat

• Deze situatie alleen voorkomt als het ook daadwerkelijk niet bepaald kan worden
• En/of de eindgebruiker te triggeren om dit op te lossen (dit kan de zaakbehandelaar zijn of een archiefspecialist)

Hoe dit werkt is dan aan de verschillende consumer-applicaties. De reden dat ik hiervoor pleit is dat het daarmee voor consumers een stuk voorspelbaarder wordt hoe de Zaken-API gaat reageren op het afsluiten van de zaak. Er zijn dan drie opties:

1. Er is echt iets fout in de data -> de Zaken-API reageert met een foutbericht; de zaak wordt niet gesloten.
2. De archiefactiedatum kan bepaald worden of is al vooraf gezet door de consumer -> de Zaken-API sluit de zaak en zet Zaak.archiefstatus = gearchiveerd en Zaak.archiefactiedatum = de berekende of al vooraf ingevulde datum
3. De archiefactiedatum kan niet worden bepaald -> de Zaken-API sluit de zaak en zet Zaak.archiefstatus = gearchiveerd_procestermijn_onbekend en Zaak.archiefactiedatum = null; er is nog actie nodig bij deze zaak, ofwel direct ofwel op een later moment.

In het voorstel zoals het er nu staat is er nog een soort onduidelijke vierde optie waarbij het niet duidelijk voor de consumer is waarom de Zaken-API met een foutbericht reageert en de zaak niet gesloten wordt. Is er echt iets fout? Of moet de consumer zelf nog de correcte waarde van archiefstatus zetten? (iets was in de overige scenario's door de Zaken-API gebeurt) Wat moet de consumer dan aan de eindgebruiker laten zien? Dat introduceert allemaal onnodige complexiteit.
Bovendien, waar zou "de geldige combinatie van archiefstatus en archiefactietermijn" vandaan moeten komen? De consumer kan de archiefstatus niet zetten voor de zaak daadwerkelijk gesloten is en het sluiten gebeurt door de Zaken-API.

[ArjanKloosterboer]

Dus volgens mij voldoende reden om de redenering/conclusie van @ArjanKloosterboer iets aan te passen

Ik ben het daarmee eens, alle reacties gelezen hebbende. Ik ging nog uit van inmiddels verouderde inzichten. In het RGBZ is BESLUIT nog onderdeel van het zakendomein en bestaat alleen bij de gratie van een zaak. Terecht is in de API's BESLUIT in een eigen API opgenomen, los van de ZKN-API. BESLUIT heeft daarmee een eigen bestaansrecht, los van wat dan ook. Het gedraagt zich op vergelijkbare wijze als een object in een objectregistratie. En kan dus ook gemuteerd worden nadat de zaak waarin het is ontstaan, afgesloten is (v.w.b. vervallen-gegevens). Mijn opmerking trek ik hierbij in.
Zou er wel voor pleiten om BESLUIT uit het RGBZ te halen en in een eigen informatiemodel op te nemen. Geldt overigens voor meer objecttypen in het RGBZ.

[ArjanKloosterboer]

Op verzoek van met name @MNIJ heb ik getracht duidelijk te maken in welke gevallen de Zaken API geautomatiseerd de archiefstatus en archiefactiedatum kan afleiden en registeren en hoe de Zaken API deze kenmerken in die gevallen berekent.

Mooie uitwerking. Geen andere opmerkingen dan die van MNIJ. Daarbij de volgende opmerkingen.

ANDERS ALS Resultaat.Resultaattype.brondatumArchiefprocedure.afleidingswijze = vervaldatum_besluit

De meest correct oplossing zou volgens mij zijn om hier aan te houden: Als het gerelateerde besluit met de hoogste ingangsdatum een vervaldatum heeft, gebruik deze datum; Heeft dit besluit geen vervaldatum, zet dan Zaak.archiefstatus = gearchiveerd_procestermijn_onbekend.

De redenering bij 'vervaldatum_besluit' moet nog aangepast worden op bovenstaande discussie. Of de door MNIJ voorgestelde oplossing wenselijk is, betwijfel ik. Is het besluit met de hoogste ingangsdatum inderdaad het besluit dat gaat vervallen? Kan het niet zo zijn dat bij een ander, meer relevant, besluit al een vervaldatum geregistreerd is? Het lijkt mij dat bij meer besluiten de gebruiker aan zet is.

ANDERS kunnen Zaak.archiefstatus en Zaak.archiefactiedatum niet door de Zaken API worden worden afgeleid en geregistreerd. Valideer dat een geldige combinatie van archiefstatus en archiefactietermijn is vastgelegd.

Ik zou er toch voor willen pleiten om op alle plekken waar dit staat, in plaats daarvan de regel te maken dat de Zaken-API in die gevallen Zaak.archiefstatus = gearchiveerd_procestermijn_onbekend en Zaak.archiefactiedatum = null zet.

Ik betwijfel of dit een wenselijke oplossing is. De transactie lijkt dan - voor de consumer(-software) - goed gegaan te zijn. Dat triggert niet om verdere actie. Terwijl dat in deze gevallen wel degelijk nodig is: de provider kan archiefstatus en -datum niet bepalen. Terwijl er wel geldige waarden geregistreerd moeten worden. M.i. zou gereageerd moeten worden met een specifieke foutcode zodat het de consumerapplicatie duidelijk is dat de gebruiker geldige waarden moet ingeven. Dat kan overigens nog steeds 'gearchiveerd procestermijn onbekend' en geen datum zijn.

[MNIJ]

Op verzoek van met name @MNIJ heb ik getracht duidelijk te maken in welke gevallen de Zaken API geautomatiseerd de archiefstatus en archiefactiedatum kan afleiden en registeren en hoe de Zaken API deze kenmerken in die gevallen berekent.

Mooie uitwerking. Geen andere opmerkingen dan die van MNIJ. Daarbij de volgende opmerkingen.

ANDERS ALS Resultaat.Resultaattype.brondatumArchiefprocedure.afleidingswijze = vervaldatum_besluit

De meest correct oplossing zou volgens mij zijn om hier aan te houden: Als het gerelateerde besluit met de hoogste ingangsdatum een vervaldatum heeft, gebruik deze datum; Heeft dit besluit geen vervaldatum, zet dan Zaak.archiefstatus = gearchiveerd_procestermijn_onbekend.

De redenering bij 'vervaldatum_besluit' moet nog aangepast worden op bovenstaande discussie. Of de door MNIJ voorgestelde oplossing wenselijk is, betwijfel ik. Is het besluit met de hoogste ingangsdatum inderdaad het besluit dat gaat vervallen? Kan het niet zo zijn dat bij een ander, meer relevant, besluit al een vervaldatum geregistreerd is? Het lijkt mij dat bij meer besluiten de gebruiker aan zet is.

Ik ben het er mee eens dat mijn voorstel voor vervaldatum_besluit discutabel is. Mijns inziens zal dit in 99% van de gevallen correct zijn, maar ik weet dit niet helemaal zeker en het is zeker niet 100% robuust.

ANDERS kunnen Zaak.archiefstatus en Zaak.archiefactiedatum niet door de Zaken API worden worden afgeleid en geregistreerd. Valideer dat een geldige combinatie van archiefstatus en archiefactietermijn is vastgelegd.

Ik zou er toch voor willen pleiten om op alle plekken waar dit staat, in plaats daarvan de regel te maken dat de Zaken-API in die gevallen Zaak.archiefstatus = gearchiveerd_procestermijn_onbekend en Zaak.archiefactiedatum = null zet.

Ik betwijfel of dit een wenselijke oplossing is. De transactie lijkt dan - voor de consumer(-software) - goed gegaan te zijn. Dat triggert niet om verdere actie. Terwijl dat in deze gevallen wel degelijk nodig is: de provider kan archiefstatus en -datum niet bepalen. Terwijl er wel geldige waarden geregistreerd moeten worden. M.i. zou gereageerd moeten worden met een specifieke foutcode zodat het de consumerapplicatie duidelijk is dat de gebruiker geldige waarden moet ingeven. Dat kan overigens nog steeds 'gearchiveerd procestermijn onbekend' en geen datum zijn.

Ik ben het hier functioneel gezien helemaal mee eens. Maar ik vind dit de verantwoordelijkheid van de consumer-applicatie (in samenwerking met de eindgebruiker). Uiteindelijk geeft de consumer-applicatie aan de Zaken-API de opdracht om de zaak te sluiten. Naar mijn mening mag de Zaken-API dat alleen weigeren als de Zaken-API met zekerheid kan bepalen dat de data niet geschikt is om de opdracht uit te voeren.

[Hugo-ter-Doest]

Volgens mij is de kern van het probleem dat een zaak niet kan worden afgesloten als de archiefactiedatum niet kan worden bepaald. Daar hebben we bij Dimpact last van bij de ontwikkeling van de zaakafhandelcomponent die onderdeel is van ons nieuwe product PodiumD. Ik kan me goed vinden in de oplossing die @MNIJ geeft:

De meest simpele aanpassing om het probleem te verhelpen zou zijn:

1. Consumer zet de laatste status bij de zaak
2. ZRC bepaalt confrom ZRC-021 wat zaak.archiefactiedatum moet worden
3. Lukt dit niet omdat gegevens ontbreken -> ZRC zet zaak.archiefstatus = "gearchiveerd_procestermijn_onbekend" en zaak.archiefnominatie = waarde op basis van zaak.resultaat, zaak.archiefactiedatum blijft leeg.
4. Lukt dit wel -> ZRC zet zaak.archiefstatus = "gearchiveerd", zaak.archiefnominatie = waarde op basis van zaak.resultaat en zaak.archiefactiedatum = waarde op basis van zaak.resultaat.
   Dit vereist aanpassingen aan ZRC-021 en ZRC-022.

Voor zaken die hierdoor zaak.archiefstatus = "gearchiveerd_procestermijn_onbekend" krijgen, zal er op een gegeven moment nabewerking nodig zijn en daarvoor is de scope zaken.geforceerd-bijwerken nodig. Maar dat zal in elke oplossing zo zijn en dat is ook precies waar archiveringssoftware voor bedoelt is, dus een archiveringsmodule zal altijd deze scope nodig hebben, dat zie ik niet als een nadeel.

Ik zie dat dit issue zal worden meegenomen met milestone Zaken API 1.4.

@michielverhoef kun jij aangeven hoe en wanneer dit issue in de standaard kan worden aangepast?