Algemeen: initiële adresmatch

We hebben een proces toegevoegd dat alle adressen overloopt in het register. Elke adres dat nog niet is geverifieerd ten opzichte van het adressenregister, wordt opgezocht via adresmatch. Wanneer een resultaat wordt gevonden, wordt het adresId toegevoegd en worden de adrescomponenten aangepast aan de spelling zoals deze in het adressenregister voorkomt.

Publieke API: Mutatie dienst

In de publieke API is een nieuw endpoint beschikbaar dat kan gebruikt worden voor afnemers die synchroniseren naar hun eigen databank/CRM. Met dit endpoint kan je alle vCodes opvragen waarvoor er een wijziging is gebeurd sinds de laatste keer dat je de synchronisatie hebt uitgevoerd.

Om dit endpoint aan te spreken heb je een API Key nodig.

Voorbeeld:

GET <publiekURL>/v1/verenigingen/mutaties?sinds=<vorigeMaxSequence>
response body:
[
    {
        "vCode": "V0001027",
        "sequence": 86
    },
    {
        "vCode": "V0001024",
        "sequence": 89
    }
]

In dit voorbeeld weet je nu dat V0001027 en V0001024 gewijzigd zijn. Om die te synchroniseren, haal je data op via een of meerdere van volgende (bestaande) endpoints:

• Beheer Detail: <BeheerURLviaMAGDA>/v1/verenigingen/<vCode>

  • om alle gegevens van een vereniging op te vragen

• Publiek Detail: <PubliekURL>/v1/verenigingen/<vCode>

  • om alle publieke gegevens van een vereniging op te vragen - dit gebruik je wanneer jouw organisatie enkel met publieke gegevens werkt OF wanneer je geen recht hebt om alle gegevens via MAGDA op te vragen

• Beheer Historiek: <BeheerURLviaMAGDA>/v1/verenigingen/<vCode>/historiek

  • om meer informatie te bekomen over de wijzigingen die zijn uitgevoerd (enkel wanneer je hier toegang toe hebt)

Na synchronisatie, onthou je de hoogste verwerkte sequence (in het voorbeeld is dat 89) zodat je de volgende keer alle nieuwe wijzigingen kan opvragen via

GET <publiekURL>/v1/verenigingen/mutaties?sinds=89

Goed om weten: in dit endpoint komen ALLE vCodes voor en worden ALLE wijzigingen gereflecteerd. Dit heeft enkele gevolgen die je best mee overweegt bij de implementatie van deze mutatiedienst. Enkele voorbeelden:

• Wanneer er iets veranderd aan een vertegenwoordiger van een vereniging, dan is dit een wijziging, maar via de publieke data stroom zal je geen enkel verschil opmerken.

• Wanneer een vereniging uitgeschreven wordt uit de publieke datastroom, dan komt dit naar voor als wijziging, maar via de publieke datastroom betekent dit dat je de vereniging plots niet meer zal terugvinden. (Publiek detail geeft dan een 404)

• Wanneer een vereniging verwijderd wordt, dan komt dit naar voor als wijziging, maar noch bij publiek, noch bij beheer detail zal je deze vereniging nog terugvinden (respons = 404). Via beheer historiek kan je wel nog terugvinden dat deze vereniging verwijderd is, met daarbij de reden van verwijdering.

Dagelijkse synchronisatie met het adressenregister

Deze kleine update zorgt er voor dat er nu dagelijks automatisch een synchronisatie loopt met het adressenregister.

Wijzigingen aan publieke API

Geen

Info over beheer mogelijkheden

Synchronisatie met het adressenregister

Wanneer een adres wordt opgegeven met een adresId EN adrescomponenten (straatnaam, huisnummer, …) dan wordt dit nu geweigerd.

Wanneer een adres wordt opgegeven met enkel een adresId, dan worden de bijhorende adrescomponenten opgehaald uit het adressenregister, maar enkel wanneer het adresId verwijst naar een bestaand adres in status Ingebruik of Voorgesteld.

Wanneer adresmatch de adrescomponenten wijzigt en hierdoor zou een identieke locatie ontstaan (zelfde locatietype, naam en adres), dan zal een van de identieke locaties verwijderd worden: de locatie die als primair is aangeduid blijft behouden, de andere verdwijnt. Wanneer beide locaties als niet primair stonden aangeduid, dan wordt de nieuwste locatie verwijderd

Bugfix voor lege locatie naam

Stel: een vCode heeft een locatie met type = activiteiten en naam leeg ("naam": ""). Wanneer dan een nieuwe locatie wordt toegevoegd met type = activiteiten en hetzelfde adres maar in de request om toe te voegen wordt het naam veld niet ingevuld, dan werd deze locatie toch niet als dubbel gezien. Dit is nu opgelost, zodat het weglaten van het naam veld hetzelfde reageert als het toevoegen van "naam": ""

Adresmatch op ingevoerde adressen

Alle ingevoerde adressen worden nagekeken of ze al dan niet overeenkomen met een bestaand adres uit het adressenregister. Wanneer een match gevonden wordt, wordt de juiste spelling van het adres overgenomen. Het adres krijgt dan ook een adres ID toegewezen (zie locaties.adresId.bronwaarde)

Statuspagina

Op https://www.vlaanderen.be/digitaal-vlaanderen/status/status-overzicht?product=Verenigingsregister vind je de status van de verschillende API’s op de 2 omgevingen terug. Je kan je ook abonneren op meldingen zodat je hiermee automatisch op de hoogte gebracht wordt van nieuwe releases en/of zware incidenten.

Bugfix voor de synchronisatie met KBO

Na de release op staging van de vorige versie, is gebleken dat er nog problemen waren met de synchronisatie met KBO. Deze bugs zijn in deze versie aangepakt, zodat we nu toch van start kunnen gaan met de KBO synchronisatie.

Synchronisatie met KBO

De gegevens van de verenigingen met rechtspersoonlijkheid worden bij registratie overgenomen uit KBO. Vanaf nu gaan we ook dagelijks de wijzigingen in KBO synchroniseren naar het verenigingsregister. Zowel de naam, korte naam, startdatum, maatschappelijke zetel als de contactgegevens worden daarbij gecontroleerd. Ook wanneer een KBO vereniging stopt in KBO (status in KBO is niet langer Actief of in oprichting), wordt de vereniging gestopt in het verenigingsregister.

Bugfixes JSON-LD

2 kleine wijzigingen aan het JSON-LD output formaat:

• De context bevatte nog een komma op het einde wat een probleem veroorzaakte bij het converteren naar triples

• Bij het veld hoofdactiviteit.code was de prefix act: vergeten

Verbeteringen publiek zoek sorteren

Wanneer de resultaten van de publieke zoek gesorteerd worden op een tekstveld, dan worden ook hier enkele verschillen in schrijfwijze genegeerd om een intuitievere sortering te bekomen.

Bij het sorteren op tekstvelden, negeren we enkele verschillen in schrijfwijze:

• hoofdletter ongevoelig ( A = a, B = b, …)

• accent ongevoelig (é = è = ê = ë = e, à = â = ä = a, …)

• puntjes worden weggewerkt (a.b.c = abc)

• leading spaces (zodat “ AAA” voor “ZZZ” komt)

Output in JSON-LD formaat

Zowel de publieke zoek als de publieke detail endpoints zijn nu in JSON-LD formaat. Om dit te realiseren zijn enkele velden toegevoegd en is ook het context bestand opgevuld. Samen zorgen deze er voor dat de gehele output correct vertaald kan worden naar triples.

verbeteren publieke zoek resultaten

Bij het zoeken op tekstvelden, negeren we enkele verschillen in schrijfwijze:

• hoofdletter ongevoelig ( A = a, B = b, …)

• accent ongevoelig (é = è = ê = ë = e, à = â = ä = a, …)

• puntjes worden weggewerkt (a.b.c = abc)

• leestekens worden genegeerd

toevoegen korte beschrijving aan publieke zoek

In het zoekresultaat werd nu ook de korte beschrijving toegevoegd. Dit veld kan eveneens gebruikt worden als zoekcriterium.

Voorbeeld: Onderstaande URL zoekt naar alle verenigingen die het woord tennis in hun korte beschrijving hebben staan. Het 2e voorbeeld zoekt naar alle verenigingen die het woord tennis in een van de zoekvelden hebben staan, dus niet alleen in de korte beschrijving, maar dit kan ook terug te vinden zijn in de naam, de korte naam, het adres…

GET <publiekURL>/v1/verenigingen/zoeken?q=korteBeschrijving:*tennis*
GET <publiekURL>/v1/verenigingen/zoeken?q=*tennis*