Vaccine Stock Based Requisitions

Target release
Epic OLMIS-3850 - Getting issue details... STATUS
Document status
Document owner
Technical LeadNick Reid (Deactivated)

Decided to implement in multiple iterations. 3.3 will only include the Vaccine Stock Based requisition.


  • 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


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


  • 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

#TitleUser StoryLabelImportanceJira tickets
1Configurability for Authorize 

As an administrator I need to configure the authorize step in Requisitions so that it is not required in the resupply process.

2Create a Stock Based requisitionAs a DIVO I need to requisition stock when I have completed my physical inventory and determine that additional stock is needed.

Acceptance Criteria:

  1. Create requisition
  2. Display fields per template configuration
  3. Select Products to requisition, or skip products that are not needed
  4. Enter requested quantities
  5. Submit for approval (no authorize), view submitted requisition


  1. Which fields are required to complete requisition? All columns will appear on the stock based requisition.
  2. What do we need to consider for the scenario where physical inventory is submitted weekly or more frequently than the requisition processing period? Only one stock based requisition can be created per processing period.
  3. Is rejecting a SB requisition a final status? When a requisition has been rejected, this may be caused by SOH data being incorrect. If this is the case, then the DIVO would not edit the requisition, they would have to update their physical inventory and then start the requisition process again.
  4. Can products be skipped in a stock based requisition? If products can be skipped, how does that affect the SOH and requisition calculations?


  1. Stock based requisition template contains all the same columns as regular requisition template (only with different configurations, and the added ISA column).

Tickets to be deaded:

3Configure Stock based requisition template

As an admin I need to configure stock based requisition templates so that they display required fields.

Acceptance Criteria:

  1. Configure more than one requisition template by program (at least one regular and one stock based requisition)
  2. Modify template to be displayed and uneditable vs user input for columns that are pre-populated by stock cards
  3. Map the pre-populated columns to stock cards
  4. Allow for configuration of requisition template to display and use ISA instead in the calculated order qty
  5. Allow admin to edit which columns are displayed (show all columns, or select a few)


  1. When the SB requisition template is configured, how does it affect the regular requisition template calculations? Does the SB requisition template pull from the regular requisition template columns? What if the facility is not requisitioning through OpenLMIS?
  2. Can both the regular requisition AND a stock based requisition get used for the same program at different facilities? 

OLMIS-3916 - Getting issue details... STATUS

OLMIS-3917 - Getting issue details... STATUS

Ticket to be deaded:

OLMIS-3665 - Getting issue details... STATUS

4Approval process 

As a program supervisor I need to approve/reject SB requisitions so that I can review or adjust requisitions that affect my budget.

Acceptance Criteria:

1. SB requisition should use same approval process as requisitions (use supervisory nodes/existing supervisory hierarchy)
2. Remove authorize step in approval process for simple requisition
3. Reject should be a final status (if a SB requisition is rejected, it does not need to get deleted)


OLMIS-3666 - Getting issue details... STATUS

5Replace Convert to Order Process

Modify the current 'convert to order' process so that requisition can be fulfilled with OpenLMIS (need ability for the user to view orders for other facilities, and select a facility that is not a warehouse to fulfill when the order is created)

OLMIS-3918 - Getting issue details... STATUS


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


Connecting Stock Management to Requisitions (Brandon Bowersox-Johnson are there dependencies?)
In Local Fulfillment, when a DIVO is deciding how much to fulfill at each facility, they can manually update the SOH. When we are completing stock based requisitions this field in fulfillment should be populated by the stock cards, so that the SOH in fulfillment matches the SOH in the stock based requisition, and this field should not be editable if it is auto populated.

Open Questions

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

1Will stock based requisitions use different consumption calculations? For example if more than one stock based requisitions are created within a regular requisition processing period? 
2Is there a difference between stock based requisitions and emergency requisitions? Should they be the same? (Reuse or modify emergency requisitions to support additional requirements (if any) for stock based reqs.)

3If I have created a SB requisition, and that is pending approval, should I be able to create another simple requisition before the first is approved? 

4If I have submitted my physical inventory on previous date, and now want to create a SB requisition, how will I get to that screen? This workflow would require the user to submit another physical inventory, and then they will see the prompt to create a requisition. Should there be another way? A button on the stock mgmt screen?


What are the triggers for creating the SB requisition? Should there be a prompt every time a physical inventory is submitted? Or are there automated calculations that trigger a user to create the SB requisition? (triggered by stockouts?)

6How are reporting and existing requisitions impacted?

7What products are on a stock-based requisition? Does it start empty and you pick and add products one-by-one?For 3.3 we will use FTAPs and address the one by one in later releases.Closed
8What columns are on a stock-based requisition?

9Product must have a stock card? If there is a product that doesn't have a stock card, should Spock still be able to request it?

Out of Scope

OpenLMIS: the global initiative for powerful LMIS software