Page Comparison

At what point in time the system will actually create the stock cards?

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.

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.

Will we create a new scheduling mechanism or we will reuse the one we already have in requisitions?

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.

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

What is the priority of Recall functionality?

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.

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)

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

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.

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.

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?

For Product Committee

Do we need archiving permission at facility level, or is a 'deactivate' function at the national (admin?) sufficient?

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)

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. 

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

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

For Zambia Facility Edition:

(email from Lakshmi Balachandran, 13 Jan 2017)

1. 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?
2. 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:

1. What do the Reverse Transactions and Backlog allow users to do?
2. 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.

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?

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

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?