ZTC: voorstel business rule begin- en eindGeldigheid

[johannesbattjes]

In het hoofdstukje "Concepten" tussen business rules ztc-008 en ztc-009 staat een aantal aanwijzingen voor het gebruik van begingeldigheid en eindgeldigheid van zaaktypes, zonder dat een duidelijke business rule is gedefinieerd. Het is bijvoorbeeld niet duidelijk óf de ZTC moet checken op begin- en eindGeldigheid en zo ja hoe dan precies. Bij de implementatie van de ZTC 1.3 lopen we daar tegen aan. We stellen een business rule voor om dit duidelijk te maken.

Een situatie waar we rekening mee moeten houden is dat soms meerdere versies van een zaaktypes op één dag gepubliceerd worden. Wellicht onwenselijk, maar het kan gebeuren. Als de volgende suggestie uit de huidige standaard wordt toegepast: "de datum eindGeldigheid van de voorgaande versie van het object .. zetten met een waarde die 1 dag minder is dan de datum beginGeldigeid van de gepubliceerde versie" krijgt de voorgaande versie een datum eindGeldigheid die eerder is dan zijn eigen beginGeldigheid. Voorbeeld van het publiceren van twee versies op 30-07-2024:

	beginGeldigheid	eindGeldigheid
vervallen versie	30-07-2024	29-07-2024
geldende versie	30-07-2024

Tegelijkertijd moet het mogelijk zijn om conceptversies te laten overlappen met andere versies in geldigheid, bijvoorbeeld in het volgende (extreme) geval:

	beginGeldigheid	eindGeldigheid
gepubliceerde versie	01-01-0000
conceptversie	30-07-2024

Wij stellen een business rule voor die duidelijk aangeeft hoe en wanneer de ztc moet checken op overlap in geldigheid, en die bovengenoemde twee gevallen mogelijk maakt:

Gepubliceerde versies van zaaktypes met dezelfde identificatie mogen geen overlappende geldigheidsperiode hebben. De geldigheidsperiode is te definiëren als de reeks van datums waarvoor geldt dat de datum groter of gelijk is aan beginGeldigheid EN kleiner of gelijk aan eindGeldigheid, waarbij een lege waarde voor eindGeldigheid als de hoogst mogelijke waarde telt.

[HenriKorver]

@michielverhoef Heb jij een antwoord op deze vraag?

[johannesbattjes]

Hoi @HenriKorver het is geen vraag maar een voorstel, graag als zodanig in behandeling nemen

[MaartenRutten]

Johannes heeft een goed punt.

Ter ondersteuning van het voorstel: tijdens inrichten/onderhouden van een zaaktype is het absoluut geen uitzondering dat er meerdere versies per dag gepubliceerd worden.
Als een nieuwe zaak wordt geregistreerd op een datum waarop meerdere versies gepubliceerd zijn dan wordt de laatste versie van die dag van het zaaktype geselecteerd voor de nieuwe zaak.

[HenriKorver]

@michielverhoef Kun jij je vinden in dit voorstel?

[michielverhoef]

Per dag kan slechts 1 versie van een zaaktype geldig zijn. Mocht een geldige versie van een zaaktype fouten bevatten kunnen deze met behulp van een correctie opgelost worden. Dan worden ook de lopende zaken van dit zaaktype meegenomen in de wijziging, iets wat niet zou gebeuren wanneer een nieuwe versie van het zaaktype gemaakt zou worden.

Het lijkt me ook lastig te verkopen aan een burger wanneer deze een aanvraag doet en precies op dat moment wordt een andere versie van het bijbehorende zaaktype in gebruik genomen. Welke versie van het zaaktype is dan geldig? De versie die geldig was toen de burger de aanvraag begon of toen de zaak aangemaakt werd? Zoals gezegd, fouten kunnen hersteld worden met een correctie. Voor het overige zie ik geen reden om meerdere versies van hetzelfde zaaktype op dezelfde dag te publiceren.

Daarnaast is de datumgeldigheid van het zaaktype de aanmaakdatum (creatiedatum) van de zaak. Deze bevat geen tijd. Het is dan niet mogelijk om een zaaktype op te vragen met behulp van zaaktypeidentificatie en datumgeldigheid wanneer deze een tijd moet bevatten.

[johannesbattjes]

@HenriKorver wat precies is onduidelijk aan ons voorstel? We kunnen het toelichten.

[HenriKorver]

@johannesbattjes Ik heb het label "onduidelijk" zojuist weer ingetrokken. Vorige week was voor mij het hele versioneringsmechanisme in de Catalogi API nog één groot mysterie door gebrek aan goede documentatie. Gelukkig heb ik deze week kunnen bijpraten met Michiel en is het een stuk duidelijker geworden.

Michiel heeft inmiddels gereageerd op je voorstel. Kun je je daarin schikken?

[MaartenRutten]

Er wordt erg makkelijk gezegd "Voor het overige zie ik geen reden om meerdere versies van hetzelfde zaaktype op dezelfde dag te publiceren.".

Als een applicatiebeheerder een zaaktype configuratie aan het ontwerpen is dan wordt het zaaktype op een gegeven moment gepubliceerd. er wordt een eerste testzaak geregistreerd om de definitie te controleren. De eerste opzet (statusverloop) ziet er goed uit en de applicatiebeheerder wil nu kenmerken toevoegen aan de configuratie.
Op basis van de rule "er kan maar één keer per dag gepubliceerd worden" kan die wijziging pas de volgende dag gepubliceerd worden.

Dit is niet werkbaar voor een applicatiebeheerder.

(we werken al jaren met versionering van zaaktype configuraties en hebben nooit problemen gehad met de mogelijkheid dat een zaaktype configuratie meerdere versies kan hebben per dag. Sterker, we hebben er voordeel van. )

[johannesbattjes]

@HenriKorver Ik begrijp eigenlijk niet wat nu de procedure is.
Wij dienden een voorstel in voor een business rule in, die de standaard volgens ons verduidelijkt. Het voorstel is onderbouwd. Mocht het niet voldoende onderbouwd zijn dan hoor ik het graag. We krijgen geen vragen over de voorgestelde business rule dus ik neem aan dat ook de voorgestelde business rule duidelijk is.

Wat onduidelijk is: het verdere verloop. Is de business rule nu bijvoorbeeld al beoordeeld door @michielverhoef ? Wat is in dat geval de uitkomst? En wat zijn dan de criteria aan de hand waarvan het voorstel beoordeeld werd? Wie bepaalt of het voorstel verder in behandeling wordt genomen?

Ik wil zeker ook graag op de opmerkingen van @michielverhoef in gaan maar heb daar ook weer vragen bij, dus er zal dan een lange thread ontstaan. Voordat ik daar in duik daarom eerst deze vragen.

[HenriKorver]

Ik begrijp eigenlijk niet wat nu de procedure is.

De procedure is dat we (VNG) eerst het verzoek/voorstel/users-story goed moeten begrijpen voordat we het in behandeling kunnen nemen. Dat is bij nader inzien hier blijkbaar niet het geval, dus ik zet het label "onduidelijk" weer terug.

Bijvoorbeeld, ik begrijp je eerste voorbeeld niet goed. Daar is bij de vervallen versie de einddatum (29-07-2024) kleiner dan de begindatum (30-07-2024), oftewel er is een soort negatieve geldigheidsperiode: -1 dag. Normaal gesproken is dit niet valide. Wil je dit als een truc gebruiken om te kunnen voldoen aan de eis van "geen overlappende geldigheidsperiode"?

[HenriKorver]

Ik wil zeker ook graag op de opmerkingen van @michielverhoef in gaan maar heb daar ook weer vragen bij, dus er zal dan een lange thread ontstaan.

Ja prima, heel fijn, ik zou zeggen: ga helemaal los. Van je vragen en opmerkingen kunnen we met ze allen leren om dit subtiele onderwerp beter te begrijpen.

[johannesbattjes]

Bijvoorbeeld, ik begrijp je eerste voorbeeld niet goed. Daar is bij de vervallen versie de einddatum (29-07-2024) kleiner dan de begindatum (30-07-2024), oftewel er is een soort negatieve geldigheidsperiode: -1 dag. Normaal gesproken is dit niet valide. Wil je dit als een truc gebruiken om te kunnen voldoen aan de eis van "geen overlappende geldigheidsperiode"?

Het klopt dat de 'negatieve geldigheid' meerdere versies op één dag mogelijk maakt. Je zegt 'normaal gesproken is dit niet valide'. Maar waar staat dat in de standaard? De negatieve geldigheidsperiode volgt juist uit de standaard, want daar staat "Daarnaast is het van belang de datum eindGeldigheid van de voorgaande versie van het object te zetten met een waarde die 1 dag minder is dan de datum beginGeldigeid (sic) van de gepubliceerde versie."
Stel ik publiceer op 9-sep-2024 versie 1 van een zaaktype en even later versie 2. Versie 1 is dan de 'voorgaande versie' en die moet dus volgens deze regel in de standaard een waarde eindGeldigheid krijgen met een waarde die 1 dag minder is dan 9-9-2024, dus 8-sep-2024. Dit komt al heel veel voor en kunnen we dus ook niet terugdraaien. Dat zou een breaking change zijn.

[johannesbattjes]

@michielverhoef
"Per dag kan slechts 1 versie van een zaaktype geldig zijn. "
=> Waar komt deze stelling vandaan. Is dit een aanname van de ZGW- of andere standaard? Zo ja waar staat dat?
Of bedoel je dat dit de praktijk is? Zo ja op welke gegevens baseer je dit? In de ZTC van Fundament zitten in totaal 1353 zaaktypeversies waarvan eindegeldigheid = begingeldigheid - 1 dag, dus in de VTH-praktijk bestaan meerdere versies op één dag. Zie ook het commentaar van Maarten Rutten over de praktijk.

"Mocht een geldige versie van een zaaktype fouten bevatten kunnen deze met behulp van een correctie opgelost worden. "
=> Correctie is aan restricties gebonden. Er mag bijvoorbeeld wel een IOT worden toegevoegd maar niet verwijderd.

"Dan worden ook de lopende zaken van dit zaaktype meegenomen in de wijziging, iets wat niet zou gebeuren wanneer een nieuwe versie van het zaaktype gemaakt zou worden."
=> Maar dit gebeurt toch ook niet als ik de volgende dag een nieuwe versie publiceer (wat wel mag)?

"Het lijkt me ook lastig te verkopen aan een burger wanneer deze een aanvraag doet en precies op dat moment wordt een andere versie van het bijbehorende zaaktype in gebruik genomen. Welke versie van het zaaktype is dan geldig? "
=> stel dat je gelijk hebt dat een burger klaagt dat zijn zaak wordt afgehandeld volgens versie 1 terwijl juist op dat moment versie 2 geldig wordt. Dit kan toch ook voorkomen als versie 1 en 2 op verschillende dagen worden gepubliceerd? Stel bijvoorbeeld dat versie 1 geldig is, en versie 1 is gisteren gepubliceerd. Ik als burger doe vandaag een aanvraag denkend dat ik conform versie 1 indien, en juist op dat moment wordt versie 2 gepubliceerd. Dan is er toch precies hetzelfde probleem? Dus wat heeft het probleem met de burger dat jij ziet met het publiceren van twee versies op dezelfde dag te maken?

[HenriKorver]

Bedankt @johannesbattjes voor je heldere antwoord op mijn bovenstaande vraag. Jullie voorstel is nu voor mij duidelijk en ik kan me erin vinden. Het lijkt mij ook de enige manier om dit probleem op een backwards compatible manier op te lossen.

Ik wacht nog even de reactie van Michiel af en zal daarna je voorstel verwerken in een pull request.