2023-08-01 Developers Deep Dive - CORE-MIS

Owned by Dominika Bieńkowska (Deactivated)
Last updated: Aug 01, 2023 by Uwe Wahser

 

Overview

Date: 2023-07-25

Objective: Plan payment method integration

Participants:

@Dominika Bieńkowska (Deactivated)

@Wojciech Zgliniecki
Damian
Seweryn
Kamil
@Jan Dołkowski
Oliver
Piotr

@Uwe Wahser

Minutes

  1. GIZ administrative things:

    1. we need access / downloads of the CORE-MIS sources to have our legal support analyse dependecies for OS licenses incompabilities

  2. Validation of flows for on site and digital payments.

    1. payroll as way of aggregation of bills/invoices

      1. Unsettled invoices. How should be handled?

        1. Invoices that don’t have proof of payment should be treated as not payed.

      2. Should we allow maker-checker logic for Payroll part

        1. Reconciliation should have maker-checker logic

    2. Roles and responsibilities for the system

    3. Hook that would confirm if institution has enough balance to create payment.

    4. Photos as a proof of payment.

  3. Mojaloop Adaptor

    1. Is there any documentation of usage of Mojaloop in openIMIS?

      1. https://openimis.atlassian.net/wiki/spaces/OP/pages/3316219905

      2. Need to get in touch with 2m-corp. They were responsible for implementation.

      3. If no there are two alternatives:

        1. Creating a basic dummy server that would accept payments and having an adaptor as a proof of concept

        2. Create and adaptor for actual payment system that is connected to production instance of coreMIS

      4. What option to choose?

        1. First contact 2m-corp.

Action items

  •  

Additional resources

On-site payments flow

Flow

  1. Invoice Generation: An invoice is generated in the system.

  2. Payroll Assignment: Each invoice is subsequently assigned to a specific payroll for processing.

  3. Cash Disbursement Preparation: Upon preparing for disbursement, the system updates the status of the payroll to 'Ongoing'. Meanwhile, the funds for the payroll are readied for distribution.

  4. Payment Execution: The disbursement officer travels to the payment location and proceeds with the manual distribution of funds. Each transaction is carefully documented, likely through a mobile application, to ensure record accuracy.

  5. Upload Payment Proofs: The transaction records collected through the mobile application are uploaded to the system, associating them with their corresponding invoices. As a result, the status of those invoices is updated to 'Awaiting Reconciliation'.

  6. Payroll Reconciliation: Upon the completion of the disbursement process, the payroll in the system undergoes reconciliation. This phase involves freezing the payroll, ensuring no further changes can be made to the associated invoices.

Sequence Diagram:

@startuml participant "User" as A participant "System" as B participant "Disbursement Officer" as C participant "Mobile App" as D A -> B: Generate Payroll B -> B: Assign Invoice to Payroll B -> B: Update Payroll Status to 'Ongoing' note right of B: Disbursement Preparation C -> B: Travel to Payment Location and Distribute Funds C -> D: Document Transactions D -> B: Upload Transaction Records B -> B: Change Invoice Status to 'Awaiting Reconciliation' A -> B: Perform Payroll Reconciliation note right of B: Reconciliation Phase @enduml

 

Questions

  • Unsettled Invoices: For invoices that remain unsettled post-disbursement, the system could place these invoices back into a pool for assignment during the next payroll cycle, or handle them according to the specific protocols. What would be desired behavior?

  • Maker-Checker Logic: Should this process also allow maker/checker logic?

  • Role Responsibility: What are actors responsible for creating payroll, uploading data and confirming action?

Digital Payments Flow

Flow

  1. Invoice Generation: An invoice is generated.

  2. Payroll Assignment and Payment Method Selection: The invoices are assigned to a payroll, where the payment method is determined (e.g., mobile payment, bank transfer, or any digital method).

  3. Beneficiary Data Validation (Optional): Given different plans, beneficiary data may vary and it's not always the same. It would be good to have the ability to validate whether a given payment can already be made at this stage - for example, if there is a bank account assigned, etc.

  4. Payroll Approval: The payroll is approved by the responsible person, and then:

    • A request is sent to the external server for magic to happen for each invoice. Their status changes.

    • [Nice to have] Scheduler for later payment

  5. Payment Request Execution: A request is sent to the payment gateway, which performs operations related to actual transfers, etc.

  6. Recording Payment Gateway Response: The response from the payment gateway is recorded, and the payment status for the invoices changes. Note: This is an easier case than when we don’t have asynchronous and we get response right away.

  7. Payroll Reconciliation: Verify the payroll to ensure that all payments match with the invoices and the responses received from the payment gateway.

Sequence Diagram

@startuml participant "User" as A participant "System" as B participant "External Server" as C participant "Gateway" as D A -> B: Generate Payrol B -> B: Assign Invoices to Payroll and Set Payment Method B -> B: Validate Beneficiary Data (Optional) A -> B: Approve Payroll note right of B: Payroll Preparation B -> D: Execute Payment D -> B: Send Payment Response B -> B: Record Response and Update Payment Status note right of B: Payment Execution A -> B: Perform Payroll Reconciliation note right of B: Reconciliation Phase @enduml

 

Questions

Did you encounter a problem or do you have a suggestion?

Please contact our Service Desk


This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. https://creativecommons.org/licenses/by-sa/4.0/