Stock adjustment modal window


When a user is filling out a product's losses, they need to say how much of the stock was lost for which reason. This is done in a modal window, that is launched by clicking on the amount of product that was lost. This happens in the UI whenever the admin has configured the Stock Adjustment reasons (OlMIS-381) for the program, and added the Total Losses/Adjustments (D) field to the requisition template for this program (). When a requisition is initiated with a program that uses D, this field will be in the requisition, and the requisition service along with the reference data service will provide all the information the UI needs to expose this field (see ).

Looking forward
This component should be built in a way that the modal view can be reused, as a later feature will need the exact same display. However, for this ticket we will focus on putting something up which works.

Acceptance Criteria

  • An end-user is initiating and filling out (updating) a requisition that uses field D, meaning the admin/implementer has configured stock adjustment reasons and included field D in the requisition template for this program...

  • User selects the product(s) on the requisition to adjust (clicks into this new field)

  • A new modal window opens (see screenshots).

  • It provides a list of stock adjustment reasons that are pulled from the reference data service API, see OLMIS-380. The order they appear on the UI dropdown matches the order configured in OLMIS-381.

  • They can add zero, one or multiple entries and each entry is associated with a 'reason' and has an adjustment quantity integer.

  • Increment/decrement (+/-) of the quantity depends on the reference data reason configuration (reference data indicates if the adjustment is a positive or negative).

  • User can select the type of adjustment from a dropdown, then enter the integer, and keep adding more if they want to.

  • User can close the model window when they have added zero, one or more adjustments. But they cannot close it if they enter a quantity without picking a reason.

  • User will get an error if they try to enter an invalid quantity (not an integer).

  • User is required to enter number quantity of number of units to adjust. Number must be an integer zero or greater

  • User permissions are enforced (user is allowed to change this field if the line item is editable and the requisition is currently editable; note that sometimes a user might not have permissions to edit the requisition, in which case field D should not be editable and this modal should pop up in read-only mode and not be editable)

  • Adjustment amount is added or decremented from stock on hand count as appropriate for adjustment type (an *example *list below - these fields live in the reference data and should be configured on setup):

    • Damaged - decrement stock

    • Transfer In - increment stock

    • transfer Out - decrement stock

    • Expired - decrement stock

    • Passed VVM - decrement stock

    • Cold Chain Failure - decrement stock

    • Lost - decrement stock

    • Facility Return - increment stock

  • the field is calculated D = D1+D2...DN (D is the Total Adjustment quantity) so that the total adjustment applies to the requisition line item after you close the modal.

    • when adjustment reasons are defined () it includes defining if that reason is either a or adjustment, this definition should be enforced here. If defined as a the quantity entered will be subtracted.

  • if the user saves the requisition and opens it again later, all the reasons and quantities in any line item are preserved, the quantities can be edited, and the +/- numbers still calculate correctly, and if you add yet another reason or zero out a reason you can save it again and it will update the total D value

Assume the following JSON model for adjustment - this is the requisitionLineItem:


Paweł Gesek


Nick Reid



Story Points


Time tracking


Epic Link



Fix versions