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. |
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.