Kurt J. Braman, of Highsmith Inc., has a guideline in place for an
outbound EDI document, and his trading partner, in turn, has her own
different guideline for the equivalent inbound EDI document. Kurt wants
to know which guideline should be used: his or hers?
The answers have just about been unanimous - the dominant partner,
almost invariably the customer, gets to impose his "version" of the EDI
document on the supplier. Apparently suppliers - no matter the quality
or service they provide - hold no sway with the customer; they'd be
dumped in a heartbeat if they had the temerity to suggest another way to
share data. This is a classic study in anthropology, showing pecking
order in action: the "alpha male" (the customer hub or "800-lb.
Gorilla") peeing to mark his territory; the lesser males and the females
(the vendors) arranged in a hierarchy, picking bugs and sh*t from the
alpha male's fur, each demanding their due from subordinates.
Paul Lemme, of AppNet, musing on the old days, wrote that "some of us
thought that each sender would send all of the information they had to
send, and receivers would simply pick out what they needed. Since the
sender couldn't send any more, and generally receivers were already
doing business with these senders in a manual world utilizing this
information, this approach would stop the need for 'partner by partner'
relationships."
Boy, was Paul ever wrong: "Obviously this didn't happen, and EDI became
somewhat complicated." Further, Paul finds it "interesting that many
seem to think XML will be easier for some reason. But if 'partner by
partner' relationships still prevail, it is difficult to see how XML
will become easier."
It's obvious that Mr. Lemme would rather be a righteous man telling the
truth than to be an internet e-commerce billionaire. Get with the
program, Paul: XML is extensible, lets you add junk on the fly, is easy
for the SME to parse and doesn't require those expensive VANs. But I'm
pretty sure that Mark Kusiak's fake orgasm over XML is not in the same
league as Meg Ryan's.
I'm torn in this matter - over guidelines, that is. On the one hand,
the thought of all those unique EDI guidelines out there means there's
still plenty of opportunity to sell EDISIM, the World's leading EDI
productivity tool, for editing, printing and testing guidelines. Then
on the other hand, if every trading partner relationship requires a
unique map, what was the point of EDI in the first place? Alan Chute,
of File Express, Inc., addresses this in "The Mythical Value of EDI
Standards", at http://www.filex.com/filex/edimyth.htm (October 10,
1996). Mike Rawlins, one of the luminaries on EDI-L, also examines this
problem in "Implementation Conventions, or Why EDI Is Such a Pain," at
http://www.metronet.com/~rawlins/x12imp.html.
And even if it were possible to devise a guideline which was an
"intersection" of all trading partner requirements, where some of the
TPs could ignore what they don't need, there's a roadblock here too:
the U.S. Government wants to be able to reject any transaction set with
extra unused information not specified in their guidelines. A new 997
is being voted on at this very moment to provide for rejection of data
that doesn't conform *EXACTLY* to the recipient's guideline.
Nonetheless, I have invited Kurt Braman to share with us on EDI-L his
guidelines and some background on his trading partner, suitably
anonymized if that suits him, so we can conduct a pedagogical exercise
to come up with a compromise guideline to be used by both parties. Or
we can even have a vote on which guideline should be used, after making
fun of individual pieces-parts. At least Kurt would have more complete
information to use in his decision and dealings with his trading
partner, as Mark Kusiak suggests.
William J. Kammerer
FORESIGHT Corp.
4950 Blazer Memorial Pkwy.
Dublin, OH USA 43017-3305
(614) 791-1600
Visit FORESIGHT Corp. at http://www.foresightcorp.com/
"Commerce for a New World"
=======================================================================
To signoff the EDI-L list, mailto:[EMAIL PROTECTED]
To subscribe, mailto:[EMAIL PROTECTED]
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
