A. Plan Re-Supply Order
Goals
Add text here
Background
insert discussions during the workshop which are relevant to note. List participants.
User Stories
Step 1 - View Critical Element
This set of stories captures the data that the "supplier" needs to view on the screen as First Step when taking re-supply decisions, regardless of Requisition or Allocation supply model
| # | Title | User Story | Label | Importance | Notes | JIRA Ticket |
|---|---|---|---|---|---|---|
| 1 | View forecasted need | Supplier views forecasted amount for the receiver site, by EPI product, and for the re-supply time period scheduled in the system Source for 'Forecasted Amount' – Multiple Options below; aslo cross-ref Forecasting and Estimation Domain i) Uploaded onto OpenLMIS via an upload file With this option, an admin uploads a file containing forecasted amounts, per facility, by product and time period. So the work to estimate is done outside OpenLMIS/not OpenLMIS responsibility. OpenLMIS only pulls info from this upload file and displays to user. Display should show forecasted amounts per product, by facility, for the chosen time period. ii) OpenLMIS calculates forecasted amount and displays it (WHO calculator) | Allocation + Del SC Allocation + PU SC Req + Del SC Req + PU SC | MVP | OLMIS-3234 - Getting issue details... STATUS | |
| 2 | View & Verify SOH | Supplier views SOH of the receiver site Options: 1) If receiver site has OpenLMIS, then the "view" will show their most recent SOH update for a product and time stamp for when that update was done 2) If receiver site does not have OpenLMIS, then the supplier has to first (on a separate screen) update SOH per product and the "view page" would display this after it's been saved/synced. | Allocation + Del SC Allocation + PU SC Req + Del SC Req + PU SC | MVP | Assumptions: If the receiver node has OpenLMIS, they have updated their SOH Collecting of SOH at sublevels is currently done outside the system by:
If the receiver node does not have OpenLMIS, the supplier has some way of accessing SOH outside the system and manually entering it into OpenLMIS VS note: what about viewing own (i.e. supplier) SOH as a critical step in decision-making? RP: Yes, from Senegal we found out that this is a necessary step in the process also. | OLMIS-3275 - Getting issue details... STATUS |
| 3 | View CCE status | Supplier views CCE functionality status of the receiver site; if CCE is broken or functioning erratically, then Supplier takes action (outside of OpenLMIS) and then decides if re-supply should happen and how much (in case re-supply is to stock a cold box only versus a full CCE, etc). As an intermediate warehouse manager, I want to know the CCE status of the facilities to which I am preparing fulfillment of vaccines so that in the event of non-functional or erratic functioning of CCE, I can follow-up to see if I should even be preparing this fulfillment From: SELV | Allocation + Del SC Allocation + PU SC Req + Del SC Req + PU SC | MVP Down vote: 1 (Ryan McWhorter) | This view is currently possible through a CCE workflow. User can go to CCE Management and view the CCE Inventory list. They will be able to see the functionality status of CCE in their supervised facilities. | |
| 4 | View total CCE capacity | Supplier views total CCE capacity at supplier site | Allocation + Del SC Allocation + PU SC Req + Del SC Req + PU SC | MVP | ||
| 5 | View pipeline | Supplier is able to see what stock is coming into her/his own CCE so that a determination can be made whether rationing of re-supply to lower nodes is necessary or not | Allocation + Del SC Allocation + PU SC Req + Del SC Req + PU SC | Next Up votes: 6 | ||
| 6 | View net CCE capacity | Supplier is able to view the net CCE capacity at receiver site, based on their SOH as well as how many CCE is working properly | Allocation + Del SC Allocation + PU SC Req + Del SC Req + PU SC | Next Up votes: 3 | ||
| 7 | View previous consumption | Applies only to requisition based SCs If a requisition asks for more or less than what is in the plan/forecasted for that receiving site, then supplier views previous consumption history to see if they point to more or less being consumed. | Req + Del SC Req + PU SC | Next | Lot of work to be done here in terms of scope of story. How far back does consumption go? And when does supplier view? When the requisition ask is less than or more than by a certain % or even if it's 1 dosage more or less than forecasted? | |
| 8 | View session plans | Supplier is able to view the session plans for the receiving site | Allocation + Del SC Allocation + PU SC Req + Del SC Req + PU SC | Next Up Vote: 4 | Big understanding gap in terms of what is needed and why so many votes in favour. | |
| 9 | View utilization | Supplier is able to view historical vaccine utilization (i.e actual doses count administered of each product – program data) to inform re-supply decisions for the future | Allocation + Del SC Allocation + PU SC Req + Del SC Req + PU SC | Next Up Vote: 5 | Need to determine why this is more important or better data point to rely on for re-supply decision-making instead of using consumption data reported via SM domain (i.e. all issues out of CCE regardless of given to people or wasted). |
Step 2
The set of user stories below captures what happens next in preparing an order once the above critical elements data is available to Supplier to make his/her decision
| # | Title | User Story | Label | Importance | Notes | JIRA Ticket |
|---|---|---|---|---|---|---|
| 1 | Batch view SOH | Supplier can batch view SOH of receiver sites for allocation (for settings where both supplier and receiver nodes use OpenLMIS) | Allocation + Del SC Allocation + PU SC | MVP | Mary Jo Kochendorfer (Deactivated), do you recall the conversation around this? I'm now unsure of what we meant by this piece. | |
| 2 | Capture SOH | Supplier captures SOH of receiver site on OpenLMIS (for settings where only supplier has OpenLMIS and receiver is using paper systems) | Allocation + Del SC Allocation + PU SC | MVP | Assumption is that HFs have provided SOH data to DIVO via paper, SMS, phone call, or in-person prior to the re-supply process kicks-off and the DIVO uses this information to input SOH data per product per site into OpenLMIS | |
| 3 | Basic view requisitions | Supplier views a list of all the requisition orders As an intermediate vaccine warehouse manager, I want a screen where I can view all my pending requisitions and select one to view and convert to issue so that I can react to requisitions sent to me Acceptance Criteria: From: VIMS | Requisition + Del SC Requisition + PU SC | MVP | Assumption is that DIVO has already submitted requisition requests which have been approved so Supplier is viewing the approved order request | |
| 4 | Capture requisitions | Supplier (DIVO) captures the requisitions amounts in OpenLMIS, as requested by a HF via a paper requisition form (in settings where only supplier node has OpenLMIS) | Requisition + Del SC Requisition + PU SC | MVP | ||
| 5 | Grouping requisitions | System groups/batches for multiple requistions | Requisition + Del SC Requisition + PU SC | Next Up votes: 5 | Mary Jo Kochendorfer (Deactivated), do you have more details on this one? I will also look back at the user stories I have for reference after I finish these tables up | |
| 6 | Prioritize requisitions | Provides ability to re-order requisitions in terms of priorities (assigned by rules) As an intermediate vaccine warehouse manager, I want facilities that I supply to only be able to have one pending requisition at any given time so that I can prioritize those facilities that have been waiting longest for their requisitions to be filled Acceptance Criteria: From: VIMS | Requisition + Del SC Requisition + PU SC | Next | ||
| 7 | Reject approved requisitions | Reject an entire requisition order (though approved) Edge case | Requisition + Del SC Requisition + PU SC | Next | Need to find out more about when this is likely to happen; also, what is the next set of actions that this option provides – once rejection happens, does the receiver get notification to re-submit? etc | |
| 8 | Managing exceptions | System should be able to manage exception cases (deviations from rules, ad-hoc events) etc | Allocation + Del SC Allocation + PU SC Req + Del SC Req + PU SC | Next Up Vote: 2 | This was a new sticky note placed on the board without any discussions on Day 3; so vague and broad in scope that we'd require a lot of work to define some boundaries around managing exceptions | |
| 9 | Supplier sets allocation amounts | Supplier sets allocation amounts instead of just going by what system says s/he should allocate) | Allocation + Del SC Allocation + PU SC Req + Del SC Req + PU SC | MVP | ||
| 10 | FEFO and supplier SOH based allocation amounts | System recommends allocation amounts based on FEFO and amount of antigen that is available in supplier''s CCE | Allocation + Del SC Allocation + PU SC Req + Del SC Req + PU SC | Next Up Votes: 13 | I reckon this should actually be two stories (one for FEFO and one for RIVO's own available stock) - correct? | |
| 11 | Top-up to max. policy amounts | System recommends top-up amount to max (if such policy exists for this level) | Allocation + Del SC Allocation + PU SC Req + Del SC Req + PU SC | Next Up Votes: 6 | Is there a story in the requisition workflow that does this for the node doing the requisitioning? In VIMS, it is the requesting node that has the system automatically calculate the routine top-up for that level before node hits submit | |
| 12 | Bundling | System groups antigens to their associated dry stock (diluents) | Allocation + Del SC Allocation + PU SC Req + Del SC Req + PU SC | Next Up Votes: 4 |
Assumptions
- insert
Diagrams
Dependencies
insert
Open Questions
Below is a list of questions to be addressed as a result of the vaccine workshop:
| Question | Outcome | |
|---|---|---|
Out of Scope
Out of scope for this feature OR potentially saving for future development
OpenLMIS: the global initiative for powerful LMIS software