In de I-Navigator is het veld Resultaattypeomschrijving vastgezet op AN80, de standaard STUF- ZTC schrijft voor dat dit AN20 moet zijn. Hier houdt de leverancier van ons zaaksysteem zich aan vast. Die willen niet aanpassen. SDU stelt dat AN80 beter aansluit bij de selectielijst, er zijn aanmerkelijk veel resultaattypeomschrijvingen die de 20 te boven gaan. Wanneer wij de ZTC inlezen dan kapt het zaaksysteem dus af. Dit is niet gewenst. Zijn er andere gemeenten die deze problemen herkennen? Is er een mogelijkheid om de standaard aan te passen en op te rekken naar AN80 zodat er betere aansluiting kan plaatsvinden op de selectielijst?
do, 9-08-2018 - 14.16u
#1
vraag over veldomvang resultaattypeomschrijving
De standaarden hierop aanpassen is niet zonder gevolgen. Backwards-compatability is lastig bij het vergroten van de lengte van een element. Daar moeten dus goede redenen voor zijn.
Als voorbeelden van resultaatomschrijvingen worden in het ImZTC genoemd "verleend", "geweigerd" en "ingetrokken". Dat zijn korte, kernachtige termen. En zo is het ook bedoeld. Wat is dan de reden dat 20 posities niet genoeg zijn? Welke omschrijvingen worden dan gebruikt? Zijn dat wel resultaatomschrijvingen of wordt er meer semantiek in vastgelegd? Kun je een paar voorbeelden geven?
In de bijlage heb ik de zaaktypen toegevoegd waarvan de resultaatomschrijving langer dan 20 is. Deze kolom is rood gemarkeerd. Deze komen uit de I-Navigator en hebben een directe relatie met de selectielijst. Wanneer je de I-Navigator als bron neemt dan heb je hier dus mee te dealen. Het gaat pas mis wanneer de eerste 20 posities identiek zijn door afkappen van het zaaksysteem. de leverancier van het zaaksysteem blijft vasthouden aan 20, de SDU blijft vasthouden aan 80.
Bijlage
Bedankt voor de voorbeelden. 20 posities lijkt inderdaad wat kort, bijvoorbeeld 'buiten behandeling gesteld' past er al niet in. Maar, formeel gezien heeft jullie zaaksysteemleverancier gelijk. De standaard schrijft 20 posities voor en dat is niet voor niets een standaard. De bedoeling is dat iedereen zich aan deze afspraken houdt opdat interoperabilteitsproblemen worden voorkomen. Het kan niet zo zijn dat een partij 'op eigen houtje' afwijkt van de standaard. Dat lijkt hier wel het geval, met een interoperabilteitsprobleen tot gevolg.
Indien een afspraak in een standaard niet meer aansluit bij de dagelijkse praktijk, dan kan er reden zijn om die afspraak te wijzigen. Daar hebben we procedures voor zodat dat beheerst plaats vindt en alle partijen de consequenties daarvan doorvoeren. Waardoor interoperabilteit geborgd blijft. Ik stel voor dat jij of SDU een dergelijk wijzigingsvoorstel doet, graag op het ZS-DMS-forum aangezien daar de meest discussies plaatsvinden en het vooral consequenties heeft voor dat koppelvlak en desbetreffende software (verwijs daarin naar deze discussie).