a Quicken user tests out GnuCash...

James Ralston qralston+ml.gnucash-user at andrew.cmu.edu
Tue Feb 25 02:27:36 CST 2003


Thanks for the responses, everyone.

On 2003-02-21 at 06:26:54-0500 "Thomas J. Baker" <tjb at bakerconsulting.com> wrote:

> > Is [importing splits which contain negative numbers] a known bug?
> > (I'm using Quicken 2000 on Windows 98 SE.)
> 
> Known bug. It will be fixed in 1.8.2. (I had it and helped debug it).

Ok.  Do you need any further debugging help for current CVS?

On 2003-02-21 at 23:58:14+1100 David Overton <doverton at bigpond.net.au> wrote:
> I believe this is just standard accounting practice: in a journal
> entry the debits should come before the credits so that's the way
> GnuCash displays them.

On 2003-02-21 at 10:03:31-0500 plussier at mindspring.com wrote:
> I've never had this problem myself, but why does the order matter?
> As long as the transaction contains all the appropriate splits with
> the money going to/coming from the proper accounts, and everything
> is properly balanced, then you should be all set, shouldn't you?

The reason why the order matters to me is because the split amounts
correspond to the order of something in the real world (e.g., my
paycheck, a restaurant check, etc.), and the real world frequently
doesn't follow general account practices.

Take my paycheck, for example.  Due to taxes, the exact amount that is
deposited to my bank account fluctuates.  In Quicken, I've memorized
the transaction, but whenever I enter a new paycheck, I need to check
each line item to make sure it's the correct amount.  Performing this
double-checking is a *lot* easier if the order in my split transaction
view is the same order as the itemization on my paycheck.

I can appreciate GnuCash trying to adhere to general account practices
(GAP).  For example, as a long-time Quicken user, the "categories
aren't categories; they're accounts" philosophy was a big difference.
But I pondered it, and it makes sense.  I'm willing to change.

However, I don't think GnuCash should force GAP upon me just for the
sake of GAP.  I want to order my splits in a manner which makes it
easier for me.  GnuCash should give me that option, rather than
forcing me to use the split order it thinks best adheres to GAP (but
which I find to be significantly inconvenient).

Could this feature (a "use the split order I've entered" option) be
added in a future version of GnuCash?

On 2003-02-21 at 10:03:31-0500 plussier at mindspring.com wrote:

> > What is GnuCash's equivalent of Quicken's "adjust split total"
> > button?
> 
> AFAIK, you just hit Enter, and if it's unbalanced, GnuCash will pop
> up a window asking what you want to do.  One of the choices is to
> allow GnuCash to balance the transaction.

But as far as I can tell, the only way it balances is by adding
another entry into the split.  I want a button that says "balance the
transaction by totaling up all of the splits, and then setting the
transaction amount to that total".

Or have I misunderstood the interface?

On 2003-02-21 at 10:03:31-0500 plussier at mindspring.com wrote:

> > In Quicken, when entering a transaction with splits, I find it
> > very handy to enter the total transaction amount first, before I
> > start entering splits; that way, if all of the splits total to the
> > amount I entered, I know I've gotten the splits correct.  In
> > GnuCash, however, I haven't found a way to edit the transaction
> > total directly; I can only change it via entering splits.  How do
> > I change it directly?
> 
> Ahm, has something drastic changed between 1.6.6 and 1.8.x?  I
> always enter the transaction total first, then add splits in in
> exactly the way you describe.

Perhaps I'm misunderstanding the interface, but I simply can't enter
the transaction total.  I *have* to do it in the split.

I'm using gnucash 1.8.1, which came with Red Hat Linux 8.0.94 (the
third "Phoebe" beta).  If this is a bug, let me know, and I'll
bugzilla it with Red Hat.

Regards,
James



More information about the gnucash-user mailing list