Stock Management

Stock Management

Target release

3.1

Epic

https://openlmis.atlassian.net/browse/OLMIS-623

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

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

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 editor

Dependencies

 

Open Questions 

Below is a list of questions to be addressed 

Question

Outcome

Related Story

Status

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) 

https://openlmis.atlassian.net/browse/OLMIS-706

Closed

2

Do we need the view part of the stock card configuration for the admin user

 

https://openlmis.atlassian.net/browse/OLMIS-706

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.

https://openlmis.atlassian.net/browse/OLMIS-706

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.

 

https://openlmis.atlassian.net/browse/OLMIS-978

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

https://openlmis.atlassian.net/browse/OLMIS-1145

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

https://openlmis.atlassian.net/browse/OLMIS-1112

In Progress, @Shiyu Jin (Deactivated) is leading this process.

7

What level of configuration do we need for stock card?

OLMIS-706 defines this

https://openlmis.atlassian.net/browse/OLMIS-706

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.

https://openlmis.atlassian.net/browse/OLMIS-18

Open

9

Are there specific needs around search/grouping products? By donor? @Tenly Snow (Deactivated)

 

https://openlmis.atlassian.net/browse/OLMIS-532

Open

10

Should Adhoc Issuance and Receipts REASONS be specific to program? Or global?

Specific to each program, though we can start with global

https://openlmis.atlassian.net/browse/OLMIS-629

https://openlmis.atlassian.net/browse/OLMIS-630

Open

11

What is the priority of Recall functionality?

To be done during/after Lot Management OLMIS-1308

https://openlmis.atlassian.net/browse/OLMIS-1116

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

https://openlmis.atlassian.net/browse/OLMIS-1431

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.

https://openlmis.atlassian.net/browse/OLMIS-634

https://openlmis.atlassian.net/browse/OLMIS-615

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?

 

https://openlmis.atlassian.net/browse/OLMIS-1429

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.

https://openlmis.atlassian.net/browse/OLMIS-706

 

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?

 

https://openlmis.atlassian.net/browse/OLMIS-1435

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.

 

https://openlmis.atlassian.net/browse/OLMIS-1439

https://openlmis.atlassian.net/browse/OLMIS-1620

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)

https://openlmis.atlassian.net/browse/OLMIS-2113

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.

https://openlmis.atlassian.net/browse/OLMIS-634

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?

https://openlmis.atlassian.net/browse/OLMIS-2519

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

OpenLMIS: the global initiative for powerful LMIS software