Jim,
Very well said! What do you suppose it will take to get this message across
to those that need to hear and understand it. But, then, it doesn't sell
magazines, does it!
Rachel Foerster
Principal
Rachel Foerster & Associates, Ltd.
Professionals in EDI & Electronic Commerce
39432 North Avenue
Beach Park, IL 60099
Phone: 847-872-8070
Fax: 847-872-6860
http://www.rfa-edi.com <http://www.rfa-edi.com>
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. =20
>>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. =20
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. =20
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:=20
email [EMAIL PROTECTED]
----- Original Message -----=20
From: jwells123=20
To: [EMAIL PROTECTED]=20
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.
------=_NextPart_000_000E_01C1313E.601978E0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4616.200" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>The issues you discuss relate to doing =
business. How the=20
documents are sent whether via field delimited fixed format, =
XML=20
format, or paper forms is not relevant. </FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>>><FONT face=3DArial>A buyer sends forecast =
data to=20
suppliers in lieu of purchase orders</FONT></FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2><FONT face=3DArial><FONT face=3D"Courier New">This =
is not=20
correct.</FONT> </FONT><FONT face=3D"Courier New">Forecasts are =
sent to feed=20
the supplier's MRP system. Fixed forecasts could be used to =
generate a=20
shipment against a blanket PO but a release order is perhaps more =
correctly used=20
to initiate a shipment. A discussion of the use of forecasts =
requires a=20
knowledge of supply chain management and JIT and MRP and ?. Most =
of the=20
articles I have read on the business use of XML have indicated a great=20
shortcoming by the author in most of the related disciplines =
such as=20
computer science, common business practices, accounting, business law,=20
etc. Just the use of the term "XML vs. EDI" indicates to me =
that the=20
author is not knowledgeable of the topic at hand. =
</FONT></FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>XML is a document format. The only advantage =
it offers=20
currently over traditional EDI methods is in the fact it can ease visual =
presentation. Since EDI shouldn't involve human interaction, this =
is a=20
limited benefit in B2B environments. The disadvantage it =
offers is=20
that there are currently few agreed upon standards of use. The =
problems of=20
electronic business communications lies in semantics not =
format. Any=20
computer can easily handle any format. It is the interpretation=20
of the content that is and probably always will be a problem for=20
computers. </FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>If you are attempting to document the =
advantages/disdavantages=20
of the use of XML vs. ANSI X12 or EDIFACT, then you need to discuss the =
topic at=20
the IT level. The business level issues are identical regardless =
of the=20
data format chosen.</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D3>Jim Divoky<BR>EC Solutions, Inc.<BR>PO Box =
667<BR>Kent,=20
OH 44240-0012<BR>Providing EDI/EC Consulting and Contracting=20
Services<BR>Mobile 330-606-6826<BR>Pager =20
877-282-3426 (Toll free)<BR>Email </FONT><A=20
href=3D"mailto:[EMAIL PROTECTED]";>[EMAIL PROTECTED]</A><BR> =
=20
To send short message to mobile phone:=20
<BR> &nb=
sp; =20
email <A =
href=3D"mailto:[EMAIL PROTECTED]";>[EMAIL PROTECTED]</A></DIV>=
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV=20
style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
<A [EMAIL PROTECTED]=20
href=3D"mailto:[EMAIL PROTECTED]";>jwells123</A> </DIV>
<DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
[EMAIL PROTECTED]=20
href=3D"mailto:[EMAIL PROTECTED]";>[EMAIL PROTECTED]</A> =
</DIV>
<DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, August 28, 2001 =
7:34=20
PM</DIV>
<DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Application-level =
trading=20
partner integration</DIV>
<DIV><BR></DIV>
<DIV><FONT face=3DArial size=3D2>I often read that one of the =
challenges of EDI is=20
having to make changes to your internal applications for each new =
trading=20
partner integration. As I don't work with EDI, I've been trying to dig =
up some=20
examples of this.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>1. Large buyers often send EDI POs =
with many=20
ship-to addresses (up to 2500). Their suppliers have to modify their=20
applications to split these POs into multiple orders.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>(General case: The =
sender crams extra=20
information into one EDI document to reduce information =
repetition=20
as much as possible, until there are effectively multiple documents =
crammed=20
into one. The receiver has to modify their application to split the =
document=20
back apart in order to process it properly. Presumably the VAN =
costs=20
savings are greater than the costs of modifying the application, or =
else this=20
is just an example of the larger trading partner dumping their costs =
on the=20
smaller?)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>2. </FONT><FONT face=3DArial =
size=3D2>One=20
trading partner wants to exchange information that currently =
isn't=20
handled by the other's application. For example, a buyer =
could send=20
information in the PO that the seller is required to=20
repeat in the advance ship notice (ASN), such as PO number, line =
numbers,=20
dock door number, etc, but the seller's application might not be =
equipped to=20
handle this information.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>3. A buyer sends forecast data to =
suppliers in=20
lieu of purchase orders, but the forecast data must be processed =
as a=20
PO.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>(This one strikes me as odd...why not =
just send a=20
PO?)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Does anyone know of other =
cases?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>In my ongoing EDI vs. XML comparison, =
I notice=20
that XML can't really help with any of these...one more way to =
counter=20
the misconception that XML is going to solve the problem of=20
application-level integration with each trading partner.</FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2></FONT> </DIV></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_000E_01C1313E.601978E0--
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
