Discount Error

[DunDes LLC]

Hi, I keep seeing issues when checking-out with a coupon code (25% off). I always get this error: "There was a problem processing your order, please try again or contact the store administrator." We are running Joomla 3.3.6 with VM 3.0.6.2.

Talking to PayPal they see an error on their end "10413 which is "The totals of the cart item amounts do not match order amounts.""

Looking at the checkout page I can see the final amount has been rounded up one penny (see image). This only happens when applying the coupon code. Not sure why.

This is throwing off credit cards for people trying to purchase. I've been playing with the shop but am frustrated because I cannot figure out where to fix the issue. Help!

Mod edit:  bump message removed. Please read http://forum.virtuemart.net/index.php?topic=104795.0

[Milbo]

There is an option, round by display or round by item in the vm config. Just select another. Btw, the result of your Coupon discount is "499.5 and the total is 20.985.

I talked quite often with paypal about it, also with other companies. They do round not correct, yes unbelievable, but you can recalculate yourself. The problem is that they recalculate the result their own way, but do it wrong. Other companies added now an option, as we have already.

[DunDes LLC]

Thats odd!
How do I change to Round by Item?
Here is what I see (see attached).

[Milbo]

Disable "round only display"

[DunDes LLC]

I did this but still get the error. 

[Milbo]

So where is the exactly the 1 cent difference? What does paypal expect?

[DunDes LLC]

Here is what PayPal said:

"In regards to your cart's response, I ran a test myself and I think it's more that we don't change the numbers we receive when we are sent.   In the last example 20.99 = 20.98.  If your system is sending something like 20.985 our system is simply taking 20.98 and ignoring everything after that second decimal place.   Unfortunately I didn't think about it before if you sent 20.985 for example I can't see that in my log as our system ignores everything after the 2nd decimal place.  In order for it to properly work the rounding would need to be performed before the information is sent to PayPal."

[DunDes LLC]

Thoughts?

[Jörgen]

Hello

Normally You save as much significant digits as You can. But You can´t send more digits to for example paypal than they can handle. In this case it seems that paypal gets more digits than they will use. If everything is going to work 100 % correct then every number that is displayed in the invoice must be rounded and fixed. Showing a rounded figure and calculating with a number that has more digits is not good. I will give a very simple exmple.

We have four items:
Item       Actual price    Displayed price
Item_1   €1,234           €1,23
Item_2   €2,344           €2,34
Item_3   €3,444           €3,44
-------------------------------------
Total      €7,022           €7,01

There will be a difference when adding these prices €0,022.
The correct way is to add the ROUNDED prices not the actual prices. The same thing applies when sending data to another company. If you display the curency with two decimals, you should always use the rounded result in the following calculations. The price is €1,23 not €1,234. The value must be rounded and used for further calculations.

You can´t use the unrounded intermediate results if the rounded price is used and displayed anywhere in the invoice. I understand that the calculation is not easy and different number of decimals are used for different currencies. Sending a number of rounded prices together with a sum that is not calculated with these rounded prices will result in trouble and visible rounding errors.

All the prices that are used in the calculation must be rounded to the same number of decimals that are used for displaying the prices and the grand total.

just my 2 cents

Jörgen @ Kreativ Fotografi

[DunDes LLC]

Okay, this stuff is way over my head. All I know is VM has been giving me issues constantly. There is this rounding issue, the payment options disappeared by themselves and there is an issue with being able to choose a separate shipping address. This is just too much to handle. I've already scrapped one Joomla ecommerce (JoomShopping) for issues and now I'm having issues with VM. I'm in need of some serious help. Does VM offer any assistance or paid support that would be willing to log into the site and checkout the code on the server and make things right?

[jenkinhill]

? http://extensions.virtuemart.net/support/virtuemart-supporter-membership-detail

[AH]

Okay, this stuff is way over my head. All I know is VM has been giving me issues constantly. There is this rounding issue, the payment options disappeared by themselves and there is an issue with being able to choose a separate shipping address.

It is a shame that you are having issues - but that is the joy/challenge of open source systems/web development.  You get to go hands on.

So you have three things that you cannot figure out

Rounding issue -  I am confused as to why you are not just sending paypal a single payment amount - using hosted payment - they do not need to see any cart line detail.
Things do not just "disappear by themselves" - something must have changed - work out what and change it back.
Separate shipping address - from what I can tell these work perfectly well in the code I am currently testing.  Only the devs can tell when this will be released.
In another post you note that

I'm getting beat up by my clients over this.

I trust that this is only an issue in a test environment and that this is only delaying live deployment.

As jenking notes
http://extensions.virtuemart.net/support/virtuemart-supporter-membership-detail

This may help, but it is not a dedicated support ticket for your site to be "fixed"

[DunDes LLC]

Nope, I tested this in a test environment before going live. This seems to be something that just popped in there during an update I'm guessing.

[AH]

This seems to be something that just popped in there during an update I'm guessing.

"just popped in"  means that someone update the system in either LIVE and/or a test environment.

The system does not auto update.

[Milbo]

Jörgen,
its wrong. and you seem to ignore what I wrote. That makes me upset

Normally You save as much significant digits as You can.

No, the amount of digits is quite fixed. http://en.wikipedia.org/wiki/Floating_point, we have float and double, thats it.

But You can´t send more digits to for example paypal than they can handle.

Not paypal, your currency is the limit!

In this case it seems that paypal gets more digits than they will use. If everything is going to work 100 % correct then every number that is displayed in the invoice must be rounded and fixed.

No, where is the law for that? It is your idea of it, but not the reality.

Your answer makes me so upset, because you completly ignore the knowledge already given and you completly ignore the already given answer.

Showing a rounded figure and calculating with a number that has more digits is not good. I will give a very simple exmple.

ah nobrainer, "is not good" but "inevitable" => we call that the hard reality.

We have four items:

blablabla ....

There will be a difference when adding these prices €0,022.

This is all known and explained. Seems you completly ignore what I wrote many, many times. You seem even to ignore my answer in this threat

There is an option, round by display or round by item in the vm config. Just select another. Btw, the result of your Coupon discount is "499.5 and the total is 20.985.
.....Other companies added now an option, as we have already.

So as long you ignore that vm has a switch for it, .... And it is really useless to explain, how it works and to demand the other mode, if you did not even found or noticed the switch. Got it? You are like someone coming in and explaing that an engine works with gas, but the discussion is already if we use gas or diesel.

The correct way is to add the ROUNDED prices not the actual prices. .....
You can´t use the unrounded intermediate results if the rounded price is used and displayed anywhere in the invoice.

Again, where is the law. Where is the theory behind that?

Jörgen, I am sorry, but what is your profession? Are you a mathematician? a physics? an engineer? a bookeeper? tax consultant?

Small example, I sell screws for 1 cent and 20 % VAT. If I follow your way Jörgen, I do not have to pay any tax. The reality is that you can show
[1 cent (netto) + 0 cent (tax)] * 100 => 1.20 euro (incl. 0.20 cent tax)
and that is correct that way, because the tax officials only look on the 1.20 and the 0.20 euro


Do you really think that you do not have to pay tax then? Your way would be (1 cent + 0 cent) * 100 => 1.00 euro + 0 tax
So the method how to write the invoice, changes the result? Nonono,...

LoLz! and maybe you should take a look on the swizz. VM is even supporting the rounding on 0.05.

But I really sick of explaing 6. class math again and again. I wrote it often enough down here and VM is as far as I know the only ecommerce system with a switch. If someone wanna tell what todo to avoid the error by paypal, I must see that the knowledge is there.

and it is not solveable, mathematical proven, Jörgen.
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."

http://en.wikipedia.org/wiki/Distributive_property
"Distributivity and rounding
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."


I am really gentleed up, that paypal dont want to learn how it works. VM calculates more exact then some banks and more exact then paypal, that is the reality.


We could also call it B2C rounding and B2B rounding. But I can assure you, that the tax officials look on your final result, NOT the steps in between.