US7966235B1 - Method and apparatus providing automated control of spending plans - Google Patents
Method and apparatus providing automated control of spending plans Download PDFInfo
- Publication number
- US7966235B1 US7966235B1 US09/969,140 US96914001A US7966235B1 US 7966235 B1 US7966235 B1 US 7966235B1 US 96914001 A US96914001 A US 96914001A US 7966235 B1 US7966235 B1 US 7966235B1
- Authority
- US
- United States
- Prior art keywords
- spending
- departments
- value
- recipient
- department
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active, expires
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
- G06Q20/102—Bill distribution or payments
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
- G06Q20/105—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems involving programming of a portable memory device, e.g. IC cards, "electronic purses"
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
- G06Q20/108—Remote banking, e.g. home banking
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/03—Credit; Loans; Processing thereof
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/06—Asset management; Financial planning or analysis
Definitions
- the present invention generally relates to automated, computer-based financial planning.
- the invention relates more specifically to a method and apparatus providing automated control of spending plans.
- a particular problem in this context involves allocation of spending values.
- one department is viewed as an internal supplier or source of services or resources to other departments that are consumers or recipients.
- the Facilities department which is responsible for maintaining offices, laboratories, equipment, and other facilities used by other departments, provides internal maintenance services and related resources to those other departments.
- the Facilities department is a source and the other departments are recipients.
- Still another problem of past approaches involves time delay. Since an allocated spending value is one component of the budget of a recipient department, that recipient department normally cannot finalize its budget for itself or for upper-level management review until it receives the allocated spending value from the source department. In past approaches, this has led to delay in preparing and distributing departmental budgets or plans, and the source department can become a bottleneck that can impede the ability of numerous recipient departments from completing their budgets or plans.
- a recipient department manager may find that department spending generally is within budget, but goes over-budget because a source department has over-spent, and therefore the portion of that source department's spending that is allocated to the recipient department is greater than expected. Thus, a budget overage can occur in a way that is beyond the control of the recipient department manager. There is a need for a way for the recipient department to identify allocations in its plan so that such control issues are apparent upon management review of the plan.
- Still another problem of past approaches is that the allocation model is maintained outside the planning environment, in a side document or spreadsheet that is used for reference but not fully integrated into the plan. As a result, computing allocations and distributing them to affected departments is cumbersome. There is a need for a way to provide allocation values and an underlying allocation model that are tightly integrated into the planning environment, rather than residing outside it.
- a typical financial planning system includes a general ledger or an equivalent that comprises plan or actual revenue and expense values for a plurality of accounts.
- Each account may have one or more sub-accounts. For example, there may be a Travel Expense account that has sub-accounts for Lodging, Air Travel, and Meals.
- the plan may have a Marketing budget included in it, but the user is accustomed to thinking about the portion of the budget that the user wishes to spend on various customers or projects.
- the rigidity imposed by general ledger accounts also affects planning that focuses on cross-functional programs, rather than individual projects. For example, in past approaches, there is no way in an electronic spending plan to associate spending values with programs that involve multiple different functions of an enterprise. As a specific example, in a given enterprise the Finance, Sales, Marketing, and Engineering departments all may be involved, in different ways, in an initiative involving the launch of a new product. Thus the product launch, which is an example of a program, involves cross-functional activities.
- a common operation in use of a financial management application is to roll up numbers.
- to roll up numbers means to consolidate values from lower level nodes of a hierarchy into higher-level nodes of a hierarchy, or to make information from a subordinate in an organization visible for judgment by his or her superior.
- Such roll-ups enable a user to view spending values by account, by department, by program, etc.
- a key constraint of past approaches has been that only one organizational hierarchy may be defined.
- the hierarchy represents departments and business units in one particular way that is analogous to an organization chart of an enterprise.
- a particular enterprise may have one hierarchical view of its departments that is based on location in association with function, and an alternate view that is based only on function, or based only on a higher level of authority, such as management only.
- the method involves creating and storing a spending plan comprising a plurality of spending limit values.
- Each spending limit value is associated with a department from among a plurality of departments.
- a first selected department is identified from among the plurality of departments as a source for allocation of a first spending value.
- One or more recipient departments are identified as recipients of an allocation of the first spending value.
- the first spending value is then automatically allocated among the recipient departments according to a specified allocation model, resulting in creating and storing a plurality of allocated spending limit values, wherein each of the allocated spending limit values is associated with one of the recipient departments.
- the first spending value is associated with the first selected department, and the first spending value is automatically retrieved from the spending plan.
- a department hierarchy is created and stored, comprising nodes representing departments of an enterprise.
- the first selected department is other than a root node of the department hierarchy.
- the first selected department is represented by an intermediate node in the department hierarchy, and the first selected department is the only node in a branch of the department hierarchy that is selected as a source of a first spending value for allocation.
- automatically allocating the first spending value according to a specified allocation model involves allocating a portion of the first spending value to each recipient department based upon a proportional consumption value that represents a proportion of the first spending value that is consumed by that recipient department.
- a related feature involves automatically allocating a portion of the first spending value to each recipient department based upon an amount of physical space occupied by that recipient department in one or more work spaces in proportion to all space occupied by all recipient departments in all such work spaces.
- a portion of the first spending value is allocated to each recipient department based upon a number of individuals associated with that recipient department in proportion to all individuals associated with all recipient departments.
- automatic allocation of the first spending value may involve allocating a portion of the first spending value to each recipient department based upon an amount of revenue generated by that recipient department in proportion to all revenue generated by all recipient departments.
- user input is received that selects a new allocation model, different from the specified allocation model, for use in allocating the first spending value, and the first spending value is automatically re-allocated among the recipient departments according to the new allocation model.
- a plurality of allocated spending limit values are created and stored in a spending plan. Each of the allocated spending limit values is associated with one of the recipient departments.
- a plurality of space values representing amounts of physical space occupied by the recipient departments, are received in a table of a graphical user interface.
- the table identifies the recipient departments, current values for the physical space, and a proportion of each such physical value in comparison to all space occupied by all recipient departments.
- an allocation proportion for a recipient department that is associated with the received space value is automatically computed, based on the allocation model and an allocation basis value thereof. The computed allocation proportion is automatically displayed in the graphical user interface table.
- a headcount value When a headcount value is used as the allocation basis, it may be automatically retrieved from a human resources planning application. Further, an updated headcount value for a particular one of the recipient departments may be programmatically received from the human resources application. The first spending value then may be automatically re-allocated to the particular recipient department based upon the updated headcount value in proportion to all individuals associated with all recipient departments.
- reports of budgeted spending with allocations are provided.
- a report of budgeted spending limit values for one or more departments may be generated.
- Each budgeted spending limit value that is displayed in the report for a particular department is reduced by the plurality of allocated spending limit values that have been allocated to the recipient departments.
- the budgeted spending limit values displayed in the report for the recipient departments are increased by the plurality of allocated spending limit values that have been allocated to the recipient departments.
- the user may selectively generate reports with or without allocations, thereby providing flexibility for the user to see the total cost of business or just expenses for which the user is accountable.
- allocation values are tightly integrated into the planning environment, rather than residing outside it.
- the allocated expenses may be kept out of a forecast prepared by a cost center manager, so that such a manager plans only for those expenses for which the manager is directly accountable.
- the invention encompasses a computer apparatus, a computer readable medium, and a carrier wave configured to carry out the foregoing steps.
- FIG. 1A is a block diagram that illustrates an overview of a network context in which an embodiment may be used
- FIG. 1B is a block diagram that illustrates one embodiment of the Financial Management application of FIG. 1A ;
- FIG. 2A is a block diagram that illustrates a financial management application
- FIG. 2B is a block diagram that illustrates a configuration function of the application of FIG. 2A ;
- FIG. 2C that illustrates an allocation and related data
- FIG. 3A is a flow diagram of one embodiment of a method of automatically allocating a spending value
- FIG. 3B is a flow diagram of one embodiment of a method of automatically computing allocation values for recipient departments
- FIG. 4 is a diagram of a screen display that may be generated to receive user input for an allocation model
- FIG. 5 is a diagram of a spending plan report with allocations that may be generated in an embodiment
- FIG. 6A is a diagram of a screen display that may be generated by the financial management application and illustrating a shared financial plan with cost center major accounts;
- FIG. 6B is a diagram of an example screen display that may be generated, in one embodiment, showing minor accounts
- FIG. 6C is a diagram of a screen display that may be generated, in one example embodiment, for adding a detailed line item or providing a specified model for a line item;
- FIG. 7A is a flow diagram that illustrates a process for updating line item detail values
- FIG. 7B is a flow diagram that illustrates a process for updating line item detail values
- FIG. 8A is a diagram of a program management screen display that may be generated, in one example embodiment
- FIG. 8B is a diagram of a screen display that may be generated, in one embodiment
- FIG. 8C is a diagram of an example department headcount planning page illustrating records of individuals or “heads” in association with program identifiers
- FIG. 8D is a screen display that may be generated, in one embodiment
- FIG. 9A is a screen display showing an example private spending plan that may be used to access program-specific spending plan information
- FIG. 9B is a diagram of an example of a program-specific spending plan display that may be generated, in one embodiment
- FIG. 10 is a diagram of an example of a program-specific report that may be generated, according to one embodiment
- FIG. 11A is a block diagram that depicts a data hierarchy definition according to an embodiment
- FIG. 11B is a block diagram that depicts a hierarchy elements definition, i.e., a particular instance of data hierarchy definition
- FIG. 11C illustrates an alternate hierarchy based on the hierarchy of FIG. 11B ;
- FIG. 12 is a flow diagram illustrating an example method of creating a data roll-up using an alternate hierarchy
- FIG. 13 is a block diagram that illustrates a computer system upon which an embodiment may be implemented.
- FIG. 14 is a block diagram of an example deployment architecture that may be used to implement the embodiments described herein.
- FIG. 1A is a block diagram that illustrates an overview of a network context in which an embodiment may be used.
- One or more clients 102 A, 102 B which are respectively associated with a first department 10 and second department 12 of an enterprise, are communicatively coupled through network 104 to a financial management application 110 .
- Each client 102 A, 102 B in one embodiment, is a workstation, personal computer, personal digital assistant, or other end station.
- clients 102 A, 102 B represent a server, application program, or process that communicates programmatically with financial management application 110 .
- clients 102 A, 102 B may execute an interface application 103 to facilitate communications with network 104 and financial management application 110 , and to facilitate display of information received from them.
- interface application 103 is a network browser, for example, Microsoft Internet Explorer, Netscape Navigator, etc.
- FIG. 1 depicts two clients 102 A, 102 B associated with two departments; however, in a practical system there may be any number of clients and any number of departments.
- Financial management application 110 comprises one or more computer program servers, modules, or processes that cooperate to carry out the functions described herein, and optionally additional functions.
- Financial management application 110 is communicatively coupled to a database 112 in which the application may store tables of financial data, programmatic objects, stored procedures, etc.
- An example of a suitable commercially available database is Oracle 8i.
- financial management application 110 also is communicatively coupled to a human resources application 114 that has an associated HR database 115 .
- financial management application 110 can retrieve data relating to human resources matters, such as headcount values by department, for use in functions of the financial management application.
- data, application 114 , or database 115 may be contained within financial management application 110 .
- financial management application 110 is configured to store one or more spending plans associated with departments 10 , 12 , and the enterprise with which they are associated.
- the spending plans may comprise budgets, business plans, spending limits, and the like.
- a spending plan may comprise data stored in database 112 , in which each department or groups of the enterprise has a specified spending limit value that represents the total amount of corporate resources that the enterprise is authorized to spend.
- Financial management application 110 also stores metadata about the enterprise environment, such as one or more hierarchies that represent users, groups, departments, and relationships among them. Examples of such hierarchies are described in application Ser. No. 09/905,258, filed Jul. 12, 2001, the entire contents of which is hereby incorporated by reference as if fully set forth herein, and in the parent application hereof.
- FIG. 1B is a block diagram that illustrates one embodiment of the Financial Management application of FIG. 1A .
- Financial Management application 110 comprises a Revenue Planning module 150 , a Business Plan module 151 , and a Spending Capacity module 152 .
- the Revenue Planning module 150 receives input providing revenue forecast values and actual revenue values for a business from one or more organizations focused on revenue generation, such as sales organization 153 , marketing organization 154 , manufacturing organization 155 , etc. Any department or other element of the enterprise may provide such input.
- Revenue Planning module 150 is communicatively coupled, directly or indirectly using one or more networks, to a Business Plan module 151 . Using this communication, Revenue Planning module 150 dynamically provides revenue forecast information to the Business Plan module 151 for use in profit and loss (“P&L”) statements, balance sheets and statements of cash flows that are created and managed using the Business Plan module.
- the revenue forecast information that is communicated from Revenue Planning module 150 to Business Plan module 151 might be organized by product, by customer, etc.
- Business Plan module 151 may retrieve the latest revenue forecast information at any time and may refresh the financial planning information that it provides, using business rules and constraints.
- Business Plan module 151 is also communicatively coupled, directly or indirectly through one or more networks, to Spending Capacity module 152 .
- Business Plan module 151 receives expense information from Spending Capacity module 152 and provides spending target values, or spending capacity values, to the Spending Capacity module 152 .
- One or more departments 159 , 160 , 161 are communicatively coupled to Spending Capacity module 152 directly or indirectly through one or more networks and access the Spending Capacity module to manage spending plans and budgets, request increases in spending capacity values, etc.
- Managers of departments 159 , 160 , 161 or other users may operate Spending Capacity module 152 to periodically roll up spending plans to Business Plan module 151 for validation by the Business Plan module and for review and approval by higher-level managers.
- Spending Capacity module 152 may operate to periodically roll up spending plans to Business Plan module 151 for validation by the Business Plan module and for review and approval by higher-level managers.
- privately created department spending plans are compared to spending target values established using Business Plan module 151 , and the department spending plans may not become public if the spending target values are exceeded.
- Spending Capacity module 152 may have other functions and features, which are not critical.
- Spending Capacity module 152 may comprise SpendCap Manager, commercially available from Closedloop Solutions, Inc., of Redwood City, Calif.
- Spending Capacity module 152 has the structure and functions that are disclosed in application Ser. No. 09/804,851, filed Mar. 31, 2001.
- the main electronic financial statements that are planned using Business Plan module 151 are one or more P&Ls.
- a user may set spending targets within the context of a P&L.
- the user may set the spending targets either at a high level with respect to top-level P&L lines, or at a lower level by drilling down to sub-lines of the P&L top-level lines.
- Spending targets may be established for them by selecting a more detailed view and providing values for each such group.
- the spending target values are automatically updated as spending capacity values by Spending Capacity module 152 and thereby operate to restrict spending plans of lower-level departments.
- This architecture enables the departments such as sales organization 153 , marketing organization 154 , manufacturing organization 155 , etc., to contribute revenue values based on their view of revenue-generating operations, without accessing or interfering with higher-level business planning operations.
- departments such as sales organization 153 , marketing organization 154 , manufacturing organization 155 , Revenue Planning module 150 and Business Plan module 151 are communicatively coupled using a public packet-switched network such as the Internet.
- FIG. 2A is a block diagram that illustrates a financial management application.
- Financial management application 110 may comprise personal plan functions 202 , shared plan functions 204 , message functions 206 , report functions 208 , and configuration functions 210 .
- personal plan functions 202 involve creating, storing, modifying, and managing one or more personal financial plans.
- a personal financial plan is a plan for a department in which a user participates that is kept private from others in the enterprise. If desired, the user may publish the personal plan to others in the enterprise, placing it in a shared planning area that is managed by shared plan functions 204 .
- Message functions 206 may provide a message in-box for messages directed to a particular user relating to that user's planning activity. Such messages may be system messages, alerts, notifications, or information messages from other users.
- Report functions 208 involve generating one or more reports from data that is managed by the system.
- Configuration functions 210 generally involve configuring administrative features and functions.
- FIG. 2B is a block diagram that illustrates a configuration function of the application of FIG. 2A .
- Configuration functions 210 may comprise, in one example embodiment, an allocations management function 220 , which is described in the next section of this description.
- Financial management application 110 may have other functions and features, which are not critical.
- financial management application may comprise BizPlan Manager, commercially available from Closedloop Solutions, Inc., of Redwood City, Calif.
- planning entities are organizational groups within the company that is planning information in the system.
- planning entities comprise “Corporate,” one or more Business Units, one or more Rollup Departments, and one or more Cost Centers.
- the planning entities are organized in one or more organizational hierarchies that are represented by data stored in database 112 . The structure and use of such hierarchies is described herein in the next section.
- each hierarchy comprises a plurality of nodes, designated as “profit centers” and as “spending departments.” Nodes that are “profit centers” are responsible for (and plan for) both revenues and spending. Nodes that are “spending departments” only spend money and therefore do not plan for revenues. All “profit centers” can use the techniques disclosed herein to plan one or more integrated sets of financial statements such as a P&L, balance sheet and cash flow statements.
- the profit centers comprise two types; one top-level node is termed the “Corporate” node, and lower-level nodes are termed “Business Units.”
- the names of such nodes can be changed, but for purposes of illustrating a clear example, the terms “Corporate” and “Business Unit” are used herein.
- a Business Unit can alternately be termed a Division, a Branch, a Region, etc.
- the “Corporate” node is always the top-level planning entity in the departmental hierarchy.
- a system administrator can change the name of the top-level planning entity to something else, but in this document, for clarity, the top-level planning entity is referred to as Corporate.
- Business units always report to Corporate, or to other Business Units, thus creating a hierarchy of Business Units.
- Rollup departments can report to other rollup departments, to a business unit, or directly to Corporate, depending upon how your company is structured.
- Cost centers normally report to rollup departments, but may report directly to a business unit or Corporate.
- a business unit is an organizational node that is a profit center and is not the Corporate node, and which plans a contribution P&L instead of simply setting spending capacity for its child departments, as other parent departments do.
- a business unit plans a contribution P&L using Business Plan module 151
- a rollup department plans using a Spending Capacity Assignment page in Spending Capacity module 152 .
- Corporate sets spending and revenue targets for each business unit, and the parent of a rollup department (whether Corporate, a business unit, or another rollup department) sets spending capacity for the rollup department.
- a business unit has considerably more autonomy within the company, and greater control over its spending levels, than a rollup department.
- a business unit identifies an organizational element that contributes a profit or loss to the overall enterprise and generates revenue and expenses, as distinguished from certain departments that solely generate expenses and are not involved in generating revenue.
- a spending target is a non-binding spending goal set by Corporate or a higher-level business unit for a child business unit.
- a business unit can plan to spend less or more that the target suggests.
- a revenue target is a non-binding revenue goal set by Corporate or a higher-level business unit for a child business unit.
- a business unit can plan to generate less or more revenue than the target suggests.
- a spending capacity value is a mandatory limit set by a parent department (Corporate, a business unit, or another department) for a child department.
- validation checks are applied to private plans of child departments when the plans are published, so that the child departments cannot plan to spend more than the spending capacity value allows.
- the validation checks may be turned off for some or all the spending departments.
- embodiments may be used in the context of a system providing revenue-driven reallocation of spending resources.
- revenue forecast information is captured.
- the process of allocating spending capacity values among a plurality of spending parties is automated, based on the latest revenue forecast, in order that an organization is able to achieve its desired profitability objectives.
- a set of related pro-form a financial statements are generated, including P&L statements, balance sheets, and statements of cash flows.
- a method providing automatic allocation of a spending limit value among a plurality of spending parties is provided.
- a user may invoke an automatic allocation process by launching the financial management application 110 , selecting the configurations function 210 , and selecting the allocations management function 220 .
- allocations management function 220 manages an allocations list 230 that is stored in the database.
- Allocations management function 220 may include an Add function 231 A, Modify function 231 B, and Delete function 231 C, which operate to add, modify, or delete, respectively, one or more allocations 232 A, 232 B, 232 N, etc., that are stored in allocations list 230 .
- financial management application 110 displays Add, Modify, and Delete options, and a list of the allocations 232 A, 232 B that are then currently stored in allocations list 230 .
- allocations 232 A, 232 B, 232 N There may be any number of allocations 232 A, 232 B, 232 N stored in allocations list 230 , although normally each source department participates in only one allocation or allocation model.
- the displayed list may reference each allocation by a source value 234 A and model value 236 A, which uniquely identify each allocation, and which are described further herein.
- the list may comprise an electronic document in which each source value and model value is rendered as a hyperlink. Using such a list, a user may invoke a desired function by selecting a particular source value and then selecting Add, Modify, or Delete. To change the model value 236 A, the user may select the model value hyperlink.
- FIG. 2C that illustrates an allocation and related data.
- Each allocation 232 A in this embodiment, comprises a source value 234 A, model value 236 A, description value 238 A, and a list 240 A of one or more recipients of an allocation.
- a source is a department of an enterprise that has an associated spending value that is to be allocated among the recipients.
- the model value identifies an allocation model. For example, allocations may be carried out based on square footage occupied by the recipient departments, based on revenue generated by the recipient departments, based on the number of personnel in the recipient departments, etc.
- the description value 238 A is a description associated with the allocation, such as “Allocation of Facilities costs among consuming departments,” or any other text desired by the user.
- the list 240 A identifies one or more departments that are recipients of an allocation from the source department.
- list 240 A comprises Engineering, Manufacturing, and Human Resources. This indicates that a spending limit value associated with the source department is to be allocated among the Engineering, Manufacturing, and Human Resources departments of an enterprise.
- the departments identified in list 240 A may be all or less than all the departments in the enterprise.
- the departments identified in list 240 A normally are selected from a department hierarchy, or other master list of departments, that is maintained in the database by the financial management application, as described further herein.
- FIG. 3A is a flow diagram of one embodiment of a method of automatically allocating a spending value.
- a spending plan is created and stored.
- block 302 involves using financial management application 110 to create and store, in database 112 , information in the nature of a budget that specifies maximum allowed spending values for one or more departments of an enterprise and one or more line items in each such department. Line items may represent spending categories, standard accounting accounts, projects, programs, etc. The specific form or format of the spending plan is not critical provided that there is a spending value associated with a department.
- block 304 a source department is identified.
- block 304 involves receiving user input that selects one of the departments that is represented in the spending plan of block 302 , in a graphical user interface or other data input mechanism.
- the financial management application 110 may generate a graphical user interface window or page that includes a Department pull-down menu from which the user selects an available department.
- the source department could be Facilities, IT, Legal Services, Finance, HR, etc., i.e., any department providing services or resources that another department or business unit would consume as part of its operating costs.
- block 306 one or more recipient departments are identified.
- block 306 involves receiving user input that selects one of the departments that are in the enterprise department hierarchy, in a graphical user interface or other data input mechanism.
- the financial management application 110 may include a list of recipient departments that exist in the hierarchy, each associated with a check-box or other user interface widget. To select one or more recipients, the user selects check boxes associated with available departments, and then submits the checked page to financial management application 110 for further processing.
- an allocation model is stored information that associates one or more departments with respective proportional consumption values and with respective percentage consumption values for a period of time.
- An allocation model may be based on square footage occupied by a department, revenue generated by a department, headcount of a department, etc.
- the associated period of time is an accounting period.
- an allocation model may comprise the stored information set forth in Table 1:
- ALLOCATION MODEL FACILITIES Q4FY2001 QIFY2002 DEPARTMENT SPACE PCT SPACE PCT AMERICAS SALES 3,000 6.9% 4,000 9.2% INSTRUMENTATION 4,000 9.2% 3,000 6.9% MFG ENGINEERING 4,500 10.3% 4,500 10.3% NEW PRODUCT MFG 27,500 63.2% 27,500 63.2% FINANCE 3,000 6.9% 3,000 6.9% QA 1,500 3.4% 1,500 3.4% TOTAL 43,500 100% 43,500 100%
- the square footage values are examples of proportional consumption values
- the percentage values are examples of percentage consumption values.
- a model may store any number of such values for any number of time periods for each department. Because such values significantly affect computation of allocations and possibly other planning values, in an embodiment, access control is applied to the proportional consumption values. For example, only an administrator or “super-user” is authorized to modify or update the proportional consumption values in a model.
- Revenue values, or any other appropriate “driver” values that are attributable to recipient departments, may substitute for square footage values. Further, the proportional consumption values may be retrieved in real time by financial management application 110 automatically from another data source. For example, revenue values may be retrieved substantially immediately from revenue planning module of the financial management application 110 , or from another source of top-line data such as revenue generated by departments. Alternatively, financial management application 110 may request such values from an external application or retrieve such values from an external database.
- Embodiments may provide a graphical user interface for the purpose of creating one or more models.
- the financial management application 110 may generate and send to the client a graphical user interface window or page that comprises a table having data entry fields to receive values for the proportional consumption values.
- FIG. 4 is a diagram of a screen display that may be generated to receive user input for an allocation model.
- Screen display 400 comprises an allocation model 402 having rows 404 that identify recipient departments and columns 406 , 408 that identify proportional consumption values and percentage consumption values for different accounting periods.
- a label 412 specifies by the text “Space/Other Allocation Model: Facilities” that the allocation model 402 is based on space or another factor, and that the source department is Facilities.
- Column 408 comprises a data entry field 408 A for each of the rows 404 that receives a proportional consumption value associated with that department.
- the value “15,000” in field 408 A indicates that the “BU Hardware” recipient department occupies 15,000 square feet of office space or the like.
- a corresponding percentage computation value 408 B in this case “26.3%,” is automatically computed and displayed in association with the data entry field. The value “26.3%” is the percentage of facilities spending that will be allocated to the “BU Hardware” recipient department.
- a total value 409 is automatically computed and represents the sum of all values in fields 408 A.
- a percentage total value 410 is the sum of all computed percentage values 408 B and normally has the value “100%.”
- a user may modify the value in field 408 A and then obtain an updated view by selecting the Done button 414 , which sends the modified value and all other field values to the financial management application 110 .
- the application generates a new screen display with updated values and returns it to the client.
- the percentage computation values are automatically computed and displayed in the graphical user interface windows based on the proportional consumption values that have been entered.
- a user may re-compute an allocation model by modifying one of the proportional consumption values and re-submitting the page to the financial management application 110 .
- the allocation model is based on headcount, that is, the number of individuals that are associated with each department in the model.
- headcount values are provided in the model of Table 1 rather than square footage values.
- the headcount values may be retrieved in real time by financial management application 110 automatically from another data source. For example, the headcount values are retrieved substantially immediately from the total headcount values appearing in a public spending plan that has been established using shared plan functions 204 .
- financial management application 110 may request headcount values from human resources application 114 , or retrieve such values from HR database 115 , or retrieve headcount values from another data structure or database table that is contained within application 110 or database 112 .
- the allocated spending values are saved.
- the allocated spending values may be saved in database 112 .
- FIG. 3B is a flow diagram of one embodiment of a method of automatically computing allocation values for recipient departments.
- a roll-up value associated with the source department is retrieved.
- block 312 involves retrieving a source value that is rolled-up from the public spending plan that has been prepared using shared plan functions 204 .
- a loop is initiated in which each department that is identified in the allocation model is considered.
- an allocated spending limit value is computed as the product of the source spending limit value and the proportional consumption value for that department, divided by the sum of all proportional consumption values of all recipient departments in the model.
- the allocated spending limit value is computed as the product of the source spending limit value and the percentage consumption value for that department.
- the computed allocated spending limit value ASLV is:
- the Americas Sales department is allocated $6,900 as the portion of the $100,000 Facilities budget that is consumed by the Americas Sales department.
- that value becomes a cost of the Americas Sales department that is automatically reflected in its spending plans and reports that show its budget, costs, or spending plans.
- the computed value is stored in the database as a cost item that is associated with the recipient department in the public or shared plan for the enterprise. Block 316 then is repeated for all other departments in the model.
- the computed value may be stored in association with the plan and retrieved from the plan for use in other operations.
- the stored computed allocated spending limit values for the departments are used to adjust values that are provided in budget reports, spending reports, and the like.
- the allocated spending limit values for the departments may be presented in one or more user interface windows, or presented to users in tables, or in a version of the allocation model. Because the allocated spending limit values are automatically stored as cost items for the recipient departments, values for such recipient departments in reports automatically reflect the allocated spending limit values.
- Table 2 is a facsimile representation of a spending plan report with allocations that may be generated in an embodiment.
- the spending values for the Facilities department are presented as zero values, because the budget of the Facilities department has been 100% allocated to other departments using the foregoing model and computation.
- the Facilities department values are automatically reduced in proportion to the amount of allocation to other departments that has been computed.
- recipient departments such as Manufacturing, automatically reflect the allocated spending value that has been computed for them in one or more Allocation lines. For example, amounts allocated into the plan from the HR department are reported in the HR Allocation line.
- management of the Manufacturing department can immediately see the effect of allocated-in values on the department plan, which act as a charge or cost to that department.
- FIG. 5 is a diagram of an example of a spending plan report with allocations that may be generated.
- Report 500 comprises a header 502 and body 504 having an account column 506 .
- This report is for a recipient department called “Asia Pac.”
- the specific example of FIG. 5 shows spending by account for one department, “Asia Pac,” which is a recipient of allocations as indicated by the second line of the report (“Allocations In”).
- Source departments will have an “Allocations Out” line and will total to zero if the report is run with allocations.
- the allocation values may be incorporated or displayed within a department's shared spending plan that is accessed and managed using shared plan functions 204 .
- the allocation lines may be displayed as part of a complete spending plan, either in an “above the total” line position, or below the total line. The user may select whether to display the allocation lines above the total line or below. This enables the user to selectively place allocation values within a department's spending capacity, or in a separate area that enables analysis of the department's spending without considering the impact of allocations, or outside the department's core spending total.
- the detailed line items are created and used in the context of a computer-based financial plan.
- financial management application 110 may maintain the detailed line items.
- FIG. 6A is a diagram of a screen display 600 that may be generated by the financial management application 110 and illustrating a shared financial plan 602 with cost center major accounts.
- financial plan 602 is a spending plan for a cost center designated “HW QC,” as indicated by pull-down menu 601 and label 610 .
- a spending plan may be prepared for a different cost center by selecting a cost center from pull-down menu 601 .
- the plan 602 comprises a plurality of spending limit values associated with accounts of a cost center.
- Financial plan 602 comprises a plurality of rows 608 each associated with an account and each comprising an account hyperlink. For example, hyperlink 608 A is associated with a Travel account.
- the plan 602 also comprises a plurality of columns 612 that identify spending amounts associated with particular accounting periods and accounts.
- a Spend Cap row 609 identifies maximum spending values for all accounts shown in rows 608 .
- a Total row 614 identifies a total of all spending values associated with accounts 608 in a particular column 612 .
- An Available SpendCap row 616 identifies an amount of value, if any, from among the maximum spending values that is not yet assigned to an account. Thus, values in row 616 represent the difference of the maximum spending values and the total of all spending values associated with accounts 608 in a particular column 612 .
- One or more detailed line items may be added in a position logically below any of the accounts 608 .
- a user selects a shared plan (termed, in one embodiment, “MyPlan”), for example, by selecting a MyPlan button 606 from screen display 600 .
- financial planning application 110 generates a screen display showing a plan for the selected department, which may have a format similar to that of screen display 600 , and which is editable.
- the user selects an account 608 , e.g., hyperlink 608 A.
- financial planning application 110 generates a screen display that shows the planned minor accounts for this major account. Assume, for purposes of illustrating an example, that the user selects Travel link 608 A as the selected account.
- FIG. 6B is a diagram of an example screen display that may be generated, in one embodiment.
- Screen display 620 comprises plan information for sub-accounts 622 that are associated with the travel department. Additional detailed items may be added by selecting one of the accounts 622 for which line items are desired, such as “Travel-Other” account 622 A.
- financial management application 110 generates and sends to the client a screen display that can accept a definition of a new line item.
- FIG. 6C is a diagram of a screen display that may be generated, in one example embodiment.
- an account screen display 630 comprises a plan excerpt 632 that displays planning values for the “Travel-Other” account. Each such account comprises a default line item identified as “Detail,” as shown by Detail line item 634 .
- the Travel-Other account also has a “User Conference” line item 635 that has been added by a user for the purpose of tracking expenses for a user conference event.
- Screen display 630 also comprises an Add Model link 638 that is associated with a description field 636 .
- a user may enter a description in the description field 636 and then select the Add Model link.
- financial management application 110 generates and sends to the client an updated version of screen display 630 that includes the new line item above the Detail line item 634 .
- the Detail line item then adds as a default or catch-all account for entering spending values relating to the “Travel-Other” account. Any number of line items may be added in the foregoing manner.
- the user may enter a line item description in Description field 636 and select the Add Model link 638 again.
- Each subsequently added line item is displayed in screen display 630 immediately above the default line item, e.g., “Detail” line item 634 of FIG. 6C .
- the user may enter new spending values that are associated with the detailed line item 635 in one or more columns 640 , and may save the values by selecting an Update button 646 , or the equivalent.
- Update button 646 or the equivalent.
- new total values are displayed in Subtotal row 642 .
- a line item may be deleted by selecting a Delete link that is adjacent to the line item to be deleted.
- the system generates a warning message that requires the user to confirm that the user wishes to delete the line item.
- any data values entered in columns 640 for past accounting periods are automatically added to and stored in the default line item for the account, and data values for future accounting periods are discarded.
- line item 635 is selection for deletion at a point in time during the first quarter of fiscal year 2002.
- Plan 632 includes a value of “10.0” in the “Oct FY 2001” column, i.e., a past accounting period with respect to the time of deletion. Therefore, upon deletion of line item 635 the value “10.0” is added to the value of default line item 634 , and the same action is taken for all other column values in 2001.
- the values in the columns for “Jan FY 2002” and other accounting periods in 2002 and forward are discarded.
- the screen display 630 is then re-displayed, with line item 635 removed, and the values for line item 634 in an updated state.
- the integrity of historical data in a plan is unaffected by deleting one or more line items that have been used for planning in the past, but the user is able to remove line items that were used in the past and are no longer meaningful, or that were temporary.
- the account spending values in the plan 621 of FIG. 6B are automatically updated to reflect or “roll up” the new plan values that were entered for the line item. For example, the values for “Travel-Other” account 622 are increased to reflect the values that were entered for the “User Conference” line item.
- the user may update or edit the plan at the account level. For example, the user may enter one or more values in columns 620 A for any of the accounts 622 . If a particular account is updated, and that account has one or more line items in addition to the default line item, then the difference between the account total entered in screen display 620 and the sum of the then-current line item values is computed and automatically added to the default line item value. In this way, the user may edit a plan at the account level, but the integrity of line item values is preserved, and specific line item values that the user has established remain unaffected.
- 6C is updated to show “76,” which is the difference of “126” and “50.”
- the total account value (“126”) is properly divided among the user-defined line item (“50”) and the default line item (“76”), without affecting the integrity of the user-defined line item.
- the line item details may be published to a shared plan by selecting an appropriate function from screen display 620 .
- the line item details are displayed and can be viewed, but cannot be modified or deleted.
- each of the line items is established by individual managers or other users; there may be multiple line items in different personal plans of different individuals that relate to the same activity but have different names.
- the user may select one of a plurality of models for use with the minor account.
- an model provides a way to enter spending values for a line item that are computed based on some external constraint or criteria. For example, spending values for a line item may be expressed based on the headcount of an associated cost center, the number of new personnel assigned to that cost center (“new heads”), etc.
- information relating to a selected allocation model is displayed in area 650 of plan 632 .
- a particular model is selected from a Model Type pull-down menu 660 .
- screen display 630 is refreshed to display one or more rows of information in area 650 that are appropriate for the selected model.
- a Headcount model has been selected, as indicated by Headcount row 652 and Rate per Head line 654 .
- Headcount row 652 displays the number of personnel associated with the cost.
- Rate per Head line 654 displays a spending rate or cost rate per person that is user-defined. Thus, the rate per head may be modified by a user by entering appropriate values in the Rate per Head line 654 for any accounting period.
- Subtotal line 656 displays the total spending by headcount, i.e., the product of the values in Headcount row 652 and Rate per Head line 654 .
- Total line 658 then displays the sum of Subtotal line 656 and Subtotal line 642 .
- the subtotals and totals are automatically computed by financial management application 110 .
- Headcount information for Headcount row 652 may be obtained from the HR database 114 or may be maintained by financial management application 110 .
- the New Heads model operates in a similar manner, except that the value displayed in a New Heads line in area 650 comprises only those personnel who are identified as “new” for this time period.
- the Ad hoc model allows the user to define both the driver and the rate for the model.
- FIG. 7A , FIG. 7B are flow diagrams that illustrate processes for updating line item detail values.
- a process for updating a line item value upon updating of an account value is shown.
- a spending plan having one or more accounts is created and stored, as in computer storage.
- a default line item is created for each account that is included in the plan.
- the default line item may be a “Detail”-type line item as shown in FIG. 6C .
- a user selects a link that requests addition of a line item to a selected account, and provides a description or name for the line item.
- the new line item is added to the plan.
- an account-level update is received to one of the plan values associated with an account that has a line item. For example, user input is received that provides an account-level update to a spending value for an account that has one or more line items.
- a difference of a sum of all the line item spending values, other than the default line item, and the updated account spending value is determined.
- the difference is stored in the default line item.
- the default line item reflects that portion of the updated account spending limit value that is not already reflected in a user-defined line item.
- FIG. 7B is a block diagram of a process of a process for updating line item values upon deletion of a line item is shown.
- user input is received that requests deletion of a line item.
- spending plan values for past accounting periods associated with the deleted line item are stored in a default line item associated with an account.
- a user may add more detailed line items that are logically located below the accounts or sub-accounts of a financial planning system and that may have personal meaning or temporary usefulness.
- the line items enable users to organize spending plans at a level of detail greater than typical general ledger accounts, without imposing such detail on the entire enterprise or requiring a change in the structure of the general ledger.
- individual users gain the ability to develop a budget or plan that is meaningful to them and takes into account all expense categories that are known to the individual user.
- Given a spending limit value the user can create line items and allocate portions of the spending limit value among various projects, customers, or activities until the spending limit value is reached among an aggregate of the line items. Further, the integrity of values entered in the past is preserved so that a historical view of the plan is always accurate even when line items are deleted.
- a spending plan may be provided with program values that identify programs.
- program refers to a project or activity of an enterprise.
- the Sales & Marketing department might have a Summer Trade Show program, New York Trade Show program, Value-Added Reseller program, etc.
- spending values associated with numerous disparate departments may be associated with a particular program, thereby providing consolidated cross-functional reporting of spending and budgets.
- an administrator creates and stores a list of programs that can be tracked.
- the programs may be organized in a hierarchy rather than a list; for example, there may be a program called “Product Initiatives” and one or more sub-programs that identify product-specific initiatives.
- the programs are assigned to the various departments that will participate in the programs, thereby creating an association of one or more departments to each program. Assignment of a program to a department may also reflect a management policy decision that a particular department is required or able to spend some amount of its total spending authority on that program. Programs may also be associated with headcount, capital resources, or other elements of a plan.
- a manager can carry out planning with respect to various programs. For example, associating programs with personnel (“heads”) enables a manager to determine the total headcount that is devoted to a particular program.
- one head is assignable to one program.
- one head may be assigned to more than one program, reflecting that the assigned individual will work on multiple programs.
- spending values associated with the head are divided among spending limit values of the assigned programs. For example, a salary value associated with the head is proportionally divided among the spending values for the assigned programs. Bonus values, commission values, healthcare insurance premiums, and any other value associated with a head likewise are divided among the assigned programs.
- Reports can display spending limit values by program, so that the total spending for a particular program, across all involved departments, is shown.
- FIG. 8A is a diagram of a program management screen display that may be generated, in one example embodiment.
- screen display 800 displays a list 802 of programs, each of which is identified by a hyper-link 804 that specifies the name of the program.
- a plurality of radio buttons 806 are provided for specifying a method of spreading spending amounts among multiple programs.
- spreading methods include a proportional spread, even spread, and headcount-driven spread.
- a proportional spread which may be selected with radio button 806 A
- department spending values are spread among a plurality of programs in the same proportion as that of the department values compared to the total spending for a plan.
- an even spread which may be selected with radio button 806 B
- the department spending values are divided equally among the programs.
- headcount-driven spread which may be selected with radio button 806 C
- the spending values of the assigned departments are spread among a plurality of programs according to the number of individuals in the departments.
- FIG. 8B is a diagram of a screen display that may be generated, in one embodiment.
- Screen display 820 comprises a Name field 822 that displays a program name corresponding to the selected hyperlink 804 , a Description field 824 that can receive a text description of the program, and a Code field 826 that can receive a project code for the program.
- Screen display 820 further comprises a table of department affiliations 830 that indicate which departments are participating in the program or are required to provide spending values for it.
- a department affiliations 830 that indicate which departments are participating in the program or are required to provide spending values for it.
- the user may select an Add Department link 834 and then select a department name from a pull-down menu.
- a user may add a program to list 802 by selecting an Add button 810 .
- financial management application 110 generates and provides an Add page that functions in a manner similar to the modification functions described herein with respect to FIG. 8B .
- FIG. 8C is a diagram of an example department headcount planning page illustrating records of individuals or “heads” in association with program identifiers.
- data is provided in a table 842 that comprises a plurality of rows 846 and columns 844 .
- Each row identifies an individual in a department; in the example of FIG. 8C , the department is “Instrumentation,” as indicated by label 843 .
- Program labels 844 A identify programs that are associated with individuals and rows.
- FIG. 8D is a screen display that may be generated, in one embodiment.
- Screen display 850 comprises data entry fields 852 that receive values relating to a particular individual who is identified in name fields 852 .
- a pull-down menu 854 identifies the program with which the individual is then currently associated.
- a user may modify the associated program by selecting a different program name using the pull-down menu 854 .
- FIG. 9A is a screen display showing an example private spending plan that may be used to access program-specific spending plan information.
- screen display 902 provides a spending plan 904 that comprises a plurality of account rows 906 and a plurality of spending limit data fields in columns that are associated with particular financial periods.
- the “Engineering Consulting” account 906 A has been planned with a value 908 of “25.0.”
- Each of the cells in the spending plan is a data entry field that may receive a plan value associated with the corresponding accounting period and account.
- the user may select the account 906 A, which is a hyperlink.
- financial management application 110 generates and provides a program-specific spending plan display.
- FIG. 9B is a diagram of an example of a program-specific spending plan display that may be generated, in one embodiment.
- a program-specific spending plan 920 comprises a table 921 having rows 922 that identify programs, and columns 924 that identify accounting periods.
- Table 921 further comprises a plurality of cells in the form of data entry fields that may receive spending plan values associated with programs and accounting periods.
- the program “IDC Atlanta” of row 922 A has received a plan value of “5.0,” referring to $5,000, for the accounting period September of fiscal year 2001.
- a total row 926 displays an account total for all programs in the Engineering Consulting account.
- total value 926 is equal to the column plan values of 5.0, 5.0, 5.0, and 10.0 that appear immediately above it.
- FIG. 10 is a diagram of an example of a program-specific report that may be generated, according to one embodiment.
- report 1000 comprises a label 1002 that identifies the report as program-specific, a plurality of rows 1004 that identify programs, and a plurality of data values 1006 that provide aggregate spending values for each program for a particular accounting period.
- Each of the data values 1006 relates to all spending for a program that has been identified by all departments in the enterprise, across all functional groups.
- a program-specific view of a spending plan is provided, enabling a manager to associate an aggregate spending value with a plurality of programs, without modifying the general ledger or other department hierarchy to add the program names. Reports that are organized based on programs provide a way to view spending data across functional departments.
- a financial management application is provided with mechanisms that enable the application to roll up numbers according to a plurality of alternative roll-up hierarchies.
- the mechanisms are based upon a hierarchical data model that includes the use of one or more data hierarchies. Any type or number of data hierarchies may be used depending upon the requirements of a particular application and the invention is not limited to any particular type or number of data hierarchies.
- embodiments of the invention are described hereinafter in the context of using a product data hierarchy and a customer data hierarchy.
- data hierarchies are each defined by a data hierarchy definition and a hierarchy elements definition.
- a data hierarchy definition defines and names each level in a data hierarchy.
- a hierarchy elements definition is an instance of a data hierarchy definition and as such, defines a particular data hierarchy that is defined by a data hierarchy definition.
- FIG. 11A is a block diagram that depicts a data hierarchy definition 1100 according to an embodiment.
- Data hierarchy definition 1100 defines a customer data hierarchy structure that includes four hierarchical levels: BUSINESS UNIT 1102 , BUSINESS GROUP 1104 , LOCATION 1106 and DEPARTMENT 1108 .
- Data hierarchy definition 1100 defines a tree structure where each hierarchical level is related to one or two other hierarchical levels as indicated by the connecting lines. It should be noted that although data hierarchy definition 1100 defines a particular data organization based upon particular attributes, other attributes might be used depending upon the requirements of a particular application. For example, a hierarchy could be organized by technology or size.
- FIG. 11B is a block diagram that depicts a hierarchy elements definition, i.e., a particular instance of data hierarchy definition 1100 .
- the example hierarchy elements definition of FIG. 11B comprises a root node designated as Corporate node 151 , which has R&D node 1152 , G&A node 1154 , and Sales node 1156 as immediate child nodes.
- the R&D node 1152 , G&A node 1154 , and Sales node 1156 are associated with roll-up departments. Alternatively, nodes at the same level may be associated with business units.
- the data for any particular forecast node may be determined from the data at all nodes below the particular node.
- a roll-up may be determined by starting at a leaf node, such as one of the departments of nodes 1172 , 1174 , 1162 , 1176 , etc., and conducting a pre-order walk of the hierarchy to a roll-up department node, or to the Corporate node 1151 .
- FIG. 11C illustrates an example of a secondary hierarchy that may be created based on the same nodes as shown in FIG. 11B .
- the hierarchy is based on geography.
- the top-level roll-up nodes are U.S. node 1182 , Europe node 1184 , and Asia node 1186 .
- R&D and G&A facilities and personnel are located in the U.S. whereas Europe and Asia only have sales and marketing organizations. Accordingly, all child and leaf nodes of R&D node 1152 and G&A node 1154 of FIG. 11B are rooted at U.S. node 1182 in FIG. 11C .
- FIG. 12 is a flow diagram illustrating an example method of creating a data roll-up using an alternate hierarchy.
- Block 1202 a primary hierarchy is established.
- Block 1202 may involve, for example, programmatically creating or using a user interface to create and store information representing and organized as a primary organization hierarchy.
- the hierarchy of FIG. 11B could be created.
- a primary hierarchy may be created by importing a data file that defines the hierarchy. The new hierarchy becomes the next-numbered hierarchy among a plurality of alternate hierarchies.
- financial management application 110 has a pre-defined maximum number of allowed alternate hierarchies, e.g., 20.
- Block 1204 a spending plan is established based on the primary hierarchy.
- Block 1204 may involve, for example, creating and storing a spending plan using financial management application 110 , wherein spending limit values are associated with departments of the primary hierarchy, and optionally with their projects or programs.
- FIG. 6A , FIG. 6B , and FIG. 9A show a user interface that may be generated by the financial management application 110 for the purpose of receiving user input data representing spending plan values. The values are created and stored in the plan in association with department values or other node values obtained from the primary hierarchy.
- an alternate hierarchy is created, by program action, based on user input, or based on a data file that contains a description of the alternate hierarchy.
- Block 1206 generally involves creating and storing parent nodes for the new alternate hierarchy.
- block 1208 nodes of the primary hierarchy are assigned to the alternate hierarchy.
- block 1208 involves storing data that associates a child node of the primary hierarchy with a parent node of the alternate hierarchy.
- block 1208 may be carried out by creating associations in database 112 among leaf nodes of the primary hierarchy of FIG. 11B to alternative roll-up nodes, resulting in a data representation of the alternate hierarchy of FIG. 11C .
- associations may be created programmatically or using an appropriate user interface.
- associations are created by launching financial management application 110 , selecting configuration functions 210 , and selecting a department management function.
- the application 110 generates a display of the primary hierarchy, in which each node of the primary hierarchy is a hyperlink.
- the application 110 When a user selects a hyperlink of a node, the application 110 generates and displays values of properties of the node.
- the properties include one or more assignments to parent nodes of other hierarchies. The user may then set or modify such assignments.
- one or more users are assigned to the alternate hierarchy. This action provides such assigned users with visibility of the alternate hierarchy.
- an administrator or other authorized user grants authorization to specific named users to the alternate hierarchy for specific operations.
- the authorization mechanism comprises retrieving a user profile, displaying a list of available departments, and providing user input that authorizes the user in the profile to have access to a selected department. Such authorization may involve specifying what operations the user is authorized to carry out, e.g., view, update, delete, etc.
- users may generate roll-ups or reports that provide spending values organized according to a defined alternate hierarchy or based on the primary hierarchy, as indicated by block 1212 .
- spending reports, headcount reports, capital asset and depreciation reports, etc. may be generated based on geographical location of departments, business unit organization, etc.
- generating a report based on an alternate hierarchy involves accessing a user interface screen that provides report options; selecting a report type; and selecting nodes to include in the report, where the selected nodes include nodes in the alternate hierarchy.
- a particular hierarchy is selected by name from a list of known or available hierarchies.
- the reports display spending plan values that are rolled-up based on the alternate hierarchy.
- such rolled-up values are generated by issuing one or more appropriate queries to database 112 associated with application 110 .
- the queries are created based on a pre-order walk of the alternate hierarchy tree from leaf nodes to root.
- An appropriate query is one that includes all leaf nodes of the alternate hierarchy.
- FIG. 13 is a block diagram that illustrates a computer system 1300 upon which an embodiment of the invention may be implemented.
- Computer system 1300 includes a bus 1302 or other communication mechanism for communicating information, and a processor 1304 coupled with bus 1302 for processing information.
- Computer system 1300 also includes a main memory 1306 , such as a random access memory (“RAM”) or other dynamic storage device, coupled to bus 1302 for storing information and instructions to be executed by processor 1304 .
- Main memory 1306 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 1304 .
- Computer system 1300 further includes a read only memory (“ROM”) 1308 or other static storage device coupled to bus 1302 for storing static information and instructions for processor 1304 .
- ROM read only memory
- a storage device 1310 such as a magnetic disk or optical disk, is provided and coupled to bus 1302 for storing information and instructions.
- Computer system 1300 may be coupled via bus 1302 to a display 1312 , such as a cathode ray tube (“CRT”), for displaying information to a computer user.
- a display 1312 such as a cathode ray tube (“CRT”)
- An input device 1314 is coupled to bus 1302 for communicating information and command selections to processor 1304 .
- cursor control 1316 is Another type of user input device
- cursor control 1316 such as a mouse, trackball, stylus, or cursor direction keys for communicating direction information and command selections to processor 1304 and for controlling cursor movement on display 1312 .
- This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.
- the invention is related to the use of computer system 1300 for providing automated control of spending plans.
- providing automated control of spending plans is provided by computer system 1300 in response to processor 1304 executing one or more sequences of one or more instructions contained in main memory 1306 .
- Such instructions may be read into main memory 1306 from another computer-readable medium, such as storage device 1310 .
- Execution of the sequences of instructions contained in main memory 1306 causes processor 1304 to perform the process steps described herein.
- hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention.
- embodiments of the invention are not limited to any specific combination of hardware circuitry and software.
- Non-volatile media includes, for example, optical or magnetic disks, such as storage device 1310 .
- Volatile media includes dynamic memory, such as main memory 1306 .
- Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 1302 . Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.
- Computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punchcards, papertape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.
- Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to processor 1304 for execution.
- the instructions may initially be carried on a magnetic disk of a remote computer.
- the remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem.
- a modem local to computer system 1300 can receive the data on the telephone line and use an infrared transmitter to convert the data to an infrared signal.
- An infrared detector can receive the data carried in the infrared signal and appropriate circuitry can place the data on bus 1302 .
- Bus 1302 carries the data to main memory 1306 , from which processor 1304 retrieves and executes the instructions.
- the instructions received by main memory 1306 may optionally be stored on storage device 1310 either before or after execution by processor 1304 .
- Computer system 1300 also includes a communication interface 1318 coupled to bus 1302 .
- Communication interface 1318 provides a two-way data communication coupling to a network link 1320 that is connected to a local network 1322 .
- communication interface 1318 may be an integrated services digital network (“ISDN”) card or a modem to provide a data communication connection to a corresponding type of telephone line.
- ISDN integrated services digital network
- communication interface 1318 may be a local area network (“LAN”) card to provide a data communication connection to a compatible LAN.
- LAN local area network
- Wireless links may also be implemented.
- communication interface 1318 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.
- Network link 1320 typically provides data communication through one or more networks to other data devices.
- network link 1320 may provide a connection through local network 1322 to a host computer 1324 or to data equipment operated by an Internet Service Provider (“ISP”) 1326 .
- ISP 1326 in turn provides data communication services through the worldwide packet data communication network now commonly referred to as the “Internet” 1328 .
- Internet 1328 uses electrical, electromagnetic or optical signals that carry digital data streams.
- the signals through the various networks and the signals on network link 1320 and through communication interface 1318 which carry the digital data to and from computer system 1300 , are exemplary forms of carrier waves transporting the information.
- Computer system 1300 can send messages and receive data, including program code, through the network(s), network link 1320 and communication interface 1318 .
- a server 1330 might transmit a requested code for an application program through Internet 1328 , ISP 1326 , local network 1322 and communication interface 1318 .
- one such downloaded application provides for providing automated control of spending plans as described herein.
- the received code may be executed by processor 1304 as it is received, and/or stored in storage device 1310 , or other non-volatile storage for later execution. In this manner, computer system 1300 may obtain application code in the form of a carrier wave.
- FIG. 14 is a block diagram of an example deployment architecture that may be used to implement the embodiments described herein.
- Financial Management application 110 is implemented as a Web-based application.
- An application user logs into the application 110 from a client 102 A using a Web browser 105 , such as Microsoft Internet Explorer.
- the application 110 resides as a servlet in an application server 1402 , such as Apache Tomcat, and is written in the Java programming language.
- the application server 1402 is accessed from a Web server such as the Apache web server, also represented by block 1402 .
- the application logic interprets a user request to view data, or update data, or import or export a file.
- a user request and the application's response are carried over the HTTP (or HTTPS) Internet protocol.
- the application logic involves accessing local memory, local files, or the application database, choosing an algorithm appropriate to the request, and returning a dynamically generated HTML page back to the user's browser.
- Certain application functions may be encoded in database-resident stored procedures rather than Java application logic.
- Application 110 comprises business logic 1406 , which implements program functions and provides an interface to data and metadata stored in database 112 , and a presentation layer 1404 that organizes output from the business logic for display by a browser or other client.
- the application server 1402 and associated Web server are communicatively coupled to presentation layer 1404 and business logic 1406 .
- the Web server, application server, and database server form a 3-tier architecture.
- Financial Management application 110 is an Internet-enabled application based on the Java® language and related platform elements, such as Java 2 Enterprise Edition (J2EE) elements.
- Java® language and related platform elements such as Java 2 Enterprise Edition (J2EE) elements.
- presentation layer 1404 and business logic 1406 preferably are implemented using Java.
- Database 112 may be based on standard relational databases such as Oracle 8i.
- Browser 105 displays HTML pages, such that Financial Management application 110 is not hardware specific.
- the elements of Financial Management application 110 shown in FIG. 14 execute in a two-processor X86/Linux or Sun Sparc/Solaris server.
- An additional two-processor server may execute the reporting server.
- Alert messages may be sent using e-mail, as well as using a messaging area within application 110 .
Abstract
Description
TABLE 1 |
EXAMPLE ALLOCATION MODEL |
ALLOCATION MODEL: FACILITIES |
Q4FY2001 | QIFY2002 |
DEPARTMENT | SPACE | PCT | SPACE | PCT |
AMERICAS SALES | 3,000 | 6.9% | 4,000 | 9.2% |
INSTRUMENTATION | 4,000 | 9.2% | 3,000 | 6.9% |
MFG ENGINEERING | 4,500 | 10.3% | 4,500 | 10.3% |
NEW PRODUCT MFG | 27,500 | 63.2% | 27,500 | 63.2% |
FINANCE | 3,000 | 6.9% | 3,000 | 6.9% |
QA | 1,500 | 3.4% | 1,500 | 3.4% |
TOTAL | 43,500 | 100% | 43,500 | 100% |
or
ASLV=100,000×(0.069)=6,900
TABLE 2 |
EXAMPLE SPENDING REPORT |
Corporate Spending Summary by Department |
FY2002-(USD ′000) |
DEPARTMENT | Q1 | Q2 | | Q4 | ||
FACILITIES |
0 | 0 | 0 | 0 | ||
FINANCE | 82.4 | 83.1 | 84.0 | 84.2 | |
|
0 | 0 | 0 | 0 | |
IS | 16.2 | 17.0 | 17.2 | 18.0 | |
Total for G & A BU | 98.6 | 100.1 | 101.2 | 102.2 | |
MFG ENGINEERING | 116.6 | 117.0 | 117.1 | 117.2 | |
NEW PROD ENG | 100.2 | 100.3 | 102.3 | 102.5 | |
QA | 80.3 | 80.5 | 81.0 | 82.0 | |
TEST | 54.0 | 54.5 | 51.0 | 55.0 | |
HR Allocation | 27.9 | 28.8 | 29.0 | 29.2 | |
Total for MFG BU | 379.0 | 381.1 | 380.4 | 385.9 | |
Claims (33)
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/969,140 US7966235B1 (en) | 2001-10-01 | 2001-10-01 | Method and apparatus providing automated control of spending plans |
AU2002330208A AU2002330208A1 (en) | 2001-10-01 | 2002-10-01 | Method and apparatus providing automated control of spending plans |
PCT/US2002/031515 WO2003029930A2 (en) | 2001-10-01 | 2002-10-01 | Method and apparatus providing automated control of spending plans |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/969,140 US7966235B1 (en) | 2001-10-01 | 2001-10-01 | Method and apparatus providing automated control of spending plans |
Publications (1)
Publication Number | Publication Date |
---|---|
US7966235B1 true US7966235B1 (en) | 2011-06-21 |
Family
ID=25515239
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/969,140 Active 2028-02-14 US7966235B1 (en) | 2001-10-01 | 2001-10-01 | Method and apparatus providing automated control of spending plans |
Country Status (3)
Country | Link |
---|---|
US (1) | US7966235B1 (en) |
AU (1) | AU2002330208A1 (en) |
WO (1) | WO2003029930A2 (en) |
Cited By (45)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070226130A1 (en) * | 2004-10-29 | 2007-09-27 | American Express Travel Related Services Co., Inc. A New York Corporation | Using commercial share of wallet to make lending decisions |
US20090171687A1 (en) * | 2007-12-31 | 2009-07-02 | American Express Travel Related Services Company, Inc. | Identifying Industry Passionate Consumers |
US20100023374A1 (en) * | 2008-07-25 | 2010-01-28 | American Express Travel Related Services Company, Inc. | Providing Tailored Messaging to Customers |
US20100293163A1 (en) * | 2009-05-15 | 2010-11-18 | Mclachlan Paul | Operational-related data computation engine |
US20120233547A1 (en) * | 2011-03-08 | 2012-09-13 | Apptio, Inc. | Platform for rapid development of applications |
US20120284067A1 (en) * | 2011-05-03 | 2012-11-08 | Intuit Inc. | Revenue-based impact analysis using multidimensional models of software offerings |
US8478673B2 (en) * | 2004-10-29 | 2013-07-02 | American Express Travel Related Services Company, Inc. | Using commercial share of wallet in private equity investments |
US8538869B1 (en) | 2012-02-23 | 2013-09-17 | American Express Travel Related Services Company, Inc. | Systems and methods for identifying financial relationships |
US20130246237A1 (en) * | 2012-03-15 | 2013-09-19 | Aptitude, Llc | Method, apparatus, and computer program product for purchase planning |
US8543499B2 (en) | 2004-10-29 | 2013-09-24 | American Express Travel Related Services Company, Inc. | Reducing risks related to check verification |
US8615458B2 (en) | 2006-12-01 | 2013-12-24 | American Express Travel Related Services Company, Inc. | Industry size of wallet |
US8694403B2 (en) | 2004-10-29 | 2014-04-08 | American Express Travel Related Services Company, Inc. | Using commercial share of wallet to rate investments |
US8766981B2 (en) | 2012-02-02 | 2014-07-01 | Apptio, Inc. | System and method for visualizing trace of costs across a graph of financial allocation rules |
US8781954B2 (en) | 2012-02-23 | 2014-07-15 | American Express Travel Related Services Company, Inc. | Systems and methods for identifying financial relationships |
US8781933B2 (en) | 2004-10-29 | 2014-07-15 | American Express Travel Related Services Company, Inc. | Determining commercial share of wallet |
US8788388B2 (en) | 2004-10-29 | 2014-07-22 | American Express Travel Related Services Company, Inc. | Using commercial share of wallet to rate business prospects |
US20140278807A1 (en) * | 2013-03-15 | 2014-09-18 | Cloudamize, Inc. | Cloud service optimization for cost, performance and configuration |
US20150088741A1 (en) * | 2013-09-25 | 2015-03-26 | Nathan Lyman | Spending Delegation |
WO2015177742A1 (en) * | 2014-05-21 | 2015-11-26 | Ibis Information Systems Pty Ltd | Method and system for visualising financial allocation models |
US9275050B2 (en) | 2011-10-24 | 2016-03-01 | Apptio, Inc. | Global dictionaries using universal primitives |
US9350561B1 (en) | 2015-05-27 | 2016-05-24 | Apptio, Inc. | Visualizing the flow of resources in an allocation model |
US9384511B1 (en) | 2015-12-16 | 2016-07-05 | Apptio, Inc. | Version control for resource allocation modeling |
US9477988B2 (en) | 2012-02-23 | 2016-10-25 | American Express Travel Related Services Company, Inc. | Systems and methods for identifying financial relationships |
US9529863B1 (en) | 2015-12-21 | 2016-12-27 | Apptio, Inc. | Normalizing ingested data sets based on fuzzy comparisons to known data sets |
US9754271B2 (en) | 2004-10-29 | 2017-09-05 | American Express Travel Related Services Company, Inc. | Estimating the spend capacity of consumer households |
JP2017168073A (en) * | 2016-03-15 | 2017-09-21 | 株式会社オービック | Consolidated budget formulation device, consolidated budget formulation method and consolidated budget formulation program |
US20180308138A1 (en) * | 2015-11-17 | 2018-10-25 | Nanjin Tangyi Digital Technology Co., Ltd | Data processing method and apparatus |
US20180322429A1 (en) * | 2017-05-05 | 2018-11-08 | Servicenow, Inc. | Graphical User Interface for Discovering Consumption of Services |
US10157356B2 (en) | 2016-12-14 | 2018-12-18 | Apptio, Inc. | Activity based resource allocation modeling |
US10268980B1 (en) | 2017-12-29 | 2019-04-23 | Apptio, Inc. | Report generation based on user responsibility |
US10268979B2 (en) * | 2015-09-28 | 2019-04-23 | Apptio, Inc. | Intermediate resource allocation tracking in data models |
US10324951B1 (en) | 2017-12-29 | 2019-06-18 | Apptio, Inc. | Tracking and viewing model changes based on time |
US10325232B2 (en) * | 2013-09-20 | 2019-06-18 | Apptio, Inc. | Allocating heritage information in data models |
US10387815B2 (en) | 2015-09-29 | 2019-08-20 | Apptio, Inc. | Continuously variable resolution of resource allocation |
US10417591B2 (en) | 2013-07-03 | 2019-09-17 | Apptio, Inc. | Recursive processing of object allocation rules |
US10474974B2 (en) | 2016-09-08 | 2019-11-12 | Apptio, Inc. | Reciprocal models for resource allocation |
US10482407B2 (en) | 2016-11-14 | 2019-11-19 | Apptio, Inc. | Identifying resource allocation discrepancies |
US10726367B2 (en) | 2015-12-28 | 2020-07-28 | Apptio, Inc. | Resource allocation forecasting |
US10726456B2 (en) | 2013-07-15 | 2020-07-28 | Aptitude, Llc | Method, apparatus, and computer program product for providing a virtual aggregation group |
US10936978B2 (en) | 2016-09-20 | 2021-03-02 | Apptio, Inc. | Models for visualizing resource allocation |
US10937036B2 (en) | 2012-11-13 | 2021-03-02 | Apptio, Inc. | Dynamic recommendations taken over time for reservations of information technology resources |
US11094016B1 (en) | 2016-05-04 | 2021-08-17 | Wells Fargo Bank, N.A. | Full balance sheet advisor |
US11151493B2 (en) | 2015-06-30 | 2021-10-19 | Apptio, Inc. | Infrastructure benchmarking based on dynamic cost modeling |
US11244364B2 (en) | 2014-02-13 | 2022-02-08 | Apptio, Inc. | Unified modeling of technology towers |
US11775552B2 (en) | 2017-12-29 | 2023-10-03 | Apptio, Inc. | Binding annotations to data objects |
Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5621201A (en) * | 1994-05-11 | 1997-04-15 | Visa International | Automated purchasing control system |
US5914472A (en) * | 1997-09-23 | 1999-06-22 | At&T Corp | Credit card spending authorization control system |
US6012044A (en) | 1997-12-10 | 2000-01-04 | Financial Engines, Inc. | User interface for a financial advisory system |
US6021943A (en) * | 1996-10-09 | 2000-02-08 | Chastain; Robert H. | Process for executing payment transactions |
US6029158A (en) | 1998-12-22 | 2000-02-22 | Ac Properties B.V. | System, method and article of manufacture for a simulation enabled feedback system |
US6073127A (en) | 1998-12-22 | 2000-06-06 | Ac Properties B.V. | System, method and article of manufacture for a goal based system with dynamic feedback information |
US6173269B1 (en) * | 1998-12-16 | 2001-01-09 | Zowi.Com, Inc | Method and apparatus for executing electronic commercial transactions with minors |
US20010041996A1 (en) | 1997-01-06 | 2001-11-15 | Eder Jeffrey Scott | Method of and system for valuing elements of a business enterprise |
JP2002092465A (en) | 2000-09-13 | 2002-03-29 | E Advisor Kk | Financial planning information providing device, financial planning information providing system, and financial planning information providing method |
US20020095363A1 (en) | 1999-11-01 | 2002-07-18 | Sloan Ronald E. | Financial planning and counseling system projecting user cash flow |
US20020111890A1 (en) | 1999-11-01 | 2002-08-15 | Sloan Ronald E. | Financial modeling and counseling system |
US20020133444A1 (en) | 2001-03-13 | 2002-09-19 | Sankaran Sarat C. | Interactive method and apparatus for real-time financial planning |
-
2001
- 2001-10-01 US US09/969,140 patent/US7966235B1/en active Active
-
2002
- 2002-10-01 AU AU2002330208A patent/AU2002330208A1/en not_active Abandoned
- 2002-10-01 WO PCT/US2002/031515 patent/WO2003029930A2/en not_active Application Discontinuation
Patent Citations (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5621201A (en) * | 1994-05-11 | 1997-04-15 | Visa International | Automated purchasing control system |
US6021943A (en) * | 1996-10-09 | 2000-02-08 | Chastain; Robert H. | Process for executing payment transactions |
US20010041996A1 (en) | 1997-01-06 | 2001-11-15 | Eder Jeffrey Scott | Method of and system for valuing elements of a business enterprise |
US5914472A (en) * | 1997-09-23 | 1999-06-22 | At&T Corp | Credit card spending authorization control system |
US6012044A (en) | 1997-12-10 | 2000-01-04 | Financial Engines, Inc. | User interface for a financial advisory system |
US6173269B1 (en) * | 1998-12-16 | 2001-01-09 | Zowi.Com, Inc | Method and apparatus for executing electronic commercial transactions with minors |
US6073127A (en) | 1998-12-22 | 2000-06-06 | Ac Properties B.V. | System, method and article of manufacture for a goal based system with dynamic feedback information |
US6029158A (en) | 1998-12-22 | 2000-02-22 | Ac Properties B.V. | System, method and article of manufacture for a simulation enabled feedback system |
US20020095363A1 (en) | 1999-11-01 | 2002-07-18 | Sloan Ronald E. | Financial planning and counseling system projecting user cash flow |
US20020111890A1 (en) | 1999-11-01 | 2002-08-15 | Sloan Ronald E. | Financial modeling and counseling system |
JP2002092465A (en) | 2000-09-13 | 2002-03-29 | E Advisor Kk | Financial planning information providing device, financial planning information providing system, and financial planning information providing method |
US20020133444A1 (en) | 2001-03-13 | 2002-09-19 | Sankaran Sarat C. | Interactive method and apparatus for real-time financial planning |
WO2002073365A2 (en) | 2001-03-13 | 2002-09-19 | Closedloop Solutions, Inc. | Interactive method and apparatus for real-time financial planning |
Cited By (60)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8682770B2 (en) | 2004-10-29 | 2014-03-25 | American Express Travel Related Services Company, Inc. | Using commercial share of wallet in private equity investments |
US8775301B2 (en) | 2004-10-29 | 2014-07-08 | American Express Travel Related Services Company, Inc. | Reducing risks related to check verification |
US8788388B2 (en) | 2004-10-29 | 2014-07-22 | American Express Travel Related Services Company, Inc. | Using commercial share of wallet to rate business prospects |
US8781933B2 (en) | 2004-10-29 | 2014-07-15 | American Express Travel Related Services Company, Inc. | Determining commercial share of wallet |
US8694403B2 (en) | 2004-10-29 | 2014-04-08 | American Express Travel Related Services Company, Inc. | Using commercial share of wallet to rate investments |
US20070226130A1 (en) * | 2004-10-29 | 2007-09-27 | American Express Travel Related Services Co., Inc. A New York Corporation | Using commercial share of wallet to make lending decisions |
US8478673B2 (en) * | 2004-10-29 | 2013-07-02 | American Express Travel Related Services Company, Inc. | Using commercial share of wallet in private equity investments |
US8744944B2 (en) * | 2004-10-29 | 2014-06-03 | American Express Travel Related Services Company, Inc. | Using commercial share of wallet to make lending decisions |
US9754271B2 (en) | 2004-10-29 | 2017-09-05 | American Express Travel Related Services Company, Inc. | Estimating the spend capacity of consumer households |
US8543499B2 (en) | 2004-10-29 | 2013-09-24 | American Express Travel Related Services Company, Inc. | Reducing risks related to check verification |
US8775290B2 (en) | 2004-10-29 | 2014-07-08 | American Express Travel Related Services Company, Inc. | Using commercial share of wallet to rate investments |
US8630929B2 (en) * | 2004-10-29 | 2014-01-14 | American Express Travel Related Services Company, Inc. | Using commercial share of wallet to make lending decisions |
US20140172686A1 (en) * | 2004-10-29 | 2014-06-19 | American Express Travel Related Services Company, Inc. | Using commercial share of wallet to make lending decisions |
US10360575B2 (en) | 2004-10-29 | 2019-07-23 | American Express Travel Related Services Company, Inc. | Consumer household spend capacity |
US8615458B2 (en) | 2006-12-01 | 2013-12-24 | American Express Travel Related Services Company, Inc. | Industry size of wallet |
US20090171687A1 (en) * | 2007-12-31 | 2009-07-02 | American Express Travel Related Services Company, Inc. | Identifying Industry Passionate Consumers |
US20100023374A1 (en) * | 2008-07-25 | 2010-01-28 | American Express Travel Related Services Company, Inc. | Providing Tailored Messaging to Customers |
US8768976B2 (en) | 2009-05-15 | 2014-07-01 | Apptio, Inc. | Operational-related data computation engine |
US20100293163A1 (en) * | 2009-05-15 | 2010-11-18 | Mclachlan Paul | Operational-related data computation engine |
US20120233547A1 (en) * | 2011-03-08 | 2012-09-13 | Apptio, Inc. | Platform for rapid development of applications |
US9020830B2 (en) | 2011-03-08 | 2015-04-28 | Apptio, Inc. | Hierarchy based dependent object relationships |
US9305275B2 (en) * | 2011-03-08 | 2016-04-05 | Apptio, Inc. | Platform for rapid development of applications |
US20120284067A1 (en) * | 2011-05-03 | 2012-11-08 | Intuit Inc. | Revenue-based impact analysis using multidimensional models of software offerings |
US9275050B2 (en) | 2011-10-24 | 2016-03-01 | Apptio, Inc. | Global dictionaries using universal primitives |
US8766981B2 (en) | 2012-02-02 | 2014-07-01 | Apptio, Inc. | System and method for visualizing trace of costs across a graph of financial allocation rules |
US8781954B2 (en) | 2012-02-23 | 2014-07-15 | American Express Travel Related Services Company, Inc. | Systems and methods for identifying financial relationships |
US8538869B1 (en) | 2012-02-23 | 2013-09-17 | American Express Travel Related Services Company, Inc. | Systems and methods for identifying financial relationships |
US11276115B1 (en) | 2012-02-23 | 2022-03-15 | American Express Travel Related Services Company, Inc. | Tradeline fingerprint |
US9477988B2 (en) | 2012-02-23 | 2016-10-25 | American Express Travel Related Services Company, Inc. | Systems and methods for identifying financial relationships |
US10497055B2 (en) | 2012-02-23 | 2019-12-03 | American Express Travel Related Services Company, Inc. | Tradeline fingerprint |
US20130246237A1 (en) * | 2012-03-15 | 2013-09-19 | Aptitude, Llc | Method, apparatus, and computer program product for purchase planning |
US10937036B2 (en) | 2012-11-13 | 2021-03-02 | Apptio, Inc. | Dynamic recommendations taken over time for reservations of information technology resources |
US20140278807A1 (en) * | 2013-03-15 | 2014-09-18 | Cloudamize, Inc. | Cloud service optimization for cost, performance and configuration |
US10417591B2 (en) | 2013-07-03 | 2019-09-17 | Apptio, Inc. | Recursive processing of object allocation rules |
US10726456B2 (en) | 2013-07-15 | 2020-07-28 | Aptitude, Llc | Method, apparatus, and computer program product for providing a virtual aggregation group |
US10325232B2 (en) * | 2013-09-20 | 2019-06-18 | Apptio, Inc. | Allocating heritage information in data models |
US10032159B2 (en) * | 2013-09-25 | 2018-07-24 | Paypal, Inc. | Spending delegation |
US20150088741A1 (en) * | 2013-09-25 | 2015-03-26 | Nathan Lyman | Spending Delegation |
US11244364B2 (en) | 2014-02-13 | 2022-02-08 | Apptio, Inc. | Unified modeling of technology towers |
WO2015177742A1 (en) * | 2014-05-21 | 2015-11-26 | Ibis Information Systems Pty Ltd | Method and system for visualising financial allocation models |
US9350561B1 (en) | 2015-05-27 | 2016-05-24 | Apptio, Inc. | Visualizing the flow of resources in an allocation model |
US11151493B2 (en) | 2015-06-30 | 2021-10-19 | Apptio, Inc. | Infrastructure benchmarking based on dynamic cost modeling |
US10268979B2 (en) * | 2015-09-28 | 2019-04-23 | Apptio, Inc. | Intermediate resource allocation tracking in data models |
US10387815B2 (en) | 2015-09-29 | 2019-08-20 | Apptio, Inc. | Continuously variable resolution of resource allocation |
US20180308138A1 (en) * | 2015-11-17 | 2018-10-25 | Nanjin Tangyi Digital Technology Co., Ltd | Data processing method and apparatus |
US9384511B1 (en) | 2015-12-16 | 2016-07-05 | Apptio, Inc. | Version control for resource allocation modeling |
US9529863B1 (en) | 2015-12-21 | 2016-12-27 | Apptio, Inc. | Normalizing ingested data sets based on fuzzy comparisons to known data sets |
US10726367B2 (en) | 2015-12-28 | 2020-07-28 | Apptio, Inc. | Resource allocation forecasting |
JP2017168073A (en) * | 2016-03-15 | 2017-09-21 | 株式会社オービック | Consolidated budget formulation device, consolidated budget formulation method and consolidated budget formulation program |
US11094016B1 (en) | 2016-05-04 | 2021-08-17 | Wells Fargo Bank, N.A. | Full balance sheet advisor |
US11587175B1 (en) | 2016-05-04 | 2023-02-21 | Wells Fargo Bank, N.A. | Full balance sheet advisor |
US10474974B2 (en) | 2016-09-08 | 2019-11-12 | Apptio, Inc. | Reciprocal models for resource allocation |
US10936978B2 (en) | 2016-09-20 | 2021-03-02 | Apptio, Inc. | Models for visualizing resource allocation |
US10482407B2 (en) | 2016-11-14 | 2019-11-19 | Apptio, Inc. | Identifying resource allocation discrepancies |
US10157356B2 (en) | 2016-12-14 | 2018-12-18 | Apptio, Inc. | Activity based resource allocation modeling |
US11087256B2 (en) * | 2017-05-05 | 2021-08-10 | Servicenow, Inc. | Graphical user interface for discovering consumption of services |
US20180322429A1 (en) * | 2017-05-05 | 2018-11-08 | Servicenow, Inc. | Graphical User Interface for Discovering Consumption of Services |
US10324951B1 (en) | 2017-12-29 | 2019-06-18 | Apptio, Inc. | Tracking and viewing model changes based on time |
US10268980B1 (en) | 2017-12-29 | 2019-04-23 | Apptio, Inc. | Report generation based on user responsibility |
US11775552B2 (en) | 2017-12-29 | 2023-10-03 | Apptio, Inc. | Binding annotations to data objects |
Also Published As
Publication number | Publication date |
---|---|
AU2002330208A1 (en) | 2003-04-14 |
WO2003029930A2 (en) | 2003-04-10 |
WO2003029930A3 (en) | 2003-10-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7966235B1 (en) | Method and apparatus providing automated control of spending plans | |
US7657471B1 (en) | Method and apparatus providing automated financial plan controls | |
US8433632B2 (en) | Interactive method and apparatus for real-time financial | |
US7761324B2 (en) | Forecasting and revenue management system | |
US8799039B2 (en) | System and method for collecting and providing resource rate information using resource profiling | |
US7729935B2 (en) | Method and apparatus for managing workflow | |
US8671036B2 (en) | User interface for defining account dimension combinations | |
JP4652418B2 (en) | System and method for enterprise wide policy management | |
US20030115207A1 (en) | Hierarchical hybrid OLAP analytics generators | |
US20030061225A1 (en) | Hierarchical hybrid OLAP scenario management system | |
US7516084B1 (en) | Approach for managing forecast data | |
US20060143220A1 (en) | Software application framework using meta-data defined object definitions | |
US20050027651A1 (en) | Transaction workflow and data collection system | |
US20020161602A1 (en) | Methods and systems for identifying prospective customers and managing deals | |
US20020169650A1 (en) | Methods and systems for identifying prospective customers and managing deals | |
US20080066067A1 (en) | Enterprise performance management software system having action-based data capture | |
US20030061246A1 (en) | Hierarchical hybrid online analytical processing services system | |
US20070143175A1 (en) | Centralized model for coordinating update of multiple reports | |
US20060184422A1 (en) | Method and apparatus for accessing transaction data in a travel settlement system using a graphical user interface | |
US7644009B2 (en) | Method for forecasting and revenue management | |
CA2772824C (en) | Role mapping and training tool | |
US9135587B2 (en) | Methods and systems for creating business-oriented report entities | |
US20100333106A1 (en) | Reorganization process manager | |
US20230237396A1 (en) | System with capacity and resource allocation display to facilitate update of electronic record information | |
US20030061226A1 (en) | Data loader for handling imperfect data and supporting multiple servers and data sources |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: CLOSEDLOOP SOLUTIONS, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:CAPELLI, NANCY B.;CHANDRAN, RAJESH;FULORIA, PRASHANT;AND OTHERS;REEL/FRAME:012510/0971 Effective date: 20011220 |
|
AS | Assignment |
Owner name: SILICON VALLEY BANK, CALIFORNIA Free format text: SECURITY INTEREST;ASSIGNOR:CLOSEDLOOP SOLUTIONS, INC.;REEL/FRAME:015195/0001 Effective date: 20030904 |
|
AS | Assignment |
Owner name: LAWSON SOFTWARE, INC., MINNESOTA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:CLOSEDLOOP SOLUTIONS, INC.;REEL/FRAME:015264/0617 Effective date: 20040419 |
|
AS | Assignment |
Owner name: SILICON VALLEY BANK, CALIFORNIA Free format text: SECURITY AGREEMENTS;ASSIGNOR:CLOSEDLOOP SOLUTIONS, INC.;REEL/FRAME:015138/0902 Effective date: 20030904 |
|
FEPP | Fee payment procedure |
Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
AS | Assignment |
Owner name: CLOSEDLOOP SOLUTIONS, INC., CALIFORNIA Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:SILICON VALLEY BANK;REEL/FRAME:026592/0415 Effective date: 20110714 |
|
AS | Assignment |
Owner name: CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH, NEW YORK Free format text: PATENT SECURITY AGREEMENT;ASSIGNOR:LAWSON SOFTWARE, INC.;REEL/FRAME:026609/0722 Effective date: 20110705 |
|
AS | Assignment |
Owner name: LAWSON SOFTWARE INC., MINNESOTA Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:027997/0553 Effective date: 20120405 |
|
AS | Assignment |
Owner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTH Free format text: SECURITY AGREEMENT;ASSIGNOR:LAWSON SOFTWARE, INC.;REEL/FRAME:028078/0594 Effective date: 20120405 |
|
FEPP | Fee payment procedure |
Free format text: PAYER NUMBER DE-ASSIGNED (ORIGINAL EVENT CODE: RMPN); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YR, SMALL ENTITY (ORIGINAL EVENT CODE: M2552) Year of fee payment: 8 |
|
AS | Assignment |
Owner name: INFOR (US), INC., GEORGIA Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:BANK OF AMERICA, N.A.;REEL/FRAME:053314/0436 Effective date: 20200529 Owner name: INFOR GLOBAL SOLUTIONS (MICHIGAN), INC., GEORGIA Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:BANK OF AMERICA, N.A.;REEL/FRAME:053314/0436 Effective date: 20200529 Owner name: GT NEXUS, INC., GEORGIA Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:BANK OF AMERICA, N.A.;REEL/FRAME:053314/0436 Effective date: 20200529 Owner name: LAWSON SOFTWARE, INC., MINNESOTA Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:BANK OF AMERICA, N.A.;REEL/FRAME:053314/0436 Effective date: 20200529 |
|
AS | Assignment |
Owner name: INFOR (US), INC., NEW YORK Free format text: CHANGE OF NAME;ASSIGNOR:LAWSON SOFTWARE, INC.;REEL/FRAME:055986/0127 Effective date: 20120701 |
|
AS | Assignment |
Owner name: INFOR (US), LLC, NEW YORK Free format text: CHANGE OF NAME;ASSIGNOR:INFOR (US), INC.;REEL/FRAME:056048/0944 Effective date: 20201101 |
|
FEPP | Fee payment procedure |
Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY |
|
FEPP | Fee payment procedure |
Free format text: 11.5 YR SURCHARGE- LATE PMT W/IN 6 MO, LARGE ENTITY (ORIGINAL EVENT CODE: M1556); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 12 |