[PS] UoS not taken into account on the Sales Order Line

[Harmel Delphine (OpenERP)]

trunk, revno 3377

Using demo date, define a UoS for product [CPU2]. This UoS is in PCE with a coefficient of 4 (it means we sell by quantity of 4 products)

* Sales/Sales/Sales Order, create a Sales Order and on a Sales Order line select [CPU2].

Obtained result : the system takes the correct qty for UoM and UoS but still use the Qty(UoM) for the price calculation

Expected result : the system takes the Qty(UoS) to calculate the total for the Sales Order line

reported by dha, OpenERP Prof. Services

[Tom (tompower2)]

I believe I have ran in to this bug also. e.g

Length of steel bar with a UoM of PCE. Sale price for PCE is £100

UoS is defined as m with a coefficient of 7.

I then generate a sale order line for this steel bar using a UoS of 3 meters

I would expect to see the Unit price as 100/7 so ~£14.29. But it is still using a unit Price of £100 but it comes to the same sub total of;

£14.29*3 = 42.86

[Meera Trambadia (OpenERP) (mtr-openerp)]

Hello,

I have checked as per the scenario mentioned in the bug.
Under normal condition when you create a SO it gives the correct qty for Uom and Uos but it considers Uom into price calculation.
Even for the Warehouse management it creates picking based on the Uom qty.
While creating an invoice it takes "Uos" into account for the price calculation.

I think we require expert's suggestions here.

Thanks,
mtr

[Mustufa Rangwala (Open ERP) (mra-tinyerp)]

If its bug we can achieve it using:

add a field price_unit_uos
- update it on change product and unit price
- use it in report if there is a uos

So for moment we keep it as wishlist.
expert's suggestions are welcome.

Thanks,
Mustufa

[Maxime Chambreuil (http://www.savoirfairelinux.com) (max3903)]

If the product has a UoS, I suggest using the quantity in that unit times the unit price to get the subtotal.

If you decide to use UoS, it means your sale unit price is against that UoS, not the UoM.

[Maxime Chambreuil (http://www.savoirfairelinux.com) (max3903)]

This bug has been opened during a year and half. Can we do something about it and move forward ?

Thanks.

[Ferdinand (office-chricar)]

you may want to try
this offers some advantages over the (wired) standard behaviour
http://bazaar.launchpad.net/~c2c/c2c-rd-addons/trunk/files/head:/sale_uos_entry/

[Raúl U (ruria)]

Ferdinand, the link is broken.

Maxime, I agree with you. Mustufa, I don't agree with you.

To me this thing is clear, if I buy in UoM, my buying prices are releated to UoM. If I sell in UoS, my selling prices are releated to UoS. Even more, sale_margin module agree with me, with us really, Maxime ;-)

If you make an order with UoS, margin is calculated on uos_qty * unit_price, but line subtotals are calculated by uom_qty * unit_price !!! What a mess !!

There is not easy workarround, adding a field is not a solution because this is not a problem with Sale Order Report/ Invoice Report. It's a problem with untaxed amount, taxes amount, total amount... all the invoice is wrong (for me)

I wondered how this can be in wishlist.

[Nhomar - Vauxoo (nhomar)]

IMHO UoS feature is a bg mess since several versions ago.

For sure i was solved some issues in differents ways, but we need a
consistent logic, no matter it is wrong or ok, it must be consistent.

IMHO, we should know from OpenERP itself what is the correct way to use
this feature in all openerp because i didn't find yet a "Correct" way to be
consistent enought and documentation is not complete in this topic.

Regards.

2013/3/18 Raúl U <email address hidden>

> Ferdinand, the link is broken.
>
> Maxime, I agree with you. Mustufa, I don't agree with you.
>
> To me this thing is clear, if I buy in UoM, my buying prices are
> releated to UoM. If I sell in UoS, my selling prices are releated to
> UoS. Even more, sale_margin module agree with me, with us really, Maxime
> ;-)
>
> If you make an order with UoS, margin is calculated on uos_qty *
> unit_price, but line subtotals are calculated by uom_qty * unit_price
> !!! What a mess !!
>
> There is not easy workarround, adding a field is not a solution because
> this is not a problem with Sale Order Report/ Invoice Report. It's a
> problem with untaxed amount, taxes amount, total amount... all the
> invoice is wrong (for me)
>
> I wondered how this can be in wishlist.
>
> --
> You received this bug notification because you are subscribed to OpenERP
> Project Group.
> https://bugs.launchpad.net/bugs/751491
>
> Title:
> [PS] UoS not taken into account on the Sales Order Line
>
> Status in OpenERP Addons (modules):
> Confirmed
>
> Bug description:
> trunk, revno 3377
>
> Using demo date, define a UoS for product [CPU2]. This UoS is in PCE
> with a coefficient of 4 (it means we sell by quantity of 4 products)
>
> * Sales/Sales/Sales Order, create a Sales Order and on a Sales Order
> line select [CPU2].
>
> Obtained result : the system takes the correct qty for UoM and UoS but
> still use the Qty(UoM) for the price calculation
>
> Expected result : the system takes the Qty(UoS) to calculate the total
> for the Sales Order line
>
> reported by dha, OpenERP Prof. Services
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openobject-addons/+bug/751491/+subscriptions
>

--
--------------------
Saludos Cordiales

Nhomar G. Hernandez M.
[phone]
Skype: nhomar00
Web-Blog: http://geronimo.com.ve
Servicios IT: http://vauxoo.com
Linux-Counter: 467724
Correos:
<email address hidden>
<email address hidden>
twitter @nhomar

[Ana Juaristi Olalde (ajuaristio)]

I can tell you how this is made in other systems.
Everything begins with meaning of UOS (old discussion from 5.0 version). For me UOS is not sales unit but second unit for product.

Units are just the same than currencies. Supose 1 unit UOM, 100kg UOS, the meaning is that 1 unit is 100kg exactly the same that 1€ is 1,23$
About the price is the same, you might have a unit price X for UOM so you have got direct relation on UOS price. The example before, suposed to be 1unit=100kg, if 1 unit is 10€ then 100kg = 10€ then 1kg = 10€/100kg = 0,01€

So... it should be exactly the same selling or buying 1unit or 100kg and unit price should not be different on that case. So.. if you sale 50kg for that product unit price should be calculated using UOS but it will be the same if you put 0,5 units. So... the mistake is making calculation thinking about UOS as SALE UNIT and not SECOND UNIT.

Next questions is the unit you sale, the unit you store and the unit you buy. Usually the unit you buy use to be the same that the unit you store but could be different.
So on product form should be the option of setting that and it's there. So... It's no sense that UOS is shown in sales order line. Only the Sales Unit should be shown and the calculation should be made only if store or basis unit of product is different for sale unit and store unit on product form.
Same way, creating the picking should take in mind if sales unit and store unit are different, conversion should be made on creating picking.
Just the same on procurement and creating purchase order.
Just the same on creating incoming picking.
It would be perfectly possible managing all documents in 2 or three measure units (just the case where 3 are different) but at last should be possible managing 2 measure units.
----
The last case is when relation between UOM and UOS(taken as Second measure unit) can not be set with a formula. That's the case of food, when 1kg fish could be 10units or 12 units or even any kind of units. This are variable unit conversions.
On that case it's not possible calculating incoming units or purchasing units so it's necesary that user includes manually the number of units and kg on incoming or outgoing.
Thats only posible if ALL related documents have got both(or three) fields (Sale unit, store unit and purchase unit) and related(calculated) prices for each of them.

My 2 cents.