In BG3.10 is voor NNP's de nnp.id verplicht. Als zaaksysteem bevragen wij het gegevensmagazijn, bij het bevragen van NNP's krijgen wij echter niet altijd een nnp.id terug. Zonder nnp.id is het bericht niet geldig conform de standaard en wordt het antwoordbericht door ons zaaksysteem afgekeurd.
Het gegevensmagazijn geeft aan deze gegevens ook leeg te ontvangen vanuit het NHR waardoor deze niet altijd gevuld is.
De standaard schrijft enkel voor dat nnp.id verplicht is en uniek moet zijn. De standaard beschrijft niet met welke waarde nnp.id gevuld moet zijn.
Voor de hand ligt het om nnp.id te vullen met het RSIN. Eenmanszaken hebben echter geen RSIN maar vallen wel onder NNP. Hoe gaan andere hier in de praktijk mee om? Hoe wordt nnp.id gevuld in het gegevensmagazijn?
Van deze vraag is Issue 489968 aangemaakt.
Hallo Michiel,
Kun je aangeven hoe dit nu verder gaat met dit issue? wanneer kunnen wij hier een reactie op verwachten?
Hallo Dave,
Ik ben verder niet de autoriteit op dit gebied maar je geeft aan "de standaard schrijft enkel voor": Welke standaard bedoel je hier precies? En in welk bericht komt dit voor? Heb je een voorbeeldbericht wat niet correct zou zijn?
Even ervanuitgaande dat dit in een bevraging voorkomt: In de xsd schema's (bg0310_msg_vraagAntwoord.xsd) kan ik voor geen van de nnpLa* berichten vinden dat volgens het xsd schema nnpId verplicht is. Niet als element en niet qua inhoud.
Ingeschreven niet natuurlijke personen hebben altijd een NNP-id als unieke aanduiding
Daarnaast onderkennen we ook andere niet natuurlijke personen die niet ingeschreven zijn in het handelsregister maar waarmee een gemeente wel zaken doet. Deze hebben een nummer ander niet natuurlijk persoon als unieke aanduiding.
In RSGB 2.0 betreft dit de ANDER BUITENLANDS NIET NATUURLIJK PERSOON maar in RSGB 3.0 is dit objecttype hernoemt naar ANDER NIET NATUURLIJK PERSOON omdat onderdelen van de rechterlijke macht nog niet zijn ingeschreven in het NHR maar gemeenten daarmee ook kontakten onderhoudt. Ook kerkelijke organisaties zijn niet ingeschreven in het NHR. In StUF zit dus een fout.
Wat is dan precies de fout in StUF?
In het verStUFfingsdocument van StUF-BG 3.10 staat:
De objecttypen INGESCHREVEN NIET NATUURLIJK PERSOON (INN), ANDER BUITENLANDS NIET NATUURLIJK PERSOON (ANN) en NIET NATUURLIJK PERSOON (NNP) worden geïmplementeerd binnen het StUF-entiteittype NNP. Het entiteittype NNP bevat de vereniging van de attributen van INGESCHREVEN NIET NATUURLIJK PERSOON en ANDER BUITENLANDS NIET NATUURLIJK PERSOON.
En als je in het schema van StUF-BG 3.10 kijkt dan zie je dat er binnen NNP verschillende identificatie-elementen zijn.
Voor een NNP de nnp.id en voor ANN de ann.identificatie. Maar zoals Michiel al schrijft is in StUF-BG 3.10 inn.id maar ook ann.identificatie niet verplicht.
Dank voor jullie reacties. De BG XSD's dwingen de verplichtheid inderdaad niet af. Als we kijken naar het onderliggende datamodel van RSGB 2.01 heeft NNPid echter als kardinaliteit 1-1. Volgens de onderliggende documentatie is deze dus wel verplicht.
Als ik een nnpLa01 bericht zonder nnpid aanbied als adhoc test op het StUF TestPlatform wordt dit bericht ook afgekeurd vanwege het ontbreken van de nnpid.
Als ik kijk naar zaak- en documentservices 1.1.02 is indien initiator is nietNatuurlijkPersoon enkel inn.nnpid of ann.identificatie verplicht. Hier wordt deze verplichtheid dus ook afgedwongen. Als dit gegeven echter niet verplicht is in BG 3.10 kan het zaaksysteem op basis van deze gegevens dus niet altijd het betreffende object bevragen in het gegevensmagazijn, daar kan dit gegeven immers leeg zijn. Het zaaksysteem kan deze objecten dan bevragen en gaan volgen.
Vanuit de praktijksituatie blijf ik dus tegen de volgende issues aanlopen:
1) Klopt het nu dat in BG3.10 voor een niet natuurlijk persoon nnpid of ann.id verplicht gesteld is, en het gegevensmagazijn gegeven dus altijd één van deze 2 elementen met een waarde dient aan te leveren in het nnpla01 bericht?
2) Kan worden vastgesteld dat voor niet natuurlijke personen nnpid de waarde heeft overeenkomend met het RSIN? Zaak- en documentservices schrijft dit voor, dus dit zou dan ook moeten gelden voor BG3.10.
3) Hoe om te gaan met andere niet natuurlijke personen die niet ingeschreven zijn in het handelsregister? Deze kunnen nu niet met BG3.10 en zaak- en documentservices worden uitgewisseld, aangezien deze niet kunnen voldoen aan de verplicht gestelde velden. De oplossing hiervoor zit wel in RSGB3.0, maar nog niet in een StUF versie.
4) Geldt punt 3 ook voor de eenmanszaken? Vallen deze in RSGB3.0 onder andere niet natuurlijke personen of onder niet natuurlijke personen? En op welke wijze dienen deze dan te worden uitgewisseld binnen BG3.10 en zaak- en documentservices?
Al met al zien wij nu een aantal zaken die de bij de inzet van BG3.10 en zaak- en documentservices tot problemen leiden waardoor berichten en gegevens niet uitgewisseld kunnen worden. Dit levert niet alleen een probleem op voor ons als leverancier, maar nog meer voor onze klanten die wij willen bedienen met de inzet van deze standaarden.
Uiteraard zijn wij bereid om bovenstaande punten in een overleg met KING en eventuele andere leveranciers te bespreken om tot een gezamenlijke oplossing te komen.
Hi Dave,
Ik kan alleen reageren op punt 4 en hoe het zit in RSGB 3.0 m.b.t. de eenmanszaak. In RSGB3.0 heeft een Maatschappelijke activiteit een Persoon als eigenaar. Dit kan een natuurlijk persoon zijn (m.a.w. de eenmanszaak) of een niet natuurlijk persoon. Als het een eenmanszaak is dan wordt de eigenaar geïdentificeerd middels het BSN anders via het RSIN.
Zie ook de discussie: https://vng-realisatie.github.io/StUF-Standaarden/discussie/gemma/rsgb/werkgroep-rsgb-3....
Hoop dat dit het antwoord is op je vraag.
@post #7 van Dave.
Ad 1. Nee, StUF vereist alleen dat een object in een antwoordbericht is opgenomen, als aan één van de twee volgende voorwaarden is voldaan:
Voor een NNP zijn dit de kerngegevens:
Dus als een systeem alleen een statutaireNaam terug kan geven in plaats van een inn.nnpId is het voor StUF voldoende. Er kunnen namelijk allerlei redenen zijn waarom een systeem niet alle kerngegevens kan leveren ook al hebben ze kardinaliteit 1-1 in het RSGB. Bijvoorbeeld: iedereen heeft een geboortedatum en daarom heeft dit (kern)gegeven kardinaliteit 1-1 in het RSGB. Maar niet elk systeem kan of mag een geboortedatum leveren.
In bg0310 is de hierboven beschreven StUF-regel (minimaal één kerngegeven in antwoordbericht) niet verder aangescherpt.
Ad 2. De manier waarop het element inn.nnpId gevuld moet worden in bg0310 staat beschreven in het RSGB 2 en wordt in StUF gevolgd. Als je daar iets anders wilt is dat een RFC of een patch op het RSGB 2.
Ad 3. Waarom kunnen andere niet-natuurlijke personen niet worden uitgewisseld met bg0310? Het veld ann.identificatie heeft lengte 17, dat moet toch voldoende zijn lijkt me.
Dank voor jullie feedback. Dit geeft in ieder geval meer duidelijkheid.
Wat betreft Ad 3, bg0310 kent enkel een ander buitenlands niet natuurlijk persoon. Deze kan kan dus niet gebruikt worden aangezien dit object niet beschikt voor een nederlands bezoekadres, hierbij kunnen enkel de verblijfbuitenland velden in meegegeven worden.
Je laatste opmerking begrijp ik niet. In bg0310 zijn de objecttypen "Ingeschreven Niet-Natuurlijk Persoon" en "Ander buitenlands Niet-Natuurlijk Persoon" samengevoegd (oftewel: platgeslagen) in het entiteittype "Niet-Natuurlijke Persoon" (NNP). Dus in het bericht nnpLa01 kun je kiezen of je een Nederlands bezoekadres wilt opnemen of een verblijf in het buitenland.
Het feit dat twee objecttype zijn platgeslagen wil nog niet zeggen dat het de bedoeling is dat je over en weer elkaars eigenschappen kunt gaan gebruiken. Op een ANN zitten volgens het RSGB 2.0 alleen de adresgegevens van postadres en verblijfBuitenland; alleen die gegevens zullen dus gevuld zijn. Het 'misbruiken' van de NNP-attributen zou wel een oplossing zijn voor dit probleem, maar daar zouden dan wel alle partijen in de keten aan moeten meewerken...
Het is inderdaad niet de bedoeling om over en weer elkaars eigenschappen te gebruiken. Dus als binnen de NNP-entiteit van bg0310 het element <sub.typering> gelijk is aan "Ander buitenlands niet-natuurlijk persoon" dan mag je alleen de elementen gebruiken die bij dat type horen volgens RSGB 2. In dit geval niet het element <bezoekadres> maar wel het element <sub.verblijfBuitenland>.
Wat is nu je probleem waarbij misbruik van NNP-attributen de oplossing zou moeten zijn? Hebben jullie een Nederlands bezoekadres nodig bij een buitenlandse niet-natuurlijk persoon, of iets dergelijk?????
Een praktijkvoorbeeld:
Een zaak wordt geïnitieerd door een kerkelijke organisatie. Zoals Ellen aangeeft hebben deze geen nnpid, maar zouden ze een ander niet natuurlijke persoon aanduiding (ann.identificatie) moeten hebben. Conform zaak- en documentservices moet in het creeerzaak bericht of de nnpid meegegeven worden, of de ann.identificatie.
Wordt in dit bericht voor de kerkelijke organisatie een ann.identificatie meegegeven, dan zouden dit betekenen dat het betrekking heeft op een ander buitenlands niet natuurlijke persoon. Dit is echter niet het geval. Hoe dient deze kerkelijke organisatie via zaak- en documentservices aangeleverd te worden?
Als een andere partij in het creeerzaak bericht wel een ann.identificatie meegeeft voor dergelijke organisatie, hoe gaan we deze dan opvragen met BG.310 uit het gegevensmagazijn? Op basis van deze identificatie bevragen we de ander buitenlandse niet natuurlijke personen en kunnen we voor dit object nooit een nederlands adres terug krijgen vanuit het gegevensmagazijn. Terwijl het wel nederlandse organisaties betreft.
Andere mismatch die ik zie is het gebruik van nnpid in zaak- en documentservices en BG3.10. In zaak- en documentservices is gesteld dat het volstaat om enkel een nnpid aan te leveren en dat de nnpid gevuld dient te worden met het RSIN. Het RSGB laat open of de nnpid het RSIN is en stelt enkel dat nnpid een unieke identificatie is toegekend door de KvK.
Als er nu een creeerzaak binnenkomt met enkel een nnpid (RSIN) voor de initiator kunnen wij op basis van dit gegeven alleen niet altijd het object ophalen uit het gegevensmagazijn met een BG3.10 vraag. Hetzelfde object kan wel in het gegevensmagazijn bestaan, maar kan een lege nnpid hebben of een andere waarde hebben voor nnpid. Het zaaksysteem kan de gegevens van het object niet ophalen uit het gegevensmagazijn en ook geen afnemersindicatie zetten.
Dave, dank voor de uitleg, dit maakt voor mij het probleem duidelijk. Het probleem zit dus in RSGB 2. Daar is kennelijk geen officiële plek voor niet-natuurlijke personen zoals Kerkelijke organisaties. Dit probleem is blijkbaar opgelost in RSGB 3 maar niet RSGB 2. Als je het zuiver wilt oplossen is het een patch op RSGB 2. Maar welk concreet probleem heb je in het nnpLa01 antwoordbericht? Daar kun je gewoon een ann.identificatie in combinatie met een Nederlands bezoekadres opnemen. Zolang er geen patch is op RSGB 2 zou ik dit geen misbruik noemen van NNP-elementen noemen, maar gebruik maken van de mogelijkheden.
Henri, wij vragen het object op. Het is dan aan het gegevensmagazijn om in de nnpla01 de ann.identificatie op te nemen met een nederlands bezoekadres. Vanuit daar kunnen wij het dan overnemen. Dit is dan niet conform RSGB 2.0, maar de xsd's staan dit wel toe. Dit zal dan echter de andere partij (het gegevensmagazijn dat wij bevragen) zo geïmplementeerd moeten worden. Ik denk dat er dan vanuit KING de uitspraak dient te komen dat de standaard zo gebruikt moet worden voor deze type objecten. Dan dienen ook alle partijen zich hieraan te conformeren. Hiermee voorziet BG3.10 dan al in de oplossing zoals deze in RSGB 3 doorgevoerd wordt
Als bovenstaande doorgevoerd kan worden, kan dit ook het andere probleem oplossen. Alle niet natuurlijke personen hebben, zoals Ellen aangeeft, dan een nnpid of een ann.identificatie, Dan zouden deze wel in BG3.10 verplicht moeten worden (in ieder geval voor de nnpla vanuit het gegevensmagazijn). Alleen dan kunnen er gegevens met zaak- en documentservices worden uitgewisseld (nnpid en ann.identificatie) waarmee de betreffende objecten ook altijd in het gegevensmagazijn opgevraagd kunnen worden. In de praktijk zou het ook zo moeten zijn dat de zaakserviceconsumer en het zaaksysteem deze objecten ophaalt uit het gegevensmagazijn, de uitwisseling van de identificatie volstaat dan. Ook hier zal dan een uitspraak van KING voor nodig zijn.
Kan voor bovenstaande 2 punten een uitspraak komen of een RFC voor aangemaakt worden?
Wat betreft je eerste punt zal er een erratum moeten worden doorgevoerd op het RSGB 2 waarbij het objecttype "Ander Buitenlands Niet-Natuurlijk persoon" wordt gegeneraliseerd naar "Ander Niet-Natuurlijk Persoon" die zowel een relatie heeft naar een bezoekadres als een verblijf in het buitenland.
@Ellen: kun jij dat oppakken?
Dan kan ik daarna in het "KeuzenVerstuffing RSGB 2" document een paar zinnen aanpassen om de mapping naar de bg0310 schema's weer in overeenstemming te krijgen en klaar is Kees.
Wat betreft je tweede punt zie ik nog geen noodzaak. Als het RSGB 2 voorschrijft dat zowel NNP's als ANN's een identificatienummer moeten hebben (in bg0310: nnpid of ann.identificatie) dan moet een gegevensmagazijn daar gewoon aan voldoen als dat mogelijk is. Dus die uitspraak zit al ingebakken in het RSGB. Alleen zullen er in de praktijk gevallen zijn waardoor een gegevensmagazijn om een of andere reden (falen van NHR) van een bepaalde NNP niet kan beschikken over een identificatienummer, maar wel de andere gegevens heeft zoals de statutaire naam. Dan is het toch handig dat de koppeling niet breekt omdat het identificatienummer niet verplicht is gemaakt in het schema... Dan kun je het object nog in ieder geval proberen op te halen via de statutaire naam...
Henri, bedankt voor je reactie. Als RSGB 2 hierop aangepast kan worden, geeft dat in ieder geval duidelijkheid.
Dave, inmiddels is er een patch uitgebracht op het informatiemodel: RSGB 2.02.
Inmiddels is ook het verstuffingsdocument in overeenstemming gebracht met RSGB 2.02, zie bijlage. Deze aanpassingen hebben geen invloed op de schema's en geen verdere consequenties voor bg0310.
Aan de leden van de StUF Expertgroep: indien er binnen 14 dagen geen bezwaren worden geuit via deze forumdiscussie, dan zullen de aanpassingen in "keuzenVerStUFfing RSGB 2 versie 0112.pdf" worden meegenomen in de volgende patch van bg0310.
Bijlage
Dit onderhoudsverzoek is opgevoerd in de onderhoudsverzoeken als ONV0512.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Een punt van orde: de status van de StUF-expertgroep en de doorontwikkeling van StUF is mij niet duidelijk. Voor zover ík heb begrepen, heeft de regiegroep besloten de doorontwikkeling van StUF en daarmee de StUF-expertgroep op te schorten. Zolang dit het geval is, lijkt het me niet aan de orde om patches uit te brengen. En een stilzwijgende goedkeuring via het forum lijkt me dan ook niet aan de orde.
Ik denk, bovendien, dat dit punt nog wel enige discussie behoeft. Een van de problemen is dat ervan uitgegaan wordt dat alle andere natuurlijke personen een ann.identificatie hebben. In theorie is dit het geval, maar in de praktijk blijkt hierin een probleem te zitten: er is geen bron voor deze identificatie aangewezen, waardoor dit nummer in de praktijk niet/zelden wordt toegekend.
Om terug te komen op mijn eerste punt: als er een patch wordt uitgebracht op StUF-BG, dan lijkt me dit een overleg van de EG waardig, zodat we de patch ook binnen de EG kunnen beoordelen. Hierbij lijkt het me in eerste instantie noodzakelijk dat we duidelijkheid krijgen over de doorontwikkeling van StUF en de status van de EG.
De StUF 3.02 standaard is inderdaad "on hold" gezet door de StUF Regiegroep, maar het beheer van StUF 3.01 gaat gewoon door, dus ook het uitbrengen van nieuwe patches op StUF 3.01. Als het nodig is om errata fysiek te bespreken in een meeting van de StUF Expertgroep, dan zullen we dat zeker doen.
Voor dit erratum dacht ik dat het niet nodig zou zijn omdat bg0310 het RSGB dient te volgen. Als in het RSGB een erratum wordt doorgevoerd, dan gaat bg0310 in principe gewoon mee.
@Sid: ik kan de EG bijeenroepen om over dit erratum te discussiëren en er een hamerklap op te geven. Laat even weten of je dit echt noodzakelijk vindt!
Ik vind het nu heel lastig worden. De StUF Expertgroep is opgeschort met een reden. Aanleiding is de onduidelijkheid die er is over de toekomst van StUF. In de Regiegroep is aangegeven dat (voorlopig?!) geen sprake kan zijn voor een doorontwikkeling (en dat houdt ook in ontwikkelingen als gevolg van patches) als er geen duidelijkheid is over StUF in de nabije toekomst. Dat houdt volgens mij ook in dat het uitbrengen van patches weinig zin heeft zolang niet duidelijk is wat de rol van StUF is en wordt.
Dus niet alleen is de werkgroep opgeschort, ook de activiteiten die daarbij horen.
@Lidwien, Sid: Zoals ook in de regiegroep besproken gaat het noodzakelijk beheer op bestaande StUF-standaarden gewoon door zoals het uitbrengen van patches etc.
@Sid (post #22): Het is mij niet duidelijk welke discussie er nog gevoerd zou moeten worden. Wil je dat ik de EG-groep bijeenroep om dit erratum face-to-face te discussiëren in Utrecht? Of kan het via het forum? Zo ja, kun je dan je bezwaar concreet beschrijven en deze hier asap indienen. Jullie zijn namelijk de enige partij die bezwaar hebben tegen dit patchvoorstel...
Ik zie op het moment twee concrete zaken die mijns inziens niet (voldoende) zijn belicht en besproken:
Zie ook de discussie op het RSGB-forum: https://vng-realisatie.github.io/StUF-Standaarden/discussie/gemma/rsgb/nummer-ander-natuurlijk-persoon-en-nummer-ander-buitenlands-niet-natuurlijk#comment-5940
Ik moet zelf de vraag binnen onze organisatie uitzetten hoe met deze gegevens wordt omgegaan en of dit een probleem kan zijn voor een of meer van onze applicaties (ik zal dat gaan doen). Ik zou echter ook andere leveranciers met klem willen vragen dit te controleren. Deze patch op RSGB is mijns inziens redelijk lichtzinnig doorgevoerd (zonder enig overleg met leveranciers), maar het is nog niet te laat om de wijziging in StUF dan in ieder geval wél goed te beoordelen.
Nog niet te laat? In posts #19 en #20 (13-4-2018) heb ik de leveranciers zowel attent gemaakt op de patch van het RSGB als de daarmee samenhangende patch op bg0310. Tevens heb ik iedereen toen gevraagd om binnen 14 dagen te reageren. Een half jaar geleden dus. Hoe dan ook, graag zou ik niet later dan eind volgende week vrijdag de definitieve beoordeling willen weten.
De Makelaarsuite van PinkRoccade biedt al ondersteuning voor ann.identificatie bij binnenlandse organsiaties die niet binnen het handelsregister vallen, zowel in kennisgevingen als in vragen binnen Bg0310
@Ton: en welke sub.typering krijgt zo'n subject dan mee?
@post #27. Ik heb geen bezwaren ontvangen, dus ONV0512 gaat mee in de aankomende patch van december.