Sales using Secondary UoM show incorrect unit price

[Kenneth Andresen]

OpenERP version: openerp-6.1-20121004-232945
retested using runbot.openerp.com : 6_1_1953_base (as of dec 12, 2012)

Preparations:
1) On runbot selecting the base (6_1_1953_base) install the module "sale".
2) go to Sales -> Configurations -> Products -> Units of Measure -> UoM Categories
and create the new category "Area"
3) go to Sales -> Configurations -> Products -> Units of Measure -> Units of Measure
and create the new unit "m²" of UoM Category "Area" as the base unit.
4) go to Sales -> Products -> Products
and create new product "metal plate" using default unit of measure "m", Unit of sales as "m²" and UoM -> UoS Coeff = 0.95
leave price at 1.00.
(This would be typical when for example cutting metal plates that are 0.95 m wide and 3m long)

Test:
1) Go to Sales -> Sales -> Sales Orders and create a new sale
2) choose a random client and add the newly created product from our preparations i.e. "metal plate", and specify quantity = 10 m.
3) Click "Print Quotation"
Notice error in resulting PDF:
Qty is correctly set to 9.500 m², however price pr unit = 1.00, which is incorrect as that was the price for UoM, not UoS.
4) confirm the order and print final order.
Notice the same error is in resulting pdf.
5) Create the invoice
Notice the invoice got the correct unit price of 1.05, but now the total value is has changed to 9.97 instead of 10.00! This might not be a problem, though 1.05 x 9.5 = 9.975 which was expected to be rounded up rather than down.

[Ravish(OpenERP) (rmu-openerp)]

Hello,

           It has been Fixed in : lp:~openerp-dev/openobject-addons/trunk-bug-1089229-rmu
           Revno: 8504
           Revision ID: <email address hidden>

It will be merged soon with trunk

Thanks,

[Alejandro Santana (alejandrosantana)]

Looks like this was never commited into trunk. Also, the fix proposed raises an error when trying to convert a localized price into float, due to the formatLang(...) passed to get_price_objects method. This happens when that localized format uses a comma for decimal separator instead of a dot.
The problem is in:
[[ formatLang(line.price_subtotal and get_price_objects(formatLang((line.price_unit * line.product_uom_qty / line.product_uos_qty)),line.product_uos_qty) or line.price_subtotal ,digits=get_digits(dp='Account'), currency_obj=o.pricelist_id.currency_id)]]
But, even correcting this, there might be some decimal differences with the subtotal calculated on invoices, which is based solely in UoM, not on UoS.
Even more, the round method in get_price_objects rounds to unit, looks like discards any decimal (let's say decimal accuracy = 0). But prices should respect 'Account' decimal accuracy, which is normally 2.

So, the root of this bug goes deeper and will not be really well solved till UoS is well implemeted into OpenERP, which should be done in core, not in any extension module. There are even some "TO-DO" and "FIX-ME" comments in the code since, at least 6.1, never corrected. Take a look to:
    http://bazaar.launchpad.net/~openerp/openobject-addons/trunk/view/head:/sale/sale.py#L632
    http://bazaar.launchpad.net/~openerp/openobject-addons/trunk/view/head:/sale/sale.py#L827
There is where the real bug lies: a feature not completely implemented.

[Alejandro Santana (alejandrosantana)]

More info on this:

A case of use:
Description VAT Quantity Unit Unit Price Disc.(%) Price
Handful of peanuts ITAX S 10.000 g 20.00 0.00 200.00 €
Handful of peanuts (big) ITAX S 30.000 g 8.33 0.00 250.00 € <-- This should be: 30.000*8.33=249.90€

In this simple case we see how rounding methods can easily make a 0.10€ difference.

More puzzled now, checking database stored data for sales order and its following invoice:
- Sales order seem to make wrong calculations if UoS is set, because it uses subtotal = unit_price[per UoM] * uom_qty, no matter if UoS is defined. Subtotal computes 250.00€ in the case of use in my previous comment.
- It's following invoice (make invoice from a SO) actually makes calculations again, this time perfectly correct. subtotal = unit_price[per UoS] * uos_qty, thus 249.90€ in the same example.
- In a fresh customer invoice I cannot set a UoS, but only UoM or some other in the same category.

Therefore, I see that a Sale Order may not be accurate and also "secondary unit" is almost useless this way.

Anyone in OpenERP can fix this? At least make "secondary unit" useful in trunk and I would be delighted to try to backport it to 7 and 6.1.