IBM's San Francisco project

The frameworks have three layers. The lowest layer, or base, provides a distributed object environment that runs on multiplatform networks. Above the base is the common business objects layer. These business objects are commonly used in a variety of applications, and they also facilitate interoperability between applications. The top layer of the frameworks is the core business processes layer, which provides the basic and default business logic for various "vertical" domains, such as general ledger, accounts payable, accounts receivable, warehouse management, order management, etc. Applications can be built on top of the core business processes, fleshing them out into complete applications, or they can be built directly on top of the common business objects layer or the base.

General ledger

Financial transactions are initially recorded chronologically in a journal, listing each of the accounts involved and the change in value that occurred for each of those accounts, plus additional information describing the transaction. All transactions satisfy the constraint that any change in the total value of assets is matched by a corresponding change in the total value of liabilities and owners' equity, thus keeping the system balanced and giving rise to the convention of double-entry bookkeeping. Various types of commonly recurring transactions are typically handled by specialized journals that streamline the record keeping for the given type of transaction. Examples include special journals for cash, accounts receivable, accounts payable, fixed assets, payroll, etc.

A ledger shows a list of accounts and the value changes that occurred in each account. All transactions appearing in a ledger were first recorded in a journal. The ledger containing the accounts appearing in the balance sheet and income statement is called the general ledger.

A general ledger system is the portion of an AIS that handles the chart of accounts, the general ledger, and a basic set of journals. Specialized journals and subsidiary ledgers are typically handled by other applications within the AIS, such as those for accounts payable, accounts receivable, payroll, etc., and these applications periodically transmit to the general ledger system summaries of the financial data that they maintain. The general ledger system, then, is the one place where all of the financial data of the enterprise are represented, at least in summary form.

In complex organizations, the general ledger system is relied on not only as a provider of a standard set of financial reports, but also as a tool that allows the financial data to be used for various analyses of the enterprise and its operations. Questions such as those regarding operating efficiency, product costing, etc., often require various segments of the historical financial data for their answer, giving the general ledger system a very important role in supporting the management of the enterprise.

Improving the model

Starting as early as the 1960s, accounting researchers have been seeking ways to use computers to extend "the conventional accounting model to accommodate a broader spectrum of management information needs" and "to rethink some of the basic constructs of traditional double-entry bookkeeping." [2] Researchers recognized the need to have data that supported a wider variety of decision models and were free of the layer of interpretation imposed by conventional accounting. [3]

Research on extended accounting models has focused heavily on events accounting, introduced by Ijiri [4] and Sorter. [3] Amer et al. [5] state that events accounting research resulting from Sorter is the largest single body of research in the AIS discipline. Research in object-oriented AIS (OOAIS) is also focused on events accounting. Many of the highlights of this research are traced by Adamson and Dilts. [6] The gist has been to find a system that models an enterprise and its operations rather than merely modeling the artifacts of accounting. What kind of sculptor would create a three-dimensional likeness of a two-dimensional portrait, rather than of the real person? Accounting researchers are hoping AISs will eventually model the enterprise directly instead of merely modeling it through the conventional accounting model.

Integration of events accounting with traditional AISs has progressed through a number of modeling approaches. First was data modeling from hierarchical [7] and relational [8] standpoints. Then came entity-relationship modeling [9] and finally object modeling. [10-14] Along the way, McCarthy [15] proposed a generalized accounting framework called the REA (resources, events, and agents) accounting model, where activities are modeled in terms of economic resources, economic events, and "inside" and "outside" economic agents. [16] The collection of event/resource/agent tuples, such as implemented in the prototype by Kandelin and Lin, [17] directly models all varieties of the tangible components of the enterprise and its operations without stripping away information that does not fit in conventional accounting models.

An events accounting system must still provide many of the outputs of a conventional accounting system, including reports showing figures that comply with generally accepted accounting principles, but this information must be derived from the events-oriented data while at the same time preserving those data for many other uses.

In examining a hierarchy of enterprise information systems, McCarthy et al. [18] point out that economic tracking systems need to be supplemented by an organizing rationale. For traditional accounting systems that rationale is the equation, "assets = liabilities + owners' equity." What is more desirable, however, is a model centered around the "chain" of value creation within the enterprise. Separated accounting, manufacturing, distribution, and marketing applications, with minimal integration between them, impede this view.

Activity-based costing (ABC) and activity-based management (ABM) conventions [19] mitigate some of the distorting effects that traditional transaction tracking and costing schemes have on enterprise models, but they lack full value-chain organization and analysis. Some enterprise resource planning (ERP) systems contain enterprise value-chain models but are monolithic and inflexible. [18]

Commercially available AISs are, for the most part, based on relational database technology. In some cases, a move to OOAISs is underway. Business objects are needed in order to implement an enterprise value-chain perspective that can be easily adapted to individual enterprises and their various ways of doing business.

The San Francisco frameworks supply the basic business objects and the distributed object environment required to support them. The San Francisco general ledger core business process provides the basis for a general ledger system that can be much more flexible and adaptable in modeling an enterprise from a value-chain perspective. These features will be illustrated by examining the new levels of flexibility found in the San Francisco chart of accounts, and also by examining how financial transaction data are modeled when they are associated with some of the nonfinancial data that are part of the enterprise model. The San Francisco chart of accounts is especially interesting because of its ability to be defined in reference to other business objects within the model.

The chart of accounts

The basic idea of a chart of accounts is very simple. Table 1 shows an example of a simple chart of accounts. It is simply a list of accounts, each identified by an account code, which is sometimes referred to as the account number. For much of the processing in an accounting system, no further structure is required. Using RDB technology, this structure is easily implemented with an account table using the account code as the primary key. The account code is represented as a character string of a limited length. Some accounting systems for small operations allow as few as four digits or characters in the account code. Figure 1 shows a relational schema for account and transaction tables under this approach.

Figure 1

Even for small operations, the structure of the chart of accounts is more than a flat list. The accounts are grouped into the categories of assets, liabilities, equity, revenues, and expenses. They are often further subdivided into smaller categories at different levels of detail. The structure is really a hierarchy, even though the system, for the most part, sees it as a flat list. The hierarchy may be reflected merely in the values of the account codes, with account codes having the same prefix being in the same group. Summary or heading accounts are also included. The reporting system then uses these cues to reflect the account hierarchy in printed output.

Larger operations require charts of accounts with more accounts, more categories, and more levels in the hierarchy, resulting in the need for longer account codes. Eventually account codes become so long that segmentation is desired. An account code might be broken up into three segments, one for a company code, one for a cost center code, and the last for an account number. Each of these segments might allow its own hierarchy of values. Figure 2 shows a relational schema for this approach. Segmentation not only makes long account codes easier to handle for the user, but also allows certain segments--those for company code, for example--to be validated against other data in the system, such as the list of companies.

Figure 2

Two problems arise at this point with respect to RDB technology: code lengths and differing segmentation requirements. Field lengths in general are a problem with standard RDB technology. All fields, such as account codes or account code segments, must have a uniform length and that length must be large enough for the longest value to be stored. In cases where most values will be relatively short but some will be very long, a great deal of space will be wasted. When designing a packaged business application, the field length must satisfy not only a single enterprise, but all the enterprises in the targeted market.

With object technology, however, field lengths are not an issue. Different objects can have different lengths for a given value without producing a lot of empty space. Although with RDB technology there are ways to ameliorate the field length issue, this is an example of something that is easy with object technology but very difficult with RDB technology.

Even with an issue as trivial as field lengths, object technology provides a benefit that affects end users. When implementing an object-oriented system, it is no longer necessary to agonize over the absolute maximum length that will be required for a given field, nor is there any fear of eventually encountering data that must be entered into the system but will not fit inside the maximum field length.

The second problem that arises with RDB technology is the problem of differing segmentation requirements. One company might want account codes divided into three segments. Another company might want four segments, or three segments but with lengths different from those of the first company. Some accounting applications have predefined segmentation: a fixed number of segments with predetermined lengths for each segment. An enterprise already using a different segmentation scheme would have to either change its system account codes or do extensive customization of the accounting application.

A more advanced implementation of account code segmentation allows the segmentation to be user-defined. The user can determine the number of segments and the length of each. Figure 3 shows a relational schema of the account, transaction, and segment tables using this approach. The last table simply contains a list of segment lengths that define how the account codes stored in the account and transaction tables are segmented. All account codes are segmented in the same way.

Figure 3

Even with user-defined segmentation, existing implementations require that the same segmentation scheme be used for all accounts. It may be desirable, however, for different accounts to have different segmentation. The sales division of a company, for example, may want to use account segments to track sales by product, region, and vertical market segment, while the manufacturing division may want to track certain expenses by plant and production unit. Rather than try to define a fixed segmentation scheme that satisfies such varied requirements, it is better to vary the segmentation by account.

Figure 4 shows a diagram for an account table, a transaction table, and an account code segment table in which each account can have its own segmentation scheme. One of the penalties for this is that the account code no longer serves as a key in the tables. Instead, a surrogate key is required, referred to as the account key in this case. The surrogate key, unknown to the user, is created "behind the scenes" by the system as a way to tie an account to its variable number of account code segments. The surrogate key is used in the account and transaction tables in place of the account code, and in the account code segment table it is used along with segment numbers to index the various segments of the account code. At this point, however, the account information is no longer accessible by the account code using conventional querying methods, since the account code now occupies several rows in the table that links it to the surrogate key. Thus RDB technology cannot support a fully flexible account code structure without sacrificing the account code as a convenient means of accessing account data.

Figure 4

The San Francisco implementation. These requirements for flexible account segmentation can be satisfied easily using objects, and this is the case under the San Francisco general ledger core business process. Using San Francisco terminology, accounts are identified by posting combinations, representing the account codes discussed previously. A posting combination consists of a set of analysis codes, where each analysis code represents a segment of the account code.

Analysis codes are drawn from various analysis groups. One analysis group might contain an analysis code for each company, another group for departments, another for products, another for regions, etc. There is no limitation on the character length of posting combinations or analysis codes, nor on the number of analysis codes in a posting combination. Figure 5 shows a portion of the class diagram for this approach. A chart of accounts holds a number of analysis codes and a number of posting combinations. Each analysis code belongs to only one analysis group, but may be part of more than one posting combination. Figure 6 shows a relational schema supporting this approach, but again, surrogate keys are required. While this degree of flexibility is very difficult to achieve using RDB technology, it is merely a straightforward use of object technology.

Figure 5 Figure 6

To satisfy differing needs between sales and manufacturing, under a San Francisco implementation analysis groups could be set up for products, regions, vertical market segments, plants, and production units. The analysis group for products would contain an analysis code for each product, and the other analysis groups would follow the same pattern. A sales transaction would post to an account with a posting combination that included the analysis code for the product sold, the analysis code for the region where it was sold, and the analysis code for the vertical market segment that was represented by the customer. Certain manufacturing expense transactions would post to an account with a posting combination that included an analysis code for the plant and one for the production unit. Sample values for analysis groups and analysis codes are shown in Table 2. These can be combined to make up the posting codes shown in Table 3. This degree of flexibility actually pushes the idea of account coding to the background and replaces it with the idea of freely tagging each transaction with whatever items of information are relevant for its classification.

The use of objects for account code segmentation provides a great deal more than flexible formatting. In this case, each segment stands for more than just a series of characters. It "knows" about the underlying object that is represented by the code. Consider, for example, the account code "010-23-400-3800," made up of several segments encoded as numbers. The first segment might be the company number, the second the cost center number, the third the analysis code for "sales," and the fourth the product number. On seeing the account code displayed, a user might from time to time need help in remembering what some of the numbers refer to. The user might recall that "23" refers to a cost center, but cannot remember which one. As for "3800," the user might not be able to recall whether it refers to a product number or a sales region. Ideally the user could point to the segment in question and get a full description of what the code represents and what group it is a part of.

With San Francisco this feature can easily be implemented using properties of the analysis group and analysis code objects. Analysis codes can maintain a link to the business objects that they represent, and the business objects can be defined to support a common interface for supplying descriptive information. Many of the San Francisco business object classes, such as Company, BusinessPartner, and Area, are extensions of the base class Describable, which means that they provide a string description of themselves in response to the getDescription( ) method call. In the example just described, the account may need to show additional company information, cost center information, or product information, yet it is not necessary for the account or the general ledger to have facilities for obtaining and displaying these different types of information. The account merely requests the information from the desired account code segment, and the logic for making this request is the same regardless of which of the code segments is involved.

Thus the general ledger can provide access to the information and functions of business objects that are represented by the account code segments without containing its own logic to handle these different classes of business objects. In fact, it will support new classes of business objects that are defined after the general ledger application is completed. The close linkage of account code segments to the business objects that they represent has the effect of identifying an account less in terms of an encoded account number and more in terms of the set of business objects with which it is associated.

The chart of accounts also benefits from some of the design patterns used by the frameworks. Design patterns are used extensively throughout the frameworks. Some of them, such as Abstract Factory, Proxy, Chain of Responsibility, and Command, are described by Gamma et al. [20] Other authors, such as Fowler [21] and Hay, [22] have defined business patterns especially useful for accounting, and the San Francisco project has done this as well. [23] An interesting example is the framework's implementation of summary accounts through the use of cached balances and the Keyables design pattern.

A cached balance is an account total that is always kept up to date (as opposed to requiring a query over the journals each time its value is desired). Groups of cached balances are stored in cached balance sets, and the set of all cached balance sets is the cached balance set collection. Cached balances are selected, either singly or in sets, through the use of keys. Keys can also be used in other contexts.

There are two kinds of keys: access keys and specification keys. An access key selects a single item; a specification key selects a group of items. Keys are defined to examine a specified list of attributes, referred to as "keyables," when making the selection. For cached balances, keys can be used to examine the analysis codes of the accounts that are associated with the balances. Access keys specify a specific value for each keyable, for example, warehouse "5" and product code "1234." Specification keys specify various types of ranges or sets of values for each keyable, for example, all warehouses and product codes 1000 to 1999. Thus summary totals can be obtained for virtually any grouping of accounts, and an overlapping set of hierarchies can be supported as well.

Thus in a San Francisco implementation, the chart of accounts, defined by its collections of analysis groups and analysis codes, has much greater flexibility for reflecting diverse structures and relationships within the enterprise. More importantly, it arises naturally as a set of groupings of the business objects within the information system.

Combined financial activities

First of all, while the general ledger application provides access to all of the financial data, those data are not available until the originating applications feed the data to the general ledger. Once the data are in the general ledger, they are redundant, since the data now reside both with the originating application and in the general ledger. Users wanting access to cross sections of financial data that cross the boundaries of these different applications must be cognizant of the timing of the flow of the data into the general ledger. Search criteria that rely on more information than is transferred to the general ledger cannot be used. Furthermore, the complexity of the system is increased because of the requirement to maintain consistency between redundant sets of data. It would be better to have all financial activities stored in a single location and accessible for use in the general ledger as well as in the applications focusing on certain types of activities. This would be difficult with RDB technology but straightforward with object technology.

RDB technology is oriented toward uniform data. All the items in a table must be described by the same set of columns. If two types of activities are represented by two different tables, each including columns for financial data, processing the financial data from each table would require two different procedures, or at least two different versions of the same procedure. With objects, however, the financial activities represented in a collection can be different, with each activity containing financial data plus any additional information required by its activity type. Processing the financial data from each activity can be done in the same way regardless of the activity type. Thus while RDB technology is strongly oriented toward uniformity, object technology supports diversity. Elements can be grouped that have similarities while at the same time having significant differences.

In San Francisco, the commonality of transactions is provided by the Journal and Dissection classes, where the term "dissection" refers to the association of a value with an account. One or more transactions are represented by a journal, and the journal contains a dissection object for each posting to an account. The Dissection class can be as specialized as desired, so that a dissection object can contain additional information about the particular transaction that is involved. Because its class is an extension of the Dissection class, it will still be usable as a simple dissection by the general ledger implementation.

As the trend continues from managing vertically to managing horizontally, [19] financial information needs to be freed from its vertical orientation. It needs to be grouped according to business activities and processes without first being stripped of its auxiliary information by a conventional general ledger system. Addressing this problem eventually leads not only to refinements of conventional accounting, but also to a new underlying accounting model.

Conclusion

Acknowledgments

*Trademark or registered trademark of International Business Machines Corporation.

Cited references

Accepted for publication January 6, 1998.