Geconstateerd is dat er doublures kunnen optreden bij de berichtuitwisseling van de SBI-code uit de NHR. Doordat deze numeriek verwerkt wordt kan in 30 gevallen niet eenduidig worden vastgesteld welke SBI-code het betreft. Zie hiervoor bijlage. Als voorbeeld kan geen onderscheid worden gemaakt tussen SBI code 14 (Vervaardiging van kleding) en 01.4 (Fokken en houden van dieren). In het RSGB 2.01 staat het formaat van de Activiteitcode als N15 gedefinieerd, dit dient als erratum aangepast te worden naar alfanumeriek zodat rekening gehouden kan worden met de voorloopnullen.
di, 21-03-2017 - 16.37u
#1
Activiteitcode / SBI
Beste Thibault,
dank voor het plaatsen van deze discussie. In RSGB3.0 is SBI-code al Alfanumeriek. Het zit dus niet goed in RSGB2.0 en wij zullen dit doorgeven aan onze StUF-collega's.
Het element 'activiteitcode' heeft in StUF-BG 3.10 het volgende formaat:
<simpleType name="ActiviteitCode">
<restriction base="string">
<pattern value="[0-9]{15}"/>
</restriction>
</simpleType>
voorloopnullen moeten nu dus ook al geen probleem vormen.
Voorloopnullen zijn ook niet het probleem, maar je kunt de punt niet meer kwijt. Hierdoor worden 01.4 en 14 beiden vertaald naar 000000000000014 (om het voorbeeld van Thibault nog maar een keer aan te halen).
Het formaat zal ook punten toe moeten gaan staan en niet alleen cijfers. Zoals Remco aangaf is dit niet correct in RSGB 2 en de definitie zoals die nu in StUF zit sluit nu nog aan bij die incorrecte definitie in RSGB 2. Dit moet dus op beide plaatsen worden aangepakt.
Dit onderhoudsverzoek is opgevoerd in de onderhoudsverzoeken als ONV0481.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Het is twijfelachtig of dit als een erratum moet worden doorgevoerd, omdat de NHR in zowel de .asc bestanden als in de HR Dataservice de SBI-code voor een activiteit levert als een number (zonder een punt erbinnen). In de praktijk is dit geen probleem, omdat de dubbelingen alleen optreden voor niveaus in de SBI-code, waar nog subniveaus onder voorkomen. In geval van een dubbeling zonder subniveau is dit subniveau zelfs apart gecreëerd om de dubbeling te voorkomen. Mijn vermoeden is daarmee dat de NHR weliswaar als number aanlevert, maar nooit een number dat twee verschillende betekenissen heeft.
Als het doorgevoerd wordt als een erratum, dan kan het pattern beperkt worden tot waarden die daadwerkelijk kunnen voorkomen als sbi-code conform de spreatsheet in #1:
(\d{1,5})|(\d{2}(\.\d(\d(\.\d)?)?)?)
Een alternatief is nog om de vijftiencijferige code te handhaven en uit te breiden met de codes met punten erbinnen. Het pattern wordt dan
(\d{15})|(\d{2}(\.\d(\d(\.\d)?)?)?)
Beide wijzigingen vergen naar alle waarschijnlijkheid aanpassing in software die nu bij gemeenten geïmplementeerd is.
Tijdens de StUF Expertgroep van 21 juni 2017 is besloten dit onderhoudsverzoek af te wijzen. De StUF Expertgroep heeft geconcludeerd dat het probleem inderdaad bij de bron van de informatie ligt.