c2c-oerpscenario team mailing list archive

[Graeme Gellatly <780413@xxxxxxxxxxxxxxxxxx>]

Amit,

I understand what you are saying but I disagree.  I have not missed
something.  Well apart from finding even worse buggy behaviour testing your
unreasonable scenario.

When it comes to dollars and cents I do not want to display 5 digits, but as
per my example I want 800 grams to cost exactly the same as .8kg.  This is
the 'correct' expectation of converting UOM that the same quantity is the
same price.  Asking everyone to change decimal accuracy to 5 is unreasonable
as then there is 5 digits all over reports.  In any event it is a worthless
workaround changing it to 5 digits and saying look problem goes away.
Because as soon as you change it to an invoice the price_unit then uses
'Account' precision so now the problem is even worse, not only does the 800
grams not equal .8kg, but 800 grams on a sales order is a different price to
800 grams on an invoice.  So what now change account precision to 5.  Just
because it can be done, does not mean it is the right approach.

The most common scenario is 2 digit currencies and conversions from kg to
grams is also fairly common, asking everyone to use 5 digits and saying this
isn't an issue is not reasonable.  Also in the case of 5 digit currencies
are you going to say they need to use 8 digits?

The problem is that decimal precision is set at price_unit hence it is
rounding too early.  So now you have another issue.  Given that the sale
order total is going to be the same as the invoice should its
decimal_precision not be Account?  Also given that the price_unit is going
to be the same as the invoice price_unit should its precision not be Sale
Price?  (excepting of course that invoices also come for purcahses but you
get the point)

Equal quantities of UOM's must cost the same no matter what the decimal
precision and document.  Besides in the examples given total price does not
have the required decimal precision, it has 2 digits but is not precise, it
is out by $3.00.  The answer is easy enough.

Calculate total price then convert it, not the other way around.
Or alternatively and equally workable is to have say unit_precision for
Purchase, Sale and Invoice price units (set to 5) and then total amount
precision for these 3 documents as 'Account'.

The other alternative is to not allow any UOM smaller than the default UOM
which is the course we will need to take until OpenERP agrees that it is in
fact an issue that the exact same amount of things costs different depending
on UOM and now with your suggested workaround whether it is an order or an
invoice..

Ask any functional person this (internally if you can) - Should the same
total quantity be the same price regardless of UOM and decimal precision?
What do you think they will say - No they should be up to 50% different, of
course not.  1 or 2 cents for rounding is fine, but $3.00?


On Thu, May 12, 2011 at 8:48 PM, Amit Parik (OpenERP) <amp@xxxxxxxxxxx>wrote:

> Hello Graeme,
>
> I have tested your scenario again.
> May be you have miss something.
>
> First you have to set digit="5" or as per requirement in sale price 's
> decimal accuracy and then check your scenario.
>
> If you not set the proper digit then it is calculate by default as a 2
> digits so it is made price by rounding.
> I have also check your issue with by 2 digit in decimal accuracy and the
> rounding are proper.
>
> If you want to proper value with decimal point in sale price with using
> this type of uom then please change the digit of decimal accuracy as per
> requirement.
>
> So would you please check it again and notify us your problem.
>
> Thanks for the understanding!
>
>
> ** Changed in: openobject-addons
>       Status: Confirmed => Incomplete
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/780413
>
> Title:
>  stab6.02- changing uom leads to erroneous price calculations due to
>  rounding too early
>
> Status in OpenERP Modules (addons):
>   Incomplete
>
> Bug description:
>  Take this scenario.
>
>  Default UOM is 1kg and the net price is 4.99 / kg on a pricelist.
>  Change it to 1000 grams in an SO  and you will see the net price is
>  $0.00.  One would expect 1000g = 1kg = $4.99
>
>  Extreme example I know, but lets say it was $14.99 per kilo, how much
>  is 1000 grams
>
>  To my mind it should be $14.99 but OpenERP says it is $10.00 if I
>  change the price to $15.00 / kg then 1000 grams is $20.00.
>
>  What about a much more realistic $44.99/kg and the guy wants 800
>  grams.  Enter 0.8 kg and you charge $35.99.  Enter 800 grams and it is
>  $32.00
>
>  IMO net total price should be the same no matter what UOM is chosen to
>  represent the quantity.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/openobject-addons/+bug/780413/+subscribe
>

-- 
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.
https://bugs.launchpad.net/bugs/780413

Title:
  stab6.02- changing uom leads to erroneous price calculations due to
  rounding too early

Status in OpenERP Modules (addons):
  Incomplete

Bug description:
  Take this scenario.

  Default UOM is 1kg and the net price is 4.99 / kg on a pricelist.
  Change it to 1000 grams in an SO  and you will see the net price is
  $0.00.  One would expect 1000g = 1kg = $4.99

  Extreme example I know, but lets say it was $14.99 per kilo, how much
  is 1000 grams

  To my mind it should be $14.99 but OpenERP says it is $10.00 if I
  change the price to $15.00 / kg then 1000 grams is $20.00.

  What about a much more realistic $44.99/kg and the guy wants 800
  grams.  Enter 0.8 kg and you charge $35.99.  Enter 800 grams and it is
  $32.00

  IMO net total price should be the same no matter what UOM is chosen to
  represent the quantity.