Use case: rebates

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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
_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
Reply | Threaded
Open this post in threaded view
|

Re: Use case: rebates

Neil Williams-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark G. Woodruff wrote:
| * the purchase of a capital asset

Make a transaction from the credit card to Assets:Fixed Assets for the
value of the 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

So the credit card transaction now becomes a split so that you send the
capital cost to Assets and the tax to an Expense - probably
Expense:Tax:Sales Tax or similar. That will allow you to see all the
money spent in this way in a report of your taxes.

| * the terms of the purchase, when the payment will be
| due on my credit card

That is best done in the reconcile dialog. When you receive your first
credit card statement, reconcile it in GnuCash and set the reconcile
date to the statement date. Then, when you reconcile the next credit
card statement from that company, GnuCash will offer you a date that is
one month on from the last reconciled date.

| * the terms of the rebate

A scheduled transaction? GnuCash cannot be expected to record this as
the terms of the rebate require a real payment, not just a GnuCash
transaction. At least with an SX, you get a prompt (configurable) when
you start GnuCash that reminds you that a real-world payment needs to be
made.

| I want to know when the next payment will be due on my
| credit card, and how much it will be.

That's more difficult. The calculation depends on your terms and
conditions and once you get into cash advances, running balances,
interest rate changes it gets hard to write one calculation method that
covers all cards.

| 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).

That's the SX.

~ I'd like to be reminded if the rebate
| isn't paid on time, so I can pursue it further,

You mean if the company don't pay it to you? That's when you next
reconcile the account - the value of the SX will show up and if it isn't
on the account statement then you have a problem.
:-)

| 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,

Those reports already exist.

| 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.

Depends on your tax situation, you'd need to do this yourself - maybe
with another SX.

| 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.

You could use the Memo field for that. Others will have ideas for
handling such things too.

| Too much to ask for? I hope not; this is a very common
| transaction.

GnuCash already covers it too, and more.

| I know that the current version of
| GnuCash can't do all of this.

I disagree. The current GnuCash CAN deal with all such transactions -
all that is needed is a little time getting used to the program and how
such things would be done by an accountant.

Future versions will stick v.closely to the existing model. There's no
plan or incentive to move away from double-entry, 'best practice'
accounting methods, portability etc.

| 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'!

| 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.

Not true. GnuCash follows normal accountancy rules as far as possible
and that is the future direction of the project, too. If you approach
your accounts as an accountant would do, you will find GnuCash does
precisely what your accountant would expect. I am not an accountant but
I require GnuCash to support the principles and methods that my
accountant used before I started doing it all myself. Lots of other
users have an absolute requirement that GnuCash produces data that
satisfies their own accountants.

| This is a big
| handicap to usability.

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!

| Is this something the
| development team is tackling, or is Yet Another
| Accounting Program required?

No and no. If you want to handle your accounts in the best possible
manner, GnuCash is all you need.

| I really appreciate the development that's been done

I'm sure all the developers are grateful for such comments. If GnuCash
saves you money, you could always make a donation via the SourceForge
project page!
:-)

(Donations currently accumulate until someone comes up with a suitable
way of spending them.)

| I hope
| GnuCash turns into a life-line for all concerned.

It already is! (and has been for several years!)


- --

Neil Williams
=============
http://www.codehelp.co.uk/
http://www.dclug.org.uk/
http://www.isbn.org.uk/
http://sourceforge.net/projects/isbnsearch/

http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCx9Xyk7DVr6iX/QIRAr4JAJ467Z4gzV6D2gyz2x9iIT1Ja98b3wCdHZwI
C1Kvfxhoglg55awxUCMU6fU=
=vb5w
-----END PGP SIGNATURE-----
_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
Reply | Threaded
Open this post in threaded view
|

Re: Use case: rebates

Mark G. Woodruff
--- Neil Williams <[hidden email]> 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 
_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
Reply | Threaded
Open this post in threaded view
|

Re: Use case: rebates

Neil Williams-2
On Sunday 03 July 2005 4:48 pm, Mark G. Woodruff wrote:

> --- Neil Williams <[hidden email]> 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 is in the UK, hence the difficulties of a portable implementation. Only
larger businesses need to handle VAT calculations. To most UK account
holders, VAT is an expense - part of the retail price of the item to such an
extent that if an item is £10 without VAT, the customer is charged £11.75 and
£11.75 goes into the Expense for that purchase. There is no separate sales
tax accounting for most people in the UK.

> I suggest a better way to handle it is to have a flag
> indicating whether an item is taxable or not,

?? You appear to want inventory management. GnuCash does not do inventory, as
yet. There is work being done on that.

> Terms of credit are established before, or during a
> purchase.

Then set it up as a credit agreement?

> 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.

Patches are always welcome.
:-)

> Credit terms are fairly standardized now.

Where? Not in the UK - terms are a minefield of options and changes and are
changed without notice. You'd need to implement a full versioning system that
can cope with the account before and after each round of changes to the
conditions. Entering all that would be far more work than is necessary for
most users.

I know I don't want to laboriously enter every point change in the interest
rate of my credit cards. I just pay them off before interest is charged, it's
far easier!!!!
:-)

> > | * the terms of the rebate
> >
> > A scheduled transaction?
>
> Nope. An Account Receivable. It goes on the book as
> having value.

Yes, an SX that uses A/R.

> Accounts Payable (Credit Cards, Notes) and Accounts
> Receivable all have terms.

Look at the business objects, bill terms are handled for invoices and bills
along with the inevitable A/R.

> > 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.

Make sure you've looked over the business features.

> 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.

That's inventory again, isn't it? GnuCash currently uses accounts and running
balances.

>  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.

That's inventory.

If you increase your assets by two transactions of £1 and reduce the assets by
£0.50, you are left with assets of £1.50.

To get to a value of £1 you need to account for the loss on the sale.
Currently, you're best doing that by transferring the £0.50 to an Expense as
a cost. So 50p goes to some form of income and 50p to an expense of some
kind.

To say that you have two items and that you've sold one item rather than had
an income of £0.50p, you need inventory. If a grocer buys two apples for 10p
each and sells one for 40p, he has one apple and 40p in cash. In terms of
assets, that's 50p. In terms of inventory, it's one apple.

When I invoice a customer, if they don't pay the entire invoice I do not want
GnuCash telling me that the account is settled in full - the running balance
of the account is not zero.

> Market value does not
> belong on a balance sheet (unless an asset is
> impaired, of course)!

?? I've got assets for my house and my car. Market value is all I have and I
need to have that showing up. For UK tax purposes, I implement certain
depreciation rules for capital allowance that work solely on the original
purchase price.

> GnuCash does some things an accountant would expect,
> and some that are totally wrong.

in your humble opinion - I've yet to find GnuCash doing anything that my
accountant would not have done.

--

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Use case: rebates

Derek Atkins
In reply to this post by Mark G. Woodruff
"Mark G. Woodruff" <[hidden email]> writes:

> --- Neil Williams <[hidden email]> 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.

Or you could make a subaccount of the asset to keep track
of the tax.  Adding "flags" is much more challenging and
prone to errors..  Not to mention the challenge of the
UI to present the information and handle all the nit-picky
little locale issues everywhere in the world!

-derek
--
       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
       [hidden email]                        PGP key available
_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user