...

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 here uses a Calculation Rule (the Calculation Rules are defined in additional openIMIS modules extending the Calculation Module). This module is defining a framework to design calculations and to manage their activation and versioning in openIMIS. This solution will deliver a Calculation Module that takes the income (on the level of the Contract’s insuree) and a rate (on the level of the Contribution Plan) as parameters, make the calculation and updates the payment value of the Contract’s insuree.

This module will have two way of working, either listening to event or/and proactively checking for calculation; the later approach is to improve performance when at least one calculation rule is expected (no additional database access, no concurent access to database …)
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 or plug additional calculation to existing process.

Business process

This module will use a "generic contribution" to get the required parameters and the json_ext database field will be used to save the parameters (generic backend feature). Finally, a signal will trigger the calculation action. 

Solution

This module will rely heavily on the django signals

In order to have a generic approach that will make the code more readable, one argument will be expected in the signal, this argument will be called obj and should contain the instance of the class sending his signal:

my_signal= dispatch.Signal(providing_args=["obj"])

Use cases

UC14-1: add a new Calculation rule (needs to change the openimis.json).
UC14-2: use the frontend contribution to select a calculation rule.
UC14-3: use the fronend contribution to display the parameters required by multiple calculation for an object.
UC14-4: replace a calculation rule.
UC14-5: remove a calculation rule.

...

The backend 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

runCalculation(object obj, string context, bool stopAtFirst)

This function will be used to look for a suitable calculation for the object provided,

this function will look in all active calculation (highest priority first) to check if the object is part of a “main class“ (See member objects). if the object is from a “main class“ then it will execute the activeForObject(obj, context) to see if the calculation concerns this instance.

In case the stopAtFirst is “true” then once a calculation is valid for the object instance then it will stop looking for other calcualtionsA Custom signal class be created to add a priority of calculation

from django.dispatch import Signal as BaseSignal
from django.dispatch.dispatcher import _make_id


class Signal(BaseSignal):

    def connect(self, receiver, sender=None, weak=True, dispatch_uid=None, priority=50):
        if dispatch_uid is None:
            dispatch_uid = _make_id(receiver)

        inner_uid = '{0}{1}'.format(priority, dispatch_uid)
        super(Signal, self).connect(receiver, sender=sender, weak=weak, dispatch_uid=inner_uid)
        self.receivers.sort()

Source of the sub Signal class: https://stackoverflow.com/questions/10017567/possible-to-change-order-of-django-signals

absCalculationRule 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)

...