search

VNG-Realisatie / StUF-Standaarden

Repository met de issues uit en in de oude Drupal community omgeving en de nieuwe issues
https://vng-realisatie.github.io/StUF-Standaarden/
6 stars 3 forks source link

Het is niet mogelijk om een document met bijlagen in 1 keer op te voeren met StUF ZKN #9

Closed michielverhoef closed 3 years ago

michielverhoef commented 3 years ago

Vanuit de Veiligheidsregio Gelderland Zuid kwam de volgende vraag:

Wij zijn momenteel bezig met de inrichting van SQUIT2020, hierbij is een koppeling met Join(DMS). Nu blijkt dat wanneer we een bestand op willen slaan in Squit met meerdere bijlages, alleen de eerste bijlage geregistreerd wordt. Dit blijkt een standaard te zijn die bepaald wordt door VNG. Tenminste dat is het antwoord vanuit de firma Roxit. Zelf vinden we het een beetje raar dat dit niet mogelijk is want wanneer je 10 bijlages hebt zou je 10x iets moeten registreren. Dus mijn vraag is, is dit zo en kunt u mij aangeven waar ik deze richtlijnen terug kan vinden op jullie site ?

michielverhoef commented 3 years ago

In dit geval is er sprake van een document met bijlagen. Dit is volgens het RGBZ een samengesteld document (SDC). Een SDC bestaat uit een aantal enkelvoudig documenten (EDC) die bij elkaar horen.

In de KeuzenverStUFfing RGBZ (https://www.gemmaonline.nl/images/gemmaonline/6/6c/KeuzenVerStUFfing_RGBZ.pdf) staat op pagina 13 het volgende: De relatie tussen ZAAK en DOCUMENT is in het RGBZ gemodelleerd met de objectsoort ZAAKDOCUMENT met een aantal attribuutsoorten en relatiesoorten. ZAAKDOCUMENT wordt uitsluitend voor bevragingen geïmplementeerd in het relatie-entiteittype ZAKEDC omdat besloten is dat ZAAK en DOCUMENT alleen mogen worden gekoppeld via een EDC-kennisgeving (zie sectie 2.2) De relatie ZAAK.heeft relevant.SAMENGESTELD DOCUMENT wordt niet geïmplementeerd. Deze relatie wordt indirect gelegd via de enkelvoudige documenten die deel uitmaken van het samengestelde document en dus via een EDC-kennisgevingsbericht.

Dit betekent echter niet dat een vakapplicatie (TSA) het concept SDC niet mag ondersteunen. Integendeel, wanneer een eindgebruiker een SDC toevoegt aan een zaak dient de vakapplicatie (TSA) per onderdeel van het SDC een EDC bericht te versturen naar het Zaaksysteem.

Voor een exacte beschrijving van de relatie tussen Document (enkelvoudig en samengesteld) en Zaakdocument (de koppeltabel tussen document en zaak) zie paragraaf 2.2 van de keuzenVerStUFfing RGBZ.

Om misverstanden te voorkomen, de volgende tekst uit paragraaf 2.2 van KeuzenVerStUFfing RGBZ gaat niet over de eindgebruiker van de vakapplicatie maar over de koppeling van de vakapplicatie naar het Zaaksysteem: Omdat het werken met samengestelde documenten voorlopig nog geen gemeengoed is, wordt het niet als een ernstig gemis gezien dat je een samengesteld document met al zijn enkelvoudige documenten niet in één handeling kunt koppelen aan een zaak.

Tot zover de uitleg volgens RGBZ en keuzenVerStUFfing ZKN.

michielverhoef commented 3 years ago

Bij nadere analyse is echter gebleken dat het niet mogelijk is in het bericht edcLk01, de kennisgeving voor een enkelvoudig document, om de relatie ENKELVOUDIG DOCUMENT maakt deel uit van SAMENGESTELD DOCUMENT op te nemen.

De relatie bestaat nog wel in het objectType EDC-basis, in het objectType EDC-kennisgeving is deze echter via restrictie weggelaten.

Dit is dus een ernstige fout en dit moet worden opgelost. Dan is het mogelijk om via StUF ZKN een document met bijlagen toe te voegen. Vervolgens moet deze wijziging ook opgenomen worden in Zaak- Documentservices.

Omdat het een optionele uitbreiding van de standaard betreft is er voor gekozen deze wijziging door te voeren in de vorm van een patroonbeschrijving welke als appendix toegevoegd zal worden aan de Zaak- Documentservices 1.1 en 1.2. Voor versie 1.2 van Zaak- Documentservices zal wel een uitbreiding van de xsd schema's noodzakelijk zijn maar deze verstoort de bestaande implementaties van consumers niet.

melsk-r commented 3 years ago

Dit vereist een aanpassing van de complexType 'EDC-kennisgeving' in het schema 'zkn0310_ent_mutatie.xsd' van de StUF-ZKN 3.10 standaard. Aan dat complexType:

    <complexType name="EDC-kennisgeving">
        <complexContent>
            <restriction base="ZKN:EDC-basis">
                <sequence>
                    <element name="identificatie" ... />
                    ...
                    <element name="isRelevantVoor" .../>
                </sequence>
                ...
            </restriction>
        </complexContent>
    </complexType>

wordt dan de relatie 'maaktDeelUitVan' toegevoegd:

    <complexType name="EDC-kennisgeving">
        <complexContent>
            <restriction base="ZKN:EDC-basis">
                <sequence>
                    <element name="identificatie" ... />
                    ...
                    <element name="isRelevantVoor" .../>
                    <element name="maaktDeelUitVan" type="ZKN:EDCSDC-basis" nillable="true" minOccurs="0" maxOccurs="unbounded"/>
                </sequence>
                ...
            </restriction>
        </complexContent>
    </complexType>
melsk-r commented 3 years ago

Dit erratum is opgevoerd in de onderhoudsverzoeken als ERR0519. De lijst met onderhoudsverzoeken vind je hier.

MaartenRutten commented 3 years ago

1. Het is een wijziging met een behoorlijke impact voor applicaties in de Zaak-keten. En om de user-story te ondersteunen is het perfect mogelijk om het uploaden van meerdere bijlagen in de TSA functioneel te ondersteunen waarbij de TSA de benodigde EDC's verstuurt per bijlage. Voor de gebruiker is het één actie, voor de TSA zijn het meerdere acties.

2. Kan nagekeken worden welke CMIS operaties gebruikt kunnen/moeten worden om een samengesteld document vast te leggen in het DMS?

michielverhoef commented 3 years ago

@MaartenRutten: De beschrijving die je geeft, nl. het doorlopen van alle EDC's en die door de TSA apart laten versturen is ook de manier hoe ik het voor me zie.

Echter, zoals ik in mijn analyse heb aangegeven is de relatie ENKELVOUDIG DOCUMENT maakt deel uit van SAMENGESTELD DOCUMENT niet opgenomen in het kennisgevingsbericht voor een Enkelvoudig Document (edcLk01).

Het gaat om deze relatie: https://www.gemmaonline.nl/index.php/Rgbz_1.0/doc/objecttype/enkelvoudig_document#Relatiesoort_ENKELVOUDIG_DOCUMENT_maakt_deel_uit_van_SAMENGESTELD_DOCUMENT

Het element ZKN:maaktDeelUitVan wat wel in het EDC-Basis complexType staat is er uit gehaald in het EDC-kennisgeving complexType. Dit laatste complexType wordt gebruikt in de edcLk01 kennisgeving. het is dus niet mogelijk de relatie mee te geven en daarmee aan te geven dat een EDC tot een bepaalde SDC behoort. Om een samengesteld document mogelijk te maken moet deze relatie wel meegegeven kunnen worden.

Los van dit issue is inmiddels gebleken dat een dergelijke wijziging nog meer betekent voor de manier van werken van de medewerker. Om een EDC correct op te kunnen voeren zul je toch ofwel enkele handmatige handelingen moeten verrichten per bijgevoegd document of er voor moeten zorgen dat door aangeleverde metadata het document voldoende te identificeren is. Dit om te voorkomen dat er veel bijlagen genaamd "Bijlage1" tot en met "Bijlage26" als EDC in het DMS terecht komen.

Dit gecombineerd met de hoeveelheid werk voor leveranciers, het aanpassen van koppelingen etc is misschien een reden om dit ondanks dat het een ernstige fout is misschien toch te besluiten dit onderhoudsverzoek niet door te voeren.

johannesbattjes commented 3 years ago

Een ander aspect is dat zelfs als StUF wordt aangepast samengesteld document nog geen deel uit maakt van Zaak- en Documentservices (ZSDMS). Er ontstaat dan de onduidelijke en onwenselijke situatie dat het in StUF wel mogelijk is maar in de Zaak- en Documentservicesstandaard niet. Dit betekent opnieuw maatwerkafspraken tussen leveranciers op basis van 'half fabrikaat' StUF in plaats van duidelijk omschreven functies en methodes in ZSDMS. Daarnaast zijn wij nu volop bezig met DSO en ZGW-API's, het is voor ons niet mogelijk nu een een dergelijk grote wijziging in de deze (StUF en ZSDMS) standaarden te implementeren. Ik ben het dus eens met Michiel dit onderhoudsverzoek niet door te voeren.

michielverhoef commented 3 years ago

Op basis van de reacties op dit onderhoudsverzoek hebben we besloten deze wijziging niet door te voeren.

Ondanks dat het een duidelijke fout in het sectormodel StUF ZKN 3.10 betreft is nog niet eerder door gemeenten of leveranciers aangegeven dat dit problemen veroorzaakt. De behoefte is dus niet groot genoeg geweest of het probleem is anders opgelost. Deze wijziging zou vergaande gevolgen hebben voor applicaties die StUF ZKN en/of Zaak- Documentservices in een providerrol ondersteunen, het is zou immers mogelijk zijn dat een consumer deze nieuwe versie van de standaarden gebruikt.

StUF 3.01 en de op StUF 3.01 gebaseerde koppelvlakken worden niet verder doorontwikkeld. Een dergelijke wijziging kan echter alleen in het koppelvlak Zaak- Documentservices opgenomen worden door een nieuwe versie van die standaard uit te brengen. Een versie die weer ingebouwd en geimplementeerd moet worden. Dit staat haaks op de wens om aan te sluiten bij het Gegevenslandschap en Common Ground via de nieuwe API standaarden en brengt onnodige kosten en investeringen met zich mee. Investeringen die niet terug te verdienen zijn en beter besteed kunnen worden aan een snellere adoptie van de nieuwe API standaarden.

Om zeker te zijn dat de nieuwe API standaarden wel het gebruik van documenten met bijlagen ondersteunen is een userstory aangemaakt: https://github.com/VNG-Realisatie/gemma-zaken/issues/1695 .