File store (was Re: Salutations)

[Christopher Browne]

On Tue, 12 Dec 2000 12:49:22 EST, the world broke into rejoicing as
David Merrill <dmerrill@lupercalia.net>  said:
> On Tue, Dec 12, 2000 at 12:35:45PM -0500, Derek Atkins wrote:
> > David Merrill <dmerrill@lupercalia.net> writes:
> > 
> > [snip]
> > 
> > > But I do take issue with the argument that period closing, and the
> > > transfer of the account balance, is the way to accomplish this. It is
> > > certainly one way, but there are others. Let me propose one other way
> > > for your consideration.
> > > 
> > > Let's say we have a table that looks like:
> > > 
> > > account_num
> > > date
> > > closing_balance
> > > 
> > > Each record represents the end-of-the-day balance for the given
> > > account on the given date, which means the balance after all
> > > transactions for that day have been calculated.
> > > 
> > [snip]
> > >
> > > Does this accomplish the same thing you were proposing? Am I
> > > understanding your intent now?
> > 
> > Unfortunately I'm not convinced it completely solves the problem.  The
> > problem with any checkpointing is that if any transaction changes
> > before the checkpoint, then you have to modify all checkpoints that
> > have occurred after the transaction.
> > 
> > The nice side-effect of "closing the books" is that theoretically all
> > transactions dated prior to the closing are considered 'immutable.'
> > Perhaps this is just a different type of checkpoint?  I'm not sure.
> > 
> > If we do have the ability to make transactions prior to a particular
> > date 'immutable', then we only have to worry about checkpoint
> > consistency for dates after that date.  Perhaps we need the notion of
> > 'closing the books', whereby transactions become immutable, and
> > 'checkpointing', where transactions are still mutable so the
> > checkpoints may change as transactions get updated.
> 
> aisb, I consider the issue of closing the books and making all
> transactions prior to that immutable to be completely orthogonal to how
> the running total is determined. I am proposing a solution to the
> maintenance of running balances that scales well.

I would read it the same way, and figure the approach is 
at least _interesting_.  It may be expensive to maintain the
balances; the approach you suggest should keep the cost down
at least somewhat.

> Maybe I'm going off on a tangent, but I'm thinking in terms of db
> schema, since that is the task I've taken on myself.
> 
> I don't have an opinion on whether or not to close the books because
> I'm too ignorant about accounting practice. I have two semesters of
> college accounting, so I know basic concepts but that's it. I can say
> on my own account (tee hee!) that I scored top of my class in those
> classes, but that does not an accountant make.

I have an auditing text lying around; it talks not at all
about 'closing the books,' but devotes considerable text to
the subject of "cutoff," where the issue is to ensure that
transactions are recorded in the proper period.

In the payroll system at work, what gets locked, _every pay period_, are
the employees being processed at any given time. And, by the way, once a
payroll run is processed, the values are _all_ locked, so that the only
option you _ever_ have is to put together adjusting entries dated today.

It is common for accounting systems to lock everything dated in prior years,
although there's the notion of a "Prior Period Adjustment" that is
permitted to be used to go back to adjust past errors, which sort of
mandates that there's _some_ way to affect past years.

Another interesting option I've seen is when things are locked by
"period," there are a set of "ordinary periods," such as the 12 months
in a year, and then 13th "stub period," which might _never_ get closed,
that provides the window for those special adjusting entries required
to accrue stuff at the end of the year.

What these three examples add up to is to imply that while there are
some fairly common policies, such as "closing" old periods, the rules
are reasonably malleable to cope with the variations between different
sorts of businesses.  And it is likely that the way software is set
up will conform to some combination of:
  a) The preferences or prejudices of the authors, and
  b) The requirement to discard data in the system because
     of limited disk space and policies concerning relevant
     legal requirements to retain data.

The design for GnuCash should probably try to remain somewhat
flexible to allow for the fact that different users' needs will
vary somewhat.  

That means sitting in the somewhat uncomfortable seat named "No, we're
not assuming that there is a Single Fixed Set of Accounting Doctrines."
[Which, if you see the size of wall covered by AICPA and FASB standards,
not to mention the accounting organizations of nations other than the
US, would represent a pretty big "set." :-).]
--
(concatenate 'string "cbbrowne" "@ntlug.org") <http://www.hex.net/~cbbrowne/>
Rules of  the Evil Overlord #134. "If  I am escaping in  a large truck
and the hero is pursuing me in  a small Italian sports car, I will not
wait for the hero to pull up along side of me and try to force him off
the road  as he attempts to climb  aboard. Instead I will  slam on the
brakes  when he's  directly behind  me.  (A  rudimentary  knowledge of
physics can prove quite useful.)" <http://www.eviloverlord.com/>