In ONV 487295 "Verwerkingssoort T of I bij gerelateerde entiteit?" in de Zaak- Documentservices kwam onderstaande vraag naar voren. De oorspronkelijke vraag stond op het discussieplatform KV-ZDS: https://vng-realisatie.github.io/StUF-Standaarden/discussie/gemma/koppelvlak-zs-dms/ver...
"Volgens StUF 3.01 moet een zendende applicatie "I" sturen als hij zeker weet dat de entiteit in de ontvangende applicatie aanwezig is. Als het zendende systeem niet zeker weet of het ontvangende systeem een gerelateerde kent, dient het gerelateerde object met "T" als StUF:verwerkingssoort te worden opgenomen. Het is echter onduidelijk bij "T" wat er gebeurt als de entiteit al aanwezig is in het ontvangende systeem. Kunnen we dan ook een foutbericht verwachten?
Graag een uitspraak: of altijd "T" of altijd "I" bij een gerelateerde entiteit in het kader van ZS-DMS. Ook graag STP hierop aanpassen."
Wanneer de entiteit reeds aanwezig is in het ontvangende systeem is StUF:verwerkingssoort "T" niet correct en zou dit een foutmelding (StUF067 Dubbelen voor object gevonden) moeten geven. In de praktijk geeft dit een hoop extra berichtenverkeer terwijl dit niet nodig is.
Voorstel is om in de StUF standaard op te nemen dat bij gerelateerde entiteiten altijd de StUF:verwerkingssoort "T" gebruikt wordt. Wanneer blijkt dat de gerelateerde eniteit reeds bestaat zal de ontvangende partij geen foutmelding sturen maar de StUF:verwerkingssoort "T" verwerken als ware het een StUF:verwerkingssoort "I".
Dit onderhoudsverzoek is opgevoerd in de onderhoudsverzoeken als ONV0419.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
In de zipfile met daarin schema's en documentatie van sectormodel StUF-BG staat in het document keuzenverStUFfing_RSGB.pdf in paragraaf 2.8 het volgende geschreven
/**/
In een kennisgevingbericht mogen gerelateerden in principe worden opgenomen met verwerkingssoort 'T' (de zender weet niet of de gerelateerde al bekend is bij de ontvanger. De ontvanger mag de gerelateerde toevoegen op basis van de gegevens in het bericht) of 'I' (de zender verwacht dat de ontvanger de gerelateerde reeds kent. Indien dit niet het geval is, dan is er sprake van een foutsituatie). Bij een keuze voor verwerkingssoort 'T' hoeft een zender niet te waarborgen dat de ontvanger een object in een gerelateerde reeds kent. Zonodig voegt de ontvanger het object voor de gerelateerde toe met alleen voor de kerngegevens een waarde.
/**/
Hieruit leid ik af dat gebruik van verwerkingssoort T niet verplicht om de gegevens op te nemen. Dus wanneer de gegevens al bekend zijn bij de ontvanger hoeft deze er niets mee te doen en wordt geen foutmelding terug gestuurd. Deze zelfde interpretatie is in de StUF Expertgroep van 20-04-2016 besproken en onderschreven door de aanwezige partijen.
De documenten van het sectormodel StUF-BG zijn te vinden op: http://gemmaonline.nl/index.php/Sectormodel_Basisgegevens:_StUF-BG#Docum... .
Tijdens de StUF Expertgroep van 20 maart 2016 is gesteld dat de verwerkingssoort T altijd als een I moet worden geïnterpreteerd als het gerelateerde object al bestaat. Bij nader onderzoek blijkt dat in paragraaf 2.8 van de de verStUFfing RSGB de volgende alinea staat:
Het lijkt ons goed om deze alinea te verhuizen naar de StUF standaard.
In het bijgaande voorstel heb ik aan de eerste twee lijstitems van paragraaf 5.2.6 van de StUF standaard tekst toegevoegd die verheldering geeft m.b.t. dit issue.
Bijlage
Als ik, na het lezen van de bovenstaande alinea, een nieuwe implementatie van een StUF-koppeling zou gaan maken zou ik in al mijn kennisgevingen alleen nog gebruik gaan maken van verwerkingssoort 'T'. Dit maakt het namelijk niet meer mijn probleem. Hiernaast ik hoef ook geen foutafhandeling te maken voor het geval dat als ik een 'I' zou opsturen en het ontvangende systeem kent het gegeven al.
Ik stel dus bij deze voor schaf de hele verwerkingssoort 'I' af bij gerelateerde gegevens dan hebben we deze discussie nooit meer.
Tijdens de StUF Expertgroep van 18 mei 2016 is het voorstel nog niet goedgekeurd. De opmerking van Mark dat de waarde 'I' geen waarde meer zou hebben is door Maarten weerlegt. In synchronisatieberichten heeft dit nog zeker zijn waarde. Mark gaf aan problemen te hebben met de situatie waarin hij een foutbericht zou moeten sturen. Maarten heeft daarop uitgelegd dat er geen foutbericht gestuurd hoeft te worden. Er wordt ook niet gesproken over een foutbericht maar over een foutsituatie. Op die foutsituatie hoeft geen foutbericht gestuurd te worden maar juist een verzoek voor een synchronisatiebericht. We gaan de toegevoegde tekst verduidelijken door daarin nog beter te beschrijven wat je mag verwachten op basis van een 'I' als verwerkingsSoort.
Kleine correctie/aanvulling op bovenstaande post: Maarten gaf aan dat het niet verplicht is om een foutbericht te sturen in de genoemde foutsituatie. Een afnemer zou, zo stelde Maarten, ook een synchronisatieverzoek kunnen sturen. StUF schrijft niet voor hoe de fout moet worden afgehandeld. Andere acties zijn dus ook mogelijk.
In de post hierboven lijkt het of de ontvanger een synchronisatieverzoek zou moeten sturen. Dat is, zoals ik het heb begrepen, niet het geval.
Heel goed dat je nog wat nuances aanbrengt.
Dank je!
Bij deze het verbeterde voorstel dat ik op deze wijze alvast zal opnemen in prepatch 25.
Bijlage
Tijdens de StUF Expertgroep van 15 juni 2016 is het laatste voorstel goedgekeurd. Het zal worden opgenomen in patch 25.