Create an Adjustment

Goals/Scope

• Ability to record adjustments to my stock levels in my store room

Background

Users have a need to record adjustments of stock levels. We have heard that there are two use cases for how users normally think to enter adjustments.

• Option 1: select the type of adjustment (for example, Wastage) and select which products are part of that adjustment. For instance, if a fridge breaks we'd like to record all the products impacted by that fridge breaking.
• Option 2: select the product and apply different adjustment types (and dates).  For example, a user wishes to record loss and transfer in the same workflow but they are two types of adjustments.

The majority of the product committee on April 11 2017 decided that option 2 is the most intuitive and useful based on experiences of the members, we will aim to first achieve option 2 and subsequently build out the support for option 1 later. We see a need for option 1 within vaccines and will want a way to create an adjustment with one reason and multiple products (eg, when the vaccine fridge breaks).

Chris Opit provided details on the Zambia's facility edition (screen shot below), uses the following flow for their adjustments:

• Step1: Select the Adjustment date by clicking on the date picker.
• Step 2: Click on the arrow on the drop- down menu to select the Program Area, for example ARV program.
• Step 3: Use the Product Name search feature to quickly search for a transaction. Type in the first few characters of the product and click on search
• Step 4: Select the product you want to make an adjustment on.
• Step 5: Enter the quantities and associated remarks against various adjustment types 

Additional notes : Breadcrumbs allow the user to back up to the product selection or program selection and make additional adjustments. Usually data is entered at the end of the month when the physical inventory is due. 

Assumptions

• Adjustment reasons are centrally defined
• Storeroom manager can only make adjustments for his home facility and home facility supports programs for Release 3.1

User Stories

Steps

Step 1 : User selects Program 

Step 2 : User is brought to the "Make Adjustment" page, where they can create adjustments.

Step 3 : Make selections at the top

• Search/Select Product + Select Lot (required)
• Select Adjustment Reason (required)
• Select Date (required)

Step 4 : user selects the "Add" button

Then the following table is populated :

EACH row in the table below is a separate adjustment event. Each row of this will be submitted as a separate API call (stock event) for now. At this time, we will not leverage the API ability to have one adjustment event for multiple products (eg, the fridge breaks). We will build out the UI to support that later.

How the above table will look (plus additional columns)

Step 5 : After added products

Clear the whole table:

User can remove all added products by clicking the 'clear' button and confirm at the pop-up window

Submit:

User can submit this adjustment by clicking the submit button. After clicking the submit button then there will be a pop-up confirmation modal displays "<username> confirms N Adjustment". After user clicks 'Yes' then it will direct user to the SOH summary page within the chosen facility and program. If user clicks 'No' then the modal disappears and user stays the previous adjustment page. 

Step 6 : user sees confirmation modal which displays "<username> confirms "N" Adjustments.  We no longer need the date and signature based on the discussion with the product committee (April 11 2017). Later if an implementation wants to add signature to this modal they can do so through extension.

As for the submission mechanism, we would use the batch submission. Meaning, all adjustment stock line items would be submitted only when none of them fail to pass the validation check.

Note: When this page is saved to the server APIs, it will be multiple stock events (one for each row). We know that some might succeed and others might fail. The ones that fail would turn red. The user could make changes to those red ones in order to attempt re-submitting. The ones that succeed could be made non-editable or could be removed from the screen. The ones that succeeded would not be re-submitted again. Could you consider the intention here and come up with a suggestion of how to achieve this?

Dependencies

Open Questions

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

Out of Scope