Een van die functionaliteiten is opvragen Reisdocumentinformatie in het ReIS Aanvraagportaal (RAP) en de Reisdocumentenmodule (RDM). Hieronder lees je meer over deze functionaliteit.

Wat is functionaliteit de Reisdocumentinformatie?

Met ‘Reisdocumentinformatie’ ook wel ‘Documentinzage’ genoemd, zie je de administratieve levensloop van een reisdocument. Je krijgt detailinformatie over de status van een reisdocument te zien, inclusief de personalisatiegegevens en meldingen die zijn gedaan op het reisdocument. Hierdoor weet je welke reisdocumenten iemand nog meer heeft of heeft gehad, en of een reisdocument in omloop mag zijn. Ook als dit document door een andere uitgevende instantie is versterkt. Dit helpt je om onder andere vast te stellen welke documenten de aanvrager bij de aanvraag van een nieuw document zou moeten inleveren.

Hoe werkt Reisdocumentinformatie?

Reisdocumentinformatie is beschikbaar in het RAP en de RDM.

Je kunt zoeken op:

• Reisdocumentnummer
• BSN of A-nummer
• Personalisatiegegevens

Je ziet dan:

• Detailinformatie over de huidige status van een reisdocument, inclusief personalisatiegegevens en meldingen
• Detailgegevens van het opgevraagde document
• Tijdlijn van het document

Deze informatie komt uit het Basisregister Reisdocumenten (BR).

Toelichting en infographic Meldingen en Statussen in het BR

Er is met het Basisregister Reisdocumenten (BR) een betere manier om de status van en meldingen op een reisdocument te registreren. De volgende twee onderdelen zijn belangrijk:

• Status
• Melding

De status van een reisdocument kan alleen veranderen door een melding. Het systeem past de status automatisch aan als dat nodig is op basis van de melding.

In de infographic ‘statussen van reisdocumenten in het basisregister ’ zie je welke meldingen tot welke statussen leiden.

Wat is een status?

Alleen (bestaande) documenten hebben een status. Dit wil zeggen dat een document een status kan krijgen, nadat het reisdocument is gepersonaliseerd door de producent.

Vanaf dat moment kan een document vier statussen hebben:

• In aanvraag (IA) = Het document is gepersonaliseerd bij de producent en wordt aan de uitgiftelocatie overgedragen.
• Geldig (GD) = Het document is uitgereikt aan de burger en in omloop.
• Ongeldig (OG) = Het document is van rechtswege vervallen en nog in omloop. Het document is niet meer geldig. Het is bijvoorbeeld vermist of de geldigheidsduur is verstreken, maar het document is (nog) niet ingeleverd.
• Definitief onttrokken (DO) = Het document is ingenomen, ongeldig gemaakt door middel van ponsgaten, vernietigd en niet meer in omloop. Een document dat van rechtswege is vervallen en aan de balie wordt ingeleverd, krijgt eerst de status Ongeldig en direct daarna Definitief onttrokken. Een reisdocument kan in bepaalde gevallen als het nog geldig is, direct Definitief onttrokken worden. In dat geval wordt de status Ongeldig overgeslagen.

De status van een document verandert altijd volgens deze volgorde. Het reisdocument heeft altijd maar één status. De status kan niet terug naar een vorige status. Het is wel mogelijk om een status over te slaan. Bijvoorbeeld als een reisdocument is vervallen vóór uitreiking omdat het niet op tijd is opgehaald. Meer uitleg vind je in de infographic.

Wat is een melding?

Een status van een document kan alleen door middel van een melding een melding veranderen. De volgende meldingen zijn mogelijk:

• RGP: reisdocument is gepersonaliseerd
• RVU: reisdocument is vervallen vóór uitreiking
• RRV: reisdocument is van rechtswege vervallen
• RRU: reisdocument is uitgereikt
• RDO: reisdocument is definitief onttrokken

De uitgevende instantie legt deze meldingen vast.

Reisdocumentinformatie in overige processen

Je kunt reisdocumentinformatie ook voor andere processen gebruiken. Kies dan bij de aanleiding voor de optie ‘identiteitsonderzoek’. Bij deze optie is het invoeren van het aanvraagnummer niet verplicht.

Wat verandert er precies en wat blijft hetzelfde?

De volgende zaken veranderen:

• Je gebruikt de functionaliteit Reisdocumentinformatie om te weten te komen welke documenten de aanvrager moet overleggen.
• Het Basisregister Reisdocumenten (BR) is de nieuwe en leidende bron voor reisdocumentengegevens en statussen. Categorie 12 BRP/PIVA en de RAAS blijven voorlopig bestaan, maar het BR is leidend.
• Het opvragen van Reisdocumentinformatie vindt digitaal plaats (het vervangt het opvragen van een het RAAS-aanvraagformulier).

De volgende zaken blijven hetzelfde:

• Kopie van het foto- en handtekeningformulier vraag je op via een RAAS-aanvraagformulier bij bijvoorbeeld een vermissing of bij twijfel over identiteit.
• Reisdocument statussen in categorie 12 van de BRP/PIVA (Ingehouden, Ongeldig, Rechtswege vervallen) blijven hetzelfde, en bijhouding daarvan blijft voorlopig bestaan.

Veelgestelde  vragen

De veelgestelde vragen en antwoorden lees je op de pagina Veelgestelde vragen over het opvragen van Reisdocumentinformatie.

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

Image

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

Figuur 2. Structuur van een stuurGBAbericht (vraag)

Image

Figuur 3. Structuur van een stuurGBAbericht (antwoord)

Image

2. Voorbeelden van de stuurGBABericht webserivce

1. valideer_pl vraagbericht met Lg01 in CDATA sectie

Image

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

Image

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

Image

4. sPoed vraag: SummarizeMessages

Image

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)

Image

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

Image

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)

Image

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)

Image

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

Image

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)

Image

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)

Image

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)

Image

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

Image

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).

Image

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

Image

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

Image

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

Image

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
 

Image

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

Image

① 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.

Image

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

Image

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 &#13; 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

Image

In dit voorbeeld is de ampersand in de straatnaam V&D weg vervangen door &amp;.

Appendix B: WSDL en XSD

stuurGBABericht-v1.0.wsdl

Image

Image

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

Image

Image

Image

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)

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.
 

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.

Image

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:

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:

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):

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:

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

Image

Download PDF

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.

Image

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:

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:

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

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):

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:

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:

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

Image

Download PDF