🚀 go-pugleaf

In article <E5yGE3.EG6@world.std.com>,
Joseph H Allen <jhallen@world.std.com> wrote:
>>The smaller companies who trade with them just consider EDI to be a
>>nuisance and wouldn't bother with it even it were free, if their
>>larger partners didn't insist on it.
>
>Ah, but it should be benificial to small companies.  I've been rethinking
>this a bit.  EDI is costly and unfriendly: the big company tells the small
>company that it should send its invoices via EDI in x12 standard no. 950 (or
>whatever).  This has no meaning and only attains meaning after the small
>company invests lots of money in software and services.  Even once the small
>company is prepared to understand x12 950, it still has to communicate with
>the large company for the purpose of pinning down exact details (the
>interpretation and necessity of various fields, common item codes, etc.).

Exactly, and this (generally one-way) communication creates a lot of
work for the smaller company even after an EDI package is installed.
The big company supplies docs to the small company of what it wants
all the fields to mean, and the small company has to deal with it.
This is for the benefit of the big company, that has to deal with
100's of small companies and doesn't want to make arrangements with
all of them separately.  For a small company to small company partnership,
the solution to this problem is to NOT USE EDI.  If you're trying to
totally re-invent EDI to lower the amount of communication needed
(i.e. redefine the documents to pin everything precisely), good luck.
EDIFACT used that approach, made only a very small dent in the problem,
and the result is huge bureaucratic documents like the one you posted
(the X12 book is a lot simpler).

>Today PGP signatures for authentication and encryption for secrecy allow
>E-mail to replace the post office for this last step- so companies can now
>communicate electronically in the same way that they do with paper.

This has nothing to do with the EDI docs themselves.

>Now you still want the data to be machine readable, but you don't want to
>require small companies to become EDI experts- its too difficult and costly. 
>They want make ball bearings and don't want to concern themselves with
>obscure computer standards.
>
>So instead of a common set of standards, the big company needs to just tell
>the small company what it wants in a way that it can comprehend.

This is exactly what happens.  The big company tells the small company
how it wants the EDI segments and elements used for what purposes.

>An EDI "standard" should then meet these goals:
>
> - EDI data should be directly human readable.  The small company could
>   learn how the data is to be formatted just be looking at an example.  A
>   human should be able to process the data (perhaps the small company only
>   receives a few purchase orders- this goal is always a good idea anyway,
>   you still want to be able to conduct business if your machine is down).

This isn't realistic.  EDI docs are more human-readable than, say,
Microsoft Word files, but nobody really worries about Word files
being unreadable without a computer.

> - It should be possible to compose an EDI message either by hand or with
>   the absolute minimum in required software.

Again not realistic, if you look at the amount of detail that the usage
of every segment is spelled out in, as part of a trading partner agreement.

> - Any standards should be freely copyable.  The big company should be able
>   to just send the small company a copy of the standard (akin to sending it
>   a form).

Yes this would be nice; did you say EDIFACT was freely copyable?
If it is, why not just use it?

> - It should be trivial for the trading partners to make changes to the
>   standards.

Already trivial.

> - EDI data should also of course be machine readable so that the
>   goal of automated processing can be met.  The standard itself
>   should also be machine readable.

Well the X12 books I saw were on paper, but we had people type the
info in so the translators could use the descriptions.

>An EDI standard should probably look like a form:...

Might be fairly reasonable in theory, but existing standards work for what
they are designed for.

>>If you don't mind my asking, why are you interested in EDI if you
>>haven't been using it?  I'm not trying to give you a hard time;
>>I'm just wondering.
>
>I consult for a company which needs to become EDI capable (and I'm the one
>who has to do it).  This effort is result of: Discovering that all books an
>EDI are crap of the form "you must reengineer your business to conform to
>the new EDI paradigm...".  Discovering that "translator software" costs
>$4000.  Discovering that to get a copy of x12 costs $3000.  Discovering that
>the software is just not going to integrate well with the accouning system
>(unless we upgrade it: $10,000 - $20,000 plus everyone has to learn
>something new).
>
>Of course they're still going to do it (they want the big customer).

Yes, and if a set of new and incompatible EDI standards appears overnight,
you'll find the big customer isn't going to be interested in it.

BTW, I think you can get some translation packages for under $4k now,
and you shouldn't need a copy of X12 to use a package.  The package
should come with its own set of document descriptions, and you just
pick the fields you want to use etc.