LIST OF FIGURES

      

LIST OF TABLES

      

Table 2.0-1  Toplevel Comparison of X12 and UN/EDIFACT EDI Standards
Table 2.3-1  Data Types in UNEDIFACT
Table 3.0-1  Transaction Sets Used At The DFSC
Table 3.1-1  Transaction Set Message Equivalence

1.0  EXECUTIVE SUMMARY

      

The President via Executive Order has initiated a major program to improve federal purchasing through the use of Electronic Data Interchange (EDI) technology. In response to this initiative, federal agencies have begun to build upon industry successes with United States X12 EDI standards, and to use electronic techniques to accomplish smaller government procurements (e.g., purchase orders, request for quotes, quotes, etc.). The U.S. EDI standards body, Accredited Standards Committee X12 (ASC X12), chartered in 1979, meets under the auspices of the American National Standards Institute (ANSI). In 1983, ANSI published the first American National Standards for EDI. The international standards body, Electronic Data Interchange for Administration, Commerce, and Transport (EDIFACT), was established by the United Nations (UN) in 1985. ASC X12 and EDIFACT have established over 200 transaction sets intended to satisfy a broad spectrum of data requirements. Concurrent with these activities, several larger U.S. firms are expressing interest in accelerating migration to United Nations EDIFACT standards for international data interchange. The United States has committed to a process alignment between the domestic ANSI X12 EDI standard, and the international UN/EDIFACT standard. The EDIFACT standards are primarily used in Europe and Asia. However, in order for everyone to benefit from a single global EDI standard, ANSI X12 has agreed to begin a gradual alignment with EDIFACT in 1997. The ANSI X12 alignment plan includes for administrative alignment (and technical migration) to UN/EDIFACT.

1.1  Scope

International aspects of defense, the need for standardization and harmony, and the increasing reality of a global economy are factors that signal the need for a more common basis of data interchange. UN/EDIFACT holds the most potential for achieving this end with respect to the exchanges of routine business information. In this scenario, the Defense Fuels Supply Center must ensure that its business functions currently satisfied by the ASC X12 standard can aptly be supported by the UN/EDIFACT standards. This will be the requirement that drives this task of identifying and comparing the two standards on a syntactic and semantic basis for the domain of business activities of interest to the DFSC.

This report will introduce the basics of syntax and semantics in EDI structures. The report will also discuss various alternatives for determining semantic equivalence between the two EDI standards, ASC X12 and UN/EDIFACT. As this is a work in progress, the level of detail in the analysis will be restricted to a high level transaction set-message equivalency. However, an introduction into the final form of the matrices will be made. Detailed analyses for all transaction sets in use at the DFSC down to a data element/code list level will be in CRDL D044, "DFSC X12-UN/EDIFACT Message Semantic Equivalency Report."

1.2  Introduction

The Defense Fuels Supply Center acts as the Defense Logistics Agency's (DLA) designated representative in conducting the Department of Defense's management of fuel inventory and war reserves. DFSC's mission is to provide the Department of Defense and our customers comprehensive energy support in the most effective and economical manner possible. The Defense Fuels Supply Center (DFSC) is an important participant in the global marketplace of petroleum products. Within this marketplace, suppliers, airline industries, fixed-base operators, and other participants including DFSC, jointly developed methods for applying Electronic Data Interchange to the sale and delivery of petroleum products. International aspects of defense, the need for standardization and harmony, and the increasing reality of a global economy are factors that signal the need for a more common basis of data interchange. UN/EDIFACT holds the most potential for achieving this end with respect to the exchanges of routine business information. In this scenario, the DFSC must ensure that its business functions currently satisfied by the ASC X12 standard can firstly be supported by the UN/EDIFACT standards. DFSC methods address use of U.S. national EDI X12 standards, and are beginning to look into a limited use of UN/EDIFACT standards for international data interchange. An example of this joint effort is the Aviation Network Project or AVNET, which is attempting to maintain comparability of business information in a small set of X12 and UN/EDIFACT standards, with the goal of making use of EDI in one or both formats nearly transparent.

1.3  Definitions

The following definitions are provided for unambiguity in interpretation of the material in this report. Additional definitions of related terms are given in Appendix A.

EDI:  The computer to computer transfer of machine processble content standardized business information.

Standards:  Technical documentation approved by ANSI ASC X12 or UN/EDIFACT, specifically the transaction sets or messages, segments, data elements, code sets, and the interchange control structure.

Conventions:  Common practices and/or interpretations of the use of the standards, complying with the standards, as agreed upon by two or more trading partners. Conventions define what is included in a specific implementation of a standard.

Guidelines:  Specific instructions on the use of EDI. They provide additional information about conducting EDI. Guidelines are intended to provide assistance on how to implement EDI.

Syntax:  Structure and dependency of data within a data structure.

Semantics:  Pertains to the meaning of the information contained within a data structure, independent of the structure itself, such that the conversion from one structure to another would not change the meaning of the data.

2.0  EDI STANDARDS OVERVIEW

      

Fundamental to the ASC X12 standard is the notion that business information is to be transmitted within the body of a transaction set and data transmitted must be independent of the means of telecommunication. ASC X12 and UN/EDIFACT differ on the placement of transparent data in the respective standards. Although both ASC X12 and UN/EDIFACT offer solutions for moving transparent data in an EDI context, they are not interchangeable. Originally, UN/EDIFACT used ASC X12 for its standard design guidance. The design of the UN/EDIFACT message duplicated many aspects of ASC X12 transaction sets. At a point in time, UN/EDIFACT began to follow its own message design philosophy and resolved many perceived problems with ASC X12 by incorporating such items as generic data elements, composites, the single date/time solution, and data segment clarification descriptions as part of the message design. While some of the technology differs between the standards, both contain comparable building blocks. Each standard uses the data element as its fundamental building block. Data elements carry data characterized as numbers, amounts, quantities code values, text, and such. Data elements are grouped together in logical arrangements to convey related business information known as a segment. A message in UN/EDIFACT is made up of a series of segments arranged in a logical order to facilitate the flow of data to and from application programs. The major difference between UN/EDIFACT and ASC X12 is that UN/EDIFACT attempts to use a generic solution in message design as opposed to ASC X12, which sometimes uses a very specific approach. Some of the significant differences between ASC X12 and UN/EDIFACT are shown in the table below.

2.1  Syntax and Semantics in EDI

Both ASC X12 and UN/EDIFACT facilitate the transfer of Electronic Data Interchange information through X12 transaction sets or UN/EDIFACT respectively. These messages specify how information can be structured and exchanged in a standardized form. Message definitions include syntax as well as semantics. The syntax is defined explicitly within a message definition while semantics are specified by names and syntactic and semantic notes used throughout a message definition. An accurate measure of standards usability can be obtained when a detailed comparison of the included business functionality of each standard is made. The hierarchical structures of an ASC X12 and UN/EDIFACT message is shown below. As is evident, the structures' syntax vary in some aspects and are alike in others.

2.2  ANSI ASC X12Transactions

The X12 standards define commonly used business transactions in a formal, structured manner called transaction sets. A transaction set is composed of a transaction set header control segment, one or more data segments, and a transaction set trailer control segment. Optionally the transaction set may also include a transaction security header control segment and transaction security trailer control segment when it is desirable to send the data within the transaction envelope in an authenticated or encrypted form, or both. Each segment is composed of a unique segment ID; one or more logically related simple data elements or composite data structures, or both, each preceded by a data element separator; and a segment terminator. Composite data structures are composed of one or more logically related component data elements, each except the last, followed by a component element separator. The data segment directory entry referenced by the data segment identifier defines the sequence of simple data elements and composite data structures in the segment and any interdependencies that may exist. The composite data structure directory entry referenced by the composite data structure number defines the sequence of component data elements in the composite data structure.

A data element in the transaction set header identifies the type of transaction set. A functional group contains one or more related transaction sets preceded by a functional group header control segment and terminated by a functional group trailer control segment. Optionally, the functional group may also include a functional security header control segment and functional security trailer control segment when it is desirable to send the data within the functional envelope in an authenticated or encrypted form, or both.

The term ''semantics'' typically pertains to the meaning of the information contained within a data structure, independent of the structure itself, such that the conversion from one structure to another would not change the meaning of the data. The identification of semantic level is a designation allowing the description of a hierarchical relationship among semantic entities. The structure of a semantic entity, as published in a standards document, is its definition. The definition includes the sequence of data segments, their requirement for inclusion in any semantic entity instance, their maximum repeat counts, their placement within loops, and the requirement and repeat characteristics of such distinct loops. Segments may also be grouped in distinct areas (heading, detail, summary) to impart additional semantic significance.

The design of an X12 structure is the sequencing of data elements within segments, and then, if applicable, the combination of segments in a sequence to make up a semantic entity. A use of an X12 structure is the formatting of specific data according to the structure's design, to convey a specific meaning.

In the domain of ASC X12, the terms ''syntax'' and ''semantics,'' when used in the context of EDI implementations, refer to the structure and meaning of X12-formatted information, respectively. Syntax is the structure of the data. This includes establishing the method of encoding a piece of data by its attributes and identifying that data in the transfer. This is provided by the following aspects of the following X12 standards:

• X12.6 Application Control Structure describes the basic structure of the components of an X12 functional group and provides the control segments used to bound loops of data segments, transaction sets, and groups of related transaction sets, and the special control segments used to bound transaction sets and groups of transaction sets for security purposes.

• X12.3 Data Element Dictionary provides the attributes of type, minimum and maximum length, and if applicable, the relevant code list, of each data element that can be used in an X12 segment.

• X12.22 Segment Directory provides the segment label, data elements within the segment (in sequence), requirements for use of each element, and syntax notes indicating relationships among data elements, if any. Management transaction sets provide both the format and data content of transactions related to the interoperation of X12 systems. For example, X12.20 Functional Acknowledgement Transaction Set (997) describes the syntax-level acknowledgement of the receipt of an X12 functional group.

• X12.30 Electronic Form Structure Transaction Set (868) describes the transfer of the EDI standards, or portions thereof, in electronic form.

All other transaction sets (defined as ''business application'' transaction sets) provide the structure of the segments to be used within each, including a heading area, a detail area, and a summary area. Looping structures within those areas (and nested within each other), and the segment sequence within the transaction set are also defined. In addition, each segment and loop is further defined in terms of requirement for use and maximum use.

The term ''semantics'' relates to the meaning of the data transferred to the business application. The meaning of X12 data is derived from the descriptions of the components of the standard used in a specific implementation and is provided by the following aspects of the following X12 standards:

• X12.3 Data Element Dictionary provides the name and definition of each data element that can be used in an X12 segment, and if a code list is included, the description of each code. For ID data elements, where the code list is maintained external to the X12 Secretariat, that external source provides the meaning of each code in the list.

• X12.22 Segment Directory provides the name and definition of each segment that can be used in an X12 transaction set, as well as any semantic notes indicating relationships in the meaning of the use of one or more data elements in any one instance of the segment.

• Business application transaction sets provide semantics in the name, description of purpose and scope, and transaction set notes and comments. There are additional standardized components of the structure of X12 that control the distribution of X12 information through the enveloping of X12-formatted information, including:
  • X12.58 Security Structures defines the structures used for authentication and encryption of X12 transaction sets and functional groups.

  • X12.5 Interchange Control Structures provides the control structures for the electronic interchange of one or more functional groups.

  • X12.56 Interconnect Mailbag Control Structures defines the control segments used to bound a mailbag containing one or more X12 interchanges.

Taken together, the control components of X12 provide the structure in which the semantics of X12 can be exchanged between trading partners. The question to be addressed in this standard is whether the structure itself, by reason of the positioning of control information, provides any semantic content in the exchange of X12-formatted information. Semantic levels correspond to the hierarchy of the control levels.

The following figure is a hierarchical picture of the semantic levels outlined in the previous sections. Note that ''segment'' has been identified as the bottom level, even though ''data element'' is certainly a level under segment. The semantic meaning of a data element or composite in relationship to the segment which contains it, and of data elements in relationship to a composite, is defined by X12.6.

2.3  UN/EDIFACT Messages

The United Nation's rules for Electronic Data Interchange For Administration, Commerce and Transport are comprised of a set of internationally agreed standards, directories and guidelines for the electronic interchange of structured data. UN/EDIFACT's rules, in particular, refer to trade in goods and services between independent, computerized information systems. Transactions made with UN/EDIFACT are called messages. A message is a collection of information, that is exchanged to convey information related to a specific transaction between the partners engaged in EDI. Messages are composed of logically grouped segments required for the type of message transaction covered.

Segments:

A segment is the intermediate unit of information in a message. A segment consists of a pre-defined set of functionally related data elements which are identified by their sequential positions within the set. A segment begins with a segment identifier, a unique three alphabetic upper case code which uniquely identifies each segment, and ends with a segment terminator.

The status of a segment in a specific message type may be one of the following:

• Mandatory (M) - This segment must be used in the message.

• Conditional (C) - This segment will be used in the message dependent on certain conditions. The relevant conditions for required occurrence of the segment must be given as part of the message definition. If no conditions are specified then the segment may be used subject to agreement between trading partners, or at the option of the message originator.

Segments have specific places in a message and the same segment type may occur more than once in a message. Segments may occur in any of the following three sections of the message:

• Header Section - A segment occurring in this section relates to the entire message.

• Detail Section - A segment occurring in this section relates to the detail information only and will override any similar specification in the header section.

• Summary Section - Only segments containing totals or control information may occur in the summary section (e.g., invoice totals, overall discount, etc.).

Some segments may be repeated a number of times at their specific locations in the message structure. The status (requirement designator) and maximum number of repetitions of a type of segment are indicated in the Segment Table and in the Branching Diagram.

Within a message, specific groups of functionally related segments may be repeated; these segment groups are referred to as loops. The maximum number of repetitions of a particular loop at a specific location is indicated in the message Segment Table and in the Branching Diagram. A group of repeating segments (a loop) may be nested within other loops, provided that the inner loop terminates before any outer loop terminates.

Data Elements:

A data element is the smallest unit of information in a segment. Their descriptions and usage are defined in the UN/EDIFACT Data Element Directory (EDED). Two or more data elements may be grouped together to form a composite data element. The data elements forming a composite data element are data elements in their own right and are included in UNTDED. They are referred to as components in the Composite Data Elements Directory (EDCD).

The use of data elements in a segment is defined in the UN/EDIFACT Data Segment Directory (EDSD).

The status of a data element in a segment may be:

Mandatory - This data element must be used in the segment.

Conditional - This data element will be used in the segment dependent on certain conditions. The relevant conditions for required occurrence of the data element may be given as part of the segment definition. If no conditions are specified then the data element may be used subject to agreement between trading partners, or at the option of the message originator.

The segments in the Segment Directory are designed for use in a wide range of message types. This means that in some message types one or more conditional data elements or composite data elements in a segment may not be used. A data element whose function is to give a more precise meaning to another data element is referred to as a qualifier. The data value of a qualifier is a code taken from its associated code set. The code sets are part of the UN/EDIFACT Code Lists (EDCL).

The UNTDED notation is used to indicate the data type and length of each data element.

2.4  Overview of Syntax and Semantics Issues

From this discussion, we can derive that the two standards have the following common characteristics:

1. Tagged and delimited ASCII character strings used for encoding messages to specify the structure and content of the data.
2. Utilize a data dictionary of standard (global) business data elements and data segments.
3. Predefined message types exist to use combinations of data elements to create standard messages, which are composed of a specified sequence of data segments.

Although there are basic similarities between the ANSI X12 transaction set and UN/EDIFACT message, there are some fundamental differences outlined below.

1. The application level syntax rules of the ANSI X12 and UN/EDIFACT messages vary greatly. For example the messages are delimited and terminated using different character sets and rules.
2. Looping and nesting conventions differ.
3. There are six data element types defined in ANSI X12, while only three for UN/EDIFACT. For ANSI X12, the following six data element types exist: (1) numeric, (2) decimal, (3) identifier, (4) string, (5) date, and (6) time. For UN/EDIFACT, the following three data element types exist: (1) numerical, (2) alphabetical, (3) alpha-numerical.
4. EDIFACT allows for two levels of syntax.
5. There is no provision for optional fields using EDIFACT.
6. EDIFACT uses composite data elements.

In summary, at the macro level the interchange structure is very similar, however at the micro level the structure is significantly different. The variance in the way segments and data elements are structured is large enough that these two standards are not easily interchangeable. It is often the case that multiple X12 data elements are needed to define a single EDIFACT data element, which leads to a MANY to ONE mapping scheme.

3.0  DFSC EDI PRACTICES

      

The Defense Fuels Supply Center transacts a variety of business information with EDI, primarily with the ASC X12 transaction sets. The trading partner agreement outlines the details and conventions to be followed in the use of these transaction sets. As of the writing of this report, no business transaction is conducted with UN/EDIFACT messages. Trading partners doing business with the DFSC must adhere to the published ANSI X12 standard for transaction sets and shall comply with DFSC conventions for ANSI X12 transaction sets as identified by the trading partner agreements. Trading partners are also required to support the current and previous versions of the ANSI X12/American Standards Committee (ASC) standards within certain time limits.

EDI transactions with trading partners undergo a period of testing, in which transaction sets are sent electronically and corresponding paper documents will be sent by mail, for a mutually agreed upon time period. At the completion of the test period, if the parties determine the test to be successful, the mailing of paper documents will cease. The DFSC specified that in the event of any dispute between the trading partners during this testing period, the paper document shall prevail.

As mentioned earlier, the DFSC conducts all business with a variety of trading partners using ASC X12 transaction sets. Most of the industry trading partners use different versions of ASC X12 ranging from version 2002 to 3030. Most of the trading partners however, use version 3010. The DFSC does not mandate the requirement for a standard version of ASC X12 but instead tailors the transaction set for the vendor with the trading partner agreement and guidelines so that the relevant information can be transacted. The airline industry drives the guidelines for implementation of EDI at the DFSC, since airlines are the biggest consumer of fuel and have well set and established guidelines for EDI implementation. The DFSC is beginning to look into a limited use of UN/EDIFACT standards for international data interchange. The Aviation Network Project or AVNET, is attempting to maintain comparability of business information in a small set of X12 and UN/EDIFACT standards, with the goal of making use of EDI in one or both formats nearly transparent.

Some of the main trading partners of DFSC are oil companies like Shell, BP, Exxon, Texaco, Mobil, and Amoco. Use of EDI at the DFSC is implemented with relatively few transactions but each of them are for high volumes of fuel and involve high currency transfers. To indicate the volume level of the transactions, the DFSC conducts about

         1 Solicitation every 3 years,
         12 Transactions in Bulk Fuels per year, and
         50 Transactions in Ground Fuels per year.

A total of about $4.2 billion per year is transacted through the DFSC. So in spite of the fact that the transaction volume is low, the effects of each transaction are significantly high.

There are a total of 47 different transaction sets targeted for use by the DFSC and its regional offices. Of these 47, only 18 are in current use while the rest are still slated for implementation. There are 5 transaction sets used extensively out of the 18. All of these are shown in Table 3.0-1 below.

Of the 5 transaction sets in current use, the invoice is the most widely used. Vendors are required to submit invoices to the DFSC using ASC X12s 810 transaction set version 3010 followed under the AVNET industry implementation convention. The DFSC electronically submits an acknowledgement using Transaction Set 997 to the vendor within one day of receipt of the 810 transaction set.

Upon receipt of an incorrectly submitted invoice, an Invoice Return Notification is sent via the ASC X12s 824 transaction set, version 3010 under a specific implementation convention defined by the DFSC. The DFSC transmits the Invoice Return Notification within seven (7) days of receipt of an improper invoice (Transaction Set 810). The contractor is required to transmit a Functional Acknowledgment (Transaction Set 997) within 24 hours of receipt of the Invoice Return Notification.

Price changes are electronically transmitted to and by the DFSC using ASC X12s 832 transaction set, version 3010 under the AVNET implementation convention. The receiving party is required to electronically transmit an acknowledgment to the sending party with the Functional Acknowledgment (Transaction Set 997) within one day of receipt of Transaction Set 832.

3.1  Top Level Functional Equivalence of X12 and UN/EDIFACT

From the list of transaction sets in use by the DFSC, we have identified target UN/EDIFACT messages that would be semantically capable of transacting the same information content as is currently being done with ASC X12. This list is preliminary and is subject to change as the task progresses and determinations of the semantic equivalencies evolve. This list is based on the message definitions and segment specifications given in version D.96A of UN/EDIFACT. As the task progresses, matrices for each of these transaction sets will be built on a data segment, data element, and code set levels.

4.0  X12-UN/EDIFACT MESSAGE COMPARISON

      

Given the background of the nature of business conducted at the DFSC, the goal of this entire task is to determine a method of establishing a semantic equivalency between the information transacted with ASC X12 currently and establish the same information can be transacted with UN/EDIFACT messages. The answer to this problem lies in the definition of a clear, standardized, and structured approach to defining the semantics of the data being transacted with ASC X12 and how the same data may be transacted by UN/EDIFACT messages without any loss of meaning.

The goal of establishing a Semantic Equivalency is a work in progress of this task and will be fully detailed in CRDL D044, "DFSC X12-UN/EDIFACT Message Semantic Equivalency Report."

4.1  EDI Standards Comparison Strategies

In this report, we will introduce several of the structured approaches that may be applied to this problem. Two of the approaches which we have been looking at are

• The Basic Semantic Repository Project.
• The Universal Data Element Framework Approach.

4.1.1  Basic Semantic Repository Project

The Basic Semantic Repository (BSR) is a technical infrastructure which provides storage, maintenance, and distribution facilities for reference data about semantic units and their links with operational directories. The prototype, which was authorised by the ISO Executive Board early in 1993 and the BSR Interim Management Committee (IMC) in July 1993, as a joint project between ISO and UN/ECE, had the following major deliverables:

• Definition of the rules and guidelines to be used within the BSR and for Basic Semantic Units (BSUs).
• Definition of the data model for the BSR, including BSUs and bridges.
• Definition of the access to the BSR by the user community.
• Development and implementation of a prototype.
• Test population of the prototype.

The broad user community has been exposed to the concepts of the BSR with presentations given to: Continuous Acquisition and Life-Cycle Support (CALS) organisations from NATO, UK MoD, U.S. DoD and TC 184 including exposure at the European CALS Conference; Finance via SWIFT and TC 68; Health Care via CEN TC 251; Industry Groups - EDIFICE (Electronics), and CEFIC (Chemical). The U.S. presentations have addressed the role the BSR could play in the Presidential Programme on Electronic Commerce. A major emphasis in these presentations has been the requirement for user involvement in terms of active, committed resources to work with the central project resource. Overall, the reaction to the BSR project has been positive and supportive. The original plan, to be completed by the end of 1993, was delayed by not having sufficient committed time available for the project due to higher priority tasks for most of the team members.

The BSR is a technical infrastructure which provides storage, maintenance and distribution facilities for reference data about semantic units and their links with operational directories. It satisfies the following principal functions:

1. An aid in the analysis of data concepts in existing EDI (also including Open EDI) directories down to and including the atomic level;

2. An aid for cross referencing and migration between different EDI directories which are maintained by different agencies;

3. An aid in the modelling process within EDI;

4. A means of defining new data in a directory or redefining existing data in a directory when these data are brought up for modification; and

5. A focal point for the development of new concepts.

Components of the BSR

1. Basic Semantic Unit (BSU):  A concept unambiguously defined and applicable in one or more contexts in an EDI environment.

2. Bridge:  The link between a BSU and its related unit(s) of information in a given directory.

Conclusions

The concept of the BSR has been broadly accepted as the International initiative to address data consistency for global communication. In view of the needs of the end user community, it has become necessary to demonstrate the projects viability by having the bulk of the data supporting the major EDI applications - UN/EDIFACT and ANSI ASC X12 - defined, approved, and freely available to users world wide. As the BSR will be a critical component of the infrastructure for effective global communication it must be freely available in the public domain.

4.1.2  Universal Data Element Framework

In 1995, the CALS Industry Steering Group's Universal Data Element Framework began the process of migration toward an American National Standards Institute (ANSI) standard under the auspices of the Electronics Industries Association (EIA). Once standardized, this framework is meant to be an essential tool for an enterprise-wide data management function. In addition, a national or international data element registration authority function is required to enable the effective coordination and flow-down of the Universal Data Element Framework and the universal codes to those organizations wishing to keep their information systems interoperable with the systems within their customers and suppliers organizations.

The Universal Data Element Framework provides a common structure for mapping all shareable data elements across the various standards and legacy systems. It provides a framework which makes it feasible to map data elements from STEP, EDI, EDIFACT, the DoD Enterprise Model, and MIL-STD-1388 into the same framework. Towards the end of 1996, 100% of the over 600 Configuration Management (CM) Data Model data elements were analyzed and 95% were successfully mapped into the Universal Data Element Framework. The unmapped 5% require further coordination with the team that developed the data model.

In the framework, each data element is assigned a unique universal code that will totally define the semantics of the data element. The universal code derived from the Universal Data Element Framework is the "key" for integrating legacy data. Each legacy data element may continue to carry its original name. The universal code allows for an unlimited number of aliases.

ISO/IEC 11179 specifies a requirement that says before a data element can be recognized as an international standard, it must be registered by an internationally recognized registration authority that has been granted a unique registration authority identifier. Once the Universal Data Element Framework is initially baselined, an internationally recognized organization will need to accept ownership of the framework and assign the universal codes to each data element contained within its domain.

The Universal Data Element Framework is fundamentally object oriented. It satisfies the intent of ISO/IEC 11179 and it also satisfies DoD 8320.1-M-1 naming requirements. EIA G-33 is in the process of mapping all data elements from the CM Data Model into the framework. Once the CM Data Model is established as an interface standard to industry, the framework would provide a simple interface tool that industry could use to map their legacy data into the government's JCALS/JEDMICS/CMIS system. It would provide a common structure for "harmonizing" the various overlapping standards. Once coded into the proper tool, the Universal Data Element Framework would provide a transparent interface to legacy data.

4.1.3  Selected Strategy

Of these two different strategies, the one more suited for this task is the Universal Data Element Framework concept. This process will lead to a strucutred approach to building a semantic equivalency matrix between the two standards. The framework also lends itself to modification easily and the creation of new branches in the object and property tree structures. The goal of the task is to assign universal data element codes for each of the data elements in the transaction sets and messages being analyzed as per the respective implementation conventions. Once these elements have been assigned the codes, the task of comparison X12 elements with the same code value as elements from UN/EDIFACT messages is made easy. Detailed analyses for all transaction sets in use at the DFSC down to a data element/code list level will be in CRDL D044, "DFSC X12-UN/EDIFACT Message Semantic Equivalency Report."

4.2  Summary

The primary goal of Task 11 is to conduct a syntactic and semantic analysis of the equivalence of ASC X12 transaction sets and UN/EDIFACT messages as used for common business transactions employed at the Defense Fuels Supply Center (DFSC). This report outlines a preliminary version of a high level ASC X12 transaction set to UN/EDIFACT message matrix. The data element level analysis will use the complete set of data elements of ASC X12 and UN/EDIFACT as used in the DFSC's transaction sets and messages. Syntactic and Semantic Equivalency Matrices will be developed for the transaction sets currently in use by the DFSC using a structured approach to defining the semantics of the information being transacted. Preliminary versions of these matrices for the ASC X12 810 Invoice Transaction Set and the INVOIC message are provided in Appendices B and C. The matrices will also be useful in future expansion of ASC X12 transaction sets to UN/EDIFACT messages as the DFSC role in international data transfer expands. Specific interest will be devoted to the Aviation Network's (AVNET) implementation guidelines for EDI in the petroleum and fuel industries.

APPENDIX A:  DEFINITIONS

      

Definitions

American National Standards Institute (ANSI) ­ the principal standards coordination body in the United States. ANSI is a member of the International Organization for Standardization (ISO).

Archive ­ to store data for a given period of time for security, backup, or auditing.

Automated Information System (AIS) ­ computer hardware, computer software, telecommunications, information technology, personnel, and other resources that collect, record, process, store, communicate, retrieve, and display information. An AIS can include computer software only, computer hardware only, or a combination of the above.

Basic Ordering Agreement ­ a basic ordering agreement is a written instrument of understanding, negotiated between an agency, contracting activity, or contracting office and a contractor, that contains terms and clauses applying to future contracts (orders) between the parties during its term, a description, as specific as practicable, of supplies or services to be provided, and methods for pricing, issuing, and delivering future orders under the basic ordering agreement. A basic ordering agreement is not a contract.

Business Application ­ a computer-based system that processes business information in support of a specific business function such as purchasing, accounting, or logistics management, etc. Business application data is produced by such applications and transmitted to a translation program for conversion into an EDI format, and vice versa.

Communications Handler ­ a software program that controls computer hardware and modems and arranges for the transmission or reception of electronic data.

Compliance Checking ­ a checking process that is used to ensure that a transmission complies with syntax rules.

Control Characters ­ in communications, any transmitted characters used to control or facilitate data transmission between two or more computers. Also, characters associated with addressing, polling, message delimiting and blocking, framing, synchronization, error checking, and other control functions.

Control Structure ­ the beginning and end (header and trailer) segments for entities in Electronic Data Interchange.

Data Element ­ the smallest, meaningful piece of information in a business transaction. A data element may condense lengthy descriptive information into a short code. Equivalent to a data field in a paper document; a series of data elements is used to build a data segment. A data element dictionary that defines the data element and, where appropriate, the code is part of ASC X12 or UN/EDIFACT standards.

Data Element Delimiter ­ a separating character, such as an asterisk (*), that precedes each data element within a segment.

Data Element Dictionary ­ the publication that lists all of the data elements used within EDI standards.

Data Segment ­ a data segment is a group of related data elements in a transaction set. Each segment has a unique segment identifier and a combination of two or three uppercase letters and/or digits that serves as a name for the segment and occupies the first character positions of the segment. A segment is equivalent to a data record in a database.

DoD EC and EDI Infrastructure - a subset of the DII that is designed to support EC and EDI. It is composed of hardware, software, and people. It provides services such as translation, archiving, distribution, and result notification. It supports all DoD EC and EDI functional activities as well as other civilian agencies that may need to use it.

DoD Gateway ­ DoD Gateways control the timing and flow of EDI transactions on the government side of FACNET.

Dynamic Requirement ­ testing of dynamic requirement types requires the execution of the software application.

Electronic Commerce (EC) - the paperless exchange of business information (goods and services) or ideas using Electronic Data Interchange (EDI), Electronic mail (E-Mail), electronic bulletin boards, Electronic Funds Transfer (EFT), facsimile, video conference, and other similar technologies.

Electronic Commerce Processing Node (ECPN) ­ a collection of hardware and software systems which provides communications connectivity between Value Added Networks (VANs) and the Government Gateways to support the exchange of EDI transactions between Government procurement agencies and private sector trading partners. There are currently two ECPNs, located in Columbus, Ohio and Ogden, Utah.

Electronic Data Interchange (EDI) - the computer-to-computer exchange of business transaction information in a public standard format.

Electronic Mailbox ­ a holding location for EDI transactions generally provided by a Value Added Network (VAN) to its customers. The customers would normally dial-up and connect to their EDI mailboxes and download and upload transactions.

FACNET ­ Federal Acquisition Network was created by Section 9001, Federal acquisition Streamlining Act of 1994, Pub. L. 103-355, Oct. 13, 1994, 41 USC 426. FACNET is defined as: the Government wide Electronic Commerce/Electronic Data Interchange (EC/EDI) systems architecture for the acquisition of supplies and services that provides for electronic data interchange of acquisition information between the Government and the private sector, employs nationally and internationally recognized data formats, and provides universal user access. FAR 4.501 FACNET is not a specific system but rather a series of capabilities. For procurements at or below the Simplified Acquisition Threshold, a contracting activity using an Interim FACNET certified system is exempted from the requirement of posting or synopsis in the Commerce Business Daily (CBD) as indicated in FAR 5.202 (a) (13) and the waiting periods required before award or issuance of the solicitation.

FTP ­ a file transfer protocol typically used with TCP/IP.

Functional Acknowledgment ­ an ANSI ASC X12 Transaction Set (997) which is produced by translation software upon receiving and validating an EDI transaction set, and sent to the sender.

Implementation Convention ­ a subset of the X12 standard that represents the common practices and/or interpretations of the use of X12 standards. Conventions define how trading partners will use the standards to accommodate their mutual needs. An Implementation Convention should exist for each EDI transaction set that is to be used. Implementation Conventions deal with transaction sets at the data element level. For the Government, or any industry sector, Implementation Conventions (for doing EDI within that industry) can be highly detailed subsets of the Implementation Guidelines (for doing EDI within that industry).

Implementation Guidline ­ the Guideline contains instructions on the use of EDI. It provides additional information to assist in conducting EDI. The Guideline is intended to provide assistance and should not be your sole source of information.

Inbound Transaction ­ a transaction coming to the reciever from the sender.

Interchange Control Number ­ a control number assigned to an EDI interchange that is unique to both the interchange and the trading partner for a particular interchange.

Interim FACNET ­ means a contracting office has been certified as having implemented a capability to provide widespread public notice of, issue solicitations, and receive responses to solicitations and associated requests for information through FACNET. Such capability must allow the private sector to access notices of solicitations, access and review solicitations, and respond to solicitations.

Mapping ­ the process of manually mapping data elements from User Defined File formats to and from corresponding standard EDI transaction sets.

NIPRnet ­ NIPRnet is often referred to as the non-classified DoD intranet.

Nonrepudiation ­ the quality of a secure EDI system that prevents a party from falsely denying that they sent or received a specific transaction/message.

ORDERS Message ­ specifies details for goods or services ordered using Electronic Data Interchange (EDI) between trading partners involved in administration, commerce, and transport under conditions agreed between the seller and the buyer.

Outbound Transaction ­ a transaction leaving from the sender and going to the reciever.

Public Transaction - a transaction that, rather than being sent to one trading partner, is broadcasted to a predefined group of trading partners. Alternatively, a transaction that is made available to any trading partner by being placed in a publicly accessible media, such as an electronic bulletin board, for downloading.

Security ­ a generic term describing the methods adopted to protect data from loss, corruption, and/or unauthorized access and retrieval. Methods include passwords, digital signatures, identification keys, verification, encryption/decryption, and nonrepudiation of sender and receiver.

Simple Mail Transfer Protocol (SMTP) ­ the TCP/IP protocol for transferring electronic mail messages from one machine to another. SMTP specifies how two mail systems interact and the format of control messages they exchange to transfer mail.

Store-and-Forward ­ the process of storing EDI transmissions in an electronic mailbox before delivering them to recipients.

Static Requirement ­ testing of static requirement types does not require the execution of the software application.

TCP/IP ­ transmission communications protocol/Internet protocol.

Trading Partner (External) ­ a non-federal government entity with whom the federal government exchanges business transactions.

Trading Partner (Internal) ­ a federal government entity who exchanges business transactions with another federal government entity.

Trading Partner Agreement (TPA) ­ a written instrument of understanding negotiated agreement between EDI trading partners that specifies contractual matters and protocols of governing EDI transactions. These are generally used in the private sector among EDI trading partners. Within the federal EDI acquisition context, Trading Partner Instructions (TPAs) are issued by the Government to the vendor community and are used instead of a TPA.

Trading Partners ­ entities who exchange business transactions.

Transaction ­ all of the business information contained in a transaction set.

Transaction Set ­ a semantically meaningful unit of transaction information exchanged between EDI trading partners. It can be thought of as the electronic counterpart of a paper document that represents a transaction (e.g., an invoice, a bill of lading, or a medical insurance statement).

Translation ­ a utility that uses the results of the mapping process to automatically convert the data in User Defined File formats to and from corresponding standard EDI transaction sets.

Value-Added Network (VAN) ­ generally commercial entities that transmit, receive, and store EDI transactions on behalf of their customers. VANs may also provide additional services known as Value Added Services (also known as third party networks).

Value-Added Service (VAS) ­ a Value Added Service (VAS) may be a separate commercial organization (also known as an EDI service bureau) that provides EDI-related services, or a VAN that provides extra fee-based services beyond standard VAN services to its customers. Such services may range from translation to "EDI-to-FAX" services to complete EDI-integrated business systems.

X.400 ­ the international standard developed by CCITT for a store-and-forward message handling system in a multivendor environment.

APPENDIX B:  ILLUSTRATION OF X12 EDI TRANSACTION MAPPING TO UNIVERSAL DATA ELEMENT FRAMEWORK

      

The following is a matrix containing the mapping from ANSI X12 to Universal Data Element codes for the AVNET convention of the 810 Invoice (Version 003 Release 010). The 810 Invoice is broken into three sections as below: header, detail, and summary.

HEADER SECTION

DETAIL SECTION

SUMMARY SECTION

APPENDIX C:  ILLUSTRATION OF UN/EDIFACT EDI MESSAGE TO THE UNIVERSAL DATA ELEMENT FRAMEWORK

      

The following is matrix containing the mapping from EDIFACT to Universal Data Element codes for the AVNET convention of the INVOIV message. The INVOIC message is broken into three sections as below: header, detail, and summary.

HEADER SECTION