VAT in invoice calculated on Total not subtotal (ubercart > 2.4)

I have a similar issue on my site.

In checkout (this is correct), I have

NZ$30.00
Subtotal excluding GST: NZ$26.09
NZ 15% GST: NZ$3.91
Subtotal: NZ$30.00

However, the invoice shows
Subtotal: AU$30.00
Subtotal excluding GST: AU$30.00
NZ 15% GST: AU$4.50
Total: AU$30.00

The subtotal value is incorrect, hence, the 15% GST is incorrect as well.
Any ideas?

#1 won't work for me because I am already using Ubercart 6.x-2.4

I have the same as #2

Don't have time to look at it right now but will take a look tomorrow.

In the meantime, can anyone shed any light on this?

I confirm the bug occurs in Ubercart 2.6 but not in 2.4. It only get triggered when using uc_vat and disabling Show VAT amounts in separate columns at checkout in admin/store/settings/taxes/vat (Drupal variable uc_vat_show_cart_columns). In this case uc_vat is not calculating Taxes but simply uses the uc_taxes module for applying taxes.

The change from 2.4 to 2.6 and its implications are described in #14 of #898776: Tax calculation doesn't use altered prices. To summarize: the change happened in function uc_taxes_apply_item_tax() in uc_taxes/uc_taxes.module. In 2.4 it returns the price without taxes: return $item->price * $item->qty. In 2.6 it uses uc_price() to calculate the price and this seems to add taxes to the price. I guess this is the supposed behaviour of uc_taxes_apply_item_tax() but it finally calculates taxes in the Order total preview wrong when using uc_vat.

Hopefully longwave will come up with a solution soon. For the meantime I just restored uc_taxes_apply_item_tax() to behave like in 2.4.

i also confirm this and downgraded to ubercart 2.4 until there is a solution.

Hi,
I am on UC 2.6 and experienced the same issue. Everything OK in review order but invoice is printing wrong VAT.
Total amount is correct as well as amount excluding VAT.
Is itpossible to calculate VAT on invoice by substracting ( total amount - total excluding VAT) and simple print it in the invoice?

Thank you for advice

Subscribing.

Same problem as http://drupal.org/node/1278878 ?

Subscribing

Subscribing

Subscribe

fuerst explains the issue very well in comment #5.

Here's a small patch that solved the issue in combination with ubercart 2.6 for our setup.

Patch #13 doesn't resolve the problem in the cart/checkout/review page.

Patch #13 works for us with these settings:

Thanks for suggesting those those settings !
Now, it is better than before, but some troubles remain if I have shipping costs.

Thx for the patch in #13.
I applied the patch and VAT is correctly calculated in UC 2.6 from the subtotal and correctly displayed.
But in checkout to e.g. to paypal UC 2.6 still calculates the VAT from the total amount.
In my case we talk about German MwSt. 19%:

Sales Price (meant incl. VAT!): € 229,00
Subtotal excluding VAT: € 192,44 (correct)
19% MwSt. 43,51 € (wrong, should be "Umsatzsteuer" € 36,56)
total now in paypal: € 235,95

(wrong, should be € 229,00 which is correctly displayed in UC 2.6 in all places after the patch, but not in paypal)
any help is appreciated how to fix this also for the payment numbers to e.g. paypal.

see screenshots UC checkout ("Kasse / Vorschau der Gesamtsumme") and paypal total.

#17, It's not only for paypal. I've tried some other payment methods and the sum at /cart/checkout/review still have the wrong values. It seams that the calculation of VAT is made with the amount * the VAT. It should be amount / 1 + VAT.

But with the patch in #13 the /cart/checkout -page is correct.

I hate this ubercart / uc_vat stuff. The way uc_vat works is really ugly. But I need to get our shop to work again ...

Here's an improved patch that fixes paypal and hopefully other payments as well.

Did you see my solution in another similar issue?

https://drupal.org/node/1170992#comment-5062982

Yes, but we decided to not touch the ubercart package itself.

#19 is almost there. Unfortunately comes first the (previous) wrong VAT and after that i got an minus row. The sum is correct but in two rows instead of one:

(moms is the Swedish name of VAT)

My workaround for this issue removes the wrong calculated taxes.
The Paypal module only display the sum of all taxes. So it works there.
But your payment module displays all taxes in separate lines :-(

Your workaround is doing it's job well. Unfortunately do i not use the Paypal-module (I am writing an new payment method so I think I have to find out how the PayPaI-module is doing it...).
I've spent two days now on trying to find where and why it's going wrong in uc_vat, with no luck. It's time to leave that to better people...

How do i implement this patch without using something like putty. Because i'm no programmeur. But understand php.
Which lines should i replace/ edit?

After spending most of the weekend struggling around in the Ubercart code I think that #20 is the right way if you want an solution on this problem...

Also confirming #20 works for me.

I'm using ubercart 2.7, uc_vat 1.2.

previously GST was shown incorrectly as $11 if the product was $100, whereas it should have been $10 GST. This was in the checkout screen and review order screen.

I followed steps from #20 and it works correctly now. Shame to have to patch ubercart for this but hopefully the patches can be put in to next releases.

Thanks very much for your help !!

See my solution at this post: http://drupal.org/node/1170992#comment-5274644
I only patched uc_2 VAT support v6.x-1.2, but I did not touch the ubercart package itself.

Thanks Buddy !

It worked for me... :-)

Solution by WebsiteJo http://drupal.org/node/1170992#comment-5274644 solved this issue for me as well!

WebsiteJo's solution works OK, but you get two VAT lines, one too large and one negative one, on the Review order page. This seems to be because of the new uc_vat_calculate_tax() function, that adds the extra line to correct the VAT total.

OK, have managed to get the correct VAT line_item total in the "Order total preview:" by changing this:

function uc_taxes_apply_tax($order, $tax) {
  $amount = 0;
  $taxable_amount = 0;
  if (is_array($order->products)) {
    foreach ($order->products as $item) {
      $taxable_amount += uc_taxes_apply_item_tax($item, $tax);
    }
  }

which applies the VAT tax to the item before adding it to the total $taxable_amount, to this:

function uc_vat_apply_tax($order, $tax) {
  $taxable_amount = 0;
  if (is_array($order->products)) {
    foreach ($order->products as $item) {
      // We want the original amount without VAT applied here
      $taxable_amount += $item->price * $item->qty;
    }

Ah, reviewing the code for the fix here: http://drupal.org/node/1170992#comment-5274644 I see that they try do a similar thing but still allowing other price altering functions to run. That needs their new uc_vat_uc_taxes_apply_item_tax() and the lines added to uc_vat_price_handler_alter() to do nothing if $options['uc_vat'].

Now to get it correct in the "Review order" page too...

OK, the order's "VAT" line item is being stored with the wrong value. More later...

I think I have the solution!

The VAT module is re-using the standard line items created by the uc_taxes module, using alter functions to change the tax callback. For some reason the callback function for the "tax" line was only being altered to use the VAT calculation if the site was configured to have "Allow per line-item tax adjustments (requires patch to uc_taxes.module)" checked.

My fix is to simply comment out this test in uc_vat_line_item_data_alter(), so that the VAT tax calculation (that calculates using the ex-VAT product total) is always used, and not the standard tax calculation (that calculates using the inc-VAT product total).

Addtional fix to the code looks like:

      case 'tax':
        // Allow per-line item tax adjustments.
// We ALWAYS want this callback for the tax line item!
//       if (variable_get('uc_vat_line_item_adjustment', FALSE)) {
          $item['callback'] = 'uc_vat_line_item_tax';
//        }

Will see if I can make a patch later.

Patch file for review. Needs some tidying.

NOTE: this patch fixes the VAT calculation amount without adding additional line items to the order.

This patch is not valid: it can't be applied with git
But it seems to work when tidied up!

And we need a patch that applies to 6.x-1.x-dev

Here's Fonant's patch cleaned up and rerolled for 6.x-1.x-dev.
It seems to work for me.

Actually, this fixes the displayed VAT amount, but the VAT amount sent to PayPal is still wrong!

I've just added an issue (http://drupal.org/node/1510372) and now I see it might be related to this one.

My debugging shows that in uc_vat_apply_tax, line 881, $taxable_amount already incudes VAT if user has no show prices excluding Var permission. If the user has it, $taxable_amount does not include tax, due to line 458 in uc_vat_price_handler_alter().

Actually, this fixes the displayed VAT amount, but the VAT amount sent to PayPal is still wrong!

Yes I'm seeing the same thing.

I think this is a duplicate of #1170992: double VAT

The double VAT issue fixes the problem of too much VAT by adding another negative VAT line to the order to compensate. This gives the correct totals, but leads to two VAT lines appearing which isn't very good.

My patch, in this issue, attempts to fix the original VAT calculation code so there is no need to add a second, negative, VAT line to the order.

We've applied this to a German store that breaks out 7% and 19% VAT rates. The patch has solved the problem as others have described it in this thread.

Tempted to mark as "reviewed and tested", but it looks like the fix in #1170992: double VAT is quite similar or even based off the patch here — can someone remark on how this other report is or is not the same thing?

Do we have a final fix for this? It seems a lot of people had the same problem but there´s no definitive solution?? Please help!

I've tried the patch mentioned and still getting the incorrect value in the review and paypal pages.
Any closer to a fix yet? Its a shame its such a trivial fault too...

Please see the discussion and resolution here: http://drupal.org/node/1170992#comment-7024208