Introduction
Currently there is no handling for taxes. Some users are starting to need this, and it is a complex set of functionalities. This page is notes for refining requirements. We sprinted on this during the NOLA Symposium June 6, 2008 and created a branch called "tax" for the work.
Background and Issues
Tax rules (examples of the complexity in various use cases):
- in US, customer pays tax if in same state as a brick-n-mortar store
- in UK, different levels of VAT based on type of good
- in Brazil, 5 different taxes
- in US, some states tax shipping, some don't
- in Indiana, zip code crosses 3 counties, which provides
- in NYC, city sales tax applies based on price (below certain price, no tax)
Requirements
Basic use case
The system manages taxes (rates and rules) on items and/or on shipping. Use case includes:
- Developer sets up different rules of taxation (eggs).
- Site admin can enable taxes on the store
- Once taxes enabled on the store admin, can enter in the name and rate for each tax applied for a store, and can designate whether the tax is the default rate and if it applies to shipping costs.
- For each buyable item, admin picks which tax rate/category applies. If no tax is chosen, then the default tax is applied.
- Taxes calculated during checkout and recorded on the order (and in total), if they apply to the purchased items.
Future enhancements: Admin has tax table and counties/zips in csv and can upload to the site.
To use taxes, the site admin would have to install the egg(s) for that applies appropriate tax rates (ie the getpaid.tax.usa egg). The product should ship a simple tax module (handles a flat rate for a tax that can be given a name) with GetPaid, but this would be easy to overwrite for custom needs.
Design criteria
- Make it pluggable so other countries/states/regions can make own tax rules
- Supports multiple taxes to be paid (example: federal, state, municipal)
- The content/cart objects know what rules apply to them
Implementation details
- Use the existing tax utility (admin screen): make it have a list of taxes (admin can add tax name and rate). Set of rules are coded in by developer. Each tax has optional "applies to shipping" and "default tax rate" check boxes.
- add iTax interface:
- 3 methods (one for item, one for shipping, one for total order), has to be callable;
- Register named utilities for it (ex "VAT"): objects inside utility for rules, like 3 levels of VAT; Another scenario was suggested here by ChrisW (plz verify details!): getName method on iTax (key in dictionary) would allow the 3 levels of VAT to be 3 separate utilities, though would be able to sum to common "VAT" line item on cart total.
- Future: add convenience utilities to upload csv file
- iTaxUtility:
- has one method getTax returns a dictionary of tax amount and tax id name
- iTaxUtility has control over part of payable tab to be able to insert rendered information for admin to set on content. Admin get a list of taxes (multiselect list) on the payable form. Needs to be coded based on the tax utility you have.
Issues and Questions
- What about auditing or reporting? Make sure that possible to get out / export of tax info for accountant.
Reference
An example is the Yahoo! store tax handling.
Yahoo! Merchant Solutions Tax Wizard
Select "do not collect tax" if you determine that you do not need to collect tax from buyers. Consult the tax agency for your state (or any state where you may be deemed to have a presence) or a tax accountant to determine if you must collect sales tax.
Select "collect tax at checkout" to set up and collect tax as buyers complete the checkout process. You can select states in which to charge tax and specify a rate. You can also set up additional rates by zip code to cover special city or county tax rates.
Select "collect tax after checkout" if you wish to determine the correct tax rate while processing each order. The key benefits to this method are you do not need to set up applicable tax rates for cities and counties before opening for business, and can determine the correct tax charges for each order as they are processed. Note: Buyers may cancel an order (or worse initiate a chargeback), if their card is charged for a higher amount than displayed at checkout.
Here is the test page for the tax calculation from Yahoo!: 
Appending for info at request of Adam:
"anonymous" IRC Excerpt (2008-08-22): A: ...yeah, which is why I was having strong opinions about taxes, and why it needs to be done via rules, but one step at a time.
B: I remember talking some about it a while back but have no idea what you ended up doing.
A: This is a simple taxation product: it looks at the customer's state and the shop's state and taxes accordingly based on a rate in the config. Right now, the config is in python. I will make a screen for it next week, perhaps, but we really need much more flexbility.
B: Well, that's all you need for a simple commerce product.
A: And a lot of people are tax exempt...Yeah, this is good enough for now.
B: Other than being more flexible, exemption- and configuration-wise, what more depth of taxation support do you think should be supported? Also, I guess it's important to mark charges that are for services.
A: For example, lets say you have 3 distribution centers: one in MS, one in TN, and one in WA.
B: I am pretty familiar with the interstate exemptions with regards to shipping destination. I sold custom-built PCs on ebay when i was in high school ;d
A: Some of your customers are buying direct for them, and some are buying for resale.
B: Ah, resale, too; they have their own tax permit. It would be awesome if we could cover those cases. I am so in to help you; I know a lot about that stuff (I got my first sales tax permit at 14).
A: So, even if your corporate office is in MS by the river, if someone from WA orders your products you need to collect tax on it.
B: Ah, so complex details per state.
A: If you have a distribution point who is also tax exempt (and there are limits: some customers are tax exempt up to 20k per quarters)...and then, where it REALLY comes in to play: let's say you are a rental company like QPL. They rent workzone safety gear--hard hats, slow down and detour signs, speed limit signs, road cones, etc. There is rental tax paid, but after so much use the items go up for resale. However, they deprecate based on taxation rules set forth by the IRS. You can download those, and should be able to import them into "getpaid.taxation" or something so when you rent something 9 times over 8 months then sell it, you aren't paying the 9 percent tax (and only the 3.4 percent tax).
B: If you're going to handle all this, why not just design an accounting package which can integrate with getpaid and make sure it can have lightweight integration roughly equivalent to the simpletaxation stuff in place?
A: Because if you deal with all that, you might as well just be doing corporate accounting. Hrmm yeah, we want to do that.
B: We sure do.
A: I also want to find a customer to pay for it. B: We will. Well, grow the simpletaxation stuff, use it as a place to learn more about how to make things flexible.
A: There is no reason this stuff shouldn't be able to handle running a real business.
B: Come up with a couple of user stories we can attack before dealing with all this "border with washington" crap. ;d
A: I was going to use rules to handle the deprecation taxes...and location checking against something like simple taxation on a data grid field or something so people can fill out their own tax information...and just put some templates for gs or something and document it. Unless someone pays for it.
B: But I think you have all these ideas. We might as well start scratching out stub code in some eggs. It would put you in a better position to tell a client what they will be paying for. And again: you can have QPL pay for some, and then whoever needs each rule.
A: Right.
B: I'd just like to have something that can handle sending out service invoices and helping us to balance out the server costs, phones, dsl, and let us know the pessimistic estimate of corporate taxes due. Anyway,we should take this offline, it's slightly out the scope of getpaid, but should totally tie in.