Virtuemart doesn't work with Paypal

[Natastna2]

There is a problem in the way that Virtuemart rounds up tax amounts and makes it unusable with Paypal. 80 percent of the transactions will go through but others will not with invalid tax amount. I've posted the problem at https://www.x.com/message/189979#189979 and they told me to post here and to ask if anyone can help in correcting the rounding up. I'm trying to use 0 percent sales tax.

[jjk]

If I'm correct you might just wait for a few days until VM1.1.6 is officially released. As far as I know it contains several PayPal fixes.

[Natastna2]

OK, I have two live sites with this problem atm. Does anyone know when it should be released? I don't really want to wait on this problem and hope for the best with the update. Is there any way of contacting someone who will know what the problem is. Debug mode is showing correct info to me, ie tax amount 0 and most payments will pass through, but some figures, usually those ending in a 9 will not. I guess this is probably a result of incorrect rounding or too many decimal places. If anyone could tell me which file is responsible for the tax amount and how I could set it to 0 I'd be fine. I've contacted others with this problem but they all just gave up and went with another CMS. This cannot be a complicated problem to fix but I simply don't have the knowledge. Any help would be greatly appreciated. Thanks for your time. Ant.

[jjk]

If you can't wait for the official release, look at this:
http://dev.virtuemart.net/redmine/issues/178#change-378
But do make a backup first.

[Natastna2]

I've upgraded to 1.6 and still have exactly the same issue. Is there any way I can contact someone who can tell me which file is responsible for not shortening the tax value to a few decimal places? I'm pretty sure that's the problem even though the tax should be 0.

[Natastna2]

If the problem is too many digits in the tax amount. Maybe this is the problem. Line 1638 of ps_paypal_api.php is
$amt = round($order_totals['order_total'], 2);

and line 1639 is
$shippingamt = round($order_totals['order_shipping']+$order_totals['order_shipping_tax'],2);

but line 1640 for tax amount is
$taxamt = $amt - $order_totals['item_total'] - $shippingamt;

Could someone please help round that line. What would I need to change that to to match the other lines. Thanks, Ant.

[jjk]

Hi, its me again  
While I was typing this you made another post. In addition to your findings I think there might be a more general rounding and storing the numbers in the database problem.

I had a look at the product prices in my database table jos_vm_product_price and noticed some inconsistencies.

Can you have a look at your database tables (jos_vm_product and jos_vm_product_price) using phpadmin and check if the product prices you have a problem with are rounded differently. I seem to have some rounded to 2 decimals and some rounded to 5 decimals.

It is also possible to see the number of decimal places if you click on the price in the VM product list.

I'm going to make a corresponding post in the forum section "VirtueMart Dev/Coding Central" (that's where the devs are looking for bug reports), because I think there is a bug or two.

[update]
perhaps this helps a little bit:
https://forum.virtuemart.net/index.php?topic=78686.msg260882#msg260882

[Natastna2]

Hi, It can't be the product prices being rounded inconsistently in the product tables as I can make the transaction work with one product using a shipping that is 80p whereas I cannot with the same item with a different shipping of 50p. It seems to be the total that is wrong. I think the problem is in ps_paypal_api.php and it's the lines saying to correct a rounding error tax shall be worked out like this. Line 1523    // to avoid rounding issues, calculates tax as a differenct between total amount and other items. This does not work for some reason. Ive' since changed my version to say $taxamt =0. A very simply workaround but it seems to work atm.

[zanardi]

Sorry for the issue, I've bookmarked this thread and will have a look at it in my next VirtueMart bug checking / fixing session.

[Natastna2]

Thanks for the replies. This is the kind of response I'd hope for from the support forum. But honestly, with previous problems, this kind of response has been severely lacking. Thanks again. Ant.

[detours]

I have dumped the values before they get passed to the paypal API. Here's an example:
amt=38.68
shippingamt=31.1
order_totals=7.5
taxamt=0.079999999999998

This is an fp precision problem. I suggest that in addion to the fix in 1.1.6 "to avoid rounding issues", $taxamt should be rounded as well - or use bcmath to avoid the problem altogether.

As a side note, with no tax configured (no tax, no tax rules), the tax should actually be 0.00. Also, on the order form this shows up as "fee" not as "tax".

detours

[piperpilot]

Hi, I meant to post here as well.  I made a hack to fix the "Zero" tax problem.  Here is the thread:

http://forum.virtuemart.net/index.php?topic=78957.0

With 1.1.6 there shouldn't be a rounding issue any more because the math for tax is done via subtraction.  Basically they take the total - items - shipping = tax.  This SHOULD be a whole number to the 100ths place if the math in other places was done correctly.

In your example, it would be:

38.68 - 31.1 - 7.50 = 0.08

Now that being said, a 0 (zero) was coming out as 0.00000000000009 or something like that.  So maybe there IS a bigger problem that can be solved by rounding/truncating to the 100s place.  I'll play around with it and see if maybe a simple rounding can be applied and fix both the zero problem as well as the tax math problem.

piperpilot

[detours]

Hi piperpilot,
thanks for the heads-up. I solved it for me by simply rounding what gets assigned to $taxamt.

The total of 38.68 is already wrong to begin with. It's a figure that comes from nowhere, get's transmitted to paypal as being tax, and shows as fee in the final order confirmation, though the payment module fee is set to 1% - which, in my book, sums up to (7.50+31.10) * 0.01 = 0.386.

Now, this might have to do with rounding as well, but I'll have to dig deeper into it.

In the meantime, I'm going to give B-planet's fix a shot.

detours

[piperpilot]

What is B-Planet's fix?

[detours]

Can't say if it's any good since I haven't installed it yet, but here goes: fix on b-planet.com.

The fix addresses some of the logical problems with the way paypal payments are being handled. If it does anything regarding the rounding problems, I don't know yet, but I'll keep you posted.

detours