Ubercart 2 VAT support » D7 port

D7 will contain some support in Ubercart for showing taxed prices directly, see #991638: How can we support VAT in Ubercart 7.x-3.x now uc_price() has been removed?. This module will probably still be needed to enter tax inclusive prices, hide taxes for certain roles, etc. but I will wait to see what UC3.0 supports before working on a D7 release of uc_vat.

Ubercart has reached beta1, so it's likely to see from now on what's in and what's not.

+1

sub

Hi I was interested in this and for those who need to know it is quite easy to set up country specific tax rates in the 7x3x ubercart. A rules form is included so you can use this to compare the address with country.

subscribing

subscribing

sub

Entering and displaying tax-inclusive prices is already partially supported in Ubercart 7.x-3.x, although #1153086: Inclusive tax not visible in cart block or checkout pane is outstanding.

I suggest testing Ubercart 7.x-3.0-beta4 or -dev and seeing how you get on, and follow up here if there are features not in Ubercart core that still need to be ported.

I found the "Include this tax when displaying product prices." checkbox, but that adds the tax onto the selling price. Is there the option to enter tax-inclusive prices? If so, can you tell me where to look?

subscribing

subscribing

Does anyone have a solution for this problem? I really want to show the price in the product overview WITH vat. At this moment, the vat only shows when the full context of the product is visible.

Tried everything ( i think hihi, i'm just a noob )... If anyone know a fix, please tell me!

I did the following, to solve this problem in Ubercart 3 in Drupal 7. Actually, this kind of solution is not really nice. It works for me, but probably not for you. I've just needed a quick solution, that does not affect code in the Ubercart modules. So, problably this is what you are looking for...

1. Create a module (in this mini guide the module is called "mymodule"). At least you have to create the mymodule.info and mymodule.module files.

2. In "mymodule.module" alter the views data provided by Ubercart by adding this code:

/**
 *  Implements hook_field_views_data_alter
 */
function mymodule_views_data_alter(&$result) {
  if (array_key_exists('uc_products', $result)) {
    $result['uc_products']['sell_price']['field']['handler'] = 'mymodule_handler_field_price_tax';
  }
}

3. Copy the file "sites/all/modules/ubercart/uc_products/views/uc_product_handler_field_price.inc" into your modules folder and rename it to, for example, "mymodule_handler_field_price_tax.inc".

4. Modify your mymodule.info file and add:

files[] = mymodule_handler_field_price_tax.inc

5. Modify "mymodule_handler_field_price_tax.inc". It should look like this:

<?php // This <?php must be at the beginning of the file ;-)
/**
 * @file
 * Views handler: Product price field.
 */

/**
 * Returns a formatted price value to display in the View.
 */
class mymodule_handler_field_price_tax extends views_handler_field_numeric {
  function option_definition() {
    $options = parent::option_definition();

    $options['format'] = array('default' => 'uc_price');

    return $options;
  }

  function options_form(&$form, &$form_state) {
    parent::options_form($form, $form_state);

    $options = $this->options;

    $form['format'] =  array(
      '#title' => t('Format'),
      '#type' => 'radios',
      '#options' => array(
        'uc_price_incl' => t('Ubercart price (incl. tax)'),
        'uc_price_excl' => t('Ubercart price (excl. tax)'),
        'numeric_incl' => t('Numeric (incl. tax)'),
        'numeric_excl' => t('Numeric (excl. tax)'),
      ),
      '#default_value' => $options['format'],
      '#weight' => 1,
    );
    
    // Change weight and dependency of the previous field on the parent numeric ones
    $weight = 2;
    foreach (array('set_precision', 'precision', 'decimal', 'separator', 'prefix', 'suffix') as $field) {
      if (isset($form[$field]['#dependency'])) {
        $form[$field]['#dependency'] += array('radio:options[format]' => array('numeric'));
        $form[$field]['#dependency_count'] = count($form[$field]['#dependency']);
      }
      else {
        $form[$field]['#dependency'] = array('radio:options[format]' => array('numeric'));
      }

      $form[$field]['#weight'] = ++$weight;
    }
  }

  function render($values) {
    // Get rate
    $rate = 1 + db_query("SELECT rate FROM {uc_taxes} WHERE name = 'MwSt.';")->fetchObject()->rate; // Change the name of the tax rate!!!
    
    // Get price (excl. tax)
    $price = $values->{$this->field_alias};
    
    switch ($this->options['format']) {
      case 'uc_price_incl':
        return uc_currency_format($price * $rate);
        
      case 'uc_price_excl':
        return uc_currency_format($price);
        
      case 'numeric_incl':
        return $price * $rate;
        
      case 'numeric_exkl':
        return $price;
        
      default:
        return $price;
    }
  }
}

You have to replace in the above SQL statement the name of the tax rate you have created on the config sites in Ubercart.

6. Activate your module and flush caches.

7. Probably you have to set the correct format options in the view.

NOTE: this only works, if you have one single tax rate. Also, I don't know if this works with all features and on all views of Ubercart. I don't use all of them.

sub

OK 46AND2, you talked me into it. See enclosed uc_inc. I am working on adding this to a Drupal.org sandbox.

Fixed a typo and started documentation. What needs to go in the documentation is how this works with UC taxes.

I have to work with tax in and tax ex products. I could not make Ubercart and this modification work for tax inc.

I changed products to have a tax_inc field and tried hook_uc_line_item() but the result does not appear on the invoice. This would be a good approach if someone could document the hook and how to make the item appear on the invoice.

As a temporary measure, I changed the invoice display to include the tax.

The enclosed uc_inc is my temporary change. uc_inc uses some tax fields added to products, adds tax information to the store form then insets the information in the uc_order customer template.

The two fields added to products are tax status and tax inc. If tax status is set to inc, use the value in tax_inc. Retrieve the value at invoice display using the supplied function.

I decided to make tax status a taxonomy term because I can use the taxonomy elsewhere. The term from the taxonomy can be used for the text and changed in the text. The vocabulary lets you have different types of taxes. The code could be changed to a boolean or to use one of the Ubercart tax definitions.

The tax amount is not in the order because I did not have time to get the Ubercart order API hooks working to add to the order. I could add a tax that is added on to the invoice but not store a field that is not added on to the total.

The next bit would be to copy some tax reports to create tax inc reports.

Sorry to bump this topic, but I could not find other relevant discussions regarding adding support for a Customer VAT Number field in Ubercart for D7. Just being able to calculate VAT taxes using uc_taxes is great for B2C, but not sufficient for any B2B selling in EU, where it is necessary to store the customer's VAT number, and to use it, preferably after a verification, to calculate zero-rated prices for intrastate supplies. I wonder if anyone is working on this very important aspect of Ubercart at all. Many thanks for info.

I've done a port of this module to D7.

There are a number of changes, due to the way UC and Drupal have changed.

Due to the implementation of Rules for tax handling, the actual calculation of the tax (and display thereof) is left to uc_taxes, so that this VAT tax is handled the same as any other tax.

The main function of this module is to implement a Rule that checks the delivery/billing country against the list of European states and apply the VAT tax as applicable.

Changed / removed elements

VAT summary chart on checkout / cart page
For backwards compatibility, the cart and checkout panes displaying VAT summary information have been left in, though you may find that the built in tax display is sufficient.

The admin may now choose to display the summary on either the checkout page, the cart page, or both

Price editing options
In the D6 version, uc_vat altered prices in the database behind the scenes to store taxable items with the tax already included for those items that were inserted by the store owner as "VAT included" prices. This creates extra work for the module, and increased points of failure.

To insert tax inclusive prices for products, store managers may simply edit the tax rules to not apply taxes to those products that already have VAT included.

For this reason, the Price Editing options have been removed, and replaced with a single checkbox to tell the system if display prices included VAT or not.

Shipping message features
The functionality regarding shipping costs / messages has been removed, as this is more appropriately handled by the shipping module itself.

I don't have much experience with the D6 version of Ubercart, so my apologies if I've taken out anything necessary or implemented things without following previous standards. The ported version works for a new e-commerce site we are putting up, though I'm sure there will be other use cases that may require changes.

At any rate, I hope this can be built upon as necessary, so that this important element of e-commerce can available to those of us using D7 and UC in Europe.

I'm happy to continue maintaining the D7 port, if necessary.

Hi aacraig,

Thanks for the D7 port. However, I installed it... and I'm not sure if it really works the way it should.

My situation: I want Ubercart to assume my prices include VAT already. I see a checkbox for that in your module ("When checked, the system assumes prices are taxable, but BTW has already been included in the price."). However, when I tick that checkbox, VAT is still added to my prices in for example the checkout review.

Also, I might want to show VAT on relevant places like the cart. I ticked that box ("Show BTW amounts in the cart") and I see a new optional pane appear backend. I activated it, but nothing appears frontend...

Any idea what might be wrong? Thanks!

Remko

Perhaps we could add child issues per tax variation. Australia has GST included in the price and should not be added on. For invoices and receipts, the GST is added up and listed as a single "included" item listed before the total but not added to the total. Are there any other countries following the same system?

I agree that this may be more complex than it seems at first glance, and input from as many countries as possible would certainly be helpful.

In Italy, it's common both ways, depending roughly on the sector or type of business. Retail and services tend to include IVA in the price, and often don't break down the cost before and after taxes -- they just give the total "including IVA".

Big ticket items like cars, electronics and houses, and most B2B transactions list the base cost and the IVA tax as a separate line item which is added to create the final total due.

It wasn't clear to me how the D6 module handled this, so I admittedly glossed over the handling of this in the D7 port. I will also get more input from the client we are doing this work for, and perhaps that will help us achieve some basic use case input in the very near future.

Once there's a consensus on some standard use cases, I'll be happy to add more features to this port.

Hi, please also have a look at my issue above. The module doesn't seem to work at all?

Thank you for doing the hard work on porting this module to D7. The whole VIES validation is important for EU B2B scenarios.

It seems to me that the validation code is working well. I am not sure, however, how did you intend to plug its result into a tax rule condition. In Ireland (or UK), VAT is charged if customer's country is the same as the store country, even if the customer provides a VAT number. However, if the country is different, VAT is only zero-rated, if the VAT number has been provided, and validated.

It is easy to build rules that check the country situation, but what I am not sure about is if you already provide some sort of a condition that could be plugged into the tax rule, that takes care of the country comparison *and* the outcome of the check that the VAT number has been provided, and validated. In other words, I don't understand the interaction between your module and the uc_taxes tax rules, which I understand one still has to create, but what about their conditions? I could not see how I could do a Data Comparison condition on VAT number, as I cannot see it as a valid value in the selectors for order: or order:customer:.

Also, the validation SOAP call returns the address that is associated with the VAT number, if present. It would be great if you could store that returned address in the order, as a "VAT Validated Address" or so, because that is the address that should be shown on the invoices, if possible.

Finally, it would be great if you could allow for customisation of the messages (though it is possible to use String Overrides).

Once again, many thanks for the hard work.

The tax handling is actually now completely handled by the built in UC Tax module (via Rules).

So, to get things working for your country, you simply create a Tax which applies to the European countries (this condition is supplied by uc_vat) or whatever you like.

In fact, the sole purpose of the D7 version of this module now is to simply supply the condition defining the European countries and validate against that rule.

The actual application of the tax is handled as every tax is handled, by UC Tax.

This module does NOT handle the VAT number. That is handled by uc_vat_number, which I have also ported to D7: http://drupal.org/node/1054850. Any questions / issues regarding the VAT number handling should be asked in that project's issue queue (preferably in the D7 issue, because the port isn't official yet).

I am still working on the use case of the store admin being able to insert prices with tax already included. At the moment, you should insert prices without the tax included, and check the "Include this tax when displaying product prices." on the tax edit form.

The price display options under the VAT Settings tab don't really do anything at the moment. I will continue improving this version of the module over the next week or so, as I get more clear on the use cases.

Australian invoice:

Computer $9.90
Keyboard $2.45
105" screen $2737.65

GST included $250.00
Total payable $2750.00

I've been working on this issue a little this morning, and I think some input from the community would be quite useful.

As I see it, there are 3 use cases.

Use case 1:
The VAT tax is handled as all other taxes with no special treatment.
Using the standard tax creation form, you can set up your VAT (using the VAT module's rule to limit VAT to the appropriate countries). For display of the price, you may simply use the standard tax settings.

In this case, uc_vat only supplies the rule condition for applying the tax.

I believe this covers most use cases, such as the one in #30, where you display the price without taxes, and taxes are added as a line item in the invoice.

This is currently completely implemented in the D7 port.

Use case 2:
The VAT tax is handled as described above, but if a VAT number is supplied by the buyer, the tax should not apply.

This is an issue for uc_vat_number and is beyond the scope of uc_vat.

Use case 3:
A common situation in Italy is for store owners to display the price with tax already included. This is common enough that the uc_vat module should be able to handle the situation, but it gets a bit complicated.

In this case, you'll want to be able to:
optionally display a suffix to the price (such as 'VAT included') for those customers who will be paying VAT
optionally display the price WITHOUT VAT included for those customers who are exempt (they don't live in Europe, for instance)
optionally break the tax out when the item is displayed on the checkout form / invoice

If anyone can add a new use case, please do so.

First of all, I will repost and rephrase my question from #28 on the uc_vat_number forum, as requested by @aacraig. However, I think these are somewhat related to each other. Also Use Case 2, as listed above, is not quite complete: the tax should only not apply if (VAT Number Provided and Validated AND seller country <> buyer country AND buyer country is in EU).

By the way, if anyone just needs a condition for a uc_taxes rule that triggers VAT calculation, you could do it using a Rules components, such as this one, which you can just import:

{ "rules_country_subject_to_eu_vat" : {
"LABEL" : "Country Subject to EU VAT",
"PLUGIN" : "or",
"REQUIRES" : [ "rules" ],
"USES VARIABLES" : { "order" : { "label" : "Order", "type" : "uc_order" } },
"OR" : [
{ "data_is" : { "data" : [ "order:billing-address:country" ], "value" : "348" } },
{ "data_is" : { "data" : [ "order:billing-address:country" ], "value" : "380" } },
{ "data_is" : { "data" : [ "order:billing-address:country" ], "value" : "428" } },
{ "data_is" : { "data" : [ "order:billing-address:country" ], "value" : "440" } },
{ "data_is" : { "data" : [ "order:billing-address:country" ], "value" : "442" } },
{ "data_is" : { "data" : [ "order:billing-address:country" ], "value" : "470" } },
{ "data_is" : { "data" : [ "order:billing-address:country" ], "value" : "528" } },
{ "data_is" : { "data" : [ "order:billing-address:country" ], "value" : "616" } },
{ "data_is" : { "data" : [ "order:billing-address:country" ], "value" : "620" } },
{ "data_is" : { "data" : [ "order:billing-address:country" ], "value" : "642" } },
{ "data_is" : { "data" : [ "order:billing-address:country" ], "value" : "703" } },
{ "data_is" : { "data" : [ "order:billing-address:country" ], "value" : "705" } },
{ "data_is" : { "data" : [ "order:billing-address:country" ], "value" : "724" } },
{ "data_is" : { "data" : [ "order:billing-address:country" ], "value" : "752" } },
{ "data_is" : { "data" : [ "order:billing-address:country" ], "value" : "826" } },
{ "data_is" : { "data" : [ "order:billing-address:country" ], "value" : "372" } },
{ "data_is" : { "data" : [ "order:billing-address:country" ], "value" : "40" } },
{ "data_is" : { "data" : [ "order:billing-address:country" ], "value" : "56" } },
{ "data_is" : { "data" : [ "order:billing-address:country" ], "value" : "100" } },
{ "data_is" : { "data" : [ "order:billing-address:country" ], "value" : "196" } },
{ "data_is" : { "data" : [ "order:billing-address:country" ], "value" : "203" } },
{ "data_is" : { "data" : [ "order:billing-address:country" ], "value" : "208" } },
{ "data_is" : { "data" : [ "order:billing-address:country" ], "value" : "233" } },
{ "data_is" : { "data" : [ "order:billing-address:country" ], "value" : "246" } },
{ "data_is" : { "data" : [ "order:billing-address:country" ], "value" : "250" } },
{ "data_is" : { "data" : [ "order:billing-address:country" ], "value" : "276" } },
{ "data_is" : { "data" : [ "order:billing-address:country" ], "value" : "300" } }
]
}
}

Regarding #32, the whole purpose of the VAT module is to provide just such a rule condition. If you create a new tax, you can add a condition called "Order billing country is inside the EU" or "Order delivery country is inside the EU", and the tax will automatically apply according to the country the buyer is in.

I've also just updated VAT Number with a rule to check to see if the buyer has supplied a VAT number, so that you can charge tax or not according to that parameter.
http://drupal.org/node/1054850#comment-5821452

Together, these two conditions handle case #2.

In considering further case #3, I have arrived at the conclusion that should a module support the ability to insert prices with tax already included, and then eventually REMOVE the tax according to some condition, that functionality should be handled directly by uc_taxes rather than any other contrib module like uc_vat.

Therefore, I'll complete this port of uc_vat by simply adding the ability to label the display price according to your configuration, but won't add any functionality regarding actual tax calculation, as that should best be left to uc_taxes.

Look for the final(?) version of this port later today or tomorrow.

I haven't really been keeping an eye on this thread or this issue queue recently but it seems like there's a lot of activity going on.

Ideally, I'd like to deprecate uc_vat entirely for Ubercart 7.x-3.x and merge these features into core, as core already supports "inclusive taxes" like VAT to some extent. @aacraig and others, let me know if you think that's a good or bad idea.

For us, it would be a very good idea to have this functionality in the core. There is already some duplication regarding inclusive vs. exclusive taxation, so it would reduce some confusion.

May I add, it would be great to be able to customise the text message, other than by means of String Overrides, but more like other aspects of the core, if possible, though this is not a priority.

I agree that all use cases specific to the European VAT tax can probably be generalized out and therefore handled by the core taxes module. In writing the D7 port trying to avoid overlapping uc_taxes has been the biggest consideration, and in the end there's really not much for uc_vat to do except provide a condition of all European countries.

Australian GST sounds like Italian VAT. The tax is included in the product price. The total on the invoice/receipt is the total of the price. There is one line to display the total GST but it is not added to the total of the invoice because it is not included. Visitors to Australia can buy goods including GST then claim the GST back at the airport. GST exempt prices are only displayed on sites selling to other countries.

#35 String overrides is useless in this area because the one term may have to be overridden two ways on the same page. I would like to see invoice templates, and similar output, go through token_replace. We can then use Token ex, http://drupal.org/sandbox/peter/1504138, to add site details that are not in Ubercart or site configuration.

@aacraig: I'm not sure If I understand you correctly. What I want is simply that there is no VAT added anywhere in the shop (my prices already include VAT). However, I do need it on my invoice. Right now, is there any way to achieve that in D7?

@remkovdz clarification required when talking about "included on the invoice". Do you need it added into the total?

This is one problem with the old tax calculation. If you add an amount, say shipping, to the end of the invoice, it is added into the total. The same happens with tax. If your prices include tax then you include a tax amount at the end, it is added in the same way as shipping. The change has to display the tax on the invoice without adding it in. The problem is complicated by some cases where there are additional taxes added in even when the prices include a sales tax.

Hi Peter,

I would something like this:

Shop
Product 1: €50 (incl VAT)
Product 2: €69 (incl VAT)
Total in cart/checkout/review: €119 (incl VAT)

Invoice
Subtotal: €100
VAT: €19
Total: €119

Thanks!

@remkovdz: Ubercart can already do that without uc_vat, if you enter your prices excluding VAT then use "Include this tax when displaying product prices".

That means I would have to calculate all my existing products so that they are input without VAT....?

I just had a good conversation with a client about this. Here are my conclusions:

Any functionality having to do with taxation should be included in uc_taxes. This is just good software development practice.

Until now, the European VAT system has not presented any use case that is not also a possible use case in other tax system, as pointed out by @peterx regarding the Australian system. This includes the notion of inserting prices with the tax already included and then removing that tax given certain conditions. This could easily be implemented in uc_taxes by adding a "negate" style checkbox in the tax metadata edit form, and adjusting price displays and calculation accordingly.

The only real role that uc_vat should have is supplying the appropriate conditions to Rules so that uc_taxes knows whether to tax or not based on the purchaser's location. This IS specific to VAT, and therefore the most appropriate place is in uc_vat. There is a strong argument to merge uc_vat and uc_vat_number at this point, as they are inter-dependent for any store that wants to operate legally as far as VAT tax is concerned.

On the notion of inserting prices with the tax already included, I am against it no matter what system the store is subject to. It's simply bad accounting methodology. It complicates the math for reports, billing and everything else. Store owners should always insert the base price to which taxes, shipping and extra charges may be added. If you want to display the price with the tax included, that's fine, and uc_taxes already offers a way to do that (and set your own string, to boot).

I could see the use of a uc_tax_calculator module as an extension to uc_taxes which allows store admins to calculate the base price to insert, if they don't already know it, through some ajax mechanism.

tl;dr - Move all tax functionality to uc_taxes, keep EU tax condition in uc_vat, possibly merge uc_vat and uc_vat_number

@aacraig: Thanks, that all makes sense to me.

On the notion of inserting prices with the tax already included, I am against it no matter what system the store is subject to. It's simply bad accounting methodology. It complicates the math for reports, billing and everything else. Store owners should always insert the base price to which taxes, shipping and extra charges may be added.

I definitely agree with this. Internal storage should always be tax exclusive, so reporting and other calculations don't have to worry about tax.

However, I think it may be possible to extend price fields in the product edit UI so they have a dropdown box next to them where the user can select whether the price includes a tax, and the conversion to tax-exclusive prices is done on save and undone when reloading for editing. I think this feature could also be a candidate for core - as we support displaying tax inclusive prices to end users, why not do the same for admins.

I am also not opposed to including a basic Rules condition for EU taxes in core, simply for convenience.

The D6 version of uc_vat did just that -- if prices were marked as including tax, then it calculates the tax on the fly and displays that price in the admin form, then removes it to store it in the database.

I don't like this approach because adds an extra level of complexity which is a vector for bugs. It also displays false data to the user -- the database stores one value, but that value is altered before it's presented to the user, causing the user to have a poor concept of the data model. This will possibly cause problems in unexpected ways in other parts of the system. For instance, if another module displays prices, it would reasonably expect to display whatever value is in the database, without performing the tax transformation, so the admin could enter 10 in the price field and then be confused when a contrib module displays it as 8.50 somewhere on the site.

I think it's much better in the long run to teach admins to insert correct data and then configure how that data gets displayed.

Recalculating tax can be right or wrong depending on the tax system. The tax calculated for the total of the taxable items in the invoice can be different to the sum of the tax on individual items because of rounding errors. Your local tax laws will tell you to use one value or the other.

Let me also include my 2 cents...

I live in Belgium, and here, all the prices are always displayed with VAT (21%) included. Everywhere. At least everywhere non-B2B. I think that's the case in most European countries where VAT applies.

So prices are always entered with VAT included.
Prices are also always rounded to 2 decimal places and used like that in calculations.
Therefore, I don't think it's possible to simply recalculate the price when entering it, and storing it in the database without tax, as this would give problems with rounding. Let me give you an example:

When an item is sold in a store for 100.00 €, the invoice looks as follows:

* item : 82.64 €
* VAT: 17.36 €
* total: 100.00 €

the base price is calculated by dividing the original amount by 1.21 (100/1.21)
the VAT is calculated by subtracting the base price from the original amount (100-82.64)

if you would put the amount without tax (82.64) in the database, and then add the tax afterwards, you get the wrong original amount:

82.64*1.21 = 99.99 €

So that's not the original 100.00 € we were displaying!

Of course this could be avoided by storing the base price in the database with more precision. But I'm not sure if that's financially correct. Usually unit prices (with vat included) have 2 decimal places, with some exceptions like gas prices which have 3.

Also what Rafal sais in #32 applies here:

> the tax should only not apply if (VAT Number Provided and Validated AND seller country <> buyer country AND buyer country is in EU)

So this means NOT paying VAT is the exception rather then the rule, so I think in this case it would actually be better to store the amount with VAT included in the database, and only subtract the VAT in the above case.

In our use case, which is international B2B, we need to store prices without any tax, and add the tax at checkout, as it may apply. Since our customers are EU-wide, most of the time we do not charge VAT, only when the customer is Irish, or if they do not have a VAT number and are located in EU.

I think the idea of storing prices with more precision, to allow for rounding when displaying tax-inclusive prices, sounds good.

Regardless of the final price, or the transformations required to get there, it's still safer to store the individual components of the price separately, and do the arithmetic at the end.

You could also argue that since 99% of your customers choose the $15 overnight shipping, we should just store the price with the shipping costs already included in the price, but of course no one is doing that.

@fretje succinctly describes the problems inherent with manipulating the data behind the scenes. Since Ubercart needs to work with ANY tax system and not just the EU VAT system, it must set out a workflow that works for everyone. AFAIK the only workflow is:
1. insert the price base price
2. add taxes at the end
3. optionally display taxes in the price (as they do in Belgium, etc.) to customers in the catalog

This is already completely possible with uc_taxes and the recent D7 port of uc_vat. The shop owners simply need to adapt and insert tax-free prices instead of the VAT included price.

Of course this could be avoided by storing the base price in the database with more precision. But I'm not sure if that's financially correct. Usually unit prices (with vat included) have 2 decimal places, with some exceptions like gas prices which have 3.

Ubercart already stores prices to 5 decimal places internally to avoid this issue.

Regarding tax inclusive prices ... I can see the issues from a systems perspective and why, as a dev, one may prefer store admins to add base prices, however this doesn't always make sense from a business perspective.

Pricing decisions are often made based on market factors and once you have decided to sell your widget for £35.99 (including VAT) that is what you want to enter. It is the job of the tax modules to make the calculations and produce the reports for the accountant.

I think for a majority of retailers in the EU this will be the case.

FYI, having used OpenCart previously, unless that has changed recently, you insert the base price without tax. This would be my preferred method as well for the reason aacraig mentioned. It is true however that even with a 5 decimal precision this causes issues when generating invoices, but that is true no matter what you do (depending on item price and tax rate).

Would it make sense to make this into a D7 branch of the module, as it has already been done with uc_vat_number? Also, the name of the module, which says "Ubercart 2" might need to be updated. Or would it be better to roll it into uc_taxes as per #44? I am just wondering what the feelings are about the future of this functionality.

We're talking about two separate issues.

From the front end point of view, there's no problem offering the store administrator the possibility to insert prices inclusive of tax.

However, this shouldn't be managed by uc_vat. This feature should be included in uc_tax, as it is a possible use case for any tax, not just VAT.

Can somebody explain why there is no 7.x branch to admit standard patches and to obtain a version that can be easily installed with drush? Very desirable since uc_vat_number depends on it!

Ubercart 7.x-3.x can already display prices including tax without needing a separate module, and the rest of uc_vat has not yet been ported to 7.x.

Instead, there are two feature requests for Ubercart which would make uc_vat obsolete:

#1333868: Allow prices to be entered inclusive of tax
#1370476: Show shipping with tax

longwave you might be right, but then still there is a dependency of uc_vat_number on this module. Or do you know an alternative to that one too?

That's up to the uc_vat_number maintainer. I am unsure why that module should need to depend on uc_vat, when there is no D7 version of uc_vat.

Even if it's not officially existing, the 'weight' => lines could be removed from this module. Ubercart allows the admin to reorder the cart and checkout panes but the reordering doesn't work if the module overrides the weight settings.

Thanks to this great discussion about the VAT almost all TAX and VAT issues are covered in UC now. I am missing one important issue for my web shop in the Netherlands. And that is multiply VAT rates. Here in the Netherlands we have 2 VAT-rates (actually three if we also count 0% VAT, for services without tax like some courses).

• We have 6% VAT for product necessity of life. These are mainly product like food, mike and softdrink. Most products you can eat and drink (except liquor and restaurant food)
• and 21% for (almost) all other products.

We sell food supplements with 6% VAT and gels (for on your skin) with 21% VAT. This products are in the same product category. In Drupal 6 Ubercart 2 we could handle this with uc_taxonomy_tax. A taxonomy vocabulary named VAT with two term 6% and 21%. On every product we could choose the VAT rate for this product. The uc_taxonomy_tax module added a selection on the add taxes (/admin/store/settings/taxes/add) where you can choose the taxonomy term for which this tax (including the rule condition) was valid.

I really mis this feature, because the uc_tax module applies just one tax rate/rule on checkout. Now it's not possible to configure the tax-rule to apply on a line-item like a product, it always apply on all products in th cart.

Retail and Consumer sales

Then we sell to retailers and consumers. On the product we enter two prices: one price including VAT for consumers and one price for the retailer, a purchase without VAT (as discussed here above)

This is what i need:

Consumers

Prices including VAT
3x Product-1 € 100,00 (21% VAT)
1x Product-2 € 50,00 (6% VAT)

Subtotal € 150,00
Shipping € 10,00
--------------------------------
Total € 160,00

Retailers

Prices excludingg VAT
3x Product-1 € 53,72 (21% VAT)
1x Product-2 € 30,66 (6% VAT)

Subtotal € 84,38 (products)
21% VAT € 11,72 (products)
6% VAT € 1.84 (products)
Shipping € 8,26 (excl 21% VAT)
21% VAT € 1,74 (Shipping)
--------------------------------
Total € 107,94

(it's allowed to add the 21% VAT for shipping and products in one line-item) the we get this:
3x Product-1 € 53,72 (21% VAT)
1x Product-2 € 30,66 (6% VAT)

Subtotal € 84,38 (products)
Shipping € 8,26 (excl 21% VAT)
21% VAT € 13,46 (products)
6% VAT € 1.84 (products)
--------------------------------
Total € 107,94

Can any one help me to point me in the right direction how-to accomplish this please?

Neorg, did you ever find a solution for this? This is applicable for me due to state tax rules being based on each individual product being taxed at different rates based on their price.

e.g.
9.25% (up to $1,600)
9.65% ($1,600.01 - $3,200)
7.00% (above $3,200)

Has anyone come up with a solution for taxing individual products in the cart as apposed to the full