Inventory and Accounting

Account

This pattern finds use in many fields, especially the banking industry;fields wherein it is necessary not only to record the current value of an entity, but also its history of changes that affect its value. An account, in some sense, is similar to a quantity, because, it also has a value. The main difference is that it has an added entry for every change to its value.

Examples:

Mr.Smith withdraws $1000 from his checking account. This is represented as an entry with amount $1000 attached to his checking account.
Joe buys 4 12-packs of coke from a shop. The shop represents thise shop represents this as an entry on their coke account with amount =4 12-packs.

By using the entries, a client can determine the changes over a period of time and the total amount of deposits or withdrawals. The sign on the amount indicates whther the entry is a deposit or a withdrawal. The figure indicates two timepoints for the entry: one indicates when the charge is made and the other when the entry is booked to the account. This is particularly important when retroactive charges occur. A price for a charge may have changed between the charge date and the booked date, so both are required. For example, consider the following example:
Joe buys grocery at Farmer's Store on January 5. The credit card company receives notice of payment on January 10. The former is the charged date while the latter is the booked date.
Now, let us assume that Joe failed to make the payment on time. For calculating the fine, the company might use the booked date, whereas for the actual charge of the item(i.e. groceries), the charge date is used. Also, the item's price might have changed between these dates. Hence, both the dates are required.

Transaction

Entries help keep a record of changes to an account. Transactions help further by linking a withdrawal from one account to a deposit in another. This double entry approach stems from the following principle:

Money(or anything that needs to be accounted) is never created or destroyed, it merely moves from one account to another.

The above figure implies that every transaction is associated with two entries. This may not be the case always. Let us consider the case where a person gets $1000 from one entity and $2000 from another entity. The person decides to deposit both the checks into his checking account. This situation can be represented clearly in multi-legged transactions or transactions with multiple entries. The model is the same as the previous one except that the upper bound on the number of entries per transaction has been increased to infinity:

Multi-legged transactions provide more flexibility than the two-legged model.

Example: Super Bank debits $5000 from its New York branch, and credits $2000 to Chicago branch, and $3000 to Memphis branch on the funds account. This is a single transaction with three entries: [account: New York, -$5000],[account: Chicago,$2000],[account: Memphis,$3000].

Summary Account

It is often useful to group accounts together. An account representing the domestic expenses, including individual accounts for groceries, air travel, etc is an example. The model to represent this information is a hierarchy of detail and summary accounts, as shown below:

As seen in the figure, a summary account can be composed of both summary and detail accounts, forming a hierarchy with detail accounts as leaves. The entries of a summary account are derived from the components entries recursively. Designers can easily identify this as an instance of the composite pattern[2]. Entries can be posted to only detail accounts. Summary accounts can still be treated as accounts because their entries are derived according to their components' entries.

Example: John has a summary account for business income consisting of the detail accounts for company income and agency income.

Memo Account

Memo accounts are typically used for maintaining tax accounts. A memo account behaves much like an account except that it contains amounts of money which is not real money. For example, consider a tax liability account. Each time we earn money, we allocate a portion of it to the tax liability account. Whenever we pay taxes, we make an entry in this account, apart from the entry for withdrawal from the actual tax account. By having this account, we can be prepared for out tax returns. Memo account is a subtype of account, so we need to ensure that transactions do not shift money between a memo account and other real accounts. This can be done by excluding memo accounts in the balance constraint. Actually, in some systems, it might make sense to post entries to summary accounts as well.

Posting Rule

We have seen many types of accounts, and now, we are going to look at how to specify the ways or rules for posting entries in some of the accounts on seeing an entry being made. For instance, a person might have a posting rule for her tax liability memo account , which says, post an entry whose amount is 30% of the entry made into the income account. Such posting rules could be modeled as follows:

A posting rule is described by specifying an account as a trigger. Any entry in the trigger account causes a new entry to be made, which is original entry's amount times the multiplier. The account to which the new entry is posted is referred to as the output.

Example: For the tax liability account mentioned above, we would have a posting rule with the income account as the trigger, the tax liability account as the output and 0.30 as the multiplier.

The above model handles some simple situations, but the posting rule is not always as simple as multiplying by a scalar. Continuing with the same tax example, we might have a graduated tax system for the income, like for the first $2000, 30% and for the rest, 40%.So, we want a posting rule to carry an arbitrary algorithm, which would give us the maximum flexibility. To give posting rules this flexibility, we have to link a calculation to each instance of posting rule, since every rule will have a different way of calculating the amount of the new entry. Conceptually this means that each instance of a posting rule needs to have its own calculation method as show below:

The above model is a perfect example wherein a model hides the implementation details, i.e. it is not restricted to a particular implementation. Actually, in most of the object-oriented languages, this is not possible. Behavior , in these languages, is allowed to vary only through polymorphism and inheritance, which is class-based. We want the behavior to vary with each instance. This is the individual instance methods pattern. One possible implementation is to use the Strategy pattern [2] solution. Consider the situation where each American state, having its own posting rule calculation. This could be modeled as:

(Here, PR denotes Posting Rule )

Until now, we have seen different methods for modelling the Posting Rule pattern. It is also important to know how the posting rules are fired. There are different approaches
to this, some of which are outlined below:

Eager Firing: In this approach, posting rules are fired as soon as a suitable entry is made in a trigger account. The firing is made by the transaction that posted the entry in the trigger account.
Account-based Firing: In this method, the responsibility of firing is moved from the transactions to the account. Entries are posted to an account without any posting rules being fired. At some point the account is told to process itself and then fire its posting rules for all the entries that have been posted since the last processing.
Posting-rule-based Firing: Here, the posting rule itself is explicitly told to execute by some external agent. This is similar to account-based firing except that an account might have several posting rulesand so the responsibility for deciding which entries have been processed passes from the account to the posting rule.
Backward-chained Firing: This is a modified approach of account-based firing. Instead of the accounts just processing themselves, they cause all their dependent accounts to process, which in turn trigger processing of their dependent accounts, and so on. So, a chain of processing activities takes place. The whole account dependency network (or graph) is brought up to date by simply asking the account at the root position to update itself.

Balance Sheet and Income Statement

It is useful to know the difference between balance sheet and income statement accounts, which is shown below:

If we consider a person, his checking account will be the asset account and his credit card account will be the liability account. They reflect the money he has (or doesn't have). These appear on the balance sheet. The person might have an income account for salary from employer, another income account for interest from savings, an expense account for food, another for traveling and so on. The balance on these accounts do not reflect any money the person has, but merely classifies where money comes from and goes to.

Banking Patterns Home Page If you have comments or suggestions, email us!