JP2002334272A - System for processing product information to support commercial transaction - Google Patents

Abstract

PROBLEM TO BE SOLVED: To cope with the problems of a conventional ERP system. SOLUTION: A system for processing product information to support commercial transaction is provided with a first data base for holding the product information including product explanation, product vendors and relating product price information, a data processor for receiving the product information and updating the first database so as to incorporate the received product information corresponding to the detection of records matching between the received product information and first database information, and an interface processor for communicating the updated product information to a device corresponding to the command of the user.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION
W. filed on Wed. A. Provisional Application 60 / by Banks et al.
No. 286,387 is a non-provisional application.

[0002] The present invention provides product information, including product prices, product descriptions, and supplier information maintained in one or more databases to support commercial transactions, such as purchasing, procuring, or billing products. Related to a system for processing.

[0003]

2. Description of the Related Art With the advent of e-purchase systems, users have used these systems to compare product information, examine prices and availability, and simplify the distribution process by simplifying distribution channels. Potential improvements can be made. However, users are restricted from making purchases through these systems due to purchase restrictions implemented by their information technology systems.

For example, in the field of health care, a material management system is typically a core application,
Healthcare (and other) purchase managers and material decision makers use a material management system to order medical supplies and related supplies. Frequently, users will have complex enterprise resource planning (ERP) support to support an organization's standard purchasing process.
A significant amount of time and money is invested in implementing the system. Currently, the ERP system does not allow for easy purchase and other commercial transactions involving elements outside the ERP system. Transactions involving such external elements may use an e-purchase system that does not have accurate product information such as prices, instructions and vendor information. This has many problems. Systems in accordance with the principles of the present invention address these and other problems.

[0005]

SUMMARY OF THE INVENTION It is an object of the present invention to address the problems of conventional ERP systems.

[0006]

Means for Solving the Problems The above-mentioned problems are described in a product description,
A first database for holding product information including product vendor and related product price information; and a record for receiving product information and matching received product information between the received product information and the first database information. And a data processor for updating the first database to incorporate the data in response to the detected data, and an interface processor for communicating the updated product information to the device in response to a user command. Solved by a system for processing product information to support commercial transactions.

[0007]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS A system for supporting commercial transactions is a user's ERP from any e-catalog system.
Synchronize e-catalog data to the system and reduce "bad" purchasing behavior that leads to the purchase of off-contract items with fraudulent prices. A system for processing product information to support a commercial transaction has a first database for maintaining product information, including product description, product vendor, and associated product price information. A data processor in the system receives the product information, and incorporates the received product information in order to incorporate the received product information in response to a matching record being detected between the received product information and the information in the first database. 1 Update the database. The interface processor communicates updated product information to the device in response to the user command.

A catalog system maintains and processes a catalog of product information that supports commercial transactions and has a two-way communication processor that supports communication with remote applications. The system also has a catalog database for maintaining product information, including product descriptions, product vendors and associated product pricing information. The catalog data processor receives product usage information from the remote application using the communication processor, identifies differences between the received product usage information and the catalog database product information, and remotely processes the product information according to the identified differences. Communicate with the application.

[0009]

FIG. 1 shows a system for processing product information to support commercial transactions, the system comprising a purchase database and a catalog database. The system advantageously integrates and continuously maintains item prices from an e-catalog system to an organization's purchasing database system, such as an enterprise resource planning (ERP) system including a material management information system (MMIS). Enable. The system advantageously comprises:
Automate synchronization of inventory items and consistently maintain accurate item prices. In addition, the system provides purchase history transactions. This purchase history allows the e-catalog system to recalculate prices based on volume discounts or side-by-side price contracts and easily request a contract compliance report. The system also synchronizes the eCatalog data from the eCatalog system to the user's Enterprise Resource Planning (ERP) system, reducing "bad" purchasing activities that lead to the purchase of off-contract items with fraudulent prices. This system allows the e-purchase system to deliver catalogs and price updates to the material management system. In this case, the purchase order delivered to the supplier contains the exact price,
Buyers do not need to keep the item price continuously,
The number of slip verification errors is significantly reduced. Further, the integration of the e-purchase catalog with the ERP system advantageously supports the ERP system in the scheduling of purchase tasks and related control operations. This synchronization makes the process more efficient and reduces the number of buyer centers, systems and staff.

The inventor has recognized that while the ERP system is good at managing purchase orders, for example, the accuracy of data at the time of a purchase order depends on user data entry. In contrast, eCatalog data is maintained by the data owner and the vendor setting the product price.
Thus, the eCatalog data is inherently relatively accurate. Purchasing through these e-purchasing systems has traditionally been limited by the business practices of the enterprise imposed by the ERP system. The disclosed system includes an e-catalog system and multiple suppliers, GPOs.
(Group purchasing organization) and users. The e-catalog system provides integrated product information in one or more locations so that all parties can work together to maintain accurate prices. By providing this data to the purchasing system that places the purchase order, price errors and slip errors are minimized.

FIG. 1 illustrates the interrelationships between the e-catalog vendor 13, the supplier 19 and the ERP purchase system 17. This interrelationship is due to the e-catalog vendor 13
And record communication between the supplier 19 and the ERP purchasing system 17. Here, the term record means
It refers to the information used by the functions of the system of FIG. 1 in supporting commercial transactions. This information is stored in a non-volatile, permanent or substantial form, such as a computer file, disk, CD ROM, DVD, or other electronic storage device, and is accessed by a computer or other electronic processing system. It is possible. Item 31 that intersects both e-catalog vendor 13 and purchasing system 17 represents a continuous price synchronization (CPS) system in accordance with the principles of the present invention. The e-catalog vendor unit 13 integrates product information from multiple suppliers and maintains current product prices.

[0012] The e-catalog vendor unit 13 also maintains a website, and users (typically those who do not have their own MMIS system) typically pay a transaction fee through this website. You can buy products. Such users typically manually maintain any internal purchasing systems they operate and reflect on data obtained from purchases through the e-catalog system. Users operating MMIS purchasing systems or other simpler purchasing database systems typically place purchase orders from these MMIS purchasing systems or other purchasing systems and purchase supplies directly from suppliers. The accuracy of the price contained in the purchase order depends on the values maintained within the user system. Often, these values change unknowingly to the user, resulting in a price mismatch between the shipped purchase order and the corresponding received voucher. In contrast, the system of FIG. 1 uses a continuous price synchronization (CPS) system 31 that maintains accurate prices from multiple suppliers, and automates the integration of this information into the purchasing system. This ensures that the outgoing purchase order contains the correct price and reduces slip inconsistencies.

Although the system is described in the context of a particular healthcare embodiment, this is merely an example. Although system implementations will vary for each MMIS system involved, the principles of the present invention apply to any purchasing system that is vulnerable to inaccurate prices that cause price mismatches between vendors and buyers. . Synchronizing product information between the e-catalog and the purchase database may involve manual steps (eg, user approval or item search or matching), or may be automatic, or a combination of both. In the embodiment just described, matching product information and updating prices includes updating internal files using a combination of manual and automatic steps.

In the configuration of FIG. 1, the continuous price synchronization system 31 includes an application that operates on both the e-catalog database system 13 (application 12) and the purchase system 17 (application 15). Purchasing system 17 receives an initial download of related data 20, including the purchase agreement, price, and data maintained in the eCatalog 13 database. The data 20 is an Internet file transfer protocol (FT)
Extensible Markup Language (XM)
L) format. In another embodiment,
The data 20 includes a record in another data format transmitted by another protocol. Subsequently, the purchasing system 17 receives a daily data update 20 of the changed or added related data of the e-catalog 13 database.

The system 31 includes a file transfer, scheduling, and e-catalog database unit 13
And the execution of the functions of the purchase unit 17 supporting the price synchronization operation. Purchase database unit 17
Includes an application 15 for its operation and its internal software maintenance. Application 15
A user interface menu on the display to support user interaction and commands. This allows the user to
Price updates received from the catalog 13 can be overridden, and price, vendor, and product information can be entered locally and independently of the unit 13. The purchase system 17 is provided with purchase history data 2 of the purchase database.
2 to the e-catalog database system 13 and e
The catalog unit 13 uses this history data,
Recalculate prices and identify out-of-contract purchases and fraudulent prices performed by unit 17. Unit 13 also uses this historical data for contract compliance to identify discrepancies. This discrepancy may be corrected to ensure that the purchase order complies with the supplier's current purchase agreement. Data 22 includes records in Extensible Markup Language (XML) format transmitted using Internet File Transfer Protocol (FTP). Alternatively, data 20 and 22 may be communicated using other data formats and protocols.

The system 31 includes an e-catalog unit 13
When a catalog file is received and loaded into a series of cross-reference (data mapping) tables in the unit 17 database, it synchronizes price, vendor, product, and other information between the unit 13 and unit 17 databases. This synchronization is achieved by using a mapping table to match the information items received from unit 13 with the corresponding items in unit 17 and replace the matching items with updated information. Unit 13 provides new material to supplement the information in unit 17's database and no information item matching is performed, but in unit 17 a new record element is created to contain additional information items . Vendor records (ie, records associated with a particular vendor) are manually matched before information items contained within the particular vendor record are matched. When manually matching vendor records, the user compares certain fields to determine if a matching vendor exists on the file. These fields include, for example, supplier name, electronic data exchange (EDI) number and address. EDI numbers and other items can be found in the December 1997 publication of the Data Interchange Standards Association (DISA) in the Certification Standards Committee EDI Standard (ASC) X12 Release 00.
4010 (http: //www.x
12. org /). Each information element in the vendor record updates the information item in unit 17 with the corresponding item received from unit 13 either by the matching of system 31 (automatic matching process) or by manual matching (including user intervention). Are synchronized (ie, made the same).

In this embodiment, the user is automatically matched, ie, provided by the e-catalog 13 associated with a particular vendor, with the corresponding particular vendor of the same particular vendor in the database of the purchasing system 17. You are given information (via a display menu generated by the system 31) about the record that is automatically matched to the record. The automatic matching is performed as soon as the purchase system 17 receives the updated record information from the e-catalog 13. Further, the user is prompted to approve replacing the vendor record price information item in unit 17 with the corresponding vendor record price information item received from e-catalog 13 before an update of the unit 17 database is performed. It is. The user can visually inspect the existing record item and the proposed replacement item and check the validity of the update prior to accepting the change. System 31 matches eCatalog 13 vendor record items with corresponding system 17 database items as records and record items are loaded into a series of cross-reference tables in system 17. The cross-reference table is used by system 31 to map information items from unit 13 to corresponding information items in unit 17. The system 31 performs the vendor record matching by comparing the supplier side number and the manufacturer side number of the received e-catalog 13 with the vendor side number and the manufacturer number of the purchasing system 17 database using a predetermined standard. Additionally, other record fields are compared to determine a match that includes the item description, generic name, manufacturer name, and Universal Product Number (UPN) code.

The system 31 also supports a manual vendor record matching function that starts at the discretion and command of the user. The manual matching function performs matching based on the same field comparison as described in the automatic matching function, but displays the matching items for parallel visual inspection by the user and comparison and approval by the user. Do. Further, the manual matching function of system 31 supports comparison and matching of elements in the vendor record information item description field. To this end, the system 31 searches key fields in the description field based on data selected and entered by the user. The user is presented with a menu display, which shows a side-by-side comparison of the item description field with other fields of the eCatalog 13 and the purchase system 17 vendor record. This allows the user to make a visual comparison and approve or reject the record update. The system 31 creates a report that identifies matched and unmatched records. The system 31 also creates a report identifying either fields that have been truncated or fields that are the result of an update in the record information received from the unit 13. In alternative embodiments, the vendor records and record items may be matched fully automatically without user intervention, or semi-automatically, including user intervention in response to a displayed prompt. Is also good.

The system 31 also uses the record data received from the e-catalog 13 to update the purchasing system 17 to accommodate other types of price adjustments, including special offers and time-sensitive adjustments. . Such updates may include incentives, such as, for example, low-priced and commission-free sales for August, or may include, for example, tax adjustments. These types of price adjustments may be initiated by a contract management processor within the e-catalog system 13 or may be initiated from within the purchasing system 17. As described above, the price change that occurs in the e-catalog system 13 is supplied to the update file, and the update file is repeatedly transmitted from the e-catalog system 13 to the purchase system 17. Updates may be made, for example, within a day, every day, every week, or by the number of requested item updates that meet a predetermined threshold level. When the period of the price adjustment such as the special offer expires, a new price is supplied from the e-catalog system 13 to the update data of the unit 17. In an alternative embodiment, as previously described, system 31 may include prices derived from multiple e-catalog databases (not just a single e-catalog database 13 described in the embodiment), The information of the product and the vendor is synchronized with the information of the purchase system 17. However, in this case, the system 31 reformattes the export file of price, product and vendor information from such multiple e-catalog databases to be compatible with the import file request of the purchasing system 17.

In the configuration of FIG. 1, the e-catalog system 13
Communicates with the product supplier 19 to obtain products, prices, and contractual terms and other information in a record 29 that is compatible with the EDI832 format. The EDI832 standard is an American National Standards Institute (ANSI) ASC X12 E that provides electronic exchange of product price, sales value and contract information.
DI standard. EDI 832 record 29 is implemented in Extensible Markup Language (XML) and transmitted using Internet File Transfer Protocol (FTP).
Further, the purchasing system 17 communicates the purchase order to the product supplier 19 using different formats. These different formats may include, for example, conventional fax purchase orders or EDI850 format purchase orders. The EDI850 standard is an American National Standards Institute (ANS) that provides electronic exchange of purchase orders.
I) ASC X12 EDI standard. The record formats and protocols described here are only examples. In other embodiments, different record formats may be used to provide the required information and transaction data exchange. In another embodiment, the data 20, 22, 27 and 29 to be communicated are comma separated values (CSV).
Format or other data formats such as fixed record file format, or hypertext markup language (HTML), dynamic HTML
(DHTML), Standard Generalized Markup Language (SGM)
L) or other formats of records and transaction data. Also, such a record
It may be transmitted by another protocol or other protocol compatible with the Internet, such as Hypertext Transfer Protocol (HTTP). Further, the record items and transaction data 20, 22, 27 and 29
It may be transmitted as individual items or in a file as a batch of data items.

FIG. 2 shows a flowchart of a method for processing product information used by the application of system 31 (application 15) and the purchasing system 17 (FIG. 1) to support commercial transactions. Have been. After initialization in step 200, the application 15 proceeds to step 203 in FIG.
The product information including the product description, vendor and price information is stored in the database (FIG. 1) of the purchase system 17. In step 209, the application 15 stores the database of the unit 17 in step 206 into the e-catalog 1
Update with the product information received from 3. FIG. 4 shows that when the purchase database system 17 is updated, the e-catalog 1
3 shows an example of the record used. When the application 15 receives the record update approval from the user, the application 15
Purchase system 1 to transfer the received product information
7 is updated. By such matching, the unit 17 stores the product information record, and indicates that the product information record received from the e-catalog 13 relates to, for example, the same vendor and part. Application 15 also updates unit 17 prior to updating unit 17 data.
Verify that there is a difference between the product information record stored in the product information record and the received product information record. In another embodiment, the application 15 updates the database of the unit 17 only by detecting a difference in the record type between the product information stored in the unit 17 and the received product information. The difference between the product information stored in unit 17 and the received product information may be, for example, a difference in product price, vendor, inventory, price structure or description information. Further, differences in product price structure include differences in product prices, product quantity prices, or planned future price structures.

The application 15 detects a matching record by matching elements between the product information record stored in the unit 17 and the received product information record. Specifically, the application 15 identifies a matching vendor in the stored record and the received record, and identifies a matching information item in a record associated with the matching vendor. The application 15 updates the database information of the unit 17 in order to incorporate the received product information in response to the update approval by the user. However, in other embodiments, the application 15 responds to an acknowledgment indicating that the received information item matches a corresponding item in the database of unit 17 (ie, acknowledgment of the update is made on a per item basis). Update the database of unit 17. Alternatively, in another embodiment, the application 15 automatically updates the database of the unit 17 upon detecting the product matching information without user intervention.

The application 15 executes step 209
, A matching is performed according to a predetermined rule, and a cross-reference file record indicating the matching product information element is created. The application 15 uses a hierarchically and sequentially organized process in matching the received product information with the product information stored in the unit 17. The matching process checks the cross-reference file information of unit 17 to see if the information item has already been matched. If not, the process first matches the product vendor, and then matches the information in the record associated with the matched vendor. For example, when matching a vendor in the record of the e-catalog 13 illustrated in FIG. 4, the application 15 determines the supplier name 415 (FIG. 4), the supplier side number 413,
Supplier code 411, manufacturer name 409, manufacturer side number 4
07 and the manufacturer code 405 are matched. According to certain matching rules, at least two of these fields must be matched in order to declare a vendor match. Other fields not shown in FIG. 4 that may be used in other embodiments for vendor matching include a substitute manufacturer side number, manufacturer section, or manufacturer license code. If the cross-reference file information in unit 17 indicates that the particular vendor record has already been matched to the indicated record, the described vendor record matching process is bypassed.

When matching the product items in the record of the e-catalog 13 illustrated in FIG. 4, the application 15 uses the supplier number 413 in a hierarchical order.
(FIG. 4), the manufacturer side number 407, the element in the item description 425, and the universal product number (UPN) code 421 are matched. According to certain matching rules, at least two of these fields need to be matched in order to declare a product item match.
In other embodiments, other fields may be used for product item matching, where the manufacturer name 4
09 and a manufacturer section (not shown in FIG. 4). In other embodiments, different matching rules including different matching criteria and different record fields may be used to match either the vendor or the product item associated with the vendor. Other such embodiments include:
A contract name 419, a contract number 417, and a national drug code (NDC) 423 may be included. An alternative matching rule may use probabilistic matching, which involves weighting the match to indicate the probability of a match for a particular record field. When the matching is completed and the price update is approved by the user, the application 15
Is the updated price and the corresponding unit of measure (items 429 and 42 in FIG. 4) in step 209 of FIG.
The database of the purchasing system 17 is updated to transfer 7). As a result, the application 15 transmits the product information in the purchase system 17 to the e-catalog system 13
Synchronize with the corresponding product information in the remote database. Application 15 also updates the cross-reference file record already created in step 209 to indicate the particular information element that was matched.

The purchasing system 17 creates transaction related documents and messages using the updated product information in step 213 and communicates to the remote application in step 215. Specifically, the purchase system 17 uses the updated product information to place a purchase order (item 27 in FIG. 1).
And communicates this in step 215 to the remote application being used by the supplier (unit 19, FIG. 1). The purchase order is communicated to the remote supplier application via Internet compatible communication, but may alternatively be communicated by other forms of electronic communication or non-electronic communication such as fax or mail. Good. Alternatively (additionally), the purchasing system 17 creates other transaction-related documents or messages for communicating to the remote application. These transaction-related documents and messages are, for example, product technical specifications, slips, advance shipping notices, receipts of purchase-related documents, and reports of purchase order history. Transaction-related documents created by the purchasing system 17 are accredited standards committee EDI standards (AS
C) X12 release 004010 (http: // www)
w. x12. org /) and is compatible with the Electronic Data Interchange (EDI) format. An exemplary EDI format that can be used is
810), payment (EDI 820), (vendor)
Technical specifications (EDI 841), purchase orders (EDI 8
50), purchase order confirmation (EDI 855), advance shipping notice (EDI 856) and function response (EDI 997)
including. In other embodiments, alternative formats may be used to support the communication of transaction-related documents, including those in which the company has proprietary rights. In addition, the purchasing system 17 updates the internal transaction monitoring database at step 217 (FIG. 2) to indicate creation, communication, and receipt of a transaction-related document. For example, the purchasing system 17 updates the transaction monitoring database of the system 17 to indicate receipt of a purchase order confirmation or payment to the supplier.

In step 221, the purchasing system 17 starts displaying the updated product information and the related transaction record in response to the user command. Further, in step 223, the application 15 communicates product usage information including product purchase history data (item 22 in FIG. 1) to the e-catalog system 13 (FIG. 1). The product usage information communicated by the application 15 to the e-catalog system 13 may include product sales amount data, product part list data, or product transaction related data. FIG.
Ends in step 225.

FIG. 3 shows a flowchart of a method used by the application 12 (FIG. 1) of the e-catalog system 13 to support commercial transactions. After initialization in step 300, the application 12 keeps product information, including product description, vendor and price information, in the database of the e-catalog system 13 in step 305 of FIG. Application 12 may provide product information, including price and associated contract information, to a plurality of suppliers (eg, supplier 19 of FIG. 1) to maintain an internal product information database of system 13.
Receive from For this purpose, the price and sales catalog record 29 is created by the supplier 19 using the Extensible Markup Language (XML) format and the Internet compatible File Transfer Protocol (FTP).
(FIG. 1) is transferred intermittently to the e-catalog 13. This is performed when information suitable for transfer to the unit 13 is accumulated in response to a data request from the e-catalog 13 to the supplier 19 or at the initiative of the supplier. The transferred records use an electronic data interchange (EDI) structure, which is an EDI standard 832 that provides an electronic exchange of product price, sales value and contract information.
Compatible with (Certification Standards Committee EDI Standard (ASC)
X12 release 004010 and http: // www
w. x12. org /). In other embodiments, other record formats may alternatively be used.

The application 12 proceeds to step 310
The product usage information including product purchase history data, product sales amount data, product parts list data or product transaction related data is transmitted from the purchase system 17 to the record 22 (FIG. 1).
Receive through. FIG. 5 shows the e-catalog system 13
The record (22 in FIG. 1) used by the purchasing system 17 when updating the “.” With the product usage information is shown.
The application 12 processes the received product usage information at step 315 to identify fraudulent product prices, recalculate the purchase price of the product in the product usage information,
Identify contractual discrepancies and identify items not covered by the purchase agreement. 5 includes information items 505 to 505 that support the process of step 315.
529. Specifically, the record in FIG. 5 includes, for example, a purchase order identification number 505, a supplier name 415, a purchaser name 511, a manufacturer code 405, information items 517 to 521 related to quantity, a price 525, and other items. .

The application 12 proceeds to step 320
, The product information in the database of the e-catalog system 13 is updated based on the received product use information. E-catalog system 1 based on product usage information 22
3 can periodically synchronize its catalog of product items and associated prices with the product and price database of the purchasing system 17. The price obtained by system 17 may be reduced, for example, if a volume discount level has been reached thanks to previously ordered quantities. Thus, the user can order supplies via the purchasing system 17 based on accurate contract price information provided periodically by the e-catalog system 13. Also, based on the product usage information received by the e-catalog system 13, the e-catalog system 13 analyzes the compliance of the previously purchased products, and the product price and contract information supplied to the purchasing system 17 are typical. You can guarantee to comply with previous requirements. This gives e
The catalog system 13 can validate the prices received by the purchasing system 17, inform the purchasing system 17 of contract changes and price mismatches, and support monitoring of contract compliance. As a result, the purchasing system 17 can efficiently manage contracts, place accurate price purchase orders, accelerate overpayment collection, correct contractual variability, and identify accounting errors.

In step 325 of FIG. 3, the application 12 verifies that there is a difference between the product information stored in the database of the e-catalog 13 and the product information previously supplied to the purchasing system 17. In response to this verification, the application 12 communicates the updated product information to the purchase system 17 (FIG. 1). The process of FIG. 3 ends at step 330.

The process of FIGS. 2 and 3, the record format of FIGS. 4 and 5, and the architecture of the system of FIG. 1 are not unique. Other architectures, processes, protocols and record formats may be derived in accordance with the principles of the present invention to achieve the same purpose. The principles of the present invention are applicable in various environments for synchronizing product information, including price, vendor and product description, between different databases located remotely from each other. Still other protocols and record formats may be used to support communication and related transactions. The formats described herein that are compatible with the FTP protocol and XML and EDI are merely examples.

[Brief description of the drawings]

FIG. 1 includes a purchase database and a catalog database that processes product information to support commercial transactions;
1 illustrates a system according to the principles of the present invention.

FIG. 2 illustrates a flowchart of a method in accordance with the principles of the present invention used by a purchasing system to process product information to support a commercial transaction.

FIG. 3 illustrates a flowchart of a method in accordance with the principles of the present invention used by a catalog database system to process product information to support commercial transactions.

FIG. 4 illustrates a record used by a catalog system in updating a purchase database system in accordance with the principles of the present invention.

FIG. 5 illustrates a record used by a purchase database system in updating a catalog system in accordance with the principles of the present invention.

 ──────────────────────────────────────────────────続 き Continued on the front page (72) Inventor Morgan El Pepe USA Pennsylvania Hula Warrtown College Avenue 76 S (72) Inventor Louis Castillo United States Pennsylvania West Chester Ashbrook Dora Eve 1116 S

Claims (14)

[Claims] 1. A system for processing product information to support a commercial transaction, comprising: a first database for holding product information including product description, product vendor and associated product price information; Data for updating the first database to incorporate the received product information in response to a matching record being detected between the received product information and the information in the first database A system for processing product information to support a commercial transaction, comprising: a processor; and an interface processor for communicating updated product information to a device in response to a user command. 2. The data processor detects a matching record by matching elements between the received product information and the information of the first database, and the information of the first database is: The system of claim 1, comprising a matching vendor, and (b) a matching information item in a record associated with the matching vendor. 3. The data processor comprises: (a) an update approval, (b) product matching information, and (c) the first
In response to the user manually entering at least one of the approvals for identification of the received product information item that matches the corresponding item in the database,
The system according to claim 2, wherein information of the first database is updated to incorporate the received product information. 4. The data processor updates information in the first database to incorporate the received product information in response to detecting a difference between the information in the first database and the received product information. The system of claim 1, wherein 5. The data processor uses the updated product information to (a) purchase order, (b) product technical specification, (c) delivery slip, (d) advance dispatch notice, (e). 5. The system of claim 4, wherein the system creates at least one item of: a receipt of purchase-related documents and (f) a purchase order history report, wherein the system communicates the created item to a remote application. 6. The data processor updates information in the first database to record at least one of: (a) receipt of a purchase order confirmation; and (b) payment to a supplier. The system according to claim 4. 7. The data processor comprises: (a) a difference in product price information, (b) a difference in product vendor information, (c) a difference in product inventory, (d) a difference in product price structure, and (e) a product. Information in the first database for incorporating received product information in response to a difference between stored product information and the received product information, including at least one of the differences in the description information 5. The system according to claim 4, wherein said system is updated. 8. The difference in the product price structure is as follows:
8. A method according to claim 7, including at least one of: (i) differences in product prices, (ii) differences in product quantity prices, and (iii) differences in planned future price structures.
The described system. 9. The system includes a two-way communication network, wherein the data processor is responsive to the product usage information being communicated to a remote second database using the two-way communication network. 5. The system of claim 4, receiving product information from a second database. 10. The product usage information includes at least one of (a) product purchase history data, (b) product sales amount data, (c) product parts list, and (d) product transaction related data. The system of claim 4, wherein: 11. The data processor according to (a) detecting a difference between the product information in the first database and the product information in the second database, and (b) performing a periodic update initialization. Updating the product information in the first database to match the corresponding product information in the second database so that the corresponding product information in the remote second database is updated. 5. The system of claim 4, wherein the system automatically synchronizes with the system. 12. The data processor comprises: (a) an approval for an update; (b) product matching information; and (c) an approval for identification of received product information matching a corresponding item in the first database. Updating the product information in the first database to match the corresponding product information in the second database in response to a user manually entering at least one of the data in the first database, 5. The system of claim 4, wherein the product information in the database is synchronized with corresponding product information in a remote second database. 13. The received data processor by matching (a) a corresponding part number, (b) a corresponding item description, (c) a corresponding product name, and (d) a corresponding code. Matching records between product information and information in the first database,
The system according to claim 4. 14. A method for maintaining and processing a catalog of product information to support commercial transactions, the method comprising: maintaining product information, including product description, product vendor and associated product price information, in a catalog database; Receiving product usage information from an application, identifying a difference between the received product usage information and the catalog database product information, and communicating the product information to the remote application according to the identified difference. For maintaining and processing a catalog of product information to support commercial transactions.