Use case: rebates

[Mark G. Woodruff]

Hello!

After about two weeks of work, I finally was able to
transition from Quicken 2000 to GnuCash. ("Two weeks",
you ask? Well, consider that it involved getting
CoLinux, Debian, and Cygwin/X all running under XP,
along with fighting some bugs in the QIF import
script. At the moment, I'd say one has to pretty
motivated to move to it. But that story is for another
message.)

As I'm working with GnuCash, I look at the
transactions I make as a user and consider they might
make good use cases, either for documenting in FAQs,
or for development consideration. 

Here's my first:

I buy a new monitor using a credit card that has a
rebate. 

I want GnuCash to remember all the aspects of this
transaction, including:

* the purchase of a capital asset
* 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
* the terms of the purchase, when the payment will be
due on my credit card
* the terms of the rebate

I want to know when the next payment will be due on my
credit card, and how much it will be.
I also want GnuCash to remember the rebate under
Accounts Receivable, and the terms of the rebate (that
it should be paid within 12 weeks of the postmark, in
this case). I'd like to be reminded if the rebate
isn't paid on time, so I can pursue it further, as we
all have to do so often on rebates. I furthermore want
to be able to pull a report at the end of my tax year
that shows how much sales tax total I've paid, so I
can get the appropriate deduction. I'd also like it to
tell me what the appropriate depreciation schedule
would be for this type of asset it is. I'd also like
it to be able to segregate this purchase to a project
if need be, so that if I purchased this for a special
purpose I could find out what the balance of
everything involved in that project is.

Too much to ask for? I hope not; this is a very common
transaction. I know that the current version of
GnuCash can't do all of this. Will future versions be
able to? Is this the direction this project is going?

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. It
forces the user to learn how the program stores data,
and to enter the data in the way the program wants it,
rather than the other way around. This is a big
handicap to usability. Is this something the
development team is tackling, or is Yet Another
Accounting Program required?

I really appreciate the development that's been done
on GnuCash so far. Quicken is a frightening program
(who in their right mind would write a financial
program that uses single-precision floating point?!),
a tar pit that snares all who fall into it. I hope
GnuCash turns into a life-line for all concerned.

Mark


		
____________________________________________________ 
Yahoo! Sports 
Rekindle the Rivalries. Sign up for Fantasy Football 
http://football.fantasysports.yahoo.com