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.
 

Reply via email to