ArtInAppleS s.r.o.
Kremelska 13
P.O.Box 7
SK-840 06 Bratislava 46
Slovak Republic
amr@artinapples.sk (Augustin Mrazik) lte@artinapples.sk (Lukas Temer)
This has led to the design of a reusable abstract framework providing the general functionality of accounts and transactions. Since then, this framework had been specialized for particular problems.
The primary functionality of an account is the maintenance of its turnovers including their history and providing the actual balance of the account, i.e. summing the original balance and all turnovers.
Each account has a name, its symbol it the account classification and a variable symbol which is provided by the final application.
After opening the new account, it is capable of accepting credit or debit turnovers. All turnovers are booked on the account and they are frozen, i.e. they cannot be neither deleted nor modified anymore.
The actual balance is kept as a sum of the initial balance and all turnovers. Although the actual balance may be computed at any time, it is kept and updated upon every turnover in a separate variable (from efficiency reasons).
In the account system, the particular account represents no only its own state (own turnovers and balance), but also the total of all its sub-accounts. Particularly, at a certain level of relevance dependent on the application, in the hierarchy of the account system accounts on their owns are interesting down to a certain level; at this level, the accounts should already represent themselves INCLUDING their sub-accounts.
In this case we have a similar problem as counting the actual balance of an account from the turnovers. Although it is possible to compute the total balance of an account (including all sub-accounts) in the moment when it is needed, this might take a while or it might be even impossible (if the sub-accounts are distributed and not all of them accessible at the moment). Hence, for an account it is useful to inform its super-account about every turnover. The super-account would sum all turnovers of all its sub-accounts in a variable.
However, as we have mentioned in the example, in a distributed environment the super-account may not be available at the moment when it has to be informed about the change on the account. For this purpose, the account has keeps the balance of all not-yet reported turnovers. As soon as the connection to the super-account becomes available, the balance change is delegated to the super-account and the not-yet-reported-balance-change is reset. This is the push-update which is bottom-up.
With such functionality, the upper level accounts in the account system keep an almost up-to-date balance of their sub-accounts. This may be sufficient for immediate management decisions, but is definitely insufficient for accounting purposes. To get a very actual balance of all sub-accounts, a pull-update (top-down) may be performed; this causes all sub-accounts to be locked and their not-yet-reported-balance-change to be pulled up and reset to zero.
Accounts and the whole account system are being used for a period of time (e.g. the fiscal year). After this period, the accounts are closed ('books are closed'), balanced and, if necessary, new accounts are opened.
In our framework, the whole account system, or any of its sub-trees may be closed. Closing of a particular account means fixing the final balance and freezing the account, i.e. it is not capable of accommodating turnovers anymore. Also, closing an account causes creation of a new account with the same attributed (name, symbols ...) and initial balance equal to the final balance of the old account. The old and the new accounts are inked with each other, hence in the future it is possible to navigate from an account to its predecessor in one step (by direct pointer).
The new account has an immutable initial balance, its name may be modified, but symbols are immutable. The new account is not yet opened, i.e. it is nor capable of accepting turnovers. If a new account has sub-accounts (and they are not opened yet, as well), they may be deleted; upon such deletion their initial balance is accommodated by the parent account with appropriate notice in their name. New sub-accounts may be created from a new account (with zero initial balance).
To be capable of accommodating turnovers, the account has to be opened. Opening an account causes opening also all its sub-accounts. However, super-accounts may be still not-yet opened. For an opened account, its name cannot be modified anymore and sub-accounts cannot be deleted. However, new sub-accounts may be added at any time (with zero initial balance). Each accepted turnover is frozen (cannot be modified and cannot be deleted from the account).
An opened account may be closed. Closing an account causes closing also all sub-accounts. The rest had been described above.
For a new account system, i.e. with a new root account (just as for any new sub-tree), the structure may be modified quite freely (deleting sub-accounts or whole sub-trees, creating new ones). Upon such changes, the initial balances are moved in a correct way. This is the period when the account classification may be modified in a significant way.
During the main period - the deployment period of the account - the accounts are opened and the structure may by only extended (new sub-accounts).
At the end of its deployment period the account system is closed and ready for archiving, however, it creates a full clone of itself as new accounts, with delegating the closing balances to the new accounts as initial balances. All old and new accounts are being inter-linked, not only the whole account system.
An application of an account system can be useful only if transactions on it my be performed. In most applications, a transaction is not only a simple turnover on a sole account. For example, in the double-entry accounting every transaction has impact on at least two accounts.
Not only a single transaction may be quite complex, but a series of transactions may be needed to be viewed as a complex multi-transaction. For example, a particular turnover may be performed on one of a larger number of accounts, however, a great number of turnovers builds a complex transaction which may (or need) to be optimized by moving particular turnovers to other accounts.
Such functionality varies according on the particular application.
For the implementation we have been using ArtBASE ODBMS which supports long transactions with optimistic concurrency control, i.e. individual objects may be freely modified until the whole long transaction is either abandoned, or committed and published in the database.
We have seen the applications of the framework not only for purely financial and accounting applications, but also for other applications with similar functionality needed, however, with other nature of the turnovers (e.g. project management).
From all these reason we had decided not to implement "account transactions", but rather to enable a kind of open state to the process of booking a turnover on an account. So we have extended the accounts by pre-booked turnovers: they are already accepted by the account, but still they may be modified (the credit or debit amount, the comment, date etc.) or even deleted or moved to another account. Such pre-booked turnovers have the same impact on the balance and balance change notifications as booked turnovers, but every change of the pre-booked turnover causes the appropriate change notification, as well. In this way, complex transactions may be pre-booked turnover by turnover in the whole structure of the account system, their impact may be analyzed on the top-level account balances, changes may be done as long as needed and if accepted as a whole, all or some of the pre-booked turnovers may be definitely booked and frozen by their particular accounts. Using this functionality for "simple" accounting transactions (e.g. in the double-entry accounting) has to be defined by the application.
To support the planning of turnovers, we have extended each account by a "a kind of sub-account" keeping all planned turnovers for this particular account. This enables to use the application tools not only for browsing in the past, but also analyzing the estimated future of the account or account system.
Each of the planned turnovers has a date when it is expected to be booked (e.g. when an invoice for an order is expected to be paid). When this time comes (maybe a few days earlier or later) and the real turnover is being booked, the planned turnover has to be deleted from the plan. However, it would be a pity to delete such a valuable information - how much was expected to be compared with how much it really was, when it was expected versus when it really came. Even some plans have to be canceled (will be never realized) and some real turnovers come as a surprise (they have been never planned). Hence, the planned turnovers moved to a "history-of-the-plan sub-account" after being either realized or canceled. They are paired with their real counterparts: canceled plans and "surprising" real turnovers have no pair. This information may be used for analysis of the accuracy of the former plan for a certain period of time.
The Account Framework had been implemented in ArtGUIDE which is a kind of CASE system for VisualWorks. ArtGUIDE supports the development of a framework in three tiers:
As we have already mentioned, if database is needed, ArtBASE can be used with great advantage (due to its "Smalltalk-like way of thinking" - long transactions with optimistic concurrency control and full transparency, orthogonality and independence of the object persistence). See http://www.artinapples.sk for details (particularly, http://www.artinapples.sk/products/artbase/htmlguide/syd_conc.html).
So far, we have used the Account Framework for realty tax management system and for a property management system within an information system for a municipality and the town hall.
The Account Framework may be used without any change for simple cash and finance management, finance planning etc.
The major problem with using (and publishing) the Account Framework is the fact that ArtGUIDE is still only under VisualWorks 1.0. However, to use the code if reusable GUIs are not required should not cause great problems (it is only serious Smalltalk, with not tricks). A new implementation of ArtGUIDE for up-to-date VisualWorks release is planned for later this year.
ArtBASE is avaliable for all releases of Visualworks (see on our www).