|
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.
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 (Unlicensed) provided details on the Zambia's facility edition (screen shot below), uses the following flow for their adjustments:
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.
Short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.
# | Title | User Story | Label | Importance | Notes |
---|---|---|---|---|---|
1 | Create new adjustment page | As a storeroom clerk | Relevant labels to distinguish source. From which system, or which country? | Must Have, Nice to Have | |
2 | Choose orderables for adjustment | As a storeroom manager I want to submit an adjustment event so that I update corresponding stock cards within the new adjustment event | Shiyu Jin (Deactivated) please make sure ALL the tickets associated with adjustments are linked within this table some where. | ||
Submit adjustment | As a storeroom clerk I want to choose orderables so that I can do an adjustment for them |
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
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.
Product | Lot Number | Expiry Date | SOH | Adjustment Reason | Adjustment Quantity | Date | Actions |
---|---|---|---|---|---|---|---|
Venlafaxine capsule 75mg | Lot A | 05/05/2018 | 34 (cannot edit) | Loss (drop down if selected) | 20 (user input bubble/field) | MM/DD/YYYY (if edited, calendar pops up) | Remove button |
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?
Identify initial dependencies that are on the critical path for this functionality and may affect the delivery time and serving of business goals. Include links to stories.
Description | Link |
---|---|
Name of story or release | Link to JIRA |
Initial communication between stakeholders and the development team to help understand scope and estimates.
Below is a list of questions to be addressed as a result of this requirements document:
# | Question | Outcome | Status |
---|---|---|---|
1 | What is the work flow for creating an adjustment | Communicate the decision reached | Open, In Progress, Closed, and date of closure |
2 | How to display the error message? | Our design is: The error will be displayed only when user clicks the 'submit' button. If there are more than one row are incorrect, we will only highlight the first one. The highlight will not disappear until you click the 'Submit' button again. |