Main workshop: 2023-05-08 - 2023-05-12 openIMIS/CORE-MIS Developers Workshop

Benefits, Payment Calculation Rules, Conditionalities, Reconciliation

In CoreMIS calculation of payments are mostly made outside of the system.

It could be done by thirdparty or government (payment could be done). List of beneficiary to print that need to be delivered to each beneficiary - pdf that could be customized (proof of payment). Such list could be export as 'excel' file.

The coreMIS has android app for payment. Mobile app accessible by authorized user. App is simply PPM. Responsible for delivering payments. Photo taken, parallel GPS coordinates are taken and timestamp. Synchronization with the system through API and we have payment reconciliation.

Three modes of payment reconciliation:

• API integration (ePayment) - PaymentReconciliation - (Reconciliation with API)

• Download and upload Reconciliation (csv)

• PPM (Payment Point Manager)

PPM could be a provider like T-Mobile/Orange etc. One payroll can generate a payroll for multiple payments. If you want to create payments for the rural payments (over the counter) and for the urban ones (that are ePayment) then you generate one type of payment.

Rules are created within program definition. And we can add some rules in coreMIS level also in 'new payment' modal.

Open

You can combine filters to select particular person that match to such kind of filtering.

There could be rules that could limits the number of payments.

Graduation

First case is to search manually for particular active person that no longer need . Second is the condition included in program.

PaymentHistory - for showing payments that are submitted. Payment could be overpaid/underpaid. There could be multiple payments for invoice etc. Payments could be reconciliation in a batch.

Reconciliation is the process to confirm that payment is for sure delivered or not. (before reconciliation we can only assume that payment is done or not). It could be done by bank, agency etc.

Manage PPM - for assigning PPM to grouping.

Open

Why grouping? For example there are a lot of financial institution. And this helps making order per Payment Point Manager.

PPM - is this a organization or physical person? Yes. Both.

Approval stage - here the filter is ‘deleted’ and invoices are created ?? Amount is 'fixed’ at this point.

CoreMIS - it is possible to define the rule of taxes/additional fees (fixed amount - means that the same value for everyone included in payroll, another way (variable amount) is to have variable amount based on specific characteristics). It is called currently 'rebate'. Here we can specify the rules for variable amount/fixed amount. We can define also the maximum amount (for example we have household with 10 or more children and such household receive probably the maximum amount).

Payment Process in coreMIS:

How payments are managed and acknowledged on coreMIS level?

Schedule payment linked to the enrollment batch (periodically). Creating default payment event etc.

Payment cycles:

Some characteristics related to payments could be reused etc because they are repeatable. Tag payments into cycle and use default parameters into such payments. It is flexible when it comes to the defining characteristics. Looking into the who is active in that period.

we can define while creating Payment Cycle:

• the name of such cycle which identifies such cycle

• amount per beneficiary

• max amount per payment point

• payment rebate from select input

• start and end dates

Cycle could be suspended. Payment cycle after activating are applied to the payroll.

When it comes to the accounting part - accounting software is not always used - mostly excel is used even encouraging to use special dedicated software.

openIMIS side:

It needs to be added some additional features to support the coreMIS way of payments. There could be changes in Contribution aspects. Payroll with all beneficiaries in particular group could be supported by the openIMIS line items.

Invoices in core-MIS are related to the openIMIS Bills when it comes to the terminology and the business logic. Invoices/Bills are created automatically through calculation rules in ‘conversion' context (amount could be either calculated in 'calculate' context or fixed based on specific properties from objects that are converted into specific invoice/bill).

Invoices/Bills consists of three additional related entities:

• Line items

• payments

• events

There could be more than one line items, payments and events.

PaymentPlan is responsible for creating invoices/bill by triggering special calculation rule for specific subject which is related to the chosen openIMIS product. It is shown how such transformation into Bill works based on calculation rule called 'Unconditional Cash Payment'. More information about calculation module designs and payment plan and another aspects related to Payment Layer part:

• Project: 2021.T3 Payment Layer

• Invoices (and bills)

• Payment plan

• Calculations Module

• Calculation rules

• http://fhir.openimis.org/StructureDefinition-openimis-payment-notice.html

• http://fhir.openimis.org/StructureDefinition-openimis-invoice-invoice.html

• http://fhir.openimis.org/StructureDefinition-openimis-invoice-bill.html

On openIMIS side we have also flexibility when it comes to the defining some additional validations in order to verify some payments aspects (could be checking the line items amount in comparison with real payment, could be checking phone number whether is correct or not). If something is wrong with the Payment the exception is raised and there is note in database in Bill/Invoice Events entity.

Grievance Redress Mechanism

Idea of functionality - Collecting feedback from individuals (not only beneficiary) and base some actions based on particular grievances.

Complains could be anonymous or they can be associates with individuals in the registry.

It is possible to respond to the specific grievance

We can see in detail case the response and case details. We could resolve such case on the frontend coreMIS level.

Grievance has the separate dedicated report page on core-MIS side.

We could see grievances on beneficiary and household levels.

Currently core openIMIS implementation doesn’t contain such kind of module but it could be possible to reuse Gambian module that is similar to Grievance (but it could be tricky when it comes to the code quality of such module. Module is developed by 2MCorp company from Gambia).

There is no assigned user to consider/add the grievance. The role of grievance added through role management.

Death marking in both systems:

openIMIS - no. core-MIS - through suspension particular beneficiary (one of the reason of suspension). There is no flag for such case on coreMIS.

Are there any prioritization of considering grievances (the queue of considering grievances)?

• yes. Outside of the system is possible to set the prioritization

Design to align core-MIS UI:

• if it is not complicated we should also do this.

Mapping of terms between openIMIS and core-MIS:

Module mapping

Tentative Prioritization