Bug in EU Advanced Compliance with shipping taxes?

[30knees]

21 hours ago, Occam said:

Of course!

German invoice with  mixed taxes:  RE000019.pdf

And please, don't try to "approve" the Cart.php. Leave the code (where it deals with AEUC) like this:

 if (Configuration::get('PS_ATCP_SHIPWRAP')) {
            if ($useTax) {
                // With PS_ATCP_SHIPWRAP, we apply the proportionate tax rate to the shipping
                // costs. This is on purpose and required in many countries in the European Union.
                $shippingCost *= 1 + $this->getAverageProductsTaxRate();
            }
        } else {
            // Apply tax
            if ($useTax && isset($carrierTax)) {
                $shippingCost *= 1 + ($carrierTax / 100);
            }
        }
        $shippingCost = round($shippingCost, _TB_PRICE_DATABASE_PRECISION_);

        Cache::store($cacheId, $shippingCost);

        return $shippingCost;

 

That's exactly the code that's already there. I don't understand what you suggest doing, unfortunately.

[30knees]

The fix is to replace the whole tb cart.php with the last PS cart.php. But I don't know whether this has any other effects elsewhere.

EDIT: Gross tax shipping (i.e. incl. tax) should be 4.80.

tb cart.php

PS cart.php

Edited December 13, 2020 by 30knees

[Occam]

1) It makes no sense to open several topics for the same problem.

2) From your example it is not clear how much the gross amount of the shipping costs actually is.

Or did you mean shipping costs tax incl. when you wrote "Gross tax is set at 4.80"? If so, the problem can be identified as a bug in tb's AEUC, because though the taxes are correctly calculated, they are computed not from the net shipping amount (4.25), but from the shipping price incl. taxes (4.80)!
This bug is not new, but still unsolved. I totally forgot that this was the reason why I use my own modified AEUC in tb. Works properly without any changes in classes like Cart.php.

 

 

[30knees]

1. Agree with you - but I think they're separate issues (apart from the German language post), ie can I simply swap the cart.php files?

2. True, I meant gross shipping costs. I updated to clarify that. Thank you for the pointer. 

I'm not sure it's a bug in tb's AEUC, though. With PS cart.php everything works. 

Quote

because though the taxes are correctly calculated, they are computed not from the net shipping amount (4.25), but from the shipping price incl. taxes (4.80)!

In my opinion, this is OK. The customer should know the gross shipping cost in advance, i.e. 4.80. The taxes for the shipping cost will depend on what's in the shopping cart.

The display of the net or gross shipping price in the invoice is a different matter.

Quote

This bug is not new, but still unsolved. I totally forgot that this was the reason why I use my own modified AEUC in tb.

Mind sharing? 

[Traumflug]

3 hours ago, Occam said:

I totally forgot that this was the reason why I use my own modified AEUC in tb.

Code discussed here isn't part of the AEUC module. The module just provides a switch to enable some code in core.

[30knees]

I thought I'd share a summary I wrote for datakick of this problem, as I believe it affects all EU countries and the UK and means thirtybees isn't 'fully compliant' in a sense:

In sum there are two elements that work together to create non-compliance: 1) the tax element, 2) the consumer information element.

Regarding 1) the tax element

If you sell two products, one at a VAT rate of 10% and one at a VAT rate of 5%, and you charge for shipping, the VAT rate for the shipping (which is a separate service to the sale of goods) is dependent on the basket of products sold.

There are two ways the shipping VAT may be calculated:

a) Proportionally according to the VAT proportion in the basket.

Product A costs 32.66 net / 34.95 brutto with 7% VAT.
Product B costs 2.50 net / 2.98 brutto with 19% VAT.
--> Shipping costs 4.95 brutto with proportional VAT.

Product A represents 92.98% and Product B 7.11% of the net total.

So the VAT of the shipping costs should be proportionately split:

92.14% of 4.95 = 4.56. This means 4.56 brutto are taxed with 7%, which gives us 4.26 net + 0.30 VAT (7%) = 4.56 brutto shipping

7.86% of 4.95 = 0.39. This means 0.39 brutto are taxed with 19%, which gives us 0.33 net + 0.06 VAT (19%) = 0.39 brutto shipping

Net shipping costs: 4.95 brutto - 0.30 VAT - 0.06 - VAT = 4.59 net

b) According to the higher value VAT rate in the basket.

Product A costs 32.66 net / 34.95 brutto with 7% VAT.
Product B costs 2.50 net / 2.98 brutto with 19% VAT.
--> Shipping costs 4.95 brutto with 7% VAT. This is because Product A is more than 50% of the total.

Regarding 2) the consumer information element

The consumer needs to know the brutto shipping costs upfront. Currently, with tb, the customer can only know the net shipping costs upfront because the variable brutto is calculated from the fixed net unlike in the example above where the variable net is calculated from the fixed brutto.

Sources for tax element

Looking for material in English I found out that this requirement actually is European-wide one. It follows from a Court of Justice of the European Union case and a VAT directive. It's just that some countries (tax authorities) implement it stricter than others. Here is something in English: https://en.blog.taxdoo.com/umsatzsteuer-versandkosten-nebenleistungen/

Sources for information element

https://europa.eu/youreurope/citizens/consumers/shopping/shipping-delivery/index_en.htm#shortcut-1

  Quote

You must always be clearly informed of the total price for your purchase, including delivery** and other related costs

Total price is understood to be incl. taxes. But even if you argue and say that the customer sees the total shipping costs in the checkout before clicking buy, it's just not user friendly to have in the shipping costs FAQ part of your shop: Your shipping costs are 4.50 excluding tax - the exact amount including tax depends on your purchase, as the taxes depend on what you buy. 🙂

[Smile]

I have noticed this bug myself long time ago and have always payed to much taxes on shipping to the government. Will try to push this bug to be fixed a.s.a.p.

[datakick]

New feature was just included in the bleeding edge. It should resolve this proportionate shipping tax issue.

In carrier settings you can now specify if the shipping cost entered in the range table are with or without tax:

By default this is set to 'No', for backwards compatibility. 

If you set this to Yes, and enable 'Proportionate tax for shipping and wrapping' then the system should work as expected. For example, I have set shipping cost to 100EUR including tax, and added two products with different tax rates to the cart. Result is following: 

@30knees I would like you to ask to test the solution, if you have some testing server. You can use core updater to update to bleeding edge - 'main' version.

[toplakd]

I've noticed one weird thing.

 

Carrier - "Prices include tax" set to NO

EU Advanced  "Proportionate tax" enabled

2 products in cart - one with set tax rate (22% for me) and one set with NO TAX,

than shipping costs are making weird changes when increasing / decreasing quantity in cart

Edited March 23, 2021 by toplakd

[datakick]

19 minutes ago, toplakd said:

I've noticed one weird thing.

 

Carrier - "Prices include tax" set to NO

EU Advanced  "Proportionate tax" enabled

2 products in cart - one with set tax rate (22% for me) and one set with NO TAX,

than shipping costs are making weird changes when increasing / decreasing quantity in cart

Yeah, I can reproduce it as well. The same problem exists in 1.2.0, though, so it's not an injection.

But I will look into it, hopefully the fix will be easy

 

[datakick]

13 hours ago, toplakd said:

I've noticed one weird thing.

 

Carrier - "Prices include tax" set to NO

EU Advanced  "Proportionate tax" enabled

2 products in cart - one with set tax rate (22% for me) and one set with NO TAX,

than shipping costs are making weird changes when increasing / decreasing quantity in cart

Actually, this is expected behaviour. 

If I have

• Product A: base price = 100, tax = 22, final price = 122
• Product B: base price = 100, tax = 0, final price = 100
• Shipping with Shipping Cost = 100, "Price includes tax" = NO
• enabled "Proportionate tax"

Then if I have 1 of each in the cart, then shipping tax is

• 22% of 1/2 * 100
• 0% of 1/2 * 100

which is 11% ==> shipping price is 111

If I put 2 products A and 1 product B in the cart, then proportion is different. Product A now account for 2/3 of shipping price, and Product B for 1/3 of product price. Result tax is

• 22% of 2/3 * 100
• 0% of 1/3 * 100

Which in total is ~14.66% => shipping price is 114.66

If I put 1 product A and 2 product B, then the result is tax is composed of

• 22% of 1/3 * 100
• 0% of 2/3 * 100

which is total tax ~ 7.33% => shipping price is 107.33

The calculations are correct, it just isn't very user friendly. That's why the option "Price includes tax" = "Yes" exists, with that the final shipping price will be always 100, and base price without tax will change for each tax bracket.

 

[toplakd]

Thank you very much for very informative explanation.

[30knees]

Fantastic, thank you! I don't have a testing server. I'll set one up.

[30knees]

On 3/23/2021 at 9:39 AM, datakick said:

New feature was just included in the bleeding edge. It should resolve this proportionate shipping tax issue.

In carrier settings you can now specify if the shipping cost entered in the range table are with or without tax:

By default this is set to 'No', for backwards compatibility. 

If you set this to Yes, and enable 'Proportionate tax for shipping and wrapping' then the system should work as expected. For example, I have set shipping cost to 100EUR including tax, and added two products with different tax rates to the cart. Result is following: 

@30knees I would like you to ask to test the solution, if you have some testing server. You can use core updater to update to bleeding edge - 'main' version.

It looks good to me, thank you! 🙂

Will it flow into the 1.2.x version, too, or shall I update the live store to the main version? 

[datakick]

5 hours ago, 30knees said:

Will it flow into the 1.2.x version, too, or shall I update the live store to the main version? 

1.2.x is for serious bug fixes only. This will be in 1.3.0 / main bleeding edge

[30knees]

On 3/23/2021 at 9:39 AM, datakick said:

New feature was just included in the bleeding edge. It should resolve this proportionate shipping tax issue.

In carrier settings you can now specify if the shipping cost entered in the range table are with or without tax:

By default this is set to 'No', for backwards compatibility. 

If you set this to Yes, and enable 'Proportionate tax for shipping and wrapping' then the system should work as expected. For example, I have set shipping cost to 100EUR including tax, and added two products with different tax rates to the cart. Result is following: 

@30knees I would like you to ask to test the solution, if you have some testing server. You can use core updater to update to bleeding edge - 'main' version.

One this I just noticed in my store (and I'm not even sure it's the fix, though it's the first time I'm noticing it). On the invoice, some products show the Base price and the others don't. The products all have the same price settings. Do you have an idea why this may be?

Edited April 27, 2021 by 30knees