Method of and system for generating feasible, profit maximizing requisition sets5615109Abstract In a computer based inventory control method and system, feasible profit maximizing sets of requisitions are created. System processing starts with the creation of detailed, multi-dimensional forecasts of sales and cash receipts using stored algorithms and data preferentially extracted from a basic financial system and the adjustment of the forecasts to match the controlling forecast specified by the user. The adjustment of the forecasts is facilitated by the use of a calculated variable that defines the magnitude of the relative adjustment for each forecast element. All forecasts are adjusted to exactly match a controlling forecast which is either a multivalent combination of the previously generated forecasts or the user specified controlling forecast. The adjusted forecast of sales by item is then used in calculating a requisition set that satisfies expected demand while meeting user specified service level targets. A profit maximized requisition set is then created that utilizes vendor and unit of measure substitution under a variety of discount schedules to the extent possible within the user specified constraints. The processing completed by the system to determine the profit maximizing requisition set utilizes multi-objective, mixed-integer, linear programming techniques. A financial forecast is then calculated and displayed to determine if purchasing the profit maximizing requisition set will be feasible under the forecast financial conditions. Once the constraints and/or forecasts are adjusted as required to produce a feasible solution, processing advances to the profit enhancement stage where overall financial constraints are established and user specified constraints on commitment percentages, global unit of measure substitution and global vendor substitution are optionally relaxed and profit enhancing changes are calculated, stored and displayed. The user optionally accepts displayed enhancements and the financial forecast is recalculated to demonstrate the impact of the accepted changes before the requisitions are modified to reflect the accepted enhancements. Claims I claim: Description BACKGROUND OF THE INVENTION
TABLE 1
______________________________________
As-Ordered Discount Schedule
Vendor A Vendor B
______________________________________
$0-$20,000 0 0
$20,001-$50,000 0 5%
over $50,000 2% 6%
______________________________________
The second type of business-volume discount schedule is typically based on the customer's commitment to purchase a specified volume of a product during a specified time period. The commitment-basis discount schedules typically come in two segments. First, the customer is given a different base price schedule for items purchased when a commitment to buy a certain quantity of the item has been made. The base prices on the commitment-basis price schedule often contain discounts from the as-ordered base prices as shown in Table 2.
TABLE 2
______________________________________
As-Ordered
Vendor-Product
Commitment Base Price
Base Price
______________________________________
Vendor A - Widget
$20.00 $21.00
Vendor A - Carton
$5.00 $5.00
Vendor B - Widget
$20.50 $22.00
Vendor B - Carton
$4.50 $5.00
______________________________________
Once the customer has purchased a certain amount on a commitment basis, all subsequent orders for that item during the relevant time period will be priced at the commitment price and the customer is said to have "locked in" the commitment price. The second element of the commitment-basis discount is typically a percentage discount based on the cumulative total of commitment purchases made during the relevant time period. An example of this type of commitment-basis discount schedule is shown in Table 3.
TABLE 3
______________________________________
Commitment Discount Schedule
Vendor A Vendor B
______________________________________
$0-$10,000 0 0
$10,001-$25,000 1% 2%
$25,001-$50,000 2% 4%
$50,001-$100,000 3% 6%
over $100,000 5% 8%
______________________________________
In this environment a customer would have four different possible prices for the purchase of five hundred (500) widgets from the two different business volume discount vendors as shown in Table 4.
TABLE 4
______________________________________
Vendor A
Vendor B
______________________________________
Year to date actual as-ordered
$7,012 $19.553
volume - total
Current as-ordered discount percentage
0% 0%
Widget commitment price locked in?
YES NO
Widget base price as-ordered
$20.00 $22.00
Cost for 500 widgets - as-ordered
$10,000 $10,472
Year to date actual committed
$28,119 $67,328
purchases - total
Current commitment-basis
2% 6%
discount percentage
Widget commitment-basis price
$20.00 $20.50
Cost for 500 widgets - commit-
$9,800 $9,635
ment-basis
______________________________________
It is clear from the preceding example that the business volume discount schedules can severely complicate a purchase order decision. In the example shown above the lowest cost alternative for the company is to order from Vendor B on a commitment basis. Thus we see that a customer would have to evaluate the quantity commitments to two vendors, closely monitor the year to date volume for each vendor and evaluate up to four different prices from the two different vendors before placing a single order for a single item. It is also clear from the preceding example that the task of consistently determining the best purchase options for even a small commercial enterprise stocking only a few hundred items can be a daunting task. It is important to note here that the level of complexity shown in this example has been simplified as it ignores the complications that would be introduced by considering different units of measure from the different vendors. Because of the complexity and risk associated with the inventory management task, it is not uncommon for companies to have several personnel in an operations or purchasing department dedicated to planning, purchasing and controlling inventory investments. In performing their various job functions the operations/purchasing personnel in larger companies typically utilize several different computer based systems for: forecasting demand, planning purchase orders or manufacturing work orders, monitoring the quality and quantity of the items received in the warehouse, tracking returned goods, placing purchase orders, controlling inventory, monitoring costs and entering sales orders. In smaller companies the management of inventory is often accomplished through the use of informal and paper based systems. In some cases the informal systems and the larger "formal" systems are supplemented by microcomputer based spreadsheet programs. In all cases, the goal of the operations/purchasing department is to have the required items in inventory available for sale when the customer orders the product while keeping the investment in inventory as low as possible. Because inventory is typically the largest component of working capital for companies in the retail, manufacturing and distribution industries, the importance of efficiently managing inventory can not be overemphasized. The significance of effective inventory management practices is particularly high for the small companies that comprise the fastest growing segment of the modem American economy. These small firms typically don't have the working capital required to withstand large mistakes in inventory management. Compelling evidence of the importance of effective inventory management practices is found in the Dun & Bradstreet Business Failure Record that shows inventory investment problems are one of the leading causes of business failure for retail, manufacturing and distribution companies. It is clear from the preceding discussion that a system that helps companies effectively manage inventory could enhance both the short-term financial results and the long-term survival prospects of many companies. PRIOR ART To help address some aspects of the complex inventory management problem, inventors have previously created systems for determining the most cost effective method for procuring items under idealized conditions. U.S. Pat. No. 5,224,034 to Katz and Sedrian (1993) discloses an automated system for generating procurement lists that uses linear programming optimization algorithms to generate lists showing the annual volume of each product that is to be purchased from each of the different vendors offering business volume discounts to minimize the cost of acquiring the user specified annual volume. There are several drawbacks and limitations inherent in a system of this type including: (a) Constantly changing business conditions require that all item forecasts be updated frequently and accurately if the system is to provide truly useful output. Because the system is highly specialized, completing these data inputs requires the error-prone, time consuming and costly conversion of data to the format required by the separate inventory optimization system; (b) After completing the conversion of data to the system required format, the user is then faced with the costly and time consuming task of re-keying or transferring the data into the separate system; (c) The specialized, technical nature of the system generally requires the use of a highly-skilled, trained operator to run the systems effectively; (d) The outputs from the system need to be transferred into the purchasing and/or accounting systems before they can be fully utilized. This transfer often entails the error-prone, time consuming and costly conversion and re-keying of data; (e) The system has no provision for assuring that the company using the system will have the financial resources required to acquire the items identified on the procurement lists. It does little good to optimize plans for committed and as-ordered purchases if the company will not have sufficient funds to pay for the items ordered when the bills come due; (f) The determination of optimized inventory purchases is implicitly viewed as an exercise that is separate from the determination of financial constraints (if any) when in fact the two are tightly interrelated. The resources that a company will have available for making future purchases is in part dependent on the discounts it has received for the purchases it has previously made. At the same time, the discounts that a company will receive is a function of the size of the purchases that it can afford to commit to and/or make without running short of funds; (g) The system has no facility for effectively assessing the impact of impending obsolescence on plans for procuring items. The program may recommend an increase in the purchase quantity for an item from a vendor who is expected to introduce a new version in the near future. The new version could render the older versions of the item obsolete and the cost of writing off the obsolete inventory could very easily outweigh the cost savings realized by optimizing the purchase mix and order quantities; (h) A limitation that is closely related to the shortcoming discussed in item (g) is that the system has no capability for handling planned product obsolescence. For example, even if it is known that a product is to be phased out on a given date and a new product is to take its place, there is no mechanism available to manage the transition; (i) The system is severely limited in its usefulness as it only optimizes the mix of items purchased under business volume discount regimes. Most companies have more than one type of discount available from their different vendors. Indeed, some vendors offer more than one type of discount. The discount options may include: quantity discounts for individual items, volume discounts based on the total committed volume or volume discounts based on the total ordered volume or some combination of the two or on purchases of specific product mixes or product combinations. As a result, companies that were seeking to optimize the purchase of all of their products would be forced to incur the time, effort and expense required to install and maintain multiple inventory optimization systems; (j) The system only minimizes the cost of purchasing items forecast by the user under the user-defined constraints. In some cases the user-defined constraints impose artificial limitations on the solutions developed by the system. Limiting the system to purchase only the commitment levels and quantities forecast by the user is an artificial constraint that generally has no basis in reality. In reality, the suppliers (internal or external) can probably provide whatever quantities the user chooses to order and can afford to pay for. In some cases ordering more than the forecast requirements can produce significant savings. As shown in the following example, committing $10 more than permitted under the user specified constraints to a specific vendor would increase pre-tax profitability by $40,000:
______________________________________
Committed $ Volume
Discount %
______________________________________
$0 to $999,999 0
$1 M to $1,999,999
2
$2 M to 2,999,999 4
______________________________________
Total 12 month $ Volume Forecast Vendor A=$2,499,987.50 Maximum percentage of forecast volume that can be committed=80% Vendor A Dollar Commitment=$1,999,990.00 Increase in discount percentage from increasing commitment by $10=2% Savings from increased discount=$2,000,000.times.2%=$40,000 This enormous potential profit would not be highlighted to the user by a system that simply minimized costs within the constraints established by the user. Clearly, a system that isn't artificially restricted to solutions that include the forecast item demand limitations can provide substantial benefits to the user; (k) The system only minimizes costs and doesn't maximize the profitability of the firm using the system. The primary goal of most firms is not to minimize costs rather it is to realize as large a profit as possible. The example shown below illustrates how significant this change in focus can be when combined with the removal of the artificial constraints discussed in item (j). Consider a profit maximization model with three products and three resources. A traditional linear programming model for the specific situation would be: Maximize profit: p=80x.sub.1 +32x.sub.2 +57.6x.sub.3 Subject to: 6.4x.sub.1 +4.82x.sub.2 +3.84x.sub.3 .ltoreq.1,280 (resource 1) 3.2x.sub.1 +4.8x.sub.2 +6.4x.sub.3 .ltoreq.1,600 (resource 2) 3.2x.sub.1 +3.2x.sub.2 +3.2x.sub.3 .ltoreq.960 (resource 3) x.sub.1, x.sub.2, x.sub.3 .gtoreq.0 Using the simplex method, the optimal solution is reached at x.sub.1 =228.576, x.sub.2 =0.0, x.sub.3 =685.728 and p=$57,784.01. If the prices of the resources were s.sub.1 =$20, s.sub.2 32 $10 and s.sub.3 =$40 we can use the above constraints to determine the maximum amount that can be purchased: 1,280($20)+1,600($10)+960($40)=$80,000. If the above problem were changed to the multiple criteria, De-Novo maximization formulation to remove the artificial constraints on purchasing resources, it would appear as shown below: Maximize profit: p=80x.sub.1 +32x.sub.2 +57.6x.sub.3 Subject to: 2x.sub.1 +1.5x.sub.2 +1.2x.sub.3 .ltoreq.x.sub.4 (resource 1) x.sub.1 +1.5x.sub.2 +2x.sub.3 .ltoreq.x.sub.5 (resource 2) x.sub.1 +x.sub.2 +x.sub.3 .ltoreq.x.sub.6 (resource 3) 20x.sub.1 +10x.sub.2 +40x.sub.3 .ltoreq.80,000 (budget) x.sub.1, x.sub.2, x.sub.3, x.sub.4, x.sub.5, x.sub.6 .gtoreq.0 Solving the above yields the following optimal solution: x.sub.1 =888.896, x.sub.4 =1,777.792, x.sub.5 =888.896, x.sub.6 =888.896 and p=$71,111.68. The optimal solution from this formulation is substantially different from the previous formulation and it has a profit level 23% higher than the one produced by the linear programming model. Clearly, there can be substantial benefits to changing the focus to profit maximization rather than cost minimization while removing constraints that artificially limit the potential solutions; The next ten (10) shortcomings and limitations of the present system would all contribute to a decision to establish another separate system dedicated to inventory management. This inventory management system would provide the required forecasts, target inventory levels, requisition quantities, requisition dates, stock-out probabilities and projected stock-out costs in a consistent and efficient manner. However, to realize these benefits the user would be required to incur the time, effort and expense associated with setting up and maintaining a separate system for monitoring inventory usage, developing forecasts and managing inventory. The user would also be faced with the costly and time consuming task of re-keying or transferring data into and out of the separate inventory management system. (l) The system has no simple mechanism for allowing the user to restrict the purchase of an item to a particular vendor. It is not uncommon for a user to have strategic or qualitative reasons for choosing one vendor over another in the purchase of a specific item--even if the price for buying from that vendor is higher. Restricting vendor selection for an item using the system described by Katz & Sedrian would require the user to develop a constraint and enter it into the specialized system before processing begins; (m) The system has no provision for allowing the user to order items using different units of measure. It is commonplace for a vendor to offer items in different units of measure with different price schedules. If the user wishes to order product using a different unit of measure, then he or she will be forced to go through the costly, time consuming and error-prone effort to convert the procurement lists that have already been created using a different unit of measure. If lower prices are offered for different units of measure that weren't considered, it is entirely possible that the solution developed by the system would not be the lowest cost solution; (n) The effectiveness of the system in planning the purchases required to keep the proper items stocked in inventory is completely dependent on the demand forecasts developed and input to the system by the user; (o) The system is limited to planning purchases one year at a time for all business volume items. Because the system doesn't have the ability to analyze shorter or longer forecast time periods, the user will be required to work with another system to address inventory planning needs for any time period other than a year; (p) The system only determines the annual quantity mix by vendor for the items, the actual dates and order quantities are not determined for any item. The user is required to go through an additional time consuming exercise of determining how large the orders should be and when to place orders; (q) The system doesn't consider service levels (e.g., fill rate targets where a 95% fill rate is defined to mean that 95% of the total annual demand for an item is supplied by inventory from stock) and demand variability when determining the annual purchase quantities. Ignoring these factors can leave the commercial enterprise using the system vulnerable to inventory stock-outs. Any inventory stock-out would probably cause lost profits for the business when the consumer purchases the item from another supplier that has the item in stock. The example presented in Tables 5, 6 and 7 illustrates the impact of different levels of item demand variability on the available inventory of two different items with the same total forecast demand, the same average monthly demand and the same fill rate targets.
TABLE 5
______________________________________
Monthly Demand Part A Part B
______________________________________
Last month 100 55
Two months ago 100 0
Three months ago 100 100
Four months ago 100 20
Five months ago 100 115
Six months ago 100 95
Seven months ago 100 15
Eight months ago 100 0
Nine months ago 100 500
Ten months ago 100 0
Eleven months ago 100 0
Twelve months ago 100 300
Total 12 Month Demand
1,200 1,200
Average Monthly Demand
100 100
Sample Standard Deviation
0 152.5
______________________________________
A system that didn't address the differences caused by the different demand patterns of the two items would use the same re-order level for each item. The re-order level for the parts can be calculated as shown below: Reorder Level Part A=(100 units/month.times.2 months lead time)=200 As shown in Table 7, if the same re-order level were used for both items and the demand pattern from the prior year was repeated, then the available inventory during the coming year for these two parts would be quite different.
TABLE 7
__________________________________________________________________________
Start Inv
Part A
A Order
End Inv
Qty A
Start Inv
Part B
B Order
End Inv
Qty B
Month
Part A
Demand
Receipt
Part A
Ordered
Par B
Demand
Receipt
Part B
Ordered
__________________________________________________________________________
1 300 100 0 200 450 300 300 0 0 450
2 200 100 0 100 0 0 0 0 0 0
3 100 100 450 450 0 0 0 450 450 0
4 450 100 0 350 0 450 500 0 -50*
450
5 350 100 0 250 0 -50*
0 0 -50*
0
6 250 100 0 150 450 -50*
15 450 385 0
7 150 100 0 50 0 385 95 0 290 0
8 50 100 450 400 0 290 115 0 175 450
9 400 100 0 300 0 175 20 0 155 0
10 300 100 0 200 450 155 100 450 505 0
11 200 100 0 100 0 505 0 0 505 0
12 100 100 450 450 0 505 55 0 450 0
Total 1,200
1,350 1,350 1,200
1,350 1,350
__________________________________________________________________________
*negative inventory represents a backorder
As shown above, if the timing of the purchases of Part B weren't adjusted to build the inventory to a level that was sufficient to absorb the large variability in monthly demand, then the user would experience a two month stock-out and would be subject to the margin loss that typically accompanies a period of prolonged back-order. In this case it is clear that in order to avoid stock outs and lost profits the user would be required to incur the time, effort and expense associated with establishing a separate inventory planning system, re-keying the procurement system data into the new system, analyzing the output of the new inventory management system and manually adjusting the annual procurement quantities produced by the system described by Katz & Sedrian before placing orders; (r) The usefulness of the system as a management planning tool is severely limited as it has no provision for running different scenarios through the system or for comparing the results of the different scenarios to one another. Any "what if" type analysis would have to be completed using a separate system after re-keying or transferring the output from the inventory management system; (s) The usefulness of the system for planning within a larger organization is limited by its inability to segregate items by division, department, location or planner. While the determination of the optimal solution for a firm requires looking at total company requirements, the review of the system output and the implementation of the results is often broken down by planner, location, department or division. It may be impossible in some instances to separate recommended orders into different classifications as is the case when the system recommends the purchase of one carton per month to satisfy the demand in 5 locations. However, whenever it is possible to segregate planned purchases or production by department, division or site it is generally beneficial to do so; and (t) The system doesn't provide a mechanism for controlling the amount of margin lost because of stock-outs. This shortcoming is closely related to the one described in item "q". Given the forecast item demand, the variability of the forecast item demand and the size of planned replenishment orders, one skilled in the art of inventory management can calculate the expected size and frequency of stock outs during a given time period. When combined with the margin of the item in question, it is possible to determine the expected margin loss for the given time period. Working backwards from the targeted margin loss, it is possible to determine the order quantities required to achieve a specified margin loss target (the details of this calculation are described later in the narrative). An inventory management system without this feature leaves the user open to unexpected margin loss surprises with potentially devastating effects on financial health and stability. U.S. Pat. No. 5,237,495 to Morii (1993) discloses a similar production/purchase management system that reads the stock and remaining order information and the user-provided master production schedule and product construction item-master before it generates a prioritized purchase planning order and production planning order indicating the dates for the required item orders and quantities. While the integration in this system is enhanced relative to the system described previously, this system still suffers from virtually all of the limitations and drawbacks identified above (a-n and r-t) and has the additional limitation that it doesn't seek to minimize procurement costs or maximize profitability under any type of discount schedule. In addition to the systems described above, there are commercially available systems such as Inventory Manager from Manufacturing Management Systems, Inc. and Procurement Management from American Software, Inc. for developing item demand forecasts and for generating purchase order recommendations based on reorder point calculations and/or demand forecasts. In some cases these systems perform both functions, developing item forecasts and generating the requisite order recommendations. U.S. Pat. Nos. 5,128,861 and 5,237,496 to Akiro Kagami et al. (1993) disclose a similar system that is a hybrid, automated reorder point, economic order quantity system for ordering goods based on the system generated forecast of changes in sales. Some commercially available systems with the same inventory management functionality such as the Distribution Management System from Apogee Systems also include their own basic financial system which can help minimize the need for data conversion and re-keying. There are several drawbacks and limitations inherent in systems of this type including: (a) These systems only determine the requisition dates and quantities required to meet the forecast demand. These systems make no attempt to minimize the cost of purchasing goods under any type of discount schedule; (b) These systems make no attempt to maximize the profitability of the firm using the system; (c) These systems have no provision for assuring that the company using the system will have the financial resources required to acquire the items identified for procurement. It does little good to create purchase requisitions if the company won't have sufficient funds to pay for the ordered items when the bills come due; (d) These systems require the user to assess the impact of impending obsolescence on the plans for procuring all items and provide no mechanism for handling planned product obsolescence in the middle of a forecast time period; (e) Most of these systems require the user to incur the time and expense associated with creating item demand forecasts using a separate system before undertaking the time-consuming, error prone re-entry of the item demand forecast into the system before calculations can begin; (f) In those systems that develop item demand forecasts, the forecasts generally need to be reformatted before they can be reviewed in a meaningful manner by managers in the different functional organizations. Because the output from these systems is produced in only a unit volume format, the completed forecasts don't lend themselves to review by other functional organizations. While other functional organizations may be very well versed on revenue trends by product or account, they are typically not familiar with unit volume trends and could thus provide little in the way of meaningful input to any review discussion; (g) The robustness of the forecasts developed by these systems is questionable. In calculating the forecasts, the systems typically rely on only one or two indicators, unit volume history or unit volume history and time of year, to determine the item demand forecasts. Relying on only these few factors leaves the forecasts extremely vulnerable to skewing by one time events; (h) These systems require the user to utilize the accounting system that is provided with the inventory planning system in order to realize the benefits of an integrated system. These benefits include reduced time and expense for re-keying data, reduced lag time for adding new data to the distribution planning system and elimination of the costs associated with maintaining two separate systems. However, realizing these benefits requires the user to stop using the accounting system already in place, convert the existing accounting files and databases to the format of the new accounting system and retrain accounting personnel and system operators on the use of the new system. While each of these activities are costly to implement, retraining the existing personnel is often the most costly and time consuming part of the process. It is not uncommon for a system conversion to take several months with the total cost of the conversion effort equaling two or three times the cost of the purchased software; and (i) These systems don't generally consider margin loss targets when determining the annual purchase quantities. Another major drawback of all previously described systems is one that is inherent in having any separate system for determining requisition requirements, namely, that the forecasts and plans contained in the separate system can easily diverge from the forecasts and plans contained in other functional systems that support the operation of the company. Thus, it is possible for the requisition/inventory system to have a forecast or plan for the near future that is substantially different from the near-term forecast or plan being used by the sales organization. The plans from both organizations could in turn be different from the near-term forecast or plan being used by the finance organization. These differences between the separate plans and systems can arise all too easily because coordinating the activities of the functional organizations within a company to ensure that sales is selling what operations is planning to buy or make with the money that finance says will be available can be an expensive and time consuming task for general managers in companies of any size in virtually all industries. At the same time, the importance of achieving alignment can not be over emphasized. In the recent book Built to Last which analyzed the successful habits of visionary companies over the last 80 years, the authors James Collins and Jerry Porras concluded that one of the most significant findings of their study was the importance of organizational alignment to long term success. A related finding was that virtually all companies underestimated the difficulty of achieving and maintaining alignment. For many corporations, the expense and difficulty associated with aligning the plans and activities of different functional organizations in detail is such that it is only attempted once a year during the annual budget setting exercise. Unfortunately, even after spending the time and effort required to coordinate the activities of the different functional organizations, the gap between the forecasts and plans contained within each organization's separate functional system may not have been eliminated. One of the primary difficulties associated with synchronizing the different functional organizations within a company is reconciling the perspectives that each group has on the past, present and the future. The simplified listing of the typical focus for each functional organization that is shown in Table 8 gives an indication as to why this synchronization might be so difficult:
TABLE 8
______________________________________
Functional Organization
Focus
______________________________________
Sales Customers
Unit Volume Sold
Unit Proces
Operations Unit Costs
Inventory
Efficiency
Productivity
Finance Profitability
Cash Flow
Return on Assets
______________________________________
The lack of overlap between the primary concerns of the functional organizations is often exacerbated by the use of different terminology and/or units of measure for describing areas of common interest. For example, operations may be focused on how many truck loads of product are shipped while sales is interested in how many cases of product are being sold. Viewed in this light, the difficulty described previously can be seen as a problem of establishing a common language as the basis for discussions and analyses with further complications associated with coming to an agreement as to the interpretation of the data being analyzed. For most companies, the "common language" that can be shared most readily by all groups is a financial one. This is not surprising since everyone in every group has some experience dealing in the local currency and can readily relate to discussions on this basis. From the preceding discussion, it would be logical to conclude that the most effective system for synchronizing the plans of all groups would be a financial planning system. However, the limitations of existing financial planning software systems render this option impractical and ineffective. Financial Planning Systems Financial planning software systems are a subset of corporate financial software systems. Corporate financial software systems are generally divided into two categories, basic and advanced. Advanced financial systems utilize information from the basic financial systems to perform financial analysis, financial planning and financial reporting functions. Every commercial enterprise uses some type of basic financial system as they are required to maintain books and records for income tax purposes. An increasingly large percentage of these basic financial systems are resident in microcomputer and workstation systems. Basic financial systems include general-ledger accounting systems with associated accounts receivable, accounts payable, inventory, invoicing, payroll and purchasing subsystems. These systems incorporate worksheets, files, tables and databases. These databases, tables and files contain information about the company operations and its related accounting transactions. General ledger accounting systems generally store only valid accounting transactions. As is well known, valid accounting transactions consist of a debit component and a credit component where the absolute value of the debit component is equal to the absolute value of the credit component. The debits and the credits are posted to the separate accounts maintained within the accounting system. Every basic accounting system has several different types of accounts. The effect that the posted debits and credits have on the different accounts depends on the account type as shown in Table 9.
TABLE 9
______________________________________
Account Type:
Debit Impact: Credit Impact:
______________________________________
Asset Increase value
Decrease value
Revenue Decrease value
Increase value
Expense Increase value
Decrease value
Liability Decrease value
Increase value
Equity Decrease value
Increase value
______________________________________
General ledger accounting systems also require that the relationship shown below is maintained at all times: Asset account balances=Liability account balances+Equity account balances The general ledger system generally maintains summary, dollar only transaction histories and balances for all accounts while the associated subsystems, accounts payable, accounts receivable, inventory, invoicing, payroll and purchasing, maintain more detailed historical transaction data and balances for their respective accounts. It is common practice for the subsystems to maintain the detailed information shown in Table 10 for each transaction.
TABLE 10
______________________________________
Subsystem
Detailed Information
______________________________________
Accounts
Vendor, Item(s), Transaction Date, Amount Owed,
Payable Due Date
Accounts
Customer, Transaction Date, Amount Due, Terms,
Receivable
Due Date
Inventory
Item, Transaction Date, Transaction Type,
Transaction Qty, Location
Invoicing
Customer, Transaction Date, Item(s) Sold, Amount
Due, Due Date
Payroll Employee, Employee Type, Pay Frequency, Pay
Rate
Purchasing
Vender, Item(s), Purchase Quantity, Purchase
Price(s), Due Date
______________________________________
As is well known, the output from a general ledger system includes income statements, balance sheets and cash flow statements in well defined formats which assist management in measuring the firm's financial performance during the prior periods when data input has been completed. Financial planning systems generally use the same format used by basic financial systems in forecasting income statements, balance sheets and cash flow statements for future periods. Management uses the output from financial planning systems to highlight future financial difficulties with a lead time sufficient to permit effective corrective action and to identify problems in company operations that may be reducing profitability below desired levels. For the reasons discussed in more detail below, financial planning systems are typically found only in larger corporations. These systems are most often developed by individuals within companies using 2 and 3 dimensional spreadsheets such as Lotus 1-2-3.RTM., Microsoft Excel.RTM. and Quattro Pro.RTM.. The information from basic financial systems can be entered into these systems either by manually re-keying the appropriate data into the appropriate cells or by connecting the spreadsheets to the basic financial system database or files and importing the data to the appropriate cells within the spreadsheet. The imported data often have to be reorganized before it can be fully utilized after it has been entered into the spreadsheet. These spreadsheet programs contain preprogrammed mathematical functions which the user can use to develop formulas for forecasting future values for any or all of the accounts required to develop the desired forecast. The use of the preprogrammed functions requires the user to select the most appropriate forecasting technique for the item being forecast. Alternatively, this facet of the operation of the spreadsheet programs can be supplemented through the use of commercially available forecast creation packages such as Forecast Pro, SmartForecasts and the Modler MBA Business Analysis Program that will analyze the data and select the most appropriate forecasting technique before generating a forecast. Using these packages for forecast calculation requires the user to import or re-key the relevant data before the forecast algorithm can be selected and the forecast calculated. In some cases, the completed forecasts must be exported or re-keyed into the appropriate cells in the spreadsheet before they can be used. The use of spreadsheet programs for financial planning also requires the user to develop complex mathematical models in order to generate meaningful forecasts. This requirement is one of the primary factors that restricts the use of these programs for financial planning to larger companies that can afford the time and the specialized manpower required to develop the models and create the forecasts. The basic function of these spreadsheets is often supplemented by the creation of `macros` which are strings of command sequences that are stored for playback when the operation needs to be run again. While the use of `macros` may be helpful to the individual completing the forecast, the usefulness of the forecast spreadsheet may be limited by the user's tailoring of the output to fit his or her personal needs at the time. Furthermore, because these `macros` are often undocumented they can be very difficult to revise should the personnel who created them leave the corporation or should business needs change. The ad-hoc nature of these programs also makes them unsuitable for long term direct connection to the operational systems used to run the company. Spreadsheet programs generally also lack the ability to provide financial controls such as audit trails that are required in advanced financial applications. Financial planning systems built within an executive information system (EIS) or decision support system (DSS) are alternatives to the spreadsheet based systems. These systems often interface directly with the corporate basic financial system and access the basic financial system transactions and data in a manner that is similar to that used in the present invention. These systems also have the ability to access data from other operational systems that may be used by the corporation. However, these systems are generally not pre-programmed with any specific type of report. As a result, the user must undertake an expensive and time consuming effort to design and program the system to monitor the company's financial situation in a manner that will be beneficial. The specialized nature of these systems often dictates that the user engage specialized personnel to develop the required models and programs. In completing the programming effort, the EIS or DSS based financial planning software developer would face difficulties similar to those experienced by the spreadsheet programmer discussed previously: 1. The developer must select the most appropriate forecasting techniques to use in creating the forecasts; 2. The developer would be required to develop complex models for projecting the user's financial status in future periods; and 3. The developer would in all likelihood be required to reorganize the data obtained from the basic financial system or other operational system before using it to create forecasts or complete financial forecasts. Once the financial planning models are developed and the system is producing financial forecasts and reports, the usefulness of the information provided is limited. EIS and DSS function as early warning systems, management report generators and query tools and not operational systems. These systems are similar to the spreadsheet financial planning systems in that the undocumented nature of the software generating the specific reports can make changing the programmed models difficult. These financial planning systems also have no mechanism for aligning the calculated forecast with the forecasts in other functional systems. Furthermore, because there is generally no direct interface available to feed information of any type from the financial planning system to an accounting or operational system, the user must undertake the time-consuming, error-prone and expensive step of manually re-entering any relevant financial planning system information in order to use it for processing. Alternatively, the user can take the costly step of developing an interface between the EIS/DSS financial planning subsystem and other systems. The limited capability of these financial planning systems combined with the enormous time and expense required to develop and maintain these systems effectively limits their use to larger companies and makes it difficult to use these systems as the basis for synchronizing the forecasts used by the different functional organizations within a commercial enterprise. A method for overcoming the shortcomings with existing inventory management systems that were identified above involves combining an enhanced system and method for inventory planning together with an advanced system and method for financial planning. This innovative system begins by creating multi-dimensional forecasts of sales and cash receipts. The system uses data from existing basic financial systems together with limited user input as the basis for the forecasts. The different sales and cash receipt forecasts are then synchronized by the system with the aid of a novel variable that also helps minimize investments in obsolete inventory. After the composite forecast is completed, the base-level requisitions (profit maximizing requisition set under existing constraints) are generated for all forecast items having item quantity and business-volume discount schedules. Requisitions for items with no discount schedule or mixed discount schedules are also created at the same time. The system then develops a detailed financial forecast for use in determining if there are sufficient funds to pay for the base-level requisitions. After the system determines that the commercial enterprise can pay for the base-level requisitions while keeping the available capital above the user specified minimum level during the forecast time period, the system then creates a listing of potential changes to the base-level requisitions that can increase profitability. The application software of the present invention then creates a display of the list of changes for the user. The user then has the option of accepting or rejecting the proposed changes. When the user's review of the proposed changes is complete, the previously calculated base-level requisitions and financial forecasts are changed to reflect the impact of the accepted changes. There are no known prior attempts to: 1. Produce, store and display multivalent forecasts of sales and cash receipts for use by an integrated inventory management, requisition preparation, and financial planning system where the forecasts are created by transforming transaction data and information from standard financial software systems into forecasts of sales by item, sales by customer group and sales by account as well as forecasts of cash receipts by customer group and by account; or to 2. Develop a composite forecasts of sales and cash receipts using the multivalent combination of previously created sales and cash receipt forecasts for possible use as the controlling forecasts for forecast synchronization; or to 3. Calculate and store a unique variable for each forecast element in order to provide an efficient and effective mechanism for synchronizing forecasts that have been created on more than one dimension (i.e., sales by item, customer group and account) with a controlling forecast and facilitate obsolescence risk management for individual items; or to 4. Determine the profit maximizing requisition set (base-level requisitions) for any mixture of items with business volume and item quantity discount schedules that satisfy forecast demand while meeting the item fill-rate or item margin-loss targets specified by the user; or to 5. Create and display a detailed financial forecast for a commercial enterprise highlighting any deficiencies in available capital that affect the ability of the enterprise to acquire the base-level requisitions. This financial forecast is created by combining the previously calculated sales forecasts, cash receipt forecasts and base-level requisitions with multivalent balance sheet and expense account forecasts. The balance sheet and expense account forecasts are created by using transaction data and information from standard financial software systems together with prior forecasts as the basis for calculation; or to 6. Calculate, prioritize and display a listing of profit enhancing changes to the base-level requisitions that are feasible within the forecast financial constraints of the commercial enterprise using the system after relaxing some of the user defined constraints; or to 7. Accept user deletions to the listing of profit enhancing changes, display a financial forecast that reflects the impact of the accepted changes and then modify the base-level requisition after user acceptance of the modified financial forecast. SUMMARY OF THE INVENTION It is a general object of the present invention to provide an innovative and useful inventory management system that creates and displays a prioritized list of profit-enhancing changes to base-level requisitions that are feasible within the projected financial constraints of the company that eliminates the limitations and drawbacks of the prior art that are described above. The above and other objects of the present invention will become apparent from the narrative in the present specification and the accompanying drawings. A preferable object to which the present invention is applied is inventory management for a small commercial enterprise that can not afford to purchase, support and maintain a separate, specialized system for inventory management or expend the time and effort required to convert its accounting system to one tied to a distribution planning system with limited functionality. A large portion of the specialized manpower and effort required to support and maintain separate systems is eliminated in accordance with the present invention by using the information in the databases, tables, and files of the existing computer-based corporate financial software systems as the source for the transaction data and product parameters required to operate the system. In accordance with the invention, the use of transactions from existing computer-based, basic financial systems eliminates the need for a highly-skilled, specialized operator to complete the costly and time consuming preparation, conversion and re-keying of data. It has the added benefit of eliminating the need to replace the existing accounting system. The application software of the present invention preferentially loads the application database by copying the transaction and item data from a basic financial system database to the application database using the mapping criteria and data dictionary information input by the user. The present invention also has a provision for entering information manually and for reading the data from computer files. The present invention further eliminates time consuming and expensive effort for the user by using the transaction records from a basic financial system together with minimal user input to develop the required forecasts for the chosen time period. More specifically, the system develops forecasts for the user-specified time period of sales by product, sales by customer type, sales by account number, cash receipts by customer type, cash receipts by account number, debits by account number, credits by account number, inventory by item and account balances by period. All forecasts can be segregated by site, division or department as required for more effective review. Item forecasts can also be segregated by planner. The system also incorporates the full functionality of an advanced financial system for financial planning which is used to create detailed income statement, balance sheet and cash flow forecasts for future periods. System performance is further enhanced by the inclusion of scenario control logic that allows the user to store and compare current forecasts to prior forecasts that have been developed with the use of this system. The sales forecasts developed in accordance with the present invention are substantially more robust than the forecasts generated by existing inventory management systems as they are based on a multivalent forecasts of customer group buying patterns, sales account trends and product volume histories. Another advantage of the method and system of the present invention that is described in more detail below is that the system prepares matching sales forecasts using a customer basis, a unit-volume basis and a general ledger account basis. The resulting forecasts can be easily reviewed by the three major functional groups within any company: sales, operations and finance. When calculating the required sales forecasts, the system also completes the novel and useful calculation and storage of a TVO (Trend, Variability and Obsolescence) variable for each forecast element. The TVO variable provides a superior method for synchronizing the different functional group forecasts by prioritizing the selection of the items that will have their forecast quantities preferentially increased or decreased as required to match the controlling forecast specified by the user. Furthermore, in the present invention the TVO variable provides the user with an effective, low-cost mechanism for systematically preventing the build-up of inventory stock for items that are thought to be nearing obsolescence. The system has additional capabilities for handling the obsolescence of individual items by allowing the user to designate successor items for purchase after a specified date. The specified date is used as both the start date for sale of the new, successor item and the date when inventory balance of the predecessor item should reach a zero balance. After using the TVO variables in synchronizing the sales and cash receipt forecasts with the controlling forecast in accordance with the present invention, the system analyzes the impact of the previously calculated item demand and demand variability (V in TVO) in setting a target inventory level for each item that will produce the user specified fill rate. Alternatively, the user can specify the amount of gross margin loss that is acceptable for an item during the forecast time period. The system will then calculate, display, store and utilize the corresponding fill rate target for the item to achieve the target level of margin loss. This aspect of the present invention can greatly reduce both the number and the severity of stockouts that the company using the system experiences. The reduction in stockouts will in turn increase the satisfaction level of the customers while reducing profit loss caused by lost sales. After completing the target inventory level calculations, the system calculates the base-level requisition set that will generate the largest profit for the commercial enterprise while maintaining the target inventory levels for the individual items. The system calculates the base-level requisitions for the user's entire range of items even if more than one type of discount schedule is used. The system will determine the base-level requisitions for a collection of items with a mix of item and business volume discount schedules. This feature of the present invention provides the user with tremendous time and cost savings when compared to existing systems by using one system for optimizing all of the company's inventory purchases instead of requiring the use of two or more systems. In accordance with the present invention, further significant advantages are realized through the use of user-input variables to designate whether or not the system should consider vendor substitution and unit of measure substitution globally and at the item level as part of an optimization calculation. As discussed previously, there are often overriding concerns that lead a company to buy from a particular vendor or in a specific unit of measure even when the resulting item unit price is higher than that of an alternative. In the present invention, the user of the system only has to click a radio button with his mouse to change the Vendor Change Permitted or Unit of Measure Change Permitted variables for the entire forecast or for a single item from yes to no. Implementing this change in existing business volume discount optimization systems requires reprogramming the constraints--a time consuming and difficult task. Following the computation of the base-level requisitions, the system completes the financial forecast for the specified time period and determines whether or not the company will have sufficient cash and available credit (hereinafter referred to as available capital) to pay for the base-level requisitions in all future time periods. If the available capital is not above the user specified minimum level in all forecast time periods, then system processing will not proceed to the profit maximization step. The user can bring the available capital above the minimum level by modifying the original input parameters, the individual item sales forecasts or the individual item fill-rate or margin-loss targets before rerunning the forecast. Once the available capital is above the minimum level in every forecast time period, the user is given the option of modifying the previous calculations and input or accepting the base-level financial forecast as is. System processing advances to the profit maximization step only after the user accepts the financial forecast. These features of the system and method of the present invention assures the user that the forecast financial situation is acceptable and that the forecast financial situation will provide the means to pay for the items planned for purchase before the requisitions are finalized and orders are placed. The user realizes enormous benefits by avoiding the time-consuming, embarrassing and potentially expensive exercise of canceling or delaying orders that have already been placed. Because it would not be unusual for vendors receiving late payments to stop shipments and/or cut off credit, these features have the further advantage of protecting the user's credit history and the user's ability to obtain credit from other vendors in the future. After the base level forecast has been accepted by the user, the present invention provides the user with additional benefits by generating and displaying a prioritized listing of profit enhancing changes to requisition quantities, vendors and units of measure that are feasible within the forecast financial constraints of the company using the system after some of the user specified constraints are removed. The listed changes are prioritized for display in accordance with the ratio of profit increase to the required capital investment. The user can accept or reject the individual changes that have been recommended by the system as desired. This aspect of the present invention benefits the user by recommending changes to base-level requisitions that directly improve the profitability of the firm. It also benefits the user by clearly quantifying the cost of maintaining certain inventory management and purchasing policies and by giving the user the chance to easily modify the practices as desired to increase profitability. The present invention provides the user with a fully integrated inventory management system that utilizes minimal user input and data from existing corporate financial software systems to produce accurate multi-dimensional forecasts useful for integrated inventory and financial planning; establish the target inventory levels that will maintain user specified fill rate or margin loss targets given the previously developed demand forecasts; minimize the financial risk associated with inventory obsolescence by calculating, storing and using a unique variable for adjusting forecast quantities and by providing for the planned transition from one product to another; determine the lowest cost set of requisitions that maintain the target inventory levels for products with any mix of item and business volume discount schedules; calculate and display the forecast financial position of the commercial enterprise using the system while highlighting any deficiency in the funds required to pay for the purchase of the lowest cost set of requisitions during the forecast time period; calculate, prioritize and display a list of profit enhancing changes to the lowest cost requisition set that are feasible within the forecast financial constraints, accept user modifications to the listing, display a financial forecast to the user that reflects the impact of the accepted changes and then modify the base-level requisition after user acceptance of the modified financial forecast. BRIEF DESCRIPTION OF DRAWINGS These and other objects, features and advantages of the present invention will be more readily apparent from the following description of the preferred embodiment of the invention in which: FIG. 1 is an overview of an illustrative computer system used in the practice of the present invention; FIG. 2 is a block diagram of an illustrative computer based method of and system for generating a listing of feasible profit-enhancing changes to base-level requisitions; FIG. 3A and FIG. 3B am flow diagrams showing the sequence of the steps for determining the prioritized list of profit enhancing changes to the base-level requisitions within the constraints imposed by the forecast financial situation of the commercial enterprise using the invention; FIG. 4 is a diagram showing the files or tables in the application database of the present invention that are utilized for data storage and retrieval during the processing to determine the prioritized list of profit enhancing changes to the base-level requisitions within the constraints imposed by the forecast financial situation of the business unit or company using the invention; FIG. 5A is a flow diagram showing the sequence of the steps in the inventory replenishment subsystem that are used for forecasting sales by item, calculating the item TVO variables used for determining the magnitude of item forecast adjustments during forecast synchronization, calculating the economic order quantity for each item, determining the target inventory level required to maintain user specified fill-rate or margin-loss targets for each item, and creating the preliminary requisitions required to maintain the target inventory levels; FIG. 5B and FIG. 5C are flow diagrams showing the sequence of steps used in creating the base-level requisitions in the inventory replenishment subsystem; FIG. 5D and FIG. 5E are flow diagrams showing the sequence of steps required to generate the list of profit enhancing changes to the base-level requisitions within the constraints imposed by the forecast financial situation of the commercial enterprise using the system after relaxing some or all of the user defined constraints on vendor and/or unit of measure substitution in the inventory replenishment subsystem; FIG. 6 is a flow diagram showing the sequence of the steps in the customer payment analysis subsystem for forecasting sales by customer group, forecasting cash receipts by customer group and calculating the customer group TVO variables used for determining the magnitude of customer group forecast adjustments during forecast synchronization; and FIG. 7A and 7B are flow diagrams showing the sequence of the steps in the calculation of the financial forecast subsystem that is used for forecasting sales by account number, forecasting cash receipts by account number, forecasting expense account transaction levels, calculating balance sheet account end of period balances, calculating the account TVO variables used for determining the magnitude of account forecast adjustments during forecast synchronization and creating an overall financial forecast. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT The detailed description of the present invention will start with an overview of the functionality of the computer based automated system and the processing, storage and display of information completed by the automated system together with the processing and storage of information completed by the associated software subsystems that comprise the automated system. This overview will help put the detailed description in clear perspective while providing an opportunity to introduce concepts and examples that will facilitate the illustration of various aspects of the present invention. The overview will be followed by a description of the flow diagrams illustrative of a preferred embodiment of the present invention that will complete the detailed description. Processing in the present invention starts with the acceptance and storage of user input that defines the type of forecast that is to be calculated. Other inputs provided by the user at the beginning of operation are shown in table 11. Table 11 1. The time period used for forecast calculations (weeks or months) 2. The number of forecast time periods (maximum 78 weeks or 18 months) 3. The number of time periods for which requisitions will be calculated (the maximum is equal to the number of forecast time periods) 4. The source for transaction data: user-input, computer files or a basic financial system database 5. The source for item forecast historical data: sales transactions or inventory transactions 6. The minimum acceptable available capital balance where available capital is defined as the sum of the operating cash balance plus the unused portion of available credit line 7. The number of days per week the business operates 8. The base currency for all calculations 9. The default location (site) for forecast calculations 10. The default cost for placing, receiving and stocking an order 11. The default display format for the financial forecast 12. The default inventory carrying cost rate 13. The default percentage of forecast item demand that can be purchased on a commitment basis 14. The default sales account 15. The default inventory account 16. The number of history periods that should be used for base period forecast calculation 17. The maximum acceptable age of a forecast 18. The times in a month when orders are typically placed (end of month, every Thursday, the 7th and 21st day of each month, etc.) 19. The number of categories and the relative weightings that will be used in Item TVO variable calculation 20. The number of categories and the relative weightings that will be used in Customer TVO variable calculation 21. The number of categories and the relative weightings that will be used in Account TVO variable calculation 22. If vendor substitution is to be considered for any item 23. If unit of measure changes are to be considered for any item 24. Accuracy percentage required for unit price forecasts 25. Accuracy percentage required for unit volume forecasts 26. Accuracy percentage required for currency amount forecasts 27. Holidays and other days with no sale or receipt of goods 28. Location names (with "all locations" being one location) 29. A forecast of changes in capital structure 30. A forecast of capital investments (and divestments) 31. The account structure of the basic financial system that will be supplying transaction data 32. If vendor substitution restrictions should be removed as part of profit enhancement calculations 33. If unit of measure substitution restrictions should be removed as part of profit enhancement calculations 34. Maximum percentage total requisition quantities can be increased as part of profit enhancement calculations 35. The days orders are processed 36. The scenario designation for the current forecast, includes optional: site, division or department restrictions on customer groups, accounts and items being forecast, planner restrictions on items being forecast, forecast by item algorithm specification, forecast by account algorithm specification, forecast by customer group algorithm specification, controlling forecast designation and product only specification. The functional impact of these inputs will be described in the present specification as part of the description of the affected processing. If the user has already entered and stored the information listed above, then the user has the option of changing the previous input or proceeding to the next stage in processing. The application software of the system then checks to ensure that the required data dictionary and data source mapping tables for the user-specified data source have been completed and stored in the application database. If any required information isn't present in the application database, the user is prompted by the application software to provide the required information. After the required data dictionary and data mapping information are entered and stored in the application database, the application software establishes a connection with the specified data source utilizing user-input as required. The date of the transactions in the application database data tables are then compared with those in the specified data source by the application software of the present invention. The application software then creates a display showing the range of transaction dates that need to be added to each data table in the application database to bring the data up to date. The user is given the option of modifying or skipping the updates for specific tables before the application software copies the appropriate information from the specified data source to the tables in the application database of the present invention. The user is then prompted to provide input as required to complete the calculation of the various forecasts required for operation of the present invention. These forecasts are developed in a multi-step process that will be detailed below. The first step in the forecast calculation is the independent forecast of future sales and cash receipts using three different bases, namely, sales and cash receipts by account, sales and cash receipts by customer group and sales by item. For individual accounts or items, the user has the option of using the history or the forecast from a different account or item, respectively, as the basis for the forecast. If the user doesn't specify another account or item as the basis for forecasts then the prior history of the account or item is used as the forecast basis. Accounts and items that have their forecast based on the forecast for another account or item are said to be dependent. With items, the user also has the option of designating another item as the successor after a designated date. Each independent forecast by account, customer group or item is first completed for the preceding 3 to 10 time periods. The number of preceding time periods used in this calculation are specified by the user. The time period covered by this forecast of preceding time periods is called the base period. This definition for the base period will be applied in all subsequent descriptions of system operation. The calculation of all system generated sales, expense and price forecasts is started by using the actual history from the 15 to 24 time periods that precede the base period together with 32 different algorithms to produce 32 different forecasts covering the base period. The 32 different algorithms used in calculating preliminary sales, expense and price forecasts are listed in Table 12 below.
TABLE 12
______________________________________
Algorithm
______________________________________
1. Prior 3 period average
2. Prior 6 period average
3. Prior 12 period average
4. Prior 15 period average
5. Prior 18 period average
6. Prior 26 period average
7. Prior period actual
8. Prior period actual .times. (prior period actual/2 periods prior
actual)
9. Prior period actual .times. (1 + 3 period average period to period
trend)
10. Prior period actual .times. (1 + 6 period average period to period
trend)
11. Prior period actual .times. (1 + 12 period average period to
period trend)
12. Prior period one quarter ago
13. Prior period six months ago
14. Prior period one year ago (seasonal)
15. Prior period two years ago
16. Average of (prior period one year ago + prior period one
period before the period one year ago + prior period one
period after one year ago)
17. Average quarter during last year - converted to monthly
or weekly forecast as appropriate
18. Average quarter during last year .times. (1 + most recent
quarter to quarter growth rate) - converted to monthly or
weekly forecast as appropriate
19. Average quarter during last year .times. (1 + average quarterly
growth last year) - converted to monthly or weekly forecast
as appropriate
20. Average period last year
21. Average period last year .times. (1 + average period growth
last year)
22. Simple weighted average, heavy weighting to most recent
3 periods
23. Simple weighted average, heavy weighting to most recent
12 periods
24. Simple weighted average, heavy weighting to periods one
year ago
25. Damped trend exponential smoothing - reduced time period
26. Damped trend exponential smoothing
27. Single exponential smoothing - reduced time period
28. Single exponential smoothing
29. Double exponential smoothing - reduced time period
30. Double exponential smoothing
31. Winter's exponential smoothing - reduced time period
32. Winter's exponential smoothing
______________________________________
The error of the resulting forecasts is then assessed on two parameters, magnitude (i.e., currency level, price or item volume) and trend. The magnitude error is assessed by summing the square of the differences between the base period forecast and the actual base period results for each period and dividing the result by the number of periods as shown below. ##EQU1## Where: n=period number 1,2 . . . N N=total number of periods in the base period Q.sub.fn =quantity (currency level, price or item volume) forecast for period n in base period Q.sub.an =actual quantity (currency level, price or item volume) during period n in base period Trend is defined as the slope of the best-fit least-squares regression of the base period forecast using the formula shown below. Q.sub.n =(Q.sub.(n-1) XT)+B Where: n=period number 1,2 . . . N n-1=period prior to period n Q.sub.n =quantity forecast for period n Q.sub.(n-1) =quantity forecast for period prior to period n T=trend B=constant The error in the trend forecast is assessed by the square of the differences between the forecast trend and the actual trend as shown below. Error measure for trend=(T.sub.f -T.sub.a).sup.2 Where: T.sub.f =trend of base period forecast T.sub.a =actual trend during the base period The error of each of the 32 forecasts is assessed using the two measures and the results for each measure are then normalized. The resulting error measures are then added together to produce an overall measure of forecast error. Given the preceding error definitions it is clear that the lower the error measure is--the higher the forecast accuracy. The three algorithms that produced the closest match with the actual base period results (the three algorithms with the lowest combined error) are then assigned weightings based on the multivalent assessment of their overall accuracy as shown in Table 13. In the event two different algorithms have the same low combined error level, the algorithm having the lowest table number (as shown in Table 12) will preferentially be chosen for future forecast calculations.
TABLE 13
______________________________________
Forecast weightings
##STR1##
NORMALIZED MAGNITUDE ERROR
______________________________________
*Normalized
The same three algorithms are then used to calculate forecasts for the next 1 to 78 weeks (if the user selected time period is weeks) or the next 1 to 18 months (if the user selected time period is months). A weighted average forecast is then calculated using the three forecasts weighted by the previously designated weightings. The weighted average forecast is used as the forecast for the specified time period. The calculated forecasts for the base period and for the forecast time period are then stored for later use. The forecasts for dependent accounts or items are completed in a manner similar to that described for independent accounts or items except the dependent forecasts are created by using the forecast of the base account or item in place of prior history. The user is also given the option of designating any one of the 32 algorithms shown above for account, customer group or item forecasting. This designation can be done globally (i.e., all forecasts by item are completed using algorithm 12) or at the element level (i.e., customer group a4 forecasts are completed using algorithm 27). Global designations are specified when the forecast scenario is established while element (account, customer group or item) specifications are established in the different element master files. While completing these calculations, the system may determine that some of the accounts, customer groups or items that are being forecast require review by the user before the forecast calculations can be completed. When it is determined that a forecast element needs review, it is flagged for later review by the user. Some of the reasons for flagging individual forecasts for review include insufficient data to complete a reliable forecast and large differences between the multivalent forecast for the base period and the actual results for the base period. The user specifies the acceptable level of accuracy as part of the system set up. The flagged item, account and customer group forecasts must be reviewed by the user before the forecast calculation can proceed to completion. During the forecast calculation by account, by customer group and by item, the trend (T) and variability (V) associated with the historical pattern for each individual forecast element (where an element can be an account currency level, a customer group currency level or an item volume) is calculated and stored for later use. In accordance with the present invention, trend (T) is defined as the slope of the best-fit least-squares regression of the base period history for each element. Variability (V) is defined as the quotient of the sample standard deviation of the relevant prior history for each element over the average period value of the element during the same time span. The system calculates and stores a TVO variable for each account, customer group or item that is being forecast. Previous input by the user to the item master assessing the probability of obsolescence (O) is also related to the item forecast information. The TVO variable is calculated in accordance with the present invention based on weightings that have been determined by the system and optionally modified by the user. More specifically, the TVO variable is the weighted sum of the normalized values of the Trend, Variability and Obsolescence variables. Tables 14, 15 and 16 illustrate the steps taken to complete the TVO variable calculation for each of three different products:
TABLE 14
______________________________________
Raw Data
Trend Variability
Obsolescence Risk
______________________________________
Product A
.10 .24 Moderate
Product B
-.21 2.24 Very High
Product C
1.12 .67 Very Low
Range -.87 to 2.14
.05 to 2.89
Very Low to Very High
______________________________________
The example shown above illustrates that relatively high TVO values would typically be associated with forecasts that have a high relative period-to-period growth rate, a high relative variability in period-to-period magnitude and a low relative risk of obsolescence. The innovative and effectual storage and use of the TVO variable provides a superior method for selecting the forecast elements that will have their values preferentially increased or decreased as required to match the controlling forecast. In the case where a forecast needs to be increased to match a controlling forecast, the increase is preferentially spread to the group of elements with the highest TVO values while the group of elements with the lowest TVO values would have no increase. Reasons for preferentially increasing the highest TVO elements include: 1. Increasing the forecast for a high TVO element is in line with existing trends. The monthly level for the element is already increasing more than most other items (normalized T is highly positive), and/or; 2. Increasing the forecast for a high TVO element is conservative. The element has a high period-to-period variability (normalized V is highly positive). Increasing the forecast improves the likelihood that the forecast will cover the actual level experienced, and/or; 3. If the element is an item, increasing the forecast for an item with a relatively low risk of becoming obsolete minimizes the financial risk associated with increasing a forecast. As shown above, low risks of obsolescence carry higher normalized values of O. In light of the preceding discussion, it is clear that when a forecast needs to be decreased to match a controlling forecast, the decrease would be preferentially spread to the group of elements with the lowest TVO values while the group of elements with the highest TVO values would not be decreased. The use of the TVO variable gives the user the ability to ensure that the initial sales forecasts for items that are likely to become obsolescent in the foreseeable future are not increased under any circumstances. The user can achieve this by increasing the relative weighting of the Obsolescence (O) variable in the TVO table. Increasing the relative weighting of the Obsolescence (O) variable in the Item TVO calculation would also ensure the user that items that were expected to be obsolescent in the near future would be the first to have their forecasts decreased as part of an overall forecast reduction. The next step in the forecast development process involves the comparison of the just completed sales and cash receipt forecast(s) for the preceding 3 to 10 time periods from each of the three different perspectives (dollars, customers and units) with the actual results for the same time period. In accordance with the present invention, the system will then determine a composite sales and cash receipt forecast using a system generated multivalent weighting criteria similar to that described previously. The final step in the sales and cash receipt forecast development process in accordance with the present invention involves the adjustment of the three sales forecasts (:by account, by customer group and by item) and the two cash receipt forecasts (by account and by customer group) to match the controlling forecasts. If the system generated composite forecast has been designated as the controlling forecast (the default condition), then each sales and cash receipt forecast is adjusted to match the composite forecast. Alternatively, if the user has chosen one of the two sales and cash receipt forecasts as the controlling forecast, then the other two forecasts are adjusted to match it. Finally, if the user has chosen to use the most accurate forecast as the controlling forecast, then the system will determine which of the three forecasts mentioned previously is the most accurate in predicting the base period results and use it as the controlling forecast. The user is normally only given the option of choosing the forecast by customer group or the forecast by account as the controlling forecast for two reasons, the sales forecast by item only captures the expected revenues from product sales and the sales forecast by item doesn't have a corresponding cash receipt forecast. Use of the sales forecast by item is generally unacceptable because most commercial enterprises will have revenue from service and other miscellaneous sources in addition to product sales revenue. However, when the user has specified that the current scenario is a product only scenario, the user will have the option of choosing the sales forecast by item as the controlling sales forecast. In this case, the cash receipt forecast by account is adjusted to reflect the controlling sales forecast and is used as the controlling cash receipt forecast. If no controlling forecast is specified, then the system will use the composite forecast as the controlling forecast. The controlling forecast can be specified when the forecast scenario is established. All forecasts are adjusted to exactly match the controlling forecast in every time period. The first step in the adjustment of the forecast involves segregating each individual account, customer group or item forecast into a different sub-group or segment based on relative TVO value. If the user didn't specify the number of TVO categories for the forecast being adjusted then the system uses a default value of four segments. The changes required to bring each period forecast in line with the controlling forecast for the period are then preferentially spread to the most appropriate segments. For example, if the item sales forecast for the first period needed to be increased to match the controlling sales forecast for that period and there were four categories specified for item TVO, then the application software of the present system would segregate the items into four groups with group four having 25% of the items with the lowest TVO values, group three having 25% of the items with the next highest TVO values, group two having 25% of the items with the next highest TVO values and group one having 25% of the items with the highest TVO values. If there were no segment rankings specified, then the system would use the default values and spread: four-sevenths of the required increase on a proportional basis (each item would be increased by the same percentage) to the items in group 1, two-sevenths of the required period increase on a proportional basis to the items in group 2 and one-seventh of the required period increase on a proportional basis to the items in group 3. No adjustment would be made to the group with the lowest TVO values, group 4. All sales and cash receipt forecasts are adjusted in a similar fashion using the relative TVO values (with the O variable having a zero weighting for account and customer forecasts) as the basis for preferential increase or decrease to the forecast for each period. The number of TVO segments and the relative weighting each segment receives can be changed by the user from the default values used in the example above. The relative weightings and number of segments used for TVO calculation are stored in the customer group TVO table, account TVO table and item TVO table. Having completed forecast of sales and cash receipts by account, by customer group and by item, the next processing step in accordance with the present invention is the calculation of the preliminary requisition set required to maintain inventory at the levels required to satisfy the user specified fill rate or margin loss targets for all of the individual items. All independent items are processed in alphanumeric order unless the user has limited the scope of item processing for the current scenario. After the independent item forecasts have been completed, the forecasts are completed for the dependent items in base item order. The preliminary requisition calculations for each item are completed before processing advances to the next item. In completing the calculations, the system uses information concerning: 1.) open purchase orders for the item, 2.) open sales orders for the item, 3.) the current on-hand inventory level for the item, 4.) the current available inventory level for the item, 5.) item units of measure, 6.) item vendors, 7.) item unit prices, 8.) item lead times, 9.) item sales forecast, 10.) item demand variability (V), 11.) order processing costs, 12.) inventory carrying costs, and 13.) the user specified fill-rate or margin-loss target for the item, to determine the appropriate target inventory level and the economic order quantity. For the preliminary requisition calculation, the system will assign either the vendor currently assigned to the item by the user or the vendor the item was most recently purchased from if no vendor has been specified by the user. The system then determines if the quantity price breaks offered by the selected vendor provide sufficient cost savings to change the calculated economic order quantity. Using this information, the system then determines the timing, number and size of the requisitions that will be required to maintain the target inventory level given the sales forecast and the days of operation the user has previously designated. After completing this initial requisition calculation, the requisition set that maximizes profitability is then calculated for each item within the constraints previously specified by the user. The constraints specified by the user relate primarily to the possibility of substituting different vendors and/or different units of measure in order to reduce costs. As discussed previously, the company using the system may have strategic or qualitative reasons for choosing to do business with a particular set of vendors or to buy goods using a particular unit of measure. To accommodate this very real concern, the user is given the ability in the present invention to control vendor substitution and unit of measure substitution at both the item and global forecast level. In accordance with the present invention, control at the forecast level is effected via the use of the Vendor Substitution and Unit of Measure Substitution variables in the system setting table. Control of vendor substitution and unit of measure substitution at the item level is implemented through the use of the Vendor Substitution and Unit of Measure Substitution variables in the item master table. The first step in the calculating the maximum profit requisition set is the segregation of items into those purchased under item quantity discounts and those purchased under business-volume discounts. Vendors that don't offer any type of volume discount are considered item discount vendors for purposes of this segregation. The system will analyze items with a combination of business volume and item-discount vendors using the logic described for item-discount items. The item quantity discount items are analyzed first. The analysis of these items is completed one item at a time in alphanumeric order. A profitability equation is created for each item by subtracting the total cost of storing, processing, and purchasing, the item from the potential vendors using the available units of measure and quantity price breaks from the forecast revenue from item sales during the forecast time period. The most profitable mix is selected as the base level mix for the item and the preliminary requisitions are adjusted as required to match the specified mix. When the base level requisitions for all the item quantity discount items have been calculated, processing advances to the calculation of base level requisitions for business volume discount items. The application software of the present system uses multi criteria, mixed-integer, linear program algorithms to calculate the profit maximizing requisition set for business volume discount schedule items. More specifically, the profit maximizing set of requisitions for items purchased under business volume discount schedules on a commitment basis is calculated by the application software and then the profit maximizing set of requisitions for items purchased using as-ordered business volume discount schedules is calculated in a similar fashion. The resulting set of requisitions is designated as the base-level requisitions for the business volume items. In accordance with the present invention, the system then calculates and displays the forecast time period financial status of the commercial enterprise in any of seven formats chosen by the user. If there isn't sufficient capital to pay for the base level requisitions and maintain the specified minimum available capital balance for all periods being forecast, then the system will display the resulting forecast, highlighting the periods with a deficiency in capital. From this point, processing can return to the initial input screens where the user can increase the borrowing capacity, change the amount of capital held in reserve, increase the forecast of capital additions, decrease the forecast of capital expenditures, change individual item sales forecasts, change the item fill rate targets and/or increase the item margin loss targets before re-running the forecast. Alternatively, the user can choose to have the system repeat calculations similar to the base-level requisition calculations within the forecast financial constraints. At the same time, if there is sufficient capital to complete the purchase of the base-level requisitions, the user has the option of editing any of the prior inputs or accepting the base-level financial forecast and proceeding to the profit enhancement step. The profit enhancement step mirrors the processing that was completed in the calculation of the base level requisitions. For example, the processing is completed in the same order discussed previously with potential profit enhancing changes for item-discount items being calculated first, profit enhancing changes for committed business-volume discount items being calculated second and profit enhancing changes for as-ordered business volume discount items being calculated last. Profit enhancing changes are generated by removing the user specified constraints on vendor substitution, item commitment percentages and unit of measure substitution. Calculations are completed to show the effect of removing previously specified constraints to clearly define for the user the cost of maintaining certain policies. For example, the user may prefer to buy bolts from Acme Bolt Company because of a long standing relationship. However, if the user learns that it is costing an extra $100,000 a year to do maintain this policy, the desirability of continuing the policy might be questioned. The user specifies which constraints (if any) are removed during profit enhancement calculations as part of the scenario specification. If the user elected to consider the potential increase in profit from removing either the vendor or the unit of measure substitution restrictions, then all potential changes that enhance profitability are stored and ranked on the basis of their capital efficiency. Capital efficiency is defined as the ratio of the profit improvement over the increase in average capital investment required to produce the profit improvement. When profit improvement is achieved with a reduction in average capital investment, capital efficiency is defined as the profit improvement plus the absolute value of the reduction in average capital investment. The potential changes are stored along with the calculated capital efficiency of each change for use in a display. The user is then presented with the listing of the potential changes to the base level requisitions in descending capital efficiency order (i.e., the most efficient changes are first). At this point the user is given the option of accepting any of the displayed profit enhancing changes until the sum of the increases in average capital investment for the accepted changes equals the lowest available capital balance during the forecast time period. Once the user has completed the selection of profit enhancing changes, the system calculates and displays the revised financial forecast that incorporates the accepted changes to base level requisitions. The user then has the option of accepting or rejecting the new financial forecast. If the user rejects the new financial forecast, then system processing returns to the display of potential changes to the base level requisitions. The user will then have the ability to accept additional changes and/or reject previously accepted changes before recalculating the financial forecast. The user's other option at this point would be to accept the revised forecast. If the revised forecast is accepted, then the base level requisitions stored in the application database are revised to reflect the accepted changes and the user is presented with the option of displaying or printing a variety of management reports. DETAILED DESCRIPTION As shown in FIG. 1, the preferred embodiment of the present invention is a computer system 1 illustratively comprising a plurality of client, personal computers 10 each with a display 11, a keyboard 12, a mouse 13 and a printer 14. These client, personal computers 10 are connected to a server, personal computer 20 via an interconnection network 30. The server, personal computer 20 also has a display 11, a keyboard 12 and a mouse 13. The system can be networked to fifty or more client, personal computers 10. The computers (10 and 20) shown in FIG. 1 illustratively are IBM-PCs or clones or any of the more powerful personal computers or workstations that are widely available. It is to be understood that the diagram of FIG. 1 is merely illustrative of one embodiment of the present invention. The same client 10 and the server 20 personal computers are shown from a different perspective in FIG. 2. While only one client, personal computer 10 is shown in FIG. 2, it is to be understood that the server, personal computer 20 can be networked via the interconnection network 30 to fifty or more client, personal computers 10. It is well known that such computers include a processor 53, 73, a read/write random access memory 52, 72, a means for writing data into said memory, an internal clock that tracks the current date and time 57, 87 and a communications bus 51, 71 for channeling data between the various system components. Typical memory configurations for client, personal computers 10 used with the present invention should include at least 8 megabytes of semiconductor random access memory 52 and at least a 250 megabyte hard drive 54. Typical memory configurations for the server personal, computer 20 used with the present invention should include at least 16 megabytes of semiconductor random access memory 72 and at least a 500 megabyte hard drive 84. Resident in the memory 52 of the each client, personal computer 10 during system operation is a portion of the application software 55 of the present invention that defines system operation with respect to client, personal computer 10 data input, display, and output. A user 60 inputs data and operating instructions into the client, personal computer input/output bus 51 from a keyboard 12 or mouse 13. The user 60 also has the option of directing the application software 55 to access data from computer files such as a database table 58 or an electronic worksheet 56. These database tables 58 and electronic worksheets 56 may be residing in the hard drive 54 of the client, personal computer 10 as shown in FIG. 2. Alternatively these files may reside in the server, personal computer 20 or in another client, personal computer 10 connected to the interconnection network 30. The information is processed in the random access memory 52 using the CPU 53 and optionally stored in the hard drive 54 before being transferred via the interconnection network 30 to the server, personal computer 20. After some amount of processing is completed by an application software 80 of the present invention using the CPU 73 in the server, personal computer 20, the user 60 can view the responses from the application software 80 of the present invention that have been transferred via a data input-output segment 79 of the application software 80 to the system bus 71 to the interconnection network 30 where it is in turn passed on to the client, personal computer system input/output bus 51 and on to the display device 11 or printer 14. Data can be received from any client, personal computer 10 connected to the interconnection network 30. Reports can be output to electronic worksheets 56, database files or printed reports using the printer 14. The output can be directed to any computer connected to the interconnection network 30. Resident in the memory 72 of the server, personal computer 20 during system operation is the application software 80 of the present invention which provides for enhanced inventory management. The application software 80 consists of six interrelated segments, namely, a system settings and operations segment 74, an inventory replenishment subsystem 75, a customer payment analysis subsystem 76, a financial forecast subsystem 77, a data source mapping subsystem 78 and a data input/output segment 79. A data base management system software 81, an application database 90, a basic financial system software 82 and a basic financial system database 95 are also resident in the server, personal computer memory 72 as required during system operation. The data base management system (and the application database) is preferentially a relational database that conforms to the ANSI SQL89 standard. As is well known, common features of relational databases include primary and foreign key support, integrity checking and backup and recovery using logs. These features can be used to support indexing and filtering of the database during processing. The software and databases mentioned previously, 74, 75, 76, 77, 78, 79, 80, 81, 82, 90 and 95, are typically stored in the hard drive 84. As discussed previously, the user 60 normally interacts with the application software 80 by entering data and commands into the client, personal computer 10 which is connected with the server, personal computer 20 via the interconnection network 30. Alternatively, the user 60 may operate the system by entering data and operating instructions directly into the server, personal computer 20 from a keyboard 12, mouse 13. Operating in this manner, the user 60 would receive the responses from the server, personal computer 20 on the server, personal computer display device 11. The diagram of FIG. 2 is illustrative of only one embodiment of the present invention. An individual skilled in the art will immediately recognize that each segment of the application software (74-79), the database management system 81, Basic Financial System Software 82, the application databases 90, and the basic financial system database 95 currently shown as resident in the server, personal computer hard drive 84 can be distributed in many different combinations to other computers connected to the interconnection network 30. Alternatively, all the elements shown could be included on one computer eliminating the need for client, personal computer 10 and the interconnecting network 30. System Setting and Operation The flow diagram in FIG. 3A and FIG. 3B provides an overview of the processing in the inventive system for generating a listing of feasible profit-enhancing changes to the base-level requisition set. Processing starts with the user's entry of the system setting variables in a block 100 to define: the type of forecast to be run; the time period used for forecast calculation (weeks or months); the number of forecast time periods (maximum of 18 months or 78 weeks); the number of time periods that requisitions will be calculated for (maximum is equal to the number of forecast time periods); the source for transaction data (user-input, computer files or a basic financial system database); the source for item forecast historical data (sales transactions or inventory transactions); the minimum acceptable available capital balance (e.g., cash plus available credit); the number of days per week the business operates (five or seven days); the default currency for all calculations; the default location; the default cost for placing, receiving and stocking an order; the default display format for the financial forecast; if vendor substitution is to be considered for any item; the default inventory carrying | ||||||