WO2001071635A2

WO2001071635A2 - Managing orders based on budget restrictions in a procurement management system

Info

Publication number: WO2001071635A2
Application number: PCT/US2001/009534
Authority: WO
Inventors: Mark Resh
Original assignee: Igetsmart.Com, Inc.
Priority date: 2000-03-23
Filing date: 2001-03-23
Publication date: 2001-09-27
Also published as: WO2001071632A2; AU2001247769A1; AU2001252954A1; WO2001071546A2; WO2001071546A8; AU2001255192A1; WO2001071635A8

Abstract

A method of managing orders based on budget restrictions in a procurement management system is disclosed. Data is received and stored that defines a budget period, specifies a budget identifier that is to be associated with the budget period, and specifies a budget restriction that is associated with the budget identifier. An order request associated with the budget identifier is received. A revised aggregate budget basis is determined based on the budget basis of the order request and an aggregate budget basis for any orders accepted during the budget period for the budget identifier. If the revised aggregate budget basis conforms to the budget restriction, the order request is accepted, and if not, the order request is denied. According to other features, a budget restriction type is received and stored, such as a currency amount, an item quantity, and an item type quantity, and an approval feature is used.

Description

MANAGING ORDERS BASED ON BUDGET RESTRICTIONS IN A

PROCUREMENT MANAGEMENT SYSTEM

FIELD OF THE INVENTION

The present invention generally relates to procurement management systems. The invention relates more specifically to a method and apparatus for managing orders based on budget restrictions in a procurement management system.

BACKGROUND OF THE INVENTION

The traditional process of inventory procurement, including the design of customized products and procurement of an order, can require extensive collaboration by multiple parties, such as manufacturers, distributors, resellers, vendors, customers, and users. Manufacturers create products that are sold on the retail market directly to users and on the wholesale market to distributors and vendors. Distributors buy products from manufacturers and vendors for resale to customers, with the distributors performing little or no modification to the products. Resellers are similar to distributors in that resellers purchase products from others for resale to customers, but resellers may add value to the products sold to customers, such as by configuring or customizing the products for particular uses or customers. Vendors buy from manufacturers for resale to distributors, and vendors may buy basic materials or products from manufacturers and produce finished products for sale to distributors and customers. Customers are companies, organizations, and individuals that make purchases from others. Users are individuals that interact with other entities, and users include persons working with and for customers, resellers, distributors, vendors, manufacturers, and other companies and organizations. End users are individuals that typically work with or for a customer, and who place orders with other entities for specified goods and services.

As an example ofthe traditional procurement process, consider an end user at a customer company that wishes to purchase a printed product. The customer company may be referred to as the print buyer. After the user identifies the need for the product, the user submits a request for the printed product to the customer company's purchasing department. The purchasing department may reject or accept the request. If the request is accepted, the purchasing department checks to see if the product is in current inventory. If the product is in stock, the customer company arranges for delivery to the user from the customer company's warehouse. If the product is not in stock, the purchasing department contacts the reseller or print manufacturer from whom the product was originally purchased through an external procurement process, or the purchasing department commences the external procurement process again to find a new provider.

If a new provider is necessary, the user confers with the purchasing department regarding the specifications for the order, and the purchasing department sends a request for quotation (RFQ), request for information (RFI), or request for procurement (RFP) to multiple resellers or print manufacturers if the print manufacturer has its own sales force. The resellers and print manufacturers respond to the RFQ by submitting bids, typically by facsimile or by telephone. If the customer company selects the bid of a print manufacturer, the print manufacturer creates the printed product and arranges for delivery and billing to the print buyer. If the customer company selects the bid of a reseller, the reseller requests bids from print manufacturers. Once the reseller selects a bid, the selected manufacturer creates the printed product and arranges for delivery to the customer company.

Despite the importance ofthe purchasing function and the prevalence of information technology systems in many enterprises, procurement of many types of products remains extremely manual, heavily paper-based, labor-intensive, decentralized, and often involves multiple layers of corporate bureaucracy, as shown in the example above. Decentralized purchasing makes it difficult for businesses to manage employee purchases, control spending, prevent duplicative or unauthorized orders and maintain appropriate levels of inventories to satisfy internal needs and avoid obsolescence. Depending on the nature and the size of an order, the costs of procuring some products can exceed the cost ofthe products themselves.

A number of companies have attempted to use information technology to reduce the inefficiencies that characterize the traditional procurement process of most corporate purchasing functions. However, existing electronic purchasing methods have limitations that prevent widespread adoption by buyers and sellers.

One example of an electronic purchases method is electronic data interchange (EDI). EDI systems involve a set of uniform formats for commercial documents such as invoices and purchase orders that allow computers to exchange such documents across private networks without human intervention. EDI systems have several barriers to implementation, such as the high cost of installation and maintenance as well as significant, on-going transaction fees. Because EDI systems rely on the execution of predefined transactions, EDI systems generally are not well suited to dynamic procurement environments involving many buyers and suppliers or a wide variety of goods and services. Due to expense and complexity, EDI systems generally are unsuitable for all but the largest organizations because the majority of resellers and customers are unable to justify the resources necessary to independently create and maintain procurement management systems.

Another problem with existing procurement systems is maintaining optimal inventory levels, which is important for reducing back orders, rush orders, rush charges, and obsolescence. One approach is to set minimum/maximum levels to trigger reorders, but such an approach has limited flexibility, and the effectiveness depends on the ability to correctly estimate the proper levels for triggering reorders.

Based on the foregoing, there is a need for an improved system for managing the procurement of products and services.

SUMMARY OF THE INVENTION

Techniques are provided for an improved system for managing the procurement of products and services. In one aspect, the invention provides a method of managing orders based on budget restrictions in a procurement management system. Data that defines a budget period is received and stored. Other data that specifies a budget identifier is received and stored. An association between the budget identifier and the budget period is created and stored. Still other data that specifies a budget restriction that is associated with the budget identifier is received and stored. An order request associated with the budget identifier is received, and a budget basis is associated with the order request. An aggregate budget basis is determined for any orders accepted during the budget period for the budget identifier. Any such orders are each associated with a budget basis and the aggregate budget basis is based on a cumulative budget basis for all orders accepted during the budget period for the budget identifier. A revised aggregate budget basis is determined based on the budget basis ofthe order request and the aggregate budget basis. The revised aggregate budget basis is compared to the budget restriction. If the revised aggregate budget basis conforms to the budget restriction, the order request is accepted, and if not, the order request is denied. According to another feature, a budget restriction type is received and stored, such as a currency amount, an item quantity, and an item type quantity. According to other features, an approval feature is used for approving orders that conform to the budget restriction and for approving orders that do not conform to the budget restriction, and the cumulative budget basis may be deteπnined in response to the order request, or the cumulative budget basis may be tracked and updated for each order for the budget identifier.

In another aspect, the invention provides a method of generating and electronically sending reports to electronic destinations in a procurement management system. A procurement management database is maintained, which includes records about items in inventory and transactions associated with the items. A request for a report is received, which specifies a report type, search criteria, and formatting parameters. In response to the report request, the procurement management database is searched for records that conform to the report type and search criteria. A report is generated based on the matching records and the formatting parameters. The report is sent electronically to electronic destinations, such as a fax number or an e-mail address.

According to other features, the report is an electronic document that is attached to an e-mail message, and the electronic document is in the rich text format. According to yet other features, the search criteria specify ranges of data to be search, and the parameters for formatting the report specify types of data to be included in the report and options for organizing the data in the report. According to other features, the search criteria specify a master account that is associated with secondary accounts to which the search is limited, and the search criteria specify a product group code that is associated with products to which the search is limited.

In another aspect, the invention provides a method of selectively generating an inventory item reorder notification based on lead-time values and actual average usage values. Data defining master inventory analysis functions and schedules, and master inventory analysis behavioral parameters, is received. Other data defining inventory analysis functions, schedules, and behavioral parameters for specific inventory items is received. A schedule of inventory analyses is created and stored. When a scheduled inventory analysis executes, it determines whether to generate an item reorder notification. According to one feature, an average periodic usage value for the inventory item is determined, and a pre-determined lead-time value for the inventory item is retrieved. A reorder level value is computed as the mathematical product ofthe average periodic usage value multiplied by the lead-time value. If the quantity on hand ofthe inventory item is less than the reorder level, then a reorder notification is generated. According to other features, the reorder notification is generated based on a fixed level par value for the inventory item, cyclically by a fixed date, or cyclically by elapsed time.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example, and not by way of limitation, in the figures ofthe accompanying drawings and in which like reference numerals refer to similar elements and in which:

FIG. 1 A is a block diagram that illustrates the entities that interact through a network with a procurement management system.

FIG. IB is a block diagram that illustrates a high level overview of a procurement management system.

FIG. 2 is a flow diagram that illustrates a method for logging in a user to a procurement management system.

FIG. 3 is a flow diagram that illustrates a menu of options for a corporate manager in a procurement management system.

FIG. 4A is a flow diagram that illustrates a menu of inventory/purchasing options.

FIG. 4B is a flow diagram that illustrates a method of ordering merchandise.

FIG. 4C is a flow diagram that illustrates a method of making an inventory inquiry.

FIG. 4D is a flow diagram that illustrates a method for making an open purchase order inquiry.

FIG. 4E is a flow diagram that illustrates a method for making a back order inquiry (with item search).

FIG. 4F is a flow diagram that illustrates a method for making a back order inquiry (only item search).

FIG. 5 is a flow diagram that illustrates a method for making online inquiries.

FIG. 6 is a flow diagram that illustrates a method for generating reports.

FIG. 7 A is a flow diagram that illustrates a high level overview of a method for setting up budget restrictions in a procurement management system. FIG. 7B is a flow diagram that illustrates a high level overview of a method for managing order requests based on budget restrictions in a procurement management system.

FIG. 8 is a block diagram that illustrates budget restriction setup information.

FIG. 9A is a flow diagram that illustrates a high level overview of a method for producing reports in a procurement management system.

FIG. 9B is a flow diagram that illustrates a method for generating a report in a procurement management system.

FIG. 10A is a flow diagram that illustrates a top-level view of a process of generating reorder notification messages.

FIG. 1 OB is a flow diagram that illustrates a process of generating reorder notification messages.

FIG. 11A is a diagram of a screen display that receives report option default values for master inventory analysis records.

FIG. 1 IB is a diagram of a screen display that receives report calculation values for master inventory analysis records.

FIG. 12A is a diagram of a screen display that receives report option default values for inventory analysis item detail records.

FIG. 12B is a diagram of a screen display that receives report calculation values for inventory analysis item detail records.

FIG. 13 is a flow diagram of a process of determining whether to generate a reorder notification based on usage lead-times.

FIG. 14 is a block diagram that illustrates a computer system upon which an embodiment may be implemented.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

A method and apparatus for managing orders based on budget restrictions in a procurement management system is described, ha the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding ofthe present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention. In the following description, the various functions are discussed under topic headings that appear in the following order:

I. STRUCTURAL AND FUNCTIONAL OVERVIEW OF A PROCUREMENT MANAGEMENT SYSTEM OVERVIEW

II. EXAMPLE IMPLEMENTATION OF PROCUREMENT MANAGEMENT SYSTEM

III. MANAGING ORDERS BASED ON BUDGET RESTRICTIONS

IV. GENERATING AND ELECTRONICALLY SENDING REPORTS TO ELECTRONIC DESTINATIONS

V. USING LEAD-TIMES AND USAGE RATES TO DETERMINE INVENTORY REORDER POINTS AND LEVELS

VI. HARDWARE OVERVIEW

I. STRUCTURAL AND FUNCTIONAL OVERVIEW OF A

PROCUREMENT MANAGEMENT SYSTEM

A procurement management system is a system that manages the activities of different entities involved in procuring goods and services. For example, manufacturers, vendors, distributors, resellers, and customers interact with the procurement management system to facilitate wholesale, and retail sales of goods. The goods maybe stored in warehouses operated by each ofthe different entities, or the goods may be stored in warehouses that are provided by the procurement management system provider. Typically the customers ofthe procurement management system are the entities that participate in the wholesale market, although retail customers ofthe entities participating in the wholesale market may access the procurement management system for placing and managing retail orders. The customers ofthe procurement management system may outsource part or all ofthe procurement functions, such as inventory management, order fulfillment, and billing, to the procurement management system.

For purposes of explanation herein, the types of users that interact with the procurement management are broadly classified into four types: (1) resellers who are the customers ofthe procurement management system and who include manufacturers, vendors, and distributors, as discussed below; (2) corporate managers, also referred to as customer administrators, who typically are management or administrative workers at the customers ofthe resellers and who help manage procurement activities for the customer organization; (3) corporate users, also referred to as shopping cart users or end users, that are typically employed by the customers and who generally are the individuals that place orders; and (4) internal users who work for the procurement management system provider. The type of user is determined by each user's authorization code, which in turn may be used to control the information, menus, options, functions, and other features of the procurement management system that each user may see, access, and modify, as discussed more fully below.

FIG. 1 A is a block diagram that illustrates the entities that interact through a network with a procurement management system. While FIG. 1 A typically only shows two of each ofthe several types of entities illustrate, in practice the number of each type of entity is not limited. Also, additional types of entities may interact with the procurement management system, and not all ofthe entities shown need interact with the procurement management system. The entities shown in FIG. 1 A are not limited to the types of functions described herein, and different entities may perform functions that are typically performed by other entities.

FIG. 1 A shows a procurement management system 110 that is connected to a public network 120, such as a local area network, a wide area network, or the worldwide public communication network now commonly referred to as the Internet. Procurement management system 110 is connected to warehouses 112, 114 that maybe used to house inventory associated with the entities that interact with procurement management system 110. Procurement management server is connected to a non-electronic vendor 109. For example, non-electronic vendor 109 may represent a source of goods from a company or organization that is taken over by procurement management system 110 or otherwise incorporated into the inventory that is stored in warehouses 112, 114 as a result of a non-electronic event or transaction that occurs outside of procurement management system 110.

Procurement management system 110 is communicatively coupled to a variety of different types of entities through public network 120. As shown in FIG. 1 A, procurement management system 110 is communicatively coupled to the following entities: manufacturers 130, 132 that produce raw materials or finished products for direct sale or resale to the other entities shown in FIG. 1 A; vendors on a marketplace 140, 142 that buy products from some entities such as manufacturers 130, 132 and resell them to other entities shown in FIG. 1 A via procurement management system 110, and the goods sold by vendors on a marketplace 140, 142 may involve creating finished products from other goods; distributor/resellers 150, 152 that purchase finished goods from other entities, such as manufacturers 130, 132 and vendors on a marketplace 140, 142, for resale to other entities shown in FIG. IB, and that may also purchase finished goods from other entities for resale after adding value to the products, such as by combining products into a larger collection of products or including other services such as maintenance and training as part ofthe solution sold to a retail customer; and end customer or users 170, 172 that purchase products from the other entities shown in FIG. 1 A. An end customer is typically the individual that works for a customer company and that purchases products or makes requisitions, such as a corporate user. A user is typically a corporate manager that works at a customer company and manages the procurement process for the customer. Any ofthe entities shown in FIG. 1 A may work with or employ users ofthe procurement management system.

FIG. IB is a block diagram that illustrates a high level overview of a procurement management system. While FIG. IB illustrates particular elements in a procurement management system, in practice additional elements may be added or excluded, more than one of each type of element maybe included, and the functions of more than one element may be combined and performed by one element or broken up and performed by many elements ofthe same or a different type.

FIG. IB shows procurement management system 110 communicatively coupled to public network 120. A client 124 is communicatively coupled to public network 120. Client 124 may be a general purpose computer operated by a user ofthe procurement management system, and the user may access the procurement management system using a browser application and requesting electronic documents, such as Web pages over the World Wide Web, from procurement management system 110.

Procurement management system 110 includes a router 180 that is communicatively coupled to public network 120 and through which passes all communications from public network 120 to procurement management system 110. Router 180 receives requests from client 124 through public network 120 and directs the requests for the procurement management system to a firewall 182 that is communicatively coupled to router 180 within procurement management system 110. Firewall 182 may be implemented as a hard wired or software firewall tunnel such as a GNAT Box manufactured by Global Technology Associates, Inc.

According to one embodiment, firewall 182 is communicatively coupled to a demilitarized zone 184 that includes a presentation process and transaction server(s) 186 and a procurement server(s) 188. Demilitarized zone 184 provides security in addition to the security provided by firewall 182. Demilitarized zone 184 helps ensure that access from public network 120 is limited to the information contained within demilitarized zone 184 and helps prevent access to other information and elements contained within procurement management system 110, such as a protected internal network 192 and an application and data warehouse server(s) 190. Once a connection is established between client 124 and one ofthe servers in demilitarized zone 184, data is transferred in both directions through firewall 182, router 180, and public network 120.

Firewall 182 directs requests from users of procurement management system 110 to procurement server(s) 188, while requests from other types of users, such as corporate managers, resellers, and internal users are directed to procurement management system 110 are directed to presentation process and transaction server(s) 186. However, other implementations of a procurement management system may include additional servers and direct requests based on user types or other criteria in a manner different than that explained herein with reference to FIG. IB.

Protected internal network 192 is communicatively coupled to presentation process and transaction server(s) 186, procurement server(s) 188, and application and data warehouse server(s) 190 that is part of procurement management system 110. Although application and data warehouse server(s) 190 is shown separately from protected internal network 192 for purposes of description, in practice application and data warehouse server(s) 190 is a part of protected internal network 192. In addition, protected internal network 192 allows users ofthe procurement management system provider to access procurement management system 110 without using public network 120, although such users may also access procurement management system 110 using a client and a network such as client 124 and public network 120.

As a result of using firewall 182 and demilitarized zone 184, the portion of FIG. IB from router 180 out to public network 120 may be referred to an unprotected area of procurement management system 110. Similarly, the portion of procurement management system 110 that includes protected internal network 192 and application and data warehouse server(s) 190 maybe referred to as the protected area.

According to another embodiment, presentation process and transaction server(s) 186 and procurement server(s) 188 that are within demilitarized zone 184 are communicatively coupled to an application and data warehouse server(s) 190. The applications and the data warehouses that may be in the form of one or more databases, which comprise the core of procurement management system 110, are accessed from application and data warehouse server(s) 190. A data warehouse includes data that is used regularly, such as on a day-to-day basis, and data that is not used regularly, such as archived data.

According to yet another embodiment, application and data warehouse server(s) 190 is implemented on an IBM AS/400 computing system. The applications on the AS/400 are custom-designed to implement the functions and features of procurement management system 110. The AS/400 may use the report program generator (RPG) programming language. Application and data warehouse server(s) 190 may include additional applications in other high level programming languages, such as Java, JavaScript, CLP, C, HTML, XML, or CML. As an example, iGetSmart.com, Inc., provides the iGetSmart™ system that is comprised of applications in several different high level programming languages and data storage, which may be used as part of a procurement management system.

Presentation process and transaction server(s) 186 transforms the input and output application and data warehouse server(s) 190 to generate input and output in another format for distribution to client 124. For example, presentation process and transaction server(s) 186 may be implemented using a visual development toolkit to recreate the screens from application and data warehouse server(s) 190 in a format suitable for dissemination over the World Wide Web. The visual development toolkit can be used to edit the Web screens for presentation and object properties. An example of a visual development toolkit that may be used is J Walk by Seagull Technology, Inc. Presentation process and transaction server(s) 186 may use the WindowsNT operating system by Microsoft Corporation.

Presentation process and transaction server(s) 186 also handles transactions, typically from users such as corporate managers, although other users may access presentation process and transaction server(s) 186 to make purchases and place requisitions.

Procurement server(s) 188 provides client access to limited information from application and data warehouse server(s) 190. The access may be referred to as "thin" because the information and features accessible through procurement server(s) 188 are less comprehensive than those accessible through presentation process and transaction server(s) 186. As a result, procurement server(s) 188 maybe characterized as a streamlined server in comparison to presentation process and transaction server(s) 186.

For example, procurement server(s) 188 may limit the information that is accessed to item names, stock levels, and prices, and the features may be limited to placing orders for the items identified and charging the orders to a cost center or a credit card. As another example, procurement server(s) 188 maybe intended for use by end-users or corporate users for making purchases and requisitions.

Typically, procurement server(s) 188 is used by corporate users, also known as shopping cart users, to access the procurement management system to place orders. For example, the procurement management system may offer a Web based shopping interface that features lists product lines, product groups, or product categories and lists of products for each product line, group, or category, that are available for direct purchase via the procurement management system. The shopping interface may use a shopping cart to track the products that a user has selected for purchase. Other implementations of procurement management system 110 may associate different types of users with procurement server(s) 188 or other servers with other types of users.

Because procurement server(s) 188 is communicatively coupled to application and data warehouse server(s) 190, corporate users may access real-time stock levels that are tracked by procurement management system 100. hi addition, any orders placed by the corporate users using procurement server(s) 188 are submitted directly to application and data warehouse server(s) 190 for fulfillment. In contrast, other systems send orders by e- mail to be entered by hand. Procurement server(s) 188 may be implemented on a WindowsNT computer, but such a platform is not required and other platforms may be used.

According to one embodiment, a user accesses a login screen on a Web page associated with the procurement management system. The login screen uses a servlet to allow the user to enter authorization information, such as a username and password. Also, the servlet begins a session with the visual development toolkit, such as a J Walk session, and the login servlet may start an applet that in turn starts a Java container that enables a preview images function for specific screens used for the procurement management system, hi addition, the applet may determine the user type for the user based on the user's login information so that the appropriate menus, functions, features, and options may be retrieved.

II. EXAMPLE IMPLEMENTATION OF A PROCUREMENT MANAGEMENT SYSTEM

According to one embodiment, a user accesses a procurement management system via a network, such as a local area network, a wide area network, or the Internet. For example, the user uses a client, such as a general purpose computer, that includes a browser application, such as Microsoft Internet Explorer or Netscape Navigator. Using the browser, the user receives an electronic document, such as a Web page over the World Wide Web. The received electronic document is associated with the procurement management system and allows the user to log in to the system using identification information, such as a username and password.

According to another embodiment, an authorization code is associated with the user. Depending on the setup ofthe user's account with the procurement management system, the user may be prompted to supply a separate authorization code after login, or the system may automatically use the combination ofthe username and password or just the user's password as the authorization code. The authorization code may be used to determine the options, functions, and actions that the user may access or use in the procurement management system.

FIG. 2 is a flow diagram that illustrates a method for logging in a user to a procurement management system. The method illustrated in FIG. 2 may be implemented using a variety of approaches. For example, a separate login process, such as an applet running on the client, may be used. Also, one or more electronic documents or Web pages may be sent to the client as part ofthe login method, or a larger application running on a server associated with the procurement management system and that interacts with the client over a network may be used. While FIG. 2 provides a particular order ofthe steps ofthe method of logging in a user, a different order may be used, additional steps may be included, or steps presented in FIG. 2 may be omitted. The method illustrated in FIG. 2 begins at block 202 where the user enters into the user's browser application a World Wide Web address, such as a uniform resource locator (URL), for a Web page on a server that is associated with the procurement management system. For example, the user may enter the address as http ://www.igetsmart.com to access the home page ofiGetSmart.com, Inc., and from the iGetSmart.com home page the user may access the login procedure by selecting a login object on the home page, such as a "Corporate Managers Login Here" link or a "Corporate Users Login Here" link. Users may elect to save the address ofthe login Web page for convenience, such as by using the "bookmark" function ofthe browser application.

In block 204, the user is presented with the "Login Screen," or login Web page, that is associated with the Web address supplied by the user. The login Web page allows the user to enter a form of user identification, such as a userid or other unique identifier, and a password associated with the unique identifier. Identifiers and passwords may be issued to the corporate users and corporate managers ofthe procurement management system by resellers or by the procurement management system provider to anyone that uses the system. For example, a userid may comprise the first initial of a user's first name and up to nine letters ofthe user's last name.

In block 206, the identification and password provided by the user are checked to determine if they are correct, such as by matching the userid and password supplied by the user against a list or database of valid user identifiers and passwords. If the identification and password are correct, the method continues to block 208, but if the identification and password are not correct, the method returns to block 204 to allow the user to try to enter valid identification information again.

In block 208, the user sees a Web page featuring a "Welcome Screen." After the user is logged into the procurement management system, the servers associated with the system, such as presentation process and transaction server(s) 186 and procurement server(s) 188 in FIG. IB, may deliver one or more applets to the user's browser. The browser application running on the client automatically executes the applets. For example, Java may be used.

In block 208, the procurement management system queries the user to determine if the user wishes to access a corporate account or promotional materials. For example, the system may use an applet to provide a dialog box to the user to present such a query and receive the user's selection or other response. If the user selects promotional materials, the method proceeds on to block 214, from which the user accesses the promotional materials that are available. If the user selects corporate account, the method proceeds to block 210.

In block 210, the user is requested to provide an authorization code. The authorization code may be used to determine the role and level of access permitted for the user. For example, resellers may create, store, and use shopping lists based on user roles, or groups. As another example, users that are purchasing agents may be restricted to particular classes of goods that are appropriate to the business unit that they serve.

According to another embodiment, only some users ofthe system, such as resellers or internal users, are prompted for a separate authorization code after logging in. Other users, such as corporate users and corporate managers, are not prompted for a separate authorization code after logging in because the procurement management system automatically assigns the user's password as the authorization code for such types of users. The procurement management system identifies in a user configuration record or file whether each user has a separate authorization code or whether the system should automatically enter the user's password as the authorization code.

According to yet another embodiment, the collection and verification of an authorization code above is not performed, and the combination ofthe user's username and password or just the password is used as the authorization code for all user types.

In block 212, the authorization code is checked to determine it if is correct, such as by comparing the code to a list or database of valid authorization codes. If the authorization code is correct, the method continues on to a main menu 302 as shown in FIG. 3. If the authorization code is not correct, then the method returns to block 210 to allow the user to re-enter the authorization code. If the user fails to enter the correct authorization code after a predetermined number of attempts (e.g., after three attempts), the user is not allowed to make further attempts to provide a valid authorization code without seeking technical assistance.

FIG. 3 is a flow diagram that illustrates a menu of options for a corporate manager in a procurement management system. Other types of users may see fewer, more, or different menu options after logging in and providing an authorization code, if required. The particular options shown in FIG. 3 are representative examples, and additional options may be included or options shown in FIG. 3 may be omitted. In FIG. 3, a main menu 302 is shown, which may be implemented using an electronic document sent from a server to a client, such as a Web page from presentation process and transaction server(s) 186 to client 124 as shown in FIG. IB. Main menu 302 includes a number of options or additional menus for different types of features and functions. After selecting the options or menus included in main menu 302, users may return to main menu 302 to select additional options or menus.

While main menu 302 includes several different menu options and features, not all ofthe options and features may be used in a particular implementation and additional options and features may be included. In addition, the particular menu options and features may depend on the type of user, such as reseller, corporate manager, corporate user, or internal user. The example menu options and features described herein are typical of those seen by the corporate manager type of users.

Main menu 302 includes an inventory/purchasing menu 304 that allows users to place and check orders. If the user selects inventory/purchasing menu 304, another set of options and menus is provided, such as those shown in FIG. 4A that is discussed below.

Main menu 302 includes a reports wizard 306 that allows users to obtain reports from the procurement managements system. If the user selects reports wizard 306, another set of options and menus is provided, such as those shown in FIG. 6 that is discussed below. Similar reporting options and features may be included as part of other menu options. For example, sales representatives who are employed by resellers may be authorized to view and use a purchase order menu that allows for creating and managing purchase orders, or the employees of a reseller may be able to access an inventory reports menu. Other reporting features and menus may include one or more report options that include the feature of sending the requested report via e-mail or fax to one or more individuals or fax numbers, respectively.

Main menu 302 includes an online inquiries 308 option that allows users to submit inquiries to the procurement management system. If the user selects online inquiries 308, another set of options and menus is provided, such as those shown in FIG. 5 that is discussed below.

Main menu 302 includes a "review new enhancements to the product" option 310 that allows users learn more about recent changes to the procurement management system and how the changes may affect the users use ofthe system. For example, if the user selects "review new enhancements to the product" option 310, the user maybe asked to provide an "effective date." The system then provides all enhancement notifications to the user since the effective date, and the user may select one or more ofthe listed enhancements to learn about the selected enhancement.

Main menu 302 includes a "sign off' option 312 that allows a user to sign off, or log out, from the procurement management system.

FIG. 4 A is a flow diagram that illustrates a menu of inventory/purchasing options. The particular inventory/purchase options shown in FIG. 4A are representative examples, and additional options may be included or options shown in FIG. 4A may be omitted.

An inventory/purchasing menu, such as that shown in FIG. 4A, provides access to functions ofthe application programs relating to manipulating requisitions and requisition-related data. Users navigate to particular menus by selecting the menu options. From the requisitions menu, a user may select from several sub-functions. For example, to order merchandise, the user is provided with an order form on which to enter charge account information, shipment information, and any other information required to make the requisition, or order. The user may select products from one or more product lines. The product lines available to the user may depend on the role and level of access ofthe user based on the user's authorization code.

Other sub-functions that may be accessed from the purchasing menu include: allowing the user to submit a requisition for the release or transfer of existing inventory; submitting a requisition for replenishment (e.g., via a purchase) of depleted inventory; verifying inventory levels including checking the items on hand and the items on back order; and verifying the status of unfulfilled requisitions.

According to another embodiment, the procurement management system maintains real-time inventory information so that views regarding inventory are up to date and accurate, and all inquiries and other transactions are immediately reflected in updates to the inventory information, such as may be included in an inventory database.

According to one embodiment, all data entry involves a dialog at the client between the user and an applet. An applet generally is a small utility application often written in an object oriented programming language such as Java. The applet is provided by a server and runs on the client so as to reduce network traffic between the client and the server. When the order form is complete, the applet sends the information to a server associated with the procurement management system, such as presentation process and transaction server(s) 186 that in turn passes forwards the request to application and data warehouse server(s) 190. For example, to modify inventory, a user enters the quantity of products that the user wishes to receive, or transfer. The applet displays a screen that enables the user to review the order prior to the user submitting the order for release.

According to another embodiment, the user may select to preview the actual appearance of a product. For example, after obtaining a list ofthe inventory items, the user may select a particular inventory item to be released and preview the actual appearance ofthe item before ordering the release ofthe item. The product preview function may be implemented in a what-you-see-is-what-you-get (WYSIWYG) graphical user interface window that pops up over the inventory item list.

FIG. 4A shows inventory/purchasing menu 304 from FIG. 3, which maybe implemented using an electronic document sent from a server to a client, such as a Web page from presentation process and transaction server(s) 186 to client 124. Also, inventory/purchasing menu 304 may be implemented using an applet that presents the options or functions available to the particular user, receives the user's selection, and sends a message to the procurement management system regarding the user's selection.

Inventory/purchasing menu 304 includes a number of options or additional menus for particular types of features and functions related to inventory and purchasing. After selecting the options or menus included in inventory/purchasing menu 304, users may return to inventory/purchasing menu 304 to select additional options or menus.

Inventory/purchasing menu 304 includes an order merchandise 402 option that allows users to order products and services. If the user selects order merchandise 402, another set of options or menus is provided, such as those shown in FIG. 4B that is discussed below.

Inventory/purchasing menu 304 includes an inventory inquiry 404 option that allows users to submit inquiries about items in an inventory. If the user selects inventory inquiry 404, another set of options or menus is provided, such as those shown in FIG. 4C that is discussed below.

Inventory/purchasing menu 304 includes an open PO inquiry 406 option that allows users to inquire about the status of open purchase orders (PO's). If the user selects open PO inquiry 406, another set of options or menus is provided, such as those shown in FIG. 4D that is discussed below.

Inventory/purchasing menu 304 includes a back order (with item search) 408 option that allows users to check the status of back ordered items, such as by using a search function. If the user selects back order (with item search) 408, another set of options or menus is provided, such as those shown in FIG. 4E.

Inventory/purchasing menu 304 includes a back order (current items only) 410 option that allows users to check the status of items that are currently on back order. If the user selects back order (current items only) 410, another set of options or menus is provided, such as those shown in FIG. 4F.

Inventory/purchasing menu 304 includes a sign off 412 option that allows a user to sign off, or log out of, the procurement management system.

FIG. 4B is a flow diagram that illustrates a method of ordering merchandise. The method begins with the user selecting the option for order merchandise 402 in FIG. 4A. While a particular order ofthe additional steps ofthe method of ordering merchandise are provided in FIG. 4A, a different order may be used, and additional steps may be included or steps presented in FIG. 4A may be omitted.

In block 414, the user enters billing and shipping information, and in block 416 the user selects the product line from which to order. For example, the user may have the option of selecting "Office Supplies" or "Managed Inventory." The available product lines from which the user makes a selection may be based on the role and level of access for the user based on the user's authorization code. Also, the items that can be seen in a particular listing for a product line may be a subset ofthe items available, which may be used by a customer company that desires its employees to only be able to see particular items or by a reseller that desires its customers to only be able to see particular items. An option to perform searches on the complete inventory catalog of items for the product line maybe provided to allow users to find additional items not included in the subset of items presented for review.

In block 418, the user locates the inventory, or item, that the user wishes to order from the product line selected in block 416. An option may be provided that allows the user to switch back and forth between one view showing all available items and another view that shows ordered items.

In block 420, the user enters a quantity ofthe product to order.

In block 422, if the user wants to order additional items, the method returns to block 418, but if the user does not want to order additional items, the method continues on to block 424. In block 424, the user reviews the order and chooses from a number of options regarding the disposition ofthe order. For example, the user may release or submit the order, save the order for future release, modify or change the order, review the items in the order, or cancel the order. The review order screen may default to a summary view that shows general information about the entire order, such as the total cost. The review order screen may include an option to view the order in detail, including price, quantity, description, and other information for each item. Additional item details may be viewed by selecting an item from the detail review order screen. Once an item is selected for review, additional options may be provided, such as viewing an inventory usage analysis for the item, which may include a graph ofthe usage ofthe selected item over the current or past year.

After the user has made a disposition ofthe order, the method continues to block 426 where the user may return to a desired screen or menu option from those already viewed by using the back button feature on the browser application that the user is running on the client. For example, the user may return to order merchandise 402 to place another order, to inventory/purchasing menu 304 to select another inventory or purchasing option, or to main menu 302 to select another ofthe main menu options that are available. Alternatively, the user may return to a previous menu level by selecting an appropriate object, such as a button on a Web page, which acts as a link to a previous menu or option, such as inventory/purchasing menu 304 or main menu 302.

Another option (not shown in FIG. 4B) that may be included in the method for ordering merchandise is collecting release acknowledgement information from the user. For example, a separate screen may be presented after the screen for providing the billing and shipping information. The separate screen allows the user to select a person, cost center, or organization to be notified about the purchase transaction.

According to one embodiment, acknowledgement recipients may be notified by fax or e-mail. The notification information for the acknowledgement, such as who to notify and how to notify them, may reflect default information for the customer or cost center, or the user may change the notification information as part of releasing the inventory. For example, the default notification information may specify that the cost center receive a faxed acknowledgement and that the customer receive an e-mail acknowledgement. The user may change or delete the default notifications or add additional notifications. If a user has the proper authority, the user may change the default notification information, such as by using an option or function to update the cost centers.

Another option (not shown in FIG. 4B) that may be included in the method for ordering merchandise is a screen for collecting billing information to allow for immediate processing ofthe order. For example, after the user submits the order, or elects to have the order released, a billing screen may be shown. The billing screen allows the user to provide billing information, such a name, address, and how to charge the order, such as by allowing the user to specify a cost center or a credit card number.

Yet another option that may appear on any screen is a "preview image" option that allows the user to preview one or more images of a selected product along with additional descriptive material about the product, such as specifications.

FIG. 4C is a flow diagram that illustrates a method of making an inventory inquiry. The method begins with the user selecting the option for inventory inquiry 404 in FIG. 4 A. While a particular order ofthe additional steps ofthe method of making an inventory inquiry are provided in FIG. 4C, a different order may be used, and additional steps may be included or steps presented in FIG. 4C may be omitted. block 430, the user selects the product line from which to make the inventory inquiry. As with placing orders, the available product lines from which the user makes a selection may be based on the role and level of access for the user based on the user's authorization code.

In block 432, the user locates the inventory or merchandise about which the user wishes to inquire from the product line selected in block 430. The user formulates an inquiry using a collection of objects, such as pull down menus, input fields, options, pick lists, etc. The user may formulate inquiries to find many types of information, such as how often the user's company orders an item, how many ofthe item may be used or ordered by the user, the cost centers that use the item the most, the identity of who ordered an item from a sales representative, or when a recent order is due to be shipped.

In response to the user submitting the inquiry, the procurement management system provides information about the selected item from a data warehouse, such as a database. For example, the information may be grouped under various sections, headings, or tabs, such as item information for details and specifications about the item, price information for cost information and cost analysis for the item, ship to information for the location to which the item has been or will be delivered, and header information for details about the customer and the job.

In block 434, if the user wants to view or inquire about additional items, the method returns to block 432 to allow the user to select additional inventory or merchandise. If the user does not want to view additional items, the procurement management system retrieves the appropriate information about the selected items or merchandise from an inventory database and provides the information to the user.

After the user has completed the inventory inquiry, the method continues to block 436 where the user may return to a desired screen or menu option from those already viewed by using the back button feature on the browser application that the user is running on the client or by selecting an appropriate object that corresponds to a previous menu or option, as described above for block 426 in FIG. 4C.

FIG. 4D is a flow diagram that illustrates a method for making an open purchase order inquiry, which may be referred to as an open PO inquiry or an open job inquiry. According to one embodiment, new items are added to a customer's inventory by placing an order through a sales representative. The order may be placed in response to a reorder notice that indicates that the inventory level for an item is low. Once the sales representative has placed the purchase order, the customer or user may check the purchase order via a purchase order inquiry method, such as that shown in FIG. 4D.

The open purchase order inquiry method begins with the user selecting the option for open PO inquiry 406 in FIG. 4A. In response, a screen showing the open PO's for the user's company maybe shown. While a particular order ofthe additional steps ofthe method of making an open purchase order inquiry are provided in FIG. 4D, a different order may be used, and additional steps may be included or steps presented in FIG. 4D may be omitted.

In block 440, the user locates the purchase order, such as by using a list of PO's or by entering the PO number for the particular PO in which the user is interested. After the user has selected the PO, the procurement management system retrieves the information about the PO, such as the data that may be retrieved from a list, table, or database.

In block 442, the user examines the information about the PO, such as in a summary view or a detail view. After the user is done viewing the information about the selected PO, the method continues to block 444. If the user decides to view additional PO's, the method returns to block 440 to allow the user to select an additional PO.

After the user has completed the open PO inquiry, the method continues to block 446 where the user may return to a desired screen or menu option from those already viewed by using the back button feature on the browser application that the user is running on the client or by selecting an appropriate object that corresponds to a previous menu or option, as described above for block 426 in FIG. 4C.

FIG. 4E is a flow diagram that illustrates a method for making a back order inquiry (with item search). The method begins with the user selecting the option for back order (with item search) 408 in FIG. 4A. While a particular order ofthe additional steps ofthe method of making a back order inquiry (with item search) are provided in FIG. 4E, a different order may be used, and additional steps may be included or steps presented in FIG. 4E may be omitted.

In block 450, the user locates the back ordered item using a list of back ordered items. The list may be organized by a number of different types of data about the back orders, such as by the bill of lading number for each order or the cost center for each order. The user may use a search option to locate a one or more back ordered items, such as by entering a product number for the item or other identifying information for the item. After the back ordered item(s) are identified, the user selects a particular item, and the procurement management system retrieves the information about the selected back ordered item, such as the data that may be retrieved from data warehouse, such as a list, table, or database.

In block 452, the user examines information about the back ordered item, such as in a summary view or in a detail view. The information may include item information or ship to information, as discussed above.

After the user is done viewing the information about the selected back ordered item, the method continues to block 454. If the user decides to view additional back ordered items, the method returns to block 450 to allow the user to select an additional back ordered item.

After the user has completed the back order inquiry, the method continues to block 456 where the user may return to a desired screen or menu option from those already viewed by using the back button feature on the browser application that the user is running on the client or by selecting an appropriate object that corresponds to a previous menu or option, as described above for block 426 in FIG. 4C.

FIG. 4F is a flow diagram that illustrates a method for making a back order inquiry (current items only). The method begins with the user selecting the option for back order (current items only) 410 in FIG. 4 A. While a particular order ofthe additional steps ofthe method of making a back order inquiry (current items only) are provided in FIG. 4F, a different order may be used, and additional steps may be included or steps presented in FIG. 4F may be omitted.

In block 462, the user scrolls through the items in a detail view to select the particular back ordered item about which the user is interested from the list of items currently on back order. After the back ordered item is identified, the user selects the item, and the procurement management system retrieves the information about the selected back ordered item, such as the data that may be retrieved from a list, table, or database. The user may examine information about the back ordered item, such as in a summary view or in a detail view, and the information may include item information or ship to information, as discussed above.

After the user is done viewing the information about the selected back ordered item, the method continues to block 464. If the user decides to view additional back ordered items, the method returns to block 462 to allow the user to select an additional back ordered item.

After the user has completed the back order inquiry, the method continues to block 466 where the user may return to a desired screen or menu option from those already viewed by using the back button feature on the browser application that the user is running on the client or by selecting an appropriate object that corresponds to a previous menu or option, as described above for block 426 in FIG. 4C.

FIG. 5 is a flow diagram that illustrates a method for making online inquiries. The online inquiry method allows users to access historical information about items in a customer's inventory. The method begins with the user selecting the option for online inquiries 308 in FIG. 3. While a particular order ofthe additional steps ofthe method of generating an e-mail report are provided in FIG. 5, a different order may be used, and additional steps may be included or steps presented in FIG. 5 may be omitted. In block 502, the user selects the type of inquiry. For example, the user may retrieve historical information using a number of criteria, such as by bill of lading number, by inventory reference number, by item number, by date, and by cost center.

In block 504, the user enters the selection criteria to use in making the inquiry. For example, the user may provide a particular identification number (e.g., a bill of lading number, an inventory reference number, a budget identifier, or an item number) or a range of data (e.g., a range of dates or cost centers). In response to the specification of the inquiry type and selection criteria, the procurement management system retrieves information that conforms to the specifications provided by the user.

In block 506, the user selects how to review the information provided in response to the inquiry. For example, the user may select to view back order information, and the user may select to view the retrieved information in a summary view or in a details view. All items matching the search criteria may be displayed. For each item listed in the search results, addition information may be review, such as header information, item information, and ship to information, as discussed above.

After the user is done viewing the information retrieved in response to the online inquiry, the method continues to block 508. If the user decides to view additional items, such as by making additional inquiries, the method returns to block 504 to allow the user to enter revised selection criteria.

After the user has completed making online inquiries, the method continues to block 516 where the user may return to a desired screen or menu option from those already viewed by using the back button feature on the browser application that the user is running on the client or by selecting an appropriate object that corresponds to a previous menu or option, as described above for block 426 in FIG. 4C.

FIG. 6 is a flow diagram that illustrates a method for generating reports, which may be sent to a user, such as by e-mail or fax. The method begins with the user selecting the option for reports wizard 306 in FIG. 3. While a particular order ofthe additional steps ofthe method of making online inquiries are provided in FIG. 6, a different order may be used, and additional steps may be included or steps presented in FIG. 6 may be omitted.

In block 606, the user selects the type of report to generate. The report types may include, but are not limited to, one or more ofthe following: detail/summary of inventory on hand; summary of inventory activity; inventory receipts; inventory adjustments; detail of inventory releases; use analysis by cost center or ship date; cost center list by cost number; cost center list by state/city; items catalog; inventory back order control by item; inventory release by cost center; open orders; or custom reports set up for each customer.

In block 608, the user provides the parameters, limits, or other selection criteria for use in collecting the desired information for the report. The selection criteria may be provided using data entry fields, pick lists, check boxes, buttons, or other input mechanisms. Each customer may define restrictions, such as limiting the number of days that may be shown in one or more report types.

According to one embodiment, the user provides an e-mail address to which the user wants the report to be sent, as shown in block 610. According to another embodiment, the user provides a fax number to which the user wants the report to be sent. According to yet another embodiment, the user does not provide an e-mail address or fax number, but instead uses the default contact information that is stored for the user in the procurement management system. Reports may be contained in the body of an e-mail or included as an attachment to an e-mail using a variety of formats, such as the rich text format.

In block 612, the procurement management system generates the report according to the specifications provided by the user. For example, the system may use the selection criteria to formulate a query to a database. The system creates a formatted report based on the retrieved information and delivers the report to the e-mail address provided by the user in block 610.

In block 614, if the user wants to generate additional items or reports, the method returns to block 608 to allow the user to enter revised selection criteria.

After the user has completed generating reports, the method continues to block 616 where the user may return to a desired screen or menu option from those already viewed by using the back button feature on the browser application that the user is running on the client or by selecting an appropriate object that corresponds to a previous menu or option, as described above for block 426 in FIG. 4C.

III. MANAGING ORDERS BASED ON BUDGET RESTRICTIONS According to one embodiment, the procurement management system manages orders based on budget restrictions by setting up budget periods and associating the budget periods with budget identifiers and budget restrictions that are applied when processing a request for an order. A. Setting Up Budget Restrictions

According to one embodiment, a budget period is defined and associated with a budget identifier in the procurement management system. For example, a budget period may be defined as a year, quarter, month, week, day, or more generally as any period that has a starting date and an ending date. Budget periods may be based on a calendar year or a fiscal year, such as a particular customer's third fiscal quarter.

A budget identifier may be associated with the budget period so that the budget period is used to track transactions associated with the budget identifier during the budget period. For example, the budget identifier may be a cost center and the budget period may be a calendar quarter so that all orders for the cost center are used for budgeting purposes during the calendar quarter.

As used herein, a budget period is any period of time that is used for budgeting purposes. A budget identifier is an identifying name, number, symbol, code, or a combination thereof, which is used for tracking one or more transaction characteristics. Examples of budget identifiers include, but are not limited to, a cost center, a company number, a customer number, a branch number, and an account number.

A cost center is a code used for organizing information associated with orders and other transactions, such as by type of cost, type of products or product lines, customer or organizational division within customers, or physical location. A cost center may have a specific location type, such as a charge-to cost center that receives bills or purchase orders or reorders, a ship-to cost center that inventory is sent to when the inventory is ordered or released, a bill-to cost center where invoices are mailed, and a reorder location cost center that is used if the purchase order is a reorder and the cost center location is different than in previous orders.

According to other features, the authorization code is used to control the user access to the features ofthe procurement management system and what is displayed to users on each screen. For example, the authorization code may be used to limit the ability to place orders for each cost center to only users whose authorization code has been associated with each cost center. As another example, authority groups may be established, and items and users may be assigned to the authority groups such that only users assigned to an authority group may view items assigned to the authority group when the users review an inventory catalog or another list of items. According to another embodiment, each budget period is associated with a type of budget restriction. For example, the types of budget restrictions may include, but are not limited to, a currency restriction, an item number restriction, an item type restriction, or a combination thereof. As a further example, a currency restriction may be a maximum currency amount, or maximum currency limit, that may not be exceeded by the orders for the budget identifier over the budget period. Similarly, an item number restriction may be a maximum limit on the number of items that may be ordered, and an item type restriction may be a maximum limit on the different types of items that may be ordered.

Although budget restrictions may often be in the foπn of a maximum allowable value, budget restrictions are not limited to maximum limitations. For example, a cost center may be set up to have a minimum number of items budget restriction so that an order must be at least of a specified size to prevent numerous orders for single items that have a small cost.

According to another embodiment, a budget restriction is associated with each budget identifier. For example, if the budget identifier is associated with a budget period that has a currency restriction as the budget restriction type, a budget restriction of X currency units may be associated with the budget identifier such that the orders for the budget identifier for the budget period may not exceed X currency units.

FIG. 7 A is a flow diagram that illustrates a high level overview of a method for setting up budget restrictions in a procurement management system. Not all ofthe steps ofthe method illustrated in FIG. 7 A are required, nor is the order shown required. Additional steps may be added, and the steps shown may be removed or reordered in a particular implementation.

In block 710, data that defines a budget period is received and stored. For example, a user may supply a starting date of February 5 and an ending date of May 26. Information that defines the budget period may be included in a Budget System Customer Master File that is part of a procurement database. The ability ofthe user to define budget periods and other aspects of setting up a budget restriction may be controlled by the user's authorization code. hi block 712, data that specifies the type of budget restriction to use for the budget period is received and stored. For example, the use may specify a currency restriction for the February 5 to May 26 budget period. The information that specifies the budget restriction type may be included in the Budget System Customer Master File. hi block 714, the user is given the option to define another budget period. If the user wants to define another budget period, the method returns to block 710. If the user does not want to define another budget period, the method continues on to block 712. The number of budget periods that can be associated with a customer account may be limited. For example, each customer account may be limited to 13 budget periods for each budget year.

In block 720, the procurement management system receives and stores data that specifies a budget identifier and that identifies which budget period to associate with the budget identifier. For example, the user may enter a cost center code of 1234 to denote "cost center 1234" for the budget identifier and identify the February 5 to May 26 budget period as the budget period to use with cost center 1234. The information associating the budget identifier with the budget period may be included in a Cost Center Master File that contains information about each cost center. The Cost Center Master File may be part of a data warehouse, such as a database that is part of application and data warehouse server(s) 190 of FIG. IB.

In block 722, data that specifies a budget restriction to be associated with the budget identifier is received and stored. For example, if the budget restriction type is a currency restriction, the user may specify a $1,000 maximum currency limit as the currency restriction. As a result, the orders for cost center 1234 over the period of February 5 to May 26 would be limited to $1,000. The information that defines the budget restriction may be included in the Cost Center Master File.

In block 724, the user is given the option of setting up another budget restriction for another budget identifier. If the user wants to set up another budget restriction, the method returns to block 720. If the user does not want to set up another budget restriction, the method continues to block 726, which is the end ofthe budget restriction set up.

FIG. 8 is a block diagram that illustrates budget restriction setup information. The information shown in FIG. 8 is an example and implementations may vary in what budget setup information is recorded and how the budget setup information is organized.

FIG. 8 shows a budget system customer master file 800 that organizes budget setup information using one row for each budget period with each row containing values ofthe budget period parameters as column headings for the rows. Specifically, budget system customer master file 800 includes the following column headings: a budget period number 810, a start date 812, an end date 814, and a restriction type 816. Each budget period is defined by the information in each row, such as rows 820, 822, 824 that are shown in FIG. 8. For example, as shown in FIG. 8, row 820 contains the data for the first budget period that is identified by the budget period number "1" and has a start data of "01/01," an end date of "12/31," and a restriction type of "currency."

B. Applying Budget Restrictions to Order Requests

According to one embodiment, when an order request is received by the procurement management system, the budget basis for the order request is used to compare to the budget restriction to determine if accepting the order will conform to the budget restriction. For example, if the budget restriction is a maximum currency amount of $1,000 and the prior orders for cost center 1234 during the February 5 to May 26 budget period total $950, an order for $100 more of products would not conform to budget restriction of $1,000, but an order for $25 of products would conform to the budget restriction of $1,000.

As used herein, the term "budget basis" is a measurement of a type of characteristic that is associated with orders and order requests. For example, if the budget restriction is a currency restriction, the budget basis for an order may be the cost ofthe order. As additional examples, if the budget restriction is an item quantity or an item type quantity, the budget basis for an order may be the number of items orders or the number of types of items ordered, respectively.

The term "conform" as used herein means that the budget basis is consistent with, or satisfies, the budget restriction. For example, if the budget restriction is a maximum currency amount, the budget basis conforms to the budget restriction when the budget basis does not exceed the maximum currency amount.

According to one embodiment, the budget basis for an order request may be used with an aggregate budget basis to compare to the budget restriction. According to one embodiment, the budget basis for each order for the budget period is retrieved and aggregated to determine the aggregate budget basis. The budget basis for the order is used with the aggregate budget basis to determine a revised aggregate budget basis that is compared to the budget restriction. If the revised aggregate budget basis conforms to the budget restriction, the order is accepted, but if the revised aggregate budget basis does not conform to the budget restriction, the order is denied. Whether or not a particular order request is ultimately accepted or denied may depend on whether approvals, or approval features, are available or required, which is discussed in detail below.

According to another embodiment, an aggregate budget basis is tracked for each budget identifier from the start ofthe budget period. As orders are accepted for the budget identifier during the budget period, the aggregate budget basis is retrieved, updated, and stored, such that the aggregate budget basis reflects the cumulative budget basis for all prior accepted orders. When an order request is received, the current aggregate budget basis for the budget identifier is retrieved and used with the budget basis for the order request to determine a revised aggregate budget basis for comparison to the budget restriction.

FIG. 7B is a flow diagram that illustrates a high level overview of a method for managing order requests based on budget restrictions in a procurement management system. Not all ofthe steps ofthe method illustrated in FIG. 7B are required, nor is the order shown required. Additional steps may be added, and the steps shown may be removed or reordered in a particular implementation.

In block -730, the procurement management system receives an order request that specifies a budget identifier. The order request is associated with a budget basis. For example, the order request may specify a budget identifier of ZYWV987 and the budget basis for the order request may be $1,500. For this example, assume that budget identifier ZYWV987 has already been associated with a budget period of September 15 to December 15 for which the budget restriction type is specified as a currency restriction. Assume further that the budget restriction for the budget identifier is a maximum currency amount of $5,000.

In block 732, an aggregate budget basis for the budget identifier for the budget period is determined. For example, if the order request is made on December 1, and there have been three previous orders after September 15 for budget identifier of ZYWV987 of $1,000, $1,800, and $1,200, the aggregate budget basis is the cumulative budget basis of $4,000.

In block 734, a revised budget basis for the budget identifier is determined based on the budget basis ofthe order request and the aggregate budget basis. For example, for budget identifier ZYWV987, the budget basis for the order is $1,500, the aggregate budget basis is $4,000, and the revised aggregate budget basis is $5,500. In block 736, the revised aggregate budget basis is compared to the budget restriction. In this example, the revised aggregate budget basis of $5,500 is compared to the budget restriction of $5,000.

In block 738, the procurement management system determines whether the revised aggregate budget basis conforms to the budget restriction. If so, then the order request is accepted, but if not, the order request is denied. Note that FIG. 7B includes additional blocks relating to approvals, which are explained below along with the remainder of FIG. 7B.

In this example, the revised aggregate budget basis of $5,500 does not conform to the budget restriction of a maximum of $5,000, so the order is denied. However, if either the budget basis ofthe order request or the aggregate budget basis were reduced by at least $500, then the budget restriction would be satisfied and the order therefore would be accepted.

C. Order Request Approvals

According to another embodiment, an order request is accepted if the order request is approved. For example, the customer account may be configured to require the approval of appropriate management before an order may be accepted. Therefore, even if the order request conforms to the budget restriction, the order will not be accepted without management approval.

According to yet another embodiment, an order request that does not conform to the budget restriction may still be accepted if the order request is approved. For example, the customer account may be configured to allow for management override approval even if a maximum currency amount for the cost center is exceeded.

FIG. 7B shows one example of how an approval feature maybe implemented for otherwise acceptable orders and how an approval override feature may be implemented for otherwise unacceptable orders. Actual implementations of one or both types of approvals may include fewer or more steps than those shown in FIG. 7B or use the steps that are shown in a different order or configuration.

Referring again to block 738, if the revised aggregate budget basis conforms to the budget restriction, the method continues to block 740 where the procurement management system determines whether approval ofthe order request is required. For example, the implementation ofthe procurement management system for the customer maybe configured to require approval of all order requests or just some order requests based on a selection criteria, such as those order requests over a threshold currency amount for a specified cost center. Configuration ofthe approval feature may be included in the Cost Center Master File.

If order request approval is not required in block 740, the method continues to block 760, which indicates that the order request is accepted.

If order request approval is required in block 740, the method continues to block 742, where the procurement management system inquires whether the approval is granted. Approval may be granted by specified users. For example, the Cost Center Master File may list the users that may grant approval. The procurement management system may be configured to automatically send an approval request notification to one of the users that may grant approval and receive a response from the user indicating whether or not the order request is approved.

If approval is granted in block 742, the method continues to block 760, which indicates that the order request is accepted. If approval is not granted in block 742, the method continues to block 762, which indicates that the order request is denied.

Returning to block 738, if the revised aggregate budget basis does not conform to the budget restriction, the method continues to block 750, where the procurement management system determines whether an approval override is available. For example, the customer account may be configured to allow management personnel to approval order requests even though approval ofthe order requests cause the budget restriction for the budget identifier to be exceeded.

If approval override is not available, the method continues to block 762, which indicates that the order request is denied.

If approval override is available, the method continues to block 752, where the procurement management system inquires whether the approval is granted. Approval may be granted by specified users. For example, the Cost Center Master File may list the users that may grant approval. The procurement management system may be configured to automatically send an approval request notification to one ofthe users that may grant approval and receive a response from the user indicating whether or not the order request is approved.

If approval is granted in block 752, the method continues to block 760, which indicates that the order request is accepted. If approval is not granted in block 752, the method continues to block 762, which indicates that the order request is denied. IV. GENERATING AND ELECTRONICALLY SENDING REPORTS TO ELECTRONIC DESTINATIONS

According to one embodiment, the procurement management system generates and electronically sends reports to electronic destinations. For example, a report request may be received from a user or from the procurement management system itself at specified times. In response to the request, the procurement management system searches one or more data warehouses, such as a database that is included in application and data warehouse server(s) 190, to identify the records that match the request, generate the report, and send the report to a one or more electronic destinations, such as a fax number or an e-mail address.

As used herein, a "procurement management database" is a database containing information for use with a procurement management system. As used herein, an "electronic destination" is a destination that is associated with an address, such as a phone number, an e-mail address, or a network identifier to which information can be transmitted electronically over a communications network, such as a local area network, a wide area network, or the Internet.

FIG. 9A is a flow diagram that illustrates a high level overview of a method for producing reports in a procurement management system. However, each implementation may use more or fewer steps or follow a different order of steps than those shown in FIG. 9A.

In block 910, the procurement management system maintains a database that includes inventory records and transaction records. The inventory records describe the items contained in an inventory that is managed by the procurement management system. The transactional records describe the transactions associated with the items contained in the inventory. While the example described herein includes one database with inventory records and transaction records, additional databases and record types may be used and the method described may use any types of records and is not limited to inventory and transaction records. hi block 920, the procurement management system receives a request for a report. The request may come from a user or the procurement management system itself. The request may specify a variety of information, such as a particular report type from among a list of available report types, search criteria that are used to identify matching records from the database, and formatting parameters that control what information is shown on the report and how the information is organized.

In response to the request, the procurement management system generates the report based on the request using records from the database, as shown in block 930. For example, the request may identify the types of records to be retrieved or limit the records to a particular value, such as a customer identifier or a range of identifiers. The procurement management system creates the report based on the matching records, the report type, and the formatting parameters.

In block 940, the procurement management system sends the report to an electronic destination. For example, the request may include an e-mail address to which the report is to be sent, and the procurement management system may create an electronic document in the rich text format and attach the document to an e-mail message that is sent to the e-mail address. As a result, the user receiving the report may review and print the electronic document in any manner desired by the user, such as by using a suitable application program, such as a word processor. Receiving the electronic document at an electronic address allows the user to review the report in a more convenient format, particularly for longer reports, as compared to viewing the longer report online, which may be inconvenient for the longer reports. The particular electronic destination (or destinations) to which the report is sent maybe specified in a number of ways, such as in a configuration record for the type of report, customer, or user, or the destination (or destinations) may be specified in the report request.

A. Report Requests

Requests for reports may be initiated from any part ofthe procurement management system. For example, a user may request a report from a report menu that is part of a main menu for the system or a sub-menu ofthe system. Other menus or system options may include a report feature for generating a report relating to the information for the menu or option. In addition, some reports may be generated automatically by the procurement management system at specified times, such as each day, each week, or the end of each month, or according to some other schedule. Users may specify the scheduling of such reports, or the automatic reports maybe generated by defaults included in the procurement management system for all users or by defaults that are set when the procurement management system is implemented for each customer, reseller, etc. According to one embodiment, a request for a report includes a report type, search criteria, and parameters for formatting the report. For example, the procurement management system may include a variety of report types that may be used, or a customized report may be requested. The search criteria may include, but are not limited to, ranges of data, particular values, or particular types of data or collections of data. The display parameters may include, but are not limited to, the types of data to be included in the report and the organization ofthe data included in the report. Report types, search criteria, and formatting parameters are discussed in detail in the sub-sections below.

B. Generating Reports

According to one embodiment, the procurement management system generates a report by searching a data warehouse, such as a database, to identify records per the report request and generating the report based on the records that match the request, the report type, and the formatting parameters. For example, the system may retrieve from a database the records that conform to the report type and the search criteria specified in the request for the report. As another example, the system may create the report based on the records retrieved from a database and the report type and the parameters for formatting the report that are specified in the request for the report. Report types and search criteria are discussed in detail below.

FIG. 9B is a flow diagram that illustrates a method for generating a report in a procurement management system. However, each implementation may use more or fewer steps or follow a different order of steps than those shown in FIG. 9B.

In block 932, a search is made of a database for records that conform to the report type and the search criteria that are specified in the request for the report. For example, if the report type is a summary of inventory on hand report and the search criteria specify a particular customer and a particular year, the inventory records in the database are searched for records of transactions for the particular customer in the particular year.

In block 934, the overall organization and format for the report is established based on the report type. For example, if the report type is a "summary of inventory on hand" report, the overall organization is a table that lists the items currently on hand in the inventory.

In block 936, the information to be included in the report is selected from the records identified in the search of block 932. The information is selected based on the formatting parameters and the report type. For example, if the report type is a "summary of inventory on hand" report, the information may include the item number, description, and quantity on hand in the inventory. If the formatting parameters specify that price data is to be included, price information for each item is included in the report.

In block 938, the detailed organization ofthe information in the report is established based on the formatting parameters and the report type. For example, if the formatting parameters specify that the items are to be sorted by item number, an item number sort is used to organize the information in the report. If the report type is a "summary of inventory on hand" report, the information for the items may organized into columns with the item number column first, item description second, quantity third, and price fourth.

According to another embodiment, the report that is generated by the method described in FIG. 9B is electronically formatted based on the destination to which the report is to be sent. For example, if the report is to be sent using e-mail, the report is formatted as an electronic document, such as by converting the report contents into a file in the rich text format. The electronic document may be attached to an e-mail message that is sent to a specified e-mail address. As another example, the report may be formatted as simple text that is included in the body of an e-mail.

C. Sending Reports to Specified Electronic Destinations According to one embodiment, a report is electronically sent to one or more electronic destinations. For example, the electronic destination may be a fax number or an e-mail address. Reports maybe sent to multiple destinations ofthe same or different types. For example, two copies may be sent to a fax number and one copy to each of five e-mail addresses.

The destination or destinations that are specified for each report may be included in or modified by the request for the report. Also, destinations may be determined based on the report type. For example, a "summary of inventory on hand" report may be configured to be sent to the specified default destination, such as the e-mail address ofthe inventory manager for the reseller. Further, default destinations may be specified as part ofthe configuration records for a client, such as a reseller, ofthe procurement management system. For example, a "summary of inventory on hand" report may be configured to be sent by default to a specified fax number. D. Report Types

According to one embodiment, a request for a report specifies a report type from among a collection of report types that may depend on the type of user. For example, a user at a customer of a reseller may be able to request reports from a list provided by reports wizard 306 in FIG. 3, and a user at a reseller may be able to request reports from another list provided by a report option on the main menu provided to users at resellers. Examples ofthe reports that maybe provided are discussed in detail below.

According to another embodiment, a report type is implemented by establishing values for search criteria, formatting parameters, or both, which are consistent with the purpose ofthe report type. For example, an item catalog report may include, as search criteria, a range of item numbers that encompasses all item numbers that are associated with the catalog. The item catalog report may include, as formatting parameters, the price of each item included in the catalog and a sort sequence that specifies that the items be sorted in ascending order by item number. For each report type, each ofthe established search criteria and formatting parameters may be either fixed or modifiable by users prior to generating the report.

Examples of reports that maybe accessible to corporate management users ofthe procurement management system include, but are not limited to, a detail of inventory on hand report or a summary of inventory activity report. Such reports are generally predefined reports that are available to all users, or all users of a particular type (e.g., corporate users, corporate managers, resellers, or internal users). In addition, custom reports may be created. A name may be assigned that describes the custom report, and more than one custom report may be created.

The users at a reseller may access a large variety of reports, including but not limited to, inventory list reports, inventory detail reports, billing reports, purchase order reports, chain reports, sales analysis reports, sales analysis inquiry reports, and budget reports. Users at a reseller may access a "customer custom report" option that allows the reseller users to access the "custom reports" for customers, such as the customer reports referred to above in the examples ofthe types of reports accessible to corporate users.

E. Search Criteria

According to one embodiment, a request for a report includes search criteria for use in searching a database for records that conform to the search criteria. Search criteria may specify different types of information, such as ranges of data to be searched or specific values of data to be searched. Also, the search criteria may specify a master account so that a report may be generated based on all ofthe secondary accounts that are associated with the master account, or the search criteria may specify a product group code so that a report may be generated based on all ofthe products that are associate with the product group code. Master accounts and product group codes are discussed in detail below.

The ranges of data to be searched may include, but are not limited to, one or more ofthe following: a branch range, a cost center range, a customer range, a date range, an item range, a job number range, a manufacturer range, an owner range, a period ending date, a product code range, a region range, a sales representative range, a special charge range, and a warehouse range.

The specific values of data to be searched may include, but are not limited to, one or more ofthe following: a branch number, a company number, a cost center type, a customer number, an invoice number, a number of days that invoices are overdue, a product group code, a region number, a sales representative number, a state identifier, a record status type, an invoice status type, and a warehouse type.

F. Formatting Parameters

According to one embodiment, a request for a report includes parameters for formatting the report. The formatting parameters may specify different aspects of what the report contains and options for organizing, such as the types of data from each matching record to include in the report and how to sort the records appearing on the report.

The types of data to include from each record in the report may include, but are not limited to, one or more ofthe following: a display unit price, an item number, a manufacturer number, an inventory type, an inventory bill type, a quantity value, a cost price, a sell price, an extended sell value, and a purchase order number.

The options for organizing data in the report may include, but are not limited to, one or more ofthe following: an items shipped sort sequence, an extended sell dollars sort sequence, an item number sort sequence, a release sort sequence, a reorder location sort sequence, an item description sort sequence, a units shipped sort sequence, a minority vendors only listing, a preferred vendors only listing, a summary view, and a detail view. G. Chain Accounts

According to one embodiment, the search criteria for a report request specifies a master account that is associated with number of secondary accounts. The term "chain account" is used to refer to the account organization of a master account that is associated with secondary accounts. By specifying a master account in a report request, a report maybe generated that includes data from all ofthe secondary accounts that are associated with the master account.

According to another embodiment, a mapping is created and stored between each master account and the secondary accounts that are associated with the master account. For example, a data warehouse such as a list, table, or a database may be used to associate master accounts and secondary accounts. When a report request specifies a master account, the procurement management system identifies the secondary accounts that are associated with the master account based on the mapping.

For example, if a customer has multiple ship-to locations and separate invoices need to be sent to each location, a separate account may be established for each location. A master account maybe established that is associated with each ofthe accounts for each ship-to location to allow for generating a report that includes data for all ofthe ship-to locations. Inventory is received and released under the master account, and the secondary accounts pull inventory from the master accounts. The secondary accounts are the separate ship-to and bill-to locations. While cost centers and charge-to locations may be set up for the master and secondary accounts for the internal accounting purposes ofthe customer, invoices are sent to the main billing address for the master account.

If the procurement management system is configured to support chain accounts, additional screens for specifying a chain account number are used for releasing inventory and making inquiries. In addition, if the configuration supports multiple customers for a chain account, an additional screen may be presented to allow selection ofthe customer for a transaction.

H. Product Group Codes

According to one embodiment, the search criteria for a report request specifies a product group code that is associated with many products or items. By specifying a product group code in a report request, a report may be generated that includes data from all ofthe items that are associated with the product group code. Product group codes may be used to associate any collection of items regardless of whether the items share a common purpose or a common product code.

According to another embodiment, a mapping is created and stored between each product group code and the items or products that are associated with the product group code. For example, a data warehouse such as a list, table, or a database may be used to associate product group codes and items. When a report request specifies a product group code, the procurement management system identifies the items that are associated with the product group code based on the mapping.

Product group codes may be added or created, changed, and deleted by a reseller. The reseller may assign a product group code to a company or a customer, and the reseller may make changes to product group codes that are already assigned to a company or a customer. The reseller may add, change, or delete items that are associated, or assigned, to a product group code.

I. Setting Report Options

According to one embodiment, a user may be authorized to receive reports at a specified electronic destination. For example, each user may have a configuration, or a set of set-up parameters, which may be referred to as a User Master File, and which includes an option for receiving reports at electronic destinations. The User Master File may include separate options corresponding to each type of electronic destination, such as a fax number or an e-mail address. If a user is configured to receive reports at an electronic destination, the identifier for the electronic destination is included in the user master file, such as the particular fax number or e-mail address to use for the user. When the user requests a report, the report will automatically be sent to the user at the specified electronic destination. At the time the user requests a report, the user may change the electronic destination, delete the electronic destination, or add other electronic destinations.

In addition, a Company Master File or a Customer Master File may specify an electronic destination to which reports are sent. For some types of reports, such as an inventory analysis report, the report request screen may include options for sending the report to specified electronic destinations. Whether or not a report is sent to the specified electronic destinations may be controlled by the user's security level as determined based on the user's authorization code. V. USING LEAD-TIMES AND USAGE RATES TO DETERMINE INVENTORY REORDER POINTS AND LEVELS

According to one embodiment, a process for achieving optimal inventory levels using reorder points is provided. In this context, a "reorder point" is a condition at which an entity needs or is required to reorder products from a vendor and place them into inventory. In past approaches, reorder points are set generally solely based upon minimum levels of inventory and maximum levels of inventory. A software system tracks levels of products that are in inventory. When a particular level or quantity of a product reaches a pre-defined minimum level, the software generates a message indicating that it is time to reorder the product. The reorder message specifies the amount of product needed to change the current inventory level to a pre-defined maximum inventory level.

In contrast, accordingly to an embodiment, broadly, a system generates information and reports specifying real-time inventory levels and actual usage rates. A user specifies reorder points based on actual usage levels. Periodically, a software agent analyzes use of specific items, considers use trends and lead-times involved in obtaining replacement items. Based on such analysis, the generated information and the pre-defined reorder points, one or more reorder notices are generated and presented to a user with sufficient time to enable the user to create and enter a new purchase order for the needed items.

According to one feature, a batching approach is used, in which multiple reorders are combined in order to achieve volume discounts. According to another feature, reorder point processing is used to remind a user to order seasonal items such as holiday cards or holiday sale flyers.

Maintaining appropriate inventory levels of products in this way reduces inventory back orders, rush orders and corresponding rush charges and obsolescence.

In one specific embodiment, reorder notification is supported by an inventory analysis master file that is maintained, in part by an inventory analysis master setup function. The inventory analysis master file stores basic information about what products are in inventory and how they are used. The inventory analysis master setup function is used to add or change information in the inventory analysis master files, or to make records inactive. It can be used to view use-trend and comparative-use history information, determine which cost centers are using specific inventory, whether current use is higher or lower than average, how much inventory has been used in the current year compared to the past year, whether stock is running low, etc.

In the following description, the term "user" refers to an administrative user associated with a distributor of products or items such as printed matter. The distributor distributes the products to its customers. The distributor also configures certain field values on behalf of its customers that affect how the customer is notified of various information.

The processes described in this section may be implemented in one or more software elements that are executed by a client computer that is associated with a user. The client-side software elements communicate over a network to an application server that carries out storage, computation, analysis, and reporting functions. In one embodiment, applets executed in a browser of a user's client computer carry out the processes. However, this implementation is not required, and any other computer-based implementation in which a system ofthe user cooperates with a server may be provided.

FIG. 10A is a flow diagram that illustrates a top-level view of a process of generating reorder notification messages. For purposes of illustrating a specific example, FIG. 10A is described herein with reference to the graphical user interface shown in FIG. 11 A, FIG. 1 IB; however, the process of FIG. 10A is not limited to that specific graphical user interface.

In block 1002, data defining master inventory analysis functions and schedules is received for a customer. In general, block 1002 involves creating and storing data that defines what kind of inventory analysis to execute periodically for a customer, and when the analyses are executed.

In one specific embodiment, block 1002 is implemented by using one or more software elements, such as browser applets, to create and store data values using a graphical user interface as shown in FIG. 11 A. In this embodiment, a user associated with a distributor has a computer system or terminal ("client-side computer") that connects over a network to an application server. The application server may cooperate with a Web server to deliver one or more electronic documents, such as HTML pages, to the client- side computer. The electronic documents received at the client-side computer may include one or more client-side software applications or applets that act as a software interface for the distributor to the application server. The processes described in this section are accessed by selecting a Setup Files Menu from a top-level menu ofthe client-side distributor application. The client-side distributor application may have many other menus and options for carrying out other functions; file setup for the purpose of inventory analysis is one example function. In response, the client-side applet displays an inventory analysis master form 1100 that includes a Header/Report Setup tab 1102. Data defining master inventory analysis functions and schedules may be created and stored by entering values in the inventory analysis master form 1100.

Initially, an Inventory Analysis screen is displayed that includes a prompt to enter a customer number and select an Add, Change, or Delete function. The user enters a valid customer number or selects one from a list in a pop-up menu, and selects Add, Change or Delete. If Add is selected, then the user is requesting the system to add a new inventory analysis master file record for the specified customer, and form 1100 is then displayed.

Values entered using form 1100 and tab 1102 provide master values for a customer. Thus, the values entered using form 1100 and tab 1102 apply to all inventory analyses that are carried out for a particular customer, unless the values are overridden by item-specific entries. A process of overriding values using item-specific entries is described herein with respect to FIG. 1 IB.

Data values are entered in the fields of tab 1102 to establish which analyses are run and when they will run. Tab 1102 automatically displays the specified customer number in a company / customer display line 1104. Record update code field 1106 is used to indicate whether the current analysis record, represented form 1100, is active, inactive, or deleted. The default value is Active, and normally is left unchanged by the user.

Analysis type field 1108 indicates the calendar pattern of an analysis, and may be set to Monthly, Weekly, or Biweekly on either odd or even weeks. For example, if analysis type field 1108 is set to Weekly, then the analysis represented by all other data in form 1100 is executed weekly.

Reports availability field 1110 is used to indicate which inventory analysis reports the system should carry out. In one embodiment, check boxes are provided for an Analysis Report, Reorder Notices, and Low Stock notification. A user may check the box corresponding to each report or notification that the user wishes to generate periodically. Optionally, a number of copies ofthe reports maybe entered. A "When to Run Reports" field 1112 receives data indicating when the reports and notifications identified in reports availability field 1110 should be generated. Data entered in GUI widgets associated with field 1112 establishes whether reports or notifications run on a certain day ofthe week (as indicated by day abbreviation values, e.g., *MON, *TUE, *WED, *THU, FRI), at the start ofthe month (*MST), or at the end ofthe month (*MEN). Alternatively, reports and notifications may be scheduled to run on a specific day of a month by entering a numeric value in a "Day of Month Run" field 1113.

The values associated with analysis type field 1108 and "When to Run Reports" field 1112, taken together, indicate specifically when inventory analyses occur. For example, when the analysis type is Monthly and the Day of Month Run value is 14, the reports and notifications represented by form 1100 are executed monthly on the 14^th day ofthe month.

Selecting the Submit button 1120 sends the data entered in form 1100 to the application server for storage in associated data storage. In an embodiment, the applet that generates form 1100 creates and sends an HTTP SUBMIT request to the application server with formatted field values.

If at least one box associated with reports availability field 1110 is checked, then the user also may specify one or more modes of delivery for each selected report or notification, using Fax/Email Options button 1114. Further, if at least one such box is checked, and the user selects Submit button 1120 and has not previously specified fax/email options using button 1114, then the system requires the user to enter fax/email options before proceeding to schedule the inventory analysis.

Selecting Fax/Email Options button 1114 causes the system to display a window that includes check boxes that prompt the user to indicate whether a fax message or email message, or both, should be provided for an analysis report and for reorder notifications. The fax and email addresses recorded in the company or customer master file are used for such messages.

Referring again to FIG. 10 A, in block 1004, data defining master inventory analysis behavioral parameters for a customer is received. In general, block 1004 involves receiving data that defines what methods are used to compute inventory analyses. In one specific embodiment, the data identified in block 1004 is received from a user who interacts with Report Options Setup tab 1150 of form 1100, as shown in FIG. 1 IB. A reorder calculation field 1122 receives a numeric value that represents a type of reorder processing method. In one embodiment, available methods include Fixed Level Par, Usage Lead-time, Cyclical by Date, and Cyclical by Elapse.

The Fixed Level Par type of reorder calculation prints a reorder notice when the inventory level on a specific inventory item (such as a printed form that is associated with a form number) goes below the specified par level amount. For example, if the par level is 1,000 items and the quantity on hand is 950 items, a reorder notice will print the next time that the Inventory Analysis runs, according to the schedule.

The Cyclical By Date type of reorder calculation prints a reorder notice on the specific date entered into the Inventory Analysis Forms setup form 1100. For example, if the date of March 31 is entered for the Cyclic date, the reorder notice will print on the scheduled Inventory Analysis closest to that date.

The Usage Lead-time type of reorder calculation type of reorder calculation prints a reorder notice when the inventory level is below the reorder level quantity. The reorder level is calculated by the average weekly/monthly usage times and the lead-time. For example, if the average monthly usage is 250 items and the lead-time is 2 months, the reorder level is 500 items. Once the quantity on hand is below 500 items, a reorder notice is generated the next time that the Inventory Analysis is scheduled to run.

The Cyclical by Elapse type of reorder calculation prints a reorder notice after the specified number of months or weeks has elapsed. For example, if "2" is entered in the box and the account is set at monthly, the reorder notice will print in 2 months.

Reorder supply field 1124 receives a numeric value indicating the number of weeks or months worth of supply to restock in the distribution center when reordering a job. By default, the value is 6 months for monthly processing and 26 weeks for weekly and biweekly processing.

Lead-time value field 1126 receives a numeric value representing the amount of time it takes for a reorder notice to be approved by the customer, produced by the manufacturer, and received into inventory. Some items may require more production time than others. The default value for monthly processing is 2 months and for weekly or biweekly processing is 13 weeks.

Reorder Notice Max field 1128 receives a numeric value that indicates the maximum number of reorder notices that are generated when a specified reorder point is achieved. For example, when the value of Reorder Notice Max field 1128 is "5," then the system will generate a maximum of five periodic reorder notices for the associated reorder point. After the last notice has been generated, the system will flag the item on the inventory analysis as having generated the final notice. In one embodiment, values from "1" to "99" are allowed, and the default value is "5."

Computer Takeover field 1130 and Computer Take field 1132 are used to control how soon computer-controlled software processes are used to determine item usage after initial setup ofthe system for a customer. Upon initial setup ofthe system, an initial item usage value is used, if such a value has been entered, as the usage value for the item. Computer Take field 1132 indicates a number of months or weeks during which the initial item usage value is valid. By default, when Computer Takeover field 1130 has a value of "1", the system will examine the value of Computer Take field 1132 and compare it to the history date to determine a date to take over calculations of item usage. When that date arrives, the initial usage value is no longer used as the usage value, and the system uses the actual usage history ofthe item.

History Calc field 1134 receives a numeric value that indicates the number of weeks or months that the system analyzes when using actual history to calculate the average usage of an item.

Omit Load P/O field 1136 is a toggle field that signals the system to omit Load Purchase Order inventory from inventory analysis reports and notifications. "Load" is existing inventory that a customer had prior to installation or deployment of a system providing the processes described herein.

Quantity or Forms field 1138 receives a value that indicates whether the system should use a quantity of containers or a quantity of printed forms as the basis for calculating usage or displaying information based on quantity. Specifically, when the value of field 1138 is "Q" for Quantity, and when calculating usage or displaying information by apply a quantity value, the system uses the actual number of cartons, packages, pads, boxes, etc. In contrast, when the value of field 1138 is "F" for Forms, the number of items in each unit of measure is used.

Exclude Cost Center field 1140 receives a value identifying a department or other cost center within a particular customer that is excluded when inventory analysis reports or reorder notifications are generated.

Include Straight field 1142 receives a toggle value (e.g., yes ["Y"] or no ["no"]) that enables a user to include calculations on straight-ship items during item usage analyses. If a straight-ship order has been placed for an inventory item, it is included in the use ofthe item on inventory analyses. In this contact, "straight-ship" items are items that are shipped directly from a vendor to a customer, bypassing the distributor.

Low Stock Projection Percent field 1144 allows a user to set the percentage that identifies inventory as "low stock." Low stock inventory is specially identified on certain reports.

Upon entering valid values in the foregoing fields, a user is able to create and store all master values needed for the system to carry out inventory analysis functions for a customer. The foregoing fields may be entered for one or more customers known to the system, thereby configuring the system to carry out inventory analyses and to automatically generate reorder notifications for such customers.

Values in any ofthe fields of FIG. 11 A, FIG. 1 IB may be changed by returning to the Inventory Analysis screen, entering the customer number for which data has changed, and selecting the Change button. An inventory analysis may be deleted by returning to the Inventory Analysis screen, entering a customer number, and selecting the Delete button. The screen displays of FIG. 11 A, 1 IB are displayed so that the user is aware of what will be deleted. The user changes Record Update Code field 1106 to Inactive or Deleted, as determined by the user. Selecting button 1120 causes the record to be persistently marked as Inactive or Deleted in the database.

Inventory Analyses that are created in the foregoing manner are scheduled for execution using a scheduler. In one embodiment, the scheduler is accessed by selecting Schedule Inventory Analysis button 1116 from form 1100. In response, the client-side software element displays a "Work With Job Schedule Entries" screen that lists all scheduled inventory analyses. By selecting appropriate user interface buttons, the user can change job parameters such as frequency, schedule date or day, and schedule time; place a selected job on hold; release a held job; remove a scheduled job; and control the list display. In this context, "job" refers to a scheduled instance of an inventory analysis report or notification.

Referring again to FIG. 10A, in block 1006 data is received that defines inventory analysis functions and schedules for specific items of a customer. The data entered in block 1006 serves to override conflicting values that are entered in block 1002. Similarly, in block 1008, data is received to define inventory analysis behavioral parameters for. specific items of a customer. Such data overrides conflicting master values that are entered in block 1004.

In one specific embodiment, a user provides such data by first selecting an Inventory Analysis Item Setup option from the Setup Files Menu ofthe user's client-side software application. In response, a Customer Search display is provided to enable the user to select a customer. The user enters a customer number or selects the customer from a pick list, and submits it to the system. In response, the client-side software application displays an Inventory Analysis Item Detail pick list, which consists of a list of items that are associated with the selected customer. The user selects an item from the pick list and selects a Change Record button, Delete Record button, or Show Detail button.

When the Change Record button is selected, in response, the client-side software application displays screen display 1200 of FIG. 12A. FIG. 12A is a diagram of a screen display that receives report option default values for inventory analysis item detail records. In screen display 1200, a summary line 1202 displays the current company, customer number, and item number. The user may select whether the current inventory analysis record for the current item is active or inactive using Record Code field 1206. Re-order location cost center field 1208 receives a value identifying a cost center associated with a purchase order that will be issued for a reorder associated with the record. The value in this field enables a reorder notification or inventory analysis report to identify which cost center is responsible for generating a purchase order representing a reorder.

When the foregoing values are entered, selecting Report Calculations tab 1210 causes the client-side software element to display screen display 1220 of FIG. 12B. FIG. 12B is a diagram of a screen display that receives report calculation values for inventory analysis item detail records. In screen display 1220, fields that have names identical to those in FIG. 1 IB are used to receive values that are identical to those described above with respect to FIG. 1 IB, except that the field values received in screen display 1220 apply only to the specific inventory item that was selected using the display of FIG. 12 A.

For example, reorder calculation field 1222 of FIG. 12B receives values generally identical to those of reorder calculation field 1122 of FIG. 1 IB. Although field 1222 uses a plurality of radio buttons as shown in FIG. 12B, alternatively, a numeric value is entered. Similarly, usage lead-time field 1224 of FIG. 12B has individual fields corresponding to reorder supply field 1124 and lead-time field 1126 of FIG. 1 IB. In addition, lead-time field 1224 of FIG. 12B includes an Initial Usage sub-field that receives usage information for a new inventory item. The usage information entered in the field is used to calculate reorder levels until the system has actual usage data available based on tracking releases of inventory that are controlled by the system.

Fixed Par Level field 1226 comprises a Reorder Fix Supply sub-field and a Par Level sub-field. The Reorder Fix Supply field receives a value indicating the number of inventory item units that are specified as a reorder quantity. Thus, when a reorder issues, it is made for the number of units indicated in the Reorder Fix Supply field. The Par Level field receives a value indicating the level of inventory that triggers the system to generate a reorder notification. Once inventory is below the par level, the reorder notice is generated.

Reference numeral 1228 identifies a Cyclic Date field and a Cyclic Elapse field. The Cyclic Date field receives a date value indicating a date on which a reorder notification is generated. In general, the Cyclic Date field is used to specify an annual reorder point for a seasonal item. Once a reorder notification is printed for a year, the system automatically updates the value ofthe Cyclic Date field to reflect the next calendar year. The Cyclic Elapse field receives a numeric value indicating the number of weeks or months to elapse before another reorder is generated.

Computer Take Value field 1230 corresponds to Computer Take Value field 1132 of FIG. 1 IB, on a per-item basis. Reorder Notice Max value 1232 corresponds to Reorder Notice Max field 1128 of FIG. 1 IB, but holds a value for the current item. History Calc field 1234 corresponds to History Calc field 1134 of FIG. 1 IB, for the current item. Similarly, Computer Takeover field 1236 corresponds to Computer Takeover field 1130, and Quantity or Items field 1238 corresponds to Quantity or Forms field 1138.

A Base Line Quantity field 1240 receives a numeric value indicating the original order quantity used by the customer with a previous vendor. In this context, a previous vendor is one with whom the customer contracted before adopting use ofthe processes and systems described herein. Base Line Date field 1242 receives a date value identifying a date on which the value of Base Line Quantity field 1240 was entered.

Base Line Sell Price field 1244 receives a numeric value indicating the sell price used by the distributor with their previous vendor. The Suggested Sell Price field 1246 optionally receives a numeric value indicating an estimated new sell price for the item. When one or more ofthe foregoing field values have been entered, the user may select the Submit button 1120 to cause the client-side application to submit the data values to the server. The user may repeat the foregoing process for any number of inventory items in the inventory analysis item detail pick list.

In another specific embodiment, software elements ofthe system have functions that allow the user to specify a reorder location value. The reorder location value is used on inventory analysis reports and billing invoices to track which locations within a customer or other end user entity are placing reorders. The reorder location can be a street address, such as a shipping address or charge-to address, or it can be a separate cost center.

Based on the foregoing data values, according to an embodiment, reorder notification messages are periodically generated based on a fixed par level, or usage lead- time values, or cyclical by date, or cyclical by elapsed time. FIG. 1 OB is a flow diagram that illustrates a process of generating reorder notification messages. In block 1020, a scheduled inventory analysis is executed. According to a specific embodiment, block 1020 involves executing an inventory analysis when the current time, as indicated by a system clock or similar facility, is approximately equal to a scheduled time ofthe inventory analysis or scheduled "job." In block 1022, inventory item data is evaluated based on the functions and behavioral parameters that have been specified in connection with the process steps of FIG. 10A. Specific sub-steps involved in carrying out block 1022, in one example embodiment, are described further herein in connection with FIG. 13. In block 1024, if a reorder point has been reached, then a reorder notification message with a suggested reorder level is generated and delivered to a user. Notification messages may comprise printed reports, email messages, fax messages, or messages delivered by any other suitable communication mechanism.

T7T/-1 1 -1 1 - _ J?f IL _ .£^• _ _ J? J _i :— ^•. 1_ _i1 A_ _ - _-. - _ number of weeks or months that have elapsed, and the number of product units that have been released, an average usage value is determined.

In one specific embodiment, when the value entered in analysis type field 1108 of FIG. 11 A is "monthly," then the average usage value is determined over a period of months, whereas when the value is "weekly," then the average usage value is computed for a period of weeks. The number of months or weeks that constitute the averaging period is the value that has been entered in History Calc field 1134 of FIG. 12B, or a default value, e.g., 26 weeks, 6 months, etc.

In block 1304, a lead-time value for the inventory item is retrieved. For example, the value that was entered by the user and stored in the database for lead-time field 1224 of FIG. 12A is retrieved. If the value is null, then the value for lead-time field 1126 of FIG. 11 A is retrieved and used as a default value.

In block 1306, a reorder level value is computed by determining the mathematical product ofthe average usage level value multiplied by the lead-time value.

In block 1308, a test is made of whether the current quantity on hand ofthe inventory item is less than the reorder level value. If so, then in block 1310 a reorder notification is generated. If not, then processing continues, e.g., with other scheduled inventory analyses, or other calculations for the current item.

The reorder notification may specify the quantity of inventory items to be ordered.

In one approach, the quantity to order is expressed in terms of weeks or months of inventory, as indicated by the value in reorder supply field 1124 of FIG. 1 IB or the value in the Reorder Supply sub-field ofthe Usage Lead-time field 1224 of FIG. 12B. In another approach, the quantity to order is equal to the reorder level. In an alternative approach, the quantity to order is equal to the difference between the reorder level and the current quantity on hand. In still other alternatives, the quantity to order is a multiple of the reorder level, or a multiple ofthe average periodic usage value.

Alternatively, at block 1020, other processes may be used for determining whether to issue a reorder notification. For example, in a Fixed Level Par approach, a reorder notice is generated only when the inventory current level for a specific inventory item is less than a specified par level value that is stored in the database. For example, if the par level value entered in field 1226 of FIG. 12B is 1,000 items, and the current quantity on hand is 950 items, a reorder notice is generated. In a Cyclical By Date approach, a reorder notice is generated when an inventory analysis is executed on the specific date entered into the Inventory Analysis Forms setup form 1100. For example, if the date of March 31 is entered for the Cyclic date, the reorder notice will print on the scheduled Inventory Analysis closest to that date. In a Cyclical by Elapse approach, a reorder notice is generated after the specified number of months or weeks has elapsed. For example, if "2" is entered in field 1228 as the Cyclical by Elapse value, and the account is set at monthly, the reorder notice is generated in 2 months.

VI. HARDWARE OVERVIEW

FIG. 14 is a block diagram that illustrates a computer system 1400 upon which an embodiment ofthe invention may be implemented. Computer system 1400 includes a bus 1402 or other communication mechanism for communicating information, and a processor 1404 coupled with bus 1402 for processing information. Computer system 1400 also includes a main memory 1406, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 1402 for storing information and instructions to be executed by processor 1404. Main memory 1406 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 1404. Computer system 1400 further includes a read only memory (ROM) 1408 or other static storage device coupled to bus 1402 for storing static information and instructions for processor 1404. A storage device 1410, such as a magnetic disk or optical disk, is provided and coupled to bus 1402 for storing information and instructions.

Computer system 1400 maybe coupled via bus 1402 to a display 1412, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device 1414, including alphanumeric and other keys, is coupled to bus 1402 for communicating information and command selections to processor 1404. Another type of user input device is cursor control 1416, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 1404 and for controlling cursor movement on display 1412. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.

The invention is related to the use of computer system 1400 for implementing the techniques described herein. According to one embodiment ofthe invention, those techniques are performed by computer system 1400 in response to processor 1404 executing one or more sequences of one or more instructions contained in main memory 1406. Such instructions may be read into main memory 1406 from another computer- readable medium, such as storage device 1410. Execution ofthe sequences of instructions contained in main memory 1406 causes processor 1404 to perform the process steps described herein, hi alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments ofthe invention are not limited to any specific combination of hardware circuitry and software.

The term "computer-readable medium" as used herein refers to any medium that participates in providing instructions to processor 1404 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non- volatile media includes, for example, optical or magnetic disks, such as storage device 1410. Volatile media includes dynamic memory, such as main memory 1406. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 1402. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications .

Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punchcards, papertape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.

Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to processor 1404 for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 1400 can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on bus 1402. Bus 1402 carries the data to main memory 1406, from which processor 1404 retrieves and executes the instructions. The instructions received by main memory 1406 may optionally be stored on storage device 1410 either before or after execution by processor 1404. Computer system 1400 also includes a communication interface 1418 coupled to bus 1402. Communication interface 1418 provides a two-way data communication coupling to a network link 1420 that is connected to a local network 1422. For example, communication interface 1418 maybe an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 1418 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface 1418 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

Network link 1420 typically provides data communication through one or more networks to other data devices. For example, network link 1420 may provide a connection through local network 1422 to a host computer 1424 or to data equipment operated by an Internet Service Provider (ISP) 1426. ISP 1426 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the "Internet" 1428. Local network 1422 and Internet 1428 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 1420 and through communication interface 1418, which carry the digital data to and from computer system 1400, are exemplary forms of carrier waves transporting the information.

Computer system 1400 can send messages and receive data, including program code, through the network(s), network link 1420 and communication interface 1418. In the Internet example, a server 1430 might transmit a requested code for an application program through Internet 1428, ISP 1426, local network 1422 and communication interface 1418.

The received code may be executed by processor 1404 as it is received, and/or stored in storage device 1410, or other non- volatile storage for later execution. In this manner, computer system 1400 may obtain application code in the form of a carrier wave.

In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope ofthe invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Claims

CLAIMSWhat is claimed is:

1. A method for managing orders based on budget restrictions in a procurement management system, the method comprising the computer-implemented steps of: receiving and storing first data that defines a budget period; receiving and storing second data that specifies a budget identifier and that specifies that the budget identifier is to be associated with the budget period; creating and storing an association between the budget identifier and the budget period; receiving and storing third data that specifies a budget restriction that is associated with the budget identifier; receiving an order request that is associated with the budget identifier, wherein a particular budget basis is associated with the order request; determining an aggregate budget basis for any orders accepted during the budget period for the budget identifier, wherein each ofthe orders is associated with a budget basis and wherein the aggregate budget basis is based on a cumulative budget basis for all orders accepted during the budget period for the budget identifier; detemiining a revised aggregate budget basis based on the particular budget basis and the aggregate budget basis; comparing the revised aggregate budget basis to the budget restriction; when the revised aggregate budget basis does not conform to the budget restriction, denying the order request; and when the revised aggregate budget basis does conform to the budget restriction, accepting the order request.

2. The method of Claim 1 , wherein the budget identifier is selected from the group consisting of a cost center, a company number, a customer number, a branch number, and an account number.

3. The method of Claim 1 , further comprising the computer-implemented steps of: identifying an authorization code associated with a user that sends the order request; determining whether the user is authorized to place the order request based on the authorization code and the budget identifier; when the user is not authorized to place the order request, denying the order request.

4. The method of Claim 1, wherein the step of determining the aggregate budget basis is comprised ofthe computer-implemented steps of: retrieving from a data warehouse the budget basis for each order accepted during the budget period for the budget identifier; and generating the aggregate budget basis based on the budget basis for each order accepted during the budget period for the budget identifier.

5. The method of Claim 1 , wherein the step of determining the aggregate budget basis is comprised ofthe computer-implemented steps of: for each particular order accepted from among the orders accepted during the budget period for the budget identifier, retrieving the aggregate budget basis that reflects any orders accepted prior to acceptance ofthe particular order; updating the aggregate budget basis to account for the budget basis ofthe particular order; storing the updated aggregate budget basis; and repeating the steps of retrieving, updating, and storing for each order received during the budget period for the budget identifier.

6. The method of Claim 1, further comprising the computer-implemented step of: receiving and storing fourth data that specifies a budget restriction type from among a plurality of budget restriction types, wherein the budget restriction type is associated with the budget period, and wherein the budget restriction, the budget basis, the particular budget basis, the aggregate budget basis, and the revised aggregate budget basis conform to the budget restriction type.

7. The method of Claim 6, wherein the plurality of budget restriction types is comprised of a currency amount, an item quantity, and an item type quantity.

8. The method of Claim 1 , wherein the budget basis is a currency amount, the particular budget basis is a particular currency amount, the aggregate budget basis is an aggregate currency amount, and the revised aggregate budget basis is an revised currency amount, the budget restriction is a currency restriction, and the aggregate currency amount conforms to the currency restriction when the aggregate currency amount satisfies a predetennined relationship with the currency restriction.

9. The method of Claim 8, wherein the aggregate currency amount satisfies the predetermined relationship with the currency restriction when the aggregate currency amount does not exceed the currency restriction.

10. The method of Claim 1 , wherein the budget basis is a quantity of items, the particular budget basis is a particular quantity of items, the aggregate budget basis is an aggregate quantity of items, and the revised aggregate budget basis is an revised quantity of items, the budget restriction is a quantity of items restriction, and the aggregate quantity of items conforms to the quantity of items restriction when the aggregate quantity of items satisfies a predetermined relationship with the quantity of items restriction.

11. The method of Claim 10, wherein the aggregate quantity of items satisfies the predetermined relationship with the quantity of items restriction when the aggregate quantity of items does not exceed the quantity of items restriction.

12. The method of Claim 1, wherein the budget basis is a quantity of item types, the particular budget basis is a particular quantity of item types, the aggregate budget basis is an aggregate quantity of item types, and the revised aggregate budget basis is an revised aggregate quantity of item types, the budget restriction is a quantity of item types restriction, and the aggregate quantity of item types conforms to the quantity of item types restriction when the aggregate quantity of item types satisfies a predetermined relationship with the quantity of item types restriction.

13. The method of Claim 12, wherein the aggregate quantity of item types satisfies the predetermined relationship with the quantity of item types restriction when the aggregate quantity of item types does not exceed the quantity of item types restriction.

14. The method of Claim 1 , wherein the step of accepting the order request is comprised ofthe computer-implemented steps of: when the revised aggregate budget basis does conform to the budget restriction, sending an order request notification to a recipient; receiving a reply from the recipient in response to the order request notification, wherein the reply specifies whether the order request is approved or not approved; when the order request is not approved, denying the order request; and when the order request is approved, accepting the order request.

15. The method of Claim 1 , wherein the step of denying the order request is comprised ofthe computer-implemented steps of: when the revised aggregate budget basis does not conform to the budget restriction, sending an order request notification to a recipient; receiving a reply from the recipient in response to the order request notification, wherein the reply specifies whether the order request is approved or not approved; when the order request is not approved, denying the order request; and when the order request is approved, accepting the order request.

16. An apparatus for managing orders based on budget restrictions in a procurement management system, comprising: a processor; a network interface coupled to the processor and to a network for communicating procurement management information among the processor and the network; and a computer-readable medium accessible by the processor and carrying one or more sequences of instructions which, when executed by the processor, cause the processor to carry out the steps of: receiving and storing first data that defines a budget period; receiving and storing second data that specifies a budget identifier and that specifies that the budget identifier is to be associated with the budget period; creating and storing an association between the budget identifier and the budget period; receiving and storing third data that specifies a budget restriction that is associated with the budget identifier; receiving an order request that is associated with the budget identifier, wherein a particular budget basis is associated with the order request; determining an aggregate budget basis for any orders accepted during the budget period for the budget identifier, wherein each ofthe orders is associated with a budget basis and wherein the aggregate budget basis is based on a cumulative budget basis for all orders accepted during the budget period for the budget identifier; determining a revised aggregate budget basis based on the particular budget basis and the aggregate budget basis; comparing the revised aggregate budget basis to the budget restriction; when the revised aggregate budget basis does not conform to the budget restriction, denying the order request; and when the revised aggregate budget basis does conform to the budget restriction, accepting the order request.

17. A computer-readable medium carrying one or more sequences of instructions for managing orders based on budget restrictions in a procurement management system, which instructions, when executed by one or more processors, cause the one or more processors to carry out the steps of: receiving and storing first data that defines a budget period; receiving and storing second data that specifies a budget identifier and that specifies that the budget identifier is to be associated with the budget period; creating and storing an association between the budget identifier and the budget period; receiving and storing third data that specifies a budget restriction that is associated with the budget identifier; receiving an order request that is associated with the budget identifier, wherein a particular budget basis is associated with the order request; determining an aggregate budget basis for any orders accepted during the budget period for the budget identifier, wherein each ofthe orders is associated with a budget basis and wherein the aggregate budget basis is based on a cumulative budget basis for all orders accepted during the budget period for the budget identifier; determining a revised aggregate budget basis based on the particular budget basis and the aggregate budget basis; comparing the revised aggregate budget basis to the budget restriction; when the revised aggregate budget basis does not conform to the budget restriction, denying the order request; and when the revised aggregate budget basis does conform to the budget restriction, accepting the order request.

18. The computer-readable medium of Claim 17, wherein the budget identifier is selected from the group consisting of a cost center, a company number, a customer number, a branch number, and an account number.

19. The computer-readable medium of Claim 17, further comprising sequences of instructions which, when executed by the one or more processors, cause the one or more processors to carry out the steps of: identifying an authorization code associated with a user that sends the order request; determining whether the user is authorized to place the order request based on the authorization code and the budget identifier; when the user is not authorized to place the order request, denying the order request.

20. The computer-readable medium of Claim 17, wherein the step of determining the aggregate budget basis is comprised of sequences of instructions which, when executed by the one or more processors, cause the one or more processors to carry out the steps of: retrieving from a data warehouse the budget basis for each order accepted during the budget period for the budget identifier; and generating the aggregate budget basis based on the budget basis for each order accepted during the budget period for the budget identifier.

21. The computer-readable medium of Claim 17, wherein the step of determining the aggregate budget basis is comprised of sequences of instructions which, when executed by the one or more processors, cause the one or more processors to carry out the steps of: for each particular order accepted from among the orders accepted during the budget period for the budget identifier, retrieving the aggregate budget basis that reflects any orders accepted prior to acceptance ofthe particular order; updating the aggregate budget basis to account for the budget basis ofthe particular order; storing the updated aggregate budget basis; and repeating the steps of retrieving, updating, and storing for each order received during the budget period for the budget identifier.

22. The computer-readable medium of Claim 17, further comprising sequences of instructions which, when executed by the one or more processors, cause the one or more processors to carry out the steps of: receiving and storing fourth data that specifies a budget restriction type from among a plurality of budget restriction types, wherein the budget restriction type is associated with the budget period, and wherein the budget restriction, the budget basis, the particular budget basis, the aggregate budget basis, and the revised budget basis conform to the budget restriction type.

23. The computer-readable medium of Claim 22, wherein the plurality of budget restriction types is comprised of a currency amount, an item quantity, and an item type quantity.

24. The computer-readable medium of Claim 17, wherein the budget basis is a currency amount, the particular budget basis is a particular currency amount, the aggregate budget basis is an aggregate currency amount, and the revised aggregate budget basis is an revised currency amount, the budget restriction is a currency restriction, and the aggregate currency amount conforms to the currency restriction when the aggregate currency amount satisfies a predetermined relationship with the currency restriction.

25. The computer-readable medium of Claim 24, wherein the aggregate currency amount satisfies the predetermined relationship with the currency restriction when the aggregate currency amount does not exceed the currency restriction.

26. The computer-readable medium of Claim 17, wherein the budget basis is a quantity of items, the particular budget basis is a particular quantity of items, the aggregate budget basis is an aggregate quantity of items, and the revised aggregate budget basis is an revised quantity of items, the budget restriction is a quantity of items restriction, and the aggregate quantity of items conforms to the quantity of items restriction when the aggregate quantity of items satisfies a predetermined relationship with the quantity of items restriction.

27. The computer-readable medium of Claim 26, wherein the aggregate quantity of items satisfies the predetermined relationship with the quantity of items restriction when the aggregate quantity of items does not exceed the quantity of items restriction.

28. The computer-readable medium of Claim 17, wherein the budget basis is a quantity of item types, the particular budget basis is a particular quantity of item types, the aggregate budget basis is an aggregate quantity of item types, and the revised aggregate budget basis is an revised quantity of item types, the budget restriction is a quantity of item types restriction, and the aggregate quantity of item types conforms to the quantity of item types restriction when the aggregate quantity of item types satisfies a predetermined relationship with the quantity of item types restriction.

29. The computer-readable medium of Claim 28, wherein the aggregate quantity of item types satisfies the predetermined relationship with the quantity of item types restriction when the aggregate quantity of item types does not exceed the quantity of item types restriction.

30. The computer-readable medium of Claim 17, wherein the step of accepting the order request is comprised of sequences of instructions which, when executed by the one or more processors, cause the one or more processors to carry out the steps of: when the revised aggregate budget basis does conform to the budget restriction, sending an order request notification to a recipient; receiving a reply from the recipient in response to the order request notification, wherein the reply specifies whether the order request is approved or not approved; when the order request is not approved, denying the order request; and when the order request is approved, accepting the order request.

31. The computer-readable medium of Claim 17, wherein the step of denying the order request is comprised of sequences of instructions which, when executed by the one or more processors, cause the one or more processors to carry out the steps of: when the revised aggregate budget basis does not conform to the budget restriction, sending an order request notification to a recipient; receiving a reply from the recipient in response to the order request notification, wherein the reply specifies whether the order request is approved or not approved; when the order request is not approved, denying the order request; and when the order request is approved, accepting the order request.