Is there a use case that there might be another recipient within the group? Yes, if the beneficiary is not available. It depends on the implementation. Sometimes given person can be the next of kin. In on site payment distribution it is due to manager to validate data of the proxy recipient. If for any reason they cannot be validated (e.g. different ID) then data would have to be updated before payment can be received.
There are several roles in the household i.e Husband, Wife. Each group should have one core recipient responsible for collecting money, however there can be situation in which other group members also are authorized to receive money.
When it comes to the group creation - it should be based on the input attributes and approach similar to one existing for openIMIS insurees. In the data input (like csv) there should be group indicator like UUID. If group for given identifier is already in the database then individuals should be attached to existing group. In case when identifier is not yet recognized then new group should be defined.
Patrick has described the diagram of entity relations within the new system:
Malike was describing the use case for grouping beneficiaries funcionality while data uploading via ETL. To address this one, we need to extend the current ETL upload by another filed which will be used as a groups indicatior (i.e group number). If beneficiaries’d have the number indicated, then the system should automatically group them under one “Group”
Several use cases/requirements have to be confirmed with Andrea and other WB Team members to be sure that we skip addressing them in the first MVP and postpone to the MVP2
create a list of what was changed in UI and then we’ll clarify what has to be changable, ideally with the description what how it was changed @Damian Borowiecki@Artur Lebiedziński
create a diagram to sum up how to modules cooperate with each other in business matter @Patrick Delcroix