Upload of Beneficiaries Data

Current Approach

Current approach for data upload will be replaced with individual upload described in the next section.

We’ll most likely have to wrap up this transition before release as the requirements for the February Release states that we should cover enrollment requirements for programmes.

Following enrollment requirements are currently not available:

Note: Editing should not be retroactive, especially if it creates inconsistencies with historical records

Note 2: These two requirements were not discussed during the Workshops, and should be double checked.

New Approach

In the new approach data will be uploaded directly to the benefit program but into the individual table and then then relevant individuals will be added to the program using simplified targeting option.

This will require adding a global schema for individuals that are uploaded and changing the benefit plan view that will forbid data from the upload.

[Note: This point is not essential for the flow to be MVP as we could start from uploading the data to the beneficiary. However in the longer term it’s required and may cause issues with backwards compatibility if implementations would use March release and it’s recommended to introduce this change.]

Simplified flowchart

Payroll creation

Payroll creation will have to be alternated. Currently in order to create payrolls user have to create payment cycle first and then add the invoices to the payroll. In the new approach payroll will be independent from payroll because we need to be able to have more flexibility with the cycles and store data about the invoice details during the payroll creation (e.g. if individuals data has changed after payroll creation it will not be reflected in payroll invoice).

Therefore Payroll will have to be changed in following way:

1. Generation of payroll will be based on the Benefit Plan, Payment Plan and advanced filters.

2. Payroll will have Payment cycle attached to it during creation (this will be addressed latter on under payment cycle creation).

3. Data in invoices for payroll will not be changed.

4. Selected data for payroll:

   1. Benefit Plan,

   2. Payment Plan,

   3. Payment Cycle,

   4. Payment Point

5. Payroll creation will go through maker-checker logic.

As the Payment Reconciliation and Evidence upload will require some rework we should introduce new entity called benefit consumption in order to keep track of the payroll content. It will also be beneficial latter on for the goods distribution. While this use case will not be covered in scope of this work it’s advised to structure the benefit consumption in a way which allow seamless transformation latter on.

Tip: Generation implemented in the payment cycle should be incorporated in this as it shared a lot of functionality.

Note: Payment points will require rework as well. The strategy shouldn’t be added manually for whole payment point but rather determine programmatically based on the schema.

Payment Cycle Creation

Payment cycle creation has to be reworked. Currently it’s generating invoices and that’s not desired behavior. Payment cycle has to be changed and serve as an aggregation for payrolls. Now when Payment Cycle is created then we should be able to view the payrolls that were generated for given payment cycle under the payment cycle detailed view. Also date from and date to should be added and don’t have specified periodicity as months or weeks but be put by users.

Payment Generation (CSV Version)

Currently we have payment reconciliation based on the API pipeline based on the Lightning workflow. This approach is not straightforward when it comes to testing and we have to implement the base CSV upload version.

Payment upload process also have to be improved. Currently we don’t have a possibility to store the evidence of the distribution. This should be attached to the benefit consumption mentioned in previous point. The evidence should come with following fields: photo, individual full name, amount, receipt, date.

During the upload user have to provide the csv file with standard format that would have information about the consumption in scope of the payroll. It has to come with:

• identifier of the benefit consumption (could be invoice ID or code)

• receipt

• amount

• code

If the file has any issues error with validation details should be provided to the user (That’s MVP version, in the final version we should keep the change log similar to one used for the beneficiary import).

After the data is uploaded payroll manager can decide if payment is legit and change it’s status otherwise (e.g. potential duplicate, or incorrect confirmation). This action doesn’t require the maker-checker logic.

Payroll in that form can be approved or rejected.

• If it’s approved then invoices are generated.

• If it’s rejected then [Clarification needed]

Action of approving or rejecting of the payroll goes through the maker checker logic.

Upon approval the payroll is reconciled.

Reconciled payroll cannot be edited.

Data Model For Benefit Consumption:

1. Individual Reference

2. Photo

3. Code

4. Date

5. Receipt (string)

6. Amount

7. Type (string)

8. UUID

9. Status (ENUM - Accepted, Rejected, Duplicate)

10. M:N relation with invoice