# New tax calculation method

Hello,

The following tax calculation method, suggested at [url]http://forum.cs-cart.com/vbugs.php?do=view&vbug_id=1532[/url], will be implemented in CS-Cart 2.1:

Example (the most complex situation, with several taxes)

``` ProductA (tax1: 10%) - \$100 x 2 ProductB (tax2: 5%) - \$50 x 3 ProductC (tax1 and tax2: 10% + 5%) - \$70 x 4 Order total = \$630 Order discount = \$60 Step 1: Calculate discounted subtotal 630 - 60 = 570 Step 2: Allocate discount by tax group subtotal 570 / 630 = 0.904762 tax1 subt: ((100 * 2) + (70 * 4)) * .904762 = 434.29 tax2 subt: ((50 * 3) + (70 * 4)) * .904762 = 389.05 Step 3: Calculate taxes tax1: 434.29 * .1 = 43.43 tax2: 389.05 * .05 = 19.45 Step 4: Calculate total (discounted subtotal + taxes) 570 + 43.43 + 19.45 = \$632.88 ```

As always, any additions are welcome.

[quote name=‘zeke’]Hello,

The following tax calculation method, suggested at [url]http://forum.cs-cart.com/vbugs.php?do=view&vbug_id=1532[/url], will be implemented in CS-Cart 2.1:

Example (the most complex situation, with several taxes)

``` ProductA (tax1: 10%) - \$100 x 2 ProductB (tax2: 5%) - \$50 x 3 ProductC (tax1 and tax2: 10% + 5%) - \$70 x 4 Order total = \$630 Order discount = \$60 Step 1: Calculate discounted subtotal 630 - 60 = 570 Step 2: Allocate discount by tax group subtotal 570 / 630 = 0.904762 tax1 subt: ((100 * 2) + (70 * 4)) * .904762 = 434.29 tax2 subt: ((50 * 3) + (70 * 4)) * .904762 = 389.05 Step 3: Calculate taxes tax1: 434.29 * .1 = 43.43 tax2: 389.05 * .05 = 19.45 Step 4: Calculate total (discounted subtotal + taxes) 570 + 43.43 + 19.45 = \$632.88 ```

As always, any additions are welcome.[/QUOTE]

We need a fix NOW. You should provide us with code fixes we can manually change.

And what makes this worse is that in v. 2 you don’t allow us to edit the sales tax field directly in the admin panel . . . so we can’t even go in and correct the orders that have been placed with the wrong sales tax. So you should also make this field editable so we can manually correct any wrong tax calculations (at least as a short term workaround).

That looks great. I could only suggest keeping the decimal at more than 2 places on tax1 and tax2 subt. Since the discount is converted so some percent, it could result in being off by \$0.01. Not much, but better safe than sorry. Perhaps the decimal should be kept at a ~4 places until the end.

Over here we integrate everything into a MS accounting system automatically, and it likes generating its own taxes and will throw an error is the total is off by a penny.

[quote name=‘phazei’]That looks great. I could only suggest keeping the decimal at more than 2 places on tax1 and tax2 subt. Since the discount is converted so some percent, it could result in being off by \$0.01. Not much, but better safe than sorry. Perhaps the decimal should be kept at a ~4 places until the end.

Over here we integrate everything into a MS accounting system automatically, and it likes generating its own taxes and will throw an error is the total is off by a penny.[/QUOTE]

Zeke,

I would like you to confirm the calculations when there is a discount on a product and/or a global cart discount.

Will it work the same way as your example for both kinds of discounts?

I am not clear on this.

And, the final calculations is where rounding should officially occur, You may want to round calculations for each product as a reference, but the final calculations for discounts/taxes should use the unrounded numbers.

Thanks,

Bob

[quote name=‘pbannette’]Zeke,

I would like you to confirm the calculations when there is a discount on a product and/or a global cart discount.

Will it work the same way as your example for both kinds of discounts?

[/QUOTE]

Yes, it’ll work for both kinds of discounts.

[quote name=‘pbannette’]

And, the final calculations is where rounding should officially occur, You may want to round calculations for each product as a reference, but the final calculations for discounts/taxes should use the unrounded numbers.

Thanks,

Bob

[/QUOTE]

Right, we’ll do it this way.

When 2.1 is planned to be released? This fix is of major importance to us.

Beta is expected at mid-May 2010.

Need clear separation between taxes applicable to an item or tax on the NET amount of the products. I.e. in the US (most regions) there is NO tax on food items and some other products (like vitamins, medicine, etc.), but there is tax on services and goods and may be location dependent.

Someone should be able to simply say “add 8.5% sales tax” to the sum of the products (after discounts) minus the NET of any products that have a tax-exempt flag set. Make it easy to identify tax-exampt items versus pushing a tax to all items and then having to go in and change the tax to zero for specific items.

I provided an algorighm in the bugs area that shows exactly the steps for how this would be done. Assigning a tax to a specific item should be the exception rather than the rule.

[quote name=‘tbirnseth’]Someone should be able to simply say “add 8.5% sales tax” to the sum of the products (after discounts) minus the NET of any products that have a tax-exempt flag set. Make it easy to identify tax-exampt items versus pushing a tax to all items and then having to go in and change the tax to zero for specific items.[/QUOTE]

Perhaps I am misunderstanding you but I don’t think it is quite as easy as this. Some states (I think Illinois, for instance) have different tax rates for different product classes in addition to a tax-exempt class. How would you handle this situation where where some products get TaxA and some others get TaxB and still others are exempt?

Bob

First I would support a “tax exempt” checkbox on the product details page.

Then, it’s fine to associate specific taxes with specific items. I have no issue with that whatsoever.

However, the most common case (in the US anyway) is to have a rate based on the net amount of non-exempt items based on location (down to zip code).

So it seems there should be a tax-exampt checkbox on the product details page and a “taxes” tab where someone can set a specific tax appropriate to that item. The ‘tax’ should be named and one should also have the ability to “apply” a tax to all items (or selected) from the Shipping/Taxes tab. Or to simply have tax calculated on the net amount of the order (before shipping).

Maybe another checkbox on the “taxes” tab of the item detail page that says “use specific taxes only” to prevent an “apply taxes to products” from affecting that product.

Also, one could add the concept of a “product class” and have taxes be applied based on the “class” of a product (medicine, hardware, service, whatever). But this is yet another level of abstraction that would probably cause more confusion than it’s worth.

Fortunately, CS-Cart handles most of this even if not so elegantly.

I guess there is some benefit to the tax-exempt checkbox (you could search on this) but more important might be the “use specific taxes only” to prevent other taxes being accidentally applied. Of course, currently, if you check no taxes on the product, it is treated as if it is tax-exempt and not included in any tax bucket.

Unfortunately, providing an international solution for taxes is a bit of a quagmire. I have been arguing that they should try to get this right now because jumping back into tax code is always a challenge. I am now firmly inline with a number of others: half a loaf is better than we have now. Even better, I think with the proposed changes we will be getting something close to 90% or more of that “loaf”.

Bob

Similar to the way shipping is handled… Allow the user to define their tax methods (tax tables in the old world). Let them define if there is a “class” of product that either gets specific taxes or is ignored by specific taxes. Allow them to decide “when” to apply taxes (before or after discounts).

If you have to, make it a config option to have a Euro, US, Russian, Austrailian or any other set of tax rules. When I worked in the auto industry taxes were the biggest mess to automate/quote. Customers would go to one state to buy a car but the dealership had to tax them as if they were in their own locale. There were separate tax tables for Insurance, tires, fuel-surcharge, luxury taxes, and on and on. It took a whole team of people just to keep up with it and figure out how to distribute it.

So the merchant in this case needs to have a way to manage a “tax table” and to associate products with specific taxes (or tax-exempt) based on the locale of the user and/or the locale of the merchant. For instance, in the LA area, you can have a different tax rate for district, city, county, state depending on the type of product or service… With the economic pressures currently happening to municipalities, the situation is only going to get worse, not better and the merchant is the final point of liability as far as the tacing regions are concerned.

So whatever they end up doing, they better get it right or merchants will toss their \$300 investment and move on to something that meets their needs. Right now, the standard taxation (and the addon fix) are so inaccurate for most US based merchants that they have no choice but to inflate their prices to compensate. They then become less competitive, etc…

I’ll rely on my algorighim in the bugs section. I think it addresses all the needs I’ve seen with the exception of apply taxes to a “class” of product.

It seems to me that the proposed change for calculating taxes should work for most people. The biggest problem with the current setup is that taxes are not calculated on the amount after an order discount is applied; the new method will deduct the order discount prior to calculating any taxes. It will also allocate any order discount among several tax classes which is what is required in some places that have multiple, overlapping taxes (like GST and PST in some Canadian provinces).

They should consider adding your suggestion to use tax classes and that you can specify for each tax class whether the discounted or non-disounted subtotal is used for calculation. I just came across a specific example where this would be required: in California, cell phones are always taxed at the non-discounted price. So a Califirnia-based electronics merchant would need to be able to specify different tax bases depending on the product class.

Perhaps they can work this in as part of this change.

Bob

[quote name=‘tbirnseth’]First I would support a “tax exempt” checkbox on the product details page.

[/QUOTE]

As with the free shipping, an icon could be associated with the selected tick box so customers could see which products are tax free on the product detail page.

How could the cart handle tax for products with options, for example some goods bought in small quantities are subject to tax, 2kg pack = 17.5%, but a 15kg pack of the same product = 0%.

Bob,

Taxes are extremely difficult and require constant and continous maintenance. Because of this, a “taxing system” must be flexible enough to do it all. It’s not a small task and could make the rest of the cart look small and simple in comparison.

Barry,

I’m not entirely sure… But think this would be addressed via the option itself. It should have the same taxing capability as the root product (exempt, tax1, tax2, etc.) Or possibly via the “option combination” capability…

[quote name=‘zeke’]Beta is expected at mid-May 2010.[/QUOTE]

Are we still good for ides of May? One week left…

A Beta? I have send you an request for the new version, you have answered me in may, but Zeke you havent write me that is a BETA. If it a beta, when i am not wrong we cant or shouldnt use it in a live shop???

We need a stable version…

[quote name=‘Triplex’]A Beta? I have send you an request for the new version, you have answered me in may, but Zeke you havent write me that is a BETA. If it a beta, when i am not wrong we cant or shouldnt use it in a live shop???

We need a stable version… :-)[/QUOTE]

A beta is the first step to a stable version. And I hope that they take the time needed to deliver a solid beta rather than try to meet some arbitrary mid-May date that bears no reflection to the readiness of the product. Of course, there will be others who want the new code ASAP and who will install it on a live site then come back here and scream bloody murder that things aren’t working properly - just as happened with the 2.0 release.

Bob