RFC: A "book-close dialog" to help auto-zeroize all Inc/Exp accounts

Derek Atkins warlord at MIT.EDU
Mon Dec 24 13:36:30 EST 2007

Quoting Mike or Penny Novack <stepbystepfarm at mtdata.com>:

> The result you have is two transactions, one representing total 
> income and one representing total expenses. But the absolute 
> magnitude of these two amounts is of little interest while the 
> difference between them and especially the sense of that difference 
> is considered of paramount importance (oh the famous lines from 
> Dickens's "David Copperfield" say that so much better).

That's not necessarily true.  The difference between them is
certainly ONE piece of data that's of interest to users, but
I certainly want to be able to see the total income and total
expense for a year.  The CoA will perform that subtraction
for you if the Income Total and Expense Total accounts are
either a) the same, or b) siblings.  I completely disagree
that you need a third transaction.

Also, I should add that the implementation I committed last night
to trunk actually creates one transaction per currency, so if you
have multiple income/expense currencies it will make sure that
it doesn't mix them.

> So yes, your users can see whether the total income amount or the 
> total expenses amount is the greater and perhaps even do a rough 
> subtraction in their head BUT they probably would prefer a single 
> amount clearly labeled as a "gain" or "loss" for the year. Which is 
> why the traditional method was as it was (and from that temporary 
> account the "profit and loss" report easily produced).

I disagree.  That single amount can still be labeled as such
on the reports but by combining them in a single transaction
in the registers you effectively lose data, and it's data that
I dont want to throw away.

> Now equity accounts are "standing" accounts. Not entirely crazy for 
> the "close the books" function to require the existence of a named 
> equity account to be used for the closing process. The closing 
> function would then generate THREE (instead of two) transactions 
> (total income, total expenses, and gain (or loss) for the year).

As said above, no, it's only two transactions.  I don't understand
what you mean by "standing accounts".  Also, the function, as implemented,
doesn't require the account to exist a priori -- you can create it as
part of the closing process itself.

The alternative is to have the process auto-create an Equity account
on your behalf, but I consider that kind of thing generally rude to
the users.  I'll note, however, that it does auto-create sub-accounts
if you use multiple currencies.

> Michael
> PS: We (MA Chestnut Foundation) will probably agree to adopt GnuCash 
> at the January board meeting after I present my recommendation. After 
> which I presumably will become available to work on some of the 
> things desired. But also likely to at first be working on the special 
> report formats generally used by non-profits (we have so few 
> accounts/transactions that no big deal to close the books manually so 
> an autoclose not my highest priority).

Not a big deal -- I've already implemented it.  :-D

>    If I get involved, would have to be considered a "serious" 
> resource (retired senior analyst with a few decades experience 
> designing/writing/debugging financial business software).

Everyone is considered serious.  Supply good patches that follow the
standards and listen to the advice and suggestions given by the existing
developers and your patches will be given the same attention as all
the others.  On the other hand, if you come in with a chip on your
shoulder, "hey, I'm a retired senior analyst; I've been doing this forever.
I don't have to listen to you young whippersnappers" then expect to
get a very different response from us ;)

This is a meritocracy, but it's a closed meritocracy.  Prove your merit
by submitting good, clean, simple, straightforward patches that fit
into the existing framework and architectures.  Extend what's there
already instead of starting over.  Stuff like that.

I look forward to seeing your reports and other changes.


       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
       warlord at MIT.EDU                        PGP key available

More information about the gnucash-devel mailing list