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:
Create a database structure to save the account receivable
Save the different account receivable (contribution and funding)
Convert the different account receivable following that structure
Create a FHIR interface for the accounting systems
Create a database structure to save the account receivable
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 book 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.
outboundInvoices
field | type | comment |
HistoryBusinessModel fields | ||
subject | json | referenceActor {
"label":"",
"code":"",
"type": "batchRun/commissionOverview/capitationReport",
"id":"UUID",
"address":{"text":"",...}
}
|
recipient | json | 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 such as payment systems |
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 | 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 |
inboundInvoiceLineItems
to docuement the content fo the inboundInvoice
field | type | comment |
code | str | reference |
HistoryModel fields | ||
inboundInvoiceId | UUID | reference to inboundInvoice |
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 | tax details {
"lines": [
{"label":"", "rate":"", "base":"", "amount":""}]
…
],
"total":""
}
|
amount_total | float | net +tax |
amount_net | qty * unitprice - discount |
inboundInvoicePayments
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 inboundInvoicePayments, once the reconciliation between the different invoice will be done.
field | type | comment |
HistoryModel fields |
| |
Status | int | Accepted / Rejected |
code_ext | str | payment reference |
label | str | label of the payment |
code_rcp | str | Reference from the payment system / bank |
inboundInvoiceId | UUID | reference to inboundInvoice |
code_reciept | str | reciept number |
amount_payed | float | Amount that need to be matched against business items (fees might be added if there were removed before reaching the system) |
fees | float | |
amount_recieved | float | Amount that is received (may include or not the fees) |
date_payment | date |
inboundInvoiceEvents
this table will log the event relating to the invoice
field | type | comment |
HistoryModel fields |
| |
inboundInvoiceId | UUID | reference to inboundInvoice |
type | int | Message / Status / Warning / Payment / Payment error |
data | json | Payload linked to type (TODO) |
inboundInvoicedocuments (???)
Save the different account receivable
Convert the different account receivable following the new structure
Create a FHIR interface for the accounting systems
Here the FHIR ressource to be used:
https://www.hl7.org/fhir/invoice.html
Front end
Search page
search criteria
search result
card page
general information
detials
Account receivable, using the same structure as account receivable, when associated to the contract might also replace the “contribution/premium“