Naar aanleiding van deze discussie denk ik dat er een inconsistentie zit tussen de StUF 0301 standaard en keuzenVersStUFfing.
In de StUF standaard staat op pagina 63:
In een toevoegkennisgevingbericht 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. Het is in deze situatie overigens niet verplicht om een foutbericht te sturen in de genoemde foutsituatie. Een afnemer zou ook een synchronisatieverzoek kunnen sturen. Andere acties zijn echter ook mogelijk). Bij een keuze voor verwerkingssoort 'T' hoeft een zender niet te controleren of de ontvanger een object in een gerelateerde reeds kent. Indien de de ontvanger het object nog niet kent voegt deze het voor de gerelateerde toe met alleen voor de kerngegevens een waarde. Indien de ontvanger het object wel al kent dan mag deze de verwerkingssoort 'T' interpreteren als een 'I'. Er is dan geen sprake van een foutsituatie
In de keuzenverStUFfing staat op pagina 12:
De zaak die als deelzaak wordt gekoppeld dient eerst in een kennisgeving te worden aangeboden, omdat vanuit de 'hoofd'zaak statusinformatie over deelzaken gevolgd moet kunnen worden. Alleen verwerkingssoort 'I' is derhalve toegestaan in de gerelateerde.
De tekst in de StUF standaard is aangepast naar aanleiding van ONV0419, zoals beschreven in https://vng-realisatie.github.io/StUF-Standaarden/discussie/gemma/stuf-301/verwerkingssoort-t-i-bij-gerelateerde-entiteit
Moet de keuzenverStUFfing dan niet aangepast worden? Want het kan voorkomen dat de asynchrone kennisgevingen uit de Zaak- Documentservices in een andere volgorde verwerkt worden dan ze verstuurd worden. De zender weet dan niet of een (deel)zaak al bekend is in het ontvangende systeem maar wil zijn gegevens wel graag versturen.
Er lijkt me hier geen sprake te zijn van strijdigheid, maar van een specificatie in de keuzenVerStUFfing van de toegestane waarde voor de verwerkingssoort van een gerelateerde in een specifieke context. De StUF-standaard schetst wat er allemaal kan en mag, maar een berichtontwerper mag altijd een concreet bericht restricten tot een deel van wat in principe van StUF mag.
Functioneel blijft dan natuurlijk wel de vraag staan of de nu gedefinieerde functionaliteit wenselijk is, maar dat is een andere discussie.
Dit Onderhoudsverzoek is opgevoerd in de onderhoudsverzoeken als ONV0507.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Tijdens de StUF Expertgroep van 21 februari 2018 is het onderhoudsverzoek afgekeurd. Michiel gaf aan dat hij het in het koppelvlak kan dichttimmeren. De vraag of het wenselijk is het dicht te timmeren moet echter in de werkgroep besproken worden.