Re: Application-level trading partner integration

[Jim Divoky]

The issues you discuss relate to doing business.  How the documents are sent whether via field delimited fixed format, XML format, or paper forms is not relevant.    >>A buyer sends forecast data to suppliers in lieu of purchase orders   This is not correct.  Forecasts are sent to feed the supplier's MRP system.  Fixed forecasts could be used to generate a shipment against a blanket PO but a release order is perhaps more correctly used to initiate a shipment.  A discussion of the use of forecasts requires a knowledge of supply chain management and JIT and MRP and ?.  Most of the articles I have read on the business use of XML have indicated a great shortcoming by the author in most of the related disciplines such as computer science, common business practices, accounting, business law, etc.  Just the use of the term "XML vs. EDI" indicates to me that the author is not knowledgeable of the topic at hand.    XML is a document format.  The only advantage it offers currently over traditional EDI methods is in the fact it can ease visual presentation.  Since EDI shouldn't involve human interaction, this is a limited benefit in B2B environments.  The disadvantage it offers is that there are currently few agreed upon standards of use.  The problems of electronic business communications lies in semantics not format.  Any computer can easily handle any format.  It is the interpretation of the content that is and probably always will be a problem for computers.    If you are attempting to document the advantages/disdavantages of the use of XML vs. ANSI X12 or EDIFACT, then you need to discuss the topic at the IT level.  The business level issues are identical regardless of the data format chosen.   Jim Divoky EC Solutions, Inc. PO Box 667 Kent, OH  44240-0012 Providing EDI/EC Consulting and Contracting Services Mobile  330-606-6826 Pager   877-282-3426   (Toll free) Email   [EMAIL PROTECTED]         To send short message to mobile phone:                 email [EMAIL PROTECTED] ----- Original Message ----- From: jwells123 To: [EMAIL PROTECTED] Sent: Tuesday, August 28, 2001 7: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.