This page contains ideas that didn't make it into the Software Requirement Specification but should still be captured for a later time.

Bulk Orderable Update

---START HERE---

The current stock control view focuses on single stock card transactions one orderable at a time. We will add a new area to the Android client that allows dispensary technicians to make changes to multiple orderables. This user interface is targeted at store managers who need to issue, adjust or receive multiple orderables in a single transaction. Examples include issuing multiple orderables to a single third party, stock take adjustments, large wastage adjustments and receive a shipment.

Discussion:

• Is there a better name for this section?
• Do we have story points for these activities?
• Is there a better way to layout this section? Currently, it's based on actions that need to be performed

Action 1: Issue Stock - Issue multiple orderables to a single third party

This action allows a store manager to issue multiple stock items to a single third party in a single transaction. The store manager will be presented with a form that allows them to define the destination and choose the quantity of each orderable to issue from the list of orderables that are currently in stock.

Data Entry Screen

• Section: Issue to - This section allows the user to select the third party who will receive the stock.
  • Field: Location - This list will be populated by the OpenSRP facility list.
  • Field: Person - This list is populated by users who are part of the facility as defined by the OpenSRP team management module
  • Business logic:
    • Only one location or person can be selected in this section.
    • Stock cannot be issued to the location that is currently active in the app
    • One of these fields must be selected to be able to save the form.
    • The selection in this section can be changed after the orderables are selected with no change to the orderable section
• Section: Orderables - This section allows the user to choose which orderables to issue and the quantity to issue
  • (The UI for this section has not yet been defined)
  • Field: Select Orderable by name and unit - This field allows the user to select an orderable of orderables that are currently in stock (value >0)
  • Field: Issue Quantity - This field allows the user to specify the quantity of units to issue
  • Field: VVM - If a VVM is available for this product, the user must select the VVM of the orderable (number 1 - 4)
  • Business logic:
    • Orderable name and unit are auto populated by the OpenLMIS metadata
    • Issue Quantity cannot exceed the available number of units on hand
    • Issue Quantity is a required field
    • VVM is only displayed if the orderable has a VVM. In which case, VVM is a required field.

Form Save Android Client Business Logic

• Once the form is saved each orderable is decremented by the issue quantity and values are updated across the entire stock management module
• The user is redirected to the Stock Control Landing View

Discussion:

• Does the user need to be able to issue stock up the OpenLMIS hierarchy?
• What is the OpenSRP server side business logic that needs to be captured before it is sent to OpenLMIS?
• Are there any other sections that should be added to this view?
• Do we need to handle the case where stock is issued to a community health worker who is able to login to the same Android device without requiring a sync to the server?
• Future Idea: Should we prepopulate the orderables section with any information based on the field selected in the "Issue to" section?

Action 3: Adjustment -  Bulk Wastage Event

This action allows a store manager to make bulk adjustments in the event of a large wastage like a Cold Chain Equipment failure or natural disaster. The view includes a list of all orderables that are currently in stock at the facility.

Data Entry Screen:

• Field: Wastage Reason - This single select field is populated from the program specific adjustment reason.
• Section: Orderables - This section displays a tabular view of all orderables that currently have a stock value greater than 0. Each orderable signifies a single row in the table.
  • (The UI for this section has not yet been defined)
  • Column: Orderable name
  • Column: Orderable unit
  • Column: Stock on Hand - This shows the current stock on hand for the orderable
  • Column: Amount Wasted - This field allows the user to capture the number wasted
  • Column: Calculated stock on hand: - This is a calculated field that calculates the new stock on hand value by subtracting the amount wasted from the stock on hand value (stock on hand - amount wasted). This field displays in whole units.
  • Business logic:
    • Each orderable represents in a row in the table
    • Orderable name and unit are auto populated by the OpenLMIS metadata
    • All orderables are displayed on this screen
    • Amount wasted cannot be greater than the current stock on hand.

Form Save Android Client Business Logic

• Once the form is saved each orderable is adjusted to the calculated stock on hand quantity and values are updated across the entire stock management module
• The user is redirected to the Stock Control Landing View

Discussion:

• Do we need to include open vials?
• How do we define the order of the orderables that are displayed on this screen?
• What is the server side business logic?

Action 4: Receive Stock - Receive multiple orderables from a single third party

This action allows a store manager to receive multiple stock items from a single third party in a single transaction. The store manager will be presented with a form that allows them to define the source and choose the quantity of each orderable that was received from the list of available orderables. The list of available orderables are defined by OpenLMIS and maintained in the OpenSRP orderable map. The end user will not have the ability to add orderables that have not already been added in the OpenSRP server. Note that the Android client will need to sync if the system administrator has updated the list of available orderables.

Data Entry Screen

• Section: Received from - This section allows the user to select the third party who sent the stock.
  • Field: Location - This list will be populated by the OpenLMIS facility list.
  • Field: Person - This list is populated by users who are part of the facility as defined by the OpenSRP team management module
  • Business logic:
    • Only one location or person can be selected in this section.
    • Stock cannot be received from the location that is currently active in the app
    • One of these fields must be selected to be able to save the form.
    • The selection in this section can be changed after the orderables are selected with no change to the orderable section
• Section: Orderables - This section allows the user to choose which orderables are received and the quantity received
  • (The UI for this section has not yet been defined)
  • Field: Select Orderable by name and unit - This field allows the user to select an orderable of orderables that are currently in stock (value >0)
  • Field: Quantity Received - This field allows the user to specify the quantity of units to that are received
  • Field: VVM - If a VVM is available for this product, the user must select the VVM of the orderable (number 1 - 4)
  • Business logic:
    • This section is prepopulated by the list of all available orderables to the facility as defined in the OpenSRP orderable map
    • Orderable name and unit are auto populated by the OpenLMIS metadata
    • Quantity Received is a required field
    • VVM is only displayed if the orderable has a VVM. In which case, VVM is a required field.

Form Save Android Client Business Logic

• Once the form is saved each orderable is updated by the quantity received and values are updated across the entire stock management module
• The user is redirected to the Stock Control Landing View

Discussion:

• Does the user need to be able to issue stock based on the OpenSRP hierarchy?
• What is the OpenSRP server side business logic that needs to be captured before it is sent to OpenLMIS?
• Are there any other sections that should be added to this view?
• Do we need to handle the case where stock is received from a community health worker who is able to login to the same Android device without requiring a sync to the server?
• Future Idea: Should we prepopulate the orderables section with any information based on the field selected in the "Issue to" section?

Other Features Not Yet Specified

Cold Chain Equipment

The SOW includes an activity to track the status of cold chain equipment at the facility. These workflows need to be defined jointly. The feature could be as simple as an SMS interaction from OpenLMIS directly to the health worker, a Boolean toggle on in the OpenSRP Android client, or more complex to keep track of Cold Chain Equipment serial numbers.

Could also view functionality over time in the Android, probably not needed, but I'd assume time series functionality will be important in the reporting.

Advanced Stock Notification / Proof of Delivery

The Advanced Stock Notification (ASN) and Proof of Delivery (POD) are currently being specified by OpenLMIS. These workflows will need to be jointly defined by the OpenLMIS and OpenSRP teams. In theory, OpenSRP server could receive a JSON payload from the OpenLMIS server, push that down to the Android client, and prep the proof of delivery for easy validation in the UI. The teams need to specify the workflows and features independent of the activities that have been specified in this document.

Which may include extensions so that OpenLMIS can push data to external servers

Mobile Role Based Access Controls

As of the MVP, all users will be able to access the stock management module and perform all activities. In the future, we should introduce a role based access control system in the mobile app that allows only a subset of users to access the stock management transactions.

Out of Scope

This section includes a list of items that are out of scope for phase 1.

• Real-time notifications. There is the possibility to provide real-time advance stock notification through push messages to the OpenSRP App. However, this requires a different technical backend. The current model will only provide updates when the mobile device syncs to the OpenSRP server.
• Requisition Creation
• Multiple programs
• Schedules
• Periods