Taxes

[michaelbromley]

Most countries have some kind of sales tax applied to goods being purchased.

In the UK for example, the current VAT rates are zero (0%), reduced (5%) and standard (20%). Here are rates in other EU countries

A tax is modeled as a type of Adjustment (#29) (AdjustmentType.TAX) and should be applied before any other adjustments, since other adjustment conditions would typically query the tax-inclusive prices.

Design

1. The ProductVariant entity should have a taxCategory property which points to a tax AdjustmentSource.
2. The price property should be tax-inclusive. There should be a new property, priceBeforeTax which contains the price before taxes are applied.

[michaelbromley]

Note: It might make more sense to calculate the tax-inclusive price once at write-time rather than dynamically at read-time for perf reasons.

Whenever the price or taxCategory of a ProductVariant is changed, the tax-inclusive prices are calculated and saved to the DB.

[michaelbromley]

After playing around with the initial implementation, it looks like it will not be flexible enough to account for differing tax zones.

I'll now have to look into a zone system (see https://docs.sylius.com/en/1.2/book/customers/addresses/zones.html) which can then be used for configuring both tax adjustments and shipping adjustments.

For an example of how complex tax rules can get (and the need for user-defined zones), check out this example from the Shopify docs:

Shopify has built-in tax overrides for clothing products for the states of New York, Massachusetts, and Rhode Island. The following state tax exemptions for clothing products apply:

New York: Clothing products, footwear products, and items used to repair clothing products with an individual price under $110 are exempt from state sales tax. For example, two items with a combined price of $200 will each be exempt from sales tax, but one item with an individual price of $110 will be subject to sales tax.
Massachusetts: Clothing products with a price under $175 are exempt from state sales tax, and clothing products with a price of over $175 will collect tax only on the amount that their price is over $175. For example, an item of clothing with a price of $200 will be taxed on $25 because the first $175 is not taxable.
Rhode Island: Clothing and footwear products with an individual price of $250 or less are exempt from state sales tax, and only the incremental amount above $250 is subject to sales tax. For example, if a suit costs $275, then the tax applies only to $25.
source

[michaelbromley]

Customer Tax Category

Researching this a bit further, and there is more complexity we need to support: different types of customer might be liable to different rates of tax. For example, a business customer in another EU country would be charged 0% VAT whereas a consumer would be charged regular VAT.

The use-cases are well described in this Sylius issue: Sylius/Sylius#8047

Therefore the current naive implemetation will need a complete redesign to account for:

1. Destination (country / zone)
2. Customer group (needs to be implemented)
3. Tax category of the ProductVariant

[michaelbromley]

Another case study for various taxes to be considered by a UK business: reactioncommerce/reaction#972 (comment)

[michaelbromley]

The above merge implements a workable taxation system implementing the requirements above.

Net vs Gross prices problem

There remains one major deficiency though: currently all ProductVariant prices are considered net (before tax) values. Taxes are then calculated based on the applicable rate. This is simple and flexible, but in the real world this is not always desirable. Consider:

A UK-based shop sells rocks primarily to the UK market. They wish to sell Rock A at a (gross) price of 99p. With standard UK VAT at 20%, there is no way to achieve this:

Net price (pence)	Tax calculation	Rounded gross price
82	82 * 1.2 = 98.4	98
83	83 * 1.2 = 99.9	100

Thus the closest possible gross prices are either £0.98 or £1.00.

For some companies, this will be a deal-breaker because they may want to set gross prices based on marketing or other factors, and be able to offer those exact gross prices to customers.

Solutions

I can see 2 possible solutions to this problem:

1. Allow fractions of a penny in the net price field
   ✅ The current tax calculation method can remain unchanged.
   👎 Will cause issues when applying a tax rate of 0% - we cannot charge a customer a fraction of a penny.
   👎 Negates the benefits of working only with integers at the API level (avoidance of floating-point maths issues)
   👎 Will complicate the ProductVariant API - we'll need to specify which price (net or gross) is the "true" price and add additional logic at the service layer to derive the other value.
2. Allow prices to be set as gross, and alter the way taxes are calculated in this case.
   ✅ Aligns with how many (especially smaller or largely domestic) businesses think.
   ✅ We can keep using integers everywhere.
   👎 The calculation of taxes to non-default zones will get more complex - we'll need to remove the default zone tax and apply the new tax on top.
   👎 We'll have to store somewhere whether prices are net or gross and refer to this when doing totals calculations.

I think the second option is the better one here. The next question is then: where to store the fact that the prices include tax?

1. In the TaxRate. This is the way Sylius does it. They have a flag on the TaxRate which says whether the prices are net or gross. I think this will lead to problems when shipping to non-default zones, e.g. if we have all prices inclusive of UK VAT @ 20%, and ship to Australia we want to charge zero VAT. We'd then need to know the rate of tax which is included in the price so that we can remove it, but at this point we have lost the information that the prices include VAT. See Sylius/Sylius#1568 for this issue playing out in the Sylius system.
2. In the Channel. If we have the flag in the channel, we can get around the above problem. We see that the zone is "Rest of World", and we know that this is not the default Zone. We then check if the "prices include tax" flag is true. If so, we get the default Zone's tax rate and can remove it. This also implies other channels can have different pricing policies, which should be fine since the price amount is stored on a per-channel basis.