Pick List Tool

[agritheory]

Pick Lists are currently restricted to a single Sales Order. This tool would serve as a way to pick multiple Sales Orders, optionally generate Delivery Notes and allow for partial fulfillment. A Print Format for this report would aggregate by Item (total qty to pull), ordered by warehouse lft in way that the user could pull the items needed in an order that made some kind of sense.

[agritheory]

Include a filter for already picked, not picked or all unshipped items. This will help with isolating the workflow from the print format.
Date filters should filter on Sales Orders
Handle Product Bundles, we should add some items to deal with this.
Scenario where picking is required from more than one warehouse (customer requires 30, we have 25 and 15 available in different warehouses).
Warehouse filter, which should include descendants: "Washington" (group) warehouse has children "Rack A" and "Rack B". We should expect to see available quantities from both Rack A and Rack B in the query.

We should expect to use the Frappe Query Builder for this, but it might be appropriate to start with some raw SQL.

[federicocalvo]

The principal idea is to generate in a first instance, a screenshot of what you are looking to be prepared, in order to be able to visualize it in another way, which can be used for picking ( print format). Also taking into consideration the limits of the report view and the print view.

The pick percentage is at the SO level, so for the moment, it would not be possible to detect which line was not picked in an SO without adding complexity. For this reason, the main filter will allow, based on the per_picked field to know if it is equal to or different from 100% in order to differentiate the SOs that already have a pick list.

• The Already Picked status will allow us to see the orders that are 100% picked. The Print Pick button should appear in this state, we will have to show a validation if clicked out of this state in case it is always visible. By not having detail per line, partially picked SO's would be entered as Not Picked.

• The Not Pick status, will allow us to see the orders that are with a percentage less than 100% in per_picked.

Question: should we allow the printing of the Pick Lists that are found, of the partially picketed SO?

• The Unshipped filter status will use the per_delivered field, where the % is different from 100%.

Note: We place the partially delivered ones inside this filter because otherwise, we should have more states.

I think the warehouse filter should repeat the behavior of the parent_warehouse field of the PickList doctype in order to use the same logic.

Note: This comment which seems obvious is because something more complex would be to use a multiselect, where in addition to choosing more than one parent, you can choose exactly the children. This could add complexity, so it is up to you to decide.

Report View

In this first way of visualizing it, we think that the objective is to have a quick overview of what is and what is not in stock. If there is no total stock for all the OVs that appear in the filter we would simply mark each product with an option that denotes that there is not enough to satisfy the entire order, so that in case, you keep playing with the filters and you can arrive at the desired result.

For the Total Stock field, we should generate a query accumulating the total product-wise in the selected warehouses and subtract it by the total of SO Qty, to show graphically what is compliant and what is not.

In the example, we use the result Total Availability and not Total Availability with two colors for easy understanding.

Knowing that some orders are not fulfilled in full you can use the Check Stock button so that it mentions the missing products and their quantities. This is the same method used by the Pick List creation check.

Note: It would be necessary to see if in the future you do not want to make a Request for Materials in order to fulfill the pick list.

Create action

Our main idea, based on the logic of use that we understand, is that Pick Lists are created per client. Because the tool serves a role of massively having something that is seen individually in the pick list.

Note: But, we could either have the actions separately (create PL by Customer and Create a PL), which would create a single PL without customer. Or you can make a configuration so that the button behaves in one way or another.

Create Pick List:

The PL is created in draft state. This will allow it to be used for the picking through Scan Mode or Promp Qty. Also being able to choose or change serialized or batched products.

Note: It could also be differentiated from two different actions, or from a configuration, in case you want to include the PL Validated (everyone who uses the picking with printing might want it to be validated since they do not use the previously mentioned tools).

Create PL and DN:

Especially in this section is where we see with more sense the creation of PL by Customer since it would allow us to then make the DN. This action would leave the PL Validated and the DN Validated.

Note: In case we opt for the pick list option without client, there should be some more logic at the moment of going through the OV that conforms it, and creates the DN then by client.

Print Pick

No matter the filter, we will look for the Pick Lists created with respect to the OV shown in the Report (this is because the information is taken from the Pick Lists), and we will build a printout listing the pick lists separated by customers, grouping by product and differentiating by warehouse, the quantities needed to pick. This is the same action that the individual pick list printout does.

The Cocoplum example shows that you should look for 10 in Principal and 15 in Washington. The checked column is simply a manual control.

Note: The Serial Number and Batch could be shown if used in the company. Although there is no general configuration, only by product, we can see the way to have this data saved before (example of printing of the second pick list).

Note: In the case that the idea is to generate a single pick list without differentiating by customer, I would believe that it is simpler, only that equally in the filter, there can be more than one pick list and not be associated with any customer.

Bundles

The pick list creation method already controls for the elements that make up the bundle, indicating which product you are missing, but does not specify which bundle they belong to.

The print format of the pick list, brings the code of the Bundle product line, we could see to bring the name of the product to make it clearer, adding a Bundle column.