By: R.E. Johnson
Published in: PLoPD2
Category: Accounting, Transaction Processing
Summary: Business transaction processing systems cause master files of accounts to be updated. These patterns describe how these systems work and how to improve them.
Businesses need to prove that things are as they say they are, so they must turn everything into a transaction that can be recorded. The current state of a business should be apparent from the aggregate record.
You're using Business Transactions. Use different representations of transactions during processing from those for archival purposes. Don't archive transactions until you've finished all processing related to a business event, including rerunning it and generating management information.
Keep a set of accounts that track the current state of the business. State variables are attributes of the accounts.
Some transactions are composite transactions, so post a transaction to several accounts; e.g., a sales transaction might be posted to a sales system, an inventory system, and an accounts receivable system.
Never change a transaction once it has been posted. Instead, post an "adjustment" transaction.
Finalize all transactions in a month-end closing. If accounts are out of balance, then transactions can be adjusted to fix the problems. After a month-end closing, transactions for that month cannot be changed. Closings can also occur weekly, quarterly, or yearly.
Separate business rules from transaction-processing software and store them in a database. Each rule must have a specified time during which it is valid. This allows you to stop programming in terms of the implementation language and start programming in the language of the rules themselves.
Process all transactions when they are entered into the system. This includes posting them to accounts, updating the attributes of those accounts, and checking for any dependencies on the updated attributes.