de vrije berichten voor het genereren van identificaties moet nog worden vastgesteld.
Ik wil graag aandacht voor extra elementen hierin, die afhankelijke van het zaaksysteem optioneel gevuld kunnen worden.
Zo heeft PinkRoccade bijvoorbeeld een extra element voor prefix, waarmee je als zaakconsumer je eigen code kunt opnemen in de zaakidentificatie.
Wij willen graag het zaaktype meekrijgen van de zaakidentificatie die wordt opgevraagd. Op die manier kunnen we regelen dat niet zomaar iedere willekeurige applicatie een zaakidentificatie bij ons opvraagt en daarna een zaak gaat creeeren waar hij niet toe gemachtigd is, of waarvan de zaaktypecode bijvoorbeeld niet eens bestaat. Ook hebben wij nu een manier waarop de zaakidentificatie wordt samengesteld op basis van die zaaktypecode, wat dus anders moet als we deze niet ontvangen bij het genereren van de zaakidentificatie.
Ook op documentidentificatieniveau willen we dat graag. Een document kan gegenereerd worden op basis van zaakidentificatie (zodat je meteen weet voor welke zaak een document wordt gemaakt) en het documentype (zodat je weet dat dit documenttype bij deze zaak thuishoort)
Het antwoord van document- en zaakidentificatie moet ook extra elementen kunnen bevatten zodat het mogelijk is om bij documenten bijvoorbeeld barcodes en kenmerken mee te geven die op het document geplaatst kunnen worden.
Als in ieder geval die mogelijkheid van extra elementen maar wordt voorzien in de vrije berichten dan komt de invulling wel goed.
De specificatie stelt de minimale set aan te ondersteunen berichten en elementen vast. Daarnaast mag elke leverancier extra elementen gebruiken zolang de berichten voldoen aan de StUF ZKN standaard. Echter, cruciaal hierbij is dat er geen eisen gesteld kunnen worden aan deze extra elementen. Oftewel, voor de serviceconsumer geldt er geen verplichting om deze extra elementen aan te leveren. Een zaaksysteem moet dus ook berichten kunnen verwerken waarin deze elementen niet zijn opgenomen. Pinkroccade mag dus werken met een extra element ‘prefix’ maar, indien een serviceconsumer geen prefix aanlevert, dan moet het bericht evengoed verwerkt kunnen worden zoals in de specificatie is aangegeven.
Als serviceprovider van de service ‘geefZaakidentificatie’ mag je kiezen om een zaaktype mee te geven in het geefZaakidentificatie bericht zolang het bericht maar voldoet aan StUF ZKN en minimaal het element ‘Zaakidentificatie’ bevat zoals is gespecificeerd. De Zaakidentificatie moet voldoen aan de eisen die het RGBZ stelt (gemeentecode + 45 tekens o.i.d.). Zolang jullie manier van samenstellen voldoet aan deze eisen dan is dat natuurlijk toegestaan. Als Zaaksysteem mag je niet verwachten dat de serviceconsumer iets met het Zaaktype (of andere elementen dan Zaakidentificatie) doet.
Hetzelfde geldt voor documentidentificatie.
Voor deze services is nog geen WSDL beschikbaar. Graag ontvangen we die op korte termijn zodat we deze services kunnen gaan implementeren volgens de standaard. Dan ziet iedere 'genereerzaakidentificatie' service van alle zaaksystemen er hetzelfde uit. Kunnen jullie aangeven wanneer deze gereed is en wordt vrijgegeven?
Volgens reactie van Decos tijdens werkgroep dd 12-2-2014 is deze vraag beantwoord/afgehandeld. Daarom topictitel aangepast naar [afgesloten]
Graag deze toch weer op de agenda zetten. Het is met de huidige service voor zaak- en documentidentificatie niet mogelijk om extra elementen mee te geven. Er is alleen een mogelijkheid voor stuurgegevens en die laten geen extra elementen toe.
Hierbij een voorstel over de wijzigingen die nodig zijn om deze extra functionaliteit te laten werken. Dit zou een extra zijn bovenop de ZS-DMS standaard voor Zaaksystemen die dit ondersteunen.
Bijlage