Electronic Data Interchange

ELECTRONIC DATA INTERCHANGE
CHAPTER 1 INTRODUCTION
Prosperity, and even survival, for small businesses depends as never before on the ability to respond with speed and certainty to the challenges and opportunities that are presented by competitors and customers. Electronic Commerce provides an opportunity to increase competitive edge and consolidate and enhance both business to business and business to consumer trading relationships. In the current competitive & fast moving world of E-commerce & Electronic data transfer , comes a highly relevant , yet , under-utilized system of data exchange the Electronic Data Interchange , or the EDI. For several hundred years, commerce has been based upon the movement of written documents. These documents contained the information that one company needed to convey to another company in order to do business. Over a period of time the documents started to take on standard names such as Invoice, Credit Note and Order. However, the documents were certainly not of any standard layout. They did not need to be because the recipient was always a human being and humans have the ability to read, interpret and rationalize. About all that could be said of an invoice document, for example, was that it would contain header information about the parties involved, detail lines about the products, quantities and prices, and finally some totaling information. In the early 1950s, computers started to be used by large companies for their accounting and payroll needs. Throughout the following decades, computers rapidly took over task after task until they were involved not only in accounting, but in production, administration and all other areas of commerce. But one thing did not change. The computers still produced printed documents in various non-standard formats. This situation was not too bad for those sending a document but was much worse for the receiver. Many documents must be sent from one companys computer to their trading partners computer. Computers cannot easily read written documents, and getting them to understand what they have just read is an almost impossible task,
SRTIST, ECE 1
so the receiving company would have to employ personnel to re-key the information from the received documents into the companys computer system. In 1996, the National Institute of Standards and Technology defined electronic data interchange as "the computer-to-computer interchange of strictly formatted messages that represent documents other than monetary instruments. EDI implies a sequence of messages between two parties, either of whom may serve as originator or recipient. The formatted data representing the documents may be transmitted from originator to recipient via telecommunications or physically transported on electronic storage media." It distinguishes mere electronic communication or data exchange, specifying that "in EDI, the usual processing of received messages is by computer only. Human intervention in the processing of a received message is typically intended only for error conditions, for quality review, and for special situations. For example, the transmission of binary or textual data is not EDI as defined here unless the data are treated as one or more data elements of an EDI message and are not normally intended for human interpretation as part of online data processing."
SRTIST, ECE
CHAPTER 2 ELECTRONIC DATA INTERCHANGE

Electronic data interchange (EDI) is the structured transmission of data between organizations by electronic means, which is used to transfer electronic documents or business data from one computer system to another computer system, i.e. from one trading partner to another trading partner without human intervention.[1] It is more than mere e-mail; for instance, organizations might replace bills of lading and even cheques with appropriate EDI messages. It also refers specifically to a family of standards.
2.1 Working
EDI is simple to set up. All the Trading Partner needs to send or receive electronic transactions are the following equipment and software capabilities A mainframe, mid-tier, or personal computer. Translation software to format their business data into the American National Standards Institute (ANSI) X12 standard format for transmission interpretation. Third party service provider for processing their data if they do not have the hardware or software.
2.2 Urgency Issues

The time factor was also a problem. The company sending the document had printed it in a few seconds. It was placed in an envelope and then posted. The document would probably take several days to reach the final destination (always with the possibility of accidental loss) where the envelope would be removed and the document presented for keying in to another computer. For a long time, managers had been thinking how good it would be to have Just in Time production techniques, where a supply lorry would be able to arrive at the production line gates just in time to be unloaded and its contents taken directly to where they were needed on the production line. They dreamed of an end to costly warehousing and stock control. But these methods were impossible while the trading partners were still using the post. Lorries would be arriving at the wrong times, or not
SRTIST, ECE 3
at all, causing the production lines to stop and chaos to reign, all because of the delay in the information flow.
2.3 Communications
Part of the answer to these problems was computer communications and the need to make one trading partners computer talk to another. Communications have been in existence since the early days of computers. A file can be transmitted from one computer to another, either over a normal telephone line or over a Leased Line that is continuously in use and dedicated to computer communications. Many commercial products exist that can move files in this way. Communications did not solve the whole problem though. Once a file is received it needs to be understood by the receiving computer. Items of information must be in the exact place that the computer is expecting them. If just a single character is out of place, the whole file will become uninterruptable by the computer. In the early days of communications, trading partners had to spend a great deal of time agreeing exactly where each item of information would be stored in the files that were transmitted. These agreements were only active for one trading partner. Start trading with another partner and the requirements would change slightly, a larger product code would perhaps be needed, or a different method of pricing, but the whole negotiation and agreement process had to take place all over again. It kept the programmers busy but did little for the company profits.
2.4 Move to Standardized EDI

The solution was EDI, Electronic Data Interchange, a standard method of transferring commercial information between computers.
2.4.1 The Message

EDI (Electronic Data Interchange) files contain information, in one of many possible formats, pertaining to commercial documents. For example, a paper invoice will always contain certain information whatever the company or country of origin. It will contain the originating and receiving companys information such as addresses, telephone numbers, contacts, etc. It will then have a section where the items to be invoiced are laid out in a formatted manner, with prices and quantities, and finally it
SRTIST, ECE 4
will have a totals section. All this information may be contained within an EDI file of a pre-defined format, so that whoever receives the file will be able to understand it and automatically pass this information into their own in-house systems, irrespective of the type of computer or the systems that they are running.
2.4.2 The Standards Bodies

A number of different standards bodies were created to define both methods of communications and the layout of standard trading documents, so that simple and cost effective electronic trading could take place. The main document standards with which we will be concerned are EDIFACT, Tradacoms and ANSI X12, but before going into detail about the standards themselves, here is a short background to the development of the UK documents standards bodies. The earliest development of standards, usually for particular sectors of industry, was carried out in the late 1970s under the auspices of the EAN. EAN is the International Article Numbering Organization dealing with EDI standards. It acts as an umbrella group for the various national Numbering Organizations. In 1998, as a result of the merger of the Article Number Association (ANA) and the Electronic Commerce Association, the e.centre UK was launched as the EAN Numbering Organization for the UK. More recently, in February 2005, the e.centre UK has become GS1 UK. This is in line with the global re-launch of EAN International as GS1. The first UK message standards were published by the ANA in 1982, having been tested and developed since 1979. Over 90% of all UK trade EDI takes place using standards from the ANA, whose members include representatives from manufacturing, distribution, wholesaling, service and retail organizations. The ANA standards use the two key syntaxes: UN/GTDI (General Trade Data Interchange), which forms the basis for TRADACOMS messages; UN/EDIFACT (EDI for Administration Commerce and Transport), which is the basis for EANCOM and UK EDIFACT messages.
SRTIST, ECE
2.5 Mapping Data to EDI Transaction Formats

To exchange information using EDI, data must be translated into a format that complies with an EDI standard. Mapping is the initial process that describes how each piece of the original data, such as an invoice relates to the EDI transaction standard being used. The transaction software uses this mapping process to translate the EDI transactions so they can be used by the receiving Trading Partner. Entergys currently uses 4010 version.
2.6 Adjuncts
EDI creates a system whereby companies, governments, and entities that work on different computer systems to exchange information efficiently. EDI is a standardized format of relevant data which can be transmitted from one computer system to another with minimal human intervention. It is widely used and industry to transmit what would have formerly been sent as a document, through the post. By utilizing EDI, the communication partners are able to send a range of documents electronically, which provides and increased efficiency rate as well as reduced paper expenditure. There are currently hundreds of documents that can be exchanged electronically between multiple trading partners. The Internet has allowed for an increased flow of these exchanges, rather than those allowed through closed computer systems. EDI is a popular and efficient way to send and receive documents that would otherwise be spending wasted days on the road in the back of a delivery van. However, there is Value Added Network (VAN) used in this situation, and it is similar to a post office. It is a middle man warehouse where EDI documents can be storage until the receiver is ready for them. This ensures that important documents do not bounce back to the sender, or get lost in the tray. Although VAN is used by many companies, and in particular the healthcare industry, many EDIs are being sent over the internet. However, as VANs provide a myriad of other services such as retransmission of the document, provision of third party audit information, and acting as a gateway for different transmission methods, handling telecommunications support etc., they are quite popular within vicarious industries. Increasingly, EDI documents are being embedded into other transmission vehicles such as XML, which is being seen as one way to reduce costs. Although EDI
SRTIST, ECE 6
originated in its current form in the United States, its origins can be seen throughout international co-operative operations which require standardized manifests and instructions.
SRTIST, ECE
CHAPTER 3 EDI MODEL

There are three logical levels or layers of standards required to achieve EDI information transfer, each layer having its own controlling standards organizations (although some organizations may define more than one layer). This structured approach to EDI allows for the maximum flexibility. And also enables future developments in technology and standards to be easily incorporated.
Figure 3.1 Layers in EDI model

From the lowest layer upward, these three layers are: The Communications Standards - Defining just how the data is to be transferred from the sender to the receiver. The Syntax Standards - Defining what overall standards format the EDI file will be in. The Message Standards - Defining exactly what the message is and what information is to be placed where within this message. These standards are going to be further described in the following sections but it is important to remember that whatever standards are used within each layer, the layering process is required to allow flexibility. For example not all users will wish to
SRTIST, ECE 8
use a specific communication protocol; some may even wish to copy the data onto a floppy disk and send it in the post! So the communications level is now a floppy disk but the higher levels still remain. This principle of multiple methods of achieving the same goal is found over and over again within the EDI regime. It is not an attempt at duplication but is designed to give users the best possible solution and flexibility in all cases.
3.1 VDA Standard

It should be noted that VDA messages are treated as non-EDI files by most members of the ODEX family. This is because VDA messages are not true EDI messages. VDA stands for Verband der Automobilindustie (Motor Industry Association). The VDA is a German automotive standards body which issues the VDA standard documents. VDA messages are not strictly EDI messages as they are simply flat files. Instead of using special characters to divide each segment from the next and each data element from the next, a VDA message consists of fixed length records within which each data element (field) is allowed to take up a specific number of characters. If any item of data is omitted, its absence must be shown by a space the same length as the omitted item of data. Furthermore, VDA messages do not contain service segments, so there is no concept of interchange or group. However, the first record in a VDA message does contain addressing information of a kind and can therefore be used by an intelligent program such as ODEX Enterprise or DARWIN for routing purposes. There are enough similarities between VDA messages and true EDI messages to allow VDA messages to be treated by some programs as EDI. VDA messages have a hierarchical structure, meaning that records within a message must adhere to certain rules about the position in which they may appear. VDA records, like EDI segments, also have attributes such as a name, a maximum number of times they may occur and whether their occurrence is mandatory or conditional. Owing to the differences that exist between the VDA standard and real EDI standards, VDA messages are usually treated as non-EDI files. However, ODEX Enterprise and DARWIN 3 have been programmed to recognize VDA messages and to treat them as if they were real EDI messages.
SRTIST, ECE 9
3.2 EDI in Action

Let's take a high level look at the EDI process. In a typical example, a car manufacturing company is a trading partner with an insurance company. The human resources department at the car manufacturing company has a new employee who needs to be enrolled in an insurance plan. The HR representative enters the individual into the computer. The new employee's data is mapped into a standard format and sent electronically to the insurance company. The insurance company maps the data out of the standard format and into a format that is usable with their computer. An acknowledgment is automatically generated by the insurance company and sent to the car manufacturer informing them that the data was received. Hence, in order to summarize the EDI process, the sequences of events in any EDI transaction are as follows The sender s own business application system assembles the data to be transmitted . This data is translated into an EDI standard format (i.e., transaction set) The transaction set is transmitted either through a third party network or directly to the receiver's EDI translation system. The transaction set, in EDI standard format, is translated into files that are usable by the receiver's business application system. The files are processed using the receiver's business application system.
3.3 EDI Features

Independent of trading partners' internal computerized application systems. Interfaces with internal application systems rather than being integrated with them. Not limited by differences in computer or communications equipment of trading companies. Consists only of business data, not verbiage or free-form messages.
SRTIST, ECE
10
CHAPTER 4 SYNTAX STANDARDS

The middle level in our three layer EDI model is the Syntax Standard to be used. Taking the analogy of a telephone call, it is no use if the call is connected but the remote party does not speak the same language as the caller; a few minutes will be lost whilst each side tries to understand the other but no meaningful information may be exchanged. To avoid this problem, three main syntax standards are used for EDI. These are the American ANSI X12 standard, the European EDIFACT standard and an older European standard still very popular in some sectors such as the retail industry, UNGTDI (United Nations Guidelines for Trade Data Interchange). There is also the VDA syntax standard, used in Germany. Although not strictly EDI, VDA messages have been included under the EDI umbrella. With the exception of VDA, no matter what standard is used, the same EDI terms and concepts apply. Let us now look at these terms and what they mean in more detail. An EDI Message may be split up into a number of logical units. The message is itself a single document such as an invoice or an order, and is made up of a number of Segments. Each segment contains complete information about a part of the document. For example two segments that will be required in an invoice message are the buyers and sellers details. Segments can themselves be split down into Data Elements. Data elements hold the actual information. Simple data elements hold only one item of information, such as a name or a value. Composite data elements hold one or more Sub-Elements of closely associated information such as the lines of an address.
Figure 4.1 Messaging between two trading partners

SRTIST, ECE 11
EDI messages between two trading partners may be grouped together into an interchange. The interchange may contain messages of varying types, the only common factor being the sending and receiving parties. All EDI files must contain at least one interchange; this ensures that the interchange can be routed to the correct destination. Messages of the same type can be held together in a group. The functional group is not a very widely used vehicle, most partners considering that as the interchange is the main routing method and may contain many messages, then the group is somewhat superfluous. Different standards call the group different names. The group itself is an EDIFACT term, UNGTDI standards know it as a batch and ANSI X12 standards as a document. ANSI X12 also calls the message a transaction.
4.1 Service Segments

Interchanges, groups and messages are identified in an EDI file by special segments known as service segments. Service segments contain the information necessary to route the interchange towards its final destination, to identify the contents of the interchange, its date and time of production, standards used and much more. Remember that the interchange may be passing through several different routing agencies, just as a letter is passed to and through the post office before reaching its final destination. EDI is not always a point-to-point matter. The service segments act in the same way as the envelope and enclosed document headings used in paper correspondence. Service segments enclose a block of segments that they are defining. In other words there will be service segments both at the start and end of each interchange, group and message. The service segments names are different for each syntax standard.
4.2 Segment Delineation Characters

Obviously some method is needed to indicate the end of one segment and the start of the next, and likewise for the end of one data element and the start of the next. The manner of achieving this is by segment delineation characters. These characters are used to split the EDI file up into its constituent parts. Each syntax has its own
SRTIST, ECE 12
default delimiters, i.e. those that are used if no others are specified, but in most cases these can be overridden by special means if necessary.
4.3 Streams of information

The use of service segments not only allows routing of EDI data between trading partners but also allows the concept of regular data streams to be implemented, allowing the trapping of missing data and regular activities to be performed on EDI interchanges. Interchanges from each trading partner may be identified by the contents of the interchange control segment. A sequence number in the segment allows the receiver to check that this interchange is greater than the last one, avoiding possible duplication, and also allows for missing sequences and hence missing interchanges to be identified. In real life these cases may be more complex. Routing via a VAN may cause some interchanges to be received out of sequence. This scenario would be similar to the post arriving at your premises. The post is dumped in an unsequenced pile in the mailbox and the letters are then opened in any sequence. There is no guarantee that the sequence of documents processed or opened is correct. To solve this problem the concept of a sequence window is used. So long as the increase in the application reference number is not greater than the window size, then all is well and the sequence may then be checked for missing numbers at a later time when all the documents are expected to have been received.
SRTIST, ECE
13
CHAPTER 5 MESSAGE STANDARDS

In our telephone analogy, our telephone callers may exchange information because both parties are speaking the same language and understand the protocols that they must use, but unfortunately the remote party still does not understand the information that the caller is giving because they are from different industries and each industry has its own jargon and sequence or layout of information. To get over this problem the final layer of the EDI model was developed, in which both tradespecific and general document standards are defined by the controlling organizations. It should be mentioned at the outset that the message standards are subject to different interpretations and even misuse by some trading partners, so it is vital to get agreements between partners not only about the message standards used but also about the exact meaning and contents of information, before EDI interchanges are exchanged. Many large organizations publish their own implementation manuals for the standards that they wish to use. Even though these standards are based upon an industry standard message, there may well be minor differences in layout and format. The EDIFACT message standard is the most widely used in Europe. EDIFACT is a general-use standard not linked to any particular industry and is controlled by the EDIFACT board closely associated with both the EAN numbering associations and the United Nations. For the automotive industry there is ODETTE (Organization for Data Exchange by Tele-Transmission in Europe) and VDA (Verband der Automobilindustrie). ODETTE have historically had their own standards but have, since 2000, adopted the EDIFACT standards. The VDA standard is not a true EDI standard but does have many similarities. Many other industry specific organizations exist, such as CEFIC for the chemical industry and TRADACOM for the retail industry. Each message standard is firstly defined by a structure diagram detailing the segments and where they occur. Each segment on the structure diagram is defined as having a number of attributes. These are a name, a maximum number of occurrences and a mandatory or conditional status.
SRTIST, ECE 14
Here we see a NAD segment (NAD segments are used by EDIFACT to define Names and Addresses) where the segment name is held in the top section of the diagram. The segment is Mandatory ( M ) meaning that it must occur at least once in the message. The alternative to mandatory is Conditional ( C ) meaning that it need not occur if there is no information to be held in it. The segment is repeating ( R ) which means that it may occur more than once. An invoice, for example, may have more than one item line on it. Alternatives to this are the number 1 for a segment that may only occur once, or a number defining the maximum number of times that the segment may occur.
5.1 Message Structure

Many of these segment diagrams are combined together to form a message structure diagram. The message structure is hierarchic, meaning that segments may appear at a number of different levels and some segments will act as parents and children to others to define more complex pieces of information. To take a simple example, an item of goods appearing on a document, an invoice or order perhaps, would have a basic description held in a parent segment and then be further defined by child segments under the parent which describe its dimensions, its cost, its markings and many other attributes. These child segments may themselves be parents to more detailed segments, for example the segment holding the price may have date information segments under it as the price changes with time.
SRTIST, ECE
15
CHAPTER 6 CODES AND ROUTINGS

6.1 Introduction
An EDI Code is analogous to an address found on the envelope of a letter and forms the basis for all EDI routing. In this section we look at the use of EDI codes. There are two basic types of EDI code: physical codes and logical codes. A physical EDI code pertains to a physical computer or EDI system. A logical EDI Code could be: a computer application such as an invoicing system a trading sub division of a company, for instance a manufacturing plant a company (in legal terms) a corporation (a collection of companies)
6.2 EDI Routing

EDI routing, the path which guides the EDI data to its final destination, may be a long and winding trail. Organizations themselves are often complex and a large multinational organization may hide a world-wide network with many computers and systems. Files entering through a corporate gateway (a single access point from the corporation to the outside world) must be onward routed by that organization to their final destination. There are three levels at which EDI data is routed through such a system. Physical routing (in OFTP terms called SSID routing). This is routing during a communications connection by physically contacting another system using a network such as the X.25 packet switching system. The EDI code at this level is referred to as the SSID code. File routing (in OFTP terms called SFID routing). The largest collection of data crossing a physical connection will always be a file. A file may contain many EDI interchanges but will still always be considered as a single file. The EDI code at this level is referred to as the SFID code.
SRTIST, ECE
16
Interchange routing (sometimes called UNB, STX or ISA routing). Examination of the contents of an EDI file will enable the forwarder to split a single file into one or more EDI interchanges, all of which will contain interchange control segments with origin and destination EDI codes. The EDI code at this level is referred to as the EDI code. The first of these three routing methods handles the physical routing and the latter two methods handle logical routing.
6.3 Routing Nodes

The entities which exist at the three levels of routing are sometimes called nodes. The three basic node types are: Network Node (sometimes called the Physical Node or SSID Node) File Node (sometimes called the SFID Node) Message Node (sometimes called the UNB Node). The last two node types, File and Message Nodes, are also called Logical Nodes. The Message Node is not strictly part of OFTP addressing. Each Network node may have one or more File nodes and each File node may have one or more Message nodes. A simple analogy for EDI routing nodes (origin or destination points of contact) is to consider the structure of a medium to large company. Incoming mail for that company will be delivered to the mailroom. The mailroom is therefore the equivalent of the network node as it is the point of contact with the outside world. The mail will then be sorted and delivered to each department in bundles. The department is the equivalent of the file node. Finally each letter will be delivered to an employee, or section, within that department. This is the equivalent of the message node and the information has reached its final destination. In smaller companies some of these sections will be omitted so that the mailroom, the department and the final destination are all the same person. So it may be with EDI. In this case all three levels will share the same EDI code.
SRTIST, ECE
17
6.4 The Hierarchy of Node Types

To further understand the reason for these different types of node and hence the attributes of each node, it is necessary to look at the communications aspect of an EDI file.
6.4.1 The Session Level

Let us assume that an EDI file has been scheduled to be sent to the Accounts Departments Sales Ledger section of company A. A communications session is started with company A. The first contact and first level of validation that this data is being sent to the correct place is when the trading partners identify each other and exchange passwords. This level of communication is carried out at Network Node level. In the OFTP protocol, the SSID (Start Session Identity) is used to exchange this information and agree certain standards between the partners.
6.4.2 The File Level

Once the session has been started and passwords have been exchanged, the file may be sent. High level information is exchanged and again there has to be agreement between the two partners that, for example, the receiving partner has an Accounts Department (the destination of the file) and enough room on his system for the file to be sent. In the OFTP protocol, the SFID (Start File Identity) is used to exchange this information.
6.4.3 The Message Level

Finally the EDI data itself may now be transferred between the partners. The EDI data contains its own internal addressing. In the UNB segment (for EDIFACT), the STX segment (for UNGTDI) or ISA segment (for ANSI X12), there must be routing information defining both the senders and receivers EDI Codes. In this case the EDI code of the Sales Ledger section will be defined in the message as the receiver of this data. In practice, many users, particularly smaller companies, do not wish to use all three levels of routing. These users will have only one EDI code defining all three levels. ODEX can cater for these users and trading partners as well by allowing all three levels to be defined in a single user profiling operation, creating a combined Network Node, File Node and Message Node with the same EDI Code.
SRTIST, ECE 18
6.5 EDI codes in ODEX Enterprise

In ODEX Enterprise, the terms Network Node, File Node and Message Node are not used, and the hierarchical nature of the nodes is not so obvious as in other ODEX members, but the EDI codes for each level are still required. The SSID is defined on the Overview page, the SFID is defined on the Mailboxes page and the EDI code is defined on the EDI Codes page. Just as in other ODEX members, all three EDI codes can be defined at once, from the Overview page, if they are identical at all three levels.
6.6 EDI Codes for Clearing Centres

When communication between two trading partners is achieved via one or more clearing centres, such as DINET, the SSID code of the users clearing centre must be used as the Network Node (SSID) in ODEX or DARWIN 3, while the SFID and EDI code of the users trading partner must be used for the File Node (SFID) and Message Node (EDI code).
6.7 The Makeup of an Odette/EDIFACT EDI Code

Network and File Node EDI codes may be up to 25 characters long but at interchange level an EDI code may be as many as 35 characters. The codes should be made up using the following list of characters and no others. A to Z 0 to 9 / , . & ( ) Uppercase characters Hyphen Slash or Oblique Comma Full Stop Ampersand Left hand bracket Right hand Bracket Blank or space (CAUTION this is NOT recommended as some systems cannot cater for it). alphabetic
Numeric characters
SRTIST, ECE
19
There are currently no standards for EDI codification schemes. Obviously it is vital that the code should be unique. New EDI users have a number of choices available to them Choose their company name (not recommended) Be allocated an EDI code by a third party network (VAN) or trading partner Derive their own EDI Code
6.8 The Makeup of a Tradacoms EDI Code

Network and File Node EDI codes may be up to 25 characters long but at interchange level a Tradacoms EDI code must be no more and no less than 13 numeric characters long. In the Tradacoms standard, EDI codes are referred to as ANA codes and may be obtained from one of the standards bodies, such as DUNS or GS1.
6.9 VDA EDI Codes

Network and File Node EDI codes may be up to 25 characters long but at interchange level an EDI code can only be a maximum of 9 characters. For VDA communications, users are normally allocated an EDI code by their trading partner. This EDI code is usually their supplier code. Trading partner EDI codes are usually their customer code.
SRTIST, ECE
20
CHAPTER - 7 ENCODING STANDARDS

7.1 Introduction
Encoding standards deal with the representation of data within the computer. All computers store data in binary format, but the same character can be stored differently depending on the encoding standard used. Some encoding standards, such as ASCII and EBCDIC, are based on an 8-bit byte (or octet), which allows them to represent English letters and some non-English characters, graphics symbols, and mathematical symbols. Some ASCII standards are only based on 7-bit bytes. Other encoding standards, such as Unicode, are based on two octets (16 bits), allowing them to represent a much larger character set including Arabic, Cyrillic, Greek and Hebrew characters as well as English. To illustrate how various encoding standards represent the same character differently, we can use the letter A as an example, showing its binary bit pattern. In ASCII format, A is represented by 01000001 In EBCDIC format, A is represented by 11000001 In Unicode format, A is represented by 0000000001000001 This means that, for example, if a file in EBCDIC format is transferred to a computer which expects files in ASCII format, each character will be interpreted as if it were in ASCII, in effect becoming corrupt and losing its meaning. One answer is to allow for the conversion of files from one format to the other when transferred between computers which use incompatible encoding standards. ODEX Enterprise, for example, recognizes EBCDIC files and can convert them before displaying their details in human-readable text. However, if a user tries to view an EBCDIC file using a standard editor, such as Notepad, no conversion will be done and the file will be illegible. All the encoding standards represent characters as numbers so that they can be stored as binary values. This means that the binary bit pattern which represents each character also represents a number. For example, the binary bit patterns for the letter
SRTIST, ECE 21
A, shown above, also represent the numbers 65, 193 and 65 respectively. To the computer, the character is no different from the number. The difference is only made by the programs which access the data and must define the data as numeric or nonnumeric.
7.2 ASCII
ASCII (pronounced ask-ee) stands for American Standard Code for Information Exchange. ASCII is a code for representing characters as numbers inside the computer. The standard ASCII character set uses just 7 bits for each character, which allows each letter to be assigned a number from 0 to 127. For example, the ASCII code for uppercase A is 65. There are several larger ASCII character sets that use 8 bits, which gives them 128 additional characters. The extra characters are used to represent nonEnglish characters, graphics symbols, and mathematical symbols. ASCII encoding is used by all PCs, Unix machines and Apple Macs.
7.3 EBCDIC
EBCDIC (pronounced eb-sih-dik) stands for Extended Binary-Coded Decimal Interchange Code. EBCDIC is an IBM code for representing characters as numbers inside the computer and is based on an 8-bit byte. EBCDIC was developed at a time when one of the main criteria for the character set was its ease of use with punched cards. Even though the days of punched cards are long gone, EBCDIC is still used in IBM mainframes, such as MVS, and mid-range systems, such as the AS/400, mainly for backward compatibility.
7.4 Unicode
True Unicode, based on 16-bit character representation, provides a single unique number for every character, no matter which platform, language or program is being used. This means that if all systems were to adopt Unicode as their encoding standard, there would be no need for conversion. However, most systems have continued to use ASCII or EBCDIC, and Unicode is as yet mainly used by systems where a different language character set is required, such as Chinese or Arabic.
SRTIST, ECE 22
As well as true Unicode based on 16 bits (2 bytes or octets), Unicode has several other versions, such as UTF7 and UTF8, which are simply Unicode versions based on 7-bit and 8-bit encoding respectively. All Unicode is based on the ASCII representation of characters. In some systems, when the characters are part of the ASCII character set, the character representation is held in the second byte while the first byte represents binary zero. This is called Little Endian Unicode (i.e. the bytes in each file character are low order first). In other systems, the representation is vice versa. This is called Big Endian Unicode (i.e. the bytes in each file character are high order first). Files encoded in Unicode, Big Endian Unicode and UTF8 all contain a byte order mark in the first few bytes of the file to indicate how the file is encoded. Big and Little Endian encoding is only applicable to encodings which use 2 bytes per character (i.e. true Unicode). On a Windows system, most applications will expect Little Endian encoding. Mainframes will expect Big Endian encoding. Unix systems may use either, depending on their operating system. Whether a system uses Big or Little Endian encoding is inherent in that computer system. Even if character representation is only based on 8 bits, the system is still referred to as either Big Endian or Little Endian.
7.5 File encoding in DI products

DARWIN 3 and all members of the ODEX family support the use of both ASCII and EBCDIC encoding. ODEX Enterprise supports not only ASCII and EBCDIC but also Unicode and its variations. Uniquely, ODEX Enterprise can recognise which encoding it is dealing with. In the case of DARWIN, messages received from specific trading partners (i.e. those, such as Ford, whose data is produced on mainframes) are expected in EBCDIC format and are therefore translated into ASCII on receipt. Messages for these trading partners are translated into EBCDIC before they are sent. ODEX/MVS and ODEX/400 are both based on EBCDIC. All other ODEX members are based on ASCII.
SRTIST, ECE
23
In the case of all ODEX members apart from ODEX Enterprise, the user must configure the details for each trading partner to specify whether files to and from the trading partner are to be translated from and into EBCDIC. In the unlikely event that a trading partner normally using EBCDIC were to send a file in ASCII format, ODEX would in fact try to translate the ASCII file into ASCII, resulting in an unintelligible file. ODEX Enterprise, however, can recognize the encoding of files sent in any of the following formats: ASCII, Big Endian Unicode, EBCDIC, Unicode, UTF7, UTF8 Using the Workflow Manager, ODEX can be configured to translate files in any of these formats into another of these formats before passing the file on to a system requiring the translated file.
SRTIST, ECE
24
CHAPTER - 8 DATA TRANSMISSION AND IMPLEMENTATION

Trading partners are free to use any method for the transmission of documents. Furthermore, they can either interact directly, or through a third party.
8.1 Serial communications

At one time a common method of transmitting EDI messages was using a Bisync modem; one partner would have one or more modems set up to receive incoming calls, and the other would call it with their own modem. It was also possible to use a dedicated leased line or a network such as Telex. Some organizations may have transmitted EDI files via BBS.
8.2 Internet
As more organizations connected to the Internet, eventually most or all EDI was pushed onto it. Initially, this was through ad-hoc conventions, such as unencrypted FTP of ASCII text files to a certain folder on a certain host, permitted only from certain IP addresses. However, the IETF has published several informational documents (the "Applicability Statements"; see below under Protocols) describing ways to use standard Internet protocols for EDI.
8.3 Peer-to-Peer
EDI standards are written such that trading partners could connect directly to each other. For example, an automotive manufacturer might maintain a modem-pool that all of its hundreds suppliers are required to dial into to perform EDI. However, if a supplier does business with several manufacturers, it may need to acquire a different modem (or VPN device, etc.) and different software for each one.
8.4 Value-added networks

To address the limitations in peer-to-peer adoption of EDI, VANs (valueadded networks) were established. A VAN acts as a regional post office. It receives transactions, examines the 'from' and the 'to' information, and routes the transaction to
SRTIST, ECE 25
the final recipient. VANs may provide a number of additional services, e.g. retransmitting documents, providing third party audit information, acting as a gateway for different transmission methods, and handling telecommunications support. Because of these and other services VANs provide, businesses frequently use a VAN even when both trading partners are using Internet-based protocols. Healthcare clearinghouses perform many of the same functions as a VAN, but have additional legal restrictions. VANs may be operated by various entities:

telecommunication companies; industry group consortia; a large company interacting with its suppliers/vendors.
8.5 EDI IMPLEMENTATION

To start using EDI with your trading partners, you will need the following: Translator Standards Reference Connection
8.5.1 Translator
A translator can either be created or purchased .The EDI Professional website contains a list of translator vendors. It is important to review several vendors' products carefully to ensure that the translator you select will meet your business needs. Below are some considerations when selecting a translator: Find out how many looping structures deep the translator can handle. Compare the looping structure constraints to the commonly used EDI transactions your business will be using. Does the translator have a GUI front-end? GUI front-ends allow for easy drag and drop capabilities. What type of systems will the translator run on? PC, UNIX, MVS, etc. What are the system requirements? What kind of tracking capabilities are offered?
SRTIST, ECE
26
Does the vendor offer technical support? What are the hours for technical support? And, of course, what are the costs associated with acquiring, installing, and maintaining the translator.
8.5.2 Standards Reference

The EDI ANSI-X12 standards are published in both paper and electronic formats. Each person/company has their own preference on which type of format to use. New releases of the standards come out several times a year. It is important to note that when creating an EDI document, the version of the EDI standards used by the two trading partners exchanging the document must be the same. Therefore, it is not uncommon to have several versions of the standards. If the paper format is preferred, you will need to allow for extra room to store the EDI standards books when they are not in use.
8.5.3 Connection
A connection between you and your trading partner will need to be established to allow an electronic transfer of the EDI document. Several options are available including the following Frame Relay Internet Dedicated line (i.e. T1) to the trading partner Dedicated line to a VAN ISDN
8.6 Barriers to implementation

There are a few barriers to adopting electronic data interchange. One of the most significant barriers is the accompanying business process change. Existing business processes built around paper handling may not be suited for EDI and would require changes to accommodate automated processing of business documents. For example, a business may receive the bulk of their goods by 1 or 2 day shipping and all of their invoices by mail. The existing process may therefore assume that goods are typically received before the invoice. With EDI, the invoice will typically be sent
SRTIST, ECE
27
when the goods ship and will therefore require a process that handles large numbers of invoices whose corresponding goods have not yet been received. Another significant barrier is the cost in time and money in the initial set-up. The preliminary expenses and time that arise from the implementation, customization and training can be costly. It is important to select the correct level of integration to match the business requirement. For a business with relatively few transactions with EDI-based partners, it may make sense for businesses to implement inexpensive "rip and read" solutions, where the EDI format is printed out in human-readable form and people, rather than computers, respond to the transaction. Another alternative is outsourced EDI solutions provided by EDI "Service Bureaus". For other businesses, the implementation of an integrated EDI solution may be necessary as increases in trading volumes brought on by EDI force them to re-implement their order processing business processes. The key hindrance to a successful implementation of EDI is the perception many businesses have of the nature of EDI. Many view EDI from the technical perspective that EDI is a data format; it would be more accurate to take the business view that EDI is a system for exchanging business documents with external entities, and integrating the data from those documents into the company's internal systems. Successful implementations of EDI take into account the effect externally generated information will have on their internal systems and validate the business information received. For example, allowing a supplier to update a retailer's Accounts Payable system without appropriate checks and balances would put the company at significant risk. Businesses new to the implementation of EDI must understand the underlying business process and apply proper judgment.
SRTIST, ECE
28
CHAPTER - 9 ADVANTAGES AND APPLICATIONS

9.1 Advantages Associated with EDI
Some of the major benefits associated with the use of EDI are Elimination of Lost invoices Reduction in cycle time Elimination of data entry errors Reduced clerical workload Reduction in form, postage, and handling expenses Greater emphasis on process improvements, and automated acknowledgement of data exchanged Better market position relative to non-EDI competitors
9.2 Advantages over paper systems

EDI and other similar technologies save a company money by providing an alternative to, or replacing, information flows that require a great deal of human interaction and materials such as paper documents, meetings, faxes, etc. Even when paper documents are maintained in parallel with EDI exchange, e.g. printed shipping manifests, electronic exchange and the use of data from that exchange reduces the handling costs of sorting, distributing, organizing, and searching paper documents. EDI and similar technologies allow a company to take advantage of the benefits of storing and manipulating data electronically without the cost of manual entry. Another advantage of EDI is reduced errors, such as shipping and billing errors, because EDI eliminates the need to rekey documents on the destination side. One very important advantage of EDI over paper documents is the speed in which the trading partner receives and incorporates the information into their system thus greatly reducing cycle times. For this reason, EDI can be an important component of just-in-time production systems. According to the 2008 Aberdeen report "A Comparison of Supplier Enablement around the World", only 34% of purchase orders are transmitted
SRTIST, ECE 29
electronically in North America. In EMEA, 36% of orders are transmitted electronically and in APAC, 41% of orders are transmitted electronically. They also report that the average paper requisition to order costs a company $37.45 in North America, $42.90 in EMEA and $23.90 in APAC. With an EDI requisition to order costs are reduced to $23.83 in North America, $34.05 in EMEA and $14.78 in APAC.
9.3 EDI BENEFITS AT A GLANCE CURRENT SCENARIO

About 50,000 private sector companies in the United States are currently use EDI. Companies such as Federal Express, Eastman Kodak, American Airlines, Nike, Staples, and Prudential Insurance. EDI is widely used in manufacturing, shipping, warehousing, utilities, pharmaceuticals, construction, petroleum, metals, food processing, banking, insurance, retailing, government, health care, and textiles. According to a recent study, the number of companies using EDI is projected to quadruple over the next 6 years.
9.4 EDI APPLICATIONS

EDI is currently being utilized only in a limited realm of activities, in spite of its enormous capabilities. It is so under - tapped, that the industry joke goes that several companies are even unaware of the expansion of EDI. As of now, it is being used in the following areas, apart from purely business purposes. Streamlining buyer - seller interaction. Quick transcript exchange in universities. Transmitting large, complex engineering designs created on specialized computers, in auto manufacturing. Sending on-line catalogues to customers on product- prices , discounts & terms , for large MNC s .
9.5 EDI FOR BUSINESS

The advantages of using EDI in business are manifold. Apart from reducing costs, it is also faster, easier & helps in creating strong business relationships due to better interaction between trading partners & customers all over the world. Therefore, EDI can:
SRTIST, ECE
30
9.5.1 Increase Opportunities

EDI greatly increases business opportunities, not only with the Government, but also with many private sector trading partners through wider diffusion of procurement information.
9.5.2 Satisfy Customers

EDI is much faster in processing orders. It'll reduce order time. There is high customer satisfaction with faster response to orders and less paper to handle. There will be faster billing. Since orders are filled and delivered sooner, billing and closeout can occur sooner.
9.5.3 Improving Management

There will be better information for management decision-making. EDI provides accurate information and audit trails of transactions, enabling you to identify areas offering greatest potential for efficiency improvement or cost reduction.
9.5.4 Reducing Costs

You'll lower mailing costs. There is reduction in mailroom sorting/distribution time, elimination of lost documents, and a reduction of postage and other mailing costs.
9.5.5 Review Expected Benefits

In addition to learning about EC/EDI so that you can sell more to the government, there are other reasons for becoming a trading partner. Benefits include increased business with other private sector companies, lower costs, and greater efficiency.
9.5.6 Open Business Opportunities

EDI greatly increases business opportunities, not only with the government, but also with many private sector trading partners through wider diffusion of procurement of information.
9.5.7 Improved Record Keeping

There are improvements in overall quality through better record-keeping, fewer errors in data, reduced processing time, less reliance on human interpretation of data, and minimized down time
SRTIST, ECE 31
9.5.8 Reducing Inventory

Reduced need for inventory frees capital. EDI permits faster and more accurate filling of orders, help reduce inventory and assists you in "Just-in-Time" inventory management.
9.6 EDI IN INTERNATIONAL TRADE

Reduced transaction expenditures Quicker movement of imported & exported goods Improved customer services through track-and-trace programs , on the location of goods Easier entry for small-traders Faster customs clearance & reduced chances for corruption
9.7 APPLICATION CASE STUDIES

Recognizing the versatility of EDI, the Technology Innovation Group of the WDA introduced the EDI (Electronic Data Interchange) and Electronic Commerce Implementation Project in 1996. Co-financed by the European Regional Development Fund (ERDF), the project aimed to support the development and implementation of electronic commerce in at least 20 SMEs. The initiative followed on from the successful awareness promotion activities which had been undertaken by the EDI Awareness Centre for Wales (supported by the Agency and the European Commission's TEDIS programme) during the period 1993 - 1995. The rationale for the creation of the Centre was an underlying concern about the potential impact of EDI and E-Commerce on SMEs, at a time when large organizations were developing their competitive advantage by utilizing EDI between trading partners. It was felt that E-Commerce related services were becoming a prerequisite of trading in many sectors. It was a key priority to provide SMEs with ECommerce and EDI strategy and implementation support to help keep them ahead of the competition and to be in a stronger position to win new business. During the implementation programme the Agency funded 44 pilot projects in order to investigate and test the requirements for the process of implementing ECommerce in SMEs, and to better understand the conditions under which EDI and ESRTIST, ECE 32
Commerce works. A methodology for auditing the projects was agreed which covered the major activities to be completed both by the participating SME and the various facilitating organizations. The activities pioneered by the organizations included the following areas : enhancing management awareness of EDI and E-Commerce and outlining the specific conditions and constraints for introducing EDI related applications preparing for EDI development incorporating, the definition of the application, analysis of communication and information flow, definition of EDI messages and technical set-up, and confirmation of partner requirements implementing and testing pilot application including training advising on website functionality and site promotion evaluating the outcomes and examining opportunities for further development.
SRTIST, ECE
33
CHAPTER - 10 CONCLUSION
Researches are on, in employing EDI in fields like Railway rolling stock monitoring Ship berthing /scheduling notices Notification of hazardous goods & cargoes Exchange of CAD/CAM documents Lodgment of law court documents Airline ticket settlements Exchange & lodging customs clearances, airway bills, etc. It is estimated that in the next century , Electronic Data Interchange is all set to take over the world of business transactions , replacing several currently existent , yet obsolete methods and establish itself in all other fields where transfer of information are to be electronically documented . It has tremendous deal in the business field , and has an extremely promising future.
SRTIST, ECE
34
BIBLIOGRAPHY
www.lucent.com/press/0101/010130.bla.html http://www.research.ibm.com/research/press/holographic.html http://www.imation.com/about/news/newsitem/0%2C1233%2C298%2C0 0.html http://www.pitt.edu/~drew1/2089/holo.htm http://www.sciam.com/2000/0500issue/0500toigbox5.html
SRTIST, ECE
35

Electronic Data Interchange

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Electronic Data Interchange

Diunggah oleh

Hak Cipta:

Format Tersedia

ELECTRONIC DATA INTERCHANGE