In het XSD is voor een Adres in de rol van gerelateerde (bijv. onder PRSADRVBL) opgegeven dat enkel de kerngegevens mogen worden opgenomen.
Echter, als je StUF 02.04 leest en vervolgens de beschrijving van BG 02.04 in het document BG0204.doc, dan moet voor ADR de volledige set gegevens beschikbaar zijn. Hiervoor verwijs ik naar onderstaande citaten.
Het XSD moet daarom dus in overeenstemming gebracht worden met de beschrijving.
Dit speelt een rol bij applicaties die wijzigingen van een ADR alleen maar in de rol van gerelateerde kunnen doorgeven.
Denk hierbij ook aan de GBA applicaties die in het kader van LO 3.7 nu elementen opnemen. De opname van of een wijziging in deze elementen wordt als een infrastructurele wijziging doorgegeven. Een StUF bericht vanuit een dergelijke applicatie zal als topfundamenteel PRS bevatten en een wijziging van ADR onder PRSADRVBL, PRSADRINS en/of PRSADRCOR.
Citaten uit StUF 02.04
Citaat 1
Blz. 26: Een kennisgevingsbericht kan zonder expliciete afspraken in het sectormodel slechts drie typen wijzigingen doorgeven. Het toevoegen, verwijderen, wijzigen en corrigeren van fundamentele entiteit. Het toevoegen of beeindigen van een relatie. Een wijziging in de gegevens van een relatie-entiteit.
Citaat 2
Blz. 26: Van een gerelateerde fundamentele entiteit mogen tenzij anders gespecificeerd in het sectormodel alleen de kerngegevens worden opgenomen.
Citaat 3
Blz 36: In het sectormodel kan gespecificeerd worden dat een gerelateerde entiteit ook mag voorkomen met de verwerkingssoort W.
Citaat 4
Blz 38: Een gerelateerd object mag als onderdeel van een relatie worden toegevoegd. <...> In deze gevallen dient in het gerelateerde object T als verwerkingssoort te worden gespecificeerd en gelden voor de gerelateerde entiteit dezelfde regels als voor een fundamentele entiteit uit de header van het bericht met inachtneming van de eventuele beperkingen gedefinieerd in het sectormodel.
Citaat 5
Blz 38: Bij het wijzigen of corrigeren van een relatie mag in het sectormodel worden gespecificeerd dat als onderdeel van de wijziging ook gegevens van het gerelateerde object mogen worden gewijzigd. <...> Bij het wijzigen of corrigeren gegevens in het gerelateerde object dient als verwerkingssoort W te worden gespecificeerd en gelden verder dezelfde regels als voor het wijzigen van een fundamentele entiteit met inachtneming van de beperkingen gedefinieerd in het sectormodel.
Citaat uit BG 02.04.doc
Blz. 17: Een via PRSADRVBL, PRSADRINS of PRSADRCOR gerelateerd adres hoeft niet voor te komen in het ontvangende systeem. Het ontvangende systeem kan het adres al dan niet toevoegen op basis van de in de entiteit ADRES gespecificeerde gegevens. Indien het adres reeds in het ontvangende systeem voorkomt met andere gegevens, dan dienen de oorspronkelijke gegevens gehandhaafd te worden en moet een foutmelding gegeven worden. Via een kennisgevingsbericht van een toevoeging van een persoon mogen geen wijzigingen in een gerelateerd adres worden doorgegeven. Hiervoor moet een kennisgevingsbericht voor een adres gebruikt worden.
Een wijziging in een van deze adressen mag worden doorgegeven als een wijziging in de gegevens van het gerelateerde adresobject.
Een dergelijke tekst is ook terug te vinden bij KDO, NNO en VBO.
Ik wil hier nog aan toevoegen dat bij ADR als gerelateerde, het tijdvak geldigheid ook opgegeven moet kunnen worden.
Deze is nu niet aanwezig in de XSD.
Hallo Ton,
De vraag waar we voor staan is of dit een erratum is of niet. Ik zelf neig ernaar om dit als een erratum te zien, omdat je in je post voldoende motiveert dat het altijd de bedoeling is geweest dat adressen binnen persoonsberichten (afkomstig uit GBA en VOA) voldoende gegevens bevatten om in applicaties die adressen als zelfstandig object bijhouden de mutaties in dit zelfstandige adresobject door te voeren. Daarvoor is uitbreiding van de gerelateerde met de door jou genoemde elementen noodzakelijk.
Ik stel voor dat we dit punt ter beslissing voorleggen aan de StUF Expertgroep en dat betrokkenen vooraf hun mening geven op het forum via jouw post.
Maarten
Niet geheel verassend ben ik voorstander om dit via een erratum te corrigeren.