On Dec 3, 2007 11:21 PM, John Locke <
..hidden..> wrote:
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...
I wonder what format that is in (Excel doesn't handle 800k rows). I will have to contact them as well. Since SSTP is something a lot of states are trying to implement in order to push for large businesses with no locations in their state to "voluntarily" collect taxes for them, I would expect it ought to be a standard tax module in LSMB. (This is "voluntary" in the same sense that SSTI is "streamlined.")
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).
Understood.
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...).
LSMB's delivery address system needs to be reworked a little in that we haven't dropped the shipto table yet. However, the loopup should be simple. We can provide a city, state, zipcode, and address.
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.
Somehow we need to calculate the tax jurisdiction o the address. Since in 1.3, customers can have multiple addresses, the tax rates need to be stored per customer.
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.
Right.
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.
SSTP is supposed to be a unified system. Once we get it done for Washington, there is no reason it couldn't be improved and extended to support other states. I was thinking that having a single sstp tax module might be a good idea.
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).
The tax engine is now completely separate and can do whatever it needs to. The tax module is now completely aware of the invoice structure and modules can do whatever processing they need to do.
Best Wishes,
Chris Travers