SYSTEM AND METHOD FOR PROCESSING DOCUMENTS

Abstract: An electronic document processing system and a method for processing electronic documents between trading partners for a transaction is described. The system includes a comprehensive database that contains all the information necessary to process a purchase order, invoice, or other similar document. The system includes a validation portion that checks the information in the electronic document with the information in the database. The system also includes an outbound processing portion of converting the electronic document into a format required by the receiving trading partner. Information for the outbound processing is also contained in the database. A document sending portion is also included for sending the outbound document to the receiving trading partner.

Description: SYSTEM AND METHOD FOR PROCESSING DOCUMENTS The present application claims priority to U.S. Provisional Application No. 60/145,871 filed July 27, 1999 herein incorporated by reference in its entirety. Field ofthe Invention The present invention relates generally to a system for processing documents such as purchase orders and invoices between trading partners. Summary ofthe Invention The present invention includes a method for processing documents between trading partners. The method includes receiving an electronic document from a first trading partner into a document processing system having a database that contains database trading information for the trading partners, wherein the document contains transaction specific information. The method further includes validating the transaction specific information with the database trading information and creating an outbound document for sending to the second trading partner using the database trading information contained in the database. Still further, the method includes sending the outbound document to the second trading partner. The method ofthe present invention may also include the step of determining if the structure ofthe document can be read by the document processing system. The electronic document may be an EDI document, an XML document, or a non-EDI document. The outbound document may be selected from the group consisting of an EDI document, an XML document, a non-EDI document, and a facsimile document. The method ofthe present invention includes an electronic document that is a purchase order or an invoice. Still further, the electronic document may be received from a network of computers or from a value added network. Still further, the method includes recording each transaction in the database. The method may include an electronic document that contains purchase order information for purchasing at least one product from the second trading partner and the database contains product information for the second trading partner, the step of validating the transaction specific information further comprising comparing the purchase order information for each product with the product information. The present invention also includes a system for processing an electronic document between trading partners that contains transaction specific information. The system comprises a document receiving portion for receiving the electronic document from a first trading partner; a database that comprises, document structure information, database trading information for each trading partner, and outbound document information for each trading partner; a document structure validation portion for comparing the document structure with document structure information contained in the database; a document processing portion configured to compare the transaction specific information in the electronic document with the database trading information for each trading partner; an outbound processing portion that creates an outbound document using the outbound document information for sending to a second trading partner; and a document sending portion adapted to send the outbound document to the second trading partner. Further, the database may include database portions comprising a trading partner profile for each trading partner; a product listing portion that contains information for each product for each trading partner; a transmission queue defaults table; a promotional information portion for each product for each trading partner; a buying points portion that contains rules for governing a transaction between the trading partners; and an authorized product portion that contain a listing of authorized products for each trading partner; and wherein each ofthe database portions are in electronic communication with the document processing system. The document receiving portion may include an EDI receiving portion having an EDI input for receiving an EDI document and a network document receiving portion having a network document input for receiving a network document. The document sending portion may further include an EDI sending portion having an EDI output for sending an EDI document and a network document sending portion having a network document output for sending a network document, and a facsimile sending portion having a facsimile sending output for sending facsimile documents. Still further, the system may further include a database maintenance portion for updating the database. The network document receiving portion ofthe system may be connected to the internet. The present invention also includes a method for updating information in a record in a database in a document processing system comprising receiving a database maintenance electronic document from a trading partner into the document processing system, wherein the document contains database record update information for the trading partner; finding the record for updating; comparing the record update information with the information in the record; and updating the record with the record update information. The record update information may be adding a new record or deleting an existing record. Brief Description ofthe Drawings Figure 1 is a diagram illustrating a global view of a system that includes a document processing system in accordance with an embodiment ofthe present invention. Figure 2 is a diagram ofthe document processing system shown in Figure 1. Figure 3 is a diagram of a database for the document processing system shown in Figure 2. Figure 4 is a diagram of an overview of a document processing system in accordance with one embodiment ofthe present invention. Figure 5 is a diagram of a document structure validation system for the document processing system shown in Figure 4 Figures 6a and 6b are diagrams for a purchase order validation system for the document processing system shown in Figure 4 Figures 7a and 7b are diagrams for an invoice validation system for the document processing system shown in Figure 4 Figure 8 is a diagram for a database maintenance validation system for the document processing system shown in Figure 4 Figure 9 is a diagram for an outbound document processing system for the document processing system shown in Figure 4. Detailed Description ofthe Preferred Embodiment The present invention generally relates to processing documents for a transaction between two parties. The parties to the transaction are hereafter referred to as trading partners The type of documents that may be processed include purchase orders, invoices, database maintenance documents, and other documents used in a transaction between trading partners. More particularly, the present invention is applicable to trading partners in industries that buy and sell products, supplies, materials, or goods through a supply chain. Trading partners include, but are not limited to, customers, retailers, wholesalers, distributors, suppliers, sales and marketing organizations, manufacturers, and shipping companies. While the invention is applicable to a wide range of industries, the invention will be described in the context ofthe consumer package goods industry. Typically, in the consumer package goods industry, as well as other industries, manufacturers either appoint sales and marketing organizations to represent them in specific geographical markets or they act as their own sales and marketing organization. One sales and marketing organization may represent more than a thousand different manufacturers. The sales and marketing organizations and manufacturers traditionally use in-house computer systems to provide a variety of services. These services include (1) sales and marketing to customers such as retailers, wholesalers, and distributors; (2) retail store checking; (3) foodservice operator calls; (4) entry, expediting, and validating purchase order data received from the customers for the product to be supplied by the manufacturer; (5) resolving price and promotional discrepancies between the customers' purchase order and the manufacturers' published pricing; (6) maintaining manufacturers' product and promotional information on their individual database; and (7) keeping customers up to date on promotions, new items, and price changes. When each sales and marketing organization or manufacturer is handling these services, it results in an inefficient process. There are many different computer systems maintaining separate databases. Paper purchase orders have to be entered and validated by a customer service representative where the representative is visually checking each item, price, and promotion for eligibility. The representative is makings changes to the order based on their knowledge ofthe relationship with the customer. In order to process electronic data interchange ("EDI") document purchase orders, each order processing computer requires EDI translation software and results in value added network ("VAN") charges. Many individual computer systems are unable to handle individual customer's non-standard EDI elements. Further, the EDI purchase orders typically have to be checked by a customer service representative. In the case of a sales and marketing organization the order still has to be forwarded to the manufacturer which requires additional computers and EDI translation software and results in additional VAN charges. For non-EDI capable manufacturers the order has to be faxed to the manufacturer. Shipment tracking by the customer and manufacturer is also inefficient. The customer typically has to call the marketing organization for shipment status of an order. The representative for the marketing organization calls the manufacturer. The manufacturer calls the trucking company. The manufacturer then advises the marketing organization. The marketing organization then advises the customer. The present invention centralizes the processing of orders, invoices, the exchange of product and promotional information, and the providing of sales analysis to authorized users throughout the supply chain. This is accomplished by the use of an extensive database that contains all the relevant information about a trading partner and their relationship with other trading partners. The document processing system checks an order from a customer with information from the manufacturer that relates to that customer. The system is capable of evaluating various criteria relating to the transaction. For example, the system can evaluate whether a customer is authorized to purchase a particular product, the price for that customer, any required minimum amounts for that customer, and if there is a promotion the customer is eligible for. The result ofthe document processing system is that the orders are validated with minimal clerical intervention. With reference now to Fig. 1, there is shown a global view of a system 10 that includes a document processing system 100 in accordance with an embodiment ofthe present invention. Briefly, the document processing system 100 is capable of sending and receiving EDI documents through a value added network ("VAN") 12. Further, the document processing system 100 is connected to a computer network 14 by way of a network server 16. The network 14 may include one or more computers 15 in electronic communication with one another, the Internet, the Intranet, or any other network in which one or more computers and electronic communication with one another. Non-EDI electronic documents and XML documents 18 enter the document processing system 100 through the network 14 and the network server 16. Paper documents 20 may be placed into electronic form through a data entry station 22 in which the data entry station transmits the information in the paper document to the network 14 at which time it is then forwarded to the network server 16 and enters the document processing system 100. It will be appreciated that any trading partner that has access to the network of computers will be able to submit documents for processing. A data warehouse 24 stores the transaction history and information regarding the processing ofthe documents. This information may be posted to the network. With reference now to Fig. 2, there show a diagram for a document processing system 100 in accordance with an embodiment ofthe present invention. The system 100 includes an EDI document receiving portion 110 that has an EDI input 112 for receiving an EDI document from the VAN 12. The system 100 also includes a network document-receiving portion 114 that includes a document input 116 for receiving network documents from the network server 16. Alternatively, the document receiving portion may be configured to directly receive document from the network. The system 100 includes a document structure validation portion 118, a purchase order-processing portion 120, an invoice processing portion 122, a database maintenance portion 124, a database portion 126, and an outbound processing portion 127. Also included in the system 100 is an EDI sending portion 128 that has an EDI output 130 for sending EDI documents to the VAN 12. A network sending portion 132 having a network output 134 for sending network documents to the network server 16 for posting to the network 14 is also included in the system 100. Alternatively, the network sending portion may be configured to send documents directly to the network. Further the output may also be configured to send documents to the data entry station 22. Still further, a facsimile sending portion 136 having a facsimile output 138 for sending facsimile documents may also be included in the system 100. Each ofthe above parts ofthe system 100 are connected by a data bus 102 which may also be connected with other systems. The Document Processing System Database The document processing system 100 relies upon the database portion 126 for information about the trading partners when processing a purchase order or invoice. The database is extensive and contains information regarding the relationship between trading partners. The database 126 contains enough information to process a purchase order, invoice or other similar document with only a minimal amount of clerical intervention, if any at all. An exemplary database 126 for the document processing system 100 is shown in Fig. 3. The database 126 contains trading partner profiles 140. Each trading partner, including but not limited to, a customer, manufacturer, distributor, supplier, or shipper, may have unique methods and requirements for sending purchase orders and other documents, as well as unique requirements for receiving them. The database 126 includes information used for automating the transmission process in the trading partner profile 140 for each trading partner. The trading partner profile contains detailed information for both inbound and outbound transmissions, all EDI and XML codes and identifications necessary for validating the structure and content ofthe document, EDI and facsimile formatting specifications, any customized rules and options for transacting business with the trading partner. The database 126 may also contain transmission queue defaults 142. Each buyer and seller relationship (buying point) may have one or more methods by which documents are to be transmitted. The document processing system 100 uses the transmission queue defaults portion 142 and any other information necessary in the database 126 to automatically queue up each transaction as required. Marketing organization profiles 144 may also be included in the database 126. These profiles would contain information such as names and addresses ofthe organization and the marketing organization group identification number or tag. The database 126 may also contain a supplier profile portion 146. This profile 146 would include information such as addresses and contact, shipping methods and instructions, pricing methods, market area and product classifications, sales and marketing organization, and commission calculation methods and rates. The database 126 also includes a product-listing portion 148. The product- listing portion 148 preferably contains every product sold by every manufacturer. The product-listing portion 148 may contain information regarding the description, packaging and dimensions ofthe product. Further, the products listing portion 148 would preferably contain UPC and other identification numbers for the products. Product classifications, ordering, pricing and tracking units including factors for converting from one unit to another may also be included in the product listing 148. Preferably, past, current and future prices are also maintained in the product-listing portion 148. The database 126 also contains customer profiles 150. These profiles include information about the customer, such as bill-to information, ship-to locations and delivery instructions. The database 126 may also contain information on promotions for a product in a product promotion portion 152. The document processing system 100 allows promotional data to be customized according to customer and by product. Promotional information may include, but is not limited to, date eligibility, customer eligibility, product eligibility, allowance types and amounts, minimum and maximum quantities (case caps) allowed, any special conditions, other pertinent promotional data. The database 126 may also contain a buying point's portion 154. The buying points portion 154 contains information and data about the relationship between a particular buyer and seller and may include such information as pricing, the terms of the transactions, manufacturer designations (market areas, regions, etc.), and specific business rules and overrides. In a preferred embodiment, the database 126 may contain an authorized product portion 156 that contains a table of authorized products. The table contains all ofthe products that each customer buys and includes information such as customer warehouse codes, authorization and discontinue dates and suggested retail prices. The database 126 also includes a purchase order and invoice transaction portion 150 that contains information such as order header data, order detail or product data, promotion details, notes, comments, shipping instructions, and inbound EDI raw data. Further, the database 126 may contain several tables that contain information for automating the document processing system. These tables may include an EDI mapping table 160. The table 160 maps database fields to EDI segments according to trading partner-specified requirements. Further, a facsimile mapping table 162 may be included for mapping database fields to facsimile documents according to trading partner-specified requirements. Other tables such as a forms table portion 164 for generating trading partner specific forms may also be included. Further, the database may contain an XML document type definition ("DTD") portion 214 for parsing XML documents. The database 126 may also include a history compilation portion 166 for compiling the transmission history for a transaction. The database 126 archives all outbound transmissions and includes information such as the date, time and status of the transmission. All ofthe portion ofthe database 126 are in communication with one another and with the rest ofthe document processing system by a database data bus 167. The database may utilize a Progress ™ Relational Database. The database and software system may be written in Progress™ 4GL programming language. However, other suitable programming languages and database formats may be used. The Document Processing System Generally, the document processing system receives a document from a trading partner, such as a purchase order or invoice, in electronic form for sending to a second trading partner. The electronic structure ofthe document is first validated to make sure the document is in a form the processing system can read. Upon structure validation, the type of document is ascertained and the content ofthe document is validated against information and rules between trading partners contained in the database. When the content ofthe document has been validated, the document goes to an outbound document processing system. The outbound processing system uses information and rules contained in the database to prepare the document for forwarding to the second trading partner. One embodiment ofthe present invention provides for automatically sending pertinent sales and promotional history to an internet based data warehouse and reporting tool for sales analysis. The system ofthe present invention can receive and process a variety of different types of documents. These documents include, but are not limited to, EDI documents, XML documents, and non-EDI electronic documents. The document processing system can receive and process EDI documents, using XI 2 standards, as well as XML documents. The document processing system forwards these documents, upon validation, to manufacturers, suppliers, and other trading partners in either EDI, XML or text formats which the system will customize to the receiving trading partner's specifications. In one embodiment, the system receives and transmits EDI documents through a VAN. The VAN acts as "store and forward" conduits for EDI transactions in all types of industries. However, the VAN does not typically validate the contents ofthe EDI documents that pass through them. With reference now to Fig. 4, there is shown a diagram illustrating an overview of the document processing system 100. An EDI document 168 enters the document processing system 100 through a VAN 12 and subsequently goes through the document structure validation system 170, to be described in detail below. Non- EDI electronic documents 18 and XML documents 19 enter the document processing system 100 through the network 14 and proceeds to the document structure validation system 170. Information from paper documents are entered and converted to an electronic document at a data entry station 22. Each of the above documents enter the document structure validation system 170 where the electronic structure ofthe incoming document is validated to make sure the document structure is one the document processing system 100 can evaluate. Upon document structure validation, the electronic document is sent to a document type decision gate 172. In one embodiment ofthe present invention the system can process database maintenance documents, purchase order documents, and invoice documents. If the document is a database maintenance document, it is forwarded to the database maintenance portion 124 where the content of the document is checked and validated against information in the database 126. An invoice, is forwarded to the invoice-processing portion 122. If the document is a purchase order, it is forwarded to the purchase order-processing portion 120. After the content of an invoice or purchase order has been validated, a XML document is created at XML point 174 and sent to the network 14 and data entry station 22. If the document needs editing, edits can be made at the data entry station 22. Once the content ofthe document has been validated, the document is sent to the outbound processing portion 127. The invoice or purchase order document is formatted for outbound transmission at the outbound processing portion. The document then passes to an outbound EDI decision gate 176 where an EDI document is forwarded to an EDI document sending point 178 where the EDI document is sent to the VAN 12 and subsequently to the intended trading partner such as a manufacturer, supplier, or customer 180. If the outbound document is not an EDI document, it is forwarded to an outbound XML decision gate 182. An outbound document that is an XML document is forwarded to an XML document sending point 184 where the XML document is forwarded to the manufacturer, supplier or customer 180 in XML format. If the outbound document is not a XML document it is forwarded to a fax sending point 186 where the document is then faxed to the manufacturer or customer 180 using third-party facsimile software 188. The Document Structure Validation System As discussed above, once a document is received in the document processing system, the document is forwarded to a document structure validation portion or system 170. The purpose ofthe validation system is to ensure that the document being received has the proper electronic structure that the document processing system 100 will be able to understand and process. With reference now to Fig. 5, there is shown a document structure validation system 170 in accordance with the present invention. An inbound electronic document 190 enters an EDI document decision gate 192. If the document is an EDI document, it is forwarded to an EDI translator 194 where the EDI document is translated using information from an EDI data dictionary 196 contained in the database 126. Upon EDI translation, the document is forwarded to a functional acknowledgment decision gate 198. If the inbound electronic document is a functional acknowledgment, the document is sent to an update transmission status point 200 where the database 126 is updated with the functional acknowledgment information. If the inbound document was not a functional acknowledgment, the document passes to a structure verification gate 202 where the document structure validation system 170 uses the EDI mapping table 160 and information contained in the database 126 to validate the structure ofthe EDI document. If the structure ofthe document is validated, the document is sent to an acceptance functional acknowledgment point 204 where an acceptance functional acknowledgment is sent to the sending trading partner and the document is then sent to the document type decision gate 172. If the structure ofthe document is not correct, the document is forwarded to a rejection functional acknowledgment point 206 where a rejection functional acknowledgment is sent to the sending trading partner. Further, if the structure ofthe electronic document is not correct, the document is also sent to an e- mail support staff point 208 where support staff are notified by e-mail that the electronic document did not have proper structure. If the inbound electronic document 190 is not an EDI document, the document passes to a XML document decision gate 210 where XML documents are forwarded to a XML parser 212. The XML parser 212 uses information from XML document type definitions ("DTD") portion 214 contained in the database 126 to translate the XML document. Upon translation, the inbound electronic document 190 is sent to a structure verification gate 216 where the structure ofthe document is verified using information contained in the database 126. If there is a problem with the structure, the document is sent to an e-mail support staff point 218 where support staff are notified by e-mail that there is a problem with the inbound XML document. Once the structure ofthe document has been validated, the document is sent to the document type gate 172. If the inbound electronic document is not a XML document the document is forwarded to a custom translation point 220 that uses customized rules 222 contained in the database 126 for translating the inbound electronic document. Many trading partners have their own format for electronic documents. This information is contained in the database 126 and is used to translate the document. Once the document has been translated, it is forwarded to structure validation decision gate 224 where problems with the structure validation are forwarded to an e-mail support staff point 220 where support staff are e-mailed notification of any problems with the structure. With reference back to Figure 4, once the inbound document structure has been verified, the document is forwarded to the document type decision gate 172 where the type of document is determined and forwarded to the appropriate validation system. Purchase Order Validation System A document that has had its structure validated is sent to a document type decision gate 172. If the document is a purchase order, it is forwarded to a purchase order validation system 120 where the contents ofthe purchase order are checked and validated. Upon validation, the purchase order goes to the outbound purchase order processing system 127 where the purchase order is formatted according to the manufacturer's specifications. Once the purchase has been successfully formatted, the purchase order is sent to the intended trading partner such as a manufacturer or supplier. With reference now to Fig. 6a and 6b, there is shown a diagram ofthe purchase order validation system 120 in accordance with the present invention. The purchase order validation system checks the customer's request contained in the purchase order with requirements from the manufacturer or supplier. If there are errors or discrepancies between the customer's request and the manufacturer's requirements, the purchase order validation system reports the errors to the data entry station 22 and logs them in the database 126. Turning now to Fig. 6a, the purchase order document is first sent to a validation gate 226. The validation gate 226 checks the header information contained in the purchase order with the related information in the database 126. The database 126 contains customer specific rules and information for a given manufacturer. The validation gate 226 compares the header information contained in the purchase order with the information in the database 126 and any customer and manufacturer specific rules. Errors are recorded in the error log 240 and reported to the data entry station 22. Once a purchase order has passed through the validation gate 226, it is forwarded to a product detail process point 228 where each product is processed. After each product has been validated, the document passes to a more products decision gate 230 until all products on the purchase order have been validated. The validation process begins with valid product identification number gate 232. If the requested product does not contain a valid identification number, the product goes through a valid alternate product identification 234. If there is no valid alternate product identification, the product is sent to a valid customer product identification gate 236. If the product successfully passes through any of these gates, the customer designated units for the products are converted to the manufacturer's units at the convert customer units to manufacturer unit point 238. If the product identification number cannot be determined, an error is registered on the error log 240 in the database 126 and reported to the data entry station 22. Once the units have been converted, the units are checked in a valid conversion gate 241. Upon successful unit conversion, the product information is sent to an authorized product gate 242. The authorized product gate 242 determines whether the products are authorized by the customer. Unauthorized products go to an override authorization gate 244 where the rejection can be overridden. In the event of an override, the database 126 is updated at the add to authorized product table point 246 to add the product to the database. As shown in Fig. 6b, authorized products are sent to a price calculation point 248 where authorized products are assigned prices listed in the database 126 for that manufacturer, customer and product. If there are any eligible promotions, they are applied to the product. The product is then forwarded to a price comparison decision gate 250 where the calculated price is compared to the price the customer listed for the product on the purchase order. The product then passes to a promotion match decision gate 252 where any promotions listed in the purchase order are compared to eligible promotions listed in the database 126. The product is then forwarded to a mandatory fields decision gate 254 where the purchase order is checked to make sure all mandatory fields are populated. If there is a rejection in any of these decision gates, the product is sent to an override authorization decision gate 256 where any ofthe rejections can be overridden. If a rejection is not overridden, an error corresponding to the type of rejection is recorded in the error log 240 and reported to the data entry station 22. Once all the mandatory fields have been populated, the document is sent to an order totals and commissions point 258, where the totals and commissions are calculated based on specific customer and manufacturer information contained in the database 126. The document is then sent to an all-rules satisfied gate 260 where the document is checked against all the rules that should be applied to this transaction that are contained in the database 126. If all the rules are not satisfied, the document is sent to an override authorization decision gate 262 where the rejection maybe overridden. If the rejection is overridden or all the rules are satisfied, the results from the calculations and decision gates are recorded in the database 126. If all the rules were not satisfied and were not overridden an error is recorded in the error log and reported to the data entry station 22. Referring back to Fig. 6a, once the rules are satisfied or overridden, the database 126 is updated with the product information and the document goes back to the each product detail process point 228 and subsequently passes to a more products decision gate 230. If there are more products to be analyzed, they are processed as just previously described until there are no more products remaining at which time the document is sent to XML point 174. With reference back to Figure 4, after the purchase order has been validated and there are no more products to validate, if there were errors with the validation of the purchase order, the purchase order containing error messages is sent to a data entry station 22 in XML format from XML point 174. The data entry station 22 may correct the errors in the purchase order document and sent it back to the document processing system 100. Error-free purchase order documents are sent to the outbound processing system 127. The outbound processing system 127 as will be discussed in detail below, uses information in the transmission queue defaults table 142 in the database 126 to determine what form the outbound purchase order document should take. Invoice Validation System When a manufacturer or other trading partner fills an order and generates an invoice, the invoice is received in the invoice validation system 122 Referring now to Figures 7a and 7b, there an invoice validation system 122 is shown The invoice validation system 122 has the same structure and many ofthe same components as the purchase order validation system 120 Many ofthe same decision gates and rules that were applied to the purchase order document are applied to the invoice document Turning now to Fig 7a, the invoice document is first sent to a validation gate 264 The validation gate 264 checks the header information contained in the invoice with the related information in the database 126 The database 126 contains customer specific rules and information for a given trading partner such as a manufacturer or supplier The validation gate 264 compares the header information contained in the invoice with the information in the database 126 and any customer and manufacturer specific rules Once an invoice has passed through the validation gate 264, it is forwarded to a product detail process point 266 where each product is processed After each product has been validated, the document passes to a more products decision gate 268 until all products on the invoice have been validated The validation process begins with valid product identification number gate 270 If the requested product does not contain a valid identification number, the product goes through a valid alternate product identification 272 If there is no valid alternate product identification, the product is sent to a valid customer product identification gate 274 If the product successfully passes through any of these gates, the customer designated units for the products are converted to the manufacturer's units at the convert customer units to manufacturer unit point 276 If the product identification number cannot be determined, an error is registered on the error log 240 in the database 126 and reported to the data entry station 22. Once the units have been converted, the units are checked in a valid conversion gate 278 Upon successful unit conversion, the product information is sent to an authorized product gate 280 The authorized product gate 280 determines whether the product is authorized by the customer Unauthorized products go to an override authorization gate 282 where the rejection can be overridden In the event of an override, the database 126 is updated to add the product to the database at the add product point 284 As shown in Fig 7b, authorized products are sent to a totals and commission calculation point 286 where invoice totals and commissions are calculated, and any invoice-specific rules are applied The document then passes to a rules satisfied decision gate 288 where a document that has satisfied all the necessary rules listed in the database 126 is sent to the purchase order matching gate 292 If all the rules were not satisfied, the document is forwarded to an override authorization gate 290 where the rules may be overridden If not, an error is recorded in the error log 240 and reported to the data entry station 22 Once all the rules have either been satisfied or overridden, the invoice is sent to an invoice and purchase order matching gate 292 If an invoice matches an un- invoiced purchase order, the purchase order data is replaced with the invoice data at the replacement point 294 The database 126 is updated to reflect the new invoice information If the invoice does not match an unvoiced purchase order, the document is sent to a purchase order origination decision gate 296 If the manufacturer's purchase orders are not normally processed through the document processing system 100, the document is forwarded to create a new invoice order point 298 where a new invoiced order is created. If the manufacturer's order should have been processed through the document processing system 100, an error is reported in the error log 240. Referring back to Figure 4, upon completion ofthe invoice validation, the document is sent to the XML document point 174 where an XML document reflecting the invoice and any errors is forwarded to the network 14 and the data entry station 22. Database Maintenance Validation System It is important that the database containing all the trading partner profiles be routinely updated and maintained properly. Incorrect information in the database will likely generate errors in the document processing system. The present invention may include a database maintenance validation system 124 where trading partners can update information in the database 126. With reference now to Figure 8, a database maintenance validation system 124 in accordance with an embodiment ofthe present invention is shown. As with the purchase order validation system 120 and the invoice validation system 122, the database maintenance validation system 124 can process EDI, XML or non-EDI documents. Maintenance documents that have the proper electronic structure go the database maintenance validation system 124. The maintenance document is forwarded to a maintenance type evaluation point 300 that determines the type of maintenance the document is purporting to accomplish. For example, changing manufacturer information, customer information, buying points, products, promotions, authorizing products, or representative categories will require updating the database. Once the type of maintenance is determined, the document goes to a new record decision gate 302. If a new record is requested, the system checks to see if the record already exists at the existing record gate 304. Records that already exist generate an error and are recorded in the error log 240 and reported to the data entry station 22. If the record does not already exist, the document goes to a validation gate 306 where the information for the new record is validated and checked for invalid relationships. Upon successful validation, the database 126 is updated with a new record containing the updated information from update database point 308. Maintenance document that do not require a new record are forwarded to an edit existing record gate 310 where documents that are intended to be edited are then forwarded to a record found decision gate 312. If no record is found, an error is registered in the error log 240 and reported to the data entry station 22. If the desired record is found, the document is forwarded to an editing validation gate 314 where the information in the maintenance document is validated. Upon successful validation, the database 126 is updated with the edited information from the update database point 308. If the record is not found or if the validation process generates errors, errors are recorded in the error log 240 and reported to the data entry station 22. If the maintenance document is not editing an existing record or adding a new record, the document is forwarded to a delete existing record decision gate 316. Documents that are attempting to delete an existing record are passed to a record finding decision gate 318. When the record finding decision gate 318 finds the requested record, the document is sent to a validation gate 320 where the information in the maintenance document is validated and check against information contained in the database. Upon validation, the database 126 is updated with the maintenance information from the update database process point 308. If the record is not found or if the validation process generates errors, errors are recorded in the error log 240 and reported to the data entry station 22. With reference back to Figure 4, if errors were generated in the database maintenance validation system 124, the document with the errors is forwarded to the XML document point 174 which is forwarded to the data entry station 22 for review and release over the network. Error-free maintenance documents are reported to the data entry station 22 or review point for approval. Upon approval, the database 126 is updated. Outbound Document Processing System Once the structure and content ofthe inbound document has been validated, the document is forwarded the outbound document processing system 127. With reference now to Figure 9, there is shown an outbound document processing system in accordance with an embodiment ofthe present invention. The document passes to an error decision gate 322. If there were errors in the invoice or purchase order validation process, the document is converted to an XML document with the error messages using information from the database 126 and the error log 240 at the generate XML document with error messages point 324. The XML document with the error messages is then forwarded to the sending trading partner. Error free documents are sent to an outbound requirement generator 326 that uses information in the transmission queued default table 142 to determine what form the outbound document should take. The document is then forwarded to an EDI decision gate 328. If the outbound requirement for the manufacturer is for an EDI document, an EDI document is generated at the EDI document transaction point 330. The EDI document transaction point uses information in the database 126 that includes an EDI mapping table and dictionary 160 and other information from the trading partner profile 140. A XML document may also be created for posting to the network at the XML document point 332. The trading partner may require that the document be faxed for processing. In such an event, when the document passes to the fax decision gate 334, a faxed document is generated at the fax document point 336 using the facsimile table 162 and information from the trading partner profile 140 from the database 126 in order to generate the facsimile document. A XML document may also be created for posting to the network at the XML document point 338. The trading partner may require that a XML document be created using trading partner-specific information. In such an event, the document is forwarded to a XML decision gate 340 where the document is forwarded to an XML document point 342. An XML document is created using information in the trading partner profile 140 ofthe database 126 to create the XML document. Referring back to Fig. 4, once the documents have been processed for their outbound specifications, the documents are forwarded to the outbound EDI decision gate 176. From this point, EDI documents are sent to the EDI document point 178 for forwarding to the receiving trading partner, such as a manufacturer, supplier or customer 180 through the VAN 12. All other documents are forwarded to an outbound XML decision gate 182 where XML documents are forwarded to a XML document sending point 184. XML documents are then forwarded in XML format to the receiving trading partner, such as a manufacturer, supplier or customer 180. All other documents are forwarded to the fax sending point 186 where facsimile documents are then sent to the manufacturer or customer 180 by using third-party facsimile software 188. It is to be appreciated that to practice the system and method ofthe invention, it is not necessary that the processor and/or the memory be physically located in the same place. That is, it should be appreciated that each ofthe processor and the memory may be located in geographically distinct locations and connected so as to communicate in any suitable manner, such as over a network, for example. Additionally, it should be appreciated that each ofthe processor and/or the memory may be composed of different physical pieces of equipment. Accordingly, it is not necessary that the processor be one single piece of equipment in one location and that the memory be another single piece of equipment in a another location. That is, it is contemplated that the processor may be two pieces of equipment in two different physical locations. The two distinct pieces of equipment may be connected in any suitable manner. Additionally, the memory may include two or more portions of memory in two or more physical locations. Further, the memory could include or utilize memory stores from the Internet, Intranet, Extranet, LAN or some other source or over some other network, as may be necessary or desired. As described above, the invention may illustratively be embodied in the form of a computer or computer operating system. It is to be appreciated that the software that enables the computer operating system to perform the operations described above may be supplied on any of a wide variety of data holding media. Further it should be appreciated that the implementation and operation ofthe invention may be in the form of computer code written in any suitable programming language, which provide instructions to the computer. It should be appreciated that the software code or programming language that is utilized in a computer system to perform the above described invention may be provided in any of a wide variety of forms. Illustratively, the software may be provided in the form of machine language, assembly code, object code, or source language, as well as in other forms. Further, the software may be in the form of compressed or encrypted data utilizing an encryption algorithm. Additionally, it should be appreciated that the particular medium utilized may take on any of a variety of physical forms. Illustratively, the medium may be in the form of a compact disk, a DVD, an integrated circuit, a hard disk, a floppy diskette, a magnetic tape, a RAM, a ROM, or a remote transmission, as well as any other medium or source of information that may be read by a computer or other operating system. Accordingly, the software ofthe method ofthe invention may be provided in the form of a hard disk or be transmitted in some form using a direct telephone connection, the Internet, an Intranet, or a satellite transmission, for example. Further, the programming language enabling the system and method ofthe invention as described above may be utilized on all ofthe foregoing and any other medium by which software or executable program code may be communicated to and utilized by a computer or other operating system. As described herein, the system and method ofthe invention may utilize an application program, a collection of separate application programs, a module of a program that is designed to handle, or a portion of a module of a program, for example. As noted above, it should be appreciated that the computer language used in the system and method ofthe invention may be any of a wide variety of programming languages. Further, it is not necessary that a single programming language be utilized in conjunction with the operation ofthe system and method ofthe invention. Rather, any number of different programming languages may be utilized as is necessary or desirable. It will be readily understood by those persons skilled in the art that the present invention is susceptible to broad utility and application. Many embodiments and adaptations ofthe present invention other than those herein described, as well as many variations, modifications and equivalent arrangements, will be apparent from or reasonably suggested by the present invention and foregoing description thereof, without departing from the substance or scope of the invention. Accordingly, while the present invention has been described here in detail in relation to its preferred embodiment, it is to be understood that this disclosure is only illustrative and exemplary ofthe present invention and is made merely for the purposes of providing a full and enabling disclosure ofthe invention. The foregoing disclosure is not intended to be construed or to limit the present invention or otherwise to exclude any other such embodiments, adaptations, variations, modifications and equivalent arrangements, the present invention being limited by the claims and the equivalents thereof.

Claims: CLAIMS What is claimed is: 1. A method for processing documents between trading partners comprising: receiving an electronic document from a first trading partner into a document processing system having a database that contains database trading information for the trading partners, wherein the document contains transaction specific information; validating the transaction specific information with the database trading information; creating an outbound document for sending to the second trading partner using the database trading information contained in the database; and sending the outbound document to the second trading partner. 2. The method of claim 1 further comprising determining if the structure ofthe document can be read by the document processing system. 3. The method of claim 1 wherein the electronic document is an EDI document. 4. The method of claim 1 wherein the electronic document is an XML document. 5. The method of claim 1 wherein the electronic document is a non-EDI document. 6. The method of claim 1 wherein the outbound document is selected from the group consisting of an EDI document, an XML document, a non-EDI document, and a facsimile document. 7 The method of claim 1 wherein the electronic document is a purchase order. 8. The method of claim 1 wherein the electronic document is an invoice. 9 The method of claim 1 wherein the electronic document is received from a network of computers. 10. The method of claim 1 wherein the electronic document is received from a value added network. 11. The method of claim 1 further comprising recording each transaction in the database. 12. The method of claim 1 wherein the electronic document contains purchase order information for purchasing at least one product from the second trading partner and the database contains product information for the second trading partner, the step of validating the transaction specific information further comprising comparing the purchase order information for each product with the product information. 13. A system for processing an electronic document between trading partners that contains transaction specific information comprising: a document receiving portion for receiving the electronic document from a first trading partner; a database that comprises, document structure information, database trading information for each trading partner, and outbound document information for each trading partner; a document structure validation portion for comparing the document structure with document structure information contained in the database; a document processing portion configured to compare the transaction specific information in the electronic document with the database trading information for each trading partner; an outbound processing portion that creates an outbound document using the outbound document information for sending to a second trading partner; and a document sending portion adapted to send the outbound document to the second trading partner. 14. The system of claim 13 wherein the database further comprises database portions comprising: a trading partner profile for each trading partner; a product listing portion that contains information for each product for each trading partner; a transmission queue defaults table; a promotional information portion for each product for each trading partner; a buying points portion that contains rules for governing a transaction between the trading partners; and an authorized product portion that contain a listing of authorized products for each trading partner; wherein each ofthe database portions are in electronic communication with the document processing system. 15. The system of claim 13 wherein the document receiving portion further comprises an EDI receiving portion having an EDI input for receiving an EDI document and a network document receiving portion having a network document input for receiving a network document. 16. The system of claim 13 wherein the document sending portion further comprises an EDI sending portion having an EDI output for sending an EDI document and a network document sending portion having a network document output for sending a network document, and a facsimile sending portion having a facsimile sending output for sending facsimile documents. 17. The system of claim 13 wherein the system further comprises a database maintenance portion for updating the database. 18. The system of claim 15 wherein the network document receiving portion is connected to the internet. 19. A method for updating information in a record in a database in a document processing system comprising: receiving a database maintenance electronic document from a trading partner into the document processing system, wherein the document contains database record update information for the trading partner; finding the record for updating; comparing the record update information with the information in the record; and updating the record with the record update information. 20. The method of claim 19 wherein the record update information is adding a new record. 21. The method of claim 19 wherein the record update information is deleting an existing record.

Inventors: SPILLER WARREN H, SPILLER, WARREN, H.
Applicants: GLINK LLC, SPILLER WARREN H, GLINK, LLC, SPILLER, WARREN, H.
Application year: 2000
Main classification: G06F17
IPC codes: G06Q30