Stock Management
Target release | 3.1 |
|---|---|
Epic | |
Document status | DONE |
Document owner | @Shiyu Jin (Deactivated) and @Mary Jo Kochendorfer (Deactivated) |
Tech Lead | @Pengfei Cui (Deactivated) |
Scope
The scope of the epic is to create and manage electronic stock cards for a facility. The work will be done in phases, focusing on the basic 'must have' functionality first and subsequently building out 'nice to have' features. This iterative approach will allow for feedback and changes during the development life-cycle. The first iteration included in 3.1 will include the following high level features :
Background
Stocks are maintained in the facility in the form of stock cards. Every inventoriable product that is present in the facility has its own stock card. A stock card is just like a log book in which every in and out is documented along with the reason.
User Personas
The following personas are designed to help the development in understanding the viewpoint and experience of the users for the purposes of stock management. A persona is depicted as a specific person but is not a real individual; rather, it is synthesized from observations and input from various stakeholders across multiple countries.
Note these user personas are a subset of the full list of personas documented here, and only describe users' goals and roles as they relate to stock management.
User | Level | Goals | System Role | Pain Points | Context, Characteristics, Comments, Quotes |
|---|---|---|---|---|---|
Title: Storeroom Manager/Clerk Stock Mgmt Role: Manage Stock at their Storeroom | Level 1 Service Delivery Point |
|
|
| Tech aptitude: Low technical skills
|
Title: Store Manager Stock Management Role: Oversees/Audits Stock Cards | Level 1 |
|
|
|
|
Title: N Program Supervisor Stock management Role: Decision Maker (N could be district/regional/central level. Approvers can also be program specific - Expanded Program on Immunization (EPI), Malaria, Family Plannin, etc) | Varies Central, Regional, District |
|
|
| Tech aptitude: varies
|
Title: District Storeroom Manager - Level 2 Stock management Role: Manage Stock, Reviews data/reports for supply planning | Level 2 Intermediate store (can be multiple, Regional, District, etc) |
|
|
|
|
Role: Funder |
|
|
|
|
|
Central Logistics Personnel Stock Management Role: Review Reports, Decision Maker | Central |
|
|
| Tech aptitude: ?? |
System Administrator Stock Management Role: Manage stock event reasons, Level 1 Support, Manage Physical Inventory Schedule, Manage Minimum Stock level, Assign reasons/facility | Central |
|
|
|
|
Implementer Stock Management Role: Set up OpenLMIS system, Feed historical requisition data into stock management service | Central |
|
|
|
|
Key Features
The release/version is still under discussion.
Process Flow
Current Release schedule:
3.0 is in green. 3.1 is in yellow (pending finalization during prioritization efforts).
Updated scope based on workshop conducted by ThoughtWorks on March 6 - 10 of 2017.
No stock management features were delivered in the 3.0.0 release. All features in 3.1 are highlighted in Yellow. @Shiyu Jin (Deactivated) please feel free to update or insert in an additional document providing an overview of the scope for external parties to reference.
Gliffy Diagram is only supported by the cloud editor
Because Forge macros arent supported by the legacy editor, you'll need to convert this content to the cloud editor to display this macro properly. Find out more about converting to the cloud editorDependencies
Open Questions
Below is a list of questions to be addressed
Question | Outcome | Related Story | Status | |
|---|---|---|---|---|
| 1 | At what point in time the system will actually create the stock cards? | (a) when facility's product list is set up: OLMIS-1431 | Closed | |
| 2 | Do we need the view part of the stock card configuration for the admin user |
| Open | |
| 3 | Do we have the stock cards based on programs or they will always be product wise? If product wise, how do we do reporting when a product belongs to more than one program? Note that Zambia has stock cards based on programs (i.e. if a product belongs to multiple programs, it has multiple stock cards) while Mozambique has product-wise stock cards. Suggestion at the prioritization exercise (Dar/Nov 2016) was to have an admin config available for this. | Product Committee: Generally, we're seeing stock cards per program (so product stored in different locations by program and hence with different bin cards). In some cases, the product assignment is done at dispensing, in which case there's a single stock card. So - prioritise making program-specific stock cards. Make other option a configuration (eventually or immediately if possible) Side note: donor-specific stock cards? Isn't necessarily done now since visibility to that level is difficult, but might become a requirement to track donated stock. This relates to the donor field on the stock card. | Closed | |
| 4 | For Product Committee For Min/Max calculations, (a) What are the standardized formula for min/max calculations with respect to consumption or populations (b) What are the most important factors other than population and consumption Note that including location seasonality considerations came up at the prioritization exercise (Dar/Nov 2016) (c) and at which level (Geographic Zones, Facility, Programs) they will be configured. |
| Open | |
| 5 | Will we create a new scheduling mechanism or we will reuse the one we already have in requisitions? | OLMIS-1145 assumes we reuse | Open | |
| 6 | Product Committee: In supporting Lot management, what level do we want the configuration? Globally or by program or facility type? If it is turned on, what is required? Also, there are some open questions on the details around what happens if a TradeItem doesn't have lots but then a user decides to start using lots. Can the system allow a tradeItem to have a stock card and a lot to have a stock card? Lot Management for Stock Management Service for more details. | Currently the team has prioritized managing lots centrally to start. Does the PC see major issues with this approach? It will be turned on or off globally. We can works to more configuration and potentially allowing end users to add lots. Right now we do not allow end users to add new products (Question #13) so we took that with adding lots. Please weigh in PC members | In Progress, @Shiyu Jin (Deactivated) is leading this process. | |
| 7 | What level of configuration do we need for stock card? | OLMIS-706 defines this | Closed | |
| 8 | For viewing a stock on hand card, how detailed level information is required? Do we just need a total stock count or we would also require breakdown of stocks with respect to lots/batches? | If lot management is "on" and lot is a selected as a column for the stock card through OLMIS-706, this should include breakdown with respect to lots as well. See OLMIS-625. | Open | |
| 9 | Are there specific needs around search/grouping products? By donor? @Tenly Snow (Deactivated) |
| Open | |
| 10 | Should Adhoc Issuance and Receipts REASONS be specific to program? Or global? | Specific to each program, though we can start with global | Open | |
| 11 | What is the priority of Recall functionality? | To be done during/after Lot Management OLMIS-1308 | Open | |
| 12 | Should an initial physical stock count be mandated when a facility profile is created? | This is optional and we can force user to do the initial physical inventory via process | Open | |
| 13 | Do we allow facilities to receive (or rather, record receipt of) products (a) outside the facility's product list, (b) outside the implementation's master product list | For (a), we've assumed yes in OLMIS-634 Product Committee: This is a Policy vs. Practice question. A few sources: no national supply, supplementing supply from private sources, or donation. Frequently, outside the traditional requisition process, but not as frequently outside the master product list (though it does happen for nutritional supplements). Solution: whether or not this is allowed should be configurable - at the program level. If allowed, facilitate (easy) report to see non-traditional products being used. | Open | |
| 14 | What aspects of stock management need offline functionality? | Product Committee: Priority 1: (a) anything the store room managers do frequently. So not ad-hoc receiving for e.g., (2) anything that might take a while and impacted by lost connectivity. So, scheduled physical stock count. Priority 2: Everything offline - to avoid the use of paper if there's no connectivity. Needs more research (should this be a mobile/other UI feature developed for the implementation) | All | Open |
| 15 | Do we assume stock is destroyed during a recall process? Do we need stories to track the stock being returned up the supply chain? |
| Open | |
| 16 | Should "Manufacturer" be an option for the electronic stock card? | If lots are being used, manufacturer will be associated with tradeItems. See Medical Commodities: OpenLMIS Model for GS1 for more information. |
| |
| 17 | How should stock management activities be recorded – by product or by activity (i.e. does user select “Ad hoc Issue” --> list of products, or a single product --> Ad hoc Issue)? We could do one by default (activity → product(s) is how most stories have been written right now), and have an extension point to change this? Might be difficult to set up the extension point. | Product Committee: Multiple-product entry has been a huge time saver - let's stick with that as default. So select the activity (e.g. issue, adjustment, etc.) and then selecting multiple products | Implemented. | Closed |
| 18 | What is the priority of Redistribution function? |
| Open | |
| 19 | Do we need to include any approval/supervisory processes in any stock management functions? For instance, will someone need to approve an ad-hoc issue/receipt? | Product Committee: For 3.1
Looking forward
| Decision made, will address later. | |
| 20 | Once the stock management module is completed, is there a need to do physical stock counts, adjustments, and/or other stock management activities through the requisition form? What happens when both stock management and requisitions are "on" for an implementation? | I'm flagging this question for @Josh Zamor (Deactivated) | Open | |
| 21 | Do we need to generate a POD for ad-hoc receipts? Should we have this as a core feature or an extension point? | Product Committee: No - we haven't seen a business requirement for this. | Decision made, will address later. | |
| 22 | What permissions need to be enforced for stock management? Do these need to be separate from permissions set up for requisitions? (https://clintonhealth.box.com/s/2rsoebxxrofxjh2c5tkjerwtiycmjzb9)
| Product Committee:
| Under discussion | |
| 23 | For Product Committee Do we need archiving permission at facility level, or is a 'deactivate' function at the national (admin?) sufficient? | @Shiyu Jin (Deactivated) could you fill this out. I believe we discussed this during the workshop. Currently, there is no archiving function in release 3.1. |
| Closed |
| 24 | What kind of options/configurations for signatures should be provided in the core product?
| @Shiyu Jin (Deactivated), please update this with the plan for signature at this time. As for physical inventory, we allow end user to input free text signature but as for other stock events: adjustment,receive,issue we would use the initials generated by system from user login. |
| Closed |
| 25 | 25.1 Should users be allowed to enter historical movements (i.e. in a non-chronological order)? If so, how far back can they enter movements for? 25.2. How should correction of historical movements be done? Example options for ways to deal with correcting historical movements: Correcting stock movements
Follow up for Product Committee: 25.3. When users run a report that includes historical movements, will the calculated SOH be based on the date of movement or system date? Should both options be provided to user? | Product Committee: 25.1. Yes, users will be allowed to enter historical movements. Cutoff TBD. Use cases across implementations:
Options for cut-off:
|