*DLM 4000.25, Volume 1, April 09, 2022*

*Change 10*

# C2. CHAPTER 2

**BUSINESS CONCEPTS AND ENVIRONMENTS**

C2.1.  OVERVIEW

	C2.1.1.  Defense Logistics Management Standards.  The Defense Logistics Management Standards (DLMS) provide procedures and data formats to link the various component organizational elements of the Defense Logistics community including: inventory control points (ICPs), distribution depots, maintenance depots, transportation nodes, and end users in posts, camps, stations, ships, and deployed units.  The DLMS address the different functional processes of logistics and provides standards to exchange data across the Military Services, Defense Agencies, other Federal Agencies, foreign national governments, international government organizations, and nongovernment participants.  As other electronic business (EB) methods emerge, DLMS will incorporate these new capabilities into the DoD logistics business processes, as appropriate.

	C2.1.2.  Purpose.  This chapter provides an overview of some of the technologies and procedures that all participants must implement to employ the DLMS across the range of participating organizations.  This chapter also provides a road map to other parts of the manual that may provide more details about specific topics.

C2.2.  DLMS IMPLEMENTATION PROCESS.  The Defense Enterprise Data Standards Office (DEDSO) coordinates DLMS related requirements with the DoD Component focal points and interfaces with DAAS to ensure these requirements are fulfilled. These requirements are transformed into new or revised DLMS procedures, transactions and data standards.  

	C2.2.1.  Transactions.  The DLMS provide descriptive procedures, transactions, and data formats for computer-to-computer communications.  The transactions initiate a logistics action (e.g., requisition an item, authorize a funds transfer, ship an item).  The transactions are structured and formatted to be transmitted by computer systems without human intervention.

	C2.2.2.  Transaction Flow.  DAAS acts as a central hub for all DLMS transactions.  Transactions flow from the originator's computer to the Defense Automatic Addressing System (DAAS) operated by DAAS.  DAAS will edit the transactions for correct format, retain an image in an interactive data base for user access, and route the transactions to the correct recipient(s).  The receiving computer(s) will process the transactions and initiate the appropriate logistics action.  This action will frequently result in generation of additional DLMS transactions to other systems and/or responses back to the originator via DAAS.  Refer to Defense Logistics Manual (DLM) 4000.25-4, Defense Automatic Addressing System (DAAS) manual for procedures and operations of DAAS.

C2.3.  DLMS DATA MANAGEMENT

	C2.3.1.  Data management for DLMS provides data standards, syntax, and procedures necessary to ensure the data at the heart of DLMS transactions is well understood and interoperable.  It prevents overlapping or incompatible uses of data and enables trading partners to communicate data or carry forward important data through related processes.  The foundation of DLMS data management is based on the guiding principles established in DoD Directive (DoDD) 8190.01E, “Defense Logistics Management Standards (DLMS),” January 9, 2015, and DoDD 8320.02, “Data Sharing in a Net-Centric Department of Defense.” April 23, 2007.  DLMS Data Management is further described in Chapter 5 of this volume.

	C2.3.2.  Continued Support For Legacy Data.  DAAS will continue to execute the DLSS error notification processes until DoD has totally implemented the DLMS.

C2.4.  REQUIREMENTS FOR NEW OR REVISED DLMS PROCEDURES

	C2.4.1.  Use of DLMS Procedures.  DoD Components must use standards and procedures prescribed by the DLMS when undertaking development of new or revising existing logistics systems.  If a DoD Component or other participating external organization requires changes to, or expansion of, the existing DLMS to accommodate technological innovations planned for new system designs, they must submit PDCs with full justification and explanation of the intended use following the instructions in Chapter 3 in this volume.

		C2.4.1.1.  DLMS Enhancements.  The DLMS procedures and the supporting DLMS Implementation Conventions (IC) identify DLMS enhancements that may not have been implemented by all DLMS trading partners or within legacy systems.  Therefore, data associated with an enhancement transmitted within a DLMS transaction may not be received or understood by the recipient’s automated processing system.  Additionally, DLMS procedures may not have been developed to support the data exchange.  Components wishing to implement DLMS enhancements must coordinate with DEDSO and trading partners prior to use.  DoD Components must submit a PDC reflecting required business rules/procedures prior to implementation of DLMS enhancements already documented in DLMS ICs.  

		C2.4.1.2.  Future Streamlined Data.  The DLMS procedures and the supporting DLMS ICs identify data that may be targeted for elimination under a full DLMS environment.  This data is often referred to as “future streamlined data”.  This data is retained within DLMS during a transition period when many trading partners employ legacy systems or cannot move to full DLMS capability.  DoD Components wishing to streamline data must coordinate with DEDSO prior to doing so.  Components need to submit a PDC reflecting any revised business rules associated with such termination.

		C2.4.1.3.  DLMS Data Element Field Size.  The DLMS ICs identify ANSI X12 field sizes and some field size constraints existing under DLSS legacy transactions.  Many DLMS trading partners operating within a legacy system will not be able to support the DLMS expanded field size.  Components desiring to implement an expanded field size under DLMS must be aware that the conversion process to the DLSS legacy transactions cannot accommodate the larger fields.  Components must coordinate with DEDSO prior to use and may submit a PDC to adjust a field size to a recommended length.

	C2.4.2.  Submission of New Data Elements.  Data elements employed in DoD-wide, inter-DoD Component, and participating external organization logistics systems’ authoritative issuances that have not been standardized under DoDD 8320.02, “Data Sharing in a Net-Centric Department of Defense,” April 3, 2007, will be submitted as proposed DoD logistics standards following procedures developed under the authority of ASD(S).  DoD logistics standard data elements must be used in design and upgrading of:

		C2.4.2.1.  DoD-wide and inter-DoD Component automated logistics systems and authoritative issuances, and

		C2.4.2.2.  DoD Component systems and issuances.

C2.5.  DATA REQUIREMENTS AND FORMATS

	C2.5.1.  General Information.  The DLMS use ANSI ASC X12 transactions for EDI and X12 based extensible markup language (XML).  EDI is widely used in the private sector to conduct business operations, and also between industry and the Government in acquisition, transportation, finance, and other functional areas.  The DLMS extend this electronic connectivity to internal DoD logistics operations.  The DLMS may also expand to include other emerging EB methods as they are standardized and approved for use by the DoD.  The standards and conventions are described in Chapter 6 of this manual.

	C2.5.2.  DoD/ANSI ASC X12 Conversion Guides.  DoD systems that store internal data in DoD format and exchange data in X12-based DLMS format must incorporate three conversion guides to convert DoD data values established in legacy systems to the corresponding ASC X12 code values.  DoD applications must convert outbound transactions from DoD code values to ASC X12 code values based on the DoD/ASC X12 Conversion Guide definitions.  DoD applications must convert inbound transactions from ASC X12 code values to DoD code values based on DoD/ASC X12 Conversion Guide definitions (Appendix 4).

The three conversion guides available from a link on the DEDSO Website and Appendix 4 are:

		C2.5.2.1.  Transportation Method/Type Code Conversion Guide.

		C2.5.2.2.  Type of Pack Conversion Guide.

		C2.5.2.3.  Unit of Material Measure (Unit of Issue/Purchase Unit) Conversion Guide.

	C2.5.3.  Legacy Format to DLMS Cross Reference Tables.  A Defense Logistics Standard System (DLSS) legacy 80 record position format to DLMS transactions cross reference table provides the following information:

		C2.5.3.1.  Cross Reference to Legacy Formats.  Cross Reference of each legacy format Document Identifier Code (DIC) (e.g., A01) to DLMS IC number (e.g., 511R) for legacy format processes in DIC sequence and DLMS IC sequence. Refer to Appendix 5. 

		C2.5.3.2.  Correlation Tables.  MILSTRAP correlation tables in legacy DIC sequence provide general functional equivalency between each MILSTRAP legacy DIC and DLMS IC.  Details for the correlation tables are provided in Appendix 5, DLMS to DLSS Cross Reference Tables.  The MILSTRAP correlation tables can be viewed at the DEDSO Website. 

 		C2.5.3.3.  Cross Reference Tables.  Cross reference tables for each legacy 80 record position DLSS DIC are available in DIC and DLMS sequence at the DEDSO Website. 

	C2.5.4.  DLMS Code Lists/Qualifiers.  DLMS Code Lists/Qualifiers used to identify DoD functional data elements in the DLMS ICs are described in Appendix 6.  They are accessible from a link in Appendix 6, DLMS Code List Qualifiers, or in LOGDRMS from the DEDSO Website.

	C2.5.5.  Editing

		C2.5.5.1.  General.  Data contained in DLMS transactions must be complete and accurate for the receiving computer systems to process.  The following paragraphs define principles for maintaining accurate data within the DLMS for all participants.

		C2.5.5.2.  Edit at Origin.  DLMS procedures require recipients to edit and, if necessary, reject transactions back to the sender.  Originating activities should maximize editing and validation on their own transactions prior to transmission; this can minimize the expense and delay involved in processing erroneous transactions.  Outbound transactions must meet all DLMS IC requirements.  Components may apply more stringent or specific edit requirements on outbound transactions to meet their business requirements 

		C2.5.5.3.  Use Data Only as Defined.  Data elements will carry ONLY the data specifically defined in the DLMS ICs.  Capabilities exist within the DLMS to support DoD Component unique data.  However, DoD Components must submit proposed DLMS changes following Volume 1, Chapter 3 requirements to address any planned usage of Component-unique data.

	C2.5.6.  Error Processing

		C2.5.6.1.  Transaction Set (TS) 997, Functional Acknowledgement.  DLMS use TS 997 when the translator encounters an error that violates ANSI ASC X12 syntax rules.  TS 997 may also be used to acknowledge receipt of a transaction set without error when agreed to between the DoD and a commercial trading partner.  Use of TS 997 is discussed in more detail in Appendix 8 of this manual and in DLM 4000.25-4, DAAS manual.

		C2.5.6.2.  DLMS Implementation Convention 824R, Reject  Advice.  DLMS 824R is used by the  transaction recipient to reject a DLMS transaction that could not be processed due to erroneous or missing data based on requirements identified in the DLMS IC for a particular transaction.  DLMS 824R is generated as an exception by DAAS and DoD Component application programs to convey information to the sender’s application process.  Originating sites will possess technical and procedural means to receive the application advice, correct errors, and retransmit appropriate data.  Use of DLMS 824R is discussed in Volume 1, Chapter 4, Functional Application Errors ***and Volume 2 Supply Standards and Procedures***.

	C2.5.7.  Change Control.  DAAS is the designated activity to perform change management for the translator used to convert legacy DLSS to DLMS or DLMS to legacy DLSS.  DAAS will upgrade the translator as logistics data requirements change and the DLMS are updated to reflect the changes.  Volume 1 Chapter 3 discusses the guidelines for maintaining the DLMS and defines the procedures for processing and recording proposed DLMS changes.

	C2.5.8.  Enveloping.  The DLMS support the bundling of multiple groups of data, referred to as enveloping.  Specifically, multiple transactions can be bundled into a single DLMS interchange.  Multiple transaction sets of a similar type can be placed into a single functional group, and multiple functional groups can be placed into a single interchange group.  The DLMS use of envelopes is consistent with ANSI ASC X12.6 standards.  Refer to Defense Logistics Manual (DLM) 4000.25-4, DAAS manual (Communications) for details of DLMS envelope usage.

C2.6.  DLMS DEVIATIONS OR WAIVERS

	C2.6.1.  Submission.  DoD Components and participating external organizations will not request DLMS deviations or waivers solely to accommodate existing internal systems and procedures or organizational environments.  When requesting deviations or waivers, DoD Components and participating external organizations must submit them following the guidelines in Chapter 3 in this volume.

	C2.6.2.  Review.  The PRC Chairs will consider requests for DLMS deviations or waivers when the requestor demonstrates that the system cannot provide a workable method or procedure, or cannot accommodate interim requirements.  The Director, DEDSO, will forward unresolved matters to the applicable OSD proponent office for resolution. 

C2.7.  COMMUNICATION REQUIREMENTS

	C2.7.1.  Telecommunication Networks.  The method for conveying DLMS transactions from one activity to another will be by DoD and Federal electronic telecommunications networks.  DoD Components will route all DLMS transactions to DAAS.  The Defense Information Systems Network (DISN) is the main network pathway for transmission of transactions to and from the DAAS.  Refer to the DAAS procedures in DLM 4000.25-4 for DLMS-specific capabilities and requirements for transmitting data within the DISN. 

	C2.7.2.  Common Communications Approach.  All participating activities must use a common communications approach.  DAAS procedures (DLM 4000.25-4) define specific communication requirements.  The following paragraphs highlight some of the key communications requirements:

		C2.7.2.1.  Data transmission will be via the DISN or other approved alternatives.

		C2.7.2.2.  Compression algorithms as defined by DAAS will be used.

		C2.7.2.3.  Transaction set syntax and content will be in accordance with ANSI ASC X12.6 standards and the DLMS implementation conventions defined in this manual.

		C2.7.2.4.  Transactions through DAAS are encrypted. 

		C2.7.2.5.  Component activities will maintain readily accessible copies of all transmissions for at least one week, and will be able to retransmit them at the request of the receiving party.  DAAS will retain a copy of all receipts and transmissions in accordance with DoDI 5015.02, DoD Records Management Program.  DAAS procedures define the retention period for each type of transaction set.

		C2.7.2.6.  DLMS transactions are variable length and in many cases have no practical maximum size.  However, for transmission purposes, an overall maximum size will be imposed for transaction sets and transmission envelopes (see Chapter 4).[footnoteRef:1] [1:  Temporary restrictions at the data element level may be imposed on translation requirements to the previous fixed-length formats.] 

	C2.7.3.  Technical Solutions.  DoD Component activities will have the discretion to determine the technical means to create the data exchange formats defined above, for example, using a commercial translator or develop their own software.

C2.8.  DAAS OPERATIONS

	C2.8.1.  Functions.  DAAS is central to all DLMS operations.[footnoteRef:2]  It performs numerous corporate functions for DLMS operations including: [2:  Complete procedures for DAAS are contained in the DLM 4000.25-4, DAAS manual.] 

		C2.8.1.1.  Performing basic edits and returning any transactions with errors back to the originator.

		C2.8.1.2.  Archiving all received and transmitted messages, to ensure retransmission capability in the event the original message was lost due to computer or telecommunications failure.

		C2.8.1.3.  Generating images, as required.

		C2.8.1.4.  Holding or forwarding transactions per DoD Component profile for the recipient.

		C2.8.1.5.  Executing "suppress" or other national command directives.

		C2.8.1.6.  Loading transaction data into the Logistics On-Line Tracking System (LOTS).

		C2.8.1.7.  Coordinating and providing DoD management information on supply system performance evaluation.

		C2.8.1.8.  Performing additional functions for requisitioning, including rerouting requisitions to the correct source of supply (SOS).

		C2.8.1.9.  Rerouting other documents using DoD Component rules and records as appropriate.

		C2.8.1.10.  Evaluating the "To" address capability for receiving transactions in DLMS versus DLSS format.

		C2.8.1.11.  Converting transactions from legacy format DLSS to DLMS and from DLMS to DLSS, as required.

	C2.8.2.  DLMS Global Services Provider.  DAAS maintains activity profiles recording EDI capability, compression techniques, encryption techniques, communications media, and other address data of the DoD Components.

		C2.8.2.1.  Capabilities.  In its role as the DLMS Global Services Provider and as a DoD distribution point for EDI communications with industry, DAAS maintains an extensive capability to translate between EDI formats and other file structures.  As required, DAAS will provide translation between DLMS and Component user defined formats; between multiple versions of the ANSI ASC X12 standards; and between other EDI formats, such as XML.  In addition, DAAS will support translation between DLSS legacy formats and DLMS formats referred to as “conversion”.

		C2.8.2.2.  Transition Conversion Requirements.  During a transition period of indeterminate length, the DoD will operate in a mixed legacy 80 record position/DLMS environment.   DAAS will provide conversion processing between the standard legacy formats and DLMS to support this transition.  Legacy format to DLMS conversion tables have been developed that facilitate the conversion of data from legacy format to DLMS, and vice-versa.  The conversion tables enable logistics business to be conducted in both environments.  To accomplish the conversion, DAAS uses a commercial “any to any” mapping software package that supports a robust conversion.  The Components are able to use their current format, either legacy format or DLMS, to initiate a transaction.  DAAS incorporates and maintains a profile of each organization and specifies whether the organization is operating in legacy format, DLMS, or both.  The legacy format data elements are retained in DLMS to support the conversion.  However, DLMS enhanced data may not be supported in legacy or transitioning systems, so coordination with DEDSO is required prior to implementation of DLMS enhancements.

C2-4	CHAPTER 2