I do not get the point. Why would it be slower to use the relate from the product form than searching on a list for a specific product.
For me it is a duplicate workflow to prevent one click but with less accuracy (because it requires to search correctly on the product name).
I’m not sure I understand you correctly but Tryton has several ways of searching/selecting several products:
Using " or " operator on search
Using colon on code. IE: Code: 1234;2345;…
Double-clicking on a product category
And also, in many businesses similar products have similar names and/or similar codes. And in some cases the users need to know where are located similar products.
So the current workflow is to search for the required products and for each one open the list of locations to see where the product is stored.
I imagine that you have some use case that a user needs to search the locaion of several products and that’s what you are trying to improve. But could you explain which is this case?
For me, there is one case when the user needs to know where are several products are stored and this is when picking a shipment. But this is already solved by the shipment picking process. So I do not see which is your use case.
This is one of those features in which there’s not one big clear daily use case, but there are some cases in which it is necessary or useful. That’s why I said that the use case is the same than when you want to know where a product is located. Why would you want to know where a product is located if you can know it from a shipment, for example?
That, said one such example is when you don’t find a product in the warehouse and suspect that a user may have made a mistake by bringing the product to a location where there are similar products. You cannot or don’t want to wait for a complete inventory to be done, because it may take too much time.
You have product X0001 which the system says that it can be found in location A1 but it’s not there. Then you think that probably a user made a mistake and confused product X0001 by some other product of the X family (which look almost the same). So you search want to know all the locations for all X products to check if the product is there.
So you get a report with:
X0002, A3, 3u
X0003, A5, 8u
X0004, A15, 10u
You just need to check those 3 locations. Eventually you realize that X0001 was stored in A15 together with X0004 products, and you physically move the products to the correct A1 location. No move at Tryton needs to be done.
And you can go to A3, A5, and A15 and check.
This sounds really like crafted scenario just for this proposal.
It will not work if you have a lot of products and it does not speed up a lot if you have few products.
So for me, it is an unnecessary feature that will increase code maintenance. And it will have very poor performance because it will requires a cross join between products (or worse the lot) and locations, then a stock computation for each row.
Asking for an scenario and saying it’s not real… What part don’t you believe? The pharmaceutical industry is one of those with lots of very similar products and this kind of mistakes is very frequent.
But, can you tell me what is the use case for the link on the product that allows you to see the locations where a product can be found?
Or what is the use case that justifies the feature that allows you to select several sales and go to their invoices?
What is the use case for the
For me there are use cases which happen more unfrequently that highly frustrate the user when they cannot extract some data that it is in their system.
This reminds me the missing menu entry on account move lines. This menu entry does not exist but it is something that we end up adding to all customer databases simply because it’s very useful when the user has made a mistake although it does not respond a clear use case.
I tried it with the database of our largest customer a year ago or so and it took 15 seconds to compute at the PostgreSQL level all products for all locations. That’s why a table query would not be usable but a report would.
I only rised the issue after another customer, from a very different industry raised the issue.
We found a similar requirement in a customer from a very specific business sector. They needed to query the stock of a “family” of products [1] for all locations, so we created a module to get stock from product categories (form relation from product category).
Additionally the module has a report that allows to show many product categories from a location enabling (or not) first level child location detail.
As I said this is an specific requirement and I’m not sure if it’s valid for a general purpose.
[1] this is a set of products with a common feature.
That is a proper way to solve miss placing products. And any way, this can already be done with existing tools.
It is to find a product.
Nothing and it is not something that was developed explicitly. It is a side effect of a generic feature which has usefulness in many other places. This behavior does not increase the maintenance of the project.
I do not see why a user could wait 15 seconds for a report but not 15 seconds to open a tab.
Any this proof that such computation will be slow.
This is only possible using the templates (and it is implemented) because it is the only set of products that are guaranteed to share the same category of unit of measure.
But it is also possible to develop other model that group products with the same category of UoM and launch the stock computation on it using the grouping attribute.