Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Concepts

The rules for the Formal Sector can be complex and evolving. Therefore, the "Formal Sector" solution should bring flexibility to avoid complete redesign and databases change when a parameter to define the contribution value is changed.
To bring that flexibility, the solution described in that document use a "calculation module". This module will create a framework to design calculations and to manage their activation and version on openIMIS. The calculation rule themselves will be in the form of other modules, dependent on the "Calculation" module. This solution will deliver a calculation module that takes the income (on the level of the contribution collection details) and a rate (on the level of the contribution plan) as parameters.
The value of the parameters will be saved as a JSON string in the json_ext field.
Later, this module could be used as a framework to create event-based actions

Business process

This module will use a "generic contribution" to get the required parameters and the ExtJson database field will be used to save the parameters (generic backend feature) finally a signal will trigger the calculation/actions. 

Use cases

Back-end

UC14-1: add a new calculation (needs to change the openimis.json).
UC14-2: use the front end contribution to select a calculation.
UC14-3: use the fron end contribution to display the parameters required by multiple calculation for on object.
UC14-4: replace a calculation,
UC14-5: remove a calculation,

Authorities

This module won't have ad-hoc authorities.

Entities

CalculationRules

  • UUID (char(24) )
  • CalculationClassName(varchar)
  • Status (int)
  • Description (varchar)
  • Version (int)
  • Json_ext (json)
  • DateCreated(date)
  • DateUpdate(date)
  • UserUpdateUUID(fk users)
  • UserCreateUUID (fk users)
  • DateValidFrom (date)
  • DateValidTo (date)

sub table CalculationRulesDetails

  • UUID (char(24) )
  • CalculationRulesUUID (varchar)
  • Status (int)
  • ClassName
  • Main (bool)
  • Params (Json)
  • ClassParams(json)
    • Type
    • rights
    • Relevance
    • conditions
  • Json_ext (json)
  • DateCreated(date)
  • DateUpdate(date)
  • UserUpdateUUID(fk users)
  • UserCreateUUID (fk users)


Details design


Back end

Backend management code:

The back end management code will be used to register the calculation sub-module parameters, the sub-module status and the ReadUpdate right management on the database.
This code should have a function to clean the table from the remove calculation
This code should manage the uniqueness of the active version for a given UUID

absCalculation class

The calculation module will be composed of an abstract class "absCalculation" that will have those methods and members.
This class should be imported as a module in the subclass definition (inside the "hat" modules)

Members

static version
The version is used to keep track of the changes in the version of the calculation rule,
status
integer inactive, future, active, archived
static UUID
UUID to follow the version of the calculation

static CalculationClassName

short name of the calculation rule

static description

description text of the calculation

list of impacted class and parameters

<list>JSONObject objects {class:"className", main:True/False ,'parameters':['type':"int",'name':"example",'rights':{'read':"readAuthority", 'write':"writeAuthority"},relevance:"frontendjsdisplaylogic",condition:"frontendjsvalidationlogic"]} // list of the parameters required on other object,

Methods

ready()

This method makes sure the calculation is registered in the calculation table (if not the line should be added with "inactive status") and register the signals only if it is active

calculateEvent(sender, **kwargs)

This method runs the calculation based on the object sending the signal, this means that the relationship with the other item required for the calculation could be found from the object sending the signal. (e.g., link to the product can be found in the policy as foreign key.)
This function should call the calculate(*args) function
Signal need to be set up on the ready function to call it

calculateUUID(*UUID)

Function that fetches the args from the UUID [order specific ?] then run the calculate(*args) function.

calculate(*args)

Function that will do the calculation based on the parameters

getParamteres(ClassName)

Return the data contained on the JSON so the frontend can ask the parameters for a new object of the ClassName.

frontend

Calculation management page

This page will show the calculation page and change the status/activate a given version
This page should group the calculation by UUID

Contributions

Standard contributions should be available for most of the entities (claims, contribution, contribution collection, policies, insuree ....)
Those contributions should get the parameters template from the backend and display the relevant ones. The values should be saved in the JsonExt fields

  • No labels