Approved DLMS Change 75

DLA Unique Identification of Internal Delivery Date in Requisitions

1. ORIGINATOR:

a. Service/Agency: DLMS Supply Process Review Committee, Ms. Ellen Hilert, Cochair, J-673 (DLMSO), 703-767-0676 (DSN 427), ellen_hilert@hq.dla.mil 

b. Functional Area POC: Mr. Bob Vitko, J-332

2. REFERENCES:

DLMS Supply PRC Meeting 02-2, April 23-25, 2002

3. REQUESTED CHANGE:

a. Title: DLA Unique Identification of Internal Delivery Date in Requisitions

 b. Description of Change: This change accommodates the Business Systems 

Modernization (BSM) SAP requirement for a delivery date on requisition/order transactions. 

The new date will be calculated by DAASC translator and inserted in the requisition series 

transactions for use in the BSM SAP. This calculated date simulates the UMMIPS Standard 

Delivery Date timeframes associated with the requisition priority designator and RDD entries as 

specified in the DoD Materiel Management Regulation, DoD 4140.1-R, with the exceptions that 

the timeframes for overseas shipments are not geographic area specific and customer RDDs with 

an “S” or “X” in rp 62 are assigned delivery dates based on the entry in rp 63-64. In addition, as 

DAASC is interfaced to DLA BSM using DLMS transactions, the original customer RDD, when 

present, will also be communicated to BSM SAP.

c. Procedures: 

(1) DLSS/DLMS Conversion Required: DAAS will edit the RDD field for all 

DLSS DI Code A0_ requisition transactions submitted to the DLA source of supply under BSM, 

Routing Identifier Code (RIC) = SMS and will create an internal delivery date necessary for 

requisition processing under the SAP program logic. This date is not intended or authorized to 

change any current MILSTRIP/UMMIPS policy relative to requisition processing precedence or 

delivery timeframe requirements. Based upon the conversion logic provided below, DAAS will 

populate the DLMS transaction G62/DTM date field, as applicable, with this calculated date. In 

addition, any data (i.e., day of year or special coding) contained in the customers RDD field will 

be perpetuated to the LQ Qualifier AL, Special Requirements Code. (Note: This will be in 

addition to standard conversion mapping which also creates an appropriate G62/DTM date entry 

in CCYYMMDD format based upon the customer’s required delivery day entry.)

(2) DLMS Requisition Submission - No Conversion Required: Where the 

original requisition is submitted in DLMS format using one of the existing qualifiers to define 
3

the RDD, the DAAS translator will use the same logic to populate the internal delivery date. In 

addition, the translator will convert the CCYYMMDD DLMS date to a three-position day of 

year equivalent and to populate the LQ Qualifier AL, Special Requirements Code.

(3) Add the following codes/notes to the DLMS Implementation Conventions 

(ICs) and DLMS Supplements (DSs).

Transaction Set Location Change

511M and 511R 2/G6201/80 Add qualifier “68” with the following associated DLMS note: 

68 Requested Delivery Date

DLMS Note: For DLA use only to identify the DLA-calculated

delivery date used for internal processing of a customer order.

869F 2/DTM01/030 Add qualifier “002” with the following associated DLMS note:

002 Delivery Requested 

DLMS Note: For DLA use only to identify the DLA-calculated 

delivery date used for internal processing of a customer order.

d. DAAS Delivery Date Conversion Logic

TP1:

(a) If RP4-6=SMS and RP60-61 = 01,02,03 & RP3 = Alpha & RP62-64 is not S numeric 

numeric, X numeric numeric, then calculate a date for the ANSI 511R/511M/869F

G62/DTM segment by adding 3 days to the document number date (RP36-39).

(b) If RP4-6=SMS and RP60-61 = 01,02,03 & RP3 = Numeric & RP62-64 is not S numeric 

numeric, X numeric numeric, then calculate a date for the ANSI 511R/511M/869F

G62/DTM segment by adding 8 days to the document number date (RP36-39).

TP2:

(a) If RP4-6=SMS and RP60-61 = 04,05,06,07,08,09,10,11,12,13,14,15 & RP3 = Alpha & 

RP 62-64 = 444, 555, 777, N__, E__ or RP62-64 is 001-366 and < 8 of RP37-39, then 

calculate a date for the ANSI 511R/511M/869F G62/DTM segment by adding 7 days to the 

document number date (RP36-39).

(b) If RP4-6=SMS and RP60-61 = 04,05,06,07,08,09,10,11,12,13,14,15 & RP3 = Numeric 

& RP62 = 444, 555, 777, N__, E__ or RP62-64 is 001-366 and < 8 of RP37-39, then 

calculate a date for the ANSI 511R/511M/869F G62/DTM segment by adding 14 days to the 

document number date (RP36-39).

TP3:

(a) If RP4-6=SMS and RP60-61 = 04,05,06,07,08,09,10,11,12,13,14,15 & RP3 = Alpha and 

RP62-64 is blank or numeric, other than 444, 555, 777, 999, 001 thru 366 and < 8 of RP37-

39, or alpha/numeric, other than N__, E__, S numeric numeric, X numeric numeric, then 

calculate a date for the ANSI 511R/511M/869F G62/DTM segment by adding 16 days to the 

document number date (RP36-39).
4

(b) If RP4-6=SMS and RP60-61 = 04,05,06,07,08,09,10,11,12,13,14,15 & RP3 = Numeric 

and RP62-64 is blank or numeric, other than 444, 555, 777, 999, 001 thru 366 and < 8 of 

RP37-39, or alpha numeric, other than N__, E__, S numeric numeric, X numeric numeric, 

then calculate a date for the ANSI 511R/511M/869F G62/DTM segment by adding 58 days 

to the document number date (RP36-39).

Special Rules: 

1. If RP4-6 = SMS, regardless of the Priority Designator or CONUS/Overseas indicator, if 

RP62-64 is S numeric numeric or X numeric numeric, then calculate a date for the ANSI 

511R/511M/869F G62/DTM segment using current translator logic using the entry in rp 

63-64 as the number of months in the future from the document number date.

2. If RP 4-6 = SMS, regardless of the Priority Designator, if RP62-64 is 999, then calculate 

a date for the ANSI 511R/511M/869F G62/DTM segment using TP1 timeframes of 3 and 

8 days for CONUS and Overseas respectively.

e. Alternatives: None identified.

4. REASON FOR CHANGE: Under MILSTRIP/DLMS rules, a customer RDD is not 

required, since a standard date can be determined under UMMIPS using the customer’s Priority 

Designator and special coding contained in the RDD field. However, SAP always requires a 

delivery date on the order transactions to facilitate internal processing and monitoring logic. In 

order to accommodate this requirement, DLA will generate a suitable date at DAAS, simulating 

the UMMIPS SDD, to be contained in the DLMS requisition transaction forwarded to the DLA 

BSM source of supply. It is believed that this will be an interim solution to be phased out in a 

later phase of DLMS/SAP implementation.

5. ADVANTAGES and DISADVANTAGES:

a. Advantages: Satisfies BSM SAP requirements for a delivery date. 

b. Disadvantages: Requires complex conversion to support COTS software logic which 

does not conform to DoD procedures.

6. IMPACT: DLA/DAAS 511R implementation reported complete; remaining transactions to 

be addressed as resources become available. Under full DLMS implementation RDD dates will 

be subject to validation in accordance with the ANSI standard thereby eliminating many 

potential problems. 

a. DAAS requisition processing must be modified to comply with above procedures.

b. Publication(s): DoD 4000.25-M, DLMS; DLMS Supplement and corresponding 

Federal IC.