🚀 go-pugleaf

In article <phrE5w244.5vy@netcom.com>, Paul Rubin <phr@netcom.com> wrote:
>Generally EDI transactions are between a big company (say General Motors)
>and a small company (say Foobar Ball Bearings Inc, which supplies parts to
>GM) where the use of EDI is dictated by the big company and the small
>company goes along with it to get the business.  And it's the big company
>that gets to choose which standards will be used, which VANs will be used,
>etc. so of those 20,000 businesses using EDI, only a few (the big ones) are
>making these decisions, and they tend to stick with what they're already
>doing and they're big enough to not care about the cost of a set of X12
>books or whatever.

Sigh.  Yes mob-boss rule is exactly the problem, and one which is difficult
to solve.  All I can say is that to change the process it will help if there
is a developed alternative.  It is possible that one industry will start
using Free-EDI... if it does then others wishing to join that industry get
to use our standard instead...  Another possibility is that if Free-EDI
becomes popular, the EDI VANs might become gateways between Free-EDI and
legacy EDI.  It would be nice to be able to send Free-EDI email to
free-edi@sterling.com and have them forward it to GM or whoever.  GM can
continue to pay the VAN, but new vendors maybe wouldn't have to.

Also there is the possibility that smaller industries (which can't affoard
EDI) could use Free-EDI.  If that happens then the larger companies will be
forced to change if they ever want to get in on the smaller industries.

It may also be in the larger company's interest to accept Free-EDI.  They
try to muscle their trading partner's into using EDI, but they don't always
succeed.  If they want their trading partner's to communicate with them
electronically, then they should make it easy for them to do so.

>If you want to have a chance in h*ll of succeeding with real EDI
>users, you have to use the same formats as current standards in
>order to work with the existing popular software packages.

I don't think I want to use any of the existing EDI formats (although I
would love to hear more contrary arguments- I'm certainly no EDI expert). 
Although it would certainly be nice to be able to translate into them.

From what I gather, each EDI standard requires almost a parser (even though
the EDI standards themselves are not formalized context-free grammars, BNFs
or regular expressions), and a generic EDI translator essentially is a
parser generator- one of the most complex pieces of software one can write.

The approach I'm thinking of is to make Free-EDI transactions look like
databases.  The software to read a transaction into a relational database
system should be trivial (and you only need one trivial parser).  Once the
data is in the database, one can use the database system to map vender's
codes and customer's codes, merge the data with the custmer's database or
whatever.

I'm thinking of providing a bunch of utilities for doing as much generic
data conversion as I can think of.  One neat one would be something to read
an accounting system's line-printer output (assuming it can be captured in a
file, as it always can be for UNIX systems) and convert it into a Free-EDI
transaction (you'd supply a set-up file giving field positions and form
lengths and so on).  So the company prints invoices using its old accounting
software to a file, and presto they're Free-EDI capable.  Another peice of
software would receive a Free-EDI transaction and pretty print it.  It
should be easy to write JAVA applets to compose an EDI transaction, and
netscape plug-ins can certainly send e-mail...

Free-EDI transactions should also be UNIX friendly.  You should be able to
use UNIX's database commands: sort, uniq, awk, join, etc. and be able to
build simple shell-scripts to process Free-EDI data.

Free-EDI transactions should also be Visual-Basic, MS-Access and MS-mail
friendly. 

I don't know much about it, but it would certainly be nice if Free-EDI
transaction could be AS/400 friendly as well.

The Free-EDI web site should be a depository for all of these utilities.
-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}