this page is to document 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 payable
savethe different account payable
convert the different account payable following that structure
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
https://developer.sage.com/api/accounting/guides/invoicing/
outInvoice
...
field
...
type
...
comment
...
third_party
...
json
...
referenceActor {
“label“:””,
“code“:””,
“type”: “batchRun/commissionOverview/capitationReport“,
“id“:”UUID”,
“address“:{“text“:””,…}
}
...
source
...
json
...
referenceSource {
“label“:””,
“code“:””,
“type”: “HF/Insuree/PH/payer/user“,
“id“:”UUID”,
“address“:{“text“:””,…}
}
...
id
...
UUID
...
code
...
str
...
code_rcp
...
str
...
code_ext
...
str
...
date_due
...
date
...
date_invoice
...
date
...
date_from
...
type
...
date_to
...
date
...
date_payed
...
date
...
amount_discount
...
float
...
amount_net
...
float
...
tax_analysis
...
json
...
amount_total
...
float
...
status
...
int
...
currency_rcp_code
...
str
...
currency_code
...
str
...
note
...
bigttext
...
terms
...
bigttext
...
method(type)
...
type
...
method(type)
...
type
outInvoiceDetails
...
field
...
type
...
comment
...
code
...
str
...
description
...
str
...
details
...
json
...
ledger_account
...
int
...
quantity
...
float
...
unit_price
...
type
...
discount
...
float
...
tax_rate
...
Calculation uuid
...
tax_analisis
...
json
...
amount_total
...
float
Save the different account payable
Claim valuation (batchRun):https://openimis.atlassian.net/browse/OTC-10
Capitation payment: https://openimis.atlassian.net/browse/OTC-10
Commission payment
payment fees
Convert the different account payable following the new structure
Claim valuation (batchRun):
Capitation payment:
Commission payment
payment fees
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) | ||
|---|---|---|
|
[OUT OF SCOPE]Insuree cash transfet
converter
one accountPayable per insuree (for all dependant), one line per cash payment (level of Item and service)
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
Insurance clerk generates claim bill per health facility for a given time period
Insurance clerk generates commission bill per EO for a given time period
Insurance clerk generates capitation bill per HF for a given time period
Insurance clerk display the bill with details
Insurance clerk add a payment on the bill
Insurance clerk print the bill
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)