Problems in and solutions for ZTC 1.3
There are numerous problems within the standard ZTC 1.3. For some of these problems, we have posted issues on Github for ZGW. In the table below we list the Github issues and indicate how various Roxit components (should) deal with them.
The "ZTC 1.3.3" column indicates whether and how the official standard itself resolved the problem in that version - as opposed to the other columns, which describe how our own software deals (or dealt) with the problem, regardless of the standard.
| Problem (short) | Github issue | ZTC 1.3.3 | Solution in ZTC registration component itself | Solution in ZRC, BRC or DRC | Solution in ZTC config app (PMA process, casetype management) | Solution in client app |
|---|---|---|---|---|---|---|
| Scope geforceerd verwijderen (forced delete) unclear | #2478 | Scope must be ignored | Do not give the possibility to delete pubished types (in stead give the casetype an end date) | |||
| Scope geforceerd schrijven (forced update) superfluous | #2477 | Scope must be ignored | Give a warning when correcting | |||
| ztc-013 is unclear | #2482 | Business rule ztc-013 has been removed | Apply the rule only to roltype-zaaktype, eigenschap-zaaktype, statustype-zaaktype, zaaktypeinformatieobjecttype-zaaktype and resultaattype-zaaktype. | |||
| Filter on status for object types without status unclear | #2479 | Solved according to our suggestion | Filter on status of related case type | |||
| Double relationship: BT-> ZT on BT and ZT-> BT on ZT | #2475 | Relationship BT-> ZT is not possible anymore | Relationship BT-> ZT is not stored (or retrieved) | When creating or updating a Besluit with a related case, check whether the casetype of the case is related to the besluittype of besluit | Only allow config on ZT->BT. Do not give the possibility BT-> ZT | Retrieve possible BT's by a GET on ZT. The get on BT will not return ZT's |
| Which URL's of related ZT, BT or IOT (here related type or "RT") are returned in GET on BT, ZT, ZIOT and IOT (here objecttype or "OT") | #2474 | Solved according to our suggestion | Return the following url's of RT:
| - | If the name (= description, identification) of RT also is available in the response - show that. Otherwise do a GET on the RT and show its name. | - |
| ZTC: attribute name of ZT identificatie en ZT datumgeldigheid is different in response resultaattype | #2473 | Solved according to our suggestion | zaaktypeIdentificatie and datumgeldigheid in response | use zaaktypeIdentificatie and datumgeldigheid from response | ||
| Business rule ztc-011 is ambiguous and superfluous | #2471 | Solved according to our suggestion | Do not implement ztc-011 | Do not implement ztc-011. Do use ztc-010 (with adjustments - see below) and ztc-009 | ||
| Business rule ztc-012 is unclear and superfluous | #2476 | Business rule has been removed according to our suggestion | Do not implement ztc-012 | Do not implement ztc-012. Do use ztc-010 (with adjustments - see below) and ztc-009 | ||
| Catalogus attribute is superfluous in POST/PUT/PATCH voor Resultaattype en Roltype | #2468 | Solved according to our suggestion | Neglect the catalogue field in these calls | Don't implement a possibility to add a catalogue to Resultaattype en Roltype | ||
| Unclear in which format BT and IOT are added to resultaattype and whether they are required | #2467 | Required has been removed according to our suggestion | For both BT and IOT:
| For both BT and IOT:
| ||
| ztc-010 is unclear and should be rewritten | #2456 | Business rule rewritten according to our suggestion | If Roltype, Statustype, Eigenschap, Zaaktype-Informatieobjecttype, Resultaattype or Zaakobjecttype is related to ZT with concept=false then no POST/PUT/PATCH/DELETE is allowed except in correction mode | If Roltype, Statustype, Eigenschap, Zaaktype-Informatieobjecttype, Resultaattype or Zaakobjecttype is related to ZT with concept=false then no POST/PUT/PATCH/DELETE is allowed except in correction mode | ||
| New business rule begin/einde Geldigheid | #2455 | Rules for geldigheid are now according to our suggestion | Apply to published versions of ZT with identical identifications, BT with identical descriptions, and IOT with identical descriptions: They may not have overlap in Geldigheid (validity). The period of validity (geldigheidsperiode) is the series of dates >= beginGeldigheid AND <= eindGeldigheid, (where empty eindGeldigheid is the highest possible date). | Apply to published versions of ZT with identical identifications, BT with identical descriptions, and IOT with identical descriptions: They may not have overlap in Geldigheid (validity). The period of validity (geldigheidsperiode) is the series of dates >= beginGeldigheid AND <= eindGeldigheid, (where empty eindGeldigheid is the highest possible date). | ||
| POST zaken not backwards compatible because deelzaaktypen required | #2452 | Required has been removed according to our suggestion | Do not check on presence Deelzaaktypen | Do not require deelzaaktypen | ||
| GET ZT -> informatieobjecttypen should return array (not string) | #2445 | Solved according to our suggestion | Return multiple IOT (if present) in response | Support multiple IOT in response | Support multiple IOT in response | |
| POST besluittype should support related ZT | #2437 | Not really solved (OAS still lacks this attribute), but our suggestions are valid | Allow the field but neglect it (see #2475) | Do not support this attribute (see #2475) |