Het zetten van eindstatus van de zaak met datum geeft vreemd gedrag

[MNIJ]

Reproductiescenario:

1. Gegeven: Een zaak van een zaaktype met minimaal 2 statustypes, bijvoorbeeld Zaak in behandeling en Zaak afgerond, waarbij Zaak afgerond de status met het hoogste volgnummer is en daarmee de eindstatus van de zaak
2. Voeg een status aan de zaak de zaak met status.type = Zaak in behandeling en status.datumStatusGezet = 10 april
3. Voeg daarna een status aan de zaak de zaak toe met status.type = Zaak afgerond en status.datumStatusGezet = 1 april

Gevolg: de zaak krijgt einddatum 1 april en wordt in alle opzichten behandeld als een gesloten zaak. Maar de status van de zaak wordt teruggegeven als Zaak in behandeling en niet als Zaak afgerond.

Het lijkt duidelijk dat dit gedrag in ieder geval niet correct is, maar alle ZRC implementaties die ik getest heb gedragen zich zo (inclusief Open Zaak en de referentie-implementatie). Er zijn wel meerdere oplossingsrichtingen mogelijk om dit op te lossen, waarbij de keuze afhankelijk is van de scenario's die ondersteund moeten worden in de ZRC.

Oplossingsrichting 1: statussen moeten op volgorde in tijd gezet worden

Sta niet toe dat er een status aan een zaak wordt toegevoegd met een datumStatusGezet kleiner of gelijk aan de hoogste waarde van datumStatusGezet van de statussen die al bij de zaak bestaan. Daarmee kan er geen status "geïnjecteerd" worden in de tijdlijn van de zaak en kan bovenstaande probleem niet optreden.

Dit lijkt een relatief simpele en doeltreffende oplossing, maar daarmee wordt het onmogelijk om het volgende te doen:

1. Handel een zaak normaal af, hierbij krijgt de zaak een opeenvolging van statussen, afsluitend met de eindstatus. De zaak is nu gesloten.
2. Heropen de zaak op een later moment. Hierbij moet de zaak een status krijgen anders dan de eindstatus
3. Sluit de zaak opnieuw, maar herstel hierbij de oorspronkelijke einddatum.

De beschreven oplossingsrichting zou stap 3 onmogelijk maken. Er is ook geen andere manier om de einddatum van een zaak te zetten of aan te passen. Dit is wel een noodzakelijke functionaliteit.

Oplossingsrichting 2: de laatst gezette status is de status van de zaak, ongeacht de waarde van datumStatusGezet

Als de actuele status van de zaak niet wordt bepaald op basis van datumStatusGezet, maar op basis van welke status als laatste is toegevoegd, dan kan het probleem ook niet meer optreden en is het scenario voor het heropenen en daarna opnieuw sluiten met de oorspronkelijk datum WEL mogelijk. Het maakt wel de betekenis van het veld datumStatusGezet enigszins ambigue.

Oplossingsrichting 3: maak het mogelijk om een andere einddatum te zetten dan datumStatusGezet

Gelijk aan oplossingsrichting 1, maar maak het mogelijk om bij het zetten van de eindstatus van de zaak, de einddatum van de zaak te bepalen anders dan via datumStatusGezet van de status. Bijvoorbeeld door het toevoegen van een extra optioneel veld bij het zetten van een status datumStatusVanKracht. Als dit niet gevuld wordt, is het automatisch gelijk aan datumStatusGezet en bepaalt dat dus de einddatum. Als het wel gezet wordt, is datumStatusVanKracht bepalend voor de einddatum van de zaak.

[michielverhoef]

@ArjanKloosterboer Kun jij hier ook naar kijken?

[michielverhoef]

Een aantal reacties uit de losse heup van mijn kant:

• De status met het hoogste volgnummer is niet automatisch de eindstatus. Hiervoor bestaat het attribuut isEindstatus .

Als ik het zo zie klopt de validatie bij het zetten van een status niet. Het zou niet mogelijk moeten zijn om op een latere datum een status te zetten die een eerdere datumStatusGezet krijgt (zoals in het voorbeeld). Dat is eigenlijk wat je in oplossing 1 beschrijft. Het heropenen van een zaak is eigenlijk een geforceerde actie, ook al zal dat misshcien best eens voorkomen.

In dat geval zou de reeds bestaande scope geforceerd-bijwerken gebruikt kunnen worden om een zaak die reeds een eindstatus heeft bereikt te voorzien van een nieuwe, eerdere status. Bij het heropenen van een zaak zou de Zaak.eindDatum ook leeg gemaakt moeten worden, de zaak is immers niet meer gesloten. Dit leegmaken van Zaak.eindDatum zou ook kunnen met dezelfde scope geforceerd-bijwerken.

In Zaken API 1.3 is het attribuut indicatieLaatstGezetteSatus toegevoegd. Dat is dit attribuut in RGBZ 2 https://www.gemmaonline.nl/index.php/Rgbz_2.0/doc/attribuutsoort/status.indicatie_laatst_gezette_status

https://zaken-api.test.vng.cloud/api/v1/schema/#operation/status_read

Door dit attribuut te gebruiken wordt volgens mij een groot deel van het probleem opgelost, zeker wanneer ook nog de scope geforceerd-bijwerken toegevoegd wordt zodat een zaak heropend kan worden en deze een andere dan de vastgelegde eindstatus kan krijgen.

Is oplossingsrichting 3 dan nog nodig? Volgens mij niet omdat je nu kunt bepalen of een eindstatus ook daadwerkelijk de laatst gezette status is. Is dit niet zo dan is de zaak nog niet afgehandeld en wordt de einddatum van de zaak niet gezet.

[MNIJ]

De status met het hoogste volgnummer is niet automatisch de eindstatus. Hiervoor bestaat het attribuut isEindstatus .

Dat komt op hetzelfde neer, bij het aanmaken van statustypen kan je het veld isEindstatus niet zetten, dit wordt automatisch bepaald op basis van volgnummer. De beschrijving van het veld isEindstatus is dan ook "Geeft aan dat dit STATUSTYPE een eindstatus betreft. Dit gegeven is afgeleid uit alle STATUSTYPEn van dit ZAAKTYPE met het hoogste volgnummer."

In dat geval zou de reeds bestaande scope geforceerd-bijwerken gebruikt kunnen worden om een zaak die reeds een eindstatus heeft bereikt te voorzien van een nieuwe, eerdere status. Bij het heropenen van een zaak zou de Zaak.eindDatum ook leeg gemaakt moeten worden, de zaak is immers niet meer gesloten. Dit leegmaken van Zaak.eindDatum zou ook kunnen met dezelfde scope geforceerd-bijwerken.

Dit werkt ook al zo. Het is nu al mogelijk om een zaak te heropenen door een andere status dat de eindstatus te zetten. Daarbij wordt de einddatum leeg gemaakt. Dit staat beschreven in ZRC-008 en werkt correct in de implementaties die ik getest heb. Hier is ook een speciale scope voor 'zaken.heropenen'.

In Zaken API 1.3 is het attribuut indicatieLaatstGezetteSatus toegevoegd. Dat is dit attribuut in RGBZ 2 https://www.gemmaonline.nl/index.php/Rgbz_2.0/doc/attribuutsoort/status.indicatie_laatst_gezette_status

https://zaken-api.test.vng.cloud/api/v1/schema/#operation/status_read

Door dit attribuut te gebruiken wordt volgens mij een groot deel van het probleem opgelost, zeker wanneer ook nog de scope geforceerd-bijwerken toegevoegd wordt zodat een zaak heropend kan worden en deze een andere dan de vastgelegde eindstatus kan krijgen.Is oplossingsrichting 3 dan nog nodig? Volgens mij niet omdat je nu kunt bepalen of een eindstatus ook daadwerkelijk de laatst gezette status is. Is dit niet zo dan is de zaak nog niet afgehandeld en wordt de einddatum van de zaak niet gezet.

Als het inderdaad mogelijk wordt om dit attribuut te zetten bij het plaatsen van een status, dan denk dat dat het probleem inderdaad oplost. Zo te zien is dat het geval. Dit is in feite een variant of invulling van "Oplossingsrichting 2" die ik hierboven beschreef. Dus mooi dat dit probleem al is opgelost!

Het is dan wel van belang dat niet ook "Oplossingsrichting 1" geïmplementeerd wordt, dus het moet juist wel mogelijk blijven om op een later moment een status toe te voegen met een eerdere datumStatusGezet, maar wel het attribuut indicatie_laatst_gezette_status.

[MNIJ]

Ik zou dit graag even testen. Misschien is het een domme vraag, maar hoe kan ik tegen de https;//zaken-api.test.vng.cloud aanpraten? De credentials die ik gebruik voor https://zaken-api.vng.cloud werken niet.

[michielverhoef]

Dat is geen stomme vraag helaas :-( We zijn er druk mee bezig maar de token generator werkt momenteel alleen nog voor de productieomgeving. Ik heb zojuist onze ontwikkelaars hier nog naar gevraagd.

[MNIJ]

Ik ben toch niet helemaal zeker of dit het probleem oplost.
Van de ene kant zit het nieuwe veld indicatie_laatst_gezette_status in de request body van het bericht om een status te zetten. wat impliceert dat je het expliciet kan zetten bij het aanmaken van een status. Van de andere kant is de beschrijving van het veld:

Het gegeven is afleidbaar uit de historie van de attribuutsoort Datum status gezet van van alle statussen bij de desbetreffende zaak.

Dat impliceert dat het automatisch bepaald wordt op basis van de status met de hoogste datum en dan is er dus eigenlijk niks veranderd. Dan is dit veld alleen een convenience property waardoor je als afnemer niet hoeft te sorteren op datum.

[michielverhoef]

Dat bedacht ik me gisteren ook al. Ik denk dat dit veld uit de bewerk operaties (POST, PUT, PATCH) gehaald moet worden en door de ZRC automatisch berekend/gevuld moet worden.

[michielverhoef]

Wat wel zou kunnen is dat er een regel komt dat je geen status mag injecteren, dus tussen reeds gezette statussen in kunt plaatsen.

Wanneer indicatieLaatstGezetteStatus dan gezet wordt op het moment dat een status daadwerkelijk gezet wordt is het weliswaar geen afgeleid gegeven meer maar wel een "hard" gegeven. Lost dat het probleem op?

Ik heb #2088 hiervoor aangemaakt.

[michielverhoef]

Ik zou dit graag even testen. Misschien is het een domme vraag, maar hoe kan ik tegen de https;//zaken-api.test.vng.cloud aanpraten? De credentials die ik gebruik voor https://zaken-api.vng.cloud/ werken niet.

Helemaal lekker werkt het nog niet maar via https://zaken-auth.test.vng.cloud/ zou je een token moeten kunnen genereren etc. Omdat de Notificaties API herzien is en deze token tool nog uitgaat van de oude versie krijg je een 500 foutmelding wanneer je het vinkje voor superuser gebruikt. Bij handmatig per API instellen geeft ook een 500 error maar wanneer je dan terug gaat (in de browser, niet via de knop Home) blijkt de ingestelde autorisatie toch doorgevoerd te zijn.

Er wordt nog naar gekeken, zodra het opgelost is laat ik het weten.

[MNIJ]

Wat wel zou kunnen is dat er een regel komt dat je geen status mag injecteren, dus tussen reeds gezette statussen in kunt plaatsen.

Wanneer indicatieLaatstGezetteStatus dan gezet wordt op het moment dat een status daadwerkelijk gezet wordt is het weliswaar geen afgeleid gegeven meer maar wel een "hard" gegeven. Lost dat het probleem op?

Ik heb #2088 hiervoor aangemaakt.

Het verbieden van het "injecteren" van een status zou inderdaad de bug oplossen. (dat is "oplossingsrichting 1" in de originele beschrijving).

Maar ik denk wel dat er dan (van ons of van anderen) een nieuw userstory aangemaakt gaat worden voor het kunnen wijzigen van de einddatum van een zaak. Al dan niet na het heropenen. Maar het is misschien wel zuiver om dat in een losstaand issue te doen.

[sergei-maertens]

Ik heb nog niet de hele discussie gelezen, maar ik wil wel iets opmerken:

Daarmee kan er geen status "geïnjecteerd" worden in de tijdlijn van de zaak en kan bovenstaande probleem niet optreden.

Dit is problematisch bij migraties van zaaksystemen naar ZGW API's via de API. Als je statushistorie migreert, dan is dat een hele goeie kandidaat om dat in parallel in plaats van sequentieel te doen. Er is dus geen garantie dat de statussen ook in volgorde van de werkelijkheid bij de Zaken API aankomen én verwerkt worden (race condition).

Dit speelt ook in programmeertalen die een async event loop hebben - er is geen garantie over volgorde van de calls die gemaakt wordt in die situaties.

[sergei-maertens]

Rest doorgelezen.

Het lijkt mij perfect valide om t.b.v. correcties toch "eerdere statussen te injecteren". Er kan altijd iets fout gaan en dat moet je kunnen corrigeren.

M.i. is er gewoon een bug/ambigue gedrag in de referentie-implementatie (onlangs hebben we dit zelfs gefixed in Open Zaak) waarbij Zaak.status niet naar de meest recente status (op basis van timestamp) wijst, maar naar de status op basis van database ID. En dat gaat fout als je een nieuwe status met een eerdere datum aanmaakt.

Aangezien Zaak.status berekend/afgeleid is, moet m.i. gewoon de bug in referentie-implementatie gefixed worden met de reden dat "status-met-meest-recente-timestamp = huidige status". Zo was het in het design ook bedoeld volgens mij.

[MNIJ]

Rest doorgelezen.

Het lijkt mij perfect valide om t.b.v. correcties toch "eerdere statussen te injecteren". Er kan altijd iets fout gaan en dat moet je kunnen corrigeren.

M.i. is er gewoon een bug/ambigue gedrag in de referentie-implementatie (onlangs hebben we dit zelfs gefixed in Open Zaak) waarbij Zaak.status niet naar de meest recente status (op basis van timestamp) wijst, maar naar de status op basis van database ID. En dat gaat fout als je een nieuwe status met een eerdere datum aanmaakt.

Aangezien Zaak.status berekend/afgeleid is, moet m.i. gewoon de bug in referentie-implementatie gefixed worden met de reden dat "status-met-meest-recente-timestamp = huidige status". Zo was het in het design ook bedoeld volgens mij.

Dat zou het probleem inderdaad oplossen en dit is ook het gedrag dat ik oorspronkelijk had verwacht. Dit is een vrij simpele fix, gelijk aan wat ik hierboven "oplossingsrichting 2" heb genoemd. Als we dit gewoon als een bug zien (zo heb ik dit ook indgediend), hoeft er dus niet eens een aanpassing in de standaard voor te komen maar alleen bugfixes in de implementaties. Ik begrijp dat die bugfix in Open Zaak al is gedaan, blijkbaar in een nieuwere versie dan die ik getest heb, maar dat zou heel goed kunnen.

Ik sluit niet uit dat er op termijn dan nog steeds een user story komt om de einddatum van de zaak te kunnen corrigeren, maar dat is dan veel minder urgent en mogelijk zelfs totaal overbodig.

[MNIJ]

Het is dan nog wel een goed idee om dit gedrag ergens in de standaard te benoemen, zodat daar bij (nieuwe) implementaties naar verwezen kan worden.

[WilliamRoxit]

Misschien moet dat gewoon benoemd worden bij de status property op het zaak object in de OpenAPI spec, samen met een ZRC postman testcase (welke dan als een soort compliance test gebruikt kan worden).

[michielverhoef]

Rest doorgelezen.

Het lijkt mij perfect valide om t.b.v. correcties toch "eerdere statussen te injecteren". Er kan altijd iets fout gaan en dat moet je kunnen corrigeren.

M.i. is er gewoon een bug/ambigue gedrag in de referentie-implementatie (onlangs hebben we dit zelfs gefixed in Open Zaak) waarbij Zaak.status niet naar de meest recente status (op basis van timestamp) wijst, maar naar de status op basis van database ID. En dat gaat fout als je een nieuwe status met een eerdere datum aanmaakt.

Aangezien Zaak.status berekend/afgeleid is, moet m.i. gewoon de bug in referentie-implementatie gefixed worden met de reden dat "status-met-meest-recente-timestamp = huidige status". Zo was het in het design ook bedoeld volgens mij.

Het duurde even tot ik bovenstaande snapte maar als ik het goed begrijp wordt in de referentie implementatie de indicatielaatsGezetteStatus berekend op basis van recordID in plaats van datumStatusGezet? Dat is inderdaad een bug die er meteen uitgehaald moet worden.

Hmm, stof tot nadenken..

[MNIJ]

Even voor de duidelijkheid, welke time-stamp bedoel je @sergei-maertens ?
Zou volgens jou de status van de zaak moeten zijn:

1. De status met de hoogste waarde in het veld datumStatusGezet?
2. Of de status met de hoogste waarde als creation date?

Optie 2. zou dit probleem oplossen. Optie 1. is volgens mij juist hoe het nu werkt in de implementaties die ik getest heb en de oorzaak van het probleem.

[michielverhoef]

datumStatusGezet is een functionele datum, niet de technische datum waarop het record aangemaakt is. Die datum moet dus niet gevuld worden met de timestamp van het moment van het aanmaken van een record maar met de datum waarop de zaak een nieuwe status heeft gekregen. creationDate is een timestamp voor aanmaken van een record.

Wanneer je een status injecteert wordt datumStatusGezet gevuld met de datum waarop de zaak die status heeft gekregen, niet met de timestamp waarop het record is aangemaakt.

De huidige status is de status met de hoogste waarde in datumStatusGezet. Dat is de meest recente status.

Ik ga uitzoeken hoe bij het wegschrijven van een status de datumStatusGezet gevuld wordt.

Edit: Zo wie zo moet indicatieLaatstGezetteStatus weg uit de requestbody van de POST en afgeleid worden.

[MNIJ]

Het is (of lijkt) ook helemaal logisch dat de status van de zaak de status is met de hoogste datumStatusGezet. Maar mogelijk heb ik het probleem daarmee dan niet helemaal duidelijk gemaakt. Nogmaals het reproductiescenario:

1. Gegeven: Een zaak van een zaaktype met minimaal 2 statustypes, bijvoorbeeld Zaak in behandeling en Zaak afgerond, waarbij Zaak afgerond de eindstatus van de zaak is
2. Voeg een status aan de zaak de zaak met status.type = Zaak in behandeling en status.datumStatusGezet = 10 april
3. Voeg daarna een status aan de zaak de zaak toe met status.type = Zaak afgerond en status.datumStatusGezet = 1 april

Gevolg: de zaak krijgt einddatum 1 april en wordt in alle opzichten behandeld als een gesloten zaak. Maar de status van de zaak wordt teruggegeven als Zaak in behandeling en niet als Zaak afgerond.

In dit reproductie-scenario is de status van de zaak dus inderdaad de status met de hoogste datumStatusGezet. Maar de zaak wordt door stap 3 wel gesloten en krijgt de einddatum 1 april. Je zit dan dus in een soort hybride situatie waarin de status van de zaak gebaseerd is op de status met de hoogste datumStatusGezet, maar het sluiten van de zaak gebaseerd is op de status die het laatst is toegevoegd (maar dan dus met een lagere datumStatusGezet).

Dat lijkt me in ieder geval niet correct. Als vervolgens de conclusie is dat datumStatusGezet altijd leidend zou moeten zijn voor wat de actuele status van de zaak is, dan zou stap 3. de zaak dus niet moeten sluiten. Dat is een prima antwoord, maar dat gebeurt nu wel en dat is de bug die ik probeerde duidelijk te maken.

En als dat het antwoord is, dan komt de vervolgvraag: hoe kan de einddatum van een zaak gecorrigeerd worden? Maar dat is dan een nieuwe functionele user-story.

[michielverhoef]

In het voorbeeld zijn foute gegevens opgeslagen. In de zin dat later een (eind)status is gezet met een eerdere datumStatusGezet dan de status die er voor gezet is.
Hoewel er op dit moment geen validatie is om dit te voorkomen zit daar de fout. Volgens mij geef je dit ook zelf aan.

Dat vervolgens de verkeerde status als laatstgezette status wordt berekend is niet de fout van afleiden uit de hoogste waarde van datumStatusGezet maar omdat de gegevens niet correct zijn.

Tenzij de zaak als volgt doorlopen is:

• Zaak wordt aangemaakt met status.type = zaak.afgerond en status.datumStatusGezet = 1 april
• Zaak wordt gemuteerd en er wordt een status status.type = zaak.inbehandeling en status.datumStatusGezet = 10 april aan toegevoegd

Dat lijkt me niet de bedoeling? Tenzij de zaak inderdaad heropend is en de status inBehandeling inderdaad de laatste status is.

Het is lastig hier goede validatie voor te bedenken. Dichttimmeren met een regel dat er altijd een datumStatusGzet moet zijn die gelijk aan of hoger moet zijn dan die van de huidige laatste status maakt het onmogelijk een status te injecteren.

[MNIJ]

In het voorbeeld zijn foute gegevens opgeslagen. In de zin dat later een (eind)status is gezet met een eerdere datumStatusGezet dan de status die er voor gezet is. Hoewel er op dit moment geen validatie is om dit te voorkomen zit daar de fout. Volgens mij geef je dit ook zelf aan.

Klopt, maar er is niets in de standaard dat zegt dat dit niet zou mogen en er is dus ook geen validatie op.

Dat vervolgens de verkeerde status als laatstgezette status wordt berekend is niet de fout van afleiden uit de hoogste waarde van datumStatusGezet maar omdat de gegevens niet correct zijn.

Als de regel inderdaad is "De status van de zaak is de status met de hoogste datumStatusGezet" en volgens mij is dat wat zowel jij als @sergei-maertens zeggen (en het is ook vrij logisch), dan is de fout in het gegeven voorbeeld niet zozeer de status van de zaak, want die voldoet aan die regel, maar het feit dat de zaak gesloten wordt in stap 3.

De oplossing zou dan dus een validatie zijn die stap 3 voorkomt. Dat zou kunnen zijn:
"Bij het toevoegen van de eindstatus aan de zaak MOET de datumStatusGezet hoger zijn dan de hoogste bestaande waarde van de statussen bij de zaak."

Daarmee voorkom je dat de zaak voortijdig gesloten wordt, maar is het nog steeds mogelijk om bijvoorbeeld in een conversie scenario de overige statussen asynchroon toe te voegen.

[MNIJ]

Zoals ik al eerder aangaf gaan we dan wel een user story aanmaken voor het corrigeren van de einddatum van de zaak. Want we kwamen achter deze bug bij het onderzoeken van scenario's voor het heropenen van zaken (iets wat al kan) en het daarna weer sluiten van de zaak met ofwel een gecorrigeerde einddatum ofwel met herstel van de oorspronkelijke einddatum. Dat is onmogelijk als de business rules zijn:
zaak.status == status met hoogste datumStatusGezet EN de enige manier om de einddatum van een zaak te zetten is d.m.v. datumStatusGezet bij het zetten van de eindstatus.

[michielverhoef]

Als de regel inderdaad is "De status van de zaak is de status met de hoogste datumStatusGezet" en volgens mij is dat wat zowel jij als @sergei-maertens zeggen (en het is ook vrij logisch), dan is de fout in het gegeven voorbeeld niet zozeer de status van de zaak, want die voldoet aan die regel, maar het feit dat de zaak gesloten wordt in stap 3.

Een zaak wordt afgesloten wanneer deze een eindstatus bereikt heeft, daar zou ik niet aan tornen.

De oplossing zou dan dus een validatie zijn die stap 3 voorkomt. Dat zou kunnen zijn:
"Bij het toevoegen van de eindstatus aan de zaak MOET de datumStatusGezet hoger zijn dan de hoogste bestaande waarde van de statussen bij de zaak."

Dat zou ik een goede regel voor validatie vinden.

Wel zou ik een soort "beschrijving van goed gedrag" willen voorstellen dat bij het injecteren van statussen die een zaak eerder gehad heeft de datumStatusGezet wel de correcte waarden moet hebben en deze overeen moet komen met de waarden tijdens de afhandeling van de zaak.

[michielverhoef]

Zoals ik al eerder aangaf gaan we dan wel een user story aanmaken voor het corrigeren van de einddatum van de zaak. Want we kwamen achter deze bug bij het onderzoeken van scenario's voor het heropenen van zaken (iets wat al kan) en het daarna weer sluiten van de zaak met ofwel een gecorrigeerde einddatum ofwel met herstel van de oorspronkelijke einddatum. Dat is onmogelijk als de business rules zijn: zaak.status == status met hoogste datumStatusGezet EN de enige manier om de einddatum van een zaak te zetten is op d.m.v. datumStatusGezet bij het zetten van de eindstatus.

Volgens mij geeft dat geen problemen toch? Een heropende zaak heeft geen einddatum meer, die is immers leeggemaakt bij het heropenen. Op het moment dat een zaak opnieuw een eindstatus bereikt wordt de einddatum weer gezet. Met de datumStatusGezet van de nieuwe eindstatus.

Zolang een heropende zaak geen eindstatus die tevens de laatste status is meer heeft is deze nog niet afgesloten en is de einddatum leeg.

[MNIJ]

Weer even een simpel voorbeeld van een zaak met diezelfde twee statustypen In behandeling en Afgerond.

1. Zaak wordt gestart op 1 juni en krijgt status In behandeling met datumStatusGezet = 1 juni
2. Zaak wordt afgerond op 10 juni en krijgt status Afgerond met datumStatusGezet = 10 juni, hierdoor wordt de einddatum ook 10 juni.
3. Zaak wordt heropend op 20 juni door opnieuw de status In behandeling te zetten met datumStatusGezet = 20 juni
4. De gebruiker wil vervolgens de zaak opnieuw sluiten. Daarvoor moet opnieuw de status Afgerond worden toegevoegd. Dit kan nu alléén met een datumStatusGezet en dus een nieuwe einddatum van 20 juni of hoger. Functioneel gezien wil je de mogelijkheid hebben om de einddatum van 10 juni te herstellen of eventueel zelfs om een geheel andere einddatum te zetten in het kader van foutcorrectie.

Maar het lijkt me zuiverder om deze wens niet verder in deze bug te bespreken, maar in een apart issue.

[michielverhoef]

Als je een issue aanmaakt ga ik daar dan op reageren :-)

[MNIJ]

Ok, dat zal ik doen zodra we de user-stories daarvoor 100% scherp hebben. Dat zal waarschijnlijk zijn nadat we de functionaliteit voor het heropenen met deze beperking gedemonstreerd hebben.

[ArjanKloosterboer]

@ArjanKloosterboer Kun jij hier ook naar kijken?

Oeps, al een hele discussie. Ik draag wat bij vanuit de functionele insteek, hoe het bedoeld is. Niet hoe dit in API's te vatten (daar zijn jullie goed in).
M.i. ontbreekt er in het RGBZ een bedrijfsregel voor de attribuutsoort 'Datum status gezet' die stelt dat statussen achtereenvolgens worden gezet. M.i. is het zo wel bedoeld, meen ik te lezen uit de toelichting op het objecttype Status: "Een zaak heeft in de loop van de tijd meerdere statussen: de achtereenvolgens bereikte mijlpalen. [...] De laatst bereikte status is uiteraard de meest actuele status. Daarvoor bereikte statussen zien we niet als historische waarden van de laatst bereikte status maar als historische statussen." De vermelde casus, 1e status op 10-4 en 2e op 1-4, zou dan ook niet moeten kunnen. Dat pleit voor oplossingsrichting 1.
Ik lees her en der dat dat in individuele gevallen tot problemen leidt, zoals bij het heropenen van een zaak en het 'injecteren' van tussenliggende statussen. Beide zijn m.i. geen normaal patroon maar afwijkende situaties waarin iets gecorrigeerd moet worden. Dat moet m.i. dan ook geen normale gang van zaken worden maar apart opgelost worden.
Het heropenen van een zaak is niet niets. Misschien is 'ie al gearchiveerd en wat zijn dan de consequenties? Bij het heropenen gaat m.i. de zaak weer verder d.w.z. de einddatum gaat er van af en er wordt een status toegevoegd die de stand na heropening weergeeft en een statusdatum na de laatst geregistreerde status heeft (de zaak gaat immers verder). Daarna verloopt alles weer als normaal, maar wel oppassen bij het opnieuw afsluiten (op een latere datum) ivm. evt. eerdere archivering.
Ik lees dat het ook kan voorkomen dat een zaak heropend wordt en weer afgesloten wordt met dezelfde einddatum. Dat is m.i. typisch een geval van correctie dat als zodanig verwerkt moet worden. Dit niet als normale gang van zaken beschouwen.
En dan zouden ook nog statussen 'geinjecteerd' moeten kunnen worden. Ook geen normale gang van zaken, blijkbaar is er iets mis gegaan bij het registreren. Ook als apart geval behandelen.

[sergei-maertens]

Even voor de duidelijkheid, welke time-stamp bedoel je @sergei-maertens ? Zou volgens jou de status van de zaak moeten zijn:

1. De status met de hoogste waarde in het veld datumStatusGezet?
2. Of de status met de hoogste waarde als creation date?

Optie 2. zou dit probleem oplossen. Optie 1. is volgens mij juist hoe het nu werkt in de implementaties die ik getest heb en de oorzaak van het probleem.

Ik had notificaties gemist zie ik.

De timestamp die ik bedoel is dus Status.datumStatusGezet (ondanks de naam van het attribuut is dit een datetime, met dus precieze informatie en er kan binnen dezelfde dag gesorteerd worden).

De status van de zaak = de status met meest recente (=hoogste) waarde datumStatusGezet.

In principe is het toch de bedoeling dat je een status aanmaakt voor het moment dat die status bereikt is. Als dat in het verleden ligt, prima, als dat "nu" is, dan wordt dat de nieuwe "huidige status" van de zaak. Dit laat je dus toe om een status met datumStatusGezet in het verleden nu te registeren, zonder dat dat afbreuk doet aan wat de daadwerkelijke huidige status is.

Een zaak heropenen is dan een nieuwe status "nu" zetten die niet eindstatustype is.

Ik denk dat er misschien een beleving is dat status volgnummer alleen maar omhoog mag gaan, maar in het kader van correcties en potentieel werkelijk verloop lijkt me dat geen requirement. Is wel een vervelende ervaring voor de klant...

[michielverhoef]

Helemaal mee eens. Het feit dat een status nu geregistreerd wordt staat los van het moment waarop die status bereikt is. In datumStatusGezet wordt het moment waarop die status bereikt is vastgelegd, niet het moment waarop de administratie bijgewerkt is.

[sergei-maertens]

de rest van de discussie kan ik me ook in vinden - extra validatie op het moment van zetten van eindstatus lijkt me een praktische oplossing, en misschien moet het inderdaad ook mogelijk worden om de einddatum expliciet te schrijven. Wel zou ik daar dan aandacht voor willen in de audittrails als dat gebeurt, omdat dit afwijkingen zijn t.o.v. normaal gedrag (wat Arjan ook beschrijft).

Afwijkingen moeten inderdaaad als afwijkingen beschouwd worden, maar de API moet natuurlijk ontworpen worden zodat je deze technisch nog kan uitvoeren. Daar zit de uitdaging :D