WO2002007008A1

WO2002007008A1 - Network procurement system

Info

Publication number: WO2002007008A1
Application number: PCT/US2001/013913
Authority: WO
Inventors: Cornelis Hubertus Johannes Maria Ubink; Carolina Adriana Johanette Van Den Bosch; Olaf Reinhard; Paul Mazzapica; Mike Grecco
Original assignee: Ubink Cornelis Hubertus Johann; Den Bosch Carolina Adriana Joh; Olaf Reinhard; Paul Mazzapica; Mike Grecco
Priority date: 2000-04-28
Filing date: 2001-04-30
Publication date: 2002-01-24
Also published as: AU2001259274A1

Abstract

Product procurement services are provided to a customer by receivng from at least one user representing the customer a purchase order (128) for a product in a product database containing a listing of a plurality of products available from at least one vendor (130) and purchase terms for a sale of each of the products, the purchase order being according to the purchase terms in the product database associated with the product. It is termined whether the purchase order falls within predefined order limits for the at least one user. If the purchase order falls within the predefined order limits, the at least one user is provided an opportunity to commit to purchase the product (132). The procurement service may be implemented as a network based system.

Description

NETWORK PROCUREMENT SYSTEM FIELD OF THE INVENTION The present invention relates to procurement methods and systems.

BACKGROUND Company managements the world over are recognizing the strategic importance of procurement within their organizations. A shift is occurring from classic, reactive, and paper intensive purchasing departments to proactive and strategic professional procurement departments. The results are startling and range from significantly reduced costs, faster cycle times, and supplier partnerships that impact the bottom line to competitive advantages, and even revenue generation programs. Strategic procurement is a major competitive weapon to differentiate companies, particularly amidst increasingly shrinking margins. Similar to the Internet growth and acceptance phenomena, strategic procurement is becoming a necessity in order to survive in the new global economy. There are a number of steps toward moving to strategic procurement. The easiest to recognize is the development of Internet-based procurement software designed to reduce transaction costs and to automate many the steps required to move toward proactive and strategic activities.

The marketplace currently offers two major procurement system concepts. First, companies such as SAP of Walldorf, Germany and Oracle of Redwood Shores,

California offer manufacturing focused procurement systems as part of their enterprise wide suite of business applications. The design of these programs essentially duplicates the current tactical purchasing process, provides data integration into databases, and provides some automation for the purchasing department. The added incremental input requirements sometimes increase the manpower required to run these purchasing systems. When properly implemented though, the data integration value offsets the resource costs. The second and newer concept is the use of the Internet for the development of marketplaces and auction sites. Current industry leaders include CommerceOne of Pleasanton, California and Ariba of Mountain View, California. Recent announcements by Ford Motor Company of Dearborn, Michigan, Cargill of Minneapolis, Minnesota, and others have generated great interest in these models.

The chief value is a reported reduction of transaction costs from an average of $150 per purchase order to less than $30 per purchase order. Other values include ease of use by purchasers and increased buying leverage with fewer suppliers. The major downside thus far is that this arena has limited itself to indirect sales, for example, buying simple items such as office supplies, desktop computers and other items normally bought for internal use. The current approaches do not include customized, proprietary, one-off services, or other similar functionality. For most companies, over 70% of their spending requirements are not included.

A procurement department spends a company's money and does so often at the request of other employees of the company. This simple statement has consequences for any procurement system that is to be developed. Moreover, a number of legal requirements exist either on a regional, national or international level, which in turn stipulate demands on a procurement environment. Therefore, procurement systems must ensure accountability and trace-ability of various transactions, as well as transparency of the process, while ensuring confidentiality of information and providing the tools for a pro-active, value-add environment. All of these features, which sometimes conflict, should be satisfied. No system currently addresses these issues. Therefore, there is still a need for a solution that addresses the shortfalls of existing systems within the procurement industry.

SUMMARY OF THE INVENTION In a method for providing procurement services to a customer, and a system embodying the method, a purchase order is received from at least one user representing the customer for a product in a product database containing a listing of a plurality of products available from at least one vendor and purchase terms for a sale of each of the products. The purchase order is according to the purchase terms in the product database associated with the product. It is determined whether the purchase order falls within predefined order limits for the at least one user. The at least one user is then provided an opportunity to commit to purchase the product if the purchase order falls within the predefined order limits.

The above method and system provide the framework for automating a requisition process, thereby decentralizing the tasks normally associated with paper- intensive and procurement department reliant procurement processes. The system may be implemented in part in a hosted environment or locally at a customer according to the customer's preferences. If required automatic generation of a request if the required item is not covered under the product or does not fall within a predetermined order limit may be accommodated. The above and other features of the present invention will be better understood from the following detailed description of the preferred embodiments of the invention that is provided in connection with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings illustrate preferred embodiments of the invention, as well as other information pertinent to the disclosure, in which:

FIG. 1 is a stylized view of a network-based procurement system; and FIGS. 2-5 are flow diagrams illustrating the functionality of an exemplary procurement process.

DETAILED DESCRIPTION First, it is necessary to define what the procurement process is, where it begins and where it ends. Procurement is often understood to be a synonym to ordering. However, the term procurement is considerably broader than the term ordering. Many current systems support primarily such as narrow interpretation to the extent that they concentrate on providing administrative support limited to registration of orders. Existing ERP (Enterprise Resource Planning) applications supply this functionality. There remains a need to look at the entire procurement process and its links to the other processes in an organization. This process typically begins with the recognition of the requirement for a product or service and runs through the specification process, market evaluation and contract negotiation. This process also includes follow-up, shipment and receipt. Finally links have been identified which can be made to accounts payable systems, commitment registration systems, inventory control systems, MRP (Material Resource Planning) systems and CAD (Computer Aided

Design) systems. These links to outside systems bring the entire procurement process to a logical close. The described system and method automates portions of the procurement process that are not addressed by any other current solution. Each of these features is described in more detail below. Referring to Figure 1, a stylized view of a system 10 is shown. A computer network 12, such as the Internet, facilitates the transfer of information between sources such an application service provider indicated as procurement service provider system 14 and a customer system 16. The procurement service provider system 14 may include a host server or cluster of servers and databases which may be programmed to provide some or all of the procurement system's features described herein. The service provider system 14 may be accessed through a customer system 16 which provides individual user terminals and servers, such as computers, within the system 16 access to the Internet, and thus system 14, typically through a local area network (LAN) or wide area network (WAN). The customer system 16 may include a plurality of interconnected local servers, computer terminals, and databases.

The customer system may include existing ERP systems, such as accounting and inventory control systems. An individual user terminal 18 may also be configured to access the services of system 14 through Internet 12 independent of customer system 16.

A user terminal 18 may be a computer which accesses a system 14 using the domain name of the web server with procurement service provider system 14 and Internet browser software, such as NETSCAPE or Microsoft' s INTERNET

EXPLORER. A terminal 18 may include other devices which allow communications via a computer network, such as a pager which can communicate through the Internet using the Internet Protocol, a Kiosk with Internet access, a connected electronic planner (e.g., a PALM device manufactured by Palm, Inc.) or other device capable of interactive Internet communication, such as an electronic personal planner, or combination thereof.

Also shown in system 10 are vendor system 20, shipper system 22, and external data sources 24. Although only one external data source 24, customer system 16, user terminal 18, vendor system 20, and shipper system 22 are shown in Figure 1, system 10 may include a plurality of each of these systems and sources.

The functionality of the procurement process described hereafter may be implemented in software within a stand-alone system or be complementary to an established ERP system being run locally within a customer system 16. The application may be used in either an intranet installed model where some or all of the functionality is provided by a customer system 16 or in a hosted environment where software providing the described functionality is preferably installed on a central cluster of database, transaction and web servers within procurement service provider system 14, which is accessible by any thin client user terminal using standard browser technology. Of course, dedicated links or communication paths, although not shown in Figure 1, may also be provided between external data sources 24, vendor systems

20, and/or shipper systems 20 to the procurement provider system 14 and/or customer system 16. Additionally some functions as described hereafter may be WAP-enabled. Before a product may be procured using the procurement process described below, an electronic product catalog is first developed and stored in a product database. The product database is preferably maintained within procurement service provider system 14 in order to provide centralized access to a plurality of users through the Internet, although this is not a requirement. The advantage of centrally locating the database is that modifications need only be made at one central location accessible to all customers, and accessibility to the database is not location dependent. The database may alternatively be located at each customer system 16, or partially between the customer system 16 and provider system 14, but this alternative requires the periodic updating of the product catalog within each customer's database, such as through CD-ROM updates or downloads from a central master database.

The product catalog includes a list of a plurality of products, whether the products are material objects, e.g., computers, pens, paper, toner cartridges, desks, staplers, etc., or services, e.g., temporary labor services, drafting services, advertising services, computer programming services, etc. The products lists may be downloaded from a vendor's database located at a vendor system 20 or otherwise inputted into the product database. Each product in the product catalog is associated with one or more sources or "vendors" for the product. For example, a product such as a specific brand of pencils may be available from several different vendors (Vendor A, Vendor B, Vendor C, etc.) which have products listed in the product catalog. If several similar but not identical products are entered into the product catalog, such as several different brands of pencil, one or more of the products may also be indicated as a "preferred product" based upon as predefined criteria for designating products as such. Entry of the product into the product catalog is based upon the existence of a framework agreement. The framework agreement sets forth terms and conditions at which a vendor is willing to sell a product, including quantity levels, pricing levels, shipping conditions, and the like. These conditions may be actively negotiated between a customer and a vendor or, in a hosted environment, between the host and a vendor. The vendor may agree to different pricing levels which may be available based upon the size of the customer (e.g., small v. large) or quantity or price of orders, for example. The products and price levels agreed upon between a vendor and a customer or a vendor and a host are loaded into a database, which is made available to all selected authorized users as described below through the product catalog. It should be understood that the framework agreements provide structure to the product database and facilitate procurement decisions and simplification for a customer, but need not be what is considered"firm" offers. Each product is listed in the catalog with at least one price. Of course, if a product is available from more than one vendor, the product may be listed with more than one price if the prices differ. Alternatively, even if more than one vendor is available for a particular product, a single price could be listed for the product which, particularly in a hosted environment, provides some margin of profit to the host. The price may be determined by a procurement specialist or other person by comparison of competitor prices, taking into consideration costs incurred by the host. The prices shown to the customer may, therefore, be the price the customer can agree to pay regardless of the vendor. If the host chooses the vendor, the host can choose a vendor with a sales price that maintains the hosts desired profit margin. In this situation, payment is made to the host at the host price and to the vendor at the vendor price, with the host earning the margin. The listed price can be dynamic, and change in order to reflect market conditions.

A cross-selling table may also be created for each product in the product catalog, if appropriate. This table may include accessories or other products within the product catalog which are related to a listed product, but which are usually sold separately (with or without a discount). For example, a desktop computer product may be associated with a mouse pad, a printer, software, floppy diskettes, and the like, all of which are also listed in the product catalog. The product catalog may also include a comparison table which identifies products which may be considered equivalents of a listed product. This may be particularly useful with replacement products. For example, a generic ink refill may be cross-referenced from a brand-name ink refill for a brand-name pen. Product codes, pictures, and descriptions may also be included for some or all of the products in the product catalog in the product database. These descriptions may be used in creating key words which are associated with each product and which facilitate searching and querying of the product catalog. Physical dimensions and weights for each product may also be included as part of the description if available. In order to facilitate organization of the database and cross-references to products, each product is preferably provided with a material coding, which can identify both generic and specific information. This material coding may be provided separately from any "keywords" associated with the product. The generic level provides sufficient detail to allow the selection of products. A more specific level is used where such information is necessary, for example in order to identify equipment with its spare parts. The structure is such that flexibility is ensured, with at least two levels of identification, i.e., class, category and optionally groups and subgroups. The system could, however, support an infinite number of categorizations. In one embodiment, each material code is a Universal Standard Products and Services Classification (UNSPSC) code. The UNSPSC code covers many products and service that can be bought or sold. It currently includes over 12,000 codes covering everything from pencils to computers and from accounting to cleaning services.

Each product may also be linked to different standards of measurement when important, such as the metric system, (name other two), thereby, allowing a relationship to be established between various units of measurement that may apply to one material code. A table provides the values between the units of measurement per material code allowing automatic calculation of appropriate quantity per unit of measurement (e.g., 1 kg of material X = 1.23 liters of material X). This feature allows a material to be ordered by customer in a first unit of measurement, ordered at a vendor in a second unit of measurement and, and invoiced in a third unit of measurement, all as per the appropriate industry standards for the material or customer preference.

It should be apparent that the database described above may be structured in any number of manners and styles, but in any case should be easily searched and modified and be available at all times to any module operating within the system. Each product is also preferably identified in a standard format which is not vendor dependent. Once a database of products is compiled, access to the database may be offered to customers. Of course, if centrally located, access to the database may be offered on several access levels. For example, access may be provided to the world in general, such as is conventional with many e-commerce retailers. An individual person or business may also be registered as a preferred user which is entitled to discounted prices. However, the enhanced functionality of the procurement system is preferably offered to "customers," those businesses or other entities which register for the services of the procurement system as described below.

Each vendor of a product in the database is also preferably listed in a vendor database, which may or may not form a part of the product database. The vendor database preferably includes contact information for the vendor, such as employees contacts, telephone numbers, addresses, access information for a vendor computer system 20, etc., as well as the vendor's standard shipping terms, conditions and possibilities. For example, the vendor can list the different shipping companies that it uses as well as delivery options, e.g., overnight, within ten days, etc. These vendor shipping options may be listed along with the product in the product catalog to allow a user to select a product from a specific vendor. Further details of the vendor database are described below in connection with the procurement process.

Once the product and vendor databases are compiled, at least one customer is preferably registered, although a plurality of customers is desired in a hosted environment in order to utilize economy of scale considerations. A customer is typically a business, government agency or department or non-profit, such as an educational institution, or a division, location or department of any of the forgoing, or other entity that has employees, contracted personnel, or volunteers and procurement needs. For each customer, the functionality of the present system may be utilized to streamline the procurement process by relieving a customer's procurement department of many of its procurement responsibilities. In order to utilize the features of the Procurement System, the customer is first registered with the system during a setup process. During the setup process, the customer's employees are preferably modeled in a hierarchal structure of those employees who may at some point utilize the procurement system described herein or who have responsibilities within the procurement process. A first level of employees preferably includes "user" groups of employees. Each user group preferably comprises a plurality of employees who are likely to have similar procurement needs. For example, a user group may include all of the secretaries of a company or those employees who are within the same department. These individuals are likely to have overlapping procurement needs, such as repeated orderings of paper, pens, toner cartridges, computers, etc. Of course, an employee may be a part of more than one user group if desired. Another example may be an information services group, which would typically order computers, software, routers, programming services, and the like. A second level of employees includes "supervisor" groups of employees. A supervisor group may include one or more employees and be responsible for at least one user group. A supervisor as described below may authorize procurement transactions which do not otherwise fall within pre- authorized transactions for a user group. Approval can include multiple levels of supervisors. Settings allow for approval from one or all supervisors. The hierarchy can be flat (any supervisor can approve) or vertical (all supervisors in the chain must approve). Depending upon the product, approval may require managerial approval for costs and technical approval for necessity and proper specification confirmation. A third employee level includes an "administrative" group. This group may include one or more employees, such as high level managers, or members of the procurement department of the customer. These persons are generally responsible for any final decisions that affect substantially all user groups, such as those persons who are in charge of initially registering the customer in the system or reconfiguring user groups or product groups as described below. Some members of the administrative group may be non-employees of the company, such as in an application service provider embodiment. The groups may be structured such that those employees in a supervisor or administrative group are themselves included in a user group. Each user may also be identified with a user profile which identifies the user's group, a username, and a password. The profile can also include user-specific billing and shipping address and payment methods. The profile is preferably flexible to accommodate the preferences of a customer.

Shipping information for each customer is registered as well as billing information. Shipping information, such as shipping addresses, may preferably only be modified by a user in the administrative group. All purchases may, for example, be made on a credit account provided the customer by the vendor, on a single credit card account, a plurality of credit card accounts (e.g., departmental credit cards), or on company credit cards issued to individuals. Procurement cards or Electronic Check Handling (ECH) methods may also be utilized.

The customer is also preferably modeled financially, for example, on a budgetary level. Each department may be assigned a budget for a specific time period, whether it be a fixed time period (e.g., one calendar month) or a rolling time period (e.g., the last 30 days). Budgets may be delineated by user group, by individual, and/or by product. As a part of the customer registration process, availability of the product database may be apportioned amongst the user groups. For example, assume a product database includes a list of 27,000 products, of which 200 are products which a secretarial user group may regularly need to order. These 200 products may form a defined product group for the secretarial user group. The maximum quantities that may be ordered and total amounts spent on these items (preferably per fixed or rolling time period) are defined for the group and/or for any user within the group. For example, an individual user within the group may be limited to purchases of paper that do not exceed $200 or that do not exceed 100 reams of paper in any thirty-day period. Likewise, the entire user group may be limited to maximum combined purchases for a given period of time. Purchases by individual users also affect departmental budgets described above.

Accessory listings and cross-selling references for generic equivalents in the product catalog may also be limited by user groups if desired. It should be apparent that registration is preferably a dynamic process. For example, user groups may be modified, products may be added or deleted from product groups, and product pre-authorization levels may be modified. As described below, the initial customer registration process allows for the automation of a substantial portion of the responsibilities conventionally handled by staffed procurement departments. This provides a powerful tool for improving the overall efficiency of a customer while requiring only the initial, reasonable efforts expended in the registration process, i.e., to identify user groups, product groups, and product levels.

A procurement process utilizing the above customer registration and product catalog generation processes is described hereafter in connection with Figures 2-5.

Various functions are described in connection with individual software modules, but it should be apparent that these modules merely describe functionality and some or all of the functions may be combined instead of being provided as discrete modules. Also, as described above, the process may be implemented through a procurement service provider system 14 or local embodiment within a customer system 16 or be distributed among systems 14, 16.

Referring to Figure 2, a user from a user group defined in the customer registration process begins the requisition process by accessing an ordering module at step 100. Access may be granted through, for example, providing a username and password to a login screen or webpage of the system or other secure access methods. A menu screen or page is then generated and provides the user with at least an option of "ordering." The order module allows the user to browse a product catalog at step 102. The product catalog is preferably limited to the product group defined for the user's user group. If a product is not found within the user's product group at step 105, the user is transferred to a request module at step 104, described below in connection with Figure 5.

If a product is identified for procurement by the user, the user selects the product for purchase at step 106 and fills out an order form for the product at step

109. As described in the customer setup process above, each product in the catalog may also be listed along with cross-references to equivalent products and/or accessory products which a user may wish to purchase at step 110 along with the user's desired product. Assuming the listed price and delivery terms in the product catalog are acceptable to the user at step 107, the user is prompted to identify whether he or she requires a vendor recommendation at step 108 (assuming more than one vendor is available for the acceptable terms). If the user does not require a vendor recommendation or only one vendor is listed or associated with the selected product, an order form is filled out by or for the user at step 109. The order form may include such information as product identification code, ordered quantity, payment method, delivery date requirements, and vendor of the product(s). Some or all of this information may be predetermined for the product in the product database and imported from the product database rather than provided for user selection. If the terms identified in the product catalog are not acceptable to the user at step 107, if the user requires a vendor recommendation at step 108, or if more than one vendor is available and the user requires automated vendor selection at step 108, the vendor recommendation and identification procedures are completed before the order form is completed at step 109. These procedures are described below in more detail.

If the vendor for the product is already identified, and thus the location of the vendor is known, import duties (if necessary) can be calculated and included in the total purchase price on the order form. This may be accomplished by cross- referencing the material coding of the product with information from the worldwide Harmonized System - an external data source 24 - supported by the World Customs

Organizations (WCO) and GATT, to allow easy calculation of import duties. The Harmonized System information may be download from WCO if available or otherwise entered into a database and periodically updated.

The user may choose at step 110 to continue browsing for additional products. When the user has filled out all desired order forms for products, the purchase order placed by the user is transferred to "checkout" module at step 112 and described in connection with Figure 3. The user's orders may be maintained in the user's electronic "shopping cart" until an order is actually placed with a vendor, thereby allowing the user to "log out" of the system and return to an order at a later time, such as when an order is pending approval by a supervisor group as described below.

Referring to Figure 3, the purchase order of the user for a product selected by the user as described above are checked against any restrictions placed on the user in the customer registration process. Restrictions are also referred to herein as predetermined order limits. It should be understood that a "purchase order" as used herein is not a commitment to purchase, but rather identifies the terms of a purchase.

The user may still be required to affirmatively commit to the terms identified in the purchase order, such as after the order is checked against any predetermined order limits on the user or user's group and/or after supervisor approval of the purchase order is received. These terms may still require a commitment by the user. For example, if the user is in a user group that has a defined budget limitation, it is determined whether the user's purchase order amount falls within the budget amount at step 114. This task may be performed by a budgeting module which utilizes the budget information set forth above provided during customer registration. As mentioned, a budget may be defined for each user group or for a department group including the user. Each time a purchase is made by a user within a group that is subject to budget restrictions, an indicator is updated identifying how much of the budget is still available. If the order falls within the available remaining budget balance, the order is checked at step 116 to identify whether the order falls within the quantitative restrictions placed on the user group or placed on the user in the customer registration process, e.g., order quantity and total cost per item or per time period. If the order satisfies these restrictions, the order is then processed by a vendor order module at step 118 in order to place the order with the vendor. If the order does not meet budget or quantitative restrictions at steps 114 or

116, the order is sent for approval at step 120. The individual or group which has approval authority is defined in the customer setup as the supervisor group having authority over the user's user group. An approval or authorization module may be responsible for the authorization process. Approval by more than one supervisor within a group or more than one supervisor group may be required if so designated in the customer setup. As mentioned, both technical and financial authorization possibilities may be possible. The module preferably allows the authorization holder to delegate his/her authorization temporarily to another employee for a fixed period of time or alternatively select the option for remote authorization using WAP technology. Approval can also preferably be temporarily conferred by a supervisor to another employee. The delegation feature may be particularly beneficial when a supervisor or group of supervisors will be unavailable for any extended period of time, such as for vacation or a conference. The approval request may be accomplished in the form of an email notification to the supervisor group (or individual within the group) to which the supervisor may respond with an approval or disapproval. The email request may be periodic in nature, such as twice daily. The supervisor may also be prompted for approval or disapproval the next time the supervisor accesses the Procurement System through the login procedure. Notification and approval may also preferably be given through a WAP enabled telephone or device. This feature is particularly beneficial when a supervisor often travels. If the supervisor does not approve the order at step 122, the user is preferably provided the option of modifying the order at step 124. If the user opts to modify the order, the system links at step 126 to the order form procedure identified at step 109 of Figure 2. The order process ends, at least with respect to that particular order, if the user decides at step 124 not to modify the order. If the order meets the budget and quantitative restrictions at steps 114 and 116, the order is forwarded to the vendor order module for processing as described in connection with Figure 4.

Figure 4 is a flow chart illustrating the processing of an order transferred to the vendor order module. The steps illustrated in Figure 4 assume that a vendor has already been identified for the product, i.e., the vendor identification and recommendation procedures of Figure 2 are complete if required. Functions which may be performed external to the vendor order module are indicated to the right of bar

131. An order from step 118 (Figure 3) is forwarded at step 128 to a vendor of the ordered product. Of course, this could be accomplished by mailing or otherwise transmitting a paper copy of an order, but the order is preferably transmitted electronically through the Internet to a vendor system 20 (Figure 1). The steps illustrated between bars 131 and 133 indicate functions performed by the vendor in the procurement process, and steps illustrated to the right of bar 132 indicate steps which a shipping agent performs. The vendor, and preferably a vendor's electronic order processing platform, receives an order at step 130 and forwards an order receipt confirmation to the vendor order module at step 132, which is received by the vendor order module at step 134.

After order receipt is confirmed at step 132, the vendor typically undertakes various order completion activities at step 134, including confirming whether the product is in stock and confirming whether the customer's shipping requirements can be met by the vendor. If the vendor cannot meet the order requirements, the vendor order module receives notice of this inability at step 136. The user may then be notified so that the user can select a new product or a different vendor for the product. This notification is received by the user at step 137. Notification may be by electronic mail or posted notice to the user in a predefined location on a screen or webpage when the user logs into the system 14 (in a hosted environment) or system 16 (in a non- hosted environment). If the order can be filled by the vendor, the order is completed at step 138, and order completion notification is received by the vendor order module at step 140. If payment for the product is to be made using a credit card, a pre- authorization procedure may be executed during the checkout procedures so that the credit card account may be charged when the order confirmation from the vendor is received.

The vendor order module may customize the order completion notice at step 142 in a manner preferred by the customer, such as in a customer's preferred language and including tracking numbers for the shipping agent. This notice may also be customized to the customer's preference with respect to measurement units and currencies, which are described in greater detail below. This feature recognizes that a procurement system may be global in nature, particularly when implemented through the Internet and with customers who have a global presence. If the vendor order module is run at least in part in a hosted environment, the notice is transmitted through the Internet at step 144 and received by the customer at step 146. This notification may be in the form of an electronic mail to the user who placed the order, or a notification to the user the next time that the user accesses the Procurement System, e.g., the next time the user logs into the system to use any or all of the functionality provided by the system.

As is conventional, the user may use the tracking information at step 148 to monitor the progress of the ordered product. The system may provide links to the shipper's computer system 22 in order to track the product. Steps 150 and 152 indicate that the shipping agent is notified by the vendor that a product must be ordered, and the shipping agent then ships the product to the customer.

Figure 5 is a flow diagram illustrating the steps in the procurement process which occur after step 104 of Figure 2, i.e., when a user cannot locate a desired product within its product group. The user identifies at step 160 a product which the user desires to purchase. The product may be specifically identified, such as by product name, or through search criteria. At step 162, the entire product catalog, not just the product group available to the user's user group, is searched. If the product is located in the product catalog, the order is sent to the user's supervisor for approval at step 164, and the approval and order process is followed as described beginning with step 120 of Figure 3.

If the desired product is not in the product catalog at step 162, off-catalog order procedures are begun at step 166. If a product is not located by the procedures of step 166, the ordering process ends at step 168. If a product is located at step 168 from the off -catalog procedures of step 166, an order form is filled out by the user, as described previously at step 108 of Figure 2. The order is preferably automatically tagged, however, as requiring supervisor approval once the order proceeds to the checkout processes illustrated in Figure 3.

The off-catalog procedures indicated at step 166 of Figure 5 can take on any number of forms and may also be automated at least in part. For example, a request may be forwarded to a procurement specialist employee of the application service provider or to, or through, a procurement specialist of the customer. The request may be in the form of telephone, electronic mail, or live chat room correspondence. A product may be located by the procurement specialist from one or more vendors, which may or may not be listed in the vendor database, and be identified to the requesting user along with pricing and shipping terms. A request is generated by the customer or procurement personnel at the request of the ordering user. The administrative groups are preferably provided access to a software module which automatically creates a Request for Quotation (also known as Request for Proposal or Enquiry). To do so, the product specifications may be obtained from the user's request; by identifying the appropriate product category, possible vendors may be identified from the vendor database that provide products in the desired product's categories. Additional requirements may be added, such as required delivery time, proposed delivery terms, payment terms, applicable terms and conditions and so forth. Upon receipt of a quotation, a bid tabulation and bid summary are preferably created in the application, calculating all costs first in bidder's currency, and subsequently in the customer's currency for evaluation purposes. Bids may also be solicited from vendors which are not a part of the vendor database, but upon receipt of a bid, particularly a winning bid, the vendor should be registered in the vendor database to facilitate processing of the order.

If the product is acceptable to the user, an order form is filled out by the user at step 170. If the vendors identified by the procurement specialist are listed in the vendor database, the vendor identification and recommendation procedure identified in Figure 2 and described below may be utilized. The quality of the proposals may also be stored in the vendor database for utilization as described below. The product may also be added to the product database if acceptable to the vendor. The product can then be added to the product list of various users as appropriate. The vendor recommendation and identification procedures indicated in Figure

2 are now described. Assuming that more than one vendor is available to supply a product and the user has requested a vendor recommendation at step 108, or an automatic vendor selection procedure is enabled, a vendor identification and selection process may be initiated to either automatically select a vendor or to provide a list of ranked, available vendors to the user for selection by the user. The ability of the vendor to fill the order according to the terms may be verified as described in connection with the vendor order module of Figure 4 prior to generating the list. The list of vendors may be generated by ranking vendors according to a vendor comparison process as described hereafter, or automatic vendor selection may be implemented by automatically selecting the highest ranking vendor after the comparison process is complete. The functionality may be implemented in a software module. Also, in the hosted embodiment of the system where only one price for the product is displayed to the user, only vendors that offer prices which fit within the hosts profit margin are preferably listed or considered.

The vendor database in connection with the product database includes information which provides the basis for the evaluation of vendor performance and sale terms. The vendor evaluation and identification procedures may be implemented through a vendor evaluation module which uses predefined weighted factors to indicate a ranking of vendors. Populating the vendor database preferably includes a first phase which is a simple registration of supplier details (address, bank details, and such). The next phase registers the results of pre-qualification, including possible financial limitations, physical or infrastructure limitations such as warehouse capacity, and identification of product categories and terms and conditions that the vendor can satisfy, etc. The third phase may include compiling vendor performance data identifying the historical results of actual use of the vendor by customers or other purchasers, incorporating both quantitative and qualitative factors such as overall delivery performance, overcharges, delivery shortages, delivery of damaged goods, compliance with specifications, quality of prices, quality of proposals or bids received during off-catalog processes, and shipping flexibility, to name a few. This customer feedback may be supplied by the customer through electronic questionnaires regarding delivery performance or otherwise inputted into the vendor database. This, vendor performance history is typically generated after the supplier is registered into the system and has performed services or supplied goods. If other information is available, such as through a marketing or satisfaction study, this information could also be imported into the system. The vendor may be discontinued if performance remains below the required minimum, but the history for such supplier is maintained.

In the customer registration process, or as a part of the order process, the customer or user can rank the importance of certain criteria, such as quality of goods, competitive pricing, on-time delivery, minority ownership preferences, location of the vendor, size of the vendor, the history of possible requests for remedial action against the supplier, and the like. Alternatively, the factors can be weighted according to a default setting of importance. It should be apparent that the number and type of factors may vary. In any case, the factors are weighted according to the defined set of rules in order to identify and recommend the vendor which most closely satisfies the customer's defined criteria - the vendor with the highest ranking. The vendor evaluation and identification module may then automatically select the highest ranked vendor or provide the user with a list for selection. Once a vendor is identified, the order may be placed with the vendor as described above.

The vendor database may also be used in the scenario where the customer has identified a product for purchase at step 106 (Figure 2) but the terms of the purchase are not acceptable to the customer. This scenario should be distinguished from the situation described above under the request process where a product is not in the catalog at all. The customer then provides its preferred pricing and shipping terms which are different from those listed in the product catalog. The customer's terms can be provided in. an open forum to a plurality of potential vendors. The vendors can submit their best offers, which after vendor reconsideration may match the customer's preferences even though those listed for the vendor in the product catalog did not. The offers can then be evaluated according to the factors identified by the customer or default set of rules to provide the customer with what is objectively analyzed as the best offer. If the offer is acceptable to the customer, the order may be placed with the vendor as described above. In a hosted embodiment, the vendors may return their offers to the host, who may then identify whether any offers allow the host to maintain its desired profit margin at the user's requested terms before presenting a price or other terms to the customer. The quality of offers may be recorded in the vendor database for future use in a vendor ranking and identification process. Quality may be any number of methods, including the ranking of the vendor's bid, the amount of difference between the vendor's bid and the average bid, or other method. Alternatively, if the customer does not find the price and/or shipping terms for a product in the product catalog which meet the customer's preferences at step 107, the vendor database may be used to identify a vendor for the product whose terms do not exactly meet those of the customer, but who, based upon the weighing of the factors described above, most closely meets the preferences of the customer without opening the order up to an open vendor proposal. If this closest vendor is acceptable to the customer, the customer can proceed with the order process and the order may be placed with that vendor. This process may also be distinguished from the Request process described in Figure 5 where the product is not available within the customer's product group. Again, in a hosted embodiment where one price is offered to a customer, the host can offer a price to the customer which allows the host to maintain it profit margin.

The vendor selection process and customer feedback features also provide valuable information which may be provided to vendors. Assuming Vendor A, although registered in the vendor database as providing a specific product, rarely receives orders from the system. The vendor may be informed based upon the above described selection process that, for example, its prices are not competitive or its timely shipping performance has weighed against selecting or recommending the vendor for order fulfilment. The procurement process allows controlled, de-centralized requisition by an end-user, incorporating procurement card functionality and creation of consolidated call-offs to framework vendors while maintaining the identification of an order per requisition, per user, and per delivery location. Delivery confirmation (either full or partial, with or without delivery discrepancies), consolidated outgoing invoices in a fully hosted environment or internal transfer in an intranet environment may be included. Commitments registered as a result of call-offs may also be forwarded to a customer's ERP commitment registration system - a customer's financial system which registers and tracks the customer's financial commitments. The steps executed in order to order a product within an exemplary automated procurement process are described above. Other features which may be incorporated within the process or which enhance the procurement environment generally are described hereafter.

Since the procurement process and system may run in a fully hosted environment (i.e., the procurement function is outsourced to the host), the system preferably provides the facility for the easy creation of invoices if the user did not choose a credit card payment option. The procurement process can either generate the invoices or merely provide the required information to an invoicing system. This information is preferably consolidated per pre-set time periods and for each customer. Different price levels for customers are supported. This feature may also be used by customers in an intranet environment should they require the charging of costs to separate business units. Since the host system 14 can serve as a middleman between the vendor and customer, the host can customize the invoice to the customer, such as by providing the invoice in the customer's preferred language, units of measurement, and currency.

In one embodiment of the procurement system, a customer and/or a vendor may be provided access to a contract module in order to create specific contract documents, to develop template agreements and to register and distribute the contract to identified users. The contract module may be utilized by a customer (or a vendor if so desired) and have access to a database containing header information containing the information of the customer, and standard portions of its contracts, including, for example, name and address, delivery terms, payment terms, summary of the contract document, unique reference number used to identify the document, etc. The detail level is created from a database containing all the standard contract clauses used within a customer's organization. The user can create the contract by selecting the various clauses. Re-numbering preferably takes place automatically. Furthermore, various relationships between the various clauses can exist such as "if using this clause add also that clause" or "when using this clause, that clause cannot be added."

Changing the wording of the clauses is also allowed for users that have the appropriate access level. The documents so created are provided to various parties in read-only mode, and possibly with or without confidential information if so authorized. A vendor, a customer, and/or a host may use the module when populating the product database with products, and thus terms and conditions which apply to the sale of the products.

When the customer commits to a purchase covered by the created template contract (which in itself does not create a commitment), the commitment may be registered by notification to an external ERP system as a commitment registration. This interface with the ERP system may be through an XML interface.

Expert contracts may be created using the same standard clauses, creating templates for typical contracts, e.g., typical contract for services, typical car lease contract, typical software development contract, etc. These template contracts may be modified using clauses from the contract clause database. Users can modify the contract content and clauses providing the user has the appropriate authorization level.

When goods are received by a customer, the user may access the vendor database through a user interface (e.g., computer screen or webpage) in order to provide feedback to the database on vendor compliance with the order requirements. A link may also be provided to an ERP inventory management system of the customer in order to enter new inventory into the ERP management system, if the customer maintains such a system. If such a system is maintained, the order module or other module within the procurement system can also cross-check an order with the inventory database before allowing an order to be forwarded to a vendor. This provides protection against ordering products which are in stock or overstocked by the customer. The system can translate between the material coding of the product in the database to that used in the customer's ERP inventory management system. For specialty orders such as those which are specification intensive, such as machine design and construction, an expediting or quality control module may be utilized by the procurement department. When a specialty order is placed and before delivery, a procurement department typically carries out a number of actions. These actions are specifically expediting and inspection. An expediting and inspection module allows the expeditor or auditor of the customer to view all orders placed with a particular vendor and provides the user with the possibility to enter information related to the order(s), such as fabrication on schedule, sub orders placed, quality plan required and received, next expediting visit, next expediting call, next inspection visit, actions taken by supplier in the event of delay, and the like. The vendor can update this information either via the procurement system through the Internet or on their own native systems - vendor system 20. In the latter situation, the procurement system is capable of connecting to vendor systems and downloading this information, such as through an XML interface. The system can provide reminders, such as electronic mail reminder or calendar updates to an inspector if and when inspections are to take place. The inspector can be the same person who placed the order, such as procurement personnel. The module preferably allows the inspector to create inspection reports using a browser from any location with Internet access. Standard formats and fields for selected information may be available for the inspector to complete, as well as the facility to associate his/her report with the order reference within the system and provide feedback to the vendor database.

The system and process described above preferably support both multiple currencies and multiple languages. Multi-currency rates can be either fixed rates or flexible. Flexible rates can be retrieved from, for example, bank websites - an external data source 24 - for regular update of applicable exchange rates. The timing of such update is customer dependent. Multiple currencies are preferably shown and calculated for each transaction according to the customer's preferences. The system preferably uses an architecture which includes an active language feature, thereby allowing for immediate translation of all screens in any available language. One of ordinary skill should recognize that operating systems, web browsers and plug-ins are available to handle multi-language functionality.

Throughout the entire procurement process, traceability is ensured by storing data pertaining to an order throughout the procurement process. This data may be stored for the user in the procurement service provider system 14 or locally at the user. Each time a user uses the system to perform a function vis a vis an order, data pertaining to that function or event is stored and includes an identification of the user and the time. Once an order form is created, the status of the order may be stored and updated throughout the procurement process, such as to reflect that the order is in a shopping cart, the order is in checkout, the order is pending approval, a request for proposal has been created, confirmation from vendor has been received, or that the order is in any other stage of the procurement process. It is also possible for a supervisor to take ownership of an order, in essence to accept responsibility for the order. Should this happen, the appropriate access levels for utilizing the functions of the system vis a vis that order are changed to conform to the new owner's access level.

The basic procurement framework described above may be utilized within several specific vertical procurement embodiments. For example, a temporary labor embodiment specifically addresses the temporary labor market. A publisher embodiment addresses the creation of advertisements using standard pricing and ordering features, and n vehicle lease and rental embodiment may utilize standard pricing and ordering features. In these embodiments, temporary labor services, vehicle leases and publishing services are products in the product database, and the ordering process as described above may be utilized to purchase these products. Additional features not described above may be included in the procurement process and method described above to enhance the procurement process relative to these specific products. Within the objective of providing pro-active, value-add tools, these embodiments may form an integrated part of the system, establishing an efficient relationship between a customer and a vendor.

A temporary labor embodiment recognizes that ordering and keeping track of large numbers of temporary employees poses very specific challenges. Temporary labor services may be included as a product in the product database and ordered using the process described above. The request, approval, and vendor identification and recommendation procedures may all be utilized. As an example, a specific user group may have blanket authorization to order temporary labor from the product database for fixed periods of time and at fixed rates. Requests may be generated when the labor service is not within a user's product group and the approval procedures described above may be invoked when the user places a purchase order which exceeds his or her predetermined order limits.

The procurement process described above is maintained but added functionality is provided with easy registration of hours worked, either using browser or WAP or indeed the old-fashioned time sheet. The WAP technology may also be used to report ill, to request leave, or to plan vacation.

A process similar to the approval process described above may also be utilized to approve the actual hours worked by the temporary labor employee. The temporary labor employees may simply be viewed as a user group over which a supervisor has authority. The customer has accurate and up-to-date accounting of the cost of the temporary labor and a tool for easy verification of invoices issued by a temporary labor vendor. The vendor also receives input in electronic format, which permits easy creation of outgoing invoices and updating of the vendor's personnel records for payment of salary to employees. This embodiment offers added value to a customer and vendor which normally falls outside of the procurement area of a customer, but which may be based on the same procurement application describe above and accessed by an authorized customer or vendor user through an Internet browser.

A publisher embodiment uses the general approach of the application but with added functionality. First, framework agreements are negotiated either by the customer or host with a number of publishers based on general templates of advertisements that may be placed. These templates include information such as available sizes, applicable colors and fonts. This process is part of the standard procurement application. However, these templates must be completed with the specific text and/ or pictures for the actual advertisement to be placed. Additional graphics software may be provided to allow the remote users to complete the template with all the necessary information. The user may then select the type of publication or publisher from publishers and publications in the vendor database and confirm the order without undue delay. The advantage of this embodiment to the customer is that an authorized user can create advertisements without jeopardizing the customer standards, which were included in the template or in the selection of standard texts and pictures. The user can compose the advertisement from the various standard components, add the specific text, and select his or her preferred publication method all within the same application. It obviates the need for every single advertisement to be vetted by marketing or legal departments because each advertisement is created within the confines of the templates provided according to the customers set up preferences. Separate standards may be established by vendor publishers for different customers. The vendor/publishers may be granted limited access rights so that they can collect the information and provide order confirmation through the Internet. The advertisement or publication may be provided in any convenient electronic format, such as in a PDF (Portable Document Format) file, Quark or audiovisual (MPEG, WAV) file, to name a few.

Each framework template is linked to a price level with a number of publishers and publications. This allows the user to move from creation of the advertisement to ordering the advertisement in a standardized and automated approach. The environment so created supports a controlled de-centralized environment providing value to various departments within the customer organization. It ensures clear and transparent communication and reduces the need for separate negotiations for each ad providing the framework agreements have been set up to include a wide range of standard price levels per template.

A vehicle leasing and renting embodiment allows for the arrangement of a standard framework agreement with a number of vehicle lease and rental vendors.

Matching of actual drivers to vehicles preferably takes place through the procurement process described above. The ordering, request, approval, user group, vendor identification and recommendation, budgeting, and other features described above in connection with the procurement process illustrated in Figures 2-5 may all be utilized in procuring a vehicle lease or rental. For example, user groups may have predetermined order limits for lease term lengths, pricing, accessories, type of vehicle, vehicle brand, etc. A purchase order for a lease based upon a lease product within product database may be checked against these predetermined order limits as described above. Likewise, the approval, budget and request processes may also be utilized in a lease procurement process.

Consolidated pro forma invoices created on the customer side may provide the input for the vendor/lessor's outgoing invoice and easy verification for the customer. Using WAP technology, mileage, maintenance, and any problems may be reported to both customer and vendor.

The vehicle lease embodiment is similar to the temporary labor embodiment. Where an organization makes use of leased cars for its employees, the ordering process can again be incorporated within the standard application as described above.

Similar to temporary labor, however, a vehicle lease is an ongoing process creating a considerable administrative burden during the lease (i.e., after a lease purchase order has been committed to by a user). Functionality may be incorporated into the process and system to ease burdens arising during the course of the lease, such as reporting damage and repairs, monitoring mileage and maintenance, lease payments and the like. Further, approval processes similar to those described above may be utilized if, for example, a user wants to deviate from a pre-approved maintenance schedule, exceed mileage limits, or generally take any non pre-approved action with respect to the lease or vehicle. It should be apparent that a system implementing the processes described above requires little maintenance on the user level, particularly if the bulk of the functionality is provided in a hosted environment. All software may be centrally located on either an intranet or host servers. Access is provided through standard browsers and linked to appropriate access levels. Standard ERP applications may have some of the above functionality but can -typically not provide the easy distribution to potentially all users without installing the software on each desktop, thereby incurring extra costs. The remote features, using WAP technology or remote log-in using Internet, are innovative approaches. The multi-language feature provides enhanced flexibility to the system. The ability to easily switch between languages at the user-level allows, for example, users within the same company and accessing the same server-based application to simultaneously receive procurement information in, for example, French, English, or German. Regardless of the underlying architecture used to implement the process described above in a hosted environment, the architecture preferably provides reliability, independent from database physical structure and brand (e.g., Microsoft SQL Server, Oracle, etc.), global audit trail, and extensive scaleability of the system up to several thousand or more concurrent users. Using the XML language, although not a requirement for interfacing, provides flexibility within the system for smooth interfacing with supplier, vendor and customer ERPs and systems.

All of the above contribute to the creation of a more cost-efficient and effective customer organization. A controlled environment is created that allows the organization to push the ordering process itself to the end-user on his or her own desktop while using the best prices, standard materials, standard terms and conditions, all as negotiated previously by the procurement professional. The authorization structure ensures that financial and technical responsibilities within the organization are embedded within the application. All this information and functionality is available to any authorized user who has a suitable browser installed on the desktop computer or other user terminal 18. The system can encompass the entire procurement process, from recognition of user requirements to delivery and registration of the product in inventory. The, system is also extensible, able to encompass various vertical specialties such as a publisher embodiment, temporary labor embodiment and an auto lease embodiment, described above.

The procurement process may be implemented through a plurality of software modules, although one of ordinary skill should recognize that some or all of the functionality of these modules as described herein may be combined and/or distributed. Also, although not required, interaction between the system and a user is preferably implemented in a windows type interface, whether it be a webpage transmitted and displayed to a user via a user terminal or an interface screen generated on a monitor by a software stored locally within a customer system. Such windows- type interfaces are well known to those of ordinary skill and allow a user to select from different options presented to the user generally by "clicking" on "buttons" or entering information into "windows" displayed to the user. Any phrase, icon, or the like which is "clickable" may be considered a prompt to the user to make a selection and/or transmit information. Providing the user with two "clickable" alternatives is essentially the equivalent of directly prompting the user with a textual prompt to make a selection, e.g., "Please select A or B." In a hosted environment, the selection of the user is then transmitted through the Internet by the user terminal to a web server. The generation of interactive web pages and their design is also well known to those in the art of web page design, such as those familiar with programming in the XML, HTML, and JAVA languages.

It should also be understood that although a user may be an employee of the customer, this is not a requirement. Temporary contracted workers, volunteers, and part owners of small businesses may all be users. It is envisioned that a representative, such as a representative employee of a procurement service provider entity, could place product orders on behalf of the employee. If this representative represents the user employee, these product orders, however, would still be limited to product orders which the user employee could place as described above, such as those order which may be placed with and without additional approval. In essence, the representative takes the place of the employee, and purchases which would require approval from a supervisor would still require approval. Of course, the web representative could be designated in the hierarchal structure defined in the setup process as having such approval authority.

The present invention can be embodied in the form of methods and apparatus for practicing those methods. The present invention can also be embodied in the form of program code embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention. The present invention can also be embodied in the form of program code, for example, whether stored in a storage medium, loaded into and/or executed by a machine, or transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention. When implemented on a general-purpose processor, the program code segments combine with the processor to provide a unique device that operates analogously to specific logic circuits.

Although the invention has been described in terms of exemplary embodiments, it is not limited thereto. Rather, the appended claims should be construed broadly to include other variants and embodiments of the invention that may be made by those skilled in the art without departing from the scope and range of equivalents of the invention.

Claims

What is claimed: 1. A method of providing procurement services to a customer, comprising the steps of: (a) receiving from at least one user representing said customer a purchase order for a product in a product database containing a listing of a plurality of products available from at least one vendor and purchase terms for a sale of each of said products, said purchase order being according to said purchase terms in said product database associated with said product; (b) determining whether said purchase order falls within predefined order limits for said at least one user; and (c) providing said at least one user an opportunity to commit to purchase said product if said purchase order falls within said predefined order limits.

2. The method of claim 1 , wherein step (b) includes the step of identifying whether said purchase order exceeds a product quantity limit for said at least one user.

3. The method of claim 1 , wherein step (b) includes the step of identifying whether said purchase order fits within a budget limit.

4. The method of claim 1 , wherein step (b) includes the step of identifying whether said purchase order exceeds a price limit for said at least one user.

5. The method of claim 1, further comprising the step of requesting authorization from a supervisor identified for said at least one user if said purchase order does not fall within said predefined order limits.

6. The method of claim 1 , wherein step (a) further comprises the steps of identifying said at least one user as being within at least one predefined user group and providing said at least one user an opportunity to commit to purchase without additional approval only products in said product database that are assigned to said at least one predefined user group.

7. The method of claim 6, further comprising the steps of providing said at least one user an opportunity to request to purchase a product which is not assigned to said at least one user group, identifying whether said product is within said product database, identifying a user with authority to approve said request to purchase if said product is within said product database, and requesting approval for said request to purchase from said user with authority to approve said purchase.

8. The method of claim 1 , further comprising the steps of identifying from a vendor database whether a plurality of vendors are registered to supply said product, said vendor database including a listing of a plurality of vendors, each of said vendors registered to supply at least one of said products in said product database, and vendor performance data, and, if a plurality of vendors are register, comparing said plurality of vendors based at least in part on said performance data.

9. The method of claim 8, further comprising the step of recommending a vendor for said purchase order based at least in part on results of said comparison.

10. The method of claim 9, wherein said step of recommending includes the step of ranking said plurality of vendors.

11. The method of claim 1, further comprising the steps of receiving a request to purchase a product which is not listed in said product database and generating a request for proposal for said product.

12. The method of claim 11, wherein the step of generating a request for proposal includes the steps of identifying at least one product category which covers said product which is not listed in said product database, identifying from a vendor database at least one vendor which supplies products in said at least one product category, said vendor database including a listing of a plurality of vendors, each of said vendors registered to supply at least one of said products in said product database, and forwarding said request for proposal to said identified at least one vendor.

13. The method of claim 12, further comprising the step of receiving at least one bid from said identified at least one vendor, and providing said at least one user an opportunity to commit to purchase said product which is not listed in said product database according to purchase terms within said at least one bid.

14. The method of claim 13, wherein a plurality of bids are received and said vendor database includes vendor performance data, further comprising the step of comparing said bids based at least in part on said performance data.

15. The method of claim 13, wherein said vendor database includes vendor performance data, said method further comprising the steps of updating said performance data based at least in part on said at least one received bid.

16. The method of claim 13, wherein the step of providing said at least one user an opportunity to commit to purchase said product which is not listed in said product database includes the step of requesting approval for said purchase of a product not listed in said database from a user with authority to approve a purchase of a product which is not listed in said product database

17. The method of claim 1, further comprising the steps of receiving a commitment to purchase said product from said at least one user and forwarding said commitment to purchase to a vendor listed in said vendor database.

18. The method of claim 1, wherein said product is a temporary labor service, a vehicle lease, or a publishing product.

19. A computer-readable medium encoded with a computer program code for directing a processor to provide procurement services to a customer, the medium comprising: a first code segment for receiving from at least one user representing said customer a purchase order for a product in a product database containing a listing of a plurality of products available from at least one vendor and purchase terms for a sale of each of said products, said purchase order being according to said purchase terms in said product database associated with said product; a second code segment for determining whether said purchase order falls within predefined order limits for said at least one user; and a third code segment for providing said at least one user an opportunity to commit to purchase said product if said purchase order falls within said predefined order limits.

20. The computer readable medium of claim 19, wherein said second code segment identifies whether said purchase order exceeds a product quantity limit for said at least one user.

21. The computer readable medium of claim 19, wherein said second code segment identifies whether said purchase order fits within a budget limit.

22. The computer readable medium of claim 19, wherein said second code segment identifies whether said purchase order exceeds a price limit for said at least one user.

23. The computer readable medium of claim 19, further comprising a fourth code segment for requesting authorization from a supervisor identified for said at least one user if said purchase order does not fall within said predefined order limits.

24. The computer readable medium of claim 19, wherein said first code segment identifies said at least one user as being within at least one predefined user group and provides said at least one user an opportunity to commit to purchase without additional approval only products in said product database that are assigned to said at least one predefined user group.

25. The computer readable medium of claim 24, further comprising a fourth code segment for providing said at least one user an opportunity to request to purchase a product which is not assigned to said at least one user group, identifying whether said product is within said product database, identifying a user with authority to approve said request to purchase if said product is within said product database, and requesting approval for said request to purchase from said user with authority to approve said purchase.

26. The computer readable medium of claim 19, further comprising a fourth code segment for identifying from a vendor database whether a plurality of vendors are registered to supply said product, said vendor database including a listing of a plurality of vendors, each of said vendors registered to supply at least one of said products in said product database, and vendor performance data, and if a plurality of vendors are register, comparing said plurality of vendors based at least in part on said performance data.

27. The computer readable medium of claim 26, further comprising a fifth code segment for recommending a vendor for said purchase order based at least in part on results of said comparison.

28. The computer readable medium of claim 27, wherein said fifth code segment ranks said plurality of vendors.

29. The computer readable medium of claim 19, further comprising a fourth code segment for receiving a request to purchase a product which is not listed in said product database and generating a request for proposal for said product.

30. The computer readable medium of claim 29, wherein the fourth code segment identifies at least one product category which covers said product which is not listed in said product database, identifies from a vendor database at least one vendor which supplies products in said at least one product category, said vendor database including a listing of a plurality of vendors, each of said vendors registered to supply at least one of said products in said product database, and forwards said request for proposal to said identified at least one vendor.

31. The computer readable medium of claim 30, further comprising a fifth code segment for receiving at least one bid from said identified at least one vendor, and providing said at least one user an opportunity to commit to purchase said product which is not listed in said product database according to purchase terms within said at least one bid.

32. The computer readable medium of claim 31, wherein a plurality of bids are received and said vendor database includes vendor performance data, further comprising a sixth code segment for comparing said bids based at least in part on said performance data.

33. The computer readable medium of claim 31, wherein said vendor database includes vendor performance data, said medium further comprising a sixth code segment for the updating said performance data based at least in part on said at least one received bid.

34. The computer readable medium of claim 31, wherein said firth code segment requests approval for said purchase of a product not listed in said database from a user with authority to approve a purchase of a product which is not listed in said product database

35. The computer readable medium of claim 19, further comprising a fourth code segment for receiving a commitment to purchase said product from said at least one user and forwarding said commitment to purchase to a vendor listed in said vendor database.

36. The computer readable medium of claim 19, wherein said product is a temporary labor service, a vehicle lease, or a publishing product.

37. A computer data signal embodied in a carrier wave encoded with computer program code for directing a processor to provide procurement services to a customer, comprising: a first code segment for receiving from at least one user representing said customer a purchase order for a product in a product database containing a listing of a plurality of products available from at least one vendor and purchase terms for a sale of each of said products, said purchase order being according to said purchase terms in said product database associated with said product; a second code segment for determining whether said purchase order falls within predefined order limits for said at least one user; and a third code segment for providing said at least one user an opportunity to commit to purchase said product if said purchase order falls within said predefined order limits.

38. The computer data signal of claim 37, wherein said second code segment identifies whether said purchase order exceeds a product quantity limit for said at least one user.

39. The computer data signal of claim 37, wherein said second code segment identifies whether said purchase order fits within a budget limit.

40. The computer data signal of claim 37, wherein said second code segment identifies whether said purchase order exceeds a price limit for said at least one user.

41. The computer data signal of claim 37, further comprising a fourth code segment for requesting authorization from a supervisor identified for said at least one user if said purchase order does not fall within said predefined order limits.

42. The computer data signal of claim 37, wherein said first code segment identifies said at least one user as being within at least one predefined user group and provides said at least one user an opportunity to commit to purchase without additional approval only products in said product database that are assigned to said at least one predefined user group.

43. The computer data signal of claim 42, further comprising a fourth code segment for providing said at least one user an opportunity to request to purchase a product which is not assigned to said at least one user group, identifying whether said product is within said product database, identifying a user with authority to approve said request to purchase if said product is within said product database, and requesting approval for said request to purchase from said user with authority to approve said purchase.

44. The computer data signal of claim 37, further comprising a fourth code segment for identifying from a vendor database whether a plurality of vendors are registered to supply said product, said vendor database including a listing of a plurality of vendors, each of said vendors registered to supply at least one of said products in said product database, and vendor performance data, and if a plurality of vendors are register, comparing said plurality of vendors based at least in part on said performance data.

45. The computer data signal of claim 44, further comprising a fifth code segment for recommending a vendor for said purchase order based at least in part on results of said comparison.

46. The computer data signal of claim 45 , wherein said fifth code segment ranks said plurality of vendors.

47. The computer data signal of claim 37, further comprising a fourth code segment for receiving a request to purchase a product which is not listed in said product database and generating a request for proposal for said product.

48. The computer data signal of claim 47, wherein the fourth code segment identifies at least one product category which covers said product which is not listed in said product database, identifies from a vendor database at least one vendor which supplies products in said at least one product category, said vendor database including a listing of a plurality of vendors, each of said vendors registered to supply at least one of said products in said product database, and forwards said request for proposal to said identified at least one vendor.

49. The computer data signal of claim 48 , further comprising a fifth code segment for receiving at least one bid from said identified at least one vendor, and providing said at least one user an opportunity to commit to purchase said product which is not listed in said product database according to purchase terms within said at least one bid.

50. The computer data signal of claim 49, wherein a plurality of bids are received and said vendor database includes vendor performance data, further comprising a sixth code segment for comparing said bids based at least in part on said performance data.

51. The computer data signal of claim 49, wherein said vendor database includes vendor performance data, said medium further comprising a sixth code segment for the updating said performance data based at least in part on said at least one received bid.

52. The computer data signal of claim 49, wherein said firth code segment requests approval for said purchase of a product not listed in said database from a user with authority to approve a purchase of a product which is not listed in said product database

53. The computer data signal of claim 37, further comprising a fourth code segment for receiving a commitment to purchase said product from said at least one user and forwarding said commitment to purchase to a vendor listed in said vendor database.

54. The computer data signal of claim 37, wherein said product is a temporary labor service, a vehicle lease, or a publishing product.

55. A procurement system, comprising: a product database containing a listing of a plurality of products available from at least one vendor and purchase terms for a sale of each of said products; and at least one server, said at least one server comprising: means for receiving from at least one user representing said customer and using a user terminal a purchase order for a product in said product database according to said purchase terms in said product database associated with said product; means for determining whether said purchase order falls within predefined order limits for said at least one user; and means for providing said at least one user an opportunity to commit to purchase said product if said purchase order falls within said predefined order limits; and at least one user terminal for communicating with said at least one server through a network.

56. The system of claim 55, wherein said server further includes means for identifying whether said purchase order exceeds a product quantity limit for said at least one user.

57. The system of claim 55, wherein said server further includes means for identifying whether said purchase order fits within a budget limit.

58. The system of claim claim 55, wherein said server further includes means for identifying whether said purchase order exceeds a price limit for said at least one user.

59. The system of claim 55, wherein said server further includes means forrequesting authorization from a supervisor identified for said at least one user if said purchase order does not fall within said predefined order limits.

60. The system of claim 55, wherein said server further includes means for identifying said at least one user as being within at least one predefined user group and providing said at least one user an opportunity to commit to purchase without additional approval only products in said product database that are assigned to said at least one predefined user group.

61. The system of claim 60, wherein said server further includes means for providing said at least one user an opportunity to request to purchase a product which is not assigned to said at least one user group, identifying whether said product is within said product database, identifying a user with authority to approve said request to purchase if said product is within said product database, and requesting approval for said request to purchase from said user with authority to approve said purchase.

62. The system of claim 55, further comprising a vendor database including a listing of a plurality of vendors, each of said vendors registered to supply at least one of said products in said product database, and vendor performance data.

63. The system of claim 62, wherein said server further comprises means for identifying from said vendor database whether a plurality of vendors are registered to supply said product, and means for comparing a plurality of vendors based at least in part on said performance data if a plurality of vendors are register.

64. The system of claim 63, wherein said server further comprises means for recommending a vendor for said purchase order based at least in part on results of said comparison.

65. The system of claim 64, wherein said server further comprises means for ranking said plurality of vendors.

66. The system of claim 55, wherein said server further comprises means for receiving a request to purchase a product which is not listed in said product database and generating a request for proposal for said product.

67. The system of claim 66, further comprising a vendor database including a listing of a plurality of vendors, each of said vendors registered to supply at least one of said products in said product database, wherein said server further comprises means for identifying at least one product category which covers said product which is not listed in said product database, identifying from said vendor database at least one vendor which supplies products in said at least one product category and means for forwarding said request for proposal to said identified at least one vendor.

68. The system of claim 67, wherein said server further comprises means for receiving at least one bid from said identified at least one vendor, and providing said at least one user an opportunity to commit to purchase said product which is not listed in said product database according to purchase terms within said at least one bid.

69. The system of claim 68, wherein a plurality of bids are received and said vendor database includes vendor performance data, said server further comprising means for comparing said bids based at least in part on said performance data.

70. The system of claim claim 68, wherein said vendor database includes vendor performance data and said server further comprises means for updating said performance data based at least in part on said at least one received bid.

71. The system of claim 68, wherein said server further comprises means for requesting approval for said purchase of a product not listed in said database from a user with authority to approve a purchase of a product which is not listed in said product database

72. The system of claim 55, wherein said server further comprises means for receiving a commitment to purchase said product from said at least one user and forwarding said commitment to purchase to a vendor listed in said vendor database.

73. The system of claim 55, wherein said product is a temporary labor service, a vehicle lease, or a publishing product.