Continuous Processing

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.