Wij zijn een koppeling aan het realiseren naar een zaaksysteem op basis van de KING Standaard Zaak en Documentservices 1.1.
Hierbij maken wij een zaak aan met CreeerZaak en kijken daarbij naar de regels in xsd en het specificatiedocument.
Volgens beide zou (indien initiator is vestiging) enkel het vestigingsnummer verplicht zijn. Alle andere elementen binnen het element vestiging zijn optioneel.
Als wij dit zo invullen en opsturen naar het testplatform dan krijgen wij een foutmelding dat handelsnaam ontbreekt. Als er vervolgens een handelsnaam wordt ingevuld ontbreekt verblijfsadres of verblijfBuitenland terwijl dit alle optionele velden zijn.
Doen wij iets niet goed? Wie kan hier meer duidelijkheid over geven?
Beste Dave,
Uit je beschrijving kan ik niet echt halen wat de oorzaak is van de fout. Ik heb getest met bijgevoegd bericht, waarin de vestiging zit met alleen vestigingsNummer. Dit wordt gewoon geaccepteerd, zonder foutmelding in het StUF Testplatform.
Zou je het bericht dat je hebt gebruikt kunnen bijvoegen, en kunnen aangeven precies welke foutmelding je krijgt? Graag foutmeldingnummer (bijv. SVS0000112 of ZKDM000039) en de fouttekst.
Bijlage
Hallo Frank, dank voor je reactie.
Waarschijnlijk doen wij dan iets niet goed. De foutcode is SVS0000112
Bijgevoegd alvast de weergave van de foutcode en tekst.
Bijlage
In de fout staat dat het bericht verkeerde inhoud heeft en een element datumAanvang aangetroffen is waar een verblijfsadres of verblijfsadresBuitenland toegestaan is.
Daarom nogmaals de vraag van collega Frank: heb je voor ons een testbericht? Want de enige manier voor ons om deze vraag goed te kunnen beantwoorden is naar je bericht kijken. Vanzelfsprekend mag (graag zelfs, moet eigenlijk) je privacy gevoelige informatie vervangen door nep gegevens.
Foutcode SVS0000112 betekent dat het bericht niet valideert tegen schema.
Het probleem zit zo te zien in element datumAanvang. Dit element mag je hier niet opnemen, want zit niet in complexType VES-zkn-kerngegevensKennisgeving.
Element datumAanvang is geen kerngegeven van Vestiging, en in een gerelateerde in een kennisgevingbericht worden alleen kerngegevens opgenomen.
De XML wordt gegenereerd vanuit .NET code en datumAanvang wordt niet gevuld.
Dit wordt in XML vertaald naar xsi:nil="true"
Bijgevoegd de volledig XML zoals wij hem opsturen.
Bijlage
Het probleem is heel simpel: Dat bericht voldoet niet aan het schema van een zakLk01.
In het testbericht staan na het element handelsnaam nog andere elementen waarvan datumAanvang het eerste foute element is. Zoals collgea Frank al aangegeven heeft: In de gerelateerde worden alleen de kerngegevens opgenomen maar jullie code zet er meer elementen in die daar niet in horen. Jullie code doet dus niet wat in het schema staat. Overigens hadden jullie deze fout gemakkelijk zelf op kunnen sporen door het bericht gewoonweg tegen de XSD schema's te valideren.
Bedankt voor jullie heldere uitleg.
De xml was inderdaad niet correct, datumAanvang hoort niet in vestiging voor te komen.
Voor (.NET) generatie waren de originele xsd’s gebruikt en de restriction constructie zorgde ervoor dat de restricted types als base opgenomen werden. Hierdoor kwam datumAanvang uit VES-zkn-basis in vestiging terecht (wat niet correct is).
Inmiddels maken we gebruik van “geresolvede” xsd’s waar de restrictions uitgehaald zijn (ZDS 1.2 2017 Q1 Resolved), maar lopen we nog steeds tegen het probleem aan dat optionele velden een probleem geven.
Voor het creëren van een zaak gebruiken we: CreeerZaak-ZAKBTRINI-kennisgeving
CreeerZaak-ZAKBTRINI-kennisgeving heeft het element heeftAlsAanspreekpunt.
In xsd:
<element name="heeftAlsAanspreekpunt" type="ZKN:ZAKBTRINICTP-kennisgeving" nillable="true" minOccurs="0"/>
Dus niet verplicht, mag nil zijn.
In de xml staat:
<heeftAlsAanspreekpunt xsi:nil="true"/>
Het testplatform geeft terug:
"verwerkingssoort" must appear on element "heeftAlsAanspreekpunt"
Bijgevoegd de Xml zoals wij die doorsturen.
Als heeftAlsAanspreekpunt volledig wordt ingevuld gaat het wel goed (maar zou niet hoeven)
Bijlage
Hallo Dave,
In een creeerZaak (Lk01) bericht kan je de eigenschappen van de zaak zelf opnemen, plus relevante relaties. Een relatie-element opnemen zonder inhoud heeft in dat kader geen duidelijke betekenis. Wat moet het ontvangende systeem hiermee doen?
In de StUF specificaties paragraaf 5.2.6 staat beschreven hoe een relatie in een bericht moet worden opgenomen. Als je een relatie opneemt, moet deze ook een verwerkingssoort hebben (en ook inhoud die de relatie en gerelateerde definieert). Als je de relatie niet wilt toevoegen aan de zaak, neem je het relatie-element niet op. Het is dus niet de bedoeling een relatie-element op te nemen zonder verwerkingssoort en zonder inhoud.
Hallo Frank, jouw antwoord is mij duidelijk. De verwarring zit in de manier waarop wordt aangegeven dat het relatie-element niet aanwezig is.
Als je stelt dat in dit geval het relatie-element op xml niveau niet voor mag komen dan ben ik het daar niet mee eens.
De xsd staat gebruik van het nil attribuut toe. Volgens de W3C standaard is het dan gebruikelijk om met xsi:nil="true" expliciet aan te geven dat het element niet aanwezig is. Het testplatform zou dan ook het relatie-element moeten negeren.
Ik heb een test gedaan door in de xsd nillable="true" te verwijderen bij het betreffende element. In dat geval wordt het relatie-element ook niet meer opgenomen in xml en gaat het wel goed in het testplatform.
Dave,
De XML Schema specificaties zeggen het volgende over het gebruik van xsi:nil:
XML Schema Part 0: Primer Second Edition
2..9 Nil Values
An element with xsi:nil="true" may not have any element content but it may still carry attributes.
XML Schema Part 1: Structures Second Edition
2.6.2 xsi:nil
XML Schema: Structures introduces a mechanism for signaling that an element should be accepted as ·valid· when it has no content despite a content type which does not require or even necessarily allow empty content. An element may be ·valid· without content if it has the attribute xsi:nil with the value true. An element so labeled must be empty, but can carry attributes if permitted by the corresponding complex type.
3.3.1 The Element Declaration Schema Component
If {nillable} is true, then an element may also be ·valid· if it carries the namespace qualified attribute with [local name] nil from namespace http://www.w3.org/2001/XMLSchema-instance and value true (see xsi:nil (§2.6.2)) even if it has no text or element content despite a {content type} which would otherwise require content. Formal details of element ·validation· are described in Element Locally Valid (Element) (§3.3.4).
Het komt allemaal op hetzelfde neer. Een element dat volgens zijn datatype niet leeg mag zijn mag wel leeg zijn als daarop het 'xsi:nil' attribute wordt (en kan worden) gedefinieerd met de waarde 'true'. Er wordt nergens gezegd dat een element dat een 'xsi:nil' attribute kan bevatten ook perse aanwezig moet zijn. Daarnaast wordt er ook niets gezegd over hoe je een element met een 'xsi:nil' met de waarde 'true' moet interpreteren. Dat wordt overgelaten aan de ontwerper van het schema.
Voor StUF geldt, zoals Frank al eerder aangaf, dat als je een relatie niet wil toevoegen je hem dan niet opneemt.
Robert, je stelling tav de werking van het testplaform is duidelijk, en wij zullen daar omheen werken.
Als je stelt dat interpretatie overgelaten moet worden aan de ontwerper van het schema, dan vraag ik mij nog af wat de interpretatie van de ontwerper van het StUF schema is tav het gebruik van nillable=”true”. Dit attribuut heeft blijkbaar geen betekenis binnen het schema.
Dave,
Ik begrijp de vraag niet helemaal maar in de diverse StUF schema's wordt m.b.v. 'nillable="true"' alleen aangegeven waar het attribute 'xsi:nil' gebruikt mag worden. Dat echter zal niet nieuw voor je zijn.
De manier waarop je 'xsi:nil' moet interpreteren in de context van StUF staat beschreven in de StUF standaard.
Een element is verplicht of niet verplicht.
Een leeg niet verplicht element wordt weggelaten.
Een leeg verplicht element wordt aangegeven met xsi:nil en StUF:noValue volgens de beslisboom in 3.4.1
heeftAlsAanspreekpunt is volgens het testplatform niet verplicht en moet in het geval van leeg worden weggelaten.
Als het schema voor heeftAlsAanspreekpunt enkel minOccurs=”0” zou hebben dan is daar geen twijfel over. De aanwezigheid van nillable=”true” sluit dit echter niet uit.
De aanwezigheid van minOccurs=”0” en nillable=”true” laat ruimte voor meerdere interpretaties en ik kan niet op basis van het schema eenduidig vaststellen of (in dit geval) heeftAlsAanspreekpunt een verplicht element is of niet.
Mijn vraag is dan ook: wat bepaald of een element verplicht is of niet?
Aanvullend op bovenstaande nog een keer door de specs gegaan om te begrijpen waarom het is zoals het is.
Zoals ik nu begrijp worden regels per sectormodel bepaald, maar is dat ondergebracht in één schema. Klopt dat?
Als dat zo is dan zorgt dat voor verschillende implementaties per sectormodel. Is er dan per sectormodel een model beschikbaar waarin de regels die horen bij dat sectormodel vastliggen?
Beste Dave,
Voor zover ik weet is er voor het onderwerp van deze vraag, namelijk de manier waarop relaties moeten worden opgenomen in een kennisgeving, geen specifieke invulling gegeven in het sectormodel Zaken. Hier geldt dus alleen wat is beschreven in schema en wat is beschreven in de StUF specificaties. Op een aantal aspecten mogen in een sectormodel aanvullende eisen worden opgenomen, maar dat is hier niet van toepassing.
Het schema is minder strikt voor het creeerZaak-bericht dan de specificaties. Dit komt omdat het zakLk01 bericht een generiek bericht is dat ook voor wijzigingen en correcties kan worden gebruikt. Aangezien er bij een wijziging/correctie twee voorkomens van element <object> zijn, en bij het daarin toevoegen of verwijderen van een relatie een relatie-element met xsi:nil in het eerste resp. tweede voorkomen moet worden opgenomen, zit elke relatie met nillable in het schema. Dit is de reden dat alle relatie-elementen nillable zijn in het schema, maar de StUF specificaties (niet het sectormodel) bepalen wanneer en hoe nillable moet of mag worden gebruikt. In alle gevallen, ook wanneer het relatie-element leeg is, zal er een attribuut verwerkingssoort op het relatie-element moeten worden opgenomen.
Hallo Frank,
Bedankt voor je antwoord, ik kan je uitleg volgen totdat ik bij de laatste zin aankwam waarin je schrijft: In alle gevallen, ook wanneer het relatie-element leeg is, zal er een attribuut verwerkingssoort op het relatie-element moeten worden opgenomen.
Eerder schreef Robert: Voor StUF geldt, zoals Frank al eerder aangaf, dat als je een relatie niet wil toevoegen je hem dan niet opneemt (en dan neem ik aan dat hier weglaten wordt bedoeld)
Dit is precies waar het om gaat en waar ik een antwoord op probeer te vinden om tot een correcte implementatie te komen.
Het weglaten van het relatie element werkt voor het testplatform, dat heb ik inmiddels ondervonden. Maar als je nu schrijft dat er altijd een verwerkingssoort op het relatie-element opgenomen moet worden dan is weglaten van het element niet correct toch?
Als er geen relatie is, moet je het relatie-element niet opnemen in het bericht. Dit is wat Robert al aangaf en dit geldt dus (ook) voor het creeerZaak bericht.
Wanneer je in een wijzigingsbericht (dus niet in het creeerZaak bericht, maar bijvoorbeeld in een updateZaak bericht) een relatie wilt toevoegen, neem je in het bericht op (in dit voorbeeld de relatie heeftAlsBelanghebbende):
<ZKN:object StUF:verwerkingssoort="W" StUF:entiteittype="ZAK">
...
<ZKN:heeftAlsBelanghebbende StUF:verwerkingssoort="T" StUF:entiteittype="ZAKBTRBLH" xsi:nil="true"/>
...
</ZKN:object>
<ZKN:object StUF:verwerkingssoort="W" StUF:entiteittype="ZAK">
...
<ZKN:heeftAlsBelanghebbende StUF:verwerkingssoort="T" StUF:entiteittype="ZAKBTRBLH">
<ZKN:gerelateerde>...</ZKN:gerelateerde>
...
</ZKN:heeftAlsBelanghebbende>
...
</ZKN:object>
Dus als je een relatie-element opneemt in het bericht, ook als die leeg is (zoals moet bij toevoegen en verwijderen), moet er altijd een attribuut verwerkingssoort worden opgenomen.
Maar als een relatie er niet is, en er dus ook niet de bedoeling is de relatie toe te voegen of verwijderen, moet het relatie-element niet worden opgenomen.
Helemaal helder nu! De verwarring werd veroorzaakt door de verschillen tussen "leeg" en "er niet is". Ik heb dat onterecht als hetzelfde gezien.