Use uc_price types instead of locations

Thank you Lyle for the support and the time saver through the uc_vat patch. The other patch is imo a big step into the right direction, this one still needs work.

The patch supports now also list price & cost, also the cart block shows always correct, although I do not understand why on review cart_item gets altered twice.

Next steps:
[not related]: The suffix is not displayed for teasers.
Order preview pane shows the subtotal incl. VAT, which is good for Germany. As the Total is calculated on base of the subtotal, not the subtotal excluding taxes, the Total contains 2x VAT.
My suggestion would be to build a configurable EU order preview pane, as we anyway need a place where to calculate and save VAT per item for the order pages. Thoughts?

Shipping cost pane at /checkout: At the other patch I replaced every 'type' => 'amount' by 'type' => 'shipping' and alter the values just for $context['revision'] == 'formatted'. This works without messing up the order preview pane.
The country condition I can add through a $_SESSION['country'] (default: store location, on checkout a pane has to modify it with $delivery_country), but I still didn't find a way to add the method ID as afaik the CA rule "Order has a shipping quote from a particular method" is relevant in more countries.

If you look at cart contents you see that longwave added subtotal there including the VAT the products as single items would produce. If at the order preview pane this value would be suddenly excl. VAT, this would be really confusing and also not legal. imo the key for calculation of the subtotal without messing up the tax calculation is again $context['revision'] == 'formatted'. Same with shipping.

In Europe you read the tax line items like "included VAT/tax", but the calculation works the same and I don't want to mess up anything on the logic as we have also cases where no VAT applies (country & "business role").

The pane we need not for bypassing uc_taxes, but as an addition to save each tax amount for each item for the order pages. Tax rules could change or be even deleted, so we need sth reliable. Longwave and I discussed an own table for it. Then uc_vat_uc_price_handler() should fetch the additional amount on order pages from there if revision is formatted.

Thanks to both of you for working on this! We're getting closer to a more workable solution with these patches I think.

The patch supports now also list price & cost, also the cart block shows always correct, although I do not understand why on review cart_item gets altered twice.

cart_item getting altered twice is similar to my very first comment in http://drupal.org/node/475474 - this still suggests a bug somewhere in Ubercart core though I don't understand where it's occurring either. Test coverage that includes a simple price alterer would help catch things like this but this is a lot of work to implement!

Order preview pane shows the subtotal incl. VAT, which is good for Germany. As the Total is calculated on base of the subtotal, not the subtotal excluding taxes, the Total contains 2x VAT.

The subtotal is however shown excluding VAT on the review order page, which seems correct to me - should uc_line_item_subtotal() op 'cart-preview' be using "original" instead of "altered" revisions? Or maybe we need to introduce another price type here so we can differentiate it from cart_item?

The cart contents pane shows the total including VAT, so all the necessary information is still displayed. What if the cart contents pane also showed the total excluding VAT and the VAT total for the cart products (so three "subtotal" columns instead of one), then the "Subtotal" line in the order preview pane could be renamed "Products excluding VAT"?

Now that I've looked into uc_vat.module, I wonder if it should use its own line items, instead of relying on uc_taxes'.

As you say the only way I can see of doing this is by duplicating a lot of uc_taxes code, which shouldn't be necessary. All the VAT module wants to do is display product prices including taxes, the actual tax calculations should be handled the same way uc_taxes already works. The VAT module just needs to hook in at the appropriate points and display extra tax price information where necessary, it already provides the needed checkout pane, and for the order admin screens we should be able to provide a further set of panes, but we shouldn't need a whole new set of line items.

Shipping cost pane at /checkout

Al, can you post an updated patch for this so I can test it?

This patch has the same requirements as Lyle's initial one, additionally you need this two line patch to get flatrates working.

By theory uc_vat should just alter prices at revision themed, possibly also formatted to avoid e.g. issues with uc_taxes. But then there are a lot of places I can not reach anymore like e.g. the cart block. imo this is a core issue.

$context['type'] = 'amount' doesn't tell anything about what it is. From what I saw the tax relevant information like 'shipping', which also CA uses, are available except on the payment checkout pane. With shipping I would also need the method ID, as the rule "order has a shipping quote..." is in more countries relevant to decide if taxes apply.

Line Items: afaik they are still from the times before WF_ng. Both WF_ng as well as CA never applied taxes to line items. imo this should be fixed also for consistence.

This looks already amaising, Lyle! Especially that you took the work of saving tax per item for the order pages from me:)

For shipping quotes it is now impossible to display taxes both from identification as well as from calculation of the taxed value, but also others (e.g. magento) are not able to do it. If you are willing to take another patch we could separate this and solve it at shipping costs incl. VAT?.

The big issue here is now that taxes are calculated on base of the altered (= taxed) product prices.

For a product with a sell price excl. VAT of $84.03 and 19% VAT I get:

Subtotal:  $100.00
VAT 19%: $19.00
Total:      $ 100.00

It should be:

Subtotal:  $100.00
VAT 19%: $15.97
Total:      $ 100.00

Which reminds me that for UC3 we should really find a clean deviding between the internal values without taxes for all calculations and the themed price which stays the same for the US and in the EU VAT is added at this point for display only. Taxes are calculated by both systems exactly the same.

I have applied http://drupal.org/node/475474#comment-1863092 and the two patches from comment #9 above.

They upset my shop in the following way:
Single products and the cart show the correct prices and subtotals while shopping (including VAT). but when going to the checkout page under "payment method"/"order total preview" the subtotal is displayed incl. VAT and then subject to VAT again - so effectively tax is included "twice" in order total (rolling back the patches this isn't the case).

interesting observation: when I display the cart block it shows the correct prices and total while shopping - but once I go to the checkout page each single product prices (and naturally the total) are also taxed twice there (compounded interest).

-> do I need to change some setting when I want to make good use of these patches? or did I come across a bug?

I tested the latest patch. the double taxation is gone. thanks. and yes, you are correct, we need to display the total VAT amount separately in Europe.

unfortunately there are more rules to VAT... another one is to display "the taxable amount per rate" - my shop has just one rate, so it should be easy to comply in my case: it means that I need a subtotal excluding VAT. but to make things a bit more complicated this also means that I need the display shipping cost without VAT and have them added to the subtotal excluding VAT. same for a discount (which I was planning to use): it needs to be displayed excluding VAT and is subtracted to create the subtotal excluding VAT.

example:

Subtotal: 111.21
Shipping: 17.16
Discount: -17.25
Subtotal excl. VAT: 111.12
VAT 16%: 17.78
Total: 128.90

I'm happy to help in this matter because I believe solving this will greatly increase Ubercart adoption in Europe. I also appreciate the effort to reduce the complexity of the price alterer by the way. finally I understand that for Ubercart 2.0 the implementation will not be able to fulfill all wishes and special cases of VAT. but I believe it's good to have a vision for the long term implementation so the current work can be a base for the future development. I have outlined my vision here a while ago: #487270: Display order total preview as table

let me know how I can be of further help.

( P.S. if you want to see the official rules you can read page 43 (most important paragraph (8)) of this document: http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2006:347:0001... )

I'm still a supporter of simplifying the price alterer. But you need to know that the current patches change more than just the way things are calculated in the background.

See attached pictures for illustration. I set the numbers to match post #13 - with one simplification: the discount is already subtracted from the product price.

I've applied the patch from #12 to uc_vat in order to test out Ubercart 2.0-rc5, but as already noted this needs 518916_tax_line_alter.patch to also be applied to Ubercart - without this there is the double taxation issue on the checkout page as noted in #11. Once this has been applied all seems to be okay in as far as rc5 shows the same prices that rc3 did on my test site.

I have committed this for now anyway and will add a note to the project page that 518916_tax_line_alter.patch needs to be applied to rc5 for taxes to be calculated correctly at checkout.

For those who need working VAT support in rc5 but can't or don't want to install the patch, adding the following code to the top of uc_vat_price_handler_alter() will fix the cart block:

if ($_GET['q'] == 'cart/checkout' && $context['type'] == 'cart_item' && !isset($context['subject']['cart'])) {
  return;
}

There is no easy workaround for the order preview pane that I can find, my best suggestion for this for now is simply to disable that feature under "Payment method settings" at /admin/store/settings/checkout/edit/panes.

This latest patch seems good to me - it applies cleanly against my test site and clears up the double taxation issues. However I don't think I should be the one to set this issue to "reviewed & tested by the community", so if someone else can review and test this, please do!

I just tested it again - this time against ubercart rc6.
yes, it applies without an error.
yes, it fixes the double taxation issue.

but it still makes my shop illegal. see post #13 & #14.
@longwave: do you still have the "Subtotal excl. VAT" line in your invoices? could it be a problem in my settings / db that I have a different output with the patch?

@xibun: Sorry, I didn't check for your issue earlier. In uc_vat.module line 300, comment out the following line to restore the "Subtotal excluding VAT" line:

$item['callback'] = NULL;

If this makes the order preview pane and invoices correct, I will commit this change to uc_vat.

@longwave: good one, "Subtotal excluding taxes:" is back!

Before all the changes we had "Subtotal:" and "Shipping:" (in other words the lines above "Subtotal excluding taxes:") shown without taxes. now they include taxes. right now I'm not sure if there is a strong reason for one or the other way. maybe you remember one?

@longwave: sorry, was a bit too trigger happy. it's good now on "Checkout" but not yet on "Review order"

@Island Usurper: on reviewing and testing with xibun, the tax alter patch seems to move the double taxation problem to later in the checkout process.

The tax-inclusive prices are locked in during uc_cart_checkout_form_validate(), but these altered prices are then used to recalculate the line items, so the tax is apparently applied twice on the review order page. Looking in the database, data['taxable_amount'] in uc_order_line_items already includes tax - uc_taxes_apply_tax() appears to be summing prices that have already been altered.

As we are storing altered prices against each product, maybe we need to ensure that as well as the product prices, all the line items in the order are fixed in uc_cart_checkout_form_validate() - and for the case of "Subtotal excluding taxes", which is needed for legal reasons in EU countries and was reintroduced in the change in #20, maybe uc_vat needs to ensure this line item is also stored in the database rather than calculated, as we no longer have access to the untaxed prices.

Or perhaps the locked-in product price should exclude VAT, but we should store the VAT rate against each ordered product? This seems like it may be a better option if we think of VAT as a tax that alters the display price of a product, rather than the actual price that is stored.

Okay, I've come up with a patch that I think clears up all the double taxation issues.

The original order product price stays in the 'price' field, and if an altered price is locked in, it is stored in data['altered_price']. uc_order_get_total() has then been modified to use this altered price if one has been set. This means we now have the original price for each order product (needed to calculate subtotal excluding taxes) and the final, altered price for each product (needed to calculate the full order total). Some quick tests now show the same figures on the review order, order admin and invoice pages as are shown in the order total preview pane.

This patch must be applied after the patch in #17; I've done it this way to make my changes easier to review.

Just tested the additional patch (also including the change posted in #20).
now the numbers are good on both: checkout and on review order.

BUT there is a difference between those two and the invoice sent by email when we add shipping costs:
Shipping is shown inclusive VAT in "Checkout", "Review order" and "Orders - View" (Admin section)
But exclusive VAT in Email invoice and "Orders - Invoice" (Admin section)

Further note: "Products on order:" on the invoice are now displayed excl. VAT - but the "Products Subtotal:" higher up is incl. VAT. this could lead to confusion.

One question.. with new patches and everything, are products stored including VAT on the uc_order_products table? If so, it's really bad for reporting.

@hanoii: Island Usurper's patch in #17 does store the VAT inclusive price in uc_order_products, but as you say this is bad for reporting (and causes double taxation issues elsewhere). My patch in #24 changes this so both the original price and the VAT inclusive price are stored - we need the latter in case the VAT rate changes at a future time.

@xibun: I am not completely sure my patch is the right way to solve this issue, or whether the products subtotals lines should be exclusive or inclusive of VAT. I would like input from Island Usurper (or anyone else!) before I go making any further changes.

Tested patches from #28 over the latest UC dev snapshot:
- problems mentioned in #25 remain
- additionally there seems to be double taxation of the product basket [EDIT: only in Checkout] (on the other hand shipping is correctly only taxed once)

In order review and also in the invoices, the tax amount is being displayed not correctly. It seems there's an additional tax calculation on the tax-amount itself. Altough in the payment settings at check-out, the tax-amount is being displayed correctly, it's only in the 'review order'-pane things go wrong.

I'm not that much of a php-guru myself to be able to solve the problem, but maybe one of you heroes can.

I installed ubercart-6.x-2.0-rc6 and applied the patches from comment #28.

Then I configured my new shop for germany with 19% VAT.
I entered my prices without VAT, ubercart correctly prints the prices with the tax in my shop.

On the checkout page i still see an error under "payment method / order total preview". The subtotal already contains the VAT, then there is the VAT line and the order total seems to be subtotal + (vat * 1.19).

Please take a look at the attached screenshot to follow my questions.

Is it correct that subtotal already contains the VAT? Seems correct to me, because it's the same subtotal as displayed below cart contents.
If subtotal already contains the VAT then the next line should read "includes 19% VAT" instead of "19% VAT". The displayed amout is corrent.
The order total should be the same as Subtotal, because the VAT is already included. But now it seems to be subtotal + (vat-line * 1.19).

Am i doing something wrong? Could I somehow help to fix it? I really would like to use ubercart in a live website. When do you think the VAT module will be stable enough?

I'm coming back to this after a week or so now....

In the end I went live with my project using Ubercart Rc3 and the vat dev module.

In all instances I could check that REALLY mattered VAT calculations were correct and product displays were correct. VAT was shown inclusive when displaying prices in the store, and vat was seperated out but shown in the checkout, cart, preview pane, invoice and order details.

Minor point was that product prices in the invoices and message sent to buyer are ex VAT - but we can live with that..... all the correct financials are displayed and charged for in the right places.

So now i was stable and launched I have come back to a clone of my site and thought I would test out the patches etc.....

My first worry is the word 'patch'....... I cant help but feel that if it needs to be a patch it already means it is likely to still have bugs so I never really considered it a good approach other than to test and try to move forward the development info for Longwave et al.

I used the pre patched version of ubercart - because I just cant get the hang of patching and dont trust my method..... so big thanks for a pre patched version. Using the pre patched ubercart rc6 and the dev version of vat I can definately confirm that the vat is still being applied twice in order preview and review.....

Also postage is now displayed inc VAT to the user..... not sure if thats neccessary..... but I guess it is more 'honest'. However - apart from in the preview I think it should allways be refered to as ex vat to avoid confusion - and even here I dont think its neccessary.

As I see it the process should be like this :

order subtotal (ex VAT)
postage
discounts
-------------
VAT then applied to all of the above to be charged
--------------
--------------
Order Total.

I'm pretty sure this is how the tax should be charged and is correct for EU. VAT is charged AFTER discounts, postage etc....

Products in the store should always show price inc. of VAT...... and in B2B usually both ex and inc

Customers should always be given a breakdown of an items price ex and inc VAT - so in all invoices, emails etc. Where a breakdown is not given the price should be shown inc VAT.

You guys are doing a wicked job developiing this module and if I can offer any php services I would - but frankly we'd be peddling backwards!! I am however FULLY prepared to brand this module and offer some marketing advice once developed to ensure it is widely adopted, trusted and integrated by other modules..... hopefully then it will be taken into core more readily...... the offers there.

So to sum up - I guess my input is to advise anyone unsure of this to just go with the ubercart rc3 option for now.... I'm 99% sure its all good at that point.

But on top of that - keep a dev version put to one side and help Longwave test further patches and upgrades untill we can all move forward.

I'm guessing that as Ubercart becomes more stable and hits full release that the finalisation of this module will be a bit easier.... its pretty hard if the goalposts keep moving - even if only a bit!

My only other ask would be :

For the longterm future how is it looking to be compatible with discount modules such as discount coupon and discounts_alt..... ubercart is amazing and does nearly everything needed out of the box..... if it had VAT, discount and role pricing features it would cater for nearly every outcome I could think of needing for most stores.... hopefully as mentioned - once ubercart hits stable everyone will be heading the right way and be compatible - but if not then I'm pretty scared of hitting some pretty fatal brick walls with future upgrades to these stores!!

Keep up the good work - I appreciate how hard time is to find for pushing forward!

+ the double taxation issue is gone
- there are still the problems mentioned in #25
/ thanks for the continuing effort on this one

+ the problems mentioned in #25 are gone. Yippee! :)

- longwave already pointed out in #27 that VAT rate can change in the future. I tested for this and found an issue: looking at stored orders which were placed under the "old" VAT rate "Subtotal excluding taxes" and "VAT" show the correct (historic) numbers - but all other items include the "new" VAT rate. (related to this also read #21)

note: I don't have an intelligent test case without VAT, please someone else test this.

Just a quick question: which one of the many patches in this thread makes it possible to show the subtotal excluding taxes in the payment pane at checkout?

With Ubercart 6.x-2.0-rc3 and uc_vat 6.x-1.0-rc3, the subtotal in the payment pane at checkout was shown correctly excluding taxes.
Now I updated to Ubercart 6.x-2.0-rc6 and uc_vat 6.x-1.x-dev plus the patches 518916_combined.patch (#36) and uc_vat_order_product.patch (#28), and the subtotal in the payment pane at checkout is shown with included taxes, which is wrong for my country.

How can I get the old way of showing the subtotal excluding taxes back?

Ubercart & UC_VAT RC3 showing the correct Subtotal excluding taxes
Subtotal: 84,03
VAT 19%: 15.97
Total: 100.00

Ubercart & UC_VAT RC6 showing the wrong Subtotal including taxes
Subtotal: 100.00
VAT 19%: 15.97
Total: 100.00

@MJH: did you already enter the shipping address? In my shop the "Subtotal excluding taxes:" line only appears once I enter a postal code.

Same problem as MJH in #39

which patches and on which versions (UC R6 / dev, UC Vat R3 / dev) should be applied? When I know this, I can test and try to help.

see: http://drupal.org/node/580152

Fossie

@ xibun (#40)

Because my shop has only non-shippable products, a shipping address can not be entered at checkout. Only the billing address.
The subtotal does show up, it is only calculated wrong (taxes already included).

===

@ Island Usurper (#42)

I have used exactly these two patches (well I patched a freshly installed Ubercart 6.x-2.0-rc6 instead of dev). And the result is the subtotal with included taxes in the payment pane at checkout:
Subtotal: 100.00 <==== SHOULD BE: 84.03
VAT 19%: 15.97
Total: 100.00

So the big question is:
- Is this the way you wanted it to be (for example because it is required in your country)? Then how can I change it for the requirements in my country.
- Is this a bug?
- Is this a setting somewhere in ubercart?

I can confirm MJH's issues in #43 where the Subtotal is showing inclusive of VAT.

Versions as per #42

subscribing

So how can the **subtotal with included taxes in the payment pane at checkout** problem be fixed.
I need to open my shop soon and this is the only remaining bug (I found so far).

subscribing

Just a quick confirm that when using the latest bzr version (which includes the patch at #47) that the subtotal still includes VAT.

Sounds reasonable enough that uc_vat_line_item_data_alter() needs to remove the tax on the subtotal.

As a test the following works (no time atm to flesh it out or submit a patch):

    elseif ($item['id'] == 'tax_subtotal') {
      $item['callback'] = 'uc_vat_line_item_tax_subtotal';
    }

function uc_vat_line_item_tax_subtotal($op, $order) {
  $amount = 0;
  if (is_array($order->products)) {
    foreach ($order->products as $item) {
      $amount += $item->price * $item->qty;
    }
  }
  return array(array(
    'id' => 'tax_subtotal',
    'title' => t('Subtotal excluding VAT'),
    'amount' => $amount,
  ));
}

subscribing

I've just committed Island Usurper's patch from #28 and an extended version of fenstrat's patch from #49 that also includes line items in the subtotal excluding VAT. In conjunction with the latest Ubercart 2.x development release the prices now seem to be consistent and correct throughout the checkout process and into the admin pages on my test store. There is still work to be done where the prices change if the taxed line items are changed or the VAT rate alters, but I will work on these separately - but for now this seems to be enough to get stores up and running with VAT support.

Many thanks to everyone who contributed to this issue with testing and patches!

OK we are nearly there! With latest uc_vat 6.x-1.0-rc7 and ubercart 6.x-2.0-rc7, the payment pane at checkout looks like:

Subtotal: 29,95€ <=== This line should be deleted, everything else is perfect!
Subtotal excluding VAT: 25,17€
VAT:	4,78€
Total: 29,95€

So if the line "Subtotal: 29,95€" could be deleted somehow, everything would be perfect! But how can the first line be deleted?

The first "Subtotal:" line cannot be deleted for stores with shipping and/or discount. There will additional lines between "Subtotal:" and "Subtotal excluding VAT:" and both of them are needed to make sense. See post #13 for an example. So the "deleting" needs to be conditional.

Yeah, I don't think the "Subtotal" line can be deleted, as on the first checkout page load it doesn't need to be there, but as soon as you click a shipping option or apply a discount or something, it needs to appear - but as far as I can figure out there is no way of doing this at present, the line must be there as soon as the page loads.

I could add a checkbox option to remove the line at all times for stores that will never use shipping or discounts, if that would help.

@ #54
> I could add a checkbox option to remove the line at all times for stores that will never use shipping or discounts, if that would help.

That would help ;)

Or an automatical setting like the existing "Hide shipping information when possible for carts with no shippable items." at the General checkout settings:
Hide #first line subtotal# when possible for carts with no shippable or discountable items...

Thanks for all your work!

"Hide the Subtotal line item at checkout" has been added as a new option, this has been committed to CVS and will show up in tomorrow's -dev release.