MonthEndClosing makes it hard to get up-to-date data, 
since all data tends to be a month old.  
MonthEndClosing tends to hide all the mistakes in the 
data until the end of the month, and it is then hard
to find them because they are buried in so much data and 
because one mistake can mask the effects of another.

MonthEndClosing usually has a lot of programs for checking 
the consistency of data.  
We could duplicate them for everyday use, or we could
simulate month-end closing every day.  
Even better, we could change month-end closing.

'''Therefore,''' process all transactions completely as soon as they are
entered into the system.  This amounts to posting them to accounts,
updating the attributes of the accounts to which they were posted,
and then checking for any dependencies or actions that depend on the
attributes that are updated.

I wrote some programs at the Cornell Campus Store that would
simulate the checks of MonthEndClosing, and they had a dramatic
effect.  Problems would be spotted and solved
long before the end of the month.  This made MonthEndClosing
go much more smoothly than it had before.  It also helped me to
find some problems in my own code, and made me a lot more bold
about installing fixes, since I knew that errors that I made
would probably be caught by the checks that we were soon running
nightly.

Unfortunately, this duplicated a lot of checking jcode.
''Accounts'' avoids duplicating code by processing all 
transactions right away.
It only uses MonthEndClosing as a way of keeping people
from changing data.