Target release 3.3 Epic Link to related JIRA epic or feature Document status Document owner Sam Im (Deactivated) Technical Lead Technical Lead who reviews or supports document

Goals/Scope

• Support resupply functionality by making changes to existing requisitions, stock management, fulfillment, and POD services.

Background

The process changes below support the 4 Re-supply types: (see Re-Supply).

Assumptions

• What are technical or business specific details and characteristics that should be known to explain the environment? List the assumptions you have such as user, technical or other business assumptions. (e.g. users will primarily access this feature from a tablet).

Proposed work to be prioritized

These are not in priority or implementation order.

1. Configure authorize step in requisition workflow (MVP)
   • Current state: When requisition is submitted, an additional review is required and completed in the authorize step before the requisition can be approved.
   • Proposal (DONE): Allow authorize step to be configured by admin 
2. Automatically create an order after requisition is approved (MVP - Priority 3)
   • Current state: The Convert to Order step is required for External Fulfillment since the supplying warehouse is an external facility that is determined once the order is ready to fulfill (after requisition approvals).

   • Proposal: For Local Fulfillment, the supplying warehouse is known when the user is initiating the requisition (in some cases the same warehouse that initiates the requisition will fulfill), and requisitions will auto-convert to orders as soon as final approval is made.

   • 

     Option A: Based on program settings, requisitions in this program auto-convert to orders as soon as final approval is made.  (There would need to be exactly 1 supplying warehouse determined by supply line configuration with no user selection needed. TBD: how to handle error if supply lines don't have exactly 1 warehouse configured; perhaps email an error to user and require them to manually convert in that case.) Option B: Allow the user initiating the requisition to select the supplying facility (if there is only one, facility is pre-populated with that) before they start the requisition. (TBD: does it happen in a modal; is it editable during certain requisition statuses; is it based on initiating user's rights or based on supply lines.) Option C: Allow users editing the requisition to select or change the supplying facility as part of the requisition.  (Supplying facility would be a field visible on the requisition and editable during certain statuses.)

      

3. Use ISA in Requisition product grid to calculate order quantities to resupply (MVP - Priority 1) 
   1. Current state: Configurable ISA values are stored in OpenLMIS, but they are not visible or used anywhere in the Requisition process.

   2. Proposal: Add ISA column as a configurable, optional column that can be added to any requisition template. If enabled, the column shows the read-only value of the ISA for each line item where an ISA is set in OpenLMIS.

      

      This is set once at initiation of the requisition and becomes part of the snapshot (it does not change if the admin configures a different ISA after that requisition was initiated.) (TBD: How is the ISA used for calculations, EG Calculated Order Quantity and/or the default Requested Quantity value or any other calculations? Let's add to this story or split off calculations as a new story. If no ISA is set for some product/period/facility, do we show blank or calculate zero?) (Note: ISAs are tied to Periods, Facilities, and Commodity Types. It appears that ISAs are not tied to a program, so if the same product is on the Requisition form for two different programs, it appears there is no way to set two different ISAs. It's also not clear if ISAs can be used with Orderables that are not Commodity Types (EG in Malawi implementation). See OLMIS-396.)

      
      

4. Requisition product grid fields are pre-populated from stock cards (MVP - Priority 2 - combined 4, 5, 7)
   • Current state: No fields are pre-populated from stock management; beginning balance is pre-populated from previous period requisition closing balance, and average consumption is calculated from previous requisitions' consumption values.

   • Proposal: Add a configuration option into the Requisition Template to allow the following fields to be configured so they pre-populate from stock card data when a requisition is initiated: 

     Beginning balance (come from stock card balance at start of period instead of coming from previous requisition currently); Total received quantity (pull all receipts from stock card during period date range); Total consumed quantity (ditto); Total losses and adjustments (ditto); Stockout days (auto-compute based on how many days during period the stock card showed zero balance). (These fields would still be editable in the Requisition Form during certain statuses as they currently are. Tickets below would make them read-only. Note: Average consumption would not come from stock card data /directly/, but would still come from previous requisitions' consumption values which themselves had been pre-populated from stock card data.) (Note: I don't think there are complex Commodity-Type/Trade-Item issues with this user story, because the Requisition service already pushes data to stock cards which are tied to the exact same orderables as appear on the requisition, and those same cards would be used to pull in this data to pre-populate.) (TBD: What to do when the user edits these fields that were pre-populated from stock cards. Does that mean when the requisition is later approved we want to re-save the changed values back to the stock management service? That is complex to implement and instead we can simplify the work by combining this feature with the one below, forcing any of the pre-populated fields to be read-only.)

      

5. Requisition product grid (pre-populated) fields are read-only (MVP - Priority 2 - combined 4, 5, 7)
   • Current state: Even with the feature above, the fields that are pre-populated from stock cards are editable in the requisition grid.

   • Proposal: Add a configuration option for admins to make the pre-populated fields read-only. For each of the following fields, if it is configured to pre-populate from stock cards, then it is read-only in every requisition status (no user can ever change the value) and the user only needs to enter requested quantities and an explanation.

     Beginning balance Total received quantity Total consumed quantity Total losses and adjustments (the modal would be view-only so users could view all the reasons and quantities but not edit any of them) Stockout days (Note: As mentioned in the TBD for the above feature, it is simpler to implement this if we merge this feature with the one above. If we merge both features together, then choosing to have a field pre-populated from stock cards makes that field read-only. That simplifies the combinations from 4 to 2: either the field is pre-populated from stock cards and is read-only and does not push back to stock cards; or the field is manual entry and editable, and pushes to stock cards upon approval.) (Note: Another possible simplification is that the admin would configure all 5 of these fields together at once; we would prohibit having /some/ of these 5 fields pre-populate from stock cards while others were manual entry. It's all or nothing. Similarly, that would prohibit some of the 5 from pulling from stock card data while other fields pushed into stock card data upon approval.)

      

6. Select Orderables to add to Requisition product grid (not part of MVP, in Gap analysis)
   • Current state: When a user initiates a requisition it is populated with all orderables for that program per the FTAP list.

   • Proposal: Allow a user to select orderables one-by-one to add to their requisition OR add all from the FTAP list (to keep existing process). If the user is adding one-by-one, they also need a way to remove an orderable if they made a mistake.

     Option A: Make this a configuration option in the requisition template for the program. The admins can configure the requisition template to allow the user to select orderables one-by-one to add to the requisition (it starts off blank with zero line items) OR configure it to use the FTAP list as it currently does. Once orderables have been added to the requisition product grid, the user must have the option to select one to many orderables and remove them if needed. Option B: Allow the end-user who initiates a requisition to choose whether to start their requisition off blank and select orderables one-by-one OR to add all orderables from the FTAP list. If the requisition product grid is populated with all orderables then the user must be able to remove orderables they do not want to resupply. (TBD: Would this choice be in a modal or appear in a new screen after clicking "Proceed" to initiate a requisition?) (Note: We would implement this in a feature toggle technique so current users, such as the Malawi implementation, will not see any change.)

      

7. Orderables auto-populate in Requisition product grid from Physical Inventory (MVP - Priority 2 - combined 4, 5, 7)
   • Current state: When a user initiates a requisition it is populated with all orderables for that program per the FTAP list.

   • Proposal: Auto-populate the list of orderables in the requisition product grid from the set of products that were captured in the most recent Physical Inventory. 

     Option A: Make this a configuration option in the requisition template for the program. The admins can configure the requisition template to use the Physical Inventory OR configure it to use the FTAP list as it currently does. Note: This list of products would be all Orderables that have a stock card (because Physical Inventories must include all Orderables with stock cards for a given facility and program). Note: There is complexity here with the Commodity Type/Trade Item product model. The Physical Inventory might be using either type of Orderables, depending on the implementation's configuration. On the Requisition, however, we typically want Commodity Type Orderables only. Business logic to do this is TBD. One possible solution is that we start with the Physical Inventory stock cards, then for each stock card's Orderable, we try to identify a related Orderable on the FTAP list. We would use the Commodity Type-Trade Item relationships.

     
     

8. Creating more than one regular requisition in a period (Not needed, this is an Order concept)
   • Current state: Only one regular requisition can be initiated/in existence per period (if you delete a requisition, then you can initiate a new one for that same period).

   • TBD Proposal: To support resupply we must allow for many regular requisitions within a period. Proposed solutions TBD.
     

     Proposed solutions here? Brandon Bowersox-Johnson Response: Let's talk through this one more, Sam Im (Deactivated). This gets really difficult because of the reporting aspects of the Requisition workflow. It's almost like we need to separate out the periodic reporting from the requisitioning/requesting part–separating the R & other R. Another approach is to say we don't use requisitions and just Create An Order. Or another approach is to make this a configuration option to toggle whether Requisitions are connected to Periods or not. If a program is not using Periods, then users can create a Regular Requisition at any time. This has lots of impacts–need a different way to pick the right ISA (because those are by period); need a different way to compute Average Consumption (since the calculation is done by looking back N number of periods); no way to run the Timeliness or Reporting Rate reports; and maybe other impacts. The bullet point below touches on this. NEXT STEP→ Brandon talk with Josh to ask more questions and revise/discuss with Sam. Reporting changes? How do the changes to requisitions impact reporting? If a user only requisitions specific orderables at a time, how do we ensure they continue to report every period?

     
     

      

9. Capture requisition if receiving facility does not have OpenLMIS (MVP - This is wrong, we need to have a requirement and proposal for creating an order)
   • Current state: When a receiving facility does not have OpenLMIS, the supplying facility can create an Issue in Stock Management to decrement their stock and supply the facility. 

   • TBD Proposal: Issue Voucher - part of Stock Management for Vaccines that got 5 votes

     Ad-hoc Issues should trigger a Receiving stock event at receiving facility (it was discussed and ultimately cut from scope of 3.1 Stock Management) Note: The Issue type should allow for stock on hand data entry and either the average consumption or ISA to assist in calculating the recommended resupply amount.

     
     

10. TBD: Support for Receiving facilities not using OpenLMIS
    

    • Need to discuss with Mary Jo or others to help interpret Copenhagen and Senegal outcomes.

      Current state: Requisitions and Physical Inventories (SOH data) can be done on paper by a Receiver and entered into OpenLMIS by a Supplier. (EG, Malawi using paper for health facility Requisitions and Districts enter these into OpenLMIS.) Open questions: Do we need to support just "4. Allocation delivery" re-supply type? Or which of the 4 types? See Re-Supply page "Submission of necessary data (receiver)" column of MVP grid.

      
      

11.  Add support for multiple requisition templates within one Program (MVP - Priority 4)
    
    • Current state: Each program has exactly one Regular and one Emergency requisition template. Each program has one set of "Program Settings" which apply to all Requisitions.

    • Proposal: Add support for any number of Requisition Templates within a Program. Templates would each have a different name so it's easy to distinguish them. Templates would be associated with one or more Facility Types, and that would determine which template will be used when any requisition is initiated.

    • 
      

      

      Also, the "Program Settings" that correspond with the Requisition Template would also need to allow multiples. We should move them out of the 'Program Settings' tab and rename them Requisition Template Settings. These include: Allow Skipping Periods; Skip Authorization Step; Display Non-Full Supply Tab; Enable field for Date Physical Stock Count Completed. Open questions: Can we do this just for Regular Requisitions? Or is there ever a case where the Emergency template needs to be different?

      
      

12. Notification/indication of low stock (Not needed as part of MVP)
    
    • Current state: There is not any "low stock" notification (on hold–see note below). There is a stockout notification that generates an email alert. Neither shows any visual indication inside the OpenLMIS web app.

    • TBD Proposal: Add a visual indication inside OpenLMIS where there is low stock. This will prompt the user to begin their re-supply process.

      Option A: Use a color-coded icon/indicator to display next to any facility that has low stock. Perhaps put this indicator on "my facility" or in my banner when the low stock is at my own facility (UI design process needed). We could also put a different color/icon where there is a stockout. Option B: Use a button to prompt the user to begin their re-supply process. This is harder than Option A because we need to know what kind of re-supply process this particular user can or should trigger (Initiate a Requisition? Create an Order?). If a RIVO logs in with lots of permissions, we don't want 200 buttons if they have permissions to re-supply 200 facilities. Option C: Build Notification service to provide 'in app notification' alerts. This may require significant effort. We may want the Notification service to offer all notifications in-app in a way that the user can read and clear them. Note: Stock Management already includes  and  in the Vaccines MVP. The latter is On Hold because the system does not have a definition of "minStock" or what counts as "low".

      
      

    
    
    
13. Prompt to initiate requisition after Physical Inventory (Not needed to support MVP)
    
    • Current state: Users must intentionally initiate a requisition. There is no prompt.

    • TBD Proposal: Upon completing a Physical Inventory, prompt the user to begin a requisition.

      Similar to the options above, this could be a Button, a Modal, an in-app Notification, etc. See two sections of the Vaccine Stock Based Requisitions that give examples of 'Unintentional Request'.

      
      

14. Configuration option for Rejected Requisitions to be a 'final status' (Not part of MVP and not needed)
    
    • Current state: Rejected status works like Initiated status, and such a Requisition can still be edited, submitted/authorized, etc. When a Rejected regular requisition is present, users cannot initiate the Regular Requisition for the following period.

    • Proposal: Add a configuration option in the Program settings (soon to be the Requisition Template settings) that allows administrators to configure whether Rejected status is a 'final status' or not. When true, once a Requisition is Rejected, users cannot edit and submit it, and it does not block the ability to initiate requisitions for the following period.

      Open questions: Is this feature for Regular or also for Emergency requisitions? What permissions apply for the ability to Delete a Rejected requisition when this setting is turned on? If you delete it, can you initiate a new requisition for the period?

      
      

15.  Proof of Delivery updates receiving facility stock cards (MVP)
    
    • TBD: Not sure if this is already captured anywhere. Current POD work is spread across many of the different epics, especially Local Fulfillment. I suggest we spend more time ASAP mapping out Proof of Delivery.
      
      
16.  Pick-up versus Delivery (MVP)
    
    • TBD: Very little of our documentation describes supply for pick-up, even though it is 2 of the 4 types of Re-supply. Are there any features needed to support pick-up? Does it still use a "Proof of Delivery" even for pick-up? Or is there a different mechanism that the receiver uses to add the pick-up quantities into their own facility stock cards?
    
    
    
17.  Support re-supply for receiving facilities with "no stocking data in OpenLMIS" (Duplicate of 10)
    
    • TBD: The wiki pages mention this, but how do we support this? Are we still capturing a current SOH and using an ISA to set a default re-supply amount? 
    
    
    

Note: Some of the other epics in Re-supply also contain stories and tickets where work is underway: /wiki/spaces/OP/pages/88670474 and /wiki/spaces/OP/pages/135823499. Some of the ideas above have tickets in Vaccine Stock Based Requisitions, however this page presents the features in a more granular way and does not use the "stock-based requisition" terminology. Proposals on this page may replace what is on the Vaccine Stock Based Requisitions page.

User Stories

Diagrams

Include any business process mapping, mockups, diagrams or visual designs relating to these requirements. Describes the tasks and the personas who perform those activities. The diagram provides the context for the user stories and serves as a focal point for achieving clarity and agreement among stakeholders. Looks like a standard flow chart.

Dependencies

Identify initial dependencies that are on the critical path for this functionality and may affect the delivery time and serving of business goals. Include links to stories.

Open Questions

Initial communication between stakeholders and the development team to help understand scope and estimates.

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

Out of Scope

• List the features discussed which are out of scope or might be revisited in a later release.