...
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
Fee-for-service
Registration on signals from other module(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]
two way of creating the accountPayable are possible for the valuation, in both case there will be one “accountPayable” per HF
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
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]
two way of creating the accountPayableare possible for the capitation, in both case there will be one “accountPayable” per HF
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;
Population living in catchments area of the health facility
Number of families living in catchments area of the health facility
Insured population living in catchments area of the health facility
Insured number of families living in catchments area of the health facility
Number of claims (contacts) with the health facility by insured in the catchment area
Adjusted amount
asset (line) per product with the detail of the calculation as asset description
Commission
Converters
one accountPayable per EO,
one asset (line) per product/commission, sum of policy value as quantity, commission as unit price, product account code as ledger account
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
one accountPayable per type of payment (TBC)
...
one asset (line) per product/commission, sum of policy value as quantity, Payment fees as unit price, product account code as ledger account
...
Filter by label (Content by label) | ||
---|---|---|
|
[OUT OF SCOPE]Insuree cash transfet
...
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
...
[
...
area: if not national, will take only the product define on the level selected or below
type: the type below could be checked
supplier payment method (notion not yet existing)
Claim valuation (fee for service - batchRun): https://openimis.atlassian.net/browse/OTC-10
Capitation payment: https://openimis.atlassian.net/browse/OTC-10
operation fee payment method (notion not yet existing)
Commission payment:
Payment fees
insuree Cash payment (doesn’t exist yet)
an account payable param report will be generated for each of the bellow Item when required by the payment method
Product / payment period for “supplier payment method”
actor / payment period for “operation fee payment method”
insuree for the insuree payment period
[out of scope]new signals are use to trigger action in another module:
...
Account receivable, using the same structure as Account payable, when associated to the contract might also replace the “contribution/premium“
...
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)