Document toolboxDocument toolbox

2023-02-27 BWG 19

Focus

Komende features en change requests

Presentator(s)

Presentatie: Benjamin Peeters, Eveline Neirings, Luc Geyskens, Nicolas Hoflack, Evelyne Devos
Verslag: Evelyne Devos

Agenda

Topics

Welkom

 

 

Aanpak businesswerkgroepen 2023

5’

 

Aankomende features komende PI

15’

Nieuwe inlichting: socio-econ. vergunning

 

15’

Visualisatie adressen

 

5’

Contactinformatie op PDF/GUI

 

15’

Correctiemelding door lokaal bestuur visualiseren

Aankomende change requests

10’

Soort weg waarlangs perceel gelegen is

PAUZE

5’

 

 

10’

Voorwaarden gem. akte

Features high level

15’

Correctieaanvraag

 

5’

Betalingsflow - gemeente

 

10’

Discrepanties omgevingsloket

Vragen

15’

 

Presentatie

Aanwezigen

Verslag

Omschrijving topic

Probleemstelling - Opmerkingen en beslissingen

Actiepunten

Omschrijving topic

Probleemstelling - Opmerkingen en beslissingen

Actiepunten

Aanpak BWG 2023

Doelstelling van de businesswerkgroep:

  • Business afstemming features/change requests komende/volgende PI waar nog input en/of validatie nodig is vóór ontwikkeling

  • High level afstemming latere features 2023

Wat past NIET binnen de businesswerkgroep:

  • Features die geen afstemming meer nodig hebben (informeren) > publieke demo en feature planning

  • Andere infodeling en updates > product mailing

  • Melding problemen, suggesties > vastgoedinformatieplatform@vlaanderen.be en wij evalueren of over dit topic afstemming nodig is op volgende BWG

 

Aankomende features komende PI

Nieuwe inlichting: socio-econ. vergunning​

  • Oorspronkelijke vraag kwam van Heusden-Zolder, Zwalm, Gent, Merksplas

  • Wat is de geldigheid hiervan?

    • onbepaalde duur, dus nog relevant voor een VIP-dossier

  • Gemeenten hebben dit al gedeeltelijk gedigitaliseerd maar wordt nog niet meegegeven

    • Merksplas is klaar om dit mee te geven, Gent ook

    • Meeste gemeenten niet, dus voorkeur om optioneel te houden

  • Fednot vraagt aandachtig te zjin dat het niet is omdat een inlichting vandaag niet kant-en-klaar beschikbaar is, deze niet belangrijk is om mee te geven - moet verder geanalyseerd worden wat de impact is

  • ‘Oude’ vergunningen zitten niet bij RO, maar bij dienst ‘Economie’

  • Recente vergunning zitten in Omgevingsloket, oudere niet

  1. Momenteel socio-economische vergunning nog niet verplichten
@Evelyne Devos aparte analysecall inplannen met de gemeenten die dit wensen mee te geven (Merksplas, Hove, Heusden-Zolder, Gent)

Visualisatie adressen​

Probleemstelling

Wanneer de gebouweenheid niet aanwezig of gekend (bv. notarissen kennen enkel partitienummers) worden vaak ALLE gebouweenheden geselecteerd en wordt in het toelichtingsveld gespecifieerd waarover de aanvraag gaat. Met als gevolg een lange, onoverzichtelijke lijst van adressen bij veel gebouweenheden in PDF en GUI en geen onderscheid tussen hoofdadressen en subadressen.

Doelstelling

Duidelijk manier van adressen visualiseren in de VIP GUI en PDF

Voorgestelde aanpak

  • Hoofdadressen vermelden met vermelding subadressen tussen haakjes (zoals busnummers)

  • Ook toelichtingsveld met bv. partitienummers vermelden

  • De gebouweenheden worden niet weergegeven in VIP GUI en PDF. De gebouweenheden blijven wel beschikbaar in API.

  • Bij aanduiding van een gebouweenheid zonder subadres staat enkel het hoofdadres vermeld, gelijkaardig aan een aangeduid adres zonder gebouweenheden (bv. voor gemene delen van een appartementsgebouw)

Toelichting aanvraag iBOT (FEDNOT) naar VIP - waarom gebeurt aanduiding van alle adressen en gebouweenheden ookal is het slechts voor een aantal partitienummers?

  • FEDNOT koppelt met federale authentieke bron (kadaster)

  • Wanneer zij de gebouweenheid in VIP kunnen matchen, geven ze in de interactie het specifieke adres mee

  • Indien niet, zal de integratie iBOT - VIP alle gebouweenheden selecteren.

Opmerkingen

  • Dit blijft een tussentijdse oplossing, de grond van het probleem, zijnde een goede matching tussen partitienummers, adressen en gebouweenheden moet de doelstelling blijven > VIP blijft hier inderdaad parallel mee aan sturen

  • Waarvoor is specificatie van adres nodig? een dossier wordt afgeleverd op capakey/perceel:

    • Voor inlichtingen leegstand en verwaarlozing, VLOK-data (op heden nog geen filtering, maar wel de bedoeling), vergunningstoestand (optioneel), mogelijks ook bepaalde vergunningen en bouwovertredingen

  1. Akkoord om de visualisatie van adressen (via hoofd/subadressen tussen haakjes) op PDF en in GUI door te voeren
  2. Akkoord dat de aangevraagde gebouweenheden niet worden weergegeven in VIP GUI en PDF
  3. Akkoord om bij aanduiding van een gebouweenheid zonder subadres niets te tonen in PDF/GUI
@Nicolas Hoflack (Unlicensed) volgt werkgroepen rond matching partitienummers/adressen/gebouweenheden mee op

Contactinformatie op PDF/GUI​

Voorstel om de contactinformatie van alle informatieleveranciers in de pdf toe te voegen bij ‘over dossier’ en in de GUI per inlichting. Op vandaag enkel via gebruikersomgeving beschikbaar. De bron wordt ook bij elke inlichting vermeld. Dit om duidelijk te maken dat de verantwoordelijke bronhouder moet gecontacteerd worden bij inhoudelijke vragen over de doorgegeven inlichting.

Opmerking

  • In een latere fase kunnen de logo’s van gemeenten en andere infoverstrekkers ook opgenomen worden.

  • Het is momenteel niet mogelijk om contactgegevens per rubriek/inlichting mee te geven. In de MVP versie is het enkel mogelijk om 1 email adres te voorzien, in de toekomst eventueel op te delen per rubriek.

    • Vraag van Leuven en Antwerpen

  • Is het mogelijk om bij doorklikken op mailadres een mail met vooringevuld onderwerp en/of inhoud toe te voegen? bv. Link naar dossier, dossiernummer… > wordt bekeken in welke mate dit kan opgenomen worden in de MVP versie.

  1. Akkoord om op voorgestelde manier de contactinformatie op te nemen in de PDF/GUI
@Nicolas Hoflack (Unlicensed) zet vraag op backlog om contactinfo per rubriek/inlichting te kunnen specifiëren
@Nicolas Hoflack (Unlicensed) bekijkt om default mail onderwerp/body toe te voegen bij doorklikken op mailadres bronhouder

Correctiemelding door lokaal bestuur visualiseren​

Probleemstelling

Lokale besturen merken (mogelijke) fouten op bij read-only inlichtingen waarvan zij geen bronhouder zijn dus geen aanpassingen kunnen doen. Om te vermijden dat aanvrager deze mogelijks foutieve info doorkrijgt, staat het dossier on hold tot de bronhouder de fout heeft aangepast en de bron herbevraagd kan worden: dit is omslachtig en verlengd de doorlooptijd.

Voorgestelde (gefaseerde) aanpak

  1. Fase 1 (eerste helft 2023):VIP voorziet mechanisme waarbij een gemeente een correctiemelding kan meedelen op inlichtingtypes van gewestelijke read-only bronnen (GUI/PDF)
    Lokaal bestuur gaat ZELF de bronhouder contacteren per mail met deze melding. Binnen de 3 werkdagen antwoord, kan het lokaal bestuur herbevraging doen (via knop in VIP). Indien geen antwoord, dossier valideren mét de correctiemelding die gevisualiseerd wordt voor de aanvrager

  2. Fase 2 (eind 2023): Mail notificatie: VIP gaat de foutmelding van het lokaal bestuur per mail verzenden naar de bronhouder – met de vraag om deze binnen de 3 werkdagen uit te voeren

    Resultaat van gewijzigde read-only bronnen weergeven:
    Bij herbevraging van de bronnen gaat VIP een resultaat weergeven welke gewijzigd zijn. Zodat het lokaal bestuur deze controleert en waar nodig de foutmelding verwijdert.
    Lokaal bestuur gaat ook hier de 4e werkdag het dossier valideren, met of zonder foutmelding.

Niet in scope voor 2023: Gecorrigeerd dossier automatisch bezorgen aan aanvrager indien correctie doorgevoerd werd na validatie.

Opmerkingen

  • Niet alle gemeenten controleren de read-only inlichtingen.

  • Belangrijke nuance:

    • soms is dit wel relevant, zoals bij Onroerend Erfgoed of VLOK data

    • VIP als katalysator voor bronoptimalisatie, waar de gemeenten mee een rol (kunnen) spelen

  • De aanvrager kan terecht bij de bronhouder voor verdere vragen. Contactinformatie wordt voorzien (zie hoger)

  • Gemeente is niet verantwoordelijk voor de read-only gewestelijke data, op deze manier kan de gemeente wel adviserend optreden naar de bronhouder - gelijktijdig kan de aanvrager hiervan op de hoogte worden gesteld.

  • Van dit soort inlichtingen een 'adapt' inlichting maken zodat gemeente meteen juist kan wijzigen, is juridisch niet toegestaan. Gemeente is geen bronhouder en zou hierdoor verantworodelijkheid nemen over data waarvan zij geen infoverstrekker is.

  • Kunnen bronhouders niet proactief hun lagen goed zetten? Hier zijn we parallel ook mee voor aan het sensibiliseren.

  1. Akkoord met de voorgestelde gefaseerde aanpak voor visualisatie correctiemelding door lokaal bestuur. Het is optioneel, maar wel aangeraden dat lokale besturen de check doen om zo de brondata te helpen verbeteren.

Aankomende change requests​

Soort weg waarlangs perceel gelegen is​

Voorgestelde aanpak

  • Bedoeling om te koppelen met het Wegenregister voor het verrijken van deze inlichting, met nieuwe attributen

  • ADAPT in plaats van FEED

  • Beherende instantie: gedifferentieerde aanpak

    • Lokaal bestuur: code beheerder = niscode dossier

    • Nabijgelegen lokaal bestuur: (nis)code beheerder <> niscode dossier

    • Andere wegbeheerder uit codelijst

    • Ook particulier

  • Er wordt met buffers gewerkt, 13m voor alle wegtypes, m.u.v. autosnelwegen waarbij buffer = 30m

  • Geen filtering: alle wegen, ook de trage wegen

Opmerkingen

  • Hoe kan het wegenregister goed gezet worden? (decentraal beheer)

    • via GIS-bulk of later via een loket: we vragen hierover verdere info aan wegenregister

  • Mogelijk wel teveel informatie doorkomen, door het gebruik van de buffers. Het is de bedoeling dat het lokaal bestuur dit gaat aanpassen/verwijderen, vermits ADAPT

  • Wordt er aan de andere wegbeheerder ook gevraagd om hun wegen na tek kijken? bv. Infrabel > te bekijken samen met wegenregister

@eveline.neirings plant overleg in met wegenregister over decentraal beheer en bespreking andere wegbeheerders (bv. Infrabel) en hun data
  1. Akkoord met de voorgestelde aanpak herwerking inlichting soort weg en koppeling wegenregister

Voorwaarden gem. akte

Huidige context

  • Percelen die in het verleden eigendom waren van de gemeente en die verkocht zijn mits bepaalde voorwaarden

  • Als hetzelfde perceel daarna doorverkocht wordt en er zijn bepaalde van die voorwaarden uit de gemeentelijke akte nog van toepassing voor de nieuwe eigenaar

Voorstel verruiming context

  • Deze optionele inlichting kan ook gebruikt worden voor een perceel dat nog in eigendom van de gemeente

  • De voorwaarden meegeven die al bepaald werden door de gemeenteraad/CBS en ter info al worden meegeven aan de koper, vóór de akte wordt verleden

Opmerkingen

  • Optionele inlichting

  • Bij voorkeur ook in een vastgoeddossier en niet enkel bekend gemaakt in de onderhandse akte zodat de gemeente al tijdig kan informeren aan de potentiële kopers

  • Verduidelijking nodig hoe lang de voorwaarden geldig zijn + wanneer de akte is verleden of nog moet verleden worden

  1. Akkoord dat de optionele inlichting voorwaarden gem. akte gebruikt kan worden voor een perceel dat nog in eigendom is van de gemeente en waarvoor de voorwaarden al gekend zijn, mits nuance tussen beide soorten duidelijk is.
@Nicolas Hoflack (Unlicensed)analyse opvolgen hoe verruiming voorwaarden gem. akte in datamodel
@eveline.neirings neemt met Blankenberge op hoeveel keer dit voorkomt
Oostende bekijkt of ze deze verruiming ook zouden gebruiken/of dit vandaag nog veel voorkomt

 

Features high level

Correctieaanvraag

Voorstel

Tot nog toe beperkt aantal fouten opgemerkt door de notarissen en makelaars op aan een (gemeentelijke) inlichting. De afhandeling van deze correctie aanvraag gebeurt buiten VIP. Gezien het beperkt aantal correctie aanvragen stelt VIP voor om dit pas na 2024 via VIP te laten verlopen.

Opmerking

  • Metrics opnieuw bekijken want gemeenten geven aan dat er al meer zijn

  • Aanvraag tot correctie en aflevering gecorrigeerd dossier blijft via mail aan de gemeente verlopen

  • Gemeente moet, tot deze feature is geïmplementeerd, bij wijziging na validatie van het dossier de pdf zelf sturen naar de aanvrager van het dossier vermits geen van de aanvrager applicaties de nieuwe PDF bezorgen.

  • Zal het mogelijk zijn om extra bijlage toevoegen bij de melding vanuit de aanvrager naar de gemeente? Voorbeelden: plannen, vergunningen, aktes, …

    • Komt dit voor? bezorg ons voorbeelden/cijfers

  1. Akkoord om correctieaanvraag door notaris/makelaar én aflevering gecorrigeerd dossier via VIP pas na 2024 op te nemen in de VIP roadmap.
@eveline.neirings bekijkt met DEV de metrics van hoeveel keer afgelopen tijd hervalidaties gebeurd zijn

Betalingsflow - gemeente

Het is de bedoeling dat VIP eind 2023 de inning van retributies gaat doen en het deel gemeentelijke retributie doorstort aan de gemeenten.

  • De gemeentelijke retributies dienen gefactureerd te worden aan DNB vanuit de gemeenten

  • Hoe gaat dit in zijn werk: maandelijkse factuur of self-billing principe?

  • Wat hebben jullie als gemeenten nodig qua detail? 

Jullie collega’s van de financiële dienst worden uitgenodigd op een volgende werkgroep

Discrepanties omgevingsloket

Probleemstelling

Zij er discrepanties tussen gemeentelijke data omgevingsvergunning en wat in omgevingsloket zit? In functie van latere koppeling VIP met het omgevingsloket.

Input gemeenten

  • Welke aanpassingen:

    • Geometrie

    • Omschrijving passen ze wel aan in functie van consequentie

  • De aanpassingen gebeuren lokaal in eigen software en stromen niet terug naar het omgevingsloket

  • Bij Leuven: pas volledig en ontvankelijk als geometrie overeenkomt met de realiteit

  • Kavels worden door aanvragers dikwijls niet of slordig ingetekend

  • Bij Antwerpen is de afspraak dat dossier onontvankelijk wordt verklaard als contour verkeerd is omdat aanpassingen niet terugvloeien en anders is er een discrepantie tussen GIS bij gemeente en de 'officiële' (en verschillen die later niet kunnen opgezocht)

  • Leuven: Algemene contour van verkavelingsaanvraag is correct maar specifiek deelkavels (wat is groep, voorschriften… is niet gegeorefeerde info)

  • Brugge: Als het om een ingedeelde activiteit gaat (milieu-luik), dan kunnen de rubrieken anders vergund worden dan aangevraagd. Deze anders-vergunde  rubrieken worden niet geregistreerd in het omgevingsloket, staan enkel in de beslissing die een bijlage is in het omgevingsloket. 

  • Brugge: Wat met beschikbaarheid data? dossiers blijven maar 2 of 3 jaar zichtbaar in het omgevingsloket, dacht ik - na te gaan

  • Antwerpen: Probleem is ook de historische verkavelingscontouren en -loten die niet centraal beschikbaar zijn maar enkel op gemeentelijk niveau

 

Andere/vragen

 

  • Meldingsysteem: er komen veel vragen bij gemeenten over update dossier

    • notificaties zijn geïmplementeerd in iBot en sinds 27/02 gereleased.

    • notificaties waren reds geïmplementeerd in RealSmart, aangevuld met de mogelijkheid welke notificaties

    • voor VIP GUI te bekijken of en wanneer dit zal opgenomen worden en welke notificaties

  • Urgente aanvragen zijn niet mogelijk. Aanvragen worden chronologisch afgehandeld. Sensibilisering vanuit FedNot is al gebeurd.

  • Fouten bij kadastrale perceel nummers (basisregister wordt met maand vertraging geüpdatet, terwijl in de aanvraag toepassing de federale authentieke bron wordt gebruikt)

    • Voorstel om met het oude kadastrale perceel nummer de aanvraag te doen en dan in de toelichting de nieuwe capakey.

  • Inlichting risicogronden OVAM: analyse is ongoing, we komen er later op terug.

  • Algemeen de gewoonte maken als gemeente om bij problemen door te verwijzen naar de servicedesk van de toepassing van de aanvrager

    • Aanvrager moet zelf servicedesk contacteren

    • indien nodig neemt RealSmart of iBOT wel contact op met VIP

  • Issue met aanvragen die blijven hangen

    • Bug in VIP: is gefixed