Middels creeerZaak proberen we een zaak met als initiator een Natuurlijk Persoon (NPS) te creeeren. De NPS moet aangemaakt worden (verwerkingssoort=T). Het enige verplichte veld volgens ZDS en StUF-ZKN is "inp.bsn".
Echter, het datamodel bevat bijvoorbeeld ook het verplichte veld "geslachtsaanduiding" (kardinaliteit 1-1 volgens RGBZ->RSGB). Volgens ZDS en in StUF-ZKN is dit echter een optioneel element. De NPS kan daardoor niet worden aangemaakt in de database, maar voldoet wel aan de XSD validatie.
Wat is hier het gewenste gedrag?
Bij dit soort vragen is het altijd goed om te vermelden welke versies van de informatiemodellen RGBZ en RSGB, StUF ZKN en Zaak- Documentservices gebruikt worden. In dit geval is het zo dat jullie RGBZ 2 implementeren en de Zaak- Documentservices 1.2 zijn gebaseerd op RGBZ 1.
Het is dus heel goed mogelijk dat er gegevens in RGBZ 2 verplicht zijn maar niet in RGBZ 1, waardoor ze ook niet verplicht zijn in StUF ZKN 03.10 en de ZDS 1.2.
Verder is het zo dat de schema's van StUF ZKN 03.10 bewust vrij gelaten zijn om de berichten voor meerdere toepassingen geschikt te maken. Met andere woorden, veel elementen zijn in de schema's optioneel terwijl ze op informatie model mogelijk verplicht zijn in bepaalde situaties. Op deze manier kan hetzelfde bericht in verschillende situaties toegepast worden en naar aanleiding van die situatie gevuld worden. In de koppelvlakken zijn de berichten al een stuk strakker gedefinieerd, al zal ik de eerste zijn om toe te geven dat daar nog een hoop winst te behalen valt.
Nu terug naar de situatie die je beschrijft: volgens mij probeer je in een creeerZaak een gerelateerde (NPS in dit geval) toe te voegen. Doordat het hier een gerelateerde betreft (en geen volledige NPS) is alleen een identificerend veld verplicht, niet de volledige set gegevens om een NPS aan te maken. Ontbrekende gegevens om een NPS op te slaan wanneer deze nog niet bekend is in het zaaksysteem kunnen opgehaald worden door middel van de unieke identificatie BSN (of Ander Natuurlijk Persoon.identificatie wanneer het een niet-ingezetene betreft).
Overigens is het volgens mij niet nodig dat dat een BSN of anp.identificatie verplicht is. Hiermee zou het nl. niet mogelijk zijn om een anonieme melding of een melding met alleen naam gegevens te doen. Terwijl er genoeg meldingen te verzinnen zijn waarvoor een identificatie van de initator helemaal niet noodzakelijk is. Wanneer ik een melding maak van een kapotte straatlantaarn is mijn BSN irrelevant terwijl er wel een zaak aangemaakt wordt. De gemeente kan zelf controleren dat de straatlantaarn inderdaad kapot is en ik zie vanzelf wel wanneer deze gerepareerd is. Terug melden is dus ook niet noodzakelijk.
In dat geval kan een BSN leeggelaten worden en dan is er geen aanvullende informatie van de initator of kan deze opgehaald worden. Volgens mij moet een zaaksysteem hier mee om kunnen gaan.
Edit: een BSN kan niet leeggelaten worden maar moet gevuld worden met een reeks van 9 cijfers. Dit kunnen echter wel bijvoorbeeld allemaal nullen zijn, waardoor het element niet verwijst naar een bestaand BSN. Bij de inrichting kan dan bepaald worden dat in dat geval sprake is van een onbekend BSN/anonieme melding en het bericht als zodanig behandelen.
Dag Michiel,
Bedankt voor je antwoord. Naar aanleiding hiervan nog enkele vervolgvragen (heb ze genummerd).
Ik was inderdaad vergeten versie nummers te noemen. Komt mede omdat we tegenwoordig alle bijna versies checken qua documentatie om tot een implementatie te komen. Het gaat hier specifiek om ZDS 1.2, met RGBZ 2.0, waarbij ik de kanttekening plaats dat in het geval van "geslachtsaanduiding" hier geen wijzigingen zijn t.o.v. RGBZ 1.0. Ook hebben we gekeken naar RSGB 2.0 waar het attribuut "geslachtsaanduiding" vandaan komt.
1. Ik begrijp bovenstaande redenatie, maar hoe weten consumers dan wat ze mee moeten geven? Trial and error?
Klopt.
Klopt ook, volgens de schema's en specificatie.
2a. Zeg je hier dat het Zaaksysteem aan de hand van het BSN de overige (volgens RGBZ 1.0) verplichte NPS gegevens moet ophalen, en deze dan moet "aanmaken"?
2b Of, bedoel je dat de consumer eerst een NPS moet ophalen en aanmaken middels een andere service?
Ik ben het met je eens dat het in praktische scenario's niet altijd verplicht zou hoeven zijn. We willen echter niet afwijken van de specificatie (waarin het nu eenmaal wel verplicht is in RGBZ 1.0 en de schema's), dus dan zou de specificatie aangepast moeten worden.
3. Stel, BSN is optioneel en wordt niet meegegeven, hoe kan het ZS dan de overige (volgens RGBZ 1.0) verplichte NPS gegevens ophalen?
Hoi Joeri,
Een deel van je vragen volgt uit het feit dat in de koppelvlakken geen processen beschreven staan maar alleen maar gegevensuitwisselingen. De processen en het berichtenverkeer worden tijdens de implementatie van een systeem ingericht, al dan niet met (maat/meer)werk. In ieder geval zijn systemen niet zelflerend dus trial en error zal het zeker niet zijn.
Jammer genoeg zijn er op dit moment nog geen design patterns en proces beschrijvingen hoe een applicatie moet werken. De GEMMA architectuur schrijft voor referentiecomponenten voor welke functionaliteiten ondersteund moeten worden maar laat de leveranciers daar relatief vrij in om eea. in te vullen.
Wanneer er geen sprake is van identificerende gegevens (een identificatie of matchinggegevens die uniek kunnen identificeren) is het erg lastig een NPS of andere gerelateerde aan te maken. In zo'n geval kan het zijn dat een initiator anoniem is. De gemeente bepaalt zelf hoe zo'n situatie opgelost moet worden.
Of dat een ideale situatie is kunnen we nog best eens een boom opzetten maar met de huidige standaarden is het zoals het is.
Deze ervaringen gaan we natuurlijk meenemen in de doorontwikkeling van de standaarden, bedankt voor je input en kom vooral met meer!
Groeten,
Michiel