Discussion of various tax-handling methods

[lat9]

Various reports of issues for Zen Cart's handling of an order's tax have been reported over the years (see this thread for one example). Let's use this current thread as a means of gathering the processing required for various taxing situations in an effort to define the requirements so that we can generate a plan for corrective action.

[torvista]

Here is a good chunk of country-specific information from the Dolibarr wiki:
https://wiki.dolibarr.org/index.php/...rounding_rules

It may well cover all eventualities...people should have a look at it and comment if their own situation requires something more.

[lat9]

Nice link, @torvista! I'll be reviewing that over the next couple of days.

[lat9]

Nice link, @torvista! I'll be reviewing that over the next couple of days.

... or months.

I've come to the conclusion over the past (almost year, now) that the underlying issue's complexity is that there's no centralized point within Zen Cart to provide the region-dependent tax calculations. The storefront calculations are spread among the shopping_cart and orders classes as well as embedded in the shopping_cart page's header. On the admin side, those calculations are spread across the orders.php page as well as various product-types collect-info pages.

Tax calculations (as mentioned before by @balihr, but I can't locate that posting) are different for stores that display prices with tax and those that don't, as is the point in the calculations at which an amount should be rounded.

I'm thinking that the storefront should have a defined tax.php class and that the ot_tax.php module should be the centralized point in the order's tax calculations, gathering information collected by the tax.php class and then calculating the order's tax. That class could, for instance, determine on load whether the store is displaying prices with or without taxes and load a calculation module (which could be overridden by a specific store's one-off requirements) that "knows" how to do those calculations.

[torvista]

Maybe you should start a Kickstarter for "Fix ZC Rounding Errors", I imagine there is a lot of people who would pay to see that fixed for once, me included!

[carlwhat]

i am a big fan of tax being done in 1 place, ie ot_tax. people can replace their ot_tax class to calculate tax the way they want....

i suppose my biggest question would be how many store fronts display prices including tax? i have a feeling it is done more in europe (and other places) than in the US. as i can not think of any place in the US where prices are displayed with tax. it's always after subtotalling.

but all of these tax functions should be within the ot_tax module, IMO.

rounding errors are a completely different issue. prices and subtotals displayed on the screen should always add up to the next total. easier said than done.

[balihr]

Tax calculations (as mentioned before by @balihr, but I can't locate that posting) are different for stores that display prices with tax and those that don't, as is the point in the calculations at which an amount should be rounded.

I described it here with a solution I've used and still use with sites I build (except for US).

But yeah, I couldn't agree more - one centralized place to do all tax calculations would be GREAT.

[lat9]

I described it here with a solution I've used and still use with sites I build (except for US).

But yeah, I couldn't agree more - one centralized place to do all tax calculations would be GREAT.

Thanks for 'jogging my memory', @balihr! Pulling together these various tax-calculation postings into one thread should be a big help.