search

dma61 / VBPUOdsk

2 stars 0 forks source link

Wijzigingsvoorstel Berichtstructuur 3. Pensioenprojectie (0001c) #8

Closed kooskaspers closed 5 months ago

kooskaspers commented 8 months ago

Verbetervoorstel Berichtstructuur 3. Pensioenprojectie (0001c).pdf Verbetervoorstel Berichtstructuur 3. Pensioenprojectie (0001c).docx

Let op: uitganspunt voor de aanpassing is de 11 januari versie hieronder.

kooskaspers commented 8 months ago

Dank voor je feedback Duco. Hierbij een nieuwe versie:

Verbetervoorstel.Berichtstructuur.3.Pensioenprojectie.0001c-20240111.docx

dma61 commented 8 months ago

Dit wijzigingsvoorstel wordt besproken (februari) in de functionele rond functionaliteit.

estrenuo commented 7 months ago

In het wijzigingsvoorstel zie ik nog een probleem. In de totalPayment (op pensionScheme) en payment (op cohort) wordt een refKey vermeld die zich herhaalt (steeds "1") terwijl de Date wel steeds verschilt (dat is ook de bedoeling). Maar als de definitie van een refKey is dat deze de entiteit uniek identificeert, dan gaat dat niet goed. De refKey is in het voorbeeld namelijk alleen in combinatie met de Date uniek.

kooskaspers commented 7 months ago

@estrenuo, helemaal eens. Die refkey in het voorbeeld had uniek moeten zijn. Foutje in van mijn kant.

estrenuo commented 7 months ago

@kooskaspers is die refkey überhaupt wel nodig eigenlijk nu ik erover nadenk? Zolang er geen meerdere expectedPensionPayment zijn op dezelfde (toekomstige) datum, is die datum namelijk voldoende voor identificatie in combinatie met de refkey van de cohort.

kooskaspers commented 7 months ago

Ook daar ben ik het helemaal mee eens @estrenuo. Ook wat mij betreft halen we die er idd uit!

dma61 commented 6 months ago

Aanvraag uitgezet voor benodigde AFD 2.0 aanpassingen. De structuur van het aanpassingsvoorstel wordt gevolgd. De entiteit.entitytype en attribuutnamen kunnen daardoor anders worden. Interne SIVI referentie: 519

dma61 commented 6 months ago

20240324 toevoeging: refKey laten vervallen ligt voor de hand. @kooskaspers svp graag het onderstaande laten bevestigen (of ontkennen) door Lieuwe. => Het komt NOOIT voor dat er meerdere expectedPensionPayment op dezelfde (toekomstige) datum zijn onder 1 pension.cohort binnen 1 en hetzelfde bericht.

@kooskaspers is die refkey überhaupt wel nodig eigenlijk nu ik erover nadenk? Zolang er geen meerdere expectedPensionPayment zijn op dezelfde (toekomstige) datum, is die datum namelijk voldoende voor identificatie in combinatie met de refkey van de cohort.

dma61 commented 6 months ago

@kooskaspers moet hedgedAmount niet ook in de pensionPayment entiteit onder pension.cohort staan?

Hier komt hij nu in het voorstel wel voor: image

maar hier niet: image

kooskaspers commented 6 months ago

20240324 toevoeging: refKey laten vervallen ligt voor de hand. @kooskaspers svp graag het onderstaande laten bevestigen (of ontkennen) door Lieuwe. => Het komt NOOIT voor dat er meerdere expectedPensionPayment op dezelfde (toekomstige) datum zijn onder 1 pension.cohort binnen 1 en hetzelfde bericht.

@kooskaspers is die refkey überhaupt wel nodig eigenlijk nu ik erover nadenk? Zolang er geen meerdere expectedPensionPayment zijn op dezelfde (toekomstige) datum, is die datum namelijk voldoende voor identificatie in combinatie met de refkey van de cohort.

Ha Duco, dit is inderdaad slechts 1 bedrag, per regeling, per datum, per cohort.

@kooskaspers moet hedgedAmount niet ook in de pensionPayment entiteit onder pension.cohort staan?

Hier komt hij nu in het voorstel wel voor: image

maar hier niet: image

Dat heb ik als zodanig overgenomen uit de functionele documentatie:

image

Je leest hier dat het een veld is wat alleen relevant lijkt te zijn over cohorten heen (dus op totaal niveau). Wat je eventueel zou kunnen doen is het veld optioneel beschikbaar maken onder payment die hangt onder de pension.cohort entiteit en verplicht houden onder payment onder de pension.scheme entiteit.