Bij de implementatie van de prefill services zijn we tegen de volgende fouten aangelopen: 1. In de schema's is bij de stuurgegevens van vesLa01-prs-Vestiging voor het element 'entiteittype' het attribuut fixed='NPS' opgenomen. Dat moet 'VES' zijn. Oorzaak is dat in element vesLa01-prs-Vestiging voor de stuurgegevens wordt verwezen naar type StUF:stuurgegevensLa01-prs-NatuurlijkPersoon. Dat moet zijn StUF:stuurgegevensLa01-prs-Vestiging. 2. In de voorbeeldberichten is het verblijfsadres dubbel opgenomen. Dat komt door de wijze waarop de relatie met adressen in de schema's is opgenomen. In de StUF-BG schema's heeft de choice het attribuut maxOccurs=1. In de prs schema's is maxOccurs=2 opgenomen. Naar ons idee is dat laatste onjuist. 3. In de schema's is in vesLv01-prs-Vestiging en vesLa01-prs-Vestiging onder het element verblijfsadres het element 'inp.locatiebeschrijving' opgenomen. Dit attribuut is echter in RSGB alleen bij ingezetenen gedefinieerd en dus niet bij vestigingen. In StUF-BG is dit element ook niet opgenomen voor vestigingen. 4. In de berichtdefinitie van vesLa01-prs-Vestiging wordt voor het element parameters verwezen naar complextype parametersLa01-prs-NatuurlijkPersoon. Dit moet zijn parametersLa01-prs-Vestiging. Beide complextypes hebben dezelfde definitie dus dit heeft geen invloed op de validatie maar het zou wel netjes zijn dit in een volgende versie aan te passen.
do, 4-09-2014 - 14.47u
#1
Fouten in de schema's
Hoi Roel, mijn reactie: 1.) Inderdaad, dit zal ik corrigeren conform jullie suggestie. 2.) Ik heb gekeken naar NPSNINING-basis in bg0310-ent-basis.xsd uit de StUF-BG schema's. Daar is de minOccurs=0 en maxOccurs=2. In het bericht npsLa01-prs-NatuurlijkPersoon in bg0310_msg_prs.xsd uit de prefill e-formulierenservices is de minOccurs=1 en maxOccurs=2 (en 'verblijfsadres' verplicht. Hierdoor kan aan het verblijfsadres nog een verblijf in het buitenland worden aangegeven. 2a) Klopt dit tot zover? Of kijkt Centric naar NPS-kerngegevens, waar de restrictie wel een maxOccurs=1 heeft? 2b) Ik zie in het voorbeeldbericht npsLv01-prs-NatuurlijkPersoon-max.xml inderdaad 2x het verblijfsadres. Zou dit wel goed zijn wanneer de 2e instantie omgevormd wordt naar BG:sub.verblijfBuitenland? Of moeten we het bericht aanpassen zodat NPS-kerngegevens gebruikt wordt? 3.) 3a) Naar welke entiteit kijkt Centric in StUF-BG? VES-kerngegevens? Ik vermoed dat PRS uit is gegaan van VES-basis. 3b) Wat is de gewenste oplossing? We kunnen het attribuut op de correcte manier toevoegen aan het bericht (door een nieuwe entiteit te creëren voor PRS), maar dan verrijken we met iets dat verder gaat dan RSGB. Mijn voorkeur is dus om het attribuut te schrappen. Drastischer is de oplossing dat we het bericht opnieuw maken op basis van VES-kerngegevens. 4.) Inderdaad, dit zal ik corrigeren conform jullie suggestie.
2) Ik had gekeken naar het antwoordbericht vesLa01 in bg0310_msg_vraagAntwoord.xsd. Naar aanleiding van jouw reactie heb ik nog wat verder gekeken. Het is in het vraagbericht vesLv01 inderdaad zo dat in de scope een maxOccurs van 2 wordt toegepast. Omdat je als vrager niet weet of de vestiging een binnenlands of buitenlands adres heeft moet je immers beide kunnen opvragen. In het antwoord kan slechts één van beide worden geretourneerd. Daar heeft maxOccurs dus (impliciet) een waarde van 1. In de betreffende prs-vraag (vesLv01-prs-Vestiging) is het verblijfsadres als verplicht opgenomen. Omdat het element achter een choice is opgenomen heeft dat geen effect. Bovendien kan een vestiging een binnenlands of een buitenlands adres hebben. Eén van beide verplicht stellen is dus functioneel ook niet gewenst. Overigens valideren geldige vragen en antwoorden tegen dit schema. Eventuele aanpassing heeft dus geen haast. Het is alleen wel handig het foute voorbeeld aan te passen. Maak je van de 2e instantie BG:sub.verblijfBuitenland dan klopt het wel. 3) Ook hier heb ik gekeken naar vesLv01 en vesLa01 in in bg0310_msg_vraagAntwoord.xsd. Daar worden respectievelijk VerblijfsadresGrpNNPVES-vraag en VerblijfsadresGrpNNPVES-antwoord gebruikt. De fout zit in het feit dat in de prefill service het complextype VerblijfsadresGrp-prs-r wordt gebruikt en die is opgezet voor gebruik in combinatie met natuurlijke personen.
M.b.t. 1): aangepast in bg0310_msg_prs.xsd: "In element vesLa01-prs-Vestiging voor de stuurgegevens werd verwezen naar type StUF:stuurgegevensLa01-prs-NatuurlijkPersoon. Dat moest zijn StUF:stuurgegevensLa01-prs-Vestiging. Dit is gecorrigeerd." M.b.t. 2): Eigenlijk willen we toch BG:sub.verblijfBuitenland tegelijk met verblijfsadres niet per se ondersteunen? Uit je uitleg leid ik af dat het of-of moet zijn. Voor nu heb ik de volgende aanpassing doorgevoerd: In bg0310_ent_prs.xsd aangepast: Choice van verblijfsadres/verblijfbuitenland binnen 'VES-antwoord-prs-r' aangepast naar min en max van '1'. M.b.t. 3): In bg0310_ent_prs.xsd heb ik de volgende aanpassingen gedaan: - ComplexType VerblijfsadresGrpVes-prs-r toegevoegd, omdat VerblijfsadresGrp-prs-r niet voor vestigingen bruikbaar is. - Type van 'verblijfsadres' binnen VES-antwoord-prs-r gewijzigd naar VerblijfsadresGrpVes-prs-r. - ComplexType VerblijfsadresGrpVes-scope-prs-r toegevoegd - Type van 'verblijfsadres' binnen VES-scope-prs-r gewijzigid naar VerblijfsadresGrpVes-scope-prs-r M.b.t. 4): aangepast in bg0310_msg_prs.xsd: In element vesLa01-prs-Vestiging werd voor de parameters verwezen naar parametersLa01-prs-NatuurlijkPersoon. Dat moest zijn StUF:parametersLa01-prs-Vestiging. Dit is gecorrigeerd.
M.b.t. 2): Dat klopt. We willen inderdaad een van beide in het antwoord. Min en max van 1 voor de choice is correct. Je moet alleen ook het element verblijfbuitenland een min van 1 geven want anders wordt niet afgedwongen dat een van beide wordt aangeleverd. De choice met een max van 2 in de scope van de vraag blijft wat lastig omdat daarmee ook twee maal dezelfde keuze kan worden opgevraagd. Het zou volgens mij beter zijn beide opties zonder choice met een minOccurs van 0 in de sequence op te nemen. Maar aangezien het op dezelfde manier in het StUF-BG schema voor npsLv01 zit, is het waarschijnlijk beter dit zo te laten.
We hebben ook nog de volgende issues m.b.t. de vestiging gevonden: 1. In de vraag vesLv01-prs-Vestiging is in de scope een choice met maxOccurs 1 opgenomen voor het correspondentie adres. Omdat de vrager waarschijnlijk niet weet of het correspondentie adres al dan niet een postadres is, moeten beide in de scope kunnen worden opgenomen. Hier moet het attribuut maxOccurs dus de waarde 2 hebben. 2. In het antwoord vesLa01-prs-Vestiging is de postcode in het verblijfsadres niet nillable en in het correspondentie adres wel. Zou dat niet andersom moeten zijn? 3. In bovengenoemde is de postcode in het correspondentie wel nillable maar het attribuut noValue ontbreekt.