Re: Application-level trading partner integration

[Dave Taylor]

Indeed!   Just one more example of the fact that nothing changes if you replace the X12 document architecture with the XML document architechture at the integration level, with some exceptions.   The single PO "with many ship-to addresses" probably refers to Store Numbers and Quantites in SDQ lines in a retail PO.  Any good translator will separate these out into individual POs for each store before converting them into Sales Orders in the backend software.  It is true, however, that the translator or the backend software must have names and addresses for each of these stores so that each store can be invoiced individually, even if the products for multiple stores are shipped to a single distribution center.   Any good translator will also provide for the input of the information required for the ASN, such as Carton Contents and Bill-of-Lading information.   Yes, the backend software or the translator must be able to process the information required by the Trading Partner if you want to continue to do business with that Trading Partner, but what backend software does not accept the Customer's P.O. Number as part of each Order?   Rgds,   Dave Taylor President Sysmark Information Systems, Inc. EC/EDI Software Specialists 800-SYSMARK (800-797-6275) ----- Original Message ----- From: jwells123 To: [EMAIL PROTECTED] Sent: Tuesday, August 28, 2001 5:34 PM Subject: Application-level trading partner integration I often read that one of the challenges of EDI is having to make changes to your internal applications for each new trading partner integration. As I don't work with EDI, I've been trying to dig up some examples of this.   1. Large buyers often send EDI POs with many ship-to addresses (up to 2500). Their suppliers have to modify their applications to split these POs into multiple orders. (General case: The sender crams extra information into one EDI document to reduce information repetition as much as possible, until there are effectively multiple documents crammed into one. The receiver has to modify their application to split the document back apart in order to process it properly. Presumably the VAN costs savings are greater than the costs of modifying the application, or else this is just an example of the larger trading partner dumping their costs on the smaller?)   2. One trading partner wants to exchange information that currently isn't handled by the other's application. For example, a buyer could send information in the PO that the seller is required to repeat in the advance ship notice (ASN), such as PO number, line numbers, dock door number, etc, but the seller's application might not be equipped to handle this information.   3. A buyer sends forecast data to suppliers in lieu of purchase orders, but the forecast data must be processed as a PO. (This one strikes me as odd...why not just send a PO?)   Does anyone know of other cases?   In my ongoing EDI vs. XML comparison, I notice that XML can't really help with any of these...one more way to counter the misconception that XML is going to solve the problem of application-level integration with each trading partner.