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 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...
>
> ** Summary changed:
>
> - [PS] It is possible to encode product with prices in two different
> currencies within the same Sales Order
> + [PS] Mixing Pricelists in Sale Orders may result in incorrect prices
>
> --
> You received this bug notification because you are subscribed to OpenERP
> Addons.
> https://bugs.launchpad.net/bugs/782168
>
> Title:
>   [PS] Mixing Pricelists in Sale Orders may result in incorrect prices
>
> Status in OpenERP Modules (addons):
>  Confirmed
>
> Bug description:
>   When writing a sale order, it is possible to use multiple pricelists,
> even ones with different currencies.
>  When doing the latter, the final prices are incorrect, because they were
> expressed in different currencies.
>
>  Solving this in a fool-proof manner is quite difficult.
>
>  However, one possible thing to improve for this use case is to modify the
> tooltip on the pricelist field to warn the users about this.
>  We could use 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!"
>
>
>  ===== original description for reference (suggested solution invalid)
> ============
>   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
>