Standards are one of the keys to the success of EC/EDI. Without standards it would be almost impossible to exchange information electronically with a wide variety of trading partners. The development of EDI standards, along with new communications technology (faster modems, Internet, Value Added Networks) and the increasing functionality of PC systems, has allowed ever increasing numbers of organizations to become EDI-compliant. Standards are one way of making EDI a realistic and opportunity-enhancing option.
Just what is a standard? As the name implies, standards are an agreed upon set of customs that tells users how their data should be structured. Since any individual user may have their own specific format for a document, it would be impossible for trading partners using different formats to connect and understand each other. An analogy would be two people speaking different languages. Unless there is a third language that both people know, it will be impossible for them to understand one another.
Standards are the common language. For computers to exchange data in recognizable formats data must be prepared in accordance with standards. Although the data must be passed in a standard format, it can be translated at the receiving end into any internal format desired. The bottom line is, communication with electronic trading partners requires a set of standards that allows comprehension of the message. There must be a common language.
Although there are more than one set of standards, ANSI X12 is the most widely used standard in the United States. Outside the US the most commonly used standard is a United Nations sponsored set of EDI standards known as UN/EDIFACT: EDI for Administration, Commerce and Transport. If you have a trading partner outside the US you might have to use this standard. Although there is much discussions to merge the two standards, currently no integration effort has occurred. Luckily, many EDI software packages can handle both standards.
Early on, the United States realized a need for common EDI standards, an agreed upon set of customs that tells users how their electronic data should be structured. Standards allow electronic trading partners to exchange data in a manner that makes the information realizable by any partner, regardless of the specific format in which any particular user may view his documents. In 1979, the American National Standards Institute (ANSI) chartered the Accredited Standards Committee (ASC) X12 to develop uniform standards for electronic interchange of business transactions. ASC X12 had to develop the structure, format, and content of business transactions conducted through EDI. That meant defining ANSI X12 standards for all types of business transactions: shipping and receiving information, invoicing, placement and processing, and payment processes.
The result of the ASC X12 committee's efforts are the ANSI X12 standards and the ability to electronically conduct nearly every facet of business-to-business operations. The committee's first version was released in 1983 and there are new releases every year. The latest is 3060 (which stands for version 3 release 6), although a new release, 3070, is expected soon.
The ASC X12 body comes together three times each year to develop and maintain EDI standards. New versions are created by the committee to include information needed by business. As the scope of business transactions increase and more and more industries become involved, some changes to the standards may be required.
ANSI X12 standards define transaction sets. A transaction set is often described as the EDI equivalent of a business document. A purchase order, invoice, or price catalog would each be a transaction set. The ASC X12 committee has created more than 275 transaction sets. As new business requirements are added, the committee refines its standards and releases a new version. The new release may make simple changes like changing a section of a transaction set or it could add an entirely new transaction set. This allows the ANSI X12 standards to stay vital and useful. But it also means that anyone involved with EDI needs to be aware of any changes in the X12 standards. New versions are not backward compatible. That means if you use version 3060 in your EDI software, you may not be able to handle a transaction set in 3050 format.
Because ANSI X12 standards are broadly defined so that they may be used for many different industries and businesses, it is sometimes necessary to develop a subset of the X12 standards known as implementation conventions (IC). ICs are an agreement among EDI trading partners on how a specific standard will be used in a particular industry or business context.
The Government has chosen to use and endorse ANSI X12 standards. The ANSI X12 standards have been used successfully by industry for many years. Rather than abandon this accomplishment, the Government decided to build on industry's success. The use of ANSI X12 standards by the Government also means that those trading partners that want to do business with the Government will only need to support a single set of EDI standards. The Federal Government has endorsed the use of ANSI X12 standards for EC/EDI with the U.S. Government through Federal Information Processing Standards (FIPS) publication 161 (copies can be obtained from the Government Printing Office). The DoD and the Electronic Commerce Acquisition - Program Management Office (ECA-PMO) have published implementation conventions (2003, 3010, 3040 and 3050) that describe how the standards should be used for exchanging EDI documents with the Government.
The ANSI ASC X12 committee is supported by the Data Interchange Standards Association, Inc. (DISA). DISA manages the ASC X12 membership, balloting, standards development and maintenance, publications, and communications with ANSI on behalf of ASC X12. To learn more about DISA visit http://www.disa.org/x12/ or contact them at (703) 548-7005.
When computers exchange business information electronically, they must do so in a format that both the receiving and sending station will recognize. For that reason EDI requires the use of standards--an agreed upon set of customs that tells users how their electronic data should be structured. ANSI X12 is the set of standards used in the United States for EDI. The ANSI ASC X12 committee defines these standards and publishes the latest release and standards version. A transaction set is the electronic equivalent of a paper business document like a purchase order, sales catalog, invoice, etc.
Since an EDI transaction is really just the electronic transmission of a business document, transaction sets that are prepared in accordance with an ANSI X12 standard, must be defined for every major business document. The ANSI X12 standard defines over two hundred transaction sets. Each transaction set is assigned a name and number for reference in the ANSI ACS X12 EDI environment. It is also given version release reference number. For example a purchase order sent by the DoD to a trading partner would be an ANSI X12 standard version 3010 transaction set # 850. Each of these designations is important to note. While standards allow much compatibility between users, the correct version release and transaction sets must be used to ensure connectivity.
Transaction sets support many different business areas: communications and controls, product data, finance, Government, materials management, transportation, purchasing, distribution and warehousing. To view a complete list of all ANSI X12 transaction sets visit: http://www.acq.osd.mil/ec/newhandbook/appendixa/appendixa.htm
DoD does not utilize all the existing transaction sets to do business with its trading partners. The following fourteen ANSI X12 transaction sets supporting procurement are being phased in:
840 Request For Quotation
997 Functional Acknowledgment
843 Response To Request For Quotation
832 Price/Sales Catalog
850 Purchase Order
855 Purchase Order Acknowledgment
824 Application Advice
860 Purchase Order Change
836 Contract Award Summary
865 Purchase Order Change Acknowledgment
838 Trading Partner Profile
869 Order Status Inquiry
864 Text Message
870 Order Status Report
If a transaction set is the electronic equivalent of a paper document, a functional group is a set of related documents. For example transaction set #135--student loan application, #139--student loan guarantee result, and #144--student loan transfer and status report would all fall under the same functional group. But the methodical grouping of transaction sets does not end there. Like any language, the language of ANSI X12 standards has many different levels. Functional groups are the phrases or sentences. Transaction sets are the "words." These words are constructed of even more detailed subsets known as data segments and data elements. You will notice a hierarchical relationship developing. The illustration below depicts this hierarchy.
Each transaction set contains data segments and data elements. Data elements are the smallest set of data contained in a transaction set. It could include basic information like price, size or product code. Just as a functional group contains logically related transaction sets, a data segment consists of logically related data elements. By definition, a data segment must begin with a segment identifier followed by one or more data elements and ending with a segment terminator.
Just like a dictionary for the English language, the definitions of all data elements contained in a transaction set are contained in a data element dictionary provided with each transaction set standard. It is possible to look up the definitions of specific data elements. Similarly, a data segment dictionary is a publication which shows the format of all the segments in the standard.
Standards allow electronic trading partners to exchange data in a manner that makes the information realizable by any partner. Standards create a common language for electronic data interchange. They make information recognizable to trading partners even if the partners use different internal formats. EDI standards were also designed to be useful for a wide range of business applications. As such, standards must be somewhat flexible.
In an EDI environment, the electronic documents that partners exchange are called transaction sets. While parts of any transaction set must remain intact, other parts can be adapted by a user. This built-in flexibility allows customized EDI. When transaction sets are changed or modifying in this way it is referred to as creating "implementation conventions." Basically the creation of implementation conventions by an industry or group is necessary to ensure compatibility within that particular set of trading partnerships. It enables the members of this group to better utilize their transaction sets and makes the interchange of data more efficient and effective by defining exactly how a transaction set is used and narrowing down the information required for a specific report format. Implementation conventions also establish which version and release of the EDI standard is used.
Of course if you are involved with different groups of partners you will need to be sure you are using their particular set of implementation conventions. If you intend to do business with a Government agency using EDI, you need to use the implementation conventions that are used by your Government trading partner. Generally, this will be either "Federal 3040 Implementation Conventions" for civil agency use or "DoD 3010 Implementation Conventions" for DoD use. However, there is currently an effort underway within the Government to standardize on a single set of Government-wide implementation conventions that are consistent with ANSI X12 Version 3050.
The DoD 3010 Implementation Conventions (and those for the Federal 3040 838 transaction set) are available on the Internet: http://www.itsi.disa.mil
Visit the National Institute of Standards and Technology web site on Government implementation conventions at : http://snad.ncsl.nist.gov/dartg/edi/fededi/html