WO2002086779A1 - Network-based procurement system and method - Google Patents

Network-based procurement system and method Download PDF

Info

Publication number
WO2002086779A1
WO2002086779A1 PCT/IB2002/002430 IB0202430W WO02086779A1 WO 2002086779 A1 WO2002086779 A1 WO 2002086779A1 IB 0202430 W IB0202430 W IB 0202430W WO 02086779 A1 WO02086779 A1 WO 02086779A1
Authority
WO
WIPO (PCT)
Prior art keywords
invoice
supplier
items
purchaser
customer
Prior art date
Application number
PCT/IB2002/002430
Other languages
French (fr)
Inventor
Paul G. O'shanassy
James X. Chen
Lee A. Clough
Stuart M. V. Simpson
Glen M. Kyne
Original Assignee
Sagacious Procurement Pty Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sagacious Procurement Pty Limited filed Critical Sagacious Procurement Pty Limited
Publication of WO2002086779A1 publication Critical patent/WO2002086779A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/08Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/087Inventory or stock management, e.g. order filling, procurement or balancing against orders
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions

Definitions

  • a purchasing entity generally requires 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.
  • 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.
  • purchasing entities 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 present invention is directed to a procurement
  • 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.
  • transaction sources such as functional front-end systems (e.g., a web browser, customer software, etc.), to suppliers who sell the desired products.
  • purchase orders are transferred via a network, such as the Internet, into a customized server-side central database of the procurement system.
  • a network such as the Internet
  • POS 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:
  • a managing entity aggregates the purchase order with a plurality of purchase orders from other customers in the electronic procurement system
  • the managing entity transmits the aggregated purchase order to one or more selected suppliers via the electronic procurement system
  • 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;
  • 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.
  • 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.
  • a common coding structure such as XML (extensible markup language) or other suitable language
  • suppliers 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.
  • ASP application service provider
  • 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.
  • FTP file transfer protocol
  • 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.
  • customers may access the system server 20 via a phone line 50 using a telephone 55 or fax machine.
  • 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.
  • 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.
  • customer-side terminals e.g., customer computers running customer software or otherwise connected via a network, etc.
  • the customer side may include a network of terminals that output purchase orders for a single customer.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • descriptor e.g., "orange”
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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) .
  • a copy of the approved and/or signed invoice 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • EFT electronic funds transfer
  • payment terms and pricing may be pre-agreed between the managing entity and its ' suppliers and customers.
  • 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.
  • 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.
  • 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.
  • 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.
  • customers may also be provided with supporting financial information that preferably matches the customer' s General Ledger (GL) coding structure.
  • GL General Ledger
  • the customer's consolidated invoice may include extra pages detailing all purchase orders filled by a given supplier.
  • the customer's consolidated invoice is preferably sent electronically (e.g., via email) to the customer.
  • 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 is outlined at steps 300-330, a variation of which is produced in Fig. 3.
  • 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.
  • 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.
  • the customer's specific product requirements are collected and stored in the central database 65.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the electronic purchasing system 10 may be equipped with software for producing the reports in the central database 65.
  • 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.
  • the electronic purchasing system may provide one or more of the following benefits:
  • supplier management i.e., relationship management
  • the electronic management system 10 may also provide customers with one or more of the following benefits:

Abstract

A procurement system and method that provides a virtual supply chain to fill purchase orders placed by customers for products and other items. The system aggregates and directs purchase orders through transaction sources, such as functional front-end systems (e.g., web browsers), to suppliers who sell the desired products. Applying a common coding structure, purchase orders are transferred via a network, such as the Internet, into a customized server-side central database procurement system. At the point of sale, a customer database is provided by which a customer may capture data for a product and which enables the flow of a purchase order through a transaction source into procurement system. The purchase order is then transmitted to a supplier for filling the order. Once the supplier delivers the goods to the customer, a managing entity pays the supplier and bills the customer. The customer then pays the managing entity.

Description

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.

Claims

Claims :
1. A method of electronically purchasing products by a purchaser, comprising the steps of: selecting items for purchase from a product file;
placing a purchase order for the items selected in an electronic purchasing system maintained by a managing entity;
aggregating the purchase order with purchase orders from one or more other purchasers to form an aggregated purchase order;
transmitting the aggregated purchase order to a supplier via the electronic purchasing system;
processing the purchase order by the supplier;
delivering the items selected, along with an invoice corresponding to the items selected, to the purchaser;
paying the supplier, by the managing entity, for the items indicated on the invoice;
billing the purchaser for the items indicated on the invoice; and
paying the managing entity, by the purchaser, for the items indicated on the invoice.
2. A method according to claim 1 further comprising the step of entering into the electronic purchasing system a confirmation from the purchaser indicating that the items were received by the purchaser.
3. A method according to claim 1 further comprising the steps of: approving the invoice by the purchaser;
sending the signed invoice to the supplier; and
forwarding the signed invoice to the managing entity, before the managing entity pays the supplier.
4. A method according to claim 3 further comprising the step of updating the purchase order to "invoice posted" status in the electronic purchasing system after the approved invoice is forwarded to the managing entity.
5. A method according to claim 3 further comprising the step of modifying the invoice by the purchaser, before signing the invoice, if the items delivered to the purchaser do not correspond to the selected items.
6. A method according to claim 1 further comprising the step of negotiating price terms from suppliers based on aggregated order quantities from multiple purchasers.
7. A method according to claim 1 wherein the step of transmitting the purchase order to the supplier comprises transmitting the purchase order via electronic mail .
8. A method according to claim 1 wherein the step of transmitting the purchase order to the supplier comprises transmitting the purchase order via an electronic fax.
9. A method according to claim 1 wherein the step of billing the purchaser comprises aggregating all invoices of the purchaser over a predetermined billing period into a consolidated invoice and billing the purchaser for the items indicated on the consolidated invoice.
10. A method according to claim 1 wherein the step of selecting items for purchase comprises selecting items from an electronic menu including products specifically tailored to meet requirements of the purchaser.
11. A method according to claim 1 wherein the electronic purchasing system is server-based and accessible via the Internet.
12. A method of electronically procuring products by a purchaser, via an electronic purchasing system maintained by a managing entity, comprising the steps of: selecting items for purchase from a product file located in the electronic purchasing system; placing a purchase order for the items selected in the electronic purchasing system;
aggregating the purchase order- with purchase orders from a plurality of other purchasers to form an aggregated purchase order;
selecting a seller to fill the aggregated purchase order;
transmitting the aggregated purchase order to the seller via the electronic purchasing system;
processing the purchase order by the seller;
delivering the selected items, along with an invoice corresponding to the selected items, to the purchaser;
approving the invoice by the purchaser;
forwarding the approved invoice to the managing entity;
paying the seller, by the managing entity, for the items indicated on the invoice;
aggregating multiple invoices of the purchaser over a predetermined billing period into a consolidated invoice;
billing the purchaser for the items indicated on the consolidated invoice; and paying the managing entity, by the purchaser, for the items indicated on the consolidated invoice.
13. A method according to claim 12 further comprising the step of updating the purchase order to "received" status in the electronic purchasing system after the items are delivered to the purchaser.
14. A method according to claim 12 wherein the electronic purchasing system is server-based and accessible via the Internet.
15. A method according to claim 12 further comprising the step of sending the approved invoice to the seller, wherein the step of forwarding the approved invoice to the managing entity is performed by the seller.
16. A method according to claim 12 further comprising the step of modifying the invoice by the purchaser, before approving the invoice, if the items delivered to the purchaser do not correspond to the selected items.
17. A method according to claim 12 further comprising the step of negotiating price terms from suppliers based on aggregated order quantities from multiple purchasers.
18. An electronic purchasing system, comprising: a customer database including a menu, the menu including a list of products specifically tailored to meet requirements of a customer associated with the customer database such that the customer may select products for purchase from the menu;
a central database in communication with the customer database for aggregating purchase orders from the customer with purchase orders from other customers, and for processing the aggregated purchase orders; and
a supplier database in communication with the central database for receiving the aggregated purchase orders from the central database.
19. The electronic purchasing system of claim 18 wherein the central database is server-based and is updateable from the customer database via the Internet.
20. The electronic purchasing system of claim 18 wherein the central database, the customer database, and the supplier database comprise an integrated system.
21. The electronic purchasing system of claim 18 wherein the supplier database includes a list of products offered for sale by a plurality of suppliers.
22. The electronic purchasing system of claim 18 further comprising a reporting entity in communication with the central database for providing purchasing reports to customers and to a managing entity of the electronic purchasing system.
23. A method of product procurement via an electronic purchasing system managed by a managing entity, comprising the steps of: permitting a purchaser to submit a purchase order by the steps of selecting items for purchase from a product list and placing a purchase order;
obtaining price terms from suppliers based on aggregated order quantities from multiple purchasers;
selecting a supplier for fulfilling the purchase order;
transmitting the purchase order to the supplier via the electronic purchasing system;
wherein the supplier fulfills the purchase order by the steps of processing the purchase order, arranging for delivery of the items to the purchaser, and sending an invoice to the purchaser;
paying the supplier via the electronic management system for items indicated on the invoice;
billing the purchaser for items indicated on the invoice;
wherein the purchaser pays the managing entity for the items indicated on the invoice.
24. A method of product procurement by a plurality of purchasers via an electronic purchasing system managed by a managing entity, comprising the steps of: selecting items comprising a plurality of individual ingredients from a product file located in the electronic purchasing system;
placing purchase orders in the electronic purchasing system for the items selected;
segregating the purchase orders into a plurality of ingredient orders corresponding to the individual ingredients that make up the items;
aggregating a plurality of ingredient orders corresponding to a first ingredient into an aggregated supplier order for the first ingredient;
selecting a supplier to fill the aggregated supplier order;
transmitting the aggregated supplier order to the supplier via the electronic purchasing system;
processing the aggregated supplier order by the seller;
delivering the first ingredient, along with an invoice, to each purchaser indicated on the aggregated supplier order;
approving the invoices by the indicated purchasers;
forwarding the approved invoices to the managing entity; paying the supplier, by the managing entity, for the items indicated on the invoices;
aggregating multiple invoices of each of the indicated purchasers over a predetermined billing period into a consolidated invoice for each indicated purchaser;
billing each indicated purchaser for the items indicated on a corresponding consolidated invoice; and
paying the managing entity, by each of the indicated purchasers, for the items indicated on the consolidated invoice.
PCT/IB2002/002430 2001-03-16 2002-03-18 Network-based procurement system and method WO2002086779A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US27684501P 2001-03-16 2001-03-16
US60/276,845 2001-03-16

Publications (1)

Publication Number Publication Date
WO2002086779A1 true WO2002086779A1 (en) 2002-10-31

Family

ID=23058300

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2002/002430 WO2002086779A1 (en) 2001-03-16 2002-03-18 Network-based procurement system and method

Country Status (1)

Country Link
WO (1) WO2002086779A1 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018165248A1 (en) * 2017-03-07 2018-09-13 Mastercard International Incorporated Method and system for recording point to point transaction processing
CN108960943A (en) * 2017-05-17 2018-12-07 上海展来信息技术有限公司 A kind of commodity transaction method and system of B2B E-commerce
CN111160999A (en) * 2019-12-05 2020-05-15 国信电子票据平台信息服务有限公司 Bill collaborative management method and system
US10956973B1 (en) 2016-07-06 2021-03-23 LedgerFunding, Inc. System and method for verifiable invoice and credit financing
CN111160999B (en) * 2019-12-05 2024-04-30 国信电子票据平台信息服务有限公司 Bill collaborative management method and system

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999066436A1 (en) * 1998-06-19 1999-12-23 Protx Limited Verified payment system
WO2000075846A1 (en) * 1999-06-08 2000-12-14 Ariba, Inc. A facilitator for aggregating buyer power in an on-line market system
GB2352848A (en) * 1999-07-31 2001-02-07 Int Computers Ltd Computer system for goods procurement including consolidating orders
WO2001018712A1 (en) * 1999-09-10 2001-03-15 Rodgers William C Web-based system to facilitate purchase, pick-up, and delivery of, and escrow and payment for, merchandise
US6260024B1 (en) * 1998-12-02 2001-07-10 Gary Shkedy Method and apparatus for facilitating buyer-driven purchase orders on a commercial network system
JP2001357276A (en) * 2000-06-12 2001-12-26 Toshiba Corp Method and system for providing group purchase service and computer-readable storage medium

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999066436A1 (en) * 1998-06-19 1999-12-23 Protx Limited Verified payment system
US6260024B1 (en) * 1998-12-02 2001-07-10 Gary Shkedy Method and apparatus for facilitating buyer-driven purchase orders on a commercial network system
WO2000075846A1 (en) * 1999-06-08 2000-12-14 Ariba, Inc. A facilitator for aggregating buyer power in an on-line market system
GB2352848A (en) * 1999-07-31 2001-02-07 Int Computers Ltd Computer system for goods procurement including consolidating orders
WO2001018712A1 (en) * 1999-09-10 2001-03-15 Rodgers William C Web-based system to facilitate purchase, pick-up, and delivery of, and escrow and payment for, merchandise
JP2001357276A (en) * 2000-06-12 2001-12-26 Toshiba Corp Method and system for providing group purchase service and computer-readable storage medium

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
DATABASE WPI Derwent World Patents Index; Class T01, AN 2002-119515/16 *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10956973B1 (en) 2016-07-06 2021-03-23 LedgerFunding, Inc. System and method for verifiable invoice and credit financing
WO2018165248A1 (en) * 2017-03-07 2018-09-13 Mastercard International Incorporated Method and system for recording point to point transaction processing
US10659227B2 (en) 2017-03-07 2020-05-19 Mastercard International Incorporated Method and system for recording point to point transaction processing
US11456868B2 (en) 2017-03-07 2022-09-27 Mastercard International Incorporated Method and system for recording point to point transaction processing
CN108960943A (en) * 2017-05-17 2018-12-07 上海展来信息技术有限公司 A kind of commodity transaction method and system of B2B E-commerce
CN108960943B (en) * 2017-05-17 2023-12-19 上海展来信息技术有限公司 Commodity transaction method and system for B2B electronic commerce
CN111160999A (en) * 2019-12-05 2020-05-15 国信电子票据平台信息服务有限公司 Bill collaborative management method and system
CN111160999B (en) * 2019-12-05 2024-04-30 国信电子票据平台信息服务有限公司 Bill collaborative management method and system

Similar Documents

Publication Publication Date Title
JP5172354B2 (en) Project information planning / scope change management information and business information synergy system and method
US7143051B1 (en) Method and system for quoting, issuing, and administering insurance policies including determining whether insurance policies are self bill or list bill
US7464092B2 (en) Method, system and program for customer service and support management
US8069096B1 (en) Multi-constituent attribution of a vendor's product catalog
US8595076B2 (en) Method and system for purchase of a product or service using a communication network site
US20050125251A1 (en) System and method for enterprise resource management
US20020052801A1 (en) Hosted asset procurement system and method
US20020069096A1 (en) Method and system for supplier relationship management
US20020095355A1 (en) Computer-implemented international trade system
US20030074273A1 (en) Apparatus and method for facilitating trade
US20080300959A1 (en) Enterprise application procurement system
US20040019494A1 (en) System and method for sharing information relating to supply chain transactions in multiple environments
US20040073507A1 (en) Method and system for providing international procurement, such as via an electronic reverse auction
US20040039681A1 (en) Computer system and method for producing analytical data related to the project bid and requisition process
MX2008012200A (en) Information management system and method.
WO2001071546A2 (en) Using lead-times and usage rates to determine inventory reorder points and levels
KR100432400B1 (en) A managing and business supporting system for membership drug-store based on internet and method thereof
US20030191652A1 (en) Customs information system with assist calculation engine
WO2005031543A2 (en) Visibility and synchronization in a multi-tier supply chain model
US20020128944A1 (en) Public hub employing a trusted agent to facilitate the exchange of commodities
US20140067431A1 (en) System and method of providing devices for injuries under worker's compensation coverage
TWI239453B (en) Network-based virtual commodity exchange
US20050177468A1 (en) Request for quote system and method
WO2002086779A1 (en) Network-based procurement system and method
Buck-Emden et al. mySAP CRM

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: COMMUNICATION UNDER RULE 69 EPC ( EPO FORM 1205A DATED 19/04/04 )

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP