Introduce the concept of a taxable type

[dwkitchen]

Our TaxType resolvers are on the whole actually resolving the Place of Supply. There are some common rules that work across the globe.

The taxable can either be goods or services, but there is now a growth of countries creating a new classification of digital.

Generally the Place of Supply for goods is the destination, and services the source.

In the EU this has been complicated by trying to unify 28 different countries and there are a total of 16 possible taxable types that define the Place of Supply. There are three possible results of these results; the source, the destination or the location of the thing upon which as service is being provided.

In addition to the taxable type the Place of Supply can also be effected by the status of the supplier and the customer, i.e. if they are a business and registered for tax in their own country and/or the others country.

The same situation as found in the EU may be created in India as they also have states that can set different GST rates in a common GST zone.

Our current implementation of the EuTaxTypeResolver is to simplistic, it currently only covers 3 use cases but we are aware of more use cases in use on existing Drupal Commerce 1.x sites.

When a taxable is passed to the resolver it needs to include the taxable type. If if appropriate the locations of the supplier, the customers and the destination of the goods or the location the service took place.

The list of taxable types is not common across all tax types (accept those in the EU) and we have discussed the idea of creating a "tax tag" that would reference the taxable type for each tax type resolver.

For example Canada has a similar number of taxable types (http://www.cra-arc.gc.ca/placeofsupply/) as the EU, but they are different and there would need to be a greater range than each zone, but it would be less that the combination of the two.

...

More to follow

This is related to #20 and probably replaces it.

[joshmiller83]

David,

Just reading through github notices and saw this. I always wondered at the simplicity of zones. Watching this issue evolve. I'm happy to make diagrams if it helps articulate the complications.

Josh

[bojanz]

New title. I thought about having each resolver supply tags, but didn't like the UX / DX of it.
Ultimately, the taxable types need to be understood by the end-user. Our goal is to cover the most common ecommerce use cases, not support every tax edge case. So I propose a getTaxableType() method on the TaxableInterface and a TaxableType enum with the following options:

• Physical goods
• Digital goods
• Services
• Events
• Shipping
• Non-taxable

Each resolver can decide how to behave based on that. In some cases (Canada) they will treat all non-physical types the same, in some (EU) they'll have unique logic for each one.

That covers people selling t-shirts (physical), subscriptions and ebooks (digital), web development or hotel bookings (services), conference tickets (events).

[dwkitchen]

We can't get away from the concept of Place of Supply, this I think is more important that than Tax Type both the EU and Canada have this consept as the first step of working our which rate to charge.

This still doesn't cover some simple cases in the EU. In the UK a childs T-shirt is a different VAT rate to an adults T-shirt yet in France they are the same. An online video subscription and an ebook in the UK are the same VAT rate, but in France they are different.

If we use the fashion house ecommerce site we worked on on Drupal 7 as an example. The Place of Supply is dependent on the where the Company is registered for VAT in the EU and this depends on how much trade they do in each country.

In their case they were a UK business, also regisered in France, Spain and Italy becuase of the levels of exports to those countries.

If they shipped a childs t-shirt to the following countries its VAT rates would be:
UK: gb-zero, because the UK rate for child's clothes is 0%, note this 0% rate, not VAT expempt.
FR: fr-standard, because they are registered in France and the FR rate for child's clothes is 20%
DE: gb-zero, bacause they are not registered in Germany the rate for country where the item is shipped from, rather than shipped to is used.

I had a first go at creating this in #33

To make this simple for the majority use case we would supply some supported standard tax tags, which reference the Place of Supply Rules to use and the rate to charge in each country once the place has been resolved.

[bojanz]

I'm not saying we give up on the concept of place of supply, I agree that it's vital.
The taxable type is only used for that. Determining which rate to use is a separate process. And one where the library users are on their own, since we don't have the time resources to map various product categories to their non-standard rates. In Drupal that means having tax override config entities where you can say "this product/category/type uses this rate"