Federal

Government

Federal

Implementation

Guidelines for

Electronic Data

Interchange (EDI)

August 1994

BASELINE AS OF: AUGUST 31, 1994
Federal

Government

Federal

Implementation

Guidelines for

Electronic Data

Interchange (EDI)

FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

BASELINE AS OF: AUGUST 31, 1994

This document was prepared by the Federal Electronic Commerce Acquisition Program Management Office (ECA-PMO). Permission to

quote or reproduce any part of this document except for Government purposes must be obtained from ECA-PMO.

Federal Electronic Commerce Acquisition Program Management Office

Skyline 4, Suite 400

5113 Leesburg Pike

Falls Church, VA 22041
TABLE OF CONTENTS

1.0 INTRODUCTION .......................... 1

1.1 PURPOSE OF THE GUIDELINE ......... 1

1.2 SCOPE ............................... 1

1.3 ADMINISTERING BODY ............... 1

1.4 INTRODUCTION TO EDI ............... 1

1.5 HOW TO USE THE GUIDELINE ......... 2

1.5.1 Conventions, Standards, and Guideline ... 2

1.5.2 Documentation of Conventions .......... 4

2.0 BUSINESS ISSUES ......................... 1

2.1 IMPLEMENTATION 

CONSIDERATIONS .................... 1

2.2 TIMING OF TRANSACTIONS ........... 1

2.3 MODES OF OPERATION ............... 1

2.4 SECURITY ........................... 1

3.0 LEGAL CONSIDERATIONS ................. 1

4.0 ENVIRONMENTS ......................... 1

5.0 MAINTENANCE ........................... 1

5.1 MAINTAINING GUIDELINE ............ 1

5.2 MAINTAINING X12 STANDARDS ....... 1

5.3 VERSION/RELEASE TIMING ........... 1

6.0 COMMUNICATION ........................ 1

7.0 MISCELLANEOUS ......................... 1

7.1 SOURCE OF REFERENCES ............. 1

8.0 GLOSSARY ............................... 1

8.1 X12 GLOSSARY ...................... 1

8.2 FEDERAL GLOSSARY ................. 6

FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

BASELINE AS OF: AUGUST 31, 1994 iii
9.0 FORMS AND DOCUMENTS ................. 1

9.1 ASC X12 FORMS ...................... 1

9.2 ASC X12 DOCUMENTS ................ 7

10.0 FEDERAL CONVENTIONS FOR USING 

ASC X12 TRANSACTION SETS ............. 11

10.1 INTRODUCTION ...................... 1

10.2 CONTROL SEGMENTS ................ 1

10.2.1 Description of Use .................... 2

10.2.2 Control Segment Specifications ......... 7

10.3 LARGE CODE LISTS MAINTAINED 

BY ASC X12 ......................... 19

10.4 CODE LISTS NOT MAINTAINED 

BY ASC X12 ......................... 19

10.5 FEDERAL CONVENTIONS, 

MATRICES OF USE, 

AND EXAMPLES .......................

10.5.1 810 Invoice 

Convention ...................... 1

Matrix ......................... 55

Example ....................... 63

10.5.2 820 Payment Order/Remittance Advice

Convention ...................... 1

Matrix ......................... 47

Example ....................... 55

10.5.3 824 Application Advice

Convention ...................... 1

Matrix ......................... 17

Example ....................... 21

10.5.4 832 Price Sales Catalog

 (Reserved)

10.5.5 836 Contract Award

Convention ...................... 1

Matrix ......................... 17

Example ....................... 21

10.5.6 838 Trading Partner Profile (Vendor Registration)

Convention ...................... 1

Matrix ......................... 43

Example ....................... 51

10.5.7 838 Trading Partner Profile (Confirmation of 

Vendor Registration)

Convention ...................... 1

Matrix ......................... 15

FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

iv BASELINE AS OF: AUGUST 31, 1994
Example ....................... 19

10.5.8 840 Request for Quotation

Convention ...................... 1

Matrix ........................ 123

Example ...................... 135

10.5.9 841 Specification/Technical Information

 (Reserved)

10.5.10 843 Response to Request for Quotation

Convention ...................... 1

Matrix ........................ 111

Example ...................... 123

10.5.11 848 Material Safety Data Sheet

 (Reserved)

10.5.12 850 Purchase Order

Convention ...................... 1

Matrix ........................ 135

Example ...................... 147

10.5.13 855 Purchase Order Acknowledgment

Convention ...................... 1

Matrix ......................... 33

Example ....................... 41

10.5.14 856 Ship Notice/Manifest

 (Reserved)

10.5.15 860 Purchase Order Change

 (Reserved)

10.5.16 864 Text Message

Convention ...................... 1

Matrix ......................... 15

Example ....................... 19

10.5.17 865 Purchase Order Change Acknowledgment

 (Reserved)

10.5.18 869 Order Status Inquiry

 (Reserved)

10.5.19 870 Order Status Report

 (Reserved)

10.5.20 997 Functional Acknowledgment

Convention ...................... 1

Matrix ......................... 13

Example ....................... 15

APPENDIX: IMPLEMENTATION

CONVENTIONS RECORD OF CHANGES

FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

BASELINE AS OF: AUGUST 31, 1994 v
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

vi BASELINE AS OF: AUGUST 31, 1994
1.0 INTRODUCTION

This chapter explains the purpose and scope of the guideline, and

provides an explanation of its use.

1.1 PURPOSE OF THE GUIDELINE

The guideline provides general guidance on the implementation of

American National Standards Institute (ANSI) Accredited Standards Committee (ASC) X12 electronic data interchange (EDI)

standards within automated information systems (AIS). The guideline also serves as guidance on information interchange procedures

that require the collection, reporting, and/or exchange of data

needed to perform government missions.

1.2 SCOPE

The guidance presented here should be used by organizational elements of the Federal community and by government organizations

that exchange data with the Federal community.

The federal community encompasses the (a) Federal agencies of the

United States Government including Department of Defense (DoD);

(b) local and state governments; (c) foreign national governments;

and (d) international government organizations.

The implementation conventions (IC) published in this guideline

are for execution. Implementation conventions labeled drafts are

for trial use and comment. Federal components must submit to the

administering body their data requirements that are not covered in

these implementation conventions as soon as possible, as indicated

in Chapter 5, Section 5.1. 

1.3 ADMINISTERING BODY

A Standards Management Committee (SMC) is being chartered

within the Federal Electronic Commerce Acquisition Program

Management Office (ECA-PMO). The SMC will be made up of

Federal agency representatives with the National Institute for Standards and Technology (NIST) functioning as secretariat. The SMC

will provide government-wide support, coordination, and oversight

of the development and continued maintenance of the IC required

to ensure fulfillment of business requirements for the implementation of electronic commerce (EC).

1.4 INTRODUCTION TO EDI

EDI is the computer-to-computer exchange of routine business information in a standard format. The Federal government, as part of

the President’s re-inventing government program, has begun a major initiative for “Streamlining Procurement through Electronic

Commerce.” As part of that initiative, a report establishing an

overall Federal architecture for EC was published for comments in

FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

BASELINE AS OF: AUGUST 31, 1994 1 1.0
April 1994. Following the publication, the Office of Management

and Budget chartered the Federal ECA-PMO mentioned above.

In recent years, many private-sector companies have reaped substantial benefits from automating their internal operations, such as

accounting, order entry, purchasing, scheduling, and material processing. Those same companies are now focusing on automating

their external operations using EDI and, in doing so, are reporting

significant economic rewards — between $2 and $10 or more in

direct cost savings from every document that they transmit electronically to their trading partners.

In spite of the magnitude of direct cost savings achieved through

EDI, many proponents note that the real benefits of EDI come

from using it as a tool to simplify and improve business

procedures — business process re-engineering, in the current parlance. As a consequence, they are reporting $4 to $5 in indirect

cost savings for every $1 in direct cost savings from various business improvements made possible by EDI, such as reduced inventories, improved competitive pricing strategies, enhanced auditing

procedures, and streamlined operations.

The government has long recognized the economic and strategic

advantages of EDI, both in the Defense and the civilian sectors.

Those advantages are becoming even more important as Federal

budgets are constrained. Additionally, as a major player in the

world trade, the U.S. needs to improve its ability to compete. The

adoption of common Federal Implementation Conventions and the

promotion of “better business practices” are expected to help in

promoting our nations commerce, electronically.

1.5 HOW TO USE THE GUIDELINE

The main topics and structures of this document conform to the

EDI Implementation Reference Manual Guideline document developed by the standing task group on training and implementation of

the ASC X12. The purpose of having agreed-upon “rules” and

structures is to facilitate the use of EDI among the many industry

and government activities who conduct business electronically with

these transactions. This document serves as a reference to all those

activities.

1.5.1 Conventions, Standards, and Guideline

The terms conventions, standards, and guideline are used throughout this document and are defined as follows: 

Standards are the technical documentation approved by

ASC X12; specifically, transaction sets, segments, data elements, code sets, and interchange control structure. Standards

provide the framework for how a specific EDI message will be

formatted for transmission.

FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

1.0 2 BASELINE AS OF: AUGUST 31, 1994
Conventions are the common practices and/or interpretations of

the use of ASC X12 standards. Conventions define how trading

partners will use the standards for their mutual needs.

The Guideline is 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. 

Implementation Notes help explain how trading partners will use

the standards for each convention. For convenience, they are

clearly marked and placed throughout the convention at the appropriate point. Implementation notes are the bridge from the

standards to the convention.

1.5.1.1 Who Develops the Conventions?

Conventions result from a joint effort by business, technical, and

EDI ASC X12 standards experts. After defining the business data

requirement, a transaction set is selected that best matches the data

and overall business purpose. The transaction set must then be tailored for that specific business’ use by “mapping” each data requirement to a corresponding data element within the transaction

set. The convention is usually written before any computer EDI

systems development work and serves as a design document for that

development process.

1.5.1.2 Why Use a Convention?

To create an ASC X12 transaction, a user must know the data requirements, understand the ASC X12 standard, and be able to use

that information to develop an interface program between the computer application and the ASC X12 translator. The convention

document provides the information necessary for this to take place.

Trading partners using the same convention will ensure that their

messages are understood at the translation point.

1.5.1.3 Who Needs a Convention?

System analysts and application programmers who plan to create or

read ASC X12 transactions use a convention to aid in interface software design. The convention will help the programmer and analyst

identify where their application data requirement should be carried

in an ASC X12 transaction set.

1.5.1.4 Can I Develop a Convention?

Conventions already exist for some of the most common business

practices. Copies of existing conventions can be acquired through

your organization’s EDI coordinator at the start of an EDI project.

If you find no conventions for the business practice you are about to

implement, your EDI coordinator should contact the administering

body.

1.5.1.5 Will I Need Any Other Implementation Guideline

All new implementations of EDI must conform to the guideline.

There will be a period of transition as existing government ICS are

FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

BASELINE AS OF: AUGUST 31, 1994 3 1.0
incorporated into the Federal Government Implementation Convention (FGIC) set (003040). If you are currently doing business with a

government agency, continue your operations, but be aware that

both you and the agency(ies) are expected to develop migration

plans to conform to the current Federal Guideline. It is the SMC’s

expectation that by working with the established standards body

and the various industry associations represented at the ASC X12

working groups, the tendency towards IC proliferation can be

halted. The SMC’s charter is to contain the proliferation within the

Federal government and hopes to work with the state government

representatives towards a national set of ICs.

1.5.2 Documentation of Conventions

Conventions are adopted from, and are intended to be in conformance with, ANSI ASC X12 standards or ASC X12 Draft Standards for Trial Use (DSTU).

Federal EDI ICs define the standard government usage of ASC X12

standards. Each implementation convention contains information

from the ASC X12 standard as well as additional information that

serves to define and clarify usage of the standard. With a few exceptions, implementation conventions are self-contained collections

of information: the transaction set table is followed by information

about transaction set segments, including detailed information

about the data elements that make up the segments. In cases where

lengthy code lists are specified, the implementation convention

may refer the implementation convention user to the appropriate

ASC X12 documentation. For this reason, it is recommended that

the user acquire the ASC X12 standards version/release 003040, as

well as future standards.

Federal EDI implementation conventions are based on a particular

ASC X12 version and release. Under no circumstances should an

implementation convention developed for one ASC X12 version

and release be used in conjunction with a different ASC X12 version and release. For example, an implementation convention developed for ASC X12 version/release of 003010 may not be used to

program an EDI translator to process transaction sets at ASC X12

version/ release 003040. 

For various reasons, Federal implementation conventions are subject to maintenance actions. For example, as new users of an implementation convention attempt to implement EDI, new data

requirements may be identified. Since implementation conventions do change, a Federal version number is used to indicate the

version of the implementation convention. The ICs in this guideline are numbered version/release 003040FED1.

It is crucial that the user of EDI implementation conventions be

aware of both the ASC X12 version and release and the Federal

version of the implementation convention being used. 

FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

1.0 4 BASELINE AS OF: AUGUST 31, 1994
1.5.2.1 Transaction Sets

All Federal Government EDI implementation conventions begin

with transaction set tables. Transaction set tables define information that is relevant to a particular business function (e.g., invoicing). In addition to providing information directly from the ASC

X12 standard, these tables contain important government specific

information. Federal implementation notes define the purpose and

scope of the function that the implementation convention serves.

Also, the implementation convention transaction set table defines

which ASC X12 segments may be used by Federal EDI trading

partners.

Figure 1.5-1 is a guide to the information provided in implementation convention transaction set tables. In general, government specific information is shown on the left side of the page and in

italicized notes. All other information comes directly from the

ASC X12 standard. Table 1.5-1 provides explanations for the numbered notes.

Following the transaction set tables, implementation conventions

contain information about transaction set segments. Segment information pages in EDI implementation conventions contain information from ASC X12 transaction set tables, the ASC X12 segment

directory, and the ASC X12 data element dictionary. In addition to

providing information directly from the ASC X12 standards, these

segment pages contain important, application specific information.

Implementation notes clarify usage for segments, data elements,

and codes. Segment and data element requirement designators define the requirements for including segments and data elements.

For identifier (ID) type data elements, acceptable code values are

listed as part of the data element information, unless all values are

acceptable in which case a implementation note will so indicate.

FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

BASELINE AS OF: AUGUST 31, 1994 5 1.0
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

1.0 6 BASELINE AS OF: AUGUST 31, 1994

 FEDERAL GOVERNMENT

 IMPLEMENTATION CONVENTION

ANSI ASC X12 VERSION/RELEASE 003030FED_

841 • REQUEST

1

841 Specifications/Technical Information

This Draft Standard for Trial Use contains the format and establishes the data contents of 

the Specifications/Technical Information Transaction Set (841) for use within the context of 

an Electronic Data Interchange (EDI) environment. The transaction set can be used to 

transmit specifications or technical information between trading partners. It can be used to 

allow EDI trading partners the ability to exchange a complete or partial technical description 

of a product, process, service, etc. over the same path as any other EDI transaction. The 

detail area can include graphic, text, parametric, tabular, image, spectral, or audio data. A 

transmission includes identification information to assist the receiver in interpreting and 

utilizing the information included in the transaction.

Further action as a consequence of the receipt and initial processing of the specification or 

other technical data may or may not require human intervention. The transmission and 

receipt of the data may require private agreement between the trading partners to automate 

the receipt of the data.

The total transaction must be in the general form of all ASC X12 transactions so that an EDI 

computer system will be able to automatically recognize it as a Specification/Technical 

Information Transaction Set and pass it on for processing of the data itself. The transaction 

set is not media dependent.

The detail area of the Specification/Technical InformationTransaction Set provides a 

structure which allows for the exchange of a variety of specification information. For 

example, if the transaction contains information describing a complete assembly, it would 

be necessary to include the assembly model, the models for each of the individual parts, 

and the associated specifications. In the case of a process it may be necessary to transmit 

the specification of the product along with the specifications of the process and raw 

materials. This transaction set can also be linked to other transaction sets.

This transaction set is not limited to a specific transmission protocol and uses other 

standards as applicable where they do not conflict with these requirements for specification 

transaction.

Implementation Notes

1. This draft implementation convention can be used as a request for specifications/technical information, as follow-up of 

a previous request, or as a cancellation of a previous request.

2. A trading partner can use the 841 convention to request data based on the receipt of an 840 and 841 transaction set, 

which may not contain all the required specifications/technical information or based on the need for updated drawings.

3. Each request for specifications/technical information must be submitted as an individual request and should contain 

the reference number of the solicitation, contract modification number, or transaction set reference number that 

generated the need for the request.

2

3

4

5

6

7

Transaction Set Header

SEG. ID NAME REQ. DES. MAX USE LOOP REPEAT

ST M 1

LOOP ID - SPI >1

Specification Identifier

Revision Date/Time

Note/Special Instruction

Export License

Import License

Customs Information

SPI

RDT

NTE

X1

X2

X7

M

O

O

O

O

O

1

>1

>1

1

1

1

Table 1

PAGE # POS. #

010

020

030

040

050

060

070

5

6

N/U

8

N/U

N/U

N/U

1

GC99 • JULY 9 1993

8

9 10

11

12 13

14 15

16

18

17

19

Figure 1.5-1 Implementation Convention Transaction Set Table
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

BASELINE AS OF: AUGUST 31, 1994 7 1.0

Figure 1.5-1 Implementation Convention Transaction Set Table (Continued)

Reference Numbers

LOOP ID - SPI/N1 >1

LOOP ID - SPI/REF >1

FEDERAL GOVERNMENT

IMPLEMENTATION CONVENTION

ANSI ASC X12 VERSION/RELEASE 003030FED_

2

N/U 080 GOV Military Standard 1840-A Record Definition O >1

9 090 REF Reference Numbers O 1

10 100 DTM Date/Time Reference O >1

N/U 110 PER Administrative Communications Contact O >1

11 120 N1 Name O 1

12 130 N2 Additional Name Information O 2

13 140 N3 Address Information O 2

841 • REQUEST

GC99 • JULY 9 1993

14 150 N4 Geographic Location O 1

N/U 160 REF Reference Numbers O >1

15 170 PER Administrative Communications Contact O >1

SEG. ID NAME REQ. DES. MAX USE LOOP REPEAT

LOOP ID - HL >1

Table 2

PAGE # POS. #

16 010 HL Hierarchical Level M 1

Specification Identifier

Revision Date/Time

Item Identification

Name

Message Text

SPI

RDT

LIN

N1

MSG

O

O

O

O

O

1

>1

>1

1

>1

020

030

040

045

050

18

20

22

26

27

LOOP ID - HL/SPI >1

Product/Item Description

Packaging Description

Quantity

Measurements

Unit Detail

PID

PKD

QTY

MEA

UIT

O

O

O

O

O

1

>1

>1

>1

>1

060

065

070

074

075

N/U

N/U

N/U

N/U

N/U

LOOP ID - HL/PID >1

Location

Paperwork

LOC

PWK

O

O >1

076 1

077

N/U

N/U

Marking, Packaging, Loading

Measurements

PKG

MEA

O

O

1

>1

078

079

N/U

N/U

LOOP ID - HL/PID/PKG >1

Reference Numbers

Date/Time Reference

Administrative Communications Contact

REF

DTM

PER

O

O

O

1

>1

>1

080

090

100

N/U

N/U

N/U

LOOP ID - HL/REF >1

Assigned Number

Measurements

LX

MEA

O

O

109 1

110

N/U

N/U

LOOP ID - HL/LX >1

DTM Date/Time Reference

REF

O

O

>1

>1

120

130

N/U

N/U

1

Electronic Format Identification

Military Standard 1840-A Record Definition

Binary Data

EFI

GOV

BIN

O

O

O

1

>1

>1

140

150

160

N/U

N/U

N/U

LOOP ID - HL/EFI >1

Characteristic/Class ID

Unit Detail

CID

UIT

O

O

1

1

170

180

N/U

N/U

LOOP ID - HL/CID >1

20
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

1.0 8 BASELINE AS OF: AUGUST 31, 1994

Figure 1.5-1 Implementation Convention Transaction Set Table (Continued)

LOOP ID - HL/CID/EFI >1

3

N/U 201 CSS Conditional Sampling Sequence O 1

N/U 210 SPS Sampling Parameters for Summary Statistics O

N/U 220 MSG Message Text O >1

FEDERAL GOVERNMENT

IMPLEMENTATION CONVENTION

ANSI ASC X12 VERSION/RELEASE 003030FED_

841 • REQUEST

GC99 • JULY 9 1993

LOOP ID - HL/CID/MEA >1

N/U 230 MEA Measurements O 1

N/U 240 DTM Date/Time Reference O >1

N/U 250 REF Reference Numbers O >1

Conditional Sampling Frequency

Loop Header

Loop Trailer

CSF

LS

LE

O

O

O

1

1

1

282

283

287

N/U

N/U

N/U

LOOP ID - HL/CID/CSF >1

Electronic Format Identification

Military Standard 1840-A Record Identification

Binary Data

EFI

GOV

BIN

O

O

O

1

>1

>1

290

300

310

N/U

N/U

N/U

TMD Test Method O

1

N/U 190

N/U 200 PSD Physical Sample Description O 1

>1

LOOP ID - HL/CID/STA >1

N/U 260 STA Statistics O 1

N/U 270 DTM Date/Time Reference O >1

N/U 280 REF Reference Numbers O >1

LOOP ID - HL/CID/CSF/CID >1

N/U 284 CID Characteristic/Class ID O 1

N/U 285 MEA Measurements O 1

N/U 286 STA Statistics O 1

SEG. ID NAME REQ. DES. MAX USE LOOP REPEAT

Table 3

PAGE # POS. #

28 010 SE Transaction Set Trailer M 1

To be meaningful, at least one of the SPI, PID, REF, MEA, EFI, or CID loops must be present 

with each occurrence of the HL loop.

The HL segment may be used to define the hierarchical relationship of product-related 

specifications reported in the associated HL loop. Product-related specifications may refer to 

the product in its entirety or to subunits of the product. For example, if the top level refers to an 

assembly, the second-level HL segment may refer to parts or subassemblies of the top 

assembly. This pattern may be repeated as often as required.

The CID segment may be used to define either a general class of properties, such as physical 

properties, or an individual property within a class. The CID loop allows the user the ability to 

define specifications such as the properties of the item or class, the environmental conditions 

under which the specifications apply, the test methods to be used, and other parameters related 

to properties within the current HL hierarchical level.

The sampling sequence specified in the CSS segment will take precedence over any other 

sampling rate (PSD03, PSD09, SPS06, CSF02, and CSF03) from the point the CSS01 event 

occurs until the specified sequence is completed.

NOTES:

2/010

2/020

2/170

2/201

21
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

BASELINE AS OF: AUGUST 31, 1994 9 1.0

Table 1.5-1

Transaction Set Table Explanations

Note 

Number

Name Explanation

1 Application Name If the implementation convention is designed to satisfy a particular business application, the name of

that application will appear. If the implementation convention is generic, the ASC X12 transaction set

title will appear.

2 Document Status Implementation conventions that have not been formally approved will be denoted by the word Draft in

this field.

3 ANSI ASC X12 

Version and Release

Identifies the ANSI ASC X12 Version and Release in which the implementation convention is written.

Also identifies the agency for whom the IC was developed, e.g., DoD Department of Defense, FED

Federal Government, etc.

4 Version Implementation conventions are revised periodically to accommodate new requirements. When they

are modified, the version number is changed. This number will appear following the ASC X12 Version

and Release number.

5 Transaction Set

Identifier

The 3 position number of the transaction set assigned.

6 Transaction Set Title The title of the transaction set as per ASC X12 standards.

7 Purpose and Scope A brief explanation of the intended use of the transaction set.

8 Implementation Notes If the implementation convention is intended to be used in a manner that is more specific than the ASC

X12 purpose and scope, these notes define the intended use.

9 Page # Usage indicators are listed in this column. If a segment is approved for use in this implementation convention, a page number is provided. This page number refers to the segment information page. If the

segment is not approved for use, “N/U” (Not Used) will appear. For those segments marked as “N/U”,

the IC will not generate this segment and trading partners should not send this segment.

10 Pos. # (Position

Number)

Position numbers are listed in this column. These numbers are unique within implementation convention transaction set tables and serve to efficiently identify the location of segments within a transaction

set.

11 Transaction Set Area Refers to areas which convey header, detail, or summary level information within the transaction set

and is referred to as Table 1, 2, or 3 respectively.

12 Seg. ID A 2 or 3 position alpha/numeric identifier of the segment, e.g., BEG, N1, G61, etc.

13 Name The name of the segment as per ASC X12 Standards.

14 Req. Des. A designation of the segment use within the specific transaction set, e.g., M, Mandatory, (must be used);

O, Optional, (may be used); or F, Floating (can appear anywhere within the transaction set).

15 MAX Use The maximum number of times the segment may be used in the transaction set at that specific location.

16 Loop Repeat The maximum number of times the loop may be repeated in the transaction set at that specific location.

The number of times a segment within a loop may be used is determined by its MAX Use Designator.

17 Loop Identifier A loop is identified by the first segment identifier in the loop.

18 Loop Bracket Lines in the transaction set tables that identify all segments and nested loops with a loop.

19 File ID Number A number assigned to identify a specific implementation convention, e.g., GC99.

20 Nested Loop Loops that are contained within another loop.

21 Notes Comments may also appear.
Figure 1.5-2 is a guide to the information provided for implementation convention segments. Table 1.5-2 provides explanations of

the numbered notes. 

Segment information pages are presented in the order that the segments appear in the transaction set table. Note that segment information pages for those segments marked as “N/U” (not used) in the

transaction set table do not appear in the convention. 

The following definitions are for use in interpreting the segment

requirement designators on the implementation convention segment

pages. 

Mandatory:

This segment is mandatory as defined by ASC X12. The government IC never changes ASC X12 mandatory designations.

Optional:

This segment is used at the option of the initiator. These segments can be retained for optional use or changed to required or

not used.

Required:

An optional segment under ASC X12 rules but required by the

government.

Recommended:

This criteria is not used in Federal implementation convention.

The following definitions are for use in interpreting the data element requirement designators on the implementation convention

segment pages. 

Mandatory:

This data element is mandatory as defined by ASC X12. The

government IC never changes ASC X12 mandatory

designations.

Optional:

This data element is used at the option of the initiator. These

data elements can be retained for optional use or changed to required or not used.

Required:

An optional data element under ASC X12 rules but required by

the government.

FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

1.0 10 BASELINE AS OF: AUGUST 31, 1994
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

BASELINE AS OF: AUGUST 31, 1994 11 1.0

Figure 1.5-2 Implementation Convention Segment

FEDERAL GOVERNMENT

IMPLEMENTATION CONVENTION

ANSI ASC X12 VERSION/RELEASE 003030FED_

20

841 • REQUEST

GC99 • JULY 9 1993

NAME

REF. 

DES. ATTRIBUTES

Data Element Summary

RDT • REVISION DATE/TIME

Segment:

Level:

Loop:

Usage:

Max Use:

Purpose:

Syntax:

Detail

HL/SPI

Optional

>1

To specify the revision level of the electronic data item.

Implementation Note:

This segment can be used to specify a revision, change, or version of the specifications/technical information being 

requested. If multiple revisions/changes are being requested and they cannot be identified by use of the specific words in 

RDT02, use as many repetitions of the RDT segment as required to identify them.

1. C0102 – If RDT01 is present, then RDT02 is required.

2. L030405 – If RDT03 is present, then at least one of RDT04 

or RDT05 are required.

3. C0605 – If RDT06 is present, then RDT05 is required.

RDT Revision Date/Time

DATA

ELEMENT

Optional RDT01 795 Revision Level Code O ID 1/1

Code indicating the revision or engineering level of the 

data items referred to by the specification number.

Change Level

Revision Level

Version Level

Conditional RDT02 796 Revision Value C AN 1/30

Revision or engineering change level of the data items 

referred to by the specification number.

A

E

H

Implementation Notes:

1. When RDT01 is Code A or Code E, insert either the actual number or letter of the change/revision being requested or 

the appropriate following word(s) to indicate the requested change/revision:

 "Latest": to indicate the latest change, or revision is being requested.

 "All": to indicate all changes, or revisions are being requested.

 "All After __": to indicate all changes, or revisions after the one specified are being requested.

2. When RDT01 is Code H, insert the words "As-Built" or "As Shipped" to indicate the version being requested.

Optional RDT03 374 Date/Time Qualifier O ID 3/3

Code specifying type of date or time, or both date and 

time.

007 Effective

Conditional RDT04 373 Date C DT 6/6

Date (YYMMDD).

Code Value Implementation Note:

Use Code 007 to indicate the date of the change, revision, or version being requested.

1

10

2

4

7

3

Optional

5

6

8

9

11

12

13

14

15

16

17

18

19

20
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

1.0 12 BASELINE AS OF: AUGUST 31, 1994

Table 1.5-2

Transaction Set Segment Notes

Note

Number

Name Explanation

1 Segment Identifier A 2 or 3 position alph/numeric identifier of the segment, e.g., BEG, N1, G61, etc.

2 Segment Name The name of the segment as per ASC X12 Standards.

3 Transaction Set Level Heading = Table 1, Detail = Table 2, Summary = Table 3

4 Loop If a segment is part of a loop, the Loop ID is provided. If the segment is the first segment of

a loop, the loop repeat value from the transaction set table will be provided.

5 Segment Requirement

Designator

Developers of implementation conventions may use a segment in accordance with the ASC

X12 Standards (mandatory usage cannot be changed) or may require that an optional segment be used, may recommend that an optional segment be used, or may choose not to use

an optional segment.

6 ASC X12 Segment Requirement DesignatorAn ASC X12 designation of the segment use within the specific transaction set, e.g., M,

Mandatory, (must be used); O, Optional, (may be used); or F, Floating (can appear anywhere within the transaction set).

7 Max Use The maximum number of items the segment may be used in the transaction set at that specific location.

8 Segment Purpose A brief explanation of the purpose (intended use) of the segment.

9 Segment Syntax Notes Segment Semantic Notes and Comments. Issues by ASC X12 may also appear.

10 Segment Implementation Note Notes provided by the developer of the implementation convention related to how the segment is to be used to include the type of data that will be carried in the segment.

11 Data Element Requirement

Designator

ASC X12 standards assign the following usage of data elements within a segment: Mandatory, (must use), Optional (may use), or Conditional (must use under certain conditions).

Developers of implementation conventions may use a data element in accordance with the

ASC X12 standards (mandatory usage cannot be changed), may require that an optional or

conditional segment be used, or may choose not to use an optional or conditional segment.

12 Ref. Des. The positional designation of the data element within the segment.

13 Data Element The identification number assigned by ASC X12 to the data element.

14 Name The name of the data element as assigned by ASC X12.

15 Attributes The use of the data element within the segment; the type of data element, e.g., AN indicates

it is an alpha/numeric data element; and the minimum/maximum number of characters that

the data element can contain.

16 Data Element Description A brief description of the use of the data element.

17 Approved Codes The codes that may be used in this data element for this implementation convention

18 Data Element Implementation

Notes

Implementation notes provide specific information about the purpose of the data element for

government use.

19 Code Value Implementation

Notes

Code value implementation notes provide specific information about code usage.

20 Implementation Convention

Page Number

This page number appears in the implementation convention transaction set table in the

Page # column.
Not Used:

This data element is not used. The government will not generate this data element and trading partners should not send this

data element.

Conditional:

The presence of the data element is dependent on the presence

or absence of other data element(s) in the transaction set. 

1.5.2.2 IC Naming Convention

The Federal government implementation conventions (ICs) contained in this Federal Guideline are maintained in a data base with

other ICs for the same transaction sets. In order to assure configuration control is maintained on all of these ICs, an application

name, identification of the organization for whom the IC was

developed, and a file number is assigned to each IC. If there is only

one IC in the data base for a given transaction set, the application

name may be the same as the transaction set name. The application

name is shown at the at the top of the IC, following the transaction

set number. As an example, the application name for the

843 transaction set is: Response to RFQ – Federal Solicitation. 

The identification of the organization for whom the IC was developed is also shown at the top of the IC following the ANSI

ASC X12 version/release number. As an example, ANSI ASC X12

Version/Release 003040FED_. See Section 5.3 for a more detailed

explanation of the version/release numbering structure.

Table 1.5-3 is shown at the bottom of the IC prior to the date. As

an example, the file number for the 843 IC is GC02.

The following matrix further explains the use of an application

name, organization identifier and file number for the enclosed ICs:

FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

BASELINE AS OF: AUGUST 31, 1994 13 1.0
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

1.0 14 BASELINE AS OF: AUGUST 31, 1994

Table 1.5-3

Implementation Convention Header/Footer Structure

Transaction

Set

Application Name Version/Release File Number

810 Commercial Invoice 003040FED1 GF01

820 Payment Order/Remittance Advice 003040FED1 GF02

824 Application Acceptance/Rejection 003040FED1 GA03

836 Award Notice 003040FED1 GC04

838 Vendor Registration 003040FED1 GA01

838 Confirmation of Vendor Registration 003040FED1 GA02

840 RFQ - Federal Solicitation 003040FED1 GC01

843 Response to RFQ - Federal Solicitation 003040FED1 GC02

850 Federal Purchase Order 003040FED1 GC03

855 Federal Purchase Order

Acknowledgment

003040FED1 GC11

864 Federal - Text Message 003040FED1 GC10

997 Functional Acknowledgment - Federal

Small Purchase

003040FED1 GI01