Vaccine Stock Based Requisitions

Goals/Scope

• A Stock Based requisition is defined as: 
  
  • A requisition using pre-populated stocking information that cannot be changed.
  • The following rules also apply:
    • The only field a user can edit is requested quantities and an explanation.
    • Administrators can turn off the authorize step.
    • Follows existing processing periods.
    • Can include new ISA column to assist in amount to request (assuming ISA quantities are configured).
    • Utilizes existing approval hierarchy from Requisitions within OpenLMIS
    • For an ideal state, a user should be requesting commodity types for any requisition (same set of products as defined in FTAP)
    • An administrator can configure multiple templates per program

Background

These are the differences between regular requisitions and stock based requisitions:

• In stock based requisitions the SOH is prepopulated from stock cards and is uneditable. In Requisitions the SOH data can also be prepopulated from Stock Management stock cards, but the fields are editable.
  
  • This is also visible in the templates configured for the requisitions because fields that are User Input in regular requisitions may be display only in SB requisitions.
• Forecasting data  (ISA, Calculated Order Qty, Average Monthly Consumption) 
  • Do users need to see these amounts, or can the amounts be calculated and populated in the requested quantity fields? The ISA will be used in the calculation and is not required to display in the stock based requisition form.
• There is no authorization step in stock based requisitions. Since the SOH data comes from stock cards, an additional review step "Authorize" is not needed.
• When a stock based requisition receives its final approval it will automatically create an order.
  • Since the orders are filled locally, there is no need for the DIVO to log into the system separately to select a facility to convert a requisition to order. 
• When a stock based requisition is rejected, this is a final status.
• The products in the stock based requisition form come from the most recent stock card. The product list is the same set of products as defined in FTAP.
  • Either the user will have the option to select specific products, or skip products they do not need to requisition.
• Stock based requisitions may be created multiple times within a processing period. In Requisitions, there can only be one regular requisition per processing period.
• Creating an order requirements are documented here: /wiki/spaces/OP/pages/135823499
• Local fulfillment requirements are documented here: /wiki/spaces/OP/pages/88670474

Assumptions

• Stock on Hand level is only incremented/decremented in the Proof of Delivery process. This needs to be defined when the Proof of Delivery feature requirements are documented.
• Stock Card is the Stock on Hand at that time - this is not historical stock or available stock

• We want to use the existing requisition endpoints as much as possible

• New System generated triggers to prompt a user to create a stock based requisition (alerts and notifications for stock outs or potential stockouts) are out of scope for this release
• Additional consideration to support the Product Model must be included in these requirements to request commodity types and trade items for requisitions, orders, and fulfillment, but is still being designed (as of 1/5/18). 
  • Stock Management records stock on hand as dispensing units
  • Requisitions records stock on hand and requested quantities as dispensing units
  • View Orders reports Order quantities as dispensing units

User Stories

Using known stock data, Spock needs to request new stock (stock-based requisition) so that an order can be created to fulfill.

This is the user journey and the expected steps within each user journey are:

Create Stock Based Requisition → Approve Stock Based Requisition & Create order → Fulfill order

Spock → Apu → Philomena

Diagrams

Process Workflows:

• Intentional Request: Spock knows he needs to request more stock before he even logs into OpenLMIS (based on external data maybe)
  • Spock can create a stock based requisition for a facility/program *at any time*
  • Spock knows of an external (undocumented maybe) need for stock, and sees his stock will be low
• Unintentional Request: Spock is completing stock management activities in OpenLMIS and is notified or looks at stock data and determines that he needs to request stock. (This is otherwise known as system alerts or notifications.)
  • Spock completed his physical inventory and sees that his ISA is higher than the SOH, next order won't be for some time
  • Spock has loss/wastage that he reported in his physical inventory, and now needs new stock
  • Spock received notification (email or phone call) that his stock is low
  • Min/max stock levels compared to physical inventory, Min stock level notification
  • Emergency order point notification
  • When Spock creates an issue, he is prompted to create a stock based requisition

Dependencies

Open Questions

Below is a list of questions to be addressed as a result of this requirements document:

Out of Scope