Verwerking DSO STAM berichten [Documentatie]

Deze pagina is alleen-lezen. Je kan de broncode bekijken maar niet veranderen. Neem contact op met de beheerder als je denkt dat dit niet klopt.
====== Verwerking DSO STAM berichten ======

Zie ook:

  * [[openwave:1.34:applicatiebeheer:probleemoplossing:programmablokken:upload_dso-document_vanuit_digi-koppelaar]] 
  * [[openwave:1.34:applicatiebeheer:instellen_inrichten:testen_dso_erkmaatreg]]

De service laag van de OpenWave omgeving ontvangt deze DSO-berichten (een triggerbericht in xml-formaat en een verzoekbericht in xml-formaat en een Jnet/EnableU bericht in xml om een intrekking door te geven) op het endpoint /DSO/Verzoek/ als HTTPS:POST.

De luisterservice op /DSO/Verzoek -endpoint roept getAuthorisation aan met de loginnaam/pass uit de HTTPS en krijgt hierdoor een sessie identifier.

Met deze sessie identifier wordt (deze) API verwerkDSOVerzoekbericht aangeroepen met de sessie identifier als eerste en de xml als tweede parameter.

Alleen in het geval dat het binnengeschoten bericht geen verzoek- of trigger- of verzoeknotificatie- of Intrekbericht is, wordt een foutcode geretourneerd (naar de digi-koppelaar).

===== Loggen messagelog =====

De berichten worden gelogd indien de instelling //Sectie: DSO en Item: Messagelog// aangevinkt is (beheertegel //Messagelog//). Indien aangevinkt en //Getal1// is ongelijk aan 1, dan worden alleen de valide trigger- en verzoekberichten gelogd in Tbmessagelog (mits de algemene instelling //Sectie: OWB en Item: Messagelog// ook aangevinkt is). Indien //Getal1// de waarde 1 heeft, dan worden ook de niet valide berichten op het DSO-endpoint gelogd.

In geval dat het bericht valide is, maar door ontbrekende configuratie het bericht toch niet kan worden verwerkt, dan wordt de oorzaak van dit euvel in de messagelog in de kolom //Error// getoond.

===== Intrekbericht =====

Indien een aanvrager een verzoek heeft ingetrokken is het de digi-koppelaar (Jnet/EnableU) die in een eigen formaat deze boodschap doorgeeft:  <code xml>
<root>
  <oin>00000001001100415000</oin>
  <verzoeknummer>2022070500133</verzoeknummer>
  <actie>close</actie>
</root>
</code>

OpenWave vangt deze op en behandelt deze alsof het een verzoekbericht is met doel **intrekken**: zie hieronder.

===== Koppelbericht zaakcode bevoegd gezag aan DSO-verzoeknummer =====

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.34:applicatiebeheer:probleemoplossing:programmablokken:export_documenten_bij_dso_zaak_van_map_naar_dms_bevoegd_gezxag]]

<code json>
{
    "casetype_id": "f8285eb3-6fd2-4b9a-8663-dfd0df9767af",
    "requestor": {
        "reference": "12ee135b-719e-4000-a8f1-734ec79b1854",
        "id": {"kvk_number": "11016659"},
        "type": "company"
    },
    "source": "externe applicatie",
    "open": true,
    "values": {
        "oin": ["00000001001831112000"],
        "dso_verzoeknummer": ["2024022800277"],
        "dso_coordinatie": ["Nee"],
        "ztc_onderwerp": ["Asfaltonderhoud Barneveld 2024 - Dronkelaarseweg"],
        "dso_activiteit_naam": ["Graven in bodem met een kwaliteit onder of gelijk aan de interventiewaarde bodemkwaliteit"],
        "dso_bevoegd_gezag_naam": ["Gemeente Barneveld"],
        "dso_bevoegd_gezag_oin": ["00000001001831112000"],
     }
}
</code>

OpenWave zal het DSO-verzoeknummer uit het JSON bericht opzoeken in tbomgvergunning.dvlvoaanvraagnummer. Indien er één kandidaat wordt gevonden zal de externe zaakidentifier (de reference) worden geplaatst in de kolom dvzaaknrbevgezag.

<adm warning>

OpenWave heeft niet in de hand wanneer dit bericht verzonden wordt: dat kan dus theoretisch gebeuren voordat OpenWave zelf het betreffende DSO-verzoekbericht heeft verwerkt en in dat geval wordt de externe zaakidentifcatie niet gevuld in de kolom dvzaaknrbevgezag. Wel is altijd het bericht terug te lezen in de messagelog: daar kan dan alsnog de reference geknipt en geplakt worden.

</adm>

===== 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.

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.

===== Verplichte instellingen =====

  * In de beheertabel //Adressoorten/rollen// dient exact één kaart te bestaan waarbij het vakje //Is rol voor contactpersoon uit verzoekbericht DSO// (tbadressoort.dldsorolcontactpers) aangevinkt is. Deze rol is bedoeld voor de contactpersoon uit het DSO-verzoekbericht. Geldt niet meer voor STAM 6.
  * In de beheertabel //Adressoorten/rollen// dient exact één kaart te bestaan met code //AVR// die gebruikt wordt als aanvrager (initiatiefnemer).
  * In de beheertabel //Adressoorten/rollen// dient exact één kaart te bestaan met code //GEM// die gebruikt wordt als gemachtigde.
  * In de tabel met instellingen (beheertegel //Configuratie//) moet bestaan de kaart met //Sectie: Koppeling OLO// en //Item: Dossierbehandelaar//, waarbij kolom //Tekst// gevuld is met een waarde die overeenkomt met de code (tbmedewerkers.dvcode) van een (niet vervallen) kaart uit de medewerkerstabel. Dit wordt de default dossierbehandelaar bij ontbreken van de default-behandelaar in het zaaktype.
  * In de tabel met instellingen moet bestaan de kaart met //Sectie: Koppeling OLO Item: DummyLokatiePerceelkey// waarin //Getal2// verwijst naar een dnkey van een kaart in tbperceeladressen die staat voor onbekend adres.

Zie ook de veronderstelde aanwezigheid van bepaalde zaaktypes hieronder in het blok //Zaaktype//.

===== Verwerking Verzoekbericht =====

Uit de tag <verzoeknummer>  wordt het verzoeknummer opgehaald.

==== Doel ====

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.

  * 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.

==== Locatie ====

Alleen bij Initiëren/Indienen en Conceptverzoek.

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:

  - OpenWave zoekt eerst op adres (waarbinnen eerst op BAG-ID nummeraanduiding, anders op postcode + huisnummer-gegevens, en anders op straat, huisnummergegevens en woonplaats)
  - Niet gevonden (of niet aanwezig in STAM-bericht) dan wordt gezocht op x- en y-coördinaat op grond van de opgegeven punt locatie in rijksdriehoek.
  - Niet gevonden (of niet aanwezig in STAM-bericht) dan wordt gezocht op kadastrale gegevens.
  - Niet gevonden (of niet aanwezig in STAM-bericht) dan wordt gezocht op punt van coördinaten ERTS, waarbij zo nodig omgerekend wordt naar rijksdriekhoek.

Niet gevonden (of niet aanwezig in STAM-bericht) valt OpenWave terug op //Getal2// van //Sectie: Koppeling OLO Item: DummyLokatiePerceelkey// (onbekend adres). Daar kan nog van worden afgeweken indien OpenWave (bij ontbreken van uitvoerende instantie) op grond van bevoegd gezag in de tabel tboin een gemeente-id verwijzing vindt (kolom tboin.dvgemeenteid), waarvoor een compartiment is gedefinieerd in OpenWave. In dat laatste geval zal OpenWave de waarde - mits gevuld - van kolom tbcompartiment.dnkeyswfdummyadres nemen als keyverwijzing naar tbperceeladressen. Die tbperceeladressenkaart moet bij dezelfde gemeente-id horen!

==== Zaaktype ====

Alleen bij Initiëren/Indienen en Conceptverzoek.

De volgende (plicht)types kunnen worden aangeleverd in het verzoekbericht:

  * Aanvraag vergunning
  * Melding
  * Informatie
  * Informatie ongewoon voorval
  * Aanvraag maatwerkvoorschrift
  * Melding gelijkwaardige maatregel
  * Aanvraag toestemming gelijkwaardige maatregel

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|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//.

Anders, indien de gevonden gemeente-id (op grond van locatieadres/bevoegd gezag) wel voorkomt in tbkopcompgem (de tabel met gemeentes per compartiment) dan is het verzoekbericht voor een compartiment. Het is in dit geval van groot belang dat de kolom tbcompartiment.dnkeyswfdummyadres met een keywaarde uit tbperceeladressen wordt gevuld, die van toepassing is op dat compartiment (dezelfde gemeente-id).

Om het zaaktype (een rij uit tbsoortomgverg) te kunnen vaststellen redeneert OpenWave als volgt:

  * Indien de zaak NIET voor een compartiment is dan:
    * 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 = 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  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 = 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  = 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  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.

==== Project ====

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//).

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.

==== 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 **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.

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>\\

Per blok ''<projectlocatie>'' wordt een kaart aangemaakt in deze tabel, waarbij - indien aanwezig - zowel puntcoördinaat, als polygoon (vooralsnog alleen de exterior ring), als adresgegevens, als kadastrale gegevens worden overgenomen. De puntcoördinaten en polygonen worden door OpenWave omgerekend naar het Rijksdriehoekstelsel.]] Indien geen blok adresAanduiding in STAM-bericht en ook geen blok kadastralegegevens dan wordt de tbprojectlocaties.straatnaam gevuld met 'Getekend gebied'. Openwave kijkt naar de coördinaten van het blok coordinatenetrs of (vanaf STAM 6) naar //coordinatenafgeleid//. Indien deze staan in rijksdriehoek (epsg 28992) dan worden ze rechtstreeks overgenomen in de rijksdriehoekkolommen //dvgmlrdpolygoon, dvxrdcoordinaat, dvyrdcoordinaat. // Zo niet dan worden de gegevens door OpenWave geconverteerd van het opgegeven stelsel naar rijksdriehoek: en dat verklaart soms een minimale afwijking ten opzichte van de opgegeven coördinaten.

Indien de omgevingzaak is aangemaakt bij het onbekende perceeladres (DummyLokatiePerceelkey of dnkeyswfdummyadres bij compartiment) EN de instelling //Sectie: DSO-VerzoekAfhandelen en Item: Hoofdprojectlocatie// is aangevinkt, dat wordt de kolom tbzaakkadperc.dlhoofdprojectlocatie van de eerste projectlocatie uit het STAM-bericht automatisch op T gezet.

Indien de instelling //Sectie: DSO-VerzoekAfhandelen en Item: Hoofdprojectlocatie// is aangevinkt EN //Getal1 = 1.0// dan zal het vinkje ook aangevinkt worden voor bekende projectlocaties (projectlocaties op grond van stambericht DSO die __niet__ landen op een dummy-adres).

==== Bevoegd gezag ====

Alleen bij Initiëren/Indienen en Conceptverzoek.

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).

==== Bevoegd gezag historie ====

Alleen bij Initiëren en Vooroverleg.

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).

==== Uitvoerende instantie ====

Alleen bij Initiëren/Indienen en Conceptverzoek.

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 ===

Alleen bij Initiëren/Indienen en Conceptverzoek.

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).

==== Dossierbehandelaar ====

Alleen bij //Initiëren/Indienen en Conceptverzoek//.

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//.

==== 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. Halverwege de verschijningsperiode van STAM 5 is dit blok contactpersoon uit de verzoek.xml gehaald. Dus zit niet meer in verzsoek.xml van STAM 6.

</adm>

Het blok **Contactpersoon** kan alleen worden opgevoerd bij het indienen van de aanvraag wanneer een vestiging of bedrijf de aanvraag indient. Het gaat dan om de volgende situaties:

  * 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. 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. \\

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.

Wat betreft het overnemen/overschrijven van adresgegevens redeneert OpenWave chronologisch als volgt:

  * als blok ''<afwijkendAdres>'' bestaat EN de waarde van tbcontactadressen.dvstraatnaam (postadres) is leeg dan worden de postadresgegevens overschreven met de gegevens uit dit blok
  * als blok ''<binnenlandsAdres>'' bestaat EN de waarde van tbcontactadressen.dvveststraat (vestigingsadres) is leeg dan worden de vestigingsadresgegevens overschreven met de gegevens uit dit blok
  * als tbcontactadressen.dvstraatnaam (postadres) nog steeds leeg is overschrijf dan de postadresgegevens met de waardes uit blok ''<binnenlandsAdres>'' 
  * als blok ''<buitenlandsAdres>'' bestaat EN de waarde van tbcontactadressen.dvbuitenladresregel1 is leeg dan worden de buitenlandadresgegevens overschreven met de gegevens uit dit blok.

==== Initiatiefnemer ====

<adm warning>

Alleen STAM 5 of ouder. Is in STAM 6 vervangen door blok <betrokkene>

</adm>

//Bij Initiëren/Indienen en Conceptverzoek 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.

<adm Altijd nieuw Niet Natuurlijk Contact aanmaken?>

Indien de instelling //Sectie: DSO en Item: AltijdNieuwNNP// is aangevinkt en de initiatiefnemer is een niet natuurlijk persoon (KvK- dan wel vestigingsnummer is gevuld) dan zal er altijd een nieuw contactadres aangemaakt worden in OpenWave. Deze instelling kan gebruikt worden ter voorkoming van overschrijven van niet natuurlijke contactpersonen in OpenWave.

</adm>

Wat betreft het overnemen/overschrijven van persoonsgegevens (natuurlijk persoon) redeneert OpenWave als volgt:

  * dddatummutatie met systeemdatum
  * dvtelefoon met <telefoonnummer>
  * dvemail met <emailadres>
  * dvachternaam met <geslachtsnaamNaamgebruik>
  * 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>

Wat betreft het overnemen/overschrijven van bedrijfsgegevens (niet natuurlijk persoon) redeneert OpenWave als volgt:

  * dddatummutatie met systeemdatum
  * dvtelefoon met <telefoonnummer>
  * dvemail met <emailadres>
  * dvrsin met <rsin>
  * dvstatutairenaam met <statutaireNaam>
  * dvbin met <kvkNummer>
  * dvhandelsnaam met <handelsnaam>
  * dvbedrijfsnaam met <verkorteHandelsnaam>

Wat betreft het overnemen/overschrijven van adresgegevens redeneert OpenWave chronologisch als volgt:

  * De aanvrager/initiatiefnemer is een natuurlijk persoon (blok: ''<natuurlijkPersoon>''):
    * als blok ''<correspondentieAdres>'' ''<afwijkendAdres>'' bestaat dan vanuit blok ''<afwijkendAdres>'' de postadresgegevens overnemen (indien dit een Postbusnummer betreft EN instelling //Sectie: KoppelingNHR, Item: PostbusnrInHuisnr// is aangevinkt dan wordt als straatnaam 'Postbus' gezet en als huisnummer het postbusnummer)
    * als blok ''<correspondentieAdres>'' ''<binnenlandsAdres>'' bestaat dan vanuit blok ''<binnenlandsAdres>'' de postadresgegevens overnemen 
    * als blok ''<correspondentieAdres>'' ''<buitenlandsAdres>'' bestaat dan uit blok ''<buitenlandsAdres>'' de buitenlandse adresgegevens overnemen
    * als blok ''<verblijfsadres>'' bestaat dan uit blok < verblijfsadres> de vestigingsadresgegevens overnemen
    * als blok ''<verblijfsadresBuitenland>'' bestaat EN tbcontactadressen.dvbuitenladresregel1 is null dan uit blok ''<verblijfsadresBuitenland>'' de buitenlandse adresgegevens overnemen.
  * De aanvrager/initiatiefnemer is een niet natuurlijk persoon (blok: ''<NietNatuurlijkPersoon>''):
    * als blok ''<postAdres>'' ''<afwijkendAdres>'' bestaat dan uit blok ''<afwijkendAdres>'' de postadresgegevens overnemen (indien dit een Postbusnummer betreft EN instelling //Sectie: KoppelingNHR, Item: PostbusnrInHuisnr// is aangevinkt dan wordt als straatnaam 'Postbus' gezet en als huisnummer het postbusnummer)
    * 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 ''<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.

<adm Ontbrekend postadres>

Indien de instelling //Sectie: DSO-Verzoekafhandelen en Item: OntbrekendPostadresVullenMetVestiging// is aangevinkt en het STAM-bericht bevat geen post- c.q. correspondentieadres bij aanvrager (initiatiefnemer) en/of gemachtigde dan zullen de verblijfs- c.q. vestiging gegevens in OpenWave zowel in het vestigingsadres als in het postadres bij de contactadreskaart worden overgenomen

</adm>

==== Gemachtigde ====

<adm warning>

Alleen STAM 5 of ouder. Is in STAM 6 vervangen door blok <betrokkene>

</adm>

//Bij Initiëren, Indienen en Conceptverzoek 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 ''<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.

<adm Altijd nieuw Niet Natuurlijk Contact aanmaken?>

Indien de instelling //Sectie: DSO en Item: AltijdNieuwNNP// is aangevinkt en de gemachtigde is een niet natuurlijk persoon (KvK- dan wel vestigingsnummer is gevuld) dan zal er altijd een nieuw contactadres aangemaakt worden in OpenWave. Deze instelling kan gebruikt worden ter voorkoming van overschrijven van niet natuurlijk contactpersonen in OpenWave.

</adm>

Wat betreft het overnemen/overschrijven van persoons- dan wel bedrijfsgegevens en de adresgegevens redeneert OpenWave hetzelfde als hierboven beschreven bij de initiatiefnemer.

==== Betrokkene ====
== (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.

<adm warning>

Veel tags onder het blok ''<betrokkene>'' kunnen twee keer voorkomen (hoeft dus niet). Als een tag twee keer voorkomt dat is daar het attribuut bron bijgevoegd, namelijk bron = “DSO-LV” wil zeggen: zo staat het in de basisregistratie OF  bron = “gebruiker” wil zeggen dat de aanvrager het gegeven heeft overschreven\\  In het geval dat een tag 2 x voorkomt dan redeneert Openwave vanuit de tag met attribuut bron = “gebruiker”.

</adm>

De betrokkene kan een natuurlijk persoon zijn:  het blok <betrokkeneNP>

  * achternaam
  * voorvoegsel
  * tussenvoegsel
  * bsn
  * geboortedatum

Of een NIET natuurlijk persoon : het blok <betrokkeneNNP>

  * handelsnaam
  * kvknummer
  * vestigingsnummer
  * rsin

De betrokkene kan één of meer adreskanalen hebben in het blok <kanaal>

  * ''<binnenlandsAdres>''
    * huisletter
    * huisnummer
    * huislnummertoevoeging
    * postcode
    * straatnaam
    * woonplaatsnaam
  * buitenlandsAdres 
    * adresBuitenland1
    * adresBuitenland2
    * adresBuitenland3
    * land
  * postbusnummer
    * nummer
    * postcode
    * woonplaatsnaam
  * antwoordnummer
    * nummer
    * postcode
    * woonplaatsnaam

Daarnaast kunnen bij de betrokkene drie extra contactgegevens worden opgegeven in het blok ''<kanaal>'' met het attribuut doel="vragen'

  * emailadres
  * telefoonnummer
  * contact

Een BSN-nummer bestaande uit 9 nullen beschouwt OpenWave als leeg. Een KvK-nummer bestaande uit 8 nullen beschouwt OpenWave als leeg. Een vestigingsnummer bestaande uit 12 nullen beschouwt OpenWave als leeg. Een rsin bestaande uit 9 nullen beschouwt OpenWave als leeg.

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.

Indien geen gegadigde wordt gevonden dan wordt een nieuwe kaart aangemaakt in tbcontactadressen.

<adm Altijd nieuw Niet Natuurlijk Contact aanmaken?>

Indien de instelling //Sectie: DSO en Item: AltijdNieuwNNP// is aangevinkt en de betrokkene is een niet natuurlijk persoon (KvK- dan wel vestigingsnummer dan wel rsin is gevuld) dan zal er altijd een nieuw contactadres aangemaakt worden in OpenWave. Deze instelling kan gebruikt worden ter voorkoming van overschrijven van niet natuurlijk contactpersonen in OpenWave.

</adm>

Bij de bestaande of nieuwe relatie in tbomgvergcontactennn worden de drie extra vraag-contactgegevens opgenomen onder de kolommen dvvraagcontact, dvvraagemail en dvvraagtelefoon.

In de view vwfromgcontacten t.b.v. de contactenlijst op het scherm MDLC_geefOmgContactenOverzicht.xml zijn deze drie kolommen dvvraagcontactmet, dvvraagemail en dvvraagtelefoon opgenomen waarbij geldt dat de schermkolom

  * voor vragen wordt gevuld met dvvraagcontactmet en dus ook leeg kan zijn
  * email wordt gevuld met dvvraagemail, maar als deze leeg is met de email van het contactadres
  * telefoon wordt gevuld met dvvraagtelefoon, maar als deze leeg is met de telefoon c.q. mobiel van het contactadres.

De binnenlandse adresgegevens komen in OpenWave in tbcontactadressen onder het blok verblijfs/bezoekadres. De buitenlandse adresgegevens komen in OpenWave in tbcontactadressen onder het blok adres buitenland. De postbus en antwoordnummers komen in OpenWave in tbcontactadressen onder het blok postadres, waarbij

  * Indien instelling //Sectie = koppelingnhr en Item = postbusnrinhuisnr// bestaat EN aangevinkt is dan wordt de straatnaam: //postbus cq antwoordnummer// en komt het nummer zelf in de huisnummer, en anders komt in de straatnaam //postbus cq antwoordnummer// direct gevolgd door het nummer zelf (en blijft huisnummer leeg)
  * het antwoordnummer prioriteit krijgt boven het postbusnummer indien beiden zijn gevuld.

Indien

  * de instelling //Sectie: DSO-Verzoekafhandelen Item: Ontbrekendpostadresvullenmetvestiging// aangevinkt is.
  * EN de straatnaam van het postadres in OpenWave is leeg (dvstraatnaam)

dan worden de postadresgegevens overschreven met die van het vestigingsadres.

==== Activiteiten ====

//Bij Initiëren en Vooroverleg en Aanvullen en Intrekken.//

=== 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. 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.

De kolom dvmbaplicht wordt overgenomen uit de kolom dvmbadefaultplicht van de gevonden soort activiteit (tbsrttoestemming).\\  Indien deze defaultwaarde echter leeg is dan geldt indien het gaat om een DSO-verzoek //plichttype// =

  * Informatieplicht dan worden de aangemaakte activiteiten default voorzien met tbtoestemmingen.dvmbaplicht = 'I'
  * 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.

=== Mapping antwoorden uit specificaties op grond van vraagid ===

In de beheertabel achter de tegel //Acties op DSO-SpecVraagids// kan ingesteld worden hoe een antwoord op een bepaalde vraagid doorgezet kan worden naar andere kolommen van de OpenWave database. Een voorbeeld met betrekking tot het plaatsen van de bouwkosten in tbtoestemmingen (activiteiten/onderdelen) in de kolom opgegeven bouwkosten (dflegesopgbasis):

Er zijn twee vraagid's (en misschien nog wel meer) die naar de bouwkosten vragen namelijk:

  * 284856 indien de specificatie hoort bij activiteit //Bouwactiviteit (omgevingsplan)// en 
  * 368212 indien de specificatie hoort bij activiteit //Bouwactiviteit (technisch)//.

Beide vallen onder aanvraagtype //Aanvraag vergunning//, belangrijk, want eenzelfde vraagomschrijving bij eenzelfde activiteit kan per aanvraagtype een andere vraagid opleveren. In de tabel (tbdsospecvraagid) moeten dus 2 kaarten worden aangemaakt met de genoemde vraagid's (dvdsovraagid). Hoewel de omschrijving vrij staat is het belangrijk zo goed mogelijk het verschil aan te geven in de kolom dvomschrijving. In beide gevallen is het de bedoeling dat de kolom dflegesopgbasis van de tabel tbtoestemmingen moet worden gevuld: de kolom //ga naar tabel// (dvganaartabelnaam) moet daarom gevuld worden met tbtoestemmingen.

Nu moet het programma weten bij welke dnkey van tbtoestemmingen de aanpassing moet gebeuren: de kolom //select statement// (dvsqlprimkeyganaartabel) moet gevuld worden met een valide SQL select statement. In bovenstaande gevallen //select dnkeytoestemmingen from tbdsospecificaties where dnkey = %keypointer%//. De variabele// %keypointer%// wordt daarbij on the fly vervangen door de dnkey uit de tabel tbdsospecificaties die hoort bij de betreffende vraagid.

Nu moet OpenWave weten welke kolom(men) van tbtoestemmingen moeten worden vervangen. Er zijn vier mogelijkheden. In dit voorbeeld wordt alleen de eerste (dvedit1kolomnaam) gevuld met de gewenste kolomnaam uit tbtoestemmingen: //dflegesopgbasis//.

Tot slot moet aangegeven worden in de kolom //dvedit1waarde// met welke waarde tbtoestemmingen.dflegesopgbasis moet worden vervangen. In //dvedit1waarde// zal de string //%dvdsoantwoord%// on the fly worden vervangen met het antwoord op de vraag uit het DSO STAM-bericht. Aangezien dit een characterstring is moet de beheerder zelf aangeven hoe deze string geconverteerd moet worden om in het floatfield dflegesopgbasis te passen, namelijk //replace(%dvdsoantwoord%,chr(44),'.')::float// (de eventuele komma in het antwoord wordt eerst omgezet naar een decimale punt, en dat resultaat wordt als float opgeslagen).

Als het antwoord in een stringveld terecht moet komen dan is bijvoorbeeld %dvdsoantwoord%, maar ook substr(%dvdsoantwoord%,2,5) valide. Indien een vaste waarde (dus niet gebaseerd op het antwoord) dan moet deze geplaatst worden tussen enkele aanhalingstekens indien de kolom die vervangen moet worden een stringveld of datumveld is. Bij type float of integer geen aanhalingstekens.

**Ander voorbeeld**:

De provincie Noord-Holland heeft als extra vraag in het DSO-verzoek toegevoegd: //Aan welke weg gaat u activiteiten uitvoeren?// Het antwoord kan niet anders dan een wegnummer bevatten.// 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. 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:

<code sql>
  select dnkey from tbzaakkadperc where dnkeyomgvergunningen = (select dnkeyomgvergunningen from tbtoestemmingen where dnkey = (select 
  dnkeytoestemmingen from tbdsospecificaties where dnkey = %keypointer%)) limit 1
</code>

  * //Kolomnaam1// moet gevuld worden met de kolomnaam waar het wegnummer in moet komen: //dvwegnummer//
  * //Waarde1// moet gevuld worden met het antwoord uit het DSO-bericht: //%dvdsoantwoord%//
  * //Kolomnaam2// moet gevuld worden met de kolomnaam van is hoofdprojectlocatie namelijk: //dlhoofdprojectlocatie//
  * //Waarde2// moet gevuld worden met de vaste waarde T (dlhoofdprojectlocatie is type char-veld dus tussen enkele aanhalingstekens) //'T'//.

=== 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
  * EN de instelling //Sectie: DSO en Item: Kwaliteitsborger// aangevinkt is 
  * EN er nog geen contactpersoon gekoppeld is aan de aangemaakte omgevingszaak met de ROL kwaliteitsborger

dan onderzoekt OpenWave de specificaties van het STAM-bericht op groepen waarin de tekst kwaliteitsborger voorkomt. De - ongestructureerde - antwoorden van de vragen:

  * met vraagid 366941 en 365921 (of vanaf 1.29.3 de vraagtekst: Wat is het KvK-nummer van de kwaliteitsborger?) zal OpenWave interpreteren als een KvK-nummer 
  * 366940 en 365920 (of vanaf 1.29.3 de vraagtekst: Wat is de bedrijfsnaam van de kwaliteitsborger?) als bedrijfsnaam
  * 365923 en 366943 (Wat is het adres van de kwaliteitsborger?) als een postadres (waarin straat huisnummer, woonplaats ongestructureerd voorkomen)
  * 366938 en 365912 (Wat is de naam van de contactpersoon die de kwaliteitsborging uitvoert?) als een achternaam (waarbij voorletters, tussenvoegsel en naam ongestructureerd voorkomen)
  * 365919 en 366946 (Wat is het telefoonnummer van de contactpersoon die de kwaliteitsborging uitvoert?) als telefoon van de kwaliteitsborger
  * 366944 en 365916 (Wat is het e-mailadres van de contactpersoon die de kwaliteitsborging uitvoert?) als email van de kwaliteitsborger.

OpenWave gaat als volgt te werk:

  * OpenWave onderzoekt is of in de kaartenbak contactadressen de betreffende kwaliteitsborger al voorkomt. Dat gebeurt op de twijfelachtige combinatie KvK-nummer en Email. Indien precies één kaart gevonden dan wordt deze contactpersoon ook gekoppeld aan de aangemaakte omgevingszaak met de rol kwaliteitsborger.
  * Geen bestaand contact gevonden of meerder mogelijkheden: dan maakt OpenWave een nieuwe contactadreskaart aan op grond van de ongestructureerde antwoorden, waarbij op voorhand al uitgesloten kan worden dat de kolommen //Postadres// en //Achternaam// juist worden gevuld. Er is dus altijd werk aan de winkel voor een mens om het contactadres goed te krijgen.

=== Gevraagde bijlages per specificatie ===

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). 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 ===

Bij Initiëren en Vooroverleg en 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).

Per blok ''<document>'' wordt op grond van de tag ''<documentId>'' en de primary key in tbdsogevrbijlages van de betrokken gevraagde bijlage gezocht of deze combinatie voorkomt in de tabel tbomgoloberichten (dvolomessageid en dnkeydsogevrgbijage). Zo nee dan wordt aldaar een nieuw record aangemaakt met de documentgegevens en - indien het om een aanvulling/intrekking gaat - ook het DSO-verzoek-volgnummer.

Wanneer een nieuwe kaart wordt aangemaakt in tbomgoloberichten wordt naast de dnkeydsogevrgbijage ook de dnkeyomgvergunningen gevuld zodat de documentkaarten ook rechtstreeks te zien zijn vanaf de omgevingstegel //DSO-berichten//.

Indien een aanvulling wordt verwerkt kan het zijn dat eerdere documenten zijn vervangen door andere of zelfs helemaal niet meer opgenomen zijn in het aanvullingsbericht. Deze documenten worden in de tabel tbomgoloberichten voorzien van een vervaldatum (datum dat aanvulling is binnengekomen). Indien deze vervallen documenten ook een registratie hebben in de tabel tbcorrespondentie (geregistreerde documenten) wordt ook daar een vervaldatum toegekend.

==== Documenten verzoekbijlages ====

Bij Initiëren, Indienen en Conceptverzoek 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.

Per blok ''<document>'' wordt op grond van de tag ''<documentId>'' van de betrokken verzoekbijlage gezocht of deze reeds voorkomt in de tabel tbomgoloberichten (dvolomessageid met een lege dnkeydsogevrgbijage). Zo nee dan wordt aldaar een nieuw record aangemaakt met de documentgegevens en - indien het om een aanvulling/intrekking gaat - ook het DSO-verzoek-volgnummer.

Wanneer een nieuwe kaart wordt aangemaakt in tbomgoloberichten wordt naast de dnkeydsogevrgbijage ook de dnkeyomgvergunningen gevuld zodat de documentkaarten ook rechtstreeks te zien zijn vanaf de omgevingstegel //DSO-berichten//.

Indien een aanvulling wordt verwerkt kan het zijn dat eerdere documenten zijn vervangen door andere of zelfs helemaal niet meer opgenomen zijn in het aanvullingsbericht. Deze documenten worden in de tabel tbomgoloberichten voorzien van een vervaldatum (datum dat aanvulling is binnengekomen). Indien deze vervallen documenten ook een registratie hebben in de tabel tbcorrespondentie (geregistreerde documenten) wordt ook daar een vervaldatum toegekend.

===== Product/ subproduct/ zaakverantwoordelijk team =====

Op grond van de combinatie soort activiteit en zaaktype kan Openwave alvast product/subproduct/team vullen bij de aangemaakte omgevingzaak. Zie hiervoor onder het //Blok default product/subproduct/team bij dsoverzoek met deze activiteit// bij [[..:portalen_en_moduleschermen:zaakbeheer:tegels_kolom_afhandeling:soort_activiteit_onderdeel]].

===== 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.

Bij het verwerken van STAM-bericht wordt eerst deze voorcheck gedaan: Indien

  * Er nog geen kaart bestaat in tbomgvergunning met Dvlvoaanvraagnr = Verzoeknummer
  * EN in het STAM-bericht is het OIN-nummer van de uitvoerendeInstantie gevuld 
  * EN dat OIN-nummer van uitvoerende instantie is ongelijk aan dat van het bevoegd gezag
  * EN dat OIN-nummer is ongelijk aan de kolom //Tekst// van instelling //Sectie: SWF en Item: OINvanZender// (dit is de OIN van de host: de hoofdorganisatie die OpenWave gebruikt)
  * EN - 
    * indien OIN van bevoegd gezag voorkomt in niet-vervallen rij van tboin waarbij tboin.dvgemeenteid verwijst naar een gemeente van een compartiment EN de kolom //dldsoKopieberichtenOpslaan// van dat compartiment heeft **waarde F** 
    * anders (gaat niet om compartimentszaak) EN de instelling //Sectie: DSO en Item: KopieberichtenOpslaan// is **NIET** aangevinkt is (of bestaat niet)

DAN gaat het om een kopiebericht dat moet worden genegeerd. In de messagelog wordt het bericht wel opgenomen met de reden waarom genegeerd.\\

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|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 
  * er WEL sprake is van een compartiment dan EN de kolom dlAutoZaakDmsOmgeving is aangevinkt bij het betreffende compartiment (beheerportaal-Nieuw).

Zie voor overige verplichte instellingen voor aanmaken zaak in extern zaak/DMS bij [[openwave:1.34:applicatiebeheer:probleemoplossing:programmablokken:creeer_zaak_zaak_dms|Creëer zaak zaak/dms]].

==== Automatisch aanmaken mappen op fileshare ====

Indien

  * de zaak NIET valt onder een compartiment:
    * de instelling //Sectie: Documenten Item: OphalenViaFileserver// aangevinkt is 
    * EN de instelling //Sectie: Documenten Item: AutomAanmaakFileservermappen// aangevinkt is

OF indien

  * de zaak WEL valt onder een compartiment:
    * de kolom //ophalen via fileserver// op de detailkaart van het betreffende compartiment is aangevinkt
    * EN de kolom //Automatisch aanmaken mappen// (dlautoaanmaakmappen) aangevinkt is bij het betreffende compartiment

dan zullen bij het aanmaken van een nieuwe zaak automatisch de omgeving_mappen genoemd in de rijen van //Sectie: Aanmaakmappen// worden aangemaakt waarbij er een '4' voorkomt in //Getal1// (dus indien //Getal1// de waarde 25 heeft dan niet, indien bijv. 4 of 124 dan wel). Hierbij uitgezonderd zijn de mappen waarin de variabelen  ''%adviesnr%'' , ''%bezwaarnr%'' en  ''%inspnr%''  zijn opgenomen. Indien OpenWave in de Cloud draait, dan moet wel de [[openwave:1.34:applicatiebeheer:instellen_inrichten:satellite_filesysteem|satellite]] geïnstalleerd zijn.

==== Automatisch vullen van kolom dvhyperlink ====

Zie: [[openwave:1.34:applicatiebeheer:instellen_inrichten:hyperlink]].

==== Automatisch sturen van DSO Ontvangstbevestiging ====

Dit is het geval indien:

  * 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)

Zie voor overige verplichte instellingen voor automatisch versturen van DSO ontvangstbevestiging bij  [[openwave:1.34:applicatiebeheer:probleemoplossing:programmablokken:dso_ontvangstbevestiging]].

==== 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]].

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).

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.

De verzoek.pdf staat niet in tbomgoloberichten, maar ook deze (altijd de laatste versie) wordt zo nodig opgehaald en geregistreerd.

Voor het kunnen aanroepen van de DSO-verzoekafhandelen-API gelden de volgende voorwaarden:

  * De OIN van de zender moet bekend zijn: deze wordt eerst opgezocht op basis van behandeldienst/uitvoerende instantie: indien deze gevuld dan wordt het OIN-nummer uit tboin van de uitvoerende instantie gebruikt. Anders, indien behandeldienst leeg en bevoegd gezag wel gevuld, dan wordt het OIN-nummer uit tboin van het bevoegd gezag gebruikt. Anders, indien bevoegd gezag en behandeldienst leeg zijn dan wordt het OIN van de zender ook uit tboin gehaald, maar dan op grond van de gemeente waar de zaak speelt.
  * VarAlgemeenEndpoint moet gedefinieerd zijn in kolom //Tekst// van //Sectie: DSO-Verzoekafhandelen en Item: AlgemeenEndpoint//.

Indien er toch nog documenten ontbreken dan kan handmatig de functie //Haal ontbrekende documenten// aangeroepen worden vanuit de lijst met DSO berichten (tbomgoloberichten). Zie kopje //Haal ontbrekende documenten// bij [[openwave:1.34:applicatiebeheer:probleemoplossing:module_overstijgende_schermen:olo-aim_bijlage_verwijzingen]].

Met welke attributen een DSO-document wordt geregistreerd in tbcorrespondentie staat onder kopje: //Automatische registratie van document// van [[openwave:1.34:applicatiebeheer:probleemoplossing:programmablokken:upload_dso-document_vanuit_digi-koppelaar]].

==== Ophalen van DSO Verzoek.xml ====

Indien de instellingen:

  * //Sectie: OWB en Item: OphalenDSODocsViaApi// EN 
  * //Sectie: DocumentRegistreren en Item: AlleOLODSOUploads// EN 
  * // Sectie: DSO en Item: VerzoekXMLOpslaan// zijn aangevinkt

Dan wordt het DSO verzoekbericht in diens originele staat bij de desbetreffende zaak opgeslagen, in XML-formaat. Het verzoekbericht zal onder de naam dvdsovolgnr + '-verzoekbericht.xml' opgeslagen worden. Dit bestand komt niet voor in tbomgoloberichten maar wordt wel weergegeven in tbbadextupload in het geval dat het niet geplaatst kan worden.

=== 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.

De conversie maakt gebruik van [[openwave:1.34:applicatiebeheer:instellen_inrichten:onlyoffice|OnlyOffice]] indien de instellingen //Sectie: Documenten en Item: OnlyOffice// aangevinkt is EN //Sectie: Documenten en Item: ConverteerPDF en Getal1 = 1//. Anders wordt de interne DocConverter gebruikt.

<adm warning>

Het renderen van documenten met de extensies ods, odt, doc, docx, xls, xlsx,txt en xml kan alleen indien de kolom Tekst gebeurt via OnlyOffice (mits geïnstalleerd). Indien //Getal1// van //Sectie: Documenten en Item: ConverteerPDF// de waarde 1 heeft. Zo niet, dan worden documenten geconverteerd naar PDF via Libre Office. In dit laatste geval dient de instelling //Sectie: Koppeling Converter en Item: EndpointClassDocument// gevuld te zijn met een valide endpoint van de Libre Office-converter.

</adm>

==== 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>

Dit gebeurt alleen bij het creëren van een zaak via DSO. Latere aanpassingen aan de activiteiten leiden niet tot automatische aanpassing van //dlzaakpubliceren//

</adm>

{{tag>openwave:1.34:applicatiebeheer:functionaliteiten:dso}}