Verschillen

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

--- openwave:1.34:applicatiebeheer:probleemoplossing:programmablokken:verwerking_dso_stam_berichten [2026/03/06 12:30] – [Betrokkene] Marc Pullens
+++ openwave:1.34:applicatiebeheer:probleemoplossing:programmablokken:verwerking_dso_stam_berichten [2026/05/06 16:27] (huidige) – [Automatisch sturen van DSO Ontvangstbevestiging] Charlie Kluin
@@ Regel 72: / Regel 72: @@
 De gegevens in deze tabel tbDSOtrigger worden opgeschoond na 31 dagen tenzij anders aangegeven in kolom //Getal1// van de instelling //Sectie: DSO en Item: BewaardagenTabelDsoTrigger//.
-Het DSO heeft een versienummer aan het Verzoeknotificatiebericht toegekend, gelijk aan dat er voor STAM bericht versies bestaan. Huidig kent het DSO versie 4 en 5 van de verzoeknotificatie. Beide versies kan OpenWave verwerken. Met deze versie doet OpenWave verder niets. Het instellen van welke versie per OIN gewenst is hangt samen met (maar is niet gelijk aan het instellen van) de STAM versie bij het DSO. Voor het omzetten naar versie 5 dient een API van het DSO aangeroepen te worden om dit te configureren. Dit zal per bevoegd gezag/OIN gedaan moeten worden. REM kan hierbij ondersteunen.  De digikoppelaar zal vervolgens ervoor zorgen dat het verzoek bericht in de corresponderende STAM versie wordt opgevraagd.
+Het DSO heeft een versienummer aan het Verzoeknotificatiebericht toegekend, gelijk aan dat er voor STAM bericht versies bestaan. Huidig kent het DSO versie 5 en 6 van de verzoeknotificatie. Beide versies kan OpenWave verwerken. Met deze versie doet OpenWave verder niets. Het instellen van welke versie per OIN gewenst is hangt samen met (maar is niet gelijk aan het instellen van) de STAM versie bij het DSO. Voor het omzetten naar versie 5 dient een API van het DSO aangeroepen te worden om dit te configureren. Dit zal per bevoegd gezag/OIN gedaan moeten worden. REM kan hierbij ondersteunen.  De digikoppelaar zal vervolgens ervoor zorgen dat het verzoek bericht in de corresponderende STAM versie wordt opgevraagd.
 ===== Verplichte instellingen =====
@@ Regel 90: / Regel 90: @@
 ==== Doel ====
-<adm STAM 5 versus STAM 4>
+Uit de tag ''<doel>'' wordt bepaald of het bericht gaat over Indienen, Aanvullen of Intrekken. In de tag ''<type>'' staan de  mogelijke waardes: Concept, Definitief, Idee. Het type geeft aan of het om een Conceptverzoek, Definitieve aanvraag of een VerkenUwIdee gaat.
-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.
   * 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.
   * Indien **Intrekken** dan wordt de kaart gezocht in tbomgvergunning met dvlvoaanvraagnr = verzoeknummer. Indien niet gevonden of er zijn meerdere gevonden 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.
-  * Indien **Conceptverzoek** of **Initiëren** of **Indienen** dan wordt in principe altijd een nieuwe kaart gemaakt in TbOmgvergunning.
+  * Indien **Indienen** dan wordt in principe altijd een nieuwe kaart gemaakt in TbOmgvergunning.
 ==== Locatie ====
-Alleen bij Initiëren/Indienen en Conceptverzoek.
+Alleen bij Indienen.
 Uit blok ''<projectlocaties>'' wordt alleen de informatie uit het eerste sub blok ''<projectlocatie>'' gebruikt om de nieuwe zaak te koppelen aan precies één OpenWave locatie (tbperceeladressen). Als volgt:
@@ Regel 118: / Regel 112: @@
 ==== Zaaktype ====
-Alleen bij Initiëren/Indienen en Conceptverzoek.
+Alleen bij Indienen.
 De volgende (plicht)types kunnen worden aangeleverd in het verzoekbericht:
@@ Regel 141: / Regel 135: @@
   * Indien de zaak NIET voor een compartiment is dan:
-    * Indien doel = Initiëren (STAM 4) of doel = Indienen EN type = Definitief (STAM 5), dan wordt in deze tabel de - niet vervallen - kaart opgezocht waar Verzoektype (dvdsotype) gelijk is aan de waarde van de aangeleverde tag ''<Type>'' (STAM 4) of tag ''<Plicht>'' (STAM 5) EN waarbij //Is zaaktype vooroverleg DSO// (dlisdsovooroverleg) **NIET** is aangevinkt EN waarbij //Zaaktype is exclusief voor compartiment// (dlW055) **NIET** is aangevinkt. |  Dat moet er precies één zijn anders wordt de verwerking gestopt (zie kolom //Error// in messagelog).
+    * Indien doel = = Indienen EN type = Definitief, dan wordt in deze tabel de - niet vervallen - kaart opgezocht waar Verzoektype (dvdsotype) gelijk is aan de waarde van de aangeleverde tag  ''<Plicht>'' EN waarbij //Is zaaktype vooroverleg DSO// (dlisdsovooroverleg) **NIET** is aangevinkt EN waarbij //Zaaktype is exclusief voor compartiment// (dlW055) **NIET** is aangevinkt. |  Dat moet er precies één zijn anders wordt de verwerking gestopt (zie kolom //Error// in messagelog).
-    *  Indien doel = Conceptverzoek (STAM 4) of doel = Indienen EN type = Concept (STAM 5), dan wordt in deze tabel de - niet vervallen - kaart opgezocht waar Verzoektype (dvdsotype) gelijk is aan de waarde van de aangeleverde tag ''<Type>'' (STAM 4) of tag ''<Plicht>'' (STAM 5) EN waarbij //Is zaaktype vooroverleg DSO// (dlisdsovooroverleg) WEL is aangevinkt EN waarbij //Zaaktype is exclusief voor compartiment// (dlW055) **NIET** is aangevinkt.. Dat moet er precies één zijn anders wordt de verwerking gestopt (zie kolom //Error// in messagelog).
+    *  Indien doel = Indienen EN type = Concept, dan wordt in deze tabel de - niet vervallen - kaart opgezocht waar Verzoektype (dvdsotype) gelijk is aan de waarde van de aangeleverde tag ''<Plicht>'' EN waarbij //Is zaaktype vooroverleg DSO// (dlisdsovooroverleg) WEL is aangevinkt EN waarbij //Zaaktype is exclusief voor compartiment// (dlW055) **NIET** is aangevinkt.. Dat moet er precies één zijn anders wordt de verwerking gestopt (zie kolom //Error// in messagelog).
-    *  Indien doel = Indienen EN type = Idee (STAM 5) dan wordt in deze tabel de - niet vervallen - kaart opgezocht waarbij //Is zaaktype Verken Uw Idee DSO// (dlisdsoverkenuwidee) WEL is aangevinkt EN waarbij //Zaaktype is exclusief voor compartiment// (dlW055) **NIET** is aangevinkt (Verzoektype wordt niet naar gekeken en is idealiter leeg want wordt niet aangegeven bij VerkenUwIdee)
+    *  Indien doel = Indienen EN type = Idee  dan wordt in deze tabel de - niet vervallen - kaart opgezocht waarbij //Is zaaktype Verken Uw Idee DSO// (dlisdsoverkenuwidee) WEL is aangevinkt EN waarbij //Zaaktype is exclusief voor compartiment// (dlW055) **NIET** is aangevinkt (Verzoektype wordt niet naar gekeken en is idealiter leeg want wordt niet aangegeven bij VerkenUwIdee)
   * Indien de zaak WEL voor een compartiment is dan:
-    * Indien doel = Initiëren (STAM 4) of doel = Indienen EN type = Definitief (STAM 5), dan wordt in deze tabel de - niet vervallen - kaart opgezocht waar Verzoektype (dvdsotype) gelijk is aan de waarde van de aangeleverde tag ''<Type>'' (STAM 4) of tag ''<Plicht>''(STAM 5) EN waarbij //Is zaaktype vooroverleg DSO// (dlisdsovooroverleg) NIET is aangevinkt EN waarbij //Zaaktype is exclusief voor compartiment// (dlW055) **WEL** is aangevinkt EN waarbij in de compartimentszakentabel tbkopcompsrtomgverg bij het betreffende compartiment een rij bestaat die gerelateerd is aan deze tbsoortomgvergkaart. Indien op deze wijze geen unieke kaart gevonden in tbsoortomgverg dan redeneert OpenWave dat de zaak toch niet voor een compartiment is en zoekt opnieuw in tbsoortomgverg waarbij //Zaaktype is exclusief voor compartiment// (dlW055) **NIET** is aangevinkt.
+    * Indien doel = Indienen EN type = Definitief, dan wordt in deze tabel de - niet vervallen - kaart opgezocht waar Verzoektype (dvdsotype) gelijk is aan de waarde van de aangeleverde  tag ''<Plicht>'' EN waarbij //Is zaaktype vooroverleg DSO// (dlisdsovooroverleg) NIET is aangevinkt EN waarbij //Zaaktype is exclusief voor compartiment// (dlW055) **WEL** is aangevinkt EN waarbij in de compartimentszakentabel tbkopcompsrtomgverg bij het betreffende compartiment een rij bestaat die gerelateerd is aan deze tbsoortomgvergkaart. Indien op deze wijze geen unieke kaart gevonden in tbsoortomgverg dan redeneert OpenWave dat de zaak toch niet voor een compartiment is en zoekt opnieuw in tbsoortomgverg waarbij //Zaaktype is exclusief voor compartiment// (dlW055) **NIET** is aangevinkt.
-    * Indien doel = Conceptverzoek (STAM 4) of doel = Indienen EN type = Concept (STAM 5), dan wordt in deze tabel de - niet vervallen - kaart opgezocht waar Verzoektype (dvdsotype) gelijk is aan de waarde van de aangeleverde tag ''<Type>'' (STAM 4) of tag ''<Plicht>'' (STAM 5) EN waarbij //Is zaaktype vooroverleg DSO// (dlisdsovooroverleg) WEL is aangevinkt EN waarbij //Zaaktype is exclusief voor compartiment// (dlW055) **WEL** is aangevinkt EN waarbij in de compartimentszakentabel tbkopcompsrtomgverg bij het betreffende compartiment een rij bestaat die gerelateerd is aan deze tbsoortomgverg-kaart. Indien op deze wijze geen unieke kaart gevonden in tbsoortomgverg dan redeneert OpenWave dat de zaak toch niet voor een compartiment is en zoekt opnieuw in tbsoortomgverg waarbij //Zaaktype is exclusief voor compartiment// (dlW055) **NIET** is aangevinkt.
+    * Indien doel  = Indienen EN type = Concept, dan wordt in deze tabel de - niet vervallen - kaart opgezocht waar Verzoektype (dvdsotype) gelijk is aan de waarde van de aangeleverde  tag ''<Plicht>''  EN waarbij //Is zaaktype vooroverleg DSO// (dlisdsovooroverleg) WEL is aangevinkt EN waarbij //Zaaktype is exclusief voor compartiment// (dlW055) **WEL** is aangevinkt EN waarbij in de compartimentszakentabel tbkopcompsrtomgverg bij het betreffende compartiment een rij bestaat die gerelateerd is aan deze tbsoortomgverg-kaart. Indien op deze wijze geen unieke kaart gevonden in tbsoortomgverg dan redeneert OpenWave dat de zaak toch niet voor een compartiment is en zoekt opnieuw in tbsoortomgverg waarbij //Zaaktype is exclusief voor compartiment// (dlW055) **NIET** is aangevinkt.
-    * Indien doel = Indienen EN type = Idee (STAM 5) dan wordt in deze tabel de - niet vervallen - kaart opgezocht waarbij //Is zaaktype Verken Uw Idee DSO// (dlisdsoverkenuwidee) WEL is aangevinkt EN waarbij //Zaaktype is exclusief voor compartiment// (dlW055) **WEL** is aangevinkt EN waarbij in de compartimentszakentabel tbkopcompsrtomgverg bij het betreffende compartiment een rij bestaat die gerelateerd is aan deze tbsoortomgverg-kaart (Verzoektype wordt niet naar gekeken en is idealiter leeg want wordt niet aangegeven bij VerkenUwIdee). Indien op deze wijze geen unieke kaart gevonden in tbsoortomgverg dan redeneert OpenWave dat de zaak toch niet voor een compartiment is en zoekt opnieuw in tbsoortomgverg waarbij //Zaaktype is exclusief voor compartiment// (dlW055) **NIET** is aangevinkt.
+    * Indien doel = Indienen EN type = Idee  dan wordt in deze tabel de - niet vervallen - kaart opgezocht waarbij //Is zaaktype Verken Uw Idee DSO// (dlisdsoverkenuwidee) WEL is aangevinkt EN waarbij //Zaaktype is exclusief voor compartiment// (dlW055) **WEL** is aangevinkt EN waarbij in de compartimentszakentabel tbkopcompsrtomgverg bij het betreffende compartiment een rij bestaat die gerelateerd is aan deze tbsoortomgverg-kaart (Verzoektype wordt niet naar gekeken en is idealiter leeg want wordt niet aangegeven bij VerkenUwIdee). Indien op deze wijze geen unieke kaart gevonden in tbsoortomgverg dan redeneert OpenWave dat de zaak toch niet voor een compartiment is en zoekt opnieuw in tbsoortomgverg waarbij //Zaaktype is exclusief voor compartiment// (dlW055) **NIET** is aangevinkt.
 In alle gevallen wordt bij het gevonden zaaktype uit tbsoortomgverg de fatale periode en masker van de wavezaakcode opgehaald.
@@ Regel 153: / Regel 147: @@
 ==== Project ====
-Alleen bij Initiëren/Indienen en Conceptverzoek.
+Alleen bij Indienen.
 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//).
@@ Regel 161: / Regel 155: @@
 ==== Maak nieuw of zoek bestaande zaak in tbomgvergunning ====
-  * Indien **Initiëren/Indienen of Conceptverzoek** dan wordt een nieuwe zaak aangemaakt onder het gevonden zaaktype (dnkeysoortomgverg), project (dnkeydsoproject) en bij de gevonden locatie (dnkeyperceeladressen), waarbij de kolom dvlvoaanvraagnr met het verzoeknummer wordt gevuld en de kolom dlisdso met 'T'. Bij de omgevingszaak worden de niet-repetitieve gegevens overgenomen op het detailniveau van de zaak (tags: ''<naam>'', ''<indiendatum>'', ''<ambtshalve>'', ''<doel>'', ''<volgnummer>'' e.d.). Op grond van zaaktype (masker en fatale termijn) wordt dvzaakcode berekend en de fatale datum. Bij //Vooroverleg// wordt de kolom ddvooroverleg gevuld met de indieningsdatum van het bericht.
+  * Indien **Indienen** dan wordt een nieuwe zaak aangemaakt onder het gevonden zaaktype (dnkeysoortomgverg), project (dnkeydsoproject) en bij de gevonden locatie (dnkeyperceeladressen), waarbij de kolom dvlvoaanvraagnr met het verzoeknummer wordt gevuld en de kolom dlisdso met 'T'. Bij de omgevingszaak worden de niet-repetitieve gegevens overgenomen op het detailniveau van de zaak (tags: ''<naam>'', ''<indiendatum>'', ''<ambtshalve>'', ''<doel>'', ''<volgnummer>'' e.d.). Op grond van zaaktype (masker en fatale termijn) wordt dvzaakcode berekend en de fatale datum. Bij //Vooroverleg// wordt de kolom ddvooroverleg gevuld met de indieningsdatum van het bericht.
   * Indien **Aanvullen of Intrekken** dan wordt de omgevingszaak opgezocht op grond van verzoeknummer (op kolom dvlvoaanvraagnr) en worden de kolommen //volgnummer// en //doel// bijgewerkt. Bovendien 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.
 ==== Projectlocaties ====
-Alleen bij Initiëren/Indienen en Conceptverzoek.
+Alleen bij Indienen.
 Alle gegevens uit het blok ''<projectlocaties>'' worden opgenomen in de dochtertabel tbzaakkadperc bij de omgevingszaak. Omgevingstegel: //Projectlocaties\kadastrale percelen//. Met STAM 6 bestaat de ingang ''<projectlocaties>'' niet meer: er is nog maar één blok <projectlocatie>\\
@@ Regel 178: / Regel 172: @@
 ==== Bevoegd gezag ====
-Alleen bij Initiëren/Indienen en Conceptverzoek.
+Alleen bij Indienen.
 Het OIN-nummer uit blok ''<bevoegdGezag>'' van de tag ''<oin>'' wordt opgezocht in tboin (beheertegel //OIN-nummers//). Indien deze niet bestaat wordt het OIN-nummer aangemaakt in deze tabel. In de omgevingszaak komt een verwijzing naar het tboin-record (dnkeyoinbevgez).
@@ Regel 184: / Regel 178: @@
 ==== Bevoegd gezag historie ====
-Alleen bij Initiëren en Vooroverleg.
+Alleen bij Indienen.
 De gegevens uit het blok ''<bevoegdGezagHistorie>'' worden opgenomen in de dochtertabel tbomgbevgezhistorie bij de omgevingszaak. Per blok ''<bevoegdGezag>'' wordt een kaart aangemaakt in deze tabel (omgevingstegel //Historie DSO Bevoegd gezag//). Het OIN-nummer uit de tag ''<oin>'' wordt daarbij opgezocht in tboin (beheertegel //OIN-nummers//). Indien deze niet bestaat wordt het OIN-nummer aangemaakt in deze tabel. In de tbomgbevgezhistorie-kaart komt een verwijzing naar het tboin-record (dnkeyoin).
@@ Regel 190: / Regel 184: @@
 ==== Uitvoerende instantie ====
-Alleen bij Initiëren/Indienen en Conceptverzoek.
+Alleen bij Indienen.
 Het OIN-nummer uit blok ''<uitvoerendeInstantie>'' van de tag ''<oin>'' wordt opgezocht in tboin (beheertegel //OIN-nummers//). Indien deze niet bestaat wordt het OIN-nummer aangemaakt in deze tabel. In de omgevingszaak komt een verwijzing naar het tboin-record (dnkeyoinuitvinst).
-=== Uitvoerende instantiehistorie ===
+==== Uitvoerende instantiehistorie ====
-Alleen bij Initiëren/Indienen en Conceptverzoek.
+Alleen bij Indienen.
 De gegevens uit het blok ''<uitvoerendeInstantieHistorie>'' worden opgenomen in de dochtertabel tbomguitvinsthistorie bij de omgevingszaak. Per blok ''<uitvoerendeInstantie>'' wordt een kaart aangemaakt in deze tabel (omgevingstegel //Historie DSO Behandeldienst//). Het OIN-nummer uit de tag ''<oin>'' wordt daarbij opgezocht in tboin (beheertegel //OIN-nummers//). Indien deze niet bestaat wordt het OIN-nummer aangemaakt in deze tabel. In de tbomguitvinsthistorie-kaart komt een verwijzing naar het tboin-record (dnkeyoin).
@@ Regel 202: / Regel 196: @@
 ==== Dossierbehandelaar ====
-Alleen bij //Initiëren/Indienen en Conceptverzoek//.
+Alleen bij Indienen.
 Er wordt een nieuwe kaart gemaakt in de dochtertabel tbinbehandelingbij bij de omgevingszaak met de medewerkerscode die als default behandelaar (dvcodedefbehandelaar) is toegekend aan het zaaktype (tbsoortomgverg). Indien de zaak in een compartiment wordt afgehandeld gaat het om de default behandelaar uit tbkopcompsrtomgverg (beheertegel //Compartimentrechten//). Indien deze default waardes ontbreken dan valt OpenWave terug op de verplichte instelling //Sectie: Koppeling OLO// en //Item: Dossierbehandelaar//.
@@ Regel 223: / Regel 217: @@
 De Contactpersoon aanmaken gaat vervolgens als volgt:
-  * Bij Initiëren, Indienen en Conceptverzoek en Aanvullen. De gegevens uit blok ''<contactpersoon>'' 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 = de rol/adressoort die in de beheertabel //Adressoorten/rollen// aangemerkt is als //Is rol voor contactpersoon uit verzoekbericht DSO//. 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 zoekt of de contactpersoon reeds bestaat in tbcontactadressen op de tag ''<emailadres>'' (moet dus wel gevuld zijn) EN op de tag ''<achternaam>'' (moet dus wel gevuld zijn) EN op de eerste positie van de tag ''<voorletters>'' (moet dus wel gevuld zijn) EN contact mag niet vervallen zijn. Indien geen unieke kaart gevonden wordt een nieuwe kaart aangemaakt in tbcontactadressen.
+  * Bij Indienen en Aanvullen. De gegevens uit blok ''<contactpersoon>'' 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 = de rol/adressoort die in de beheertabel //Adressoorten/rollen// aangemerkt is als //Is rol voor contactpersoon uit verzoekbericht DSO//. 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 **Indienen** - , dan zal een nieuwe relatie gelegd moeten worden naar een nieuw aan te maken of reeds bestaande adreskaart in OpenWave. OpenWave zoekt of de contactpersoon reeds bestaat in tbcontactadressen op de tag ''<emailadres>'' (moet dus wel gevuld zijn) EN op de tag ''<achternaam>'' (moet dus wel gevuld zijn) EN op de eerste positie van de tag ''<voorletters>'' (moet dus wel gevuld zijn) EN contact mag niet vervallen zijn. Indien geen unieke kaart gevonden wordt een nieuwe kaart aangemaakt in tbcontactadressen.
 Wat betreft het overnemen/overschrijven van adresgegevens redeneert OpenWave chronologisch als volgt:
@@ Regel 240: / Regel 234: @@
 </adm>
-//Bij Initiëren/Indienen en Conceptverzoek en Aanvullen//
+//Bij Indienen en Aanvullen//
-Een BSN-nummer bestaande uit 9 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.
+Een BSN-nummer bestaande uit 9 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 **Indienen** - , 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.
 <adm Altijd nieuw Niet Natuurlijk Contact aanmaken?>
@@ Regel 305: / Regel 299: @@
 </adm>
-//Bij Initiëren, Indienen en Conceptverzoek en Aanvullen//
+//Bij Indienen en Aanvullen//
 Een BSN-nummer bestaande uit 9 nullen beschouwd OpenWave als leeg.
@@ Regel 311: / Regel 305: @@
 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.
+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, 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 326: / Regel 320: @@
 == (vanaf STAM v6) ==
-//Bij Initiëren/Indienen en Conceptverzoek en Aanvullen// Het blok ''<betrokkene>'' is voorzien van het attribuut //rol// De betrokkene kan de rol initiatiefnemer hebben en de rol gemachtigde. Voor beide rollen is onderstaande proceslogica gelijk.
+//Bij Indienen en Aanvullen// Het blok ''<betrokkene>'' is voorzien van het attribuut //rol// De betrokkene kan de rol initiatiefnemer hebben en de rol gemachtigde. Voor beide rollen is onderstaande proceslogica gelijk.
 <adm warning>
@@ Regel 382: / Regel 376: @@
 Bovenstaande gegevens uit blok ''<betrokkene>'' 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// (indien rol = gemachtigde) of //'AVR// (indien rol = initiatiefnemer).
-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.  OpenWave zoekt naar de aanwezigheid van respectievelijk BSN, vestigingsnummer, RSIN en KvK-nummer in de bestaande niet vervallen kaarten van tbcontactadressen. Voor controle bij de NNP-nummers geldt ook nog dat de achternaam leeg moet zijn: dus geen persoon gekoppeld aan dat contactadres. Deze logica is gelijk voor zowel de aanvrager als de gemachtigde.
+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, dan zal een nieuwe relatie gelegd moeten worden naar een nieuw aan te maken of reeds bestaande adreskaart in OpenWave.  OpenWave zoekt naar de aanwezigheid van respectievelijk BSN, vestigingsnummer, RSIN en KvK-nummer in de bestaande niet vervallen kaarten van tbcontactadressen. Voor controle bij de NNP-nummers geldt ook nog dat de achternaam leeg moet zijn: dus geen persoon gekoppeld aan dat contactadres. Deze logica is gelijk voor zowel de aanvrager als de gemachtigde.
 Indien geen gegadigde wordt gevonden dan wordt een nieuwe kaart aangemaakt in tbcontactadressen.
@@ Regel 414: / Regel 408: @@
 ==== Activiteiten ====
-//Bij Initiëren en Vooroverleg en Aanvullen en Intrekken.//
+//Bij Aanvullen en Intrekken.//
 === Projectactiviteiten ===
@@ Regel 425: / Regel 419: @@
   * Meldingplicht dan met 'M'
   * Aanvraag vergunning dan met 'V'
+  * bij andere plichttypes krijgt tbtoestemmingen.dvmbaplicht de waarde null.
 === 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. 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.
+Bij Indienen 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. 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 487: / Regel 482: @@
 === Gevraagde bijlages per specificatie ===
-Bij Initiëren, Indienen en Conceptverzoek en Aanvullen en Intrekken.
+Bij Indienen 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). 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.
@@ Regel 493: / Regel 488: @@
 === Documenten per gevraagde bijlage per specificatie ===
-Bij Initiëren en Vooroverleg en Aanvullen en Intrekken.
+Bij Aanvullen en Intrekken.
 De gegevens uit de blokken ''<projectactiviteit>'' ''<specificaties>'' ''<gevraagdeBijlage>'' ''<documenten>'' worden opgenomen in de dochtertabel tbomgoloberichten bij de gevraagde bijlage (tbdsogevrbijlages) (omgevingstegel //Onderdelen/Activiteiten//: lijst in het detailscherm van gevraagde bijlages bij specificatie).
@@ Regel 505: / Regel 500: @@
 ==== Documenten verzoekbijlages ====
-Bij Initiëren, Indienen en Conceptverzoek en Aanvullen en Intrekken.
+Bij Indienen en Aanvullen en Intrekken.
 De gegevens uit het blok ''<verzoekbijlages>'' (gevraagde bijlages die niet direct aan een specificatie zijn te linken) worden ook opgenomen in de tabel tbomgoloberichten, maar dan zonder connectie naar een specificatie.
@@ Regel 539: / Regel 534: @@
 ===== 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.
+Na het verwerken van het verzoekbericht kunnen één of meer van onderstaande vervolgacties plaatsvinden indien het om Indienen gaat. Indien Aanvullen dan is alleen vervolgactie DSO ontvangstbevestiging sturen mogelijk.
 ==== Ophalen processtappen ====
@@ Regel 549: / Regel 544: @@
 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.
+==== Aanmaken van Extra kenmerken ====
+Het zaaktype van de omgevingskaart kan gekoppeld zijn aan vrij veldbetekenissen die automatisch aan de nieuwe zaak kunnen worden toegevoegd als Extra kenmerken. OF, indien er geen gekoppelde vrij veld betekenissen zijn, kunnen er in het beheer vrij veld betekenissen bestaan met kenmerk //Automatisch?// aangevinkt voor de omgevingsmodule. Is een van deze situaties waar dan worden er extra kenmerken aangemaakt bij de zaak.\\
+Voor meer informatie zie pagina [[openwave:1.34:applicatiebeheer:instellen_inrichten:vrijeveldenfunctionaliteit|Extra kenmerken (vrije velden) functionaliteit]].
+==== Interne betrokkenen ====
+Het zaaktype van de omgevingskaart kan gekoppeld zijn aan interne rollen die automatisch aan de nieuwe zaak worden toegevoegd als interne betrokkenen.
 ==== Automatisch aanmaken zaak in extern zaak/DMS ====
@@ Regel 583: / Regel 585: @@
   * instelling //Sectie: DSO en Item: OntvangstBevestAutoVersturen// aan is gevinkt
-  * doel van DSO STAM-bericht Initiëren, Vooroverleg, Conceptverzoek of Aanvullen is (dus niet bij Intrekken)
+  * doel van DSO STAM-bericht Indienen of Aanvullen is (dus niet bij Intrekken)
 Zie voor overige verplichte instellingen voor automatisch versturen van DSO ontvangstbevestiging bij  [[openwave:1.34:applicatiebeheer:probleemoplossing:programmablokken:dso_ontvangstbevestiging]].
@@ Regel 589: / Regel 591: @@
 ==== 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. In dat geval worden binnengeschoten documenten door de digi-koppelaar op het endpoint //%%https://[serveradres]/dso/bestanden/index.php%%// genegeerd zie [[openwave:1.34:applicatiebeheer:probleemoplossing:programmablokken:upload_dso-document_vanuit_digi-koppelaar]].
+Indien de instelling //Sectie: DocumentRegistreren en Item: AlleOLODSOUploads// is 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 de digi-koppelaar. In dat geval worden binnengeschoten documenten door de digi-koppelaar op het endpoint //%%https://[serveradres]/dso/bestanden/index.php%%// genegeerd zie [[openwave:1.34: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. 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).
+OpenWave zal altijd 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).
 Indien het document wel wordt gevonden in tbcorrespondentie dan zal OpenWave controleren dat indien de vervaldatum van tbomgoloberichten is gevuld, deze vervaldatum ook bij het geregistreerde document wordt toegevoegd.