1 Probleemstelling

1.1 Omschrijving

Nu tabel 34 Landentabel is geactualiseerd per 1 april 2026 en alle namen in overeenstemming zijn gebracht met de adviezen van de Nederlandse Taalunie, is het ook goed om dit te doen voor tabel 32 Nationaliteitentabel. Het is immers niet logisch om te spreken van Kenia in plaats van Kenya, maar de nationaliteit nog wel “Kenyaans” te noemen. Ook staan er wat onjuiste namen in de tabel. Met deze wijziging wordt de nationaliteitentabel “opgefrist”.

1.2 Herkomst

Deze wijziging komt voort uit een analyse van verschillen tussen de namen nationaliteitentabel en de aanwijzingen van de Nederlandse Taalunie en de wens om die verschillen te minimaliseren.

1.3 Raakvlakken

Er zijn geen raakvlakken met andere LO-wijzigingen.

2 Oplossing

2.1 Huidige situatie

In de huidige nationaliteitentabel komen namen soms niet overeen met de aanbevelingen van de Nederlandse Taalunie.

2.2 Oplossing

Namen van nationaliteiten worden aangepast conform de aanwijzingen van de Nederlandse Taalunie. Als zowel de spelling met oe is toegestaan, als die met een u (zoals bij Oeganda / Uganda), kiezen we voor oe. Als de naam van een nationaliteit wijzigt, wijzigt alleen de inhoud van element 05.12 Omschrijving nationaliteit. De datum ingang tabelregel en de eventuele datum beëindiging tabelregel wijzigen niet. Er is dan ook geen impact op persoonslijsten.

Hieronder volgt een overzicht van alle wijzigingen in de namen van nationaliteiten:

2.3 Openstaande punten

Er zijn na de inwerkingtreding van deze wijziging geen openstaande punten.

3 Invoering

De wijzigingen worden bij voorkeur doorgevoerd op 1 januari 2027.

4 Gevolgen

4.1 Documentatie

Deze wijziging hoeft alleen doorgevoerd te worden in tabel 32 Nationaliteitentabel.

4.2 Gemeenten

Gemeenten moeten er rekening mee houden dat de aangepaste namen van nationaliteiten kunnen worden getoond op schermen en op uittreksels uit de hun burgerzakensystemen. Verder moeten ze de bijbehorende tabelberichten kunnen verwerken.

4.3 Afnemers

Afnemers moeten er rekening mee houden dat de aangepaste namen kunnen worden getoond op schermen en in documenten. Verder moeten ze de bijbehorende tabelberichten kunnen verwerken.

4.4 IND

Geen gevolgen.

4.5 Caribische landen en Caribisch Nederland

De (ei)landen van het Caribisch deel van het Koninkrijk moeten er rekening mee houden dat de aangepaste namen van nationaliteiten kunnen worden getoond op schermen en op uittreksels uit de PIVANOBO.

4.6 RvIG-systemen

De BRP-V en de RNI moeten de aangepaste namen kunnen tonen op schermen en in documenten. Verder moeten ze de bijbehorende tabelberichten kunnen verwerken.

1 Probleemstelling

1.1 Omschrijving

Met ingang van Logisch Ontwerp BRP 2024.Q1 wordt een vaste koppeling afgedwongen tussen het te registreren actuele woon- of briefadres in de BRP en een geldig adresseerbaar object in de BAG. Dit betekent dat zowel rubriek 08.11.80 Identificatiecode verblijfplaats als rubriek 08.11.90 Identificatiecode nummeraanduiding voor een actueel adres in de BRP altijd een geldige identificatiecode van een adres van een adresseerbaar object uit de BAG moet bevatten. De Identificatiecode nummeraanduiding moet altijd verwijzen naar het hoofdadres van het adresseerbaar object in de BAG tenzij de briefadresgever een gemeente of een organisatie is. In dat geval mag de Identificatiecode nummeraanduiding ook verwijzen naar een nevenadres van het adresseerbaar object in de BAG. 

Op deze wijziging in LO BRP (W180 Vaste koppeling BAG-BRP) zijn twee aanvullingen gekomen ter nuancering:

• In LO 2024.Q2 is toegevoegd dat ook nevenadressen in de BRP mogen worden opgenomen als het om een briefadres gaat, mits de briefadresgever een gemeente of organisatie is (W190 1e Aanvulling op W180).
• In LO 2025.Q3 is een nuancering aangebracht dat adresgegevens in de BRP niet overeen hoeven te komen met die in de BAG als een verblijfsobject in de BAG de indicatie “geconstateerd” heeft of als het adresgegeven in de BAG in onderzoek staat.

In het Logisch Ontwerp is de koppeling tussen BAG en BRP zo geformuleerd dat bepaalde adreselementen, te weten 11.50 Aanduiding bij huisnummer en 12.10 Locatieomschrijving niet voorkomen in categorie 08 (maar nog wel in categorie 58). Die formulering is misleidend. Als voorschrift is het volkomen terecht: het is niet de bedoeling dat die elementen nog gebruikt worden, maar als beschrijving van hoe het systeem werkelijk werkt klopt het niet, omdat deze elementen nog wel voor kúnnen komen in de BRP. Het schrappen van dit element in de aangesloten systemen kan zorgen voor protocolfouten, omdat ontvangende partijen het element niet (meer) verwachten. Met onderhavige LO-wijziging wordt dit rechtgezet.

1.2 Herkomst

Deze wijziging komt voort uit kritische opmerkingen van binnen en buiten RvIG.

1.3 Raakvlakken

Er zijn vooralsnog geen raakvlakken met andere LO-wijzigingen.

2 Oplossing

2.1 Huidige situatie

In de beschrijving van categorie 08/58 in het LO staat nu: “Groep 12 komt niet voor.” In de beschrijving van groep 11 staat: “Voor categorie 08 geldt: […] Het element 11.50 komt niet voor.” Als voorschrift is dit correct, maar als beschrijving van de werkelijke stand van zaken niet. Een gemeente moet iemand immers inschrijven op het adres dat hij opgeeft en het kan dus voorkomen dat dit (al was het maar tijdelijk) een adres is dat (nog) niet voorkomt in de BAG, of waarvoor een locatieomschrijving of aanduiding nodig is. Ook kan het element voorkomen in categorie 08 van een persoonslijst die is opgeschort wegens overlijden voor de datum invoering van LO.2024.Q1. Deze gegevens kunnen nog verstrekt worden aan afnemers endaarom moeten zij element ook kunnen ontvangen.

2.2 Oplossing

In de beschrijvingen van categorie 08/58, groep 11, groep 12, element 11.50 en element 12.10 wordt expliciet vermeld dat deze elementen (en dus ook groep 12) niet voor mogen komen, maar nog wel voor kunnen komen. 

2.3 Openstaande punten

Er zijn na de inwerkingtreding van deze wijziging geen openstaande punten.

3 Invoering

Omdat deze wijziging geen impact heeft op systemen, maar vooral een verheldering betreft in het LO, is deze wijziging gepland voor LO 202j.Qk (1 ??? 2027).

4 Gevolgen

4.1 Documentatie

Deze wijziging in LO BRP heeft geen gevolgen voor andere logisch ontwerpen (LO BSN, LO BRPk, LO BES en LO PBK), ook niet voor de HUP en de WIR. 

4.2 Gemeenten

Geen gevolgen.

4.3 Afnemers

Geen gevolgen. Alleen wordt duidelijk dat element 11.50 en 12.10 nog wel voor kunnen komen op persoonslijsten (en dus ook in berichten), ook al mag dat niet meer.

4.4 IND

Geen gevolgen.

4.5 Caribische landen en Caribisch Nederland

Geen gevolgen.

4.6 RvIG-systemen

Geen gevolgen.

1 Probleemstelling

1.1 Omschrijving

De mailboxserver ondersteunt alleen berichten met een MessageBody van maximaal 19.000 tekens, waarbij geldt dat diakritische tekens als een afzonderlijk teken worden geteld. Er zijn op dit moment een aantal persoonslijsten waarvan de maximale lengte is of dreigt te worden overschreden. Om die persoonslijsten toch te kunnen verhuizen naar den andere gemeente of de RNI, of om deze na een mutatie te kunnen synchroniseren met de BRP-Verstrekkingsvoorziening, adviseert RvIG de gemeente of de RNI om zo’n persoonslijst in te korten. RvIG verzoekt de gemeente dan om een deel van de adreshistorie te verwijderen uit categorie 58. Op de persoonslijst bij de woongemeente gaan hierdoor adresgegevens verloren, maar in BRP-V is de gehele persoonslijst zichtbaar voor afnemers. Door deze werkwijze kan een te lang geworden persoonslijst alsnog verhuizen naar een andere gemeente of synchroniseren met BRP-V.

Ondanks dat de technische beperking van de mailboxserver in het Logisch Ontwerp wordt vermeld, is nergens aangegeven wat gemeenten moeten doen als een persoonslijst de maximale lengte van 19.000 tekens dreigt te overschrijden. Door een enkele zin toe te voegen aan het LO, wordt aan gemeenten en RNI-loketten duidelijk gemaakt hoe in zulke gevallen te handelen. 

1.2 Herkomst

Deze wijziging komt voort uit ervaringen uit het verleden met lange persoonslijsten.

1.3 Raakvlakken

Er zijn geen raakvlakken met andere LO-wijzigingen. 

2 Oplossing

2.1 Huidige situatie

In het Logisch Ontwerp BRP, in de beschrijving het sPd-protocol, de algemene definities staat bij het element Length dat de MessageBody van een bericht een maximale lengte heeft van 19.000 octets (bytes) ofwel tekens (elk teken in de Teletex tekenset wordt gecodeerd in één byte). Ook staat in het LO dat wanneer een bericht wordt aangeboden dat langer is, de mailboxserver een foutcode zal retourneren: 1241. Deze code betekent dat er een bericht is aangeboden waarvan de body meer dan 19.000 tekens bevat. Van een eindsysteem wordt verwacht dat het de lengte controleert voordat het bericht aan de berichtendienst wordt aangeboden. Er staat echter niet wat de afzender moet doen in zo’n geval om het bericht alsnog verzonden te krijgen.

RvIG adviseert in zulke gevallen om de persoonslijst in te korten, maar gemeenten zijn hier huiverig voor omdat in de BRP slechts bij hoge uitzondering gegevens van een persoonslijst mogen worden verwijderd. De BRP-V beschikt echter altijd over de volledige inhoud van de persoonslijst, ook als die door gemeenten of de RNI wordt ingekort. Hoewel gemeenten dus terughoudend zijn met verwijderen van gegevens, garandeert RvIG dat de afslag van volledige PL via BRP-V beschikbaar blijft voor wettelijke doeleinden.

Op dit moment worden 24 persoonslijsten gemonitord omdat ze te lang dreigen te worden; dit gebeurt door wekelijks een Lq01-bericht te sturen naar de huidige gemeente van inschrijving. Daarvan zijn 18 persoonslijsten al ingekort.

NB: Berichtendienstberichten die worden uitgewisseld via de webservice StuurGBAbericht of via de BRP Berichten API kennen géén maximale lengte van de berichtinhoud!

2.2 Oplossing

Aan de beschrijving van foutcode 1241 in paragraaf 6.2.5.4 van het Logisch Ontwerp BRP wordt een zin toegevoegd, en wel als volgt:

Berichtinhoud te lang (Body too long).
Er is een bericht aangeboden waarvan de body meer dan 19000 tekens bevat. Van een eindsysteem wordt verwacht dat het de lengte controleert voordat het bericht aan de berichtendienst wordt aangeboden. Om te zorgen dat een persoonslijst toch via de mailboxserver kan worden verzonden, kan RvIG een gemeente of de RNI adviseren de persoonslijst in te korten.

Deze wijziging maakt expliciet duidelijk dat gemeenten en RNI een persoonslijst mogen, zelfs moeten inkorten om ervoor te zorgen dat die alsnog via de mailboxserver kan worden uitgewisseld.

2.3 Openstaande punten

Er zijn na de inwerkingtreding van deze wijziging geen openstaande punten.

3 Invoering

Omdat deze wijziging in het Logisch Ontwerp géén impact heeft op de software van de verschillende systemen in het BRP-stelsel, is deze wijziging gepland voor LO BRP 2026.Q4 (1 oktober 2026). 

4 Gevolgen

4.1 Documentatie

Deze wijziging in LO BRP heeft geen gevolgen voor andere logisch ontwerpen (LO BSN, LO BRPk, LO BES en LO PBK) of voor de HUP en de WIR.

4.2 Gemeenten

Voor gemeenten is straks duidelijk dat het LO expliciet toestaat dat te lange persoonslijsten worden ingekort. Dit mag alleen op advies van of in overleg met RvIG. 

4.3 Afnemers

Geen gevolgen.

4.4 IND

Geen gevolgen.

4.5 Caribische landen en Caribisch Nederland

Geen gevolgen.

4.6 RvIG-systemen

Geen gevolgen.