EP1121657A4 - Gestion intelligente de transactions (itm) - Google Patents
Gestion intelligente de transactions (itm)Info
- Publication number
- EP1121657A4 EP1121657A4 EP00945325A EP00945325A EP1121657A4 EP 1121657 A4 EP1121657 A4 EP 1121657A4 EP 00945325 A EP00945325 A EP 00945325A EP 00945325 A EP00945325 A EP 00945325A EP 1121657 A4 EP1121657 A4 EP 1121657A4
- Authority
- EP
- European Patent Office
- Prior art keywords
- price
- item
- purchase order
- purchase
- trading
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
Definitions
- 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.
- pooling resources to form buying groups to better compete against large companies and leverage their "buying power.”
- 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.
- 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.
- 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.
- 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.
- It another object of the present invention to improve an independent company's buying power by substituting like items from lower cost suppliers.
- the present invention is directed to an intelligent transaction management system typically usable with Electronic Data Interchange (EDI).
- EDI Electronic Data Interchange
- 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.
- 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.
- EDI Electronic Data Interchange
- 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.
- 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
- Figure 11 is a diagram illustrating how the consolidation process is used with a purchase order.
- 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.
- a display 112 such as a cathode ray tube (CRT) or a flat panel display
- An input device 114 is coupled to the bus 102 for communicating information and command selections to the processor 104.
- cursor control 116 is Another type of user input device, 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.
- a computer system 100 such as the illustrated system
- 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.
- storage device 110 Such as storage device 110.
- the computer readable medium is not limited to devices such as storage device 110.
- 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.
- hard- wired circuitry may be used in place of or in combination with computer software instructions to implement the invention.
- 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.
- 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.
- ISDN integrated services digital network
- communication interface 118 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN.
- LAN local area network
- communication interface 118 is coupled to a virtual blackboard. Wireless links may also be implemented.
- communication interface 118 sends and receives electrical, electromagnetic or optical signals which carry digital data streams representing various types of information.
- 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.
- 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.
- 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.
- Internet 128 uses 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.
- a server 130 might transmit a requested code for an application program through Internet 128, ISP 126, local network 122 and communication interface 118.
- 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.
- 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
- 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.
- VECS inbox 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.
- 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.
- 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.
- 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.
- consolidations, substitutions, etc. are constructed into a stream of outbound transactions.
- 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.
- 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.
- 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).
- 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.
- an in-bound purchase order flow diagram is depicted.
- the process is started.
- 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.
- 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.
- 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.
- 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.
- 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.
- the projected dollar value of the consolidation are calculated which include the existing items plus items from this purchase order.
- the discount percentage is calculated for total dollar value.
- a better value is calculated for substitution or consolidation.
- FIG. 5 depicts the details of steps 450 and 485 illustrated in Figure 4.
- the process is started.
- a purchase order is started.
- 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.
- Substitute orders are added to a send queue and forwarded at the end of the handle order process in the notification module 226.
- the line item is removed from the current purchase order.
- the next line item is checked and if existing line items remain, then the process returns to step 510.
- a purchase order is complete and the process is ended at step 545.
- ASN inbound advance ship notice
- each ASN object contains a subordinate collection of order objects, each of which has a subordinate collection of item objects.
- the order object is passed, with its associated items, to a routine that compares the shipment data to the original order data.
- the next order is retrieved and the process returns to step 620 until each referenced order is reconciled.
- the ASNs are send to a send queue and at step 640, the process ends. Reconciliation includes full shipment per order.
- the process starts at step 700.
- the references are ordered from the ASN
- the system generated ASN is added to the send queue.
- the order reference is removed from the original ASN.
- 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).
- the purchase order acknowledgement (POA) data is obtained from the database.
- POA purchase order acknowledgement
- the existing shipment data is obtained from the database.
- the shipment is verified at step 755 and at step 760, it is continued for each item and loops back to step 750.
- the process is complete.
- a flow diagram of a de-consolidated order reference is depicted.
- the process is started at step 800.
- the reference is ordered.
- the component orders are retrieved.
- the ship quantity is pro-rated against the ordered quantity.
- 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.
- the order is reconciled at step 850.
- the process loops back for the next order back to step 845 and at step 860, the next ASN is evaluated.
- step 930 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.
- a purchase order number 12345 is depicted having five line items.
- the purchase order is received at step 505.
- 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.
- 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.
- 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' origin
- 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.
- 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.
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US35471399A | 1999-07-16 | 1999-07-16 | |
US354713 | 1999-07-16 | ||
PCT/US2000/018922 WO2001006430A1 (fr) | 1999-07-16 | 2000-07-12 | Gestion intelligente de transactions (itm) |
Publications (2)
Publication Number | Publication Date |
---|---|
EP1121657A1 EP1121657A1 (fr) | 2001-08-08 |
EP1121657A4 true EP1121657A4 (fr) | 2002-01-30 |
Family
ID=23394604
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP00945325A Withdrawn EP1121657A4 (fr) | 1999-07-16 | 2000-07-12 | Gestion intelligente de transactions (itm) |
Country Status (3)
Country | Link |
---|---|
EP (1) | EP1121657A4 (fr) |
AU (1) | AU5929000A (fr) |
WO (1) | WO2001006430A1 (fr) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9715500B2 (en) * | 2004-04-27 | 2017-07-25 | Apple Inc. | Method and system for sharing playlists |
US9607326B2 (en) | 2010-12-13 | 2017-03-28 | Oracle International Corporation | Order management system with a decomposition sequence |
US10083456B2 (en) | 2012-07-06 | 2018-09-25 | Oracle International Corporation | Service design and order fulfillment system with dynamic pattern-driven fulfillment |
US10387944B2 (en) | 2015-10-07 | 2019-08-20 | Oracle International Corporation | Management of revisions on revisions of orders |
Family Cites Families (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4799156A (en) * | 1986-10-01 | 1989-01-17 | Strategic Processing Corporation | Interactive market management system |
US5101352A (en) * | 1989-06-29 | 1992-03-31 | Carolina Cipher | Material requirements planning system |
US5592378A (en) * | 1994-08-19 | 1997-01-07 | Andersen Consulting Llp | Computerized order entry system and method |
US5664110A (en) * | 1994-12-08 | 1997-09-02 | Highpoint Systems, Inc. | Remote ordering system |
US5615109A (en) * | 1995-05-24 | 1997-03-25 | Eder; Jeff | Method of and system for generating feasible, profit maximizing requisition sets |
US5864822A (en) * | 1996-06-25 | 1999-01-26 | Baker, Iii; Bernard R. | Benefits tracking and correlation system for use with third-party enabling organization |
US6052667A (en) * | 1997-03-21 | 2000-04-18 | Walker Digital, Llc | Method and apparatus for selling an aging food product as a substitute for an ordered product |
US6101484A (en) * | 1999-03-31 | 2000-08-08 | Mercata, Inc. | Dynamic market equilibrium management system, process and article of manufacture |
-
2000
- 2000-07-12 AU AU59290/00A patent/AU5929000A/en not_active Abandoned
- 2000-07-12 EP EP00945325A patent/EP1121657A4/fr not_active Withdrawn
- 2000-07-12 WO PCT/US2000/018922 patent/WO2001006430A1/fr active Search and Examination
Non-Patent Citations (2)
Title |
---|
No Search * |
See also references of WO0106430A1 * |
Also Published As
Publication number | Publication date |
---|---|
EP1121657A1 (fr) | 2001-08-08 |
WO2001006430A1 (fr) | 2001-01-25 |
AU5929000A (en) | 2001-02-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6889197B2 (en) | Supply chain architecture | |
US8380553B2 (en) | Architectural design for plan-driven procurement application software | |
KR100961804B1 (ko) | 재고 제어 시스템 및 방법 | |
US20030110104A1 (en) | Enhanced vendor managed inventory system and process | |
US20030144852A1 (en) | Providing highly automated procurement services | |
WO2002044891A2 (fr) | Serveur de transaction generique | |
WO2002071282A1 (fr) | Portail de reseau entre entites commerciales adapte au marche du commerce de detail en magasin du type bazarette | |
WO2002029522A2 (fr) | Execution collaborative dans un environnement de production-distribution reparti | |
US20020069121A1 (en) | Supply assurance | |
KR100361594B1 (ko) | 컴퓨터 네트워크를 이용한 수출입 물류 정보 관리 방법 및관리 시스템 | |
KR100888749B1 (ko) | 병원 물품의 구매 및 물류 관리 시스템 및 방법 | |
CN1512421A (zh) | 采购管理系统及方法 | |
CN1629856A (zh) | 采购管理系统及方法 | |
US7197482B2 (en) | Method and apparatus for customer storefront operations | |
WO2001006430A1 (fr) | Gestion intelligente de transactions (itm) | |
KR101213541B1 (ko) | 요청 응답 방식형 기업간 전자상거래 시스템 및 방법 | |
WO2001052158A2 (fr) | Architecture de chaine d'approvisionnement | |
US20020091590A1 (en) | Fundraising system with creation, coordination, and order tracking tools | |
CN1510600A (zh) | 采购管理系统及方法 | |
KR100619529B1 (ko) | 상품 구매와 배송을 결합시킨 전자상거래 시스템 및 방법 | |
KR20220000530A (ko) | 전산네트워킹시스템을 이용한 수출입 운송 및 물류 데이터 관리 방법 및 처리 시스템 | |
KR20210102571A (ko) | 전산네트워킹시스템을 이용한 수출입 운송 및 물류 데이터 관리 방법 및 처리 시스템 | |
KR20210116973A (ko) | 네트워크를 이용한 자동 물류 정보 관리 방법 및 관리 시스템 | |
JP2003030505A (ja) | アクティブデータウェアハウスの処理方法 | |
JP2002230342A (ja) | 電子商取引仲介方法、システム、記録媒体、データベースおよびコンピュータプログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20010409 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT |
|
AX | Request for extension of the european patent |
Free format text: AL;LT;LV;MK;RO;SI |
|
A4 | Supplementary search report drawn up and despatched |
Effective date: 20011218 |
|
AK | Designated contracting states |
Kind code of ref document: A4 Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN |
|
18D | Application deemed to be withdrawn |
Effective date: 20030204 |
|
RBV | Designated contracting states (corrected) |
Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE |