Hi, recetly has been commited changes to allow the stock computation by lots [1] (and virtually by other move fields). It has changed the signature of products_by_location() method [2] which allow to get the "stock by grouping" filtering by locations and products.
In a scenario with lot of Lots in the same product, current implementation is not efficient to compute the stock of only some of the lots of a product (because it will compute and return the stock of all lots). You can see an example of use of products_by_location() to get the stock by lot in the WiP review "stock_lot: added 'quantity' and 'forecast_quantity' searchable fields to Lot" [3] Another ineficiency is the implementation of quantity fields searcher [4]. To improve it, I propose to change the products_by_location() signature (and implementation) in this way (see the details at the end of email): Currently, there is already an issue which propose an API change for this method. It propose to move the method from Product to Move (issue 971002 [5]). In this issue Ced and I have also been discused to change the name of the method [6]. Taking in account all of these, I propose a single change (issue, review, commit) which add in Move model a new version of products_by_location (mantaining this name or a new one) which include the new params. To mantain the backward compatiblity, produts_by_location() will be remain in Product calling new function and printing a DeprecationWarning message.. What do yo think? [1] http://hg.tryton.org/modules/stock/rev/2ba5cc517d47 [2] http://hg.tryton.org/modules/stock/rev/2ba5cc517d47#l6.24 [3] http://codereview.tryton.org/963003/ [4] http://hg.tryton.org/modules/stock/file/363ea8c8ce9a/product.py#l125 [5] http://codereview.tryton.org/971002/ [6] http://codereview.tryton.org/971002/diff/1/trytond/modules/stock/move.py#newcode667 Changes in products_by_location() ========================= Add two more OPTIONAL params (maybe replacing the current product_ids param): - grouping_filters: a dictionary with Grouping elements in keys and list of ID in values. It's not required to have all the keys that are in 'grouping' param. For examples: - products_by_location(..., grouping=('product', 'lot'), grouping_filters={'product': [1, 2, 3], lot=[2, 5, 6]}) - products_by_location(..., grouping=('product', 'lot'), grouping_filters={'product': [1, 2, 3]}) - products_by_location(..., grouping=('product', 'lot'), grouping_filters={lot=[2, 5, 6]}) The implementation will ensure that all grouping_filters keys are in grouping and then, will do what currently do for product_ids param (only the part where product_ids has values) but for all grouping_filters items. - quantity_domain (or other name...): a 2-tuple with the operator in first item and operand in second (if it is called from searcher of some quantity field, it could be called using the searcher domain param as: domain[1:]) The implementation will add a HAVING clause over SUM(quantity). Previously, it ensure that supplied domain make sense to be applied to quantity (like it is done in _search_quantity_eval_domain() function). To be more flexible, the values of 'grouping_filters' could also be a domain, or directly replace 'grouping_filters' by a domain... but I think it would do the implementation more complicated. -- Guillem Barba http://www.guillem.alcarrer.net
