This page documents the change that will be performed in the scope of the Tanzanian payment layer project to make openIMIS ready for interfacing with an payment and 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
...
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 book 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.
...
to document the content for the Invoice
field | type | comment | |||||
HistoryBusinessModel fields | |||||||
code | str | referenceHistoryBusinessModel fields | |||||
invoiceId | UUID | reference to invoice | |||||
description | str | ||||||
details | json | depend of the type, TBD | |||||
ledger_account | int | from specific payment module | |||||
quantity | float | ||||||
unit_price | type | ||||||
discount | float | to document difference between the std price and the price to be paid, useful for relative pricing | |||||
tax_rate | Calculation uuid | Calculation to calculate the tax | |||||
tax_analysis | json |
| |||||
amount_total | float | net +tax | |||||
amount_net | qty * unitprice - discount |
...
field | type | comment |
HistoryModel fields |
| |
invoiceId | UUID | reference to invoice |
type | int | (Message / Status / Warning / Payment / Payment error) module configuation |
data | json | Payload linked to type (TODO) |
[
...
field
...
type
...
comment
...
HistoryModel fields
...
...
invoiceId
...
UUID
...
reference to invoice
...
type
...
int
...
(invoice, receipt, other)Module configuration
...
pathType
...
int
...
local/Hyperlink/other (sdb, s3, nfs… )
...
path
...
json
...
Payload linked to type (TODO)
...
out of scope] invoicedocuments
This should be managed by a document management module
Integration points:
Services
invoicePaymentRefRecieved
invoicePaymentRejected
invoicePaymentRecieved
invoicePaymentRefunded
invoiceCreate (called on save)
invoiceUpdate (called on save)
invoiceDelete
invoiceItemCreate
invoiceItemUpdate
invoiceItemDelete
invoiceAmend
invoiceValidateItems
invoiceMatchItems
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
Contribution:
the grouping will be done per Head of family, therefore such invoice will have only 1 detail.
Registration on signals from other module(existing or not):
contributionCreated
Converters
informal sector
1 invoice per policy, with 1 invoiceLineItem, dependants might be documented in the details invoiceItemLine
field | type | comment | |||||
HistoryBusinessModel fields | validFrom: Policy efective date validTo:Policy exiry date | ||||||
code | str | PRODUCT-code | |||||
description | str | PRODUCT-label | |||||
details | json | Dependant otherName, name, gender, age, relation to insuree | |||||
ledger_account | int | Product premium accounting code | |||||
quantity | float | 1 | |||||
unit_price | type | BASE Policy Value | |||||
discount | float | renewal discount … | |||||
tax_rate | Calculation uuid | null | |||||
tax_analysis | json |
| |||||
amount_total | float | net +tax | |||||
amount_net | qty * unitprice - discount |
Contract:
the invoice of a contract will match the contract value and details.
...
Add Comment button near the search (see add contract insuree) modal popup with a text field
colunm to show All schema fields but UUID
[Nice to have]InvoiceDocument
search filters on All schema fields but UUID
upload document button near the search (see add contract insuree)
add linked document button near the search (see add contract insuree)
colunm to show All schema fields but UUID
...