openerp-india team mailing list archive

[Graeme Gellatly <932586@xxxxxxxxxxxxxxxxxx>]

Hi,

I've had a look at this issue, and simply the easiest way to resolve it
is to remove _get_uom_id and default on uom in sale.order.line.

This will fix 99% of the times this issue occurs, which is when creating
a new orderline with a uom in unit category.

The only time downside is by removing the default is when not entering a
product_id and manually using description field and a new order line
which is a far rarer case, and even then the only issue is the user has
to manually specify the UOM which is a very minor inconvenience.

The other 1% of cases, which is changing the product_id of an existing
order line, where the new product and old product share the same uom
category but not the same uom I think is OK and desired behaviour, and
rare enough.  Note that this is already the existing behaviour and not
introduced by removing the default.

Also I found another impact of this bug which is quite serious.  If you
have a UOM of say box of 500 then when you enter the new order line, by
defaulting to PCE the UOM conversion makes the price 0.00.

-- 
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/932586

Title:
  [trunk][sale] error in how _get_uom_id and product_id_change interact

Status in OpenERP Addons (modules):
  Confirmed

Bug description:
  Tested with new database, demo data, just stock and sale installed.

  A sale order line sets the default uom to PCE as per _get_uom_id.  Now
  when the product id is changed if its default UOM is in the same
  category (unit) the uom is not changed as the uom from _get_uom_id is
  passed.

  To test is easy, create a new UOM called Piece in the Unit category
  and change ARM100 to use Piece.

  Then enter a salesorder and enter the line ARM100 and you see PCE
  instead of Piece.

  To prove it is get_uom_id is obvious but if you must just change its
  return to False and restart and retest and you now see correct uom.
  Now the problem is caused by the following couple of bits of code in
  product_id_change but they actually do something useful.

          if uom:
              uom2 = product_uom_obj.browse(cr, uid, uom)
              if product_obj.uom_id.category_id.id != uom2.category_id.id:
                  uom = False

  in that if you change a product it doesn't change the uom already set
  unless it is in a different category which would be really annoying if
  it did.  I can see no way to detect this case based on the current
  parameters passed to onchange whether it is just the default entry or
  not.

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