WO2005015460A1 - Mutable general ledger account structure - Google Patents

Abstract

A computer program product and method for representing a general ledger account. The data structure includes an account type table, an account table, a segment type table, a segment table, and an association table (Fig 1A). The account type table includes account type identification and an associated account type name (Fig 1B). The account table includes account identification and an associated account type identification from the account type table (Fig 1C). The segment type table includes one or more segment type identification and an associated segment type name, display position, status, length, and account type identification from the account type table (Fig 1D). The segment table includes one or more segment identification and an associated segment value and segment type identification from the segment type table (Fig 1E). The association table includes an association between the segment identification from the segment table and account identification from the account table (Fig 1A).

Description

MUTABLE GENERAL LEDGER ACCOUNT STRUCTURE

PRIORITY CLAIM This application claims priority from Provisional Application Ser. Nos. 60/375,192

(Our Ref: FXAG.1.1001) and 60/375,202 (Our Ref: FXAG.1.1002) both of which were filed April 22, 2002, and are hereby incorporated by reference. FIELD OF THE INVENTION This invention relates generally to general ledger software systems. BACKGROUND OF INVENTION A significant business problem exists for defining charts of accounts for business, government, and non-profit organizations. For conventional accounting information systems, the general ledger account structure must be chosen and fixed before the chart of accounts can be populated. (The account structure consists of a string of primarily numeric characters which is subdivided into segments. Each segment has a fixed starting position and a fixed length.) After financial transactions have been created, the structure of the general ledger account for these transactions cannot be changed. This inability to change account structure is a particularly challenging problem for rapidly growing organizations whose business needs are changing. Currently, the only solution is to redefine the chart of accounts periodically to provide the additional required information content to the management of the organization. This either (1) creates a discontinuity between fiscal years for comparative purposes, or (2) requires a significant onetime software engineering effort to convert data from the old general ledger account structure to the new structure. Such conversions create major concerns for data integrity, system availability, and system reliability. In case (2) above, data conversion is often beyond the means of a rapidly growing business because software development resources are scarce and expensive. Also, significant business risk is involved because the data conversion might not be 100% successful. Finally, software development resources are often needed to support the direct line of business. The typical financial application handles only data. As far as the application is concerned, the structure is hard coded at compile time, the application is programmed about the hard coded structure, and then at run time the structure can be populated, but cannot be changed without tearing into the application programming. Most chart of account systems rely on a fixed number of segments and often a fixed field length for each segment. The example described below is one of the more elegant versions of the current architecture. They allow the user to create variable number of segments of variable length. However, they require that the defined structure be "frozen" and thus becomes "fixed" once it has been defined. While the user may make changes to the structure, it cannot be done on-the-fly, nor can it be done without significant complications. Again, with our system, it can be changed on-the-fly and existing data remains consistent with the new structure. The following text is from the Oracle Financials Handbook: "It is also difficult to change your Accounting Flexfield after it has been frozen and has been used to capture data through transaction processing. Changing your structures after-the-fact may create data inconsistencies that could impact the behavior of your application or require a complex conversion program. As soon as you are satisfied, freeze your Accounting Flexfield structure to prohibit unnecessary modifications. You must freeze and compile your flexfield definition before you use your flexfield." The following illustrates an example of the above identified problem. FIGURES 1 A- E illustrate a conventional model. Four tables represent a basic conventional model. The GLAccountType table is metadata that represents all segment types of each chart of accounts. The relative position of each segment type in a table defines the chart of accounts format. The GLSegmentType table, which represents metadata, constrains each segment type. The GLSegmentType table defines the name and each segment type length. The GLAccount table is data that represents each entry in the chart of accounts. The value of each segment occurs in the defined relative position for each segment type. The GLSegment table constrains each segment value, which is the data value of each segment. The database cannot enforce the constraints and therefore the application must enforce them. Therefore, there exists a need for easily adaptable general ledger accounting software where adaptability is not performed through complex changes in the application program. SUMMARY The present invention provides a computer program product that includes a data structure for representing a general ledger account. The data structure includes an account type table, an account table, a segment type table, a segment table, and an association table. The account type table includes one or more account type identification and an associated account type name, wherein one of the account type names is primary account. The account table includes one or more account identification and an associated account type identification from the account type table. The segment type table includes one or more segment type identification and an associated segment type name, display position, status, length, and account type identification from the account type table. The segment table includes one or more segment identification and an associated segment value and segment type identification from the segment type table. The association table includes an association between the segment identification from the segment table and account identification from the account table. In accordance with another embodiment of the present invention, the computer program product includes a graphical user interface (GUI). The GUI allows for entering an account type into the data structure, for entering a segment into the data structure, and for changing display positions in the segment type table. The graphical user interface component further allows for deactivating a segment, changing the size of a segment, and changing the segment value in the segment table. BRIEF DESCRIPTION OF THE DRAWINGS The preferred and alternative embodiments of the present invention are described in detail below with reference to the following drawings. FIGURE 1A-E are pictorial representations of a prior art database model for a general ledger account structure; FIGURE 2 is a pictorial representation of a structural database model for a general ledger account structure formed in accordance with the present invention; FIGURES 3-7 are tables that represent the structural database model shown in FIGURE 2; FIGURES 8-11, 13, 14, 18, 20, 21, and 23 are example graphical user interfaces formed in accordance with the present invention for interacting with the database model; and FIGURES 12, 15-17, 19, and 22 are tables that illustrate the actions performed in the graphical user interfaces. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT As shown in FIGURE 2, the present invention is a database model 40 for a general ledger account. In the model 40, a GLAccount is comprised of an arbitrary number of GLSegments. GLSegmentType describes each GLSegment. Each GLSegmentType and GLAccount has a GLAccountType. GLAccountType indicates how an account is used, e.g., recording transactions for actual events, budgeting, or consolidation. GLSegmentType defines each segment of the multipartite GL account, e.g., company, department, and account. GLSegment stores the segment number and title, e.g., "4420.10 Salary Expense." GLAccount and the many-to-many relationship between GLAccount and GLSegment assemble the segment numbers and titles into a single complete GL account. A common occurrence in Chart of Accounts reorganizations is the addition of a new account segment. This example shows the contents of the tables shown in FIGURE 2 before and after addition of a segment. The account in the "before" case consists of a company and an account segment. In the "after" case, it consists of company, department, and account. This simple example demonstrates that none of the extant data in the tables GLAccount, GLSegment, and GLAccountSegment is altered for this reorganization. Only the metadata in GLSegmentType is changed.

"Before" Case: Company-Account

GLAccount

"After" Case: Company-Department-Account Changes are underlined and italicized.

GLSegmentType Note that the second row in this table is the only change to a record that exists in the "Before" case; and that this table contains metadata, not the fundamental transactional data of an enterprise.

GLSe ment

GLAccount

As shown in FIGURES 3-7, five tables (stored in memory) represent the database model 40. As shown in FIGURE 3, a GLAccountType table 60 includes metadata that represents each chart of accounts. The GLAccountType table 60 includes a glAccountTypeED column and a glAccountType/Name column. One of the items in the glAccountType ID column is identified as a primary chart of accounts. Any number of alternate charts of accounts are also present in the GLAccountType table 60. As shown in FIGURE 4, a GLAccount table 70 is data that represents the chart of accounts. The GLAccount table 70 includes a glAccountID column and a glAccountTypelD column. As shown in FIGURE 5, a GLSegmentType table 80 is metadata that represents each segment type of a chart of accounts. The GLSegmentType table 80 includes a glSegmentType ID column, a glSegmentTypeName column, a displayPosition column, a status column, a maxLength column, and a glAccountTypelD column. There could be any number of segment types in the GLSegmentType table 80, such as company, department, project, program, product, etc. Each chart of accounts represents segments in any order. Each chart can have different segment types. The GLSegmentType table 80 allows the user to change the number, order, and length of segment types that make up each chart of accounts. The GLSegmentType table 80 also allows a segment to be active or inactive. As shown in FIGURE 6, a GLSegment table 90 includes the value of each segment. The GLSegment table 90 includes a glSegmentlD column, a glSegmentValue column, and a glSegmentTypeLD column. As shown in FIGURE 7, a GLAccount_GLSegment association table 100 represents the relationship between the GLAccount table 70 and the GLSegment table 90. The GLAccount_GLSegment table 100 includes a glAccountID column and a glSegmentlD column. FIGURES 8-11, 13, 14, 18, 20, 21, and 23 illustrate exemplary Graphical User

Interfaces (GUIs) and various database structural functions that can be performed using the GUIs. As shown in FIGURE 8, the GUI is a window 200 that includes the following alterable fields: General Ledger Account Type field 208; Segment Type field 210; Display Position field 212; and Maximum Length field 214. The entries in the fields corresponds to storage locations in one or more of the above described tables. The window 200 also includes Active/Inactive status selection fields 220, and Save, Cancel, and Edit buttons. The General Ledger Account Type field 208 and the Segment Type field 210 are pull-down menus that allow the user to select from predefined lists of associated entries or create new entries. Changing the order of segments: In one example, a company (user) has set up an order (display order) of chart of account segments as follows: Company: Account: Department: Project The user decides that the following order would make it easier to report on the chart using a new generic report writer: Company: Department: Account: Project In order accomplish this change, the user simply changes the relative display position values in the Display Position fields 212 in the Account segment Type window 200 and a Department segment Type window 240 (FIGURE 9). The Display Position field 212 of the Account segment type window 200 is changed from 2 to 3 (FIGURES 8, 10) and the Display Position field 212 of the Department segment type window 240 is changed from 3 to 2 (FIGURES 9,11). As shown in FIGURE 12, the change that occurred in FIGURES 10 and 11 is illustrated in the GLSegmentType table 80. Add a new segment (record): In one embodiment, a company has grown and decided to add a product segment to the chart of accounts in order to track detail by product. The user adds a new record to the General Ledger Segment Type table called "Product" using the GUI window 200. The order of the chart of accounts now becomes: Company: Department: Account: Project: Product FIGURE 13 illustrates a GUI window 280 before the addition of a new record. FIGURE 14 illustrates the GUI window 290 after the addition of a record of a Segment Type Product with Display Position equal to 5. The Active status is marked and an arbitrary Maximum Length value is inserted. As shown in FIGURES 15-17, new records are entered into the bottom rows of the GLSegmentType table 80, the GLSegment table 90 and the GLAccount_GLSegment association table 100. Remove a segment type: In another embodiment, the company decides the use of the product segment has become too cumbersome and wants to suspend use. The user marks the product segment type as inactive using Active/Inactive status selection fields 220 (See FIGURE 18). The status field is changed in the GLSegment table 80 as shown in FIGURE 19. The order of the chart of accounts now is as follows: Company: Account: Department: Project Change the size of a segment field The company realizes that their department identifier length is too short (Maximum Length field 214) and they need to expand the field and change all the department codes. As shown in FIGURES 20 and 21, the user changes the maximum length value in the Maximum Length field 214. The change in length is reflected in the GLSegment table 80, as shown in FIGURE 22. Change the value of a segment The company decides to reorganize the order of departments and wants to change the department numbers throughout the organization. As shown in FIGURE 23, a General Ledger Segments window 360 allows a user to change the segment value of affected segments in a Segment Value 'field 370. The General Ledger Segments window 360 also includes a General Ledger Account Type pull-down field 372, a Segment Type pull-down field 374, a Segment Description field 380, and Status field section 390 that allows selection of Active, Inactive, or Report. The window 360 also includes Save, Cancel, and Exit buttons. The changes performed in the window 360 are reflected in one or more of the corresponding tables. While the preferred embodiment of the invention has been illustrated and described, as noted above, many changes can be made without departing from the spirit and scope of the invention. Accordingly, the scope of the invention is not limited by the disclosure of the preferred embodiment. By way of example and not limitation, in one alternate embodiment, this invention can be used in conjunction with the invention described in our co-pending application entitled FOOD TRACING AND TRACKING SYSTEM AND METHOD (Serial number not yet assigned) filed on April 22, 2003, and which is hereby incorporated by reference.

Claims

The embodiments of the invention in which an exclusive property or privilege is claimed are defined as follows:

1. A computer program product comprising a data structure for representing a general ledger account, the data structure comprising: an account type table including one or more account type identification; an account table including one or more account identification and an associated account type identification from the account type table; a segment type table including one or more segment type identification and account type identification from the account type table; a segment table including one or more segment identification and segment type identification from the segment type table; and an association table including an association between the segment identification from the segment table and account identification from the account table.

2. The computer program product of Claim 1 , further comprising: a graphical user interface component comprising: a first component for entering a segment into the data structure; and a second component for changing display positions in the segment type table.

3. The computer program product of Claim 2, wherein the first component includes one or more of the following fields: an account type field, a segment type field, a display position field, one or more length fields; and a status selection component.

4. The computer program product of Claim 2, wherein the graphical user interface component further comprises a third component for deactivating a segment.

5. The computer program product of Claim 2, wherein the graphical user interface component further comprises a third component for changing the size of a segment.

6. The computer program product of Claim 2, wherein the graphical user interface component further comprises a third component for changing the segment value in the segment table.

7. A method for representing a general ledger account, the method comprising: storing an account type table including one or more account type identification; storing an account table including one or more account identification and an associated account type identification from the account type table; storing a segment type table including one or more segment type identification and account type identification from the account type table; storing a segment table including one or more segment identification and segment type identification from the segment type table; and storing an association table including an association between the segment identification from the segment table and account identification from the account table.

8. The method of Claim 7, further comprising: entering a segment into the data structure using a graphical user interface; and changing display positions in the segment type table using the graphical user interface.

9. The method of Claim 8, wherein the graphical user interface includes an account type field, a segment type field, a display position field, one or more length fields, and a status selection component.

10. The method of Claim 8, further comprising deactivating a segment using the graphical user interface.

11. The method of Claim 8, further comprising changing the size of a segment using the graphical user interface.

12. The method of Claim 8, further comprising changing the segment value in the segment table using the graphical user interface.