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 ------------------------------------------------------------------------- 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
