This document summarizes the openIMIS features provided by the Contrinutions and Payments module.

• it naturally references the current openIMIS documentation (the Web application user guide)

• … and the openIMIS functional design specifications (2017, referring to TZ version)

• it provides some refinements deduced from legacy code readings

• it lists taken hypothesis (whenever ambiguity or incomplete description was encountered) and attention points for the migration to the new openIMIS architecture

The module features are, among others, used within the scope of Beneficiary Enrollment

Highlights of the database scheme:

Open

Questions:

• why “InsuranceNumber” field in PaymentDetail (matching is via Contribution, not insuree…)?

• in TZ, payment type “F” is related to funding (not contributions)… should we filter in this module (as we do filter the ‘funding’ --aka fake-- family)?

Business logic and data access layer

Main files in the legacy are:

• PremiumDAL & PremiumBL

• PaymentDAL & PaymentBL

Mostly CRUD logic, some easy validations, 3 calls to usp detailed below.

→ Will migrate “as-is”

Policy (status) update on contribution payment received

Once payment(s) is (are) received and cover the expected contribution(s) amount (and  the policy value), policy status changes and become either (based on tblIMISDefaults.ActivationOption ‘legacy’ parameter):

• Active (default)

• Ready 

Note: from the policy form/searcher, users also probably need to be able to ‘interactively’ switch from ‘Ready’ to ‘Active’ (missing mutation in policy module ?).

→ We’ll add into the policy module a listener on “savePayment” so that on payment save, if the payment match the contribution we’ll be able to update (if needed) the contribution status.

Logic in Stored Procedures

IN SCOPE as relative to contribution/payment and used

• uspAddFund in PremiumDAL

  • +/- 200 lines of PSQL

  • Check if given product is valid

  • Get Product's details

  • Check if the Family with CHFID 999999999 exists in given district

  • Check if funding District,Ward and Village exists

  • Insert Policy

  • Insert Insuree Policy

  • Insert Premium (Fund)

• uspLastDateForPayment in PremiumDAL

  • +/- 40 lines of PSQL

• uspMatchPayment in PaymentDAL

  • +/- 400 lines of PSQL

  • GET ALL UNMATCHED RECEIVED PAYMENTS

  • Validation

    • 1. Insurance number is missing on tblPaymentDetails

    • 2. Product code is missing on tblPaymentDetails

    • 2. Insurance number is missing in tblinsuree

    • 1. Policy/Prevous Policy not found

    • 3. Invalid Product

    • 4. Invalid Officer

    • 4. Invalid Officer/Product Match

    • 5. Premiums not available

  • DELETE ALL INVALID PAYMENTS

  • DISTRIBUTE PAYMENTS EVENLY

  • INSERT ONLY RENEWALS

  • Specific logic for SELF PAYER (stage R no office)  or  contribution without payment (Stage N status @ready with office)

Those are the only procedures in the scope. All others (concerning extracts and reports or standalone ones not used by the web servers) are going to be Out of scope.

Screens

We’re mostly following the existing structure with two divergences:

• We introduce dedicated screens for payments (absent in the current system), including creation and matching to contribution. This allows to have a full loop working using the interface (up to payment and matching to contribution, and as such possibly policy status update).

• We change the link from contribution list to contribution details, instead of the family one - this is very surprising when using. We’ll add a link toward the family screen to keep the current flow possible

List contributions

Open

As is - see: Find Contribution

Update: selecting a specific contribution will lead to contribution details (not to family screen as now). We’ll add a direct link to familiy (as exists already in other table) but it won’t be the “main” activity on click.

Contribution details

As is - see: Contribution Page

On screen validations

1. a) If the Contribution paid matches the price of the policy:

2. b) If the contribution paid is lower than the price of the policy:

3. c) If the contribution is higher than the price of the policy:

Payment list

New screen. Missing from existing screens, to add as an item below contribution. Same logic as other search/list screens.

Search based on

• Date

• Member

• Policy
  
  

Will include buttons to show/edit/add new payment - which is not possible in the legacy.

Payment can (but /must/ not) be linked to a specific contribution on creation - as part of the “edit” part or as a separated action “match to contribution”

Payment detail

Missing from existing screens.

Out of scope

• Capitation system

• Payers management

• Reports and extracts