Op dit moment sturen wij vanuit ons Zaaksysteem ook berichten naar andere partijen. We ondersteunen daar in ieder geval de ZAKlk01 en de EDCLk01 berichten om andere applicaties (front- en back) te attenderen op nieuwe zaken en nieuwe documenten bij een zaak. Dit is een missende feature van ZS-DMS maar is wel gewoon StUF-Zaken. Het lijkt me goed als we met elkaar kunnen afstemmen dat alle partijen (ZsC en DsC) die meedoen met de ZS-DMS services ook ondersteuning bieden voor het ontvangen van zaakinformatie en documentinformatie. Hierbij minimaal een bevestiging sturen (Bv03) van een toevoeging, wijziging en verwijdering (T, W, V) mutatiesoort van ZAKLk01 en EDCLk01. Wat een consumer daar vervolgens mee doet is aan hen. In ieder geval een ZAKLk01 toevoeging verwerken om de zaak in behandeling te nemen. Een ZsC kan zelfs volstaan met de zaak opslaan en via GeefZaakDetails (wel in ZS-DMS, dus al ondersteund) de zaak bij te werken in de eigen applicatie. Voor EDCLk01 kan dit puur ter notificatie en kan met GeefLijstZaakdocumenten de complete lijst opgehaald worden. We merken nu echter in de praktijk dat medewerkers niet in de backoffice op F5 drukken om hun documentenlijst te vernieuwen en graag proactief willen weten wanneer een document wordt toegevoegd aan een zaak.
wo, 28-05-2014 - 16.41u
#1
Uitgaande berichten door ZS naar ZsC en DsC
René, lijkt mij een prima voorstel, waarbij ik nog enkele vragen en opmerkingen heb: - Is er een reden dat je specifiek de mutatiesoorten C en F niet noemt? - Zou deze aanpassing verplicht moeten worden voor alle ZsC's en DsC's? M.i. is dat een zware uitbreiding van de eisen aan de rol van 'eenvoudige' consumer, dus ik zou zelf willen voorstellen om dit als extensie te doen. Vraag aan de overige leveranciers? - Wat vinden jullie van de suggestie van René? - Wat vinden jullie van mijn voorstel om het als extensie te doen? Het is sowieso een functionele uitbreiding, dus dit zou dan moeten gaan volgens het principe 'we beschrijven al tussentijds hoe het moet gaan werken, maar het wordt pas écht onderdeel van de standaard bij de eerstvolgende versie met functionele wijzigingen'. Op deze manier kunnen leveranciers die dat willen al voorsorteren op deze functionaliteit. Overigens maakt het voor nieuwe extensies niet zo heel veel uit of ze toegevoegd worden aan de standaard of los erbij komen; ze zijn immers niet verplicht en standaardiseren slechts 'de plusopties'. Het item heb ik met nr 33 op mijn lijst geregistreerd. Ik bedenk nog een goede prefix voor de nummering van items.
de mutatiesoorten C en F zijn bij zaakinformatie niet zo duidelijk. Voor personen (StUF-BG) is dit meer toepasbaar. Daar gaat het echt om een fysiek persoon waar foutieve informatie van rondgaat. Uiteraard kunnen we C en F ook opnemen in de lijst, maar onze zaakbehandelaars sturen wijzigingen, geen correcties.
Wat mij betreft is het een extensie, maar hoe houden we dan bij welke leverancier welke extensie ondersteund?
En er zijn dan geen alternatieven om een zaak in een ZsC te krijgen. Dit is de methode.
De oorspronkelijke post van Rene geeft mij het idee dat met deze extensie de betekenis en bedoeling van StUF lichtjes over gedaan wordt. Dit komt doordat er wordt gesproken over mutatiesoorten. Deze logica is al prima gedefinieerd in StUF zelf en het (extra) specificeren hiervan is verwarrend. Laten we het aub gewoon zaak en document-kennisgevingen noemen, zonder details van welke TFWCV wel of niet. Het gaat om de verwerking van een zaak/document bericht nadat deze is binnen gekomen bij een zaaksysteem vanuit een TSA: welke andere systemen krijgen hiervan een kennisgeving (aanroepende TSA zelf niet/wel?).
Deze vraag: "wat is de berichtenflow tussen TSA's (meervoud) en zaaksysteem" valt samen met de vraag hoe asynchrone functionele bevestigingen verstuurd moeten worden middels StUF.
Asynchrone functionele 'terugkoppeling' is onlangs in de StUF expertgroep besproken en hier is meer tijd voor onderzoek voor gevraagd. Deze usecase zou in mijn beleving daarin moeten worden meegenomen en leiden tot een verduidelijking in de StUF standaard, en daarmee ook voor de ZKN-DMS standaard. Het zou wel zuur zijn als we binnen ZKN-DMS voor een andere oplossing kiezen dan in de Expertgroep wordt gedaan dus mijn voorstel is dat af te wachten.
Het issue: terugsturen van een Bv03 is wel iets wat binnen deze standaard moet worden opgepakt omdat Pink Roccade zich beroept op StUF en Bv04's terugstuurt. Terwijl in 'keuzenVerStUFfing RGBZ.pdf' wat met elke StUF ZKN wordt meegeleverd duidelijk te lezen is dat de wsdl-schema's restricties zijn op de StUF standaard, en daarmee bepalend voor welke mogelijke reply berichten mogen worden verstuurd, is zoiets niet expliciet in de documentatie van ZKN-DMS koppelvlak genoemd.
Het lijkt me inderdaad prima om een paragraaf op te nemen over de wijze waarop het Zaaksysteem een ZsC en/of een DsC notificeert op basis van mutaties op zaken/documenten die van belang zijn voor deze ZsC/DsC. Qua modellen hoef je dan in mijn ogen niets meer uit te breiden, alleen in de functionele beschrijving hoef je dit toe te voegen.
Afgezien van de overwegingen van Wouter vindt Roxit het opnemen van (een functionele beschrijving) van de berichten van Zaaksysteem naar TSA gewenst. Deze behoefte is er via onze klanten vooral - om initieel zaken uit het zaaksysteem "door te zetten" - actief te notificeren dat er een nieuw document is bij de zaak
Ik denk niet dat het een missende feature is van de standaard. Je wilt in sommige gevallen zaken en documenten in twee richtingen synchroniseren. Dat lijkt in jouw voorbeeld van Decos met een TSA ook het geval te zijn. Dan moeten beide systemen Zaak Document Services aanbieden. Soms is Decos dan client van het TSA. Ik zou het niet willen oplossen door terug te vallen op StUF-Zaken. Gr. Hugo
Het lijkt mij inderdaad een goede zaak nader uit te werken op welke wijze TSA's worden geinformeerd over nieuwe zaken en documenten en de mutaties hierop.
Maar ik vraag me af of deze uitwerking onderdeel van de zaak- en documentservice specificaties moet zijn. Het gaat hier immers om berichten die naar TSA's en andere afnemers gestuurd worden en niet andersom.
Volgens mij ligt het daarom meer voor de hand hier een nieuwe specificatie voor op te stellen (bv. Zaaknotificatie of iets dergelijks). Daarin zou kunnen worden vastgelegd welke gebeurtenissen leiden tot notificaties, welke gegevens in de betreffende berichten worden opgenomen, hoe en waar wordt bijgehouden welke applicaties over welke gebeurtenissen worden geinformeerd, et cetera.
Ik denk niet dat Zaak- en documentservice consumers verplicht moeten worden deze berichten af te nemen. Er kan beter worden gesteld dat, als een TSA wil worden geinformeerd, deze specificaties gehanteerd moeten worden.
Ook Circle ondersteund deze functionaliteit al vanuit Verseon. Het lijk mij een goede zaak dit als extensie op te nemen in de standaard.