Re: Towards ship-to-based sales-tax support

[John Locke <..hidden..>]

Hi, Chris,

Mark has this right, at least for Washington. Some zip codes span
multiple tax locations. We have a client who has first hand knowledge of
this, with her home shop having one tax rate, and her store down the
road in the incorporated town having a different tax rate, both with the
same zip code.

I spoke with some people from the state Department of Revenue about
this, and they said a zip+4 was feasible to do the lookup, or a street
address. Not a zip code alone, however. And they're happy to send along
their spreadsheet with some 800,000 rows for doing Washington street
address lookups for the tax location code...

There is some hope the state will provide an address lookup web service
we can plug into. If not, we're planning to do one for Washington, at
least for our customers (and we're happy to share what we come up
with--the only reason we'd restrict it is bandwidth/cost of our servers).

Regarding how to treat this in LSMB, what counts is delivery address. I
haven't looked closely at the work you're doing on the current release,
but we're treating the July 1 effective date as a deadline for this, and
figured we'd start working on it in February (give the state a chance to
develop a web service first...).

I was thinking we would add a tax location code to wherever the
addresses are stored, and add a button to wherever there's an
opportunity to enter an address. The button would call some web service
with the address, and return a location code and tax rate. This would
then get added to the tax system, where the invoicing/ordering/etc
should pick it up. We would probably hide the current tax lines on the
customer screen.

The other side is reporting--as I understand it, businesses will have to
report all tax collected for each location code in their reporting
period. We'll want to create a report for total sales and tax collected
for each location.

As long as we're only collecting for a single entity (state), this seems
to be fairly straightforward to bolt on. We were thinking of an advanced
tax module that would have it's own database table of location codes/tax
rates, populated as addresses were looked up in the web service.

It would be convenient if the core transaction engine was aware of these
tax location codes, however... It seems to me there are far too many to
litter up the COA, so we need some other table to contain them, and
there will need to be a fair amount of logic built-in--such as when tax
rates for a state might change (in Washington, it can change quarterly).

Cheers,

-- 
John Locke
"Open Source Solutions for Small Business Problems"
published by Charles River Media, June 2004
http://www.freelock.com