tax in Cartridge

[Josh Cartmell]

I haven't had to deal with this before but I was wondering what is the
recommend way to deal with sales tax in Cartridge?

In the integration section of the docs http://cartridge.jupo.org/integration.html?highlight=tax#payment
it says that the payment handler has access to the order object which
includes a field for the tax amount. Looking at the model this isn't
the case.

Am I missing something? Does anyone have recommendations about how to
handle this?

[Stephen McDonald]

No you're right, the docs imply there's a field and there isn't.

Just for some context, in my country (Australia) the tax is generally included in the total amount, so the most we ever need to do is display how much of the amount is tax, without any need to store it officially or use it as part of a calculation for anything. So that at least explains the current state of it.

I think tax calculation is so varied dependant on where you are in the world. Given that, the one thing I'd like to avoid if possible is creating a structured framework that tries to cater for every scenario possible, instead opting for something open ended that lets the developer implement their precise needs. 

This is what I've tried to do with shipping - there's simply an amount on the order model, and a hook for setting it once we have an address for the shopper.

Would it suffice to simply have a tax amount field on the order model, as the docs currently imply, and leave it at that for a first step at least? We could also provide a bool setting that indicates whether tax is included in the product prices or not - this would allow us to correctly display the order totals by either adding or subtracting the tax amount to/from the order total.

--
Stephen McDonald
http://jupo.org

[Josh Cartmell]

In the US sales tax is a bit of a beast.  Tax rates can differ by county (which there are over 3000 of), but you only have to collect sales tax if it is being shipping within the same state (and I believe you collect tax at the rate of the county you are shipping from).  You also only have to collect sales tax on physical goods (so downloadable products wouldn't have to be taxed).

I think a good first step would be to include a tax amount in the order model and make the bool (as you described).  I also think it would be useful to add a bool to products that would mark them as taxable or not (if the tax included in price bool was set this could be hidden and ignored).  Another thing to add might be a setting that would be a tax rate although that may be getting to specific to the US situation.

For my use case and probably others it would also be nice to be able to show the amount of tax on the cart page so I think it would be useful to add functions to the cart called total_pretax and total_tax which would give the total cost without tax and then the total amount of tax respectively.

I would be curious to hear other people use cases and the way they would need it to work in their country so that it could be made generic enough to fit all use cases.

[Jason K]

I'm building a store targeted to Canadian and US customers. Tax here works somewhat like the US but in Canada rates vary province to province instead of by county.  There are also special cases where goods don't get taxed, or only get taxed a portion of the full tax amount. Basically our taxes have a Federal portion and Provincial portion, and some goods such as cheap food items and books only get taxed the provincial amount. There are also goods to which this only applies in specific provinces.

I think what we need is not just a bool on the product for whether tax is charged or not, but perhaps a relation to some sort of "tax model" class which can have different instances for different classes of goods. You could also choose to just leave it null or something to specify no tax. Each tax model class would then have its own logic for how much tax is charged given the location of the buyer.

[Joe Julian]

I don't actually use cartridge, but as long as you're on the subject of taxes, here in Washington state, sales tax is to be calculated based on the address the item is being shipped to, so there can be literally hundreds of tax rates that could be applied. My understanding is that this fairly new tax rule is part of a multi-state sales-tax reform process, so I don't think we're alone in this. Whatever solution you work toward, you might want to include this tax structure in your thought process.

[Stephen McDonald]

Thanks Jason that's really useful to know.

So that idea heads down the path of what I want to try and avoid - having models and a defined structure around how tax gets implemented. I think it'll end up more than trivial if we try and cater for for every scenario possible. 

The original intent behind Cartridge when it started years ago was to only implement the things that most people would always use, and provide the hooks for developers to implement the extra customization they need per project on their own, staying as lightweight as possible along the way, so that it's overall design allowed developers to easily get their head around it in order to give extra customization as short a learning curve as possible.. That's always going to be an unqualified statement, but it's the general goal nonetheless. It was in reaction to Satchmo which has all these "mini-frameworks" around product types, shipping, payment and tax - a lot of which many people won't ever need.

I'm not by any means saying that having tax models and so forth wouldn't be the right solution to the scenario you described, I'm just saying that you should be able to implement tose yourself, and those who don't need it don't have to worry about unused infrastructure being there. Hopefully with the discussion in another thread going on around making the product models more customizable, we'll soon be at a point where this is a lot easier to do. Perhaps after that some common setups for tax could sit outside of Cartridge in separate apps.