X12 and EDIFACT Glossary
This appendix contains a glossary of terms used in the X12 and EDIFACT environment for electronic data interchange.
Accredited Standards Committee (ASC) X12 |
The committee was chartered by ANSI in 1979 to develop uniform standards for the electronic interchange of business documents. Accredited Standards Committee X12 consists of U.S. industry and government members who develop Electronic Data Interchange (EDI) standards for submission to ANSI for subsequent approval as a United States Standard or to the UN/ECE for approval and submission of UN/EDIFACT international standards. |
American National Standards Institute (ANSI) |
A private, non-profit membership organization that coordinates the development and approval of voluntary consensus standards in the United States. |
American Standard Code for Information Interchange (ASCII) |
A standard character set developed to enable efficient data exchange and compatibility among different computer platforms and peripherals. ASCII is a seven bit code with an eighth bit used for parity. The term is used to describe the format for transmission and for storage. |
Bureau (WP.4) |
Office bearers (Chairman and Vice Chairman) of UN/ECE/WP.4 and its Meeting of Experts on Data Elements and Automatic Data Interchange (GE.1) and Meeting of Experts on Procedures and Documentation (GE.2), and WP.4 Secretariat. |
Component data element |
A simple data element which is a subordinate portion of a composite data element and an interchange identified by its position within the composite data element. (ISO 9735) |
Component data element separator |
A character used to separate component data elements in a composite data element. (ISO 9735) |
Composite data element |
A data element containing two or more component data elements. (ISO 9735) |
Conditional |
A statement in a segment or message directory of a condition for the use of a segment, a data element, a composite data element, or a component data element (cf. mandatory). (ISO 9735) |
Data element |
A unit of data which, in a certain context, is considered indivisible. (ISO 2382/4.) UN/EDIFACT: a unit of data for which the identification, description, and value representation have been specified. (ISO 9735) |
Data element directory |
A listing of identified, named, and described data element attributes, with specifications as to how the corresponding data element values shall be represented. (ISO 9735) |
Data element name |
One or more words in a natural language identifying a data element concept. (ISO 9735) |
Data element representation |
The format (e.g., numeric, alphabetic, variable length, etc.) of a data item. (EDIFACT) |
Data element requirement designator |
See requirement designator. |
Data element separator |
A character used to separate data elements in a segment. (ISO 9735) |
Data element tag |
A unique identifier for a data element in a data element directory. (ISO 9735) |
Data element value |
The specific entry of an identified data element represented as specified in a data element directory. (EDIFACT) |
Data Interchange Standards Association (DISA), Inc. |
A nonprofit organization funded by the ASC X12 members that serves as the secretariat for the X12 and Pan American EDIFACT Board. |
Data Maintenance Request (DMR) |
A requested correction or enhancement to an existing Status 1 (Draft Recommendations) or Status 2 (Recommendations) EDIFACT message. |
Data unit |
A segment, segment group, composite data element, data element as defined in a directory and its message type specifications. (EDIFACT) |
Directory Reference Group (DRG) |
The UN group that approves all changes to UNTDID Directories (Directories that contain the EDIFACT standards). |
Directory version |
An indication of the issue of a Directory. It includes the last two figures of the year of agreement and a third figure indicating whether it contains UNSMs or TRIAL message types with respective, supporting material. (EDIFACT) |
Draft Standard for Trial Use (DSTU) |
U.S. EDI transaction set proposed standard until approved by ANSI. |
ECE |
Economic Commission for Europe. See UN/ECE. |
EDCD |
Directory of composite data elements included in UNTDID. (UN/EDIFACT Procedures) |
EDED |
Directory of data elements included in the UNTDID (a subset of the UNTDED). |
EDI for Administration Commerce and Transport (EDIFACT) |
The international EDI standard for the electronic exchange of commercial information between trading partners. Set by the UN and administered in the US by DISA. |
EDIFACT Board |
The advisory and support team for a UN/EDIFACT Rapporteur. See rapporteur advisory and support team. |
EDMD |
Directory of messages included in UNTDID. (UN/EDIFACT Procedures.) |
EDSD |
Directory of segments included in the UNTDID. |
Electronic Commerce (EC) |
A concept and implementation that includes a range of enabling technologies supporting the timely digital exchange of business information and includes but is not limited to Electronic Data Interchange (EDI), Electronic Mail, bar-coding, electronic funds transfer, electronic bulletin boards, electronic security technologies (e.g., public key encryption), and electronic catalogs. |
Electronic Data Interchange (EDI) |
Exchange of formation from one computer system to another without human intervention. |
Electronic Data Interchange (EDI) translator |
Computer software that translates a host application data to and from an X12 EDI standard transaction set. |
Electronic Data Interchange Association (EDIA) |
Wrote the original UCS and WINS standards; currently acts as Secretariat for the Ocean, Rail, Motor, and Air EDI standards. Hosts the annual Pan American EDI conference. |
Electronic Funds Transfer (EFT) |
The electronic transfer of funds from payer to payee through the banking system. |
File Transfer Protocol (FTP) |
A communication protocol for the transfer of files from one computer system to another. The most popular file transfer protocol, FTP, is prevalent on the Internet and is described in MIL-STD 1778. |
Formal trial |
A (Status 1) Draft Recommendation phase in UNSM development, agreed by WP.4, before a draft UNSM reaches the status of Recommendation (Status 2). N.B. This does not preclude prior testing. (UN/EDIFACT Procedures) |
Functional Group |
One or more EDIFACT messages of the same type containing a header segment and a trailer segment to denote the beginning and the end of the group. |
Functional group header |
The service segment heading and identifying the functional group. (ISO 9735) |
Functional group trailer |
The service segment ending a functional group. (ISO 9735) |
Functional group |
One or more messages of the same type headed by a functional group header service segment and ending with a functional group trailer service segment. (UN/EDIFACT Procedures) |
Functional requirement |
Identification of the business or administrative needs to be met. (UN/EDIFACT Procedures) |
GE.1 |
UN/ECE WP.4 Experts on Data Elements and Automatic Data Interchange, meeting in the framework of WP.4. |
GE.2 |
UN/ECE WP.4 Experts on Procedures and Documentation, meeting in the framework of WP.4. |
Generic data element |
See qualified data element. (EDIFACT) |
Group of segments |
Identified, usually repeatable, grouping of segment. |
Hub |
Also called sponsors, hubs are large companies, very active in EDI, that strongly encourage their paper-based business partners to begin using EDI. |
Identifier |
A character or group of characters used to identify or name an item of data and possibly to indicate certain properties of that data. (ISO 9735) |
Implementation Convention (IC) |
An agreement between trading partners on how they will interpret the meaning of data elements in an EDI transaction set or message. |
Interchange |
Communication between partners in the form of a structured set of messages and service segments starting with an interchange control header and ending with an interchange control trailer. (ISO 9735) |
Interchange agreement |
Document, usually in the form of a user manual, which describes level of syntax, messages, legal, and security requirements, etc. |
International Organization for Standardization (ISO) |
An international organization with representatives from member countries that develops and approves international standards. International Organization for Standardization, based in Geneva, it is a federation of national standards organizations. |
International Telecommunications Union (ITU) |
A UN organization with responsibility for the development of international telecommunications standards. |
ISO 7372 |
ISO Trade Data Elements Directory, identical to sections 1, 2, 3, 4, and 9 of UNTDED. |
ISO 8859 Character Sets |
ISO 8859-1 supports the following languages: Afrikaans, Catalan, Danish, Dutch, English, Faeroese, Finnish, French, German, Galician, Irish, Icelandic, Italian, Norwegian, Portuguese, Spanish, and Swedish. ISO 8859-1 is just one part of the ISO-8859 standard, which specifies:
|
|
|
ISO 9735 |
International Standard issued by ISO which reproduces the UN/EDIFACT Syntax Rules as agreed by WP.4. |
Mandatory |
A statement in a segment or message directory that specifies that a segment, a data element, a composite data element, or a component data element must be used. (ISO 9735) |
Message |
An ordered series of characters intended to convey information. (ISO 2382/16) UN/EDIFACT: a set of segments in the order specified in a message directory starting with the message header and ending with the message trailer. (ISO 9735) Equivalent to a transaction set. |
Message directory |
A listing of identified, named, described, and specified message types. (EDMD, TRMD, and EDIFACT) |
Message header: |
The service segment starting and uniquely identifying a message. (ISO 9735) |
Message trailer |
The service segment ending a message. (ISO 9735) |
Message type |
An identified and structured set of data elements covering the requirements for a specified type of transaction, e.g., invoice. (ISO 9735) |
Organization for Data Exchange Through Telecommunication in Europe (ODETTE) |
ODETTE has an EDI standard used by the European Automotive Industry. |
PA/EB |
Pan American EDIFACT Board. Support and advisory team for the Pan American Rapporteur. |
Proprietary Standards |
Industry specific or company specific data formats that do not comply with ASC X12 standards. |
Qualified data element |
A data element whose precise meaning is conveyed by an associated qualifier. |
Qualified data segment |
A data segment whose precise meaning is conveyed by an associated qualifier. |
Qualifier |
A data element whose value shall be expressed as a code that gives specific meaning to the function of another data element or a segment. (ISO 9735) |
Rapporteur (UN/EDIFACT rapporteur) |
Person nominated by his/her government and appointed by UN/ECE/WP.4 to initiate and co-ordinate UN/EDIFACT development work in his/her geographical area of jurisdiction. The nomination must be endorsed by the countries in that area of jurisdiction. (UN/EDIFACT Procedures) |
Release character |
A character used to restore to its original meaning any character used as a syntactical separator. (ISO 9735) |
Release |
A unique sub-issue of a Directory Set within a Version. Releases are used to further define Version publications of the UN/EDIFACT standards. See Version/Release. |
Repeating segment |
A segment that may repeat in a message as specified in the relevant message type specification. (ISO 9735) |
Requirement designator |
Specifies whether an element or segment is mandatory or conditional. Also referred to as status. |
Section control segment |
A service segment used to separate header, detail, and summary sections of a message where necessary to avoid ambiguities in the message segment content (EDIFACT). |
Segment |
A predefined and identified set of functionally related data element values that compose an X12 transaction set or an EDIFACT message. |
Segment |
A predefined and identified set of functionally related data elements values that are identified by their sequential positions within the set. A segment starts with a segment tag and ends with a segment terminator. It can be a service segment or a user data segment (EDIFACT). |
Segment directory |
A listing of identified, named, described, and specified segments. (ISO 9735) See EDSD. |
Segment table |
A table showing the sequential order of segments, their arrangements in segment groups, and the status and allowed repetitions of the segments and groups in a message. |
Segment tag |
A composite data element in which the first component data element contains a code that uniquely identifies a segment as specified in the relevant segment directory. Additional component data elements can be conditionally used to indicate the hierarchical level and nesting relation in a message and the incidence of repetition of the segment. (ISO 9735) |
Segment terminator |
A syntax character indicating the end of a segment. (ISO 9735) |
Separator character |
A character used for syntactical separation of data. (ISO 9735.) Also known as a delimiter. |
Service segment |
A segment required to service the interchange of user data. (ISO 9735) |
Service string advice |
A character string at the beginning of an interchange defining syntactically delimiting characters and indicators used in the interchange. (ISO 9735) |
Simple segment |
A segment that requires no qualification, i.e., whose meaning is fixed and explicit. |
Status (1) |
UN/EDIFACT documents/messages bear an indicator of their development level. They can have the following status: Draft Document Status 0 (zero),
|
Status (2) |
Indication whether a segment group, segment, composite data element, or data element item is mandatory (M) or conditional (C) in the application concerned. |
Sub-set |
An extract of a message type for use within an industry or application. The extract shall follow the rules for omission of data units, and the subset usually indicates only those units needed by the industry or application. See UNSM sub-set. |
Summary section |
The portion of the message that follows the body of the message and that contains summary information relating to the entire message. Synonymous with summary area. |
Syntax rules |
Rules governing the structure of an interchange and its functional groups, messages, segments, and data elements. (ISO 9735) |
Trading Partner |
An organizational entity (government, private sector, association, small, or large business) that has a commercial relationship with another entity. |
Trading Partner Agreement (TPA) |
A legal document between two trading partners that defines general EDI procedures, terms, and conditions, and the EDI transaction sets that will be used. |
Transaction Set |
A complete business document such as an invoice, a purchase order, or a remittance advice. |
UN/ECE |
United Nations Economic Commission of Europe, one of the five regional commissions of the United Nations. It is composed of North America, Western Europe, and Eastern Europe. Headquarters are in Geneva (UN/EDIFACT Procedures). |
UN/ECE WP.4 |
Working Party on Facilitation of International Trade Procedures, a subsidiary body of UN/ECE Committee on the Development of Trade. WP.4 includes national delegations appointed by governments and international organizations having consultative status with UN or invited by the Secretariat. It is composed of experts on data elements and automatic data interchange (GE.1) and experts on procedures and documentation (GE.2) that are appointed by their governments or by organizations recognized by UN/ECE. |
UN/EDIFACT |
United Nations rules for Electronic Data Interchange for Administration, Commerce, and Transport. They comprise a set of standards, directories, and guidelines for the electronic interchange of structured data, and in particular that related to trade in goods or services, between independent computerized information systems. Recommended within the framework of the United Nations, the rules are approved and published by the UN/ECE in the United Nations Trade Data Interchange Directory (UNTDID) and are maintained under agreed procedures. UNTDID includes:
|
UNCID |
Uniform Rules of Conduct for the Interchange of Trade Data by Teletransmission, developed by the International Chamber of Commerce. (UN/EDIFACT Procedures) |
UNTDED |
United Nations Trade Data Elements Directory, part of which constitutes ISO 7372. It includes the standard data elements and associated codes. UNTDED is jointly maintained by the UN Secretariat and ISO. (UN/EDIFACT Procedures) |
UNTDID |
United Nations Trade Data Interchange Directory. See UN/EDIFACT for documents included in the UNTDID. (UN/EDIFACT Procedures) |
Value Added Network (VAN) |
A communications network owned and operated by a commercial entity that provides EDI communication services (transmission, receipt, storage, electronic mail boxes, etc.) to customers (i.e., trading partners). |
Risk Analysis and Management Glossary
This glossary of risk analysis and management terms includes the risks associated with the use of electronic commerce by DOD procurement activities. The definitions were extracted from ECPAT93 discussions or Risk Analysis and Risk Management (Volume 1, Chapter 4, Risk Management Plan). Supplementary remarks added by this report are denoted in italics.
Records Retention |
Procurement Records Retention. Risk Category: Functional. Records retention is required for three years after final payment for small purchase transactions in the Federal Government. With a volume of 11.9 million transactions in FY92 for DOD, the issue of records retention represents a significant savings opportunity because each transaction must be filed by both the buying and finance offices involved in the transaction. |
Unauthorized Access to Contractor Quote Data |
Access to Electronic Records of Contractor Quote Data. Risk Category: Functional. Access to Contractor quote data is limited to only those procurement officials involved in the procurement. Every reasonable effort is made to ensure that quote data is protected from disclosure. Any communication method used to transmit procurement data must protect the confidentiality of the data. EDI procedures and communications architecture must retain the current level of security that is afforded the paper-based process. |
Best Value |
Quotation and Proposal Evaluation Method. Risk Category: Functional. The use of quality vendors is of great importance to DOD. This policy must be balanced with the philosophy of disseminating solicitations to the public at large in order to ensure that we achieve maximum competition. |
Organizational Structure/Changes |
Changes in the procurement organization to accommodate business process improvements, mission change, or change in the scope of existing responsibilities. Risk Category: Functional. It is important to ensure that the organizational structure is in place to accommodate the business process improvements that are necessary to transition to an EC/EDI environment. Failure to restructure organizations and identify new roles and responsibilities in an EC/EDI environment may result in unaccomplished tasks. |
EDI Preference |
Preference for EDI versus Paper as the Media for the Exchange of Procurement Information. Risk Category: Functional. The regulatory environment must address a preference for EDI transactions in order to reduce the tendency for organizations and businesses to continue the use of paper-based applications. To maximize the savings associated with EDI, we must pursue its implementation to minimize the impact of budgetary cuts. Electronic transactions are less costly to produce and transmit than paper documents. Therefore, failure to transition to an EC/EDI environment is detrimental to the development of an efficient DOD contracting process. |
Offer Equal to Brand Name |
Product Substitutability in Vendor Quotation Offer. Risk Category: Functional. Allowing an offer equal to brand name in the EDI procurement process significantly reduces the buyer productivity. Each substitution requires manual intervention and evaluation to ensure that the product substituted will meet the end user's need. Allowing product substitution will decrease the potential EDI savings for the DOD. Prohibiting substitutability may increase item costs by limiting competition (e.g., cost of generic drugs vs brand-name drugs). |
User Acceptance |
Acceptance of EDI by Contracting Personnel Risk Category: Functional. Contracting personnel must embrace EC/EDI to fully realize the benefits of this technology. Some users may be reluctant to change to the EC procedures. Risk behavior is assumed to occur even after a reasonable amount of initial and follow-on training. |
Notice to Industry |
Advice Industry Trading Partners of Intent to Conduct Business through EDI. Risk Category: Functional. Industry trading partners must be informed of the Government's intent to use EC as well as the standards and procedures to be used. Premature notice without execution or late notice to Industry trading partners may initially forfeit some of the anticipated benefits of EC. Risk behavior could include "no-quotes" or fewer quotes. |
Increase in Quote Evaluation Time |
Time for Evaluation the Anticipated Increase In Quotations per Request for Quotation. Risk Category: Functional. Use of EC could result in more quotes than historically received in response to the Request For Quotations (RFQs); consequently, more time will be required for the evaluation process. Failure to carefully monitor the number of quotes received in response to RFQs could result in buyers spending an inordinate amount of time reviewing a large number of quotes for relatively small dollar actions. Implied Assumption that all evaluation is manual. Evaluation support software may be needed to identify competitive price range and provide bidder quality data. |
Use of Bulletin Boards |
Use of Electronic Bulletin Boards to disseminate procurement information (Requests for Quotes, Announcement of Awards). Risk Category: Functional. The Government currently uses Electronic Bulletin Boards (EBBs) at some contracting activities as an EC approach. Continued use of EBBs and non-EBB approaches may segregate trading partners or result in redundant administrative costs in quotes. At the same time, EBBs are an excellent low cost alternative that saves the Government money. |
ARCHIVE (ARCHIVAL QUALITY OF STORAGE MEDIUM) |
Risk Category: Technical. Archiving is the process of storing key information. Accurate and safe storage for EC/EDI transaction information will be required. Electronic storage of data in mediums provided that can be easily displayed electronically or transported to hard copy is critical. Optical disks provide a secure, long-lasting archival storage technology. |
Security (Viruses) |
Risk Category: Technical. Hardware, software, and data must be protected from direct or inadvertent tampering. Classified and sensitive data must be protected as well. Because EDI requires electronic connectivity with a large number of networks and processors outside DOD control, the system is vulnerable to unauthorized access. Unauthorized access can come in many forms (e.g., virus, illegal entry) and can cause significant damage, violate the confidentiality of vital information, and impede competition. Even those under DOD control will be more vulnerable to inadvertent security violations due to data sharing and distributed processing. This may be an archival security risk, or could possibly lead to security violations. |
Transaction Syntax Standards/Information Re-use (ANSI X12/EDIFACT Alignment) |
Risk Category: Technical. Common procedures and business practice allow communication between partners to occur more efficiently. Information reuse is the multiple use of data by several partners. EDI requires conducting business in mutually agreed upon transaction formats (syntax). Because there is no single, universally agreed upon syntax for every business activity, there is some risk that a DOD syntax will not be supported by some contractors, thus precluding EC within that group. In addition, the DOD EDI syntax may conflict with other DOD syntax standards (primarily Command, Control, Computers, Communications, and Intelligence (C3I), e.g., United States Message Text Formats) and thus preclude information re-use within DOD. Implicit is the assumption that business data and C3I data overlap and that software filters cannot be developed. If there is overlap in data (e.g., a logistical requirement for more ammunition), software filters can be developed to extract the key C3I data and map it into an EDI format (e.g., Electronic Purchase Requisition to be sent to a procurement activity). ANSI X12 to EDIFACT alignment is the subject of this transition road map. The feasibility of X12 EDI to EDIFACT software filters is being investigated under the Statement of Work referenced on the Title Page. |
Data Standards/Data Re-use |
Risk Category: Technical. DOD standards are being developed for data administration, data elements, and the re-use of data. Every attempt should be made to ensure that EC/EDI systems are in compliance with the developed standards. DOD is committed to data standardization through the Defense Data Standardization Program for the Defense Data Repository System. The EDI community may use data in conflict with DOD data elements. This conflict can preclude data re-use. DOD Implementation Conventions can define the conventions to be used within an EDI Transaction Set where interpretation of the data elements is left to the trading partners.. Where there is latitude in the EDI transaction set, definitions/values consistent with DOD data element definition may be defined. Alternatively, ANSI X12 data elements in transaction sets used by DOD should be added to the DDRS with the approved DOD Implementation Conventions. The differences in data definitions between ANSI X12 and EDIFACT are the key issue here in assessing transition alternatives. |
Communications Infrastructure |
DOD Network Communications to Support Procurement through Electronic Commerce. Risk Category: Technical. The amount of data and connectivity requirements for distribution points must be sized to ensure the Defense Information Systems Network (DISN) can support the increased requirement. EDI will require electronic connectivity and capacity not required by paper-based business practices. The commercial and DOD communications infrastructure required for connectivity and capacity may not be cost effective for some organizations/activities. |
Coop (Redundancies/ Denial/ Availability/ Parallel Processes) |
Risk Category: Technical. EC/EDI capability will be implemented on COTS computer hardware and software. Information will reside at many sites and be transported over DOD networks to/from Industry systems/networks. Service interruption is the inability to transmit data from the procurement automated information system to the Gateway and from the VAN user to DOD systems. Routers with alternative paths over communication links can route information to/from procurement activities and distribution points. Alternate communication links within DOD must be identified to provide the connectivity between DOD procurement activities and the distribution point(s). Communication links between the supplier and the point of entry(s) into the DOD Network should be a private sector choice. Such connectivity may be provided by a Value Added Network or by access to the Internet through a network access provider. |
EDI Evolution (Obsolescence, Rapid Expansion, and Technical Availability) |
Risk Category: Technical. EDI as a technology is provided through computer software. COTS and Government-Off-The-Shelf (GOTS) software for EC capability is available. EDI capability is not realized through specific hardware, but rather through software implementation. If EDI capabilities are implemented in a static or proprietary manner, maintenance, technology insertion, and EDI evolution (both technical and functional) will be adversely affected. Program Management should assure that EDI choices are consistent with the Technical Reference Model for Open Systems. Trading Partner Agreements and Implementation Conventions will affect the number of EDI mappings, the number of EDI version and releases that must be supported, and related software maintenance tasks for procurement systems that interface with the EDI translation software products. |
War Fighter Support (War Zone Capabilities) |
Risk Category: Technical. EC/EDI capability will be needed during a war-time scenario. Peace time capability must work "as is" in war. The ability to execute transactions to order and fill theater needs must be accurate and efficient, and must not interfere with C2 information requirements. EDI computer and communications requirements may reduce, or even eliminate, the ability to provide support within an isolated Theater of Operation. This may also overload tactical communication systems, delaying critical C2 information. Current tactical logistics support systems provide the capability to identify material needs and transmit those needs electronically via MILSTRIP to stock points. Modification of these tactical supply systems for EDI capabilities is a DOD policy issue and a potential Concept Of Operation Issue. The policy issue depends on the Concept of Operation. In-house DOD requisitioning from a tactical theater to a stock point is already done electronically via MILSTRIP. If the Concept of Operation calls for the in-theater logistics support element ordering supplies directly from a commercial supplier who accepts only EDI transactions, then existing in theater logistics support systems must be modified to support EDI. Standard EDI transactions are between the government (DOD procuring activity) and the supplier. From the logistics end-user perspective, the relevant EDI transaction is the ANSI X12 Procurement Request (Transaction Set 511) where the material is not in stock and the item must be procured. Back-end software filters at the stock point (not in theater) can map current system outputs to the EDI 511 and provide E-Mail or other electronic acknowledgment expected by the current in-theater logistics systems to the requester. Integrated planning of retail logistics orders with wholesale supply and procurement systems can provide for the evolutionary upgrade to tactical logistics software systems to provide improved performance capabilities over current implementations. |
Office Of The Secretary Of Defense (OSD) Senior Leadership, Direction, Management, Authority, and Resources |
Risk Category: Program. An OSD senior leader is needed to generate the enthusiasm, support, resources, and policy changes required to accomplish EC implementation and continued operations while overcoming resistance and impediments to EC. If the DOD program manager for EC is lacking the authority and resources to implement and operate the EC network, DOD will be unable to achieve its business and acquisition reform goals. |
Component Implementation |
DOD Service Component Implementation of EC. Risk Category: Program. Implementation of EC and its supporting infrastructure at the component level will be executed according to that Component's requirements and architecture and may lack a DOD corporate approach. Uncoordinated component implementation endangers the success of the DOD EC program due to differing strategies, technical solutions, and functional requirements. Private Industry cannot effectively adjust its business practices for each DOD contracting organization. |
Single Point of Entry |
Single Point of Entry into DOD Contracting Network. Risk Category: Program. Trading partners currently conduct EC/EDI business using many different access methods, conventions, and systems. If contractors must use multiple points of entry for access to DOD's activities, the number of contractors available to each contracting office will be reduced based upon the cost of maintaining these communication links. Access to the DOD Contracting Network must provide at least two entry points for reliable communications (If the primary and only entry point in the Contracting Network system goes down, then the vendor cannot communicate his bid to the procuring activity and perhaps miss a required quotation submission time/date). |
Central Contractor Registration |
Risk Category: Program. The registration of contractors conducting EC with DOD should be managed by and accessed through a single point of entry. (Interpret this as a single Registration Center). Current legacy systems require a data record on each contractor with whom it will do business. Absent this information, the activity cannot make an award without receiving the data from the contractor. A single agency such as DLSC or a Registration MegaCenter should register and maintain vendor EDI data such as electronic address SIC codes, DUNs identifier. Mirror sites may be used to maintain copies of this database and provide vendor information to authorized users. The Registration MegaCenter or DLSC should be designated as the master site and configuration manager. |
National or Regional Visibility |
Range of Dissemination or Procurement Data Risk Category: Program. The technical architecture should provide the option to disseminate request for quotations and other documents on a nationwide basis, or limit the dissemination to a regional/local trade area or on a one-to-one basis (see Chapter 3). |
Electronic Signatures |
Risk Category: Program. Documents are executed with electronic data codes, encrypted or otherwise protected, that signify approval by the named official. Many contractors and Government offices are reluctant to accept electronic documents due to the absence of a signature. Some regulations used in DOD require original signatures, including the Federal Acquisition Regulation (FAR), for procurement documents such as a bilateral purchase order. Changes to the FARs will be required to permit electronic signatures. Public Key Encryption technology exists to provide and protect electronic signatures and guarantee non-repudiation by the originator. |
Data Integrity - Destruction/Modification or Loss of Contractor Quote Data |
Risk Category: Program. Overall security responsibility belongs to the owner of the business process. The contracting activity must be assured that the data transmitted is received in total by the trading partner. |
Interface with Other Business Areas |
Risk Category: Program. To ensure that EC has a global impact within DOD, the various business areas (e.g., contracting, contract management, finance, transportation, etc.) must develop the appropriate EDI transaction sets in a coordinated manner. Development of EC for contracting, without considering interface to other business areas, can result in misalignment of the functional areas. Electronic Funds Transfer for the payment of invoices is another EDI area that can result in significant cost avoidance and provide prompt payments to vendors. |
VAN Agreements |
Risk Category: Program. VAN agreements are made to establish a trusted third party to support contractor trading partners in effectively using EC to conduct business with DOD contracting activities. Without adequate and consistent agreements, VANs and the contractors will be required to operate EC capabilities differently for various buying activities. Acceptable VAN performance cannot be readily assessed or ensured. VAN cost based on current rate structures is a significant issue for small businesses that may prevent some vendors from implementing EDI for government business only. |
Internal Distribution |
Risk Category: Program. Many organizations must establish EC connections and use appropriate conventions and translations into their operations. This presents many opportunities for failure to complete EC communications. EC Implementation Guidelines published by the DOD can provide the guidance necessary to assure successful implementation of EC and the transition to a single EDI standard. In 1991, the DOD Executive Agent for Electronic Commerce published such a guideline. The Federal Electronic Commerce Acquisition Program Management Office (ECA-PMO) has just published a Federal Implementation Guidelines for Electronic Data Interchange as of August 31, 1994. (ECA-PMO94a.) |
Software Development Costs |
Risk Category: Program. This represents the costs that are needed to develop software for all of the various components' "legacy" systems regardless of business area to create the "single face to industry." The availability of COTS translation software products, and the various "legacy" systems now in use by the various DOD components, make software development specifically for EC applications makes a high risk. If all transactions are sent using the standard conventions, data standardization among the various business areas can be achieved. Other significant software costs include the integration of COTS EDI mapping software with DOD legacy systems for procurement, and integration with a National Vendor Registration Database. |
Government Dependency on Proprietary Industry Solutions |
Risk Category: Program. As with Software Development, DOD cannot rely on any type of proprietary data to implement EC. The use of EC within DOD should be compatible with the existing "legacy" systems now in use, and the solution should be sought in the "migration" or "target" system. The development of EC standards must be made in concert with Industry, but not be driven by Industry. |
Different Functional/Technical Solutions |
Risk Category: Program. As DOD strives toward "target" systems in the various business areas through the respective CIM Councils, efforts are underway to identify business process improvements through business modeling efforts. These modeling efforts show the business process from "As-Is" and "To-Be" perspectives. The technical and/or functional solutions developed must be made in concert with one another in order to implement the "single face to industry" concept. DOD cannot rely on component unique solutions, whether functional or technical. If DOD is to have the "single face to industry," it is imperative that a single solution represent the business process improvements that have been identified in the modeling efforts. |
DOD Standards Availability (Implementation Conventions) |
Risk Category: Program. In December 1991, the DOD Executive Agent for EDI published the DOD Implementation Guidelines for Electronic Data Interchange. This document provided the first version of the draft Implementation Conventions (ICs) to be utilized in DoD. Since the issuance of the above document, several other systems have been deployed with EC/EDI capability, utilizing different ICs. To overcome and maintain effective standards availability, DOD must centralize control over all IC documentation. |
Re-engineering Business Practices |
Risk Category: Program. Business process improvement leads to new and more efficient ways of doing business. Changes to the current processes and procedures will lead to new automated solutions. A major benefit of EC/EDI is to provide information technologies that allow for efficiency improvements. Applying EDI without re-engineering the associated business practices may preclude DOD from realizing potential savings and may adversely impact the situation by accelerating the rate of information transfer. |
Functional Economic Analysis Glossary
This glossary of functional economic analysis terms includes the cost element terms associated with the use of electronic commerce by DOD procurement activities. The definitions were extracted from the Functional Economic Analysis Guidebook, Version 1.0, January 15, 1993.
Action Plan |
The schedule for integrating and implementing a given alternative's slate of initiatives (also called an implementation plan). |
Activity |
A named process, function, or task that occurs over time and has recognizable results. Activities consume assigned resources to produce products and services. |
Activity Based Costing |
An accounting technique that allows an enterprise to determine the actual costs associated with each product and service produced by that enterprise without regard to the organizational structure of the enterprise. |
Activity Cost |
The total of all costs (both fixed and variable) expended in performing an activity for a time period. |
Activity Measure |
A performance value assigned to an activity's primary output. |
Activity Model |
Model of the processes that make up the functional activity showing inputs, outputs, controls, and mechanisms through which the processes of the functional activity are (or will be) conducted. |
Actuals |
The true value of a cost or performance measurement realized during program implementation. |
Alternative |
An implementation approach or strategy that can realize a functional activity's desired TO-BE state. |
Approval Decision Package |
An integrated set of documents that consists of the Final FEA, data management and technical management planning documents, and appropriate recommendations. The OSD Principal Staff Assistant is the approval authority for the Approval Decision Package. |
Baseline |
The initial baseline is the financial profile of the funds needed to satisfy current and future workloads. An approved baseline is an approved plan describing the resources needed, using current processes and reflecting pending changes, to satisfy current and future workloads. |
Benefits |
Outputs or effectiveness expected to be received or achieved over time as a result of implementing an alternative. Monetary benefits are normally an in-flow of cash, such as revenues. Within the FEA context, monetary benefits are cost savings. Benefits can be quantifiable in terms of dollar value or some other measure of productivity, or non-quantifiable as in the case of intangible effects such as increased morale. |
Capital Asset |
Assets of a permanent character having continuing value. Examples are land, buildings, and other facilitates including equipment. |
Civilian Labor |
Cost element in the FEA Model. The total civilian pay cost, including both gross pay and all personnel benefits (e.g., retirement, health insurance, etc.) |
Constant Dollars |
A cost estimate in which costs reflect the level of prices of a base year. Cost estimates expressed in current dollars hold the purchasing power of the dollar unchanged over the analysis period and do not consider the effects of inflation on purchasing power. |
Cost |
A resource input to a project, program, or activity expressed in US dollars. |
Cost Driver |
A factor that causes a cost to be incurred in performing an activity. |
Cost Elements |
Specific resource inputs to projects, programs, or activities. The FEA cost elements include Civilian Labor, Military Labor, Information Technology, Facilities, Materiel, and Other. |
Cost Savings |
Difference between the costs of the current course of action (baseline) and the costs of a proposed alternative course of action. |
Current Dollars |
Cost Estimate convention used to show the purchasing power of the dollar in the year costs or cost savings are incurred. Current dollars consider the effects of inflation on purchasing power. |
Discounting |
The process of converting future dollars into their equivalent present value, reflecting the time value of money. |
Evaluation Decision Package |
The forma decision document that includes the Preliminary FEA, activity models, data models and other appropriate information required for the functional manager to make a preliminary evaluation of the proposed alternative courses of action. |
Facilities |
Cost element in the FEA Model. Includes all costs in owing, leasing, and operating a facility. These costs include costs for construction (including modification) if purchased, leasing costs if rented, and appropriate utility costs, repair and maintenance, and services. Non-cash charges such as depreciation are excluded. |
Final FEA |
The revision to the Preliminary FEA that is included in the Approval Decision Package. It contains a more detailed analysis based on a refinement of the cots, benefit, and schedule data that were included in the Preliminary FEA. |
Function |
A functional area under the direction of an OSD Principal Staff Assistant or the area's subordinate activities, each under the direction of a functional manager. |
Functional Direction |
The top-level objectives, measures, and strategies that provide the scope and guidance to a functional activity. |
Functional Economic Analysis (FEA) |
The methodology used in an FPI to evaluate and rank alternative ways to achieve functional objectives. FEA is also the name given to the document defined in DOD 8020.1-M. It contains eight sections: Section 1: Functional Area Strategic Plan Summary; Section 2: Functional Activity Strategic Plan Summary; Section 3: Functional Activity Performance Targets and Measures; Section 4: Proposed Functional Activity Improvement Program; Section 5: Economic Analysis of Proposed Process; Section 6: Data Management and Information System Strategy; Section 7: Data and System Changes; and Section 8: Data and System Cost Analysis. |
Functional Process Improvement (FPI) |
The functional management process for implementing the Defense information management program. The application of a structured methodology to define a function's "As-Is" environment; its objective and strategy for achieving those objectives; and a program of incremental improvements made through functional, technical, and economic analysis, and decision making. |
Improvement Opportunity |
A potential change in a business process that either corrects a process deficiency or implements a best practice. |
Initiative |
A specific set of actions that are based on one or more improvement opportunities. |
Inflation |
A persistent rise in the general level of prices over time, which results in a decline in the purchasing power of money. Measured by changes in price indices relative to some base year. |
Information Technology |
Cost element in the FEA Model. Represents the cost of hardware (including peripheral equipment), software, and related telecommunications equipment purchased from commercial sources. Non-cash charges such as depreciation and amortization are excluded. |
Management and Support |
Cost category in the FEA Model. Includes costs other than operational costs. Such costs are considered to be indirectly related to the primary output (product or service) because they cannot be easily or economically identified with the output. The costs typically support more than one primary output. (Note: may be called General and Administrative Costs in the Commercial Sector.) |
Materiel |
Cost element in the FEA Model. Costs associated with the purchases of office furniture, equipment (non-computer), and supplies including printing and postage. |
Military Labor |
Cost element in the FEA Model. The total of all officer and enlisted pay, including allowances and retirement. |
Model |
An abstraction of a real-world object, process, or activity that allows analysis and decision making. A representation of a complex, real-world phenomenon, e.g., an activity model represents a functional activity at some point in time; an FEA model represents activity levels over time. |
One-Time Cost |
Expenditures usually related to the purchase of capital assets or other items that are charged on a non-annual, non-repetitive basis (e.g., an initial training, or an initial tooling). |
Other |
Cost Element in the FEA Model. Includes project travel, specific job-related technical training, and transportation that are not covered by other costs elements. Also, includes hardware and software maintenance and support, and telecommunications usage costs (not investment). All non-cash charges such as depreciation and amortization are excluded. |
Operations |
A primary cost subdivision in the FEA Model. Includes costs associated with essential functional processes that are directly related to the primary output(s) of a function or its intended customers. Each cost element (civilian labor, military labor, information technology, facilities, materiel, and other) is divided into either Operations or Management and Support. |
Performance Measure |
A relevant, observable factor used to assess or quantify the speed of responsiveness, quality, or cost of a process, input, or output related to a performance objective. |
Performance Objective |
A quantification of an intended or targeted process, input or output based on some factor (i.e., performance measure) used to indicate a unit of output. |
Preliminary FEA |
The principal document in the Evaluation Decision Package. It is used to conduct an initial "rough order of magnitude" assessment of proposed alternatives to the "AS-IS" process, data, and, system baselines from readily available information. |
Primary Output |
The single measurable result of an activity by which the cost of an activity is accumulated. |
Process |
A chain of activities, which may cross organizational boundaries, that produces a common product. |
Real Discount Rate |
The interest rate used to convert future dollars into present dollars. |
Recurring Costs |
Expenses for personnel, materiel consumed, operating overhead, support services, maintenance, and other items that are charged annually or repetitively in the execution of a given program or work effort. |
Residual Value |
Costs that extend beyond the six-year period of data entry allowed by the FEA Model. (The sixth year of costs for each alternative and the baseline is repeated based on the number of years in the life-cycle specified by the user.) |
Risk |
The change that the actual future costs or returns (or values) will deviate from the expected costs or returns. |
Risk Adjusted Discounted Cash Flow (RADCF) |
A summary measure of annual cash flows using discounting to convert to present value and risk analysis to reflect possible deviation from expected costs or savings. |
Sunk Costs |
Unrecoverable past costs incurred before the analysis. They have no significance to the analysis and should not be included. |
Tooth-To-Tail Ratio |
The dollar magnitude of Operations-related cots divided by the dollar magnitude of Management and Support-related costs. |
Unit Cost |
The cost expended to produce one instance of an activity's primary output. |
Update FEA |
A periodic progress report on the final FEA's approved alternative through which actual costs and performance improvements are compared with those projected. The Update FEA provides updated information for managers in conducting program evaluation at key decision point milestones. |
Workload |
The time-phased, expected, overall output of a functional activity. |
Variance |
The difference between the actual value of a cost or performance measurements and the value predicted in the FEA. |
Miscellaneous Glossary
This glossary of X.500 Directory, interactive-EDI, and open-EDI includes the terms associated with the provision of electronic mail directory and interactive EDI services and other concepts of EDI operations. The X.500 definitions were extracted from the X.500 Implementation Catalog in the Internet RFC 1632 Report. Other references appearing in square brackets may be found in Appendix B or the footnotes.
AECMA |
Association of European Manufacturers of Aerospace Materiels. |
Batched-EDI |
Transactions which are bundled together and transported in one envelope to the trading partner. No application level response is applicable. Used over human-to-machine or machine-to-machine interfaces. (Steel94a.) |
Basic Semantic Repository (BSR) |
This is a database which is a sort of data dictionary. Its function is to associate a specific and meaningful label to a "semantically pure" (I'll elaborate below) data element and to carry a definition of the full semantic context and import of that data element. If a code set is associated with that data element, that is also specified - although code sets are a much more serious business in the world of semantics than in the current EDI "standardization" processes. The main function of a BSR is to provide a standardized language by which Information Technologists can communicate details of interchangeable data structures associated with the use of EDI (Electronic Data Interchange) in EC (Electronic Commerce). In theory, the BSR can also extend past interchange structures into the database domains, but there needs to be a lot more research done into this to determine the wisdom of it (other methods may be more appropriate with databases), (EDI-L95a.)1 |
Basic Semantic Unit (BSU) |
A BSU is a "semantically pure" data element. Perhaps the best way to explain this is by example. Consider a product code. The Product Code identifies a particular class of object. There are many synonyms: item number, part number, assembly code, raw material code, etc., and there can be several semantic contexts: customer's product code, supplier's product code, manufacturer's product code, etc. All the synonyms, even though they convey different flavors of product code, in fact represent exactly the same thing in IT terms - an identification for a specific class of objects (EDI-L95a.). |
Business |
A series of structured activities or processes each having a clearly understood purpose, involving more than one and directed towards some collectively defined goal, extending over a period of time. In particular, it is not limited to trade or commerce (ISO 9735-3:1993).2 |
Business Agreement Service |
The logical portion of an Information Management Domain (IMD) that provides a means for Open-EDI users to establish and utilize a shared universe of discourse for semantic descriptions of the conventions, agreements, and commitments, and information content of Open-EDI operations. This service does not establish concrete syntactic level protocols for accomplishing Open-EDI. (JTC1 SWG-EDI 91.) |
Business Operational View (BOV) |
A perspective in a model of Open-EDI transactions encompassing those aspects that are of interest to and utilized by Open-EDI user communities for polling purposes. It defines the context and framework for the Business Agreement Service and for the semantics of Open-EDI operations. Within this view, conventions, agreements, and the operations are modeled in terms of scenarios, role players, roles, and information parcels (JTC1 SWG-EDI 91). |
Conversational-EDI |
A series of separate batches of segments moving in alternate directions in different envelopes. Each batch of segments in each direction is part of the same transaction. It's an interactive kind of transaction, but carried out in batched mode. Conversational-EDI is only practical over machine-to-machine interfaces, but can use VANS and E-Mail-oriented networks (Steel94a). |
Dialogue |
A two-way conversation between co-operating parties within an I-EDI transaction. It is formally composed of a pair of interchanges (ISO 9735-3:1993.) |
DIS |
Draft International Standard. |
DSA |
A DSA is an OSI application process that provides the Directory functionality (X.500). |
DUA |
A DUA is an OSI application process that represents a user in accessing the Directory and uses the DAP to communicate with a DSA (X.500). |
DUA Interface |
A DUA Interface is an application process that represents a user in accessing the Directory using either DAP but supporting only a subset of the DAP functionality or a protocol different from DAP to communicate with a DSA or DUA (X.500). |
EDI |
Transactions that are structured in a highly standardized way that facilitates use over machine-to-machine interfaces with no human intervention. (Steel94a.) |
EDI Principal |
The logical portion of an IMD that manifests the autonomous, goal oriented, decision-making aspects of real parties. The internals of EDI principals are not within the scope of the Open-EDI Conceptual Model (JTC1 SWG-EDI 91. |
EDI Support Service |
The logical portion of an IMD that provides mechanistic support services to realize the exchange of information. They must operate according to mutually accepted standards. (JTC1 SWG-EDI 91.) |
Electronic Commerce: |
Doing business using electronic communications between the trading partners as opposed to the post and voice telephone. (Steel94a.) |
Transactions intended for use with human intervention at one or both ends. E-Mails tend to be either free-form or structured, but not in a totally standardized way that permits machine-to-machine operation. | |
Functional/Service View |
A perspective in a model of Open-EDI transactions that encompasses the attributes of IMDs appropriate to the provision of generic Open-EDI support services. Provides a generalized abstract description and formal specification of the functional capabilities and abstract services needed o support instances of the Business Operational View concepts (JTC1 SWG-EDI 91). |
I-EDI |
The automatic exchange of pre-defined and structured data, which conforms to the syntax of ISO 9735-1 for some business purpose, between pairs of co-operating processes, in a timely manner. (ISO 9735-3: 1993.) |
I-EDI Transaction |
An instance of a scenario. It consists of one or more dialogues. (ISO-9735-3: 1993.) |
IETF |
Internet Engineering Task Force. |
IMD |
Information Management Domain (JTC1 SWG-EDI 91). |
Initiator |
The application that starts the dialog and/or transaction (ISO 9735-3:1993). |
Interactive-EDI |
Interactive EDI is differentiated from batch-EDI by the following characteristics: (1) Computer Application to Computer Application Exchanges, without human intervention; (2) short response time; and (3) small (bytes) messages focused on the business context (ASC X12N-94a). |
Interactive-EDI |
A transaction where the application programs of the set of trading partners are interoperating in real time. Application level responses are on a line-by-line basis. When the transaction is complete, so is the commitment at both ends. This can operate only over machine-to-machine interfaces and must use point-to-point communication facilities: Dial-up modems, Internet, raw X25. VANS cannot handle this type of Electronic Commerce (and you can forget the smoke-screen of open mail-boxes). This is the most practical way to carry out Electronic Commerce. The move from batched EDI to interactive EDI will have an even greater effect in improving business efficiency than the move from batched input using punched cards to interactive input using VDUs had 20 years ago. Both EDIFACT and X12 are almost impossible to use in this environment because of the difficulty in integrating the message (transaction set) into the application programs. This is the most compelling and urgent reason to move ahead into New-EDI. (Steel94a.) |
Interchange |
This term is used as defined in ISO 9735-1. In I-EDI, interchange has added the property of being an instance of the message flow in one direction within a dialogue (ISO 9735-3:1993). |
IS |
International Standard. |
ITU |
International Telecommunications Union. |
MIME |
Multipurpose Internet Mail Extension, an Internet Request for Comment (RFC 1341) handling multi-media objects within an E-Mail framework. |
New-EDI |
Transactions structured using flexible messaging that is designed to facilitate the interoperation of application programs between trading partners and moves ahead from the concept of paper forms. (Steel94a.) |
Old-EDI |
Transactions structured using X12 or EDIFACT that permit interoperations between partners with extreme difficulty. Preserves the concept of paper forms at the expense efficient operation. Not practical for Electronic Commerce. (Steel94a.) |
Open-EDI |
Old-EDI requires trading partners to enter into an elaborate trading partner agreement prior to the commencement of electronic trading. This inhibits ad hoc or short-term trading relationships because of the difficulty and expense involved. Open-EDI is an initiative of SC30 of the ISO. Interactive-EDI must incorporate the concepts of Open-EDI to achieve its full potential. Because there are no pre-arranged and elaborate trading partner agreements involved in Open-EDI, it is not possible to negotiate beforehand the particular implementation and the specified version of the EDI "standard" you are going to use, so old-EDI is not suitable. To operate in an open-EDI environment requires a truly standardized approach to EDI such as that offered by the flexible messaging of new-EDI. (Steel94a.) |
Open-EDI |
Electronic data interchange among autonomous parities using public standards and aiming towards interoperability over time, business sectors, information technology systems and data types3 (JTC1-SWG-EDI 91). |
Responder |
An application replying to an initiator's query. (ISO 9735-3:1993.) |
Responsive-EDI |
A series of separate batched transactions where one transaction is an application level response to a different earlier transaction. E.g., Purchase Orders and Purchase Order Responses. If a set of trading partners operates with both these transactions in their purchasing system, then they are operating responsive-EDI. Used over both human-to-machine or machine-to-machine interfaces (Steel94a). |
Role |
A role describes all possible actions of a role player during a scenario. It supports the notion that role players model autonomous decision-making entities by providing a choice of episodes (JTC1 SWG-EDI 91). |
Role Player |
Models the attributes of the EDI Principal and the Business Agreement Service relevant to the business processes in an Open-EDI operation. (JTC1 SWG-EDI 91). |
Scenario |
A formal description of a class of business activities that defines, among other things, the dialogues that may take place between the parties to achieve a particular business objective (ISO 9735-3:1993.) |
Scenario |
Formal description of a class of business activities including the semantics of business agreements, conventions, and information content. A Scenario is created by communities of users and instantiated as Open-EDI operations (JTC1 SWG-EDI 91.) |
Trading Partner Interfaces |
There are three planes of electronic communication between trading partners: (1) Human-to-Human: A human composes the business transaction at one end, transmits it to the trading partner where another human interprets and initiates action. Examples are faxes, electronic forms, voice mail; (2) Machine-to-Human: A computer composes the transaction, transmits it to the trading partner where a human interprets and initiates action. Examples are E-Mail, the majority of EDIFACT and X12 E-Mails - particularly where free text segments are used; and (3) Machine-to-machine: A computer composes the transaction in a form that can be interpreted and acted on by the trading partner's computer without any form of human intervention. Examples are rare at the moment, but some businesses with better application software have implemented X12 and EDIFACT in this way. (Steel94A.) |
1 EDI-L News Digest, "Subject: Re: Standardization of business practices," From: Ken Steel <ksteel@CS.MU.OZ.AU>, Wed, January 11, 1995 20:34:23 PST.
2 UN/EDIFACT CD 9735-3: 1993(E), "Committee Draft Part 03: Syntax rules specified to interactive EDI, plus interactive EDI service directories" Annex A, Definitions, o/a September. 1993.
3 "Report on the Open-EDI Conceptual Model," Final Version, ISO Joint Technical Committee 1 (JTC1)/Special Working Group on EDI (SWG-EDI), May 5, 1991.
