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.
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.
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.
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:
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.
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.
Ik ben het eens met Wouter.
Op het moment dat een eindgebruiker een nieuw docoument wil genereren in bijvoorbeeld SquitXO dan duurt de, door Roel gestelde keten veel te lang. Deze keten begint met een asynchroon bericht waarbij de verwerking er van niet direct hoeft plaats te vinden, zeker niet als er een servicebus met wachtrijen tussen zit.
De gebruiker wil bij voorkeur direct in het nieuw gegenereerde document de beschikking hebben over gegevens die het zaaksysteem/DMS heeft gegenereerd. Het kunnen opnemen van extraElementen of parameters in het synchrone genereerDocumentIdentificatie_Du02 antwoord is daarom erg wenselijk.
Daarnaast dwingt ons zaaksysteem af dat een zaakdocument alleen gemaakt mag worden binnen een zaak. Het genereren van alleen een documentidentificatie kan daarom geen reservering maken van een daadwerkelijk document-record zonder dat we weten voor welke zaak het zaakdocument bedoeld is. Mede om deze reden gebruiken we een sleutel (GUID) als documentidentificatie in plaats van een leesbaar kenmerk die direct op de brief gebruikt kan worden. De opmaak van een document-kenmerk dat ons systeem genereert kan ook nog eens afhankelijk zijn van het zaaktype en documenttype waarin het zaakdocument wordt aangemaakt.
Het kunnen meesturen van de zaakidentificatie en het liefst ook het documenttype in het 'genereerDocumentIdentificatie_Di02' bericht heeft daarom ook mijn voorkeur.