BREED - over de grenzen van informatie
NETWERK VOOR DE INNOVATIEVE INFORMATIEWERKER
Omgevingswet ZTC in relatie tot de I-Navigator
Ik ben vanuit DIV betrokken bij de de implementatie van Squit2020. Squit2020 maakt gebruik van de Omgevingswet ZTC en heeft daar wat zaaktypes aan toegevoegd. Mij is gevraagd dit te matchen aan de I-Navigator. Op het oog zie ik al wat verschillen van interpretatie en zaken die ik niet kan matchen. Vanuit Squit2020 gaan zij er van uit dat ik voor de zaaktypes die zij gebruiken hier resultaatypen/bewaartermijnen voor benoem vanuit de I-Navigator.
Zijn er gemeentes die hier ook tegen aanlopen en zo ja hoe hebben jullie dit opgelost?
Berichten in deze discussie
-
Permalink Antwoord van Jean-Luc Rouvroye op
-
Dat is dus precies het probleem: de ZDS is niet voldoende. Roxit geeft het zelf ook al aan en mijn interpretatie daarvan is 'we voldoen aan de standaard, mits de leverancier van het zaaksysteem maatwerk toepast'.
Archiveren
Bij het afsluiten van de zaak stuurt Squit 20/20 een zaakresultaat mee. Dit is niet voldoende voor het automatisch bepalen van de archiverings- en vernietigingstermijn. Hiervoor is het noodzakelijk ook het product te kennen. Helaas ondersteunen ZSDMS versies 1.1 en 1.2 het meesturen van producten niet expliciet in de vorm van een vast veld.
De productsleutel van het product bij de zaak wordt wel meegestuurd in een zogenaamd extra element in het bericht creeerZaak. De naam van het extra element is "productsleutel". Tezamen met het zaakresultaat en zaaktype kan productsleutel gebruikt worden om de archiverings- en vernietigingstermijnen te bepalen. Om dit extra element te verwerken zijn verdere afspraken nodig met de leverancier van het zaaksysteem/dms: deze moet aanpassingen doen om het extra element te verwerken.
Hans Pluimers zei:Dat is, mits de betreffende organisatie het VTH-systeem en het gekoppelde archiefsysteem netjes aan elkaar heeft gekoppeld en geconfigureerd, helemaal niet nodig.
-
Permalink Antwoord van Hans Pluimers op
-
Hallo Jean-Luc,
Je kunt dit probleem op 2 manieren oplossen:
1) generieke zaakresultaten gebruiken en dan product meesturen via extra element in ZDS;
2) specifieke zaakresultaten gebruiken en dan is het niet nodig om het product mee te sturen in ZDS.
Bij het opstellen van de OW-ZTC is gekozen voor optie 2 dus dan ben je het product niet meer nodig in het archiefsysteem omdat de voor de archivering relevante parameters als zijn verwerkt in het zaakresultaat. Dan is product niet meer dan 'aanvullende metadata van een zaak' in veel gevallen wordt de productnaam ook al verwerkt in de zaakomschrijving dus dan is dat gegeven ook al zichtbaar (en doorzoekbaar) in het zaakdossier aanwezig.
In het kader van de correcte overdracht moeten dan wel alle mogelijke zaakresultaten uit de OW-ZTC ook worden opgenomen in het ontvangende zaaksysteem/archiefsysteem maar dat is dan geen 'koppelvlak-configuratie' maar ZTC-configuratie en die configuratie past (zonder technische aanpassingen) in elk zaaksysteem.
Jean-Luc Rouvroye zei:Dat is dus precies het probleem: de ZDS is niet voldoende. Roxit geeft het zelf ook al aan en mijn interpretatie daarvan is 'we voldoen aan de standaard, mits de leverancier van het zaaksysteem maatwerk toepast'.
Archiveren
Bij het afsluiten van de zaak stuurt Squit 20/20 een zaakresultaat mee. Dit is niet voldoende voor het automatisch bepalen van de archiverings- en vernietigingstermijn. Hiervoor is het noodzakelijk ook het product te kennen. Helaas ondersteunen ZSDMS versies 1.1 en 1.2 het meesturen van producten niet expliciet in de vorm van een vast veld.
De productsleutel van het product bij de zaak wordt wel meegestuurd in een zogenaamd extra element in het bericht creeerZaak. De naam van het extra element is "productsleutel". Tezamen met het zaakresultaat en zaaktype kan productsleutel gebruikt worden om de archiverings- en vernietigingstermijnen te bepalen. Om dit extra element te verwerken zijn verdere afspraken nodig met de leverancier van het zaaksysteem/dms: deze moet aanpassingen doen om het extra element te verwerken.
Hans Pluimers zei:Dat is, mits de betreffende organisatie het VTH-systeem en het gekoppelde archiefsysteem netjes aan elkaar heeft gekoppeld en geconfigureerd, helemaal niet nodig.
-
-
En de derde optie is vertaling product naar zaaktype in de ESB.
-
-
Dat is inderdaad een 3e optie maar die is erg complex.
Je moet dan niet alleen het product vertalen naar het zaaktype (van TSA > ZS en van ZS > TSA) maar dan ook nog de zaakresultaten omzetten van specifiek (OW-ZTC) naar generiek (model DSP).
Dus dat lijkt me een zeer complexe, bewerkelijke en foutgevoelige optie. Bovendien moet je aanpassingen dan altijd in de ESB-configuratie doorvoeren en dat is specialistenwerk. Bij de andere 2 opties kan een functioneel beheerder de configuratie beheren. Bij deze optie (meestal) niet. Vandaar dat ik die niet had opgenomen.
Jean-Luc Rouvroye zei:En de derde optie is vertaling product naar zaaktype in de ESB.
-
-
Je hebt helemaal gelijk, maar de ESB optie wordt door aardig wat gemeenten gekozen. Er zijn voordelen, en niet alleen omdat de archivering in het zaaksysteem beter is geregeld. De presentatie op de PIP is bijvoorbeeld ook beter, omdat de klant alleen het zaaktype ziet. Zonder vertaling van product naar zaaktype ziet de klant alleen een generiek zaaktype.
-
-
Dat klopt maar als je goede afspraken maakt over de opbouw van het onderwerp van een zaak is dat geen enkel probleem. Burgers kijken niet naar het zaaktype maar willen graag weten hoe het met hun zaak staat. En de meeste burgers hebben maar een paar zaken waar aan gewerkt wordt. Als de zaakomschrijving/het onderwerp dan voldoende helder is geformuleerd vinden ze hun zaak wel.
In het kader van de actuele ontwikkelingen rondom de ZGW-api's lijkt het erop dat het probleem rondom het meesturen van producten al is opgelost. Het product heeft al een plek gekregen binnen de ZGW-api's dus het lijkt nu vooral een 'tijdelijk' probleem te zijn dat wordt opgelost zodra een organisatie de ZWG-api methodiek gaat implementeren en gebruiken.
Jean-Luc Rouvroye zei:Je hebt helemaal gelijk, maar de ESB optie wordt door aardig wat gemeenten gekozen. Er zijn voordelen, en niet alleen omdat de archivering in het zaaksysteem beter is geregeld. De presentatie op de PIP is bijvoorbeeld ook beter, omdat de klant alleen het zaaktype ziet. Zonder vertaling van product naar zaaktype ziet de klant alleen een generiek zaaktype.
-
Permalink Antwoord van Kees-Jan Vermeulen op
-
Grappig dat je zegt 'Specifiek OW-ZTC naar generiek (model DSP)': dat is nu het hele punt: de OW-ZTC is té generiek, terwijl we in het Model-DSP specifieke processen voor de OW.
Probleem is ook dat de OW-ZTC uitgaat van producten die je kan zien als zowel producten als activiteiten. Dat matched dus niet met hoe producten worden gedefinieerd in de ZTC.
Daarnaast: de OW-ZTC kent 15 zaaktypen en dus maximaal 15 sets van statustypen die je op het PIP kan laten zien.
Er is maar 1 zaaktype beschikbaar voor APV-vergunningen en dus zullen de gegevens die je op het PIP wilt publiceren allemaal met dezelfde set statustypen moeten worden afgehandeld. Je kan dus niet per APV-vergunning andere info verstrekken, tenzij je de statustypen weer aan de producten gaat hangen.
Op de korte termijn kan dit wel werken, maar zodra je als organisatie je zaaktypen steeds beter wilt inrichten om efficiënter te werken en beter te communiceren (lees: de WOO komt eraan en daar moet je ook wat mee in je zaaktypen) wil je dus ook je zaaktypen specifieker maken. Maar aangezien producten eigenlijk leidend zijn, wordt dat lastig en dus wordt het ook lastig om afspraken te maken over de opbouw van een dossier (want je hebt maar 1 zaaktypen). Hoe meer afspraken hoe meer we moeten gaan ophangen aan producten en daar ze nooit voor bedoeld.
Jean-Luc Rouvroye zei:En de derde optie is vertaling product naar zaaktype in de ESB.
-
Permalink Antwoord van René Lodder op
-
Hallo Peter/Jean-Luc, zijn jullie ondertussen al wat opgeschoten met de mapping (vertaling) van de zaaktypen vanuit de omgevingswet ZTC met de zaaktypen in de i-Navigator. Al dan niet via de ESB?
-
-
Dag René, de keuze was gevallen op de vertaling van product naar zaaktype via enable-u. Ik wet niet of het ook gelukt is, want ik werk inmiddels bij een andere gemeente. Maar ook daar staat rx mission klaar om gekoppeld te worden, dus ik verwacht eenzelfde problematiek.
-
-
Dank Jean-Luc, heeft iemand al de vertaling kunnen maken en wil deze delen? Alvast hartelijk dank!
Partner(s)
Sponsor(s)
Direct naar...
© 2024 Gemaakt door Marco Klerks.
Verzorgd door
