Re: Looking at putting together an add-on for Washington State's sales tax

On Thu, Jan 9, 2014 at 10:50 AM, John Locke <..hidden..> wrote:

Hi, Chris,

The problem might be getting a bit more complicated than just Washington: http://www.marketplacefairness.org/what-is-the-marketplace-fairness-act/

... this act was approved by the Senate last spring, and is in committee in the House, expected to pass but there are other priorities ahead of it. Once it does, the quarter starting 6 months after passing will be when it goes into effect.

Trying hard to avoid making sarcastic comments.....

After reading the act, trying hard to avoid making even more sarcastic comments. It is not limited to streamlined sales tax states. There is an alternate process where states can qualify to demand remote seller payment which does not require accepting the SSUTA product definitions, so a state could declare kitkats to be taxed as candy (not possible under SSUTA) and still demand remote payment.

https://taxcloud.net/default.aspx

is a free web service sponsored by the participating states to handle determining what is taxable and at what rate, based on the destination address.

Providing a tax module that talks to this service, and setting up parts so that they can be tagged with the appropriate code, might be a big win for the project if this legislation passes.

For #1, to me this is the main difference between a Point-of-sale and a shipping system. I would say something along the following lines, in sequence (first match wins):

For point of sale you don't want to depend on a web service. Just use the old method. Requiring network access to a resource you don't control in an environment where you need to move people through the line fast is a recipe for trouble (do you want your cash register to be effectively down because your internet connection is slow or down). A shipping system really needs to be separate if it is going to depend on such a web service.

* Transaction done using POS: use store address
* Use ship-to address if exists
* Use billing address if exists
* Use store address

... perhaps we have a "Ship-to" that can be the store address?

... as I look at the sales invoice, I'm not seeing an option to select a shipping address. Shouldn't it be possible to have multiple shipping addresses associated with a customer?

Click "ship to" and select or enter a new one. Adding a dropdown would not be hard. Basically it would replace a hidden field with a dropdown.

Then we could populate a drop-down, one of the addresses can be set as default, and the store can be an option.

#2, not sure what you're asking, what's wrong with the current display? I think the main thing is we need the rate, the basis, the location code, and probably the taxing authority. I don't know that there can be different rates within the same order (same destination) -- as far as I'm aware, there are not different rates for different kinds of products -- but if there are it might be necessary to have multiple tax lines. One consideration is whether shipping/handling is taxable or not...

Hmmm Reading SSUTA it looks like at least two rates are allowed for each jurisdiction (food/drugs and everything else). But there are also lots of other unknowns. For example, states may define what constitutes taxable shipping and handling, or whether clothing is taxable based on how much it costs (a state-set threshold), or whether insulin is taxed under food and drugs or prescriptions (even if it requires a prescription). So one huge issue is that there are products which may clearly cross categories when crossing states. I don't know how to handle that. But that's just my cursory reading through the 200 pages of regulation.

The rounding rules, we can handle. It looks like we can round the tax per item or per invoice. I would recommend per item.

But that affects the display too.

Best Wishes,

Chris Travers

Cheers,
John Locke

On 01/09/2014 02:55 AM, Chris Travers wrote:
Hi everyone;

I know we still have some users in Washington State. I would like to modularize this so that other location-based tax systems could work as well. My thinking is to put together a class which handles locations (and delivery vs non-delivery handling) and then inherit from that something that would look up the tax code and rate for a jurisdiction.

This leads to a couple of important questions:

1. How do we want to address delivered vs nondelivered? A default in defaults? Just use the presence of a ship-to address (my preference)?

2. How do we want to handle display?

--

Best Wishes,
Chris Travers

Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in.

http://www.efficito.com/learn_more.shtml

!DSPAM:52ce801f35501629111686!
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk

!DSPAM:52ce801f35501629111686!
_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel


!DSPAM:52ce801f35501629111686!
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Best Wishes,

Chris Travers

Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in.

http://www.efficito.com/learn_more.shtml