On Fri, 28 Apr 2000, Bill Gribble wrote:
> Richard Wackerbarth <[EMAIL PROTECTED]> writes:
> > In the days of "pen and (red) ink", the accountants literally closed the
> > income/expense books and got a new book for the next period.
>
> "Closing books" is a feature that's on our "real soon" list. I think
> it goes a little beyond just transferring balances to equity; there
> are implications for editability (closed books can't be changed) and
> file storage (for data-security purposes, it makes sense to literally
> start over, with the old books in a separate file that can be archived
> as necessary).
>
> > It is perfectly valid to generate reports which cover any arbitrary
> > period of time. As an example, consider a company that starts its
> > fiscal year on March 1. They would close their books on Feb
> > 28/29. However you can reasonable generate a report for the calendar
> > year. That report would not want to include the closing entries.
>
> This is an important point. Whatever solution is arrived at for
> closing books, we have to preserve the ability to have read-only
> access to them for report generation. Even if periods don't "overlap"
> in the sense you describe, it makes sense to have access to arbitrary
> points of time in the past; how else would you generate a five-year
> sales growth chart?
Precisely. The important point I want to make is that "closing entries" must
be distinguishable from the others.
For example, throughout the period, we credit income (or did I get it
backwards?) for our sales. To close the income account, I debit it for the
current balance. If I am generating a report on income, I would not want to
include THAT debit. However I cannot exclude all debits because some of them
may reflect adjustments that must be included in income.
Closing access to the modification of data is a somewhat separate subject.
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
