Gnucash Business: Proposal: handling multiple tax accounts
Thu, 13 Jun 2002 19:35:41 -0700
If my read of it is correct, the customer already paid sales tax.
Therefore, you would use the formula...
Price = Total / ( 1 + STAP )
as below. You'd work backwards. If you don't, you wind up paying more tax
as a merchant while your customer gets a free discount. :/
WebEx Communications, Inc. accepts no liability in relation to any personal
emails, or any content of any email that does not relate directly to the
business of WebEx Communications, Inc.
From: Derek Atkins [mailto:warlord@MIT.EDU]
Sent: Thursday, June 13, 2002 7:02 PM
To: Kevin Benton
Cc: Conrad Canterford; firstname.lastname@example.org
Subject: Re: Gnucash Business: Proposal: handling multiple tax accounts
Thanks, but this wasn't quite what I was asking. I was asking a
procedural question, not a mathematical question. I was asking how
the process works for determining prices; do you start with the final
price and work backwards, or do you work forwards? Following that,
does it imply that the "TaxIncluded" flag means work backwards, too?
That would mean that you enter the final price and the tax is computed
backwards from that? It also doesn't answer the "where do you set the
TaxIncluded flag" question....
But thanks for making the math simple for others on the list ;)
Kevin Benton <KevinB@webex.com> writes:
> Anyone who operates a vending machine business has this problem. A little
> algebra helps on this one.
> Total is the total advertised price (including tax)
> Price is the actual price without sales tax.
> For this equation, STAP is the Sales Tax Aggregate Percentage including
> Total = Price * (1 + STAP)
> Since the total and tax rates are known, we need to get price by itself.
> First, let's get Price on the left like we're used to...
> Price * (1 + STAP) = Total
> Then, what we do to the left side, we must do to the right.
> Price * (1 + STAP) / (1 + STAP) = Total / (1 + STAP)
> Price = Total / (1 + STAP)
> Try it for yourself - plug in the numbers off a receipt you've been given
> and see if it works both ways.
> $1.00 item taxed at 5% requires a payment of $1.05.
> Price = $1.05 / (1 + 0.05) = $1.00
> Imagine that... :) Now you know how to compute sales tax backwards and
> forwards. :)
> Kevin Benton
> WebEx Communications, Inc. accepts no liability in relation to any
> emails, or any content of any email that does not relate directly to the
> business of WebEx Communications, Inc.
> -----Original Message-----
> From: Derek Atkins [mailto:warlord@MIT.EDU]
> Sent: Thursday, June 13, 2002 5:59 PM
> To: Conrad Canterford
> Cc: email@example.com
> Subject: Re: Gnucash Business: Proposal: handling multiple tax accounts
> Conrad Canterford <firstname.lastname@example.org> writes:
> > 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... :-)
> Where should this "tax included" option be stored? Since prices
> are advertized with-tax, how is the tax calculation made?
> > 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.
> What do you mean, "global table"?
> > > 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.
> The reason I prefer this last appoach is that:
> 1) to the user, the tax table is always mutable. They can change it
> at will, but
> 2) any posted invoices will refer back to the tax table that existed
> when it was posted, and
> 3) all the magic happens under the covers, as far as the user is
> concerned, and
> 4) it will save space by reusing tax-tables as much as possible.
> Thanks for your feedback.
> Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> Member, MIT Student Information Processing Board (SIPB)
> URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
> warlord@MIT.EDU PGP key available
> gnucash-devel mailing list
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available