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

[John Locke <..hidden..>]

Chris Travers wrote:
>
>
> On Dec 3, 2007 11:21 PM, John Locke <..hidden..
> <mailto:..hidden..>> wrote:
>
>
>     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. 

Actually, I asked them about this specifically... the tax rates need to
be stored per address, not per customer. If somebody buys something who
lives in Camas, but has it shipped directly to their daughter in
Pullman, the Pullman tax rate applies. (If they ship out of state, they
don't have to pay sales tax at all, until the cross-state stuff happens,
unless the business has a location in the destination state).

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

I am carving out time on our development calendar for this, but was
hoping to build on top of 1.3. How close is that to getting stable?
>
>
>     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.
>
I look forward to checking this out!

Cheers,



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