Total price not correct when we put high +% mark up in "tax & calculation rule"

[jlover]

Hi,

please help.
it happen many time to my customer.

they got correct unit price but wrong total price in invoice.

those customer in my list is in special price (high markup) group.

For example, at 20% marked up, unit price 122 euro, total price 2 units will come out at 245 euro shown in cart and invoice. it should be 244.

when I reduce marked up to 0% the total price is correct.

is it a bug?

Thank you.

[jenkinhill]

Sounds like a case of computer maths with rounding. What was the original price before the 20% markup?

[jlover]

Dear jenkinhill

the original price is 102 euro.

j3.4.0
vm 3.0.4

[GJC Web Design]

Are you not using cents?

102 + 20% = 122.40

122.40 x 2 = 244.80

rounded to nearest euro = 245

[jlover]

Dear GJC Web Design

thanks. I see it is computer rounding problem.

since my product sale small quantity. so customer don't want to trade in cents.


possible to have option for rounded calculation?

seem the total value will take the calculated value not display value.

thanks.

[Milbo]

Yes, there is an option.

You can use the mathematical correct method, as you have NOW ! !

As always if this topic come up, it is a shame for our society. The associative law does NOT work for rounded numbers http://en.wikipedia.org/wiki/Associative_property
"In contrast to the theoretical counterpart, the addition of floating point numbers in computer science is not associative, and is an important source of rounding error."

and http://en.wikipedia.org/wiki/Distributive_property
"In practice, the distributive property of multiplication (and division) over addition may appear to be compromised or lost because of the limitations of arithmetic precision. For example, the identity ⅓ + ⅓ + ⅓ = (1 + 1 + 1) / 3 appears to fail if the addition is conducted in decimal arithmetic; however, if many significant digits are used, the calculation will result in a closer approximation to the correct results. For example, if the arithmetical calculation takes the form: 0.33333 + 0.33333 + 0.33333 = 0.99999 ≠ 1, this result is a closer approximation than if fewer significant digits had been used. Even when fractional numbers can be represented exactly in arithmetical form, errors will be introduced if those arithmetical values are rounded or truncated. For example, buying two books, each priced at £14.99 before a tax of 17.5%, in two separate transactions will actually save £0.01, over buying them together: £14.99 × 1.175 = £17.61 to the nearest £0.01, giving a total expenditure of £35.22, but £29.98 × 1.175 = £35.23. Methods such as banker's rounding may help in some cases, as may increasing the precision used, but ultimately some calculation errors are inevitable."

Actually 6. class, you are not the only one doing this error, even big payment providers do it.

This happens when the wife of the main developer is a Dr. Maths :-) So VM supports even both methods. Go in your vm config, to the pricing tab and disable the "round only display" option. Vm uses for internally up to 8 digits.