EDI does not involve any advanced technology, but it is heavily burdened
with bureaucracy and overhead. Ultimately, an EDI transaction is just
delimited text. There are essentially field delimiters and record
delimiters, and everything is specified in great detail by standards
documents. The same can be said about XML.
The difference is that EDI standards (ANSI X.12 in the case of U.S. trading
partners) for a single transaction set generally run thousands of pages long
and still have to be supplemented by detailed "implementation guides"
composed by the trading partner in charge. EDI data doesn't look very
meaningful without tedious interpretation.
A traditional EDI transaction may involve fragile conversions between EBCDIC
(the character encoding method used by some IBM mainframe and midrange
hosts) and ASCII, and/or transport through antiquated VANs which may
introduce unexpected mangling of the data.
If you are a small organization and/or without significant resources to
implement your own EDI systems, I suggest you either purchase EDI
mapping/translation software, or use an EDI outsourcing service.
Some examples of low-end, Windows-based EDI software include:
- EDIeasy and spEDI*tran/map from http://www.stpaulsoftware.com/sol/ecpc.asp
- Mercator Desktop and Trading Partner PC/32 from http://www.tsisoft.com/
Be prepared for "low-end" to mean quite a bit more money in the EDI world
than in the rest of the software industry. The big player in EDI software is
Sterling, but you'll spend heavily to go with the leader.
Depending on what product you choose, it will either interface directly with
your database using ODBC, or it will transform the EDI data to/from a
"normal" ASCII text file that Office can deal with. If you use an
outsourcing service, you'll generally send/receive such an ASCII text file
to/from your service, and they will take care of dealing with the EDI
transaction format and any proprietary communication schemes.
If you still want to see an example of an 810 transaction, there's a sample
file for PageNet's implementation of Version 4010 at
To interpret it, in addition to the X.12 specification for 810, you'll need
to see PageNet's implementation guide at
Remember that you'll need to find out the specific version of 810 that your
trading partner wants to use, and you'll need an implementation guide from
them. (They may call it a "profile.") If you decide to write VBA code and do
the data handling aspect of EDI yourself in Access, remember that you'll
somehow need to deal with the communications aspects of EDI also.
Joe Fallon <jfal...@nospamtwcny.rr.com> wrote in message
check out our web site www.1edisource.com for a
description of how integration EDI products work.
Sent via Deja.com http://www.deja.com/
Before you buy.