*DLM 4000.25-4, April 09, 2022*

*Change 7*

**C5. CHAPTER 5**

**COMMUNICATIONS**

C5.1.  INTRODUCTION

	C5.1.1.  General.  This chapter outlines the communications methods to be used between the Defense Automatic Addressing System (DAAS) and its customers/trading partners for the exchange and processing of (DLMS) Defense Logistics Management Standards transactions.

	C5.1.2.  Defense Integrated System Network.  The Defense Integrated System Network (DISN) will be the primary communications path to convey DLMS transactions between the DAAS’ Global Exchange (GEX) eBusiness Gateways and their DLMS users.  In some cases, DLMS participants are commercial entities or foreign governments that do not have access to the Defense Integrated System Network  (DISN).  In these cases, DAAS will be responsible for conveying the DLMS transactions to the appropriate distribution point that can link to the specific DLMS trading partners (such as via a commercial Value-Added Network [VAN]).  The GEX eBusiness Gateways are nodes on the DISN as are most of our Department of Defense (DoD) trading partners.

	C5.1.2.  Purpose.  Within the general DISN requirements for transmitting data, the DLMS has additional specific data transmission capabilities and requirements.  This chapter identifies and defines these requirements and capabilities.

C5.2.  ENVELOPING

	C5.2.1.  General Information

		C5.2.1.1.  Transaction Sets.  Electronic Data Interchange (EDI) transaction sets are transmitted within other data structures that provide telecommunication (rather than functional) information.  For instance, several transaction sets (an  X12 transaction[footnoteRef:2] set begins with "ST" [transaction set header] and ends with "SE" [transaction set trailer] segments) can be grouped together within a transmission standard structure (called an envelope).  The rules governing such multiple packaging are:  (1) only transactions in the same Functional Group (FG) may be bundled together; (2) the group envelope within which they appear must begin with a "GS" (group start) segment and end with a "GE" (group end) segment; and (3) one or more like transaction set(s) will be contained within the GS and GE segments.   [2:  Accredited Standards Committee (ASC) X12] 

		C5.2.1.2.  Transaction Groups.  One or more transaction groups fit into a higher-level enveloping structure required for each EDI transmission.  This structure always begins with an "ISA" (interchange start) segment and ends with an "IEA" (interchange end) segment.  Contained within the ISA and IEA will be one or more group control set(s).

	C5.2.2.  Description of Use

		C5.2.2.1.  The interchange header and trailer segments (ISA/IEA) constitute the interchange control structure, i.e., an interchange envelope.  Interchange control segments perform the following functions:

			C5.2.2.1.1.  Define data element separators and data segment terminators.

			C5.2.2.1.2.  Provide control information.

			C5.2.2.1.3.  Identify sender and receiver.

			C5.2.2.1.4.  Allow for authorization and security information.

			C5.2.2.1.5.  Tables defining the X12 Control Structures and Segment/Element Separators are included as Appendix 6 of this manual.

		C5.2.2.2.  Interchange Control Structure.  The interchange control structure includes neither the group control structures nor the transaction control structures.  The  X12 Standard defines the latter two structures as application control structures, and even their version and release may differ from those of the interchange envelope.  An interchange envelope may encompass one or more FGs (GS/GE) which, in turn, may enclose one or more related transaction sets (ST/SE).  The DLMS Supplements (DS) to the Federal Implementation Conventions (ICs) illustrate the relationships for these structures.

		C5.2.2.3.  Purpose of FGs.  Since the only purpose of the GS/GE FGs is to serve as an additional control envelope surrounding like transaction sets (within the ISA/IEA structure), DAAS considers their usage to be as interchange control segments.  The DAAS does accept multiple transaction types if they are within the same FGs.

		C5.2.2.4.  Transaction Interchanges.  The generic term “trading partner” has extensive use throughout the EDI community.  It refers to each member of a sender/receiver pair in an interchange.  In contrast to the arrangement between some commercial or industrial trading partners, the interchange of DLMS transactions employs the capabilities of a central communications hub which is a combination of the Defense Automatic Addressing System (DAAS) and the DoD Global Exchange (GEX) eBusiness Gateway.  These systems perform several value-added functions before forwarding DLMS transactions to their ultimate receiver.  Thus, DLMS interchanges occurring between DoD Components or between Components and commercial entities should  always interface through this central hub.  For clarity within this interchange control process, DAAS distinguishes between intermediate communication between site and central facility and the exchange of EDI transactions between end-to-end entities.  DAAS characterizes the intermediate interchange between the DAAS/GEX hub and any DoD Component or commercial entity as occurring between communications partners.  The term, trading partners in the interchange control process is defined as the end-to-end communicants in an interchange.

		C5.2.2.5.  Envelope Control Segments.  Envelope control segments have few options and are identical for every EDI interchange between the same trading partners,  except for minor tailoring.  The tailoring involves the code values selected for the GS01 and GS08 elements.  GS01 classifies the particular transaction set(s) within a FG and GS08 identifies their Accredited Standards Committee (ASC) X12 version and release (and the Implementation Convention ([IC]) version itself).  NOTE: The version and release identified in the ISA12 data element pertains to the control envelope and not to the transactions.

	C5.2.3.  Data Element, Data Segment (File), and Sub-Element Separation

		C5.2.3.1.  Data Element Separator

			C5.2.3.1.1.  Purpose.  In Accredited Standards Committee ASC X12 documentation, the data element separator is typically displayed as an asterisk (*).  The data element separator employed within the interchange envelope assigns the value for the entire interchange.  The first occurrence of the data element separator is at the fourth byte of the interchange control header.  The value appearing there prescribes the data element separator through the next interchange trailer.

			C5.2.3.1.2.  Rules.  Any character can serve as a data element separator as long as:  (1) it is disjointed (i.e. not used in any other instance) from every other data element within an interchange; and (2) it does not conflict with telecommunications protocols necessary for the transmission of the interchange.  The American Standard Code for Information Interchange (ASCII) hexadecimal character 1D value recommended by ASC X12 will apply for use in the interchange of DLMS transactions.

		C5.2.3.2.  Data Segment Terminator

			C5.2.3.2.1.  Purpose.  The interchange control header establishes the value to be used for segment termination within an interchange.  ASC X12 documentation represents this graphically by a new line.  The first instance of segment termination immediately follows the ISA16 segment, where the data value occurring there sets the value for the interchange.

			C5.2.3.2.2.  Terminator Value.  The segment terminator value must be disjointed from all other data values within an interchange and must not conflict with transmission protocols.  ASC X12 recommends using the ASCII hexadecimal character “1C” (file separator) for the segment terminator character.  To comply with this requirement, DLMS users will set the pertinent parameter in their translation software.  In DLMS EDI documentation, the segment terminator is typically displayed as a tilde (~).

		C5.2.3.3.  Sub-Element Separator

			C5.2.3.3.1.  Purpose.  Sub-element separators differ from other separators.  The ISA segment provides a discrete element (ISA16) for defining the sub-element separator data value used to separate component data elements within a composite data structure.  This value must be different from the data element separator and the segment terminator.

			C5.2.3.3.2.  Rules.  The requirements for any separator value are (1) disjointedness and (2) lack of conflict with other protocols.  DLMS users will set the applicable translation software parameter to employ the recommendation of ASC X12 for sub-element separation by using the ASCII hexadecimal character “1F” (unit separator).  In DLMS EDI documentation, the back slash ( \ ) is typically used to graphically represent the sub-element separator.

C5.3.  ARCHIVING AND SEMANTIC ERROR RECOVERY

	C5.3.1.  Archiving.  EDI transactions will be retained on-line at DAAS for a period of 30 calendar days after receipt in accordance with DoDI) 5015.02 and can be accessed by the DAAS’ EDI Customer Service Support personnel.  To obtain assistance, via e-mail, click on the following e-mail address: EDI@DLA.mil.

Due to the fact that some EDI transactions are considered to be legal documents, all such transactions are archived by DAAS’ GEX eBusiness Gateway and are retained  in accordance with  DoDI 5015.02.  After successful processing,  EDI transactions are, also, moved to the DAAS Logistics On-Line Tracking System (LOTS) archives.  The DAAS central communications facility provides significant archiving and error recovery services for DLMS trading partners.  To assist with historical research in legal issues or for error correction, DAAS maintains cross-references between each customer’s original inbound transmissions and their subsequent (different) outbound transmissions, which are forwarded to a receiving trading partner.  Without these services, each end of the communication link would have to provide for extended data storage and recovery procedures.

	C5.3.2.  Transaction (Semantic) Errors

		C5.3.2.1.  Purpose.  Semantic errors involve EDI transaction data that have been correctly formatted, but whose meaning cannot be correctly interpreted by the receiving application/process.  It is not possible to detect semantic type errors during either transmission or translation.  As a result, detection of erroneous data occurring within a transaction is the responsibility of the receiving partner.  Semantic errors must be determined either within the receiving application processes or by some error detection software whose editing rules are based on the receiving application.  The DAAS’s GEX eBusiness Gateway will perform certain levels of semantic/syntax error detection for DLMS transactions based on DoD standard rules in support of central communications facility users.

		C5.3.2.2.  Error Detection.  If semantic errors are detected after transmission and translation, their correction normally falls outside the domain of either the translation or the transmission processes.  Semantic errors can be corrected either within the originating application process, by error correction software whose editing rules are based on the originating application process, by error correction software whose editing rules are based on the originating application, or by default values agreed upon by both originator and receiver.  At the request of central communications facility users, DAAS can perform various levels of semantic error correction based on computer processable editing rules.

		C5.3.2.3.  Administering Corrections.  For the originating application process to administer correction measures, the application must be aware of the error’s existence and location.  An error advice transaction must be generated by the receiving trading partner or by some error detection software outside the originating process.  The DS to 824 Federal IC-Reject Advice, may be used to report transaction semantic errors.

C5.4.  TRANSACTION ACKNOWLEDGEMENT / ENVELOPE ERROR REPORTING

	C5.4.1.  General Information

		C5.4.1.1.  Failure Levels.  In addition to semantic errors, EDI formats are subject to failure at three  levels:  (1) transmission, (2) EDI control envelope, and/or (3) EDI transaction syntax.  When successful processing is not possible due to problems within one of these levels, error recovery may be performed by the central communications facility.

		C5.4.1.2.  Transmission Integrity.  For incoming traffic at DAAS, successful receipt of an electronic message means that the arriving transmission is the same as that which was sent.  Thus, if transmission integrity is lacking, communication protocols will consider  retransmission to have been unsuccessfully received at DAAS.  Also, receipt of any transmission whose EDI control envelope has been corrupted will prompt the GEX eBusiness Gateway to return an appropriately coded acknowledgement to the sender.  If the envelope is incorrect or lacking, the gateway will treat the faulty transmission as never having been received.

		C5.4.1.3.  Translation.  After receiving a correct EDI envelope control structure, the GEX eBusiness Gateway will attempt to translate the EDI format.  When the translation process identifies inconsistencies with agreed upon syntactical standards,  the gateway will return to the sender a coded error acknowledgment transaction.  (See ***DAAS Manual***C5.4.2 regarding the 997 DLMS IC, Functional Acknowledgment (DLMS Appendix 1)).  Transactions containing syntax errors are neither forwarded to the receiving trading partner nor retained at DAAS.  They are "refused for delivery" until corrected.  The GEX eBusiness Gateway does not utilize the 997 with the “Accepted with Error” code.

		C5.4.1.4.  Error Advice.  The original sending trading partner will accept and respond to the error advice transaction (e.g., 997 IC), by correcting the error, and retransmitting the transaction.

		C5.4.1.5.  Trading Partner Transaction.  For transmissions between DAAS and the destination trading partner, the roles for error recovery are reversed.  Transmission acknowledgement, EDI control envelope error detection, and EDI syntax checking are all performed within the receiver's communications and EDI translation facilities; the GEX eBusiness Gateway responds only to communications protocol IC 997 advice messages.

	C5.4.2.  DLMS Implementation Convention 997, Functional Acknowledgment ***(all subsequent references are such as “the 997 IC”)***

		C5.4.2.1.  Negative Functional Acknowledgment.  Between DLMS communication partners, only a negative functional acknowledgement will be employed.  The 997 IC will be transmitted for any interchange whose contents cannot be handled unambiguously by properly functioning EDI translation software.  Note that "functional acknowledgement" might be a slight misnomer; the 997 IC merely verifies (or challenges) the syntactical correctness of (ability to translate) transaction-level data within a FG.  For DLMS interchanges, a 997 IC defining translation problems is exchanged not between trading partners, but between communications hubs/partners (i.e., between the GEX eBusiness Gateway and either of the trading partners).  Positive functional acknowledgements can be sent when requested.

		C5.4.2.2.  Outbound Syntax Errors.  Outbound transaction sets that contain EDI syntax errors will cause an error condition at the receiving EDI gateway/translator (typically at DAAS).  The receiving EDI translator will report the error back to the sender via an 997 IC.  For inbound interchanges, errors in syntax discovered by the receiver during translation will result in the generation of a 997 IC defining the syntactical discrepancies and the interchange will be returned to the sending EDI gateway/translator (typically DAAS) for correction and retransmission.

			C5.4.2.3.  Compliance with DLMS Supplements.  The receiving translator (or application software if the translators do not detect the error) will reject a transaction whenever segment(s) or data element(s) identified as either mandatory or required by the DS are not present. 

C5.5.  ADDITIONAL COMMUNICATION ISSUES

	C5.5.1.  Control Numbers.  ASC X12 standards provide for syntax control on three levels:  (1) interchange, (2) group, and (3) transaction.  Within each level, use of an identical control number exhibits a positive match between the header segment and its corresponding trailer (e.g., ISA/IEA, GS/GE, and ST/SE).  The DLMS conventions specify assignment of these control numbers at each level as described in the following paragraphs.

		C5.5.1.1.  ISA/IEA Interchange Control Numbers (ISA13/IEA02)

			C5.5.1.1.1.  Assignment.  The nine-digit interchange control number is assigned by the originator's translation software starting with 000000001.  This control number is incremented by one for each subsequent interchange.  When the number in the sequence advances to 999999999, the next interchange envelope will restart the series at 000000001.  Transaction control numbers may not be consecutive to a particular customer.

			C5.5.1.1.2.  Control Number Duplication.  The duplication of a control number in both header and trailer segments provides the means to identify loss of data and easily recognize duplicates.

		C5.5.1.2.  ST/SE Transaction Set Control Numbers.  The originator's translation software also assigns the transaction set control number.  The number starts with 0001 and increments by one for each transaction set within a FG.  (While a minimum of four digits are required, never transmit more digits than the least number needed.)  The series restarts at 0001 with the next FG sent.

		C5.5.1.3.  GS/GE Data Interchange Control Numbers (GS06/GE02).  This is a one-to-nine-digit number assigned by the originator's translation software.  The group control number sequence begins with one and, in contrast to the ISA control number, is incremented by one for every FG (GS/GE) within an interchange.  This number simply represents a count of the FGs in the interchange.

		C5.5.1.4.  Sender and Receiver Identifiers.  A DoDAAC is the usual identifier used by the originators and receivers of DLMS EDI transactions, however, the Communications Routing Identifer (CommRI) code can sometimes be used.  All DoD Component requisitioning Activities are assigned a DoDAAC.  For non-government trading partners, the Commercial and Government Entity (CAGE) code, which identifies commercial contractors authorized to do business with the U.S. Government, can be used.  Other DLMS trading partners without an assigned DoDAAC, CommRI,  or CAGE code may be distinguished either by telephone number or data universal numbering system (DUNS) code, plus four-digit telephone suffix, as coordinated through their VAN provider.

	C5.5.2.  Compression

		C5.5.2.1.  General.  The most significant cost associated with the EDI interchange is the cost of communications.  Therefore, it is cost effective to reduce transmitted data to a minimum.  DLMS transactions (in EDI format) require roughly five times the number of data bytes as an equivalent amount of information conveyed using the legacy 80-character data formats.  This is due to the separation of fields within variable-length records and identification of each segment within the transmission.  Mandatory control segments also add slightly to the overhead.  Increasing the number of transactions contained within an envelope helps to improve the overhead-to-data ratio, but provides only minor gains in efficiency.

		C5.5.2.2.  Standard Pattern Recognition.  The most effective available means for reducing transmission size is data compression.  This process uses standard pattern recognition algorithms that substitute single characters for frequently occurring patterns that the decompression process at the other end of the transmission line recognizes and replaces with the original patterns.  Being inherently repetitious, EDI transactions are conducive to such data pattern substitutions and, such compression techniques, which can often result in a 40 to 80 percent reduction in the data transmitted.

		C5.5.2.3.  Data Compression.  Data compression is not a part of the EDI format standard.  As a result, compression must occur after the EDI translation process, including generation of the control envelope, and prior to packaging the data for  transmission.  Some commercial VANs offer data compression as an optional service.  

		C5.5.2.4.  Error-Free Data Recovery.  For error-free data recovery, it is essential that both sending and receiving software be compatible.  Presently, DAAS supports multiple compression software packages.  As the DLMS enterprise service provider, DAAS is responsible for coordinating use of compression software.  As with version control for EDI conventions, DAAS will manage compression software version control through trading partner profile information.

	C5.5.3.  Encryption.  DLMS transactions presently contain only unclassified data, but DoD security requirements mandate the use of some form of secure encryption technique, such as SFTP, or a secure data transmission method, such as Virtual Private Network (VPN), or IBM MQ.  DoD policy will prescribe acceptable forms of data protection or encryption techniques, which will be coordinated between DAAS and its customers.

	C5.5.4.  Maximum Sizes

		C5.5.4.1.  Transaction Size Limit.  There are no technical limitations on the size of EDI transactions.  However, there are practical limits imposed by transmission duration, speed of the translation process, available storage, communications system processing capacities, and application systems limitations.

		C5.5.4.2.  Practical Limit.  As a practical measure, DLMS transaction sets should be limited to not greater than one megabyte (1,000,000 bytes), uncompressed, for a single transmission envelope.  Should the need arise for a larger envelope capacity, such requirement will be negotiated between the affected trading partner(s) and DAAS.

		C5.5.4.3.  Batch Size Restrictions.  The restrictions on batch size for some requisitioning and billing documents will continue until all of DoD has implemented the DLMS.  A batch size limit of 496 total documents will continue for the Materiel Obligation Validation (MOV) and Interfund Billing Documents.  The ASC X12 ST/SE envelope size will, also, be restricted by these procedures.  For EDI conventions, DAAS will manage compression software version control information through the trading partner profile.

C5-1	CHAPTER 5