JOIN Zaak en Document is middels het koppelvlak Zaak- en Documentservices in staat om zaak- en document-informatie uit te wisselen met aangesloten applicaties. In de meeste gevallen gaat dit om een procesapplicatie in de backoffice. Denk hierbij aan bijvoorbeeld vergunningen- of WMO-applicaties.
Het koppelvlak is een implementatie van de Zaak- en Documentservices zoals gespecificeerd door VNG-Realisatie.
De functionaliteit van dit koppelvlak is beschreven op deze pagina
Decos biedt voor het uitwisselen van deze gegevens een berichtenservice op basis van de koppelvlakspecificatie ‘Zaak- en documentservices’ versie 1.1, zoals gespecificeerd door KING (zie documentatiereferentie II). Dit koppelvlak wordt in de praktijk aangeduid met de afkorting ‘zs-dms’.
Voor aanvullende functionaliteit op dit koppelvlak biedt Decos ondersteuning voor diverse berichten uit de StUF-ZKN standaard versie 3.10, door KING vastgesteld in 2010 (zie documentatiereferentie I). Deze berichten worden in dit document aangeduid met ‘reguliere’ StUF-Zaken berichten. Beide functionaliteiten (zs-dms en regulier StUF-ZKN) zijn onderdeel van de JOIN StUF-ZKN integratie.
Samengevat bestaan er 3 soorten berichten:
De JOIN StUF-ZKN integratie biedt asynchrone en synchrone berichtenservices. Het belangrijkste verschil tussen beide varianten is het moment van terugkoppeling (respons).
Een asynchrone berichtenservice geeft over het algemeen een betere performance vanwege de snelle bevestiging en is geschikt voor verzoeken waarbij een eindgebruiker niet hoeft te wachten op de verwerking van het verzoek.
Een synchrone berichtenservice geeft minder snel een respons doordat het verzoek eerst verwerkt moet worden. Dit type verzoek is geschikt als de eindgebruiker of de applicatie het resultaat van het verzoek nodig heeft voordat het proces gecontinueerd kan worden.
Voor al het verkeer in de richting van JOIN Zaak & Document vanuit een backoffice applicatie (hoofdstukken 2 t/m 6) worden de berichten uit de Zaak- en Documentservices aangeraden. Deze services bieden een berichten-set van asynchrone en synchrone berichten die afgestemd is op het koppelen met een backoffice applicatie.
Verkeer van JOIN Zaak & Document in de richting van een backoffice applicatie (hoofdstuk 7) wordt niet gespecificeerd in de Zaak- en Documentservices. Hiervoor worden reguliere asynchrone StUF-ZKN berichten aangeraden.
Reguliere synchrone StUF-ZKN berichten worden in zijn geheel niet aangeraden voor communicatie met een backoffice applicatie. Er zijn toepassingen, zoals bijvoorbeeld een scanoplossing waarvoor deze vorm van berichtgeving van praktisch nut kunnen zijn. In de hoofdstukken 2 t/m 6 wordt wel aangegeven met welk synchroon bericht het desbetreffende scenario uitgevoerd kan worden.
Deze autorisatie gaat op basis van de StUF-zender gegevens, waarbij de organisatienaam en de applicatienaam overeen moeten komen met de instellingen in de StUF-ZKN integratie. Tijdens de aansluitfase worden deze gegevens afgestemd tussen Decos en derde partij.
Deze applicatienaam wordt in JOIN Zaak & Document tevens geregistreerd bij één of meerdere zaaktypen d.m.v. het toevoegen en koppelen van z.g. externe applicaties in Zaaktypen.nl. Dit is door de applicatiebeheerder van JOIN Zaak & Document zelfstandig te configureren en kan dus tijdens het gebruik van de StUF-ZKN integratie wijzigen zonder tussenkomst van Decos.
Na deze instellingen is het mogelijk voor deze partij om zaken van deze zaaktype(n) toe te voegen aan JOIN Zaak & Document. Deze instellingen gelden meteen voor alle inkomende berichten van deze partij.
Het mogen toevoegen van een zaak in Decos hoeft niet te betekenen dat deze applicatie ook afnemer is van zaken of deze zaken ook behandelt. De afnemende/behandelende applicatie van de zaak is ook in te stellen in Zaaktypen.nl. Hierover meer in hoofdstuk 7.
De StUF-ZKN integratie van JOIN Zaak & Document biedt de mogelijkheid om StUF-ZKN berichten te ontvangen van derde applicaties over nieuwe zaken die toegevoegd worden aan het zakenmagazijn van JOIN Zaak & Document. Dit hoofdstuk beschrijft de functionaliteiten en de mogelijke berichten. Kijk in hoofdstuk 8 voor informatie over de gegevens die uitgewisseld (kunnen) worden in dit scenario.
Wanneer de services, die de StUF-ZKN integratie ondersteunt voor het toevoegen van zaken, een bericht ontvangen zal verwerking er van de volgende stappen doorlopen.
Allereerst wordt gecontroleerd of de zendende applicatie op basis van de stuurgegevens bekend is bij de integratie. Indien de applicatie niet bekend is volgt een fout-respons. Daarna wordt gecontroleerd of de zendende applicatie toegang heeft tot het in het bericht aangegeven zaaktype. Indien de zendende applicatie geen toegang heeft volgt een interne verwerkingsfout of een fout-respons, afhankelijk van de gebruikte berichtenservice. Indien de zendende applicatie toegang heeft tot het aangegeven zaaktype wordt de nieuwe zaak onder dit zaaktype geregistreerd.
De Zaakidentificatie bestaat uit een tekstwaarde van 40 karakters. De identificatie is een globaal unieke code en dient als communicatiemiddel in de interne StUF-berichten over de betreffende zaak. Een zaak heeft ook een kenmerk en is het leesbare zaaknummer dat in de communicatie met de burger en de medewerkers gebruikt wordt. Het zaak-kenmerk wordt verzonden in de uitgaande berichten van Decos, beschreven in hoofdstuk 7.
De StUF-ZKN integratie genereert standaard de globaal unieke code voor het ‘genereerZaakIdentificatie_Du02’ antwoordbericht. Het is echter ook mogelijk om een werkelijke zaakreservering te maken in het zaaksysteem waarbij het zaak-kenmerk als identificatie in het ‘genereerZaakIdentificatie_Du02’ antwoordbericht kan worden teruggegeven. Dit kan praktisch zijn voor applicaties die het onderscheid tussen een zaak-identificatie en zaak-kenmerk niet kennen.
De zaaktypecode is een unieke code die hoort bij het zaaktype zoals die in Zaaktypen.nl en JOIN Zaak & Document beschikbaar is. Deze zaaktypecode dient in beide applicaties bekend te zijn en overeen te komen.
De integratie zal, op basis van de gegevens over burgers en/of organisaties in de zaak-toevoeging, proberen een koppeling te maken met het desbetreffende gegevens uit de basisgegevens-bron, gebruikmakend van de StUF-BG-integratie middels een externe collectie. Wanneer dit onsuccesvol is, zal de integratie proberen het gegeven proberen te koppelen vanuit een interne collectie in JOIN Zaak & Document. Indien dit gegeven ook in deze collectie niet kan worden gevonden, zal de integratie zelf een adresregistratie aanmaken in de interne collectie, gebruikmakend van de gegevens uit het zaak-toevoegingsbericht (zie hiervoor hoofdstuk 10 - Gegevens Adressen).
De integratie zal, op basis van de gegevens over locaties in de zaak-toevoeging, proberen een koppeling te maken met het desbetreffende gegeven uit de bron voor BAG-locaties.
Naast de berichten uit de Zaak- en documentservices voor het toevoegen van zaken aan het zakenmagazijn biedt de integratie ook een synchrone (zakLk02) service op basis van reguliere StUF-ZKN berichten. Het gebruik van deze services wordt afgeraden sinds de introductie van de Zaak- en documentservices.
Voordat een zaak aan JOIN Zaak & Document kan worden aangeboden dient er eerst een zaakidentificatie opgevraagd te worden bij het zakenmagazijn middels het ‘genereerZaakIdentificatie_Di02’ bericht. Het ‘genereerZaakIdentificatie_Du02’ antwoord bevat de identificatie van de zaak.
Daarna zal de verwerking van het ‘creeerZaak_Lk01’ bericht leiden tot het registreren van alle zaakgegevens.
Bericht | Antwoord | Fout | |
---|---|---|---|
1 | genereerZaakIdentificatie_Di02 | genereerZaakIdentificatie_Du02 | Fo02Bericht |
2 | creeerZaak_Lk01 | Bv03Bericht | Fo03Bericht |
Bij gebruik van regulier synchroon StUF-ZKN berichtenverkeer hoeft er niet eerst een identificatie gegenereerd te worden. Het ‘zakLk02’ bericht kan zonder identificatie aangeboden worden. Indien de zaak succesvol is geregistreerd, volgt een ‘Bv02Bericht’ respons met de door het systeem gegenereerde zaakidentificatie en het zaak-kenmerk bevat.
Bericht | Antwoord | Fout | |
---|---|---|---|
1 | zakLk02 | Bv02Bericht | Fo02Bericht |
2 | creeerZaak_Lk01 | Bv03Bericht | Fo03Bericht |
Decos ondersteunt het ontvangen en verwerken van wijzigingsberichten op zaken. Dit zijn ‘zak’ berichten met mutatiesoort W (wijziging). Dit hoofdstuk beschrijft de functionaliteiten en de mogelijke berichten. Kijk in hoofdstuk 8 voor een compleet overzicht van alle gegevens die uitgewisseld (kunnen) worden in dit scenario.
Wanneer de services die de StUF-ZKN integratie ondersteund voor wijzigingen op zaken een bericht ontvangen zal verwerking er van de volgende stappen doorlopen.
Allereerst wordt gecontroleerd of de zendende applicatie op basis van de stuurgegevens bekend is bij de integratie. Indien de applicatie niet bekend is volgt een fout-respons. Indien de applicatie bekend is wordt de zaak opgezocht in het zaaksysteem op basis van de zaakidentificatie. Daarna wordt gecontroleerd of de zendende applicatie toegang heeft tot het aan deze zaak gekoppelde zaaktype. Indien de zendende applicatie geen toegang heeft volgt een interne verwerkingsfout of een fout-respons, afhankelijk van de gebruikte berichtenservice. Indien de zendende applicatie toegang heeft tot het gekoppelde zaaktype wordt gecontroleerd of de zaak is afgehandeld. Indien de zaak is afgehandeld, volgt een interne verwerkingsfout of een fout-respons, afhankelijk van de gebruikte berichtenservice. Indien de zaak nog niet is afgehandeld, wordt de wijziging uit het bericht doorgevoerd.
Zodra er een einddatum ingevuld is, wordt de zaak in JOIN Zaak & Document afgesloten. Het is daarna niet meer mogelijk om wijzigingen door te voeren van deze zaak.
Zodra er een resultaat wordt ingevoerd wordt de einddatum automatisch gevuld. Bij een resultaat wordt verwacht dat de zaak is afgesloten.
Het is mogelijk om de zaak te heropenen vanuit een bericht. Hierbij moet een wijzigingsbericht gestuurd worden waarbij de einddatum expliciet leeg wordt gemaakt. Daarna is het weer mogelijk om andere wijzigingen te sturen.
Het later aanpassen van een zaaktypecode wordt niet door JOIN Zaak & Document ondersteund. Op basis van een zaaktype worden er werkprocessen gestart en worden er doorlooptijden berekend. De consequenties van het aanpassen van een zaaktype zijn niet te voorspellen en wordt daardoor niet ondersteund. Wanneer het zaaktype niet correct wordt aangeleverd aan JOIN Zaak & Document, omdat het bijvoorbeeld een verkeerd zaaktype bevat, zal de zaak handmatig moeten worden afgehandeld. De status wordt hiermee op ‘afgehandeld’ gezet en het resultaat op ‘vervallen’. Vervolgens dient er een nieuwe zaak aangemaakt te worden met het juiste zaaktype.
Het verwijderen van zaken, berichten met mutatiesoort V (verwijderen) richting Decos wordt niet ondersteund. Het is bij een verwijderbericht niet bekend welke consequenties dit heeft voor de lopende aanvraag en dient altijd via een handmatig proces uitgevoerd te worden. (in beide applicaties moet de zaak verwijderd worden, wanneer dit echt niet anders kan).
Een alternatief voor het verwijderen van zaken is de status op ‘afgehandeld’ te zetten en het resultaat op ‘vervallen’ met eventueel een toelichting waarom de zaak is verwijderd.
De functionaliteit voor het koppelen- en aanmaken van adresregistraties bij zaak-wijzigingen is hetzelfde als voor toevoegingen (zie hiervoor 2.1.3 - Koppelen/ aanmaken adresregistraties). Bestaande adreskoppelingen worden hierbij altijd intact gelaten.
De integratie zal, op basis van de gegevens over locaties in de zaak-wijzigingen, proberen een koppeling te maken met het desbetreffende gegeven uit de bron voor BAG-locaties. Bestaande BAG-locatie-koppelingen worden hierbij altijd intact gelaten.
De zaak- en documentservices kent twee berichten voor het bijwerken van zaakgegevens; Een bericht specifiek voor het bijwerken van de zaakstatus (actualiseerZaakstatus_Lk01) en een bericht voor het bijwerken van overige zaakgegevens (updateZaak_Lk01). In de praktijk komt het vaak voor dat een aangesloten applicatie de zaakstatus ook doorgeeft middels het ‘updateZaak_Lk01’ bericht.
Bericht | Antwoord | Fout | |
---|---|---|---|
1 | actualiseerZaakstatus_Lk01 | Bv03Bericht | Fo03Bericht |
Bericht | Antwoord | Fout | |
---|---|---|---|
1 | updateZaak_Lk01 | Bv03Bericht | Fo03Bericht |
Bericht | Antwoord | Fout | |
---|---|---|---|
1 | zakLk02 | Bv02Bericht | Fo02Bericht |
Indien de wijziging op de zaak succesvol is doorgevoerd, volgt een ‘Bv02Bericht’. Dit bericht bevat standaard de volgende gegevens:
Zaakidentificatie
Zaak-kenmerk
Decos ondersteunt het ontvangen van zogenaamde ‘edc’ berichten (Enkelvoudig Document) over nieuwe documenten die bij een zaak geregistreerd kunnen worden. Dit zijn berichten met mutatiesoort T (toevoeging). Kijk in hoofdstuk 9 voor een compleet overzicht van alle gegevens die uitgewisseld (kunnen) worden in dit scenario
Een document toevoeging bevat een verplichte referentie naar de zaak waaraan het document moet worden toegevoegd. Bij het ontvangen van documentbericht zal eerst de bijbehorende zaak opgezocht worden. Daarna wordt gecontroleerd of de zendende applicatie toegang heeft tot het aan deze zaak gekoppelde zaaktype. Indien de zendende applicatie geen toegang heeft tot het gekoppelde zaaktype volgt een interne verwerkingsfout of een fout-respons, afhankelijk van de gebruikte berichtenservice.
Indien de zendende applicatie toegang heeft tot de gekoppelde zaak wordt het document aan deze zaak toegevoegd.
De DocumentIdentificatie bestaat uit een tekstveld van 40 karakters. De identificatie is een unieke code en dient als communicatiemiddel in de interne StUF-berichten over het betreffende document. Een document heeft ook een Decos kenmerk en is het leesbare documentnummer dat in de communicatie met de burger en de medewerkers gebruikt wordt. Het Decos kenmerk wordt verzonden in de uitgaande berichten van Decos, beschreven in hoofdstuk 7.
Het is mogelijk om documentgegevens vooraf op te vragen bij Decos, voordat het fysieke bestand wordt toegevoegd in de node ‘inhoud’. Hiervoor kan een ‘voegZaakdocumentToe_Lk01’ bericht (met identificatie) of een edcLk02 bericht (evt. zonder identificatie) worden gestuurd aan Decos. Op basis van de gerelateerde zaak en het documenttype (dct.omschrijving) wordt alvast een documentregistratie aangemaakt in Decos. Op basis van de mutatieberichten uit JOIN Zaak & Document (zie hoofdstuk 7) worden de extra kenmerken als Documentkenmerk en barcode verstrekt en kan later met een wijzigingsbericht de inhoud van het document worden toegevoegd aan Decos.
Binnen de standaard Zaak- en documentservices is gespecificeerd dat een zendende applicatie eerst een document identificatie opvraagt bij het zaaksysteem middels het ‘genereerDocumentIdentificatie_Di02’ bericht. Het ‘genereerDocumentIdentificatie_Du02’ antwoord bevat de gegenereerde identificatie van het document.
Bericht | Antwoord | Fout | |
---|---|---|---|
1 | genereerDocumentIdentificatie_Di02 | genereerDocumentIdentificatie_Di02 | Fo02Bericht |
2 | voegZaakdocumentToe_Lk01 | Bv03Bericht | Fo03Bericht |
Synchroon
Er kan ook gebruik gemaakt worden van regulier synchroon StUF ZKN bericht om een document toe te voegen. Op basis van het edcLk02 bericht volgt een ‘Fo02bericht’ met een foutmelding of een ‘Bv02Bericht’ met een bevestiging van de registratie van het document in JOIN Zaak & Document. In het Bv02Bericht wordt o.a. direct de EDC.identificatie gestuurd. In deze synchrone service is het niet verplicht om eerst een documentidentificatie bij Decos op te vragen, zoals bij de Zaak- en documentservices.
Bericht | Antwoord | Fout | |
---|---|---|---|
1 | edcLk02 | Bv02Bericht | Fo02Bericht |
De response van het Bv02Bericht bevat standaard de volgende gegevens:
Document identificatie
Document kenmerk
Document Decos barcode
Daarna wordt het daadwerkelijke document aangeboden middels het ‘voegZaakdocumentToe_Lk01’ bericht.
Decos ondersteunt het ontvangen en verwerken van wijzigingsberichten op documenten. Dit zijn ‘edc’ berichten met mutatiesoort W (wijziging).
Een document-wijzigingsbericht bevat altijd het verplichte element documentidentificatie. A.d.h.v. de documentidentificatie wordt eerst de gekoppelde zaak opgezocht. Daarna wordt gecontroleerd of de zendende applicatie toegang heeft tot het aan deze zaak gekoppelde zaaktype en of deze applicatie dus geautoriseerd is om de documentaanpassing door te voeren. Indien de zendende applicatie geen toegang heeft tot het gekoppelde zaaktype volgt een interne verwerkingsfout of een fout-respons, afhankelijk van de gebruikte berichtenservice.
Indien de zendende applicatie toegang heeft wordt de documentwijziging doorgevoerd.
De aangesloten applicatie kan op verschillende manieren een documentwijziging doorvoeren. De zaak- en documentservices beschrijven twee methodes voor het wijzigen van document-metadata of document-inhoud. Daarnaast is het mogelijk om de wijziging middels een regulier synchroon StUF-ZKN bericht door te voeren. Als laatste bestaat er de mogelijkheid tot het direct openen van de documentregistratie in JOIN Zaak & Document middels een link naar de registratie.
Middels deze services is de aangesloten applicatie in staat een documentregistratie in JOIN Zaak & Document uit te checken. Het document wordt hierbij in JOIN Zaak & Document uitgecheckt door een bij de aansluiting behorende systeemgebruiker. Daarna kan het document weer worden ingecheckt met aanpassingen of het de check-out kan worden geannuleerd.
De aangesloten Zs-DMS applicatie kan ook direct een document-update doorvoeren zonder het document eerst uit te checken. Dit kan alleen als de applicatie zelf een kopie heeft bijgehouden van het document.
Middels de synchrone webservice kan ook direct een documentupdate worden gestuurd.
De aangesloten applicatie kan een bestand ook openen middels een directe link naar de bestandsregistratie achter de documentregistratie in JOIN Zaak & Document. Deze link kan worden verkregen middels vraag-antwoordberichten (zie hoofdstuk 6). Het document wordt dan via de JOIN Client componenten geopend. Bewerkingen aan het document worden middels deze componenten teruggeschreven naar JOIN Zaak & Document. Deze functionaliteit valt buiten de scope van de StUF-ZKN integratie.
i Voor het openen van het document direct uit JOIN Zaak & Document zijn de Decos Document Control componenten nodig op de werkplek van de gebruiker en heeft de gebruiker ook Decos bewerk-rechten op dit document nodig. Daarnaast dient JOIN Zaak & Document bereikbaar te zijn vanaf de werkplek van de gebruiker.
De JOIN StUF-ZKN integratie ondersteunt geen verwijderberichten voor documenten. De Zaak- en documentservices bevatten geen berichtenspecificatie voor een verwijderbericht. De berichtenservices voor reguliere asynchrone en synchrone documentberichten regeren met een fout-respons op ‘edc’ kennisgevingen van mutatiesoort ‘V’.
De zaak- en documentservices kent twee methoden voor het wijzigen van een document:
Bericht | Antwoord | Fout | |
---|---|---|---|
1 | geefZaakdocumentbewerken_Di02 | geefZaakdocumentbewerken_Du02 | Fo02Bericht |
2a | updateZaakdocument_Di02 | Bv02Bericht | Fo02Bericht |
2b | cancelCheckout_Di02 | Bv02Bericht | Fo02Bericht |
Bericht | Antwoord | Fout | |
---|---|---|---|
1 | updateZaakdocument_Di02 | Bv02Bericht | Fo02Bericht |
Bericht | Antwoord | Fout | |
---|---|---|---|
1 | edcLk02 | Bv02Bericht | Fo02Bericht |
Decos biedt een BeantwoordVraag service, hiermee is het mogelijk om een vraag te stellen aan JOIN Zaak & Document met als doel de details op te vragen van een specifieke zaak en/of document. De Zaak- of documentidentificatie kan worden verkregen door gebruik te maken van de toevoegingsberichten van zaken die eerder zijn verstuurd (zie hoofdstuk 2).
Deze service maakt het mogelijk om informatie over een zaak op te vragen, op basis van de zaakidentificatie. De zaakidentificatie is eerder verkregen bij het toevoegen van de zaak zelf. Of door het ontvangen en verwerken van een notificatie over een nieuwe zaak van JOIN Zaak & Document.
Het antwoord van een zaakvraag bevat kan de status en andere zaakdetails van een bepaalde zaak terug geven (geefZaakstatus_Lv01 en geefZaakdetails_Lv01). Daarnaast is het mogelijk om een lijst van gekoppelde zaakdocumenten op te vragen (geefLijstZaakdocumenten_Lv01). De documentidentificaties van deze documenten worden in het antwoordbericht getoond. Deze identificaties kunnen vervolgens gebruikt worden om per document de bestandsinhoud op te halen.
In JOIN Zaak & Document is het mogelijk om meerdere bestanden bij één documentregistratie op te slaan. In deze service wordt hier rekening mee gehouden. De documentidentificaties die worden teruggegeven zijn de unieke gegevens van elk bestand in deze registratie. De meta-gegevens die worden verstrekt op basis van de vraag zijn samengesteld uit de document- en de bestandsregistratie.
Daarnaast is het, buiten de StUF-Zaken standaard om, mogelijk om via een hyperlink naar JOIN Zaak & Document direct naar de juiste zaak te gaan en Decos te starten met deze zaak als beginscherm. Op deze manier kan een gebruiker ook de lijst met documenten inzien, zoals deze in Decos zijn vastgelegd. Om deze hyperlink te kunnen gebruiken naar een zaak moet er binnen JOIN Zaak & Document aanvullende (deeplink) functionaliteit gerealiseerd worden.
Voor StUF-ZKN gelden de volgende limieten:
1.Aan een zaak mogen maximaal 250 documenten worden gekoppeld. We raden ten zeerste aan om grote dossiers te splitsen in hoofd- en deelzaken
2.Aan een zaakdocument mogen maximaal 100 bestanden worden gekoppeld. We raden ten zeerste aan om deze limieten niet op te zoeken, ook om de gebruiksvriendelijkheid van het zaaksysteem niet te compromiteren
3.Ieder uniek bestand dat aan een zaakdocument is gekoppeld mag niet groter zijn dan 500 mb.
Deze service maakt het mogelijk om een vraag te stellen aan JOIN Zaak & Document met als doel de details en de inhoud op te vragen van een document om deze in te zien. Binnen deze service wordt maar één bericht ondersteund: geefZaakdocumentLezen_Lv01. De documentidentificatie, benodigd in dit bericht, kan worden verkregen door één van de identificaties te gebruiken uit het antwoord op het bericht ‘geefLijstZaakdocumenten_Lv01’, beschreven in de vorige paragraaf.
Dit bericht geeft de metagegevens, de hyperlink en de bestandsinhoud terug van het document met de betreffende documentidentificatie.
Wanneer het de bedoeling is een document te openen om deze vervolgens aan te passen dient dit document opgevraagd te worden met het bericht ‘geefZaakdocumentbewerken_Di02’ (zie hoofdstuk 5 - Document wijzigen).
De vraagberichten zoals gespecificeerd in de zaak- en documentservices bieden voldoende functionaliteit voor elke aangesloten backoffice applicatie. Het gebruik van reguliere StUF-ZKN vraagberichten i.c.m. backoffice applicaties wordt daarom niet meer beschreven in dit document.
Er bestaan binnen de zaak- en documentservices verschillende berichten voor het opvragen van informatie uit JOIN Zaak & Document:
Opvragen zaakstatus
Bericht | Antwoord | Fout | |
---|---|---|---|
1 | [geefZaakstatus_Lv01] | zakLa01 | Fo02Bericht |
Opvragen zaakdetails
Bericht | Antwoord | Fout | |
---|---|---|---|
1 | [geefZaakdetails_Lv01] | zakLa01 | Fo02Bericht |
Opvragen lijst gekoppelde zaakdocumenten
Bericht | Antwoord | Fout | |
---|---|---|---|
1 | [geefLijstZaakdocumenten_Lv01] | zakLa01 | Fo02Bericht |
Opvragen zaakdocument
Bericht | Antwoord | Fout | |
---|---|---|---|
1 | [geefZaakdocumentLezen_Lv01] | edcLa01 | Fo02Bericht |
Vanuit JOIN Zaak & Document kunnen notificaties (kennisgevingen) over zaken en documenten worden verzonden naar afnemers. Deze afnemers kunnen zowel backoffice als frontoffice leveranciers zijn.
De gegevens die in deze berichten worden verzonden over een zaak en een document zijn beschreven in hoofdstukken 8 en 9.
In JOIN Zaak & Document kan worden aangegeven welke zaken (van welk zaaktype) verstuurd moeten worden naar een backoffice applicatie. Een backoffice applicatie heeft een abonnement op zaken van een bepaald zaaktype.
Standaard worden alle mutaties in zaken en documenten van deze zaaktypen actief verstuurd naar de aangesloten backoffice applicatie. Het is in te stellen dat mutaties die vanuit de aangesloten applicatie zélf komen, niet worden opnieuw worden verstuurd aan deze zelfde applicatie. Tijdens de configuratie van de koppeling wordt dit besproken en ingericht.
Op basis van de functionaliteiten die een backoffice bezit kunnen deze berichten opgeslagen worden of ter kennisname worden aangenomen. Het is ook mogelijk om n.a.v. deze notificaties zaak- en document informatie te bevragen bij Decos en op deze manier de actuele status te ontvangen. Zie hiervoor hoofdstuk 620.
Een zaakbericht wordt verstuurd zodra aan de volgende voorwaarden wordt voldaan:
De berichten kunnen synchroon of asynchroon aangeboden worden en verwacht dus van de backoffice een StUF-Zaken ontvangststation voor zakLk01 en edcLk01 of zakLk02 en edcLk02 berichten. (Deze services zijn niet beschreven in de standaard voor Zaak- en Documentservices). Het gebruik van synchrone uitgaande kennisgevingen wordt vrijwel niet in de praktijk gebruikt. Vrijwel alle afnemende aangesloten applicaties ondersteunen de ontvangst van asynchrone kennisgevingen.
Toevoegingen van- en wijzigingen op zaken of documenten
De StUF-ZKN integratie houdt bij welke zaken verstuurd zijn naar welke applicatie en of de applicatie dit bericht correct heeft verwerkt. Een bericht over een zaak die nog niet eerder is verstuurd naar een backoffice is een Toevoegingsbericht (verwerkingssoort T). Iedere wijziging die daarna wordt aangebracht op de zaak is een wijziging op deze zaak (verwerkingssoort W). Voor documenten geldt hetzelfde principe. Niet elke aangesloten applicatie verwerkt de door JOIN Zaak & Document verstuurde berichten. De applicatie dient echter wel elke verzonden asynchrone notificatie te bevestigen met een ‘Bv03Bericht’ respons.
Verwijderen van zaken of documenten
Wanneer een zaak of document wordt verwijderd uit JOIN Zaak & Document wordt er een verwijderbericht naar de afnemer gestuurd. Het is aan de afnemer te bepalen hoe hiermee wordt omgegaan. Niet elke aangesloten applicatie verwerkt de door JOIN Zaak & Document verstuurde berichten. De applicatie dient echter wel elke verzonden asynchrone notificatie te bevestigen met een ‘Bv03Bericht’ respons.
Uitgaande berichten filteren op bron
Standaard wordt elke mutatie op een zaak of document ter kennisgeving aangeboden aan het afnemende systeem. Ditzelfde systeem kan echter ook de initiator zijn van de mutatie. Hierdoor kan een zogenaamde ‘loop’ van berichten ontstaan. Het is mogelijk om berichten te filteren in de uitgaande berichtenstroom. Met deze instellingen wordt ervoor gezorgd dat sommige bronnen (de backoffice zelf, een OLO bericht etc.) niet leiden tot een toevoegings- of wijzigingsbericht naar een backoffice.
Zaak kennisgeving
Bericht | Antwoord | Fout | |
---|---|---|---|
1 | zakLk01 | Bv03Bericht | Fo03Bericht |
Bericht | Antwoord | Fout | |
---|---|---|---|
1 | edcLk01 | Bv03Bericht | Fo03Bericht |
De berichten die worden verstuurd omtrent nieuwe of gewijzigde documenten worden verstuurd volgens de gegevens die vermeldt staan in hoofdstuk 9. Het veld ‘inhoud’ zal echter niet gevuld zijn, maar het veld ‘link’ en de ‘identificatie’ wel. Met behulp van deze gegevens kan de documentinhoud middels de services uit hoofdstuk 6 opgevraagd worden. Daarnaast kan het document direct geopend worden uit JOIN Zaak & Document door het aanroepen van de hyperlink uit het ‘link’ veld.
i Voor het openen van het document direct uit JOIN Zaak & Document zijn de Decos Document Control componenten nodig op de werkplek van de gebruiker en heeft de gebruiker ook Decos bewerk-rechten op dit document nodig. Daarnaast dient JOIN Zaak & Document bereikbaar te zijn vanaf de werkplek van de gebruiker.
Dit hoofdstuk beschrijft alle gegevens die in inkomende en uitgaande berichten op zaakniveau worden uitgewisseld. In de eerste paragraaf worden de gegevens vanuit het bericht opgesomd. In de opvolgende paragraven wordt vanuit de beschikbare velden in JOIN Zaak & Document meer uitleg gegeven over de verwerking van de gegevens.
Veldomschrijving | Opmerking | V/O |
---|---|---|
identificatie | Unieke identificatie van de zaak zoals deze in JOIN Zaak & Document is geregistreerd | v * |
omschrijving | Beschrijving van de zaak | v |
toelichting | Toelichting op de zaakomschrijving | o |
Kenmerk | Referentiecode vanuit andere applicatie | o |
Bron | Applicatienaam van de zender | o |
Zaakniveau | Geeft aan of dit een hoofdzaak of deelzaak is | o |
Deelzakenindicatie | Geeft aan of deze zaak een deelzaak is van een andere zaak | o |
Isvan ZAKZKT omschrijving code | Relatie met het zaaktype Zaaktype omschrijving Zaaktypecode | v * |
Startdatum | Datum waarop de zaak gestart wordt | v |
Einddatum | Einddatum van de zaak (optioneel, bij aanvang leeg) | o |
Registratiedatum | Datum waarop de zaak is geregistreerd | v |
EinddatumGepland | Datum waarop de zaak gepland staat om te eindigen (mag leeggelaten worden) | o |
UiterlijkeEinddatum | Datum waarop de zaak uiterlijk afgehandeld dient te zijn volgens de wettelijke termijn (mag leeggelaten worden) | o |
Resultaat.omschrijving | Omschrijving van het resultaat van de zaak (bij aanvang leeg) | o |
Resultaat.toelichting | Eventuele toelichting bij het resultaat (optioneel, bij aanvang leeg) | o |
ZAKSTT.volgnummer | Status van de zaak | O |
ZAKSTT.omschrijving | Status van de zaak | O |
ZAKSTT.datumstatusgezet | Datum waarop de status is gezet | O |
Heeft betrekking op ZAKOBJ | Relatie met een zaakobject | O |
Adresseerbaar Object aanduiding AOA | Binnen de relatie met een object kan een adres toegevoegd worden. In Decos wordt dit adres vervolgens als tekstveld opgeslagen in het daarvoor bestemde locatieveld. Wanneer u beschikt over een BAG koppeling, wordt ook het authentieke object gekoppeld. | O |
Openbare Ruimte OPR | Binnen de relatie met een object kan een openbare ruimte toegevoegd. In Decos wordt deze openbare ruimte vervolgens als tekstveld opgeslagen in het daarvoor bestemde locatieveld. | O |
heeft als Initiator ZAKBRTINI | Relatie met de initiator van de zaak – de aanvrager | V |
heeft als Gemachtigde ZAKBRTGMC | Relatie met de gemachtigde van de zaak | o |
heeft als Belanghebbende ZAKBRTBLH | Relatie met de belanghebbende van de zaak | o |
heeft als overig betrokkenen ZAKBRTOVR | Relatie met overig betrokkenen van de zaak | o |
Natuurlijke persoon NPS.inp.bsn | Gegevens over de relatie – een BSN volstaat De volgende velden van een Natuurlijk Persoon worden opgeslagen in het zakenmagazijn wanneer het niet mogelijk is om de relatie met een burger uit het gegevensmagazijn te maken. GeslachtsNaam VoorVoegselGeslachtsNaam Voorletters Voornamen GeslachtsAanduiding Verblijfsadresgegevens WoonPlaatsnaam Straatnaam Postcode HuisNummer HuisLetter HuisNummerToevoeging | - |
Niet natuurlijk persoon NNP.inn.nnpId | Gegevens over de relatie – een KvK volstaat De volgende velden van een Niet natuurlijk Persoon worden opgeslagen in het zakenmagazijn wanneer het niet mogelijk is om de relatie met een organisatie uit het gegevensmagazijn te maken. Statutairenaam Bezoekadres Woonplaatsnaam Straatnaam Postcode HuisNummer HuisLetter HuisnummerToevoeging | - |
Vestiging VES.vestigingsnummer | Gegevens over de relatie – een vestigingsnummer volstaat De volgende velden van een vestiging worden opgeslagen in het zakenmagazijn wanneer het niet mogelijk is om de relatie met een organisatie uit het gegevensmagazijn te maken. Handelsnaam Bezoekadres Woonplaatsnaam Straatnaam Postcode HuisNummer HuisLetter HuisnummerToevoeging | - |
Heeft als uitvoerder ZAKBRTUTV | Relatie met de uitvoerder van de zaak – medewerker of organisatorische eenheid | o |
Heeft als verantwoordelijke ZAKBTRVRA | Relatie met de verantwoordelijke van de zaak – medewerker of organisatorische eenheid | o |
Medewerker MDW | Gegevens van de medewerker die de zaak behandelt. De volgende velden worden verwerkt: Identificatie Voorletters Voorvoegsel achternaam Achternaam | - |
Organisatorische eenheid OEH | Gegevens van de organisatorische eenheid die de zaak behandelt. De volgende velden worden verwerkt: Identificatie Naam | - |
Heeft als deelzaak ZAKZAKDEL | Relatie met één of meerdere deelzaken | o |
ZAK.identificatie | Hier worden de identificaties van de deelzaken bij deze zaak gevuld. | o |
JZD Veld | Intern veld | Connect property | StUF |
---|---|---|---|
Zaak identificatie | ExternalId | identificatie | |
Zaak kenmerk | MARK | [Uniek veld] | kenmerk/kenmerk |
Omschrijving zaak | SUBJECT1 | Description | omschrijving |
Startdatum zaak | DOCUMENT_DATE | StartDate | startdatum |
Zaak afgehandeld | PROCESSED | IsProcessed | - |
Datum afhandeling | DATE5 | EndDate | einddatum |
Datum registratie | DateCreated | registratiedatum |
De zaakidentificatie wordt binnen de integratie gebruikt om een zaak uniek te kunnen identificeren. Dit gegeven is niet zichtbaar in de gebruikersinterface van JOIN Zaak & Document.
De aangesloten applicatie kan een identificatie genereren m.b.v. de ‘genereerZaakIdentificatie_Di02’ service.
Het zaak kenmerk kan niet door een aangesloten applicatie geschreven worden. De waarde van dit veld wordt in het berichtenverkeer als volgt gebruikt:
<ZKN:kenmerk> <ZKN:kenmerk>[Zaak kenmerk]</ZKN:kenmerk> <ZKN:bron>[Instelling ‘Standaard bron’]</ZKN:bron> </ZKN:kenmerk>
Indien de instelling ‘Gebruik zaak-kenmerk als zaakidentificatie’ ingeschakeld is wordt de waarde ook gebruikt in de StUF node:
<ZKN:identificatie>[Zaak kenmerk]</ZKN:identificatie>
De omschrijving van de zaak is binnen StUF beperkt tot 80 karakters. Bij uitgaande notificaties wordt de zaakomschrijving hierom afgekapt. De omschrijving is een verplichte waarde voor een uitgaande kennisgeving.
<ZKN:omschrijving>[Omschrijving zaak]</ZKN:omschrijving>
Startdatum zaak
De startdatum van de zaak bevat standaard de macro DATE(). Hierdoor wordt er bij de creatie van een zaak automatisch de datum van vandaag als startdatum ingevuld wanneer deze niet in het inkomende StUF bericht is opgegeven.
<ZKN:startdatum>[Startdatum zaak]</ZKN:startdatum>
Dit veld wordt automatisch aangevinkt wanneer de zaak een gevulde einddatum ontvangt. Er is binnen StUF geen separaat veld voor deze staat.
De datum afhandeling wordt bepaald door een macro ‘DATE(PROCESSED)’ wanneer de zaak niet door het StUF-ZKN koppelvlak wordt afgehandeld.
<ZKN:einddatum>[Datum afhandeling]</ZKN:einddatum>
Voor de registratiedatum is geen veld aanwezig in het itemprofiel. Deze datum is beschikbaar als verborgen Connect property en wordt gebruikt voor de volgende StUF node:
<ZKN:registratiedatum>[Datum registratie]</ZKN:registratiedatum>
JZD Veld | Intern veld | Connect property | StUF |
---|---|---|---|
Huidige behandelaar | TEXT5 | Handler | heeftAlsUitvoerende (ZAKBTRUTV) |
Status | TITLE | Status | heeft (ZAKSTT) |
Verwachte einddatum (servicenorm) | DATE1 | DesiredEndDate | einddatumGepland |
Verwachte einddatum (wettelijk) | DATE2 | MaximumEndDate | uiterlijkeEinddatum |
Resultaat | FUNCTION | Result | resultaat |
Bron | PHONE2 | MarkSource | kenmerk/bron |
Extern zaakkenmerk | COUNTRY | IntakeID | kenmerk/kenmerk |
Verantwoordelijke backoffice | TEXT1 | ResponsiblePerson | heeftAlsVerantwoordelijke (ZAKBTRVRA) |
Feedback | EMAIL3 | FeedBack | - |
Opmerkingen bij zaak / toelichting | MEMO | Explanation | toelichting |
De behandelaar kan gezet worden door de backoffice applicatie via StUF-ZKN wanneer deze de rol ‘Behandelaar’ heeft als externe applicatie in Zaaktypen.nl. De behandelaar kan dan niet handmatig ingevuld worden in JOIN Zaak & Document.
De behandelaar kan een medewerker of een organisatorische eenheid (afdeling) zijn.
De behandelaar wordt in JOIN Zaak & Document weggeschreven als:
<voorletters>. <voorvoegselAchternaam> <achternaam> [<identificatie>] <ZKN:heeftAlsUitvoerende StUF:entiteittype="ZAKBTRUTV" StUF:verwerkingssoort="T"> <ZKN:gerelateerde> <ZKN:medewerker StUF:entiteittype="MDW" StUF:verwerkingssoort="T"> <ZKN:identificatie>001</ZKN:identificatie> <ZKN:achternaam>Boer</ZKN:achternaam> <ZKN:voorletters>J</ZKN:voorletters> <ZKN:voorvoegselAchternaam>de</ZKN:voorvoegselAchternaam> </ZKN:medewerker> </ZKN:gerelateerde> </ZKN:heeftAlsUitvoerende>
Gegevens van de organisatorische eenheid die de zaak behandeld.
De volgende velden worden verwerkt:
<ZKN:heeftAlsUitvoerende StUF:entiteittype="ZAKBTRUTV" StUF:verwerkingssoort="T"> <ZKN:gerelateerde> <ZKN:organisatorischeEenheid StUF:entiteittype="OEH" StUF:verwerkingssoort="T"> <ZKN:identificatie>008</ZKN:identificatie> <ZKN:naam>Afdeling ruimte</ZKN:naam> </ZKN:organisatorischeEenheid> </ZKN:gerelateerde> </ZKN:heeftAlsUitvoerende>
De mogelijke statussen moeten afgestemd zijn met de backoffice applicatie. JOIN Zaak & Document kent alleen een status omschrijving en een status volgnummer. De statuscode die in de uitgaande berichtgeving gevuld wordt, is de tot 8 tekens afgekapte status omschrijving.
<ZKN:heeft StUF:entiteittype="ZAKSTT" StUF:verwerkingssoort="T"> <ZKN:gerelateerde StUF:entiteittype="STT" StUF:verwerkingssoort="T">| <ZKN:zkt.code>[Zaaktype code]</ZKN:zkt.code> <ZKN:zkt.omschrijving>[Zaaktype naam]</ZKN:zkt.omschrijving> <ZKN:volgnummer>[Volgnummer status]</ZKN:volgnummer> <ZKN:code>[Status omschrijving, afgekapt tot 8 tekens]</ZKN:code> <ZKN:omschrijving>[Status omschrijving]</ZKN:omschrijving> <ZKN:ingangsdatumObject>20140101</ZKN:ingangsdatumObject> </ZKN:gerelateerde> <ZKN:toelichting>[Status omschrijving]</ZKN:toelichting> <ZKN:datumStatusGezet>[Datum vandaag]</ZKN:datumStatusGezet> </ZKN:heeft>
Bij vraag-antwoord op een zaak wordt naast de bovenstaande statusinformatie ook aangegeven of de huidige status de laatste status is:
<ZKN:heeft StUF:entiteittype="ZAKSTT"> ... <ZKN:indicatieLaatsteStatus>[J/N]</ZKN:indicatieLaatsteStatus> </ZKN:heeft>
De ‘verwachte einddatum (servicenorm)’ kan gezet worden door de backoffice applicatie via StUF-ZKN wanneer deze de rol ‘Behandelaar’ heeft als externe applicatie in Zaaktypen.nl. Indien de backoffice applicatie geen waarde meegeeft, berekent JOIN Zaak & Document een waarde op basis van de ingestelde ‘Servicenorm behandeling’.
<ZKN:einddatumGepland>[Verwachte einddatum (servicenorm)]</ZKN:einddatumGepland>
De ‘verwachte einddatum (wettelijk)’ kan gezet worden door de backoffice applicatie via StUF-ZKN wanneer deze de rol ‘Behandelaar’ heeft als externe applicatie in Zaaktypen.nl. Indien de backoffice applicatie geen waarde meegeeft, berekent JOIN Zaak & Document een waarde op basis van de ingestelde ‘Doorlooptijd behandeling’.
<ZKN:uiterlijkeEinddatum>[Verwachte einddatum (wettelijk)]</ZKN:uiterlijkeEinddatum>
De mogelijke resultaten moeten zijn afgestemd met de backoffice applicatie. JOIN Zaak & Document kent geen toelichting op het resultaat. Daarom wordt de toelichting in uitgaande berichten gevuld met de resultaatomschrijving.
<ZKN:resultaat> <ZKN:omschrijving>[Resultaat]</ZKN:omschrijving> <ZKN:toelichting>[Resultaat]</ZKN:toelichting> </ZKN:resultaat>
De velden ‘Bron’ en ‘Extern zaakkenmerk’ worden gebruikt om de waarde in op te slaan die het koppelvlak ontvangt voor binnen een kenmerk node die niet het eigen kenmerk betreft. Zo kan een applicatie bijvoorbeeld het volgende sturen:
<ZKN:kenmerk> <ZKN:kenmerk>Z/16/101546</ZKN:kenmerk> <ZKN:bron>DecosD5</ZKN:bron> </ZKN:kenmerk> <ZKN:kenmerk> <ZKN:kenmerk>Z-HZ_WABO-2015-000045</ZKN:kenmerk> <ZKN:bron>Squit XO</ZKN:bron> </ZKN:kenmerk>
In dit geval wordt de waarde ‘Z-HZ_WABO-2015-000045’ in het veld ‘Extern zaakkenmerk’ en de waarde ‘SquitXO’ in het veld ‘Bron’ opgeslagen.
In uitgaande notificaties worden altijd maximaal 2 kenmerken gestopt. Het eigen kenmerk en het externe kenmerk. Bij het ontbreken van een extern kenmerk en bron, wordt alleen het eigen kenmerk gevuld.
De verantwoordelijke backoffice kan gezet worden door de backoffice applicatie via StUF-ZKN. De verantwoordelijke backoffice kan niet handmatig ingevuld worden in JOIN Zaak & Document.
De verantwoordelijke voor een zaak kan een medewerker of een organisatorische eenheid (afdeling) zijn.
Gegevens van de medewerker die de zaak behandeld.
De volgende velden worden verwerkt:
<voorletters>. <voorvoegselAchternaam> <achternaam>
[<identificatie>] <ZKN:heeftAlsVerantwoordelijke StUF:entiteittype="ZAKBTRVRA" StUF:verwerkingssoort="T"> <ZKN:gerelateerde> <ZKN:medewerker StUF:entiteittype="MDW" StUF:verwerkingssoort="T"> <ZKN:identificatie>002</ZKN:identificatie> <ZKN:achternaam>Vries</ZKN:achternaam> <ZKN:voorletters>M</ZKN:voorletters> <ZKN:voorvoegselAchternaam>de</ZKN:voorvoegselAchternaam> </ZKN:medewerker> </ZKN:gerelateerde> </ZKN:heeftAlsVerantwoordelijke>
Gegevens van de organisatorische eenheid die de zaak behandeld.
De volgende velden worden verwerkt:
<ZKN:heeftAlsVerantwoordelijke StUF:entiteittype="ZAKBTRVRA" StUF:verwerkingssoort="T"> <ZKN:gerelateerde> <ZKN:organisatorischeEenheid StUF:entiteittype="OEH" StUF:verwerkingssoort="T"> <ZKN:identificatie>008</ZKN:identificatie> <ZKN:naam>Afdeling ruimte</ZKN:naam> </ZKN:organisatorischeEenheid> </ZKN:gerelateerde> </ZKN:heeftAlsVerantwoordelijke>
Het veld ‘Feedback’ wordt gevuld met de laatste response die het koppelvlak heeft ontvangen bij het versturen van een notificatie. Mogelijke waarden zijn:
De toelichting mag binnen StUF maximaal 1000 karakters lang zijn. Het ‘memo’ veld van JOIN Zaak & Document heeft geen maximale lengte. In uitgaande berichten wordt het veld daarom afgekapt tot 1000 karakters.
<ZKN:toelichting>[Toelichting]</ZKN:toelichting>
De velden voor deze gegevens worden niet standaard toegevoegd aan een itemprofiel, gegenereerd door een Zaaktypen.nl, maar kunnen voor sommige implementaties van nut zijn.
JZD Veld | Intern veld | Connect property | StUF |
---|---|---|---|
Deelzaak indicatie | BOL7 | SubCase | Zie beschrijving |
Behandelende organisatie | SALUTATION | OrganisationCode | Zie beschrijving |
Locatie | TEXT8 | Location | Zie beschrijving |
Dit veld kan gebruikt worden om aan te geven dat het om een deelzaak gaat. De backoffice applicatie kan dit in het StUF bericht aangeven door de volgende StUF nodes te vullen:
zaakniveau | 1-3 | 1=Hoofdzaak, 2=Deelzaak, 3=Deeldeelzaak |
---|---|---|
deelzakenIndicatie | J/N | De aanduiding of een ZAAK behandeld wordt in deelzaken. |
extraElement: idDeelZaakVan | String | Identificatie van de gerelateerde hoofdzaak |
<ZKN:zaakniveau>2</ZKN:zaakniveau> <ZKN:deelzakenIndicatie>J</ZKN:deelzakenIndicatie> <StUF:extraElementen> <StUF:extraElement naam="isDeelZaakVan">Z/16/101545</StUF:extraElement> </StUF:extraElementen>
Bijvoorbeeld:
<ZKN:zaakniveau>2</ZKN:zaakniveau> <ZKN:deelzakenIndicatie>J</ZKN:deelzakenIndicatie> <StUF:extraElementen> <StUF:extraElement naam="isDeelZaakVan">Z/16/101545</StUF:extraElement> </StUF:extraElementen>
Dit veld wordt gevuld met de behandelende organisatie. De mogelijke waarden moeten voor alle aangesloten backoffice applicaties afgestemd worden.
Voor inkomende kennisgevingen wordt de waarde gehaald uit de ‘administratie’ node uit de stuurgegevens van het bericht gehaald, dat wordt gestuurd naar JOIN Zaak & Document voor het aanmaken/bijwerken van de zaak.
Voor uitgaande kennisgevingen wordt de waarde uit het veld in de ‘organisatie’ node gezet van de ‘ontvanger’ stuurgegevens wanneer de aansluiting in het koppelvlak is geconfigureerd met meerdere organisatiecodes. Wanneer er 1 organisatiecode is geconfigureerd voor de aansluiting wordt de waarde uit het veld gestopt in de ‘administratie’ node van de ‘ontvanger’ stuurgegevens.
Voorbeeld stuurgegevens inkomende kennisgeving:
<StUF:zender> <StUF:organisatie>Gemeente X</StUF:organisatie> <StUF:applicatie>GWS4ALL</StUF:applicatie> </StUF:zender> <StUF:ontvanger> <StUF:organisatie>Decos</StUF:organisatie> <StUF:applicatie>JOINZD</StUF:applicatie> <StUF:administratie>Gemeente X</StUF:administratie> </StUF:ontvanger>
Voorbeeld stuurgegevens van uitgaande kennisgeving met meerdere ingestelde organisatiecodes:
<StUF:zender> <StUF:organisatie>Decos</StUF:organisatie> <StUF:applicatie>JOINZD</StUF:applicatie> <StUF:administratie>Gemeente X</StUF:administratie> </StUF:zender> <StUF:ontvanger> <StUF:organisatie>Gemeente X</StUF:organisatie> <StUF:applicatie>GWS4ALL</StUF:applicatie> </StUF:ontvanger>
Voorbeeld stuurgegevens van uitgaande kennisgeving met 1 ingestelde organisatiecode:
<StUF:zender> <StUF:organisatie>Decos</StUF:organisatie> <StUF:applicatie>JOINZD</StUF:applicatie> <StUF:administratie>Gemeente X</StUF:administratie> </StUF:zender> <StUF:ontvanger> <StUF:organisatie>Centric</StUF:organisatie> <StUF:applicatie>GWS4ALL</StUF:applicatie> <StUF:administratie>Gemeente X</StUF:administratie> </StUF:ontvanger>
De aangesloten applicatie heeft de mogelijkheid tot het sturen van de entiteiten ‘adresseerbaar object’ (AOA) en ‘openbare ruimte’ (OPR) als entiteiten waar de zaak betrekking op heeft.
De gegevens uit deze entiteiten worden door de koppeling vertaald naar een tekstuele representatie in het veld ‘Locatie’.
Indien dit veld als een extra kenmerk wordt toegevoegd vanuit Zaaktypen.nl, is het onvoorspelbaar welk TEXT veld wordt gebruikt. Let er op dat het, in Connect gemapte veld voor alle met StUF-Zaken gekoppelde zaaktypen hetzelfde TEXT veld is.
Van een adresseerbaar object kunnen de volgende gegevens worden verwerkt:
<ZKN:heeftBetrekkingOp stuf:entiteittype="ZAKOBJ" stuf:verwerkingssoort="T"> <ZKN:gerelateerde> <ZKN:adres stuf:entiteittype="AOA" stuf:verwerkingssoort="T"> <BG:identificatie stuf:noValue="waardeOnbekend" xsi:nil="true"/> <BG:authentiek stuf:metagegeven="true">N</BG:authentiek> <BG:wpl.woonplaatsNaam>Noordwijk</BG:wpl.woonplaatsNaam> <BG:gor.openbareRuimteNaam>Huygenstraat</BG:gor.openbareRuimteNaam> <BG:huisnummer>30</BG:huisnummer> <BG:huisletter>A</BG:huisletter> <BG:huisnummertoevoeging>Bis</BG:huisnummertoevoeging> <BG:postcode>2201DK</BG:postcode> </ZKN:adres> </ZKN:gerelateerde> </ZKN:heeftBetrekkingOp>
Resultaat in JOIN Zaak & Document:
Binnen JOIN Zaak & Document maken we onderscheid tussen een documentregistratie en een bestandsregistratie. De StUF standaard kent alleen de entiteit ‘Enkelvoudig document’ (EDC) waarbij document-metadata en bestandsinhoud gekoppeld zijn aan elkaar. Om deze reden is elk gekoppeld bestand in JOIN Zaak & Document via de StUF-ZKN integratie zichtbaar als een EDC-entiteit. Deze entiteit bevat gegevens uit zowel de documentregistratie als de bestandsregistratie.
Veldomschrijving | Opmerking | V/O |
---|---|---|
identificatie | Unieke identificatie van het document in JOIN Zaak & Document . | v |
dct.omschrijving | Documenttype omschrijving zoals is vastgelegd in de zaaktypecatalogus | o |
Creatiedatum | Datum waarop het document is aangemaakt | v |
Ontvangstdatum | Datum waarop het document is ontvangen (optioneel) | o |
Titel | Beknopte beschrijving van het document | v |
Format | Het formaat van het document (bestandsformaat) | o |
Taal | De taal van het document | o |
Beschrijving | Uitgebreide beschrijving van het document (optioneel) | o |
Status | Status van het document. | o |
Verzenddatum | Datum waarop het document is verzonden. (optioneel) | o |
vertrouwelijkAanduiding | Vertrouwelijkheidsaanduiding volgens StUF-ZKN (wordt automatisch gevuld door Decos vanuit het documenttype, kan overschreven worden door backoffice voor afwijkende aanduiding) | o |
Auteur | Auteur van het document | o |
Inhoud | Base64 inhoud van het document | o |
extraElement: kenmerk | JOIN Document kenmerk | o |
extraElement: barcode | JOIN Document barcode | o |
IsRelevantVoor EDCZAK ZAK.identificatie | Relatie met de Zaak: Unieke identificatie van de zaak zoals deze in JOIN Zaak & Document is geregistreerd. Dit kan zowel de identificatie als het decos zaakkenmerk zijn. | v |
JZD Veld | Intern veld | Connect property | StUF |
---|---|---|---|
Document identificatie | ExternalId | identificatie | |
Document type | BOOKNAME | DocumentType | dct.omschrijving |
Onderwerp | SUBJECT1 | Subject | titel |
Datum document | DOCUMENT_DATE | DocumentDate | creatiedatum |
Kenmerk | MARK | Mark | documentkenmerk |
Barcode | BARCODE | Barcode | barcode |
Auteur | TEXT5 | Author | Auteur |
Bestandsextensie | - | formaat | |
Taal | - | taal | |
Publiek | BOL9 | IsPublished | vertrouwelijkAanduiding |
Link naar registratie | EntityUrl | Link |
De documentidentificatie wordt binnen de integratie gebruikt om een document uniek te kunnen identificeren. Dit gegeven is niet zichtbaar in de gebruikersinterface van JOIN Zaak & Document.
De aangesloten applicatie kan een identificatie genereren m.b.v. de ‘genereerDocumentIdentificatie_Di02’ service.
<ZKN:identificatie>123465f612f5-c372-4f49-8bbd-f2cec6fde54a</ZKN:identificatie>
Het documenttype van het document. De tekstuele waarde van dit element moet exact overeenkomen de documenttype omschrijving.
<ZKN:dct.omschrijving>Ontvangstbevestiging</ZKN:dct.omschrijving>
Het onderwerp van het document. Deze waarde wordt in het veld ‘titel’ uitgewisseld in het berichtenverkeer.
<ZKN:titel>Aanvragen vergunning</ZKN:titel>
De creatiedatum van het document.
<ZKN:creatiedatum>20150902</ZKN:creatiedatum>
Het kenmerk van een document zoals deze in Decos is geregistreerd wordt altijd vermeldt in een extra element onderdeel van een StUF-document bericht. Een bericht dat verstuurd wordt vanuit Decos bevat dus altijd de EDC.identificatie als uniek identificerend en intern gebruikt veld én bevat het leesbare documentkenmerk en barcode van Decos voor correspondentie over dit document.
<StUF:extraElementen> <StUF:extraElement naam="documentkenmerk">D-12354</StUF:extraElement> <StUF:extraElement naam="barcode">Z0006CD16F8</StUF:extraElement> </StUF:extraElementen>
De barcode kan met behulp van het Decos Barcode lettertype op een brief geplaatst worden.
De auteur is de opsteller van het document en wordt als vrij tekstveld opgeslagen. Dit gegeven wordt niet door elke applicatie doorgegeven.
<ZKN:auteur>Jan Jansen</ZKN:auteur>
De bestandsextensie wordt in uitgaande kennisgevingen of antwoordberichten automatisch gevuld met de huidige extensie van het bestand.
<ZKN:formaat>.txt</ZKN:formaat>
Bij inkomende EDC kennisgevingen wordt de eventueel meegegeven waarde genegeerd en wordt de complete bestandsnaam uit het desbetreffende attribuut uit de inhoud node gebruikt voor het aanmaken van het bestand.
De taal van het document wordt in uitgaande kennisgevingen of antwoordberichten standaard gevuld met ‘NL’.
<ZKN:taal>NL</ZKN:taal>
Bij inkomende EDC kennisgevingen wordt de eventueel meegegeven waarde genegeert.
Dit BOL veld is gemapt aan de vertrouwelijkheidsaanduiding. Wanneer het BOL veld is aangevinkt zal de vertrouwelijkheidsaanduiding gevuld worden met de term ‘Openbaar’. Wanneer het BOL veld is uitgevinkt, wordt de vertrouwelijkheidsaanduiding gevuld met de term ‘Vertrouwelijk’.
<ZKN:vertrouwelijkAanduiding>VERTROUWELIJK</ZKN:vertrouwelijkAanduiding>
Dit veld bevat een rechtstreekse link naar de registratie in JOIN Zaak & Document in alle uitgaande kennisgevingen en antwoordberichten.
<ZKN:link>http://jzd/aspx/item.aspx?I=FA88CDC619514176AF0B1EF73B819A27</ZKN:link>
i Bij inkomende EDC kennisgevingen wordt de eventueel meegegeven waarde genegeerd.
JZD Veld | Intern veld | Connect property | StUF |
---|---|---|---|
Datum ontvangst | DATE8 | DateReceived | ontvangstdatum |
Datum verzonden | DATE7 | DateSent | verzenddatum |
De ontvangstdatum van het document.
<ZKN:ontvangstdatum>20160405</ZKN:ontvangstdatum>
De datum verzonden van het document.
<ZKN:verzenddatum>20160405</ZKN:verzenddatum>
JZD Veld | Intern veld | Connect property | StUF |
---|---|---|---|
Omschrijving | TEXT1 | File.Description | Beschrijving |
Bestandsinhoud | - | Inhoud |
De omschrijving/beschrijving van het document. Deze waarde wordt op bestandsniveau weggeschreven als bestandsomschrijving.
<ZKN:beschrijving>Beschrijving van het document</ZKN:beschrijving>
De bestandsinhoud wordt alleen vanuit JOIN Zaak & Document aan een aangesloten applicatie teruggegeven d.m.v. het antwoordbericht op een EDC vraagbericht. Uitgaande EDC kennisgevingen bevatten niet de bestandsinhoud.
Wanneer binnenkomende EDC kennisgevingen bestandsinhoud bevatten, wordt het bestand in JOIN Zaak & Document bijgewerkt met deze vernieuwde inhoud. Wanneer versiebeheer is ingeschakeld, wordt een nieuwe versie aangemaakt.
<ZKN:inhoud StUF:bestandsnaam="test.txt">aG9pIGRlY29z</ZKN:inhoud>
De StUF-Zaken integratie is in staat om adresregistraties van burgers en/of organisaties aan te maken en/of te koppelen aan een zaakregistratie.
JOIN Zaak & Document koppelt de adressen direct aan de bron in het gegevensmagazijn, gebruikmakend van de StUF-BG integratie (basisgegevens) wanneer een BSN of Vestigingsnummer beschikbaar is. Als dit niet het geval is, worden de gegevens van het persoon of bedrijf in een apart niet authentieke adrescollectie geplaatst en gerelateerd aan de zaak.
In het bericht kunnen verschillende gegevens met betrekking tot burgers of organisaties worden uitgewisseld. De integratie maakt hierbij gebruik van verschillende adresrollen.
heeftAlsInitiator ZAKBRTINI | Relatie met de initiator van de zaak – de aanvrager (adresrol ‘Initiator’) |
---|---|
heeftAlsGemachtigde ZAKBRTGMC | Relatie met de gemachtigde van de zaak (adresrol ‘Gemachtigde’) |
heeftAlsBelanghebbende ZAKBRTBLH | Relatie met de belanghebbende van de zaak (adresrol ‘Belanghebbende’) |
heeftAlsOverigBetrokkene ZAKBRTOVR | Relatie met overig betrokkenen van de zaak (adresrol ‘Overig’) |
Natuurlijke persoon NPS.inp.bsn | Gegevens over de relatie – een BSN volstaat om een koppeling te kunnen maken met een bestaand adres. De volgende velden van een Natuurlijk Persoon worden opgeslagen in het zakenmagazijn wanneer het niet mogelijk is om de relatie met een burger uit het gegevensmagazijn te maken. BSN GeslachtsNaam VoorVoegselGeslachtsNaam Voorletters Voornamen GeslachtsAanduiding Verblijfsadresgegevens WoonPlaatsnaam Straatnaam Postcode HuisNummer HuisLetter HuisNummerToevoeging |
Niet natuurlijk persoon NNP.inn.nnpId | Gegevens over de relatie – een nnp Id (RSIN/SofiNummer) volstaat om een koppeling te kunnen maken met een bestaand adres. De volgende velden van een Niet natuurlijk Persoon worden opgeslagen in het zakenmagazijn wanneer het niet mogelijk is om de relatie met een organisatie uit het gegevensmagazijn te maken. Nnp.Id (RSIN/SofiNummer) Statutairenaam Bezoekadres Woonplaatsnaam Straatnaam Postcode HuisNummer HuisLetter HuisnummerToevoeging |
Vestiging VES.vestigingsnummer | Gegevens over de relatie – een vestigingsnummer volstaat om een koppeling te kunnen maken met een bestaand adres. De volgende velden van een vestiging worden opgeslagen in het zakenmagazijn wanneer het niet mogelijk is om de relatie met een organisatie uit het gegevensmagazijn te maken. Vestigingsnummer Handelsnaam Bezoekadres Woonplaatsnaam Straatnaam Postcode HuisNummer HuisLetter HuisnummerToevoeging |
Organisatorische Eenheid OEH | |
Medewerker MDW |
Voor organisaties/maatschappelijke activiteiten is vanaf versie 2020.9 ondersteuning voor een KVK-nummer (Handelsregisternummer). De gebruikte entiteiten NNP en VES beschikken niet over een standaard veld voor een KVK-nummer. In de praktijk wordt door sommige aangesloten leveranciers gebruik gemaakt van het Nnp.Id voor het KVK-nummer.
Hoe de gegevens van een adres verwerkt worden in JOIN Zaak & Document staat beschreven in de functionele beschrijving van de StUF-BG-integratie.