I'm trying to apply a discount to product price using product pricing rule. It worked perfectly for product prices that do not include tax. However, when I tested with product with prices that include tax, the prices shown on the checkout page were not correct. Apparently, the tax was also applied to the discount amount, overstating the tax amount.

The rule I used a simple 'subtract an amount from the unit price' and the tax was of VAT type with 10% rate.

Product A: $12 (tax included)

Discount: $1 (applied through rule)

Price of Product A after discount: $11

Tax rate: 10%

On checkout page:

Product A Qty=1: $11

Subtotal: $9.91 -> Subtotal should be $10

VAT: $1.09 -> Tax should be $1

Order total: $11

Is this by design, or am I missing something?

## Comments

## Comment #1

pcambra CreditAttribution:pcambra commentedIf you create a VAT inclusive with price 12$, it means that the VAT is calculated over 12$, no matter which discount are you applying, so, if you add an 1$ discount, the VAT is still applied over 12$ which is the 1.09$ you see in the checkout page and the value of the item is 9,91 to get a total of 11$ (12$ minus 1$ of discount)

I'm not sure either if this is the desired behavior, we may need to include the option of having the discount applied before the taxes or afterwards.

## Comment #2

n9352527 CreditAttribution:n9352527 commentedThe calculation, considering only the amounts, as it is now is correct. But, the amount of tax payable is more than it should be. This would present a problem in filing the tax.

To get the correct amount of tax from the tax-inclusive price after applying a discount, the new tax amount should be calculated again from the discounted price.

Price inclusive tax: $12

Apply $1 discount: $12 - $1 = $11

Get the discounted price excluding tax: $11 / 110% = $10

Get the new tax amount: $11 - $10 = $1

Discounted subtotal including tax: $11

The above results in correct tax payable amount. But I talked to a friend that faced a similar problem, and he pointed out that although the approach above works, the more correct approach is to get the price excluding the tax first, apply the discount, and then calculate the new tax.

Price inclusive tax: $12

Price excluding tax: $12 / 110% = $10.91

Apply $1 discount: $10.91 - $1 = $9.91

Get the new tax amount: $9.91 * 10% = $0.99

Discounted subtotal including tax: $10.90

However, I prefer the first approach because it is easier to mentally obtain the discounted subtotal amount. I mean, if the price inclusive tax is $12 and I want to discount it for $3, the discounted price including tax is $9. Reversely, if I want to set the discounted price including tax to $8, for example, I could get the discount amount easily, which is $4 in this case.

I tried to alter the weight of the tax and the discount rules, so that the discount was applied first, but it didn't make a difference. So, I guess for tax inclusive price, the tax amount displayed in the checkout page was calculated differently, maybe not in response of 'Calculating the sell price of a product' event?

I'm going to look into this and try to figure out where the tax is calculated in the next few days.

## Comment #3

mikejoconnor CreditAttribution:mikejoconnor commentedI'm not entirely sure that this is a bug, I think its actually more of a feature request, price modification action that can take into account tax inclusive vs tax exclusive product pricing.

At the end of the day, if I see a product for 9.99€, with a 1€ discount, I expect my cost to be 8.99€, not 8.79€

I'm marking this as a feature request. I could be wrong, but I would like to get some discussion on it. Overall, I think this should be address in a discount module, but thats up for debate, since we do offer products inclusive of tax, we may need to offer price modifications inclusive or exclusive of tax.

## Comment #4

Artusamak CreditAttribution:Artusamak commentedI agree that it should be something configurable to have two options:

1/ final price = VAT * (VAT excluded price - discount)

2/ final price = (VAT excluded price * VAT) - discount

And it should be managed by the discount module.

## Comment #5

Jax CreditAttribution:Jax commentedVAT is a value added tax so it will always be calculated on the price the product is sold at, not the configured base price.

In our use case with have two separate price fields, commerce_price and field_promotion_price. When the promotion price is available it should be used for the product. This was easy enough to accomplish with rules.

But at the checkout the VAT is still calculated on the original price instead of the price of the line item which results in a completely incorrect VAT total. We currently solved it by entering the products VAT exclusive but that gives a whole lot of other issues.

## Comment #6

rszrama CreditAttribution:rszrama commented@Jax: Perhaps you just needed to reorder your product pricing rules so the rule to apply the VAT has a higher weight than the rule to swap the price fields?

## Comment #7

Jax CreditAttribution:Jax commentedTo make sure I changed the weight of the rule to 1 but that didn't change anything. Moreover there are two VAT calculation thingies available:

A Component:

Calculate Btw (Btw = VAT in Dutch)

commerce_tax_rate_vat

Action: Apply a tax rate to a line item

A Rule:

Calculate taxes: VAT

commerce_tax_type_vat

Action: Calculate taxes for a line item

It seems that the first one is use to calculate the vat for product display and the second one to get the VAT on checkout (but I could be wrong).

Anyway, the screenshot vat.png illustrates the issue. I have a product that is priced at 1000 EUR VAT incl. by default and has a promotion price of 10 EUR VAT incl. So in the cart it's correct but at the VAT calculation the original price is used.

When I enter the prices VAT exclusive everything happens correctly but then I had other issues for displaying the prices correctly and it was impossible to have some prices VAT incl. (with a VAT rate of 21% inputting 8.26 gave 9.99 and inputting 8.27 gave 10.01 but that is another issue). So the latter is indication that it's sometimes necessary to be able to input VAT inclusive.

## Comment #8

farald CreditAttribution:farald commented1/ final price = VAT * (VAT excluded price - discount)

Is there any way to configure this?

I need a rule that reads a percentage field (1-100) and calculates a discount based on that.

This is read from a field on the owning user entity.

Here's an export:

`{ "rules_discount_on_user_entity" : {`

"LABEL" : "Discount % on user entity",

"PLUGIN" : "reaction rule",

"WEIGHT" : "-1",

"REQUIRES" : [ "rules", "commerce_line_item", "commerce_product_reference" ],

"ON" : [ "commerce_product_calculate_sell_price" ],

"IF" : [

{ "NOT user_has_role" : {

"account" : [ "site:current-user" ],

"roles" : { "value" : { "1" : "1" } }

}

},

{ "entity_has_field" : {

"entity" : [ "commerce-line-item:order:owner" ],

"field" : "field_user_discount"

}

},

{ "NOT data_is_empty" : { "data" : [ "commerce-line-item:order:owner:field-user-discount" ] } }

],

"DO" : [

{ "data_calc" : {

"USING" : {

"input_1" : [ "commerce-line-item:order:owner:field-user-discount" ],

"op" : "-",

"input_2" : "100"

},

"PROVIDE" : { "result" : { "remainingpercent" : "remainingpercent" } }

}

},

{ "data_calc" : {

"USING" : { "input_1" : [ "remainingpercent" ], "op" : "\/", "input_2" : "-1" },

"PROVIDE" : { "result" : { "result" : "Calculation result" } }

}

},

{ "commerce_line_item_unit_price_divide" : {

"commerce_line_item" : [ "commerce-line-item" ],

"amount" : "100",

"component_name" : "discount",

"round_mode" : "0"

}

},

{ "commerce_line_item_unit_price_multiply" : {

"commerce_line_item" : [ "commerce_line_item" ],

"amount" : [ "result" ],

"component_name" : "discount",

"round_mode" : "0"

}

}

]

}

}

See attached image. Even if the caclulate VAT rule is long down in weight, this happens.

Point is, this discount should be substracted from the base price.

Now it's subtracted from the price+vat, then displayed above vat. Looks a bit weird.

## Comment #9

Maciej Lukianski CreditAttribution:Maciej Lukianski commentedI am changing this to a bug report again to put more discussion into it.

I honestly cannot think of a situation where you would want to change nett price and keep the original VAT amount. I do not know of a EU country that would support such calculation or any business scenario.

Currently if I reduce the price for a user by 90% on a 20% VAT inclusive price, I will get a negative nett amount. How can this be logical?

The amount of VAT should be calculated so that on all occasions at the end:

Nett price + VAT AMOUNT = Total price

Nett price * (1 + VAT RATE) = Total price

This is how you HAVE TO (you really do have to) invoice each single VAT taxed sale in Europe. Why would you want to display something that is not true?

@mikejoconnor #3

if you have an item at 9.99€, with a 1€ discount, the final price should be 8.99€, but it should consist of subtotal and VAT in proportions which meet the two equations above and currently it does not. VAT is calculated from 9,99 and substracted from 8,99 to come up with nett.

## Comment #10

farald CreditAttribution:farald commentedBasically, we need another field input widget that enables the inclusion of VAT, but

withouthaving it hardcoded towards the base price.Basically, a shop owner would want to price a product £10 including tax ($8 + (25% of £8)).

But, when this is hardcoded, using 'include VAT' in the standard field formatter, we override rules, making a lot of problems when calculating complex prices.

To stop this, we could create formatter that uses JS to do the calculations towards user supplied total price, but saving only the base price. So, when 'include tax' is selected, just calculate the price and save the base price.

Does that make sense?

## Comment #11

rszrama CreditAttribution:rszrama commentedReviewing some old issues; I'm actually going to close this out as a duplicate of #1825886: Add rules actions for applying discounts to prices with VAT included where pcambra has a patch that would solve this scenario.