Patent Application
20110264565
One embodiment is directed generally to a computer system, and in particular to a financial computer system that records business transactions.
Many business organizations use integrated financial computer systems to track and calculate all kinds of transactions. These computer systems typically include a general ledger, and may include business objects such as cost centers that track costs that accumulate in the general ledger, and profit centers that track profits for the organization or a portion of the organization. One example of an integrated financial computer system is the “Oracle E-Business Suite Financials” from Oracle Corp.
Business organizations frequently reorganize. A reorganization generally is a management initiated realignment of enterprise or division resources to better address operational objectives. Since cost centers are typically the most detailed level at which the consumption of resources is measured and tracked, it is an obvious focus of reorganizations. A reorganization frequently results in the restructuring of reporting relationships within an enterprise without changes to the legal structure of the enterprise. Such restructuring may cause people, quota, budgets and organization hierarchy nodes to be reassigned to different cost centers or departments. Reorganizations vary in size and scope from reorganizations of teams within a single department to changes that impact many aspects of the organization, including operational and financial reporting hierarchies, accounting rules, payroll assignments, security rules, budgets, etc.
One embodiment is a financial computer system that, in response to receiving a business object to be changed, a change type, and a effective date of the change, identifies all first transactions directly associated with the business object and identifies all second transactions not directly associated with the business object but that may be posted to the business object in the future. The system then displays the first transactions and the second transactions in a user interface.
One embodiment is a financial computer system that determines which transactions are affected or will be affected in the event of a reorganization or other type of change to a cost center or department. Such transactions include those that are directly assigned to the changed cost center, as well as transactions that may potentially be assigned to the cost center in the future. A report is then generated listing all of the affected transactions.
During a typical business reorganization, many cost centers may need to be reassigned, or their meaning changed or end-dated (i.e., closed) so that general ledger transactions can no longer be posted to them. This can cause problems because there may be many different types of transactions that will be posting to this cost center in the future but are not currently associated with the cost center. In prior art financial systems, the person that is maintaining the cost center definitions in the chart of accounts typically does not have easily obtainable visibility to these transactions. Instead, finding all of the impacts of a reorganization in prior known systems is typically a tedious and manual process where information must be queried from many different places and consolidated manually in order to have visibility to all impacted transactions across the business. Feedback is typically not given from systems on the administrative costs of trapping and redirecting transactions, nor are options available to delay implementation of changes until the queue of transactions that would be impacted has been bled dry.
These “indirectly affected” transactions can include items such as expense reports, project cross charges, purchase orders, or sales expenses. The person that is making the changes to the chart of accounts needs to at least be made aware that there are transactions which upon further processing may impact this cost center in order to assess the correct course of action. They may choose to delay the chart of accounts maintenance activities. They may choose to reassign the transaction to a new cost center. They may choose to send the transaction back to the originator and ask them to resubmit. However, because prior art financial accounting systems generally do not check for the indirectly related transactions, future transactions may be either posted to an incorrect cost center or will not able to be posted and will be stuck in a queue awaiting investigation. This can lead to underreporting of expenses and potentially misstatements in accounts.
In contrast, embodiments of the invention are a cost center change validator that generates a listing of all the types of transactions that may post to or influence posting to cost centers and provide a report to the person that determines the accounting for that type of transaction. For example, a purchase requisition may derive the charge to a cost center from the work assignment of the employee. Embodiments of the invention also store the way to identify if the transaction is already processed. For example, a requisition may have been considered in a requisition pool from which a purchase order has been created. The person in charge of chart of accounts or cost center maintenance can implement embodiments of the invention for validation of a given proposed cost center change and see the number of transactions for each transaction type. They can drill into the transaction detail and decide on the disposition on an individual transaction.
Computer readable media may be any available media that can be accessed by processor 22 and includes both volatile and nonvolatile media, removable and non-removable media, and communication media. Communication media may include computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media.
Processor 22 is further coupled via bus 12 to a display 24, such as a Liquid Crystal Display (“LCD”), for displaying information to a user. A keyboard 26 and a cursor control device 28, such as a computer mouse, is further coupled to bus 12 to enable a user to interface with system 10.
In one embodiment, memory 14 stores software modules that provide functionality when executed by processor 22. The modules include an operating system 15 that provides operating system functionality for system 10. The modules further include an impacted transactions module 16 that determines and reports transactions impacted by cost center and other business object changes, as disclosed in more detail below. System 10 can be part of a larger system, such as an Integrated Financial system or Enterprise Resource Planning (“ERP”) system that generates the financial and organization data used by module 16. Therefore, system 10 will typically include one or more additional functional modules 18 to include the additional functionality. For example, module 18 may include “Oracle E-Business Suite Financials” from Oracle Corp. A database 17 may be coupled to bus 12 to provide centralized storage for modules 16 and 18.
In one embodiment, an impacted transaction may be one of two types. One type is already directly associated with a cost center using a business object attribute. Therefore, this transaction can easily be identified as being impacted or affected when its associated cost center is changed. The other type of transaction is not yet directly associated with a cost center, but will potentially impact the cost center in the future. For example, a “sales lead” does not impact a cost center until the lead results in a sale, at which point a sales representative may be awarded a credit. This credit ultimately will impact a specific cost center. In this case, the sub-ledger accounting setup data (i.e., the configuration rules which tell the system how to determine to which account any particular transaction should be posted) must be evaluated to determine which transactions will be associated with the cost center at some point in the future. When users are given visibility to these future transactions, they then have a choice about how to handle them including an option to change the processing setup rules such that a different cost center will be used in the future. This type of visibility is not generally available in prior systems. Known systems also have various places where default cost centers are entered that can be used to populate transactions during accounting and reporting. For instance, worker assignments may have a default cost center. Embodiments of the invention can identify areas of setup where the cost center is entered for defaulting purposes.
Embodiments of the invention facilitate steps to ensure that the change or end-dating of an organization is implemented correctly across all areas of the business. For example, when a cost center is end-dated, there may be expense reports charged to this cost center which are going through the approval process which need to be looked at to determine which should post to the old cost center and which should be redirected to the new cost center. There will be subledger accounting setups which need to change so that future transactions which would have been assigned to this cost center are now assigned to the new cost center or appropriately divided between the new cost centers. For human resource (“HR”) departments, all people assigned to this cost center must be reassigned, and if the department is also a project expenditure organization as well as a department, then those transactions must be closed out and possibly a new project organization implemented to match the new department.
Some of these changes are recommended by the system, and others depend on human analysis and judgment in order to determine which way they should be handled to best reflect the intent of the reorganization being performed. Functionality of embodiments gives users visibility into all potential transactions and setup information which may be affected by the change/end-dating of a cost center or department.
One embodiment allows users to run a report by selecting the cost center (or department) which is to be changed, the type of change to the cost center (e.g., end-dating, change of parent within the primary organization chart, or change of reporting attributes such as a change of manager or management segment assigned to the cost center, etc.), and the date on which the change is to take effect. A result summary screen shows how many transactions have been found in each transaction category and how much of the review process has been completed for each category. A user may also manually mark a category as complete if they know that they do not need to take any action on any of the transactions in this category.
From user interface 300, a user can drill into the individual transactions for any one transaction type, and optionally directly to the source application and show the related transactions within the native workbench for that business process. Users can then update their review progress.
Embodiments of the invention can be used for department changes in addition to cost center changes. For example, reports can be created for departments that mirror the reports for cost centers, but will return information about transactions which reference the department in question. This report will show not only those setups and transactions which reference the department, but also any other classifications of the organization. For example, if a department is being end-dated, users must deal with the people assigned to those departments, but if that department is also classified as a project owning organization or as a sales team, then that must be part of the report as well so that appropriate actions may be taken in those areas to end-date the organization as a whole if that is the intent.
The report generated by embodiments of the invention can be used by the departments which are notified of a reorganization request to assist in the manual evaluation of all the potentially impacted transactions. The development teams which register each transaction type will also register whether the transactions must be dealt with in order to avoid inconsistency or whether the transactions can remain unchanged without any issues. For example, open expense reports to a cost center which has been end-dated might be OK as long as they post to a date before the end-date of the cost center. A decision should be made by someone in finance about whether the open expenses are appropriate to post to the old cost center or whether they should really be moved to somewhere else since that cost center is being closed.
At 402, the business object to be changed, change type, and effective date of the change in received. In one embodiment, the business object is a cost center, the change type is end-date, and the date of the change is the date when the cost center will cease to exist.
At 404, all transactions directly associated with the business object are identified. In one embodiment, these transactions will have the business object listed as an attribute of the transaction.
At 406, all transactions that are impacted by the business object change but are not directly associated with the business object (i.e., do not include an attribute for that business object) are identified. These are the transactions that in the future are likely to be posted to the changed business object. In one embodiment, during the set-up for these transactions, a business object is identified in sub-ledger accounting.
At 408, a report is generated listing all transactions identified and allowing the user to get details of each transaction.
As disclosed, embodiments identify all transactions impacted by a business object change. The transactions are displayed to a user so each transaction can be assigned to the correct business object after the change.
Several embodiments are specifically illustrated and/or described herein. However, it will be appreciated that modifications and variations of the disclosed embodiments are covered by the above teachings and within the purview of the appended claims without departing from the spirit and intended scope of the invention.
