Odoo Addons (MOVED TO GITHUB)

critical bug: 'unit price' doesn't mean the same thing in sale order and in invoice!

Bug #308813 reported by Raphaël Valyi - http://www.akretion.com on 2008-12-17

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	Odoo Addons (MOVED TO GITHUB)	Won't Fix	Undecided	Unassigned

Bug Description

In sale order, in a sale_order line, the unit price is the price after taking into account the pricelists. For instance, If I offer 20% of promo for all products, with demo data, PC1 has a unit price of 360 euros in a sale order line, this fine.

Now, if I create an invoice from this order or from it's packing, the unit price an total price will be correctly propagated, fine again.

BUT, if in the created invoice, I add an other line with a PC1, now the 'unit price' is 450 euros: that is the listed price. Pricelist are not taken into account, this means what the same 'unit price field means is not homogeneous from an order line to an invoice line. Also, it's hardcoded in the invoice to take the listed price. Meaning that if you base your price on an other field (like if you want a 'constant' dollar price as well for the product, then it won't use that field here while it would use it (part of the pricelist) in the sale order. See attached capture where you can compare the two lines. Also notice that the product description is not homogeneous either which is confusing too.

I think you'll have to byte the bullet and correct that. You'd better do it before v5 I think because else people will be angry if you change something that important and central later on.

A simple fix would be the invoice line take the pricelists into account too or call that field something else, but then customers will find it strange you present an invoice where they don't find the sale order terms.

By the way, we think there is a more profound flaw here, we mean a business flaw in lots of situation:
Indeed: suppose I'm offering 20% discount in the pricelist to my 'gold customers' and then may be the salesman might offer some 3% extra discount exceptionally (using the discount field in sale_order_line. With the current OpenERP, natively, you'll only print a 3% discount in the sale order (and invoice if made from the order, avoiding that bug we describe).

But commercially speaking, lot's of us think that: since you agree a 20% discount, then you should be given the opportunity to make some benefit out of that sacrifice: meaning in term of image it's often good to state clearly that you are doing a 20% discount (plus may be 3% extra) both on the sale order and invoice. But since currently you are not copying the product listed price on the sale_order line: it's just very difficult (but we did it) to compute those 20% while mainaining the current line amount computation system, including the native discount field and our ability to change the overall discount exceptionally (but still without writing in the product listed price or pricelists).

-> Your sale line amount computation could include one more abstraction around the listed price that might be copied into the sale_order_line/invoice_line (so we might change how much it looks exceptionally) and one or two discounts that will take into account the pricelist discount. Basic usage would look the same, but you could easily and cleanly activate an editable discount taking the pricelist discount into account.

We made a system for us based solely on computed fields (without altering the native datamodel) and using the native discount field but making it a computed field with function + inverse function (as introducing a second editable discount pricelist aware would have changed the line amount computation with unknown risky consequences) but it was hard to design, especially workarounds with delivery costs for instance where 'unit price' should keep its ability to be set manually while offering the explained system... I mean lot's of users might be interested in having a strong native system here.

Hope you can fix the bug and may be think about the discount pricelist idea, making what is possible to help here for the v5 time window (so you probably can't have that full blown system unfortunately).

Raphaël Valyi