Orderables (Products)

Goals/Scope

The goal of this requirements page is to document the feature of Orderables administration screens and the associated user stories. Administration screens for Orderables allows the administrator to view, edit and research Orderables to assist the administrator with data corrections.

• Scope: This feature includes stories on:
  • View list of Orderables
  • Search for specific Orderables
  • Edit Orderables details
  • View and Edit Associated Lots, Trade Items, and/or CommodityTypes
  • Facility Type Approved Products (this is a separate process not completed through Orderables)
  • Configure Product ISA (This was moved out of Admin screens)

Background

• Version 2 has Products but Version 3 has Orderables, Trade Items, and CommodityTypes

Assumptions

• Potentially hundreds of Orderables per Program that can affect performance

User Stories

1. Admin searches for orderable: 
   1. What information does an admin need to make their search more effective? Why are they searching for orderable? Incorrect associations?
      1. Scenario: Product is not showing in requisition, I need to check if its associated with a program and facility type
      2. Scenario: I want to update price per pack (frequently) per product or in bulk
      3. Scenario: I want to change my max stock level (FTAP)
      4. Scenario: I want to change the display order
      5. Scenario: I want to add a new lot (per product or bulk change)
      6. Scenario: Changing a product from active or inactive
      7. Scenario: I want to change the product from full supply to non full supply
      8. Scenario: I want to update the product name. Not ideal but sometimes the product is misspelt, or has additional endings which make it more/less complicated (E.g. Now it reads Nevirapine 100mg, the MOH has decided to code these items and it should read Nevirapine 100mg (1a))
      9. Scenario: I want to update (add or remove) the association to facility types.
   2. How are orderables, commodity types, and trade items structured in the database for this type of view? What changes need to be made so that we can create a view that has all associations? 
   3. Do they need to see Orderable Type?
   4. Sort by Name, filter by active/inactive. A product can belong to multiple programs, multiple facility types
2. Admin adds new orderable
   1. Goes through entire process of determining if this is a commodity type or trade item, then is directed to the page to begin entering required fields, then completing the required associations (programs, trade items, lots) 
   2. Descriptive text to explain what a commodity type or a trade item is so they go through the correct process. Explain that you can't switch it once it's been created. 
   3. How do we enable lots for an orderable? Via some module when creating a new orderable?
3. Admin edits existing orderable details:
   1. Following editable fields: Active (what happens if they mark an orderable as inactive?), Full Supply, Display Order, Price per pack, Pack rounding threshold, pack size, round to zero, dispensing unit
      1. When an admin marks an orderable as inactive is to remove it from the list of orderables in a requisitions (or they can do this by removing it from Facility Type Approved Products)
   2. Should the admin be able to edit all these fields? Are there any restrictions? Are there any impacts to making edits to fields such as pack rounding threshold during the requisition period?
      1. There are specific fields that should have validation and notifications that they cannot change. For example dispensing unit impacts reporting and requisitions. An indicator near the field shows that its read only because changes break calculations. 
      2. Pack Rounding Threshold, Pack Size, Round to Zero, Doses Per Patient 
      3. Dispensing Unit add details to help admin understand what this is (put an icon or descriptive text that this is a descriptor for the product name that helps inform people in ordering) 
      4. The only way to make the "change" would be to create a new orderable.
4. Admin wants to see which orderables are missing associations
   1. This would also require verifying whether FacilityTypeApprovedProduct exists for this orderable-facilityType-program association as they ultimately define which products are available when initiating a requisition. But +1 this is a common case.
   2. What other types of missing configurations?
   3. Orderables that aren't associated with a display category
5. Data updated in bulk via csv (This is a future requirement and not prioritized for  OLMIS-2707 - Getting issue details... STATUS )
6. Admin edits existing orderable associations:
   1. change associated trade items?
   2. change associated programs?
   3. change associated lots?
7. Doses per Patient
   1. This needs to be researched a little more to understand the impact of making changes and the expected results. This relates to Vaccines. Should this be editable?

Diagrams

Dependencies

Open Questions

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

Out of Scope

• Migration from Orderables to a Trade Item or Commodity Type when they are defined (suggestion is that the product would be set up as a new Trade Item or Commodity type but this affects historical reporting on the program).