¶ Behandelproces - Status en resultaat
De basis van het behandelproces in het zaaksysteem vormen de bij het zaaktype geconfigureerde statussen en resultaten, inclusief alle daarbij vastgelegde attributen, checklistvragen en aanvullende voorwaarden (zoals verplichte kenmerken en documenten). Zie ook het hoofdstuk checklist.
We gaan in dit hoofdstuk uit van een behandelproces dat is opgebouwd uit 4 statussen en 2 resultaten. De workflow wordt op een dusdanige wijze opgebouwd, dat dit aantal mag afwijken. Wel schrijft het model voor dat er per zaaktype een minimum van 2 statussen is vastgelegd. Dit is een logische en redelijke voorwaarde, aangezien een zaak (ongeacht het zaaktype) altijd een duidelijk begin- en eindpunt kent. Daarnaast dient er minimaal 1 resultaat per zaaktype te worden vastgelegd. Aan het aantal statussen en resultaten zijn verder geen limieten of beperkingen verbonden. Wanneer we in dit hoofdstuk spreken van een status, hebben we het in feite over het eindresultaat: een bereikte status is het resultaat van voorliggende acties. We zullen het dan ook regelmatig hebben over de fase die kan resulteren in het bereiken van de daaraan gekoppelde status.
Om dit hoofdstuk leesbaar te houden, gaan we uit van de volgende 4 statussen en 2 resultaten:
| Status | Resultaat |
|---|---|
| 1. Ontvangen | Verleend |
| 2. Geaccepteerd | Geweigerd |
| 3. In behandeling genomen | Geweigerd |
| 4. Afgehandeld | Geweigerd |
¶ Status (1) “Ontvangen”
De eerste status wordt bereikt bij het succesvol vastleggen van de zaak. Dit kan op verschillende wijzen. Zaken die extern worden geïnitieerd (aanvragen, indienen, aangeven, …) ontstaan doordat een brief of webformulier worden ontvangen, terwijl intern geïnitieerde zaken ontstaan doordat iemand het “dossier” (of de zaak) aanmaakt.
Zodra de zaak succesvol is vastgelegd (aan alle voorwaarden/validaties is voldaan) wordt automatisch het behandelproces gestart. Of, in JOIN-termen, wordt de workflow gestart. De behandeling van de zaak kan worden uitgesteld door de startdatum in de toekomst te plaatsen. Dit wordt door een wachtschakel geregeld die luistert naar de startdatum van de zaak.
De eerste handeling is het bereiken van de eerste status. Vanuit de workflow wordt de status van de zaak “opgehoogd” naar “ontvangen”. Vervolgens kan een statusbericht worden verzonden aan de initiator van de zaak. Dit statusbericht informeert de initiator over de status die is bereikt. Dit statusbericht is afhankelijk van de volgende 2 condities:
- Bij het zaaktype is vastgelegd dat de initiator dient te worden geïnformeerd (status.informeer initiator!: ja);
- Bij de zaak is een e-mailadres van de initiator vastgelegd.
Zowel het ophogen van de status als het (eventueel) verzenden van een statusbericht (per e-mail) wordt in de workflow geconfigureerd in een computeractie. Elders in dit document is deze computeractie nader gespecificeerd.
¶ Status (2) “Geaccepteerd”
In dit voorbeeld gaan we uit van 4 statussen die bij het zaaktype zijn geconfigureerd. Wanneer er slechts 2 statussen zijn geconfigureerd bij het zaaktype, dan is dit hoofdstuk niet van toepassing. In dat geval wordt na het bereiken van status 1 de laatste fase van het zaaktype gestart (die uiteindelijk resulteert in het ophogen naar de laatste status “afgehandeld”). Zijn er minimaal 3 statussen geconfigureerd, dan is dit hoofdstuk wel relevant.
¶ Checklist bij status 2
Wanneer in de tweede status een checklist, die de behandelaar van de zaak begeleidt bij het bereiken van het proces, is geconfigureerd, wordt een checklist gestart. Deze checklist kan bestaan uit (handmatige) checklistvragen (optionele en verplichte vragen) en automatische controles op de verplichtte aanwezigheid van zaakkenmerken en documenten). Zie hiervoor ook het hoofdstuk “checklist”.
Deze checklist wordt toegewezen aan de behandelende rol die bij de status (JOIN Zaaktypen) is vastgelegd. Deze behandelende rol is gekoppeld aan de gebruikersrol in het zaaksysteem. In de workflow is geconfigureerd dat de checklist “direct” wordt toegewezen aan de gebruikersrol. Dit betekent dat de gebruikersrol zichtbaar wordt in de werkvoorraad van de leden van de rol (de behandelaren). Checklistacties mogen vanuit deze centrale werkvoorraad worden heen- en weer gestuurd naar de leden van deze rol. Wanneer bij de tweede status geen behandelende rol is geconfigureerd, dan wordt de toewijzing verplaatst naar de zaakregistratie. Hier dient de registrator verplicht een gebruikersrol te selecteren in het veld “zaak toewijzen aan”.
Een checklist kent altijd standaard 2 uitkomsten: goed (accepted) en fout (rejected). Een checklist krijgt de uitkomst “accepted” wanneer minimaal alle verplichte checks (handmatig en automatisch) zijn aangevinkt.
Toewijzing “direct” aan de gebruikersrol
Een checklist krijgt de uitkomst “goed” wanneer minimaal alle verplichte checks (te herkennen aan de *) zijn aangevinkt.
Een “accepted” checklist leidt automatisch naar het bereiken van de status. Net als bij status 1 kan het ophogen van de status (naar “geaccepteerd”) worden opgevolgd door het (optioneel) versturen van het statusbericht naar de initiator van de zaak. Ook hier gelden dezelfde voorwaarden en wordt wederom gebruik gemaakt van een workflow computeractie.
Bij een “rejected” checklist (waarbij niet aan alle voorwaarden kan worden voldaan en de checklistactie voortijdig wordt afgehandeld) wordt de status (nog) niet bereikt. Dit kan verschillende oorzaken hebben. Om deze reden wordt aan de behandelaar van de checklist (die heeft besloten de onvolledige checklist af te handelen) een vraag (wat wilt u doen met de zaak?) voorgelegd met de volgende (2) mogelijke uitkomsten:
| Keuze | Leidt tot |
|---|---|
| De zaak vervolgen | Ondanks dat de checklist onvolledig is afgehandeld, kiest de behandelaar ervoor om de behandeling van de zaak te vervolgen. De status wordt alsnog opgehoogd (bereikt) en het (eventuele) statusbericht wordt verzonden. |
| De checklist opnieuw uitvoeren | De checklist wordt opnieuw gestart en kan nogmaals in behandeling worden genomen |
Gevraagde beslissing na de uitkomst “fout” van het afhandelen van de checklist
¶ Geen checklist bij status 2
Het is mogelijk dat er bij status 2 (en volgende) geen checklist is geconfigureerd in JOIN Zaaktypen. In dat geval wordt de checklist vervangen door een reguliere behandelschakel. De toewijzing van deze actie (workflow: behandeling) is gelijk aan de toewijzing van de checklist. De actiecode is gelijk aan die van de checklist.
¶ Status (3) “in behandeling genomen”
In ons voorbeeld zijn we uitgegaan van 4 statussen. In de praktijk kan dit aantal nogal eens afwijken. Wanneer er tussen de 2e en laatste status 1 of meerdere statussen zijn geconfigureerd, dan is de behandeling van deze statusacties gelijk aan die van de tweede status. Zijn er slechts 3 statussen geconfigureerd, dan is dit hoofdstuk niet relevant: de zaak belandt in de laatste fase. Deze fase (waarin de laatste status “afgehandeld” kan worden bereikt) kenmerkt zich door een afwijkende workflowconfiguratie.
De enige uitzondering in deze fase (dus de status(sen) die is (zijn) geconfigureerd tussen de 2e en de laatste status is het toewijzen van de actie (checklist of beslissing):
- Wanneer er bij de statusconfiguratie (JOIN Zaaktypen) bij status 3 geen behandelende rol is geselecteerd, dan wordt de actie (checklist of beslissing) toegewezen aan de “behandelaar van de vorige actie”.
- Wanneer er bij de statusconfiguratie wel een behandelende rol is gekozen, dan wordt de actie toegewezen aan deze rol (in het zaaksysteem is dit een gebruikersrol). Net als in status 2 “geaccepteerd” wordt de actie “direct” aan de rol toegekend.
¶ Laatste status (4) “afgehandeld”
De laatste status is in zijn configuratie duidelijk afwijkend van de voorgaande statussen. Dat is ook niet verwonderlijk:
- In de laatste fase dienen nog allerlei werkzaamheden te worden uitgevoerd (de daadwerkelijke behandeling van de zaak)
- De laatste status kan pas worden bereikt wanneer de uitkomst is geselecteerd (het resultaat is gekozen, eventuele besluiten zijn genomen)
- De laatste status kan (in veel gevallen) pas worden bereikt wanneer de uitkomst (het resultaat) is behandeld. Denk hierbij aan het opstellen van een besluit, het ondertekenen van documenten en de toetsing hiervan. Dit kan door middel van een checklist.
- De zaak is pas definitief afgehandeld zodra een eventuele verweertermijn (of bezwaarperiode) is verstreken. Binnen de AWB is het immers mogelijk dat verweer tegen een genomen besluit mogelijk is gedurende een vooraf (wettelijk) vastgestelde termijn.
In dit laatste (status) hoofdstuk worden alle handelingen beschreven die uiteindelijk moeten resulteren in het bereiken van deze laatste status “afgehandeld” en het sluiten van het zaakdossier.
¶ Checklist bij laatste status
Wanneer in de laatste status een checklist is geconfigureerd, wordt een checklist gestart. Deze checklist kan, net als bij de eerdere statussen, bestaan uit (handmatige) checklistvragen (optionele en verplichte vragen) en automatische controles op de verplichtte aanwezigheid van zaakkenmerken en documenten).
De toewijzing van de checklist is gelijk aan die van de voorgaande (3e) status:
- Wanneer er bij de statusconfiguratie (JOIN Zaaktypen) geen behandelende rol is geselecteerd, dan wordt de actie (checklist of beslissing) toegewezen aan de “behandelaar van de vorige actie”. Dit geldt ook wanneer bij status 2 geen behandelende rol is geselecteerd en deze pas in de registratiefase wordt toegekend aan de zaak.
- Wanneer er bij de statusconfiguratie wel een behandelende rol is gekozen, dan wordt de actie toegewezen aan deze rol (in het zaaksysteem is dit een gebruikersrol). Net als in status 2 “geaccepteerd” wordt de actie “direct” aan de rol toegekend.
Een “accepted” checklist leidt automatisch naar een beslissing waar de uitkomst van de zaak (het resultaat) kan worden gekozen. Deze resultaatkeuze wordt verderop nader toegelicht.
Bij een “rejected” checklist (waarbij niet aan alle voorwaarden kan worden voldaan en de checklistactie voortijdig wordt afgehandeld) wordt de resultaatvraag (nog) niet bereikt. Dit kan verschillende oorzaken hebben. Om deze reden wordt aan de behandelaar van de checklist (die heeft besloten de onvolledige checklist af te handelen) een vraag (wat wilt u doen met de zaak?) voorgelegd met de volgende (3) mogelijke uitkomsten:
| Keuze | Leidt tot |
|---|---|
| De zaak vervolgen | Ondanks dat de checklist onvolledig is afgehandeld, kiest de behandelaar ervoor om de behandeling van de zaak te vervolgen. De status wordt alsnog opgehoogd (bereikt) en het (eventuele) statusbericht wordt verzonden. |
| De zaak annuleren | De behandeling van de zaak wordt stopgezet. De zaak wordt doorgezet naar een annuleringsactie, die wordt toegewezen aan de behandelaar van de zaak. Deze bepaalt verder wat er met de zaak moet gebeuren. |
| De checklist opnieuw uitvoeren | De checklist wordt opnieuw gestart en kan nogmaals in behandeling worden genomen. |
¶ Geen checklist bij laatste status?
In de meeste gevallen zal een checklist worden geconfigureerd voor de laatste status. Dit hoeft uiteraard niet. In dit geval wordt, net als de voorgaande statussen, een reguliere behandelactie gestart[1]. Bij het afhandelen van deze actie wordt de laatste fase gestart met de resultaatkeuze (waarna het resultaat kan worden afgehandeld). Deze resultaatkeuze wordt wel toegekend aan de behandelende rol die bij status 4 is geconfigureerd of aan de behandelaar van de vorige actie (als deze niet is ingevuld bij status 4).
Er is 1 uitzondering: wanneer het zaaktype slechts 1 resultaat heeft en er bij het resultaat geen checklist is geconfigureerd, wordt alsnog een reguliere behandelactie toegevoegd voor de laatste status.
¶ Resultaatkeuze
Binnen de laatste fase dient allereerst (na het eventueel volledig afronden van een checklist) een uitkomst te worden geselecteerd. De mogelijke uitkomsten is gelijk aan het bij het zaaktype geconfigureerde resultaten. In ons voorbeeld zijn we uitgegaan van 2 resultaten: verleend en geweigerd. Is er “slechts” 1 resultaat geconfigureerd bij het zaaktype (“verwerkt”) dan is er geen handmatige beslissing.
De beslissing (?) waarin bovenstaande keuze wordt genomen wordt toegewezen aan de “behandelaar van de vorige actie”. Dit kan ofwel de behandelaar zijn die de checklist heeft afgehandeld binnen de laatste fase of de behandelaar die de vorige status heeft bereikt.
¶ Checklist bij resultaat
Wanneer er een checklist is geconfigureerd bij het resultaat (JOIN Zaaktypen), dan krijgt de behandelaar (die ook het resultaat heeft gekozen) een checklistactie toegewezen die hij/zij allereerst volledig moet afronden voordat het resultaat definitief is. Wanneer de checklist desondanks onvolledig wordt afgerond, dan keert de behandelaar terug bij de resultaatkeuze. Het resultaat kan dan opnieuw worden geselecteerd. Deze cyclus zal zich blijven herhalen zolang het gekozen resultaat niet volledig wordt afgehandeld. Wanneer er maar 1 resultaat is geconfigureerd bij het zaaktype, zal er niet worden teruggekeerd bij de resultaatkeuze (want die bestaat niet), maar bij een handmatige beslissing waar gekozen kan worden voor het “annuleren” van de zaak of het “opnieuw uitvoeren van de checklist”.
Wanneer er geen checklist is geconfigureerd bij het gekozen resultaat, dan hoeft de behandelaar geen actie af te handelen om het resultaat definitief te maken. De zaak wordt dan direct afgehandeld.
Het resultaat wordt bijgewerkt in de zaakregistratie, alsmede de archiefnominatie (bewaren, vernietigen of overbrengen) en de bewaartermijn die is gekoppeld aan de archiefnominatie (bijvoorbeeld 7 jaar). Ten slotte worden de bij het resultaat vastgelegde besluiten vastgelegd in de zaak.
¶ Afhandelen zaak
Zodra in bovenstaande situatie het gekozen resultaat is afgehandeld (wel of geen checklist), dan wordt allereerst de behandeltermijn gestopt en een einddatum bij de zaak ingevuld. Ook wordt de status bijgewerkt met de laatste status “afgehandeld”. De zaak (gegevens, relaties en documenten) wordt vervolgens door de RMA-functie van het zaaksysteem bevroren (niet meer wijzigbaar). De startdatum van de archiefprocedure (de datum waarop de bewaartermijn van het zaakdossier ingaat) wordt vervolgens vastgelegd in de zaak. Hier zijn verschillende mogelijkheden:
- De afhandeldatum van de zaak bepaalt de ingangsdatum van de bewaartermijn;
- Een bij de zaak vastgelegd datumkenmerk bepaalt de ingangsdatum (bijvoorbeeld de laatste dag van het evenement waar een evenementenvergunning voor is aangevraagd);
- Overig: de datum wordt handmatig ingevoerd door een (archief)medewerker.
De zaak is pas definitief afgehandeld zodra een eventuele bezwaarperiode is afgewacht. Wanneer er een besluit is vastgelegd bij het geselecteerde resultaat met een reactietermijn (die groter is dan 0), dan wordt de zaak gedurende deze termijn in de “wachtstand” gezet. Pas nadat deze termijn is verstreken, is de zaak “definitief” en wordt de workflow afgehandeld. Wanneer bij een resultaat meerdere besluiten zijn vastgelegd, dan wordt de kortste reactietermijn gebruikt.
¶ Controleren van de zaak na afhandelen
Normaliter wordt na afhandelen van de zaak het eindpunt van het proces (workflow) bereikt. Vanaf versie 6.0.7 is het echter mogelijk om daar nog een controlestap aan toe te voegen (bijvoorbeeld de archivaris die graag het dossier wil toetsen op archiefwaardigheid)
Wanneer bij het resultaat van het zaaktype een gebruikersrol is ingevuld bij de eigenschap “controleer zaak” wordt helemaal aan het eind van het proces een extra stap toegevoegd (controleren zaak) die wordt toegekend aan deze rol (behandelgroep).
¶ Vervolgzaken
Wanneer bij een resultaat een vervolgzaaktype is geconfigureerd (in JOIN Zaaktypen), dan wordt bij het bereiken van het resultaat een vervolgzaak aangemaakt en gekoppeld aan de hoofdzaak. De vervolgzaak start gelijk, over een bepaald aantal dagen of op een vaste datum in de toekomst. Dit allemaal afhankelijk van de instellingen in JOIN Zaaktypen.
¶ Navigatie
- Zakenmagazijn
- Zaken per Zaaktype
- Tabellen
- Zaakdocumenten
- Behandelproces - onderdelen
- Behandelproces - status en resultaat
- Bijlage: relatie JOIN Zaaktypen met JOIN
Dit gedrag is gewijzigd sinds versie 6.0.11 met actie #8813. Reden hiervoor is om het consistent te maken met de voorgaande statussen ↩︎