DLM 4000.25, Volume 1, May 19, 2014

# C8. CHAPTER 8

**MILITARY STANDARD SYSTEMS/DEFENSE LOGISTICS MANAGEMENT STANDARDS MAPPING**

C8.1.  GENERAL.  This chapter provides an overview of data mapping procedures between Military Standard System (MILS) and Defense Logistics Management Standards (DLMS) transactions.  MILS official name is the Defense Logistics Standard System (DLSS), however most users know it as MILS, MILS will be used throughout this chapter.

C8.2.  APPLICABILITY AND SCOPE.  The data mapping identifies the data content and location within the MILS and DLMS formats.  The DLMS maps are created and maintained by DAAS and support translation of data both from MILS to DLMS and DLMS to MILS.  Because DLMS transactions have the capacity to convey more data than the MILS, the mapping also highlights the gaps in the DLMS and MILS translation processes (e.g., information may be lost when translating a DLMS transaction to a MILS transaction because only values that exist in both DLMS and MILS can be translated).

C8.3.  DATA TRANSFORMATION

	C8.3.1.  Mapping is a step in a larger process known as data transformation.  Data transformation is the process of converting information from one format to another format.  MILS is based on 80-column card images developed in the 1960s and was the sole DoD transaction format for decades.  The records are fixed length and fields are based on a column position within the record.  

	C8.3.2.  DLMS currently supports two industry standard formats: American Accredited Standards Committee (ASC) X12 Electronic Data Interchange (EDI) and eXtensible Markup Language (XML).  To make data mapping easier between the multiple formats, DLMS XML uses the EDI X12 element names for the markup tags.  For example, if the EDI element name is “Reference Identification”, “<E_Reference_Identification>” and “</E_Reference_Identification>”will be used as the beginning and ending tags within XML.

	C8.3.3.  DAAS’s transformation process involves the use of executable programs to convert transactional data between MILS, DLMS EDI, and DLMS XML.

C8.4.  MILS-DLMS EDI MAP CONSTRUCT

	C8.4.1.  While the DLMS maps are based on the MILS transaction format, multiple MILS transaction formats may be mapped to a single DLMS transaction.  For example, Document Identifier Codes (DIC) D4_, D6_, DRA, DRB, DRF, DZK, D6T, BAY,C3D, C2_, DX_, Z6T, Z4S, Z6S, BG1 and BG2 are all mapped to the DLMS 527R Receipt, Inquiry Response and MRA transaction.  Due to this many-to-one relationship, the maps contain conditional statements defining how MILS elements map to the corresponding DLMS elements.  For example, the national stock number (NSN) element appears in record position 12 to 24 in both the MILS BG1 and BG2 while other MILS transaction formats use record position 8 to 20, all of which map to a single element (LIN03) in DLMS 527R.  The MILS-DLMS maps comprise two sections.

	C8.4.2.  MILS Section of the Data Map.  The legacy 80 record position MILS format is a fixed-length data format, meaning each data value resides in a specific range within the record layout.  The MILS section of the map comprises three parts: field name, record position and conditions for translation (if required).

		C8.4.2.1.  Field name is the data member within the data structure.

		C8.4.2.2.  Record position defines the beginning and ending position of the data value within the data structure.

		C8.4.2.3.  The translation describes the conditions for mapping the data between the MILS and DLMS formats.

			C8.4.2.3.1.  The mapping describes how an individual MILS transaction is translated to the DLMS.  The conditional mapping also provides information about values within the record.

			C8.4.2.3.2.  For example, the MILS transaction format is limited to a fixed number of columns;  DLMS are variable length format and do not have the same restriction.  In the MILS quantity field, M is used to designate thousands.  The map translates M to 000 so the value stored in the DLMS is a numeric quantity.

	C8.4.3.  DLMS Section of the Data Map.  The DLMS section of the data map comprises three parts: DLMS Data Element, Table, and Update information.  The DLMS data element relates back to the MILS field name (if one exists) and its MILS record position.  In many cases the MILS record position will be “none” because the DLMS transaction is an expanded/enhanced version of the legacy 80 record position MILS transaction.  DLMS are designed to support new elements and features that do not exist in the MILS version of the transactions.  The table column (next to last column in Figure C8.F3.) is an X12 EDI concept and exists to distinguish among the header, detail, and summary segments of the X12 transaction.  DLMS data elements in Table 1 (header segments) contain the transaction information, receiving location and routing information.  DLMS data elements in Table 2 (detail segments) contain the values to be used for processing the transaction.  DLMS data elements in Table 3 (summary segments) contain summary data for the transaction.

Legend: 
MILS

DLMS

Conditions

	C8.4.4.  XML Mapping.  There are no MILS to XML maps.  DLMS XML is “EDI based”.  This means the segments, elements, and looping structure of the EDI transaction are exactly the same in XML as they are in EDI.  For example, if the routing identifier code (RIC) is stored in the “N104” element in EDI, XML will use “N104” as the XML tag name when storing the RIC value in XML (e.g., <N104>S2B</N104>).

C8.5.  USING THE MAPS

	C8.5.1.  DAAS business rules define the routing of transactions and the type of transactions used by each communication system (e.g. EDI, XML, MILS).  The DLMS maps are used when the data needs to be transformed between MILS and EDI/XML.

	C8.5.2.  DAAS uses the DLMS maps to translate the input file from one format to another. Missing data, incorrect data types, values outside the parameters and many other reasons can cause the transaction to reject.  If the transaction is rejected, DAAS sends a notification back to the source system so the transaction can be corrected and resubmitted.

	C8.5.3.  Components migrating to the DLMS will need to locate the MILS format within the DLSS/DLMS cross reference table. The cross reference will indicate the correct DLMS transaction for a given MILS transaction.  Components should compare the MILS format to any existing Service unique formats and document any deltas.  The DLMS transactions can be updated in response to changing business needs.  If the Component has a unique requirement, a Proposed DLMS Change (PDC) can be submitted to have the specific transaction enhanced (Volume 1, Chapter 3 of this manual).

C8-2	CHAPTER 8