openerp-india team mailing list archive

["Olivier Dony \(OpenERP\)" <999103@xxxxxxxxxxxxxxxxxx>]

Hi Alexandre,

The algorithm for selecting a BoM is voluntarily kept very simple in the core, based only on the product and some properties. This is an area where many manufacturing companies will need to introduce smarter algorithms, so the philosophy of OpenERP is to keep the default implementation as generic and simple as possible, but to make it very simple to extend and customize (as opposed to making a complex implementation that supports many specific algorithms but is difficult to understand and configure).
It is the case for the BoM selection, quite similarly to other areas, such as the selection of the supplier to use when purchasing goods.

Historically the _bom_find function takes an extra "uom" argument that is not used by default but made available in case a customization module needs this information to implement a more specific BoM selection algorithm. It is not a bug, but the API may feel a little bit awkward because of it.
In fact, when we define newer API methods we now try to pass higher level objects that can offer access to a broader set of "context data", rather than choosing a set of explicit values, risking to miss some important ones. Here it looks like the UoM will not be very useful unless the quantity to produce is passed too, which is not the case right now.
Now instead of passing product_id, product_uom, etc, we could pass a single procurement.order object (browse_record) that encompasses  all these values at once. This works in many cases (another example is sale.order._prepare_invoice() where we pass "order" rather than all the individual values), but it may not suit all situations. I did not investigate thoroughly but there seem to be cases where we need to find a BoM without having a specific procurement.order, so this approach may not work well here.

In any case feel free to suggest a refactoring of to the API in the form
of a merge proposal if you find a better approach (e.g. add a docstring
and an optional "qty" parameter), bearing in mind that we're trying to
keep the default implementation simple but easily extensible, and would
like to preserve backwards compatibility with any existing module (as
much as possible).

Thanks!

** Changed in: openobject-addons
   Importance: Wishlist => Undecided

** Changed in: openobject-addons
       Status: Confirmed => Invalid

** Changed in: openobject-addons
     Assignee: OpenERP R&D Addons Team 2 (openerp-dev-addons2) => (unassigned)

-- 
You received this bug notification because you are a member of OpenERP
Indian Team, which is subscribed to OpenERP Addons.
https://bugs.launchpad.net/bugs/999103

Title:
  [trunk] mrp_bom._bom_find: unused argument product_uom

Status in OpenERP Addons (modules):
  Invalid

Bug description:
  The signature of mrp_bom._bom_find has a product_uom parameter which
  is not used. I think it should be deprecated and removed altogether.
  At the very least the docstring should be fixed to say that the
  argument is ignored, but I believe some code could be simplified and
  made clearer by removing that argument recursively accross the call
  stack.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-addons/+bug/999103/+subscriptions