On Dec 3, 2007 11:21 PM, John Locke <[EMAIL PROTECTED]> 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
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Ledger-smb-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
