...
| Page Properties | |||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
| # | Title | User Story | Label | Importance | Notes | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Create new adjustment page | As a storeroom clerk |
| ||||||||||||||||||
| 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 4 : user selects the "Add" button
Then the following table is populated :
...
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
| Description | Link |
|---|---|
...