In een zakLk01 (kennisgeving entiteit 'Zaak') is het mogelijk om een Niet-natuurlijk persoon (NNP) of Vestiging (VES) als betrokkene onder een zaak mee te geven. Voor zowel een NNP als een VES zijn de identificerende gegevens die hier meegegeven kunnen worden summier. Door het nog ontbreken van de koppeling naar het NHR (bij vele gemeenten) hebben veel gemeenten nog geen Vestigingsnummers vastliggen in hun centrale magazijn. Dit is dus haast onmogelijk om een unieke match te maken als verder alleen Handelsnaam en adresgegevens meegegeven kunnen worden. Ik vraag me af waarom er niet voorzien is in het meegeven van het 'handelsregisternummer' (onder gerelateerde entiteit MAC). Dit is namelijk ook HET element dat op binnenkomende post bij een gemeente vaak te vinden is en waarop een identificatie van het bedrijf plaats kan vinden. Het zou in mijn ogen dan ook efficient zijn als dit gegeven meegestuurd kan worden onder (of gerelateerd aan) zowel een VES als een NNP in een zakLk01.
wo, 13-11-2013 - 15.52u
#1
Belangrijke identificerende gegevens bedrijf zitten niet in zakLk01
Dit Erratum is opgevoerd in de onderhoudsverzoeken als ERR308.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Dennis,
Ik heb 2 vraagjes over dit issue.
Ik heb wel een vermoeden maar wil dat graag bevestigd hebben. Ik vermoed dat je daaronder verstaat het 'kvkNummer' zoals dat gedefinieerd staat in de notitie 'De nummers van het Handelsregister' van de Kamer van Koophandel.
Die laatste vraag is van belang omdat dit bepalend is voor de wijze waarop we dit kunnen implementeren in de schema's.
Groet,
Robert
Hoi Robert, Ik bedoel inderdaad het 'kvkNummer' en inderdaad kun je het samenvatten als een verzoek om dit element toe te voegen aan de berichtdefinitie van een zaak-kennisgeving om matching/identificatie in alle situaties correct te kunnen uitvoeren. Groet, Dennis
Als er geen vestigingsNummer of nnpID voor handen is, dan kun je in de gelijknamige elementen BG:inn.nnpId BG:vestingingsNummer het kvkNummer invullen. Quick en dirty maar mogelijk wel een effectieve oplossing.
Tijdens de StUF Expertgroep van 21 mei 2014 is aangegeven dat men toch liever het 'kvkNummer' toevoegt aan de kerngegevens van de betreffende entiteiten.
Het aan de kerngegevens toevoegen van het kvkNummer in vestiging leidt ertoe dat zakLk01 kennisgevingen die nu wel StUF compliant zijn dat ineens niet meer zijn. Dit lijkt me niet acceptabel. Een alternatief is om in VES binnen de belanghebbenden relaties in ZAK niet verplicht het element kvkNummer toe te voegen. Ik zelf zou overigens zeer wel kunnen leven met het uitbreiden van de kerngegevens van VES, maar ik denk dat degenen die dit niet zien zitten niet gedwongen zouden moeten worden om hun software aan te passen om weer StUF compliant te zijn. In een nieuwe versie lijkt het me zeker verstandig om kvkNummer toe te voegen aan de kerngegevens van VES.
Ik heb het toevoegen van 'rps.isEigenaarVan' aan de kerngegevens van NNP en ''oefentActiviteitenUitVoor' aan de kerngegevens van VES verder uitgewerkt en als bijlage toegevoegd. Wellicht kunnen daarmee de gevolgen daarvan beter worden ingeschat.
Bijlage
Deze uitwerking leidt er inderdaad toe dat bestaande implementaties niet meer StUF-compliant zijn. De StUF-expertgroep zal moeten beslissen of ze dit acceptabel vindt.
In overleg van de StUF expertgroep d.d. 17 September 2014 is gesproken over de mogelijkheid om de extraElement van de relatie te gebruiken om het handelsregisternummer in het bericht op te nemen. Om duidelijk te maken dat het extraElement niet bedoeld is voor de relatie maar voor de gerelateerde, wordt de naam van het extraElement: 'gerelateerde.handelsregisternummer'. Deze constructie kan gebruikt worden voor zowel VES als NNP. In de bijlage heb ik een voorbeeld bericht geplaatst van een zakLk01 met daarin een handelsregisternummer voor een overigeBetrokkene (NNP). Dit bericht is valide volgens het StUF Test Platform.
Bijlage
Tijdens de StUF Expertgroep van 19 november 2014 heb ik op basis van de input van Wouter Wigman een voorstel gedaan voor een nieuw extraElement. De StUF Expertgroep heeft het voorstel geaccepteerd met enkele correcties.
Het nieuwe extraElement is inmiddels gepubliceerd in de GEMMA community in de bibliotheek van StUF-ZKN.
Daarnaast is n.a.v. dit issue een RFC opgevoerd (RFC0358) met de bedoeling dit issue in een nieuwe versie van StUF-ZKN goed op te lossen.
Tijdens de StUF Expertgroep van 18 februari 2015 is dit issue als laaghangend fruit aangemerkt. Het doorvoeren van dit issue moet dus geen probleem opleveren.