DESCRIPTION
Network-Based Procurement System and Method
This application claims priority to provisional application Serial No. 60/276,845, filed March 16, 2001, which is hereby incorporated by reference.
BACKGROUND OF THE INVENTION
Organizations, corporations, partnerships, and other entities (hereinafter referred to as "purchasing entities") generally require a large variety of products and items to operate their businesses. A purchasing entity commonly purchases products at the outset or creation of the entity, and replenishes the products as the supply of products becomes low.
There are various types of purchasing entities, each having its own set of products and items according to its own schedule. Restaurants, for example, purchase food, recipe ingredients, napkins, disposable place mats, and other items on a regular basis. Hospitals and doctors purchase disposable medical products, medicine, and other items on a regular basis. Schools, universities, and bookstores purchase a large number of books and school supplies throughout the year, especially at times preceding the beginning of a new semester, trimester, etc. Governmental agencies and political organizations purchase a large variety of products throughout the year, particularly during election times and political events.
In order to run their businesses successfully, purchasing entities must keep track of the supply of products at their disposal, and when the supply of certain products runs low, replenish those products before they run out. To accomplish this objective,
purchasing entities must find suppliers to provide and sell the products required for running their businesses.
The processes of finding suppliers and negotiating product prices with suppliers are generally very time- consuming. As a result, many purchasing entities do not "shop" extensively to find the most reliable supplier and/or the supplier that provides the best product prices. Thus, purchasing entities often end up paying above market value for their products.
Problems may also arise for a purchasing entity when a supplier raises its prices, or when a supplier goes out of business. In these situations, the purchasing entity may be forced to find a new supplier, and negotiate product prices with the new supplier. Moreover, if time is short, the purchasing entity may be forced to pay above market value due to the limited time available to seek out bids from multiple suppliers.
Again, these procurement processes are generally time-consuming, and the lack of available products may lead to a slowing down or halting of the purchasing entity's business until a new supplier can be found. Such a situation may give new suppliers substantial leverage over the purchasing entity during product price negotiations, since the new suppliers will likely be aware of the purchasing entity's need to find a new supplier as quickly as possible.
SUMMARY OF THE INVENTION
The present invention is directed to a procurement
(or purchasing) system and method that creates a virtual supply chain to fill purchase orders placed by customers for products and other items. A preferred system
aggregates and directs customer purchase orders through transaction sources, such as functional front-end systems (e.g., a web browser, customer software, etc.), to suppliers who sell the desired products.
Applying a common coding structure and language, purchase orders are transferred via a network, such as the Internet, into a customized server-side central database of the procurement system. At a point of sale
(POS), a customer database is preferably provided for a customer, by which to capture data for a product and to enable the flow of a purchase order through a transaction source and into the procurement system. The purchase order is then aggregated with other customer purchase orders within the procurement system and transmitted to one or more suppliers so that the suppliers may fill the order.
An exemplary method of procuring products may include the following steps:
(1) a customer selects items for purchase from an electronic catalogue and places a purchase order;
(2) a managing entity aggregates the purchase order with a plurality of purchase orders from other customers in the electronic procurement system;
(3) the managing entity transmits the aggregated purchase order to one or more selected suppliers via the electronic procurement system;
(4) the supplier processes the aggregated purchase order and delivers the selected items, along with an invoice for the items, to the customer;
(5) the customer approves and/or signs the invoice, and then returns the invoice to the supplier, after which it is forwarded to the managing entity;
(6) the managing entity pays the supplier for the items indicated on the invoice;
(7) the managing entity bills the customer for the items indicated on the invoice; and
(8) the customer pays the managing entity for the items indicated on the invoice.
BRIEF DESCRIPTION OF THE DRAWINGS
Fig. 1 is a system overview diagram according to a preferred embodiment.
Fig. 2 is a flow diagram outlining a procurement process according to a preferred embodiment.
Fig. 3 is a diagram illustrating a price negotiation process according to a preferred embodiment.
Fig. 4 is a diagram of a sample customer database in communication with a server database.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
Preferred embodiments will now be described with reference to the drawings. To facilitate description, any reference numeral representing an element in one figure will represent the same element in any other figure.
Fig. 1 is an overview of an electronic purchasing system 10 according to a preferred embodiment. The electronic purchasing system 10 preferably employs a
common coding structure, such as XML (extensible markup language) or other suitable language, to transfer customer purchase orders to suppliers via a network 15, such as the Internet. The term "suppliers," as used herein, is understood to include manufacturers and/or other entities involved in producing products available for purchase by customers.
The software utilized in the electronic purchasing system 10 is preferably hosted on one or more servers 20 at an application service provider (ASP) , which may be accessed by customers via a web browser, customer software, or other suitable medium. Alternatively, the electronic purchasing system 10 may facilitate transmission of purchase orders via FTP (file transfer protocol) connectivity, direct connection, and/or any other suitable transmission standard.
The ASP environment is preferred because it provides customers with virtually unlimited access to the electronic management system 10 at all times. By using an ASP, no WAN (wide area network) or LAN (local area network) is required, and capital expenditure is minimized. The ASP environment also provides for efficient data updates via a web browser, since only data reflecting changes must be downloaded whenever a web page is "refreshed."
Customers may access the network 15 via a handheld computer 25, a workstation 30 in conjunction with a server 35, a laptop computer 40, an IBM compatible computer 45, or any other suitable computer system. Alternatively, customers may access the system server 20 via a phone line 50 using a telephone 55 or fax machine.
To facilitate the phone line 50 method of communication, a "call center" 60 is preferably provided to which customers may call or fax order requirements. The call center staff may then enter the purchase requirements into the electronic management system 10. The call center offers a method of access to the electronic management system 10 that is well suited to customers that do not have technology capable of communicating with the system 10 via other methods.
The one or more system servers 20 preferably house a central database 65. The central database 65 preferably contains product files 70, purchase order files 75, payment files 80, reporting and billing files 85, analysis and benchmarking modules 90, and other information relevant to the electronic purchasing process, as further described below.
The central database 65 preferably transfers data to and from one or more customer and/or supplier databases containing information specific to each customer and/or supplier that utilizes the electronic purchasing system 10. The specific information is preferably established and entered into the system when a customer or supplier opens an account in the electronic purchasing system 10 via a managing entity.
The specific customer or supplier information may include common product requirements, quantity requirements, and price requirements of a given customer, as well as products offered for sale, product prices, and product inventory status of a given supplier. For example, a customer database may include all of the products that a customer might purchase for use in its business, as well as the individual components that make
up each product, and the prices that the customer is willing to pay for the products.
The central database 65 is preferably automatically updateable by each of the customer databases. All purchase order movements in the customer system are preferably mirrored in the central server system. Thus, customer databases may periodically update the central database 65 on purchase order movements (e.g., status changes) . In turn, the central database 65 preferably updates the customer databases, as appropriate, on product, supplier, and payment status changes, including available products and suppliers.
Multiple customer-side terminals (e.g., customer computers running customer software or otherwise connected via a network, etc.) may be attributed to a single customer. Thus, the customer side may include a network of terminals that output purchase orders for a single customer. In such a case, the customer may choose to be billed separately for purchase orders generated from each individual site, or may choose to receive a single consolidated bill for purchase orders from all sites combined, as further described below.
Each customer database preferably includes a template or menu including a list of products specifically tailored to meet the requirements of the customer associated therewith. Thus, the customer may select products from a pre-established menu that includes only products relevant to the customer's business, which may significantly streamline the product selection process.
The use of a customer-specific menu also allows a customer to order a product made up of several individual
components, and the electronic purchasing system 10 may then aggregate the individual components required for preparing or assembling the final product into a purchase order. Accordingly, the customer does not have to order each individual component, but may instead place an order for the final product only, and the electronic purchasing system 10 may then assemble a proper purchase order.
For example, a restaurant manager may order a specific meal from a pre-established customer menu, and the resultant purchase order would reflect an aggregation of the ingredients required for preparing the meal. Accordingly, the customer does not have to order all of the individual ingredients of the meal, but only has to order the meal itself. The electronic purchasing system 10 may then aggregate the order volume of a given ingredient from several customers in order to negotiate for the best price and quality available for that ingredient from suppliers, as further described below.
In one embodiment, the electronic purchasing system 10 may combine a common ingredient from multiple meal orders, generated from one or more customer locations, into an aggregated order for that ingredient. For example, if tomatoes are used in four different meals at a first restaurant, and six different meals at a second restaurant, a quantity of tomatoes required for all ten meals at the two restaurants may be combined into a single aggregated order, which may then be sent to a tomato supplier. This example may be scaled up to any number of customers ordering a common ingredient, such that all of the orders for the common ingredient over a predetermined time period may be combined into a single aggregated order.
In an alternative embodiment, the central database 65 may be integrated with the customer and supplier databases into an integrated purchasing system. Such an integrated system is preferably fully enabled in that it integrates purchasing, manufacturing, supplying, financing, and other functions into a unitary system. Accordingly, data may be efficiently transferred within the integrated system, since the data does not have to be transferred to and from a remote server-based database.
Fig. 2 is a flow diagram outlining a product purchasing process utilizing the electronic purchasing system 10 according to a preferred embodiment. At step 100, a customer searches for and selects one or more products from an electronic catalogue or product file located within the electronic purchasing system 10. Access to the electronic catalogue is preferably attained via a web browser, or via any of the other means described above.
Products are preferably selected using order templates or menus, which include products that the specific customer uses in its business, as described above. While each product listed on a menu is preferably identified by a single descriptor (e.g., "orange"), the system itself may employ multiple descriptors for any given item.
For example, if the system uses five suppliers that provide syringes, the central database 65 may then combine those suppliers into a single "syringe" category. Then, when a customer places an order for syringes, the electronic purchasing system 10 may rationalize the applicable data and select the most appropriate of the five suppliers to fill the purchase order. The selection may be based on the geographic location of the customer
in relation to the available suppliers, the types of syringes that each supplier provides, the size of the supplier's inventory, and/or other suitable criteria.
If a product comprises several individual elements or components, the electronic purchasing system 10 preferably retrieves the individual elements used to prepare or assemble the product, and places those elements into a purchase order. Alternatively, products selected for inclusion on a purchase order may be placed directly onto a purchase order template, as opposed to using a customer-specific menu.
At step 110, product requirements are finalized into a purchase order within the electronic purchasing system 10. The purchase order is preferably the result of customer requirements, which are generally aggregated into a sales order. The sales order is preferably reproduced into a purchase order, which includes an aggregation of ingredient requirements for the customer.
Each purchase order typically includes the products required, quantity required, unit of measure, agreed price, customer name, customer delivery address and contact, purchase order number, supplier product code, and contact details for the managing entity of the electronic purchasing system 10.
At step 120, the finalized purchase order is sent to and retained in the electronic purchasing system 10. If the customer uses a non-web-based access method, such as the phone connection 50 illustrated in Fig. 1, the finalized purchase order is entered into the electronic purchasing system 10 by a staff member working at the call center 60.
Once the purchase order is stored in the central database 65, it becomes a file having a "status" associated therewith. The status preferably reflects the pending nature of the purchase order. For example, the status may indicate that the purchase order has not yet been responded to with a delivery of goods, and thereafter, that an invoice from a supplier has been received, as further described below.
The electronic purchasing system 10 preferably may receive multiple purchase orders from multiple customers at the same time. Specifically, the electronic purchasing system 10 preferably provides the bandwidth, as well as the processing and storage capabilities, necessary to handle the purchasing needs of thousands of customers at any given time. Common ingredients or elements from the plurality of customer orders may then be aggregated into individual orders, which may then be sent to one or more suppliers, as explained above.
At step 130, the finalized purchase order is sent to one or more suppliers. The purchase order preferably includes a field value indicating that the managing entity owns the purchase order, and is therefore responsible for directly paying suppliers.
By virtue of the managing entity owning the purchase order, and therefore not having to use an outside source to provide payment to suppliers, several advantages are realized. Specifically, the managing entity is able to remain unbiased with respect to negotiations with suppliers and across industries. Accordingly, the electronic management system 10 is able to aggregate purchaser orders over a varied customer base, and is able to negotiate with and utilize suppliers across all
industries without favoring any particular customer or supplier.
The ability to aggregate in this manner provides leverage for the managing entity when negotiating supplier terms, which results in the managing entity being able to obtain the best product prices available for its customers. Additionally, the managing entity has control over cash flow within the procurement system because it is a fully functional third party entity that owns the debt owed to suppliers, and it may therefore regulate billing and payment procedures.
The purchase order is preferably sent via electronic mail, electronic facsimile (e.g., Winfax software), direct electronic connection, or other suitable delivery method. The delivery method selected is primarily dependent on the supplier' s ability to receive purchase orders through the various means described.
At step 140, the supplier receives the purchase order and preferably processes the order under an account that recognizes that the goods will be delivered to the customer, and that the managing entity will be billed. The supplier preferably uses software that allows the supplier to receive and automatically process purchase orders electronically, i.e., with minimal or no human intervention.
At step 150, the supplier arranges for physical delivery of the products indicated on the purchase order to the customer via the supplier's own delivery vehicle, courier, postal service, or other suitable delivery means. The supplier preferably includes an invoice or receipt notice, which includes the purchasing system file
number (preferably embedded in the purchase order file number), with the products.
At step 160, the customer physically receives the products and checks to ensure that they conform to the purchase order, preferably from its customer-side interface. If the products received match those listed on the purchase order, the customer preferably approves and/or signs the invoice (or delivery note) , and may further update the order status to "received," "delivery completed," or other similar nomenclature, in the customer database. Alternatively, the managing entity may update the order status upon receipt of the approved invoice, as further described below.
If, on the other hand, the goods received do not exactly conform to the purchase order, the customer may decide to keep or reject the goods. If the customer decides to accept the goods, the customer may update the status of the purchase order in the customer database to reflect receipt of the goods, and may also modify the purchase order to reflect the goods actually received versus the goods requested in the purchase order. Thus, the customer may electronically make adjustments to the original purchase order file when necessary.
If the customer decides to reject the goods, the customer does not approve or sign the delivery note or invoice. Additionally, the customer does not change the status of the purchase order in the customer database to
"delivery completed" status.
In such a case, the goods are preferably returned to the seller, and the purchaser, seller, and/or the managing entity may attempt to come to an agreement on how the customer may acquire conforming goods. If an
agreement is reached with the same supplier, the existing purchase order may be modified to reflect any new agreed upon terms and/or dates, or a new purchase order may be entered into the electronic purchasing system 10 (in which case the existing purchase order is cancelled from the system) .
If, on the other hand, an agreement cannot be reached, the original purchase order is cancelled from the system, and the customer may attempt to obtain goods from a different supplier, either through the electronic purchasing system 10, or via other means.
At step 170, in situations where the delivery is accepted by the customer, a copy of the approved and/or signed invoice (or delivery note) is returned to the supplier as proof of receipt of the goods. The supplier may then confirm/process the signed invoice in the supplier' s accounting system, after which the supplier preferably provides the invoice to the managing entity as proof of delivery.
At step 180, the managing entity receives the invoice, and any appropriate supporting documentation, to satisfy itself that the goods have been sent by the supplier and received in good order by the customer. The actual invoice may be physically delivered, or a copy of the invoice may be mailed electronically, to the managing entity.
At step 190, supplier invoices received by the managing entity are preferably entered into the central database 65 of the electronic purchasing system 10. The managing entity preferably checks the receipt information to ensure that the physical supplier invoice conforms to the purchase order, and then updates the purchase order
status to "invoice posted," or other similar nomenclature, in the electronic purchasing system 10. If there are any differences between the supplier invoice and the original purchase order (including the agreed supplier prices) , the central database 65 generates a "supplier credit adjustment" to be processed in the system to reflect the discrepancy.
At step 210, the central database 65 preferably monitors the status of all purchase order files for completeness and enables full management control to be applied to each step of the procurement process. The central database 65 preferably monitors product files, purchase files, billing and payment files, and any other suitable files related to the product procurement process.
At step 220, the managing entity preferably authorizes payment, reflecting any supplier credit adjustments (as explained at step 190) , to the supplier for goods delivered. The managing entity may also authorize billing of the customer for the goods delivered, although the customer is preferably not actually billed at this time. Instead, the electronic purchasing system 10 preferably aggregates purchases by the customer over a predetermined billing cycle, as further explained below, and bills the customer accordingly. The central database 65 is also preferably updated to reflect this payment/billing information.
At step 230, the customer's database is preferably updated to reflect that the purchase order is authorized for payment and invoicing. This step is preferably part of an automatic background process in which the central database 65 updates the customer database to reflect purchase order status changes.
The customer may preferably view the purchase order, as well as the information on the invoice (including an invoice number) , and be made aware that the invoice is being paid by the managing entity (via the electronic purchasing system 10) . The customer may also check to see when' the customer itself will be charged for the invoice payment, which will typically be on its next billing cycle, as explained below at steps 250 and 260.
At step 240, the supplier is preferably paid by the managing entity as per agreed credit terms between the supplier and the managing entity. Each purchase order is preferably paid via the electronic purchasing system 10 when an invoice is received that matches with the purchase order and reflects delivery of the goods to the customer. Payment is preferably achieved through electronic funds transfer (EFT) , or other suitable method.
In an alternative embodiment, payment terms and pricing may be pre-agreed between the managing entity and its 'suppliers and customers.. In such a case, credit terms and payment are based on the receipt information located within the electronic management system 10 itself. Accordingly, the invoice from the supplier is merely a control mechanism that may be used to validate the pre-agreed price.
At step 250, billing cycles are preferably agreed for each customer, e.g., biweekly or monthly. The managing entity may impose a uniform billing cycle for each customer, or may give one or more customers the option to pay according to a desired payment schedule.
At step 260, the billing applied to each customer is preferably an aggregate (consolidated or master invoice)
of all purchases received for that customer within the predetermined billing period. Depending on customer requirements, the billing may be applied to individual customer sites, or may be aggregated to multiple sites operated by the same customer. This billing process is preferably automated in the central database 65.
At step 270, depending on customer requirements, customers may also be provided with supporting financial information that preferably matches the customer' s General Ledger (GL) coding structure. In such a case, the customer's consolidated invoice may include extra pages detailing all purchase orders filled by a given supplier.
At step 280, the customer's consolidated invoice is preferably sent electronically (e.g., via email) to the customer.
At step 290, the customer preferably pays the invoice within pre-agreed payment terms established with the managing entity (preferably via the electronic purchasing system 10) .
A procurement negotiation process according to a preferred embodiment is outlined at steps 300-330, a variation of which is produced in Fig. 3. At step 300/300' , purchasing data analysis is preferably performed periodically to obtain key usage information about customers and suppliers. Such information may include individual products consumed, consumption of product groups or families, product duplications, supplier pricing schemes, and any other suitable purchasing data.
This information may then form the basis of supplier negotiations where negotiations are undertaken by the managing entity on behalf of the customer, or on behalf of an aggregate of the total customer base of the managing entity.
At steps 310-320/310' -320' , the managing entity preferably negotiates the best price available with suppliers for customer-specific products and/or for products across its total supply base. Data is preferably continually collected and analyzed as part of the procurement process on all products for all suppliers .
The procurement negotiation process preferably runs constantly in parallel to the distribution and purchasing processes. When a new customer subscribes to the electronic purchasing system 10, the customer's specific product requirements are collected and stored in the central database 65. Additionally, the central database 65 is preferably constantly updated with the results of the procurement negotiation process.
The electronic purchasing system 10 then sources the appropriate one or more suppliers for the product requirements of the customer, and through a tender process, negotiates the best price for those products.
At step 330, the final negotiated and authorized supplier/product prices are preferably entered into a product catalogue, or central product file, in the central database 65. These prices are preferably continually analyzed to ensure that the best price available is achieved across the customer base of the electronic purchasing system.
At step 340, the central product file may be viewed by customers, which allows a significant opportunity for the customers to obtain information-rich data about suppliers, available products, product prices, and other relevant purchasing information.
At step 350, customers are able to use information from the central product file to aid in strategic business planning. For example, a customer may use information in the central product file to plan a yearly budget, to determine quantities and types of products that the customer will purchase, and to determine which suppliers are able to meet the customer's needs.
Additionally, purchasing reports may be provided to customers and/or to the managing entity to aid in purchasing analysis and observation of purchasing trends in the electronic management system 10. Such reports may relate to spend in purchasing, historical analysis, benchmarking, recommendations, and other suitable purchasing data.
To facilitate reporting, the electronic purchasing system 10 may be equipped with software for producing the reports in the central database 65. Alternatively, an independent reporting entity may be employed to provide the purchasing reports to the central database 65, or to customers and/or the managing entity directly.
Reports may also be generated to aid in ensuring an efficient purchasing operation. For example, "exception reports" detailing non-compliance to agreements by customers and/or suppliers may be generated by the electronic management system 10 or by an independent reporting entity.
These reports may then be used to make customers and suppliers aware of non-conforming parties, and may further provide the basis for excluding a non-conforming party from the electronic management system 10. Guidelines for excluding a non-conforming party may be established by the managing entity.
Fig. 4 is a flow diagram of a sample customer database 400 for a customer, such as a restaurant, in communication with a central server database 410, referred to as "Linkhand." The customer begins production 420 of a purchase order by accessing menus 430 that include products specific to the customer' s business .
The customer may first select meal components 440 from the pre-established menus 430. The customer may then select pre-established recipes 450 and/or ingredients 460 for preparing the meal components, or may allow the system to select appropriate default ingredients from the ingredient database 460.
The selected ingredients are then aggregated into a purchase order, and may further be combined with common ingredient orders from one or more other customers, as described above. The aggregated purchase order is then sent to a supplier 470, who preferably fills the purchase order via the processes described above. The managing entity may then pay the supplier for the ingredients, and bill the customer 480 accordingly. Every step of the purchase process is preferably updated in the central database 410 throughout the procurement process.
The electronic purchasing system 10 and product procurement method described herein provide several
benefits. For example, the electronic purchasing system may provide one or more of the following benefits:
providing a product file or catalogue from which customers may select their agreed product range;
aggregating purchasing data and providing an online mechanism to place purchase orders for items;
arranging with suppliers to deliver goods directly to the customer;
aggregating all billing to the customer into a simple invoice per billing cycle;
providing a full integration of systems, e.g., point of sale, finance, customer relationship management, enterprise resource planning, procurement, etc.;
providing a full financial breakdown of purchases consistent with a customer's own GL structure;
vesting the liability for the customer's debt in the managing entity, which enables the system to aggregate and consolidate vast numbers of invoices and to produce multi-level invoices to the customer and the relevant comparable payments and ancillary information to a vast number of suppliers;
providing cost analysis and cost referencing (i.e., data management) ;
providing contract management (open/closed tenders, direct negotiations, pricing compliance) ;
providing benchmarking (external & internal) ;
providing record retention (supplier and customer document management) ;
providing advanced business unit reporting (tailored management reports to customers' needs) ;
providing monitoring compliance and exception reporting;
providing supplier management (i.e., relationship management) ;
providing vast scalability potential, particularly in the ASP environment; and
acting as an intermediary without bias to any particular player in the supply chain.
The electronic management system 10 may also provide customers with one or more of the following benefits:
the potential to leverage their purchasing power with other customers of the managing entity, therefore obtaining the best price for the best product (leveraged supplier negotiations through group purchasing) ;
the ability to capture complete purchase data and allow range rationalization, product standardization, and access to data they did not previously have;
the ability to use the managing entity' s leveraged purchasing power over its total customer base to negotiate with suppliers; and
— increased exposure to a supply base.
Thus, while embodiments and applications of the present invention have been shown and described, it would
be apparent to one skilled in the art that other modifications are possible without departing from the inventive concepts herein. The invention, therefore, is not to be restricted except in the spirit of the claims that follow.