This page contains possible future changes to the Adjusted Consumption field and the AMC calculation. This is not meant as a current design document or an official part of the roadmap. It is intended to document an internal Team ILL meeting held October 9, 2017 to discuss issue OLMIS-3201 and build consensus for how we move forward.

Background

Some of Team ILL (Josh, Mary Jo, Brandon, Christine, Sam) met to discuss issues raised in OLMIS-3201 around the 360-day calendar and Adjusted Consumption. Below are whiteboards from the meeting and a summary of next steps. It's also important to note that there are important legacy issues around the 360-day calendar support, around how that worked in OpenLMIS V1 and V2, how it impacts the Gap Analysis, and more. Any future tickets for work in this area should include Josh and Mary Jo, along with appropriate dialogue with the Product Committee / country implementor representatives.

Meeting Notes Oct 9, 2017

The current Adjusted Consumption formula:

Note: The current formula only works well for periods that are a whole number of months (1 mo, 2 mo, etc). For periods of other lengths (not a whole number of months), it rounds but the resulting calculations are not meaningful.

This table shows each option (left-to-right) and what is proposed for its UI and API. At the bottom of the board are longer-term tickets.

Action Steps

Short-term and long-term steps were identified:

#	Action Step	Timeline	Notes	Jira ticket
1	Revert work done in OLMIS-3201	Short-term	This will be reverted before 3.2.1. We agree this will leave in-consistent validations and it will leave a limitation that users in the Malawi implementation cannot enter 31 stock-out-days. But we agree that outcome is better than releasing the changes that were made in OLMIS-3201.	OLMIS-3201 - Getting issue details... STATUS
2	Design and implement "actual days" data entry	Mid-term	Gap Analysis work in 2018 may tackle this issue. Notes on the whiteboard above summarize this concept. Josh and Mary Jo need to be involved in design. There are details to work out before implementation. (It's not a trivial ticket.)
3 or TBD	Admin UI to configure periods	Mid-term	Core work on admin screens may tackle this issue. FYI Sam Im (Deactivated). The timeline for this action step can happen independently from the others, but we do need to include Josh and Mary Jo so we make sure that Admin UI will align with the rest of this.
4	Create a new column to separate 'Average Consumption' from 'AMC'	Long-term	The 'Average Consumption' column would not use a 360-day calendar; it would work fine for any length periods. The AMC column would be based on periods that are multiples of a whole number of months; it would use a 360-day calendar. Both columns would be calculations that share the same "actual days" data entry field from step 2 above. This work needs to include documentation for implementers about reporting, forecasting and calendaring. FYI Sam Im (Deactivated) once this is decided this needs to be added to the R&R template configuration in the Configuration Guide.

Code & Background

Current formula, shown above, only works effectively for periods that are multiples of whole months.
In Requisition service, see RequisitionLineItem.java calculateAndSetFields(), Requisition.java numberOfMonthsInPeriod, and LineItemFieldsCalculator.java calculateAdjustedConsumption().
In ReferenceData service, see ProcessingPeriod.java durationInMonths.
- This comes from Java 8 java.time.Period.getMonths() logic which provides a whole number of months in the Period DTO and endpoints.