Discount Error

[Milbo]

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.

[Jörgen]

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