Re: Application-level trading partner integration

[Mark Kusiak]

Oh Dave,   We deal with retailers very little and are not able to accomplish this in either the translator or the back end application.  My application requires a unique PO number and will bounce any duplicated number as illegal.  There are definite methods to work around this, but if I could not handle it the way I currently do it for my retailers, then I have a hugh inability to do business with Dave.  My management is not going to be very happy at all if I come to them and say that I can’t support this business flow.   Now we have a good example of the differences for two different organizations and what they feel are perfectly acceptable solutions.   If Dave and I began working toward becoming trading partners, what organization would be required to modify or build the capability to handle the proposed business flow?  I would have to write the capability to accomplish this in my already extensive collection of interface programs, or negotiate with Dave to send each individual stores orders in a separate PO……   Now, can someone please tell me why this would take time and cost money?????   Dave,  I felt that this was a good representation of the issues that EDI professionals face each day.  The answers to the business related questions here are going to have a definite impact on what approach I take as an IT professional to solve the issue and ultimately move this data into the application.   Regards,   Mark     -----Original Message----- From: Dave Taylor [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 29, 2001 8:32 PM To: [EMAIL PROTECTED] Subject: Re: Application-level trading partner integration   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.