Zaak- en Documentservices

https://discussie.kinggemeenten.nl/discussie/gemma/koppelvlak-zs-dms/uitbreiding-van-genereer-document-identificatie-bericht
Wouter Wigman:
Graag zouden wij het genereer document-bericht willen uitbreiden met de mogelijkheid om aan te geven voor welke zaak dit document gegenereerd moet worden. Dit stelt het zaaksysteem in staat om zaak(type) specifieke informatie terug te kunnen geven in het resultaat bericht. Dit betreft bijvoorbeeld extra identificerende gegevens (zoals barcode die ook wordt teruggeven om in een document te worden opgenomen), welke zaaktype afhankelijke inhoud kent.

Het voorstel is om dit analoog aan andere berichten te doen via het element parameters. Er is een voorstel als bijlage toegevoegd.

Wouter Wigman:
Zoals toegezegd tijdens het ZKN-DMS overleg, dd 09-09-2015, volgt de volgende usecase om het probleem duidelijker te omschrijven:

Een gemeente wil bij het genereren van een nieuw document een barcode en 'OnsKenmerk' in de brief hebben staan. Dit betekent dat voordat de documentcreatie koppeling wordt gebruikt, de barcode en 'OnsKenmerk' van het document bekend moeten zijn, anders kunnen ze niet worden doorgegeven aan de DCA. De barcode en 'OnsKenmerk' zijn eigenschappen van een document, waarbij de inhoudelijke waarde afhangt van de zaak (type en/of data zoals zaaknummer) waarbij het document gegenereerd gaat worden. Om deze reden is het logisch dat het zaaksysteem, welke de document identificatie bepaald, óók deze metadata bepaald.

Bij een ZKN-DMS++ koppeling met Decos worden deze extra metadata in het EdcLa-bericht nu al gecommuniceerd via extraElementen. Dit mag volgens het schema niet,, dus dat zouden we willen opnemen in de standaard (toestaan van extraElementen in de edcLa01 van genereerDocumentIdentificatie_Du02-operatie). Ook zouden we graag de definitie voor het gebruik van deze extra Elementen willen standaardiseren voor zover mogelijk, om syntax-verschillen te voorkomen (hoofd-kleine letters, spaties).

Voorstel is om de naam en toelichting van de volgende extra elementen te definiëren:

Kenmerk - het menselijk leesbare kenmerk van een document. Dit wordt bepaald door het zaaksysteem. Dit kan eventueel gelijk zijn aan het veld 'identificatie', maar omdat identificatie ook een heel technische inhoud mag hebben (GUID), kent dit veld een ander gebruik en moet er onderscheid gemaakt worden. [Bij gemeenten wordt ook vaak de term 'OnsKenmerk' gebruikt voor dit veld.]

Barcode - het kenmerk van een document dat gebruikt kan worden in de automatisch verwerking van een document, door middel van een barcode scanner.

Het is nadrukkelijk niet de bedoeling om genoemde velden in een bericht verplicht te stellen, maar optioneel, met als doel dat indien de client en zaaksysteem deze informatie willen kunnen communiceren, duidelijk is op welke wijze dit via de standaard gedaan moet worden.

Het meest eenvoudige is misschien om de definitie van deze velden op te nemen in de standaard, en de mogelijkheid te benoemen voor de uitwisseling van deze velden, maar dit niet als 'extensie' te definiëren. Dus niet: als er een zaaknummer meegegeven wordt moet er een Kenmerk en Barcode terugkomen. Maar wel: het is mogelijk om bij het opvragen van een nieuw documentnummer, een zaaknummer mee te geven, welke het zaaksysteem kan gebruiken bij de generatie van een identificerend veld (of velden) voor het document.

Het mooiste vind ik persoonlijk om hier geen extra service-operatie voor te maken, maar de beschikbare velden toe te laten binnen de bestaande berichten, maar als men dit echt nodig vind, is een heel nieuw 'genereerOverigeDocumentIdentificaties'-bericht ook een optie.

Roel de Bruin:
De operatie is alleen bedoeld voor het genereren van een identificatie. Extra functionaliteit is hier naar mijn idee niet gewenst.

Volgens RGBZ kan een document relaties met meerdere zaken hebben. Het doorgeven van een zaakidentificatie bij het verzoek om een documentidentificatie sluit hier niet goed bij aan.

De ‘barcode’ en ‘ons kenmerk’ zijn niet opgenomen in RGBZ. Het is daarom niet wenselijk deze wel in de berichtdefinitie op te nemen.

Zouden we de elementen wel opnemen dan moet in de specificaties ook worden beschreven welke functionaliteit daar aan gekoppeld moet worden en die is mijns inziens buiten scope van de Zaak- en Documentservices.

Michiel Verhoef:
Als ik het goed begrijp worden Kenmerk en Barcode niet gebruikt voor het genereren van de documentidentificatie maar zijn deze later nodig als inhoud wanneer vanuit het DMS een document gegenereerd wordt.

Ik ben het wel met Roel eens dat het meegeven van informatie die niets met het doel van het bericht (genereren van een documentidentificatie) te maken heeft oneigenlijk gebruik van het bericht is. Alsof er een soort "overige opmerkingen" veld is wat ineens heel relevantie informatie bevat.

Kan dit niet veel netter opgelost worden door het volgende te doen:

1. genereerDocumentIdentificatie
2. maakZaakDocument => hierin kunnen kenmerk en barcode aan de object.isrelevantVoor.gerelateerde Zaak worden meegegeven
3. DMS roept Documentcreatieservices aan
4. DMS koppelt gegenereerd document aan zaak via de CMIS Documentservice #16 Koppel Zaakdocument Aan Zaak (par 5.4.1 van het specificatie document)

Wouter Wigman:
Wat ik misschien niet goed heb toegelicht, is dat een document meer dan 1 'identificatie' kan hebben in systemen die gebruik willen maken van de standaard. Het Ons Kenmerk en Barcode zijn daar voorbeelden van waarvan het gebruik en nut tot de verbeelding zou moeten spreken voor iedereen die weet hoe gemeenten met documenten omgaan.

In het voorbeeld van Michiel wordt kenmerk en barcode door de client applicatie gegenereerd. Het gaat juist om onskenmerk en barcode die door het zaaksysteem gegenereerd moeten kunnen worden, dus naast de document identificatie, en teruggeven worden aan de client applicatie, wat met deze RFC gefaciliteerd moet worden. Wat er mee gebeurt, document genereren of gewoon 'in de systemen van de gemeente gebruiken' hoeft niet specifiek genoemd te worden. Natuurlijk hoeven extra identificerende elementen niet altijd door het zaaksysteem te worden gegenereerd, maar in het geval van Decos wordt dit sinds jaar en dag al wel door hun zaaksysteem/DMS gedaan, en dus gebruikt door tal van gemeenten en allerlei applicaties die ermee koppelen.

Je kunt dus niet stellen dat het 'niets met het doel van het bericht te maken heeft, of oneigelijk gebruik van het bericht', want het gaat wel degelijk om identificerende eigenschappen voor een nieuw (te genereren) zaak-document. Het vraagt wel begrip voor het feit dat er meerdere kunnen zijn dan die ene die in de standaard is gedefinieerd. Het uitgangspunt is m.i. dat we hier een koppelvlak samenstellen dat alle bestaande moet vervangen, en dat we dus ruimte moeten kunnen geven aan dit soort 'extra elementen'.

Als Roel en de meerderheid het erg tegen staat om een expliciete definitie in de documentatie te hebben, dan hoeft dat niet per se. Als het maar in de berichten mogelijk wordt extraElementen te versturen. In RGBZ staat immers ook geen definitie van extraElementen, maar in de StUF berichten kunnen ze wel verstuurd worden.

Roel de Bruin:
In de specificaties staat: "De ‘genereerDocumentidentificatie_Di02’-service biedt DSC’s de mogelijkheid om een uniek en geldige Documentidentificatie op te halen". Het gaat hier dus niet om identificerende eigenschappen in zijn algemeenheid maar heel specifiek om een unieke waarde voor het attribuut 'identificatie'. Je moet hier ook niet uit het oog verliezen dat de berichtdefinities zijn afgeleid van het achterliggende informatiemodel. Mocht er behoefte bestaan aan meerdere identificaties, dan zouden we die moeten opnemen in RGBZ. Daar ben ik op zich geen tegenstander van.

Mogelijk biedt het voorstel van Michiel wel mogelijkheden. Het request voor MaakZaakdocument bevat zowel de documentidentificatie als de zaakidentificatie. Het zaaksysteem zou op basis daarvan een kenmerk en een barcode kunnen genereren en lokaal opslaan. Je zou die vervolgens kunnen opvragen met een request aan de functie geefZaakdocumentLezen. Die maakt voor de response gebruik van een edcLa01-bericht en voor dat bericht zijn de extra elementen wel in het schema opgenomen.

Mocht dat toch niet gaan werken, dan zouden we inderdaad ook extra elementen kunnen opnemen in de definities van de vrije berichten. De 'Ontwerpregels en best practices voor StUF-berichten' verbied dit niet en ze zijn in alle andere berichten ook opgenomen.

Uit de notulen van 5-11:
Bij gemeenten blijkt behoefte aan het kunnen aanmaken van een identificatie die meer informatie bevat dan alleen een gegenereerd, betekenisloos nummer. Na een intense discussie besluit de werkgroep het voorstel vraagbericht aan te nemen en in een parameterblok optioneel het ZaakType en/of DocumentType.omschrijving mee te geven. In de specificatie van de standaard komt een beschrijving hoe deze gegevens gebruikt kunnen worden.

Het kunnen verwerken is echter niet verplicht. Hoe de gegevens gebruikt worden bij het genereren van een betekenisvolle documentidentificatie kan per implementatie verschillen en wordt daarom door de standaard niet voorgeschreven. In het antwoordbericht bestaat al de mogelijkheid in het object Zaak extraelementen op te nemen,
deze kunnen gebruikt worden om terug te geven welke extra gegevens gebruikt zijn voor het genereren van de documentidentificatie.

Daar de beschreven functionaliteit niet voor alle gemeenten van toepassing is meent KING dat de voorgestelde oplossing niet in de standaard opgenomen hoort te worden.

De voorgestelde oplossing zal daarom niet opgenomen worden in ZDS 1.2

In een gesprek met Jos Teunissen van gemeente Oegstgeest is de vraag naar deze functionaliteit nogmaals naar voren gekomen.

Daarom is de mogelijkheid aangebracht om extraElementen in het aanvraagbericht op te nemen. Tevens is de volgende beschrijving toegevoegd aan de service genereerDocumentIdentificatie_Di02:

_In bepaalde gevallen kan het wenselijk zijn om een identificatie te genereren die meer bevat dan een uniek, gegenereerd maar verder betekenisloos nummer. In het inkomende bericht (genereerDocumentIdentificatie_Di02) kunnen extra gegevens meegestuurd worden om een betekenisvolle documentidentificatie te genereren. Hiervoor is in het element parameters de mogelijkheid om extraElementen te gebruiken. Gebruik van deze gegevens is echter niet verplicht en vergt extra, onderlinge afstemming tussen betrokken partijen. _