Versions Compared

Old Version 14

changes.mady.by.user Patrick Delcroix

Saved on

compared with

New Version 15

changes.mady.by.user Patrick Delcroix

Saved on

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

...

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 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.

...

field

type

comment

HistoryBusinessModel fields

subject

json

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

 sender

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 such as payment systems
 date_due
 date 
date on which the payment is due
 date_invoice
 date 
Date of the “invoice“
 date_from validFrom*
 date 
invoice covering service/item from
 date_to validTo*
 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 (module configuration): 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
...
field
type
comment
HistoryModel fields
 
billId
UUID
reference to bills
type
int
Message / Status / Warning / Payment / Payment error
data
 json
Payload linked to type (TODO)
[
...
field
...
type
...
comment
...
HistoryModel fields
...
 
...
 
...
billId
...
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)
Services: Save the different account payable
Ideally the “batchrun“ would be rename “close accounts payable”, closing account will be on a defined scope:
  1. area: if not national, will take only the product define on the level selected or below
  2. type: the type below could be checked
    1. supplier payment method (notion not yet existing)
      1. Claim valuation (fee for service - batchRun): https://openimis.atlassian.net/browse/OTC-10
      2.  Capitation payment: https://openimis.atlassian.net/browse/OTC-10 
    2. operation fee payment method (notion not yet existing)
      1. Commission payment: 
      2.  Payment fees
    3. insuree Cash payment (doesn’t exist yet)
  3. an account payable param report will be generated for each of the bellow Item when required by the payment method
    1. Product / payment period for “supplier payment method” 
    2. actor / payment period for “operation fee payment method”
    3. insuree for the insuree payment period
...
out of scope]billdocuments
This should be managed by a document management module
Integration points:
Services
o billPaymentSent
o billPaymentRejected
...
o billValidateItems
o billMatchItems
bill 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 
Fee-for-service
Registration on signals from other module
...
o claimValuated
new signals are use to trigger action in another module:
o [one signal per service]
o billValidated (all billItemMatched and billItemAmountValidated)
o billFullyPaid
Converters: Convert the different account payable following the new structure
Claim valuation (batchRun):
(existing or not):
  • billCreationFromCalculation
Only the “valuated“ claims are eligible for bill generation meaning that the batch run might be triggered before in case .
[nice to have]Ideally the “batchrun“ would be rename “close accounts payable”, closing account will be on a defined scope and be available from the thee dots menue
billCreationFromCalculation will have a variable that will tell the signal listener to be activated or not: this will be activated for “fee-for-service“
Converter
[to be updated]
  1. two way of creating the accountPayable are possible for the valuation, in both case there will be one “accountPayable” per HF
    1. One asset (line) per claim, claim details as asset description: claimed amount as unit price, net amount as net price, discount calculated based on net and unit price
    2. one asset (line) per item or service with claim detail as asset description: item/service claimed unit price as unit price, net as valuated price, quantity as quantity, discount calculated based on net and unit price
Capitation
...
Registration on signals from other module(existing or not):
  • billCreationFromCalculation
Batch run might be required upfront to have the relative indexes calculated / all claim valuated where there is relative prices.
billCreationFromCalculation will have a variable that will tell the signal listener to be activated or not: this will be activated for “capitation“
Converter
[to be updated]
  1. two way of creating the accountPayableare possible for the 
     valuation
    capitation, in both case there will be one “accountPayable” per HF
    1.  one asset (line) per weighted indicator I for product P : Allocated contribution/ Sum(indicator for P) as unit price , indicator I as quantity, (1-weight) as discount;
      1. Population living in catchments area of the health facility 
      2. Number of families living in catchments area of the health facility 
      3. Insured population living in catchments area of the health facility 
      4. Insured number of families living in catchments area of the health facility
      5. Number of claims (contacts) with the health facility by insured in the catchment area 
      6. Adjusted amount
    2. asset (line) per product with the detail of the calculation as asset description
Commission
...
Converters
  1. one accountPayable per EO, 
    1. one asset (line) per product/commission, sum of policy value as quantity, commission as unit price, product account code as ledger account
    2. one asset (line) per policy : policy value as quantity, commission as unit price, product account code as ledger account (dependent detail as asset description)
Payment fees
Converter
  1. one accountPayable per type of payment (TBC)
    1. one asset (line) per product/commission, sum of policy value as quantity, Payment fees as unit price, product account code as ledger account
    2. one asset (line) per policy : policy value as quantity, Payment fees as unit price, product account code as ledger account (dependent detail as asset description)
    insuree Cash payment (doesn’t exist yet) 
[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
Approach
[to be updated]
  1. area: if not national, will take only the product define on the level selected or below
  2. type: the type below could be checked
    1. supplier payment method (notion not yet existing)
      1. Claim valuation (fee for service - batchRun): https://openimis.atlassian.net/browse/OTC-10
      2.  Capitation payment: https://openimis.atlassian.net/browse/OTC-10 
    2. operation fee payment method (notion not yet existing)
      1. Commission payment: 
      2.  Payment fees
    3. insuree Cash payment (doesn’t exist yet)
  3. an account payable param report will be generated for each of the bellow Item when required by the payment method
    1. Product / payment period for “supplier payment method” 
    2. actor / payment period for “operation fee payment method”
    3. insuree for the insuree payment period
[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
...