Co-sign data is not included in stuf-zds creeerzaak bericht

[olenitsj]

Product versie / Product version

2.7.8

Customer reference

No response

Omschrijf het probleem / Describe the bug

Co-sign data is not included in stuf-zds creeerzaak bericht.

This does work with object api, but not with stuf-zds.

Stappen om te reproduceren / Steps to reproduce

1. Fill in a form with co-sign and submit
2. Log in with the second digid account and submit the form.
3. See that stuf ZDS creerZaak bericht is being sent.
4. See that the xml does not include any of the co-sign data, except an e-mail adres.

Verwacht gedrag / Expected behavior

Expected that the bsn and other cosign data is being sent in a xml node of zaakDMS standard.

Screen resolution

None

Device

None

OS

None

Browser

No response

[olenitsj]

@LaurensBurger terinfo

[joeribekker]

@olenitsj Please indicate where you want this to be added in the StUF-ZDS creeerZaak operation XML attributes

[olenitsj]

@joeribekker, This would be our preference:

{% if co_signer %}
<ZKN:heeftBetrekkingOp StUF:entiteittype="ZAKOBJ" StUF:verwerkingssoort="T">
    <ZKN:gerelateerde>
        <ZKN:natuurlijkPersoon StUF:entiteittype="NPS" StUF:verwerkingssoort="T">
            <!-- BSN of the co-signer -->
            <BG:inp.bsn>{{ co_signer.bsn }}</BG:inp.bsn>
            <BG:authentiek StUF:metagegeven="true">J</BG:authentiek>
            
            <!-- Additional common data for co-signer -->
            {% if co_signer.geslachtsnaam %}<BG:geslachtsnaam>{{ co_signer.geslachtsnaam }}</BG:geslachtsnaam>{% endif %}
            {% if co_signer.voorvoegselGeslachtsnaam %}
                <BG:voorvoegselGeslachtsnaam>{{ co_signer.voorvoegselGeslachtsnaam }}</BG:voorvoegselGeslachtsnaam>
            {% else %}
                <BG:voorvoegselGeslachtsnaam xsi:nil="true" StUF:noValue="geenWaarde" />
            {% endif %}
            {% if co_signer.voorletters %}<BG:voorletters>{{ co_signer.voorletters }}</BG:voorletters>{% endif %}
            {% if co_signer.voornamen %}<BG:voornamen>{{ co_signer.voornamen }}</BG:voornamen>{% endif %}
            {% if co_signer.geslachtsaanduiding %}<BG:geslachtsaanduiding>{{ co_signer.geslachtsaanduiding }}</BG:geslachtsaanduiding>{% endif %}
            {% if co_signer.geboortedatum %}<BG:geboortedatum>{{ co_signer.geboortedatum }}</BG:geboortedatum>{% endif %}
        </ZKN:natuurlijkPersoon>
    </ZKN:gerelateerde>
    
    <!-- Description of the relation to the case, i.e., mede initator/cosign -->
    <ZKN:omschrijving>mede_initiator</ZKN:omschrijving>
</ZKN:heeftBetrekkingOp>
{% endif %}```

[joeribekker]

Ah, a technical answer :)

I mostly needed to know which StUF-element will be used for this but you are adding it to "heeftBetrekkingOp". I'm not sure this is semantically the correct location. The relation roughly means: "it affects X". This is typically used when you move to another location, and your family members move with you.

Maybe more appropriate would be a "heeftAlsOverigeBetrokkene"? But, since this is unclear/undocumented behaviour I can't say for sure what is best.

@sergei-maertens what would be your estimate to add this?

[sergei-maertens]

Hrm, as far as I know we currently only get the BSN. Using the prefill configuration we can get additional details, but this blurs the lines again tussen old and current cosign.

I think this would take a team member about 3 working days and then some extra (2d?) to patch up mistakes because of ordering etc. since we don't have access to a real StUF-BG backend to test with.

[olenitsj]

@joeribekker I agree, we looked at heeftAlsOverigeBetrokkene first. But it is correct in both ways. The one we prefer will work out-of-the box with our current implementation of the integration tunnel+xxllnc zaken. So that's why we have a preference for heeftBetrekkingOp element.

Most important we need the BSN of the cosigner and other data that you already output for the Object API registration backend for cosigning for the GU in the current version in prod. As this is the minimum data set needed for the GU.

With regards to estimation and timelines: When will be the first possible moment we could get this installed in our environment?

[joeribekker]

The specification for heeftBetrekkingOp does not alllow authentiek to be set to J, even though we clearly know the BSN via a validated source (DigiD). This strengthens me to use heeftAlsOverigBetrokkene, which does allow it.

Due to Sergei's comment, we also need to strip all the other information.

This snippet should appear directly below </ZKN:heeftAlsInitiator>:

{% if co_signer %}
<ZKN:heeftAlsOverigBetrokkene StUF:entiteittype="ZAKOBJ" StUF:verwerkingssoort="T">
    <ZKN:gerelateerde>
        <ZKN:natuurlijkPersoon StUF:entiteittype="NPS" StUF:verwerkingssoort="T">
            <BG:inp.bsn>{{ co_signer.bsn }}</BG:inp.bsn>
            <BG:authentiek StUF:metagegeven="true">J</BG:authentiek>
        </ZKN:natuurlijkPersoon>
    </ZKN:gerelateerde>
    <ZKN:omschrijving>mede_initiator</ZKN:omschrijving>
</ZKN:heeftAlsOverigBetrokkene>
{% endif %}

@olenitsj can you confirm this is ok?

[olenitsj]

I can definitely agree on <ZKN:heeftAlsOverigBetrokkene, this is fine, and a valid reason for the authentiek J.

I can agree on a first release without the additional information of the cosigner.

I am not sure the business will accept the missing data. However, if this can be added without any additional rework at a later moment. That is fine by me. I will try selling the bsn only solution internally for the time being.

[joeribekker]

@vaszig go :)