LIST OF FIGURES

      

LIST OF TABLES

      

1.0  INTRODUCTION

      

1. Strategy and test plan for testing the UN/EDIFACT ORDERS message prototype,
2. Test analysis report documenting the results of the prototype testing,
3. Strategy document for reaching out to industry and informing companies of migration plans for EDIFACT, and
4. Information package supporting the outreach strategy.

As information background, it is important to first understand what necessitated the development of the UN/EDIFACT ORDERS message prototype and testing in the DoD. The following section provides a brief background plus explains the justification for this task.

1.1  Overview and Background

The President, via Executive Order, (1994), has initiated a major program to improve Federal purchasing through the use of 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.). 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 American National Standards Institute (ANSI) X12 EDI standard, and the international UN/EDIFACT standard. The EDIFACT standards are primarily used in Europe and toa limited extent in Pacific Rim countries. 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 to, and technical migration to, UN/EDIFACT. As a result of this migration and the growing acceptance of UN/EDIFACT standards within Europe, Japan, South Korea, North Atlantic Treaty Organization (NATO), Australia and other countries, representatives of DoD and Federal procurement organizations have intensified efforts to migrate business functionality pertaining to purchase orders to EDIFACT. There is now a need to trial test the EDIFACT ORDERS message with a few U.S. firms to validate the adequacy of the message against actual requirements.

In light of this move, the business functionality of both the DoD and Federal procurement organization's purchase orders process will be trial tested using a prototype implementation of the UN/EDIFACT ORDERS message. The operational testing of the new EDI components and procedures in 'live' user environments will provide proof of intended benefits prior to widespread deployment. This will be accomplished by selecting certain U.S. firms to validate the adequacy of the message against actual applied requirements. The specific objective of this task is to test the ORDERS message in coordination with the DoD Federal Acquisition Network (FACNET) architecture within the context of Basic Ordering Agreements and simple delivery orders. In this initial report we assess the UN/EDIFACT ORDERS message from the syntax/semantics perspective, and define both an architectural framework for testing of this message, as well as assessing initial risks and requirements to be applied to the testing process. The following section explains how we plan to approach this task.

1.2  Approach

A prevailing concern in approaching this task is the uncertain final form of the UN/EDIFACT ORDERS message. The U.S. Department of Defense (DOD) is currently working through the Pan American "EDIFACT" Board to augment the "ORDERS" message in order to satisfy DOD requirements. Because changes to the ORDERS message will have an impact on this task, we must continue to be sensitive to this issue. Future versions of this report will reflect these changes triggered by the next release/version of the ORDERS message. The general approach for accomplishing the overall task is presented below in Figure 1.2-1.

Because testing of the ORDERS message involves many areas of complexity, a well defined and organized understanding of the ORDERS message and EC/EDI systems area must be embodied in our assessment. Our approach to assessing the ORDERS message will follow the steps outlined below.

• Develop a general purpose framework for testing EC/EDI systems by emphasizing sufficient structure and clarity.
• Compare ANSI X12 and UN/EDIFACT message structures.
• Perform syntactical/semantical analysis of ORDERS message.
• Identify and define EC/EDI products and processes involved in testing.
• Develop functional flow diagrams for each layer of functionality defined in this framework.
• Identify a preliminary set of risks and their potential negative impact.
• Develop a preliminary requirements classification scheme and definition strategy.
• Identify preliminary set of basic requirements.
• Plan for incorporating risks and requirements into the testing process.
• Obtain Basic Ordering Agreement and simple delivery order.
• Assess ORDERS message functionality in the context of a Basic Ordering Agreement and simple delivery order.

2.0  UN/EDIFACT ORDERS MESSAGE ASSESSMENT

      

2.1  UN/EDIFACT Message Structure

Before conducting a functional assessment of the ORDERS message, it is necessary to understand the basic structure of a UN/EDIFACT message. Recalling that for this prototype test, the UN/EDIFACT ORDERS message will be used in place of the ANSI X12 850 transaction set, it is important to consider basic structure of a UN/EDIFACT message as it relates to the ANSI X12 structure. Figure 2.1-1 illustrates the message structure of an ANSI X12 transaction set and UN/EDIFACT message.

Aside from a nearly identical message structure, the following list summarizes additional similarities:

1. Tagged and delimited American Standard Code for Information Interchange (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 that are mentioned below.

1. The 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. Looping and nesting conventions also differ.
2. There are six data element types defined in ANSI X12, while only three for 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 EDIFACT, the following three data element types exist: (1) numerical, (2) alphabetical, (3) alpha-numerical.
3. EDIFACT allows for two levels of syntax.
4. There is no provision for optional fields using EDIFACT.
5. 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.

2.2  UN/EDIFACT ORDERS Message Functional Assessment

It is important to examine the functionality of the ORDERS message to understand how to approach the testing process. Accomplishing this assessment involves examining the entities and relationships, and the business functions supported by the ORDERS message to necessitate developing a testing approach.

A detailed study of the UN/EDIFACT ORDERS message revealed that there are 54 segment groups, which are divided into three sections: header, detail, and summary sections (the standard taxonomy for UN/EDIFACT messages) as shown in Table 2.2­1 below.

There are approximately 45 data segments (refer to Table 2.2­2 below) used in the orders message, which are in turn used to make up the 54 segment groups previously mentioned. It is important to analyze the segments at the segment groups level, because each group is constructed for a particular semantic meaning. An excerpt from the 96A version of UN/EDIFACT Draft Recommendation for the ORDERS message, which provides the semantic descriptions of the purpose for each segment group, is provided in Appendix C.

A functional assessment of the UN/EDIFACT ORDERS message reveals that the ORDERS message allows a buyer to order one or more goods, items, or services. The purchase order may refer to goods, items, or services related to one or more delivery schedules, call-offs, etc. A purchase order for cross-border transactions may contain additional information for customs and/or statistical purposes. A purchase order may contain details for transport and destination as well as delivery patterns. After examining the Segment Groups, Segments, and Data Elements for the header, detail, and trailer sections of the ORDERS message particular business functions supported by this message have been identified and include the following four primary functional areas:

1. Packaging, Handling, Shipping, and Transportation;
2. Product Characteristics;
3. Financials; and
4. Rules, Laws, and Regulations

The ORDERS message supports the following functions:

1. A buyer may order one or more goods, items, or services.
2. A purchase order may refer to goods, items, or services related to one or more delivery schedules, call-offs, etc.
3. A purchase order for cross-border transactions may contain additional information for customs and/or statistical purposes.
4. A purchase order may contain details for transport and destination as well as delivery patterns.

3.0  ARCHITECTURE FRAMEWORK MODEL FOR TESTING

      

Product Areas:

1. Application Interface,
2. Data,
3. Communications/Network, and
4. Off-The-Shelf Software.

Within these 4 product areas, there are 17 specific products that may be tested. Each product area is defined in this section.

The first product area, Application Interface, simply refers to the software programs that either generate or receive relevant data for or from the EC/EDI transaction. Individual products identified in this category include:

Application Interfaces:

1. Government Automated Information System(AIS) - EC/EDI System, and
2. Business Application - EC/EDI System.

The second product area, Data, simply refers to the various data sets that are encountered in the EC/EDI process. Individual data products identified in this category include:

Data:

1. Data exported from the Government AIS,
2. EC/EDI translation process output data, and
3. Data exported as a User Defined Format (UDF).

The third product area, Communications, simply refers to the various hardware, software, and networking components necessary for transporting EC/EDI messages to and from trading partners. Individual products identified in this category include:

Communications/Network:

1. Government Gateway,
2. Electronic Commerce Processing Node (ECPN),
3. N-level Internet Protocol Router Network (NIPRnet) - Internet Bridge,
4. Value Added Network (VAN), and
5. Leased Line connection.

The fourth product area, Off-The-Shelf Software, simply refers to the various data sets that are encountered in the EC/EDI process. Individual off-the-shelf software products identified in this category might include:

Off-The-Shelf Software:

1. Translation and Mapping,
2. Database,
3. Communications,
4. EDI Mailbox,
5. Security,
6. Audit Logging, and
7. Archival and Restoration.

When considering testing any system, it is meaningful to not only examine the system as a whole, but to also examine individual test areas that make up the system. A functional decomposition of the EC/EDI process has therefore been performed and an architecture documented. This EC/EDI testing architecture demonstrates the functions that apply to all EC/EDI systems, regardless of what transaction sets or messages are being exchanged. This architecture for testing allows for requirements to be partitioned into self-contained areas of functionality and will serve as the foundation for developing a modular test plan. It should be noted that streamlining of the testing process will be facilitated using a qualification process, which will be discussed in the next deliverable (Test Plan).

The primary objective of this model is to put in place a structure on which the test plan may be developed. This model provides a framework that will be used to reference the various levels of testing involved in testing EC/EDI systems for conformance to relevant DoD requirements. To this end, a five­layered model depicting the distinct and separate levels at which testing may occur, hereinafter referred to as the "Architectural Framework Model for Testing EC/EDI Systems," was developed. This model is intended to be used as a reference guide for developing and implementing the individual EC/EDI test sets in accordance with this task.

A preliminary study of the electronic purchasing process reveals a functionally symmetrical testing architecture involving both automated business transactions and data translations that are centered around network telecommunications through which this data is transmitted between DoD and industry trading partners. The data flow for this process is bi-directional (inbound vs. outbound) as illustrated in Figure 3.0-1 below.

Table 3.0-1 summarizes the model areas and lists some characteristic areas that may be targeted for testing for each area.

When considering the interface between the EC/EDI transaction/translation systems and the application programs (i.e., order processing, purchase order generation, accounts payable, accounts receivable, etc.) the testing architecture is augmented to include two additional layers (Layer 1, Layer 5) as follows:

      Layer 1: Application Interface: Outbound
      Layer 2: Transaction Generation: Outbound
      Layer 3: Network Communications: Outbound/Inbound
      Layer 4: Transaction Interpretation: Inbound
      Layer 5: Application Interface: Inbound

Sections 3.1 through 3.5 examine the individual layers of the test architecture and provide flow diagrams for each layer of functionality defined.

3.1  Application Interface: Outbound

The outbound application interface layer represents the interface between the Government AIS and their EDI translation/transaction application. Transactions are entered via the AIS and translated to a UDF readable by the EDI translator, and then presented to the translator as illustrated in Figure 3.1-1 below.

In summary, the three functional areas for this layer include:

1. Input/editing of business data (i.e., purchase order).
2. Perform business data translation from AIS to UDF.
3. Present business data to EDI translator.

3.2  Transaction Generation: Outbound

The outbound transaction generation layer involves reading and processing the EDI transaction data for formatting and transmission of the EDI message from the Government entity to the communications system. The functional steps involved in this layer are illustrated in Figure 3.2­1 below:

In summary, the functional areas for this layer include:

1. Input/editing of business data (i.e., purchase order).
2. Present business data to EDI translator.
3. Perform data transformation from UDF to EDI format.
4. Identify trading partners.
5. Assign EDI control numbers.
6. Perform EDI compliance checking:
   
   Check that mandatory fields contain data (e.g., date and invoice number).
   Check that the optional and conditional requirements of the data are satisfied.
   Check for correct data types in fields (i.e., alphabetic, alphanumeric, numeric).
   Check data sequence by element, segment, transaction set/message, and by batch.
7. Assign data delimiters.
8. Convert data to ANSI X12 or EDIFACT standard compliant format.
9. Create audit/event/error logs.
10. Queue transactions for transmission.
11. Present EDI interchange data to communication system handler.

3.3  Network Communications: Outbound/Inbound

The communications layer represents the hardware, software, and networks within FACNET for Government and industry to interchange EC/EDI information. The primary function of this layer is to interface the ECPNs with the industry VANs. The functional steps involved in this layer are illustrated in Figure 3.3­1 below:

It is important to note that within this communications architecture the ECPN is connected to the VAN by either the leased line or the Internet - NIPRnet bridge. In either event, the same protocols are used for transmission and communications of data.

In summary, the five primary functional areas for this layer include:

1. Establish Communications Link
   
   Access Security
   Authenticate
2. Protocol Support
   
   Transmission Control Protocol /Internet Protocol (TCP/IP) [File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP)]
   Open Systems Interconnection (OSI) (X.400, X.435)
3. Receive Transaction (inbound)
   
   Decryption
   Receive EDI Message
4. Store Transaction
   
   Create/maintain Audit Logs
   Archiving
   Retransmission
5. Forward Transaction
   
   Encryption
   Transmit EDI Message
   Route to Trading Partner

3.4  Transaction Interpretation: Inbound

The inbound transaction interpretation layer involves reading and processing the EDI formatted transaction data. The functional steps involved in this layer are illustrated in Figure 3.4­1 below:

In summary, the functional areas for this layer involve the following:

1. Process EDI message data file (i.e., unenvelope the data).
2. Perform EDI compliance checking:
   
   Verify that mandatory fields contain data (e.g., date and invoice number).
   Verify that the optional and conditional requirements of the data are satisfied.
   Verify that correct data types are used (i.e., alphabetic, alphanumeric, numeric).
   Verify data sequence by element, segment, transaction set/message, and by batch.
3. Functional Acknowledgment Creation.
4. Verify trading partner.
5. Format and write data to internal business application.
6. Perform control number verification.
7. Create and maintain audit logs and error logs.

3.5  Application Interface: Inbound

The inbound application interface layer represents the interface between the Government AIS and their EDI translation/transaction system. Transactions are entered via the AIS and translated to a UDF readable by the EDI translator as illustrated in Figure 3.5-1 below.

In summary, the functional areas for this layer involve the following:

1. Supports internal business function,
2. Perform data translation (export) from EDI to UDF format,
3. Validates information content,
4. Merges EDI data with internally maintained data, and
5. Updates business application database.

4.0  RISK ASSESSMENT

      

1. Identify Risks,
2. Assess the Potential Negative Impact of the Risk,
3. Establish Control Objectives,
4. Prioritize and Categorize Risks and Control Objectives by Functional Area, and
5. Incorporate Risks and Control Objectives in the Testing Process.

For the preliminary release of this deliverable only the risk identification and impact assessment will be discussed. Risk control objectives will be incorporated in the future release of the test plan deliverable.

4.1  Risk Identification and Impact

Risks have been identified from both an analysis of the electronic procurement process and the utilization of common risk checklists for automated business applications. Preliminary risks identified thus far are categorized in the following three areas and include:

1. Communications/Network,
2. Operational, and
3. Administrative.

Risks for each of the aforementioned areas are explained in subsections 4.1.1 through 4.3.1.

4.1.1  Communications/Network

Communications/Network risks involve potential problem areas that could occur during the transmission or reception of EC/EDI data. Risks of this type may have been categorized into the following four areas:

1. Communication system failures,
2. Performance problems,
3. EDI message transmission problems, and
4. Unauthorized line access.

Communication system failures might include the service interruptions due to problems with the communication lines, VAN, Gateway, ECPN, Government Contracting Agency, or the Industry Trading Partner. The impact of communication system failures risks is highly negative. Interruption of service due to communication system failures can potentially result in lost business due to incomplete fulfillment of orders, potential loss of revenue can occur due to the inability to obtain payment for goods or services shipped, or breach of agreement between service provider and trading partner or between trading partners can occur.

The second type of communications/network risk identified, performance problems, addresses delays in transmission and or reception of data among trading partners and or within the FACNET architecture. Again the impact of the inability to deliver critical time-sensitive EDI transactions could have a highly negative impact, which could result in loss of revenue and or breach of agreement between service provider and trading partner or between trading partners. In the case of relatively small delays, the risk typically only results in a minor inconvenience.

The third type of communications/network risk identified, transmission problems, specifically addresses incomplete, lost, missing, duplicative, and or garbled messages being transmitted and or received among trading partners, as well as the possibility of EDI messages being sent and or received from the wrong trading partner. The impact of receiving incomplete, erroneous, or errant EDI messages could result in incorrect orders (types, quantities, destinations, etc.) being shipped, orders being shipped, or payment for goods or services shipped sent to wrong trading partners, etc. Loss of revenue or assets for suppliers, deprivation of goods/services for buyers, and or breach of agreement between service provider and trading partner or between trading partners can result in this case.

An additional area of risk, unauthorized line access, addresses unauthorized access to the EC/EDI communication via inside lines, via outside lines, or via VAN lines. Valuable information could be potentially extracted by tapping lines carrying EDI transmissions. Risks resulting from unauthorized line access could potentially be devastating and result in loss of business and or assets.

4.1.2  Operational

Operational risks involve potential problem areas that could occur during the normal day-to-day operation of EC/EDI systems. Risks of this type may be categorized into two basic categories as follows:

1. Unintentional, and
2. Intentional.

The first type of operational risks identified, unintentional errors, addresses areas of risk induced by invalid information introduced in the EC/EDI. Unintentionally induced errors include system errors such as translation errors, time-date errors (e.g., year 2000), and invalid operator inputs/outputs.

The second type of operational risks identified, intentional errors, addresses areas of risk maliciously induced by a human perpetrator. Intentional errors typically include either a falsification of information and or a violation of security. Intentional errors may include entering false information, or altering existing information without authorization. Security violations include falsely assuming the identity of a different trading partner, and or denial of receipt.

The impact of operational risks can be very negative. Erroneous information (intentional or unintentional) can potentially result in lost business due to incomplete fulfillment of orders, potential loss of revenue can occur due to the inability to obtain payment for goods or services shipped, or breach of agreement between service provider and trading partner or between trading partners, and having EDI messages sent to the wrong trading partner, or received from the wrong trading partner.

4.1.3  Administrative

Administrative risks are potential problem areas that could occur during the process of overseeing the EDI process. One of the fragile characteristics of the EC/EDI process is the absence of paper. The nature of the paper document lends itself to be legally considered as acceptable as evidence. It is tangible, lasting, and revisions are typically clearly visible. The electronic document however is quite different. It takes the form of a magnetic medium whose data content can be changed at any time. Revisions (or falsifications) to the electronic document are not always as discernible. Risks of this type may be characterized as paperless and include loss of audit trail between trading partners, loss of accounting transactions, lack of data retention, and storage media mishandling. The impact of this area can result in ineffective auditability of financial information and transaction histories. In the case of trading partner disagreements, legal disputes, or tax audits, the loss of an audit trail to verify financial and or operational transactions could result in serious consequences. When considering the communication/network area, there is always a risk that something may go wrong. The question is who should carry this risk and what should the consequences be?

5.0  REQUIREMENTS ANALYSIS

      

1. Requirement type,
2. Terms or conditions of the requirement, including preconditions if applicable,
3. Test type, and
4. Test method.

As mentioned previously, requirement types may be either object, event, or abstract oriented. Terms and conditions of requirements will be expressed in complete, consistent, unambiguous, and testable terms. For the case of situational requirements (i.e., requirements that need to be satisfied for certain situations) all relevant preconditions will be identified and defined. To help automate the development of the test plan, the following two fields have been added to the requirement definition: test type and test method. The test type field denotes whether or not testing the requirement requires the execution of the software application, in which case it is referred to as a dynamic requirement (static requirements do not require the execution of software applications). The last field, test method, will allow for an optional description of how and what is needed to prove (or disprove if applicable) that the conditions of the requirement have been satisfied. It should be noted that particular requirements and details of the test environment have not yet been defined and will be incorporated into the test plan document. However, in order to facilitate the requirements identification and definition process, the following preliminary requirement categories have been established:

1. Data Format and Content,
2. Communications,
3. Business Process,
4. Basic Functions,
5. Data Management,
6. Security Services, and
7. Policy, Laws, and Regulations.

A brief explanation of each requirement area is provided in subsections 5.1 through 5.7. In addition, a listing of some very high-level requirements is included in this section.

5.1  Data Format and Content

Sources of requirements for the data structure and content include the UN/EDIFACT standards, DoD implementation conventions, and if applicable trading partner agreements. The UN/EDIFACT rules and standards provide numerous requirements relating to the data format (structure and syntax), syntax rules, and semantics of EDI data and relationships among constituent data elements. DoD implementation conventions relating to this prototype message could contain additional requirements pertaining to which data elements are mandatory and which are excluded. Furthermore, trading partner agreements (as well as implementation conventions) may contain requirements pertaining to limitations on data elements such as restricting dollar amounts or quantities for certain data elements.

Examples of high level requirements belonging to the data format and content category could include the following:

1. Compliance of the ORDERS message with the data format and semantics specified in the UN/EDIFACT standards.
2. Compliance with any restrictions or limitations imposed by the trading partner agreement.

5.2  Communications

Requirements pertaining to communications encompasses the transmission/reception of data, data access, and protocol support areas. Many requirements in this area are performance oriented, and include stipulations applying to responsiveness, reliability, and accessibility of information. Examples of high level requirements falling in this category might include the following:

1. Support EDI transmissions between prototype test partners and their DoD trading partners, as well as any other civilian agencies.
2. The capability to immediately establish a connection with a trading partner upon request and to send or receive data.
3. Support for EDIFACT.
4. Time limits for the delivery of time sensitive EDI transactions, as well as for general time limits.
5. Support common EDI VAN functions and features.
6. Protocol support for TCP/IP, and or OSI.

5.3  Business Process

Because for this task the business process is already in place and we are introducing a new and untested means of accomplishing the process (i.e., using ORDERS message), it is anticipated that the majority of the most important requirements relevant to testing the prototype system will be necessitated by the business process. The ORDERS message basically specifies details for goods or services ordered using EDI between trading partners involved in administration, commerce, and transport under conditions agreed between the seller and the buyer. The high level condition that must be tested for this requirement area asks the question "Does the UN/EDIFACT ORDERS message prototype system work as well or better than the X12 purchase order transaction set in the context of this test environment?" In order to answer this question, the underlying basic ordering process must be considered.

When considering requirements relating to the basic ordering or simple delivery order business process it is important to understand what is implied by a Basic Ordering Agreement (BOA) or a simple delivery order. Requirements for the BOA business process will be identified as illustrated in Figure 5.2­1.

A BOA is an instrument of understanding (not a contract) executed between a procuring activity and a contractor which sets forth negotiated contract clauses which will be applicable to future procurements entered into between the parties during the term of the agreement. It includes as specific as possible a description of the supplies or services and a description of the method for determination of prices. Examples of high level requirements belonging to the business process category could include the following:

The ORDERS message shall facilitate the following requirements:

1. Describe the method for determining prices to be paid to the contractor for the supplies or services.
2. Include delivery terms and conditions or specify how they will be determined.
3. List one or more Government activities authorized to issue orders under the agreement.
4. Specify the point at which each order becomes a binding contract (e.g., issuance of the order, acceptance of the order in a specified manner, or failure to reject the order within a specified number of days).
5. Provide that failure to reach agreement on price for any order issued before its price is established is a dispute under the Disputes clause included in the basic ordering agreement.
6. If fast payment procedures will apply to orders, include the special data as required by the Federal Acquisition Regulations (FAR).

An excerpt of the FAR describing BOAs is located in Appendix D of this report.

5.4  Basic Functions

Basic functions, at a very high level, refers to the ability to send and receive purchase orders using the ORDERS message, as well as any additional transactions that are required. This category also includes requirements pertaining to the capability to convert data from standard EDI formats including ANSI X12, UN/EDIFACT, as well as the capability to automatically convert the data in User Defined File formats to and from corresponding standard EDI messages. The following list summarizes the high level requirements pertaining to the basic functions category:

1. Provide the capability to send and receive purchase orders using the ORDERS message, as well as any additional transactions that are required.
2. Provide the capability to convert data from standard EDI formats including ANSI X12, UN/EDIFACT.
3. Provide the capability to automatically convert the data in UDF formats to and from corresponding standard EDI messages.

5.5  Data Management

The data management requirement category addresses many important aspects related to record keeping and archiving and restoration of data. As discussed earlier in this report, record keeping is especially important when dealing with electronic documents because of the inherent auditability difficulties involving automated digital information processing systems. The areas of transaction/event tracking, and error logging are important record keeping requirement areas when considering the need to construct audit trails of activity. In addition to establishing requirements for recording transactions, events, and errors, it is also necessary, because of the volume of information being exchanged, to ensure archival and restoration capabilities satisfy all relevant requirements. The following list summarizes some high level data management capability requirements:

1. Track transactions and other events.
2. Log all errors that may be encountered.
3. Archive any and all records being tracked.
4. Restore archives in a timely manner.

Additional information regarding archival and restoration of EDI data within the U.S. is contained in the Internal Revenue Service (IRS) Procedure 91-59 document. In the case of EDI data archival and restoration outside of the U.S., refer to the International Chamber of Commerce's Uniform Rules of Conduct for Interchange of Trade Data by Teletransmission (UNCID) rules.

5.6  Security Services

The security services area is necessitated by the need for protection of data from loss, corruption, and or unauthorized access, retrieval, or alteration of data. The capability of the UN/EDIFACT message to allow for built in security will be assessed and tested, if deemed relevant. Without further discussing security issues, the possible requirements related to security may be classified as follows:

Security Services:

1. Identification,
2. Authentication,
3. Nonrepudiation (of origin and receipt),
4. Verification,
5. Encrypted data transmission, and
6. Privacy.

Additional information related to security and EC/EDI can be found in the Uniform Commercial Code 4A. This document provides additional guidelines for Electronic Funds Transfer security requirements within the U.S.

5.7  Policy, Laws and Regulations

Policy issues that must be considered for this task include Defense Information Infrastructure (DII) and FACNET policy. For example when considering FACNET, it is required that all communication to and from the Government be handled through a Government-certified VAN within the FACNET architecture. The components of the DII that are of primary interest for the purposes of this report are the elements of EC/EDI and all those that fall under the main area of communications and computer infrastructure. For a detailed discussion of this subject, refer to the CALS Integrated Data Environment Program Telecommunications Considerations Report, prepared by Don Reynolds, October 23, 1996. Requirements for this area attempt to answer the question "Does the prototype system conform with all the relevant DII policies, strategies, and initiatives?" The FAR is another potential source of regulatory requirements pertaining to the business process (purchase order) that may need to be tested. Another potential source of policy requirements is the National Archives and Records Administration (NARA). NARA is developing standards for management of Federal records created or received on electronic mail. Although this requirement area is no less important than the other six areas identified, specific requirements pertaining to testing the ORDERS message implementation as it relates to this area will likely comprise only a small number of the total requirements.

6.0  SUMMARY AND CONCLUSIONS

      

A comparative analysis of the UN/EDIFACT and ANSI X12 message revealed a nearly identical structure for the two message formats. However, the syntax, syntax rules, and semantic differences between the two standards are large enough that the data adhering to each of the standards is not easily interchangeable. The analysis of the ORDERS message revealed that the message may be reduced to four primary functional areas, which include (1) Packaging, Handling, Shipping and Transportation, (2) Product Characteristics, (3) Financials, and (4) Rules, Laws and Regulations.

A five layered architectural framework model shows that there are approximately 31 functional areas and 17 product areas to be accounted for when developing the test plan. The risk assessment discusses potential risk areas and their impact. Risks are categorized as either communications/network, operational, or administrative related and consist primarily of system failures, errors, or security breaches. An approach for defining requirements, which considers the importance of complete, consistent, unambiguous, and testable requirements, has been established. Preliminary requirements areas are categorized in the following seven areas (1) Data Format and Content, (2) Communications, (3) Business Process, (4) Basic Functions, (5) Data Management, (6) Security Services, and (7) Policy, Laws, and Regulations. Definitions of each requirement have also been established. As additional information pertaining to requirements, risks, and testing becomes available, it will be incorporated in the test plan deliverable.

All preliminary requirements, and risks will be used to develop the test plan for this task (Strategy and test plan for testing the UN/EDIFACT ORDERS message prototype), which will be structured according to the testing architecture presented in this report.

REFERENCES

      

"Electronic Data Interchange Implementation and Transition Road Map," prepared for the OSD CALS IWSDB Project, March, 1995.

"Standards Governing EC/EDI," Chapter 7, EC/EDI Handbook, http://www.acq.osd.mil/ec/

hdbk/chap08.html.

EDI Compliance Certification Facility Test Concepts and Procedures, DISA, September 1996.

Defense Information Infrastructure Master Plan, April 1996.

Executive Summary of the DoD Electronic Commerce in Contracting Process Action Team, December 20, 1993.

EDI-Charting: A Course to the Future by R.T. Crowley, Research Triangle Consultants, Inc., 1993.

The EDI Implementation Handbook by Gordon Jenkins and Ray Lancashire, EDI Council of Canada, 1992.

The Electronic Commerce Handbook by Gordon Jenkins and Ray Lancashire, EDI Council of Canada, 1994.

APPENDIX A:  GLOSSARY

      

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 process 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 are used to build a data segment. A data element dictionary that defines the data element. 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, 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 ­ the Federal Acquisition Network was created by Section 9001, Federal Acquisition Streamlining Act of 1994, Pub. L. 103-355, October 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 Treshold, 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 is a number assigned to an EDI interchange that is unique to both the interchange and the trading partner unique to 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.

SMTP ­ Simple mail transfer protocol

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 between EDI Trading Partners that specifies contractual matters and protocols governing EDI transactions. These are generally used in the private sector among EDI Trading Partners. Within the Federal EDI acquisition context, Trading Partner Instructions (TPIs) 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. They are 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 Consultative Committee on International Telegraph and Telephone (CCITT) for a store-and-forward message handling system in a multivendor environment.

APPENDIX B:  ABBREVIATIONS AND ACRONYMS

      

APPENDIX C:  SEGMENT GROUP SEMANTIC DESCRIPTION