As a storeroom manager, I want to fill out a Requisition and specify Beginning Balance, Received Quantity, Consumed Quantity, and Adjustment Reasons (damaged, expired, etc) without having any confusion about which quantities go in which fields.
Because of ticket introduced in version 3.2.0, the requisition columns for Beginning Balance, Received Quantity, and Consumed Quantity now get mapped to stock management reasons. Those reasons are visible in the Total Losses and Adjustments modal, because they are configured as Valid Reason Assignments in the stock service. The specific 4 reasons which are configured in the .ENV file are: CONSUMED, RECEIPTS, BEGINNING_BALANCE_EXCESS and BEGINNING_BALANCE_INSUFFICIENCY.
Here is where these reasons appear in Requisition UI (Requisitions > Create/Authorize, then Search, then Proceed, then click in a Total Losses and Adjustments field) and Stock UI (Stock Management > Adjustments > Make Adjustment, then choose Product, then choose Reason).
Here is the current screen where Reasons are added in the Admin UI: Administration > Reasons > Add.
To satisfy the user story above, we do not want those 4 reasons to also appear as choices in the Reason selection within Total Losses & Adjustments. So the approach is to make a configuration in stock management that allows certain reasons to be configured as shown/hidden in the Adjustment Reasons modal selection. Those 4 reasons would be configured as Valid Reason Assignments. This is necessary so that Requisition service can send data to Stock Service without throwing the error OLMIS-3213.
To do this, this ticket will add a Show/Hide toggle setting for each Reason. A rough mockup (make new checkbox follow styleguide):
Note: the read-only show hide checkmark in the table can match the one we use in the Administration > Facilities screen here:
TBD - dev team please brainstorm; please also read the list of Acceptance Criteria and feel free to ask questions, push back,
or bring up any changes needed or issues we should discuss
Modifying show flag should not affect already existing requsitions
API changes in Stock Management service to allow configuration of these valid reason assignments with a Show/Hide toggle; default is Show (database migration to add this new field will default every valid reason assignment to Show)
the endpoints in Stock that provide the list of valid reasons will still return ALL the valid reason assignments but include this Show/Hide value for each
Admin UI offer this new Show/Hide toggle to configure each valid reason assignment as Show or Hide
default is Show (checked)
UI changes in both the Requisition UI (total losses and adjustments field) and the Stock UI (Adjustments reason list) to now only display the reasons that are set to Show (and not the ones set to Hide)
in Requisition service, the snapshot list of reasons in Requisition will therefore get ALL the reasons but the Requisition UI will use the Show/Hide setting to only show certain choices on the screen
Demo data change to make the 4 special reasons set as HIDE but all other valid reason assignments as SHOW
QA manual testing to test the API, the Admin UI, and the end-user UI in Requisition UI and Stock UI
CHANGELOGs for each component impacted, and specifically saying if this requires any new configuration/setup for existing implementations; especially so that Malawi implementers will be able to see they can use the API to set their 4 reasons to HIDE now.
Add instructional text to the Configuration Guide explaining what show/no show stands for, and more details on when reasons should be shown vs hidden: https://openlmis.atlassian.net/wiki/spaces/OP/pages/112138794/Implementer+Administrator#Implementer/Administrator-SetupStockManagementincludingAdjustmentReasons
Automated test coverage (can we test based on our demo data to make sure the right lists of reasons show up in the right parts of the UI?) Will that take Selenium or can our Contract Test tools handle it?
Have the Requisition Service check whether the special reasons (the ones configured in the .ENV file or the hard-coded defaults) are actually included in the requisition snapshot list of reasons. That snapshot list was the valid reason list at the time of requisition initiation. If one of the special reasons configured in Requisition Service is not valid at the time we initiate and create that snapshot, it could throw an error at the time of requisition initiation.