Intro + a bug

Mike or Penny Novack stepbystepfarm at
Tue Aug 7 08:40:47 EDT 2007

Josh Sled wrote:

>The developer who started that work hasn't had a lot of time for GnuCash in
>the last few years.  I really hope he does respond, but I don't feel out of
>order responding on his behalf.
>There are two approaches to book closing:
Maybe stop right there. As soon as there appear to be difficulties with 
the "only" approaches step back one level of the process and maybe more 
alternatives will appear.

In other words, what must "close the books" DO. Let's consider what an 
accountant did when keeping books on paper to close the books.
1) Create a special "closing" equity account (name usually 
Income-Expense or Profit&Loss) and close all income and expense accounts 
into it (they now all have zero balances)
2) Close this account into "equity at start of new fiscal period" 
("equity at start of last period" + amount to close P&L)
3) Check that the standing accounts (asset and liability accounts) 
balance with this account.
4) Disallow any entries with dates prior to closing (but allow 
recreation of reports, allow closed accounts to be viewed, etc.)
The fact that normally (when using paper) might have been into a new 
physical book not really relevant, just that an effective "double line" 
has been drawn with all "temporary" accounts closed (all the income and 
expense accounts) and the standing accounts are in balance and that no 
alterations are allowed.

There should be no specification that this be "calendar year" ("fiscal 
year" might or might not coincide)
There may or may not be a "special date" for these entries that falls 
after the last date of the books being closed and before the first date 
of the new books.

Obviously users should "burn" a copy of the books before and after 
closing, but backup procedures are really outside the process except 
that I will revisit this when discussing the security of the closing 
process. Whether the "obsolete" accounts are deleted or not is again an 
additional feature. Personally I would prefer to leave them there, 
perhaps just make them "invisible" (have an income placeholder and an 
expense placeholder with names like "obsolete income" -- move them there 
and then not expand the view to hide them). You want the accountant to 
easily be able to answer questions like "how much did we pay for "tree 
guard" last year?" (a deer repellent, our organization grows trees) and 
this shouldn't require reloading from backup. I can't see how the 
decision whether obsolete can be other than manual. It's CHANGES to 
prior year entires that must be prevented. In our case (and this is not 
untypical) only sometimes would an income or expense account with the 
same name be used in the following accounting period, the majority would 
remain in use.

Because it is easy to underestimate the abilities of programmers to 
alter data in spite of whatever checks exist in the programs (they can 
do that OUTSIDE the control of the program), I would recommend that the 
process include at least the opportunity to make that "burn" to read 
only medium and to include a "compare/verify" function that given such a 
CD or DVD (and a date) could confirm that no entries prior to that date 
have been altered. In other words, to confirm that no entries have been 
made for a date prior to the previous closing. This function could be 
used whenever doubts arose that perhaps the entries for a prior period 
have been altered.

OK -- accountants reading this, what have I left out of the "close the 
books" process? (I am not an accountant). Consider all the "options" 
which would be good to include and what parameters these would require. 
With NO options at least "name of books to be closed" and 
"closing/reopening date" but might provide choices like "continue" vs 
"new books" (requires name/path). We might also want to perhaps enforce 
some of these choices (if "close the books" is to exist). Thus we might 
REQUIRE "new books" (starts out with all the accounts of the old, all 
temporary accounts zero balance, all standing accounts as they are at 
the start, no transactions prior to the date (for any account), but 
everything else copied exactly (doesn't this answer the "3" and "4" 
points below) and BTW, this does NOT eliminate the need for a "verify 
against read only copy".


>One approach has a structure either above or within the current top-level
>data structure of a "book".  This structure is probably an "archive" section
>that contains transaction/history information outside of the current
>financial period.  All of the rest of the application (file load/save; the
>UI, generally; reports; &c.) would need to be extended to support this
>Another approach would be more procedural, simply creating a new, standalone
>datafile for the new period.  While we already have the functionality to
>export the existing account hierarchy (only and alone), a welcome
>extension/variant of that export would probably also...
>1/ allow the user to "ignore" obsolete accounts that the user doesn't want to
>   carry forward...
>2/ create appropriate opening-balance Equity transactions for the rest of the
>   {Asset, Liability} accounts.
>3/ carry relevant commodities and price-db entries forward.
>4/ carry relevant (user-selectable) business items (customers,
>   vendors; unpaid invoices, &c.) forward.
>>I am not in a position to offer to "take over" since I can't make a long 
>>term commitment not to return to paid work should a tempting offer 
>>arrive* but at the moment have time available.
>Well-formed patches that improve the system are welcome regardless of
>long-term commitments.

There is no possibility of social justice on a dead planet except the equality of the grave.

More information about the gnucash-devel mailing list