An Executive Briefing on EDI

Transcription

1 A Drummond Report An Executive Briefing on EDI with Electronic Funds Transfer and Bar-code Rik Drummond

2 Copyright 1992 by Richard V. Drummond 2nd. All rights reserved. Printed in the United States of America. No part of this book may be reproduced or distributed in any form or by any means, or stored in a database or retrieval system without the prior written permission of the publisher. Neither Richard V. Drummond 2nd nor Drummond Company assume responsibility for any errors that may appear in this document. Drummond Company Suite 227, 6080 Hulen St. South Fort Worth, TX 76132

3 Contents Contents...i Acknowledgments...iv Purpose...v Introduction and Organization...1 Introduction...1 Book Organization - EDI, EFT and Bar-code Interaction...2 Definitions...4 EDI, EFT and Bar-code Interaction Example...6 Section 1 - EDI Implementation Considerations...7 EDI Drivers - Why Companies Implement EDI...7 EDI Benefits...8 Tactical Benefits...8 Increased Accuracy and Timeliness of Information...8 Increased Customer Service Ratings...8 Reduced Inventory Costs...8 Strategic Benefits...9 Automotive Industry...9 Grocery Industry...9 Retail Industry...9 General Benefits...9 Legal Issues...10 Introduction...10 The Statute of Frauds...10 Uniform Commercial Code (UCC)...10 Federal Government and EDI...11 IRS Revenue Procedure EDI Trading Partner Agreement...11 i

4 Auditing Issues...13 Introduction...13 Audit Trail...14 American Bar Association and Auditing...15 Security Issues...16 Introduction...16 Trusted Computer Base Evaluation Criteria...16 End-to-End Data Encryption...17 Sender or Recipient Non-repudiation of Messages...18 EDI Project Stages...19 Re-engineering Internal Processes...21 Industry Trade Associations...21 EDI Implementation Cost Model...22 EDI Cost Range Example...23 Section 2 - Electronic Data Interchange...24 Electronic Data Interchange Diagram...24 Definitions...25 Invoice Processing Example...25 Communication Methods / Options...26 Direct Connection...26 Value Added Networks...27 EDI Software...29 Existing In-house and EDI System Mapping...29 Mapping Example...30 X12 Data Format Description...31 Introduction...31 Definitions...32 X12 Data Structure Overview...34 X12 Interchange Control Structure...40 An X12 Encoded Data File Example...44 ii

5 Section 3 - Electronic Funds Transfer...47 Electronic Funds Transfer Diagram...47 Definitions...48 Automated Clearing House...49 ACH Electronic Funds Transfer Formats...50 Reconciling Accounts Receivable Records Using EFT...50 ACH Electronic Funds Transfer Formats...50 EFT Description Example...51 ACH and EDI Service Integration...52 Section 4 - Bar-code...53 Bar-code Diagram...53 Introduction...54 Definitions...55 Company-specific Bar-code Applications...55 Industry-wide Bar-code Applications...56 Introduction...56 Industry Use Overview...56 UPC-A Bar-code...57 Bar-code Interleave 2 of Appendix A - ASC X12 Organization...1 Appendix B - X12 Transaction List...3 Appendix C - Value Added Network Vendors...7 Glossary...9 Bibliographies...17 Acknowledgments I would like to thank the following people for reviewing, editing and commenting on the manuscript: Jesse Alderson, Richard Branch, Jack Becker, Ph.D., Kay Cecil, Larry Clark, Sara Drummond, Rosie Horvath, Don Huckaby, Esther Huckaby, Ph.D., Debbie Welch, and Charles Wright, Ph.D. RVD2 iii

6 Purpose Over the years as I managed large corporate-wide technical projects in Fortune 100 firms and as technology rapidly changed, it became more and more difficult to maintain the appropriate level of technical expertise necessary to manage the projects to an adequate depth. Most technical books are written in too much detail for people who only need to understand the architecture and the overall concepts of the technology they manage - - not the technical specifics. To that end, this book is written to be easily read, yet convey the primary technical concepts of Electronic Data Interchange (EDI) at a manager's or executive's level. Additionally, two companion technologies, Electronic Funds Transfer (EFT) and Barcode, are reviewed. Unlike most books on the subjects of Electronic Data Interchange (EDI), Electronic Funds Transfer (EFT), or Bar-coding that are 250 to 350 pages in length and require several days of dedicated attention to digest, this manuscript avoids extraneous information and focuses on key concepts and relationships to enhance comprehension. The average reading time is less than three hours. Please send comments or inquiries to: Rik Drummond DRUMMOND COMPANY Suite 227, 6080 Hulen St. South Fort Worth, TX (817) DRUMMOND COMPANY is an Electronic Messaging and Electronic Data Interchange Consultancy offering on-site seminars and consulting to Fortune 1000 clients. i

7 Introduction and Organization Introduction It is said that the implementation of Electronic Data Interchange (EDI) requires 80 percent people, political, and project management skills, and 20 percent technical expertise. The implementation of electronic inter-company business documents such as purchase orders, invoices and sale catalogs affects several parts of an organization, such as warehouse, finance, audit, legal, security, and MIS. EDI affects people's responsibilities! EDI will change the tools a company uses to conduct business with other organizations. When the tools change, the personnel and skill-mix requirements of an organization change. Employees' jobs and careers change. The personal impact on people causes significant resistance to an EDI implementation if those being affected do not feel involved in the EDI Project. Many EDI implementations have stalled by passive or outright resistance because the internal organizations being affected had too little or no buy-in to the EDI concept and project. It is very important that the EDI objectives and plans be sold to (and buy-in received from) all affected organizations and personnel. Unless all personnel feel non-threatened by t h e changes, it is not possible to receive total organizational buy-in. For all subdivisions of an organization to participate fully in an EDI project, it is important that the project be "owned" by an executive at a high enough level in the organization to "own" all the affected sub-divisions of the organization. It is not appropriate to have MIS executives responsible for an EDI Implementation Project, unless they are responsible for the finance, the warehouse and all other affected organizations. This book focuses on supplying information on all parts of the EDI implementation to a sufficient depth to impart a thorough education on the subject without going into unnecessary detail. 1

8 Book Organization - EDI, EFT and Bar-code Interaction Electronic Data Interchange, Electronic Funds Transfer and Bar-coding are three related technologies that often work in concert to reduce greatly paper transactions, speed information flow, and enhance data accuracy. The book is divided into the following sections: Section 1- deals with general non-technical EDI implementation considerations ranging from a general project plan to auditing issues. Section 2 - this section deals with the technical aspects of EDI in areas such as data communications protocol, interfacing to existing computer systems, EDI software, and the cross-industry X12 EDI Standards. (See Figure 1.) Section 3 - this section deals with the technical aspects of EFT and its interaction with EDI. (See Figure 1.) Section 4 - this section deals with the technical aspects of Bar-coding in transportation and retail industries. (See Figure 1.) Appendix A - ASC X12 Organization Appendix B - X12 Transaction List Appendix C - Value Added Network Vendors Glossary Bibliography 2

9 EDI, EFT and Bar-code Interaction Diagram The subjects covered in Sections 2, 3, and 4 are keyed to Figure #1 below to enhance the understanding of the technology interaction. Section 2 Company A Purchase Order Invoice Remittance Advice Company B Payment Order/ Remittance Advice Remittance Advice Company A's Bank Section 3 Corporate Trade Exchange (CTX) Company B's Bank Product Transportation Using Bar-coding Company A's Shipping Agent Section 4 Product Product Transportation Using Bar-coding Company B's Shipping Agent Figure 1 Note: It is impossible to cover all the ways companies use the EDI tool in 50 to 60 pages. The examples used throughout this book are real working implementations and are used by many organizations. There are many more options available. 3

10 Definitions EDI - Electronic Data Interchange EDI, Electronic Data Interchange, is the exchange of business documentation, such as shipping notices, invoices, and purchase orders, in a structured computerprocessable format through data communication protocols. In the United States, the primary computer-processable formats are defined by the X12 Organization. X12 is accredited by ANSI, the American National Standards Institute, a not-for-profit organization. Other industry-specific EDI formats have historically existed. They are rapidly being incorporated into X12. In Europe and many other parts of the world, EDIFACT is the primary EDI format. X12 is currently aligning with the international United Nations EDIFACT format. If the EDI industry works as most computer related industries, then X12 products will automatically align with the EDIFACT Standards at little or no conversion cost to the user community through version releases. Purchase Order Item 1 Item 2 Total Figure 2 4

11 EFT - Electronic Funds Transfer EFT, Electronic Funds Transfer, is the inter-bank exchange of value (dollar amounts) in a structured, computer-processable format. It is the equivalent of an electronic check. Other inter-bank value transfer networks exist. However, NACHA is the primary one used by general business. Several different Automated Clearing House (ACH) formats exist for inter-bank funds transfer. These inter-bank standards are managed by the banking industry organization NACHA. NACHA is an acronym for National Automated Clearing House Association. Pay To: $ /100 Figure 3 Bar-code Bar-codes are printed codes consisting of lines and spaces that may be read by a bar-code scanner. Several different bar-code methodologies are in used in commerce today. The UPC, Uniform Product Code, is used for product identification. Another bar-code, Interleave Code 2 of 5, is used for shipping container tracking in the grocery industry. In some bar-code methodologies the combination of spaces and lines can only represent the numerals zero (0) through nine (9). In other methodologies the bars and spaces can represent the entire alphanumeric character set plus several special characters such as $, %, *, /, etc. Figure

12 EDI, EFT and Bar-code Interaction Example Two companies interact because one offers a product or service the other needs or wants. A product purchase interaction between two companies is described below, using Figure #1 as the basis. Company-A requests price information, refers to Company-B's product catalog, and sends a purchase order to Company-B to buy the product. Company-B may respond to Company-A in many ways depending on product availability and price changes. We will assume the product is still available at the catalog price. Company-B sends an Advanced shipping notice to Company-A to notify them of the product, quantity, and the shipping date. Company-B ships the product to Company-A using the transportation industry. The transportation industry uses bar-coding to mark shipping containers and packages to facilitate package handling and tracking. Company-A receives the product package, scans the bar-code on the container, and matches the bar-code value against the value contained in the Advanced shipping notice to verify that the Advanced shipping notice belongs to the package. The verified Advanced shipping notice is used to automatically update Company- A's inventory. After the product arrives, Company-B may invoice Company-A. Some companies who use EDI pay many of their providers from information in the Advanced shipping notice and forgo the Invoice. Company-A sends Company-B remittance advice and instructs its bank to pay Company-B the appropriate amount. Company-A's bank transmits a CTX transaction (electronic check and remittance advice) to Company-B's bank for the proper amount. The bank debits Company- A's account. Company-A's bank attaches to the CTX the electronic remittance advice information received from Company-A. Company-B's bank receives the CTX, credits Company-B's account, uses the remittance advice from the CTX, and forwards the information on to Company-B through either an EDI or private network connection. 6

13 Section 1 - EDI Implementation Considerations EDI Drivers - Why Companies Implement EDI Most Fortune 500 firms are implementing EDI to reduce costs, enhance competitiveness, improve inventory turnover, improve customer service, reduce data entry errors, or reduce the overall personnel cost of processing transactions such as purchase orders, invoices, shipping notices, and payment order / remittance advice. Many of the smaller Fortune 2000 firms implementing EDI are doing so at the request of larger trading partners and customers. The benefits of EDI are often overlooked by small companies because they implement EDI only to appease their larger customers, not for the direct benefits. Several organizations have documented the savings from their EDI implementations. The Automotive Industry Action Group, AIAG, the purveyor of EDI in the Automotive Industry, believes EDI has reduced the cost of each car by over $200. The two Arthur D. Little Grocery Industry Studies projected administrative savings of over $700 million per year through the implementation of EDI, direct store product delivery, and bar-coding. Over 47 percent of the savings is passed on to customers. SuperValu has projected savings of over $600,000 per year by shortening the order cycle. Many companies have found that the cost to process an EDI purchase order is less than one-fourth of the paper purchase order cost. HP recorded purchase order processing cost decreases from $1.65 to $0.58, RCA $62 to $7.50 and DEC $125 to $32 as they left paper purchase orders behind and implemented electronic purchase orders. Many companies have found the cost of processing a n EDI purchase order is less than one-fourth the cost o f processing a paper purchase order. Some have found even larger savings. EDI Benefits The implementation of EDI has many tactical and strategic benefits. 7

14 Tactical Benefits Increased Accuracy and Timeliness of Information One of the first benefits of implementing EDI is increased timeliness and accuracy of information. Without the direct computer-to-computer exchange of information, data must be entered by hand into the destination computer system. Most organizations have time lags ranging from a few days to several weeks between the receipt of information on paper and entry into the computer system. Because of this time lag, the computer information database does not normally reflect up-to-date information. Information reentered by Data Entry personnel has a significantly higher error rate than information received directly from another computer. Increased Customer Service Ratings Some companies have implemented EDI to serve their customers more effectively. With EDI, customers can enter and track order status, receive shipping order notices, and receive catalog and catalog price updates, all electronically in a timely and costeffective manner. Reduced Inventory Costs The Automotive Industry effectively implemented Just-In-Time (JIT) inventory concepts with their suppliers through the use of EDI. Through this JIT method a company keeps minimal inventory on hand and continually re-orders and replenishes -- sometime several times a day -- directly from the supplier. The order and order status are exchanged between trading partners through EDI. The implementation of JIT can greatly decrease an organization's cost of maintaining inventory stock by reducing (1) warehouse-floor-space cost, (2) warehouse-personnel cost and (3) the cost of maintaining idle inventory. 8

15 Strategic Benefits Automotive Industry The Auto Industry implemented EDI in the early 1980's to help reduce costs and regain market share. Grocery Industry The Grocery Industry became much more cost-effective and timely by implementing bar-coding, point-of-sale bar-code scanners, and EDI. The industry saves hundreds of millions of dollars a year because of EDI and related technologies. Retail Industry The Retail Industry, following the Grocery Industry's lead, implemented bar-coding, point-of-sale bar-code scanners, and EDI. Several large retail companies such as Levi and Haggar Apparel have implemented Quick Response. The Quick Response initiative through the use of point-of-sale data, bar-coding, and EDI helps keep a retail outlet's shelves stocked with the best-selling sizes, styles, and colors. Data from the point-of-sales bar-code scanners are used to compute current seasonally adjusted inventory needs. A purchase order with the appropriate replenishment quantity, size, style, and color is posted nightly to the manufacturer. The manufacturer may "overnight deliver" the order to the retail pointof-sale. The companies involved in this initiate have shown a sizable percentage increase in sales because the best selling sizes, styles, and colors are always available to the buying public. General Benefits Many industries have improved relationships with customers and suppliers during the EDI implementation process. Many companies re-engineer and reorganize supporting administrative processes, departments, and functions to take advantage of EDI. The re-engineering often significantly reduces personnel and administrative costs. A major effort is being made in the retail industry to collect and analyze point-of-sale data to project customer needs, wants, and buying habits. If Quick Response in the retail industry is any indicator, having the right product at the right place at the right time will significantly increase sales volume and profit for a company. 9

16 Legal Issues Introduction It is important to involve your company's legal counsel and auditor in EDI planning sessions to work out the legal and audit issues. The discussion below is not meant to replace legal counsel: it is offered merely as a summary of issues that may concern your organization. The Statute of Frauds The Statute of Frauds specifies what constitutes a contract between two entities. The statute differs somewhat from state to state. Usually it describes a time, a dollar amount, or a value over which a signature is required for a contract to be valid. Contracts over that amount are not considered contracts unless signed. An EDI purchase order is a contract to buy goods or services with no place for a conventional signature. An umbrella EDI Trading Partner Agreement is usually signed between the parties to cover the legal contingency. The Trading Partner Agreement specifies the conditions under which each party will exchange EDI transactions and when they are considered to be valid contracts. The X12 EDI envelopes have authentication fields. When the field is occupied by the appropriate secret code it is accepted as an authentic signature. The codes are often shared only between each pair of trading partners. Note: If the EDI software is not sophisticated enough to record and check these codes for many trading partners, people will pick a single code and pass it on to many others, nullifying a major control. Uniform Commercial Code (UCC) The Uniform Commercial Code (UCC) is a set of model statutes that govern most commercial transactions. Versions of UCC have been implemented in all states except Louisiana. Both the Statute of Frauds and the Uniform Commercial Code assume a paper audit trail. Paper is exactly what EDI is attempting to eliminate. Some companies believe EDI transactions are adequately covered in both sets of statutes. (See IRS RP below.) Most believe that until a clearer ruling on the subject is made by the judiciary, extra insurance is needed. The extra insurance is in the form of a Trading Partner Agreement. 10

17 Federal Government and EDI The federal government is interested in implementing EDI to reduce administrative overhead and paper work. With the largest employer and organization in the nation implementing EDI, the legal issues should be resolved rapidly. IRS Revenue Procedure Recently the IRS, in Revenue Procedure (RP) 91-59, stated that an organization need not keep a paper evidence trail under the following conditions: The IRS must have access to electronic records. The EDI user must have a system of internal controls covering the electronic records. The electronic records must support information reported on the tax statement. The EDI user must comply with the standards set by the National Archives and Record Administration for the physical handling and periodic check of records. EDI Trading Partner Agreement Companies participating in an EDI exchange normally sign a Trading Partner Agreement that specifies what constitutes a signature, who is responsible for loss, security assumptions and conditions, confidentiality requirements, etc. Some companies issue three-page Trading Partner Agreements while others have agreements over 20 pages long. A few companies believe that EDI fits within the existing laws and business practices and requires no additional contractual instruments. A company's legal counsel should choose the contents of a company's Trading Partner Agreement. The American Bar Association (ABA) has released a Model Trading Partner 11

18 Agreement that may be used as the basis for a company's agreement. The model agreement with comments, discussion and conditions is 25 pages long. Below is a brief description of several sections to give an idea of the focus of the model agreement: Document Standards - specifies the type of EDI transactions each party will accept, such as purchase orders or invoices. Third Party Providers (VANs) - specifies who pays for the services. Usually each party pays for what it uses. Systems Operations - specifies that each party will operate the required hardware and software to send and receive EDI at its own expense. Security Procedures - details the required minimum security to be used by each party. Signatures - states what constitutes a signature for the exchange. Receipt - describes the conditions that are necessary to say a party has received a transaction. Verification - specifies that the receiving party will notify the sender of delivery upon receipt of the document. Acceptance - states conditions under which a document is deemed accepted. Unintelligible Transmission - states the conditions and responsibilities of the receiver to notify the sender during transmission problems. Terms and Conditions - lists terms and conditions which apply to the exchange. Confidentiality - states what is confidential between the parties. Governing Laws - lists laws under which the exchange will take place. Force Majeure - states that no party is responsible for conditions out of its control. Arbitration - details how conflicts and disagreements will be resolved. 12

19 Auditing Issues Introduction The methods used by an auditor to review a system are common in overall composition. In any system, whether computer or paper process, auditing progresses through several steps: Evaluate the documented internal controls and procedures for appropriate audit control coverage. Evaluate the internal controls and procedures for consistency in use. Determine any overlooked items in the control processes to assure there are no undocumented or overlooked risks. Test the system controls and procedures. Issue the audit opinion. Normally, the auditor has paper copies of documents and reports to test the controls and procedures. With the arrival of EDI, paper copies no longer exist for EDI transactions. On-line data is used to evaluate the system. Assurance that the on-line audit trail is at least as good as the previous paper trail is paramount. 13

20 Audit Trail EDI data may be moved through five different systems as it is exchanged between two companies. It moves through the following systems: Company-A's internal existing system Company-A's EDI software VANs or other communication systems Company-B's EDI software Company-B's internal existing system EDI Interchange Components End-to-End Internal Existing Systems EDI Software A B Networks C Networks EDI Software D Internal Existing Systems 1 A E Figure 5 Given that the five systems involved in the exchange have the appropriate audit controls, the only components involved in the exchange that have not previously been assured are the interfaces A, B, C, D, E, and the end-to-end document security and exchange procedures. 14

21 American Bar Association and Auditing The interfaces A, B, C, D, and E should be audited to verify that the appropriate procedures and controls are in place to retain the audit integrity among the five existing components. Once this is complete, end-to-end system integrity procedures and mechanisms should be implemented through the Trading Partner Agreement. Several items in the American Bar Association's Model Trading Partners Agreement that are pertinent to end-to-end audit trails are listed below: Document Standards Systems Operations Security Procedures Signatures Proper Receipt Verification Procedures Acceptance Confirmation Garbled Transmission Reconciliation Most off-the-shelf EDI software packages have controls which track and report on information flowing in and out of the system. The VANs serve thousands of EDI partnerships that have the same security, legality, and audit concerns as discussed above. With these considerations, there is nothing new with EDI auditing compared to existing internal computer systems. Some people say that in the previous systems they had external signed-paper evidence to verify the internal system and with EDI they lose the external paper evidence. The external evidence exists in the VAN transaction records and the EDI communications software of both parties. It should be easier to verify on-line external computerized evidence than external paper evidence. These issues will only be resolved when electronic signature and nonrepudiation standards are widely implemented. 15

22 Security Issues Introduction EDI security issues are not any different from those of current computer and data communications systems. Just ensure that all three divisions, (1) the internal existing systems, (2) the EDI software products, and (3) the intermediate communication networks, have the proper physical and logical access, event tracing, and archival control procedures in place. See Figure #5. Trusted Computer Base Evaluation Criteria The specification for rating the level of computer security in a computer complex is the Department of Defense's Trusted Computer Base Evaluation Criteria. The Criteria defines the required software security components and procedures to manage the entire computer complex to a rated level of security. The Criteria rating methodology is much like a school's grading system. A system rated "A" is the most secure; one rated "B" is a little less secure; a system rated "C" is even less secure. A system rated "D" is the least secure of all. Several grade levels are subdivided into levels using numbers such as C1 and C2, with C1 being less secure than C2. If the existing in-house EDI software and intermediate communications network are each rated as C2 or B1 capable, and each is managed in a manner that implements the security capabilities, then the whole system is at the appropriate level of security for most EDI endeavors. 16

23 End-to-End Data Encryption The only remaining security consideration is end-to-end encryption of the transmitted EDI data. At the present time, the continuous administrative effort to implement encryption between several trading partners is cost prohibitive for many companies. The problem with encryption of EDI data is not t h e technology, but rather how to manage the encryption keys for many trading partners. Cost-effective, PCbased encryption products are currently available f o r use. They may be sufficient for smaller applications. New software and procedures that allow the implementation of end-to-end encryption in a cost-effective, administratively-efficient manner are on the horizon. The new techniques will use the Public Key Encryption Algorithms. Watch for forthcoming EDI software products a n d releases that support and effectively manage Public Key Encryption for many trading partners. 17

24 Sender or Recipient Non-repudiation of Messages Non-repudiation is the ability to verify without question that a message was sent by a certain party, or alternately, that a message was received by a specific party. The implementation of this feature uses variations of Public Key Encryption that are not normally part of the EDI envelope architecture. The X.400 International Messaging Standard section X.435 has the non-repudiation of messages function built into the architecture. This feature is important to EDI exchanges. Look at the items in the American Bar Association's Model EDI Trading Partner Agreement. Procedures such as return receipt, who is at fault for message loss, and message loss prevention are addressed in the contract. VANs can add a form of non-repudiation between trading partners by recording the receipt and delivery of messages between parties. However, this does not implement a form of nonrepudiation between the sender and its VAN, the receiver and its VAN, or between the interconnected VANs. 18

25 EDI Project Stages An EDI project has a number of stages and critical issues that must be addressed for the project to be successful. Below is an example EDI Implementation Plan. The early involvement of key executives, affected departments and trading partners in defining t h e schedule, events, and issues is critical to project success. Tie EDI implementation to the Company's Business plan. Recruit the executive EDI project champion. Create an Advisory Board composed of executives from affected subdivisions of the organization. Define the EDI strategy. Create an internal project team, which reports to the Advisory Board, with representatives from affected organizations such as accounting, purchasing, auditing, sales and marketing, manufacturing, security, and legal. Choose the X12 transaction sets to implement. Train the project team. Identify EDI information sources such as EDI software, VANs, and trade associations. Initiate RFI (Request for Information) to EDI software vendors and VANs. Select the best products and service for the company. Review and study existing external and internal information process flows in the areas which EDI will initially affect. Categorize these processes by trading partners, owners, anticipated problems, affected procedures, ease of modification, and effort and cost to modify. Identify key trading partners. Categorize by transaction volume, dollar volume, influence, relationship, EDI expertise, and the positive and negative aspects of an EDI implementation on the relationship. Investigate and create the company's Trading Partner Agreement using legal counsel in concert with the EDI Project Team. Define and review EDI components such as software, communications, and procedures for the appropriate audit and evidence trail. Estimate the cost of implementation in areas such as process re-engineering, personnel, capital (hardware and software), and impact on the organization. Estimate the ongoing production costs in personnel, capital, in-house and off-theshelf software maintenance, and VAN usage. Select and train the EDI operations staff. 19

26 Educate the company's personnel as to EDI benefits, impacts, strategies, and technologies. Create the project plan, detailing schedule, initial trading partners, and initial and ongoing costs. Identify any issues that must be handled with special sensitivity. Have the EDI Sponsor sign off on the EDI Implementation plan. Select and educate the initial trading partners. Determine the X12 transactions and versions to exchange, and the communications protocol or VANs to use. Choose the specific trading partner implementation schedule with the individual trading partners. Sign contracts with initial trading partners. Before "going live" with each trading partner, run an EDI pilot in parallel to existing paper or automated systems for a set length of time to verify EDI data. Ensure internal and external customer satisfaction by formally conducting a survey on issues and perceptions. Use survey comments to evaluate preceding steps. 20

27 Re-engineering Internal Processes One of the key factors in harvesting the most significant benefits of EDI is reengineering the internal processes to take advantage of the new EDI tool. Numerous books have been written on the subject of process re-engineering or Business Process Improvement. They contain techniques, tools, and overall guidelines on how to conduct an effective Business Process Improvement effort within an organization while minimizing organizational disruption and damage. A large-scale Business Process Improvement effort is not required to begin an EDI Program. However, t h e limited number of processes initially affected by EDI such as those in purchasing, accounts payable, accounts receivable, and inventory should b e investigated and appropriately modified to use the EDI tool more effectively. Industry Trade Associations Most industries have established trade associations that monitor forthcoming government regulations, industry and economic trends, and conduct mutually beneficial joint projects in subjects affecting the overall industry. Many of these associations have an established EDI facilitation group of some kind. The group's function is to enhance and speed the EDI implementation effort among the trade association companies by sharing contacts, information, and lessons learned. Most publish a set of EDI Implementation Guidelines specific to their industry. These guidelines can greatly facilitate a company's entry into the EDI world. EDI information may often be obtained from your Industry Trade Association. 21

28 EDI Implementation Cost Model EDI may be implemented on a personal computer or on a mainframe. EDI software may be integrated with the existing in-house systems or left disconnected from those systems. Internal company processes may be re-engineered to take advantage of EDI or left as they were before EDI was introduced to the company. Many EDI experts would agree that each of these areas has a general rule-of-thumb implementation cost inter-relationship. Norman Barber of Cornerstone believes if it costs one dollar to purchase and install the EDI software, then it will cost five dollars to integrate it with the existing internal systems and it will cost ten dollars to reengineer the internal processes. Rule-of-Thumb EDI Implementation Cost Implementation Components Purchase and install the EDI software and hardware Integrate the EDI software into the existing in-house information system environment Re-engineer the internal processes to take advantage of the EDI tool Table 1 Relative Cost 1X 5X 10X 22

29 EDI Cost Range Example A company may choose to implement EDI on a personal computer or on a mainframe. Below is an example cost range to implement the "1X" part of an EDI Project. Implementation Cost Range Categories PC Mainframe EDI Software $500 $30,000 Required Hardware $2,500 Normally a small added cost Yearly Maintenance $300 $3,000 Yearly Comm. Cost $500 $10, "1X" Total = $3,800 $43,000 Table 2 Usually smaller companies use personal computers and larger companies use mainframes. At times it may be cost-effective for a large company to use a personal computer. 23

30 Section 2 - Electronic Data Interchange Electronic Data Interchange Diagram This section covers the technical aspects of EDI as specified in the figure below. The major topics are: Definitions Invoice Processing Example Communication Methods / Options EDI Software X12 Data Format Description Section 2 EDI Diagram Company A's Existing Information Systems: Accounts Payable Accounts Receivable Purchasing Inventory MRP C B EDI Software Purchase Orders Invoices Remittance D A VAN & Communication System To Company-B Account Activity & Status Payment Order/ Remittance Advice Company A's Bank Figure 6 Each of the above items, (A), (B), (C) and (D) will be discussed later in this section. Item (A) is covered in the section Communication Methods / Options. Items (B) and (C) are covered by the topic EDI Software. Item (D) is covered in section X12 Data Format Description. Definitions Mapping Mapping is the process of identifying the relationship of internal systems data elements to those in the X12 standards so that the interchange of information between the existing and EDI system may be automated. 24

31 Logging Event logging is writing a time-stamped record for each key event to a file for later review by EDI operations, auditing, and/or security. Transactions Examples of X12 transactions are: Purchase Order, Invoice, Advance Shipping Notice, Contract Award, Freight Invoice, Price Sales Catalog, Railway Bill, and Payment Order / Remittance Advice. Value Added Networks Value Added Networks provide services such as: a data communication network, translation between versions and standards, audit trails between trading partners, transaction archiving, and education and consulting services. Invoice Processing Example The following events take place when Company-B sends Company-A an invoice. Company-A's EDI software receives an invoice from Company-B through the VAN. Company-A's EDI software verifies that the X12 structure is correct, and because company-b requested it, returns an acknowledgment to Company-B. The EDI software records in its logging database who the invoice was from, and when, and how the invoice was received. The EDI software translates the fields of the X12 invoice into the internal company format using the mapping information previously defined by the programmers. The actual exchange of information is normally in the form of a series of neutrally-defined flat files. The exchange of the flat files is usually through a batch job. The internal system receives the invoice and matches it against the internal Accounts Payable files. If what was delivered matches what was ordered, the company issues a payment to company-b. (At this point, many companies have human intervention to approve a payment over some preset limit.) 25

32 Company-A reconciles the invoice with the internal system, and transfers the payment information to the EDI software mapping routines. Company-A's EDI software converts the payment information into a Payment Order / Remittance Advice X12 data stream and transmits to its bank by way of the VAN. The EDI software logs to whom and when the X12 transaction was sent. If it does not receive a functional acknowledgment within a predetermined amount of time, it will notify the EDI software operator that there may be a problem with the transmission. Company-A's bank receives the Payment Order / Remittance Advice from Company-A and issues an Electronic Funds Transfer to Company-B's bank. See Section 3 - Electronic Funds Transfer for further details. The invoice has been submitted and paid entirely electronically. Communication Methods / Options Two means exist for communicating with trading partners. The first is a direct connection not using a VAN. The second is through a VAN. Each has benefits and detriments. Direct Connection Direct connection is the use of the X.25 network, or leased or dial-up lines directly between two trading partners. EDI information is generally data communications insensitive. (This assumes the recommendations for constructing the transmission package are followed.) An EDI Envelope may be transmitted using a PC to PC file protocol such as X.PC or ZModem. It may be transmitted using normal mainframe to mainframe protocols such as 2780/3780. The direct connection method assumes that two partners communicate with a single data communication protocol out of over ten available options. This works well when only a few partners are involved or if one party can dictate to all their trading partners the single protocol to use. As the numbers of partners increase, so does the number of protocol options one must support, and therefore, the management of the trading partner communications becomes more complex. Direct EDI data communication connections between partners often become less effective as the number of partners grows. 26

33 Direct connection can be less costly than connecting through an intermediate VAN. Direct connections, using leased line or dial-up, are not sensitive to the number of characters transmitted between the two parties. Direct connect costs are usually determined by a flat monthly charge or a per-minute usage charge. One of the VANs' normal charging methods is on a character volume basis. Even if one is using a VAN, it may be more costeffective to implement a direct connection between high volume trading partners. Value Added Networks VANs are large networks, usually international in nature, which transport EDI information among participating trading partners. VANs offer services such as EDI packet transportation, conversion between different EDI versions and standards, audit trails, security, trading partner identification, education, and consulting. VANs can greatly facilitate a company's entrance into the EDI arena. VAN to VAN Interconnection Over the last five years, the VANs have interconnected their networks so that any company using one of the several VANs can communicate with any other EDI user, whether on the same VAN or a different VAN. Most VANs surcharge users for EDI exchanges other VANs. with VAN Charging Methods VANs have different methods of charging for services and usage. The VANs' pricing structures change over time as they adjust to market pressures. Most have a flat monthly fee and charge by the volume of EDI envelopes or data characters transmitted. Several have minimum monthly charges. Many VANs charge for the detailed monthly billing statement. Many VANs offer volume discounts. It is not hard to negotiate a 30 to 50 percent discount for a sizable monthly EDI volume. 27

34 VAN Protocol Conversion One of the significant offerings from the VANs is the ability to offer transparent data communications protocol conversion between trading partners. Example: If Company-A transmits EDI using the IBM Bisynchronous 2780 protocol and Company-B uses the PC protocol X.PC, they will not b e able to communicate directly without changing to the other's data communication protocol. However, by an intermediate VAN, they could each communicate using their chosen protocol. The VAN would transparently convert protocols as it delivered t h e information between the two partners. The protocols most VANs support are: X.25 SNADS TCP/IP X.400 (84) X.400 (88) X / BSC 3270 SNA RJE/HASP X.PC XModem YModem UTS Not all VANs support conversion between all protocols. They may support conversion between 2780 and X.25 but not support conversion between 2780 and X.PC. These offerings are constantly changing. It is important to query the VAN market through a Request For Information (RFI) to obtain the best value and price before entering into a contract with a VAN. A current list of VANs is included in Appendix C f o r this purpose. 28

35 EDI Software The EDI software is the software that connects the company to the Electronic Data Interchange world. The software usually has the following features: Interchanges data with the existing in-house computer applications (Some PC packages do not offer this capability.) Communicates using different data communications protocols and VANs Converts between different versions of the X12 transaction sets Converts between different industry-specific EDI formats Manages the specific trading partner profiles and interface requirements Verifies that the EDI transactions and surrounding EDI envelopes are properly constructed Records an event log of activity Reports the transaction activity and notifies the staff of specified error conditions Existing In-house and EDI System Mapping In a previous section, EDI Implementation Cost Model, the cost of integrating the EDI software with the internal computer applications was reported to be at least 5 times (5X) the cost of buying and installing the software and hardware. Mapping is the activity that integrates the EDI and existing in-house systems. This can be a personnel-intensive effort. Many vendors are offering increasingly more sophisticated tools to support the mapping effort and reduce the personnel involved in integrating the two systems. Before buying an EDI software package, review t h e mapping support tools carefully. The appropriate tools can significantly reduce the effort and cost o f integrating EDI with the existing in-house systems. 29

36 Mapping Example The following simple mapping example shows some of the issues involved in moving data back and forth between the internal purchasing system and the X12 purchase order in the EDI software system. Example: Company-A orders 10 cases of widgets at $100 each from Company-B. The information is found in internal file ABC, with t h e value "10 Cases" in field XYZ and the value "100" in field EFG. These two pieces of information will be placed in three fields in the 43rd record of the X12 Draft Version 3 Release 1 Purchase Order transaction. The first four fields of this 25 field record are: Line Number, Quantity Ordered, and Unit of Measure Code, and Unit Price. Figure #7 shows what part of the actual 43rd record of the X12 Purchase Order transaction would look like for the above data. Purchase Order PO1 Record Example Record Type Name = PO1 Line Number Quantity Ordered Unit of Measure Code Unit Price PO1*1*10*CA*100*n/l Data Element Separator =* Figure 7 Data Segment Terminator Note: The asterisk character is used as the Data Element Separator in this example. The asterisk character starts each new field. The single item "10 Cases" in the internal system was separated into two separate fields in the X12 document. 30

37 Once the mappings between "like" data items in the internal and the EDI software systems are defined, the data mapping can be automated and used for all future purchase orders. Some of the fields in a transaction may not be used by all trading partners. The software may need to handle the differences in field and record usage for different partners -- a slightly different mapping for each trading partner. This can rapidly get complex. A software package with a highly functional Trading Partner Profile database can reduce the management and cost of maintaining the trading partner specifics. X12 Data Format Description Introduction The information in this section is from the X12 Draft Version 3, Release 1 Standards. This section gives an overview of an X12 transaction and the interchange control structure, within which the transactions are placed, for transmission to trading partners. The primary section topics are: Introduction Definitions X12 Data Structure Overview X12 Interchange Control Structure An X12 Encoded Data File Example The X12 Standards define the data and interchange control structures of EDI transactions such as purchase orders, invoices, and shipping notices. An X12 transaction structure is a flat file with a variable number of variable length records. Each record is composed of a well-defined set of fields. Some of the fields are optional. 31

38 Definitions X12 Standards X12 is the inter-industry EDI standard in the United States of America. Historically each industry, such as grocery or transportation, developed its own EDI standards. These industry standards required ongoing translation in order to communicate with other industries. In 1978, the X12 Committee was formed to create the cross-industry EDI standards. In 1979 the American National Standards Institute (ANSI), the official United States standards organization, chartered the X12 Committee as the official Accredited Standards Committee (ASC) for cross-industry EDI standards in the United States. Interchange Control Structures The interchange control structures are composed of two envelopes, one inside the other. The outside envelope will be called the EDI Envelope throughout this document. The inside is the Functional Group Envelope. See Figure #9. The EDI Envelope, the outside envelope, contains the source and destination address data as well as other information. The inside envelope, the Functional Group Envelope, is used to group "like" transactions, all purchase orders, all invoices, etc., together inside the mailing envelope -- the EDI Envelope. The EDI Envelope will be the primary interchange control structure discussed below. EDI Envelope The EDI Envelope is the outside envelope of an EDI exchange. ISA Header The ISA Header is a record that forms the front of the EDI Envelope. It is a 16 data element record that contains the source and destination address information. 32

39 IEA Trailer The IEA Trailer is the record that forms the back of the EDI Envelope. It is a short two data element record. Between the ISA Header and the IEA Trailer, all EDI data is placed for inter-company transportation. Data Segments A data segment is analogous to a flat file record. Data segments are variable in length, have a two or three character name, and are composed of data elements. Data Element A data element is the field in X12. It, like fields in most applications, has a length, either variable or fixed, and a set of edit criteria, such as string, numeric, date, time, or specific character sequences. Data Element Separator The data element separator separates data elements in the file. The recommended separator characters are specified in the X12 standards. For the sake of discussion, "*" will always be used as the character that separates data fields. This implies that "*" may never be used within the actual data. Data Element Separator Example First Field Second Field Nth Field ISA*xxx*yyyyy**...*zzz*n/l Data Element Separator =* Data Segment Terminator Figure 8 33

40 Data Segment Terminator The data segment terminator ends each record. It may be one of several characters. For the sake of discussion, "n/l", the new line character will always be used. Throughout the discussion of X12 data structures t h e terms data segment, segment, and record are used interchangeably. Additionally, the terms data element, and field have the same meaning. X12 Data Structure Overview X12 Interchange Control Structure The Electronic Data Interchange protocols were developed to transfer computerreadable business documents between computer systems independently of data communication protocols. The smallest meaningful piece of transmitted information is called a Transaction. Examples of transactions are business documents such as Purchase Orders, Shipping Notices, Invoices, and Purchase Order Status. 34

41 X12 Envelope Structure Diagram Purchase Order Functional Group Envelope Total: Purchase Orders Within Invoice Invoice Invoice Invoice Total: Total: Total: Total: Invoices Within Functional Group Envelope EDI Envelope. To: From: Date: Time: Authorization Info: Standard Version: X12 Version: Ack. Requested?: Sender Cntrl #: Test Message?: Destination Figure 9 A number of transactions may be transmitted to a trading partner in EDI envelopes called the Interchange Control Structure. The Interchange Control Structure is composed of two nested envelopes: (1) EDI Envelope and (2) the Functional Group Envelope. See Figure #9. The EDI Envelope will be wrapped inside a data communication protocol, such as SNA, X.400, or 2780/3780, for transmission to the recipient. Several transactions are normally exchanged in a single EDI Envelope during a single data communications session. The ISA and IEA records together compose the EDI Envelope. Everything from the first character of the ISA Envelope Header to the last character of the IEA Envelope Trailer is part of the EDI transmission package. See Figures #10 and #13. X12 Transaction Everything from the first character of the ST record to the last character of the SE 35

42 record is part of a single transaction. Several transactions may be included within a single EDI Envelope, each with its own beginning ST and ending SE segment. See Figures #9, #10, and #13. The ST record always begins a transaction, whether it is an invoice, a purchase order, or etc. The ST segment identifies the type of transaction contained between the ST and SE segments. Transaction Identifi ers Each transaction has a unique identifying number assigned. For example the number for the purchase order is 850, the invoice is 810, and the Payment Order / Remittance Advice is 820. The ST segment of an invoice contains the value "810" to identify the data between the ST and SE segment as an invoice transaction. See Appendix B for a list of transactions and their identification numbers. See Figure #14 for a usage example. X12 Variable Length Data Structure Diagram 36

43 Data Segment EDI X12 files are composed of ordered data segments. The data segments may be thought of in the same manner as the data processing records in a file. Each record is terminated with the data segment terminator. The terminator used for the examples is the new line character represented by "n/l." See Figure #10. The data segment terminator is defined in the ISA segment of the EDI Envelope for each transmission. However, in practice, trading partners consistently use a single agreed-upon character. The new line character, "n/l" is used in the examples. Data Segment Names An X12 file, unlike most flat files, contains many different record formats. Each record or data segment has a unique two or three character name to identify the record and its format as it occurs in the overall file. The name of the EDI Envelope Headers segment is "ISA", EDI Envelope Trailer is "IEA", Transaction Headers segment is "ST", Transaction Trailer segment is "SE", the name for one of the segments in a PO transaction is "PO1". These names occur in the actual data stream. See Figures #8 and #10. Each record in X12 has a name which is two or three characters long. The name actually occurs in the data at the start of its record. Data Element A data segment is composed of several data elements. Data elements are separated within the X12 file by the data element separator character, in this case an "*" asterisk. Each transmission may define the data e l e m e n t separator character. The separator is defined in t h e ISA segment. However, in practice, a single value is usually agreed upon by the trading partners for all exchanges. Each data element has a defined place in the sequence of data elements in a data segment. A single data element definition may be included in several data segments. 37

44 Example X12 Data Stream Encoding In the purchase order example following, Item 1, Item 2, and Item 3 are each a single occurrence of the X12 Data segment named PO1. The PO1 record contains information such as the name, quantity, and price of the ordered product. In Item 1 in Figure #11, the product being ordered is a shovel with a vendor catalog number of 456, a quantity of 54, and a price of $0.99. ACS Consultive Services Purchase Order Example Purchase Order Date: July 3, 1992 Bill To: John Smith, ABC Corporation 1234 Easy Street, Great, TX Deliver To: A&D Company 1009 Stella, St. Louis, MO Contact: Sally (111) Item 1 54 $0.99 Each, Ven.Cat.#:456 Item 2 1 $5.49 Dozen, Ven.Cat.#:654 Item 3 12 $14.39 Each, Ven.Cat.#:DEF Item 4 Total: $ Figure 11 In the Purchase Order example above, if the raw data stream of an X12 purchase order were printed and the data from Line Item 1 viewed, it would appear as in Figure #12. 38

45 X12 Encoding Purchase Order Example Data Element Separators Data Segment Terminator PO1*1*54*EA*0.99*CA***VN*456n/l Product ID Product ID, VN=Vendor Catalog two empty fields Price Code, CA=Price from Catalog Unit Price Unit of Measure Quantity Ordered Assigned Identifier Segment Name for the Line Item segment Figure 12 39

46 X12 Interchange Control Structure Introduction This section discusses in detail the contents of the EDI Envelope structure. The EDI Envelope is composed of two data segments: the ISA Header and the IEA Trailer. The transactions are placed between these two segments for transmission to trading partners. See Figure #13. The ISA Header is the front of the EDI Envelope. T h e IEA Trailer is the back of the EDI Envelope. These two segments contain information usually associated with any paper mailing envelope: Source of information Destination of information Date and time the envelope was mailed Optional return receipt Besides information contained on paper envelopes, the electronic EDI Envelope contains verification, security, and other information. Some of these will be discussed in more detail below. The contents of the EDI Envelope may be either of two items: TA1 Interchange Acknowledgment segment Transaction data Interchange Control Structure Diagram ISA - EDI Envelope Header TA1- Interchange Acknowledgment Segment GS - Functional Group Header ST - Transaction Header Transaction Data SE - Transaction Trailer GE - Functional Group Trailer IEA - EDI Envelope Trailer Figure 13 Data Portion of the EDI Structure. EDI Envelope Header Detail The EDI Envelope Header is a single Data segment composed of the data segment 40

47 identifier characters ISA and 16 additional data elements for a total length of 114 characters. Some of these fields will be discussed below: Source and Destination Address Fields Date and Time Fields EDI Standard Field X12 Version Field Control Number Field * Acknowledgment Request Field Test Indicator Field EDI Envelope Trailer Detail The EDI Envelope Trailer is composed of two data elements. The trailer segment data elements are: Number of Included Groups Field Control Number Field * * Both the Header and Trailer use the Control Number field. The field contains a usergenerated number. The same value appears in both the header and the trailer as a way to match the beginning and end of the envelope. 41

48 Source and Destination Address Fields Both the source and destination information are composed of two data elements. The first element tells the type of address contained in the next following field. The address qualifier field, the first field, is two characters long. The address field, the second field, is fifteen characters long. Since X12 is a cross-industry EDI standard, it incorporates various existing standards into its addressing method. The sender could be identified to the X12 software by a phone number of a dial-up modem, while the receiver is identified by a Dun & Bradstreet number. See Figure #14 for an example. The contents of the address qualifier field are: X12 Addressing Methods Value Description. 01 Duns Numbers 02 Standard Carrier Alpha Code 03 Federal Maritime Commission 04 International Air Transport Association 08 UCC EDI Communications ID 09 CCITT X.121 Address 11 Drug Enforcement Administration 12 Phone Number 13 UCS Phone Number Code 14 Duns Plus Suffix 15 Petroleum Accountants Society of Canada Company Code 16 Duns Number with 4-character Suffix 17 American Banker Association Transit Routing Number NR National Retail Merchants Association 42

49 Interchange Date & Time The date is a Date Format field which is six characters long. The format is YYMMDD -- year, year, month, month, day, day. Interchange Time is a Time Format field which is four characters long. It contains the exchange time in a twenty-four hour clock using format HHMM -- hour, hour, minute, minute. X12 Version This field is five characters long and contains information on the X12 version of the interchange segment and the functional group control segment. The X12 version used for this chapter is Draft Version 3, Release 1. The encoding of the field for this version is "00301". Interchange Control Number This field is nine characters long. The number is generated by the sending party, and together with the source name uniquely identify the exchange. This field value appears in the EDI Envelope Header and Trailer Segment. It is used as a way to verify that the Header and Trailer are a pair. Acknowledgment Request This data element is one character long. The field has two possible values: "0" - Do not acknowledge the message "1" - Acknowledgment of the exchange is expected Test Indicator This data element is one character long. It has two values: "T" - Test data "P" - Production data 43

50 An X12 Encoded Data File Example The following is an encoded X12 Draft Version 3, Release 1, data stream ready for transmittal to the recipient. The data are from the purchase order described in Figure #11. Note: ISA & IEA segments compose the EDI Envelope and are, respectively, the EDI Envelope Header and Trailer. GS & GE segments compose the Functional Group Envelope and are, respectively, the Functional Group Envelope Header and Trailer. ST & SE segments compose a single transaction and are, respectively, the transaction Header and Trailer. The remaining data segments compose the purchase order data from Figure #11 and are defined in detail in the purchase order transaction tables in the X12 standards. 44

51 Detailed X12 Data Structure Example ISA*00**00**13* *16* *920703*1604*U*00301* *1*T*n/l GS*PO*123*321*927003*1203*1112*T*003010n/l ST*850*7623n/l BEG*00*FH*03551**920502*n/l PER*AC*SALLY SMITH*TE* n/l N1*BT*JOHN SMITHn/l N2*ABC CORPORATIONn/l N3*1234 EASY STREETn/l N4*GREAT*TX*98761n/l N1*ST*A&D COMPANYn/l N3*1009 STELLA n/l N4*ST. LOUIS*MO*34567n/l PO1*1*54*EA*0.99*CA*CB*123*VN*456*n/l PO1*2*1*DZ*5.49*CA*CB*321*VN*654n/l PO1*3*12*EA*14.39*CA*CB*ABC*VN*DEFn/l CTT*3n/l SE*15*7623n/l GE*1*1112n/l IEA*1* n/l Figure

52 (1) "850" means the data between the ST and the SE segments are part of a purchase order. (2) "BT" means the data in the N1, N2, N3, and N4 segments are "The Bill To Address". (3) "AC" means the following information is about the "Administrative Contact". (4) "ST" means the data in the N1, N3, and N4 segments are about the "Ship To Address". (5) These are the purchase order line items. (6) "VN" means the next field is the Vendor Catalog Item Number. (7) "920703*1604" are the date and time values. Note the data element separator is "*". The value "920703" is the purchase order date of July, 3, The value "1604" represents 4:04 p.m. -- the time the EDI Envelope was sent. (8) " " is the user-generated Interchange Control Number found in the Header and Trailer segments. (9) The value "00301" is the X12 version used in the EDI Envelope. Draft Version 3, Release 1. (10) The "13* " data is composed of the sender address qualifier and the sender address. The value "13" means " " should be interpreted as a telephone number. Note the data element separator is "*". (11) The "16* " data is composed of the receiver qualifier and the receiver address. The value "16" means the " " should be interpreted as a Dun and Bradstreet assigned address. (12) "T" in this field means all the data in this EDI Envelope is test data. Note: The data elements in the ISA data segment are all fixed length. In the example above, any spaces have been removed to shorten the field so that t h e drawing will fit on the page. 46

53 47

54 Section 3 - Electronic Funds Transfer Electronic Funds Transfer Diagram Electronic Funds Transfer (EFT) uses a series of inter-bank communication formats to transfer value between customer banks and customer accounts. An Electronic Funds Transfer is the equivalent electronic check. of a n This section briefly touches on all three information exchange methods (A), (B), and (C), with Company-A's Bank. See Figure #15 below. Section 3 EFT Diagram Company A Payment Order/ Remittance Advice VAN A Account Activity & Status B Payment Order/ Remittance Advice To Company-B's Bank Company A's Bank Corporate Trade Exchange (CTX) C Automated Clearing House System Figure 15 48

55 Definitions Automated Clearing House (ACH) Network ACH is composed of 42 regional hubs which route ACH formatted transactions between the participating financial institutions. National Automated Clearing House Association (NACHA) NACHA is the association of financial institutions that administers the ACH network. CCD CCD is an ACH format for bank-to-bank value transfer that is used primarily to consolidate cash into a central account. It does not carry remittance advice or other administrative data. This was the earliest ACH EFT format developed. CCD+ CCD+ is an ACH format for bank-to-bank value transfer that is frequently used by corporations to pay quarterly taxes and by the Federal Government in its Vendor Express electronic payment program. CCD+ has limited ability to carry administrative data bytes. It was developed to overcome the shortcomings of CCD. In 1991, 92 percent of all ACH transactions were CCD+. CTP CTP is an ACH format for bank-to-bank value transfers that has more space for administrative data -- almost 5000 records of 94 bytes each. In 1991, five percent of all ACH transactions were CTP. CTX CTX is an ACH format developed in 1987 for bank-to-bank value transfers. The CTX allows the attachment of the X12 Payment Order / Remittance Advice to the EFT transaction. During 1991, three percent of all ACH transactions used the CTX format. The growth rate of this format is over 100 percent per year. It is frequently used for the payment of company-to-company invoices on the ACH network. Fedwire Federal wire transfer is an electronic means to transfer large sums of money between banks on short notice. Unlike ACH transactions that are often periodic and require posting at least one full day before the actual debit or credit takes place, Fedwire transfers are immediate. S.W.I.F.T. S.W.I.F.T. is an international X.25/X.400 banking network used for inter-bank electronic messages. It does not carry value. Automated Clearing House Unlike EDI, which is used to communicate contractual and administrative detail about a product or service, EFT is used to transfer actual value (dollars) between customer 49

56 bank accounts and banks. EDI transactions are transmitted directly between two trading partners or through commercial Value Added Networks (VANs), while EFT transactions are only transmitted over special inter-bank networks. The most ubiquitous network is the Automated Clearing House (ACH) network. Several other financial networks exist such as New York Automated Clearing House and Fedwire. S.W.I.F.T. is another inter-bank network. It is an international electronic messaging network instead of an EFT network like the ACH network. S.W.I.F.T. is evaluating offering EDI services in addition to EFT services. So are several large banks. The focus of this section is the ACH CTX transaction. EDI and EFT transactions do not share the same networks. The Automated Clearing House (ACH) System was started in 1972 and is administered by the National Automated Clearing House Association (NACHA) under the auspices of the American Bankers Association and the Federal Reserve. NACHA has 42 clearing-house hubs which route ACH transactions among over 5000 participating institutions on a nightly basis. All ACH transactions require at least a one day turn-around period. By the end of 1992, all banks wishing to participate in ACH Electronic Funds Transfer will be on the ACH network. Currently, smaller banks may elect to communicate with an ACH through service points using paper transactions. This option will cease by the end of 1992, when they must start communicating directly to the ACH network. The NACHA is offering ACH personal computer software for smaller banks at a reasonable price. 50

57 ACH Electronic Funds Transfer Formats Several ACH EFT format choices are offered by financial institutions. The main difference in them is the amount of administrative data that can accompany the EFT payment order. Reconciling Accounts Receivable Records Using EFT Many companies pay multiple invoices with a single check. When the paper check is sent to the supplier, a list of invoices is usually attached to help the supplier reconcile its accounts receivable records with the payment. This additional information is termed remittance advice. Until the creation of the CTP and the CTX ACH formats, companies were not able to attach remittance advice to electronic checks written for multiple invoices. The suppliers found this lack of electronic remittance data troublesome in reconciling their accounts receivable records. CTX is the only ACH transaction that integrates the X12 Payment Order / Remittance Advice standard. The others use proprietary formats. ACH Electronic Funds Transfer Formats Below are the four different ACH EFT payment formats in order of development: CCD is for bank-to-bank value transfer and is used mostly to consolidate cash into a central account. CCD+ is for bank-to-bank value transfers that require limited administrative data be attached. CTP is for bank-to-bank value transfers that support additional space for administrative data. CTP offers up to 4990 records of 94 bytes each for administrative data. CTX is the bank-to-bank value transfer format that allows the attachment of the X12 Payment Order / Remittance Advice to the electronic check. The CTX is the preferred EFT format for companies paying multiple invoices with one EFT check. It is also the fastest growing of the four EFT transaction types. 51

58 EFT Description Example There are several ways for a company to initiate a credit payment to a trading partner through a bank. The company may use paper, a phone call, a direct non-edi link to the bank, or may send an X12 Payment Order/ Remittance Advice transaction to the bank using one of several EDI VANs. In the example below we will concentrate on a credit (versus a debit) transaction using the X12 Payment Order / Remittance Advice to initiate a CTX EFT transaction. (Company-A may alternately send the Payment Order / Remittance Advice directly to Company-B, bypassing Company-A's Bank. Company-B would then forward the Payment Order / Remittance Advice to Company-B's bank which would initiate a debit to Company-A's bank account.) Company-A sends through its commercial VAN an X12 Payment Order / Remittance Advice transaction to Company-A's bank requesting the bank to pay Company-B. The Payment Order / Remittance Advice details the invoices to pay, the date to pay, Company-B, Company-B's bank, and the bank account number. Company-A's bank holds the payment until the day before the payment date, when it initiates an EFT using one of several possible payment formats. The customer or bank chooses to use the CTX format because it allows the remittance advice from Company-A's electronic Payment Order / Remittance Advice transaction to be appended to the end of the CTX payment transaction. Company-B's bank receives the CTX transaction, removes the remittance advice from the CTX transaction, and updates Company-B's accounts with the amount specified in the CTX. Company-B's bank notifies Company-B of the account credit activity and forwards the remittance advice through EDI to Company-B. Company-B receives the EDI remittance advice. The Accounts Payable (AP) System reconciles Company-A's outstanding invoices with the remittance advice and the bank account activity report. Company-A has paid Company-B entirely without using paper. 52

59 ACH and EDI Service Integration ACH and EDI services are distinct offerings. ACH is offered by many banks. Over one-half of all banks are part of the ACH electronic network. By the end of 1992, almost all will be networked to the ACH EFT system. Not all banks can offer the four EFT services: CCD, CCD+, CTP, and CTX. The implementation and integration of the EFT transactions with current in-house banking systems become increasingly more complex and expensive as one progresses from the CCD to the CTX transaction format. The whole area of the EDI and EFT integration b y banks and VANs is changing rapidly. It is important to obtain current information from banks a n d communication service providers before choosing VAN or EFT services. Several EDI VANs offer a Financial Service that connects to ACH banks. Several Banks are investigating offering EDI services in conjunction with the current EFT services. 53

60 Section 4 - Bar-code Bar-code Diagram The Bar-code section focuses on two bar-code examples of over 40 types of bar-code in use today. They are UPC Bar-code for (A) Point-of-sale applications and (B) the Bar-code Interleave Code 2 of 5 for package tracking applications. See Figure #16 below. Section 4 Bar Code Diagram Point-of-Sale A Company A Company B Product Bar-code is used extensively in point-of-sale and shipping applications. Product Company A's Shipping Agent B Product Company B's Shipping Agent Figure 16 This section is a restatement of information found in Data Communication for the Office, edited by Rik Drummond and to be published by Bantam Professional Books in This section is composed of the following divisions that focus on UCC bar-code standards: Definitions Introduction 54

61 Introduction Company-specific Bar-code Applications Industry-wide Bar-code Applications Bar-codes are irrevocably tied to many EDI implementations. The Uniform Code Council (UCC) was created to administer common bar-code methodologies for the grocery and warehousing industries. Two years after the group was formed, it expanded its charter to include EDI because of the high degree of synergy in the two technologies for reducing paper usage and reducing administrative overhead. Bar-coding is a cost-effective means for putting the status of physical objects into computer information systems. It ties the physical object to its detailed computerized description data. Bar-code scanners read the bar-code on products or shipping containers and convert the bar-code symbols into an identifying numeric or an alphanumeric sequence. These sequences are keys that represent the object or a class of objects in the computer databases. EDI transactions between companies often refer to these identifying alphanumeric sequences in Purchase Orders and Advanced shipping notices. Bar-coding is used by manufacturers, wholesalers, distributors, blood banks, libraries, photo labs, grocery stores, and retail industries. There are two general applications for bar-coding (1) Company-specific and (2) Industry-wide. 55

62 Definitions Bar-code A Bar-code is a means for representing symbols (character sets) which are easily read by scanning devices. A number of bar-code symbologies represent letters, numerals, and special characters. Others represent only the numerals 0 through 9 and a few special characters. Symbology Each bar-code symbology has a character set it can represent in bar-code symbols. A certain sequence of bars and spaces represent an "A", while a different sequence represents a "B". Character Set A Character Set is a group of symbols. Some bar-codes are able to represent only numerals and a few special characters, such as the UPC bar-code. Others such as the Code 128 Bar-code are able to represent a character set of A,B,C through Z, a,b,c through z, 0,1,2 through 9, and several additional special characters. Company-specific Bar-code Applications Many companies use bar-coding internally to trace the progress of goods though the manufacturing, inventory, and loading process. Others use bar-code symbols to identify employees to automated data collection and time recording systems. These applications often use company-unique alphanumeric codes to represent the objects. The scanning of a bar-code might generate the employee number sequence "ABC1". The symbol has meaning within the organization, but has no meaning to other organizations. This is an example of a company-specific bar-code application. 56

63 Industry-wide Bar-code Applications Introduction Industry-wide naming standards are needed to identify an object in a unique manner for multiple companies and organizations in order to facilitate inventory control during transporting, warehousing, and point-of-sale activities. Several industry organizations define and maintain these object identification methods and bar-coding standards. One of the most visible is the Uniform Code Council (UCC) which is responsible for bar-code and EDI standards in the retail, mass merchandising, grocery, and warehousing industries. The familiar bar-code used at grocery checkout counters, UPC, is administered by the UCC. Industry Use Overview The following is an overview of two of over 40 bar-code symbologies in use today. The symbologies covered are: UPC-A Interleaved Code 2 of 5 Each of these bar-codes uses a different method of interpreting the bars and spaces to represent characters in the character set. An example character set would be the upper a n d lower case English alphabet, A through Z, a through z, the numerals 0 through 9 and the special characters!,@,#,$,%,^,&,*,(,), and +. Another character set might be composed of only the characters 0 through 9. 57

64 Bar-code Symbols In some bar-code methodologies, the position and number of bars represent characters. Spaces have no meaning. In others, the width of the bars and the width of the spaces have meaning; both are used to represent characters in the character set. Because of the coding of the bars and spaces, some bar-codes are more sensitive to the type of material on which they are printed and work better for some applications than others. Some bar-codes require more space to represent information than other bar-codes. A bar-code represents symbols (character sets) which are easily read by scanning devices. Each bar-code symbology has a character set it represents in barcode symbols. A number of bar-code symbologies represent letters, numerals and special characters. Others represent only the numerals 0 through 9 and a few special characters. Universal Product Code - UPC One of the most common and most visible bar-codes is the Universal Product Code (UPC) used in the retail, grocery and the mass merchandising markets. A large number of grocery chains, warehouses, and suppliers in the early 1970s formed the Uniform Code Council (UCC) to administer and promote the use of a common bar-coding methodology throughout the grocery industry. The Universal Product Code Barcode (UPC), which is visible on most consumer products today, was first introduced by the UCC in Its numbering system uniquely identifies each product in the grocery industry. It has been expanded since then to encompass the retail and mass merchandising industries. UPC-A Bar-code The UPC-A (Universal Product Code - Version A) is the primary way to identify consumer products to point-of-sale bar-code scanners in the United States. The UPC-A is a bar-code symbology composed of three groups of numbers: a single digit, followed by five digits, ending with five digits. A single digit checksum follows the first 11 digits. The checksum is used to identify errors in the first 11 digits. 58

65 UPC Bar-code Example Start Character Stop Character Item Number Checksum Manufacturer ID Number (Includes Numbering System) Numbering System Figure 17 In the example above, the single digit "0" is a number representing the number system used for the next five-digit field, contents "12345". When the first digit is 0, the next five digits are interpreted as the unique "UCC Manufacturer ID Number" assigned by the UCC to each registered product manufacturer. The next field, "67890", is used by the registered manufacturer to identify each of its products. The last number is the checksum. All bar-codes have a start character and a stop character so that they may be scanned in either direction without losing the start of the string. The first digit position on the left, "0", in this case, tells what "numbering system" will be used to interpret the next five digits. 59

66 The Numbering Systems values are: Value Description. 0 assigned to all items except as follows: 2 assigned to items sold by unit of measure 3 assigned to companies which have a national Drug Code Number as their UPC Manufacturing ID Number 4 assigned for retailers' use only (closed systems) 5 assigned to coupons 6 assigned to retail products 7 assigned to retail products In Figure #17, "67890" might represent a pair of black pants, size 38 long, type full cut, manufactured by company "12345" under numbering system 0. 60

67 Bar-code Interleave 2 of 5 In the retail, grocery, and mass merchandising environments, Bar-code Interleave 2 of 5 is frequently used to mark shipping containers using one of two UPC Shipping Container Codes. One is used for packaged contents and one is used for products sold by unit-of-measure such as kilos or square yards. The example below is the former. Interleave 2 of 5 is used in shipping container applications because, unlike many bar-code symbologies, it is relatively insensitive to scan errors when printed on corrugated boxes. Note how the same numbering system and Manufacturer ID Number are used as in the UPC Bar-code. Interleave 2 of 5 Shipping Carton Example Item # Manufacturer ID Number Numbering System Package Indicator Figure 18 61

68

69 Appendix A - ASC X12 Organization ASC X12 Organization Structure X12 Membership X12 Chair DISA Secretariat Steering Committee Procedures Review Board Legal Pan American EDIFACT Board Version / Release Conference & Exhibits Planning Operations & Procedures X12/EDIFACT Alignment Subcommittees X12C - Communications & Control X12D - Education & Implementation X12E - Product Data X12F - Finance X12G - Government X12H - Materials Management X12I - Transportation X12J - Technical Assessment X12K - Purchasing X12L - Industry Standards Transition X12M - Distribution & Warehousing X12N - Insurance Figure 19 The X12 Accredited Standards Committee is under the auspices of the American National Standards Institute (ANSI), a Federal Government organization. Once a transaction is approved by the X12 organization it goes through a three year national review under the ANSI review procedures. X12 does not approve EDI standards for the United States. The X12 membership approves Draft Standards for Trial Use (DSTU). After the Standards pass the rigors of the internal X12 process they are submitted to ANSI for the ANSI approval process. Once a transaction passes the X12 DSTU stage it is highly likely that the transaction is firm. Most leading EDI companies will use the new standards as needed. 1

70 Information on the procedures to join ASC X12 and submit requests for changes on X12 transaction sets may be obtained from ASC X12 by contacting: ASC X12 Secretariat 1800 Diagonal Road, Suite 355 Alexandria, VA

71 Appendix B - X12 Transaction List The following ASC X12 Draft Version 3, Release 2, Standards were approved for trial use in December CODE TRANSACTION SET NAME. 104 AIR SHIPMENT INFORMATION 110 AIR FREIGHT DETAILS AND INVOICE 114 AIR SHIPMENT STATUS MESSAGE 170 REVENUE RECEIPTS STATEMENT 204 MOTOR CARRIER SHIPMENT INFORMATION 210 MOTOR CARRIER FREIGHT DETAILS AND INVOICE 213 MOTOR CARRIER SHIPMENT STATUS INQUIRY 214 MOTOR CARRIER SHIPMENT STATUS MESSAGE 217 MOTOR CARRIER LOADING AND ROUTE GUIDE 218 MOTOR CARRIER TARIFF INFORMATION 300 RESERVATION (BOOKING REQUEST) (OCEAN) 301 CONFIRMATION (OCEAN) 303 BOOKING CANCELLATION (OCEAN) 304 SHIPPING INSTRUCTIONS (OCEAN) 309 U.S. CUSTOMS MANIFEST (OCEAN) 310 FREIGHT DETAILS AND INVOICE (OCEAN) 312 ARRIVAL NOTICE (OCEAN) 313 SHIPMENT STATUS INQUIRY (OCEAN) 315 STATUS DETAILS (OCEAN) 322 TERMINAL OPERATIONS ACTIVITY (OCEAN) 323 VESSEL SCHEDULE AND ITINERARY (OCEAN) 324 VESSEL STOW PLAN (OCEAN) 350 U.S. CUSTOMS RELEASE INFORMATION (OCEAN) 353 U.S. CUSTOMS MASTER IN-BOND ARRIVAL (OCEANS) 354 U.S. CUSTOMS AUTOMATED MANIFEST ARCHIVE STATUS (OCEAN) 361 CARRIER INTERCHANGE AGREEMENT (OCEAN) 404 RAIL CARRIER SHIPMENT INFORMATION 410 RAIL CARRIER FREIGHT DETAILS AND INVOICE 414 RAIL CARHIRE SETTLEMENTS 3

72 417 RAIL CARRIER WAYBILL INTERCHANGE 418 RAIL ADVANCE INTERCHANGE CONSIST 426 RAIL REVENUE WAYBILL 429 RAILROAD RETIREMENT ACTIVITY 431 RAILROAD STATION MASTER FILE 466 RATE REQUEST 468 RATE DOCKET JOURNAL LOG 485 RATEMAKING ACTIONS 490 RATE GROUP DEFINITION 492 MISCELLANEOUS RATES 494 SCALE RATE TABLE 810 INVOICE 811 CONSOLIDATED SERVICE INVOICE/STATEMENT 812 CREDIT/DEBIT ADJUSTMENT 815 SECURITY STRUCTURE 819 OPERATING EXPENSE STATEMENT 820 PAYMENT ORDER/REMITTANCE ADVICE 821 FINANCIAL TRANSACTION REPORT 822 CUSTOMER ACCOUNT ANALYSIS 823 LOCKBOX 824 APPLICATION ADVICE 826 TAX INFORMATION REPORTING 827 FINANCIAL RETURN NOTICE 829 PAYMENT CANCELLATION REQUEST 830 PLANNING SCHEDULE WITH RELEASE CAPABILITY 832 PRICE/SALES CATALOG 835 HEALTH CARE CLAIM PAYMENT/ADVICE 836 CONTRACT AWARD 838 TRADING PARTNER PROFILE 840 REQUEST FOR QUOTATION 841 SPECIFICATION/TECHNICAL INFORMATION 842 NON CONFORMANCE INFORMATION 843 RESPONSE TO REQUEST FOR QUOTATION 844 PRODUCT TRANSFER ACCOUNT ADJUSTMENT 4

73 845 PRICE AUTHORIZATION 846 INVENTORY INQUIRY/ADVICE 848 MATERIAL SAFETY DATA SHEET 849 RESPONSE TO PRODUCT TRANSFER ACCOUNT ADJUSTMENT 850 PURCHASE ORDER 851 LEASE SCHEDULE 852 PRODUCT ACTIVITY DATA 855 PURCHASE ORDER ACKNOWLEDGMENT 856 SHIP NOTICE/MANIFEST 857 SHIPMENT AND BILLING NOTICE 858 SHIPMENT INFORMATION 859 FREIGHT INVOICE 860 PURCHASE ORDER CHANGE - BUYER INITIATED 861 RECEIVING ADVICE/ACCEPTANCE CERTIFICATE 862 SHIPPING SCHEDULE 863 REPORT OF TEST RESULTS 864 TEST DOCUMENT 865 PO CHANGE ACKNOWLEDGMENT 866 PRODUCT SEQUENCE 867 PRODUCT TRANSFER AND RESALE REPORT 868 ELECTRONIC FORM STRUCTURE 869 ORDER STATUS INQUIRY 870 ORDER STATUS REPORT 872 RESIDENTIAL MORTGAGE INSURANCE APPLICATION 878 PRODUCT AUTHORIZATION/DE AUTHORIZATION 879 PRICE CHANGE 888 ITEM MAINTENANCE 889 PROMOTION ANNOUNCEMENT 894 DELIVERY/RETURN BASE RECORD 895 DELIVERY/RETURN ACKNOWLEDGMENT AND/OR ADJUSTMENT 896 PRODUCT DIMENSION MAINTENANCE 940 WAREHOUSE STOCK RECEIPT ADVICE 945 WAREHOUSE SHIPPING ADVICE 947 WAREHOUSE INVENTORY ADJUSTMENT ADVICE 5

74 980 FUNCTIONAL GROUP TOTALS 990 RESPONSE TO A LOAD TENDER 996 FILE TRANSFER 997 FUNCTIONAL ACKNOWLEDGMENT 6

75 Appendix C - Value Added Network Vendors Some companies which offer Value Added Network services are: AT&T British Telecom General Electric Harbinger IBM Kleinschmidt, Inc MCI International MEMA/Transnet Railinc AT&T Easylink Services Interpace Parkway Parsippany, NJ EDI*Net 2560 North First Street P.O San Jose, CA GE Information Services Washington Street Rockville, MD Harbinger Century Place Atlanta, GA IBM Corporation Box Tampa, FL Kleinschmidt Lake Cook Road Deerfield, IL MCI International 19th Street, N.W. Suite 500, Washington, DC MEMA/Transnet Box 1638 Englewood Cliffs, NJ Railinc F Street Washington, DC

76 Sears Sears Communications Company Martingale Road Schaumburg, IL Sprint International Sprint International Sunrise Valley Drive Reston, VA Sterling Software Telecom Canada Transettlements Ordernet Services Box 7160 Lake Hurst Court Dublin, OH Telecom Canada Elgin Street Ottawa, Ont. K1G 3J4 Transettlements Phoenix Blvd. Atlanta, GA

77 Glossary ACH ASC X12 AIA AIAG AIM AISI ANA ANS ANSI APA API ASCII ASN Asynchronous ATA BAI BAI Format Bar-code BDI Bisync Automated Clearing House Accredited Standards Committee for inter-industry electronic data interchange standards Aerospace Industries Association Automotive Industry Action Group Automated Identification Manufactures American Iron And Steel Institute Article Number Association American National Standards American National Standards Institute American Payroll Association American Petroleum Institute American Standard Code for Information Interchange. Seven bit standard encoding scheme for most computers. The letter 'A' equals while a lower case 'a' would equal in binary. Advanced Shipping Notice Transmission of data where each character is self-contained with its own start and stop bits. The common method of transmitting data at lower speeds between a computer and a modem. It is also known as Asynch. American Transport Association Bank Administration Institute EFT remittance data for a customer's lockbox. An array of rectangular bars and spaces that are arranged in a predetermined pattern following unambiguous rules to represent elements of data that are referred to as characters. Business Data Interchange is the real name for the X12 EDI standards. Binary Synchronous Communications Protocol. 9

78 Bisynchronous BPS BSC BSC 3270 BYTE CALS CCD CCD+ CCITT CEC CEF CEFIC CIDX CISCO A major category of communications protocol used in mainframe networks. It requires that both the sending and receiving devices are synchronized using a common clock before and after data transmission. Also known as Bisync. Bit Per Second Binary Synchronous Communications Interactive Binary Synchronous Communications Eight (8) bits. A single character and a byte are often synonymous. Computer-Aided Acquisitions and Logistics Support Cash Concentration And Disbursement. An EFT format, with very limited remittance data Cash Concentration and Disbursement Plus. An EFT format, with limited remittance data. Comite Consultatif International Telephonique Et Telegraphique (International Telephone and Telegraph Consultative Committee). The international standards board for telecommunications hardware and protocols. Commission for the European Community Commission For The European Chemical Manufactures Association European Chemical Industry Chemical Industry Data Exchange. Corporate Information Standard Coordinating Committee - GM EDI CODABAR A variable length bar-code symbology which can represent 10 numerals and 6 special characters CODE Alpha-numeric or numeric only characters representing a specific standard text. CODE 39 A bar-code which can represent 43 different characters, 0 through 9, a through z, and seven special characters. CODE 128 A bar-code, variable in length, which can represent all 128 ASCII characters. COMM ID Communication Protocols COMPORD The participant EDI identification sold by the UCC Standard rules for how to encode information for transmission between locations. Proprietary Standard For The Steel Industry 10

79 COS CTP CTX Data Element Data Element Attribute Data Element Dictionary Data Element Name Data Element Representation Data Element Separator Data Element Tag Data Item Data Segment Data Segment Dictionary DEA DES DEX/UCS DISA DOD DSD/USC DSS DSTU DUNS EAGLE Corporation For Open Systems Corporate Trade Payment - An EFT format with remittance data. Corporate Trade Exchange - An EFT ANSI X12 format. The smallest named unit of information in the X12 standard. A defined characteristic of a data element. The document that specifies the numbers, names, and definitions of data elements. A unique name of the data element. The format of a data item, including characteristics: numeric, alphabetic variable or fixed length. A special character, used for no other reason in the X12 exchange, which designates the beginning of the next data element. A unique identification frame for a data element. Content of a data element. X12 segment composed of an ordered sequence of data elements. The segment contains application data. The document that specifies the codes, names, and definitions of data segments. Drug Enforcement Agency Data Encryption Standard Form of direct store delivery. Exchange between route drivers and back door receivers. Administered by UCC. Data Interchange Standards Association. The secretariat for the Accredited Standards Committee X12. Department Of Defense. Direct Store Delivery. Administered By UCC. Digital Signature Standards ASC X12 Standard Approval Level - Draft Standard For Trial Use. The Address Number Assigned By Dun & Bradstreet. Standard used by the wholesalers and manufactures in the hardware & houseware industry. 11

80 EAN EANCOM EBCDIC EBDI EDGAR EDI EDIA (TDCC) EDICC EDIFACT EDIFICE EDN EDX EFT EIA EIAJ EIDX ERS FACT FIPS Functional Group European Article Numbering or International Article Number corresponds to the UPC in the United States. European Article Numbering Committee. Extended Binary Coded Decimal Interchange Code. Eight bit coding standard used by IBM mainframe and compatible systems. Similar to the ASCII standard. Electronic Business Data Interchange is a term for EDI Electronic Data Gathering Analysis & Retrieval Electronic Data Interchange Electronic Data Interchange Association Electronic Data Interchange Council Of Canada EDI For Administrative, Commerce, And Trade EDI For Companies Interested In Computing And Electronics Enterprise Defined Network Electronic Data Interchange For The Electrical Industry Electronic Funds Transfer Electronic Industry Association Electronics Industry Association Of Japan Electronics Industry Data Exchange. The Communication Standard subset for ASC X12. Evaluated Receipts Settlement. This concept replaces the invoice in a transaction by using the electronic advance shipping notice. Federation Of Automated Coding Technologies Federal Information Processing Standards An ANSII ASC X12 and EDIFACT standards term used to identify one or more messages of the same type headed by a functional group header and ended with a functional group trailer. A functional group begins with a GS group header segment and ends with a GE trailer segment. GMAIC General Merchandise And Apparel Implementation Committee - Bar-coding. 12

81 GOSIP Guideline HIBCC Interleave 2 Of 5 ISO Item Code Number IVAN JIT LIC LOGMARS MAC Mail Bag Ta3 Mailbox Manufacturer ID Number Mapping NACHA NEX/UCS NIST NRMA Government OSI Protocol. ISO network management specification developed under some twenty government agencies which have pooled networking needs under one standard. Developed as part of a series of ongoing NIST Workshops for the implementers of Open Systems Interconnections. Recommended set of procedures used within EDI. Health Industry Business Communications Council -EDI Technical Committee. Bar-code standard used to mark the outer shipping cases in many industries. International Standards Organization. Based in Geneva, Switzerland, and comprised of national standards bodies from more than 75 countries, the ISO has defined a number of important standards, including OSI. The third field in the UPC. A five digit code assigned to the product by the member company. International Value Added Network Just-In-Time Label Identification Codes are an HIBC standard administered by the HIBC council. An Acronym for The DOD Project on Logistics Applications of Automated Marking and Reading Symbols. Message Authentication Code A New X12 Standard for Exchanging EDI Packets Between Parties Storage area in a VAN holding transmissions for users. Transmissions may be retrieved by the user. The second field in the UPC. A unique 6 digit number assigned by the UCC for each member of the Uniform Code Council. Integrating the EDI translator with the in-house application in a seamless manner. National Automated Clearing House Association Form of direct store delivery. Exchange between offices. Administered by UCC. National Institute Of Standards And Technology National Retail Merchant's Association 13

82 Number System Character ODETTE ORDERNET/NWDA OSI PADIS PIDX PKCS POS Quick Response RFI RFP RFQ RJE RS232 S.W.I.F.T. SDLC Segment Segment Directory Segment Identifier Segment Name Segment Terminator SMC The first digit in the UPC. The first position is a number system digit in the range of "0" to "7". "0" - is normally used. Organization Of Data Exchange By Tele-Transmission In Europe. The European AIAG. Standard For The Pharmaceutical Industry Open System Interconnect. Defined by the ISO, OSI describes a seven layer model for network communications. The top layer consists of end-user applications. The bottom layer is the physical connection (or wire) between network nodes. Passenger and Airport Data Interchange Standards board is responsible for the development and maintenance of all passenger and airport services' EDIFACT messages. Petroleum Industry Data Exchange Public Key Cryptosystem Point-Of-Sale Retail industry EDI endeavor focusing on responding very quickly to customer needs in sizes, colors, products and styles. Request For Information Request For Proposal Request For Quote Remote Job Entry A recommended standard for serial communications. It is an OSI data link layer standard. International Banking Network. Originated In Europe. Synchronous Data Link Control A group of logically related and sequentially positioned data elements, starting with a segment code and ending with a segment terminator. The document describing all the attributes of all data elements. A unique X12 two or three character identifier for the segment. The identifier is the label identifying the start of the segment in a transaction. The name or tag identifying a segment. A special character, used for no other reason in the X12 exchange, which designates the end of a segment. Standard Maintenance Committee Of UCC 14

83 SMTP SNA SNA 3270 SNADS SWIFT Syntax Rules TALC TCIF TCP/IP TDCC (EDIA) TDI TMA TRADACOMS Trading Partner Transaction Set UCC UCC UCC 4A Simple Mail Transport Protocol. Developed by the Department of Defense (DoD), SMTP is a simple mail protocol used with Internet and other TCP/IP or Unix based network environments. System Network Architecture. A networking protocol developed by IBM in Originally a strictly hierarchical control structure, it is now being expanded to a peer-to-peer control structure with appc SNA Interactive Communications SNA Distribution Services International Banking Network. Originated In Europe. Standards language. The rules that govern the structure of user data and associated data in message interchanging. Textile And Apparel Linkage Council Telecommunications Industry Forum. The communication standard subset for ASC X12. Transmission Control Protocol/Internet Protocol. The U.S. Government Standard for Wide-Area Networking, TCP/IP is used to connect Government Agencies and Universities. It makes possible the Interconnection of a variety of hardware platforms. TCP/IP may eventually be replaced by OSI. Transportation Data Coordinating Committee. Name Changed to EDIA. Trade Data Interchange Of Britain. Basis For EDIFACT The Treasury Management Association A Multi-Industry Organization in Great Britain An EDI user who another EDI user has agreed to exchange business data electronically. Partners include customers, distributors, suppliers, services providers, etc. Business document transmitted electronically. Formatted into an accepted standard made up of a header segment followed by segment sections and closed with a summary section. Each segment contains at least one field of particular information such as part number, date, etc. Uniform Code Council Uniform Commercial Code Uniform Commercial Code Statute that defines the responsibilities of banks and payer companies in the electronic payment process. 15

84 UCS UIC UN/EDIFACT UN/JEDI UPC UPS VAN VDA VICS WINS WP.4 WSA Uniform Communications Standard - Grocery And Retail Industry. Administered by Uniform Code Council. Uniform Industrial Code. The UIC is a Non-Retail Application of the UPC. Same As EDIFACT United Nations Joint Electronic Data Interchange Committee Universal Product Code - a bar-code standard used in the retail and grocery industries for products. Universal Product Code. A Bar-Code Standard. Value Added Network European Automotive Industry EDI Group - mostly in Germany. Voluntary Inter-Industry Communications Standards Organization. Administer by Uniform Code Council Warehouse Information Network Standard Working Party Number 4 For UN/ECE. Wholesale Stationers Association X.25 The CCITT protocol standard for connecting to packet switched networks. Typically used to connect wide-area networks through ADMDS. X.400 messaging is typically provided using X.25 gateways although X.400 may also be transmitted over other protocols such as TCP/IP and Internet. OSI network layer (layer 3) transmission protocol. X.400 A series of CCITT standards defining standards for message handling systems. X12 XMODEM YMODEM ANSI standard for inter-industry electronic interchange of business transactions. A Personal Computer File Transfer Protocol. A PC File Transfer Protocol with support for multi-concurrent data streams. 16

85 Bibliographies Accredit Standards Committee X Electronic Data Interchange - X12 Draft Version 3 Release 1 Standards Accredit Standard Committee X12, Alexandria VA Baker, Richard H EDI - What Managers Need to know About the Revolution in Business Communications TAB Professional and Reference Books, Blue Ridge Summit, PA Digital Equipment Corporation Electronic Data Interchange - Executive Summary Digital Equipment Corporation, Maynard MA Drummond 2nd, Richard V. ed Data Communications in the Office Bantam Professional Books, New York, New York. Emmelhainz, Margaret A Electronic Data Interchange - A Total Management Guide Van Nostrand Reinhold, New York NACHA, Financial EDI: State of the Industry National Automated Clearing House Association, Herndon Va. Sokol, Phyllis K EDI - The Competitive Edge McGraw-Hill, New York 17