Patent Application
20060190397
The present invention generally relates to computerized financial/accounting systems. More particularly, the present invention relates to utilizing supporting dimensions to further define transaction entities in a financial/accounting system.
Computerized financial systems and programs (i.e., software applications) are configured for use by both accountants and non-accountants. These systems allow users to set up various types of accounts such as general ledger, inventory, order entry, accounts receivable, accounts payable, bank manager, and payroll accounts. Each account, or account module, of the accounting system are typically fully integrated and share common data. As a result, a transaction can be entered, for example, as an invoice, and the accounting system automatically performs the necessary credits and debits on the affected accounts including posting the transaction to the general ledger without requiring the user to reenter any data. Thus, such computerized accounting systems are ideal tools for the non-accountant user. Additionally, they save time, reduce the likelihood of errors, and eliminate the need to reenter data for posting to the general ledger.
The general ledger maintains a list of posted transactions relating to all of the accounts of the system. As is well known for double entry bookkeeping systems, valid accounting transactions include a debit component and a credit component where the absolute value of the debit component is equal to the absolute value of the credit component. The general ledger module typically maintains the summary information of the transaction histories and balances for all of the accounts of the system, while the individual account modules maintain more detailed historical transaction data and balances for their respective accounts. In the general ledger module and the other account modules, individual entries or records relating to a transaction are, in general, referred to as transaction entities.
In a typical accounting system, in addition to an account number, date and an amount, a transaction entity usually includes information that further defines the entity. For example, a transaction entity for ticket sales at an event can include an event code and a visitor code (to further define the transaction entity) in addition to an event date, an account number, and an amount, which constitute the “core” of the transaction information. Valid event codes and visitor codes are predefined and stored in the financial system. Thus, a user entering ticket sales transactions is restricted to entering/selecting and saving only predefined event and visitor codes to further define the sales transactions. Such additional pieces of information or dimensions, that are predefined and selected on the transaction, are referred to as “standard” dimensions. Using only standard dimensions to further define transactions helps maintain data integrity within the financial system. However, such constraints do not allow a user to enter/track additional non-predefinable data, related to the transaction, such as a quantity (for example, in a ticket sales transaction, the number of people who attended a particular event), which may be useful for analytical purposes.
The present invention relates to a computer-implemented financial system that allows for account modules to be set up, and transaction data to be entered, stored and retrieved as transaction entities, with each transaction entity including an amount. The financial system further allows for supporting dimensions (dimensions that are entered and saved to the transaction only and that are not selected from a predefined dimension code list) to be utilized.
The present invention relates, in general, to financial systems that utilize dimensions to further define transaction entities. More specifically, the present invention relates to financial systems in which supporting dimensions (dimensions that are entered and saved to the transaction only and that are not selected from a predefined dimension code list) can be added to transactions to help categorize and track highly specific transaction activity with relative ease. However, before describing the present invention in greater detail, one illustrative embodiment in which the present invention can be used will be discussed.
The invention is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
The invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
With reference to
Computer 110 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 110 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computer 100. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier WAV or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, FR, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.
The system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132. A basic input/output system 133 (BIOS), containing the basic routines that help to transfer information between elements within computer 110, such as during start-up, is typically stored in ROM 131. RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120. By way of example, and not limitation,
The computer 110 may also include other removable/non-removable volatile/nonvolatile computer storage media. By way of example only,
The drives and their associated computer storage media discussed above and illustrated in
A user may enter commands and information into the computer 110 through input devices such as a keyboard 162, a microphone 163, and a pointing device 161, such as a mouse, trackball or touch pad. Other input devices (not shown) may include a joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 120 through a user input interface 160 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). A monitor 191 or other type of display device is also connected to the system bus 121 via an interface, such as a video interface 190. In addition to the monitor, computers may also include other peripheral output devices such as speakers 197 and printer 196, which may be connected through an output peripheral interface 195.
The computer 110 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 180. The remote computer 180 may be a personal computer, a hand-held device, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 110. The logical connections depicted in
When used in a LAN networking environment, the computer 110 is connected to the LAN 171 through a network interface or adapter 170. When used in a WAN networking environment, the computer 110 typically includes a modem 172 or other means for establishing communications over the WAN 173, such as the Internet. The modem 172, which may be internal or external, may be connected to the system bus 121 via the user-input interface 160, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 110, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation,
It should be noted that the present invention can be carried out on a computer system such as that described with respect to
Front-end tool 202 communicates with database 204 via interface 206. Interface 206, in general, is capable of translating generalized requests, update statements, etc., into database specific query/update statements, which typically include sequential query language (SQL) statements, that retrieve/update the necessary data stored in database 204. Interface 206 returns any data retrieved from database 204 to front-end tool 202.
Prior to discussing the present invention in greater detail, a brief discussion (with examples) of the differences between standard and supporting dimensions may be helpful. As mentioned earlier, standard dimensions have dimension codes, and are generally based on information about an enterprise such as departments and product lines. Supporting dimensions do not have dimension codes and are used to further describe an entity of a transaction. Supporting dimension information is not generally used in financial reports but is important for internal analysis. Tracking the attendance at events or entering the stock price for purchased stock are some examples of supporting dimensions.
As will be discussed in greater detail further below, in some embodiments of the present invention, valid combination rules or usage rules are used to determine when a supporting dimension is available for entry. The rules can also determine if the supporting dimension is required, optional or not allowed. It should be noted that the usage rules are optional and can be defined independently of accounts and account modules. Thus, supporting dimensions can be defined with or without usage rules and are typically defined and utilized independently of accounts and account modules. The following is a specific example that illustrates how supporting dimensions can be used in line items of an invoice prepared by a company that contracts out security and parking for events. Parking and security are billed per employee (quantity). For an event, the company wants to know how many vehicles were parked and what the attendance was for the event to help with future staffing needs for security and parking.
Assume the following:
Supporting Dimensions (No Codes):
Valid Event Codes
A first usage rule, requiring entry of a value for the Attendance (ATTD) supporting dimension if “Security” is entered as an invoice item, is defined. A second usage rule, requiring entry of a value for the Vehicle (VEH) supporting dimension if “Parking” is entered as an invoice item, is also defined. A value (restricted to the any one of the above predefined event codes) for the EVENT standard dimension is required when either “Parking” or “Security” is entered as an item. Example invoice items/transactions entered using the above combination or usage rules are shown below in Table 1.
As can be seen from the above example, any quantity can be entered as a value for the ATTD and the VEH supporting dimensions. However, as mentioned above, usage rules that allow or require entry of values for VEH only when “Parking” is entered as an item, and that allow or require entry of values for ATTD only when “Security” is entered as an item, are defined. Values for the EVENT standard dimension are restricted to the respective predefined codes.
Transaction entities (invoice line items, for example), such as those shown in Table 1 above, are stored in a financial system database (such as 204), which typically includes multiple tables for each account module.
Utilizing a screen such as 500, for the invoice item example provided earlier, enables a user to generate reports to show per event the number of vehicles and the attendance. Thus, using the present invention, analysis can be carried out to help with future staffing needs for security and parking, for example.
It should be noted that a supporting dimension can include a wide variety of things. A few examples include a quantity, string, date or even another currency value. Once a particular supporting dimension is defined, different software applications, internal or external to the financial system, can be granted access to query and/or update the supporting dimension.
Although the present invention has been described with reference to particular embodiments, workers skilled in the art will recognize that changes may be made in form and detail without departing from the spirit and scope of the invention. It should be noted that supporting dimensions are not necessarily restricted to being associated with only transaction data. Supporting dimensions can be associated, in general, with any business data or records such as master records, transaction data, etc., without departing from the scope and spirit of the present invention.
