Re: Application-level trading partner integration

[Matthew Montano]

You've touched on why EDI/B2B is not a simple IT exercise.   > many ship-to addresses (up to 2500)...   ERP software 'thinks' one way, EDI documents 'think' another, and your trading partner will 'think' in another. Sound familiar?   Most EDI implementations, at least the ones that I've come across, aren't as simple as an ERP system coupled with a mapping tool and a message transport tool. In your SDQ examples, solutions include 'double mapping/splitting', 'user exits' in the ERP package, or pieces of "glue code."   Most EDI job postings including UNIX shell scripting as a 'nice to have' for a very good reason. ;-)   > buyer sends data in an inappropriate document   Isn't this the truth? Half of the problem is that it could be easier to 'cram' data into an inappropriate document and export the problem to their trading partner. The other half of the problem is the reality that every business does business differently, and it gets mapped into EDI documents differently as well.   Put all of these together and it becomes obvious why I've always used a rule of thumb of a minimum of 4 man-weeks per transaction per application/trading party pair. Throwing XML formats, Internet based transports, partner management tools doesn't decrease the 4 weeks. If anything they make it worse.   (Want some more? How about variations in the interpretation of English? Does "Requested Delivery Date" mean the date to goods are supposed to leave the warehouse, or arrive at the customer site? What does "price" mean, before discount, after rebate or visa-versa, or neither.)   Matthew         -----Original Message----- From: Electronic Data Interchange Issues [mailto:[EMAIL PROTECTED]]On Behalf Of jwells123 Sent: August 28, 2001 5:34 PM To: [EMAIL PROTECTED] 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.