Verschillen

Dit geeft de verschillen weer tussen de geselecteerde revisie en de huidige revisie van de pagina.

--- openwave:1.32:applicatiebeheer:probleemoplossing:programmablokken:verwerking_dso_stam_berichten [2025/07/01 10:59] – aangemaakt - Externe bewerking 127.0.0.1
+++ openwave:1.32:applicatiebeheer:probleemoplossing:programmablokken:verwerking_dso_stam_berichten [2025/12/18 11:56] (huidige) – Kars Gottschal
@@ Regel 37: / Regel 37: @@
 Via de digi-koppelaar (Jnet/EnableU) kan een bericht doorgegeven worden in eigen JSON-formaat waarin een externe zaakidentifier (requestor-reference) en een DSO-verzoeknummer is opgenomen.\\
 Het doel van dit bericht is om OpenWave te laten weten onder welke zaakcodering het DSO-verzoek bij het bevoegd gezag is aangemaakt, zodat OpenWave na de behandeling van datzelfde DSO-verzoek door de omgevingsdienst, de van belang zijnde documenten kan exporteren naar dat bevoegd gezag. Zie: [[openwave:1.32:applicatiebeheer:probleemoplossing:programmablokken:export_documenten_bij_dso_zaak_van_map_naar_dms_bevoegd_gezxag]]
-<code JSON>
+<code json>
 {
     "casetype_id": "f8285eb3-6fd2-4b9a-8663-dfd0df9767af",
@@ Regel 65: / Regel 66: @@
 </adm>
-=====Verzoeknotificatiebericht =====
+===== Verzoeknotificatiebericht =====
 Het verzoeknotificatiebericht is qua inhoud zo beperkt dat OpenWave alleen nog het DSO-verzoeknummer uit het bericht opslaat in de tabel tbDSOtrigger (geen userinterface). De registratie van het DSO-verzoeknummer in tbDSOtrigger blijft behouden zodat er toch voor ieder nieuw DSO aanvraag een registratie is van het binnengekomen triggerbericht bij OpenWave.
@@ Regel 88: / Regel 89: @@
 Uit de tag <verzoeknummer>  wordt het verzoeknummer opgehaald.
-==== Doel ====
+==== Doel====
 <adm STAM 5 versus STAM 4>
-Met STAM 5.0 is het een en ander veranderd qua inhoud van tag <doel>, is tag <type> hergebruikt voor een nieuwe toevoeging en is er een tag bijgekomen: <plicht>. In tag <plicht> staan de waardes die in STAM 4 nog bij tag <type> werden gebruikt. \\
+Met STAM 5.0 is het een en ander veranderd qua inhoud van tag <doel>, is tag ''<type>'' hergebruikt voor een nieuwe toevoeging en is er een tag bijgekomen: <plicht>. In tag ''<plicht>'' staan de waardes die in STAM 4 nog bij tag ''<type>'' werden gebruikt.
 Onderstaand wordt de verwerking uitgelegd voor zowel STAM 4 als 5. In de praktijk zal er qua instellingen en verwerking niets veranderen voor STAM 5 en hoeft men alleen voor VerkenUwIdee een nieuw zaaktype aan te wijzen.
 </adm>
-Uit de tag <doel> wordt bepaald of het bericht gaat over Initiëren (STAM 4)/Indienen (STAM 5), Conceptverzoek (alleen STAM 4), Aanvullen of Intrekken. In STAM 5 is er nieuwe tag <type> aanwezig met mogelijke waardes: Concept, Definitief, Idee. Het type geeft aan of het om een Conceptverzoek, Definitieve aanvraag of een VerkenUwIdee gaat.
+Uit de tag ''<doel>'' wordt bepaald of het bericht gaat over Initiëren (STAM 4)/Indienen (STAM 5), Conceptverzoek (alleen STAM 4), Aanvullen of Intrekken. In STAM 5 is er nieuwe tag ''<type>'' aanwezig met mogelijke waardes: Concept, Definitief, Idee. Het type geeft aan of het om een Conceptverzoek, Definitieve aanvraag of een VerkenUwIdee gaat.
   * Indien **Aanvullen** dan wordt de kaart gezocht in tbomgvergunning met dvlvoaanvraagnr = verzoeknummer. Indien niet gevonden of er zijn meerdere kaarten gevonden met hetzelfde verzoeknummer dan wordt de verwerking gestopt (zie kolom //Error// in messagelog). Indien wel gevonden dan wordt een kaartje aangemaakt in tbomgdsoaanvulintrek bij de betreffende omgevingszaak (deze tabel is zichtbaar als lijstje in detailscherm omgevingszaak in blok **DSO-aanvullingen**) met het volgnummer en doel.
       * Uitzondering: indien niet gevonden maar instelling //Sectie: DSO, Item: AanvullingTotNieuweZaak// is aangevinkt (default false) dan wordt er wel een nieuwe zaak aangemaakt. Dit kan men zo instellen om de DSO verzoeken tot een nieuwe zaak te verwerken in OpenWave waarop al 1 of meer aanvullingen zijn, die pas na het wijzigen van bevoegd gezag bij de organisatie binnenkomen. In dit geval stuurt het DSO alleen de laatste Aanvulling naar de organisatie. Als de instelling aan staat zal er een nieuwe zaak worden aangemaakt conform werking zoals beschreven op deze pagina (doel blijft //Aanvullen//). Daarnaast wordt een record in tbomgdsoaanvulintrek bij de nieuwe omgevingszaak aangemaakt. Mocht er ingesteld staan dat er automatisch een DSO ontvangstbevestigingsmail verstuurd moet worden dan zal deze van sjabloon Aanvulling zijn.
@@ Regel 128: / Regel 130: @@
 Het is raadzaam hier zaaktypes voor te definiëren (of bestaande te hergebruiken) in de beheertabel //Zaaktypes omgeving// (tbsoortomgverg). Daartoe is de kolom //Verzoektype// (dvdsotype) in het blok //DSO-type//. OpenWave zal eerst proberen vast te stellen of het DSO verzoekbericht voor een compartiment is bedoeld op grond van de locatie, uitvoerende instantie en bevoegd gezag.
-{{openwave:applicatiebeheer:probleemoplossing:programmablokken:dsointierenbepalingzaaktypedummyadres.png?900|}}
+{{openwave:applicatiebeheer:probleemoplossing:programmablokken:dsointierenbepalingzaaktypedummyadres.png?900|dsointierenbepalingzaaktypedummyadres}}
 Indien de uitvoerende instantie (behandeldienst) in het verzoekbericht is gevuld dan is het verzoekbericht sowieso niet voor een compartiment, tenzij het gaat om een kopiebericht of tenzij de behandeldienstdienst gelijk is aan bevoegd gezag. Zie hieronder onder kopje //Negeren van binnenkomende kopieberichten in kader afhandelen complexe verzoeken in samenwerkingsverband//.
@@ Regel 150: / Regel 152: @@
 Alleen bij Initiëren/Indienen en Conceptverzoek.
-Indien de tag <projectId> is gevuld, zoek dan de inhoud hiervan op in TbDsoProject. Niet gevonden (maar wel gevuld) maak dan een nieuwe projectkaart in TbDsoProject (beheertegel //DSO projecten//).
+Indien de tag ''<projectId>'' is gevuld, zoek dan de inhoud hiervan op in TbDsoProject. Niet gevonden (maar wel gevuld) maak dan een nieuwe projectkaart in TbDsoProject (beheertegel //DSO projecten//).
 In alle gevallen wordt de kolom tbomgvergunning.dlisdso gevuld met 'T'. Deze kolom bepaalt of de DSO-blokken zichtbaar zijn in de detailkaart van de omgevingzaak.
@@ Regel 171: / Regel 173: @@
 ==== Bevoegd gezag ====
 Alleen bij Initiëren/Indienen en Conceptverzoek.
@@ Regel 194: / Regel 197: @@
 ==== Dossierbehandelaar ====
 Alleen bij //Initiëren/Indienen en Conceptverzoek//.
@@ Regel 199: / Regel 203: @@
 ==== Contactgegevens verwerken ====
-===Contactpersoon ===
+=== Contactpersoon===
 <adm warning>
 Niet te verwarren met Initiatiefnemer of Gemachtigde: het gaat hier om hoe OpenWave de gegevens verwerkt uit het blok **Contactpersoon** indien aanwezig in het STAM-bericht
@@ Regel 207: / Regel 213: @@
   * Er is geen gemachtigde en de initiatiefnemer is een bedrijf of vestiging
   * Er is een gemachtigde en de gemachtigde is een bedrijf of vestiging
-Staat er in het STAM-bericht een initiatiefnemer/gemachtigde (bedrijf) en een blok contactpersoon, dan wordt er zowel een Aanvrager/Gemachtigde (het bedrijf) als een DSO contactpersoon aangemaakt.\\
+Staat er in het STAM-bericht een initiatiefnemer/gemachtigde (bedrijf) en een blok contactpersoon, dan wordt er zowel een Aanvrager/Gemachtigde (het bedrijf) als een DSO contactpersoon aangemaakt.
 Het is ook mogelijk dat een bedrijf of vestiging de aanvraag indient ZONDER een extra contact. In dat geval zal er alleen een Aanvrager/Gemachtigde bij de zaak worden aangemaakt: zie voor verwerking Aanvrager/Gemachtigde (bedrijf) de kopjes //Initiatiefnemer// resp. //Gemachtigde// op deze pagina. \\
@@ Regel 223: / Regel 229: @@
 //Bij Initiëren/Indienen en Conceptverzoek en Aanvullen//
-Een BSN-nummer bestaande uit 9 nullen beschouwd OpenWave als leeg.\\
+Een BSN-nummer bestaande uit 9 nullen beschouwd OpenWave als leeg.
-Een KvK-nummer bestaande uit 8 nullen beschouwd OpenWave als leeg.\\
+Een KvK-nummer bestaande uit 8 nullen beschouwd OpenWave als leeg.
 De gegevens uit blok ''<initiatiefnemer>'' (in OpenWave is dit de aanvrager) worden aangevuld of nieuw aangemaakt in de tabel tbcontactadressen (omgevingstegel //Contactadressen//). De relatie tussen het contactadres en de omgevingszaak ligt in de dochtertabel tbomgvergcontactennn op de kaart met dvcodeadressoort = AVR (zie hierboven bij verplichte instellingen). Bij **Aanvullen** kijkt OpenWave of deze relatie in tbomgvergcontactennn reeds bestaat. Zo ja dan worden de contactgegevens zo mogelijk aangepast in de betrokken adreskaart van tbcontactadressen. Zo nee, - of het gaat om **Initiëren, Indienen of Conceptverzoek** - , dan zal een nieuwe relatie gelegd moeten worden naar een nieuw aan te maken of reeds bestaande adreskaart in OpenWave. OpenWave kijkt in het STAM-bericht naar de aanwezigheid van BSN, KVK-nummer of vestigingsnummer en zoekt daarmee naar een bestaande, niet vervallen (unieke) kaart in tbcontactadressen. Indien het een natuurlijk persoon betreft (BSN is gevuld), dan wordt op BSN gezocht (indien meer dan 1 gevonden dan diegene met de hoogste dnkey). Geen (unieke kaart) gevonden, dan wordt er een nieuw contactadres aangemaakt. Indien het om een bedrijf gaat dan wordt op vestigingsnummer en/of KvK-nummer gezocht waarbij eerst op vestigingsnummer indien gevuld: ook hier geldt indien meer dan 1 gevonden dan diegene met de hoogste dnkey EN waarvoor geldt dat de achternaam LEEG is (achternaam komt namelijk niet mee in het STAM-bericht, er dient dus een leeg contact te zijn voor het bedrijf). Is er geen vestigingsnummer maar wel een KvK-nummer dan wordt op KvK gezocht (ook hier geldt indien meer dan 1 gevonden dan diegene met de hoogste dnkey EN waarvoor geldt dat de achternaam LEEG is).
 Indien geen unieke kaart gevonden wordt, of het gaat om een bedrijf en de achternaam is niet leeg van het contactadres in OpenWave, dan wordt een nieuwe kaart aangemaakt in tbcontactadressen.
@@ Regel 239: / Regel 245: @@
   * dvvoorvoegsel met <voorvoegselNaamgebruik>
   * dvvoorletters met <voorlettersNaamgebruik>
-  * dvbriefaanhef met – afgekapt op 200 tekens - De aanhef zoals bepaald bij instelling //Sectie: Programma, Item: Aanhefcontactpersonen// + ‘ heer/mevrouw ‘ + (alleen indien <voorvoegselNaamgebruik> gevuld, dan <voorvoegselNaamgebruik>+ een spatie ) + <geslachtsnaamNaamgebruik>
+  * dvbriefaanhef met – afgekapt op 200 tekens - De aanhef zoals bepaald bij instelling //Sectie: Programma, Item: Aanhefcontactpersonen// + ‘ heer/mevrouw ‘ + (alleen indien ''<voorvoegselNaamgebruik>'' gevuld, dan <voorvoegselNaamgebruik>+ een spatie ) + <geslachtsnaamNaamgebruik>
 Wat betreft het overnemen/overschrijven van bedrijfsgegevens (niet natuurlijk persoon) redeneert OpenWave als volgt:
@@ Regel 262: / Regel 268: @@
     * als blok ''<postAdres>'' ''<binnenlandsAdres>'' bestaat dan vanuit blok ''<binnenlandsAdres>'' de postadresgegevens overnemen
     * als blok ''<postAdres>'' ''<buitenlandsAdres>'' bestaat dan uit blok ''<buitenlandsAdres>'' de buitenlandse adresgegevens overnemen
-    * als blok <bezoekadres> bestaat dan uit blok < bezoekadres> de vestigingsadresgegevens overnemen
+    * als blok ''<bezoekadres>'' bestaat dan uit blok < bezoekadres> de vestigingsadresgegevens overnemen
-    * als blok <bezoekadresBuitenland> bestaat EN tbcontactadressen.dvbuitenladresregel1 is null dan uit blok <bezoekadresBuitenland> de buitenlandse adresgegevens overnemen
+    * als blok ''<bezoekadresBuitenland>'' bestaat EN tbcontactadressen.dvbuitenladresregel1 is null dan uit blok ''<bezoekadresBuitenland>'' de buitenlandse adresgegevens overnemen
     * als blok ''<vestiging>'' ''<postAdres>'' ''<afwijkendAdres>'' bestaat EN ''<adrestype>'' gevuld dan vanuit blok ''<afwijkendAdres>'' de postadresgegevens overschrijven
     * als blok ''<vestiging>'' ''<postAdres>'' ''<binnenlandsAdres>'' bestaat EN ''<straatnaam>'' gevuld dan vanuit blok ''<binnenlandsAdres>'' de postadresgegevens overschrijven
     * als blok ''<vestiging>'' ''<postAdres>'' ''<buitenlandsAdres>'' bestaat EN ''<adresBuitenland1>'' gevuld dan uit blok ''<buitenlandsAdres>'' de buitenlandse adresgegevens overnemen
     * als blok ''<vestiging>'' ''<locatieAdresVestiging>'' bestaat EN ''<straatnaam>'' gevuld bestaat dan uit blok ''<locatieAdresVestiging>'' de vestigingsadresgegevens overnemen
-    * als blok ''<vestiging>'' <locatieAdresBuitenland> bestaat EN tbcontactadressen.dvbuitenladresregel1 is leeg dan uit blok <locatieAdresBuitenland> de buitenlandse adresgegevens overnemen.
+    * als blok ''<vestiging>'' <locatieAdresBuitenland> bestaat EN tbcontactadressen.dvbuitenladresregel1 is leeg dan uit blok ''<locatieAdresBuitenland>'' de buitenlandse adresgegevens overnemen.
 <adm Ontbrekend postadres>
@@ Regel 279: / Regel 285: @@
 //Bij Initiëren, Indienen en Conceptverzoek en Aanvullen//
-Een BSN-nummer bestaande uit 9 nullen beschouwd OpenWave als leeg.\\
+Een BSN-nummer bestaande uit 9 nullen beschouwd OpenWave als leeg.
-Een KvK-nummer bestaande uit 8 nullen beschouwd OpenWave als leeg.\\
+Een KvK-nummer bestaande uit 8 nullen beschouwd OpenWave als leeg.
 De gegevens uit blok ''<gemachtigde>'' worden aangevuld of nieuw aangemaakt in de tabel tbcontactadressen (omgevingstegel //Contactadressen//). De relatie tussen het contactadres en de omgevingszaak ligt in de dochtertabel tbomgvergcontactennn op de kaart met dvcodeadressoort = GEM (zie hierboven bij verplichte instellingen). Bij **Aanvullen** kijkt OpenWave of deze relatie in tbomgvergcontactennn reeds bestaat. Zo ja dan worden de contactgegevens zo mogelijk aangepast in de betrokken adreskaart van tbcontactadressen. Zo nee, - of het gaat om **Initiëren of Vooroverleg** - , dan zal een nieuwe relatie gelegd moeten worden naar een nieuw aan te maken of reeds bestaande adreskaart in OpenWave. Net als bij de Aanvrager kijkt OpenWave in het STAM-bericht naar de aanwezigheid van BSN, KvK-nummer of vestigingsnummer en zoekt daarmee naar een bestaande, niet vervallen (unieke) kaart in tbcontactadressen. Deze logica is gelijk voor zowel de aanvrager als de gemachtigde.
 Dus alleen indien er geen unieke kaart gevonden wordt, of het gaat om een bedrijf en de achternaam is niet leeg van de contact in OpenWave, dan wordt een nieuwe kaart aangemaakt in tbcontactadressen.
@@ Regel 293: / Regel 299: @@
 //Bij Initiëren en Vooroverleg en Aanvullen en Intrekken.//
-===Projectactiviteiten===
+=== Projectactiviteiten ===
-De gegevens uit het blok ''<projectactiviteiten>'' worden opgenomen in de dochtertabel tbtoestemmingen bij de omgevingszaak (omgevingstegel //Onderdelen/Activiteiten//). Per blok ''<projectactiviteit>'' wordt eerst  op grond van de tag ''<imowid>''  gezocht of deze voorkomt in de tabel tbsrttoestemming (beheertegel //Soort Activiteit/Onderdeel//) bij de niet-vervallen kaarten. Zo nee, en het gaat om een bruidsschat activiteit, dan wordt deze imowid veralgemeniseert met //9999// als gemeentecode (dus bijvoorbeeld //nl.imow-gm9999.activiteit.DierenSlachten//) en nog een keer gezocht in tbsrttoestemming. Nog niet gevonden dan wordt nog een keer gezocht op de tag ''<activiteitnaam>''. Indien nog steeds niet gevonden  dan wordt in tbsrttoestemming een nieuw record aangemaakt met de activiteitsnaam en (de eventueel veralgemeniseerde) imowid.\\
+De gegevens uit het blok ''<projectactiviteiten>'' worden opgenomen in de dochtertabel tbtoestemmingen bij de omgevingszaak (omgevingstegel //Onderdelen/Activiteiten//). Per blok ''<projectactiviteit>'' wordt eerst  op grond van de tag ''<imowid>''  gezocht of deze voorkomt in de tabel tbsrttoestemming (beheertegel //Soort Activiteit/Onderdeel//) bij de niet-vervallen kaarten. Zo nee, en het gaat om een bruidsschat activiteit, dan wordt deze imowid veralgemeniseert met //9999// als gemeentecode (dus bijvoorbeeld //nl.imow-gm9999.activiteit.DierenSlachten//) en nog een keer gezocht in tbsrttoestemming. Nog niet gevonden dan wordt nog een keer gezocht op de tag ''<activiteitnaam>''. Indien nog steeds niet gevonden  dan wordt in tbsrttoestemming een nieuw record aangemaakt met de activiteitsnaam en (de eventueel veralgemeniseerde) imowid.
 Wel gevonden, en er is precies één of er zijn meerderere kandidaten dan wordt degene met de laagste (oudste) primary key genomen: in het geval van meerdere kandidaten krijgen de overige kandidaten een vervaldatum.\\
 De primary key van de gevonden of zojuist aangemaakte kaart in tbsrttoestemming wordt in combinatie met de primary key van de omgevingszaak opgezocht in tbtoestemmingen.dnkeyomgvergunningen en tbtoestemmingen.dnkeysrttoestemming. Indien NIET gevonden dan wordt een nieuwe kaart aangemaakt in tbtoestemmingen. De projectactiviteit is hiermee gekoppeld aan de omgevingszaak. De unieke DSO activiteit-id's, waarin ook een bevoegd gezag code is opgenomen, alsmede de onderliggende subactiviteitsnaam (indien van toepassing) worden bij de activiteit van de omgevingszaak overgenomen.
@@ Regel 306: / Regel 312: @@
 === Specificaties (vragen en antwoorden per activiteit)===
-Bij Initiëren, Indienen en Conceptverzoek en Aanvullen en Intrekken. De gegevens uit het blok ''<projectactiviteit>'' ''<specificaties>'' worden opgenomen in de dochtertabel tbdsospecificaties bij de activiteit (tbtoestemmingen) (omgevingstegel //Onderdelen/Activiteiten//: lijst in het detailscherm van activiteit). Per blok <specificatie> wordt op grond van de tag ''<vraagId>'' en de primary key in tbtoestemmingen van de activiteit gezocht of deze combinatie voorkomt in de tabel tbdsospecificates (dvdsovraagid en dnkeytoestemmingen). \\
-Zo nee dan wordt aldaar een nieuw record aangemaakt met de vraag en antwoord gegevens.\\
+Bij Initiëren, Indienen en Conceptverzoek en Aanvullen en Intrekken. De gegevens uit het blok ''<projectactiviteit>'' ''<specificaties>'' worden opgenomen in de dochtertabel tbdsospecificaties bij de activiteit (tbtoestemmingen) (omgevingstegel //Onderdelen/Activiteiten//: lijst in het detailscherm van activiteit). Per blok ''<specificatie>'' wordt op grond van de tag ''<vraagId>'' en de primary key in tbtoestemmingen van de activiteit gezocht of deze combinatie voorkomt in de tabel tbdsospecificates (dvdsovraagid en dnkeytoestemmingen).
-Zo ja (doel = aanvullen) en het antwoord op de vraag wijkt af van het reeds opgeslagen antwoord, dan wordt de kolom volgnr gevuld met het volgnummer van de aanvulling en het nieuwe antwoord in de kolom dvdsoantwoord geplaatst en - indien tag <oorsprantwoord>  gevuld - de kolom dvdsooorsprantwoord overschreven met de tag <oorsprantwoord> uit het bericht.
+Zo nee dan wordt aldaar een nieuw record aangemaakt met de vraag en antwoord gegevens.
+Zo ja (doel = aanvullen) en het antwoord op de vraag wijkt af van het reeds opgeslagen antwoord, dan wordt de kolom volgnr gevuld met het volgnummer van de aanvulling en het nieuwe antwoord in de kolom dvdsoantwoord geplaatst en - indien tag <oorsprantwoord>  gevuld - de kolom dvdsooorsprantwoord overschreven met de tag ''<oorsprantwoord>'' uit het bericht.
 === Mapping antwoorden uit specificaties op grond van vraagid ===
@@ Regel 335: / Regel 342: @@
 De vraagid voor deze vraag in het DSO-verzoek = 380711.//
 Het is de bedoeling dat het antwoord met het wegnummer terechtkomt in tbzaakkadperc (de projectlocaties) en dat de betreffende kaart in tbzaakkadperc gelijk de status hoofdprojectlocatie krijgt.
-In de tabel tbdsospecvraagid moet een kaart aangemaakt worden met //vraagid// = 380711. De kolom //ga naar tabel// met gevuld worden met tbzaakkadperc.\\
+In de tabel tbdsospecvraagid moet een kaart aangemaakt worden met //vraagid// = 380711. De kolom //ga naar tabel// met gevuld worden met tbzaakkadperc.
 Bij de verwerking van een DSO-verzoek wordt altijd een kaart aangemaakt in tbzaakkadperc met de projectlocatie. Dit is al gebeurd voordat de specificaties worden behandeld. Het //select statement primary key van ga-naar-tabel// om deze kaar te vinden wordt dan:
@@ Regel 349: / Regel 356: @@
 === Opnemen kwaliteitsborger als contactpersoon op grond van specificatie-groepen kwaliteitsborger ===
 Indien
   * er een adresrol (beheertegel //Adressoorten//) bestaat waarbij de kolom //Is rol voor kwaliteitsborger uit verzoekbericht DSO// (dldsorolkwaliteitsborger) is aangevinkt
@@ Regel 368: / Regel 376: @@
 Bij Initiëren, Indienen en Conceptverzoek en Aanvullen en Intrekken.
-De gegevens uit de blokken ''<projectactiviteit>'' ''<specificaties>'' ''<gevraagdeBijlage>'' worden opgenomen in de dochtertabel tbdsogevrbijlages bij de specificatie (tbdsospecificaties) (omgevingstegel //Onderdelen/Activiteiten//: lijst in het detailscherm van specificatie bij activiteit).\\
+De gegevens uit de blokken ''<projectactiviteit>'' ''<specificaties>'' ''<gevraagdeBijlage>'' worden opgenomen in de dochtertabel tbdsogevrbijlages bij de specificatie (tbdsospecificaties) (omgevingstegel //Onderdelen/Activiteiten//: lijst in het detailscherm van specificatie bij activiteit).
 Per blok ''<gevraagdeBijlage>'' wordt op grond van de tag ''<documentsoortDSO>'' en de primary key in tbdsospecificaties van het betrokken vraag/antwoord gezocht of deze combinatie voorkomt in de tabel tbdsogevrbijlages (dvdsodocumentsoort en dnkeydsospecificaties). Zo nee dan wordt aldaar een nieuw record aangemaakt met de gevraagde bijlage gegevens.
-=== Documenten per gevraagde bijlage per specificatie===
+=== Documenten per gevraagde bijlage per specificatie ===
 Bij Initiëren en Vooroverleg en Aanvullen en Intrekken.
@@ Regel 396: / Regel 404: @@
 ===== Negeren van binnenkomende kopieberichten =====
 In het kader van afhandelen complexe verzoeken in samenwerkingsverband, wordt er eerst gekeken of het te verwerken bericht genegeerd moet worden.
 Dat wil zeggen of het gaat om een zogenaamd kopiebericht.
@@ Regel 411: / Regel 420: @@
 Indien het kopiebericht toch moet worden opgeslagen (indien geen compartiment en de instelling //Sectie: DSO en Item: KopieberichtenOpslaan// is **WEL** aangevinkt of wel compartiment en //dldsoKopieberichtenOpslaan// heeft **waarde T**), dan krijgt het verzoeknummer de postfix '_KCV'.
-{{openwave:applicatiebeheer:probleemoplossing:programmablokken:dsozwartegatenenkopieberichten.png?900|}}
+{{openwave:applicatiebeheer:probleemoplossing:programmablokken:dsozwartegatenenkopieberichten.png?900|dsozwartegatenenkopieberichten}}
 ===== Vervolgacties =====
 Na het verwerken van het verzoekbericht kunnen één of meer van onderstaande vervolgacties plaatsvinden indien het om Initiëren, Indienen of Conceptverzoek gaat.
 Indien Aanvullen dan is alleen vervolgactie DSO ontvangstbevestiging sturen mogelijk.
 ==== Ophalen processtappen ====
 Het zaaktype van de omgevingskaart kan gekoppeld zijn aan één of meer processen. De bijbehorende processtappen worden automatisch aan de nieuwe zaak toegevoegd indien het attribuut //automatisch// bij die koppelingen aangevinkt is (beheertegel //Zaaktypes omgeving//. Detailscherm bij zaaktype en daarbinnen lijst gekoppelde processen).
 ==== Ophalen checklijsten ====
 Het zaaktype van de omgevingskaart kan gekoppeld zijn aan processen die automatisch aan de nieuwe zaak kunnen worden toegevoegd (zie hierboven). Indien aan een automatisch toegevoegd proces één of meer checklijsten zijn verbonden die ook de eigenschap //automatisch toevoegen// hebben (tbkopproccheck.dlauto = 'T'), dan worden deze checklijsten automatisch toegevoegd bij de zaak.
 ==== Automatisch aanmaken zaak in extern zaak/DMS ====
 Dit is het geval indien:
   * er GEEN sprake is van een compartiment EN de instelling //Koppeling ZAAK// en //Item: AutoZaakDmsOmgeving// is aangevinkt
@@ Regel 431: / Regel 444: @@
 ==== Automatisch aanmaken mappen op fileshare ====
 Indien
   * de zaak NIET valt onder een compartiment:
@@ Regel 443: / Regel 457: @@
 ==== Automatisch vullen van kolom dvhyperlink ====
 Zie: [[openwave:1.32:applicatiebeheer:instellen_inrichten:hyperlink]].
 ==== Automatisch sturen van DSO Ontvangstbevestiging ====
 Dit is het geval indien:
   * instelling //Sectie: DSO en Item: OntvangstBevestAutoVersturen// aan is gevinkt
@@ Regel 455: / Regel 471: @@
 ==== Ophalen en registreren van bijlages en verzoek.pdf ====
-Indien de instelling //Sectie: OWB en Item: OphalenDSODocsViaApi// is aangevinkt EN de instelling //Sectie: DocumentRegistreren en Item: AlleOLODSOUploads// is ook aangevinkt (of de kolom tbcompartiment.dldocregalleolodsouploads indien het gaat om een compartiment) dan worden alle DSO-documenten automatisch opgehaald door OpenWave zelf na het verwerken van een DSO-verzoekbericht (ook het verzoek.pdf). En dus niet meer door de digi-koppelaar.\\
+Indien de instelling //Sectie: OWB en Item: OphalenDSODocsViaApi// is aangevinkt EN de instelling //Sectie: DocumentRegistreren en Item: AlleOLODSOUploads// is ook aangevinkt (of de kolom tbcompartiment.dldocregalleolodsouploads indien het gaat om een compartiment) dan worden alle DSO-documenten automatisch opgehaald door OpenWave zelf na het verwerken van een DSO-verzoekbericht (ook het verzoek.pdf). En dus niet meer door de digi-koppelaar.
 In dat geval worden binnengeschoten documenten door de digi-koppelaar op het endpoint //<nowiki>https://[serveradres]/dso/bestanden/index.php</nowiki>// genegeerd zie [[openwave:1.32:applicatiebeheer:probleemoplossing:programmablokken:upload_dso-document_vanuit_digi-koppelaar]].
-OpenWave zal met de aangevinkte instelling //Sectie: OWB en Item: OphalenDSODocsViaApi// na het verwerken van het verzoekbericht de tabel tbomgoloberichten doorlopen van de betreffende omgevingzaak en per document nagaan of deze aanwezig is in de geregistreerde documenten (tbcorrespondentie). Het DSO-registratienummer van het document (tbomgoloberichten.dvolomessageid) wordt hiertoe opgezocht in de kolom dvdmskenmerk van tbcorrespondentie bij dezelfde omgevingzaak bij de rijen met dvuitolodsoswf = //D//. Vanaf de uitlevering versie 1.29 zijn de DSO documenten in tbcorrespondentie voorzien van dat registratienummer.\\
+OpenWave zal met de aangevinkte instelling //Sectie: OWB en Item: OphalenDSODocsViaApi// na het verwerken van het verzoekbericht de tabel tbomgoloberichten doorlopen van de betreffende omgevingzaak en per document nagaan of deze aanwezig is in de geregistreerde documenten (tbcorrespondentie). Het DSO-registratienummer van het document (tbomgoloberichten.dvolomessageid) wordt hiertoe opgezocht in de kolom dvdmskenmerk van tbcorrespondentie bij dezelfde omgevingzaak bij de rijen met dvuitolodsoswf = //D//. Vanaf de uitlevering versie 1.29 zijn de DSO documenten in tbcorrespondentie voorzien van dat registratienummer.
 Indien het document niet aanwezig is wordt deze opgehaald door aanroep van de DSO-verzoekafhandelen-API en vervolgens geplaatst op de tempmap (zie kolom //Tekst// van //Sectie: OWB en Item: TussenMapDSOUploadfiles//). De DSO-verzoekafhandelen-API wordt aangeroepen met het originele DSO-verzoeknummer: dus zonder prefix of postfix.\\
 Het opgehaalde document wordt geplaatst op de tussenmap onder de naam: DSO-verzoeknummer (nu wel inclusief postfix indien bijv. kopiebericht) + '_' + dvdsovolgnr uit tbomgoloberichten + '-' + dvlvobestandnaam uit tbomgoloberichten. Vervolgens wordt de interne API uploadfile aangeroepen met o.a. de bestandsnaam op de tussenmap en het registratienummer als parameters,  die het document registreert en opslaat op het ingestelde medium (fileserver of DMS).
@@ Regel 475: / Regel 492: @@
 ==== Ophalen van DSO Verzoek.xml ====
 Indien de instellingen:
   * //Sectie: OWB en Item: OphalenDSODocsViaApi// EN
@@ Regel 482: / Regel 500: @@
 === De verzoek XML automatisch converteren naar PDF ====
 Niet elk DMS is in staat om het bestandstype .xml te accepteren. Om alsnog het verzoekbericht in de originele staat op te slaan is het mogelijk om het bericht direct te converteren naar het bestandstype .pdf.
 Hiervoor dient de instelling //Sectie: DSO en Item: VerzoekXMLnaarPDF// aangevinkt te zijn.
@@ Regel 493: / Regel 512: @@
 ==== Aanpassen kolom drop publiceren?====
 De kolom **DROP Publiceren ?** (dlzaakpubliceren) in het blok keten van het detailscherm van de aangemaakte omgevingzaak krijgt als defaultwaarde normaal de waarde 'T'. Bij het verwerken van een DSO verzoekbericht tot een nieuwe zaak kan hiervan afgeweken worden indien alle toegevoegd activiteiten bij die zaak de eigenschap tbsrttoestemming.dlnietpublicerendrop op T hebben staan. In het zaakbeheerportaal onder de kolom Afhandeling achter de tegel //Soort activiteit/onderdeel// kan per soort activiteit aangegeven worden of de activiteit NIET gepubliceerd hoeft te worden in DROP.\\
 <adm warning>