Versions Compared

Key

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

...

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.

The link with the Source and actor won’t be in a form a database foreign keys because those could be from different table.

bills

...

field

...

type

...

comment

...

HistoryBusinessModel fields

...

subject

...

json

...

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

...

 sender

...

json 

...

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

...

 code

...

 str 

...

or reference for the insurance

...

 code_sdr

...

 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“

...

 validFrom*

...

 date 

...

invoice covering service/item from

...

 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_sdr_code

...

 str 

...

currency of the recipient (if different)

...

 currency_code

...

 str 

...

currency of insurance

...

exchange_rate

...

decimal

...

 note

...

 bigttext 

...

 terms

...

 bigttext 

...

conditions

billLineItems

to document the content for the bill

...

field

...

type

...

comment

...

code

...

 str 

...

reference

...

HistoryModel fields

...

billId

...

UUID

...

reference to bill

...

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, useful 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

Note: Do we need unit of measurement ? or should it be in the description.

billPayments

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 billPayments, once the reconciliation between the different invoice will be done.

...

field

...

type

...

comment

...

HistoryModel fields

...

 

...

Status

...

int

...

Accepted / Rejected/Refunded/cancelled

...

code

...

code_ext

...

str

...

payment reference

...

label

...

str

...

label of the payment

...

code_sdr

...

str

...

Reference from the payment system / bank

...

billId

...

UUID

...

reference to bills

...

code_receipt

...

 str 

...

receipt 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

billEvents

this table will log the event relating to the invoice

...

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)

[out of scope]billdocuments

This should be managed by a document management module

See invoice model

Integration points:

Services

...

  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

Search page

search criteria

...