WO2001020514A1

WO2001020514A1 - Method, apparatus, and system for facilitating transactions between vendors and purchasers

Info

Publication number: WO2001020514A1
Application number: PCT/US2000/024671
Authority: WO
Inventors: Rod Georgiu; Eric Olson; Jim Leach; Ralph Cesena
Original assignee: Autovia Corporation
Priority date: 1999-09-13
Filing date: 2000-09-07
Publication date: 2001-03-22
Also published as: AU7126100A

Abstract

A method, apparatus, system and machine-readable medium for facilitating and automating business transactions between multiple vendors and purchasers using a centralized system to which the multiple vendors and purchasers are connected via a computer network. In one embodiment, a catalog query function (323) is performed at the centralized system (301) to identify and display a list of part items in a first catalog that match the query criteria submitted by a first purchaser, a stock check function is performed by the centralized system (301) to inquire about prices and availability of the part items in the list that are selected by the first purchaser to be stock checked. A list of stock check responses received from the selected vendors is then displayed to the first purchaser. In response to an order placement request (327) submitted by the first purchaser, an order placement function is performed by the centralized system (301) to order the part items in the list of responses that are selected by the first purchaser to be ordered.

Description

METHOD, APPARATUS, AND SYSTEM FOR FACILITATING TRANSACTIONS BETWEEN VENDORS AND PURCHASERS

FIELD OF THE INVENTION

The present invention relates to the processing of information in a client-server environment. More specifically, the present invention relates to an apparatus, method, system, and machine-readable medium for facilitating commercial transactions between vendors and purchasers of auto parts.

BACKGROUND OF THE INVENTION Traditionally, vendors and purchasers of auto parts conduct their business transactions via phone or other methods of manual communications and processing. Vendors of auto parts may include wholesalers, distributors, retailers, or other business entities engaging in the distribution and selling of auto parts. Purchasers of auto parts may include automobile repair facilities, retailers, individuals, or other entities that have a need to locate and order various auto parts for various purposes. Conventionally, purchasers and vendors of auto parts perform various tasks manually to initiate and process various commercial transactions pertaining to their businesses. Some ofthe manual tasks performed by a typical purchaser may include searching through a paper catalog to identify one or more specific part numbers and other information for one or more parts needed to do a repair job (i.e., catalog query), searching through the paper catalog or some paper directories to identify the particular vendors that carry the required parts (catalog query), calling or faxing a request to the vendors to inquire about the price and availability ofthe required parts (stock check), and calling the vendors to place orders for the required parts, etc. Moreover, the typical purchaser described in the above scenario may have to repeat those manual tasks several times before placing one or more orders with one or more vendors. For example, the purchaser may have to look through multiple paper catalogs to identify the part information and the vendors that us carry the required parts. In addition, if the purchaser wants to shop around to find better prices or if the particular vendors initially contacted by the purchaser do not have the required parts in stock, the purchaser may have to make several phone calls (or send several faxes) to different vendors to inquire about the prices and availability ofthe required parts, provided that the purchaser can figure out who to call. It is obvious from the above example that the manual tasks that a typical purchaser would need to perform to obtain the parts required to complete a repair job are not only tedious and time consuming but also inefficient and can easily result in processing errors which would cost more time, money and customer satisfaction. For example, the purchaser may obtain a wrong part number from the paper catalog, may provide erroneous part information to the vendors who would in turn provide erroneous information back to the purchaser. In addition, each vendor may have different requirements/business practices/procedures with respect to various aspects of auto parts ordering and processing which would place a heavy burden on the purchasers to conform to. For example, a purchaser who deals with two different vendors having different business practices and procedures may have to use or develop different forms and/or procedures in conducting business transactions with those two different vendors. Such a business operational environment is not only inefficient but also may create inconsistencies and more room for errors. For example, wrong forms may be sent or faxed to wrong vendors, etc. Of course, the problems or issues facing the purchasers may also face the vendors on the other end. For example, a particular vendor may have to deaTwith numerous different purchasers who operate in different business environments using different procedures/practices. A typical vendor may also incorrectly process the information provided by the purchaser. In some cases, some vendors and/or purchasers may have access to use some computer systems designed to assist the vendors and purchasers in conducting their business transactions. Even in these limited cases, the amount of work that need to be performed manually by both vendors and purchasers is still considerable. Moreover, since these small number of proprietary computer systems are designed to suit particular needs of particular vendors and/or purchasers, they cannot operate across different business environments or across different technical platforms. Even if a purchaser in some special circumstances has access to use two or more computer systems to perform stock checks and order placements with two or more vendors, such access is still limited within the confines of those computer systems and the purchaser has no other automated mechanism to perform concurrent, parallel inquiries about prices, availability of required parts or place multiple orders simultaneously. There exists a need for a centralized system to which multiple vendors and purchasers can be connected to facilitate and automate business transactions between the multiple vendors and purchasers.

SUMMARY OF THE INVENTION

The present invention provides a method, apparatus, system and machine- readable medium for facilitating and automating business transactions between multiple vendors and purchasers using a centralized system to which the multiple vendors and purchasers are connected via a computer network. In one embodiment, a catalog query function is performed at the centralized system to identify and display a list of part items in a first catalog that match the query criteria submitted by a first purchaser. In response to a stock check request submitted by the first purchaser, a stock check function is performed by the centralized system to inquire about prices and availability ofthe part items in the list that are selected by the first purchaser to be stock checked. A list of stock check responses received from the selected vendors is then displayed to the first purchaser. In response to an order placement request submitted by the first purchaser, an order placement function is performed by the centralized system to order the part items in the list of responses that are selected by the first purchaser to be ordered.

BRIEF DESCRIPTION OF THE DRAWINGS

The features and advantages ofthe present invention will be more fully understood by reference to the accompanying drawings, in which:

Figure 1 is a block diagram of one embodiment of a system for facilitating and processing transactions between multiple purchasers and vendors of auto parts;

Figure 2 shows a more detailed block diagram of one embodiment ofthe system in Figure 1; Figure 3 illustrates a functional block diagram of one embodiment of the system described in Figure 2; Figure 4 shows a structure diagram of one embodiment of a transaction database according to the teachings ofthe present invention;

Figure 5 shows a tree-view diagram of one embodiment ofthe transaction database described in Figure 4; Figure 6 shows a table-view representation ofthe transaction database described in Figure 4;

Figure 7 shows a structure diagram of one embodiment of a message database in accordance with the teachings ofthe present invention;

Figure 8 shows a tree-view representation of one embodiment ofthe message database;

Figure 9 is a table- view representation of one embodiment ofthe message database;

Figure 10 illustrates a block diagram of one embodiment of a vendor gateway according to the teachings ofthe present invention; Figure 11 shows a block diagram of a vendor response server interface;

Figure 12 shows a flow diagram of a sequence of events that take place in a typical transaction scenario between a purchaser and a vendor of auto parts;

Figure 13 shows a flow diagram of one embodiment of a method for facilitating and processing auto part transactions; Figure 14 is a flow diagram of one embodiment of a method for creating/updating a purchaser account and profile information;

Figures 15A-L show examples of various user interfaces that are used to create/update a purchaser account and profile information;

Figure 16 shows a flow diagram of one embodiment of a method for creating/updating a vendor account and profile information;

Figures 17A-H shows examples of various user interfaces used to create/update a vendor account and profile information;

Figure 18 illustrates a flow diagram of one embodiment of a method for facilitating and automating new orders of auto parts; Figure 19 shows a flow diagram of one embodiment of a part query/search process; Figure 20 shows a flow diagram of one embodiment of a method for performing a part search based upon a part number and a manufacturer line code;

Figures 21A-N show examples of various user interfaces used in the part query /search process described in Figure 19; Figure 22 is a flow diagram of one embodiment of a method for performing a stock check function;

Figure 23 shows an example of a stock check results user interface; Figure 24 is a more detailed flow diagram of one embodiment of a method for performing a stock check function; Figure 25 shows a flow diagram of one embodiment of a method for performing an order placement function;

Figure 26 is a detailed flow diagram of one embodiment of a method for performing an order placement function;

Figure 27 is a flow diagram of one embodiment of a method for providing job status information to the users;

Figure 28A is an example of a job status summary user interface; Figure 28B is an example of a user interface displaying detailed vendor information;

Figure 28C is an example of a user interface showing detailed order status history;

Figure 29 is an example of a user interface showing detailed order status history; Figure 30 shows an example of a user interface for job closing confirmation; Figure 31 shows an example of a user interface for cost estimate; Figure 32 shows an example of a user interface showing status of completed jobs;

Figure 33 shows an example of a detailed order status history; Figure 34 is an example of a return authorization request summary user interface; Figure 35 illustrates a flow diagram of one embodiment of a process for providing order status history of an order; Figure 36 shows a detailed flow diagram of one embodiment of a process for performing a cancellation function; Figure 37 shows a detailed flow diagram of one embodiment of a method for performing a return function;

Figure 38 illustrates a flow diagram of one embodiment of a method for allowing the user to review and update status information; Figures 39 A-B show examples of various user interfaces used for updating status information;

Figure 40 is a flow diagram of one embodiment of a method for reporting transactional information to a user ofthe system;

Figures 41A-F show examples of various user interfaces used to report transactional information to a user;

Figure 42 is a flow diagram of one embodiment of a process for allowing a vendor to view and take appropriate actions with respect to pending transactions;

Figures 43 A-D show examples of various user interfaces used to review pending transactions; Figure 44 illustrates a flow diagram of a method for providing historical transactional information to a vendor;

Figures 45A-C show examples of various user interfaces used to provide historical transaction information to a vendor;

Figure 46 shows a flow diagram of one embodiment of a method for reporting transactional information to a user; and

Figures 47A-G show examples of various user interfaces used to report transactional information to a user.

DETAILED DESCRIPTION

In the following detailed description numerous specific details are set forth in order to provide a thorough understanding ofthe present invention. However, it will be obvious to one skilled in the art that the present invention may be understood and practiced without these specific details.

In the discussion below, the teachings ofthe present invention are utilized to implement a system to facilitate and automate various commercial transactions between vendors and purchasers of auto parts via a computer network. The system is designed and configured to process different types of data requests and responses from the vendors and purchasers and to transmit various types of transactional information between the vendors and the purchasers. Transactional information processed and transmitted by the system include stock check requests submitted by the purchasers and stock check responses generated by the vendors, part order requests submitted by purchasers and part order confirmations generated by vendors, order status requests submitted by purchasers and order status responses generated by vendors, cancellation requests and cancellation confirmations, return requests, return authorizations, and return confirmations etc. The system is configured to allow a purchaser to submit multiple stock check requests and/or multiple order requests concurrently to multiple vendors. Purchasers and vendors can use the system to generate various types of reports containing information relating to their transactions. Purchasers and/or vendors can use the system to specify their business preferences including the specific business entities with whom they want to conduct business and the relative ranking among those business entities. The teachings ofthe present invention are applicable to any business environment in which multiple purchasers and sellers wish to conduct their business transactions over a computer network. The present invention is not limited to the facilitating and processing of auto parts transactions and can be applied to other types of business transactions in other business areas or disciplines. Figure 1 illustrates a block diagram of one embodiment of a system environment and configuration 100 for facilitating and processing transactions between multiple purchasers and vendors of auto parts. In this configuration, various business entities can be connected to a centralized processing system 101 via a computer network. In one embodiment, the computer network can be a local area network (LAN), a wide area network (WAN), the Internet, or any combinations thereof. In one embodiment, the centralized system 101 is an Internet-based system designed to perform various functions to facilitate and process various types of transactions between multiple purchasers 105a- 105c and multiple vendors 121a- 121c. The various functions performed by centralized system 101 include the processing of parts queries, stock check requests, order placement requests, order status and tracking requests, order cancellation requests, return requests, etc. The processing of these various types of requests and/or functions is described in detail below.

Referring to Figure 1, in one embodiment, various purchasers 105a- 105c can establish connections with the centralized system 101 via the Internet. The purchasers 105a- 105c can submit various types of requests to the centralized system 101 and conduct various types of transactions with one or more vendors 121a-121c using the centralized system 101. As mentioned above, purchasers of auto parts 105a- 105c may include automobile repair facilities, retailers, individuals, or other entities that have a need to locate and order various auto parts for various purposes. Vendors of auto parts 121a- 121c (also referred to as distributors herein) may include wholesalers, distributors, retailers, or other business entities engaging in the distribution and selling of auto parts. The centralized system 101 is designed to facilitate and process various types of business transactions between the purchasers 105a- 105c and the vendors 12 la- 121c and perform other functions relating to their business transactions. The various processes and functions performed by the centralized system 101 are described in detail below. Continuing with the present discussion, one ofthe purchasers, for example purchaser 105a, can establish connection with the centralized system 101 via an Internet connection. The purchaser 105a can submit a part lookup or catalog query request to the centralized system 101 to locate one or more specific parts that are needed to perform a repair job. The centralized system 101, upon receiving the catalog query request from the purchaser 105 a, conducts a search of an electronic catalog and retrieves the part entries or items in the catalog that match the search criteria specified by the purchaser 105a. The centralized system 101 then sends the information retrieved from the catalog to the purchaser 105a. The purchaser 105a can select one or more specific parts to be stock checked. In the present specification, the term "stock check" is used to refer to the inquiry about the availability and price of one or more specific parts. The purchaser 105 a can submit a stock check request on the specific parts to one or more vendors selected by the purchaser 105a using the centralized system 101. Assuming in the current example that the purchaser 105a wishes to perform a stock check on the selected parts with the vendors 121a and 121b. The centralized system 101, upon receiving the stock check request from the purchaser, performs a number of functions to be described in more detail below to send the stock check request to both vendors 121a and 121b. In one embodiment, the stock check request is sent concurrently to both vendors 121a and 121b. The vendors 121a and 121b, after processing the stock check request submitted, send a response to each stock check request back to the purchaser 105a via the centralized system 101. The centralized system 101, upon receiving the stock check response back from the vendors 121a and 121b, transmits the stock check response to the purchaser 105a. Similarly, the purchasers 105a-c and the vendors 121a-c can perform other types of transactions and functions to be described in more detail below using the centralized system 101. In one embodiment, other entities can also be connected to the centralized system

101 to conduct various types of business transactions and functions. For example, auto part manufacturers 109a- 109b can use the centralized system 101 to obtain statistical information concerning the buying and selling of certain auto parts to determine the marketability and desirability of those parts, etc. In addition, advertisers 113 can also place advertisements using the centralized system 101. Other entities 117 can also use the. centralized system 101 for various purposes including establishing business connection with certain vendors and/or purchasers, obtaining statistical and market information stored by the centralized system 101, etc.

Figure 2 shows a more detailed block diagram of one embodiment ofthe system configuration 100 illustrated in Figure 1. For clarity and simplicity, the discussion is focused on the interactions between the purchasers 251, vendors 271 and the centralized system 201. However, everything discussed herein equally applies to other business entities in the auto parts processing as well as in other business environments. In one embodiment, the centralized system 201 facilitates various types of business transactions including stock checks and order transactions between multiple purchasers 251 (e.g., repair shops) and multiple parts vendors or distributors 271. In one embodiment, the centralized system 201 is also configured to process various types of reporting functions desired by the purchasers and vendors with respect to their business transactions including transactional summary and detailed reports that are described in more detail below. In one embodiment, the centralized system 201 is logically organized into three major subsystems or units: a market subsystem or unit 203, a transaction database or unit 213, and a vendor gateway subsystem or unit 227. The market subsystem or unit 203, in one embodiment, contains one or more market servers 205, a catalog server 209, and a catalog 213 containing auto parts information. The transaction database subsystem or unit 215, in one embodiment, contains a database server 217, a transaction database 221 , and a database converter/translator 225. The vendor gateway subsystem or unit 227, in one embodiment, contains a database server 229, a message database 233, and a vendor system interface (VSI) component 237. These various system components ofthe centralized system 201 are described in further detail below.

Continuing with the present discussion, in one embodiment, the purchasers 25 la-b (e.g., workshop technicians at repair shops) establish connection with the centralized system 201 via the Internet and access the various functions ofthe centralized system 201 using an Internet browser (also referred to as the client program). The purchasers 25 la-b can establish connection with the centralized system 201 using a router, a dial-up modem, or other methods of Internet connections available to them. The purchasers 25 la-b can utilize an Internet browser to interface with the centralized system in order to access the various functions and features ofthe centralized system 201 including catalog query, stock check or quotes, order placement, order management, returns and profiles management, etc. In one embodiment, the purchasers 25 la-b can also use the browser client program to communicate via voice and/or video with parts vendors and other purchasers (e.g., repair shops). In one embodiment, the centralized system 201 is designed to support both Microsoft® INTERNET EXPLORER® and Netscape® NAVIGATOR® browser software.

Parts vendors 271a-c (also referred to as distributors or suppliers), in one embodiment, establish connection with the centralized system 201 via the Internet. The vendors 271a-c can establish connection with the centralized system 201 using routers, dial-up modems or other methods of Internet connections available to them. In one embodiment, the vendors 271a-c use an Internet browser to access the centralized system 201 to perform various functions including establishing the profile of their businesses and generating various types of transaction reports, etc. They can also use the browser to optionally review quote and order information and communicate with the purchasers 25 la-b and other vendors. The various functions performed by the centralized system 201 in response to various requests by the vendors 271a-c are described in detail below.

Referring again to Figure 2, in one embodiment, the market server 205 is a primary web application server that provides the system interface between the purchasers 251 , the vendors 271 , and the centralized system 201. In one embodiment, the market server 205 is a web application server built on an underlying framework using Microsoft Active Server Pages, Microsoft COM objects and stored procedures in the database. In one embodiment, Active Server Pages (ASP) is an extension of Microsoft IIS web server using the IS API interface. In one embodiment, ASP provides both server-side scripting using Visual Basic Script and client-side scripting using Java Script. ASP can access Microsoft COM objects. In one embodiment, Microsoft's Visual InterDev is used to create ASP code. In one embodiment, Microsoft's Visual C++ and Microsoft's Visual Basic is used to create COM objects. In one embodiment, database stored procedures are created using a text editor and are compiled using the database stored procedure compiler.

In one embodiment, the catalog server 209 is coupled to a catalog storage device 213 that contains parts information. The catalog storage device 213 can be any type of storage medium including but is not limited to disks, tapes, etc. In one embodiment, the catalog server 209 is a high performance indexed file system provided by MacDonald Computer Systems of Valencia, California. In one embodiment, the catalog 213 provides auto parts content from many manufactures and is customized for the automotive industry.

In one embodiment, the transaction database 221 is configured to store customer profile information (e.g., information of purchasers and vendors) and transaction information (e.g., information relating to business transactions between purchasers and vendors). The information stored in the transaction database 221 includes purchaser profiles and vendor profiles; catalog query results, stock check results, order information, cancellation information, return information, delivery information, etc. The transaction database 221 can be any type of storage medium including disk, tape, etc. In one embodiment, the transaction database 221 is configured as a relational database containing a set of various tables used to store various types of customer profile and transaction information as described above. However, the teachings ofthe present invention are not limited to relational database structures and can equally apply to any other database or file structures including flat file structure, indexed file structure, hierarchical database structure, networked database structure, or combinations thereof, etc.

The database converter/translator 225, in one embodiment, functions as an interface between the transaction database 221 and the vendor gateway 227. In one embodiment, the database converter 225 scans the transaction database 221 for new transaction requests (e.g., new stock check requests), creates appropriate request messages (e.g., stock check request messages) in the message database 223, scans the message database 223 for responses or confirmations (e.g., stock check response messages), and updates the transaction database 221 with the response or confirmation information retrieved from the message database 223. The structure and functions ofthe database converter 225 are described in more detail below. The vendor gateway 227, in one embodiment, functions as an interface between the centralized system 201 and the vendors 271. As described above, the vendor gateway 227, in one embodiment, includes the message database 233 and a vendor system interface (VSI) 237. In one embodiment, the message database 233 is configured to store a set of various tables containing transaction information of various types of transactions including order information, stock check information, etc. The structure of the message database 233 is described in more detail below. The vendor system interface (VSI) 237 contains logic for transmitting transaction information to and receiving transaction information from the various computer systems that are used by the vendors 271 to process their transactions. In one embodiment, the vendor system interface 237, utilizing various types of communications methods to be described in more detail below, transmits various types of transaction requests (e.g., stock check requests) to the systems ofthe vendors 271 based on the information retrieved from the message database 233, receives the transaction responses or confirmations (e.g., stock check responses) from the vendors' systems, and updates the message database 233 with the responses or confirmations received from the vendors' systems. The operations and functions performed by the vendor system interface (VSI) 237 in order to transmit transaction information to and receive transaction information from the vendors' systems are described in greater detail below. The vendor system interface 237 can be connected to the vendors' systems in a number of ways including LAN connection, serial port connection, or terminal connection, etc. These various types of connections will be described in further detail below.

Figure 3 shows a functional block diagram of one embodiment ofthe centralized system 201 described above with respect to Figure 2. It will be recognized by one skilled in the art that the following description is for illustration purposes only and does not in anyway limit the scope ofthe present invention. In one embodiment, the logic and/or functions that are described below can be implemented using one or more programming languages suitable for the software or system development in a client-server environment, such as Visual Basic, C++ or Java, etc. It should be recognized by one skilled in the art, however, that the logic or functions described herein can be implemented by other programming languages, circuits, or techniques in accordance with the teachings ofthe present invention without loss of generality.

Continuing with the present discussion, the centralized system 301 contains a user profile/account update logic or function 311, a new order processing logic or function 321, an existing order processing logic or function 331, a reporting logic or function 341, and other functions 351. The user profile/account update logic 311 contains logic to allow purchasers and vendors of auto parts to register with the centralized system, to establish and maintain their user profile and account information that are used for various purposes by the centralized system as described in greater detail below. In one embodiment, the user profile and account information maintained for a purchaser includes the purchaser account information such as business name and address, information specifying one or more major metropolitan markets in which the purchaser is located; user account information that allows for the tracking of individual usage and tailoring individual access to different functions ofthe centralized system; information regarding vendor selection and assignment of vendor type that are used by the centralized system to perform various functions as described in more detail below; and display preferences with respect to vendors and costs of parts, etc. Similarly, the user profile and account information maintained for vendors includes vendor company information such as business name, address, and major metropolitan market areas in which the vendors are located; vendor services information including delivery and shipping options; vendor user information specifying system access and authorization levels; information indicating the manufacturer lines carried by the vendor; and display preferences with respect to prices, etc.

The new order processing logic 321 contains logic to receive, process, and transmit various types of requests from purchasers to vendors and logic to receive, process, and transmit various types of responses from vendors to purchasers. The various types of requests and responses that are received, processed, and transmitted by the new order processing logic 321 are described in detail below. In one embodiment, the existing order processing logic 331 contains logic to process various types of transactions and requests regarding existing auto part orders between the purchasers and vendors. The reporting logic 341 contains logic to generate various types of reports for the users ofthe system including purchasers and vendors based upon the report request type and information available in the system.

In one embodiment, the new order processing logic 321 contains catalog query logic 323, a stock check logic 325, and an order placement logic 327. The catalog query logic 323 is used to perform a catalog query function to identify and present to a purchaser a list of auto parts entries in the catalog 213 that match the query criteria specified by the purchaser. For purposes of discussion herein, the list containing auto parts entries in the catalog that match the query criteria specified by the purchaser is also referred to as the matched list or catalog results. The stock check logic 325 contains logic to allow the purchaser to select one or more part entries in the matched list to be stock checked. The stock check logic 325 also contains logic to allow the purchaser to specify, for each part entry selected to be stock checked, one or more vendors to whom the stock check request for the respective selected part is to be sent. The order placement logic 327 contains logic to allow the purchaser to place an order request for one or more part entries for which stock check information have been received from the vendors. The order placement logic 327 also contains logic to allow the purchaser to specify, for each part to be ordered, one or more vendors to whom an order request for the selected part is to be sent. The existing order processing logic 331, in one embodiment, contains order status logic 333, an order cancellation logic 335, an order return logic 337, and a delivery update logic 339. The order status logic 333 is used to obtain order status information from one or more vendors. In one embodiment, the order status logic 333 contains logic to generate a summary status list for jobs within a particular purchaser's account. The generation of the summary status list is described in further detail below. In one embodiment, the order status logic 333 contains logic to allow the purchaser to select, from the summary status list, a particular order number to obtain more detailed status information about that particular order. In one embodiment, the status information for a particular order or job contains, for each item on the order or job, the stock check status, order status including when order request is sent, accepted, etc., return status, and core status, etc. The order cancellation logic 335 contains logic to allow a purchaser to review existing part orders and individually select one or more items from one or more specific part orders to be canceled. The return logic 337 is used to allow a purchaser to review existing part orders and individually select one or more part items from one or more specific part orders to be returned. In one embodiment, a purchaser can initiate a cancellation and/or return action when viewing the order status of a particular order. The delivery update logic 339 allows a user to view and update pickup/delivery information with respect to part items that have been ordered, the cores corresponding to the part items ordered, and return information with respect to return items. In one embodiment, the delivery update logic 339 contains logic to display a summary list of pickup/delivery information with respect to a particular vendor selected by the user. In one embodiment, the delivery update logic 339 further contains logic to allow the user to individually select one or more part items in the list to indicate that the respective part items have been received, logic to individually select one or more part item in the list to indicate that the cores for the respective part items have been returned, and logic to specify whether a particular part item has been returned.

Figure 4 shows a structure diagram of one embodiment ofthe transaction database 221 described in Figure 2 above. As illustrated in Figure 4, the transaction database 221, in one embodiment, is configured to store both user information 401 and transaction information 451. In one embodiment, the user information 401 contains the vendor information 405 and the purchaser information 409. As described above, the vendor information 405 includes the vendor company information, the vendor services information, the vendor user authentication information, information about the manufacturer/line of products carried by the vendor, etc. The purchaser information 409 includes the purchaser account information, the purchaser user login information, the vendor selection and vendor type, and display preferences, etc.

In one embodiment, the transaction information 451 stored in the transaction database 221 includes the job information 455, the stock check requests 459, stock check responses 463, order requests 467, order confirmations 471, cancellation requests 475, cancellation confirmations 479, return requests 481 , return authorizations 485, return confirmations 497, etc. A detailed description ofthe creation and update ofthe various types of information and transactions stored in the transaction database 221 is provided below. As explained above, in one embodiment, the transaction database 221 is implemented as a relational database structure and the various information stored in the transaction database 221 can be organized and maintained in various tables that can be cross-referenced or linked together using certain data items stored as keys or descriptors. The transaction database 221, however, is not limited to relational database structure and can be implemented in any other database or file structure including flat file, indexed file, hierarchical database, networked database, etc. or any combinations thereof. Figure 5 shows a tree view diagram of one embodiment ofthe transaction database 221 with respect to some ofthe information stored therein. A purchaser identified as purchaser 1 (e.g., a repair shop that has registered with the centralized system 201 ) may have created multiple jobs (e.g., job 1 , job 2, ... , job N), the information of which are stored in the transaction database 221. As shown in Figure 5, each of these jobs originates from purchaser 1 and therefore can be traced back to purchaser 1 using some identifiers, for example a unique purchaser identifier assigned to purchaser 1 by the system. Each of these jobs may have one or more transaction requests associated with it. For example, as shown in Figure 5, job 1 has two stock check requests (stock check 1 and stock check 2) and two order requests {order 1 and order 2) associated with it. Since these requests are associated with job 1, they can be linked or traced back to job 1 using an identifier, for example a unique job identifier generated by the system. Each stock check request, for example stock check 1, may have one or more stock check request items (i.e., specific part items to be stock checked). Each stock check item, for example stock check item 1 , may have a corresponding stock check response. Figure 6 shows a table-view representation of one embodiment ofthe transaction database 221. As shown in Figure 6, the transaction information are organized and maintained in various tables that are cross-referenced or linked by certain data items stored in the tables (keys or descriptors). In this example, information about the various jobs created by the purchasers are stored in a table referred to as job table 611. Stock check requests submitted by the purchasers are stored in a table referred to as stock check table 621. Likewise, order requests are stored in a table called order table 625. Each stock check request stored in the stock check table 621 may have one or more corresponding stock check items stored in the stock check item table 631. Similarly, each order request stored in the order table 625 may have or more order items stored in the order item table 635. Each stock check item stored in the table 631 may have a corresponding stock check response stored in the stock check response table 641. Entries that are stored in the various tables mentioned above are also referred to as records or rows in the present specification. Again, the table structures shown in Figure 6 are for illustrative purposes only and it would be obvious to one skilled in the art that the table structures described herein can be implemented by other data structures, methods, and techniques within the scope ofthe present invention.

Figure 7 shows a structure diagram of one embodiment ofthe message database 233 described above with respect to Figure 2. In one embodiment, the message database 233 is implemented as a relational database using various tables to store various types of transaction information including transaction requests and responses. The various tables in the message database 233 include an order table 701, a request item table 711, a stock check response table 721 , an order response table 731, and a comment table 741. In one embodiment, the message type in the order table 701 and the request-item table 711 is used to indicate whether the information stored in the tables is for a request (e.g., stock check request) or response (e.g., stock check response) and also the type of request or response. The use ofthe message type in processing various types of transaction requests and responses is described in detail below. As shown in Figure 7, each order entry (also referred to as an order record or row) in the order table 701 can have one or more corresponding entries in other tables, for example, the request item table 711. Likewise, each entry in the request item table 711 can have one or more corresponding entries in other tables, for example the stock check response table 721. As illustrated in Figure 7, the OrderlD field is used a key to link entries in the order table 701 with entries in other tables. Likewise, the OrderlD field and ItemID field are used as a key to link the other tables together.

Figure 8 shows a tree- view representation ofthe message database 233 described in Figure 2 and Figure 7. In this representation, one ofthe order entries in the order table, for example order 1, may have one or more corresponding entries in the request item table, for example request items 1, 2, and 3. Each of these request items may have one or more corresponding entries in other tables. For example, request item 1 of order 1 may have a corresponding entry in the stock check response table, a corresponding entry in the order response table, and a corresponding entry in the comment table.

Figure 9 shows a table-view representation of one embodiment of message database 233. As shown in Figure 9, the transaction information (e.g., transaction requests, responses, etc.) are organized and maintained in various tables that are cross- referenced or linked by certain data items stored in the tables (keys or descriptors). In this example, each order entry in the order table 901 may have one or more corresponding entries in the request item table 911. Each request item in the request item table 911 may have one or more corresponding stock check responses in the stock check response table 921 and order responses in the order response table 931, etc. The table structures shown in Figure 9 are for illustrative purposes only and it would be obvious to one skilled in the art that the table structures described herein can be implemented by other data structures, methods, and techniques within the scope ofthe present invention.

Figure 10 shows a block diagram ofthe vendor gateway 227 described above with respect to Figure 2. In one embodiment, the vendor gateway 227 contains one or more vendor terminal interface (VTI) units 1011 and one or more vendor response server interface (RSI) units 1015. In one embodiment, the vendor terminal interface 1011 and the vendor response server interface 1015 retrieve request messages (e.g., stock check request messages, etc.) from the message database 1005 and submit the request messages to selected vendors in a format that is compatible with the vendors' systems. The vendor terminal interface 101 1 and the vendor response server interface 1015 then receive response information from the vendors and update the message database 1005 with the response information received from the vendors. In one embodiment, the vendor interface 1011 is used to exchange information (e.g., stock check requests and responses, etc.) between the centralized system 201 and those vendors with terminal emulation connection 1021 and 1029. The vendors with terminal emulation can be further classified into two different categories based upon the respective communication protocols used. In this example, vendor 1021 is a vendor that has terminal emulation using RS232 protocol while vendor 1025 is a vendor that uses TCP/IP terminal emulation protocol. In one embodiment, to centralize and simplify the vendor terminal interface configuration, two interface products are used. One product is called a terminal server produced by Lantronix Corporation of Irvine, California. The terminal server is used to convert RS232 protocol to TCP/IP message packets. The other product is called MitemView produced by Mitem Corporation of Menlo Park, California. MitemView is a tool used to construct interfaces to vendor (distributor) systems without modifying the vendor (distributor) system software. In one embodiment, this is accomplished by creating a "virtual user" session with the distributor system by connecting the vendor gateway to the terminal port on the distributor system. In one embodiment, the MitemView virtual user session receives requests from the vendor gateway message dispatcher and processes the messages interactively with the distributor system. The MitemView product not only simplifies the construction of each individual distributor system interface but also provides a server-based implementation ofthe terminal interaction with the distributor system. Referring again to Figure 10, the vendor terminal interface 1011 uses the MitemView interface to communicate with vendor 1021 that has TCP/IP terminal emulation configuration. The vendor terminal interface 1011 communicates with vendor 1025 using both the MitemView interface to exchange information and the terminal server to convert RS232 protocol to TCP/IP message packets. As illustrated in Figure 10, the vendor response server interface 1015 is used to exchange information between the centralized system 201 and those vendors with TCP/IP response servers, vendor 1029 in this example and those vendors with RS232 response servers, vendor 1033 in this example. In one embodiment, the vendor response server interface 1015 communicates with vendor 1029 using XML messages to exchange transaction information between the centralized system 201 and vendors with TCP/IP response servers, e.g., vendor 1029.

Figure 11 shows a block diagram ofthe vendor response server interface 1015 described above with respect to Figure 10. In one embodiment, the vendor response server interface 1015 is structured to include multiple threads with each thread containing one Response Server Interface Dispatcher (RSI Dispatcher) COM object 1101 communicating with one vendor response server. As shown in Figure 11, each RSI Dispatcher 1101, in one embodiment, contains a data access module 1110 and a data communication module 1120. The data access module 1110 is used to retrieve requests (e.g., stock check requests, order requests, etc.) from the message database 233 and convert these requests to appropriate XML messages to be sent to the vendor response server. The data access module 1110 is also used to convert XML messages (e.g., stock check response messages, order confirmation messages, etc,) received from the vendor response server to an appropriate format for storing in the message database 233. The communication module 1120, in one embodiment, contains routines to send XML messages to and receive XML messages from the vendor response server using TCP/IP. As shown in Figure 11 , in one embodiment, the data access module contains an XML reader module 1112 and an XML writer module 1114. The XML reader module 1112 is used to parse XML messages into a format ready to be stored in the message database 233. The XML writer module 1114 is used to build XML messages from the data read from the message database 233. In one embodiment, the vendor response server interface 1015 can be configured to have multiple RSI Dispatchers communicating to one vendor response server. For example, if there are three vendors A, B, and C and it is determined that there are three times more requests going to vendor A than to the other vendors. In this case, the vendor response server interface 1015 can be configured to have five RSI Dispatchers: three communicating with vendor A, one communicating with vendor B, and one communicating with vendor C. In one embodiment, the connection information for each RSI Dispatcher (e.g., what vendor to connect to) can be stored in a configuration file, for example an NT registry file, a database file, or a flat file, etc. In one embodiment, this configuration file is also used to tell the vendor response server interface system 1015 the number of RSI Dispatchers to start.

Figure 12 illustrates one example of a sequence of events that take place in a typical transaction scenario between a purchaser and a vendor using the centralized processing system 201 described above. The sequence of events starts at block 1201. At block 1205, a customer (e.g., a vehicle owner) arrives at a repair shop with a repair request. At block 1207, a repair shop technician determines the parts required for the repair. At bock 1209, the repair shop technician logs on to the market server ofthe centralized system 201 described above. It is assumed that the repair shop in this example has already established an account with the centralized system and therefore does not need to go through the process of creating a new account. At block 1211, after logging on to the market server, the technician creates a new job to keep track of related transactions to be processed by centralized system subsequently. At block 1213, the technician locates one ofthe parts required for the repair job using an interface to the parts catalog in the market server. At block 1215, the market server returns a list of parts available from various manufacturers. The process then proceeds to block 1217 where the technician selects one or more parts from the list to be stock checked. At decision block 1219, the process loops back to block 1213 if there are more required parts. Otherwise, the process continues to block 1221 where the technician requests a stock check for the selected parts from one or more vendors. At block 1223, the market server stores the stock check request in the transaction database. At block 1225, the stock check request is passed to one or more distributor systems by the vendor gateway. At block 1227, a stock check response is generated by the distributor systems and passed to the transaction database by the vendor gateway. At block 1229, the stock check response is displayed to the technician. At block 1231, the technician reviews the stock check response and selects the parts to be added to one or more distributor orders. At block 1233, the technician requests the orders to be sent to the distributors. At block 1235, the market server stores the order request in the transaction database. At block 1237, the order request is passed to one or more distributor systems by the vendor gateway. At block 1239, the order is processed by the distributor systems and order confirmations are passed to the transaction database by the vendor gateway. At block 1241, the order confirmation is displayed to the technician. At block 1243, the distributor ships the parts ordered to the repair shop. At block 1245, the delivery ofthe parts is acknowledged by indicating each part received using an interface to the market server.

Figure 13 shows a flow diagram of one embodiment of a method 1300 for facilitating and processing auto parts transactions between multiple vendors and purchasers using the centralized processing system 201 described above. The method 1300 starts at block 1301 and proceeds to block 1305. At block 1305, a purchaser logs on to the system. As mentioned above, in one embodiment, the purchaser can establish a connection with the system via the Internet. However, the teachings ofthe present invention are equally applicable when the user connects to the system via a Local Area Network (LAN), a Wide Area Network (WAN), or other types of network connections. As described above, in one embodiment, the purchaser can use a client browser software such as the Netscape® Communicator software or the Microsoft® Internet Explorer software to communicate with the system (i.e., transmitting data to and receiving data from the system, etc.). For the purposes of the present specification, the Internet browser software or any other software program used by the user to communicate with the system is also referred to as the client program. Continuing with the present discussion, at decision block 1309, the method proceeds to block 1313 to perform an account registration function, to be described in more detail below, if the purchaser is a new user and has not established an account including account and user profile information with the system. Otherwise the method proceeds to block 1317. After performing the account registration function, the method also proceeds from block 1313 to block 1317. At block 1317, a default menu interface is displayed to the purchaser that allows the purchaser to invoke one ofthe functions that are described in more detail below. In one embodiment, after the purchaser logs on to the system, a summary status list for jobs that are within the user's account (i.e., purchaser's account) is generated and displayed to the purchaser to let him know at a high level the current status of the jobs including the status ofthe particular orders associated with each job. In the present specification, the term "job" may be used to refer to a work order or repair order or project with respect to a particular vehicle. The term "job" may also used to refer to any larger group of work to which one or more part orders belong for tracking purposes.

Continuing with the present discussion, the purchaser can elect to perform a number of different functions with respect to each job or each order being displayed based upon the current status of each respective job or order. The different functions that can be performed based upon the current status of the jobs or orders being displayed are described in more detail below.

Referring again to Figure 13, the method 1300 proceeds from block 1317 to block 1321 where the purchaser initiates a transaction activity or invokes a function. At decision block 1325, the method either proceeds to block 1331, block 1333, block 1335, block 1337, or block 1339, depending upon the function selected or activity initiated by the purchaser. At block 1331, a new order processing function is performed. The new order processing function is described in more detail below. At block 1333, the method 1300 performs an existing order processing function that includes order tracking and status function, order return function, order cancellation function, etc. These existing order processing functions are described in further detail below. At block 1335, a reporting function is performed. At block 1337, an account update function is performed. At block 1339, other functions are performed including user supporting functions.

The method then proceeds from block 1331, block 1333, block 1335, block 1337 or block 1339 to decision block 1351. At decision block 1351, the method 1300 loops back to block 1325 if there are more activities or functions to be performed. Otherwise the method 1300 proceeds to end at block 1391. Figure 14 illustrates a flow diagram of one embodiment of a process 1400 for creating/updating a purchaser account and profile information in the centralized processing system 201. The process 1400 starts at block 1401 and proceeds to block 1405 to display a purchaser account information user interface (UI) in response to a request made by the purchaser to create or update a purchaser account. The purchaser account information UI is used by the purchaser to enter his account information including the business name and address, contact information, etc. In addition, the purchaser account information UI also allows the purchaser to specify a market area (also referred to as the metropolitan area) in which the purchaser is located. The market area or metropolitan area information specified by the purchaser will be used by the system to perform various functions described herein including selecting the vendors that are located in the same metropolitan area with whom the purchaser may wish to do business. An example of a purchaser account information UI is shown in Figure 15 A. At block 1407, the purchaser account information entered by the purchaser using the purchaser account UI as shown in Figure 15A is obtained and stored in the transaction database. In response to the purchaser's request to continue with the account registration, the process 1400 proceeds to block 1409 to display a primary user login information user interface. This UI is provided to allow the purchaser to enter information about the primary user for the purchaser account including user name and password, level of access to certain functions within the centralized processing system, etc. In one embodiment, the purchaser is allowed to have multiple users with their own unique user-name/password combinations for logging on to the centralized processing system. This will allow for the tracking of individual usage and tailoring different levels of access to certain functions that are available in the centralized processing system. An example of a user interface allowing the purchaser to enter information with respect to one or more users ofthe purchaser account is illustrated in Figure 15B. Continuing with the present discussion, the process 1400 proceeds to block 1411 to obtain and store the user information entered by the purchaser. At block 1413, an account user summary is displayed to the purchaser showing the user information for each user in the purchaser account including the employee name, user name, password, and the corresponding permission level. An example of an account user summary is provided in Figure 15C. From this account user summary, the purchaser can select to delete one or more specific users in this list as well as adding more users to the purchaser account. The account user summary interface also allows the purchaser to modify the permission level assigned to each user in his account. The process then proceeds to block 1415 to display a local supplier (vendor) selection interface listing vendors that are located in the same metropolitan area as the purchaser. An example of a local vendor selection interface is shown in Figure 15D. Information about each vendor is displayed in this interface including vendor name and address, vendor contact information, etc. The interface also allows the purchaser to individually select the vendors with whom he wishes to conduct business and to assign a specific vendor type to each vendor selected. In one embodiment, a local vendor may be designated by the purchaser to be a primary local vendor, a secondary local vendor, or an alternate local vendor. The vendor type assigned to each selected vendor by the purchaser will be used by the system for various purposes that are described herein. In one embodiment, the primary vendors have the highest display preferences followed by the secondary vendors and then the alternate vendors. At block 1417, vendor selection information and vendor type information are obtained and stored in the transaction database. At block 1419, a matrix summary of local primary, secondary, and alternate vendors is displayed to the purchaser including the specific manufacturer/line carried by each selected vendor. An example ofthe matrix summary of local vendors is shown in Figures 15E and 15F.

The process 1400 then proceeds to block 1421 to display a "will ship" aftermarket vendor selection interface to allow the purchaser to select one or more vendors as the primary will-ship vendors, one or more vendors as the secondary will- ship vendors, and one or more vendors as the alternate will-ship vendors. An example of a will-ship aftermarket vendor selection is shown in Figure 15G. After the purchaser makes the selections with respect to the will-ship vendors, the process 1400 proceeds to block 1423 to obtain and store the will-ship vendors selection information in the transaction database. At block 1425, a matrix summary containing the selected will-ship aftermarket vendors by manufacturer/line is displayed. An example of a summary of will-ship vendors is illustrated in Figures 15H and 151. The process then proceeds to block 1427 to display a summary of all selected vendors including local aftermarket vendors and will-ship aftermarket vendors. An example ofthe summary of all selected vendors is shown in Figure 15J. The purchaser can specify, for each vendor displayed in the summary, a relative display order with respect to other vendors ofthe same vendor type. The relative display order specified by the purchaser will be used by the system in performing various functions including the catalog query and stock check processing functions to determine, as between two or more vendors ofthe same vendor type (e.g., primary local vendors), which vendor has a higher display priority. In one embodiment, a relative display priority for each vendor with respect to other vendors within the same vendor type can be specified by the purchaser using a drop down numeric menu. Vendor display priority information is stored in the transaction database at block 1429. The process 1400 then proceeds to block 1431 to allow the purchaser to specify, for each vendor selected, the vendor price display preferences. For each vendor in his profile, the purchaser can select a "selling price calculation method" option. The selling price can be selected by the purchaser to be either the vendor suggested selling price or another pricing method such as cost plus markup %. If the percentage markup on cost option is chosen, the purchaser enters a markup percentage that is used by the system to calculate the selling price. The purchaser can also select a cost display option for each vendor in his profile. The purchaser can specify whether cost is to be displayed or not. An example of a user interface allowing the purchaser to select vendor price display preferences is shown in Figure 15K. The process 1400 then proceeds to block 1433 to store the vendor price display preferences. At block 1435, an interface is provided to allow the purchaser to specify whether to display both primary and secondary vendors together or only primary vendors. An example of this interface is shown in Figure 15L. At block 1437, information about vendor default display preference is obtained and stored in the transaction database. At block 1439, the purchaser account and profile information as described above are stored in the transaction database. As described herein, the purchaser account and profile information provided by the purchaser and stored in the transaction database will be used for various purposes by the centralized system including allowing the purchaser to select a group of vendors of a particular vendor type for stock check and order purposes and tailoring the vendor display preferences in certain user interfaces based upon the preferences specified by the purchaser. The various uses of the purchaser account and profile information in performing certain system functions are described in more detail below. The process 1400 proceeds to end at block 1491.

Figure 16 shows a flow diagram of one embodiment of a process 1600 for creating/updating a vendor's account and profile information in the centralized system 201. The process 1600 starts at block 1601 and proceeds to block 1605 to display a vendor company information user interface in response to a request made by the user to create or update a vendor account. The vendor company information UI is used by the vendor to enter his company information including the business name and address, contact information, and business hours etc. In addition, vendor company information UI also allows the vendor to specify a market area (also referred to as the metropolitan area) in which the vendor is located. The market area or metropolitan area information specified by the vendor will be used by the system to perform various functions described herein including selecting the purchasers that are located in the same metropolitan area with whom the vendor may wish to do business. An example of a vendor account information UI is shown in Figure 17A. At block 1607, the vendor company information provided by the vendor using the UI as shown in Figure 17A is obtained and stored in the transaction database. In response to the vendor's request to continue with the account registration, the process 1600 proceeds to block 1609 to display a vendor services information user interface as shown in Figure 17B. This UI is provided to allow the vendor to enter information about the kinds of services that are offered by the vendor including the delivery options or services, shipping options, whether the vendor permits the purchasers to place parts on hold, and other terms and conditions relevant to the vendor's business, etc. The vendor services information is obtained and stored in the transaction database at block 1611. At block 1613, a vendor user authentication UI is displayed to allow the vendor to enter information for system access including user name and password, level of access to certain functions within the centralized processing system, etc. In one embodiment, the vendor is allowed to have multiple users with their own unique user-name/password combinations for logging on to the centralized processing system. This will allow for the tracking of individual usage and tailoring different levels of access to certain functions that are available in the centralized processing system. An example of a user interface allowing the vendor to enter information with respect to one or more users ofthe vendor account is illustrated in Figure 17C.

Continuing with the present discussion, the process 1600 proceeds to block 1615 to obtain and store the user information provided by the vendor. At block 1617, an account user summary is displayed to the vendor showing the user information for each user in the vendor account including the employee name, user name, password, and the corresponding permission level, etc. An example of an account user summary is provided in Figure 1-5D. In one embodiment, from this account user summary, the vendor can select to delete one or more specific users in this list as well as adding more users to the vendor account. The account user summary interface as shown in Figure 17D also allows the vendor to modify the permission level assigned to each user in his account. The process 1600 then proceeds to block 1619 to display a vendor manufacturer/line selection interface. This UI allows the vendor to specify specific lines of products from different manufacturers that are carried by the vendor. An example of this interface is illustrated in Figure 17E. At block 1621, the information with respect to the specific lines of products carried by the vendor is obtained and stored in the transaction database. At block 1623, a vendor parts sub-group selection interface is displayed to allow the vendor to specify information with respect to the various parts sub-groups for which the vendor is willing to provide stock check information to the purchasers. A parts sub-group, in one embodiment, is considered a subset of a larger set of different parts that are included within a particular line of product. In one embodiment, the vendor can specify a specific line code for each parts sub-group! An example of a parts sub-group selection interface is shown in Figure 17F. The process 1600 then proceeds to block 1625 to store the parts sub-group selection information in the transaction database. At block 1627, a vendor workflow procedures interface is provided to allow the vendor to specify information relevant to his transaction review and approval procedure, for example whether manual approval of all stock checks and orders is required, etc. This interface also allows the vendor to specify the pricing display options. An example of this user interface is illustrated in Figure 17G. The process 1600 then proceeds to block 1629 to obtain and store information with respect to the vendor workflow procedures in the transaction database. At block 1631 , an interface is displayed to allow the vendor to view a list of purchasers that are located in the same metropolitan area as the vendor. This interface allows the vendor to provide certain information (e.g., customer number, etc.) for the purchasers who already have accounts with the vendor. In addition, this interface allows the vendor to invite one or more purchasers listed to become his customers by sending a business invitation notice to the purchasers selected. An example of this interface is shown in Figure 17H. At block 1633, information provided by the vendor for the purchasers who already have accounts with him is stored in the transaction database. At block 1635, if the vendor indicates that he wants to invite one or more purchasers to become his customers, an interface will be displayed to allow the vendor to send invitations to the selected purchasers. The process 1600 then proceeds to end at block 1691.

Figure 18 illustrates a flow diagram of one embodiment of a method 1800 for facilitating and automating new orders of auto parts. The method 1800 starts at block 1801 and proceeds to block 1805. At block 1805, a part query request is received from a purchaser. As described above, in one embodiment, the purchaser can establish connection with the centralized processing system via a network (e.g., the Internet). The purchaser can use a client software program such as the Microsoft Internet Explorer or the Netscape Navigator browser software to communicate with the market server ofthe centralized processing system (i.e., transmit information to and receive information from the market server). In one embodiment, the purchaser can submit a part query request (also referred to herein as part lookup request or part search request) using the vehicle and part specification as the query criteria or using the part number and the manufacturer line code as query criteria. At block 1809, the market server performs a search in the part catalog to identify the part items that match the query criteria specified by the purchaser. The method 1800 then proceeds to block 1813 to display a list of part items retrieved from the part catalog that match the query criteria specified by the purchaser. In one embodiment, the purchase can select, from the list of part items being displayed, one or more specific part items to be stock checked. The purchaser can also specify, for each part item selected to be stock checked, one or more vendors to whom the stock check request is to be sent. At block 1817, a stock check request is received from the purchaser. At block 1821, the stock check request is stored in the transaction database. The method 1800 then proceeds to block 1825 to transmit the stock check request to the vendors selected by the purchaser to receive the stock check request. At block 1829, stock check responses are received from the selected vendors to whom the stock check request is sent. After receiving the stock check responses from the vendors, the method 1800 then proceeds to block 1833 to display the stock check responses to the purchaser. In one embodiment, the purchaser can select from the list of stock check responses one or more specific part items to be ordered. In one embodiment, for each part item selected to be ordered, the purchaser can specify one or more specific vendors to whom the part order is to be sent. At block 1837, a part order request for selected part items from selected vendors is received from the purchaser. The method 1800 then proceeds to block 1841 to store the part order request in the transaction database. At block 1845, the part order request is transmitted to the vendors. At block 1849, part order confirmations are received from the selected vendors to whom the part order request is sent. At block 1853, part order confirmations received from the vendors are displayed to the purchaser. The method 1800 proceeds to end at block 1891. The part query process (i.e., part lookup or part search), the stock check process, and the part order process are described in more detail below.

Figure 19 shows the flow diagram of one embodiment of a part query process 1900 as described above with respect to Figure 18. As mentioned above, the purchaser can perform a part search using either the vehicle and part specifications or using the part number and the manufacturer line code as the search or query criteria. The process 1900 starts at block 1901 and proceeds to block 1905 to display a first part search user interface showing a selectable list of vehicle years for the purchaser to select in order to perform a part query or search using the vehicle and part specification. The first part search interface also provides a box for the user to enter a specific part number for searching if the purchaser wishes to search by part number and manufacturer line code. An example ofthe first part search interface is provided in Figure 21 A. The process 1900 then proceeds to decision block 1909. At decision block 1909, the process 1900 proceeds to block 1913 to perform a part query by part number and manufacturer line code if the purchaser indicates that this is the method he wants to use for part search. Otherwise the process 1900 proceeds to block 1917 to perform the process of part search by vehicle and part specifications. At block 1917, in response to the user's selection of a specific vehicle year in the list of vehicle years, a list of vehicle makes corresponding to the specific year selected is displayed to the user. An example ofthe system's response to the user's selection of a specific vehicle year is shown in Figure 21B. At block 1921, in response to the user's selection of a specific vehicle make from the list of vehicle makes being displayed, a list of vehicle models corresponding to the specific vehicle make selected is displayed to the user as shown in Figure 21C. The process 1900 then proceeds to block 1925. At block 1925, in response to the user's selection of a specific vehicle model from the list of vehicle models being displayed, a list of various engine types corresponding to the vehicle model selected is displayed to the user as illustrated in Figure 21D. At block 1929, in response to the user's selection of a specific engine type being displayed, a list of parts groups corresponding to various subsystems ofthe specified vehicle (i.e., identified by vehicle year, vehicle make, vehicle model, and vehicle engine type) is displayed to the user as shown in Figure 2 IE. This list of parts groups allows the user to narrow down the part search by selecting or specifying more specific part information (part specification) ofthe specific part that the user wants to locate in the part catalog. At block 1933, in response to the user's selection of a specific part group being displayed, a list of parts subgroups corresponding to the part group selected is displayed to the user. The list of parts subgroups allows the user to further narrow down the part search. An example of a list of parts subgroups displayed as a result ofthe user's selection of a part group is shown in Figure 2 IF. The process then proceeds to block 1937. At block 1937, in response to the user's selection of a specific part subgroup being displayed, the system performs a search in the part catalog to retrieve the part items or entries that match the search criteria specified by the user. The process then proceeds to block 1941. At decision block 1941, if the number of part entries or items retrieved from the part catalog exceeds a predetermined number, for example 100, the process 1900 proceeds to block 1949, otherwise the process 1900 proceeds to block 1945. At block 1945, a list of part entries or items retrieved from the part catalog is displayed to the user. At block 1949, a multi-selectable list of part descriptions corresponding to the part subgroup selected is displayed to allow the user to further narrow down the part search, as shown in Figure 21 G. At block 1953, in response to the user's selection of one or more part descriptions being displayed, a list of part entries corresponding to the part description(s) selected is displayed to the user. An example of a parts catalog search results interface is shown in Figure 21H. The process 1900 proceeds to end at block 1991. In one embodiment, the part entries that are retrieved according to the search criteria specified by the user are filtered based upon the particular vendors that are selected by the user. For example, if the user selects primary local vendors as the vendors with whom the user wants to conduct the present business transactions, then only those part entries that belong to the specific lines of products carried by one or more primary local vendors are displayed to the user in the search results interface. Figure 20 shows a flow diagram of one embodiment of a process 2000 for performing a part search based upon a part number and a manufacturer line code provided by the purchaser. The process 2000 starts at block 2001 and proceeds to block 2005. At block 2005, the process 2000 proceeds to block 2009 after a part number is provided or entered by the purchaser. An example of an interface to allow the purchaser to enter a part number for a part search is shown in Figure 21 A. After the purchaser has entered a part number and indicated that he wants to continue with the part search, the process 2000 proceeds to block 2007 to display an interface to allow the purchaser an option of either entering a specific manufacturer line code or selecting a valid manufacturer line code to be used in conjunction with the part number for the part search. An example of this user interface is illustrated in Figure 2 II. The process then proceeds to block 2009. At decision block 2009, depending on whether the user chooses to enter a specific manufacturer line code, the process either proceeds to block 2013 or block 2019. At block 2013, if the user chooses not to enter a specific line code, the user is allowed to select a specific letter from an alphabetical selection list in order to proceed with the search without entering a specific manufacturer line code. An example ofthe alphabetical selection list is shown in Figure 211. At block 2015, in response to the user's selection of a specific letter from the alphabetical selection list, a list of manufacturers whose names beginning with the letter selected by the user is displayed to the user, as shown in Figure 21 J, for him to further narrow down the search. At block 2017, in response to the user's selection of a specific manufacturer being displayed, a user interface listing various parts subgroups with corresponding line codes is displayed to the user as shown in Figure 2 IK. This interface allows the user to select one or more specific line codes corresponding to one or more specific parts subgroups being displayed in order to continue with the part search. In one embodiment, the user can select the specific line codes by clicking on the selection boxes corresponding to the specific parts subgroups being displayed as shown in Figure 2 IK. The process 2000 then proceeds from block 2017 to block 2023. Referring again to Figure 20, the process 2000 proceeds from block 2009 to block 2019 if a specific line code is entered by the user using an interface as shown in Figure 211. At block 2019, the specific line code entered by the user is validated to determine whether it is a valid manufacturer line code. At decision block 2021, the process 2000 proceeds to block 2013 if the line code entered or provided by the user is not valid. Otherwise the process 2000 proceeds to block 2023. At block 2023, the process 2000 retrieves part entries in the part catalog that match the part number and the manufacturer line code that is either provided or selected by the user as described above. At decision block 2025, the process 2000 proceeds to block 2027 to display the part entries retrieved from the part catalog if there are part entries in the part catalog that mach the criteria provided by the user (i.e., the part number and the manufacturer line code). An example ofthe part catalog search results is shown in Figure 21L. In one embodiment, the part entries that are retrieved according to the search criteria specified by the user are filtered based upon the particular vendors that are selected by the user. For example, if the user selects primary local vendors as the vendors with whom the user wants to conduct the present business transactions, then only those part entries that belong to the specific lines of products carried by one or more primary local vendors are displayed to the user in the search results interface. If there is no entry in the part catalog matching the search criteria provided by the user, the process 2000 proceeds to block 2029 to display a message indicating to the user that there is no match found as shown in Figure 21M. In this case, the user is still allowed to submit a stock check request to a part vendor even if there is no part entry in the part catalog that matches the part number and the manufacturer line code provided by the user. As shown in Figure 21M, the user can continue with the stock check process by clicking on the "check stock" button. Assuming in this case that the user wants to continue with the stock check process. At block 2031, in response to the user's indication to perform a stock check on the part item that is not found in the part catalog, the process 2000 display a vendor selection interface as shown in Figure 2 IN to allow the user to select a specific vendor to whom the stock check request is to be sent. After the user selects a specific vendor and requests the stock check to be sent, the process 2000 then proceeds to block 2033 to perform the stock check processing function that is described in more detail below. The process 2000 proceeds from either block 2027 or block 2033 to end at block 2091.

Figure 22 illustrates a high level flow diagram of one embodiment of a method 2200 for performing a stock check function utilizing the centralized processing system described above. The method 2200 starts at block 2201 and proceeds to block 2205 to display a list of part entries matching the query criteria specified by the user. The part query process to search the part catalog for part entries matching the query criteria provided by the user is described in detail above. An example of a user interface or screen that is used to display the list of matching part entries is shown in Figure 21H. In one embodiment, as shown in Figure 21H, the matching part entries or catalog search results are displayed in a matrix format with multiple rows and columns where the rows correspond to the part entries and the columns correspond to various pieces of information pertaining to the specific part entries (e.g., part number, part description, list price, etc.). In one embodiment, as illustrated in Figure 21H, the user can change the sort order ofthe part entries being displayed. For example, as shown in Figure 21H, the user can toggle between sorting the matching part entries by part description or sorting by manufacturer line by clicking on the sort selection button 2107. As described above, in one embodiment, the vendor display order for the catalog search results can be specified by the purchaser during the account registration/update process. In one embodiment, the default vendor display order with respect to the catalog search results are as follows:

1. Primary vendors alone, in the order specified by the purchaser in the user account and profile information. The vendor with the highest rank (i.e., #1) is displayed in the left-most available column.

2. Primary and Secondary vendors combined, in the order specified by the user in the user account and profile information. The vendor with the highest rank (i.e., #1) is displayed in the left-most available column.

3. Secondary vendors, in the order specified by the user in the user account and profile information. The vendor with the highest rank (i.e., #1) is displayed in the leftmost available column. 4. Alternate vendors, in the order specified by the user in the user account and profile information. The vendor with the highest rank (i.e., #1) is displayed in the leftmost available column.

Continuing with the present discussion, in one embodiment, the vendors that carry the specific part items being displayed are indicated or made known to the user by providing a corresponding selection box 2113 for each vendor that carries the specific part item, as shown in Figure 21H. The process 2200 then proceeds to block 2209 to allow the user to individually select one or more specific part items to be stock checked. In one embodiment, the user is provided a check box 2111 for each part item to select or click on if he wants the respective part item to be stock checked. At block 2213, for each part item to be stock checked, the user is allowed to specify the required quantity of the respective part item by entering a number in a quantity box 2109 provided. At block 2217, for each part item to be stock checked, the user is allowed to select one or more vendors to whom the stock check request is to be sent. In one embodiment, the vendors that can be selected by the user are vendors who carry the specific product line to which the specific part item to be stock checked belongs. In one embodiment, the user can select the vendors by clicking on the vendor selection box 2113 as shown in Figure 21H. In response to the user's command or indication to submit a stock check request for the selected parts to the selected vendors, the method 2200 proceeds to block 2221 to create one or more stock check requests based upon the user's selections. At block 2225, the stock check requests are sent to the selected vendors. At block 2229, stock check responses for the selected part items are received from the selected vendors. At block - 2233, the stock check responses received from the vendors are displayed to the user. An example of a user interface for displaying the stock check responses or results to the user is shown in Figure 23, the detail of which is described below. The method 2200 then proceeds to end at block 2291.

Figure 24 shows a detailed flow diagram of one embodiment of a method 2400 for performing stock checks as described above with respect to Figure 22. In one embodiment, as described herein, the various components or subsystems ofthe centralized processing system work together to facilitate and process various types of transactions including stock check requests, order requests, etc. The flow diagram as shown in Figure 24 describes the various tasks performed by the different components of the centralized processing system and the interactions thereof to process stock check requests submitted by users of the system (i.e., purchasers of auto parts). For clarity, the various tasks performed by the different components of the centralized processing system (e.g., the market server, the database converter, and the vendor gateway, etc.) and the interactions thereof are described below in a sequential manner. However, it would be obvious to one skilled in the art that many of these tasks can be performed in parallel or concurrently unless there are true logical dependencies between them. In one embodiment, the market server, the database converter, and the vendor gateway subsystems can perform their corresponding functions in parallel (i.e., running separate threads or separate programs in parallel). Furthermore, for clarity and simplicity, the discussion that follows is sometimes focused the processing of a stock check request by one user ofthe system even though everything discussed herein equally applies to the processing of multiple stock check requests by multiple users ofthe system. Referring again to Figure 24, the stock check process 2400 starts at block 2401.

At block 2403, the market server receives a stock check request from a user ofthe system. A detailed description of how the user submits a stock check request to the market server is provided above. At block 2405, the market server updates the transaction database with the new stock check request submitted by the user. As described above, in one embodiment, the transaction database contains various tables that are used for various purposes including storing the relevant information pertaining to stock check requests and responses, order requests and confirmations, etc. In one embodiment, the market server updates the corresponding tables (i.e., the stock-check- requests table and the stock-check-items table) in the transaction database to add the new stock request and its corresponding stock check items. After updating the transaction database with the new stock check request, the market server proceeds to block 2407 to wait for the corresponding stock check response. In one embodiment, the corresponding stock check response once received from the selected vendor is stored in the transaction database. At decision block 2409, if the stock check response is available in the transaction database (i.e., it has been received from the vendor and stored in the transaction database), the market server proceeds to block 2411 to retrieve the corresponding stock check response from the transaction database and displays it to the user. Otherwise the market server loops back to block 2407 to wait for the stock check response. The market server then loops back from block 2411 to block 2403 to continue processing new stock check requests. While the market server is performing its corresponding function in processing new stock check requests and responses, the database converter and the vendor gateway subsystem are also performing their corresponding functions in parallel. At block 2431, the database converter scans the transaction database for new stock check requests. At decision block 2433, the database converter proceeds to block 2435 if new stock check requests are found in the transaction database. Otherwise the database converter loops back to block 2431 to continue scanning the transaction database for new stock check requests. At block 2435, for each stock check request found in the transaction database, the database converter updates the message database accordingly to add a new stock check request message and corresponding request item messages. In one embodiment, as described above, the message data base contains a set of message tables used to store the relevant information relating to the various types of transactions including stock check request messages, order placement request messages, etc. In one embodiment, for each new stock check request found in the transaction database, the database converter adds a new record or row to a table called the order table and sets the message type ofthe new record to a particular value (e.g., STKREQ) to indicate that the newly added record is a new stock check request message. For each part item included in the new stock check request found in the transaction database, the database converter also adds a corresponding record or row to a table called the Requestltem table and set the corresponding message type to a particular value (e.g., STKREQ) to indicate that newly added item in the Requestltem table is for a new stock check request. The new stock check request messages and their corresponding request item messages created by the database converter will be used by the vendor gateway subsystem as described below. At block 2439, the database converter scans the message database for new stock check responses received from the vendors. In one embodiment, the database converter performs a select on the Order table and Requestltem table looking for those rows or records in the tables with the message type set to a particular value indicating stock check response records (e.g., message type = STKRESP). At block 2441, if there are new stock check response messages found in the message database, the database converter proceeds to block 2443. Otherwise the database converter loops back to block 2439 to continue scanning the message database for new stock check responses. At block 2443, the database converter updates the transaction database accordingly with the new stock check response messages found in the message database. After updating the transaction database with the new stock check responses found in the message database, the database converter sets the message type ofthe corresponding records in the Order and the Requestltem tables in the message database to a particular value indicating that these records have been used to update the transaction database (e.g., message type = STKUPDT) so that these records will not be processed again the next time the database converter scans the message database for new stock check responses. The database converter then loops back to block 2431 to continue processing new stock check requests and responses. Continuing with the present discussion, while the market server and the database converter perform their corresponding functions in processing stock check requests and responses, the vendor gateway subsystem also perform its corresponding function in parallel. At block 2461, the vendor system interface (VSI) component ofthe vendor gateway subsystem scans the message database for new stock check request messages. In one embodiment, the VSI performs a select on the Order table and the Requestltem table looking for those records or rows with the message type set to a particular value (e.g., STKREQ). At block 2463, if there are any new stock check request messages found in the message database, the VSI proceeds to block 2465. Otherwise the VSI loops back to block 2461 to continue scanning the message database for new stock check request messages. At block 2465, the VSI submits the new stock check requests found in the message database to the appropriate vendors selected by the user to receive the stock check requests. As disclosed above, depending upon the type of connection and the communication protocol used the by selected vendors, the VSI performs the appropriate communication tasks to exchange information with the corresponding vendors. At block 2467, the VSI receives stock check response information from the vendors' systems. At block 2469, the VSI updates the message database accordingly with the stock check response information received from the vendors. In one embodiment, the VSI creates a new stock check response record or row in the StockCheckResponse table for each part item in the Requestltem table based upon the stock check response information received from the vendors. The VSI also updates the message type ofthe corresponding records in the Order and Requestltem tables to a particular value (e.g., STKRESP) that is used by the database converter in scanning the message database for new stock check responses, as described above. In one embodiment, if the vendors have alternate or substitute parts for a part item, additional records or rows are created in the StockCheckResponse table with the same ItemID as the one used for the original part. The VSI then loops back to block 2461 to continue processing new stock check requests and responses. As described above, the market server, the database converter, and the vendor gateway work in a coordinated fashion to perform several tasks in processing the stock check requests and stock check responses.

Figure 25 illustrates a high level flow diagram of one embodiment of a method 2500 for performing an order placement function utilizing the centralized processing system described above. The method 2500 starts at block 2501 and proceeds to block 2505 to display a list of stock check responses (also referred to as stock check results) that are received from the vendors and stored in the transaction database as described above with respect to the stock check process. The stock check process to submit stock check requests to and receive stock check responses from selected vendors is described in detail above. An example of an interface or screen that is used to display the list of stock check responses or results is shown in Figure 23. In one embodiment, as shown in Figure 23, the stock check responses or results are displayed in a matrix format with multiple rows and columns where the rows correspond to the specific part items and the columns correspond to various pieces of information pertaining to the specific part items (e.g., part number, part description, cost, quantity available, etc.). In one embodiment, as illustrated in Figure 23, the user can change the sort order ofthe part entries being displayed. For example, as shown in Figure 23, the user can toggle between sorting the stock check results by part description or by manufacturer line by clicking on the sort selection button 2307. As described above, in one embodiment, the vendor display order for the stock check results can be specified by the purchaser during the account registration/update process. In one embodiment, the default vendor display order with respect to the stock check results are as follows:

3. Secondary vendors, in the order specified by the user in the user account and profile information. The vendor with the highest rank (i.e., #1) is displayed in the leftmost available column.

4. Alternate vendors, in the order specified by the user in the user account and profile information. The vendor with the highest rank (i.e., #1) is displayed in the leftmost available column. The process 2500 then proceeds to block 2509 to allow the user to individually select one or more specific part items to be ordered. At block 2513, the user is allowed to select one or more specific vendors being displayed to whom the order placement request for the selected item is to be sent. In one embodiment, for each part item in the stock check results list and for each vendor that has provided the corresponding stock check response for the respective part item being displayed, the user is provided a check box 2311 as shown in Figure 23 to select the specific part item to be ordered from the corresponding vendor. In one embodiment, the user can select the specific part items to be ordered from the corresponding vendors by clicking on the order selection box 2311 as shown in Figure 23. At block 2517, in response to the user's command or indication to submit an order placement request for the selected part items, the method 2500 creates one or more order placement requests based upon the user's selections. At block 2521, the order placement requests for the selected part items are sent to the selected vendors. At block 2525, order placement confirmations for the selected part items are received from the selected vendors. At block 2529, the order confirmations for the selected part items from the selected vendors are displayed to the user. The method 2500 then proceeds to end at block 2591. Figure 26 shows a detailed flow diagram of one embodiment of a method 2600 for performing an order placement processing function as described above with respect to Figure 25. In one embodiment, as described above, the various components or subsystems of the centralized processing system work together to facilitate and process various types of transactions including stock check requests, order requests, etc. The flow diagram as shown in Figure 26 describes the various tasks performed by the different components ofthe centralized processing system and the interactions thereof in order to process order placements requests submitted by users ofthe system (i.e., purchasers of auto parts). Again, for clarity, the various tasks performed by the different components ofthe centralized processing system (e.g., the market server, the database converter, and the vendor gateway, etc.) and the interactions thereof are described below sequentially. However, it would be obvious to one skilled in the art that many of these tasks can be performed in parallel or concurrently unless there are true logical dependencies between them. In one embodiment, the market server, the database converter, and the vendor gateway subsystems also perform their corresponding functions in parallel (i.e., running separate threads or separate programs in parallel). Furthermore, for clarity and simplicity, the discussion that follows is sometimes focused the processing of an order placement request by one user ofthe system even though everything discussed herein equally applies to the processing of multiple order placement requests submitted by multiple users ofthe system.

Referring to Figure 26, the order placement process 2600 starts at block 2601. At block 2611, the market server receives an order placement request from a user ofthe system. A detailed description of how the user submits an order placement request to the market server is disclosed above. At block 2615, the market server updates the transaction database with the new order placement request submitted by the user. As described above, in one embodiment, the transaction database contains various tables that are used for various purposes including storing the relevant information pertaining to stock check requests and responses, order requests and confirmations, etc. In one embodiment, the market server updates the corresponding tables (i.e., the Orders table and Orderltem table) in the transaction database to add the new order placement request and its corresponding order items. At block 2607, the market server waits for the order confirmation. In one embodiment, the corresponding order confirmation once received from the selected vendor is stored in the transaction database. At decision block 2619, if the order confirmation has been received and stored in the transaction, the market server proceeds to block 2621 to retrieve the order confirmation from the transaction database and displays it to the user. Otherwise the market server loops back to block 2617 to wait for the order confirmation. The market server then loops back from block 2621 to block 2611 to continue processing new order placement requests.

As explained above, while the market server is performing its corresponding function in processing new order placement requests and confirmations, the database converter and the vendor gateway subsystems are also performing their corresponding functions in parallel to process order requests and confirmations. At block 2641, the database converter scans the transaction database for new order placement requests. At decision block 2643, the database converter proceeds to block 2645 if new order placement requests are found in the transaction database. Otherwise the database converter loops back to block 2641 to continue scanning the transaction database for new order placement requests. At block 2645, for each new order placement request found in the transaction database, the database converter updates the message database accordingly to reflect that a new order request has been submitted for selected part items. In one embodiment, as described above, the message data base contains a set of message tables used to store the relevant information relating to the various types of transactions including stock check request messages, order placement request messages, etc. In one embodiment, for each new order placement request found in the transaction database, the database converter updates corresponding records in the Order and the Requestltem tables (these records were already created during the stock check processing phase as described above) to reflect that the corresponding part items that were previously stock checked are now to be ordered. In one embodiment, this is done by updating the message type ofthe corresponding records in the Order and Requestltem tables to a particular value, for example ORDREQ. The database converter also updates other information of the corresponding records if necessary, for example changing the request quantity to the quantity to be ordered. The message type information will be used by the vendor gateway subsystem to perform its corresponding function as described below. At block 2649, the database converter scans the message database for new order confirmations (also referred to as order responses) received from the vendors. In one embodiment, the database converter performs a select on the Order table and Requestltem table looking for those rows or records in the tables with the message type set to a particular value indicating order confirmation records (e.g., message type = ORDCONF). At block 2651 , if there are new order confirmation messages found in the message database, the database converter proceeds to block 2653. Otherwise the database converter loops back to block 2649 to continue scanning the message database for new order confirmations. At block 2653, the database converter updates the transaction database accordingly with the new order confirmation information found in the message database. After updating the transaction database with the new order confirmations found in the message database, the database converter sets the message type ofthe corresponding records in the Order and the Requestltem tables in the message database to a particular value (e.g., ORDUPDT) so that they will not be used again the next time the database converter scans the message database for new order confirmations. The database converter then loops back to block 2641 to continue processing new order placement requests and confirmations.

Continuing with the present discussion, while the market server and the database converter perform their corresponding functions in processing order requests and confirmations, the vendor gateway subsystem also perform its corresponding function in parallel. At block 2661, the vendor system interface (VSI) component ofthe vendor gateway subsystem scans the message database for new order placement request messages. In one embodiment, the VSI performs a select on the Order table and the Requestltem table looking for those records or rows with the message type set to a particular value (e.g., ORDREQ). At block 2663, if there are any new order placement request messages found in the message database, the VSI proceeds to block 2665.

Otherwise the VSI loops back to block 2661 to continue scanning the message database for new order request messages. At block 2665, the VSI submits the new order placement requests found in the message database to the appropriate vendors selected by the user to receive the order requests. As disclosed above, depending upon the type of connection and the communication protocol used the by selected vendors, the VSI performs the appropriate communication tasks to exchange information with the corresponding vendors. At block 2667, the VSI receives order confirmation information from the vendors' systems. At block 2669, the VSI updates the message database accordingly with the new order confirmation information received from the vendors. In one embodiment, the VSI creates a new order response record or row in the OrderResponse table for each part item ordered based upon the order confirmation information received from the vendors. The VSI also updates the message type ofthe corresponding records in the Order and Requestltem tables to a particular value (e.g., ORDCONF) that is used by the database converter in scanning the message database for new order confirmations, as described above. The VSI then loops back to block 2661 to continue processing new order requests and confirmations. As described and explained herein, the market server, the database converter, and the vendor gateway work in a coordinated fashion to perform several tasks in processing the order placement requests and order confirmations.

Figure 27 illustrates a flow diagram of a method 2700 for providing job status information to the users and for allowing the users to initiate certain activities or functions based upon the status information provided. The method 2700 starts at block 2701 and proceeds to decision block 2705. At decision block 2705, the method 2700 proceeds to block 2711 if the user has indicated that he wants to obtain status information with respect to the open jobs in his account. Otherwise the method 2700 proceeds to block 2751. In one embodiment, status of the open jobs is the default option unless the user has indicated otherwise. As described above, transactional information including job information, stock check information, and order information, etc. are stored in the transaction database in various tables. In one embodiment, as disclosed above, the transaction database is structured as a relational database and the various tables are linked together or cross-referenced using certain data fields in the records as keys. For example, as explained above with respect to Figures 4, 5, and 6, each record in the PurchaserAccounts table includes a purchaser ID that can be used to cross-reference, locate, or select the corresponding jobs in the Job table. Similarly, each record in the Job table includes a Job ID that can be used to locate or select associated order records that are stored in the Orders table, etc. At block 2711 , the status information for the open jobs in the user's account are retrieved from the transaction database and a status summary ofthe open jobs in the user's account is displayed to the user as shown in Figure 28A. As mentioned above, each job may contain multiple order transactions that may have different statuses. In one embodiment, as illustrated in Figure 28A, the status information for each job includes the job name/description and the summary information for each order that belongs to the respective job. The summary information for each order may include the order number, the current status ofthe order, and the name ofthe vendor with whom the order is placed. The purchaser can further review more detailed information concerning each particular vendor or each particular order by selecting the appropriate options (e.g., hyperlinks) that are provided in the status summary screen. For example, the user can select a particular vendor name hyperlink 2809 to view more detailed information about that particular vendor. Likewise, the user can obtain more detailed status information of a particular order by selecting the corresponding order number hyperlink 2811 being displayed.

As illustrated in Figure 28 A, the purchaser is also allowed to perform a number of different functions based upon the current status of the orders associated with each job being displayed. For example, for each ofthe jobs that has no active orders (i.e., the current status is "catalog", "stock check", or "order in process"), the purchaser is allowed to cancel the respective job. As shown in Figure 28 A, a "cancel job" option 2815 is provided to allow the user to cancel the job if it has no active orders. The user can select to cancel these jobs by clicking on the "cancel job" option 2815. For each of those jobs whose order's current status is "order not verified" or "estimate", the purchaser is allowed to cancel the corresponding order by selecting the "cancel order" option 2817. Moreover, if the current status of the job being displayed is "catalog", the user can select the appropriate hyperlink (e.g., catalog hyperlink 2819) to view the parts catalog search results previously obtained for the user. Similarly, the user can select the stock check hyperlink 2823 to view stock check results or the estimate hyperlink 2829 to go to an estimate user interface or screen.

Referring again to Figure 2700, at block 2713, in response to the user's selection of a vendor hyperlink 2809, more detailed information about that particular vendor including business name and address, contact information, work schedules, etc. are retrieved from the transaction database and displayed to the user. An example of a screen showing more detailed information about the selected vendor is shown in Figure 28B. At block 2715, in response to the user's selection of an order number hyperlink 2811, a detailed order status history ofthe selected order is retrieved and displayed to the user as shown in Figures 28C and 29. At block 2717, in response to the user's selection to cancel a job, a job cancellation function is performed to cancel the selected job. In one embodiment, a cancel confirmation screen or message is displayed to the user as shown in Figure 30 to allow the user to confirm whether he indeed wants to cancel the job selected. At block 2719, in response to the user's indication to cancel an order being displayed, an order cancel function is performed to cancel the selected order. In one embodiment, an order cancel confirmation screen or message is displayed to the user to allow him to confirm whether he indeed wants to cancel the particular order selected. At block 2721, in response to the user's selection of a catalog hyperlink, a list of part catalog search results previously obtained and stored in the transaction database for the respective job is retrieved and displayed to the user to allow him to continue the transaction processing (e.g., perform a stock check, etc.) if he wishes to do so. An example of a parts catalog search results interface is given in Figure 21H and described in detail above with respect to the part query and stock check functions.

Continuing with the present discussion, at block 2723, in response to the user's selection of a stock check hyperlink being displayed, stock check results previously obtained and stored in the transaction database for the respective job are retrieved and displayed to the user. An example and a detailed description ofthe stock check results screen are provided above. At block 2725, in response to the user's selection of an estimate hyperlink, an estimate interface as shown in Figure 31 is presented to the user. The method 2700 then proceeds to end at block 2791. Referring again to Figure 27, the method proceeds to block 2751 if the user has indicated that he wants to view status ofthe completed jobs. In one embodiment, completed jobs are jobs that have been closed or canceled by the user. At block 2751 , a summary of status information for all completed jobs within the user's account is displayed to the user based upon information retrieved from the transaction database. An example of a user interface showing a summary of completed jobs is shown in Figure 32. The user is also allowed to perform a number of different functions from this interface. For example, the user can select any vendor name hyperlink to view more detailed information about that particular vendor. For each job being displayed in the summary, the user is also allowed to initiate a specific action depending upon the status ofthe job (e.g., whether it is closed or cancelled). In one embodiment, if the status of a job is completed, an "add parts" option is displayed in the action column as shown in Figure 32 to allow the user to conduct more transactions with respect to that particular job. If the user selects this option (e.g., clicking on the corresponding "add parts" hyperlink), a parts group user interface as shown in Figure 2 IE will be displayed to the user to allow him to locate one or more parts. If the status of a job is cancelled, a "re- open" option is displayed in the action column as shown in Figure 32 to allow the user to re-open the job for further processing. In one embodiment, if the user selects this option (e.g., clicking on the corresponding "re-open" hyperlink), a parts group user interface as shown in Figure 21 E will be displayed to the user.

Continuing with the present discussion, the method 2700 proceeds from block 2751 to block 2753 in response to the user's selection of a vendor name hyperlink. At block 2753, more detailed information about that particular vendor including business name and address, contact information, work schedules, etc. are retrieved from the transaction database and displayed to the user. An example of a screen showing more detailed information about the selected vendor is shown in Figure 28B. At block 2755, in response to the user's selection of an "add parts" function, a parts group user interface as shown in Figure 21E is displayed to the user. At block 2757, in response to the user' selection of a "re-open" function, a parts group user interface as shown in Figure 2 IE is displayed to the user. The method 2700 then proceeds to end at block 2791.

Figure 35 shows a flow diagram of a process 3500 for providing the order status history of an order and for allowing the user to perform certain functions with respect to the part items on the order based upon the current status of those part items. The process 3500 starts at block 3501. At block 3501 , in response to the user's request to view the detailed status of a particular order in his account, the detailed status history of each part item on that particular order is retrieved from the transaction database. In one embodiment, as described above, the user can select a specific order being displayed in the job summary status list as shown in Figure 28 A to view the detailed status of that specific order. An example of an order detailed status history is shown in Figure 33 that includes, for each item on the order, the part item description, the stock check status if applicable, the order status if applicable, the return status if applicable, and the core pick-up status if applicable. As explained above, a particular part item on an order transaction may have a particular status depending upon what phase ofthe transaction process the part item is in. For example, if the order for a particular part item has been sent to the vendor but has not been accepted, the status history will show the activities that have occurred up to and including the fact that the order has been sent. If the order for a particular part item has been accepted and that part item has been shipped by the vendor, the status history will display information reflecting that such activities have occurred. Therefore, by viewing the detailed status history of any particular order as shown in Figure 33, the user is able to determine not only the current status of each part item on the order (e.g., whether the order has been accepted, whether the part has been shipped, etc.) but also the history ofthe transaction activities leading up to the current status (e.g., when the catalog search was performed, when the stock check was performed, when the order was sent, etc.). In one embodiment, depending upon the current status of a particular part item on the order, the user is allowed to perform certain functions with respect to that particular part item on the order. For example, if the part item ordered has been shipped or delivered, the user is allowed to submit a return request for that particular part item to the vendor, etc.

Referring again to Figure 35, at block 3509, the current status of a part item on the order is determined. At decision block 3513, based on the current status ofthe respective part item, the process proceeds to block 3517 if the user is allowed to submit a cancel request for that particular part item on the order. Otherwise the process proceeds to block 3521. At block 3517, the respective part item is marked to indicate that the user is allowed to submit a cancel request therefor if he wishes to do so. In one embodiment, a "cancel" option or hyperlink is displayed in the action column ofthe respective part item as shown in Figure 33 that can be selected by the user to submit a cancel request. At block 3521 , the process proceeds to block 3525 if the user is allowed to submit a return request based upon the current status ofthe respective part item. Otherwise the process proceeds to block 3529. At block 3525, the respective part item is marked to indicate that the user is allowed to submit a return request therefor if he wishes to do so. In one embodiment, a "return" option or hyperlink is displayed in the action column of the respective part item as shown in Figure 28C that can be selected by the user to submit a return request. At decision block 3529, the process loops back to block 3509 if there are more part items on the order to process. Otherwise the process proceeds to block 3533 to display a detailed status history of each part item on the order as shown in Figure 33 or Figure 28C. At block 3537, in response to the user's selection to submit a cancel request (e.g., selecting the corresponding "cancel" option or hyperlink provided in the action column), a cancellation function is performed with respect to the part item selected. A detailed description ofthe cancellation function is provided below. At block 3541, in response to the user's selection to submit a return request for a specific part item being displayed, a return authorization request user interface as shown in Figure 34 is displayed to the user to allow him to enter relevant information with respect to the return request to be submitted to the vendor. Such information may include the quantity to return and the reason for return, etc. as illustrated in Figure 34. At block 3545, in response to the user's selection to submit the return request, a return function is performed. The return function is described in more detail below. The process then proceeds to end at block 3591. Figure 36 shows a detailed flow diagram of one embodiment of a method 3600 for performing a cancel processing function as described above with respect to Figure 35. In one embodiment, as described above, the various components or subsystems ofthe centralized processing system work together to facilitate and process various types of transactions including stock check requests, order requests, cancel requests, return requests, etc. The flow diagram as shown in Figure 36 describes the various tasks performed by the different components ofthe centralized processing system and the interactions thereof in order to process cancellation requests submitted by one or more users ofthe system (i.e., purchasers of auto parts). For clarity, the various tasks performed by the different components ofthe centralized processing system (e.g., the market server, the database converter, and the vendor gateway, etc.) and the interactions thereof are described below sequentially. However, it would be obvious to one skilled in the art that many of these tasks can be performed in parallel unless there are true logical dependencies between them. In one embodiment, the market server, the database converter, and the vendor gateway subsystems perform their corresponding functions in parallel (i.e., running separate threads or separate programs in parallel). Furthermore, for clarity and simplicity, the discussion that follows is sometimes focused the processing of a cancellation request by one user ofthe system even though everything discussed herein equally applies to the processing of multiple cancellation requests by multiple users of the system.

Referring to Figure 36, the cancellation process 3600 starts at block 3601. At block 3611 , the market server receives a cancellation request for a particular part item from a user ofthe system. A detailed description of how the user submits a cancellation request for a particular part item associated with a particular part order to the market server is disclosed above. At block 3615, the market server updates the transaction database with the new cancellation request submitted by the user. As described above, in one embodiment, the transaction database contains various tables that are used for various purposes including storing the relevant information pertaining to stock check requests and responses, order requests and confirmations, cancellation requests and confirmations, return requests and return authorizations, etc. In one embodiment, the market server updates the corresponding tables (i.e., the Orders table and Orderltem table) in the transaction database to indicate, for each part item to be cancelled, that the respective part item has been requested by the user to be cancelled. At block 3617, the market server waits for the cancellation confirmation. In one embodiment, the corresponding records in the transaction database are updated accordingly once the cancellation confirmations for the respective parts are received from the vendor. At decision block 3619, if the cancellation confirmation has been received and updated in the transaction database, the market server proceeds to block 3621 to retrieve the cancellation confirmation from the transaction database and displays it to the user. Otherwise the market server loops back to block 3617 to wait for the cancellation confirmation. The market server then loops back from block 3621 to block 3611 to continue processing new cancellation requests and confirmations. As explained above, while the market server is performing its corresponding function in processing cancellation requests, the database converter and the vendor gateway subsystems are performing their corresponding functions in parallel to process cancellation requests and confirmations. At block 3641, the database converter scans the transaction database for new cancellation requests. At decision block 3643, the database converter proceeds to block 3645 if new cancellation requests are found in the transaction database. Otherwise the database converter loops back to block 3641 to continue scanning the transaction database for new cancellation requests. At block 3645, for each new cancellation request found in the transaction database, the database converter updates the message database accordingly to reflect that a cancellation request has been submitted for selected part items. In one embodiment, as described above, the message database contains a set of message tables that are used to store the relevant information relating to the various types of transactions including stock check request messages, order placement request messages, cancellation requests, return requests, etc. In one embodiment, for each new cancellation request found in the transaction database, the database converter updates corresponding records in the Order and the Requestltem tables (these records were already created during the stock check processing phase as described above) to reflect that the corresponding part items are to be cancelled. In one embodiment, this is done by updating the message type ofthe corresponding records in the Order and Requestltem tables to a particular value, for example CANREQ. The database converter also updates other information ofthe corresponding records if necessary, for example changing the quantity to the quantity to be cancelled. The message type information will be used by the vendor gateway subsystem to perform its corresponding function as described below. At block 3649, the database converter scans the message database for new cancellation confirmations (also referred to as cancellation approval) received from the vendors. In one embodiment, the database converter performs a select on the Order table and Requestltem table looking for those rows or records in the tables with the message type set to a particular value indicating cancellation confirmation records (e.g., message type = CANCONF). At block 3651, if there are new cancellation confirmation messages found in the message database, the database converter proceeds to block 3653. Otherwise the database converter loops back to block 3649 to continue scanning the message database for new cancellation confirmations. At block 3653, the database converter updates the transaction database accordingly with the new cancellation confirmation information found in the message database. After updating the transaction database with the new cancellation confirmations found in the message database, the database converter sets the message type ofthe corresponding records in the Order and the Requestltem tables in the message database to a particular value (e.g., CANUPDT) so that they will not be used again the next time the database converter scans the message database for new cancellation confirmations. The database converter then loops back to block 3641 to continue processing new cancellation requests and confirmations.

Continuing with the present discussion, while the market server and the database converter perform their corresponding functions in processing cancellation requests and confirmations, the vendor gateway subsystem also performs its corresponding function. At block 3661, the vendor system interface (VSI) component ofthe vendor gateway subsystem scans the message database for new cancellation request messages. In one embodiment, the VSI performs a select on the Order table and the Requestltem table looking for those records or rows with the message type set to a particular value (e.g., CANREQ). At block 3663, if there are any new order placement request messages found in the message database, the VSI proceeds to block 3665. Otherwise the VSI loops back to block 3661 to continue scanning the message database for new cancellation request messages. At block 3665, the VSI submits the new cancellation requests found in the message database to the appropriate vendors selected by the user to receive the cancellation requests. As disclosed above, depending upon the type of connection and the communication protocol used the by selected vendors, the VSI performs the appropriate communication tasks to exchange information with the corresponding vendors. At block 3667, the VSI receives cancellation confirmation information from the vendors' systems. At block 3669, the VSI updates the message database accordingly with the new cancellation confirmation information received from the vendors. The VSI also updates the message type ofthe corresponding records in the Order and Requestltem tables to a particular value (e.g., CANCONF) that is used by the database converter in scanning the message database for new cancellation confirmations, as described above. The VSI then loops back to block 3661 to continue processing new cancellation requests and confirmations. As described and explained above, the market server, the database converter, and the vendor gateway work in a coordinated fashion to perform several tasks in processing the cancellation requests and confirmations. Figure 37 shows a detailed flow diagram of one embodiment of a method 3700 for performing a return processing function as described above with respect to Figure 35. In one embodiment, as described above, the various components or subsystems ofthe centralized processing system work together to facilitate and process various types of transactions including stock check requests, order requests, cancel requests, return requests, etc. The flow diagram as shown in Figure 37 describes the various tasks performed by the different components ofthe centralized processing system and the interactions thereof in order to process return requests submitted by one or more users of the system (i.e., purchasers of auto parts). For clarity, the various tasks performed by the different components ofthe centralized processing system (e.g., the market server, the database converter, and the vendor gateway, etc.) and the interactions thereof are described below sequentially. However, it would be obvious to one skilled in the art that many of these tasks can be performed in parallel unless there are true logical dependencies between them. In one embodiment, the market server, the database converter, and the vendor gateway subsystems perform their corresponding functions in parallel (i.e., running separate threads or separate programs in parallel). Furthermore, for clarity and simplicity, the discussion that follows is at times focused the processing of a return request by one user ofthe system even though everything discussed herein equally applies to the processing of multiple return requests by multiple users ofthe system. Referring to Figure 37, the return process 3700 starts at block 3701. At block 3711, the market server receives a return request for a particular part item from a user of the system. A detailed description of how the user submits a return request for a particular part item associated with a particular part order to the market server is disclosed above. At block 3715, the market server updates the transaction database with the new return request submitted by the user. As described above, in one embodiment, the transaction database contains various tables that are used for various purposes including storing the relevant information pertaining to stock check requests and responses, order requests and confirmations, cancellation requests and confirmations, return requests and return authorizations, etc. In one embodiment, the market server updates the corresponding tables (i.e., the Orders table and Orderltem table) in the transaction database to indicate, for each part item to be returned, that the respective part item has been requested by the user to be returned. At block 3717, the market server waits for the return authorization (also referred to as return approval). In one embodiment, the corresponding records in the transaction database are updated accordingly once the return authorizations or approvals for the respective parts are received from the vendor. At decision block 3719, if the return authorization or approval has been received and updated in the transaction database, the market server proceeds to block 3721 to retrieve the return authorization from the transaction database and displays it to the user. Otherwise the market server loops back to block 3717 to wait for the return authorization. The market server then loops back from block 3721 to block 3711 to continue processing new return requests. While the market server is performing its corresponding function in processing cancellation requests, the database converter and the vendor gateway subsystems are also performing their corresponding functions in parallel to process return requests and authorizations. At block 3741, the database converter scans the transaction database for new return requests. At decision block 3743, the database converter proceeds to block 3745 if new return requests are found in the transaction database. Otherwise the database converter loops back to block 3741 to continue scanning the transaction database for new return requests. At block 3745, for each new return found in the transaction database, the database converter updates the message database accordingly to reflect that a return request has been submitted for selected part items. In one embodiment, as described above, the message data base contains a set of message tables that are used to store the relevant information relating to the various types of transactions including stock check request messages, order placement request messages, cancellation requests, return requests, etc. In one embodiment, for each new return request found in the transaction database, the database converter updates corresponding records in the Order and the Requestltem tables (these records were already created during the stock check processing phase as described above) to reflect that the corresponding part items are to be returned. In one embodiment, this is done by updating the message type ofthe corresponding records in the Order and Requestltem tables to a particular value, for example RETREQ. The database converter also updates other information ofthe corresponding records if necessary, for example changing the quantity to the quantity to be returned. The message type information will be used by the vendor gateway subsystem to perform its corresponding function as described below. At block 3749, the database converter scans the message database for new return authorizations (also referred to as return approval) received from the vendors. In one embodiment, the database converter performs a select on the Order table and Requestltem table looking for those rows or records in the tables with the message type set to a particular value indicating cancellation confirmation records (e.g., message type = RETCONF). At block 3751, if there are new return authorization messages found in the message database, the database converter proceeds to block 3753. Otherwise the database converter loops back to block 3749 to continue scanning the message database for new return authorizations. At block 3753, the database converter updates the transaction database accordingly with the new return authorization information found in the message database. After updating the transaction database with the new return authorizations found in the message database, the database converter sets the message type ofthe corresponding records in the Order and the Requestltem tables in the message database to a particular value (e.g., RETUPDT) so that they will not be used again the next time the database converter scans the message database for new return authorizations. The database converter then loops back to block 3741 to continue processing new return requests and authorizations.

Continuing with the present discussion, while the market server and the database converter perform their corresponding functions in processing return requests and authorizations, the vendor gateway subsystem also perform its corresponding function. At block 3761, the vendor system interface (VSI) component ofthe vendor gateway subsystem scans the message database for new return request messages. In one embodiment, the VSI performs a select on the Order table and the Requestltem table looking for those records or rows with the message type set to a particular value (e.g., RETREQ). At block 3763, if there are any new return request messages found in the message database, the VSI proceeds to block 3765. Otherwise the VSI loops back to block 3761 to continue scanning the message database for new return request messages. At block 3765, the VSI submits the new return requests found in the message database to the appropriate vendors selected by the user to receive the return requests. As disclosed above, depending upon the type of connection and the communication protocol used the by selected vendors, the VSI performs the appropriate communication tasks to exchange information with the corresponding vendors. At block 3767, the VSI receives return authorization information from the vendors' systems. At block 3769, the VSI updates the message database accordingly with the new return authorization information received from the vendors. The VSI also updates the message type ofthe corresponding records in the Order and Requestltem tables to a particular value (e.g., RETCONF) that is used by the database converter in scanning the message database for new return authorization, as described above. The VSI then loops back to block 3761 to continue processing new return requests and authorizations. As described and explained above, the market server, the database converter, and the vendor gateway work in a coordinated fashion to perform several tasks in processing the return requests and authorizations.

Figure 38 illustrates a flow diagram of a method 3800 for allowing the user to review and update status information with respect to the delivery of part items, return of cores, and return of part items. The method 3800 starts at block 3801 and proceeds to block 3805. At block 3805, in response to the user's request, current status information with respect to parts delivery, cores return, and parts return in the user's account are retrieved from the transaction database and a summary of status information retrieved from the database is prepared. At block 3809, the summary of status information with respect to delivery, cores, and returns is displayed to the user. An example of a user interface used to display status information with respect to delivery, cores, and returns is shown in Figure 39 A. In one embodiment, as shown in Figure 39 A, the summary status information displayed to the user includes the names ofthe vendors, the jobs associated with each vendor, the orders associated with each job, the transaction type for each order, and the status for each order, etc. At block 3813, in response to the user's selection of a particular vendor being displayed in the summary list, a more detailed pickup/delivery summary is displayed to the user that contains a list of individual part items that the user has ordered from the selected vendor. An example of a user interface used to display the detailed summary list ofthe pickup/delivery information is shown in Figure 39B. In one embodiment, as shown in Figure 39B, the pickup/delivery user interface is divided or organized into three sections: a section listing individual part items that have been ordered from the selected vendor (orders section), a section listing individual part items for which cores are expected (cores section), and a section listing part items that the user has requested to return for various reasons (returns section). At block 3817, the user is allowed to individually indicate which part items in the orders section have been delivered to or received by the user. In one embodiment, for each part item being displayed in the orders section, a corresponding selection box is provided as shown in Figure 39B to allow the user to indicate which part items have been received. At block 3821, for each part item being displayed in the cores section, the user is allowed to individually indicate whether core(s) for a particular part item has been returned to the selected vendor. In one embodiment, a selection box is provided for each part item in the cores section to allow the user to indicate or specify whether the cores for the respective part item has been returned to the selected vendor. At block 3825, for each part item „ listed in the returns section, the user is also allowed to individually indicate whether any particular part item listed has been returned to the selected vendor. In one embodiment, as shown in Figure 39B, a selection box is provided for each part item listed in the returns section to allow the user to indicate whether the respective part item has been returned to the selected vendor. At block 3829, in response to the user's request or command to update the status information, the transaction database is updated to reflect the new delivery, core return, and part return status based upon the selections made by the user. The method then proceeds to end at block 3891. Figure 40 shows a flow diagram of one embodiment of a method 4000 for reporting transactional information to a user (purchaser) ofthe system. The method starts at block 4001 and proceeds to block 4005. At block 4005, in response to the user's request, a user interface as shown in Figure 41 A is presented to allow the user to select or specify a particular report type. In one embodiment, as shown in Figure 41 A, the user is allowed to select either a customer reporting option or a standard reporting option in order to obtain certain relevant information with respect to the various transactions in the user's account that are stored in the transaction database. In one embodiment, as shown in Figure 41 A, a monthly transaction report summarized by vendors is the default standard report that the user can select. At decision block 4009, the method proceeds to block 4013 if the custom reporting option is selected. Otherwise the method proceeds to block 4017. At block 4013, the user is allowed to download data from the system in order to create his customized reports. In one embodiment, the user is allowed to specify various criteria or parameters that are used to select the data that he wants to download. The various criteria or parameters that the user can specify for data selection include the particular database format from the available database formats (e.g., text file, Microsoft Access, Microsoft Excel, etc.), data beginning date, data ending date, data filter (e.g., data for all transactions, data for one vendor, data for one vendor affiliation, or data for a specific manufacturer, etc.). At block 4017, a monthly transaction report organized by vendors based upon information retrieved from the transaction database is displayed to the user. An example of a monthly transaction report is shown in Figure 41B. In one embodiment, a drill-down reporting mechanism is provided to allow the user to view or obtain more detailed information regarding the summary information in the monthly transaction report. At block 4021, in response to the user's selection of a particular vendor being displayed, a weekly transaction report for the selected month with respect to the selected vendor is displayed to the user as shown in Figure 41C. Similarly, at block 4025, in response to the user's selection of a particular weekly period being displayed in the weekly transaction report, a daily transaction report as shown in Figure 41 D is displayed to the user. At block 4027, in response to the user's selection a specific day being displayed in the daily transaction report, a single day transaction report listing individual transactions is displayed as shown in Figure 4 IE. At block 4029, in response to the user's selection of a particular transaction being displayed in the single day transaction report, a transaction summary report listing individual part items on the selected transaction is displayed to the user as shown in Figure 4 IF. The method 4000 proceeds to end at block 4091.

Figure 42 depicts a flow diagram of one embodiment of a process 4200 for allowing a vendor to view and take appropriate actions with respect to pending transactions or activities in his account. The process 4200 starts at block 4201 and proceeds to block 4205. At block 4205, in response to the vendor's request to view the status of pending transactions or activities, a summary status of pending transactions or activities is displayed to the vendor based upon the information retrieved from the transaction database. An example of a status summary of pending transactions and activities is shown in Figure 43A. In one embodiment, as illustrated in Figure 43A, pending transactions and activities are listed in separate sections allowing the vendor to more easily locate and focus on particular transactions or activities that require his attention. The separate sections ofthe status summary include a section listing pending orders (pending orders section), a section listing pending stock checks (pending stock checks section), a section listing pending returns (pending returns section). Pending orders are orders that require some actions by the vendor depending on the current status ofthe pending orders. For example, an order may be pending because there is inadequate stock to satisfy the quantity of parts ordered or because immediate delivery is requested by the purchaser, etc. Pending stock checks are stock checks submitted by the purchasers that require some actions by the vendor. For example, a stock check may be pending because there is inadequate stock, because manual approval is required, or because the part inquired is invalid, etc. Pending returns are return requests submitted by the purchaser as described above that require authorizations by the vendor. At block 4209, in response to the user's selection of a specific order in the pending orders section, an order summary user interface as shown in Figure 43 B is displayed to allow the vendor to review the selected pending order in more detail and to take appropriate actions to process the selected pending order. For example, as shown in Figure 43B, the vendor may decide to approve or decline the selected pending order which requires immediate delivery. At block 4213, in response to the user's selection of a particular stock check transaction in the pending stock checks section, a stock check summary user interface as shown in Figure 43 C is displayed to allow the user to review the pending stock check in more detail and to take appropriate actions to process the pending stock check. At block 4217, in response to the user's selection of a specific return transaction in the pending returns section, a return authorization user interface is displayed as shown in Figure 43 D to allow the vendor to review the selected pending return request in more detail and to approve or decline the pending return request. The process 4200 proceeds to end at block 4291.

Figure 44 shows a flow diagram of a method 4400 for providing historical transactional information to a vendor concerning the various types of transactions that take place within a selected period. The method 4400 starts at block 4401 and proceeds to block 4405. At block 4405, in response to the vendor's request, a historical transactional activity summary is displayed to the vendor. An example of a historical transactional activity summary is shown in Figure 45 A. In this example, the period is defaulted to "today" period even though the period can be defaulted to some other period, for example "this week", "this month", "last week", "last month", etc. Depending on the period selected, corresponding information will be selected and retrieved from the transaction database to construct the appropriate summary report for the period selected. In one embodiment, as shown in Figure 45A, the user is allowed to select a different period to view the historical activity summary for that period using the drop down window provided to select another period and select or click on the change view option. As shown in Figure 45A, the historical activity summary includes the customers or purchasers that have conducted transactions with the vendor during the period selected. For each customer or purchaser shown, the summary also includes various information with respect to orders, stock checks, returns, etc, At block 4409, in response to the user's selection of another period, a historical activity summary for that period is displayed to the user based upon the information retrieved from the transaction database. At block 4413, in response to the user's selection of a customer or purchaser, a historical activity summary for that particular customer or purchaser is displayed to the vendor as shown in Figure 45B, based upon the information retrieved from the transaction database. Again, as shown in Figure 45B, the vendor can also select a different period to view the historical activity summary for that period with respect to the selected customer. At block 4417, in response to the user's selection of another period using the drop down window provided, a historical activity summary for the selected period with respect to the selected customer is displayed to the vendor. At block 4421 , in response to the user's selection of a particular transaction in the historical activity summary for the selected customer, a transaction summary for the selected transaction is displayed as shown in Figure 45C.

Figure 46 shows a flow diagram of one embodiment of a method 4600 for reporting transactional information to a user ofthe system who is a vendor or distributor. The method starts at block 4601 and proceeds to block 4605. At block 4605, in response to the user's request to perform reporting functions, a user interface as shown in Figure 47A is presented to allow the user to select or specify a reporting option. In one embodiment, as shown in Figure 47A, the user is allowed to select either a customer reporting option, a lost sales report option, or a billing verification report option. The custom reporting option, if selected, will allow the user to download data from the system to create his own customized reports. The billing verification report option, if selected, will allow the user to view billing detail in his account. The lost sales report option, if selected, will allow the user to view a summary report that contains information regarding stock check request, order, and lost order detail. At decision block 4609, the method proceeds to block 4613 if the custom reporting option is selected, block 4615 if the lost sales report option is selected, or block 4617 if the billing verification report option is selected. At block 4613, the user is allowed to download data from the system in order to create his customized reports. In one embodiment, the user is allowed to specify various criteria or parameters that are used to select the data that he wants to download. The various criteria or parameters that the user can specify for data selection include the particular database format from the available database formats (e.g., text file, Microsoft Access, Microsoft Excel, etc.), data beginning date, data ending date, data filter (e.g., data for all transactions, data for one purchaser, data for one purchaser affiliation, or data for a specific manufacturer, etc.). At block 4615, a summary report containing stock check and order statistics based upon the information retrieved from the transaction database is displayed to the user. In one embodiment, as shown in Figure 47B, the summary lost sales report contains, for each month within a selected period (e.g., year-to-date), the total number of stock checks, the total number of stock checks that are unfulfilled, the total number of orders, the total number of lost orders, etc. Continuing with the present discussion, at block 4617, a monthly activity summary report by week is displayed to the user as shown in Figure 47C, based upon information retrieved from the transaction database. In one embodiment, a drill-down reporting mechanism is provided to allow the user to view or obtain more detailed information regarding the summary information in the monthly activity report. At block 4619, in response to the user's selection of a particular week in the selected month, a weekly summary report for the selected week is displayed to the user as shown in Figure 47D. Similarly, at block 4621, in response to the user's selection of a particular day in the selected week, a daily detail report for the selected day as shown in Figure 47E is displayed to the user. At block 4623, in response to the user's selection a specific purchaser in the daily detail report, a daily purchaser detail report listing individual transactions is displayed as shown in Figure 47F. At block 4625, in response to the user's selection of a particular transaction being displayed in the daily purchaser detail report, a transaction summary report listing individual part items on the selected transaction is displayed to the user as shown in Figure 47G. The method 4600 proceeds to end at block 4691.

The invention has been described in conjunction with the preferred embodiment. It is evident that numerous alternatives, modifications, variations and uses will be apparent to those skilled in the art in light ofthe foregoing description.

Claims

CLAIMSWhat is claimed is:

1. A method of facilitating transactions between a plurality of purchasers and a plurality of vendors connected to a centralized processing system via a computer network, the method comprising: providing a first purchaser with a mechanism to submit via the computer network a transaction request of a first type containing at least one part item to one or more specific vendors selected by the first purchaser to receive the transaction request of the first type; and providing the one or more specific vendors a mechanism to send to the first purchaser via the computer network a transaction response to the first purchaser's transaction request ofthe first type.

2. The method of claim 1 wherein providing the first purchaser with the mechanism to submit comprises: allowing the first purchaser to submit the transaction request of the first type to the centralized processing system via the computer network; and transmitting the transaction request of the first type from the centralized processing system to the one or more specific vendors selected by the first purchaser to receive the transaction request of the first type via the computer network.

3. The method of claim 2 further comprising: storing the transaction request ofthe first type in the centralized processing system.

4. The method of claim 3 wherein storing comprises: updating a transaction database in the centralized processing system with information corresponding to the transaction request ofthe first type.

5. The method of claim 1 wherein providing the one or more specific vendors comprises: allowing the one or more specific vendors to submit the transaction response to the centralized processing system via the computer network; and transmitting the transaction response from the centralized processing system to the first purchaser via the computer network.

6. The method of claim 5 further comprising: storing the transaction response in the centralized processing system.

7. The method of claim 6 wherein storing comprises: updating a transaction database in the centralized processing system with information corresponding to the transaction response.

8. The method of claim 2 wherein allowing the first purchaser to submit the transaction request of the first type comprises: providing the first purchaser with a user interface to construct and send the transaction request of the first type to the centralized processing system via the computer network.

9. The method of claim 2 wherein transmitting the transaction request of the first type comprises: determining, for each vendor selected by the first purchaser to receive the transaction request of the first type, the communication protocol used by the respective vendor's computer system to exchange information with the centralized processing system; and converting the transaction request ofthe first type into a format compatible with the respective vendor's computer system based upon the communication protocol used.

10. The method of claim 4 further comprising: creating a new transaction request message in a message database in the centralized processing system based upon the information stored in the transaction database corresponding to the transaction request of the first type.

11. The method of claim 7 further comprising: creating a new transaction response message in a message database in the centralized processing system based upon the transaction response received from the one or more specific vendors.

12. The method of claim 1 wherein the transaction request of the first type is an order placement request and the transaction response is an order confirmation.

13. The method of claim 1 wherein the transaction request of the first type is a stock check request and the transaction response is a stock check response.

14. The method of claim 1 wherein the transaction request of the first type is a cancellation request and the transaction response is a cancellation confirmation.

15. The method of claim 1 wherein the transaction request of the first type is a return request and the transaction response is a return response.

16. A method of facilitating transactions between multiple purchasers and multiple vendors of auto parts connected to a centrahzed processing system via a computer network, the method comprising: providing a first purchaser with a capabihty to submit via the centrahzed processing system an order placement request containing at least one part item to one or more specific vendors selected by the first purchaser to receive the order placement request; and providing the one or more specific vendors with a capability to send to the first purchaser via the centrahzed processing system a response with respect to the first purchaser's order placement request.

17. The method of claim 16 wherein providing the first purchaser with the capability to submit the order placement request comprises: providing the first purchaser with a capabihty to obtain stock check information with respect to the at least one part item from the one or more specific vendors prior to submitting the order placement request.

18. The method of claim 17 wherein providing the first purchaser with the capability to obtain stock check information comprises: allowing the first purchaser to submit via the centralized processing system a stock check request for the at least one part item to the one or more specific vendors selected by the first purchaser to receive the stock check request; and allowing the one or more specific vendors to send to the first purchaser via the centralized processing system a response with respect to the first purchaser's stock check request.

19. The method of claim 16 further comprising: providing the first purchaser with a mechanism to submit a part query request containing part query criteria to the centrahzed processing system to identify the at least one part item in a part catalog.

20. The method of claim 19 further comprising: generating a list of part items in the part catalog matching the first purchaser's query criteria.

21. The method of claim 16 further comprising: providing the first purchaser with a mechanism to submit a cancellation request with respect to the at least one part item to one or more specific vendors if cancellation of the order placement request for the at least one part item is allowable based upon the processing status ofthe at least one part item.

22. The method of claim 16 further comprising: providing the first purchaser with a mechanism to submit a return request with respect to the at least one part item to one or more specific vendors if return of the at least one part item is allowable based upon the processing status of the at least one part item.

23. The method of claim 16 further comprising: providing a mechanism for the first purchaser to view and update the processing status of the at least one part item based upon transactional activities taken by the first purchaser and the one or more specific vendors with respect to the at least one part item.

24. The method of claim 16 further comprising: providing the first purchaser with a capability to view the processing status of the at least one part item and to perform one or more functions with respect to the at least one part item based upon its processing status.

25. A method of facilitating transactions between multiple vendors and multiple purchasers of auto parts connected to a centralized system via a network, the method comprising: performing a catalog query function to generate a list of part items in a part catalog that match search criteria specified by a first purchaser; performing a stock check function to obtain and generate a list of stock check responses with respect to the part items in the list that are selected by the first purchaser to be stock checked; and performing an order placement function with respect to the part items in the list of stock check responses that are selected by the first purchaser to be ordered.

26. The method of claim 25 wherein performing the catalog query function comprises: obtaining the search criteria from the first purchaser; and searching the part catalog to identify the part items in the part catalog that match the search criteria obtained from the first purchaser.

27. The method of claim 26 wherein the search criteria comprise a vehicle specification.

28. The method of claim 27 wherein the vehicle specification comprises information corresponding to the vehicle year, information corresponding to the vehicle make, information corresponding to the vehicle model, and information corresponding to the vehicle engine type.

29. The method of claim 27 wherein obtaining the search criteria comprises: obtaining the vehicle specification.

30. The method of claim 29 wherein obtaining the vehicle specification comprises: presenting to the first purchaser a first list of items corresponding to a first attribute ofthe vehicle specification; and in response to the first purchaser's selection of one of the items in the first list, presenting to the first purchaser a second list of items corresponding to a second attribute of the vehicle specification.

31. The method of claim 30 wherein the first attribute of the vehicle specification corresponds to a vehicle year.

32. The method of claim 30 wherein the second attribute of the vehicle specification corresponds to a vehicle make.

33. The method of claim 30 wherein the first list is displayed in a first display area and the second list is displayed in a second display area, the first and second display areas being on a same display page.

34. The method of claim 30 further comprising: in response to the first purchaser's selection of one of the items in the second Ust, presenting to the first purchaser a third list of items corresponding to a third attribute of the vehicle specification; and in response to the first purchaser's selection of one of the items in the third Ust, presenting to the first purchaser a fourth list of items corresponding to a fourth attribute ofthe vehicle specification.

35. The method of claim 34 wherein the third attribute of the vehicle specification corresponds to a vehicle model.

36. The method of claim 34 wherein the fourth attribute of the vehicle specification corresponds to a vehicle engine type.

37. The method of claim 34 wherein the third list is displayed in a third display area, the fourth list is displayed in a fourth display area, the third and fourth display areas being on a same display page.

38. The method of claim 34 wherein the third and fourth Usts are displayed on the same display page as the first and second Usts.

39. The method of claim 27 wherein the first search criteria further comprise a part specification.

40. The method of claim 39 wherein the part specification includes a part group corresponding to a group of auto part components.

41. The method of claim 39 wherein obtaining the search criteria comprises obtaining the part specification.

42. The method of claim 41 wherein obtaining the part specification comprises: upon obtaining the vehicle specification, presenting to the first purchaser a list of applicable part groups corresponding to the vehicle specification.

43. The method of claim 42 wherein presenting the list of applicable part groups comprises: searching a database to identify the part groups corresponding to the vehicle specification specified by the first purchaser.

44. The method of claim 43 wherein the vehicle specification comprises the vehicle year, the vehicle make, the vehicle model, and the vehicle engine type.

45. The method of claim 42 further comprising: in response to the first purchaser's selection of a specific part group in the list of applicable part groups, presenting a list of applicable part subgroups corresponding to the specific part group selected by the first purchaser.

46. The method of claim 45 wherein presenting the list of applicable part subgroups comprises: searching a database to identify the part subgroups corresponding to the specific part group selected by the first purchaser.

47. The method of claim 46 further comprising: in response to the first purchaser's selection of a specific part subgroup in the list of part subgroups, retrieving the part items in the part catalog corresponding to the specific part subgroup selected by the first purchaser.

48. The method of claim 47 further comprising: presenting to the first purchaser the part items retrieved from the first catalog if the number of part items retrieved does not exceed a predetermined number.

49. The method of claim 48 wherein presenting the part items retrieved from the first catalog comprises: sorting the part items according to a predetermined sort order.

50. The method of claim 49 wherein the part items are sorted by manufacturer identifiers.

51. The method of claim 50 wherein each manufacturer identifier comprises a manufacturer line code.

52. The method of claim 49 wherein the part items are sorted by part descriptions corresponding to the part items.

53. The method of claim 48 further comprising: if the number of part items retrieved exceeds the predetermined number, presenting a list of non-redundant part descriptions based upon the part items retrieved from the part catalog, each part item retrieved from the part catalog containing a corresponding part description.

54. The method of claim 53 wherein presenting the list of non-redundant part descriptions comprises: consohdating the part descriptions extracted from the part entries to remove redundant part descriptions.

55. The method of claim 54 further comprising: in response to the first purchaser's selection of one or more part descriptions in the list, presenting the part items retrieved from the part catalog that correspond to the one or more part descriptions selected by the first purchaser.

56. The method of claim 26 wherein the search criteria comprise a part number.

57. The method of claim 56 wherein obtaining the search criteria comprises obtaining the part number.

58. The method of claim 57 wherein obtaining the part number comprises: providing the first purchaser with a user interface to enter the part number.

59. The method of claim 56 wherein the search criteria further comprise a manufacturer line code.

60. The method of claim 59 wherein obtaining the search criteria comprises obtaining the manufacturer line code.

61. The method of claim 60 wherein obtaining the manufacturer line code comprises: providing the first purchaser with a user interface to optionally enter the manufacturer line code.

62. The method of claim 61 further comprising: if the manufacturer line code is entered by the first purchaser, verifying that the manufacturer line code entered by the first purchaser is valid.

63. The method of claim 60 wherein obtaining the manufacturer Une code comprises: providing the first purchaser with a mechanism to select the manufacturer line code.

64. The method of claim 63 wherein providing the first purchaser with the mechanism to select the manufacturer line code comprises: presenting to the first purchaser an alphabetical Ust; in response to the first purchaser's selection of a specific letter in the alphabetical list, presenting to the first purchaser a list of manufacturers whose identifiers beginning with the specific letter selected by the first purchaser; and in response to the first purchaser' selection of a specific manufacturer, presenting to the first purchaser a list of manufacturer line codes corresponding to the specific manufacturer selected by the first purchaser.

65. The method of claim 59 further comprising: searching the part catalog for part items that match the part number and the manufacturer line code provided by the first purchaser; and presenting the part items from the part catalog that match the part number and the manufacturer line code provided by the first purchaser.

66. The method of claim 65 wherein presenting the part items comprises: sorting the part items according to a specified sort order.

67. The method of claim 65 further comprising: if there are no part items in the part catalog matching the part number and the manufacturer line code provided by the first purchaser, performing a special stock check function.

68. The method of claim 67 wherein performing the special stock check function comprises: informing the first purchaser that there is no part item in the part catalog matching the part number and the manufacturer line code provided by the first purchaser; and providing the first purchaser with a mechanism to perform a stock check on the specific part identified by the part number and the manufacturer line code provided by the first purchaser.

69. The method of claim 68 wherein providing the first purchaser with the mechanism comprises: allowing the first purchaser to specify one or more vendors to which a stock check request on the specific part is to be sent.

70. The method of claim 69 wherein aUowing comprises: presenting to the first purchaser a first list of vendors pre-selected by the first purchaser as vendors of first choice.

71. The method of claim 70 further comprising: providing the first purchaser with a mechanism to select a different Ust of vendors.

72. The method of claim 25 further comprising: providing the first purchaser with a mechanism to select one or more specific part items to be stock checked from the list of part items matching the search criteria specified by the first purchaser.

73. The method of claim 72 further comprising: for each part item selected to be stock checked, providing the first purchaser with a mechanism to select one or more specific vendors to whom a stock check request for the respective part item is to be sent.

74. The method of claim 73 wherein providing comprises: presenting to the first purchaser a list of the one or more specific vendors in a specified order; and indicating that the one or more specific vendors have been identified as the vendors that carry the manufacturer product line to which the respective part item belongs.

75. The method of claim 74 further comprising: providing the first purchaser with a mechanism to select another set of vendors.

76. The method of claim 26 further comprising: presenting the part items in a specified sort order; and for each part item being presented, showing in a specified order a predetermined set of vendors according to a vendor selection scheme indicated by the first purchaser.

77. The method of claim 76 further comprising: deterrnining the specified sort order in which the part items are presented; determining the type of vendors to whom the first purchaser wants to submit a stock check request; determining the order in which the vendors are to be presented.

78. The method of claim 76 further comprising: aUowing the first purchaser to specify the sort order in which the part items are to be presented; allowing the first purchaser to specify which type of vendors are to be presented; and allowing the first purchaser to specify the order in which the vendors are to be presented.

79. The method of claim 25 wherein performing the stock check function comprises: aUowing the first purchaser to select one or more specific part items to be stock checked from the list of part items matching the search criteria specified by the first purchaser; and for each part item selected by the first purchaser to be stock checked, allowing the first purchaser to specify one or more vendors to whom a stock check request for the part item selected is to be submitted.

80. The method of claim 79 wherein aUowing the first purchaser to select one or more part items comprises: presenting to the first purchaser the list of part items retrieved from the part catalog that match the search criteria specified by the first purchaser; and for each part item in the list, providing the first purchaser with a mechanism to individuaUy select the respective part item to be stock checked.

81. The method of claim 80 wherein providing the first purchaser with the mechanism to individually select comprises: presenting a selectable indicator in connection with the respective part item, the selectable indicator when marked by the first purchaser indicating that the corresponding part item is to be stock checked.

82. The method of claim 80 wherein allowing the first purchaser to specify one or more vendors comprises: aUowing the first purchaser to select a Ust of vendors of a particular type; and for each part entry being presented, showing the Ust of vendors selected by the first purchaser.

83. The method of claim 82 wherein showing the Ust of vendors comprises: presenting the list of vendors according to a display order specified by the first purchaser.

84. The method of claim 83 further comprising: providing the first purchaser with a mechanism to individuaUy select one or more vendors from the list of vendors presented as the vendors to whom a stock check request for the selected part item is to be submitted.

85. The method of claim 83 further comprising: indicating to the first purchaser which vendors in the Ust are the vendors that carry the particular product line to which the respective part item belongs.

86. The method of claim 85 wherein indicating comprises: for each part item being presented, showing a selectable indicator in connection with the vendor identifier being presented to indicate that the respective vendor carries the particular part product line to which the respective part item belongs.

87. The method of claim 79 further comprising: preparing one or more stock check requests based upon the first purchaser's selections; storing the one or more stock check requests in a transaction database; and submitting the one or more stock check requests to the vendors selected by the first purchaser.

88. The method of claim 87 wherein preparing the one or more stock check requests comprises: determining the part items that are selected by the first purchaser to be stock checked; deteraiining, for each part item selected by the first purchaser to be stock checked, the vendors that are selected by the first purchaser to whom the stock check request for the selected part item is to be submitted; and constructing the one or more stock check requests based upon the part items and the vendors selected by the first purchaser.

89. The method of claim 87 wherein submitting the one or more stock check requests to the vendors selected comprises: transmitting electronicaUy the one or more stock check requests to the selected vendors at their corresponding network addresses.

90. The method of claim 87 wherein submitting the one or more stock check requests comprises: converting the stock check requests into formats compatible with the selected vendors' systems.

91. The method of claim 90 wherein converting comprises: generating stock query messages based upon the stock check requests information; sending the stock query messages to a response server that is configured to process stock query messages at the corresponding vendor's system.

92. The method of claim 90 wherein converting comprises: generating stock query messages based upon the stock check requests information; and converting the stock query messages into interactive scripts used to invoke functions in the vendor's system via a terminal session.

93. The method of claim 79 further comprising: receiving stock check responses from the vendors with respect to the one or more stock check requests submitted; and presenting the stock check responses to the first purchaser.

94. The method of claim 93 wherein presenting the stock check responses comprises: sorting the stock check responses according to a sorting scheme selected by the first purchaser.

95. The method of claim 95 wherein the stock check response comprises the part information including the manufacturer product Une, part number, and the part description.

96. The method of claim 93 wherein the stock check response further comprises the part cost and the part availabiUty information, the part avaUabiUty information comprising quantity information indicating how many units of the respective part item are avaUable on hand.

97. The method of claim 96 wherein the part cost and the part availabiUty information for each part item are provided for each vendor in the list.

98. The method of claim 97 wherein the vendors in the list are presented in an order specified by the first purchaser.

99. The method of claim 98 wherein the vendors are presented in a horizontal display order with the highest ranking vendor being presented in the left-most available column and the lowest ranking vendor being displayed in the right-most available column.

100. The method of claim 25 wherein performing the order placement function comprises: aUowing the first purchaser to select one or more specific part items to be ordered from the list of stock check responses; and for each part item selected by the first purchaser to be ordered, aUowing the first purchaser to specify one or more vendors to whom an order request for the part item selected is to be submitted.

101. The method of claim 100 wherein aUowing the first purchaser to select one or more part items comprises: presenting to the first purchaser the list of stock check responses; and for each part item in the list, providing the first purchaser with a mechanism to individuaUy select the respective part item to be ordered.

102. The method of claim 101 wherein providing the first purchaser with the mechanism to individuaUy select comprises: presenting a selectable indicator in connection with the respective part item being presented, the selectable indicator when marked by the first purchaser indicating that the corresponding part item is to be ordered;

103. The method of claim 102 wherein aUowing the first purchaser to specify one or more vendors comprises: for each part item in the Ust of stock check responses, showing the vendors from whom the stock check response for the respective part item has been received; and providing the first purchaser with a mechanism to individuaUy select one or more vendors being shown to whom an order request for the selected part item is to be submitted.

104. The method of claim 103 wherein showing the vendors comprises: presenting the vendors according to a display order specified by the first purchaser.

105. The method of claim 103 wherein providing the first purchaser with a mechanism comprises: presenting a selectable indicator for each vendor being shown, the selectable indicator when marked by the first purchaser indicating that the corresponding vendor is the vendor to whom the order for the selected part item is to be submitted.

106. The method of claim 100 further comprising: preparing one or more part order requests based upon the first purchaser's selections; storing the one or more part order requests in a transaction database; and submitting the one or more part order requests to the vendors selected by the first purchaser.

107. The method of claim 106 wherein preparing the one or more part order requests comprises: determining the part items that are selected by the first purchaser to be ordered; deterrnining, for each part item selected by the first purchaser to be ordered, the vendors that are selected by the first purchaser to whom the part order request is to be submitted; and constructing the one or more part order requests based upon the part items and the vendors selected by the first purchaser.

108. The method of claim 107 wherein submitting the one or more part order requests to the vendors selected comprises: transmitting electronicaUy the one or more part order requests to the selected vendors at their corresponding network addresses.

109. The method of claim 108 wherein submitting the one or more part order requests comprises: converting the part order requests into formats compatible with the selected vendors' systems.

110. The method of claim 109 wherein converting comprises: generating part order messages based upon the part order requests information; sending the part order messages to a response server that is configured to process part order messages at the vendor's system.

111. The method of claim 109 wherein converting comprises: generating part order messages based upon part order requests information; and converting the part order messages into interactive scripts used to invoke functions in the vendor's system via a terminal session.

112. The method of claim 106 further comprising: receiving part order confirmations from the vendors with respect to the one or more part order requests submitted; and presenting the part order confirmations to the first purchaser.

113. The method of claim 112 wherein presenting the part order confirmations comprises: sorting the part order confirmations according to a sorting scheme selected by the first purchaser.

114. The method of claim 100 further comprising: presenting an order summary containing part orders requested by the first purchaser.

115. The method of claim 114 further comprising: aUowing the first purchaser to specify which part items in the order summary are to be sent to the vendors.

116. The method of claim 114 further comprising: allowing the first purchaser to specify, for each part item to be ordered, a time frame for the dehvery of the part item ordered.

117. The method of claim 25 further comprising: performing a cancellation function in response to the first purchaser's cancellation request.

118. The method of claim 117 wherein performing the cancellation function comprises: providing the first purchaser with a capability to review outstanding part order requests; and for each outstanding part order requests, providing the first purchaser with a mechanism to submit a canceUation request with respect to one or more specific part items on the respective part order request.

119. The method of claim 118 wherein providing the first purchaser with the capabihty to review outstanding part order requests comprises: presenting a list of part order requests submitted by the first purchaser.

120. The method of claim 119 wherein providing the first purchaser with the mechanism comprises: for each part order request listed, presenting a selectable indicator in connection with the respective part order listed, the selectable indicator when marked indicating that the corresponding part order is to be canceUed.

121. The method of claim 120 further comprising: determining which part items are selected by the first purchaser to be cancelled; preparing one or more cancellation requests based upon the first purchaser's selections; storing the one or more canceUation requests in a transaction database; and submitting the one or more canceUation requests to the corresponding vendors.

122. The method of claim 121 wherein submitting the one or more canceUation requests comprises: electronicaUy transmitting the one or more canceUation requests to the corresponding vendors at their corresponding network addresses.

123. The method of claim 122 wherein submitting the one or more canceUation requests comprises: converting the one or more cancellation requests into formats compatible with the selected vendors' systems.

124. The method of claim 122 wherein converting comprises: generating cancellation messages based upon the one or more cancellation requests information; sending the cancellation messages to a response server that is configured to process cancellation messages at the vendor's system.

125. The method of claim 122 wherein converting comprises: generating cancellation messages based upon the one or more cancellation requests information; and converting the cancellation messages into interactive scripts used to invoke functions in the vendor's system via a terminal session.

126. The method of claim 121 further comprising: receiving cancellation confirmation information from the vendors with respect to the one or more cancellation requests submitted; and presenting the cancellation confirmation information to the first purchaser.

127. The method of claim 25 further comprising: performing an order status function in response to the first purchaser's order status request.

128. The method of claim 127 wherein performing the order status function comprises: providing the first purchaser with a mechanism to review outstanding part orders submitted by the first purchaser each containing one or more part items; providing the first purchaser with a capabUity to individually select one or more part items the status of which is to be requested; and submitting one or more order status requests to corresponding vendors based upon the first purchaser's selections.

129. The method of claim 128 wherein providing the first purchaser with the capabihty o review outstanding part orders comprises: presenting a list of part orders submitted by the first purchaser in an order specified by the first purchaser.

130. The method of claim 128 wherein providing the first purchaser with the capabihty o individually select comprises: for each part item on each respective part order, presenting a selectable indicator in connection with the respective part item, the selectable indicator when marked indicating that the corresponding status for the respective part item is to be requested from the corresponding vendor.

131. The method of claim 130 wherein submitting the order status requests comprises: determining which part items are selected by the first purchaser; for each part item selected by the first purchaser, preparing a status request to be submitted to the corresponding vendor; storing the status requests in a transaction database; and submitting the status requests to the corresponding vendor.

132. The method of claim 131 wherein submitting the status requests comprises: electronically transmitting the status requests to the corresponding vendors at their corresponding network addresses.

133. The method of claim 132 wherein submitting the status requests comprises: converting the status requests into formats compatible with the selected vendors' systems.

134. The method of claim 133 wherein converting comprises: generating status messages based upon the status requests information; sending the status messages to a response server that is configured to process status messages at the vendor's system.

135. The method of claim 133 wherein converting comprises: generating status messages based upon status requests information; and converting the status messages into interactive scripts used to invoke functions in the vendor's system via a terminal session.

136. The method of claim 131 further comprising: receiving status response information from the vendors with respect to the status requests submitted; and presenting the status response information to the first purchaser.

137. The method of claim 25 further comprising: performing a part return function in response to the first purchaser's part return request.

138. The method of claim 137 wherein performing the part return function comprises: providing the first purchaser with a capability to individuaUy select one or more part orders containing one or more part items to be returned; providing the first purchaser with a capabihty to individuaUy select, from each part order specified, one or more part items to be returned; and submitting one or more part return requests based upon the first purchaser's selections.

139. The method of claim 138 wherein providing the first purchaser with the capability to individuaUy select the one or more part orders comprises: presenting a list of part orders submitted by the first purchaser in an order specified by the first purchaser.

140. The method of claim 138 wherein providing the first purchaser with the capabihty to individuaUy select the one or more part items to be returned comprises: for each part item Usted, presenting a selectable indicator in connection with the respective part item listed, the selectable indicator when marked indicating that the respective part item is to be returned.

141. The method of claim 138 wherein submitting the part return requests for the part items selected comprises: deterrnining the part items selected by the first purchaser to be returned; preparing one or more part return requests to be submitted to the corresponding vendors based upon the first purchaser's selections; and storing the part return requests in a transaction database.

142. The method of claim 138 wherein submitting the part return requests comprises: transmitting electronically the part return requests to the corresponding vendors at their corresponding network addresses.

143. The method of claim 138 wherein submitting the one or more part return requests comprises: converting the part return requests into formats compatible with the selected vendors' systems.

144. The method of claim 143 wherein converting comprises: generating part return request messages based upon the part return requests information; sending the part return request messages to a response server that is configured to process part return messages at the vendor's system.

145. The method of claim 143 wherein converting comprises: generating part return request messages based upon part return requests information; and converting the part return messages into interactive scripts used to invoke functions in the vendor's system via a terminal session.

146. The method of claim 138 further comprising: receiving the return authorizations from the vendors with respect to the part return requests; and presenting the return authorizations to the first purchaser.

147. The method of claim 25 further comprising: performing a status information update function in response to the first purchaser's request.

148. The method of claim 147 wherein performing the status information update function comprises: presenting a Ust vendors with which the first purchaser has placed one or more part orders; in response to the first purchaser's selection of a particular vendor in the list, presenting a list containing part items ordered from the particular vendor; providing the first purchaser with a mechanism to individuaUy select each part item in the list to indicate that the respective part item has been received by the first purchaser; and in response the first purchaser's update request, updating the delivery status of the selected part item to reflect that the respective part item has been received.

149. The method of claim 148 further comprising: providing the first purchaser with a mechanism to individuaUy select each part item in the hst to indicate that a core for the respective part item has been returned; and in response to first purchaser's update request, updating the core return status of the selected part item to reflect that the core for the respective part item has been returned.

150. The method of claim 148 further comprising: providing the first purchaser with a mechanism to individuaUy select each part item in the Ust to indicate that the respective part item has been returned to the corresponding vendor; and in response to the first purchaser's update request, updating the part return status of the selected part item to reflect that the respective part item has been returned.

151. The method of claim 25 further comprising: in response to a report request, performing a transaction reporting function.

152. The method of claim 151 wherein performing the transaction reporting function comprises: generating a transaction summary report for a first period, the transaction summary report for the first period containing a Ust of vendors and transactional data for each vendor in the list; and in response to the user's selection of a specific vendor in the Ust, generating a transaction summary report for the selected vendor containing a Ust of second periods and transactional data for each second period in the list, each second period corresponding to a duration within the first period.

153. The method of claim 152 further comprising: in response to the user's selection of a specific second period, generating a transaction summary report for the selected vendor with respect to the selected second period containing a list of third periods and transactional data for each third period in the list, each third period corresponding to a duration within the selected second period.

154. The method of claim 153 further comprising: in response to the user's selection of a specific third period, generating a transaction summary report for the selected vendor with respect to the selected third period containing a list of transactions conducted within the selected third period.

155. The method of claim 154 further comprising: in response to the user's selection of a specific transaction in the list, generating a transaction summary report for the selected transaction containing individual part items on the selected transaction.

156. The method of claim 25 further comprising: in response to a user's request to review status of transactions in the user's account, generating a summary Usting of transactions in the user's account, the summary Usting containing a transaction identifier and a current status for each transaction; and aUowing the user to perform one or more specific functions with respect to each transaction in the summary Usting based upon the current status of each transaction.

157. The method of claim 156 wherein the summary Usting further comprising a vendor identifier for each transaction.

158. The method of claim 156 wherein aUowing the user to perform one or more specific functions comprises: aUowing the user to cancel transactions that have not been accepted by the corresponding vendors.

159. The method of claim 156 wherein allowing comprises: in response to the user's selection of a specific vendor identifier in the summary listing, providing the user with detailed information about the selected vendor.

160. The method of claim 156 wherein allowing comprises: in response to the user's selection of a particular transaction identifier in the summary listing, providing a transaction status history for each part item associated with the selected transaction.

161. The method of claim 156 further comprising: for each part item associated with the selected transaction, aUowing the user to perform a first function if the respective part item is in a first status and a second function if the respective part item is in a second status.

162. The method of claim 161 wherein the first status indicates that canceUation of an order placement request for the respective part item is allowable and the first function comprises generating a canceUation request for the respective part item.

163. The method of claim 1161 wherein the second status indicates that a return of the respective part item to the vendor is allowable and the second function comprises generating a return request for the respective part item.

164. A system for faciUtating various types of transactions between a pluraUty of purchaser and a pluraUty of vendors connected to the system via a computer network, the system comprising: a first server to receive a transaction request of a first type from a user via the computer network; a transaction database to store the transaction request of the first type; and a vendor system interface to transmit the transaction request of the first type via the computer network to one or more vendors selected by the user to receive the transaction request of the first type.

165. The system of claim 164 wherein the vendor system interface is further configured to receive via the computer network a transaction response with respect to the transaction request from the one or more selected vendors.

166. The system of claim 165 wherein the transaction database is further configured to store the transaction response received from the one or more vendors.

167. The system of claim 166 wherein the first server is further configured to transmit the transaction response stored in the transaction database to the user via the computer network.

168. The system of claim 167 further comprising: database update logic to update the transaction database with the information associated with the transaction request.

169. The system of claim 168 further comprising: a message database to store a transaction request message based upon the transaction request stored in the transaction database.

170. The system of claim 169 wherein the vendor system interface uses the transaction request message stored in the message database to perform its corresponding function.

171. The system of claim 170 wherein the message database is further configured to store a transaction response message based upon the transaction response received.

172. The system of claim 171 wherein the vendor system interface is further configured to create the transaction response message upon receiving the transaction response.

173. The system of claim 171 wherein the transaction response message is used by the database update logic to update the transaction database.

174. A system for faciUtating transactions between multiple purchasers and vendors connected to the system via a network, the system comprising: first programming logic to fatilitate new transactions between the purchasers and vendors, the first programming logic comprising: part query logic to search a part catalog and present to a user a part list containing part items based upon a part query request submitted by the user; stock check logic to obtain and present to the user a stock check response list containing stock check information with respect to one or more part items from the part list that are selected by the user to be stock checked; and order placement logic to submit an order placement request to each vendor selected by the user, the order placement request containing one or more part items that are selected by the user from the response list to be ordered.

175. The system of claim 174 wherein the part query logic comprises: logic to receive the part query request from the user; logic to search the part catalog to identify and retrieve part items in the part catalog that match query criteria specified in the part query request; and logic to generate and present the part Ust to the user based upon the part items that match the query criteria.

176. The system of claim 175 wherein the logic to receive the part query request comprises: logic to allow the user to construct the part query request based upon vehicle and part information.

177. The system of claim 175 wherein the logic to receive the part query request comprises: logic to allow the user to construct the part query request based upon part number and manufacturer information.

178. The system of claim 177 wherein the logic to aUow the user to construct comprises: logic to aUow the user to specify the vehicle information using selectable lists; and logic to aUow the user to specify the part information using selectable Usts.

179. The system of claim 174 wherein the stock check logic comprises: logic to allow the user to select one or more specific part items to be stock checked from the part hst; and logic to allow the user to specify, for each part item selected by the user to be stock checked, one or more vendors to whom a stock check request for the respective part item is to be submitted.

180. The system of claim 174 wherein the order placement function comprises: logic to aUow the user to select one or more specific part items to be ordered from the stock check response list; and logic to aUow the user to specify, for each part item selected by the user to be ordered, one or more vendors to whom an order placement request for the respective part item is to be submitted.

181. The system of claim 174 further comprising: second programming logic to facilitate existing transactions between the purchasers and vendors, the second programming logic comprising: logic to perform a cancellation function in response to the user's request; and logic to perform a return function in response to the user's request.

182. The system of claim 174 wherein logic to perform the cancellation function comprises: logic to aUow the user to view outstanding part orders submitted by the user; and logic to allow the user to select one or more part items to be cancelled from one or more part orders.

183. The system of claim 174 wherein logic to perform the return function comprises: logic to aUow the user to view outstanding part orders submitted by the user; and logic to aUow the user to select one or more part items to be returned from one or more part orders.

184. A machine-readable medium comprising instructions which, when executed by a machine, cause the machine to perform the steps of: receiving a transaction request of a first type from a user via the computer network; storing the transaction request of the first type; and transmitting the transaction request of the first type via the computer network to one or more vendors selected by the user to receive the transaction request of the first type.

185. The machine-readable medium of claim 184 further comprising: receiving a transaction response with respect to the transaction request from the one or more selected vendors.

186. The machine-readable medium of claim 185 further comprising: storing the transaction response received from the one or more selected vendors.

187. The machine-readable medium of claim 186 further comprising: transmitting the transaction response to the user via the computer network.

188. A machine-readable medium comprising instructions which, when executed by a machine, causes the machine to perform the steps of: performing a catalog query function to generate a Ust of part items in a part catalog that match search criteria specified by a first purchaser; performing a stock check function to obtain and generate a Ust of stock check responses with respect to the part items in the Ust that are selected by the first purchaser to be stock checked; and performing an order placement function with respect to the part items in the Ust of stock check responses that are selected by the first purchaser to be ordered.

189. The machine-readable medium of claim 187 wherein performing the catalog query function comprises: obtaining the search criteria from the first purchaser; and searching the part catalog to identify the part items in the part catalog that match the search criteria obtained from the first purchaser.

190. The machine-readable medium of claim 189 further comprising: presenting to the first purchaser the hst of part items from the part catalog that match the search criteria specified by the first purchaser.

191. The machine-readable medium of claim 187 wherein performing the stock check function comprises: aUowing the first purchaser to select one or more specific part items to be stock checked from the list of part items matching the search criteria specified by the first purchaser; and for each part item selected by the first purchaser to be stock checked, allowing the first purchaser to specify one or more vendors to whom a stock check request for the part item selected is to be submitted.

192. The machine-readable medium of claim 191 wherein aUowing the first purchaser to select one or more part items comprises: presenting to the first purchaser the list of part items retrieved from the part catalog that match the search criteria specified by the first purchaser; and for each part item in the list, providing the first purchaser with a mechanism to individually select the respective part item to be stock checked.

193. The machine-readable medium of claim 192 further comprising: preparing one or more stock check requests based upon the first purchaser's

• selections; storing the one or more stock check requests in a transaction database; and submitting the one or more stock check requests to the vendors selected by the first purchaser.

194. The machine-readable medium of claim 193 further comprising: receiving stock check responses from the vendors with respect to the one or more stock check requests submitted; and presenting the stock check responses to the first purchaser.

195. The machine-readable medium of claim 188 wherein performing the order placement function comprises: aUowing the first purchaser to select one or more specific part items to be ordered from the Ust of stock check responses; and for each part item selected by the first purchaser to be ordered, aUowing the first purchaser to specify one or more vendors to whom an order request for the part item selected is to be submitted.

196. The machine-readable medium of claim 195 wherein aUowing the first purchaser to select one or more part items comprises: presenting to the first purchaser the list of stock check responses; and for each part item in the list, providing the first purchaser with a mechanism to individually select the respective part item to be ordered.

197. The machine-readable medium of claim 196 further comprising: preparing one or more part order requests based upon the first purchaser's selections; storing the one or more part order requests in a transaction database; and submitting the one or more part order requests to the vendors selected by the first purchaser.

198. The machine-readable medium of claim 197 further comprising: receiving order confirmations from the vendors with respect to the one or more part order requests submitted; and presenting the order confirmations to the first purchaser.

199. The machine-readable medium of claim 188 further comprising: performing a canceUation function in response to the first purchaser's cancellation request.

200. The machine-readable medium of claim 188 further comprising: performing an order status function in response to the first purchaser's order status request.

201. The machine-readable medium of claim 188 further comprising: performing a part return function in response to the first purchaser's part return request.