Mock Ups

Open question: do we treat physical inventory differently then others?

Main workflow for issues, receipts, adjusts

Step 1: Select activity
Step 2: Select products
Step 3: Provide the required information to record
Step 4: Potentially a review/confirm

Step 1: Select activity

Option 1: 5 options (current one)
Option 2: Stock Management (Physical Stock count, adjustments, Viewing). Receiving (normal and ad-hoc) and Issuing (normal ad-hoc)
Option 3: Requisitions, Transactions (issues and receipts), and Stock activities (adjustments and physical stock counts)

Step 2: Select products

Once in the activity, how will the experience look. These options are not mutually exclusive and could both be there.

(to be generalized to all the other activities as well)

Option 1: Add products by program

The first screenshot shows a list of programs (on the left side). Clicking on a program displays the list of commodities belonging to the program, and allows the user to either all commodities (not shown here) in that program or select commodities from the program to add.

The screen says 'Dispense', but would follow a similar pattern for Adjustments as well.

Options 2: Add products by search

Search by product name and add to page. Adding products one by one. As a sample, the first screenshot also has a search field on the top left side. Clicking there allows user to search for commodities - the screenshot below implements a predictive search.

May be useful when users don't know what programs a product belongs to. Or just adding one or two products so don't want to click through products.

Option 3: Display all products

Display full list of products initially. Select specific products from the list or a table format where they enter the data into the columns. User enters details for the products that s/he needs to

(no mock up for this view)

Step 3: Recording stock activity details (quantities)

The following information needs to be recorded for each activity (review OLMIS-1633)

Ad-hoc receipt. For each selected product, record:
- (required) Movement date: system generated, but might want to display on page
- (required) Received from (dropdown): this would usually be the same for all the selected products, so potentially have user select this at the top of the page
- (required) Received Quantity: user enters positive integer
- Reason (dropdown): this would usually be the same for all the selected products, so potentially have user select this at the top of the page
- Others: such as document number or signature, as configured by admin in OLMIS-706
- Stock on Hand: auto-generated by system, to be displayed to user
Ad-hoc issue. For each selected product, record:
- (required) Movement date: system generated, but might want to display on page
- (required) Issued to (dropdown): this would usually be the same for all the selected products, so potentially have user select this at the top of the page
- (required) Issued Quantity: user enters positive integer
- Reason (dropdown): this would usually be the same for all the selected products, so potentially have user select this at the top of the page
- Others: such as document number or signature, as configured by admin in OLMIS-706
- Stock on Hand: auto-generated by system, to be displayed to user
Adjustment. For each selected product, record:
- (required) Movement date: system generated, but might want to display on page
- (required) Adjustment Quantity: user enters positive integer
- (required) Adjustment Reason (dropdown): this would usually be the same for all the selected products, so potentially have user select this at the top of the page
  - Need to show based on reason whether it is a positive adjustment or negative adjustment (either by color of reason/quantity or +/- signs)
- Others: such as document number or signature, as configured by admin in OLMIS-706
- Stock on Hand: auto-generated by system, to be displayed to user

Physical Stock Count. For each selected product, record:
- (required) Movement date: system generated, but might want to display on page
- (required) Stock on Hand: user enters positive integer
- Others: such as document number or signature, as configured by admin in OLMIS-706
- Adjustment Quantity: auto-generated by system, to be displayed to user

For each activity, need to decide what information (such as current SOH, MOH, AMC) should be displayed while the user is entering information.

Adding screenshots for recording quantities, reasons, and other information. This will likely not need a series of options but we can discuss. (Note the reasons dropdown in these screenshots are different from ours, please ignore)

An option for adjustments is to allow the user to enter multiple quantities corresponding to each reason, all together:

Patterns

Should we have more navigational hierarchy?

Open Questions

	Question	Discussion
1	Once Stock management is selected as “on” by an implementer, can they also select which activities are “on” (i.e. choose to have any only adjustments for e.g. and record all stock management activities through adjustments). I prefer they have this ability, but open to discuss. If they can select the activities, the menu here should reflect those selections
2	Can admin/implementer re-order the dropdown menu?	Nick: should actually be doable technically? If the desire is to do this without code, becomes tricky.
3	Can admin/implementer re-group the dropdown menus? For instance, have ad-hoc receive/ad-hoc issue be part of the Receive and Fulfillment processes? Or combine Requisitions and Orders into a single dropdown? For instance, the Zambia facility edition has Requisitions, Transactions (issues and receipts), and Stock activities (adjustments and physical stock counts) Some implementers might see ad-hoc issues and receipts belonging better with the Receive and Fulfillment processes, as opposed to Stock Management. Since the only difference there is whether the issue/receipt are user-initiated or automated/through OpenLMIS	Nick: should actually be doable technically? If the desire is to do this without code, becomes tricky.
4	Should we consider the use of icons for stock management? In general, should stock management reference UI be more "advanced" than requisitions? How far can the look and feel for stock management differ from requisitions?	Nick: prefers phrases versus icons. Typically for lower literacy you'll want both. Icons can also get tricky and may not mean the same thing across boundaries.