2

ADC 329

Use of Borrowed and Migration Codes in DLMS Supplements 

1. ORIGINATING SERVICE/AGENCY AND POC INFORMATION:

a. System POC: Department of Defense (DoD) Defense Automatic Addressing System 

Center (DAASC), 937-656-3783 

b. Functional POC: Ms. Ellen Hilert, Chair, Supply Process Review Committee, 703-767-

0676; DSN 427-0676; or, e-mail: ellen.hilert@dla.mil, Mr. Robert Hammond, Chair, Finance 

Process Review Committee, 703-767-2117, DSN 427-2117 or email: robert.hammond@dla.mil, 

Mr. Thomas Lyons, Chair, Contract Administration Process Review Committee, 703-767-1481; 

DSN 427-1481; or, E-Mail: thomas.lyons@dla.mil. 

c. Technical POC: Defense Logistics Management Standards Office (DLMSO), Mr. 

Thomas Lyons, 703-767-1481; DSN 427-1481; or, E-Mail: thomas.lyons@dla.mil. 

2. FUNCTIONAL AREA: General. All DLMSO managed Process Review Committees. 

3. BACKGROUND:

There are 3 basic methods for code development and documentation which are practiced within 

the logistics domain. The methods include Borrowed Codes, Migration Codes, and Local Codes. 

 a. Borrowed Codes 

(1) A Borrowed Code is when a code value is used in an existing code table, but its 

semantic meaning is altered (i.e., the code is only used for its syntax). 

(2) The use of Borrowed Codes is less expensive during translation since the syntax 

validation does not need to be altered; Borrowed Codes are more expensive when 

transforming data since a data element is used for other than its intended use. 

 b. Migration Codes 

(1) A Migration Code is when a code from a future (but existing) version is used in a 

lower version. Semantic meaning and syntax are consistent with the higher version. A 

Migration Code does not refer to a code which already exists in the current (lower) 

version. 

(2) The use of Migration Codes is more expensive during translation since the syntax 

validation needs to be altered (or alternatively turned off); Migration Codes are less 

expensive when transforming data since a data element is used as it is intended. 

 c. Local Code 

(1) A Local Code is a code value that is not in the current version. A Migration Code is 

a particular type of Local Code. Local Codes can also include codes that have not been 

added to future versions. 
3

(2) The use of Local Codes is more expensive during translation since the syntax 

validation needs to be altered (or alternatively turned off); Local Codes are less expensive 

when transforming data since a data element is used as it is intended. 

There is a trade off to using any of the alternative code documentation methods listed above. 

What is gained in semantic clarity is lost in syntactic validation. When doing an EDI-EDI 

translation, the Borrowed Code is preferred. When data transformation is required (e.g., EDIebXML or user defined file), there is a cost to using the Borrowed Code. 

4. PROPOSED CHANGE: This change identifies revisions to DLMS Manual 4000.25-M 

Volume 1, Chapter 8 to include clarifications regarding the use of Borrowed, Local and 

Migration codes. See attached document for proposed changes to Volume 1, Chapter 8. 

5. REASON FOR CHANGE:

a. To clarify DLMSO position on use of borrowed and migration codes as it applies to the 

logistics domain. 

6. ADVANTAGES AND DISADVANTAGES:

There is a trade off to using any of the alternative code documentation methods (i.e., borrowed, 

migration, local). 

a. Advantages: When doing an EDI-EDI translation, the Borrowed Code is preferred. 

When data transformation is not required (e.g., EDI-EDI), the cost to using the Borrowed Code 

is limited to internal Component mapping costs (i.e., no additional cost for X12 translation 

tables). 

b. Disadvantages: What is gained in semantic clarity is lost in syntactic validation. When 

data transformation is required (e.g., EDI-ebXML or user defined file), there is a cost to using 

Borrowed Codes. Mapping costs (i.e., no additional cost for X12 translation tables) are incurred 

regardless of whether Borrowed, Local and Migration Codes are used. 

7. ASSUMPTIONS USED OR WILL BE USED IN THE CHANGE OR NEW 

DEVELOPMENT: none

8. ADDITIONAL FUNCTIONAL REQUIREMENTS: none 

9. IMPACT: All Service/Agency Interface Agreement parties will need to coordinate on 

testing impact of code changes. 

10. FOR XML/842 DEVELOPMENT: Code tables are currently not represented in DLMS 

XML. 
1

Enclosure 1, DLMS Manual update. 

DOD 4000.25-M, Defense Logistics Management System (DLMS) Volume 1 Chapter 8 

STANDARDS AND CONVENTIONS 

C8. CHAPTER 8

STANDARDS AND CONVENTIONS

C8.1. GENERAL INFORMATION

 C8.1.1. Use of ANSI ASC X12. The DLMS uses the ANSI ASC X12 standards for EDI to 

exchange DoD Logistics data. The ANSI ASC X12 standards are formally established, 

maintained, and published under ANSI ASC X12 to provide a common basis for communicating 

shared business information. 

 C8.1.2. ANSI ASC X12 Syntax Rules. The ANSI ASC X12 standards define the specific 

rules of syntax for using EDI constructs and define the universe of components that can be used. 

However, because the ANSI ASC X12 standards are intentionally designed to be very flexible to 

meet the needs of a wide variety of users, additional documentation is necessary to define how to 

use the standards within a specific user community. This documentation is called an IC. 

 C8.1.2.1 Non-Compliant Syntactic Validation of ASC X12 Supersets. ASC X12 

refers to the use of codes from a higher version as a Superset, which is considered 

non-compliant. The ASC X12 standard currently does not allow for use of codes from an 

higher version, nor does it allow substantially changing the meaning of the underlying code 

hence creating confusion and non-compliance with respect to semantic equivalence. 

 C8.1.2.2 DLMS use of ASC X12 Supersets. Although regarded as syntactically 

non-compliant by ASC X12, the DLMS authorizes limited use of Supersets where higher 

version codes (also known as migration codes) are necessary to support Component data 

requirements. Where approved for use under the DLMS, DOD Components and VANS shall 

ensure commercial software products are configured to supports Supersets as documented in 

the DLMS Supplement. 

 C8.1.3. Implementation Conventions. The ICs further define applicable ANSI ASC X12 

TSs used in the DLMS. Within DLMS, DSs to Federal ICs identify and define the segments, 

data elements, and codes that are used in each IC. Most importantly, the ICs specify rules and 

formats for the contents of data within the data elements. 

 C8.1.4. DLMS Supplements to Federal Implementation Conventions. The DSs to Federal 

ICs are organized by functional area: supply, transportation, finance, acquisition, and 

maintenance. A list of the supplements is contained in DLMS appendix 6 and can be accessed 

via hyperlink to the DLMSO home page: http://www.dla.mil/J6/dlmso/elibrary/TransFormats/140_997.asp. 

 C8.1.5. Code Sources
2

 C8.1.5.1. Deriving Code Values. Code values associated with data elements may be 

derived from several locations. Many of the applicable code values for DLMS data elements are 

listed in the DLMS supplements. Three data elements, transportation mode/method code 

(transportation method/type code), unit of issue (unit or basis for measurement code), and type 

pack code (packaging code), use conversion guides to convert the DLSS legacy code structure to 

the ANSI ASC X12 code structure. The DLMS will continue to support other legacy code 

structures used in the DLSS. Special processing at the point of input provides conversion from 

DoD code value to ANSI ASC X12 code value for transmission of the TS. Both the sender and 

the receiver employ the conversion guide so that the user sees only the familiar DoD code 

values. The DLMS Cross Reference/Conversion Guides are available electronically at the 

DLMSO WWW page at: http://www.dla.mil/j6/dlmso/eApplications/LogDataAdmin/dlssdlmscrossreftable.asp. 

 C8.1.5.2. References to Code Source. For data elements that reference a significant 

number of code values and all that are applicable to a DLMS application, specific codes may not 

be listed in the DLMS supplement. In those cases, reference to a code source is provided. 

 C8.1.6. DLMS Qualifiers. 

 C8.1.6.1 DLMS qualifiers are codes used in the ASC X12 -based DLMS Supplement 

to identify a specific data element. The qualifier value is selected from codes approved for use 

by ASC X12 in the version release applicable to the DLMS Supplement. At times there is no 

suitable qualifier available within the ASC X12 dictionary and an alternative code must be used 

to identify and pass the data associated with the business process. There are three methods used 

to accomplish this: 

 C8.1.6.1.1 Borrowed Code. Use of a “borrowed code” refers to establishing an 

agreement with all trading partners to use a valid X12 code at the correct version by altering 

the code’s semantic meaning (i.e., the code is used because it conforms to syntax rules, even 

though it’s intended meaning is different from its use in the identified context). The borrowed 

value must be a value that is otherwise un-used by the trading partners allowing its definition 

to be mutually changed. When a borrowed code is identified for DLMS use, DLMSO shall 

submit an ASC X12 data maintenance (DM) action to establish for a new qualifier to be 

approved for use in a higher ASC X12. The borrowed code may be used indefinitely until 

DoD migrates to a higher version of ASC X12, but, more likely, will be permanent since 

migration to higher versions is very rare. In the case of data element 1270, existing codes are 

associated with a specific industry code list which must be over-ridden by the DLMS use. 

 C8.1.6.1.2 Migration Code. A migration code is when a code from a higher (but 

existing) ASC X12 version is used in a lower version. The semantic meaning and syntax are 

consistent with the higher version. Use of a “migration code” refers to establishing an agreement 

with all trading partners to use a valid X12 code from a higher version, with its approved X12 

definition, at a lower version of X12. ASC X12 refers to the use of a migration code within 
3

implementation guidance as a superset. Manual intervention may be needed for some commercial 

applications to accept the higher version code. 

 C8.1.6.1.3 Local Code. A local code is a code value that is not in the current version, 

and has not been established at a higher ASC X12 version. A DM action may be in process to 

establish the code in a higher version. Once approved by ASC X12, the local code becomes a 

‘migration code.’ Manual intervention may be needed for some commercial applications to accept 

the local code.

C8.1.6.2. DLMS Preference for Borrowed Codes over Migration or Local Codes. To maintain 

consistency between the logistics and transportation domains, the DLMS will use codes from the 

current version of ASC X12 whenever feasible. The preference for documentation of new codes when 

they are not available in the current version is to use Borrowed Codes. When the list of Borrowed 

Codes for a data element has been exhausted or a suitable code cannot be found, Migration Codes 

are an acceptable alternative and will be approved by the PRC Chair/Administrator on a case-by-case 

basis. When codes are borrowed in the logistics domain, DLMSO shall continue to submit code 

changes to ASC X12 to add the code to a future version. Local codes shall only be used where a DM 

action has been submitted, but the associated DLMS Supplement must be updated prior to ASC X12 

approval for the requested value.

 C8.1.6.3 The DSs frequently employ a specific combination of segments and data 

elements to convey encoded information. The DLMS Qualifiers and Cross 

Reference/Conversion Guides list approximately 200 DoD standard data elements such as supply 

condition code, air commodity and special handling code, and management code. The DSs 

specify which code lists are appropriate. DLMS Qualifiers are available DLMSO WWW page 

at: http://www.dla.mil/j-6/dlmso/eApplications/LOG.NET/UIL/Log_Qualifiers/LQHome.aspx. 

C8.2. DLMS SUPPLEMENTS TO FEDERAL IMPLEMENTATION CONVENTIONS. The 

DLMS supplements are presently located on the DLMSO WWW site at http://www.dla.mil/j6/dlmso/elibrary/TransFormats/140_997.asp and are referenced in distinct volumes which 

correspond to the functional areas of supply, transportation, acquisition, maintenance, and 

finance. The DSs address how the standards are implemented. One TS may be used in several 

different functional areas or repeatedly within the same functional area. Each separate 

interpretation of the standards according to a specific usage is called an application. 

 C8.2.1. General

 C8.2.1.1. Purpose. Each DS represents a combination of ANSI ASC X12 standards 

and implementation guidance specific to the DLMS. The manner in which this information is 

presented is consistent from one application to the next. The format used is derived from the 

ANSI ASC X12 guidelines for implementing EDI with slight alteration, where necessary, to 

accommodate the amount of information included. 

 C8.2.1.2. Structure. Each DS begins with a hierarchy table showing the entire TS. 

This is followed by a segment hierarchy for each of the segments used by the application. 
4

 C8.2.1.3. Segment Hierarchy. The segment hierarchy includes a data element 

summary with information pertaining to each data element in the segment. In general, 

information printed in normal typeface is extracted from the ANSI ASC X12 standards and 

information printed in italics relates to the DLMS implementation of the standards. 

 C8.2.2. Implementation Notes

 C8.2.2.1. Instructions on Use of ANSI ASC X12 Standard. In many instances, exact 

equivalents are not available to accommodate the mapping of DoD information requirements to 

the standard. Specific instructions on how a particular portion of the standard is used under DSs 

are provided in the form of implementation notes. These notes explain what data may be carried 

where. They are printed in italics. Notes may be applicable to a transaction set, a segment, a 

data element, or a specific code value depending upon their placement. 

 C8.2.2.2. Importance of Notes. The information provided in implementation notes is 

crucial to understanding the convention. At times, the ANSI ASC X12 data element or code 

value name has little similarity to the commonly used name for a piece of information. 

Additionally, an ANSI ASC X12 data element or code value may be used as a surrogate

borrowed or migration code to carry DLMS-required data not otherwise provided for by the 

standard. It is the implementation notes which explain these circumstances 

C8.3. DLMS DICTIONARY/DIRECTORY. ANSI ASC X12 develops uniform standards for 

electronic interchange of business transactions. The main objective of ANSI ASC X12 is to 

provide standards to facilitate electronic interchange of general business transactions. The 

standards are intended to provide a broad range of ICs by trading partners. By agreement 

between trading partners, ICs are developed to satisfy a specific business interchange. These ICs 

do not incorporate the full range of allowable business information in a TS but tailor the 

configuration of the TSs to identify selected data segments and data elements essential to the 

business interchange. The DoD logistics community has exercised similar judgment in 

developing and defining DSs. The DLMS Dictionary/Directory is an extract of the ANSI ASC 

X12 Dictionary/Directory and reflects only those DSs, data segments, and data elements 

authorized for use in the DLMS data interchange processes. The DLMS Dictionary/Directory is 

available on the DLMSO WWW page at: https://www.dla.mil/j6/dlmso/eApplications/LOG.NET/UIL/Default.ASPx.