Re: Definition of EDI Transaction

["William J. Kammerer" <wkammerer@foresightcorp.com>]

Dick Brooks suggested a definition of an EDI transaction from DISA's
"Introduction to EDI," which was included last Tuesday in the ebXML TR&P
Overview  & Requirements document (v 0-92):

"The information included in a transaction set is, for the most part,
the same as the information in a conventionally printed document. A
transaction set is the data that is exchanged in order to convey meaning
between parties engaged in EDI."

I really don't like that definition, though it has undoubtedly been
influential on how people think of EDI and how they use it.
"Conventionally printed" documents, or forms, are intended for humans.
They have sections like subtotals, which are really unnecessary in an
electronic message as the recipient presumably has a computer to perform
totaling to any degree he desires.

Forms are also often broken out into schedules (as in a financial
statement), which segregate parts of the same business operation, or
"thing," onto different pieces of paper. For example, consider a loan.
Separate paper schedules or forms would contain (1) the payments made
this period, (2) loans extended this period, and (3) outstanding loans,
regardless that the same loan (or lender) might appear on all three
schedules: (2) I took the loan out this quarter, (1) I made two payments
this quarter, and (3) the loan is still outstanding at the end of the
quarter.

Forms and schedules are a logical way for a human to organize their
reporting so they don't become overwhelmed (or so they're forced to
become organized).

But it makes little sense to design an EDI transaction along these
lines.  In actuality (and virtually, in reasonable EDI), there's only
one loan, but four sub-ordinate pieces of accounting information: one
loan original amount incl. date and interest rate, two repayments
(broken out in principal and interest?), and one outstanding summary
(how much I have left to pay as of the end of the quarter).

An EDI transaction set often runs into trouble when mimicking the paper

forms it may be replacing. The mimicking of paper forms in EDI by hubs
(or "800-lb. gorillas") - *THEIR* paper forms, which may be arranged
differently from another company's paper forms - might account for a not
insignificant fraction of the different manifestations (or EDI
guidelines) of the same "standard" message.  Other reasons might include
other attributes of "forms" - lots of free text, which when mimicked in
EDI results in non-machine processable text segments, or free-text
within elements, where standard (e.g., X12, EDIFACT, ISO, or
industry-defined) codes would be far more suitable for machine
processing.

Might we be better off word-smithing our own definition of an EDI
transaction, maybe something along the lines of: An EDI transaction, or
message, is a machine-readable arrangement of data segments (or records)
conforming to a national or international standard which is exchanged
between business or trading partners, representing one or more discrete
processes (such as a Purchase Order or a Material Release), a status or
snapshot (such as a Price/Sales Catalog or Inventory Report), or a
report (e.g., a Student Transcript).

Or something like that...

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"