Nieuwe nummers KvK

Dit is een statische kopie van het eerdere discussie.kinggemeenten.nl.
Nieuwe discussies kunnen in de GitHub repository 'StUF standaarden' als issue worden opgevoerd.

6 reacties / 0 nieuw
Hein van Schijndel
Nieuwe nummers KvK

De Kamer van koophandel levert mutatieabonnementen aan gemeenten. (txt bestanden). Binnen een gemeenten worden deze bestanden ingelzen in bv Key2Datadistributie en met StUF-Bg 02.04 berichten gedistribueerd naar afnemers. In de mutatieabonnementen komen de elementen vestigingsnummer en RSIN nu ook voor.

Zover ik kan zien zijn deze 2 nieuwe elementen niet opgenomen in StUF-BG 02.04 maar wel in het RSGB en StUF-Bg 03.10. Is het een idee om voor StUF-BG 02.04 2 extra elementen te definieren?

Anoniem

Prima voorstel. Laten we goed kijken naar de definities van de reeds bestaanden elementen en de beoogde nieuwe elementen. Vanuit het oogpunt van compatibiliteit moeten zowel de oude als nieuwe nummers naast elkaar kunnen bestaan. Ook moet de mapping van bg0204 op bg0310 en vice versa hierop aangevuld worden.

Anoniem

In tegenstelling tot het attribuut 'vestigingsNummer' komt het attribuut RSIN niet voor in bg0310 en het RSGB.

Voor 'vestigingsnummer' lijkt ons de gevraagde aanpassing op zijn plaats. Wat betreft 'rsin' vragen Henri en ik ons af of de opname van 'rsin' als extraElement wel terecht is! In bg0204 bevat NNP nl. het attribuut 'sofinummer' en in bg0310 bevat VES de attributen 'inn.nnpid' en 'ann.identificatie'.
Is het niet voldoende om de mapping tussen 'sofinummer' enerzijds en 'inn.nnpid' en 'ann.identificatie' anderzijds te definieren?

Annemiek Droogh

Robert, volgens ons komt het RSIN wel voor, maar wordt deze inn.nnpid genoemd. Het lijkt ons voldoende om de mapping tussen 'sofinummer' enerzijds en 'inn.nnpid' anderzijds te definieren.

'ann.identificatie' betreft andere niet natuurlijke personen. Als er een RSIN is, dan is er toch geen sprake van een andere niet natuurlijke persoon?

Anoniem

Annemiek, inderdaad we kunnen inn.nnpid prima gebruiken voor RSIN. Dus RSIN hoeven we niet toe te voegen in bg0310. Ook de mapping tussen 'sofinummer' en 'inn.nnpid' is al in beide richtingen gespecificeerd in de vertaaltabellen, hoeven we dus ook niet aan te doen.

Er is een voorstel gedaan om RSIN wel toe te voegen aan NNP in bg0204. Dit hoeft volgens mij ook niet want we kunnen daarvoor het veld 'sofinummer' gebruiken. Wel moeten we het veld 'vestingsnummer' als extraElement toevoegen aan NNP in bg0204. Bovendien moeten we dan de  vertaaltabellen uitbreiden met een mapping van 'bg0204.NNP.vestigingsnummer' naar 'bg0310.VES.vestingingsnummer' en vice versa.

Anoniem

Correctie aangebracht in patch 12 (ERR228), post gesloten