On Dec 5, 2007 9:48 AM, John Locke <[EMAIL PROTECTED]> wrote:

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

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.


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

Reply via email to