Re: gnucash 1.3.7 bugs.

2000-05-15 Thread linas


forward note to mailing list

It's been rumoured that Jon A. Christopher said:
> 
> 
> Hello,
> 
> I'm reporting a bug in the RPM version of Gnucash 1.3.7, running on a RH
> 6.2 system.  The Account reconcile window has the credits and debits
> columns reversed.
> 
> -Jon
> 
> -- 
> Dr. Jon A. Christopher  / [EMAIL PROTECTED] |  Project URLs:
> Department of Biochem./Biophys./  spock: http://quorum.tamu.edu/spock
> Texas A&M University MS-2128  / lesstif: http://www.lesstif.org/
> College Station, TX, 77843   / personal: http://quorum.tamu.edu/jon
> 
> 




Re: gnucash 1.3.7 bugs.

2000-05-15 Thread Dylan Paul Thurston

On Mon, May 15, 2000 at 05:32:29PM -0500, [EMAIL PROTECTED] wrote:
> It's been rumoured that Jon A. Christopher said:
> > 
> > 
> > Hello,
> > 
> > I'm reporting a bug in the RPM version of Gnucash 1.3.7, running on a RH
> > 6.2 system.  The Account reconcile window has the credits and debits
> > columns reversed.

On my version of GnuCash 1.3.7 (compiled from source on a Debian woody
system), the credit and debit columns are reversed in many places,
including register windows.  It seems to only happen if the columns
are titled 'Debit' and 'Credit'.

--Dylan Thurston




Re: gnucash 1.3.7 bugs.

2000-05-15 Thread Dave Peticolas


> 
> I'm reporting a bug in the RPM version of Gnucash 1.3.7, running on a RH
> 6.2 system.  The Account reconcile window has the credits and debits
> columns reversed.
> 
> -Jon

Hi Jon, here is what happened. We recently discovered that we have
been using the terms 'debit' and 'credit' incorrectly in GnuCash.
In standard accounting practice, a debit is an increase in assets,
such as a deposit to a bank account, and a credit is a decrease in
assets, such as a payment, credit card charge, etc.

Starting in 1.3.7, we began using the terms according to the sense
above, thus the change in column position of items in the reconcile
window. I apologize for any confusion.

thanks,
dave



Re: gnucash 1.3.7 bugs.

2000-05-15 Thread Jon A. Christopher

To my understanding, that's only true if you're using a double-entry
ledger system.  The statements I get from my bank, and from every credit
card I've ever had use a debit to mean a charge...money going out of the
account, and a credit for money flowing into an account.  Thus the
terminology "deposits and other credits", and "checks and other debits".
I'm not an accountant, but I expect that the terms are still backwards.

-Jon

On Mon, 15 May 2000, Dave Peticolas wrote:

> 
> > 
> > I'm reporting a bug in the RPM version of Gnucash 1.3.7, running on a RH
> > 6.2 system.  The Account reconcile window has the credits and debits
> > columns reversed.
> > 
> > -Jon
> 
> Hi Jon, here is what happened. We recently discovered that we have
> been using the terms 'debit' and 'credit' incorrectly in GnuCash.
> In standard accounting practice, a debit is an increase in assets,
> such as a deposit to a bank account, and a credit is a decrease in
> assets, such as a payment, credit card charge, etc.
> 
> Starting in 1.3.7, we began using the terms according to the sense
> above, thus the change in column position of items in the reconcile
> window. I apologize for any confusion.
> 
> thanks,
> dave
> 

-- 
Dr. Jon A. Christopher  / [EMAIL PROTECTED] |  Project URLs:
Department of Biochem./Biophys./  spock: http://quorum.tamu.edu/spock
Texas A&M University MS-2128  / lesstif: http://www.lesstif.org/
College Station, TX, 77843   / personal: http://quorum.tamu.edu/jon





Re: gnucash 1.3.7 bugs.

2000-05-15 Thread Richard Wackerbarth

On Mon, 15 May 2000, Jon A. Christopher wrote:
> To my understanding, that's only true if you're using a double-entry
> ledger system.  The statements I get from my bank, and from every credit
> card I've ever had use a debit to mean a charge...money going out of the
> account, and a credit for money flowing into an account.  Thus the
> terminology "deposits and other credits", and "checks and other debits".
> I'm not an accountant, but I expect that the terms are still backwards.

The "problem" with credits/debits and bank statements is that it all depends 
whose books they are.

When you deposit some money at the bank, you think of it as an asset. The 
bank thinks of it as a liability (they have to pay it back).

Since most individuals don't keep books, they usually think of things 
reversed because they think that the statement is theirs when it is actually 
the banks.



Re: gnucash 1.3.7 bugs.

2000-05-15 Thread Dave Peticolas

> To my understanding, that's only true if you're using a double-entry
> ledger system.  The statements I get from my bank, and from every credit
> card I've ever had use a debit to mean a charge...money going out of the
> account, and a credit for money flowing into an account.  Thus the
> terminology "deposits and other credits", and "checks and other debits".
> I'm not an accountant, but I expect that the terms are still backwards.
 
Surprise, you are using a double-entry ledger system :) That is, unless
you are leaving all of your 'transfer from' fields blanks, all of your
entries in checking account have a matching entry in an expense, income,
etc. account.

I suppose we could make the meaning of 'debit' and 'credit' configurable.
It's really unfortunate that the informal meanings of the terms are exactly
opposite the accouting meanings.

dave



Re: gnucash 1.3.7 bugs.

2000-05-15 Thread Christopher Browne

On Mon, 15 May 2000 22:43:51 CDT, the world broke into rejoicing as
"Jon A. Christopher" <[EMAIL PROTECTED]>  said:
> To my understanding, that's only true if you're using a double-entry
> ledger system.  The statements I get from my bank, and from every credit
> card I've ever had use a debit to mean a charge...money going out of the
> account, and a credit for money flowing into an account.  Thus the
> terminology "deposits and other credits", and "checks and other debits".
> I'm not an accountant, but I expect that the terms are still backwards.

What is happening here is that the bank is reporting things from _THEIR_
perspective.

For them, a "debit memo" puts money in _THEIR_ account, and represents 
an income to THEM.

Which is mathematically opposite to what it is to you.

When you set up an account, and put $5000 in it, that may be "positive"
to you, something that you own.  From the bank's perspective, THEY OWE YOU
A DEBT.  Again, that's a symmetry whereby something that accounts _to_ you
accounts _against_ them.  Your perspective is, again, opposite to theirs.
--
Windows 'XCV -  A 32 bit patch for  a 16 bit interface to an  8 bit OS
designed for a 4 bit chip from  a 2 bit company that can't stand 1 bit
of competition...
[EMAIL PROTECTED] - 



Re: gnucash 1.3.7 bugs.

2000-05-15 Thread Jon A. Christopher

On Mon, 15 May 2000, Dave Peticolas wrote:

> > To my understanding, that's only true if you're using a double-entry
> > ledger system.  The statements I get from my bank, and from every credit
> > card I've ever had use a debit to mean a charge...money going out of the
> > account, and a credit for money flowing into an account.  Thus the
> > terminology "deposits and other credits", and "checks and other debits".
> > I'm not an accountant, but I expect that the terms are still backwards.
>  
> Surprise, you are using a double-entry ledger system :) That is, unless
> you are leaving all of your 'transfer from' fields blanks, all of your
> entries in checking account have a matching entry in an expense, income,
> etc. account.
> 
> I suppose we could make the meaning of 'debit' and 'credit' configurable.
> It's really unfortunate that the informal meanings of the terms are exactly
> opposite the accouting meanings.
> 
> dave

I'm not using gnucash's double-entry features.  Perhaps that'd be the best
solution---if using single-entry, use the informal meanings of
credit/debit, and if you're doing double entry, use the formal ones.  Or
just punt and call the columns "funds in" and "funds out" ;)

-Jon


-- 
Dr. Jon A. Christopher  / [EMAIL PROTECTED] |  Project URLs:
Department of Biochem./Biophys./  spock: http://quorum.tamu.edu/spock
Texas A&M University MS-2128  / lesstif: http://www.lesstif.org/
College Station, TX, 77843   / personal: http://quorum.tamu.edu/jon





Re: gnucash 1.3.7 bugs.

2000-05-15 Thread Rob Walker


> On Tue, 16 May 2000 00:31:06 -0500 (CDT), "Jon A. Christopher"
> <[EMAIL PROTECTED]> said:

Jon> I'm not using gnucash's double-entry features.  Perhaps that'd be
Jon> the best solution---if using single-entry, use the informal
Jon> meanings of credit/debit, and if you're doing double entry, use
Jon> the formal ones.  Or just punt and call the columns "funds in"
Jon> and "funds out" ;)

Jon,

I am with you.  Confused when getting into using the double entry for
personal finances.  However, I am going to go ahead and do double
entry anyway, as it will be the best over the long run.

rob



Re: gnucash 1.3.7 bugs.

2000-05-15 Thread Dave Peticolas

> On Mon, 15 May 2000, Dave Peticolas wrote:
> 
> > > To my understanding, that's only true if you're using a double-entry
> > > ledger system.  The statements I get from my bank, and from every credit
> > > card I've ever had use a debit to mean a charge...money going out of the
> > > account, and a credit for money flowing into an account.  Thus the
> > > terminology "deposits and other credits", and "checks and other debits".
> > > I'm not an accountant, but I expect that the terms are still backwards.
> >  
> > Surprise, you are using a double-entry ledger system :) That is, unless
> > you are leaving all of your 'transfer from' fields blanks, all of your
> > entries in checking account have a matching entry in an expense, income,
> > etc. account.
> > 
> > I suppose we could make the meaning of 'debit' and 'credit' configurable.
> > It's really unfortunate that the informal meanings of the terms are exactly
> > opposite the accouting meanings.
> > 
> > dave
> 
> I'm not using gnucash's double-entry features.  Perhaps that'd be the best
> solution---if using single-entry, use the informal meanings of
> credit/debit, and if you're doing double entry, use the formal ones.  Or
> just punt and call the columns "funds in" and "funds out" ;)

I think the latter option is probably best, since making it possible
to reverse the meanings could end up being very confusing. Right now,
as long as you don't have 'always use debit/credit' labels in the
register, you only see debit/credit in:

+ asset, liability, and equity accounts
+ reconcile window
+ a few reports, though I just noticed their use of debit/credit
  needs to be fixed.

Most people not using double-entry are unlikely to use the
asset, etc. account types.

How about, as a first step, we make the reconcile window be
configurable to use, e.g., 'Funds In' and 'Funds Out' instead
of debit/credit as you suggest?

dave



Re: gnucash 1.3.7 bugs.

2000-05-16 Thread Randolph Fritz

On Mon, May 15, 2000 at 05:56:14PM -0700, Dave Peticolas wrote:
> 
> Hi Jon, here is what happened. We recently discovered that we have
> been using the terms 'debit' and 'credit' incorrectly in GnuCash.
> In standard accounting practice, a debit is an increase in assets,
> such as a deposit to a bank account, and a credit is a decrease in
> assets, such as a payment, credit card charge, etc.
> 
> Starting in 1.3.7, we began using the terms according to the sense
> above, thus the change in column position of items in the reconcile
> window. I apologize for any confusion.
> 

Could someone tell me, please, the historical background of this odd
use of language?  If it's already been discussed, then please point me
to the archives.

-- 
Randolph Fritz
Eugene, Oregon, USA



Re: gnucash 1.3.7 bugs.

2000-05-16 Thread Bill Gribble

"Jon A. Christopher" <[EMAIL PROTECTED]> writes:
> I'm not using gnucash's double-entry features.  Perhaps that'd be the best
> solution---if using single-entry, use the informal meanings of
> credit/debit, and if you're doing double entry, use the formal ones.  Or
> just punt and call the columns "funds in" and "funds out" ;)

We've been discussing whether to eliminate the option of "single
entry" completely.  Presumably this would inconvenience you :) Can you
describe what it is that keeps you from using the default (double
entry) mode of operation of gnucash?  If you can explain it, maybe we
can fix whatever it is that's a barrier to you.

Bill Gribble




Re: gnucash 1.3.7 bugs.

2000-05-16 Thread Michael Gerdts

On Mon, May 15, 2000 at 05:56:14PM -0700, Dave Peticolas wrote:
> 
> > 
> > I'm reporting a bug in the RPM version of Gnucash 1.3.7, running on a RH
> > 6.2 system.  The Account reconcile window has the credits and debits
> > columns reversed.
> > 
> > -Jon
> 
> Hi Jon, here is what happened. We recently discovered that we have
> been using the terms 'debit' and 'credit' incorrectly in GnuCash.
> In standard accounting practice, a debit is an increase in assets,
> such as a deposit to a bank account, and a credit is a decrease in
> assets, such as a payment, credit card charge, etc.
> 
> Starting in 1.3.7, we began using the terms according to the sense
> above, thus the change in column position of items in the reconcile
> window. I apologize for any confusion.
> 
> thanks,
> dave

I suspect that this is only one of several issues that will be discovered
WRT the differences between the way that accountants do their business and
the way that everyone else thinks of their money.  I don't see it terribly
different from most of the other issues that Linux programmers have had to
deal with in attempts to expand the non-technical user base.

UNIX geeks want a full set of man pages, development libraries, a good
compiler, and a fully functional xterm-like terminal.  To many of them
(particularly the longer-term UNIX geeks), twm is the ultimate window
manager and mail(1) is a fully functional mailer, with EDITOR set to ex.

Grandma wants something that she turns on, has minimal wait, and can click
on something that looks like an envelope or a mailman (err, letter
carrier), and be able to read her mail.

Accountant-like people want a financial application that allows them to use
the terminology and practices that are the established, tehncially right
accounting ways of doing things.

I am a UNIX geek.  Accountants are boring people that do stupid things like
call the money that I own a debit.  They probably do a bunch of other dumb
things that I don't care about.  I want a configuration option that allows
me to unselect "I am an accountant".  My grandma (who used to be a
beekeeper) doesn't want to learn to see things like an accountant either.

This issue really seems to beg the question of who the target audience is.
If it is accountants, it makes good sense to do things like accountants do.
If it is the average joe that thinks that accountants are as nerdy as UNIX
geeks but lacking personality, the more casual presentation of accounting
should appear wherever there is a choice to be made between casual and
technically accurate presentation.  

Since both types of users have to adhere to the same laws and spend money
in rather similar ways, it makes a lot of sense to have a configurable
system that allows some folks to have "credit", "debit", and "double
entry", while allowing others to have "money in", "money out", "income
categories", and "expense categories".  And then when the average joe
changes majors from history to business, a simple changing of preferences
makes the personal finances turn into something that resembles things that
he/she is learning about in accounting 101.

Mike



Re: gnucash 1.3.7 bugs.

2000-05-16 Thread Rob Browning

Randolph Fritz <[EMAIL PROTECTED]> writes:

> Could someone tell me, please, the historical background of this odd
> use of language?  If it's already been discussed, then please point
> me to the archives.

If we get a good description of all this, we should stick it in the
docs.

-- 
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930



Re: gnucash 1.3.7 bugs.

2000-05-16 Thread Bill Gribble

Michael Gerdts <[EMAIL PROTECTED]> writes:
> Since both types of users have to adhere to the same laws and spend money
> in rather similar ways, it makes a lot of sense to have a configurable
> system that allows some folks to have "credit", "debit", and "double
> entry", while allowing others to have "money in", "money out", "income
> categories", and "expense categories". 

I agree about the labels; while I prefer to see the accounting way, it
makes sense to have "common sense" names for the column headers...
which there already are for the bank and credit card registers that
everyone looks at.

Not too long ago, there were "common sense" labels for everything:
liabilities, assets, expenses, income.  The problem was that they
didn't make much sense.  If you can come up with a set of good
one-word column headers that makes sense for expense, income, asset,
liability, and equity accounts I'm sure they would be appreciated.

I don't understand the objection to double entry.  From the user
perspective, what's the difference between accounts and categories?
There's not one AFAICT.  The only "oddity" is that in double entry you
are forced to pick a "category" for every transaction.  Big deal.
That's what "misc" is for.

Bill Gribble






Re: gnucash 1.3.7 bugs.

2000-05-16 Thread Bill Gribble

Randolph Fritz <[EMAIL PROTECTED]> writes:
> Could someone tell me, please, the historical background of this odd
> use of language?  If it's already been discussed, then please point me
> to the archives.

When you make a deposit in a bank account, the bank OWES YOU money.
You become a "creditor" and the bank is a "debtor", just as if you had
loaned the bank money.  Which you have.

A "credit" is a "payment by a debtor on an amount due" by both common
sense and accounting practice.

Therefore, a withdrawal of money from the bank, which reduces the 
balance of the account and therefore the amount that the bank owes
you, is a "credit". 

A "debit" is etymologically a "debt", i.e. an increase in the amount
owed by a debtor, again in both common sense and accounting practice.

Therefore, a deposit of money into the bank, which is an increase in
the balance of the account and of the amount of money that the bank
owes you, is a "debit".

I had to have this explained to me a million times but now it makes
perfect sense and I can't even think of a withdrawal being a "debit"
any more (how's that? I don't owe the bank any money!)

Bill Gribble






Re: gnucash 1.3.7 bugs.

2000-05-16 Thread Rob Walker


> On 16 May 2000 10:40:15 -0500, Bill Gribble
> <[EMAIL PROTECTED]> said:

Bill> Not too long ago, there were "common sense" labels for
Bill> everything: liabilities, assets, expenses, income.  The problem
Bill> was that they didn't make much sense.  If you can come up with a
Bill> set of good one-word column headers that makes sense for
Bill> expense, income, asset, liability, and equity accounts I'm sure
Bill> they would be appreciated.

expense   ==   out
income==   in
asset ==   good stuff
liability ==   bad stuff 
equity==   worth


not quite all one word, maybe just s/stuff//, I don't know.

rob



Re: gnucash 1.3.7 bugs.

2000-05-16 Thread Jon A. Christopher

On 16 May 2000, Bill Gribble wrote:

> "Jon A. Christopher" <[EMAIL PROTECTED]> writes:
> > I'm not using gnucash's double-entry features.  Perhaps that'd be the best
> > solution---if using single-entry, use the informal meanings of
> > credit/debit, and if you're doing double entry, use the formal ones.  Or
> > just punt and call the columns "funds in" and "funds out" ;)
> 
> We've been discussing whether to eliminate the option of "single
> entry" completely.  Presumably this would inconvenience you :) Can you
> describe what it is that keeps you from using the default (double
> entry) mode of operation of gnucash?  If you can explain it, maybe we
> can fix whatever it is that's a barrier to you.
> 
> Bill Gribble

Eliminating single-entry would be a mistake IMHO.  Who wants to learn a
new system of accounting just to balance their checkbook?  Not me.  I'm a
programmer and geek, but for some things, I just want to use the bloody
software, not become one with it.  I'm sure I could figure out the
double-entry system, but I don't really want to go to extra effort for
something as trivial as money after all.  Gnucash as it is right now
(except for the unfortunate column names) is perfect for people who just
want to balance their checkbook.  I know it'll do much more, and more is
planned, but that's not functionality I'm currently interested in.  Don't
most programs start out in the simplest mode of operation, and then allow
users to optionally add complexity?  I think that's the best way for
gnucash to go, certainly not the route of removing the simpler mode of
operation! If gnucash goes entirely double-entry, I'll probably just not
upgrade from the current version (which would be unfortunate), and if
serious bugs manifest themselves, I'd probably go with another program.  
Please don't remove the single-entry mode!

Regards,
Jon

-- 
Dr. Jon A. Christopher  / [EMAIL PROTECTED] |  Project URLs:
Department of Biochem./Biophys./  spock: http://quorum.tamu.edu/spock
Texas A&M University MS-2128  / lesstif: http://www.lesstif.org/
College Station, TX, 77843   / personal: http://quorum.tamu.edu/jon





Re: gnucash 1.3.7 bugs.

2000-05-16 Thread Jonathan Corbet

> How about, as a first step, we make the reconcile window be
> configurable to use, e.g., 'Funds In' and 'Funds Out' instead
> of debit/credit as you suggest?

Something like that is probably necessary.

Gnucash looks to me like one of the crucial tools that will get Linux onto
desktops everywhere.  But that's going to be a lot harder if "normal" users
find the interface confusing.  I think it's more important for people to be
able to handle their finances without getting confused or worrying about
getting things wrong than having the technically correct terminology.

My two cents...

jon

Jonathan Corbet
Executive editor, LWN.net
[EMAIL PROTECTED]



Re: gnucash 1.3.7 bugs.

2000-05-16 Thread Tim Mooney

In regard to: Re: gnucash 1.3.7 bugs., Michael Gerdts said (at 10:24am on...:

>This issue really seems to beg the question of who the target audience is.
>If it is accountants, it makes good sense to do things like accountants do.
>If it is the average joe that thinks that accountants are as nerdy as UNIX
>geeks but lacking personality, the more casual presentation of accounting
>should appear wherever there is a choice to be made between casual and
>technically accurate presentation.  

That's pretty much exactly what I was thinking too.  Apps like "Quicken"
use sound accounting principles but they aren't targeted at professional
accountants, so their interfaces are designed to be intelligible by Joe
User.  A professional accountant may scoff at the interface, but the simple
interface on Quicken or MS Money is very good for its target audience.

>Since both types of users have to adhere to the same laws and spend money
>in rather similar ways, it makes a lot of sense to have a configurable
>system that allows some folks to have "credit", "debit", and "double
>entry", while allowing others to have "money in", "money out", "income
>categories", and "expense categories".  And then when the average joe
>changes majors from history to business, a simple changing of preferences
>makes the personal finances turn into something that resembles things that
>he/she is learning about in accounting 101.

Perhaps, depending on how much work this turns into for the developers.  Maybe
the "know thy target audience" answer will obviate the need for this much
flexibility.  It's nice to have the flexibility, but there will be a cost
associated with it.

Tim
-- 
Tim Mooney  [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J1, IACC Building  (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164




Re: gnucash 1.3.7 bugs.

2000-05-16 Thread Richard Wackerbarth

On Tue, 16 May 2000, Tim Mooney wrote:
> >And then when the average joe
> >changes majors from history to business, a simple changing of preferences
> >makes the personal finances turn into something that resembles things that
> >he/she is learning about in accounting 101.
>
> Perhaps, depending on how much work this turns into for the developers. 
> Maybe the "know thy target audience" answer will obviate the need for this
> much flexibility.  It's nice to have the flexibility, but there will be a
> cost associated with it.

The cost may not be as bad as it seems. Since we already have the abstraction 
for "furrin" languages, we already have most of the hooks in place to handle 
alternate textual strings in the displays. The biggest hassle is likely to be 
the documentation.



Re: gnucash 1.3.7 bugs.

2000-05-16 Thread Bill Gribble

"Jon A. Christopher" <[EMAIL PROTECTED]> writes:
> Eliminating single-entry would be a mistake IMHO.  Who wants to learn a
> new system of accounting just to balance their checkbook?  

But my question was, WHAT is it about double-entry that's new?  It
doesn't change the way you use gnucash AT ALL, except that you are
required to have a "category" for every transaction.  Are you
seriously saying that that's too much for you?

> Not me.  I'm a programmer and geek, but for some things, I just want
> to use the bloody software, not become one with it. 

I just don't get it.  I agree that you might not want to go to the
effort to become "at one" with a piece of software, but I can't see
how using double entry fills that description.  I'd appreciate it if
you could explain so I can understand where you are coming from.

Bill Gribble



Re: gnucash 1.3.7 bugs.

2000-05-16 Thread Rob Browning

"Jon A. Christopher" <[EMAIL PROTECTED]> writes:

> Eliminating single-entry would be a mistake IMHO.  Who wants to
> learn a new system of accounting just to balance their checkbook?

Are you sure you understand what's meant when we're talking about
double entry?  The only thing it means is that you have to have a
category for every transaction (i.e. something, *anything* in the
"Transfer From" field).  If you're completely attached with the
"single-entry" model, which means that you're allowed to have
*nothing* in the "Transfer From" field, would you really mind just
having a default value of "misc" being put in there?  It won't change
anything else you're doing.

I just get the feeling you might be misunderstanding what we mean by
double-entry, though perhaps not.  I just want to make sure we're
talking about the same thing...

-- 
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930



RE: gnucash 1.3.7 bugs.

2000-05-16 Thread Rob Coker

>
> "Jon A. Christopher" <[EMAIL PROTECTED]> writes:
> > Eliminating single-entry would be a mistake IMHO.  Who wants to learn a
> > new system of accounting just to balance their checkbook?
>
Does he mean that he only has one category/account? - checking.  So, he's
just using gnucash like a simple calculator or maybe a preprogrammed
spreadsheet?  I don't get it.

Rob Coker




Re: gnucash 1.3.7 bugs.

2000-05-16 Thread Hendrik Boom

> > How about, as a first step, we make the reconcile window be
> > configurable to use, e.g., 'Funds In' and 'Funds Out' instead
> > of debit/credit as you suggest?
> 
> Something like that is probably necessary.
> 
> Gnucash looks to me like one of the crucial tools that will get Linux onto
> desktops everywhere.  But that's going to be a lot harder if "normal" users
> find the interface confusing.  I think it's more important for people to be
> able to handle their finances without getting confused or worrying about
> getting things wrong than having the technically correct terminology.

What we *have* to avoid is using the technically correct terminology with
an incorrect meaning.  An option for using informal language is perfectly
OK by me, as long as the informality does not consist of using correct words
with incorrect meanings.




Re: gnucash 1.3.7 bugs.

2000-05-16 Thread Christopher Browne

On Tue, 16 May 2000 20:48:30 CDT, the world broke into rejoicing as
"Rob Coker" <[EMAIL PROTECTED]>  said:
> > "Jon A. Christopher" <[EMAIL PROTECTED]> writes:
> > > Eliminating single-entry would be a mistake IMHO.  Who wants to learn a
> > > new system of accounting just to balance their checkbook?
> >
> Does he mean that he only has one category/account? - checking.  So, he's
> just using gnucash like a simple calculator or maybe a preprogrammed
> spreadsheet?  I don't get it.

No, I think that Deep Confusion has entered.

I would speculate that the perception is that "Double Entry Accounting"
is some deviant methodology practiced by professional accountants that
reverses the terminology that would normally be used by individuals
managing a simple checkbook.
--
"It is far from complete, but it should explain enough that you don't
just stare at your sendmail.cf file like a deer staring at an oncoming
truck."  -- David Charlap
[EMAIL PROTECTED] - 



Re: gnucash 1.3.7 bugs.

2000-05-17 Thread Hendrik Boom

> Randolph Fritz <[EMAIL PROTECTED]> writes:
> > Could someone tell me, please, the historical background of this odd
> > use of language?  If it's already been discussed, then please point me
> > to the archives.
> 
> When you make a deposit in a bank account, the bank OWES YOU money.
> You become a "creditor" and the bank is a "debtor", just as if you had
> loaned the bank money.  Which you have.
> 
> A "credit" is a "payment by a debtor on an amount due" by both common
> sense and accounting practice.
> 
> Therefore, a withdrawal of money from the bank, which reduces the 
> balance of the account and therefore the amount that the bank owes
> you, is a "credit". 
> 
> A "debit" is etymologically a "debt", i.e. an increase in the amount
> owed by a debtor, again in both common sense and accounting practice.
> 
> Therefore, a deposit of money into the bank, which is an increase in
> the balance of the account and of the amount of money that the bank
> owes you, is a "debit".
> 
> I had to have this explained to me a million times but now it makes
> perfect sense and I can't even think of a withdrawal being a "debit"
> any more (how's that? I don't owe the bank any money!)

Let's see if I understand this now.

Does this mean that if I overdraw my chequing account, and subsequently
deposit $16.74 to cancel the overdraft, that the $16.74 is a credit,
because I owed the bank money? And if I subsequently deposit $15.75 to
make the balance positive, the $15.75 is a debit, because it establishes the
bank's debt to me?

-- hendrik.

> 
> Bill Gribble
> 
> 
> 




Re: gnucash 1.3.7 bugs.

2000-05-17 Thread John Hasler

Hendrik Boom writes:
> Does this mean that if I overdraw my chequing account, and subsequently
> deposit $16.74 to cancel the overdraft, that the $16.74 is a credit,
> because I owed the bank money?

No.  Each check you write is a credit to your checking account (in your
books, not the banks) because it reduces the amount the bank owes you.
This includes the check that caused the overdraft.  During the period that
the overdraft existed your checking account had credit balance because you
owed the bank money.  The $16.74 is a debit because it decreases the amount
you owe them.

> And if I subsequently deposit $15.75 to make the balance positive, the
> $15.75 is a debit, because it establishes the bank's debt to me?

It is a debit because it increases the bank's debt to you.  The concept has
been abstracted a bit: anything that moves the balance of an account in the
debit direction is a debit, even if the balance remains a credit balance
after the transaction.
-- 
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI



Re: gnucash 1.3.7 bugs.

2000-05-17 Thread Scott Haug

On Wed, May 17, 2000 at 11:40:42AM -0700, Rob Walker wrote:
> 
> > On 16 May 2000 16:36:00 -0500, Bill Gribble
> > <[EMAIL PROTECTED]> said:
> 
> Bill> "Jon A. Christopher" <[EMAIL PROTECTED]> writes:
> 
> >> Eliminating single-entry would be a mistake IMHO.  Who wants to
> >> learn a new system of accounting just to balance their checkbook?
> 
> Bill> But my question was, WHAT is it about double-entry that's new?
> Bill> It doesn't change the way you use gnucash AT ALL, except that
> Bill> you are required to have a "category" for every transaction.
> Bill> Are you seriously saying that that's too much for you?
> 
> Maybe there could be an option which was "default all categories to
> misc", which would keep people from having to do the "categorize every 
> transaction" thing when they don't want to.
> 

Better yet, make the optional default category configurable, so that one person
could have it as misc, while another could have it as Uncategorized, still
another as Expenses:Miscellaneous.  There would be a default category, but
allow the user to change it to what they want.

-Scott

-- 



Re: gnucash 1.3.7 bugs.

2000-05-19 Thread Jon A. Christopher

On Wed, 17 May 2000, Rob Walker wrote:

> 
> > On 16 May 2000 16:36:00 -0500, Bill Gribble
> > <[EMAIL PROTECTED]> said:
> 
> Bill> "Jon A. Christopher" <[EMAIL PROTECTED]> writes:
> 
> >> Eliminating single-entry would be a mistake IMHO.  Who wants to
> >> learn a new system of accounting just to balance their checkbook?
> 
> Bill> But my question was, WHAT is it about double-entry that's new?
> Bill> It doesn't change the way you use gnucash AT ALL, except that
> Bill> you are required to have a "category" for every transaction.
> Bill> Are you seriously saying that that's too much for you?
> 
> Maybe there could be an option which was "default all categories to
> misc", which would keep people from having to do the "categorize every 
> transaction" thing when they don't want to.

I still think things are fine the way they are.  Why change it?

-Jon

-- 
Dr. Jon A. Christopher  / [EMAIL PROTECTED] |  Project URLs:
Department of Biochem./Biophys./  spock: http://quorum.tamu.edu/spock
Texas A&M University MS-2128  / lesstif: http://www.lesstif.org/
College Station, TX, 77843   / personal: http://quorum.tamu.edu/jon





Re: gnucash 1.3.7 bugs.

2000-05-17 Thread Rob Walker


> On 16 May 2000 16:36:00 -0500, Bill Gribble
> <[EMAIL PROTECTED]> said:

Bill> "Jon A. Christopher" <[EMAIL PROTECTED]> writes:

>> Eliminating single-entry would be a mistake IMHO.  Who wants to
>> learn a new system of accounting just to balance their checkbook?

Bill> But my question was, WHAT is it about double-entry that's new?
Bill> It doesn't change the way you use gnucash AT ALL, except that
Bill> you are required to have a "category" for every transaction.
Bill> Are you seriously saying that that's too much for you?

Maybe there could be an option which was "default all categories to
misc", which would keep people from having to do the "categorize every 
transaction" thing when they don't want to.

rob





debits and credits WAS: gnucash 1.3.7 bugs.

2000-05-17 Thread Hendrik Boom

> Randolph Fritz <[EMAIL PROTECTED]> writes:
> > Could someone tell me, please, the historical background of this odd
> > use of language?  If it's already been discussed, then please point me
> > to the archives.

Bill, Let me make another try to understand this.  In a previous posting
you (I believe?) said that the reason terminology had become so confused
was that peoples bank statements were produced from the bank's
point of view, instead of the client's point of view.  So clients
who did not understand this (i.e., most people) ended up with an exactly
reversed meaning for the words "credit" and "debit".
But you posting I am quoting below seems to completely ognore the
point-of view issue.  Let me try to weave my confusion it into
the text and see if it makes sense.

Or should I just find a good book on accounting?

> 
> When you make a deposit in a bank account, the bank OWES YOU money.
> You become a "creditor" and the bank is a "debtor", just as if you had
> loaned the bank money.  Which you have.

So the points-of-view are that of a "creditor" and a "debtor".

> 
> A "credit" is a "payment by a debtor on an amount due" by both common
> sense and accounting practice.
> 
> Therefore, a withdrawal of money from the bank, which reduces the 
> balance of the account and therefore the amount that the bank owes
> you, is a "credit". 

Is point of view relevant here?  Is this a credit from the bank's point
of view and a debit from yours?  Or is it a credit from any point of view?

> 
> A "debit" is etymologically a "debt", i.e. an increase in the amount
> owed by a debtor, again in both common sense and accounting practice.
> 
> Therefore, a deposit of money into the bank, which is an increase in
> the balance of the account and of the amount of money that the bank
> owes you, is a "debit".

And is this a debit from the bank's point of view and a credit from yours?
Because you now have an increased assets, and the bank has reduced assets?

Or is the terminology independent of point of view?

> 
> I had to have this explained to me a million times but now it makes
> perfect sense and I can't even think of a withdrawal being a "debit"
> any more (how's that? I don't owe the bank any money!)
> 
> Bill Gribble
> 
-- hendrik.
> 




Re: debits and credits WAS: gnucash 1.3.7 bugs.

2000-05-17 Thread Christopher Browne

On Wed, 17 May 2000 21:13:49 EDT, the world broke into rejoicing as
Hendrik Boom <[EMAIL PROTECTED]>  said:
> > Randolph Fritz <[EMAIL PROTECTED]> writes:
> > > Could someone tell me, please, the historical background of this odd
> > > use of language?  If it's already been discussed, then please point me
> > > to the archives.
> 
> Bill, Let me make another try to understand this.  In a previous posting
> you (I believe?) said that the reason terminology had become so confused
> was that peoples bank statements were produced from the bank's
> point of view, instead of the client's point of view.  So clients
> who did not understand this (i.e., most people) ended up with an exactly
> reversed meaning for the words "credit" and "debit".
> But you posting I am quoting below seems to completely ognore the
> point-of view issue.  Let me try to weave my confusion it into
> the text and see if it makes sense.
> 
> Or should I just find a good book on accounting?
> 
> > 
> > When you make a deposit in a bank account, the bank OWES YOU money.
> > You become a "creditor" and the bank is a "debtor", just as if you had
> > loaned the bank money.  Which you have.
> 
> So the points-of-view are that of a "creditor" and a "debtor".

For a transaction that involves a bank account, there are _FOUR_
points of view:

a) What do _you_ apply your debit to;
b) What do _you_ apply your credit to;
c) What does the _bank_ apply their debit to;
d) Can you guess the fourth?  :-)

The one "cool" thing with this is that there's two of those transactions
that are hitting the same account, namely your bank account.

For instance, if I write a cheque for rent, there are actually three
things that happen:
1.  I give the cheque to my landlord.
Debit   Credit
  Rent Expense   $500
  Chris' Chequing Account$500

2.  The landlord cashes the cheque, and gets money from my bank.
3.  My bank deducts that money from my bank account.

>From _their_ perspective, what probably happens is:
Debit   Credit
  Chris' Chequing Account   $500
  Bank's Money On Hand   $500

The fact that two lines there appear identical, save for being
"sign reversed."  Which is the exact effect that is causing all
the confusion...  The bank reports _their_ perspective on things.

> > A "credit" is a "payment by a debtor on an amount due" by both common
> > sense and accounting practice.
> > 
> > Therefore, a withdrawal of money from the bank, which reduces the 
> > balance of the account and therefore the amount that the bank owes
> > you, is a "credit". 
> 
> Is point of view relevant here?  Is this a credit from the bank's point
> of view and a debit from yours?  Or is it a credit from any point of view?

There's _always_ BOTH a debit and a credit...

Anyhoo, Yes.  Point Of View is _highly_ relevant.

The balance in your bank account represents an asset from YOUR perspective.
Something you own.

That same balance represents a liability from the BANK's perspective.  A
debt they owe, to you.

The conventions of accounting are thus:
- Asset Balances == Debits
- Liability Balances == Credits

Based on _that_ parity, it is easy to determine what income and expenses
need to have as their parity.

Receiving income means increasing an asset, which means increasing a debit
amount.

And so, to balance that, the Income account has to get a _credit_ value.

Or if you buy something on your credit card, thus increasing what you
owe, increasing _liabilities_, that involves a _credit_ value.

To balance that, the Expense account has to get something of opposite
parity, and thus a _Debit_ value.

> > A "debit" is etymologically a "debt", i.e. an increase in the amount
> > owed by a debtor, again in both common sense and accounting practice.
> > 
> > Therefore, a deposit of money into the bank, which is an increase in
> > the balance of the account and of the amount of money that the bank
> > owes you, is a "debit".
> 
> And is this a debit from the bank's point of view and a credit from yours?
> Because you now have an increased assets, and the bank has reduced assets?
> 
> Or is the terminology independent of point of view?

It's pretty crucially connected to Point Of View.

Any time you reverse the point of view, the signs change.

Which seems prettty reasonable.

--> If I have an expense, it represents an income to whomever I'm paying.

--> When I receive income (such as my salary), it represents an expense
to my employer.
--
"The idea that Bill Gates has appeared like a knight in shining armour
to  lead all customers  out of  a mire  of technological  chaos neatly
ignores  the  fact  that  it  was  he  who,  by  peddling  second-rate
technology, led them  into it in the first place."  - Douglas Adams in
Guardian, 25-Aug-95
[EMAIL PROTECTED] - 



Re: debits and credits WAS: gnucash 1.3.7 bugs.

2000-05-17 Thread shimpei

Too many people appear to be caught up with the *terminology* of debit and
credit, as opposed to the *principles*. The origins of the term is
pretty interesting, but it doesn't really reflect the principles of modern
double-entry bookkeeping.

Physics students don't let the peculiarities of the terms "positive" or 
"negative" get in their way of understanding electricity (considering the flow 
of electrons, it's arguably more logical to call it the other way around, but 
it's much too late to change now). You shouldn't let ancient terms get in
the way of understanding accounting, either. 

Having said that, what I heard once is that "credit" referred to the trust 
lenders have conferred upon you to pay back your debts. ("Credit" comes from 
the Latin word "credere," which is "to trust in"; I conjecture that "credit"
was originally used in the sense of "he trusted [me].") Hence loans, notes,
bonds, and accounts payable are all credit accounts. So is equity.

Conversely, "debit" was originally the tangible manifestation taken up by your 
debt; that is, debit accounts are the actual things that you borrowed, or
what you got in exchange for the things that you borrowed. You borrow cash
from Mr. Shylock, so cash is a debit account. And what did you spend it for? 
Umm...laptops. Yeah, laptops. Laptops are fixed assets, so that's a debit 
account as well. The same would be true if you had spent it in Las Vegas,
which would be expenses; hence expenses are debit as well. Ditto if you
were smart and put it in a bank account instead. Hence checking accounts are
assets as well.

Clearly both credit and debit have outgrown their original meanings. Income
is a credit account, but it's hard to argue that your employer is trusting
you with any money when they pay you. Accounts receivable is an asset as
well, but it isn't clear how that is a manifestation of your debt. Like I said,
don't worry too much about the words themselves; it's the concepts that
are important.

Shimpei.





Re: debits and credits WAS: gnucash 1.3.7 bugs.

2000-05-18 Thread Bill Gribble

Hendrik Boom <[EMAIL PROTECTED]> writes:
> In a previous posting
> you (I believe?) said that the reason terminology had become so confused
> was that peoples bank statements were produced from the bank's
> point of view, instead of the client's point of view. 

Right.  When you put money in the bank, your perspective is that you
are debiting your debtors, i.e.  the total amount of money owed to you
increases.  From the bank's perspective, a deposit by you means that
the total amount of money owed to THEM decreases, so it's a credit.

This is just a layman's understanding; someone with more legitimate
accounting knowledge can flesh this out a bit or fix it if it's wrong.

Bill Gribble