Toelichting en voorbeelden wsdl stuurGBAbericht
Wat kunt u vinden op deze pagina?
Toelichting en voorbeelden wsdl stuurGBAbericht
MEMO Toelichting en voorbeelden wsdl stuurGBAbericht
1. Algemene beschrijving van de stuurGBABericht webserivce
De webservice verleent drie diensten: Controleren PL, Uitwisselen van LO berichten (sPoed) en test webservice (Echo),
Omdat verschillende diensten via een webservice (met 1 wsdl) worden geleverd, vertonen deze diensten op punten gelijk gedrag. Hieronder worden de belangrijkste overeenkomsten en verschillen beschreven.
Figuur 1. Algemene beschrijving
Functionele overeenkomsten zijn:
- Alle diensten in stuurGBABericht draaien om de uitwisseling van 'GBA-berichten'.
- Elke dienst voert een actie uit op een ontvangen bericht (verwerken, controleren etctera);
- Elke dienst bestaat uit een of meer acties;
- Elke actie heeft een vraag- en een antwoordbericht (request resp. response);
- De gewenste actie wordt aangegeven in het vraagbericht in de body van het bericht.
- Het resultaat van de gewenste actie wordt teruggegeven in een antwoordbericht in de body van het bericht
Overeenkomsten in de implementatie zijn:
- StuurGBABericht maakt gebruik van TLS en HTTP basic authentication;
- StuurGBABericht is een SOAP 1.1 webservice over HTTP;
- De SOAP body van een vraagbericht bevat een <stuurGBABerichtRequest als 'root';
- Een vraagbericht bevat altijd het element actie met daarin de naam van de actie;
- Een vraagbericht bevat afhankelijk van de gevraagde actie de elementen gbabericht aanleiding en berichtnummer
- Een antwoordbericht bevat in de body stuurGBABerichtResponse als root;
- Een antwoordbericht bevat altijd het verplichte element resultaatcode. De invulling daarvan verschilt per actie;
- Een antwoordbericht bevat altijd het element referentie; met daarin de activiteit ID van de webservice actie;
- Een activiteit ID is een getal van maximaal 12 posities.
- Voor alle berichten geldt UTF-8 encodering;
- Regelovergangen volgen de XML standaard (LF), zie http://www.w3.org/TR/REC- xml/#sec-line-ends;
- Het GBA-bericht dat meegestuurd wordt, is geencodeerd in Teletex maar wel ingebed in Unicode. Zie ook de uitleg bij Voorbeeld Appendix A;
- Gebruik van character entities in de berichtinhoud en uitsluiting van het gebruik van Form Feed;
- Alle parameters (elementen en element-inhoud) zijn case sensitive;
- De wsdl en xsd zijn opgenomen in Appendix B.
Gebruik van het SOAPAction HTTP request header veld
De WSDL voor stuurGBABericht specificeert geen SOAPAction HTTP header waarde. De SOAPAction header zelf is volgens de SOAP-specificatie echter wel verplicht. In een vraagbericht moet een SOAPAction zonder waarde mee worden geven. Wanneer een gevulde SOAPAction wordt aangeboden in de HTTP volgt een fout(bericht).
Verschillen tussen de diensten zijn:
- Elk van de diensten vereist een andere autorisatie.
- sPoed maakt gebruik van WS-Addressing, de overige diensten niet.
- StuurGBABericht kan in de proefomgeving getest worden. Voor sPoed zal een aparte testomgeving worden ingericht. sPoed werkt immers de database van GBA-V bij.
De dienst sPoed volgt in grote lijnen de sPd operaties: zie LO GBA IV.5.2. In het overzicht hieronder zijn sPd-operaties afgezet tegen de acties in sPoed. Als geen actie aanwezig is nvt opgenomen of wordt een korte toelichting gegeven.
Tabel 1. sPd protocol invulling in de sPoed dienst
sPd-commando | sPoed-webservice commando |
LogonRequest | Webservice authenticatie |
LogonConfirmation | Webservice authenticatie foutafhandeling |
LogoffRequest | nvt, impliciet na ontvangen webservice response-bericht |
LogoffConfirmation | nvt |
PutMessage | PutMessage |
PutMessageConfirmation | PutMessageConfirmation |
GetMessage | GetMessage |
GetMessageResult | GetMessageResult |
GetMessageConfirmation | GetMessageConfirmation |
DeleteMessages | nvt |
DeleteMessagesConfirmation | nvt |
ListMessages | ListMessages |
ListMessagesResult | ListMessagesResult |
ListMessagesConfirmation | ListMessagesConfirmation |
SummarizeConfirmation | nvt: fouten bij het retourneren van een geldig antwoord zijn altijd een 'technische fout'. |
ChangePasswordRequest | webservice change password |
ChangePasswordConfirmation | webservice change password |
NoOperationConfirmation | nvt |
Figuur 2. Structuur van een stuurGBAbericht (vraag)
Figuur 3. Structuur van een stuurGBAbericht (antwoord)
2. Voorbeelden van de stuurGBABericht webserivce
1. valideer_pl vraagbericht met Lg01 in CDATA sectie
1. Het gbabericht bevat in dit geval een CDATA sectie met daarin het complete Lg01 bericht. De encodering van dit bericht is in Teletex ingebed in Unicode. Het gbabericht is een verplicht veld.
2. De actie is valideer_pl (let op: kleine letters en _ (underscore)) en is verplicht.
3. De aanleiding is facultatief. In dit geval is 'kwaliteitscontrole' opgenomen.
4. berichtnummer is Lg01. Dit is het berichtnummer zoals vermeld in het Logisch Ontwerp GBA. Let hier ook weer op hoofd- en kleine letters. berichtnummer is verplicht.
2. valideer_pl antwoord: BCM controle geslaagd: 1 of meer fouten gevonden
1. Het antwoord op de vraag bevat een algemene resultaatcode voor de actie valideer_pl: pl_ok wanneer de validatie is doorlopen en er geen fouten/issues in de PL zijn ontdekt; pl_nok wanneer de validatie is doorlopen en er fouten/issues (1 of meer) zijn ontdekt of als de validatie niet succesvol is doorlopen. Als er fouten zijn ontdekt is er een sectie details met hierin voor elk van de issues een detail. Als de validatie niet succesvol is doorlopen is er een sectie details waarin een van de foutcodes is opgenomen (Zie LO GBA tabel C1 par C7.3.5).
2. De toelichting bevat bij pl_ok en pl_nok een vermelding van de naam en de versie van het systeem dat is gebruikt om de PL te valideren. In dit voorbeeld: BCM v4.3. Wanneer de resultaatcode een andere (fout)code bevat, dan bevat toelichting een tekstuele toelichting op deze code.
3. Wanneer de validatie is doorlopen en er fouten/issues in de PL zijn geconstateerd, dan bevat details 1 of meer detail elementen met elk een code en omschrijving. Het element details is facultatief en kan wanneer geen details gevonden zijn afwezig zijn (bij pl_ok, of bij fouten waardoor geen validatie van de PL heeft plaats kunnen vinden).
4. De code komt overeen met de code uit de BCM sheet. De code is altijd aanwezig binnen detail.
5. De omschrijving komt overeen met de code uit de BCM sheet. Het meegeven van een omschrijving is niet verplicht.
6. De referentie bevat de activiteit ID en is primair bedoeld om bij vragen aan RvIG het verzonden bericht terug te vinden.
3. valideer_pl antwoord: BCM controle geslaagd: geen fouten gevonden
4. sPoed vraag: SummarizeMessages
1. MessageID is aanwezig als leeg element. RelatesTo is niet van toepassing en niet verplicht volgens de WSDL, dus niet aanwezig (bij aanwezigheid wordt deze genegeerd).
2. Vanwege de synchrone communicatie is de binding anoniem en is dit de standaard waarde.
3. Action is gevuld met de standaardwaarde "sPoed".
4. De actie is SummarizeMessages.
5. sPoed antwoord: SummarizeResult (0 of meerdere GBA-berichten gevonden)
1. De MessageID is aanwezig (verplicht element), maar bevat geen waarde.
2. Vanwege de synchrone communicatie is de binding anoniem en is dit de standaard waarde.
3. Action is gevuld met de standaardwaarde "sPoed".
4. De resultaatcode is SummarizeResult bij het succesvol ophalen van een bericht (zoals beschreven in sPd protocol) en is case-sensitive.
5. Code is het aantal GBA-berichten die klaar staan ter verzending. omschrijving is niet aanwezig.
6. Referentie is gevuld met het GBA-V activiteit ID dat hoort bij de SummarizeMessages bevraging.
6. sPoed vraag: ListMessages
1. MessageID is aanwezig als leeg element. RelatesTo is niet van toepassing en niet verplicht volgens de WSDL, dus niet aanwezig (bij aanwezigheid wordt deze genegeerd).
2. Vanwege de synchrone communicatie is de binding anoniem en is dit de standaard waarde.
3. Action is gevuld met de standaardwaarde "sPoed".
4. De actie is ListMessages voor het bevragen welke GBA-berichten opgehaald kunnen worden (zoals beschreven in sPd protocol en is case-sensitive).
7. sPoed antwoord: ListMessagesResult (bij gevonden berichten)
1. MessageID is aanwezig als leeg element. RelatesTo is niet van toepassing en niet verplicht volgens de WSDL, dus niet aanwezig (bij aanwezigheid wordt deze genegeerd).
2. Vanwege de synchrone communicatie is de binding anoniem en is dit de standaard waarde.
3. Action is gevuld met de standaardwaarde "sPoed".
4. De resultaatcode is ListMessagesResult bij het succesvol ophalen van een bericht (zoals beschreven in sPd protocol en is case-sensitive).
5. Code is het GBA-berichtID van het op te vragen GBA-bericht. Voor elk gevonden bericht wordt een detail opgenomen met in code het GBA-berichtID van het GBA-bericht.
6. Rreferentie is gevuld met het activiteit ID dat hoort bij de ListMessages bevraging.
8. sPoed antwoord: ListMessagesConfirmation (GEEN gevonden GBA-berichten)
1. MessageID is aanwezig als leeg element. RelatesTo is niet van toepassing en niet verplicht volgens de WSDL, dus niet aanwezig (bij aanwezigheid wordt deze genegeerd).
2. Vanwege de synchrone communicatie is de binding anoniem en is dit de standaard waarde.
3. Action is gevuld met de standaardwaarde "sPoed".
4. De resultaatcode is ListMessagesConfirmation (zoals beschreven in sPd protocol en is case- sensitive) bij geen gevonden bericht(en) ter verzending.
5. Referentie is gevuld met het activiteit ID dat hoort bij de ListMessages bevraging.
9. sPoed vraag: GetMessage
1. MessageID is aanwezig als leeg element. RelatesTo is niet van toepassing en niet verplicht volgens de WSDL, dus niet aanwezig (bij aanwezigheid wordt deze genegeerd).
2. Vanwege de synchrone communicatie is de binding anoniem en is dit de standaard- waarde.
3. Action is gevuld met de standaardwaarde sPoed.
4. De actie is GetMessage (zoals beschreven in sPd protocol en is case-sensitive) voor het ophalen van een bericht.
5. Het GBA-berichtID wordt in berichtnummer geplaatst.
10. sPoed antwoord: GetMessageResult met daarin een GBA-bericht als dat bericht geen reactie is op een eerder bericht (eerste bericht in een GBA-berichtencyclus)
1. MessageID is het GBA-berichtID, toegekend door het GBA-V systeem. RelatesTo is niet aanwezig omdat dit het eerste bericht is in de berichtencyclus.
2. Vanwege de synchrone communicatie is de binding anoniem en is dit de standaard- waarde.
3. Action is gevuld met de standaardwaarde sPoed.
4. De resultaatcode is GetMessageResult (zoals beschreven in sPd protocol en is case- sensitive) bij het succesvol ophalen van een bericht.
5. gbabericht bevat het complete Lq01 bericht.
6. berichtnummer is in dit voorbeeld Lq01. Het is een berichtnummer zoals vermeld in het Logisch Ontwerp. Het berichtnummer is gelijk aan het berichtnummer genoemd in het werkelijke bericht in gbabericht.
7. referentie is gevuld met het activiteit ID dat hoort bij de GetMessage bevraging.
11. sPoed antwoord: GetMessageResult met daarin een GBA-bericht als dat bericht een reactie is op een eerder bericht (vervolgbericht in een GBA-berichtencyclus)
1. MessageID is het GBA-berichtID, toegekend door het GBA-V systeem.
2. Vanwege de synchrone communicatie is de binding anoniem en is dit de standaard- waarde.
3. RelatesTo is gevuld met het MessageID van het bericht waar, in dit voorbeeld, de Pf01 in dit bericht het antwoord op is. De MessageID komt uit MessageID van bijvoorbeeld een PutMessage met een Lg01. De MessageID van dat bericht was in dit voorbeeld 23456.
4. Action is gevuld met de standaardwaarde sPoed.
5. De resultaatcode is GetMessageResult (zoals beschreven in sPd protocol en is case- sensitive) bij het
succesvol ophalen van een bericht.
6. gbabericht bevat het complete Pf01 bericht.
7. berichtnummer is Pf01. Dit is het berichtnummer zoals vermeld in het Logisch Ontwerp GBA-V. Let hier ook weer op hoofd- en kleine letters.
8. referentie is gevuld met het activiteit ID dat hoort bij de GetMessage bevraging.
12. sPoed antwoord: GetMessageConfirmation (GBA-bericht niet gevonden)
1. MessageID en RelatesTo zijn niet van toepassing: de GetMessageConfirmation bevat geen bericht.
2. Vanwege de synchrone communicatie is de binding anoniem en is dit de standaard- waarde.
3. Action is gevuld met de standaardwaarde sPoed.
4. De resultaatcode is GetMessageConfirmation (zoals beschreven in sPd protocol en is case- sensitive) bij niet kunnen ophalen van een bericht.
5. referentie is gevuld met het activiteit ID dat hoort bij de GetMessage bevraging.
13. sPoed vraag: PutMessage met La01 in CDATA sectie
1. MessageID is gevuld met het ID van het, in dit voorbeeld La01, bericht.
2. Vanwege de synchrone communicatie is de binding anoniem en is dit de standaard- waarde.
3. RelatesTo is in dit voorbeeld gevuld met het GBA-berichtID. Deze komt uit MessageID van het webservice bericht waarin het GBA vraagbericht (in dit geval Lq01) was opgenomen. In dit voorbeeld had dit sPoed antwoord: GetMessageResult met daarin het GBA-bericht (eerste bericht in de cyclus)
kunnen zijn.
4. Action is gevuld met de standaardwaarde sPoed.
5. gbabericht bevat in dit geval een CDATA sectie met daarin het complete La01 bericht. De encodering van het bericht in dit voorbeeld is Teletex ingebed in Unicode.
6. De actie is PutMessage (zoals beschreven in sPd protocol en is case-sensitive) voor het versturen van
een bericht.
7. berichtnummer is La01. Dit is het berichtnummer zoals vermeld in het Logisch Ontwerp GBA-V. Let hier ook weer op hoofd- en kleine letters. berichtnummer is verplicht bij de actie PutMessage en is overeenkomstig met het berichtnummer in het GBA-bericht.
14. sPoed antwoord: PutMessageConfirmation (Bevestiging bericht is ontvangen).
1. MessageID en RelatesTo zijn niet van toepassing: de PutMessageConfirmation bevat geen bericht.
2. Vanwege de synchrone communicatie is de binding anoniem en is dit de standaard- waarde.
3. Action is gevuld met de standaardwaarde sPoed.
4. De resultaatcode is PutMessageConfirmation (zoals beschreven in sPd protocol en is case- sensitive) bij het succesvol plaatsen van een bericht.
5. referentie is gevuld met het activiteit ID dat hoort bij de PutMessage bevraging.
15. actie ECHO: stuurGBABerichtRequest
1. De vaste tekst GBA-BERICHT.
2. De actie ECHO (let op: hoofdletters).
3. De aanleiding is een vrij in te vullen tekst in stuurGBABerichtRequest. De aanleiding wordt zonder verandering teruggestuurd in het antwoordbericht.
4. Het berichtnummer is een vrij in te vullen berichtnummer. Ook dit berichtnummer wordt onveranderd in het antwoord teruggestuurd.
16. actie ECHO: Antwoord op bovenstaand bericht
1. De resultaatcode van een valide ECHO stuurGBABerichtRequest is altijd OK (voorwaarde: er treedt geen technische fout op).
2. De toelichting bij de resultaatcode is Echo Response.
3. In details worden de aanleiding, actie, het berichtnummer en het in de vraag meegestuurde bericht zoals gegeven in de vraag mee terug teruggestuurd.
4. Referentie wordt standaard gevuld met de Activiteit-ID (ter referentie RvIG).
17. Technische fout
De request kan om verschillende redenen worden afgekeurd. In bovenstaand voorbeeld gaat het om een technische fout. Andere mogelijkheden zijn:
- Ongeldige combinatie gebruikersnaam / wachtwoord
- Server is niet geactiveerd voor dit account
- Wachtwoord verlopen
- Geen actuele autorisatietabelregel
- Ongeldige waarde voor parameter
Zie voor een opsomming van de foutcodes LO GBA tabel C1 par C7.3.5).
18. SOAP fout opbouw
Appendix A: opbouw en tekst-encodering van <gbabericht>
Er zijn twee varianten van de inhoud van <gbabericht>: een met het bericht in een CDATA sectie en een met het GBA-bericht opgenomen als tekst in de XML. Van beide varianten volgt hieronder een voorbeeld.
element gbabericht met Lg01 in CDATA sectie
① Het gbabericht bevat in dit geval een CDATA sectie met daarin het complete Lg01 bericht. De encodering van dit bericht is in Teletex ingebed in Unicode. Het bericht is een verplicht veld.
Elk bericht dat wordt meegegeven in de XML is in Teletex gerepresenteerd door UTF-8 unicode. Om van het Teletex bericht te komen tot het juiste bericht in de XML worden de volgende stappen doorlopen:
1.Teletex tekens worden geëncodeerd met Teletex bytes.
2.Elke Teletex byte wordt gepresenteerd met (c.q. vervangen door) een Unicode teken op basis van de numerieke waarde.
3.De resulterende Unicode tekens worden geëncodeerd en getransporteerd als UTF-8. Stap 3 is standaard voor webservices. Van belang zijn stap 1 en 2.
Je ziet dit terug in het eerder gegeven XML bericht hierboven.
Het is mogelijk de Lg01 als tekst met gewone markup mee te sturen in plaats van in een CDATA sectie. Let er hierbij op dat de volgende karakters vervangen worden door XML escape karakters (character/entities):
XML character entities
Strikt genomen hoeven alleen & en < vervangen te worden, maar het is goed gebruik al deze karakters te vervangen. Een Carriage Return komt in GBA-berichten zelden voor en is een speciaal geval. Een CR moet altijd worden opgenomen als en kan niet worden gebruikt in een CDATA sectie. De meest veelzijdige vorm van het versturen van een bericht, waarbij ook rekening wordt gehouden met Carriage Returns, is hiermee het meesturen van de PL als elementinhoud (zonder CDATA) en het escapen van alle hierboven genoemde karakters. Wanneer geen carriage return in het bericht staat is de eenvoudigste vorm die met de CDATA sectie (zonder character references).
Het Teletex karakter voor Form Feed (FF) kan niet worden gebruikt in deze webservice. Ook de character reference #12; is niet toegestaan. Dit Teletex karakter wordt in de praktijk niet gebruikt en vormt dus geen praktische belemmering.
Het element gbabericht met de Lg01 als tekst
In dit voorbeeld is de ampersand in de straatnaam V&D weg vervangen door &.
Appendix B: WSDL en XSD
stuurGBABericht-v1.0.wsdl
Het element <wsaw:UsingAddressing wsdl:required="true" /> betekent dat WS-Addressing verplicht is. Het systeem bepaalt echter aan de hand van welke dienst gebruikt wordt of de WS-Addressing van toepassing is. Voor de Controleren PL en de ECHO
diensten is WS-Addressing NIET verplicht.
De inhoud van de berichten voldoet aan het volgende schema:
XSD voor stuurGBABerichtRequest en stuurGBABerichtResponse
Werkinstructie voorraadbeheer meldplicht
Wat kunt u vinden op deze pagina?
Werkinstructie voorraadbeheer meldplicht
Werkinstructie voorraadbeheer reisdocumenten en meldplicht bij vermissing
Voor leidinggevende medewerkers Burgerzaken
1. Telling van vooraad
Om fouten en fraude te voorkomen controleer je regelmatig op wisselende kantoordagen en tijdstippen de voorraad van paspoorten en identiteitskaarten in de kluis.
Doe de telling van de voorraad het liefst door meer dan één persoon.
Vergelijk de telling van aanwezige paspoorten en identiteitskaarten in de kluis met een actueel
overzicht aanwezige reisdocumenten uit het RAAS (Reisdocumenten Aanvraag- en Archiefstation).
Ga veilig om met een pincode, toegangspas of sleutel om de kluis te openen en registreer wie toegang heeft. Leg dit vast in een kluisbeleid: wie heeft wanneer toegang tot de kluis.
- Geef een geautisoriseerde medewerker een persoonlijke pincode of toegangspas.
- Bewaar een sleutel in een sleutelkluis.
- Neem geen sleutel of toegangspas mee naar huis.
2. Ontbreekt er een document in de kluis?
Doe altijd melding van vermissing bij de Rijksdienst voor Identiteitsgegevens en verzamel bewijsstukken.*
Vul het C7-formulier volledig in.
Dit formulier is te downloaden op rvig.nl.
Zijn er sporen van inbraak?
Doe aangifte bij de politie en vraag om een proces-verbaal.
Zijn er geen sporen van inbraak?
Maak een eigen een rapport op.
Mail het C7-formulier met een proces-verbaal of rapport naar de Rijksdienst voor Identiteitsgegevens (RvIG), via info@rvig.nl.
Het gemelde documentnummer wordt nationaal en internationaal gesignaleerd. Dit beperkt de risico’s van misbruik met het document.
Breng de houder van het vermiste document op de hoogte.
* Dit is een wettelijke verplichting (PUN, artikel 85 en 86 en Paspoortwet, artikel 4a lid 4)
WALAA Korte handleiding
WALAA Korte handleiding
De Webapplicatie LAA (WALAA) is voor gemeenten de digitale omgeving om adresonderzoeken voor de Landelijke Aanpak Adreskwaliteit (LAA) te kunnen doen. Deze korte handleiding biedt ondersteuning aan medewerkers van gemeenten die zich bezighouden met het uitvoeren van adresonderzoek. In de handleiding wordt gebruik gemaakt van testgegevens. Heb je alsnog vragen over de WALAA? Neem dan contact op met je LAA-ambassadeur of LAA-accountmanager van RvIG.
Procedure verwerken signalen
Wanneer gemeenten een signaal in de WALAA ontvangen, moeten zij zo snel mogelijk terugmelden hoe zij dit signaal hebben opgevolgd:
- Binnen vier weken dien je aan te geven of het signaal aanleiding was voor een aanpassing in de BRP of dat de Persoonslijst (PL) op het adres ‘in onderzoek’ is geplaatst. Ook als er geen opvolging wordt gegeven aan het signaal moet dit worden teruggemeld.
- Binnen zes maanden dient het onderzoek afgerond te zijn. De informatie meld je uiterlijk binnen zes maanden terug.
Signalen worden na zes maanden verwijderd uit de WALAA, maar blijven zichtbaar in de ‘Monitor’.
Inloggen
- eHerkenning niveau 3 is nodig voor iedere medewerker die met de WALAA werkt.
- Tijdens het huisbezoek kun je de WALAA gebruiken op een tablet.
- Vanuit beveiligings oogpunt word je na 15 minuten inactiviteit automatisch uitgelogd.
- Maak gebruik van de navigatie-mogelijkheden in de WALAA zelf. Het gebruik van de pijltjes van de webbrowser resulteert in verlies van gegevens.
Casusoverzicht
Chronologisch op volgorde zetten van geleverde signalen.
Hier staan alle filteropties om tot een overzicht van het gewenste signaal te komen.
Menu:
-
Casusoverzicht
Voor actuele werkvoorraad
-
Monitor
Een overzicht van afgeronde signalen
-
Statusoverzicht
Geeft de status van een signaal aan
-
Instructies
Toelichting op het signaal
-
Download basisvragenlijst
Basisvragen in PDF
-
Uitloggen
Geeft de status van het signaal aan.
LET OP: LAA signalen worden maandelijks geleverd. De informatie is op dat moment twee weken oud. Check altijd eerst de actuele inschrijving op het adres in de BRP.
Monitor
Hiermee is het mogelijk een rapportage in Excel te maken.
Stel wel eerst de gewenste filters in voordat je een rapportage maakt.
Vooronderzoek
LET OP: De WALAA is niet gekoppeld aan de BRP. Eventuele mutaties moeten apart in de BRP worden doorgevoerd.
Persoon woont er volgens BRP nog.
Persoon staat geregistreerd met een briefadres.
Persoon woont er volgens de BRP niet meer.
Dit is een verplichte vraag of verplicht veld.
Toevoegen van een nieuw persoon op het adres.
Als een afgerond vooronderzoek toch moet worden aangepast, kan dit via een verzoek aan RvIG. Gebruik bij dit verzoek altijd de adrescode en niet het daadwerkelijke adres.
Huisbezoek
Persoon staat geregistreerd met een briefadres.
Persoon woont op het adres.
Persoon woont niet meer op het adres.
LET OP: De onderzoeken die voor vergoeding in aanmerking komen hebben de status:
- Afgerond (er heeft daadwerkelijk een huisbezoek plaatsgevonden)
- Driemaal bezocht (driemaal het adres bezocht maar er was niemand thuis)
- Weigering (er was iemand aanwezig op het adres, maar weigerde mee te werken aan het huisbezoek.)
Het is dus belangrijk om de uitkomst van je onderzoek op de juiste wijze in de WALAA te registreren.
UC05 Registreer nummertoekenning
Wat kunt u vinden op deze pagina?
UC05 Registreer nummertoekenning
Inleiding
De use case “Registreer nummertoekenning” beschrijft de stappen voor het registreren van een toekenning van een BSN. Het nummer is door de toekennende instantie toegekend aan een gerechtigde en is daarna niet meer beschikbaar als toe te kennen nummer.
In onderstaand model is de use case “Registreer nummertoekenning” weergegeven.
1. Hoofdscenario
1.1. Initiatie
1.1.1. Ontvang bericht “toekenning nummer”
De use case start met de ontvangst van het bericht “toekenning nummer”. In dit bericht staan de volgende gegevens:
Vraagbericht |
Identificatie afzender |
Berichtnummer afzender |
Instantie |
BSN |
Datum-tijd van toekennen |
1.1.2. Leg bericht “toekenning nummer” vast
Het BV BSN-berichtnummer wordt toegekend en het vraagbericht wordt vastgelegd in het berichtenlogboek. Zie use case “Leg bericht vast”.
1.1.3. Autoriseer verzoek
De autorisatie wordt aangevraagd en verleend. Zie “Autoriseer verzoek” (Zie alternatieve scenario´s 1).
1.2. Verwerking
1.2.1. Controleer bericht
Hier wordt gecontroleerd of de velden uit het vraagbericht goed gevuld zijn. De inhoud van het bericht moet voldoen aan de volgende eisen:
- De afzender moet gevuld zijn (zie ook Alternatieve scenario´s 2)
- Het berichtnummer van de afzender moet gevuld zijn (zie ook Alternatieve scenario´s 3)
- De instantie moet gevuld zijn (zie ook Alternatieve scenario´s 4)
- Het BSN moet gevuld zijn (zie ook Alternatieve scenario´s 5)
- Het BSN moet voldoen aan de 11-proef (zie ook Alternatieve scenario´s 6)
Daarnaast is het wenselijk dat de datum-tijd van toekennen juist is. (zie ook Alternatieve scenario’s 7)
1.2.2. Controleer validiteit toekenning
Het systeem controleert in het nummerregister of de toekenning valide is. De toekenning is valide als:
- het nummer in het nummerregister is geregistreerd en de status “gedistribueerd” heeft en
- de instantie die toegekend heeft (uit het vraagbericht) overeenkomt met het veld “instantie” uit het nummerregister (i.e., de toekennende instantie waaraan de batch met dit nummer is gedistribueerd).
De volgende alternatieve situaties worden onderkend:
- Het nummer is niet gevonden (zie Alternatieve scenario’s 8)
- De instantie van toekenning is niet valide (zie Alternatieve scenario’s 9)
- Het nummer heeft de status “aangemaakt (zie Alternatieve scenario’s 10)
- Het nummer heeft de status “in verkeer” (zie Alternatieve scenario’s 11)
- Het nummer heeft de status “uit verkeer” (zie Alternatieve scenario’s 12)
1.2.3. Registreer nummertoekenning
Voordat de wijziging in het nummerregister wordt doorgevoerd, wordt de oude situatie in de nummerhistorie vastgelegd.
Het systeem voert de mutatie in het nummerregister uit (Zie ook Alternatieve scenario´s 13):
- De status van het nummer wordt op “in verkeer” gezet;
- De datum/tijd van toekennen, zoals door de instantie in het vraagbericht meegegeven, wordt geregistreerd; (indien de tijd niet is aangeleverd wordt 00:00:00 vastgelegd)
- De registratie waarin de gegevens van dit nummer zijn opgenomen wordt geregistreerd. Deze wordt bepaald aan de hand van de identificatie van de afzender.
- Datum/tijd van wijziging.
1.3. Afronding
1.3.1. Stel antwoordbericht “toekenning nummer” samen
Het systeem stelt een antwoordbericht samen. In dit bericht staan de volgende gegevens:
Antwoordbericht |
Berichtnummer afzender |
BV BSN Berichtnummer |
BSN |
Berichtresultaatcode (5000) |
Omschrijving berichtresultaat (“Nummertoekenning geregistreerd”) |
1.3.2. Leg antwoordbericht “toekenning nummer” vast
Het antwoordbericht wordt vastgelegd in het berichtenlogboek. Zie use case “Leg bericht vast”.
1.3.3. Bied antwoordbericht “toekenning nummer” aan
Het antwoordbericht wordt aangeboden aan de actor.
1.3.4. Vul het auditlog
Het systeem registreert in het auditlog het resultaat van alle bovenstaande stappen. De volgende gegevens worden hierbij vastgelegd (Zie Alternatieve scenario´s 14):
Gegevens auditlog |
Toelichting |
Huidige datum en tijd | Systeemdatum-tijd |
Identificatie afzender | DN uit het certificaat |
BV BSN-berichtnummer | Het toegekende BV BSN berichtnummer |
Berichtnummer afzender | Overnemen uit vraagbericht |
Indicatie eindgebruiker/instantie | Overnemen uit vraagbericht |
Uitgevoerde actie | de stap die uitgevoerd is |
Resultaat van de uitgevoerde actie | Resultaat van de uitgevoerde stap |
Resultaatcode | Berichtresultaatcode uit het antwoordbericht |
2. Alternatieve Scenario’s
2.1. Alternatief 1: Autorisatie mislukt
Indien de autorisatie wordt geweigerd, wordt het volgende antwoordbericht verstuurd naar de afzender “Afzender niet geautoriseerd” (berichtresultaatcode 4). Daarnaast wordt een melding in het systeemfoutenlogboek opgenomen. Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.
2.2. Alternatief 2: Identificatie afzender in vraagbericht is niet gevuld
Indien het veld Identificatie afzender van het vraagbericht niet gevuld is, wordt de volgende foutmelding naar de afzender verstuurd ”De afzender van het bericht moet gevuld zijn” (berichtresultaatcode 8). Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.
2.3. Alternatief 3: Berichtnummer afzender in vraagbericht is niet gevuld
Indien het veld berichtnummer afzender van het vraagbericht niet gevuld is, wordt de volgende foutmelding naar de afzender verstuurd ”Het berichtnummer van de afzender moet gevuld zijn” (berichtresultaatcode 9). Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.
2.4. Alternatief 4: Instantie in vraagbericht is niet gevuld
Indien het veld instantie van het vraagbericht niet gevuld is, wordt de volgende foutmelding naar de afzender verstuurd ”De instantie moet gevuld zijn” (berichtresultaatcode 5004). Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.
2.5. Alternatief 5: BSN is niet gevuld
Indien het veld BSN van het vraagbericht niet gevuld is, wordt de volgende foutmelding naar de afzender verstuurd “Het BSN moet gevuld zijn” (berichtresultaatcode 5002). Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.
2.6. Alternatief 6: BSN voldoet niet aan de 11-proef
Indien het opgegeven nummer niet aan de 11-proef voldoet, wordt de volgende melding naar de afzender verstuurd: “Nummer voldoet niet aan de 11-proef” (berichtresultaatcode 5007).
Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.
2.7. Alternatief 7: Datum-tijd van toekenning is niet juist
Indien het veld datum-tijd van toekenning van het vraagbericht niet gevuld is of een onjuiste datum (bijvoorbeeld onjuist datumformaat of een datum in de toekomst) bevat, wordt een melding aan het nummerfoutenlogboek toegevoegd
In het nummerfoutenlogboek worden de volgende gegevens opgenomen:
Gegevens nummerfoutenlogboek |
Toelichting |
Foutnummer | Uniek volgnummer |
BV BSN-Berichtnummer | Nummer van het bericht waarbij de fout optrad |
BSN | BSN waar de fout betrekking op heeft |
Indicatie van de fout | “Datum-tijd van toekenning is niet juist” |
Datum/tijd | Datum tijd van constatering van de fout |
Status van de verwerking van de fout | Open |
Indien het nummerfoutenlogboek niet gevuld kan worden, wordt een melding in het systeemfoutenlogboek opgenomen. Dit heeft verder geen invloed op de verwerking van het bericht.
Hierna wordt verdergegaan met de verwerking. Als het nummerregister wordt gemuteerd ten behoeve van de toekenning, wordt de datum niet gevuld.
2.8. Alternatief 8: Het nummer is niet gevonden
Het nummer in het aangeleverde bericht is niet aanwezig in BV BSN en kan dus niet toegekend worden. De volgende melding wordt verstuurd naar de afzender “Het opgegeven nummer bestaat niet” (berichtresultaatcode 5003).
Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.
2.9. Alternatief 9: Instantie van toekenning niet valide
Indien de instantie van toekenning ongelijk is aan de instantie waaraan het nummer is gedistribueerd, wordt volgende melding wordt verstuurd naar de afzender “De instantie van toekennen moet gelijk zijn aan de instantie waaraan het nummer is gedistribueerd” (berichtresultaatcode 5005).
Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.
2.10. Alternatief 10: Nummer heeft status aangemaakt
Indien het nummer de status ‘aangemaakt’ heeft, wordt de melding “Het opgegeven nummer kan niet in verkeer worden genomen” (berichtresultaatcode 5006) in het antwoordbericht opgenomen.
Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.
2.11. Alternatief 11: Nummer heeft status in verkeer
Indien het nummer de status ‘in verkeer’ heeft, wordt de melding “Het opgegeven nummer is reeds in verkeer” (berichtresultaatcode 5001) in het antwoordbericht opgenomen.
Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.
2.12. Alternatief 12: Nummer heeft status uit verkeer
Indien het nummer de status ‘uit verkeer’ heeft, wordt de melding “Het opgegeven nummer kan niet in verkeer worden genomen” (berichtresultaatcode 5006) in het antwoordbericht opgenomen.
Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.
2.13. Alternatief 13: Fout bij registreren van nummertoekenning
Indien er een fout optreedt bij het registreren van de nummertoekenning, wordt de melding ”Er is een fout opgetreden” (berichtresultaatcode 2) verstuurd naar de afzender. Het nummerregister wordt teruggebracht in de toestand, zoals die was voor de start van de verwerking van het bericht Daarnaast wordt een melding aan het systeemfoutenlogboek toegevoegd.
Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.
2.14. Alternatief 14: Fout bij vullen auditlog
Indien het auditlog niet gevuld kan worden, wordt een melding in het systeemfoutenlogboek opgenomen. Aan de afzender van het bericht wordt de melding "Er is een fout opgetreden" (berichtresultaatcode 2) verstuurd. De verwerking van het bericht zal stoppen.
Indien het tussenstappen betreft wordt direct verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.
Indien het de laatste stap betreft, zal wel de beheerorganisatie, maar niet de afzender hierover geïnformeerd worden.
3. Subprocessen
Niet van toepassing.
4. Belangrijke scenario’s
Niet van toepassing.
5. Precondities
- De actor die het bericht verstuurt, is geauthenticeerd (zie use case: authenticeren).
6. Postcondities
- Alle ondernomen acties zijn vastgelegd in het auditlog;
- Er is een antwoordbericht verstuurd naar de actor.
7. Extensies
Niet van toepassing.
8. Speciale eisen
Niet van toepassing.
9. Aanvullende Informatie
9.1. Activiteitendiagram
Download PDF
UC03 Haal op set identificerende gegevens
Wat kunt u vinden op deze pagina?
UC03 Haal op set identificerende gegevens
Inleiding
De use case “Haal op set identificerende gegevens” beschrijft de stappen voor het ophalen van een unieke set identificerende gegevens uit de registratie GBA of RNI, behorende bij een BSN.
In onderstaand model is de use case “Haal op set identificerende gegevens” weergegeven.
1. Hoofdscenario
1.1. Initiatie
1.1.1. Ontvang bericht “Haal op set identificerende gegevens”
De use case start met de ontvangst van het bericht “Haal op set identificerende gegevens”. In dit bericht staan de volgende gegevens:
Vraagbericht |
Algemeen deel |
Identificatie afzender |
Berichtnummer afzender |
Indicatie eindgebruiker |
1 of meerdere vragen |
Vraagnummer |
BSN |
1.1.2. Leg bericht “Haal op set identificerende gegevens” vast
Het BV BSN-berichtnummer wordt toegekend en het vraagbericht wordt vastgelegd in het berichtenlogboek. Zie use case “Leg bericht vast”.
1.1.3. Autoriseer verzoek
De autorisatie wordt aangevraagd en verleend. Zie use case “Autoriseer verzoek” (zie ook Alternatieve scenario´s 1).
1.2. Verwerking
1.2.1. Controleer bericht
Het bericht moet voldoen aan de volgende eisen:
- Het vraagnummer moet bij 1 beginnen (zie Alternatieve scenario’s 2)
- De vraagnummers moeten oplopend zijn (zie Alternatieve scenario’s 3)
- Het bericht moet minimaal één vraag bevatten (zie Alternatieve scenario’s 4)
- Het bericht mag niet meer vragen bevatten dan het toegestane maximum, waarbij dit maximum een instelbare waarde heeft en initieel wordt ingesteld op 1 (zie Alternatieve scenario’s 5)
- De afzender moet gevuld zijn (zie Alternatieve scenario’s 6)
- Het berichtnummer van de afzender moet gevuld zijn (zie Alternatieve scenario’s 7)
- De indicatie eindgebruiker moet gevuld zijn (zie Alternatieve scenario’s 8)
- De vraagnummers moeten gevuld zijn (zie Alternatieve scenario’s 9)
De volgende stappen (zie activiteitendiagram) worden voor iedere vraag in het bericht herhaald.
1.2.2. Controleer nummer
Het opgegeven BSN wordt gecontroleerd en moet voldoen aan de volgende eisen:
- Het BSN moet gevuld zijn (zie Alternatieve scenario’s 10)
- Het BSN moet voldoen aan de 11-proef (zie Alternatieve scenario’s 11)
- Het BSN moet in verkeer zijn bij GBA of RNI (zie Alternatieve scenario’s 11)
1.2.3. Bepaal registratie
Aan de hand van het opgegeven BSN wordt in het nummerregister bepaald bij welke registratie (GBA of RNI) de identificerende gegevens moeten worden opgehaald.
1.2.4. Haal op set identificerende gegevens
Het systeem raadpleegt de registratie die in de vorige stap is bepaald. (zie ook Alternatieve scenario´s 12).
De volgende gegevens worden uit de registratie opgehaald:
Gegevens uit registratie |
BSN |
Voornamen |
Adellijke titel/predikaat |
Voorvoegsels geslachtsnaam |
Geslachtsnaam |
Geboortedatum |
Geboorteplaats |
Geboorteland |
Geslachtsaanduiding |
Aanduiding gegevens in onderzoek persoon |
Datum ingang onderzoek persoon |
Datum einde onderzoek persoon |
Datum overlijden |
Aanduiding gegevens in onderzoek overlijden |
Datum ingang onderzoek overlijden |
Datum einde onderzoek adres |
Omschrijving reden opschorting |
Indicatie geheim |
Gemeente van inschrijving |
Functie adres |
Gemeentedeel |
Straatnaam |
Huisnummer |
Huisletter |
Huisnummertoevoeging |
Aanduiding bij huisnummer |
Postcode |
Woonplaatsnaam |
Locatiebeschrijving |
LandAdresBuitenland |
DatumAanvangAdresBuitenland |
Regel1AdresBuitenland |
Regel2AdresBuitenland |
Regel3AdresBuitenland |
Land vanwaar ingeschreven |
Aanduiding gegevens in onderzoek adres |
Datum ingang onderzoek adres |
Datum einde onderzoek adres |
1.2.5. Controleer zoekresultaat
Hierna worden de volgende situaties onderscheiden:
- Als er één resultaat gevonden is, worden de gevonden identificerende gegevens teruggemeld.
- Als er meerdere resultaten gevonden zijn, wordt dit gemeld aan de afzender en wordt er een fout naar het nummerfoutenlogboek gestuurd (zie ook Alternatieve scenario’s 13)
- Als er geen resultaat gevonden is, wordt dit teruggemeld aan de afzender (Zie ook Alternatieve scenario´s 13).
1.3. Afronding
1.3.1. Stel antwoordbericht “Haal op set identificerende gegevens” samen
In onderstaande tabel wordt beschreven welke gegevens in het antwoordbericht zijn opgenomen.
Antwoordbericht |
Algemeen deel |
Berichtnummer afzender |
BV BSN Berichtnummer |
Berichtresultaatcode (3000) |
Omschrijving berichtresultaat (“Verwerking bericht succesvol”) |
1 of meerdere antwoorden |
Vraagnummer |
Resultaatcode (3002) |
Omschrijving resultaat (“Resultaat gevonden”) |
BSN |
Voornamen |
Adellijke titel/predikaat |
Voorvoegsels geslachtsnaam |
Geslachtsnaam |
Geboortedatum |
Geboorteplaats |
Geboorteland |
Geslachtsaanduiding |
Aanduiding gegevens in onderzoek persoon |
Datum ingang onderzoek persoon |
Datum overlijden |
Aanduiding gegevens in onderzoek overlijden |
Datum ingang onderzoek overlijden |
Omschrijving reden opschorting |
Indicatie geheim |
Gemeente van inschrijving1 |
FunctieAdres1 |
Gemeentedeel1 |
Straatnaam1 |
Huisnummer1 |
Huisletter1 |
Huisnummertoevoeging1 |
Aanduiding bij huisnummer1 |
Postcode1 |
Woonplaatsnaam1 |
Locatiebeschrijving1 |
LandAdresBuitenland2 |
DatumAanvangAdresBuitenland2 |
Regel1AdresBuitenland2 |
Regel2AdresBuitenland2 |
Regel3AdresBuitenland2 |
Land vanwaar ingeschreven1 |
Aanduiding gegevens in onderzoek adres1 |
Antwoordbericht
Datum ingang onderzoek adres1
In de volgende gevallen zal geen volledige set van identificerende gegevens in het antwoordbericht worden opgenomen:
- Als in de registratie de omschrijving reden opschorting gelijk is aan “E” (emigratie) of “M” (ministerieel besluit) of gemeente van inschrijving = “Registratie Niet Ingezetenen (RNI) “, worden de binnenlandse verblijfplaatsgegevens (aangeduid met “1”) niet in het antwoordbericht opgenomen.
- Als in de registratie de gemeente van inschrijving is ongelijk aan “Registratie Niet Ingezetenen (RNI) “, worden de buitenlandse verblijfplaatsgegevens (aangeduid met “2”) niet in het antwoordbericht opgenomen.
- Als in de registratie de indicatie geheim ongelijk is aan “0”, worden de verblijfplaatsgegevens (aangeduid met “1” en “2” ) niet in het antwoordbericht opgenomen.
Als in de registratie de datum ingang onderzoek is gevuld en de datum einde onderzoek niet is gevuld, dan betekent dit dat de betreffende gegevens in onderzoek zijn. De aanduiding gegevens in onderzoek is dan gevuld. In alle andere gevallen betekent het dat de betreffende gegevens niet in onderzoek zijn. De datum ingang onderzoek en de aanduiding gegevens in onderzoek worden dan niet in het antwoordbericht opgenomen.
Het veld indicatie geheim wordt in het antwoordbericht als volgt opgenomen:
- Indien indicatie geheim = 0, dan wordt “Nee” opgenomen in het antwoordbericht.
- Indien indicatie geheim <> 0, dan wordt “Ja” opgenomen in het antwoordbericht.
1.3.2. Leg antwoordbericht “Haal op set identificerende gegevens” vast
Het antwoordbericht wordt vastgelegd in het berichtenlogboek. Zie use case “Leg bericht vast”.
1.3.3. Bied antwoordbericht “Haal op set identificerende gegevens” aan
Het bericht wordt aangeboden aan de afzender.
1.3.4. Vul het auditlog
Het systeem registreert in het auditlog het resultaat van alle bovenstaande stappen. De volgende gegevens worden hierbij vastgelegd (Zie ook Alternatieve scenario´s 14):
Gegevens auditlog |
Toelichting |
Huidige datum en tijd | Systeemdatum-tijd |
Identificatie afzender | DN uit het certificaat |
BV BSN-berichtnummer | Het toegekende BV BSN berichtnummer |
Berichtnummer afzender | Overnemen uit vraagbericht |
Indicatie eindgebruiker/instantie | Overnemen uit vraagbericht |
Uitgevoerde actie | de stap die uitgevoerd is |
Gegevens auditlog |
Toelichting |
Resultaat van de uitgevoerde actie |
Resultaat van de uitgevoerde stap |
Resultaatcode |
Berichtresultaatcode uit het antwoordbericht |
Wanneer alle stappen met succes zijn doorlopen, worden de voorkomens van de betreffende stappen in het auditlog verwijderd. Van het verwerkte bericht wordt één nieuw voorkomen aangemaakt met de volgende gegevens:
Gegevens auditlog |
Toelichting |
Huidige datum en tijd | Datum-tijd van de eerste stap van het auditlog van betreffende bericht |
Identificatie afzender | DN uit het certificaat |
BV BSN-berichtnummer | Het toegekende BV BSN berichtnummer |
Berichtnummer afzender | Overnemen uit vraagbericht |
Indicatie eindgebruiker/instantie | Overnemen uit vraagbericht |
Uitgevoerde actie | “Bericht verwerkt” |
Resultaat van de uitgevoerde actie | “Succesvol |
Resultaatcode | Berichtresultaatcode uit het antwoordbericht |
2. Alternatieve scenario’s
2.1. Alternatief 1: Autorisatie mislukt
Indien de autorisatie wordt geweigerd, wordt het volgende antwoordbericht verstuurd naar de afzender “Afzender niet geautoriseerd” (berichtresultaatcode 4). Daarnaast wordt een melding in het systeemfoutenlogboek opgenomen. Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.
2.2. Alternatief 2: Vraagnummer begint niet bij nummer 1
Indien de vraagnummer niet bij nummer 1 begint, wordt het volgende antwoordbericht verstuurd naar de afzender “Vraagnummer begint niet bij 1” (berichtresultaatcode 13). Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.
2.3. Alternatief 3: Vraagnummers zijn niet oplopend
Indien de nummering van vraagnummers niet oplopend +1 zijn, wordt het volgende antwoordbericht verstuurd naar de afzender “Vraagnummers zijn niet oplopend” (berichtresultaatcode 14). Hierna wordt verder gegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.
2.4. Alternatief 4: Bericht bevat geen vragen
Indien het inkomende bericht geen vragen bevat, wordt de volgende foutmelding naar de afzender verstuurd ”Het bericht moet minimaal één vraag bevatten” (berichtresultaatcode 7). Hierna wordt verder gegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.
2.5. Alternatief 5: Bericht bevat teveel vragen
Indien het inkomende bericht meer dan n vragen bevat, wordt de volgende foutmelding naar de afzender verstuurd “Het bericht bevat meer vragen dan het toegestane maximum” (berichtresultaatcode 6). Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.
2.6. Alternatief 6: Identificatie afzender in vraagbericht is niet gevuld
Indien het veld Identificatie afzender van het vraagbericht niet gevuld is, wordt de volgende foutmelding naar de afzender verstuurd ”De afzender van het bericht moet gevuld zijn” (berichtresultaatcode 8). Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.
2.7. Alternatief 7: Berichtnummer afzender in vraagbericht is niet gevuld
Indien het veld berichtnummer afzender van het vraagbericht niet gevuld is, wordt de volgende melding naar de afzender verstuurd ”Het berichtnummer van de afzender moet gevuld zijn” (berichtresultaatcode 9). Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.
2.8. Alternatief 8: Indicatie eindgebruiker in vraagbericht is niet gevuld
Indien het veld indicatie eindgebruiker van het vraagbericht niet gevuld is, wordt de volgende melding naar de afzender verstuurd ”De indicatie eindgebruiker van het bericht moet gevuld zijn” (berichtresultaatcode 10). Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.
2.9. Alternatief 9: Een of meer vraagnummers niet ingevuld
Indien een of meer vraagnummers niet ingevuld zijn, wordt de volgende melding naar de afzender verstuurd “De vraagnummers moeten gevuld zijn” (berichtresultaatcode 11). Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.
2.10. Alternatief 10: BSN is niet gevuld
Indien het veld BSN van het vraagbericht niet gevuld is, wordt de volgende melding naar de afzender verstuurd ”BSN moet gevuld zijn” (resultaatcode 3004). Hierna wordt verdergegaan met de volgende vraag, indien deze aanwezig is.
2.11. Alternatief 11: Fout bij controleren van het nummer
Indien er een fout is opgetreden bij het controleren van het nummer, wordt de volgende melding naar de afzender verstuurd “Nummer is geen BSN” (resultaatcode 3003). Hierna wordt verdergegaan met de volgende vraag, indien deze aanwezig is.
2.12. Alternatief 12: Fout bij ophalen gegevens
Indien er een fout optreedt bij het ophalen van de gegevens uit de registratie, wordt de melding ”Er is een fout opgetreden” (berichtresultaatcode 2) in het antwoordbericht verstuurd naar de afzender.
Daarnaast wordt een melding in het systeemfoutenlogboek opgenomen Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.
2.13. Alternatief 13: Geen of meerdere resultaten gevonden
Als er geen of meerdere resultaten gevonden zijn, wordt de melding “Vraag heeft niet tot één persoon geleid” in het antwoordbericht opgenomen (resultaatcode 3001).
Indien er sprake is van de volgende situaties, wordt een fout aan het nummerfoutenlogboek toegevoegd:
- het BSN komt voor in het nummerregister en is “in verkeer” en
- het BSN is meerdere keren aangetroffen in de registratie die vermeld staat in het nummerregister
De volgende gegevens met betrekking tot het foutvermoeden worden opgenomen in het nummerfoutenlogboek:
Gegevens nummerfoutenlogboek |
Toelichting |
Foutnummer | Uniek volgnummer |
BV BSN-Berichtnummer | Nummer van het bericht waarbij de fout optrad |
BSN | BSN waar de fout betrekking op heeft |
Indicatie van de fout | “BSN komt meerdere malen voor in registratie” |
Datum/tijd | Datum tijd van constatering van de fout |
Status van de verwerking van de fout | Open |
Indien het nummerfoutenlogboek niet gevuld kan worden, wordt een melding in het systeemfoutenlogboek opgenomen. Dit heeft verder geen invloed op de verwerking van het bericht.
Hierna wordt verdergegaan met de volgende vraag, indien deze aanwezig is.
2.14. Alternatief 14: Fout bij vullen auditlog
Indien het auditlog niet gevuld kan worden, wordt een melding in het systeemfoutenlogboek opgenomen en moet de verwerking van het bericht stoppen. Aan de afzender van het bericht wordt de melding "Er is een fout opgetreden" (berichtresultaatcode 2) verstuurd.
Indien het tussenstappen betreft wordt direct verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.
Indien het de laatste stap betreft, zal wel de beheerorganisatie, maar niet de afzender hierover geïnformeerd worden.
3. Subprocessen
Niet van toepassing.
4. Belangrijke scenario’s
Niet van toepassing.
5. Precondities
- De afzender die het bericht verstuurt is geauthenticeerd (zie use case: authenticeren).
6. Postcondities
- Alle ondernomen acties zijn vastgelegd in het auditlog;
- Er is een antwoordbericht verstuurd naar de afzender.
7. Extensies
Niet van toepassing.
8. Speciale eisen
Niet van toepassing.
9. Aanvullende informatie
9.1. Activiteitendiagram
Download PDF
Beheervoorziening BSN - Overzicht functionaliteiten
Wat kunt u vinden op deze pagina?
Beheervoorziening BSN - Overzicht functionaliteiten
1. Inleiding
Dit document geeft een overzicht van de gewenste functionaliteit van de BV BSN en een korte omschrijving daarvan. De gewenste functionaliteit is uitwerkt in use-casebeschrijvingen. In hoofdstuk 2 is op globaal niveau de functionaliteit uitgewerkt in een use-casemodel. Van deze use cases is op globaal niveau in onderliggende paragrafen een beschrijving gemaakt.
Een nadere uitwerking van de use case in een basis flow en een alternatieve flow is te vinden in de use-casespecificaties.
1.1. Definities
Zie de BSN glossary.
1.2. Referenties
De BV BSN kent de volgende use-casespecificaties:
- UC02 Controleer BSN en identificerende gegevens
- UC03 Haal op set identificerende gegevens
- UC04 Distribueer nummer
- UC05 Registreer nummertoekenning
- UC06 Hang registratie om bij BSN
- UC07 Ophalen berichten uit berichtenlogboek
- UC08 Vraag auditgegevens op
- UC11 Nummer uit verkeer halen
- UC12 Match identificerende gegevens
- UC13 Opschonen loggegevens
- UC16 Toets of het nummer een BSN is (voorheen Zoek nummer)
- UC17 Authenticeren
- UC18 Autoriseer verzoek
- UC19 Leg bericht vast
- UC21 Registreren opgewaardeerd Sofi-nummer
- UC22 Registreren instantiewijziging
- UC23 Opvragen BSN op basis van identificerende gegevens
- UC24 Verificatie van identiteitsdocumenten
- UC25 Periodieke controle nummers (in bewerking)
- UC26 Vastleggen protocolgegevens
- UC27 Genereren nummers
- UC28 Ophalen nummergegevens
- UC29 Ophalen nummerfouten uit het nummerfoutenlogboek
- UC30 Ophalen protocolgegevens
- UC31 Vastleggen autorisatiegegevens
- UC32 Vastleggen foutvermoeden
- UC33 Stellen bulkvraag
- UC34 Ophalen antwoord bulkvraag
- UC35 Opvragen BSN t.b.v. schoning en initiële vulling
- UC37 Verwerken bulkvraag
- UC38 Detecteren misbruik
- UC39 Doorvoeren correctie nummerregister
2. Functionaliteit BV BSN
2.1. Globale use case beschrijving
In onderstaande paragrafen is de benoemde functionaliteit in het use case model uitgewerkt. Een gedetailleerde uitwerking van de scenario’s is te vinden in de use case specificatie van betreffende use case. Een use case specificatie bevat altijd een hoofdscenario waarin alles goed gaat om het doel te bereiken. Daarnaast kunnen er alternatieve scenario’s zijn die afwijkingen van het hoofdscenario beschrijven, bijvoorbeeld als er iets mis gaat, en aangeven hoe een actor het doel op alternatieve wijzen kan realiseren. In onderstaande paragrafen is een globale beschrijving van de use cases opgenomen.
2.1.1. UC02 Controleer BSN en identificerende gegevens
De use case “Controleer BSN en identificerende gegevens” beschrijft de stappen voor het controleren of de set van identificerende gegevens uit de registratie GBA of RNI, behorende bij het opgegeven BSN, overeenkomt met de opgegeven set identificerende gegevens uit het bericht.
2.1.2. UC03 Haal op set identificerende gegevens
De use case “Haal op set identificerende gegevens” beschrijft de stappen voor het ophalen van een unieke set identificerende gegevens uit de registratie GBA of RNI, behorende bij een BSN.
2.1.3. UC04 Distribueer nummer
De use case “Distribueer nummer” beschrijft de stappen van het genereren en distribueren van nummers in batches aan de actoren BC GBA, en BC RNI.
2.1.4. UC05 Registreer nummertoekenning
De use case “Registreer nummertoekenning” beschrijft de stappen voor het registreren van een toekenning van een BSN. Het nummer is door de toekennende instantie toegekend aan een gerechtigde en is daarna niet meer beschikbaar als toe te kennen nummer.
2.1.5. UC06 Hang registratie om bij BSN
De use case “Hang registratie om bij BSN” beschrijft de stappen voor het omhangen van een registratie bij een BSN. Bij het omhangen van een BSN, wordt in het nummerregister de registratie waarin de gegevens van een persoon zijn opgenomen, gewijzigd (bijvoorbeeld een wijziging van RNI naar GBA).
2.1.6. UC07 Ophalen berichten uit berichtenlogboek
De use case “Ophalen berichten uit berichtenlogboek” beschrijft de stappen voor het opvragen van de gegevens uit het berichtenlogboek die in de BV BSN zijn vastgelegd.
De beheerorganisatie BV BSN en het Foutenmeldpunt kunnen gegevens uit het berichtenlogboek opvragen.
2.1.7. UC08 Vraag auditgegevens op
De use case “Vraag auditgegevens op” beschrijft de stappen voor het opvragen van auditgegevens die in het auditloboek van de BV BSN zijn vastgelegd. In alle use cases is beschreven dat elke stap die door de BV BSN wordt verricht in een auditlog wordt vastgelegd. Hierdoor is het mogelijk te bepalen welke stappen een bericht heeft doorlopen en wat het resultaat van de verwerking is geweest.
De beheerorganisatie van de BV BSN kan de auditgegevens van de berichten opvragen.
2.1.8. UC11 Nummer uit verkeer halen
De use case “Nummer uit verkeer halen” beschrijft de stappen voor het uit verkeer halen van een BSN.
2.1.9. UC12 Match identificerende gegevens
De use case “Match identificerende gegevens” beschrijft de stappen voor het zoeken naar het bestaan van een BSN of SoFi-nummer op basis van een set identificerende gegevens. Aan de hand van de opgegeven identificerende gegevens wordt aan verschillende registraties gevraagd of er personen staan geregistreerd die “matchen” met die gegevens.
2.1.10. UC13 Opschonen gegevens
De use case “Opschonen gegevens” beschrijft de stappen voor het opschonen van berichten/gegevens uit de volgende logboeken:
- Schonen berichtenlogboek
- Schonen nummerfoutenlogboek
- Schonen protocollogboek
- Schonen auditlogboek
2.1.11. UC16 Toets of nummer een BSN is
De use case “Toets of nummer een BSN is” beschrijft de stappen voor het zoeken van een nummer in de BV BSN. Aan de hand van het opgegeven nummer wordt gezocht of een toegekend nummer overeenkomt met het opgegeven nummer. Het zoeken vindt dus niet plaats in de registraties, maar in het BV BSN register zelf.
2.1.12. UC17 Authenticeren
De use case “Authenticeren” beschrijft de stappen voor het authenticeren van een gebruiker van de BV BSN.
2.1.13. UC18 Autoriseer verzoek
De use case “Autoriseer verzoek” beschrijft de stappen voor het bepalen van de autorisatie van een verzoek in de BV BSN.
Autoriseren is het al of niet toekennen van bepaalde rechten aan een gebruiker of een systeem waarvan de identiteit is vastgesteld. Het vaststellen van de identiteit van een gebruiker of een systeem wordt het ‘authenticeren’ (zie UC 17) genoemd.
2.1.14. UC19 Leg bericht vast
De use case “Leg bericht vast” beschrijft de stappen voor het vastleggen van een bericht in het berichtenlogboek. Het kan hierbij gaan om een vraag- of een antwoordbericht. Dit wordt bepaald door de stap van de use case, waarin deze use case leg bericht vast wordt aangeroepen.
2.1.15. UC21 Registreren opgewaardeerd sofi-nummer
De use case “Registreren opgewaardeerd sofi-nummer” beschrijft de stappen voor het registreren van een tot BSN opgewaardeerd sofi- nummer. In onderstaand model is de use case “Registreren opgewaardeerd Sofi-nummer” weergegeven.
2.1.16. UC22 Registreren instantiewijziging
De use case “Registreren instantiewijziging” beschrijft de stappen voor wijzigen van de instantie, waaraan een BSN is toegekend, naar een andere instantie (bijvoorbeeld bij een herindeling of splitsing van een gemeente.)
2.1.17. UC23 Opvragen BSN op basis van identificerende gegevens
De use case “Opvragen BSN op basis van identificerende gegevens” stelt gebruikers in staat om op basis van een minimale set van identificerende gegevens een BSN op te vragen.
2.1.18. UC24 Verificatie van identiteitsdocumenten
De use case “Verificatie van identiteitsdocumenten” beschrijft de stappen voor het valideren van de geldigheid van een documentnummer.
2.1.19. UC25 Periodieke controle nummers
De use case “Periodieke controleren nummerregister” beschrijft de stappen voor het periodiek controleren van burgerservicenummers en Sofi-nummers.
2.1.20. UC26 Vastleggen protocolgegevens
De use case “Vastleggen protocolgegevens” beschrijft de stappen voor het bijhouden van protocolgegevens. Hierbij worden alle gegevensverstrekkende acties voor ieder BSN geregistreerd en vastgelegd.
2.1.21. UC27 Genereren nummers
De use case “Genereren nummers” beschrijft het proces waarbij nieuwe nummers die kunnen worden toegekend als Burgerservicenummer worden gegenereerd en in het register worden opgenomen.
2.1.22. UC28 Ophalen nummergegevens
De use case “Ophalen nummergegevens” beschrijft de stappen voor het ophalen van de gevraagde nummergegevens die in de BV BSN zijn vastgelegd. De beheerorganisatie BV BSN en het Foutenmeldpunt kunnen gegevens uit het nummerregister opvragen.
2.1.23. UC29 Ophalen nummerfouten uit het nummerfoutenlogboek
De use case “Ophalen nummerfouten uit het nummerfoutenlogboek” beschrijft de stappen van het doorgeven van nummerfouten aan het Foutenmeldpunt. De nummerfouten worden opgehaald uit het nummerfoutenlogboek. De bevraging vanuit het foutenmeldpunt wordt periodiek uitgevoerd. Gezien de BV BSN niet op de hoogte is van deze periode wordt deze meegegeven in het vraagbericht (begin- en einddatum), zodoende worden alleen gegevens van een bepaalde periode opgehaald waarbij de status van de foutmelding “Open” is. Voor de meldingen die worden doorgegeven wijzigt de status naar “Doorgegeven aan Foutenmeldpunt”.
2.1.24. UC30 Ophalen protocolgegevens
De use case “Ophalen protocolgegevens” beschrijft de stappen voor het opvragen van protocolgegevens die in het protocollogboek van de BV BSN zijn vastgelegd. De beheerorganisatie van de BV BSN kan het protocollog opvragen.
2.1.25. UC31 Vastleggen autorisatiegegevens
De use case “Vastleggen autorisatiegegevens” beschrijft de stappen voor het vastleggen van autorisatiegegevens in de BV BSN.
De gegevens worden door de beheerorganisatie van de BV BSN opgegeven.
2.1.26. UC32 Vastleggen foutvermoeden
De use case “Vastleggen foutvermoeden” beschrijft de stappen voor het melden van een foutvermoeden door een beheercomponent. Deze worden vastgelegd in het nummerfoutenlogboek
2.1.27. UC33 Stellen bulkvraag
De use case “Stellen bulkvraag” stelt gebruikers in staat om meerdere vragen met betrekking tot het opvragen van het BSN op basis van identificerende gegevens. De gebruiker krijgt een behandelnummer terug en kan later op basis van dit behandelnummer het antwoord op de bulkvraag ophalen. Het betreft hier een tijdelijke dienst van de BV BSN.
2.1.28. UC34 Ophalen antwoord bulkvraag
De use case “Ophalen antwoord bulkvraag” stelt gebruikers in staat om antwoord te krijgen op de eerder gestuurde bulkvraag om bij de opgegeven identificerende gegevens het BSN te zoeken (zie UC33) middels het behandelnummer.
Het betreft hier een tijdelijke dienst van de BV BSN.
2.1.29. UC35 Opvragen BSN t.b.v. schoning en initiële vulling
De use case “Opvragen BSN t.b.v. schoning en initiële vulling” stelt gebruikers in staat om op basis van een minimale set van identificerende gegevens een BSN op te vragen. Het betreft hier een tijdelijke dienst van de BV BSN.
2.1.30. UC37 Verwerken bulkvraag
De use case “Verwerken bulkvraag” verwerkt de gestelde bulkvraag (zie BV BSN UC34) op een door het systeem bepaald moment. Hierna wordt het antwoord op de bulkvraag klaargezet, zodat dit kan worden opgehaald (zie BV BSN UC35).
Het betreft hier een tijdelijke dienst van de BV BSN.
2.1.31. UC38 Detecteren misbruik
De use case “Detecteren misbruik” bewaakt het berichtenverkeer en signaleert uitzonderingssituaties aan de beheerorganisatie BV BSN.
2.1.32. UC39 Doorvoeren correctie nummerregister
De use case “Doorvoeren correctie nummerregister” beschrijft de stappen voor het corrigeren van een record in het nummerregister. De beheerorganisatie BV BSN kan een correctie doorvoeren.
Download PDF
W164 Oplegnotitie - Verschillen in kolomnamen landelijke tabellen
Wat kunt u vinden op deze pagina?
- 1 Probleemstelling
- 1.1 Omschrijving
- 1.2 Herkomst
- 1.3 Raakvlakken
- 2 Oplossing
- 2.1 Huidige situatie
- 2.2 Oplossing
- 2.3 Gerelateerde wijzigingen in wet- en regelgeving
- 2.4 Openstaande punten
- 3 Invoering
- 4 Gevolgen
- 4.1 Documentatie
- 4.2 Gemeenten
- 4.3 Afnemers
- 4.4 IND
- 4.5 Caribische landen en Caribisch Nederland
- 4.6 RvIG-systemen
W164 Oplegnotitie - Verschillen in kolomnamen landelijke tabellen
1 Probleemstelling
1.1 Omschrijving
In de loop van de jaren zijn er verschillen ontstaan in de kolomnamen van de landelijke tabellen, tussen de benaming van de rubrieken in het LO, de kolomkoppen in de CSV-versie van de tabellen en die in de PDF-versie ervan. Vanwege de beperkte ruimte in PDF-bestanden is het logisch dat kolomnamen daarin worden afgekort, maar dat gebeurt niet overal op een consistente wijze. In een enkel geval is ook de rubrieknaam in het LO niet logisch.
1.2 Herkomst
Dit probleem is geconstateerd door het LO-team.
1.3 Raakvlakken
Er zijn geen raakvlakken met andere LO-wijzigingen.
2 Oplossing
2.1 Huidige situatie
Er zijn een aantal problemen met de kolomnamen in de landelijke tabellen:
- De gekozen naam voor de rubriek is niet heel logisch of bevat nutteloze toevoegingen. Voorbeeld: 05.12 Officiële omschrijving nationaliteit. "Officiële" voegt hier niets toe.
- De kolomnaam in de CSV-versie van een tabel komt niet overeen met de rubrieknaam in het LO. Voorbeeld: 33.92.11 "Omschrijving" in de CSV van tabel 33 Gemeententabel is niet gelijk aan 33.92.11 "Officiële gemeentenaam" in het LO.
- De kolomnaam in de PDF-versie van een tabel komt niet overeen met de rubrieknaam in het LO. Voorbeeld: "Omschrijving" in de PDF-versie van tabel 36 Voorvoegseltabel is niet gelijk aan 36.02.31 "Voorvoegsel" in het LO.
- Bij kolomnamen in de PDF-versie van tabellen zijn tweede en volgende woorden vaak (niet altijd) met een hoofdletter geschreven, terwijl dat in de CSV-versie en in het LO niet zo is. Voorbeeld: "Datum Ingang" in de PDF-versie van tabel 32 Nationaliteitentabel is geen logische afkorting van 32.99.98 "Datum ingang tabelregel" in het LO.
2.2 Oplossing
In LO BRP krijgen sommige rubrieken een andere naam als die logischer of consistenter is met vergelijkbare rubrieknamen in andere tabellen. In de CSV- en de PDF-versies van tabellen worden de kolomnamen aangepast volgens de aanwijzingen in de bijlage "W164 Bijlage - Verschillen kolomnamen landelijke tabellen LO-CSV-PDF.xlsx".
2.3 Gerelateerde wijzigingen in wet- en regelgeving
Er is geen afhankelijkheid van wet- en regelgeving.
2.4 Openstaande punten
Er zijn geen openstaande punten.
3 Invoering
Geen bijzonderheden.
4 Gevolgen
4.1 Documentatie
In LO BRP worden de volgende rubrieknamen aangepast:
Rubriek |
Naam was |
Naam wordt |
32.05.12 |
Officiële omschrijving nationaliteit |
Omschrijving nationaliteit |
33.92.11 |
Officiële gemeentenaam |
Gemeentenaam |
34.94.11 |
Officiële landnaam |
Landnaam |
37.96.10 |
Reden opnemen/beëindigen nationaliteit |
Code opnemen/beëindigen nationaliteit |
37.96.20 |
Omschrijving |
Omschrijving opnemen/beëindigen nationaliteit |
38.02.21 |
Adellijke titel/predicaat |
Code adellijke titel/predicaat |
39.81.22 |
Omschrijving soort akte |
Omschrijving akte |
41.07.41 |
Reden ontbinding/nietigverklaring huwelijk/geregistreerd partnerschap |
Code ontbinding/nietigverklaring |
41.07.42 |
Omschrijving |
Omschrijving ontbinding/nietigverklaring |
48.35.11 |
Nederlands reisdocument |
Code Nederlands reisdocument |
48.35.12 |
Omschrijving |
Omschrijving Nederlands reisdocument |
49.35.41 |
Autoriteit van afgifte |
Code autoriteit van afgifte |
49.35.42 |
Omschrijving |
Omschrijving autoriteit van afgifte |
56.39.11 |
Verblijfstitel |
Code verblijfstitel |
56.39.12 |
Omschrijving |
Omschrijving verblijfstitel |
59.97.12 |
Aanduiding aangesloten op de berichtendienst |
Aangesloten op de berichtendienst |
61.32.11 |
Gezagsverhouding |
Code gezagsverhouding |
61.32.12 |
Omschrijving |
Omschrijving gezagsverhouding |
4.2 Gemeenten
Gemeenten en afnemers krijgen te maken met iets andere kolomnamen in de tabellen zoals die gepubliceerd worden op de website van RvIG. Omdat de tabelberichten blijven zoals ze zijn, is er alleen directe impact op gemeenten die de tabellen van de website downloaden en inlezen. Indirecte impact is er als gemeenten in het datamodel ook de nieuwe rubrieknamen willen hanteren, of als rubrieknamen ook op schermen (bijvoorbeeld bij een inzagefunctie voor tabellen) worden getoond. In dat geval zullen ze mogelijk hun software hierop moeten aanpassen.
4.3 Afnemers
Gemeenten en afnemers krijgen te maken met iets andere kolomkoppen in de tabellen zoals die gepubliceerd worden op de website van RvIG. Zij zullen mogelijk hun software hierop moeten aanpassen. Van sommige afnemers is bekend dat zij de tabellen in CSV-formaat downloaden van de website en via een automatische import inlezen in hun applicatie. Die import functie moet mogelijk worden aangepast. Afnemers die tabelgegevens aangeleverd krijgen via de tabelberichten, hoeven niets te doen, tenzij ze in het datamodel, of in schermen van hun applicaties de namen van de rubrieken mee willen wijzigen. In dat geval zullen ze mogelijk hun software moeten aanpassen.
4.4 IND
Geen gevolgen.
4.5 Caribische landen en Caribisch Nederland
Geen gevolgen.
4.6 RvIG-systemen
De tabellenapplicatie zal de nieuwe rubrieknamen moeten ondersteunen in haar datamodel en in de schermen voor tabelbeheer, en in staat moeten zijn om de tabellen te generen in CSV- en PDF-formaat met de nieuwe kolomnamen. Daarnaast staan tabelgegevens ook in BRP-V opgeslagen. Ook daar moeten kolomnamen worden aangepast, maar dat is vooral om intern naamgebruik consistent te houden met namen van kolommen in het LO.