Nadere uitwerking gestructureerde datatypes: BAGid. KvK-nummer, CAS nummer, UN nummer

[PeterFrans]

Aanleiding wijziging

In het IMEV 1.3 is een aantal identificatienummers opgenomen, o.a.

• BAGid;
• KvK nummer;
• CAS nummer;
• UN nummer;
• ....

Het bestaande pattern is niet specifiek genoeg voor data validatie en dus kwaliteit. Dit kan specifieker:

• een BAGid bestaat altijd uit 16 cijfers (muv dat voor een 'Woonplaats', maar die hoeft niet vastgelegd te worden in het REV). Zie voor een nog specifiekere beschrijving de Catalogus BAG, 2018, paragraaf 3.7.1;
• KvK-nummer bestaat uit 8 cijfers (zie 'De nummers van het handelsregister, p.5);
• CAS nummer voldoet ook aan vaste eisen (o.a. max 10 cijfers, zie wikipedia: 'CAS-nummer en 'Controlegetal');
• UN nummer bestaat uit 4 cijfers, beginnend vanaf 0004 (0000 tm 0003 zijn buiten gebruik, zie 'Range' bij 'UN number' op de Engelstalige Wikipedia pagina)

Voorgestelde wijziging

Een striktere beschrijving (specifieker pattern) moet in het IMEV worden opgenomen, zodat in de API van het REV hier beter op gevalideerd kan worden. Dit komt de datakwaliteit in het REV ten goede.

Impactanalyse

Geef hier een indicatie van de impact van de wijziging:

• Wie gaat er wat van merken? - Softwareleveranciers, gebruikers
• Veranderen definities van objecten in de standaard zodanig dat de wijziging impact heeft op de uit te wisselen gegevens? Nee
• Heeft het impact op het json-schema? Nee
• Kan leiden tot een opschoon actie om foutieve data te corrigeren.

Prioriteit

laag

Toelichting

Een striktere beschrijving vergemakkelijkt de validatie van gegevens en komt de kwaliteit van de gegevens in het REV ten goede.
Gerelateerd aan #33

[PB-GNM]

dit raakt aan issue #33

[JanCasSmitGeonovum]

Expert overleg IMEV 16 MEI 2023, thema aansluiten op andere registraties

Voorgestelde wijziging inhoudelijk akkoord? Ja

1. Wat adviseren we de adviesgroep: doen
2. Wat is de prioriteit (laag)
3. Klopt de beschreven impact (Nee)
   Heeft wel invloed op het json schema.
   Kan leiden tot een opschoon actie om foutieve data te corrigeren.

[PB-GNM]

Tijdens het softwareleveranciersoverleg van 7 juni is er geen bezwaar geuit tegen het doorvoeren van deze wijziging.

[PB-GNM]

Opgelost in versie 2.0.