[RFC][Core][Taxation] Allow configuration of which address to use to match the tax zone

[vvasiloi]

The OrderTaxesProcessor uses the shipping address to match the tax zone

Sylius/src/Sylius/Component/Core/OrderProcessing/OrderTaxesProcessor.php

Lines 83 to 88 in 40b65d1

	$shippingAddress = $order->getShippingAddress();
	$zone = null;
	if (null !== $shippingAddress) {
	$zone = $this->zoneMatcher->match($shippingAddress, Scope::TAX);
	}

and falls back to the default tax zone

Sylius/src/Sylius/Component/Core/OrderProcessing/OrderTaxesProcessor.php

Line 90 in 40b65d1

return $zone ?: $this->defaultTaxZoneProvider->getZone($order);

In most cases it works well because usually the shipping and billing addresses yield the same tax zone.
There are situation though, when this creates issues, especially in markets like US or EU.

I'm not sure wherever it should always use the billing address, but it should at least be configurable.
Having a strategy pattern with at least two built-in implementations to handle the tax zone matching, one that uses the billing address and another that uses the shipping address, plus configuration at the channel level will bring more flexibility and will allow more specific customizations without overriding the OrderTaxesProcessor just because of a private method.

Looking forward to other thoughts on this matter.

[stale]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in a week if no further activity occurs. Thank you for your contributions.

[LucaGallinari]

Hi guys, this issue is becoming a priority due to the "new" EU VAT regulations: https://ec.europa.eu/taxation_customs/business/vat/modernising-vat-cross-border-ecommerce_en

As @vvasiloi proposed, it would be great to have a configuration on each tax rates, so that it's possible to choose if the match should be based on the shipping or the billing address.

[CoderMaggie]

Firstly, I'd like to note that zone matching is for quite some time (since version 1.7) based on the billing address 💪🏼
That will be closing this issue 🔥

But as @LucaGallinari has mentioned the new EU VAT regulations, I'd like to ask if adding a setting on the channel for taxes to be based either on shipping address or billing address, would help?
Moreover, Luca, could you maybe describe how would it help you process the new regulations (I'm considering a doc on that, and your insight would be helpful 🙏🏼 )?

[vanssata]

Firstly, I'd like to note that zone matching is for quite some time (since version 1.7) based on the billing address 💪🏼
That will be closing this issue fire

But as @LucaGallinari has mentioned the new EU VAT regulations, I'd like to ask if adding a setting on the channel for taxes >> to be based either on shipping address or billing address, would help?

The EU does not care where you pay (billing address). They will be interested in where you use the service or product (shipping address).

Until July 1, the current law is for taxes as follows:

• For services are charged in the country where they are used (shipping(delivery) addresses)
• For goods (physical products) is charged in the country from which they are sent (channel address)

With the change from July 1, fees will be charged where the service/goods are used/sent (shipping(delivery) address)

[vvasiloi]

Firstly, I'd like to note that zone matching is for quite some time (since version 1.7) based on the billing address 💪🏼
That will be closing this issue 🔥

Now others will complain that it's based on the billing address and not the shipping address, that's why I proposed to make it configurable.
I guess the title is misleading, because the actual request / proposal is:

Having a strategy pattern with at least two built-in implementations to handle the tax zone matching, one that uses the billing address and another that uses the shipping address, plus configuration at the channel level will bring more flexibility and will allow more specific customizations without overriding the OrderTaxesProcessor just because of a private method.

[januzis]

Now others will complain that it's based on the billing address and not the shipping address, that's why I proposed to make it configurable.

Agree, since at least for EU based shops selling physical goods to other EU countries, tax zone matching based on the shipping address is always preferred, with the current VAT rules, as well as with the upcoming rule changes.

With the current regulation, if remote sales are under the VAT registration threshold for the target country - no separate tax rate is even necessary, VAT must be paid in the seller's country. E.g. a german shop selling goods to Luxembourg (based on the shipping address), but not more than 100 000 EUR a year, pays german VAT on sales.

With the new regulation, the threshold drops down to 10 000 EUR (EU-wide, not for a single country), so more shops will be over that limit. Using the same example, a german shop selling goods to Luxembourg (based on the shipping address), more than 10 000 EUR a year, will have to pay 17% Luxembourg VAT.

I'm not even sure what is the scenario, where tax zone matching based on the billing address is necessary, maybe when selling non-physical goods, or services? Could someone provide an example?

Either way, configurable tax zone matching strategy would be sensible. At least for our use case, channel-level setting would be enough.

[ikakarov]

@januzis The payment address is considered to be the address of use of the service / software. Because the service or software does not have a delivery address.

[januzis]

@januzis The payment address is considered to be the address of use of the service / software. Because the service or software does not have a delivery address.

Thanks, that makes sense. Again, seems like the proposed strategy pattern already used elsewhere in Sylius would be a sensible solution, covering 99% of use-cases with two default strategy implementations (billing address based and shipping address based matching), and creating a nice integration point for a custom strategy implementation for more advanced use cases (mixed software / physical goods shop, etc.).

[ikakarov]

@januzis Yes. After 1-juli, sylius model is 100% correct for EU to EU trades. But in this moment big missing part is EU to GB strategy, for my case i just crate custom tax calculator.
Another big problem when use international shipping is missing custom required attribute per country.
For example i need to sell form Italy to Brazil, but need to add required BIC number for Brazilian address, or Personal Customs Clearance Code (PCCC) for south korea.

I crate simple plugin in my project, but not useful for standalone on this moment.

[januzis]

@januzis Yes. After 1-juli, sylius model is 100% correct for EU to EU trades.

It's not correct for physical goods, it's currently matching based on the billing address, when the EU VAT rules are based on the recipient's (shipping address) country.

[ikakarov]

@januzis I agree with you. Current way is every tax in EU to get delivery address (shipping) . If you add only billing, address in checkout orders get this address for shipping. Current way is every tax to calculate only for shipping address after 1-july. From now correct way is tax for goods to calculate form channel country.

[vvasiloi]

Fixed by #12718

[CoderMaggie]

Glad we've managed to help (last minute before July 1st 😅 ) 💪🏼

I will just leave a note here that we will be looking at this topic once more, in order to provide a more "UI" solution. As now, you can reconfigure the whole application with the introduced parameter, though it would be awesome to have it configurable at least per channel.

[ikakarov]

I create very complex solution because every order in my project have two and more tax category.
My solution is:

• Create custom tax strategy for EU tax rules after 01.07.2021.
• Create tax zones with countries whit same rate.
• Get tax rate based on shipping address for stocks.
• Get tax rate based on billing address for services.