The promise of the "paperless office" is still a long way off. As the cost of imaging goes down, we will be able to reduce our inter-office dependence on paper considerably. But what about all of the business documents we generate destined for other companies - things like invoices, purchase orders and shipping manifests? The solution is Electronic Data Interchange (EDI). Put simply, Electronic Data Interchange (EDI) is a standardized way to represent common business documents in data files. These documents can then be exchanged between many types of businesses, computers, and locations.

On the surface, EDI looks a lot like E-MAIL. It can use a "value added network," which is a third party service providing store and forward capabilities and error-checking of EDI documents. However, EDI has advantages over conventional unformatted E-MAIL and proprietary "hard-wired" communications between companies. In EDI, business documents are defined by grouping standardized and numbered data elements or "fields", into code-named segments or "records". These segments are grouped together logically to form transaction sets that represent the various business documents.

The standards adopted depend on the type of business you are in, but among the most widely used is the American National Standard Institute's Accredited Standards Committee X12 D (ANSI ASC X12). These standards are available under several version numbers, and are extensive enough to handle all but the most unusual business documents.

Why EDI?

By integrating EDI documents into existing application systems, the need for mailing, performing data entry, and manual error correction from hard copies can be all but eliminated. By decreasing the time it takes to transfer information, companies can plan production more efficiently, carry lower inventory "safety stock" levels, and monitor cash flow more closely.

Our Experience

About a year ago, our company - a manufacturer of industrial, upholstery, and apparel fabrics - was presented with the task of informing our largest customer of daily shipment details via EDI. This was no small undertaking, considering that our DP department consists of an operator and a "technical manager" - me. Our company has what I consider to be a small-to-medium-sized user base (17 terminals, four of which are PCs attached via IBM emulation cards), and a System/36 model D24 with no communications.

I was dimly aware of EDI concepts from reading a few small articles in the trade magazines. "Paperless office" and "emerging trend" were the terms used most often, but that was all I knew. Therefore, the EDI project had a good measure of F.U.D. (Fear, Uncertainty and Doubt) potential for me - a mere seven-year RPG programmer/analyst with a smattering of PC experience.

However, this was our largest customer. If I ignored the project, I could have put undue strain on a long-standing relationship. If I acted quickly, my company could achieve the benefits of:

o Being the first supplier in our class to implement EDI with this customer, showing our commitment to customer service.

o Possibly receiving EDI production schedules from our customer, to be used to aid our own production planning.

o Gaining valuable experience in EDI so we could expand the program to other documents or to more customers if the need arose.

Upper management gave the go-ahead, and I began to research the project immediately. But where to start? I will now relate how I began this journey, treading on unfamiliar ground. I realize no one method will suit everyone in every situation, but I believe these are good guidelines.

Start With the Customer

I contacted our customer and was referred to the project leader for EDI. This phone call was the most valuable contact I made during the entire project. The project leader's company has a strong commitment to EDI, and an extensive, experienced staff. (Companies with large EDI systems in place are now being called hubs.) He outlined the way the system would work, what documentation I would need, and mentioned several vendors for "translator software" (more on that later). He also told me how to contact the value added network used by his company. Without this kind of support, I doubt the project would have succeeded.

My point to newcomers is this: establish a good working relationship with a person who has experience in this field! If you don't, you may find yourself awash in unfamiliar terms, or frustrated by a lack of information. At worst, you may look for a way to shelve the entire project out of F.U.D.

Determine the Costs

Management instructed me to keep the cost of the project as low as possible, so I made the following decisions:

o Communicate thru the PC.

Our company has only one location, and is not likely to expand beyond one location for the next several years, so communications for the S/36 were not necessary for day-to-day operations. Since the volume of EDI documents per customer would be small (one to six shipments per day), the relatively high cost of S/36 communication was prohibitive. Fortunately I had experience with PC Support/36 and async communications from the PC.

o Perform necessary programming in-house.

Hiring a consultant would have been cost- and time-prohibitive because our customer service system was written in-house. I was confident that I could handle the programming in the time it took for someone who was unfamiliar with our code to flow-chart the system. Note: if you have a packaged application system that must interface with EDI, doing the programming yourself may not be an option.

o Select a network.

We chose to use the same value added network (General Electric Information Services) as our customer was using, for reasons of reputation, familiarity and competitive cost: approximately $100.00 per month.

o Purchase "Translator" software.

This was the tricky part. I was a little confused about the purpose of an EDI "Translator" package. Then I received the ANSI X12 EDI standards manuals and began to decipher the structure of an EDI document. It reminded of the time I first saw an RPG II program after spending a year writing COBOL programs in college. About all that I managed to learn from my first encounter with the manuals was the EDI document number and name - SET 856 "Ship Notice/Manifest."

So I assumed a translator had something to do with taking my shipping data and converting it to EDI. Beyond that, I had no idea. Based on word-of-mouth and advertisements in several trade publications, I decided to purchase a PC-based package at a cost of $2000. This was a hard decision to make, because I had never before purchased software without having a clear-cut idea of its purpose. Time constraints prevented me from evaluating any software on a trial basis.

Dig In

Upon receiving the software and scanning the documentation, it became apparent that an EDI translator performs no "magic" conversion of data. It is not a substitute for actually understanding the structure of an EDI document. This is a mixed blessing.

The way I finally understood the purpose of the translator was to think of it as a kind of "compiler." You are given a "flat file" layout for the transaction set you wish to generate. This is the file that the S/36-based shipping application would have to create and add records to throughout the day. The way records are formatted and grouped in this file is essentially the same as the way they will appear in the finished EDI document.

1 shows part of an EDI advance shipment notice, and a line-by-line explanation of the content and structure. (Note that line numbers are NOT part of the file, and that EDI envelope segments are not included because the translator package handles this function.)

Figure 1 shows part of an EDI advance shipment notice, and a line-by-line explanation of the content and structure. (Note that line numbers are NOT part of the file, and that EDI envelope segments are not included because the translator package handles this function.)

More than one contiguous * indicates data elements that can be, but are not used in the segment.

Valid qualifer codes and data elements are defined in the standards manuals.

EDI File Explanation

1. The "Interchange Start" segment, indicating that this is set number 856, and the sequence number is 506.

2. The "Beginning" segment with qualifier code 00, meaning original; 00019549 is the bill of lading number; 900720 is the date created; 1540 is the time in military format.

3. A "Date and Time" segment with qualifier code 11, meaning shipped on this date and time.

4. A "Hierarchial Level" segment with 01 as the number to identify this group of related data elements. S is the qualifier code indicating SHIPMENT information follows, and 1 indicates that there will be subordinate (child) HL segments.

5. A "Type of Measurement" segment with PD qualifier code, meaning physical dimension; G qualifier code, meaning gross weight; 1292 for number of pounds, and the LB unit-of-measure qualifier code.

6. A "Carrier Detail-Routing" segment with B routing sequence code, meaning original carrier; 2 as an ID code qualifier, meaning that the ID code in the next data element is a standard carrier alpha code (SCAC); ANYT is the actual SCAC; the carrier name is the next element.

7. A "Reference Number" segment with CN qualifer, indicating that the next data element will be the carrier's PRO number; 20.533572 is the PRO number.

8. A "Name" segment with SF qualifier, indicating that this is a ship from segment; 91 qualifier, meaning assigned by seller; then our plant number 01.

9. A "Name" segment with ST qualifier indicating that this is a ship to segment; 92 qualifier meaning assigned by buyer; then the customer's plant number 9987.

10. A "Name" segment with VN qualifier indicating vendor; 08 qualifier indicating our UPC number; then our UPC number 999999.

11. A "Hierarchial Level" segment with 02 as number to identify this group of related data elements. O is the qualifier code indicating ORDER information follows, and 1 indicates that there will be subordinate (child) HL segments.

12. A "Purchase Order Reference" segment indicating that 9999-999 is the purchase order number and 0099 is the release number. 900319 is the purchase order date.

13. A duplicate of line number 6, except with the CC qualifier code, meaning that this shipment completes a release number.

14. A "Reference Number" segment with VN qualifier, meaning vendor order number; then our order number.

15. A "Hierarchial Level" segment with 03 as number to identify this group of related data elements. I is the qualifier code, indicating ITEM information follows, and 1 indicates that there will be subordinate (child) HL segments.

16. An "Item Identification Detail" segment with VN qualifier indicating vendor's item number; then our item number; then the IN qualifer indicating buyer's item number; then the buyer's item number.

17. A "Reference number" segment with IV qualifier, meaning vendor invoice number; then our invoice number.

18. A "Hierarchial Level" segment with 04 as number to identify this group of related data elements. Q is the qualifier code indicating SUB-PACK information follows, and O indicates that there will be NO subordinate (child) HL segments.

19. An "Item Identification Detail" segment with RO qualifier indicating roll number; then our inventory roll number.

20. A "Type of Measurement" segment with PD qualifier code, meaning physical dimension; LN qualifier code, meaning length; 587 for number of yards; and the YD unit-of-measure qualifier code.

21. A "Type of Measurement" segment with PD qualifier code, meaning physical dimension; CW qualifier code, meaning cuttable width; 587 for number of inches; and the IN unit-of-measure qualifier.

22. A "Type of Measurement" segment with PD qualifier code, meaning physical dimension; G qualifier code, meaning gross weight; 362 for number of pounds; and the LB unit of measure qualifier code.

Twenty-three thru 33 are segment groups for the remaining two rolls in the shipment.

34. A "Transaction totals" segment with the number of line items; and hash total of roll numbers.

35. A "Transaction set trailer" segment indicating the number of segments and the set sequence number.

The translator's main function is to check the file for adherence to the selected standards, record group relational errors, and code errors. The translation also inserts the required envelope control records and end-of-line characters. If any "terminal" errors are detected, the EDI documents will not be generated and error messages are printed.

The translator can invoke its own communications program, or an external program with which you are already familiar. However, it is necessary to modify a DOS.BAT file to do this.

After I understood the data requirements, I reviewed our S/36-based shipping procedures and files to locate a point where data could be captured. Information missing from our system could be taken from an additional data entry screen. At the end of the shipping day, a menu option that executes the PCU command would be run. This copies the EDI flat file to the S/36 virtual disk. PCU also translates the file from EBCDIC to ASCII. Then, any PC running PC Support/36 could attach to the virtual disk and use the DOS COPY command to retrieve the file.

Since multiple record formats are the rule rather than the exception in an EDI file, certain record groupings in the flat file made no sense to me. So I began to cheat - that is, I let the translator "teach" me through error messages. These messages tersely state which data-elements (fields) are missing or mis-matched and the segments (records) where they occur. After a few calls to the software support line, and persistent fiddling with RPG output specs, I finally translated a file with no errors. Now it was time to get on-line with the value added network.

Once again, I called on our customer's EDI contact for help with creating a "trading partnership" through the network. He walked me through the set-up options without any problem and we arranged a test transmittal.

At the time of the test, I exercised the entire flow of the system:

o Running a test shipment through the EDI flat file output program (on the S/36).

o Running PCU to copy it to the virtual disk (on the S/36).

o Copying the file to the PC from the virtual disk thru PC Support/36 (on the PC).

o Invoking the translator, thus creating another file (on the PC).

o Connecting with the network, via 1200 baud modem, and following the instructions for sending a "low speed service" file (on the PC).

Dig In Again

I sent the file to the network using the Hayes SMARTCOMM II communication program, apparently without difficulty. But when I tried to verify that it had been "logged" into the customer's mailbox, all I received was a cryptic "Invalid segment" error. The network support person told me that my file was unreadable by their system; therefore their error trapping prevented it from being accepted. I was told to contact the vendor of my translator software.

What the vendor told me came somewhat as a surprise. The network we use must have its files transmitted in "variable length" format, with a special "segment terminator" (end-of-line character). Fortunately, our translator package allows the selection of any character as a segment terminator, and it also includes a special conversion program to generate a variable length file. All I needed to do was change the segment terminator (a system set-up option) and insert a special .EXE command in the .BAT file after the translator ran.

I made the necessary changes and repeated the transmittal test. This time the file was accepted. After yet another conversation with our customer's EDI contact, I made some minor output changes to the RPG flat file program, and we have been transmitting the file on a daily basis ever since.

While I am still far from being an expert, I hope that my experience may help the first time EDI'er through the initial planning phases.

If you are about to undertake an EDI project of any size, there are some things to consider first:

- If you are going to use data from an installed midrange system, then this is a job that will require technical skills. If you operate a DP shop with no programmers, then retain the services of a reliable DP professional for the duration of the project. Shops that use packaged software exclusively should take note.

- There are translator options that allow you to define data entry screens and key the document directly to the PC. This could be used where no data exists on the host, and you probably will not need extensive programming.

- Your costs can vary depending on the method of communication best suited to your shop. Prices for the S/36 and AS/400 resident translator programs are higher than for the PC versions.

- Be prepared to allocate additional work time for the employee(s) who will be responsible for translating & sending the EDI document(s). This usually occurs toward the end of a business day.

In addition, here are some points in that might make the task of the programmer/analyst easier:

- Establish ongoing contact with a technical person at the other end of the partnership!

- Obtain and study the standards manuals for the type(s) and version(s) of EDI document(s) you will be sending or receiving.

- There may also be industry-specific "linkage council" manuals that will define subsets of certain EDI document standards that can be used for your industry. This reduces the number of segments that can be used in a document, thus making your job easier.

- If possible, evaluate several translator packages before you recommend or purchase one.

- Find out if the value added network requires files to be sent in a special format. Be sure the translator program can handle it.

A year has passed, and our EDI program has not grown in document types or customers, but their have been serious discussions along those lines. No matter if only one document is transmitted to one customer - the experience gained and the fact that our largest customer is satisfied made the journey into EDI a worthwhile one.

Electronic Data Interchange (EDI): A Case Study

Figure 1 EDI advance shipment notice and explanation

 Figure 1: EDI Advance Shipment Notice and Explanation 1. ST*856*0506 2. BSN*00*00019549*900720*1540 3. DTM*011*900720*1540 4. HL*01**S*1 5. MEA*PD*G*1292*LB*0*0 6. TD5*B*2*ANYT**ANY TRUCK LINE NAME 7. REF*CN*99.99999 8. N1*SF**91*01 9. N1*ST**92*9987 10. N1*VN**08*999999 11. HL*02**O*1 12. PRF*9999-9999*0099**900319 13. TD5*B*2*ANYT**ANY TRUCK LINE NAME*CC 14. REF*VN*B-9999 15. HL*03**I*1 16. LIN**VN*0956***IN*BESTWEAVE 17. REF*IV*012345 18. HL*04**Q*0 19. LIN**RO*000343933 20. MEA*PD*LN*587*YD*0*0 21. MEA*PD*CW*60*IN*0*0 22. MEA*PD*G*362*LB*0*0 23. HL*04**Q*0 24. LIN**RO*000347114 25. MEA*PD*LN*772*YD*0*0 26. MEA*PD*CW*60*IN*0*0 27. MEA*PD*G*464*LB*0*0 28. HL*04**Q*0 29. LIN**RO*000348291 30. MEA*PD*LN*759*YD*0*0 31. MEA*PD*CW*60*IN*0*0 32. MEA*PD*G*466*LB*0*0 33. HL*04**Q*0 34. CTT*03*1039338 35. SE*35*0506 Note (*) is the data element separator.