🚀 go-pugleaf

Ok, I'll have to put in my $0.02 worth.

I work for an EDI company. (See our stuff at http://www.edisoftware.com
and http://ecweb.com/catalog). I wrote our X12 translator and mapper.
The mapper looks like a cross between awk and perl. Yes, I'm an old
Unix bigot. We're implementing an EDI "mini-VAN" using ftp and PGP
for low-cost transport. I've even tricked up the incoming mapper to
take an 850 purchase order and output a SYLK spreadsheet. Where you
get the $4,000+ figure for software, I don't know. Our windows package
starts at $1495, and we include all the interface file layouts if you
want to write your own interface to your accounting package. 

I'm afraid I must agree with the general thread here that EDI documents
are rater complicated. One mentioned the ASN, affectionately known as
"the document from hell". Also the convoluted SDQ segments in an 850
purchase order turn most order-entry applications on their head. I've
been a part of a little of the ANSI ASC X12 committees, and the
process is long and involved. People are used to a robust standard
that can accomplish anything they want. I'm afraid a new, simplistic
"free-EDI" standard approach would be viewed as sort of an IBM-PC jr
of the standards world. Simple text files that are human-readable
is a nice idea, but the classic EDI document is designed to be
a transport from one application (i.e. purchasing) to another
application (i.e. order entry) at another company. EDI was never
designed to be human-readable any more than TCP packets are human-
readable. They're supposed to make sense to the program on the 
other end. That's all. If you want to make both highly structured
and human-readable, you'd have to think along the lines of SGML
for the machine-readable structure, and supply a "browser" for
the humans to interact with.

I'm afraid I'm rambling, but it's late on a Friday evening.

Have fun,

Brent Laminack (brent@ecweb.com)