View Source

Epic
Document status
Document owner	Mary Jo Kochendorfer (Deactivated)

Scope

The options in configuring the Requisition Template, which informs the columns and properties for the requisition form. The requisition form is what end users (storeroom mangers) view and edit in requesting additional stock. We call this the Requisition and Report (R&R) since information is both requested and gathered from the end user. The requisition template is configured by program. The features allow implementers to configure templates to meet the unique programmatic needs.

Implementers are able to:

Select from a robust list of columns to be included in the requisition form. For example, Beginning Balance, Received Quantity, Stock on Hand, Calculated order Quantity, Adjusted Consumption, and more.
Define column header names/labels. For example, chaging "Beginning Balance" to display as "Beg. Balance" or another term that resonates with end users.
Define column header definitions to provide definitions to end users.
Designate the order in which columns are displayed. This is done by dragging and dropping the row in the desired order.
Select end user input options. For example, either calculated or user input.
Determine if end users are allowed to skip products or not.
Add in unique calculations and columns leveraging the extensions mechanisms defined by the Technical Committee. An example of how to do this is described in the Requisition Splitting - Extension Scenario Analysis.

Background

Each implementation of OpenLMIS configures their requisition templates according to the programmatic needs. There is one requisition template per program. Using the new architecture, implementers can extend the template to meet specific needs for new formulas and options. For example, one example desired extension would be to display values as packs versus dispensing units. Take care configuring the template as many columns are dependent on either user input or reference data.

Column Dependencies

The following diagram displays the dependencies between the various column headers in the Requisition template. It also was used to discuss the proposed changes for 3.0 (in green). Once all the changes are implemented we will update this to reflect the final state. Please review the legend on the right for information on the colors.

Process Flow

Work in progress.

2.0 activity diagram between User and System

OpenLMIS > Requisition Template > FE150-after fixes.png

Stories

Beta Release

3.0 Release

Open Questions

Below is a list of questions to be addressed

	Question	Outcome	Status
1	Is M = Number of months in previous period or current period?	based on a call with Josh Zamor & Chongsun Ahn (Unlicensed) on 16 Dec 2016 M = number of months in the previous period	Closed
2	What if X is 31?	based on a call with Josh Zamor & Chongsun Ahn (Unlicensed) on 16 Dec 2016 formula would treat a 31 like a 30 (full month out of stock)	Closed
3	Should we continue to support Monthly Normalized Consumption or should we support a generic Adjusted Consumption which is flexible to varies period lengths?	Based on call with Product Committee on 20 Dec 2016 we decided to support adjusted consumption.	Closed
4	What about supporting Average Adjusted Consumption versus Average Monthly Consumption? Average Adjusted Consumption would support AMC if the implementer is implementing a monthly reorder schedule.	Based on call with Product Committee on 20 Dec 2016 we decided to support average adjusted consumption.	Closed
5	Malawi may need the max stock column to come from 'normalized consumption' versus AMC? Can we make an extension so that you can modify P to be N?	Based on call with Product Committee on 20 Dec 2016 we decided to create an extension point so that implementers could multiply by either P or another variable.	Closed
6	Should we change the name of MaxMonthsStock to infer more of a term which means "multiplier" to clarify that it doesn't have to be 'months' but can be?	Based on call with Product Committee on 20 Dec 2016 we decided to rename the field so that months isn't implicit in the attribute	Closed
7	No of New Patients, can someone explain why this variable is within consumption versus having a separate column? Potentially we could create a new column for this and incorporate it into 're-order calculation' based on the appropriate scenario.	Based on call with Product Committee on 20 Dec 2016 we decided to pull out the No of New Patients variable from "N" calculation, unless Ashraf Islam (Unlicensed) and team find something in the SOPs around needing these two combined and included in AMC.	Pending final confirmation from Ashraf Islam (Unlicensed)
8	What about migration from 2.0? Moving forward with the new columns, what's the mitigation plan? Need to ensure this is part of the gap analysis work.		Open, Need to raise with PC and gap analysis team

Notes

When OpenLMIS was implemented as eLMIS, the teams hard coded in new options to meet country needs. Below is the list of variants completed and why they were created.

Variable	Title	Options created	Details and comments. Comments in Blue are from Elias Muluneh
H	Maximum Stock Quantity	Period Normalized Consumption x 2	Allowed the maximum stock quantity to take the Period Normalized Consumption into account.
H	Maximum Stock Quantity	Dispensed Quantity x 2	Dispensed quantity = Total Consumed Quantity "C"
N	Monthly Normalized Consumption	Dispensed Quantity x No of New Patients (F)	Dispensed quantity = Total Consumed Quantity "C" Interesting is what happened here. This functionality would have been better developed by adding another column, something in the lines of ... "quantity required for new patients". basically, since that column did not exist, users renamed the new patients required label in swahilli to something in those lines ... and entered data. I would implement that separate column - and the formula would be a choice between either considering the new patient data (multiplying the new patient by doses per patient) or taking what the facility asked would be required without any assumption. My Opinion: In some cases, It makes sense to leave the calculation of quantity required for new patients to the person that is doing it. Take an example commodities that are supplied in different quantities for adults and children. If the calculation has to assume adults take twice doses as children or other complex factors have to be accounted for. I think leaving the option for the users to say how much is required is more expressive than how many new patients. And ohh, I also think ... "how much new quantity" is more about supply chain data than "how many new patients" is.
N	Monthly Normalized Consumption	(Dispensed Quantity x 90) / (90 - Stock out Days )	Dispensed quantity = Total Consumed Quantity "C" Don't know if you will find this interesting but ... This formula is only supposed to be applicable if the programs is a quarterly reporting program. For a monthly reporting program, this formula makes no sense. Basically, this formula is trying to calculate normalized consumption by considering stocked out days only. (without taking into account new patients counts) The manual system uses this simplified formula.