[PS] Mixing Pricelists in Sale Orders may result in incorrect prices

I reported this 5 months ago that the rule needs to be enforced.

The rule is 1 pricelist per order (which can be broken to be told no that
despite the fact pricelist is many2one with sales order and not m2m, you can
choose to change halfway through which is dubious (although OpenERP kindly
created sale_pricelist_recalculation module for me to fix thank you again).
Otherwise forget the fact that you have 2 currencies, how do you even know
which pricelist you used for which line. To see why this is dubious go back
to the first line you created and change the qty, remebering you set it in
Euro, look now it is in $.

To follow your logic through not only do you need to change sale order, but
also purchase order and invoice at the very least.

Besides in the real world who honestly places a single order in 2 different
currencies? The expected result should be to not allow this behaviour IMO

On Sat, May 14, 2011 at 12:12 AM, Harmel Delphine (OpenERP) <
<email address hidden>> wrote:

> Public bug reported:
>
> trunk server revno 3411
>
> having another pricelist in $ (for example)
>
> * Sales/Sales/Sales Orders, Create a sales order using the public pricelist
> (in €)
> * Add a sales order line, for example CPU1 (for a unit price of 75€)
> * change the pricelist on the sales order and select the pricelist in $
> * Add a sales order line, for example CPU1 (for a unit price of 75€
> converted into $ = 96.26$)
> * Click on compute on the sales order line, total = 171,26
>
> Obtained result : there is no difference between product in $ and €,
> moreover the total just make the sum of the two prices !
>
> Expected result : we should see that a price is in € and the other in $
> (add a column on the sales order line) and the total must be the sum of
> all prices in € or all prices in $ not a mix of the two
>
> reported by dha, OpenERP Prof Serv
>
> ** Affects: openobject-addons
> Importance: Medium
> Assignee: OpenERP R&D Addons Team 3 (openerp-dev-addons3)
> Status: Confirmed
>
>
> ** Tags: profserv
>
> ** Changed in: openobject-addons
> Assignee: (unassigned) => OpenERP R&D Addons Team 3
> (openerp-dev-addons3)
>
> --
> You received this bug notification because you are subscribed to OpenERP
> Addons.
> https://bugs.launchpad.net/bugs/782168
>
> Title:
> [PS] It is possible to encode product with prices in two different
> currencies within the same Sales Order
>
> Status in OpenERP Modules (addons):
> Confirmed
>
> Bug description:
> trunk server revno 3411
>
> having another pricelist in $ (for example)
>
> * Sales/Sales/Sales Orders, Create a sales order using the public
> pricelist (in €)
> * Add a sales order line, for example CPU1 (for a unit price of 75€)
> * change the pricelist on the sales order and select the pricelist in $
> * Add a sales order line, for example CPU1 (for a unit price of 75€
> converted into $ = 96.26$)
> * Click on compute on the sales order line, total = 171,26
>
> Obtained result : there is no difference between product in $ and €,
> moreover the total just make the sum of the two prices !
>
> Expected result : we should see that a price is in € and the other in
> $ (add a column o...

Hello Harmel Delphine,

The fix has been committed on : lp:~openerp-dev/openobject-addons/trunk-bug-782168-uco with revision 4715 <email address hidden>.

It will be merged into main addons soon.

Thanks.

Hi,

I am so glad you went this way to fixing it, much more sensible, enforcing
one pricelist per order.

However, there is a major bug in your code. What if the user changed the
price manually? You will overwrite all his manual changes. I think you
would be better implementing this in an onchange pricelist function.

On Thu, May 19, 2011 at 11:18 PM, Ujjvala Collins (OpenERP) <<email address hidden>
> wrote:

> Hello Harmel Delphine,
>
> The fix has been committed on : lp:~openerp-dev/openobject-addons/trunk-
> bug-782168-uco with revision 4715
> <email address hidden>.
>
> It will be merged into main addons soon.
>
> Thanks.
>
> ** Changed in: openobject-addons
> Status: In Progress => Fix Committed
>
> --
> You received this bug notification because you are subscribed to OpenERP
> Addons.
> https://bugs.launchpad.net/bugs/782168
>
> Title:
> [PS] It is possible to encode product with prices in two different
> currencies within the same Sales Order
>
> Status in OpenERP Modules (addons):
> Fix Committed
>
> Bug description:
> trunk server revno 3411
>
> having another pricelist in $ (for example)
>
> * Sales/Sales/Sales Orders, Create a sales order using the public
> pricelist (in €)
> * Add a sales order line, for example CPU1 (for a unit price of 75€)
> * change the pricelist on the sales order and select the pricelist in $
> * Add a sales order line, for example CPU1 (for a unit price of 75€
> converted into $ = 96.26$)
> * Click on compute on the sales order line, total = 171,26
>
> Obtained result : there is no difference between product in $ and €,
> moreover the total just make the sum of the two prices !
>
> Expected result : we should see that a price is in € and the other in
> $ (add a column on the sales order line) and the total must be the sum
> of all prices in € or all prices in $ not a mix of the two
>
> reported by dha, OpenERP Prof Serv
>

Hello Ujjvala,

we should have onchange on price list field instead of doing on compute button.

Thanks,
mra

As I commented on the merge proposal, I'm afraid the bug description is not correct, and the alternative suggestions aren't either.
Let me explain. The original bug description is incorrect because it makes no sense to mix different currencies within a single sale order, and we certainly don't want to allow that.
The alternative suggestions using on_change triggers to recompute the amounts are not correct either, for 2 reasons:
- We currently support using multiple pricelists (same currency) during the process of recording a sale order, in case a salesman needs to mix pricelists. Thus when changing pricelists, we do NOT want to alter the already entered prices (not even recompute them), as they really are supposed to be using a different pricelist!
- Now, even if we imagined a selective on_change recompute (one that would recompute prices only if the new pricelist's currency is different), this would be: 1. Hard to implement technically, because on_change triggers can't access the previous value. 2. A very counter-intuitive behavior ; how are users supposed to guess that choosing some pricelists will cause their entire prices to be altered, while some won't do anything?

OpenERP should not handle automatically all exception cases, because there is no safe way of doing that. As you can see, if we decided to enforce one behavior (e.g. automatic recompute), there would be users who would need the opposite behavior, and thus would see the fix as a bug/regression!

I see one possible thing to improve for this use case, however: we could modify the tooltip on the pricelist field to something like:
"The selected pricelist will provide suggested prices for products, and its currency will determine the currency of the sale order.
 If prices from multiple pricelists need to be mixed, select the appropriate pricelist before adding the corresponding products.
Warning: do not mix pricelists with different currencies, as that would likely result in incorrect prices!"

I hope my explanation is clear...

(correcting importance after re-evaluation of the issue)

Olivier,

Hi

While I can accept your explanation and have before, and the module
sale_pricelist_recalculation exists it still doesn't clear the underlying
issue.

FYI regards. It makes no sense to mix different currencies on an SO. While
I agree it makes no sense to me, for some reason SAP allowing PO's in
multiple currencies seems popular (but they don't allow for SO's), so to
someone it makes sense.

Imagine we don't select on on_change recompute, and we save our order and
later someone else or us for that matter opens the order. What pricelist
was charged at what line? What if they change the quantity? Now it is at a
different pricelist? Did the salesperson use the correct pricelist? How do
I know which pricelist was used? Hardly intuitive either. Also it allows
for fraud that is very difficult to detect. Just slip in a few items in the
middle of an order at another lower pricelist, and then change it back. How
does someone catch that in OpenERP.

 If each line is allowed its own pricelist then we must store pricelist
information at the order line, because your argument against on_change
becomes invalid, every time a line is amended, say change qty, or uom it
accesses not the pricelist it was created with, but the pricelist of the
moment. Now if you argue to change it back, to the original before
changing, well how do I know what that is?. The expected behaviour of a
field in a Sales Order header is that it affects every order line.

If a salesperson needs to mix 2 pricelists he has a few other choices which
are a bit more robust.
Create a third pricelist - if it is going to happen often. Mixing the
previous 2 there. For me this is preferred solution, and in fact now that I
think about is what I am going to force on my users, That way their can be
no doubt what price is charged for what and on_change won't break prices set
with a previous list.
If it is just a couple of items - then use the discount field. onchange
doesn't affect it.

Finally, technically it would be possible to have an onchange function that
explains all this as a warning rather than a tooltip, as users are more
likely to see a warning - raise the warning if and only if the order already
has 1 or more lines.

On Tue, May 24, 2011 at 5:03 AM, Olivier Dony (OpenERP) <
<email address hidden>> wrote:

> As I commented on the merge proposal, I'm afraid the bug description is not
> correct, and the alternative suggestions aren't either.
> Let me explain. The original bug description is incorrect because it makes
> no sense to mix different currencies within a single sale order, and we
> certainly don't want to allow that.
> The alternative suggestions using on_change triggers to recompute the
> amounts are not correct either, for 2 reasons:
> - We currently support using multiple pricelists (same currency) during the
> process of recording a sale order, in case a salesman needs to mix
> pricelists. Thus when changing pricelists, we do NOT want to alter the
> already entered prices (not even recompute them), as they really are
> supposed to be using a different pricelist!
> - Now, even if we imagined a selective on_change recompute (one that would
> recompute p...

Hello,

Revision ID: bde@tiny2-desktop-20110607125444-219rhbu9vlnc4b3r
Revision Number : 4730

The tooltip has been changed as per Olivier Dony's suggestion. It will be merged in trunk soon.

Thanks & Regards
Devnani Bharat R.