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
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.
Thats odd!
How do I change to Round by Item?
Here is what I see (see attached).
Disable "round only display"
I did this but still get the error. :(
So where is the exactly the 1 cent difference? What does paypal expect?
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."
Thoughts?
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
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?
? http://extensions.virtuemart.net/support/virtuemart-supporter-membership-detail
QuoteOkay, 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
QuoteI'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 (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"
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.
QuoteThis 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.
Jörgen,
its wrong. and you seem to ignore what I wrote. That makes me upset
Quote from: Jörgen on March 05, 2015, 19:30:39 PM
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.
Quote from: Jörgen on March 05, 2015, 19:30:39 PM
But You can´t send more digits to for example paypal than they can handle.
Not paypal, your currency is the limit!
Quote from: Jörgen on March 05, 2015, 19:30:39 PM
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.
Quote from: Jörgen on March 05, 2015, 19:30:39 PM
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.
Quote from: Jörgen on March 05, 2015, 19:30:39 PM
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
Quote from: Milbo on March 03, 2015, 18:15:13 PM
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.
Quote from: Jörgen on March 05, 2015, 19:30:39 PM
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.
Quote from: DunDes LLC on March 04, 2015, 01:57:18 AM
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."
And there is maybe the error we do. The real problem is that the switch seems to miss to round 1-2 results, correctly. But if someone wants to help me to find this error, I need a very detailed list of all results and what paypal expected. Then I have again to check that with other payments like klarna, sofort banking and so on. All of them work a tiny bit different.
Paypal seems to truncate the input value, that is an intersting detail, which I did not know before. Other companies round anything before they work with it. Additionally to that, there exists more rounding types than most people learned in school and yes I also examined that a whole day. None of them seems to use Bankers rounding, so I end up using "Round half up" http://en.wikipedia.org/wiki/Rounding#Round_half_up
The really right way would be to add a http://en.wikipedia.org/wiki/Error_analysis_(mathematics) on the side of VM and paypal.
Checking the code, I see atm some locations using the normal "round" function and not the internal rounding function, maybe there is the problem.
Hello Milbo
Sorry to have upset You. This was not my intention.
I am working as an electrical engineer for over 24 years designing and calculating electronics, also designing PCBs and embedded software, but I don´t see why this would make my words weigh any stronger? I also do all my bookkeeping for my camera accessory store so I am hopefully updated on how to handle taxes. If I am wrong then I am wrong even if I my name would be Stephen Hawking.
I understand Your idea of the rounded/truncated tax example with 1 cent selling price. But if I would sell one screw it would be without tax. Tax rounded down to zero. Of course no other costs involved. Selling 100 screws would give an order line total with both tax and prices that i could use and would consider ok. This rounded value should in my oppinion be used for total. Spreading these 100 screw on 100 order lines seems to be kind of crazy. But I understand that approach it would give tax = 0.
The example that was shown by dundes was actually without tax. And seeing the invoice as it is displayed looks not ok to me. If the order lines aren´t added "correctly " you will have an incorrect sum. Even a sixt grader could add these and see that this doesn´t look alright. If the switch You talk about, corrects this, then great.
When I get an invoice on paper I can´t see the hidden digits. And when I want to check these figures I have to use what I see on the paper. Adding a column of figures is very easy, but will be incorrect if the sum is based on unrounded order line totals. If this is unsolvable then it is, and I rest my case. I thought there was an easy way of avoiding this, but this may not be the case.
Sending only the total avoids of course the problem with PayPal totally. But not with the strange summation of the order lines.
I am on the way to migrate my old system to VM3 and I will see how it goes when I am finished with that work.
Once again sorry that You to have to explain the obvious once again, hope You can see it from my point of view.
While I was Writing this I see You posted once again, thank You, nice post. I hope that there will come something good out of this :)
have a nice day
Jörgen @ Kreativ Fotografi