[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Definition of EDI Transaction
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"
Powered by eList eXpress LLC