Page Properties | ||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
- Admin searches for orderable:
- What information does an admin need to make their search more effective? Why are they searching for orderable? Incorrect associations?
- Scenario: Product is not showing in requisition, I need to check if its associated with a program and facility type
- Scenario: I want to update price per pack (frequently) per product or in bulk
- Scenario: I want to change my max stock level (FTAP)
- Scenario: I want to change the display order
- Scenario: I want to add a new lot (per product or bulk change)
- Scenario: Changing a product from active or inactive
- Scenario: I want to change the product from full supply to non full supply
- 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))
- Scenario: I want to update (add or remove) the association to facility types.
- 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?
- Do they need to see Orderable Type?
- Sort by Name, filter by active/inactive. A product can belong to multiple programs, multiple facility types
- What information does an admin need to make their search more effective? Why are they searching for orderable? Incorrect associations?
- Admin adds new orderable
- 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)
- 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.
- How do we enable lots for an orderable? Via some module when creating a new orderable?
- Admin edits existing orderable details:
- 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
- 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)
- 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?
- 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.
- Pack Rounding Threshold, Pack Size, Round to Zero, Doses Per Patient
- 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)
- The only way to make the "change" would be to create a new orderable.
- 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
- Admin wants to see which orderables are missing associations
- 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.
- What other types of missing configurations?
- Orderables that aren't associated with a display category
- Data updated in bulk via csv (This is a future requirement and not prioritized for
)Jira Legacy server System JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 448ba138-230b-3f91-a83e-16e7db1deed1 key OLMIS-2707 - Admin edits existing orderable associations:
- change associated trade items?
- change associated programs?
- change associated lots?
- Doses per Patient
- 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?
...
# | Question | Outcome | Status |
---|---|---|---|
1 | How do handle archiving? | Open - Need meeting with Josh Zamor | |
2 | How does changing specific fields in Orderables impact requisition calculations? Should we allow changes to Orderables fields such as pack size, active/inactive? | Ideally, any changes to orderables wouldn't affect requisitions that have already been initiated. The requisition should snapshot the version of an orderable at initiate and use the same properties throughout the whole requisition lifecycle (price per pack, pack size, active/inactive, etc.) | |
3 | Should Facility Type Approved Products also be available in this Orderables view? Should it be editable? | Based on above user scenarios and notes, there is a strong connection to how the Orderables are associated in Facility Type Approved Products. This may make more send to have in the same page as viewing all other orderables associations. |
...