This page documents the change that will be performed in the scope of the payment layer project to make openIMIS ready for interfacing with an payment and accounting system

Glossary:

Account receivable : JLN term JLN Process - Accounts receivable

Account payable: JLN term Accounts payable 

outbound invoice, aka invoice: invoice that openIMIS send to some other third parties

inbound invoice, aka bill: invoice that openIMIS recieves from some other third parties

outbound payment, aka bill payment: payment that openIMIS send to some other third parties Payment to providers

inbound payment aka invoice payment: payment that openIMIS recieves from some other third parties like Premium collection and Funding

Models:

The concept is to use a widely use format as base. inspiration can form FHIR invoice and SAGE API Invoices. openIMIS is not an accounting system therefore generating books and ledger is not in the project scope but invoice are a good representation for the account receivable mentioned above. To bring flexibility, a JSON fields was added to the invoice line in case a structured details is required.

The link with the Source and actor won’t be in a form a database foreign keys because those could be from different table.

invoices

(editable if not payed or validated)

  contribution/contract/funding --> Drop down

Insuree/PH/payer/User --> Drop down

(calculated be)
tax details {
  "lines": [
    {"code":"", "label":"", "rate":"", "base":"", "amount":""}]
    …
  ],
  "total":""
}

invoiceLineItems

to document the content for the Invoice (editable if invoice not payed or validated)

calculated be with rules, show only after saving, not displayed during line update,  hid old value
tax details {
  "lines": [
    {"code":"", "label":"", "rate":"", "base":"", "amount":""}]
    …
  ],
  "total":""
}

InvoicePayments

(editable if invoice not in status payed)

To document the payment done on the invoice. out of scope: a payment done for 2 invoice, to support such scenario an “generalPayment“ table need to be created, this table will have sub table with relationships to invoicePayments, once the reconciliation between the different invoice will be done.

invoiceEvents

Read only for all but can add new message

this table will log the event relating to the invoice

Nice to have : addup (only on graphQL querries) mutation logs/history in the event

[out of scope] invoicedocuments

This should be managed by a document management module

Integration points:

Services

• invoicePaymentRefRecieved (payment_reference)

• invoiceEventPaymentRejected (msg) msg to event

• invoicePaymentRecieved(msg, InvoicePayments) → can update the status to payed (also include rejected payment), only last amendment can be payed

• invoicePaymentRefunded(InvoicePayments)→ can update the status to suspended (warning the busienss service to be update via signal)

• invoicePaymentCanceled(InvoicePayments)

• invoiceCreate (called on save)

• invoiceUpdate (called on save)

• invoiceDelete

• invoiceTaxCalculation() calculate tax details by merging the result of invoiceItemTaxCalculation

• invoiceItemCreate

• invoiceItemUpdate

• invoiceItemDelete

• invoiceItemTaxCalculation calculate tax details base on the tax_rate rule

• nice-to-have invoiceAmend → create new empty invoice and put current idea in “related_invoice“ and set status to amended

• invoiceValidateItems → check that we have a business item attached to the invoice are in the right status/ right price: just send a signal, handle by calculation rule, add event if issues

• invoiceMatchItems → check that we have a business item attached to the invoice (check if the subject_type / id is not empty and point to a valid database object, check line_id/type if no subject_id)

• (not attached to the object)invoiceCreationFromCalculation (will send a signal)

invoice Payment specific modules (Calculation rules)

those calculation rules modules structure

• models: none

• services: 1 per signal listened

• converters: one converter from another openIMIS object to invoice

• parameters: on for the “recipient” and “subject“ on the invoice

  • change might be required in the calculation module to save it in dedicated fields instead of json_ext OR we move those in the json ext fields

  • support search on those parameters

Listening to other modules signal are strikethrough because during the migration not all update will happens through modular therefore such trigger will complexity the invoice creation processes

Contribution plan calculation rule: Product modeling

Contract:

the invoice of a contract will match the contract value and details.

Registration on signals from other module(existing or not)

• contractApproved

• invoiceCreationFromCalculation

Converters:

Invoice

referenceSource {
  "label":contract-label
  "code":contract-code,
  "type": "Contract",
  "id":"UUID",
}

referenceActor {
  "label":ph-name,
  "code":ph-code,
  "type": "Policyholder",
  "id":"UUID",
  "address":{"text":"",...}
}

null

invoiceItem

null

[out of scope]Claim Co-paiment:

Registration on signals from other module(existing or not)

• claimSubmitted

• invoiceCreationFromCalculation

Converters:

[out of scope] - (Product payment module)Funding:

Registration on signals from other module(existing or not)

• Funding created / updated

• Contribution created / updated (for Funding families)

• invoiceCreationFromCalculation

converters:

new funding:

Too soon the new funding structure is not defined

funding contribution (legacy)

see contribution converter in Bill

[out of scope] new  signals are use to trigger action in another module:

• [one signal per service]

• invoiceValidated (all invoiceItemMatched and invoiceItemAmountValidated)

• invoiceFullyPaid

• invoicePaymentRefRequested

Create a FHIR interface for the accounting systems (change FHIR_R4 ?)

Here the FHIR ressource to be used:

https://www.hl7.org/fhir/invoice.html

Acceptance criteria:

1. Insurance clerk generates informal sector insurance invoice per head of family for a given time period

2. Insurance clerk generates formal sector insurance invoice per Policyholder for a given time period

3. Insurance clerk display the invoice with details

4. Insurance clerk add a payment on the invoice

5. Insurance clerk print the invoice

6. Insurance clerk delete an invoice (this won’t delete the generating Item)

7. [should have] access invoice via FHIR invoice resource. (read only)

out of scope

1. Insurance clerk generates a funding invoice (new) for a product/pool

2. Insurance clerk generates a funding invoice (old) for a product/pool

3. Policy activated based on invoice payment

Front end

The front end will have the same layout as the contract

Search page

search criteria

• type for invoice

• recipients (NTH: Ideally contribution from the specific payment module based on type)

• code

• date_invoice

• amount_total

• status

search result

• type for invoice

• recipients (NTH: display only the recipient attached )

• code

• date_invoice

• amount_total

• status

No add new button , All invoice MUST be generated using specific payment module

3 dots menu to generate invoice: show date from/date To

it will call invoiceCreationFromCalculation service

card page

general information

All schema fields but UUID

if not payed:

• Delete button

if payed show no button

tabs

invoiceLines

read only, All invoice MUST be generated using specific payment module

search filters on All schema fields but UUID

colunm to show All schema fields but UUID

invoicePayment

search filters on All schema fields but UUID

• Add Payment button near the search (see add contract insuree)

colunm to show All schema fields but UUID

• on each line:

  • delete payment

  • edit payment (modal popup), all fields but UUID can be modified

invoiceEvent

search filters on All schema fields but UUID , icontain for message

• Add Comment button near the search (see add contract insuree) modal popup with a text field

must: message readonly once created: nice-to-have: user can change only his own message

colunm to show All schema fields but UUID