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".
Michael
>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
>indirection.
>
>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.
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
