- Price list must be added as a filter as sometimes you want to pick products that never have been ordered before
- Consumption days concept does not make much sense and is tucked away too deeply. Extend date range filter to more human ranges such as “last week” or “last quarter”
- Most frequently ordered makes sense as it is likely that popular orders will be repeated
- Most recently ordered makes sense as it is likely that recent orders will be repeated
- Product category makes sense as a filter ("I only want to order hardware")
- Show for each product the sales/purchase order they belong to. Clicking the order will open it on a new tab so you can peek into it and see the rest of the order
- Use extra dedicated filters for the most important attributes. Use column filters for the less relevant filters
- Set default filters to avoid massive volumes
- Save filter settings for reuse per window type and user
I plan to keep Copy Lines and Copy From Order in separate windows (in fact, they are layers in 3.0 style) but the user can easily switch between them. I believe that a user either wants to select products from price lists or recent orders OR wants to reuse and merge all order lines from entire orders OR wants to duplicate a past order, including all its header and lines data. This last option can also be done in a grid by duplicating the row. So we´ll have three flavors to reuse order lines. The proposed solution tries to satisfy all three methods.
The Price List is the most important attribute in order line picking. The Price List is now set in the header. The lines to pick should have it as a default filter, although it should also still be possible to choose products from other price lists. The Price List Version is currently not used in the header. The new proposal does have it in the header although I am not certain if this is a good idea or not, so help me out here.
Then there is a whole set of business logic we need to rethink when adding products from a non-default price list or even more than one, which can get quite complicated when products exist in more than one price list.
I have attempted to model all of the above thoughts in an extended sales order scenario, see the first PDF document via the link below. The second PDF shows some background on Price Lists. I also noticed that the price list setup is very tedious. We must tackle this as well at some point but let´s first focus on the sales order flow.
Please have a good look and let us know if this all makes sense to you. Find the proposed solution and the discussion thread on this Forge forum.