WO2001006430A1

WO2001006430A1 - Intelligent transaction management (itm)

Info

Publication number: WO2001006430A1
Application number: PCT/US2000/018922
Authority: WO
Inventors: Joseph T. Bolavage; Robert G. Skyler
Original assignee: Corcentric, Inc.
Priority date: 1999-07-16
Filing date: 2000-07-12
Publication date: 2001-01-25
Also published as: AU5929000A; EP1121657A4; EP1121657A1

Abstract

The present invention is directed to an intelligent transaction management system typically usable with Electronic Data Interchange. The transaction sets representing purchase orders, invoices, purchase order adjustments and advance shipping notices are received by a trading engine (200) and destination addresses can be altered to provide best value purchasing for a group of small independent companies which are members of the buying group. The incoming purchase order includes a plurality of line items, typically including at least a quantity, price and part number. The trading engine deletes and adds line item numbers to purchase orders based on comparison of substitute products and consolidating purchase orders based on volume purchases. The electronic engine can recalculate line item quantities and price totals and generate new orders to other vendors based on substitutions and consolidations.

Description

INTELLIGENT TRANSACTION MANAGEMENT (1TM)

Field of the Invention The present invention relates generally to electronic commerce, and more particularly, to an electronic trading engine for pooling resources of a number of smaller independent companies to leverage purchasing power.

Background of the Invention Small businesses continue to lose market share to larger competitors who are able to operate more efficiently. Large companies are able to negotiate better prices from suppliers, and can standardize business processes, reducing internal costs thereby increasing large companies' operational efficiencies.

To remain in business, small companies are pooling resources to form buying groups to better compete against large companies and leverage their "buying power." There are many benefits to pooling resources including: better negotiating terms and conditions with suppliers, increased order volume discounts and rebates, higher fill rates, preferential treatment, inventory sharing, consolidated transportation and shipping, etc. However, these buying groups have been slow to adopt new technologies, stunting the buying group's ability to maximize purchasing and operational deficiencies. Conversely, larger competitors use technology to increase their competitive advantage. In short, buying groups need to use technology to level the playing field.

Traditional Electronic Commerce (EC) solutions provide a framework for sending/receiving electronic orders via Electronic Data Interchange (EDI) transaction sets, but do not provide a means for identifying, managing, and capitalizing on purchasing/fulfillment opportunities in real-time. Electronic Data Interchange is the capability to process data between a computer in one company with computers in any of their trading partners using a standard format. Data is exchanged in an error free, closed- loop process. For example, the generation of a purchase order that can be sent to another company's order entry system without human intervention is a common EDI application, especially when the purchaser is a buying group comprised of many independent companies. These independent companies do not have the necessary infrastructures to tie into each others business systems and purchase strategically, nor the ability to collectively analyze and capitalize on opportunities from the group- wide enterprise perspective. Additionally, the notion of buying at the lowest price is not always the "best value" to the purchaser. Many aspects of the purchase or trade should be considered to include: product availability, transportation/shipping costs, historical supplier fill rates, group volume discounts, group rebate maximization (e.g., will this purchase contribute to reaching the next rebate step as a group), product sales specials, generic equivalents (e.g., private-label parts), and the like.

In general, EDI documents have a predetermined destination address assigned by the individual purchaser/supplier for a particular trading partner. This common scenario is not sufficient for the successful buying group which needs to make purchasing decisions as a group and not at the individual level. Additionally, for the management of a buying group to manually group member orders and manipulate these orders for financial/strategic gains would be economically unfeasible and require the full-time attention of a dedicated staff of subject matter experts. For example, the ability to geographically combine like orders to minimize transportation costs, to substitute line items for generic "high-margin" equivalents, and to capitalize on group-wide volume discounts and rebates is a necessity to complete in today's market.

Thus, a need exists for a business solution that incorporates the capability to improve the management and overall effectiveness of a buying group's "purchasing power" to facilitate the immediate reduction of "operational costs" throughout the supply chain. A further need exists for the management of electronic transactions through the application of online automated decision support solutions, which can in real-time identify, analyze, and execute in an unattended fashion best value purchasing and fulfillment practices.

Summary of the Invention It is, therefore, an object of the present invention to provide an on-line trading engine that independently manages buying group transactions in automatic decision support.

It another object of the present invention to improve an independent company's buying power by substituting like items from lower cost suppliers.

It is yet another object of the present invention to consolidate purchase orders from various independent companies into a single purchase order to improve buying efficiencies. It is yet another object of the present invention to alter vendor destination addresses for EDI transactions based upon trading engine transaction management algorithms. It is yet a further object of the present invention to provide revised purchase orders, invoices, acknowledgements and advanced shipping notices based upon changes to purchase orders performed by the trading engine.

It is yet a further object of the present invention to de-consolidate consolidated invoices into multiple individual invoices for each independent company.

The present invention is directed to an intelligent transaction management system typically usable with Electronic Data Interchange (EDI). The transaction sets representing purchase orders, invoices, purchase order adjustments (POA's) and Advance Shipping Notices (ASN) are received by a trading engine and destination addresses can be altered to provide best value purchasing for a group of small independent companies which are members of the buying group. The incoming purchase order includes a plurality of line items, typically including at least a quantity, price and part number. The trading engine deletes and adds line item numbers to purchase orders based on comparison of substitute products and consolidating purchase orders based on volume purchases. The electronic engine can recalculate line item quantities and price totals and generate new orders to other vendors based on substitutions and consolidations. The trading engine can substitute line items for a comparable generic, private label and special sales line items. The trading engine can automatically delete line items and auto-generate new orders to substitute suppliers. The trading engine can consolidate multiple orders to a single order or a particular supplier (e.g., to gain a volume purchase discount). The trading engine can then automatically recalculate line item quantities and price totals. After invoices are received from suppliers for a consolidated purchase order, the trading engine can de-consolidate the consolidated invoice and generate multiple individual invoices to individual group members. The trading engine can automatically validate quantities and prices on related transaction sets (e.g., purchase orders and invoices). An archive is provided for automatically extracting transaction set contents for population of an SQL-compliant database for auditing, before and after transaction set manipulation, and data warehouse analysis and report generation. The trading engine can also automatically notify group members of trading engine indication and results, reconciliation discrepancies, vendor re-routing, etc., via e-mail Electronic Data Interchange (EDI) or mail boxes.

These and other objects of the present invention are achieved a computer implemented method of operating a trading engine having a plurality of trading members. A plurality of purchase orders are received, each having at least one line item, each of the plurality of purchase orders received from one of the plurality of trading members. It is determined whether each received purchase order permits at least one of substitution and consolidation. If the received purchase order permits substitution, a price on the line item is compared against a price offered to the trading engine for a substitute item and if the price for the substitute item is less than the line item purchase order price, the substitute item is substituted. If the received purchase order permits consolidation, a price on the line item is compared against a price offered to the trading engine for a larger consolidated volume and if the price for the consolidated item is less than the line item purchase order price, the consolidated item is added to the consolidation. Still other objects and advantages of the present invention will become readily apparent to those skilled in the art from the following detailed description, wherein the preferred embodiments of the invention are shown and described, simply by way of illustration of the best mode contemplated of carrying out the invention. As will be realized, the invention is capable of other and different embodiments, and its several details are capable of modifications in various obvious respects, all without departing from the invention. Accordingly, the drawings and description thereof are to be regarded as illustrative in nature, and not as restrictive.

Brief Description of the Drawings The present invention is illustrated by way of example, and not by limitation, in the figures of the accompanying drawings, wherein elements having the same reference numeral designations represent like elements throughout and wherein:

Figure 1 is a high level block diagram of a computer system usable with the present invention; Figure 2 is a high level logical architecture of a trading engine and a transaction server according to the present invention;

Figure 2a is a flow diagram of the process of using the data loading module of Figure 2;

Figure 3 is a logical architecture of the intelligent transaction management system according to the present invention;

Figure 4 is a diagram of a purchase order flow; Figure 5 is a flow diagram of a purchase order flow; Figure 6 is a flow diagram of an advance shipment notice flow process; Figure 7 is a flow diagram of a reconciliation according to the present invention; Figure 8 is a de-consolidation of an order reference according to the present invention;

Figure 9 is a verified shipment flow diagram; Figure 10 is a diagram illustrating how the substitution process is used with a purchase order; and

Figure 11 is a diagram illustrating how the consolidation process is used with a purchase order.

Best Mode for Carrying Out the Invention

A method and apparatus for using an electronic trading engine for pooling resources of a number of smaller independent companies to leverage purchasing power. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.

Hardware Overview Figure 1 is a block diagram illustrating an exemplary computer system 100 upon which an embodiment of the invention may be implemented. The present invention is usable with currently available personal computers, mini-mainframes and the like. The computer system 100 can be a "presence" as described below.

Computer system 100 includes a bus 102 or other communication mechanism for communicating information, and a processor 104 coupled with the bus 102 for processing information. Computer system 100 also includes a main memory 106, such as a random access memory (RAM) or other dynamic storage device, coupled to the bus 102 for storing information and instructions to be executed by processor 104. Main memory 106 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 104. Computer system 100 further includes a read only memory (ROM) 108 or other static storage device coupled to the bus 102 for storing static information and instructions for the processor 104. A storage device 110, such as a magnetic disk or optical disk, is provided and coupled to the bus 102 for storing information and instructions.

Computer system 100 may be coupled via the bus 102 to a display 112, such as a cathode ray tube (CRT) or a flat panel display, information to a computer user. An input device 114, including alphanumeric and other keys, is coupled to the bus 102 for communicating information and command selections to the processor 104. Another type of user input device is cursor control 116, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 104 and for controlling cursor movement on the display 112. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g.,) allowing the device to specify positions in a plane.

The invention is related to the use of a computer system 100, such as the illustrated system, for using an electronic trading engine for pooling resources of a number of smaller independent companies to leverage purchasing power. According to one embodiment of the invention, the use of an electronic trading engine for pooling resources of a number of smaller independent companies to leverage purchasing power is provided by computer system 100 in response to processor 104 executing sequences of instructions contained in main memory 106. Such instructions may be read into main memory 106 from another computer-readable medium, Such as storage device 110. However, the computer readable medium is not limited to devices such as storage device 110. For example, the computer- readable medium may include a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM, a FLASH- EPROM, any other memory chip or cartridge, a carrier wave embodied in an electrical, electromagnetic, infrared, or optical signal, or any other medium from which a computer can read. Execution of the sequences of instructions contained in the main memory 106 causes the processor 104 to perform the process steps described below. In alternative embodiments, hard- wired circuitry may be used in place of or in combination with computer software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.

Computer system 100 also includes a communication interface 118 coupled to the bus 102. Communication interface 108 provides a two-way data communication as is known. For example, communication interface 118 may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 118 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. In the preferred embodiment communication interface 118 is coupled to a virtual blackboard. Wireless links may also be implemented. In any such implementation, communication interface 118 sends and receives electrical, electromagnetic or optical signals which carry digital data streams representing various types of information. Of particular note, the communications through interface 118 may permit transmission or receipt of the purchase orders from distributors, advance shipping notices from suppliers, revised purchase orders and revised shipping notices to suppliers. For example, two or more computer systems 100 may be networked together in a conventional manner with each using the communication interface 118.

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

Computer system 100 can send messages and receive data, including program code, through the network(s), network link 120 and communication interface 118. In the Internet example, a server 130 might transmit a requested code for an application program through Internet 128, ISP 126, local network 122 and communication interface 118. In accordance with the invention, one such downloaded application provides for information discovery and visualization as described herein. The received code may be executed by processor 104 as it is received, and/or stored in storage device 110, or other non- volatile storage for later execution. In this manner, computer system 100 may obtain application code in the form of a carrier wave. The present invention is described with respect to buying groups purchasing hard goods. The present invention is easily modifiable to other business environments such as the financial market.

The logical architecture of the present invention is depicted in Figure 2. The present invention includes a trading engine 200 coupled to a transaction server 202. The transaction server 202 is coupled to one or more distributor systems 204 and to one or more distributor computer systems 206. The trading engine 200 includes a data manipulation module 208 and a web server module 210, which also includes a report engine and data archive. The web server 210 is coupled to a notification module 226. The notification module 226 performs two basic functions: (a) move transaction data from engine to the transaction server 202 and (b) generate e-mail for non-transaction messages. The data manipulation module 208 includes a data loading module 220, an identification module 222, a decision support module 224, a set manipulation module 228, a substitution module 229 and a consolidation module 230, both which are part of the set manipulation module 228, a utilities module 234, an EDI library and an on/off module 250. The data loading module 220 can pull data from flat files sent by either the distributor 204 or the distributor 206. The flat files are kept in RAM 106 and are typically loaded into database tables. The data loading module 220 is coupled to an identification module 222 which is used to analyze distributor and supplier profiles and stores an opportunity matrix which is used to determine whether an opportunity exists for a consolidation or a substitution. The decision support module 224 is coupled to the data loading module 220 and the decision support module 224 and is used to decide if there is any applicable adjustment to the purchase order such as a substitution or consolidation. The decision support module 224 can be used to decide distribution of advance shipping notices (ASN), purchase order adjustments (POA), and invoices, if consolidated. A messaging module 226 is coupled to a decision support module 224 and is also coupled to the web server 210. Messaging module 226 is used to determine the proper recipient and moves documents to their in-box. A substitution module 228 is coupled to the decision support module 224. A Transaction Modification module 228 is coupled to the decision support module 224. A substitution sub-module 229 makes and records applicable substitutions as discussed in detail below. A consolidation sub-module 230 makes and records applicable consolidations as discussed in detail below. An EDI Document Library 237 includes formatting and property specifications for Transaction types supported by the Engine. The messaging module 226 notifies distributors 204, 206 of any actions taken by the decision support module 224. The utilities module 234 includes a data utility for SQL stored procedures and a general utility for date formatting, generating unique transaction identifications, etc. The decision support module 224 applies pre-determined business rules to incoming transaction sets received from either the distributor 204 or the supplier 206. The decision support module 224 determines the optimum route for achieving a "best value" purchase. The trading engine 200 architecture is based on Microsoft Component Object Module (COM) which allows the integration of components written in a number of different languages. As such, the engine is a multi-lingual application with components written in Visual Basic, C++ and Java. The trading engine 200 takes into account such trading variables as quantity available, back order history, shipping costs, buy preferences, volume discount potential, consolidated buy opportunities and buyer credit thresholds.

The transaction server 202 is coupled to the distributors 204, 206 and to the on/off module 250. The transaction server includes a distributor outbox 260 coupled to a VECS inbox/partner outbox 262. As partners submit transactions, the transactions are routed through the electronic mailboxes to a location where the engine 200 can find them (VECS inbox). VECS outbox/partner inbox: the engine has one location to drop its output. From here the transaction server 202 picks it up, determines the appropriate EDI format and moves it to the partner's electronic inbox 262. A supplier inbox 264 is coupled to a VECS outbox 266. The notification module 226 is coupled to the VECS outbox 266.

Figure 2a is an end-to-end flow diagram of an inbound transaction. The process is started at step 250. The inbound transaction 252 can be sent and received in any number of ways, for example, either through the web, direct dialing and the like. The inbound transaction 252 is run through the data loader 220 which loads it into the database and turns the inbound transaction 252 to be used by the decision support module 224. The inbound transaction 252 can be an EDI transaction, an EDI transaction set, a web browser input, an e- mail attachment (formatted, but prone to error), and the like.

At step 260, data loading inserts the transaction data from the inbound transaction 252 into the data archive 210 and creates a software object to be used by the decision support module 224. The decision support module 224 is a support DLL file used to determine the transaction type, such as an invoice or purchase order.

At step 265, the decision support module 224 associates profile data with the appropriate transaction sets. At this point, the decision support module 224 organizes the transactions into groups by type and starts type-specific processing threads. Decision support is also receiving information from partner profile 280, which includes information on how to handle consolidation, substitutions and notifications to be performed. The partner profile is stored in set manipulation module 228. Using the inbound transaction 252 and partner profile, step 265 is performed.

The decision support step 265 then flows into three different steps or threads per transaction type. A thread is only started if necessary for each transaction type in the inbound transaction 252. A handle purchase order thread 272 is used for handling purchase orders, a miscellaneous transaction set thread 270 and a handle invoice thread 274. As a result of the various handle routines 270, 272, 274, e-mail and/or text notifications may be generated and automatically sent independently of the transactions and processing threads.

The end decision support 282 is then applied against business rules included in the set manipulation module 228. After all the threads 270, 272, 274 are completed, a transaction manipulation step 284 is used to rebundle the threads 270, 272, 274. The threads may expire or may continue to process while waiting on subsequent consolidations.

The threads 270, 272, 274 may be closed even though the engine may be waiting or additional consolidations because the threads may expire. At the conclusion of decision support 282 and at the transaction manipulation step 284, consolidations, substitutions, etc. are constructed into a stream of outbound transactions. At an outbound transaction step 286, the outbound transactions are moved to a send queue where the outbound transactions are picked up by the transaction server and forwarded to their end recipients.

The following are examples of transaction processes that can be implemented via the Intelligent Transaction Management (ITM) system of the present invention: Transaction set re-routing: alter vendor destination address for "best-value" purchase.

Electronic document re-generation: deletion and addition to line items, recalculation of line item quantities and price totals, generation of new orders "on-the-fly" to better- value vendors. Substitution: substitution of line items for comparable generic, private label, and special sales line items. Automatic deletion of line items and auto-generation of new orders to substitute vendor. Consolidation: consolidation of multiple orders to a single order for a particular vendor (e.g., to gain a volume purchase discount). Automatic recalculation of line item quantities and price totals including unit price optimization to take advantage of rebate opportunities. De-Consolidation: de-consolidation of a consolidated invoice (billing) to multiple individual invoices or de-consolidation of the consolidated advance shipping notice (receiving) to multiple independent receipts.

Reconciliation: automated validation of quantities and prices on related transaction sets (e.g., purchase orders and invoices). Archiving: automated extraction of transaction set contents and population to a

SQL-compliant database for auditing, before and after transaction set manipulation, and data warehouse analysis and report generation.

Notification: automated notification of ITM invocation and result, reconciliation discrepancies, vendor re-routing, etc. (e.g., via mailbox or e-mail). Refer now to Figure 3, where the client 320 can access, via a web browser, the transaction set status, view program status and the like, through a reporting interface 330. The reporting interface 330 is connected to the client 320 and a track 'n' trace module 340. Track 'n' trace module 340 can query into the engine 200 database archives to generate requested reports and statistics via an SQL server archive 350. Every action taken by the engine 200 is recorded in the database 350.

Refer now to Figure 4 where an in-bound purchase order flow diagram is depicted. At step 400, the process is started. At step 402 an inbound purchase order is received which comes from a trading partner's mailbox. The inbound purchase order is logged into the SQL server archive 350 database and exists as an object within the engine 200. At step 405, the originator of the inbound purchase order is identified within the document. Preferences of the originator are stored within the originator's profile in the system database 350. These preferences include whether the originator wants to participate in consolidated orders, enable automatic substitutions, etc. At step 410, the destination is identified within the document. Parameters are stored within the originator's profile and the system database 350. These parameters include consolidation, scheduling, discount amounts, rebate steps, etc. At step 415 it is determined whether the purchase order is a rush or emergency. If the purchase order is a rush or an emergency, it is not feasible to consolidate or substitute orders because the originator needs the ordered items immediately. If the determination is that the purchase order is a rush or an emergency, at step 420 the purchase order is forwarded to the destination. If the purchase order is not a rush or an emergency, at step 425, it is determined whether the originator wants to use the engine 200 functions. If the originator does not want to use the engine functions, at step 430, the purchase order is forwarded to the destination. If the originator does want to use the engine 200 functions, at step 435, it is determined whether the Originator wants to consolidate. If the originator does not want to consolidate, at step 440, it is determined whether the originator wants to substitute. If the originator does not want to substitute, at step 445 the purchase order is forwarded to the destination. If the originator does want to substitute at step 447, the discount percentage is set to equal zero. At step 450, a better value is calculated, including the substitution or original. At step 455, the purchase order is forwarded with remaining line items to the destination. At step 460, it is determined whether the originator wants to substitute. If the originator does not want to substitute, then at step 465, the engine can either start a new consolidation or add to an existing consolidation. The consolidated orders are added to a send queue but are not actually sent until the date/time specified by the supplier. If the determination at step 460 is yes, then at step 475, the projected dollar value of the consolidation are calculated which include the existing items plus items from this purchase order. At step 480, the discount percentage is calculated for total dollar value. At step 485, a better value is calculated for substitution or consolidation. At step 470, either a new consolidation is started or an existing consolidation is added to with remaining line items.

Refer now to Figure 5 where a purchase order being placed by the buying group is depicted. Figure 5 depicts the details of steps 450 and 485 illustrated in Figure 4. At step 500 the process is started. At step 505, a purchase order is started. At step 510, for each line item on the purchase order, at step 515 each line item is checked for substitutes by part number/part supplier. Substitution possibilities are stored in the system database 350. This list is maintained by the member partners as well as the buying group. At step 520, it is determined whether the substitution price is less than the order price. If the substitution price is less than the discounted order price, then at step 525, a new substitution order is started or the existing substitution order is added. Substitute orders are added to a send queue and forwarded at the end of the handle order process in the notification module 226. At step 530, the line item is removed from the current purchase order. At step 535, the next line item is checked and if existing line items remain, then the process returns to step 510. At step 540, a purchase order is complete and the process is ended at step 545. Refer now to Figure 6, a flow diagram is depicted for analyzing an inbound advance ship notice (ASN). At step 600, the process is started. At step 605, an inbound ASN is received. At step 610, the originator is determined. At step 615, each of the order references is retrieved from the ASN document. At step 620, for each referenced order, the process proceeds to step 625 where the details of the purchase order are reconciled. Each ASN object contains a subordinate collection of order objects, each of which has a subordinate collection of item objects. Here, the order object is passed, with its associated items, to a routine that compares the shipment data to the original order data. At step 630, the next order is retrieved and the process returns to step 620 until each referenced order is reconciled. At step 635, the ASNs are send to a send queue and at step 640, the process ends. Reconciliation includes full shipment per order.

Refer now to Figure 7, the process for reconciliation is illustrated. The process starts at step 700. At step 705, the references are ordered from the ASN At step 710, it is determined whether the order reference is consolidated. If the order is consolidated, then at step 615, the order reference is de-consolidated. At step 720, the system generated ASN is added to the send queue. At step 725, the order reference is removed from the original ASN. At step 730, the process is complete. If the order is not consolidated at step 710, then at step 735, the purchase order data is retrieved from the database. This returns order- specified shipment information in line item detail (e.g., quantities). At step 740, the purchase order acknowledgement (POA) data is obtained from the database. At step 745, the existing shipment data is obtained from the database. At step 750, for each item in the order, the shipment is verified at step 755 and at step 760, it is continued for each item and loops back to step 750. At step 765, the process is complete.

In Figure 8, a flow diagram of a de-consolidated order reference is depicted. The process is started at step 800. At step 805, the reference is ordered. At step 810, the component orders are retrieved. At step 815, for each component order, at step 820, the ship quantity is pro-rated against the ordered quantity. At step 825, the order details are added to the engine/generated ASN. The process is repeated at step 830 for the next component order. The process loops back to step 815 for each component order. At step 840, for each generated ASN, at step 845 for each order, the order is reconciled at step 850. At step 855, the process loops back for the next order back to step 845 and at step 860, the next ASN is evaluated. The process loops back to step 840 until all of the ASNs are reviewed. The process is completed at step 865. In Figure 9, a verified shipment flow diagram is depicted. This process is started at step 900. At step 905, the shipment item is retrieved. At step 910, it is determined whether the shipment quantity matches the order quantity. If the shipment quantity does not match the order quantity, then at step 915, the destination is notified that an erroneous quantity is being shipped. From either step 910 or step 915, the process proceeds to step 920, where it is determined whether the shipment quantity cancels a back order. At step 925, the back order list is decremented by the shipment quantity. The process is complete at step 930.

In Figure 10, a purchase order number 12345 is depicted having five line items. Referring back to Figure 5, the purchase order is received at step 505. For each line item on the purchase order at step 510, each line item is checked for substitutes by part number/part supplier. The purchase order 1010 is modified as purchase order 1020 and a purchase order VHD001 is generated to vendor CR at 1030, including Part No. ABC123XX at step 525. At step 530, the purchase order 1020 is modified and the line item is removed and the purchase order is depicted at 1040. Another line item is removed and a purchase order VHD002 is generated to vendor CRW as depicted it 1050. Again, the next item is checked at step 535 and modified purchase order at 1040 is again modified at step 525 and another purchase order at VHD003 is generated to vendor CR .

A consolidated purchase order is depicted in Figure 11 as 1110. Item D and Item A were substituted to an alternate supplier. Items B and C from Group Member No. 1 are added to a new consolidation based on the determinations made at steps 435 and 460. The purchase orders 1110 and 1120 are added together into a consolidated purchase order 1130. An ASN is generated by the supplier after the consolidated purchase order is forwarded to the supplier. The three percent discount is recorded within the trading engine database tables and is subject to agreement between the buying group and the individual supplier. This is the value that is applied to purchase order line items to determine the optimal value when deciding between substitutions and consolidations. The reconciliation process: when the engine receives ASN 0-1 it identifies a purchase order reference as a consolidated order. The engine retrieves the component orders from the system archive and prorates the ASN quantities against the order quantities per line item. These prorated amounts are used to automatically build system-generated ASNs against the original orders and forward them to the orders' originators.

Advantageously, by applying best business practices as transaction-based business rules, an organization can better manage its transactions in a real time and repeatable manner. A logical architecture of an intelligent transaction management system 300 is illustrated according to the present invention. The Transaction Server 410 reviews inbound transaction sets for implementation compliance and passes the transaction set to the Trading Engine which determines/executes the best- value purchasing scenario. The data is returned to the transaction server to be processed as an outbound transaction set. Similarly, supplier sent transaction sets such as the purchase order acknowledgement, advance ship notice, and invoice are reviewed and necessary action taken. For example, the necessary action could be if an item is back ordered as specified via a purchase order acknowledgement received from a client 320 through a transaction interface 330. The transaction server 310 translates input documents, such as a purchase order, and passes the input documents to the trading engine 200.

It should now be apparent that an Intelligent Transaction Management system solution has been disclosed within the purchasing and fulfillment areas of the supply chain which exhibits potential for increased profits, reductions in internal costs, and increased operational efficiencies. To remain competitive in business, small and mid-sized companies embrace advances in technology, which can provide them with the necessary tools to trade on equal ground with the market leaders.

It will be readily seen by one of ordinary skill in the art that the present invention fulfills all of the objects set forth above. After reading the foregoing specification, one of ordinary skill will be able to affect various changes, substitutions of equivalents and various other aspects of the invention as broadly disclosed herein. It is therefore intended that the protection granted hereon be limited only by the definition contained in the appended claims and equivalents thereof.

Claims

What is claimed is:

1. A computer implemented method of operating a trading engine, having a plurality of trading members, comprising: receiving a plurality of purchase orders, each having at least one line item, each of the plurality of purchase orders received from one of the plurality of trading members; determining whether each received purchase order permits at least one of substitution and consolidation; if the received purchase order permits substitution, comparing a price on the line item against a price offered to the trading engine for a substitute item and if the price for the substitute item is less than the line item purchase order price, substituting the substitute item; if the received purchase order permits consolidation, comparing a price on the line item against a price offered to the trading engine for a larger consolidated volume and if the price for the consolidated item is less than the line item purchase order price, consolidating the consolidated item.

2. The method of claim 1, comprising routing at least some of the line items of the received purchase order directly to a supplier for the line items of the received purchase order which requires rush processing.

3. The method of claim 1, comprising deleting line items based on said substituting and said consolidating step.

4. The method of claim 1, wherein each of the line items of the purchase order include at least an item number, a quantity, a price, whether substitution/consolidation would be permitted.

5. The method of claim 1, wherein each of the purchase orders has a vendor destination address and comprising changing the vendor destination address if the substitution step is performed.

6. The method or claim 1, comprising creating a revised purchase order and sending notification of the revised purchase order from the trading engine to the trading member that generated the purchase order.

7. The method of clam 1, comprising consolidating multiple purchase orders into a single purchase order to gain a volume purchase discount.

8. The method of claim 1, comprising automatically recalculating line item and price totals when said substituting and/or said consolidating step is performed.

9. The method of claim 1, comprising receiving a consolidated invoice and de- consolidating the consolidated invoice into multiple individual invoices and forwarding each of the multiple invoices to a respective trading member.

10. The method of claim 1, comprising relating purchase orders from trading members against invoices received from suppliers to determine actual quantities purchased and actual prices paid.

11. The method of claim 10, comprising automatically validating quantities and prices on related invoices and purchase orders.

12. The method of claim 1, comprising archiving related invoices and purchase orders into an SQL compliant database.

13. The method of claim 1, comprising automatically notifying trading members of a substitution or consolidation, reconciliation discrepancies or vendor re-routing.

14. The method of claim 13, wherein said notifying step uses e-mail.

15. The method of claim 1, wherein the purchase orders are received in EDI format.

16. A computer implemented method of operating a trading engine, having a plurality of trading members and at least one supplier, comprising: receiving a plurality of transaction sets, each having at least one line item, each of the plurality of transactions sets received from one of the plurality of trading members; determining whether each received transactions set permits at least one of substitution and consolidation; if the received transaction set permits substitution, comparing a price on the line item against a price offered to the trading engine by the at least one supplier for a substitute item and if the price for the substitute item is less than the line item purchase order price, substituting the substitute item; if the received transaction set permits consolidation, comparing a price on the line item against a price offered to the trading engine by the at least one supplier for a larger consolidated volume and if the price for the consolidated item is less than the line item purchase order price, consolidating the consolidated item.