Use case: rebates

[Mark G. Woodruff]

--- Neil Williams <linux at codehelp.co.uk> wrote:
> | * the sales tax paid on it as both part of its
> cost
> | basis and as something I can get a report on at
> the
> | end of the year
> 
> capital cost to Assets and the tax to an Expense -

Sales tax isn't an expense, it's part of the cost
basis, governed by a tax policy.

I suggest a better way to handle it is to have a flag
indicating whether an item is taxable or not, and then
allow the user to enter their local sales tax terms.
If an item is taxable, and the local tax is 5%, then
any call to obtain an items cost would be mutiplied by
1.05.

> 
> | * the terms of the purchase, when the payment will
> be
> | due on my credit card
> 
> That is best done in the reconcile dialog. 

That's after the fact.

Terms of credit are established before, or during a
purchase. That is, if I create a Credit Card account,
I should be able to enter the terms, e.g.:

12% annual, payments due the first business of the
month, new purchases included in the interest
calculations, cash advances charged 24% annual, etc. 

I'd like to know today if I would be better off buying
this on Credit Card V or Credit Card M. Would I save
money by buying it on Card V, even though it has a
higher base interest rate, because I'll be able to pay
off Card M, which has a cash advance still sitting on
it?

Credit terms are fairly standardized now. Requires a
lot of user entry, but only one time. Each time they
change their terms. :-)

> | * the terms of the rebate
> 
> A scheduled transaction? 

Nope. An Account Receivable. It goes on the book as
having value.

Accounts Payable (Credit Cards, Notes) and Accounts
Receivable all have terms. If I buy something on 2/10,
net 30 (2% discount if paid within 10 days, net if
paid in 30, 18% annual after that) I need to know
that. I also need to know if I'm better off paying
early and getting the discount, or paying another
account (Card V) and avoiding it's interest
completely.

> | There seems to be a fundamental difference between
> | tasks that real people do that need to be modeled
> in
> | an accounting program (buying a product at Best
> Buy or
> | Circuit City), and how it's handled in an
> accounting
> | program. So far, GnuCash is very model-centric.
> 
> And that is a GOOD THING. It's always good to follow
> 'best practice'!

Doing the one part of a best practice isn't the same
as doing the whole.

For example,

GnuCash's Balance Sheets are totally fubar'd. For a
balance sheet (and double entry accounting) to be
meaningful, everything must follow the cost principle.
 If I buy two things today for $1, and sell one
tomorrow for $0.50, my one thing remaining should
still be on the books at $1. Market value does not
belong on a balance sheet (unless an asset is
impaired, of course)!

> If you approach your accounts as an accountant would
> do, you will find GnuCash does
> precisely what your accountant would expect. 

GnuCash does some things an accountant would expect,
and some that are totally wrong. Making the former
easier to use is helpful; defending the latter is not.

> Not true. Quicken sacrifices 'best practice' on the
> altar of convenience
> and you've only just moved from that program, so
> it's hardly a model for
> GnuCash!

Didn't suggest it was. Quicken was and is a mess. Yet,
usability is of essential value. A hammer with a knife
sharp handle may still elegantly employ the principle
of leverage, but is useless as a hammer.

Making it easier to do what is right is a noble goal
for us all.

Mark

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com