Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

This page documents the change that will be performed in the scope of the Tanzanian project to make openIMIS ready for interfacing with an accounting system. This work will be divided in several steps:

  1. Create a database structure to save the account payable

  2. Save the different account payable

  3. Convert the different account payable following that structure

  4. Create a FHIR interface for the accounting systems

Create a database structure to save the account payable

The concept is to use a widely use format as base. We chose SAGE API Invoices. openIMIS is not an accounting system therefore generating book and ledger is not in the project scope but invoice are a good representation for the payable 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.

outInvoice

...

field

...

type

...

comment

...

source

...

json

...

Code Block
languagejson
referenceActor {
  "label":"",
  "code":"",
  "type": "batchRun/commissionOverview/capitationReport",
  "id":"UUID",
  "address":{"text":"",...}
}

...

 third_party

...

json 

...

Code Block
languagejson
referenceSource {
  "label":"",
  "code":"",
  "type": "HF/Insuree/PH/payer/user",
  "id":"UUID",
  "address":{"text":"",...}
}

...

 id

...

 UUID

...

 code

...

 str 

...

or reference for the insurance

...

 code_rcp

...

 str 

...

or reference for the recipient

...

 code_ext

...

 str 

...

if required for external system integration

...

 date_due

...

 date 

...

date on which the payment is due

...

 date_invoice

...

 date 

...

Date of the “invoice“

...

 date_from

...

 date 

...

invoice covering service/item from

...

 date_to

...

 date 

...

invoice covering service/item to

...

 date_payed

...

 date 

...

Date on which the payment was actually documented as Done

...

 amount_discount

...

 float 

...

total of the detail discount

...

 amount_net

...

 float 

...

Total without tax

...

 tax_analysis

...

 json 

...

Code Block
languagejson
tax details {
  "lines": [
    {"label":"", "rate":"", "base":"", "amount":""}]
    …
  ],
  "total":""
}

...

 amount_total

...

 float 

...

total net + tax total

...

 status

...

 int 

...

ENUM: draft, validated, payed, cancelled, deleted

...

 currency_rcp_code

...

 str 

...

currency of the recipient (if different)

...

 currency_code

...

 str 

...

currency of insurance

...

 note

...

 bigttext 

...

 terms

...

 bigttext 

...

conditions

outInvoiceDetails 

...

field

...

type

...

comment

...

code

...

 str 

...

reference

...

invoiceId

...

UUID

...

reference to outInvoice

...

description

...

 str 

...

details

...

 json 

...

depend of the type, TBD

...

ledger_account

...

 int 

...

from config

...

quantity

...

 float 

...

unit_price

...

 type 

...

discount

...

 float 

...

to document difference between the std price and the price to be paid, usefull for relative pricing

...

 tax_rate

...

 Calculation uuid 

...

Calculation to calculate the tax

...

tax_analysis

...

json

...

Code Block
languagejson
tax details {
  "lines": [
    {"label":"", "rate":"", "base":"", "amount":""}]
    …
  ],
  "total":""
}

...

amount_total

...

float

...

net +tax

...

amount_net

...

qty * unitprice - discount

Save the different account payable

  1. Claim valuation (batchRun): https://openimis.atlassian.net/browse/OTC-10

  2. Capitation payment: https://openimis.atlassian.net/browse/OTC-10

  3. Commission payment

  4. Payment fees

  5. Fee-for-service

Convert the different account payable following the new structure

  1. Claim valuation (batchRun):​

  2. Capitation payment: ​

  3. Commission payment

  4. Payment fees

  5. Fee-for-service

Create a FHIR interface for the accounting systems

Here the FHIR ressource to be used:

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

...

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

See invoice model

change from invoice models

Subject type : Batch run (claim, contribution, fees) / claim / (out of scope) Right/ (out of scope) funding contribution /

third party type: HF, User, Payer(I don’t know where the document the payment platforms/ re-insurance), Insuree

Integration points:

Services

o billPaymentSent

o billPaymentRejected

o billPaymentRefunded

o billCreate (called on save)

o billUpdate (called on save)

o billDelete

o billItemCreate

o billItemUpdate

o billItemDelete

o billAmend

o billValidateItems

o billMatchItems

bill Payment specific modules (Calculation rules)

those calculation rules modules structure

  • models: none

  • services: 1 per signal listened

  • static values

    • type: operation fee, supplier payment, reimbursment

  • 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

Filter by label (Content by label)
cqllabel = "payment-layer-project" and ancestor = "3046277126"

[OUT OF SCOPE]Insuree cash transfet

converter

  1. one accountPayable per insuree (for all dependant), one line per cash payment (level of Item and service)

  2. one accountPayable per period, one line per cash payment claim

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

o [one signal per service]

o billValidated (all billItemMatched and billItemAmountValidated)

o billFullyPaid

Create a FHIR interface for the accounting systems

Here the FHIR ressource to be used:

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

Acceptance criteria

  1. Insurance clerk generates claim bill per health facility for a given time period

  2. Insurance clerk generates commission bill per EO for a given time period

  3. Insurance clerk generates capitation bill per HF for a given time period

  4. Insurance clerk display the bill with details

  5. Insurance clerk add a payment on the bill

  6. Insurance clerk print the bill

  7. Insurance clerk delete a bill (this won’t delete the generating Item)

Permissions

Invoice (also for invoice Item) Prefix will be 1561

  • Search → 156101

  • Create → 156102

  • Update → 156103

  • Delete → 156104

  • Amend (create amendment) → 156109

Invoice Payment prefix will be 1562

  • Search → 156201

  • Create → 156202

  • Update → 156203

  • Delete → 156204

  • Refund→ 156206

Invoice event Prefix will be 1563

  • Search → 156301

  • Create → 156302 (out of scope)

  • Update → 156303(out of scope)

  • Delete → 156304(out of scope)

  • CreateMessage → 156306

  • DeleteMyMessage → 156307

  • DeleteAllMessage → 156308

Front end

See invoice page

nice to have: Third party renamed as Sender

Account receivable, using the same structure as Account payable, when associated to the contract might also replace the “contribution/premium“

Note

the text below need to be cleaned because not relevant anymore

  • Either drop down as current screen

    • General Account Payable section

      • Select “Account payable”

      • Payment plan picker in the future data model

        • can be a static drop down list for the old model: Valuation / Capitation / Commission fees / payment fees + Product picker

        • Or calculation for payment plan using the product configuration could be created, then payment plan could be created for each products

      • two datetime entries: DateFrom/DateTo

      • Location picker

    • Export Account Payable section

      • Payment plan picker in the future data model

        • can be a static drop down list for the old model: Valuation / Capitation / Commission fees / payment fees + Product picker

        • Or calculation for payment plan using the product configuration could be created, then payment plan could be created for each products

      • two datetime entries: DateFrom/DateTo

      • Location picker

      • group by: Product or third party

      • third party: user(EnrolmentOffice)/HF/”insuree”

    • section “payment plan calculated” that will display all “Account Payable generated” with there input detail in 1 column, working var in a second and the result in the third (relative index)