Toekomstige wijziging: Minimum Dataset
Binnenkort gaan we in het verenigingsregister enkele wijzigingen doorvoeren die mogelijks impact hebben op jullie toepassing. Met dit bericht geven we uitleg over de wijzigingen zodat u kan verifiëren of er impact is en zo ja, de nodige aanpassingen kan doorvoeren vooraleer wij deze doorvoeren in de productie omgeving.
De wijzigingen worden samengevat onder de noemer “Minimum dataset”. We willen hiermee de datakwaliteit van een vereniging verhogen = er voor zorgen dat er meer data beschikbaar is van een vereniging. Tegelijkertijd willen we de registratie van een nieuwe vereniging toch zo licht mogelijk houden en hier dus niet al te veel verplichten.
Behoud van data
Voor locaties, vertegenwoordigers en hoofdactiviteiten gaan we ons focussen op het behoud van de gegevens, van zodra deze voor de eerste keer al eens ingevuld zijn. Om dit te realiseren gaan we extra controles invoeren om de volgende situaties te vermijden:
het verwijderen van de laatste vertegenwoordiger (bij een feitelijke vereniging)
het verwijderen van de laatste locatie
het leeg maken van de lijst met hoofdactiviteiten
Verplicht contactpunt
We hebben niet veel aan de gegevens van een vereniging die we niet op een of andere manier kunnen contacteren. Daarom wensen we hier iets strenger in te zijn. We gaan hier niet enkel controleren dat het laatste contactpunt niet mag verwijderd worden, maar ook dat er van bij de registratie van een nieuwe feitelijke vereniging) al minstens 1 contactpunt aanwezig is.
Een contactpunt is een van volgende mogelijkheden:
Een contactgegeven direct gekoppeld aan de vereniging met type = E-mail of Telefoon
een vertegenwoordiger waarvoor een van volgende velden is ingevuld: E-mail, telefoon of mobiel
Om dit te realiseren, worden extra controles ingevoerd om volgende situaties te vermijden
het verwijderen van het laatste contactpunt
het registreren van een nieuwe feitelijke vereniging zonder enig contactpunt
Wanneer
We gaan deze wijzigingen eind Q3 implementeren, te starten met de controles op het verwijderen van de laatste vertegenwoordiger, locatie en hoofdactiviteit.
We verwachten dat de implementatie van het contactpunt, mede door de extra verplichting bij registratie, meer tijd zal vergen, zowel langs onze kant als langs jullie kant. Deze wijziging zal dus als laatste worden doorgevoerd.
Technische impact
Hieronder vind je een overzicht van de endpoints die een extra fout kunnen teruggeven (http status 400). Je kan ervoor kiezen om deze fout gewoon op te vangen en te tonen aan je eindgebruiker OF ervoor zorgen dat de fout niet kan voorkomen omdat dit eerder al in jullie user interface werd gecontroleerd.
Bij elk endpoint vermelden we eveneens of dit voor een feitelijke vereniging (FV) en/of voor een KBO vereniging (KBO) geldig is.
(FV) DELETE /v1/verenigingen/<vCode>/vertegenwoordigers/<vertegenwoordigerId>
=> Wanneer dit de laatste vertegenwoordiger was, zal deze API call geweigerd worden
=> Wanneer dit de laatste vertegenwoordiger was met een contactpunt, zal deze API geweigerd worden
(FV+KBO) DELETE /v1/verenigingen/<vCode>/locaties/<locatieId>
=> Wanneer dit de laatste locatie van deze vereniging was, zal deze API call geweigerd worden
=> let op: (voor KBO verenigingen) De locatie met type maatschappelijke zetel volgens KBO kan je niet verwijderen, maar telt wel mee om het aantal resterende locaties te tellen.
(FV+KBO) PATCH /v1/verenigingen/<vCode>
=> Wanneer de verenigingen hoofdactiviteiten had en de call bevat "hoofdactiviteitenVerenigingsloket": [], zal de API call geweigerd worden
(FV+KBO) DELETE /v1/verenigingen/<vCode>/contactgegevens/<contactgegevenId>
=> Wanneer dit het laatste contactpunt was, zal deze API call geweigerd worden
(FV+KBO) PATCH /v1/verenigingen/<vCode>/vertegenwoordigers/<vertegenwoordigerId>
=> Wanneer in deze call het laatste contactpunt leeg gemaakt wordt, zal deze API call geweigerd worden
(FV) POST /v1/verenigingen/feitelijkeverenigingen
=> Wanneer deze call niet minstens 1 contactpunt bevat, zal deze geweigerd worden.