Introduction
EDI model required for sending or receiving EDI messages. EDI is defined by its technology. The technical elements of EDI systems are:
1) EDI Standards
2) EDI Software
3) EDI Networks
4) EDI Agreements
EDI Standards
Using EDI, a business application on the computer of one organization can communicate directly with the business application on the computer of another organization.
To ensure that this exchange of information is independent of hardware, software or the nature of implementation at either of these two organizations, it is necessary to extract data from the business application and to transform it into a standard format, which is widely acceptable. This data when received at the destination is interpreted and automatically delivered to the recipient application in an acceptable form.
The exchange of business documents in a commonly agreed structured format necessitated the development of EDI standards. EDI standards are basically data standards in the sense that they lay down the syntax and semantics of the data being exchanged.
Need of EDI Standards
EDI provides an electronic linkage between two trading partners. Business transactions are output from the sending computer system, transmitted or transported in electronic format and input into the second, receiving computer system.
The computer systems exchange data need a common format; without a common format the data is meaningless. Two organizations that exchange data can, with relative ease, agree a format that meets their mutual the that needs. As network of exchanges develops then the number of organizations needing to be party to the agreement grows. To illustrate this, assume a network of three customers (say supermarkets) ordering goods from four suppliers (food manufacturers) (figure 2.16).
The network in figure 2.16 has 12 separate interchanges. It is unlikely that each of these exchanges would have its own format but it is perfectly possible that each customer would have developed its own standards (giving each supplier three separate standards to cope with). It is also possible that new exchanges added to the system will have requirements not envisaged when the data formats ware originally agreed; this would require a change to the existing standard or the introduction of an additional standard. The overall picture is one of unnecessary complexity and incompatibility.
EDI standards overcome these difficulties. The EDI standard provides or attempts to provide, a standard for data interchange that is:
i) Ready formulated and available for use;
ii) Comprehensive in its coverage of the data requirements for any given transaction;
iii) Independent of hardware and software; and
iv) Independent of the special interest of any party in the trading network.
EDI Standards provide a common language for the interchange of standard transactions.
Categories of EDI Standards
Over a period of time two major EDI standards have evolved:
1) ANSI X12: The Accredited Standards Committee (ASC) X12 was set-up by the American National Standards Institute (ANSI) in 1979 to develop cross- industry standards for exchanging electronic documents for use by all businesses in the United States. The committee dèveloped ANSI ASC X12, commonly referred to as the X12 standard.
Today, EDI standards are firm but not static, because the development of EDI is a continuing effort. It describes the format for structuring the data, the types of documents that should be transmitted electronically, and the content of each document. The identification numbers for various forms, codes for a variety of fields, and types of information is also defined in the standard. The standard also defines the sequence of information flow.
The X12 standard defines a set of documents, referred to as transaction sets, for a wide range of business transaction forms. Each transaction set is given a numeric code and each transaction set is used and for defining the transfer of a single document (purchase order, manifest, etc.) between the computers of two trading partners. The data embedded in a transaction set conveys the same information that is contained in the printed version of the document; usually, it is a subset of the whole information on the printed version.
The printed version of the document can be thought of as containing three distinct types of information:
a) Header: It contains the information that is common to the whole document such as date; from address; to address; terms and conditions, etc.
b) Detail: It refers to line items that describe the actual business transaction. In case of a purchase order, it may contain item number, description, quantity ordered, and price information.
c) Summary: It refers to the control information and other components that refer to the complete transaction. In case of a purchase order, it may refer to order value.
2) EDIFACT: The EDIFACT standard, like all other EDI standards, is about the exchange of (electronic) documents for EDIFACT each document type is referred to as a message. For trade purposes the documents include order, dispatch advice, invoice, payment order, and remittance advice.
For transmission purposes EDIFACT messages are sent in an electronic envelope known as an interchange.
Within that interchange there may well be a number of messages. The messages themselves are made-up of a series of data segments. Data segments encode a single aspect of the trade document, e.g., the order date or the buyers name and address. Data segments are, in turn, made-up of tag and a number of data items. The tag identifies the data segment and the data elements give the codes and/or values required in the document (message).
The data elements include the codes and values for items such as date and address code but they are frequently used in combination with type or qualifier data items to specify the format of the data and its use, e.g., a date could be the order date and be in eight digit century format. The requirement to use data elements together forms a composite data element.
Figure 2.17 presents the basic structure of an EDIFACT:
An EDI is possible only when there is a connection between two computers. When a connection is established, there is an interchange of information. An interchange consists of a functional group of messages. Each functional group may comprise messages of the same type that in turn might consist of data segments.
The data segments are of data elements which are either simple data elements or composite data elements. Composite data elements comprise component data elements. EDIFACT provides necessary delimiters to identify the elements separately.
Apart from the basic structure, EDIFACT provides certain control strings beginning with UN. The purpose of these control strings is mentioned in table 2.4:
Table 2.4: Meaning of Various Terms Used in EDIFACT
| Term | Meaning |
| UNA | Service segment tag that gives special meaning to characters used in the interchange |
| UNB | Interchange header identifying sender, receiver, syntax password and acknowledgement requests |
| UNZ | Interchange trailer with control totals |
| UNG | Functional group (same type of messages) header segment, including sending/receiving application IDs, and message type |
| UNE | Functional group tailor which control totals |
| UNH | Message header segment containing message reference, message identification and version number |
| UNT | Message trailer with control totals |
| Previous | Next |
|---|
Comments
Post a Comment