On Dec 5, 2007 9:48 AM, John Locke <
..hidden..> wrote:
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.
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).
Sorry, I meant address :-) However, as I think about it we probably will need to also list the customer as taxable or not. (As of 1.4, I think we will need a way of toggling this for an invoice because sometimes resellers purchase goods not-for-resale and then have to pay the sales tax).
>
>
> 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?
We were hoping to be past feature freeze by now. However things are running behind. We still need to address a few issues before we get there. I would say we should be in feature freeze within a month, maybe 2 on the outside. Then we need to test, get lots of bug reports, etc. My quick review of the changes suggests that migration to
1.3 is going to be the largest pain point. I suspect we will have fewer issues (and a shorter testing run) than with 1.2, but that migration will be more difficult and that we will expect a longer transition time. Within week, I would expect that a number of people (including myself) will be running LSMB
1.3 (from /trunk) in parallel with other systems.
>
>
> 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!\
The tax module was actually the most painful change in
1.2, but it will allow for this sort of handling. See LedgerSMB/Taxes.pm and LedgerSMB/Tax/*
The key is that, while different address formats may occur for different LSMB versions, the main tax calculation logic is likely to be pretty stable.