Als archiefbeheerder wil ik periodiek de business aansporen om nog niet ingevulde vervaldata van besluiten alsnog in te vullen

[MarcoKlerks]

...zodat deze vervaldata gebruikt kunnen worden in het berekenen van vernietigingsdata (zie deze opmerking bij #345 ).

Op het moment dat een besluit wordt genomen, is nog niet altijd duidelijk tot wanneer het besluit van kracht zal zijn. Zo worden bijvoorbeeld vergunningen en ontheffingen vaak stilzwijgend met een jaar verlengd, zolang aan bepaalde voorwaarden voldaan wordt. Regelgeving en beleid blijft van kracht totdat er nieuwe regelgeving dan wel beleid wordt vastgesteld. Het besluit wordt dan geregistreerd zonder vervaldatum en da zaak wordt afgehandeld.

Als archiefbeheerder heb ik de vervaldatum echter vaak wel nodig om te kunnen bepalen tot welke datum het zaakdossier bewaard moet worden.

Ik wil daarom periodiek (jaarlijks?) aan de business vragen om de nog openstaande besluiten te controleren en waar dat al bekend is, de vervaldatum in te vullen. Idealiter hoef ik dit niet zelf te vragen, maar gebeurt dit automatisch.

Wanneer de vervaldatum wordt ingevuld, wordt autormatisch de vernietigingsdatum berekend.

Ik laat in deze user story in het midden wie "de business" is. Is dat de behandelaar? Is dat de proces-eigenaar? Of is het iemand anders?

Definition of ready

• [ ] Iedereen in het team begrijpt de user story
• [ ] de gewenste (aanvulling op de) functionaliteit van de API's duidelijk en beschreven is.
• [ ] Is klein genoeg (maximaal 1/5 van sprint)
• [x] Product Owner akkoord en voorzien van prioriteit (mag alleen afgevinkt worden door Eelco)
• [ ] Voorzien van acceptatiecriteria (duidelijk en testbaar)
• [ ] Voorzien van Definition of Done (duidelijk en testbaar)
• [ ] Voorzien van taken
• [ ] Idee hebben van hoe deze user story kan worden gedemonstreerd.
• [ ] Userstory is ingevuld op template architectuurschets
• [ ] Userstory is voorzien van veldmapping naar RGBZ2 (mag alleen afgevinkt worden door Arjan)
• [ ] Userstory past op wenselijk gebruik ZGW volgens GEMMA 2 (mag alleen afgevinkt worden door Jeffrey)
• [ ] Vastgelegd in Github en geplaatst in kolom ready

Definition of done

• [ ] er is een OAS 3.0 specificatie
• [ ] de functionele specificatie is gepubliceerd leesbaar
• [ ] de technische specificatie is gepubliceerd leesbaar
• [ ] er is een referentieimplementatie
• [ ] de DSO URI- en API-strategie worden gevolgd of afwijkingen zijn vastgelegd als ontwerp keuze
• [ ] eventueel gemaakte ontwerp keuzes zijn gedocumenteerd
• [ ] er zijn geen (nieuwe) conflicten met ontwerp keuzes in BIP
• [ ] review heeft plaatsgevonden (dus reviewers hebben voldoende en vindbare info om te kunnen reviewen (dus duidelijke verwijzing in issue/user story naar deze documentatie)
• [ ] wijzigigen als gevolg van user story zijn vindbaar en gedocumenteerd
• [ ] functionele documentatie is gereviewd door developers (lees is techniek in overeenstemming met functionele documentatie)

Acceptatiecriteria Uit de algemene uitgangspunten:

• [ ] Voldoet aan RGBZ 2.0
• [ ] Voldoet aan GEMMA 2.0

Taken

• [ ] Opstellen welke velden bij een melding horen [verantwoordelijke]
• [ ] Aanleveren testdata [verantwoordelijke]
• [ ] Schrijven (unit) test voor referentie-implementatie [verantwoordelijke]
• [ ] Implementeren in referentie-implementatie [verantwoordelijke]
• [ ] Genereren/opstellen van OAS 3.0 [verantwoordelijke]
• [ ] Functionele documentatie [verantwoordelijke]
• [ ] Human Readable publiceren Open API Specificatie (v.3.0) [verantwoordelijke]

[TCIMEddy]

@ehotting graag visie en prio

[ehotting]

Nuttige functionaliteit, maar wel typisch uit te voeren door client software. In dit geval, beheersoftware. In Haarlem is dit geautomatiseerd met een BPMN proces die frequent alles naloopt, daarbij nu gebruik makend van services en straks van de nieuwe ZDS 2.0 API. Dit type business logica hoort in een client, daarom is de gevraagde functionaliteit out-of-scope.

Wat hieruit wel kan worden afgeleid zijn consequenties voor de API: stel dat we deze functionaliteit willen bouwen, hebben we dan alle benodigde info in de API beschikbaar, en kunnen we die data achteraf zetten?

RGBZ mapping nodig om dat te kunnen beoordelen.

@BoerBas kan jij hierop aanvullen vanuit ervaring Haarlem?

[BoerBas]

Wat Eelco zegt klopt. De archiefactiedatum kan niet altijs direct na de procestermijn worden gezet. Soms zijn daar afhankelijkheden. Onze conclusie was dus dat de proces(applicatie) niet de archiefactiedatum zet, dit is een apart proces wat geautomatiseerd dit controleerd en zet waar dit kan.

Dit BPMn proces hebben wij ontwikkeld als onderdeel van de automatisering van archiefbeheertaken. Hieronder meer:

https://haarlem.github.io/bpmn-processen/InvoerenArchiefactiedatum/README.html

[Hugo-ter-Doest]

Om dit mogelijk te maken moet je besluiten kunnen uitfilteren die zijn gekoppeld aan een zaak EN die een lege vervaldatum hebben.