Average Consumption calculation - extension analysis

W.I.P.

Purpose

The purpose of this document is to draft the scenario, design and a plan for the implementation of the first, real extension point in the OpenLMIS v3. The JIRA ticket to implement this is OLMIS-2321 - Getting issue details... STATUS .

Scenario

The incidence rate for Malaria varies based on the season. Due to this, also the consumption of the anti-malaria drugs varies depending on the month. To have the system better predict the required amount of drugs required in facilities, OpenLMIS should be able to take into account that seasonality for the Malaria program and count the Average Consumption, based on the same month for the past few years (eg. March 2016, March 2015, March 2014), rather than just the few previous months (eg. March 2016, February 2016, January 2016). Only selected programs should make use of the adjusted average consumption calculation, based on seasonality. The remaining ones should use the default calculations provided by OpenLMIS.

To summarize, the following pieces need to be done:

•  Expose the ability to adjust the calculation used for average consumption
•  Expose the ability to select which programs use the adjusted calculation
•  Implement the adjusted calculation (extension module) and make it available to the community

Proposed Design

Currently all the calculations live in the LineItemFieldsCalculator class, that contains static methods - one for each field. The extension mechanism in OpenLMIS requires that every extendible piece is a Spring bean, therefore a refactor of the class, as well as its usage would be required. Each calculation would live in its own class and be an independent Spring bean. A single class that delegates the calls to get the calculations could exist and would be used by the consumers of the calculations.

 - figure out the way to use spring beans in the domain class (passing it from controller or retrieving from a static spring helper)

 - we need a way to pass the necessary data to UI (previous requisitions in DTO)

 - Malawi may not even need an extension point to change the calculations, perhaps just the retrieval of the previous requisitions can be changed (Sebastian Brudziński needs to confirm)

Another issue that needs to be resolved is allowing the user to specify which calculation is to be used for the column and store that choice. This can be achieved by adding the extraData field to the RequisitionTemplateColumn and have the implementation of the extension point check that field to determine which calculation should be used.

The user interface needs to be capable of two things: using the adjusted calculations where necessary and exposing the ability to select the calculation that will be used. The UI currently exposes the ability to override any file in the implementation distribution, therefore it is possible to achieve the desired state without any further modifications on the core OpenLMIS side, however a more refined mechanism for calculations and calculation selection may be considered.

Actions and timeline