custom price in a sale.order.line gets lost

[Leonardo Pistone]

Observed in OE 6.0 and trunk rev 4613.

To reproduce: create a new SO, new sale.order.line, enter a custom price. Then save and change the quantity of that product. Unit price is reset to the standard unit price (from the pricelist of whatever).

Possible solution: the uom_qty field shouldn't have on_change (product_id_change). Or it should have its own onchange function that does the right thing.

[Azazahmed Saiyed (OpenERP) (saz-openerp)]

Hello Leonardo,

Yes you are right that when we apply custom price in sale line it does not reflected with the changed quantity as it is consider the default unit price due to the on change method.

The on change written for setting different values according to product for fast encoding of sale lines. So if you want to overcome this problem then you have to customize the unit price every time you wanted to change the quantity.

Thanks.

[Lorenzo Battistini (elbati)]

Hello Azazahmed Saiyed,

could you please explain the reason of using

on_change="product_id_change...

for the field

"product_uom_qty"

see: http://bazaar.launchpad.net/~openerp/openobject-addons/trunk/view/4614/sale/sale_view.xml#L133

[Leonardo Pistone (lepistone)]

The discussion on #745795 (not exactly a duplicate) is relevant here.

[Leonardo Pistone (lepistone)]

Typo: the discussion on #754345 is relevant here.

[Lorenzo Battistini (elbati)]

I'm answering to myself: I think using that method (product_id_change) for "product_uom_qty" to be correct.

Since the unit price computation is based on pricelist rules that can involve the sold quantity, the unit price should be computed every time the quantity changes.

For me, this is not a bug

[Graeme Gellatly (gdgellatly)]

That is precisely the reasoning I use to clients. If they offer a special
price on a line then configure it as a discount. This is not changed by any
on_change in sale order.

On Sat, Apr 9, 2011 at 1:41 AM, Lorenzo Battistini - agilebg.com <
<email address hidden>> wrote:

> I'm answering to myself: I think using that method (product_id_change)
> for "product_uom_qty" to be correct.
>
> Since the unit price computation is based on pricelist rules that can
> involve the sold quantity, the unit price should be computed every time
> the quantity changes.
>
> For me, this is not a bug
>
> --
> You received this bug notification because you are subscribed to OpenERP
> Addons.
> https://bugs.launchpad.net/bugs/745795
>
> Title:
> custom price in a sale.order.line gets lost
>
> Status in OpenERP Modules (addons):
> Confirmed
>
> Bug description:
> Observed in OE 6.0 and trunk rev 4613.
>
> To reproduce: create a new SO, new sale.order.line, enter a custom
> price. Then save and change the quantity of that product. Unit price
> is reset to the standard unit price (from the pricelist of whatever).
>
> Possible solution: the uom_qty field shouldn't have on_change
> (product_id_change). Or it should have its own onchange function that
> does the right thing.
>

[Leonardo Pistone (lepistone)]

Azazahmed, Lorenzo, Graeme,

looks like we agree we can leave things as they are. Thank you all anyway for the discussion.

still, what about adding a line or two of comment in the code to clarify this? ))

[Christophe CHAUVET (christophe-chauvet)]

Hi

The on_change on product_uom_qty is usefull, i explain why

if i have one quantity with uom "Month" when i change the UOM to "Year", the price_unit must be recompute.

It' not a bug.

Regards,

[Alexis de Lattre (alexis-via)]

We need an on_change on product_uom_qty of course, but I think it should call a specific function product_uom_qty_change and not product_on_change ! These two functions could share some code of course, via some common subfunction.

Here is why. Consider this scenario :
1. Add a new sale order line and select a product that has a "Sale description". The "sale description" is copied in the "Notes" tab.
2. Personnalize the description.
3. Go back to the first tab and change the quantity.
4. If you go again in the "Notes" tab, you see that your personnalisation of the description has been lost.

It's an important usability issue. I have some customers complaining about this.