Sales tax rate determined by zip code?

Is there a way to calculate the sales tax by the ship to zip code?

Thanks

I'm not aware of a module built for this.
You might try retrofitting the ot_county module ... just search for ot_county here on the forum for several discussions on the topic.

DrByte:

I'm not aware of a module built for this.
You might try retrofitting the ot_county module ... just search for ot_county here on the forum for several discussions on the topic.

I did not find any references to ot_county here. I did find a local tax module in the archived downloads, ot_local_tax_v1.0.zip, that will probably help me accomplish what I'm trying to do. However, it is from 2004 and might need to be updated to work with the current version of Zen. Anything in particular I should look for?

Thanks for your help.

oops .... ot_county* (forgot the *)

I did a search on county too ... got some more results.

Sorry ... forgot that silly * ....

interaxxis:

Is there a way to calculate the sales tax by the ship to zip code?

I've actually been working on a module like this, based on ot_local_tax but improved a lot.

The state of Oklahoma requires collection of sales tax based on destination address. This is horrible and whoever in the state gov't approved this nonsense ought to be spanked hard, but we're stuck with it for now. The good news is, the state tax agency provides a data file containing (among other things) zip+4 info correlated with city, county, and state sales tax rates.

So I parsed this data file with a perl script to remove unnecessary stuff and loaded it into a mysql table. Then my modified module searches first for zip+4 in that table. If the +4 part is missing or there are no matches, then it looks for the highest tax rate in the zip without +4. Then it falls back on city name. (That's useful because Texas has the same goofy requirements and doesn't provide zip code tables. But Texas does provide city tables.)

Anyway, it's still at the debugging and testing stage so I'm not quite ready to share it yet. ZC's inability to do this by default (take the hint guys!) has held my e-commerce site back by several months because I don't want to get in trouble with the gov't. At least ZC is free and relatively easy to modify. :cool:

Can anyone tell me where to find the original ot_local_tax contribution? I have searched every way I know, and can't find it.

Thanks!

Hello I am new and am under the same problem set as all th others who have to abide by the Destination Sales Tax (very bad idea but). This means I have to charge my customer the sales tax in their county when I sell something to them and ship them goods. Then I must submit those taxes to the state at the end of the period. So...I am under the impression that I can do this with Zen Cart. Am I right? Or is it much more complex than that (as the poster Bouncey alluded to above).

I was trying to define county sales taxes in my admin config, then realized that it has to show up somehow when the customer checks out and I am not sure that it will.

Thanks for any help on this issue. It is going to become very popular very soon as lots of small businesses will be crushed under the burden of Destination Sales Tax. Bad business but it is the law for now.

It has been the law for decades in NY (from personal experience) and CA (from other testimony).
There is a way to do this (essentially removing the "state name" from the states list and inserting "state name - aa county", "state name - bb county", etc. so customers have to pick a county when giving their address, discussed in the New York Sales Tax thread.

gjh42:

so customers have to pick a county when giving their address

And that's a big problem on several levels. First, in my experience, about one time out of four people aren't really sure what counties they actually live and work in. Second, it's not just the county that has its own sales tax. So does each town and the state as a whole. They all add together.

Texas also has special purpose districts, such as for metro transit authorities, whose special tax area is mostly independent of any city and county jurisdictions. But unlike Oklahoma, at least Texas has a mandatory cap on how high they can add.

So if we want to let the customers pick out their city, county, state, and special purpose district from menus, that's fine. But it'll be an administrative nightmare. Judging by the steady stream of update postcards from the Oklahoma Tax Commission, many of the rates change every 3 months. And that assumes the buyer will cooperate.

The easiest way to approximate all of this is by ZIP or ZIP+4, if your state provides the necessary data files. I have an almost-working module to handle this. I've been too busy lately (between personal life, recovering from a recent hard drive crash, and actually trying to run a business) to finish it though.

Maybe I'll look at again soon. What's missing at this point mostly involves logging sales to another table with dates, jurisdiction codes, and amounts to simplify monthly reporting. That'll be fun.

Also I have to move all of my changes aside before every upgrade and then reapply them afterward. (What's the deal with having to do a full reinstall with every little point release?!?) Not having this feature officially included in Zen Cart has held back my online store by over a year now. And yes, I've looked into other carts. They tend to be just as bad about this.

Two other approaches have occurred to me. One is to just put a note on the cart to the effect that buyers in your state will be charged sales tax at their local rate, and then look it up by hand before processing the payment. This is simpler but it might not be compatible with all payment methods.

Another is to do as one of my in-laws suggested. His sales office is in Texas, the product is made in Florida, and they do business in several states. He just collects taxes at the state's lowest rate and then reports them at the highest rate. (Or at his relatively high local rate, I don't remember which.) Yeah, so every village isn't getting every penny for every sale way out in the sticks. But overall he pays more sales tax money than he collects. He told me that the state tax authorities have never complained. It's a darn tempting idea...

By the way, the New York Sales Tax thread (linked above) has some good insights. It's good to see that my uncle-in-law wasn't the first to have the collect-low-pay-high idea. But the prospect of being audited over this... shudder

Thinking out loud here: Oklahoma expects us to figure the tax rate as precisely as possible, and to report it with jurisdiction codes for every level of government. For this they provide a table of ZIP+4 codes with the relevant data. But they also have a provision for using only ZIP (without the +4) as a last resort.

If I change my module to use only ZIP, then a lot of the template mods and internal logic for dealing with the +4 part can just go away. The reporting would be simpler, too, because there would be no need for a separate reporting table. Also, table maintenance would be easier, and the buyer wouldn't have to know the +4 part offhand. (They almost never know it, and the US Postal Service refused my request to link into their online system to look it up automatically. Because database cleanup is adamantly not on their approved usage list. Bureaucratic bastids.)

Anyway, I'll have to dig into the code again...

This would be a wonderful thing to have, as more and more people find they need to deal with locality tax rates. I really hope NY gets on board with the database feed for rates like Kansas is reported to have... no word from them yet about that.

Thanks Bouncey and all. Alas and alack I have looked into most of the fixes you suggested and been rebuffed by the awful tax men over this point. At least in Ohio they are being superpricks about it all.

First, if you want to collect one tax rate (like collect the highest one that Ohio charges) for all Ohioans, and pay that to the state you can get busted for tax fraud. That is really the pits but it can't be gotten around. Too low and you are cheating the state. I guess you could risk it that Ohio won't pick you to go after but then again...

Second, yes people often don't know what county they live in. However, that is their problem you can't fix that. I doubt that the merchant would get nailed if some ditz didn't know what county they live in.

The zip code answer is perfect except that in Ohio the counties do not respect Zip Codes. You can have one zip code with 2 or even 3 counties in it. A nightmare.

Looking up the tax rate (or anything for that matter) and contacting them later or billing them later for it is a bad way to go. I have to do it in one transaction.

I am sorry to be so negative about all this. I have been looking into it and have not found the satisfactory answer to it among high priced shopping carts or low priced ones. Only one I know does ask you what county you live in and charge you accordingly, and that one won't tell me anything at all.

So far the best solution looks like wiping out Ohio and putting in Ohio-Hamilton County, Ohio-Warren County, etc. I don't like doing any of this, but I really don't want to get audited and I am sure you don't either.

If it's any comfort, my accountant is tearing his hair out over this. This has saved me from being interested in the high priced carts (among other things) but the vexing problem still remains. I am grateful for all your thoughts on this. Really.

fabienne:

At least in Ohio they are being superpricks about it all.
You are right about every detail, as far as I know (I've never done business in Ohio). Our tax laws are pretty much the same. The only difference here is, they gave us a theoretical way out.

Tthe Oklahoma tax people used geographic mapping services to figure out what jurisdictions are in each ZIP+4. In the few cases where that small +4 area overlapped two jurisdictions, they averaged the rates based on population. Or something. Anyway, if you're in Oklahoma and you can figure out the ZIP+4 for your customer's address, it'll all work out. Or if you can arrange to look it up manually before processing payment, there's a state web site for finding the rate by street address.

In the absolute LAST RESORT, so totally frighteningly last-resort that they hesitate to even mention it in a hushed whisper with dire "you better have already made an effort" overtones, we can use the plain 5 digit ZIP code. There's a special jurisdiction reporting code for each ZIP. The rate basically is the lowest one of all the rates in that ZIP code. But it's not encouraged.

In Texas, last time I checked, not only do the tax people say not to use ZIP codes, they also suggest not trusting the address either. Call the local city government on the phone, they say, and ask them about that destination address, just to be certain. Urk.

(And if you miss filing a quarterly sales tax report in Texas, even if it's all zeroes, they assume that you really meant to say that you owed $1,000 in taxes and they'll add a 10% penalty plus ongoing interest and send threatening letters in the mail. Then they'll grudgingly call off the dogs if you get on the phone and beg for mercy and promise to go submit those zeroes online immediately. As much as I love Texas and its residents, I might just avoid selling anything in that state for a while so I can let that permit lapse.)

(Okay, so at least Texas makes it easy to get tax permits for out-of-state companies who travel there occasionally to do business. Simple online form. Oklahoma requires a $500 bond for out-of-state companies plus extra up-front paperwork. That's more money than some of my small-biz crafter-type friends have in their bank account. But anyway.)

In theory the cart could have a tax calculation system that stores rates for each state, city, county, etc, then intelligently figures out (more or less) which rates will apply based on the given address and selected county. Except that won't work either! At least for the rural customers.

One of my uncles lives on a farm in an unincorporated part of Kingfisher County, OK. His mailing address is out of Dover, OK but he doesn't actually live in that town. So with a system based on address and county, he'll be charged Dover sales tax when really he shouldn't have to pay it. (Dover is so small that I'm not sure rural vs town can be distinguished by ZIP.)

But unincorporated areas are sparsely populated enough that it'd work okay for most customers. Maintaining the rate tables would be a full time job though. And as those Texas tax people implied, it might not even work in some dense urban areas.

In Oklahoma City, for example: Warr Acres is embedded in OKC and has a lower tax rate. Yet putting either city name on a letter to someone in Warr Acres will cause the letter to get to the right place. Sometimes they just give their address as OKC to avoid confusing people. So will the cart be smart enough to sort it out?

I suspect that a lot of this mess is an attempt to protect "local" businesses from those evil predatory online stores by subjecting everyone to the same rules. Except taking those rules literally means that a brick 'n mortar store only needs to handle one tax rate, while the rest of us have to juggle thousands.

Really, I think the best compromise would be to allow us to figure sales tax from the local rate of our actual physical location. But that's not how the law works. :frusty:

For what it's worth, PayPal assumes a single state tax rate. Google Checkout allows figuring taxes by zip code. But relying on Google's system means finding other methods for those who pay by other means.

I think at this point, any system that includes county and/or postal code will be an improvement over what we have now.

We have created a solution that integrates with ZenCart that allows storeowners to submit their order information for sales tax calculations on a zipcode-basis (both 5-digit zips and zip+4 zipcodes are supported).

If you'd like to know more you can contact me at the information provided below.

Regards,