Beheer van erkenningen

Het beheer van erkenningen werd verder uitgebreid.

Volgende functionaliteiten zijn toegevoegd:

• schorsen van een erkenning

• opheffen van een schorsing

• corrigeren van de reden van een schorsing

• wijzigen van een erkenning

• verwijderen van een erkenning

• automatisch activeren van erkenningen op hun startdatum

• automatisch laten verlopen van erkenningen op hun einddatum

Daarnaast werden verschillende validaties toegevoegd en werd de historiek, detailweergave, mutatiedienst en Power BI-projectie uitgebreid met de bijhorende events.

Zoeken op erkende verenigingen

Het zoekendpoint werd uitgebreid zodat gezocht kan worden op verenigingen die minstens één actieve erkenning hebben.

Opvolgerorganisaties na gemeentefusies

Bij het beheren van erkenningen wordt voortaan rekening gehouden met opvolgerorganisaties die ontstaan na een gemeentefusie.

Hierdoor behouden bevoegde opvolgerorganisaties de mogelijkheid om erkenningen verder te beheren. Ook de historiek werd uitgebreid om deze wijzigingen correct te registreren.

Bewaartermijnen

De toepassing van bewaartermijnen werd verder uitgebreid.

Voortaan wordt ook automatisch een bewaartermijn opgestart wanneer:

• een vertegenwoordiger vanuit KBO wordt verwijderd

• een vertegenwoordiger wordt toegevoegd aan een reeds gestopte vereniging

• een vereniging via de KBO-synchronisatie wordt stopgezet

Bankrekeningnummers

Het beheer van bankrekeningnummers werd uitgebreid.

Een bankrekeningnummer kan voortaan meerdere titularissen bevatten.

Ook de events rond de validatie van bankrekeningnummers werden uitgebreid. Bij een validatie wordt voortaan naast de OVO-code ook de naam van de bevestigende organisatie geregistreerd.

Erkenningen

Het is voortaan mogelijk om erkenningen te registreren voor verenigingen binnen het verenigingsregister.

Meer informatie over de beschikbare endpoints, request- en responsevoorbeelden en de implementatie van deze functionaliteit is beschikbaar in de API-documentatie: https://beheer.verenigingen.staging-vlaanderen.be/docs/api-documentation.html#tag/Decentraal-beheer-van-verenigingen/paths/~1v1~1verenigingen~1%7BvCode%7D~1erkenningen/post

Continues scheduled host

Het omvormen van een scheduled task naar een continues service, die periodiek taken zal uitvoeren.

Bewaartermijnen

De bewaartermijnen werder uitgebreid en consistender toegepast binnen het systeem. Voortaan wordt de bewaartermijn automatisch opgestart in volgende gevallen:

• wanneer een persoon via KSZ als overleden wordt gedetecteerd

• wanneer een vereniging wordt gestopt

• wanneer een vereniging wordt verwijderd

• wanneer een vertegenwoordiger wordt verwijderd

Na het opstarten van de bewaartermijn worden persoonsgegevens na 2 jaar verwijderd.
Hiervoor draait een dagelijkse verwerking die de verlopen bewaartermijnen afhandelt en de bijhorende persoonsgegevens verwijdert.

Bankrekeningnummers – validatie

Er werd een nieuwe mogelijkheid toegevoegd om de validatie van een bankrekeningnummer ongedaan te maken.

Locaties zonder adresmatch

Indien de adresmatch niet correct kon verwerkt worden, wordt deze voortaan dagelijks opnieuw geprobeerd.

Beheer bankrekeningnummers

• Het toelaten dat GI’s bankrekeningnummers kunnen toevoegen aan kbo verenigingen.

• Kbo sync neemt bestaand bankrekeningnummer over via de sync, indien gekend.

• Bankrekeningnummers kunnen toegevoegd worden bij registratie VZER.

• GI kan zijn bankrekeningnummers verwijderen op kbo verenigingen, indien deze niet overgenomen door kbo.

Algemene verbeteringen

• Toelaten van manuele KSZ sync op basis van INSZ

• Projecties

Bugfixes

• Verbeteren datakwaliteit: indien er bij functies persoon geen persoon wordt doorgestuurd, negeren we deze.

Wijzigen gegevens bankrekeningnummers

Deze release introduceert een endpoint om gegevens van bankrekeningnummers te wijzigen. Merk op dat enkel de velden Doel en Titularis gewijzigd mogen worden, niet het IBAN nummer. Als het IBAN nummer gewijzigd moet worden, kan dit gedaan worden door het bestaande bankrekeningnummer te verwijderen en het nieuwe toe te voegen.

Het wijzigingen van de velden Doel en/of Titularis kan via dit PATCH endpoint:

Allerlei

Deze release bevat verder allerlei probleemoplossingen en interne verbeteringen.

Bugfixes vertegenwoordigers

Deze release bevat een aantal oplossingen voor problemen bij de interne afhandeling van vertegenwoordigersdata waardoor er in bepaalde situaties data verloren kon geraken.

Introductie bankrekeningnummers

Deze release introduceert bankrekeningnummers in het register. Voor KBO verenigingen komen deze gegevens mee vanuit synchronisatie met KBO. Voor een vereniging (zonder en met rechtspersoon) zijn er endpoints om rekeningnummers toe te voegen of te verwijderen.

Verenigingen kunnen 1 of meerdere bankrekeningnummers hebben. Elk rekeningnummer kan een IBAN nummer (verplicht), Doel (niet verplicht) en Titularis (verplicht bij VZER) bevatten.

Synchronisatie met KBO

Voor KBO verenigingen worden bankrekeningnummers opgehaald vanuit KBO. Hierbij worden enkel de IBAN nummers opgeslagen, omdat bankrekeningnummers in KBO geen Doel of Titularis hebben.

Rekeningnummer toevoegen aan VZER

Voor een VZER kan een rekeningnummer toegevoegd worden via deze POST call:

Rekeningnummer verwijderen van VZER

Voor een VZER kan een rekeningnummer verwijderd worden via deze DELETE call:

Overnemen van vertegenwoordigers uit KBO

Bij registratie van een nieuwe KBO-vereniging worden ook de wettelijke vertegenwoordigers uit KBO overgenomen als vertegenwoordigers in het verenigingsregister. We nemen hierbij alleen de INSZ, voor- en achternaam over. De andere waarden blijven leeg.

Lees ook: KBO - Als bronbeheerder wil ik de gegevens in VR synchroon houden met die van KBO

Je kan deze data van vertegenwoordigers verrijken met extra velden (roepnaam, rol, isPrimair en contactgegevens) → zie 👬 Vertegenwoordigers - Als GI wil ik de vertegenwoordigers van een vereniging beheren, inclusief contactgegevens

Van zodra we een bericht binnenkrijgen dat de wettelijk vertegenwoordigers gewijzigd zijn in KBO, gaan we vertegenwoordigers toevoegen of verwijderen. Wijzigen zou ook kunnen, maar dan alleen als we zien dat de naam en/of voornaam gewijzigd is.

Vermijden dubbele blokjes in ACM API

Van zodra het verenigingsregister informatie heeft over de personen die gekoppeld zijn aan een KBO vereniging, kunnen we die data ook toevoegen aan het antwoord van de ACM API, wanneer gevraagd wordt welke verenigingen gekoppeld zijn aan en persoon). Om te vermijden dat een vereniging 2x getoond wordt bij het aanmelden op een toepassing, hebben we een extra parameter ingebouwd includeKBOVerenigingen. Met waarde true geeft deze ook de KBO verenigingen weer, met waarde false worden deze uit de response gehaald. Zonder parameter wordt nu false verondersteld.

Synchronisatie vertegenwoordigers met KSZ (enkel VZER)

Vertegenwoordigers die geregistreerd staan bij een VZER worden gesynchroniseerd met KSZ via hun rijksregisternummer (INSZ). Wanneer een INSZ niet bestaat, of wanneer een INSZ verwijst naar een overleden persoon, wordt deze persoon verwijderd uit alle verenigingen waarvan deze als vertegenwoordiger geregistreerd staat. Dit gebeurt via een regelmatige synchronisatie met KSZ.
Ook wanneer een vertegenwoordiger initieel geregistreerd wordt bij een vereniging, gebeurt er een controle of de INSZ bestaat en niet verwijst naar een overleden persoon.

Logging van dubbeldetectie en registratie

We hebben interne logging ingebouwd om te kunnen rapporteren over

• registraties die tegengehouden worden omwille van dubbeldetectie

• registraties die doorgaan na dubbeldetectie (geforceerde registratie)

We hebben grote kuis gehouden in onze code - de bugs er uit gehaald en de zaken mooier gemaakt waar het nodig was. Zo zijn we klaar voor een nieuwe ronde van verbeteringen.

topics: Migratie & fixen van de gevolgen van de Marten update

Bugfixes gelinkt aan upgrades

Door de upgrade naar .net9 zijn er intern een aantal processen die problemen veroorzaakten. Dit had gelukkig geen effect naar buiten toe, maar om onze monitoring niet nodeloos te laten afgaan, hebben we deze toch maar opgelost

Api key toevoegen aan logging publieke API

We loggen vanaf nu ook de API key die gebruikt wordt bij aanroep van de publieke API. Zo kunnen we gerichter zoeken in geval van issues.

Bugfix voor sync met adressenregister

We hebben een bug opgelost die er voor zorgde dat onze dagelijkse sync met adressenregister vastliep.

Automatisch uitvoeren van regressietesten

Onze regressie testen (postman) worden nu automatisch 2x per week uitgevoerd – zo zijn we zeker dat de kwaliteit van onze toepassing alleen maar kan verbeteren en dus niet achteruit gaat. Een subset van die testen wordt zelfs bij elke installatie op test uitgevoerd.

Upgrade naar .net9 en update van alle packages

De toepassing is ge-upgrade naar .net 9, waardoor er ook een aantal packages mee moesten upgraden.

Versnellen rebuild projecties

We hebben de rebuilds van de projecties versneld. Dit is vooral nuttig om de down time tijdens de deploy van een nieuwe versie in te korten. Wat vroeger  40 minuten in beslag nam bij elke installatie, duurt nu maar 8 minuten meer.

Dubbeldetectie uitvoeren voor adresId

Wanneer een VZER geregistreerd wordt en de locaties worden aangeleverd met een adresId (in plaats van adrescomponenten), dan wordt nu eerst gecheckt of het adresId bestaat en worden de adrescomponenten opgehaald vanuit het adressenregister. Pas dan wordt dubbel detectie uitgevoerd op basis van die adrescomponenten.

Publiek zoek sorteren op score

Je kan nu ook de resultaten van de publieke zoek sorteren op het veld score, wat staat voor de matching van de vereniging met de zoekresultaten. Vooral het dalend sorteren op score is hier interessant (sort=-score), omdat je zo de resultaten met de hoogste score eerst krijgt en dus de verenigingen met de beste overeenkomst met de zoekcriteria als eerste te zien krijgt.

Elastic search toevoegen aan health check

De health checks die zichtbaar zijn op de statuspagina, bevatten nu ook de status van de elastic search engines.

Zoeken op geotags

Zowel in publieke zoek als in beheer zoek, is er een zoekcriterium toegevoegd geotags.identificatie. Met dit veld kan je uitgebreider zoeken op basis van een postcode, gemeente of provincie. Dit veld houdt rekening met de postcodes van alle locaties, maar ook met de werkingsgebieden van een vereniging, en wel als volgt:

• wanneer een postcode als criterium wordt opgegeven, worden alle verenigingen terug gegeven met (1) een locatie met die bewuste postcode OF (2) een werkingsgebied dat de gemeente of provincie beschrijft die hoort bij die postcode

• wanneer een gemeente als criterium wordt opgegeven (in de vorm van het werkingsgebied van die gemeente), worden alle verenigingen terug gegeven met (1) een locatie met een van de postcodes binnen die gemeente OF (2) het gemeentelijk werkingsgebied OF (3) het werkingsgebied dat de provincie beschrijft die hoort bij die gemeente

• wanneer een provincie als criterium wordt opgegeven (in de vorm van het werkingsgebied van die provincie), worden alle verenigingen terug gegeven met (1) een locatie met een van de postcodes binnen die provincie OF (2) een van de werkingsgebieden van de gemeenten binnen die provincie OF (3) het werkingsgebied van die provincie

Voorbeelden

geeft alle verenigingen met een locatie met postcode 9000 maar ook alle verenigingen met werkingsgebied Gent (BE23444021) alsook alle verenigingen met werkingsgebied Oost-Vlaanderen (BE23)

geeft alle verenigingen met een locatie die een postcode heeft in Gent (9000, 9030, 9031, ...) maar ook alle verenigingen met werkingsgebied Gent (BE23444021) alsook alle verenigingen met werkingsgebied Oost-Vlaanderen (BE23)

geeft alle verenigingen met een locatie die een postcode heeft in Oost-Vlaanderen (9000, 9030, 9031, 9820, 9090, ...) maar ook alle verenigingen met werkingsgebied van Gent, Merelbeke-Melle, Aalst, … alsook alle verenigingen met werkingsgebied Oost-Vlaanderen (BE23)

PS: Dit veld kan je enkel als zoek criterium gebruiken. Het wordt dus niet weergegeven in de respons body.

Bugfix bij een te grote eTag

Wanneer bij een beheer functie gebruik werd gemaakt van de if-Match header EN daarbij een waarde werd gebruikt die groter was dan de huidige versie van die vereniging, dan gaf dit eerder aanleiding tot een interne fout (status 500), maar wordt dit nu als een 412 terug gegeven.

Voorbeeld:

Mutatiedienst zonder API Key

Voor het gebruik van de mutatiedienst in de publieke API, is nu niet langer een API key vereist.

Bugfix race condition

Er bestond een mogelijkheid om problemen te veroorzaken wanneer 2 wijzigingen in parallel op dezelfde vCode worden uitgevoerd.

Default subtype voor VZER

We hebben de default waarde van het subtype op leeg gezet (zowel bij registratie als bij migratie van eerder geregistreerde feitelijke verenigingen).

Voorbeeld:

Bugfix sorteren op leeftijd

In de zoek functie kon je sorteren op minimum- en maximum leeftijd van de leeftijdsdoelgroep. Dit sorteren gebeurde op een alfanumerieke manier waardoor bijvoorbeeld “2” groter was dan “12”. Dit is nu aangepast zodat het sorteren numeriek gebeurt (en dus 2 < 12).

Bugfix synchronisatie werkingsgebieden

Bij het ophalen van de gemeenten uit het adressenregister was er een bug waardoor sommige gemeenten meerdere malen voorkwamen in de lijst met werkingsgebieden. Dit is nu opgelost zodat we weer een lijst van werkingsgebieden hebben die bestaat uit 285 gemeenten in Vlaanderen, 19 in Brussel, 5 provincies in Vlaanderen en 1 in Brussel, en dan ook nog de waarde NVT-Niet van toepassing.

Bugfix dubbele locaties in zoek functie

In heel uitzonderlijke omstandigheden kon het zich voordoen dat een locatie 2x werd toegevoegd aan de zoekfuncties. Deze situatie zou zich waarschijnlijk nooit voordoen in de productie omgeving, maar we hebben ze toch maar preventief behandeld.

GRAR als bron voor werkingsgebieden

We gebruiken voortaan het adressenregister als de bron om alle gemeenten en hun bijhorende NUTS3 code op te halen. Dit vertaalt zich naar de lijst van mogelijke werkingsgebieden. Anders gezegd: we halen de gemeentelijke werkingsgebieden voortaan uit het adressenregister en niet langer vanuit de EU site (omdat deze met te veel vertraging reageert op veranderingen).

Dit zal er ook voor zorgen dat de werkingsgebieden worden aangepast volgens de gemeente fusies van jan-25.

Documentatie verbeteringen

De swagger bevat voortaan ook het release nummer om eenvoudiger te kunnen verifieren welke twee versies je aan het vergelijken bent

In de API docs zijn ook wat linken aangepast, zoals de link naar de technische documentatie op Confluence. Er staat ook een beschrijving voor de veel gestelde vraag ivm eventual consistency.

Bugfix voor kbo synchronisatie

Wanneer een update binnenkwam van een KBO nummer dat niet gekend was in VR, dan resulteerde dat in een bericht op de DLQ dat telkens manueel moest afgehandeld worden. Dit is nu aangepast zodat updates van ongekende KBO nummers genegeerd worden.

Extra validaties bij subvereniging

Bij het aanduiden van een VZER als subvereniging, wordt er gecontroleerd dat je nooit lid kan zijn van de vereniging waarvan je subvereniging bent. Diezelfde controle wordt ook uitgevoerd bij het beheren van de lidmaatschappen

Lokale deploy versie van VR beschikbaar

We hebben het mogelijk gemaakt om de VR software ook lokaal te installeren. Als dit u interesseert, stuur even een bericht via digitaal.vlaanderen@vlaanderen.be .

Beheren subtype van een VZER

Voor een vereniging zonder eigen rechtspersoonlijkheid (VZER) bestaat er nu ook de mogelijkheid om deze te verfijnen naar een feitelijke vereniging (FV) of naar een subvereniging (SUB). Je kan ze achteraf ook terugzetten naar de default waarde, zijnde “niet bepaald” (NB)

Verfijnen naar FV

Verfijnen naar SUB

In deze call zijn de properties subtype en andereVereniging verplicht op te geven. Properties identificatie en beschrijving zijn optioneel.

Wijzigen van de data van een SUB

Met deze call kan je de extra data van de subvereniging relatie voor deze VZER wijzigen. Dit is natuurlijk enkel mogelijk indien deze VZER eerder al verfijnd werd naar een SUB.

In dit geval is enkel property subtype verplicht. Verder wordt er wel verwacht dat minstens een van de andere velden ook aanwezig is: andereVereniging, identificatie en beschrijving.

VZER terugzetten naar NB

Extra velden in zoek en detail

Het subtype is ook zichtbaar in de zoekresultaten of in het detail van een vereniging (enkel wanneer je data opvraagt met header v2).

Wanneer het subtype = SUB, komt er nog een extra veld beschikbaar

Het veld subverenigingVan.naam is enkel beschikbaar in de detail functie en niet in de zoek.

Adresmatch verbetering

Wanneer een adres wordt ingegeven en adresmatch geeft 1 resultaat weer met een score die < 100%, dan werd die match eerder wel aanvaard. Vandaag wordt een match enkel aanvaard indien er maar 1 resultaat aanwezig is met 100% match.

Bugfix migratie naar VZER van een verwijderde vereniging

Bij de migratie van alle feitelijke verenigingen naar VZERs werden ook alle verwijderde verenigingen terug zichtbaar. Dit is nu gecorrigeerd.

Introductie VZER = Vereniging Zonder Eigen Rechtspersoonlijkheid

We introduceren binnenkort een nieuw concept: de subvereniging. Zowel een subvereniging, als een feitelijke vereniging zijn beide verenigingen zonder eigen rechtspersoonlijkheid (in tegenstelling tot de vereniging met rechtspersoonlijkheid die in KBO gekend zijn). In een eerste stap gaan we alle verenigingen die eerder gekend zijn als feitelijke vereniging nu catalogeren als vereniging zonder eigen rechtspersoonlijkheid. We houden hierbij wel rekening met afnemers en GIs die (nog) niet wijzigen naar de nieuwe versie. Of anders gezegd: als je niets wijzigt aan de manier van integreren, dan zullen de wijzigingen beperkt zijn.

GET’s met of zonder request header

De endpoints beheer zoek en detail, maar ook publiek zoek en detail kan je vanaf nu op 2 verschillende manieren gebruiken:

• Wanneer je geen extra request header toevoegt (en dus blijft werken zoals nu), dan ga je dezelfde verenigingen kunnen zoeken en opvragen, maar wordt het verenigingstype van deze verenigingen vertaald van VZER naar FV-Feitelijke vereniging. Op deze manier kan alle bestaande logica behouden blijven

• Wanneer je wel een extra request header meegeeft (key = vr-api-version, value = v2), dan krijg je het interne type terug, namelijk VZER-Vereniging zonder eigen rechtspersoonlijkheid

Voorbeeld zonder header

Voorbeeld met header

Registreer endpoint(s)

Naast het bestaande endpoint om een feitelijke vereniging te registreren, komt er ook een nieuw endpoint om een vereniging zonder eigen rechtspersoonlijkheid te registreren. Maar.. beide endpoints gaan vanaf nu een vereniging zonder eigen rechtspersoonlijkheid registreren.

Enkel: wanneer je registreert via het endpoint voor feitelijke verenigingen EN er zijn potentiële dubbels, dan worden deze potentiële dubbels teruggegeven met FV als verenigingstype (om compatibiliteits redenen). Wanneer je registreert met het endpoint /vzer, dan worden deze potentiële dubbels teruggegeven met VZER als verenigingstype.

Verschillen die je kan detecteren

Hoewel we deze transitie zo transparant hebben willen maken voor alle afnemers of GIs, zijn er toch een aantal plekken waar je de wijziging zal opmerken wanneer je geen wijziging doet aan je manier van integreren:

• In de historiek van een nieuwe FV of VZER, vind je niet langer de gebeurtenis FeitelijkeVerenigingWerdGeregistreerd terug, maar wel VerenigingZonderEigenRechtspersoonlijkheidWerdGeregistreerd

• In de historiek van eerder geregistreerde feitelijke verenigingen, ga je een extra gebeurtenis terugvinden: FeitelijkeVerenigingWerdGemigreerdNaarVerenigingZonderEigenRechtspersoonlijkheid

• Het verenigingstype in de ACM API werd aangepast van FV naar VZER. Dit is enkel van toepassing indien je dit type had toegevoegd aan je ACM claim bij integratie met global header. Momenteel is dit enkel van toepassing voor het verenigingsloket.

Bugfix dubbel beheer

Er werden 2 bugs opgelost in verband met dubbel beheer

=> Dubbels mogen niet meetellen in de facets van publiek zoek

Wanneer een vereniging als dubbel werd gemarkeerd, dan werd deze vereniging verkeerdelijk meegeteld bij het aantal vereniging per hoofdactiviteit (facets) in de publieke zoek

=> corresponderende vCodes voor nieuwe vertegenwoordiger

Wanneer een vereniging eerst gemarkeerd werd als dubbel en vervolgens werd aan de andere vereniging een nieuwe vertegenwoorriger toegevoegd, dan was het veld corresponderende vCodes voor deze vertegenwoordiger in de ACM API verkeerdelijk leeg.

Negeer gemeentenaam bij dubbel detectie

Bij registratie van een nieuwe feitelijke vereniging wordt eerst een dubbel detectie uitgevoerd. We hebben dit algoritme verbeterd door de gemeentenaam te negeren in de naam van de vereniging. In de vorige versie werden Club Dorpegem en Vereniging Dorpegem uit gemeente Dorpegem beschouwd als dubbels (omdat 50% van de naam overeenkomt). In deze versie gaan we uit de naam van de vereniging eerst de gemeentenaam zoals aangeleverd weghalen en dan pas gaan zoeken naar potentiële dubbels. In het voorbeeld worden nu Club en Vereniging met elkaar vergeleken, wat niet langer leidt tot een dubbel detectie.

We verwijderen de gemeentenaam zoals aangeleverd, dus niet de officiële naam (zoals we die waarschijnlijk achteraf terugvinden na adresmatch). Dit doen we voor ALLE gemeentenamen van elke opgegeven locatie. Wanneer de gemeentenaam wordt aangeboden in het formaat Delegem (Dorpegem), dan worden zowel Delegem als Dorpegem verwijderd uit de verenigingsnaam (voor dubbel detectie).

Bugfix ACM API voor corresponderendeVCodes

Wanneer een vertegenwoordiger werd toegevoegd aan een vereniging met corresponderende vCodes, dan werden die niet overgenomen in de ACM API response voor die vertegenwoordiger.

bugfix KBO sync voor gestopte verenigingen

Een bug in onze code zorgde er voor dat verenigingen die gestopt zijn in KBO niet gesynchroniseerd werden naar het verenigingsregister, waardoor ze daar ten onrechte als actief bleven staan.

Vereniging markeren als dubbel

We voorzien de mogelijkheid om een vereniging te markeren als dubbel van een andere vereniging. Deze actie kan enkel intern uitgevoerd worden en aangevraagd worden met een service ticket. De gevolgen van een dubbel markering zijn hieronder beschreven. Er zijn telkens gevolgen mogelijk voor:

• de dubbele vereniging (diegene die daarna niet meer direct bereikbaar zal zijn)

• de authentieke vereniging (diegene die nog bereikbaar blijft)

Beheer API

• Beheer zoek

  • De dubbele vereniging is niet meer terug te vinden.

  • Bij de authentieke vereniging wordt de lijst in veld corresponderendevCodes uitgebreid met de vCode van de dubbele vereniging

• Beheer detail

  • De status van de dubbele vereniging wordt Dubbel. In het veld isDubbelVan komt de vCode van de authentieke vereniging

  • Bij de authentieke vereniging wordt de lijst in veld corresponderendevCodes uitgebreid met de vCode van de dubbele vereniging

• Dubbeldetectie

  • De dubbele vereniging wordt niet meer als potentiële dubbel getoond

  • De authentieke vereniging kan wel nog als potentiële dubbel getoond worden

Publieke API

• publiek zoek

  • De dubbele vereniging is niet meer terug te vinden (status 404)

  • Geen wijziging aan de authentieke vereniging

• publiek detail

  • De dubbele vereniging is niet meer terug te vinden (status 404)

  • Geen wijziging aan de authentieke vereniging

• mutatiedienst

  • zowel de dubbel als de authentieke vereniging worden gemarkeerd als gewijzigd

ACM API

• De dubbele vereniging komt niet meer in de resultaten voor

• Bij de authentieke vereniging wordt de lijst in veld corresponderendevCodes uitgebreid met de vCode van de dubbele vereniging

Automatische adreswijzigingen omwille van gemeentefusies