sarahelsaig
commented
2 years ago Not a simple topic, let's dig in deeper.
Kinds of Taxes
I think there are only two kinds that come up for e-commerce: VAT or sales tax, and customs.
While there are many accounting and legal differences between VAT and sales tax, for the purpose of a sales platform like OCC they behave identically, as a percentage cost added to the line item. It's typically a single rate, but some product classes (e.g. essential food or hygiene goods) may have different rates. Though unless you are extremely sure, just use the full rate. In e-commerce the tax is paid according to the purchaser's country/state or origin.
(Customs depend on the source and destination countries too. Local orders, or orders within a customs-union (e.g. the Schengen Zone in Europe or MERCOSUR in South-America) suffer no customs and many countries waive customs on small value shipments. For the rest, it's incredibly complicated with individual line item classes, the total value, and possibly various treaties can affect the result. Luckily customs is the importer's responsibility. While bigger sites offer informative estimates, it's not a requirement.)
Generic Implementation
As a general solution I think we should have an event, something like PreparingCartForCheckout that gets the ShoppingCartItem collection and updates it. There the line items could be updated individually, in an extensible way. (The same event could be useful for shipping too to add a shipping cost entry.) When accessing the cart this even would be triggered before returning the items.
I'm unsure how we should express the tax on line items. Another question is if the prices should be net or gross. As I understand, in the USA it's typical to show net prices. This is also common in VAT-using countries for shops that primarily sell to other businesses (for VAT write-off reasons).
I think we have to bite the bullet and replace Money.Amount.Value with separate NetValue and GrossValue properties, to avoid potentially costly confusion. Then choosing which to display would be a matter of configuration. What do you think? Additionally we should have a string TaxName property, it would be important in the future if we need invoice integration.
Default VAT Implementation
This heavily depends on the above, but it should be flexible because these rates do change as legislation evolves (so don't use pre-calculated tax rate tables). As a start, we should add a feature that represents a local VAT implementation, with an admin menu where you can pick a single percentage. Then it would just apply it from the above mentioned event. This is enough if you only sell domestically. A different feature for or international orders, we might need to use a VAT API that gets the current and up-to-date numbers. I'm not aware of a reliable free API for that. If anyone has need or preference for this in the MVP, please speak up!
Nothing is Set in Stone
This is just my recommendation, please chime in if I missed something crucial. Please don't start working on the issue until we have heard some other voices on the topic.
Skrypt
UR-ScottShew
bleroy
Oh boy that's a tough one :D
Taxation is super-duper-complicated. It has lots of details, local subtleties, and unless you're selling very, very locally, you can't afford to ignore it.
In the MVP, we'll implement extensible infrastructure, enabling tax services to act on and modify an order. That's reasonably simple.
We'll also include a default implementation, that will also be fairly simple(istic), but will likely require more work for the shop administrator. It will likely involve a way to map customers to regions, and then regions to tax rates. Open questions include whether we should import data, under what format.
Jira issue