Gnucash Business: Proposal: handling multiple tax accounts

[Conrad Canterford]

On Fri, 2002-06-14 at 00:25, Derek Atkins wrote:
> I'm working on handling multiple tax accounts for business items.
> My current plan is as follows:
> 1) Defining Tax Tables

Without thinking too hard about it, these look good.

> 2) Using Tax Tables
> The point of this multi-tier default system is to give as much
> flexibility as possible.  One can envision taxing different customers
> on different tables, and one can evision taxing different _items_ on
> different tables, too.  Similarly, a simple checkbox for taxability is
> a quick way to define an item as "non-taxable".

To do it properly, its a little more complicated than that. In
Australia, an extra option "Tax included" would also be appreciated, as
a large number of small businesses (and especially any retail business)
will advertise and invoice the *tax inclusive* price. Asking whoever is
doing the accounts to deduct the tax from every invoice as its entered
is not going to make you any friends...  :-)

> 3) Open Issues
> I still have a few open issues with this plan:
>   a) Where to store tax tables?

I think a global table would be preferable. If someone is running
multiple entities, this might save them re-entering a lot of data. If
they are not, well it makes no difference to them.

>   b) How do you reference tax tables for "posted" entries?
>      - Tax Tables are immutable.
>      - Tax Tables are mutable until they are "used" (at which point
>        they become immutable).

Personally, I'd go for this one.

>        I think this might be too confusing for a user.

Why? A simple dialog pops up saying "I'm sorry, but this entry is in use
by an invoice and cannot be changed.".

>      - Tax Tables are mutable, however when you post an invoice the
>        Tax Table code creates an internal, immutable copy that is
>        linked to the mutable tax table in question.

This is really just an enhanced version of (b) as far as I'm concerned.
Basically (if you think of it the other way around), when the user goes
to change a tax table entry that's been used, the system automatically
creates a new version of that entry and isolates the old one. This is
just as prone to confuse a user as (b). However, I think any of the
other options are also likely to confuse users, just in different ways.

Conrad.
-- 
Conrad Canterford  (conrad@mail.watersprite.com.au)
Water Sprite Pty Ltd   |  url - http://www.watersprite.com.au/
GPO Box 355,           |  - Australian Tour and Event Management (ATEM)
Canberra, ACT 2601     |  - Ticketing Division.
Mobile: +61 402 697054 |  - Catering Services Division.