Het is niet mogelijk om bij het wijzigen van gerelateerdengegevens (in bepaalde situaties specifiek toegestaan) aan te geven dat het een correctie betreft. Volgens de StUF-standaard kan dit alleen met verwerkingssoort W doorgegeven worden, als zijnde een wijziging in de werkelijkheid. Technisch is er geen groot onderscheid omdat bij gerelateerden geen tijdvak geldigheid opgenomen wordt. Door de betreffende zinsneden uit de StUF-standaard te verwijderen kan echter wel aangegeven worden dat het een correctie betreft en geen wijziging in de werkelijkheid.
Ik wil de expertgroep verzoeken dit op het eerstvolgende overleg te behandelen en de betreffende zinsneden uit de StUF-standaard te verwijderen.
Jouw wens is een RFC op de stuf0301 standaard, in het bijzonder een aanpassing op tabel 5.7, een na laatste rij: corrigeren object, en de zinssnede boven die tabel.
Bovendien is het een RFC op sectormodel bg0310 waar zelfs geen wijzigingen in de werkelijkheid zijn toegestaan behalve een aantal uitzonderingen wegens legacy redenen (o.a. om de mapping vanuit bg0204 kloppend te krijgen). M.a.w. jouw RFC gaat tegen de trent in waarin uberhaupt geen wijzigingen in gerelateerden worden toegestaan. Deze dienen namelijk in een apart bericht als topfundamenteel gewijzgd te worden.
Wat is jouw argumentatie om deze trent te keren?
Standaard is het wijzigen van de gegevens van een gerelateerd object niet toegestaan. In het sectormodel kan hiervan echter worden afgeweken, en dat is dan ook gebeurd voor o.a. de relaties NPSTGO, NPSNPSOUD, NPSNPSHUW en NPSNPSKND. De exacte werkwijze is beschreven in tabel 5.7 van de StUF-standaard, en hierop is ook mijn voorstel van toepassing (er kan immers niet worden gecorrigeerd).
Je eerste zin klopt volgens mij niet. Tabel 5.7 geeft aan dat je wel mag wijzigen in een gerelateerde maar niet mag corrigeren. Echter bg0310 maakt maar in een paar gevallen (NPSTGO, NPSNPSOUD, NPSNPSHUW en NPSNPSKND) gebruik van de mogelijkheid om te mogen wijzigen in een gerelateerde. Maar daar ging mijn vraag niet over.
Wat is de business case dat je wilt kunnen corrigeren in een gerelateerde? Het alternatief zou zijn dat je de correctie comuniceert in een apart bericht met de gerelateerde als topfundamenteel.
Een GBA-systeem kent de persoon niet als een topfundamenteel, het betreft bijvoorbeeld een ouder uit een vreemd land. Daarvoor is ook de uitzondering in het sectormodel gemaakt.
Een business case zou kunnen zijn het corrigeren van de gegevens van een ouder n.a.v. een foutieve overname van de gegevens van een brondocument.
Volgens mij worden er een paar begrippen door elkaar gehaald, namelijk relatie en gerelateerde.
Een relatie (waaronder alle genoemde voorbeelden: NPSTGO, NPSNPSOUD, NPSNPSHUW en NPSNPSKND) mag volgens tabel 5.5 worden gecorrigeerd.
Wijzigen of corrigeren van een gerelateerde mag niet, tenzij dit is vastgesteld in een sectormodel. De genoemde gerelateerde mag m.i. niet gecorrigeerd of gewijzigd worden.
Tenslotte: een SUB (subject) zijnde een buitenlandse persoon is m.i. volgens RSGB geen INP (ingezeten natuurlijke persoon) maar een NIP (niet-ingezeten natuurlijke persoon). Deze vallen volgens het RSGB niet onder het RSGB maar onder het RNI. Als een GBA applicatie wordt aangepast aan het RSGB, dan zal m.i. dus óf het beheer van NIPs moeten worden uitbesteed aan een RNI appplicatie óf zal de gecombineerde GBA/RNI applicatie zowel NIPs and INPs moeten beheren.
In beide gevallen graag volgens de regels, anders wordt het een zootje.