[mobile] Pick List Workflow

[agritheory]

Submitting the Pick List should reserve the inventory without making any Stock Ledger entries. Stock Reservation Entry can be automated and configurable - it is currently only limited to Sales Orders and some customization will be required. How this reservation is to be evaporated or backflushed is TBD. With this workflow, it would seem that some fields in the Pick List should be better named. This should be an opt-in workflow, configured in BEAM Settings.

In the mobile context, as the user picks individual items from the Pick List, they should be added to a draft Stock Entry of type "Material Transfer".

The Pick List mobile view should show the critical details of the PL and a non-editable picked fraction. A new Pick List page, will show the items to be pick, but - similar to the Manufacture workflow - actually map to a Stock Entry. This list should use a day divider.

Story

• The mobile user selects a Pick List from the list of Pick Lists to work on
  • PLs should only show the remaining amount to be picked, subtracting already picked amounts.
• This navigates them to a new Pick List page with the appropriate details
  • If a SE already exists against this Pick List, it should load the (draft) mapped stock entry.
• The user picks an item, repeating as required
  • All "additions" will be manual, allowing disagreement between PL and SE
  • The "Save" action should be labeled "Save and Continue Picking", which updates the SE
• The user completes picking with an action called "Complete Picking" which will submit the SE.
• On Submit the SE should update Demand, Stock Reservation/Bin and SO/ PL detail as appropriate

---

Tests should include:

• Attempt at over-reservation of limited inventory from multiple SOs
• Attempt to pick inventory that doesn't exist (utilizing a Stock Recon after a submitted PL)

[agritheory]

Additional concerns - we will want to incorporate features that prevent users from picking against the same list at the same time. One way to do this is to note if the current user is different than the modified_by user and present a warning when this happens. This should probably be configurable to accommodate a strategy that uses some kind of "team picking" approach.

Assignments in the list filters will be critical.