Target release	3.1
Epic	OLMIS-623 - Getting issue details... STATUS
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	To manage my storeroom stock levels. I want to minimize stock outs. I want my facility to have the right stock at the right time. Receive verified quantity and quality of goods into store and determine need for remedial action when necessary.	Records stock movements: stock issues, receipts, adjustments Physical Inventory Views and monitors stock on hand Receives and responds to low stock and stock out alerts Print Stock card summary and single stock card page	Stock out, over stocks Plays multiple roles Time spent on reporting/data entry Managing multiple programs' reporting needs	Tech aptitude: Low technical skills Has limited / poor internet connectivity Examples, could be pharmacy assistant or medical assistant, nurses for HIV, Health Surveillance supervisor (vaccines) Some training in logistics management Individual responsible for issuing stock to those who are dispensing
Title: Store Manager Stock Management Role: Oversees/Audits Stock Cards	Level 1	Same as the storeroom managers.	Views and monitors stock on hand; receives low stock and stock out alters Audits physical stock count	Storeroom managers (usually sitting at Service Deliver Points (SDPs)) are late in sending their report for authorization.	Oversees the storeroom manager assistant or data entry personnel. Specialize in a program/group of commodities.
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	To have the right stock available for the needs of the service delivery point and own storeroom Review Budgets	Reviews and monitors stock movements and stock on hand at service delivery points. Receives and responds to notifications for low stock/stock outs at lower level facilities. Fulfill requisitions	Late reporting (stock issues/adjustments/etc. on a monthly basis) from SDPs Stock out, over stock	Tech aptitude: varies Likely a medical professional (MD or Pharm.) with limited to no logistics knowledge Not a primary user of nor familiar with OpenLMIS Only uses OpenLMIS to approve/reject requisitions
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)	Visibility (into stock levels, orders) into my own facility and those I'm responsible for supplying I want my facilities to have the right stock at the right time. I want to minimize stock outs or overstocks Uphold FEFO Manage the budget of my facility	Records stock adjustments. Records stock movements: stock issues, receipts, adjustments Views and monitors stock on hand at their own store and lower stores Receives notifications for low stock/stock outs at lower level facilities. Inter-facility transfers to address low stock/stock-outs	Not enough time Stock out, over stocks Plays multiple roles Time spent on reporting/data entry Managing multiple programs' reporting needs	Has internet connectivity Med. - low technical skills Most likely will be responsible for fulfilling Example, individual is located at a district hospital level Issues stock to different wards, facilities, etc. Respond to emergency orders/requests from lower-level facilities, wards, dispensaries...etc. Would want to see stock levels of lower facilities Would like an easy to use and intuitive system
Role: Funder		Verify compliance / impact of programs & projects via indicators measured in OpenLMIS Confidence in the supply chain through transparency	Receives reports and aggregate data (need to understand this better)		Limited time Very high-level, aggregated data
Central Logistics Personnel Stock Management Role: Review Reports, Decision Maker	Central	Long term supply and program planning based on stock and requisitions data	View reports Reporting rate Initiates stock recalls Views and monitors stock on hand and low stock/stock outs at all levels		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	Ensure system is running fine and not blocking end users	Configure data: reasons/source/destination Provide level1 support		Technical background Could write simple sql scripts Trouble-shooting skills
Implementer Stock Management Role: Set up OpenLMIS system, Feed historical requisition data into stock management service	Central	Ensure system is set up correctly and ready to use	Set up the system based on country-specific requirement	Simple configuration process Flexible system features	Strong technical background Can write scripts not only sql scripts

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.

Dependencies

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 (b) when a product outside facility's product list is received through the regular receive process (OLMIS-615) or ad-hoc receipt (OLMIS-634)	OLMIS-706 - Getting issue details... STATUS	Closed
2	Do we need the view part of the stock card configuration for the admin user		OLMIS-706 - Getting issue details... STATUS	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.	OLMIS-706 - Getting issue details... STATUS	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.		OLMIS-978 - Getting issue details... STATUS	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	OLMIS-1145 - Getting issue details... STATUS	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	OLMIS-1112 - Getting issue details... STATUS	In Progress, Shiyu Jin (Deactivated) is leading this process.
7	What level of configuration do we need for stock card?	OLMIS-706 defines this	OLMIS-706 - Getting issue details... STATUS	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.	OLMIS-18 - Getting issue details... STATUS	Open
9	Are there specific needs around search/grouping products? By donor? Tenly Snow (Deactivated)		OLMIS-532 - Getting issue details... STATUS	Open
10	Should Adhoc Issuance and Receipts REASONS be specific to program? Or global?	Specific to each program, though we can start with global	OLMIS-629 - Getting issue details... STATUS OLMIS-630 - Getting issue details... STATUS	Open
11	What is the priority of Recall functionality?	To be done during/after Lot Management OLMIS-1308	OLMIS-1116 - Getting issue details... STATUS	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	OLMIS-1431 - Getting issue details... STATUS	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.	OLMIS-634 - Getting issue details... STATUS OLMIS-615 - Getting issue details... STATUS	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?		OLMIS-1429 - Getting issue details... STATUS	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.	OLMIS-706 - Getting issue details... STATUS
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?		OLMIS-1435 - Getting issue details... STATUS	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 No approvals needed for basic movements on the stock card, which means that a second person isn't going in and "approving" a movement made by another person. HOWEVER, we will have permissions in the system around WHO can make movements. *Looking forward* We should look into how to add another layer around an Audit/Verification check. Stores often have monthly/periodic audits - usually around physical stock counts - where a second person approves/verifies the SOH on the system. District level store, vaccine, or costly items may need an additional workflow to explain large adjustments. If an adjustment (damages/expiries/phy stock count, etc.) exceeds certain %, require an explanation or note for why the adjustment was that large.	OLMIS-1439 - Getting issue details... STATUS OLMIS-1620 - Getting issue details... STATUS	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)	OLMIS-2113 - Getting issue details... STATUS	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.	OLMIS-634 - Getting issue details... STATUS	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) Review and validate user personas Should Storeroom Managers be assigned by programs?	Product Committee: Permissions need not be by type of movements? i.e. a user would not have permission to perform only one type of stock movement, but would get permission for all. Stock management users/Storeroom Managers should be assigned by programs?	OLMIS-2519 - Getting issue details... STATUS	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? Free text (planned currently) Username + timestamp Initials (system generated from user login)	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: Mozambique: users are not allowed to enter historical movements VIMS: users are allowed to; initial set up was anything in the current month (i.e. if it is 13 Jan, allow movements to be entered starting from 1 Jan). Eventually -based on user feedback/behaviour - this was extended to the previous month as well (i.e. if it is 13 Jan, allow movements to be entered starting from 1 Dec) Zambia: physical stock count Options for cut-off: Last physical stock count Last requisition This month Previous month 25.2.The committee was unanimous in selecting 'Reversal'. However, there was some debate on how the reversal should be recorded - whether it should be as a 'Receive' (as in the original example) or as an 'Adjustment' (see second table in the 'Reversal' section). The reason an Adjustment was preferred was so that we would have an 'Adjustment Reason' that could potentially be displayed on the Stock Card. We decided this needed more discussion of pros/cons between those two options, and that we would get back to PC after Shiyu, Mary Jo, and Josh discuss.	~~Shiyu Jin (Deactivated) can you insert the ticket fulfilling this decision?~~ OLMIS-2013 - Getting issue details... STATUS	Closed
26	For Product committee: How do we want to deal with the need for additional information for some stock movements? For example, if a large adjustment (quantity of expired goods or physical stock count) is made. Two possible options: System detects when unusual stock movements are recorded and prompts user for more information System lets movement through but allows users/decision makers at higher levels ask for more information through the system			Open
27	For Product Committee: Should we prioritise creating internal OpenLMIS notifications? i.e. notifications that show on the OpenLMIS web page, as part of a notifications centre/icon. Current the notifications service is focusing on email notifications. If/when we implement internal OpenLMIS notifications, do we force action on the user? (i.e. a physical stock count notification will only go away once the physical stock count is done; or a low stock alert will not go away till an emergency requisition is placed, etc.).			Open
28	For Zambia Facility Edition: (email from Lakshmi Balachandran, 13 Jan 2017) Are users allowed to enter historical stock movements? i.e. enter an activity from a week or month ago that they may have forgotten to record, even if one or more activities after that date have already been entered.If that is allowed, what is the cutoff date for how far back they can enter information? I understand requisitions and stock movements are recorded one product at a time. Have you had any user feedback around wanting to record say expiries for multiple products at once? I’m asking partly because we actually did get that feedback from users in Mozambique (the Android system – ESMS – right now has a user select a product and then record a movement, so one product at a time). Mary Jo shared some screenshots from the Facility Edition with me. Could you help clarify: What do the Reverse Transactions and Backlog allow users to do? The stock card (after an activity) display both Balance and Usable Balance. What is the difference?	Are users allowed to enter historical stock movements? i.e. enter an activity from a week or month ago that they may have forgotten to record, even if one or more activities after that date have already been entered. From Chris Opit (Unlicensed): Q: If that is allowed, what is the cutoff date for how far back they can enter information? -Physical count is the determinant for the cutoff. If physical count is done at the end of the month it means all reconciliations have before that date have been done. Q: I understand requisitions and stock movements are recorded one product at a time. Have you had any user feedback around wanting to record say expiries for multiple products at once? I’m asking partly because we actually did get that feedback from users in Mozambique (the Android system – ESMS – right now has a user select a product and then record a movement, so one product at a time). - Being a transaction processing system, requisitions are generated from routine transaction data. - Depending on the type of transaction, a series of products in the program are displayed for update: physical counts, losses and adjustments, issues, receipts provide an interface for multiple entries without toggling between screens. Mary Jo shared some screenshots from the Facility Edition with me. Could you help clarify: Q: What do the Reverse Transactions and Backlog allow users to do? - Reverse transaction enables a user to undo a wrong transaction. This drops data for the entire transaction allowing the user to enter a new transaction afresh. - Like bank transactions, correction of values of entries is not allowed but rather complete reversal. Q: The stock card (after an activity) display both Balance and Usable Balance. What is the difference? - Balance displays the stock as at the date selected – especially if the user wants to review stock as at a particular date in history. Usable balance is current balance of stock.		Open
29	For Product committee: Do we allow user to do physical inventory outside the schedule physical inventory date? Does store room managers must to input the stock on hand quantity for all the active products (within stock cards) during each physical inventory? Can they skip some products' stock on hand quantity?	Yes, for 3.1 there will not be a schedule and users can conduct a physical inventory at any point.	~~Shiyu Jin (Deactivated), can you insert the ticket here please.~~ https://openlmis.atlassian.net/wiki/display/OP/Manage+Physical+Inventory	Closed
30	For Product committee: What type of system permissions are needed for viewing, creating, etc. stock movements. Who can view the stock card? Does the same permission management as the requisition? Meaning anyone who can view my facility requisitions will be able to view my facility's stock cards. Should it be similar to requisitions (requisition group/program, supervisory node, home facility).	Mary Jo Kochendorfer (Deactivated) reached out to Chris Opit (Unlicensed) to learn how Facility Edition handles permissions. From Chris Opit (Unlicensed): At facility level there are 3 main categories of users: 1 - Health facility in-charge/Pharmacy in-charge/Lab in-charge: These are the the most powerful persons at each health facility and they oversee commodity security at the last mile. They have access to view stock status, RandR and associated reports. They also may occasionally participate in issuing products to the dispensing/use locations. 2 - store in-charge - may be one for lab products and another for Essential medicines and/or ARVs. These are often in charge of the stock control cards in the respective stores. They are responsible for issuing products to the dispensing points and will usually answer to the facility in-charge and the District supervisors. Providing oversight of stock at the whole facility and generating monthly Reports and Requisitions for stock replenishment. Due to shortage of health workers, the store in-charge may also assist with dispensing of health commodities at dispensing locations. 3- Dispensers/testers/lab technologists - these execute the final product-use tasks: dispensing to patients, running lab tests and managing stock in their physical locations and requisitioning from the store. Stock management may involve performing periodic physical counts of products they manage. They may not have rights to manage commodities at the main store in the facility. In some occasions they double-up as managers for the main stores as well. --- the bottom line is that there is close consultation with key staff at the facility to determine the roles of different staff at that level	OLMIS-2519 - Getting issue details... STATUS	Open
31	For Product committee: Continuing from a conversation had in 2017-02-27 Meeting Notes. First, review some example use cases on needs for negative SoH, User cases for negative SOH balance. Given the use cases, let's discuss the following: is negative SoH allowed: yes/no if negative is allowed, is the user prompted before syncing or entering a historical transaction? : yes/no how long can a negative SoH be allowed before alerts are sent (and to whom): is this a matter of hours? days? a function of the processing periods? what kind of scheduler would we need to send those alerts, and how would we use it with the negative SoH rule (policy)? How configurable is the setting? by perhaps Program, Facility, etc. I would expect that within a Program, the rule (or policy) could change over time, how would that be done?	Brought up to the PC on 28 Feb 2017 . Suggested speak with JSI, Logistimo and try to find some SOPs. Mary Jo Kochendorfer (Deactivated) has reached out to Chris Opit (Unlicensed) and team for insights from the Facility Edition. From Chris Opit (Unlicensed): 1- Negative SoH is not allowed - balance on hand is continually displayed for each transaction and usage deducts directly from balance. Users cannot perform transactions when commodities run out and have to fix any anomalies before proceeding. Some product categories like HIV test kits require the tester to perform physical counts at the close of each day. Without previous day's physical count, the tester will not be able to proceed with today's HIV testing 2- standard stores/inventory management practices are followed in public health logistics as well	OLMIS-2092 - Getting issue details... STATUS	Closed 3.1 scope does not include a distributed closed system (concept of pending stock) so SOH will not go negative.

Notes

Browser not supported