Allow display inclusive taxes to be removed via Rules

Is this because you have entered product prices including VAT?

Sorry I missed you in IRC. When you enter a price including VAT, that tax gets included in the price automatically when the product is loaded. This means Rules based evaluation concerning the tax is ignored. I can't remember if there is an open issue for removing a tax that has already been included in a product, so let's just go ahead and keep this open as a feature request. It's something we've been wanting to do but just hadn't worked out yet.

I'd like to help with this, as I'm also waiting on this feature.

I guess I want to first understand the motivation for including all prices when producing a line item from a product, though I suppose it might have been the most straightforward thing to implement.

I haven't quite thought about how tax will affect shipping costs, discounts, etc. Logically speaking, however, isn't it reasonable to initialize a line item from the product base price? Since the tax calculation rules will apply the inclusive tax anyway, the tax-inclusive price entered for a product simply is there for display. EDIT: On top of that, if you use (for example) Panels to format the price, it can be configured to use the price after applying calculations.

Beyond that, I wonder if there's any other part of Commerce that relies on the assumption that a product price is always what most customers sees, in spite of whatever rule that may have been configured to adjust the product price for an order.

I'm really surprised to not see more on this topic - which makes me worry I'm missing something obvious.... I apologise if thats the case!

As mentioned above by petednz, and in line with other topics out there I have the VAT setup running really nicely, the add tax rules are disabled. The user adds prices inclusive of tax - using the dropdown to specify which rate. Then on checkout those amounts are pulled out of the line items and displayed seperately - just as is required.

But here I run into the same issue as above - if someone is buying from a location outside the EU then they shouldn't have to pay that VAT.

All I need to get this working is some kind of data selector to use in rules that will stop the broken down tax being added back in, or to just zero it - but the shipping address or similar don't get picked up.

Is there any point where the VAT prices come back into scope of rules so this can be done? If I'm missing the obvious and someone can help - big thanks!

You're not missing anything. It's still an issue that needs to be resolved. I assume people have just been using the workaround of not using VAT inclusive product prices and handling everything through Rules (hardly ideal, I know, when you want prices incl. VAT to be round numbers).

I think there may be a related issue to trim components out n display, but I don't know how that would carry through to tax calculation.

Yup #1232320: Price components: display and rules integration

Ugh. Sorry guys, but this really looks like a bug to me.

The proposed resolution I am seeing above is:
1) For sales tax, a rule + component add a tax amount.
2) For VAT tax, a rule + component remove a previously added tax amount.
We are doing two opposite things in the same problem space, which is inconsistent.
And #2 is clearly all about undoing assumptions we have no reason to make in the first place.

Here's what I'm proposing.
In hook_field_attach_load() we only do half of the magic: calculate tax and non-tax parts of the amount, but only set the non-tax part (instead of both as we do now). Then the rules component naturally picks this up and adds the tax part.
This allows the same behavior for sales and VAT tax additions (adding conditions to control if the tax is added), making it behave like I expected in the first place (if the component doesn't fire due to a condition, the amount shown is the part without the tax).

Note that for consistency the code comment:

// Calculate the tax and non-tax parts of the price.

should be

// Calculate the tax and non-tax parts of the amount.

but that can be changed prior to commit if we agree on the proposed fix.

I can think about it, but I still don't see this as a bug. This is how the feature was designed - to intentionally reverse calculate the tax on product load. You're saying by saving a price with tax included that when it is next loaded, it should already have the tax calculated into the total price as loaded. You're effectively bypassing any Rules-based applicability of tax. This may not be documented well enough, but it's hardly a bug.

What you're proposing would change this from "entering prices including VAT" to "entering prices at what they should be if a particular VAT is applied." That's a very different thing, and it opens the door for unexpected application of pricing rules whereas before tax would always have been calculated before anything else. That assumption shouldn't be removed lightly, as it would require a careful manual review of pricing rules on any site depending on it.

As to the title of the issue - VAT tax can be conditioned via Rules, just not if you've already inputted a price including VAT (as the label reads on the form). I'm going to put it back but leave this as needs review as a potential solution... ultimately, though, I think removing a price component is going to be a preferable solution for the reasons in the above paragraph.

I can see your point, but then we're just setting bad expectations, since this is the only place we are bypassing Rules, and practically in secret.
And it forces vendors to calculate all prices without VAT in advance if they plan to sell to people outside of EU, which is a pain.

Yeah, it was definitely designed to simplify data entry for stores dealing with VAT-only transactions in-country (or region). It was never intended to be a solution for the rounding problem, though there was discussion about rounding options to better support the use of conditionally applied VAT. Perhaps there simply needs to be another module that alters the form to allow for the reverse calculation of a price given a particular tax that is not intended to actually apply the tax. : ?

At the very least, I can update the Tax documentation on DC.org. I do think the title and description already for the tax select list widget are helpful in this regard, though, so it's hard to say it's in secret:

Title: Include tax in this price
Description: Saving prices tax inclusive will bypass later calculations for the specified tax.

Description: Saving prices tax inclusive will bypass later calculations for the specified tax.

Okay, it's too obvious. Obviously put there to confuse the enemy :P

(Taking back the "in secret" part, I'm talking nonsense)

If I may be so bold as to chuck in my bit here.

I have found this to be a confusing part of VAT. I understand what is happening and the reasoning behind it, but I don't agree with it.

I see the ability to be able to enter a product's selling price including tax as nothing more than convenience. If 2 products are entered side by side, one including VAT and one excluding VAT, I would still expect them to be treated in the same way throughout the price calculation/rules process, otherwise I think that there could be quite a bit of confusion about why one is treated different to another, certainly from a non-tech perspective.

I am looking in to having to educate a current store admin to change all their prices to exclude VAT so that the product's price can be subject to the rules calculations that are set. He will then in turn need to ensure that anything else that is added is done the same way. Unfortunately all their prices include VAT, so they will need to bust out the calculators, but it currently seems to be the best way of dealing with this. I'm sure I could build something to do it for them, but the site is already live so we're trying to keep it simple.

I appreciate the discussion that is happening around this and am always massively thankful for all of the hard work that has been done.

Cheers.

Thanks for the input - it's definitely the UX that's the problem. Perhaps we should just make it completely optional whether or not you get the "tax included" select list, or as with the patch from bojanz we could always change the actual behavior in 2.x.

I think it would be nice to have the option there for store admins to enter the price inc. or exc. VAT, but I feel that the price of the product then needs to be treated the same, processed by the same rules etc.I still think that this feature is more for convenience of price entering than any different treatment of the price.

Doesn't this then help to do away with any assumptions?

I definitely agree with Shonk. Having tried both ways of approaching the VAT - it really felt in the end that adding prices inclusive of VAT was a nice convenience for the store admin - but not worth it when then trying to perform Rules calculations later on. My thoughts at the time were really along the same lines - I couldn't understand why the price was being treated differently, I do now - but at the time it didn't make any sense.

Most store owners should be familiar with the non VAT prices of their products and therefore add products excluding VAT... For the minority who have no interest in VAT exc pricing - the challenge is surely giving them a way to reverse calculate on the fly?

I was thinking about a widget that allowed a 'price preview' - this could show an on the fly price calculation next to a price field based on a standard tax rate? I admit I haven't really thought that through in detail - but in principle it could potentially solve some of the UX issues. Combined with some good documentation to explain the use cases this could work.

I'd be really interested to know what the UX is in systems like Magento etc.... Do they all expect store owners to work from a base non VAT price when adding products. What is the general expectation from clients migrating from other systems?

I was invited to this thread because I am suffering from the VAT-problems in Drupal Commerce. Maybe I can help the discussion by answering a question:

> Do they all expect store owners to work from a base non VAT price when adding products. What is the general expectation from clients migrating from other systems?

All shop/cart systems I have ever used (quite some) except for Drupal Commerce handle this topic the same way:
You define a set of VAT values (percentages), sometimes you define a group of products that shall get the same VAT value "a priori". When entering the actual price of the product you get to choose whether the price input is netto (excluding any VAT) or brutto (including the appropriate VAT value). This is, by the way, exactly what the GUI of Drupal Commerce seems to offer, while it is not how Drupal Commerce is working.
Usually the product is then stored to the DB with its REAL PRICE, which is, by definition, the netto value (excluding VAT), because VAT is a tax that is "added based on the value of the product" (therefor its name "Value Added Tax"). Again: The (price) value of the product is, by its very definition, the value with any VAT. Therefor, as VAT is always only added once, never ever twice (which is NOT what VAT is about, although other taxes my apply), it depends on the customer's/user's setting (will he get pricing quotes netto or brutto?) how the price of a product is displayed to him - ever after.

I cannot understand why Drupal Commerce uses a different approach, speaking of VAT - NOT of taxes in general. I do not see the difficulty in allowing the admin/shop owner to input a price including VAT , storing the products value as "netto" and either caching the brutto value (to spare one simple calculation) or depend the display on the user's setting (which price is he to see). In my eyes this is just the kind of granularity that Drupal aims for anyway: Having the REAL content (value of a product) stored and handling everything else through "addons".

At the moment I do not see how to solve my problem. Forgive me, if this is the wrong place, but I hope it might shed some more light on the problem of VAT (as oposite to taxes that can be added on top of each other):

Where I live we have two (actually three, including "no VAT") VAT values: 7% and 19%. Each product one can think of is clearly grouped to one of these VAT values (though the logic of this grouping is often to be questioned).
Within an online shop there are various settings necessary:
- depending on the shop owners legal situation he either has to quote VAT values of products (either the percentage value of the VAT or the amount, that is the VAT part of a products total price including VAT) OR he is not allowed to quote any VAT values at all, in the second case he may not even tell the customer "this price includes VAT", which would be against the law for this kind of shop owner
- each product has its clearly defined VAT value, so storing the products should, logically, always be "netto" (excluding VAT) plus the VAT value, since VAT values may change over time by law, while the law cannot change the product's value!
- SHIPPING costs again may be excluding VAT (depending on the shipping service used) or including VAT.
- IF shipping costs include VAT the VAT value CAN be depending on the products in the cart: Either the shipping costs VAT is the "original shipping costs VAT" (the shop only bills what the shipping service actually costs), which will most likely be 19% OR the shipping costs VAT follows the VAT value of the products with the highest value in the cart (if most of the products in the cart have 7% VAT, shippings costs must show 7% as well - et vice versa)
- if the customer lives outside the EU he has to see prices EXCLUSIVE VAT
- if the customer lives inside the EU he has to see prices INCLUSIVE VAT
- if the customer is a reseller he expects to see prices exclusive VAT but with the tax value as an information

All this is very easily handled in most shopping systems - and straight forward to set up. I think it would be even more easy to use in Drupal, if only VAT was handled the way I helped at above. Displaying the right values to the customers should be comparable simple to achieve.
The part about shipping VAT is a bit more complicated but should be easily handled through a short script.

I am very willing to help with testing, coding etc. wherever I can, since I have the urgent need to get this thing sorted out (it currently is the k.o. criterium for using Drupal for three customers). Unfortunately I find it extremely hard to get my hands on reliable documentation that actually applies to Drupal 7 in its current incarnation :-) So if there is anyone out there willing to chat with me (chat, IRC, EMail, even telephone, I'll call you up) and get this sorted out once and for all, do a doc how to do it (I volunteer to author that) or even a screen cast (dito): PLEASE let me know. I am willing to get up at any time of day or night if we can agree on a concentrated, productive "session".

+1

Unfortunately it seems that the request for clarification was more destined to postpone this matter into oblivion, not towards any real solution to the many problems with Drupal Commerce Tax Handling. I find that sad since tax handling, really, is a question of dealing with lots of tables - something a computer is better at than most human beings. So right now I am left with doing the table handling for Drupal, handling an order much easier by hand (without drupal commerce) than by help of my computer.

Sigh. Any way: I have posted a solution to the pricetable VAT inclusion problem on the pricetable module issue cue (unfortunately to the result of seemingly insulting the developer who considered the problem "works as designed").

After having suffered a lot with Drupal Commerce and having solved most problems I ran into by either hacking the code, creating weird rules or including PHP nonsense where noone would expect it I think it should be easy to handle taxes quite nicely in Drupal commerce.
The road to go would be to create products with all tax columns/attributes that might be necessary, in order to have rules taking care of the actual calculation into one "order global variable". Since taxes are depending on shipping destinations and invoice addresses the road would need a sideway of a global COUNTRY (maybe even a COUNTY) table into which all tax dependencies may point (like "product a has a tax rate of x when shipped to country/county z") creating a "tax table" depending on the country/county list analogues to a price table, but by only doing exactly what it's supposed to do, not by "automatically calculating anything".

Maybe it would be possible to put up a simple module that provides:

- a country/county table (editable) where products are shipped/invoiced to
- an attribute for every product that puts a specific tax (or several) into the tax list depending on shipping/invoicing destination
- a rule that cycles through a cart, picking all country/county dependencies (maybe even more like "customer is entitled to netto delivery") and collects all taxes into one or more oder-global variable
- a virtual product put into the cart (ONCE at display, being replaced everytime the cart is called up - "ruled") that simply holds all taxes, nicely listed and ordered by their amount and meaning

This way the problem the thread opener described should be easily solved: By changing the destination country of an order the "tax runner rule" would simply re-calculate the tax pot.

What have I missed, where's my mistake?

Honestly the lack of any debugging, object inspection, or action evaluation makes rules totally useless.
That is, unless you wrote the module. In many cases I've spend days if not weeks trying to "do it the right way" using rules and end up throwing up my hands and just writing a simple module instead.

I'm not convinced that using rules to drive a large section of the business logic for Commerce is a good idea. Especially as it relates to taxes.. for California alone you end up entering literally 8000 rule sets to evaluate each zip code/county/city combination.

That is PURE MADNESS!!

Such is why you can implement actions for things that simply cannot be decomposed. I believe your need calls for a Commerce Tax Calfornia module (or something to that effect).

Yeah zhangtaihao,
I'm beginning to come to the realization that 8000 individual rules that evaluate against the customers zip code and city name may be a serious memory hog on the server. Internalizing the evaluation in a custom module that exposes the results to rules may be the better option.

It hides the business logic from administrators, but also provides better performance.

Yep, other states have similar modules, and in this case, I'd probably just try to find a web service to integrate with that performs the calculations for me.

Finally had a chance to roll a patch for this issue while sitting in bojanz's session at DrupalCon Prague. : )

This is an initial implementation that needs some UI consideration before going in, but I'd love some additional review. Basically it just gives you an action to remove any taxes that have been applied to a line item. It gives you the option to increase the base price of the line item by the amount of tax removed, such that a product whose price was entered including VAT can be reverted to the entered price amount when the tax is removed instead of just removing the tax from the price.

It can go from:

Entered price: 100.00 incl. VAT
Unit price components: 90.00 base price amount, 10.00 VAT amount

To:

Unit price components: 90.00 base price amount

Or:

Unit price components: 100.00 base price amount

Right now it works on all tax price components regardless of the tax type, but it might make sense to limit it just to VAT since those are the only ones you should technically need to be removing. In a sales tax scenario, you just wouldn't apply the tax in the first place.

It also doesn't limit itself to any particular tax rate - it just removes them all. It might be nice either as part of this patch or another to be able to limit it to specific VAT rates.

25: 1240216.remove_taxes_action.patch queued for re-testing.

Hi,
I use this patch to remove tax for all countries outside EU. So I created a rule to check the country of the shipping address. I inserted all EU countries in the value field an activated the negative selection.
My problem now is that all product prices are displayed without tax by default. People need to register and set up an address inside EU to see prices wiht tax instead. Is there a way to set default prices with tax, so that anonymous people, not having a shipping address, see the price with tax?

I tried to combine the country-condition with some other ones but didn't manage to get it right.

Hi @vistree, it helps when you export your rule here. Not that I know that I can help you. But may be.
greetings, Martijn

Hi Martijn,
thank you for your reply. Attached, I sent my rule. Maybe someone can help????
To make a mulit selection of countries work (is one of / begins with), I had to implement the following patch: https://drupal.org/files/commerce-order-1976480-1.patch

{ "rules_remove_vat_outside_eu_negative" : {
    "LABEL" : "Remove VAT outside EU",
    "PLUGIN" : "reaction rule",
    "WEIGHT" : "9",
    "ACTIVE" : true,
    "OWNER" : "rules",
    "TAGS" : [ "Commerce Tax" ],
    "REQUIRES" : [ "commerce_order", "commerce_tax", "commerce_product_reference" ],
    "ON" : { "commerce_product_calculate_sell_price" : [] },
    "IF" : [
      { "NOT commerce_order_compare_address" : {
          "commerce_order" : [ "commerce-line-item:order" ],
          "address_field" : "commerce_customer_shipping|commerce_customer_address",
          "address_component" : "country",
          "operator" : "is one of",
          "value" : "BE\r\nAT\r\nBG\r\nCH\r\nCY\r\nCZ\r\nDE\r\nDK\r\nEE\r\nGR\r\nES\r\nFI\r\nFR\r\nGB\r\nHR\r\nHU\r\nIE\r\nIT\r\nLT\r\nLU\r\nLV\r\nMT\r\nNL\r\nPL\r\nPT\r\nRO\r\nSE\r\nSI\r\nSK"
        }
      }
    ],
    "DO" : [
      { "commerce_tax_remove_taxes" : {
          "commerce_line_item" : [ "commerce_line_item" ],
          "increase_base_price" : 0
        }
      }
    ]
  }
}

Hey Vistree

I had the same problem but it was easy to solve. For anonymous or new customers, the billing address / country is empty. So i simply extended the rule and check if the billing country is not empty.

{ "rules_remove_vat_for_eu" : {
    "LABEL" : "Remove VAT for EU",
    "PLUGIN" : "reaction rule",
    "OWNER" : "rules",
    "REQUIRES" : [
      "rules",
      "commerce_order",
      "commerce_tax",
      "commerce_product_reference"
    ],
    "ON" : { "commerce_product_calculate_sell_price" : [] },
    "IF" : [
      { "AND" : [
          { "entity_has_field" : {
              "entity" : [ "commerce-line-item:order" ],
              "field" : "commerce_customer_billing"
            }
          },
          { "entity_has_field" : {
              "entity" : [ "commerce-line-item:order:commerce-customer-billing" ],
              "field" : "commerce_customer_address"
            }
          },
          { "NOT data_is_empty" : { "data" : [
                "commerce-line-item:order:commerce-customer-billing:commerce-customer-address:country"
              ]
            }
          },
          { "NOT commerce_order_compare_address" : {
              "commerce_order" : [ "commerce-line-item:order" ],
              "address_field" : "commerce_customer_billing|commerce_customer_address",
              "address_component" : "country",
              "value" : "CH"
            }
          }
        ]
      }
    ],
    "DO" : [
      { "commerce_tax_remove_taxes" : {
          "commerce_line_item" : [ "commerce_line_item" ],
          "increase_base_price" : 0
        }
      }
    ]
  }
}

This is great and solves my problem!!! Thank you so much!

Updated patch here. The only thing I haven't addressed was my previous comment,

"Right now it works on all tax price components regardless of the tax type, but it might make sense to limit it just to VAT since those are the only ones you should technically need to be removing. In a sales tax scenario, you just wouldn't apply the tax in the first place."

I'll take a look at that in the morning and consider what to do. It still might be useful to remove even sales taxes, and the code already adequately checked to ensure it was only increasing a base price upon removal of display inclusive taxes (though I did update the label of the checkbox to make that more explicit).

I updated the action to actually match the functionality described by the checkbox description: the unit price amount will only be adjusted in the event that a display-inclusive tax (i.e. VAT) is removed.

I thought about making the option more than binary, with an additional option to just increase the base price in the event that the tax removed is inherent to the product price (i.e. not added later via Rules), but that ultimately seems unnecessary. If you only want to increase the base price to compensate for the removal of taxes that are inherent to the product price, you can just weight the tax removal rule to -10 so it executes before any other rule that would've added taxes to the product.

Folks using previous versions of this patch may need to resave their rules to accommodate the new parameter.

Commit: http://drupalcode.org/project/commerce.git/commitdiff/d7b2fe6

32: 1240216-32.remove_taxes_action.patch queued for re-testing.

Not sure what you're doing. This has already been committed and is irrelevant for testing anyways.

Sorry I wasn't sure of the "retest" functionality, I just wanted to see the patch.

Hi,
thanks for this feature, I added a RULE to remove taxes from both the product and shipping line items.
I had to make this rule a heavier weight than the default VAT rule to make it work.

Problems solved for me.

Hi,

I am trying to setup something similar to @ayalon's rule above (I also use anonymous checkout) but to apply the action when the shipping address is anything other than the site's origin country (GB). However I'm not able to create a suitable rule because I don't seem to have the necessary tokens available. I crafted it manually thus:

{ "rules_remove_vat_for_export_orders" : {
    "LABEL" : "Remove VAT for export orders",
    "PLUGIN" : "reaction rule",
    "OWNER" : "rules",
    "TAGS" : [ "vat" ],
    "REQUIRES" : [
      "rules",
      "commerce_discount",
      "commerce_order",
      "commerce_tax",
      "commerce_product_reference"
    ],
    "ON" : { "commerce_product_calculate_sell_price" : [] },
    "IF" : [
      { "commerce_product_has_type" : { "commerce_line_item" : [ "commerce_line_item" ], "type" : "product" } },
      { "entity_has_field" : {
          "entity" : [ "commerce-line-item:order" ],
          "field" : "commerce_customer_shipping"
        }
      },
      { "NOT data_is_empty" : { "data" : [ "commerce-line-item:order:commerce-customer-shipping:commerce-customer-address:country" ] } },
      { "NOT commerce_order_compare_address" : {
          "commerce_order" : [ "commerce-line-item:order" ],
          "address_field" : "commerce_customer_shipping|commerce_customer_address",
          "address_component" : "country",
          "value" : "GB"
        }
      }
    ],
    "DO" : [
      { "commerce_tax_remove_taxes" : {
          "commerce_line_item" : [ "commerce_line_item" ],
          "increase_base_price" : "0",
          "tax_rates" : { "value" : [] }
        }
      }
    ]
  }
}

This pukes with the message: "Data selector commerce-line-item:order:commerce-customer-shipping:commerce-customer-address:country for parameter data is invalid."

Without that condition, the VAT is removed site-wide, including on product listings.

I also tried applying this action in a loop to all line-items in the order as a checkout rule, but that I'm guessing is supervened by the VAT being reapplied as the sell-price is constantly recalculated. Isn't there a way to ensure this adjustment is only made within the context of the checkout, after a shipping address is entered?