1

Approved DLMS Change 57A Addendum

Requisition Modifier Processing

1. ORIGINATOR:

a. Service/Agency: DLMS Supply Process Review Committee

b. Sponsor: Ellen Hilert, DLMSO, SPRC Chair, ellen_hilert@hq.dla.mil, 703-767-

0676, DSN 427

2. FUNCTIONAL AREA: Supply

3. REFERENCES:

DLMSO memorandum, May 23, 2002, subject: Approved DLMS Change 57, Enhanced 

Edits for the Required Delivery Date (RDD) Data Field in Requisitions (Supply/MILSTRIP) 

(Staffed as PDC 65) and Withdrawal of Approved MILSTRIP Change (AMC) 40, Processing 

Cooperative Logistics Supply Support Arrangement Requisitions (CLSSA).

4. REQUESTED CHANGE:

a. Title: Requisition Modifier Processing

b. Description of Change: This change requires rejection of improper requisition 

modifier transactions and enhances the definition of status D7 which will be used to reject 

modifiers that would result in improper use or incompatibility between the RDD and the priority 

designator (PD) under the ADC 57 rules.

c. Procedures: 

(1) MILSTRIP Chapter 3. Revise paragraph C3.25.1.4.1 as indicated.

C3.25.1.4.1 When the modifier transaction contains invalid entries for data 

elements listed in chapter C2, which would require rejection under requisition edits prescribed in 

paragraph C3.1.1., the modifier request will be rejected by means of D7 supply status (DI AE_). 

Additionally, when the modifier transaction contains entries which would result in 

incompatibility or improper use of the RDD and/or PD that would not be acceptable under 

requisition edits, the modifier will be rejected with D7 status. Note: This supply status 

transaction will contain the same data fields as on the unmodified requisition, except for the status 

code (rp 65-66) and transaction date (rp 62-64). This will allow the initiator of the DI AM_ to 

rebuild the requisition as it appears on the supply source records.

(2) MILSTRIP AP2.16, Status Codes. Revise D7 status as indicated.
2

CODE EXPLANATION

 D7 1. Requisition modifier rejected because of errors in one or more data elements.

2. Requisition modifi er may be rejected due to improper application of the

Required Delivery Day (RDD) field and/or Priority Designator (PD). Check 

the original requisition RDD and PD data fields for compatibility with revised input 

Resubmit with appropriate data.

d. Alternatives: No acceptable alternative.

5. REASON FOR CHANGE: During implementation analysis for ADC 57, it became 

apparent that it would most appropriate to reject requisition modifiers which would otherwise 

process, but would not actually modify the requisition as requested. Under ADC 57, some 

incongruities between the RDD and the PD on the requisition input are corrected automatically by 

DAAS or the ICP, sometimes by blanking out the incorrect information. Should the ICP apply 

these same rules to the modifier, the modifier would process and the submitter would receive BK 

status, but the requested change would not occur because the offending value had been blanked 

out or automatically corrected. In order to prevent misunderstandings resulting from this unusual 

situation, it was determined that the only reasonable alternative would be to reject the modifier so 

the submitter can determine the cause of the problem and resubmit with appropriate entries.

6. ADVANTAGES and DISADVANTAGES:

a. Advantages: Forces the submitter to review his input data and resubmit.

b. Disadvantages: None known.

7. IMPACT: Publication(s): DOD 4000.25-1-M, MILSTRIP; DOD 4000.25-M, DLMS; 

DOD 4140.1-R, DOD Materiel Management Regulation, Component implementing instructions