ADC 256 

 WebSDR/Transaction Edits: Forwarding and Follow-up Timeframes 

1. ORIGINATOR:

a. Service/Agency: Defense Logistics Management Standards Office (DLMSO) 

b. Originator: SDR System Administrator, Ellen Hilert, DLMSO, DLA J-6251; 703-767-0676; 

(DSN 427); Ellen.Hilert@dla.mil

2. FUNCTIONAL AREA: Primary: Supply SDR

3. REFERENCES: 

a. DLAI 4140.55/AR 735-11-2/SECNAVINST 4355.18a/AFJMAN 23-215, Reporting of Supply 

Discrepancies 

b. DOD 4000.25-M, Defense Logistics Management System (DLMS), Vol II, Chapter 17 

c. DLMSO memorandum dated December 13, 2005, subject: Approved DLMS Change 

(ADC) 187, Revise SDR Reply Procedures for Forwarding SDRs to New Action Activity, E-mail 

Addresses, and Source of Supply (SoS) 

d. DLMSO memorandum dated December 21, 2006, subject: Defense Logistics Management 

Systems (DLMS) Supply Discrepancy Report (SDR) Subcommittee Meeting, December 6-7, 2006 

4. REQUESTED CHANGE: 

a. Description of Change: This change approves two new edit processes for DOD WebSDR, that 

will improve data quality and enforce existing business rules under referenced guidance. A third, 

forwarding edit, originally proposed under PDC 226, is deferred for further study [this refers to the 

proposed edit to prohibit use of 504 forwarding actions (from material owner to the source of supply), 

related to discrepancy reports for Distribution Depot receipts of requisitioned material for the colocated (retail) site]. Changes from the PDC documentation are highlighted.

(1) Follow-up transactions will be edited to ensure that an appropriate time has elapsed before 

follow-ups may be submitted. 

(2) SDR replies requesting forwarding of the SDR to a new action activity (reply code 504), 

may not be used to forward historical or other record types, which lack full data content necessary to 

establish a basic SDR report transaction. Forwarding for historical transactions will be authorized. 

 b. Background:

(1) Follow-up Edit. The WebSDR initial functional requirement included an edit on follow-up 

timeframes, but it was deferred for later refinement of the business rules, and due to higher priority 

programming requirements. Currently, customers do not understand/follow official guidance on 

timeframes for submission of follow-ups, and this causes unnecessary workload for processing the 

follow-up. The proposed change identified in this document was discussed and recommended during 

the SDR Committee meeting (reference 3.d.). 
(2) Forwarding Edit – Unable to Forward. SDR replies requesting forwarding of the SDR to 

a new action activity (reply code 504), may not be used to forward some historical or other record 

types, which lack full data content necessary to establish a basic SDR report transaction. 

 c. Procedures: 

 (1) Follow-up Edit 

(a) DOD WebSDR and other SDR applications must provide guidance, and ensure a level of 

enforcement for follow-up submission timeframes. Customers are not to submit follow-ups within: 

• 55 days of report submission; or, 

• 30 days, if FMS shipment and Discrepancy Code is S5; or, 

• 30 days, if SDR is for a controlled inventory item or hazardous situation. 

(b) The DAAS edit (on-line and transactions) will not fully enforce the above timeframes, 

since it is not cost-efficient at this time to check for a controlled inventory item code (CIIC), and 

identify exceptions, but the edit will provide business rules and limit premature submission. The 

WebSDR edit will be triggered when the customer selects to create a follow-up SDR. The current date 

will be compared to the date of the transmission of the SDR report to the action activity. If the SDR 

has been forwarded to a new action activity subsequent to the customer submission, DAAS will use 

the date forwarded to count the number of days elapsed. WebSDR will never allow a follow-up if the 

difference is less than 30 days. If less than 30 days, the submission will be blocked, and a pop-up box 

will be displayed for the user as stated below. For transactions, reject using Reply Code 933, SDR 

Follow-up submitted before action activity response time has elapsed. 

Submission of Follow-up SDRs is prohibited until the action activity has 

had sufficient time to process your report. Allow 55 days for processing. 

Exceptions are permitted to allow follow-up after 30 days, when reporting 

discrepant receipt of a controlled inventory item or a hazardous/priority 

situation. 

Forwarding of an SDR to a new action activity will restart the elapsed 

processing time. 

(c) Do not permit multiple follow-ups for the same SDR. DAAS will look to see if there is 

already an SDR follow-up in history, prior to creation of a second follow-up. If there is already a 

follow-up in history, the submission will be blocked, and a pop-up box will be displayed for the user as 

stated below. For transactions, reject using Reply Code 701 with explanation: “SDR follow-up 

already submitted. If no response within 30 days of initial follow-up, contact DDC or SoS for 

assistance.” 

DAAS history shows there is already an SDR Follow-up for this record. If 

no response was received to your initial follow-up within 30 calendar days, 

request assistance from the Source of Supply/Inventory Control Point; or, 

for Distribution Depot shipments, contact the Defense Distribution Center 

at DDC.ISDR@dla.mil. 

Implementation Note: If feasible, DAAS will identify the date of the previous Followup, and direct the user to contact the action office if 30 days from submission.

(d) WebSDR will display guidance for the user on the initial Follow-up screen, to clarify the 
submission timeframe and alert users to look for replies with the query function: 

Submit an SDR Follow-up when the action activity has not responded to your SDR 

within 55 days of report submission, or 30 days if your report concerns a controlled 

inventory item or a hazardous/priority situation. 

Prior to preparing an SDR Follow-up, you should use the WebSDR query function to 

see if a reply is already available, or if your SDR has been forwarded to a new action 

activity. Forwarding of an SDR to a new action activity will restart the elapsed 

processing time. 

(2) Forwarding Edit– Unable to Forward: 

(a) Current Rules for Forwarding Misrouted SDRs. As discussed above, current rules 

for “504” forwarding require a complete record of the original SDR to be resident in DAAS history. 

There are several reasons why the original record may be missing or incomplete. Common reasons 

include, (1) the DSS historical format is not designed to be forwarded, and lacks the necessary coded 

designation of the action activity (since this was used where SAMMS was the source of supply, and 

has now been phased out, it is not worth the effort to modify either the DSS or the DAAS programs); 

(2) during start-up, there are often SDRs which where submitted outside WebSDR; therefore, only 

later transactions are available in history which may lack original information. 

(b) Proposed Edit. DAAS will prohibit use of Reply Code 504 on SDRs which cannot be 

forwarded successfully due to missing original input. A pop-up box will be displayed for the web user 

as stated below. For transactions, reject using Reply Code 935, Forwarding action cannot be processed 

due to incomplete/complex SDR history. Contact originator to resubmit with updated action activity. 

 This SDR cannot be forwarded electronically. 

Please contact SDR initiator (or the organization where this SDR was to 

input) to request resubmission using the corrected/revised action activity. 

(c) Enhancement to 504 Forwarding Process: DAAS will adjust the 504 

forwarding process to permit forwarding using other than the original report record where 

full information is available, and no basic report (original report or information copy), is 

available, or where there is a later transaction from the initiator. Establish an order of use 

so that if there is a customer-submitted transaction later than the original, the report 

information in the forwarded SDR should carry the data content from the later 

transaction. 

[1] Use basic report (original or information copy, Transaction Set Purpose Code=00, 

or 22), or historical records (Transaction Set Purpose Code=49), which include the full data content of 

a basic (other than DSS historical). The action copy of the forwarded SDR will contain a beginning 

segment code 00, New SDR, regardless of whether 00, 22, or 49 was used in the original transaction. 

[2] If a change was posted subsequent to the original record (Transaction Set Purpose 

Code=CO), use corrected data content, and forward using corrected information. The forwarded SDR 

will again contain segment code 00, New SDR. 

[a] If the transaction was input electronically, this means that the corrected 

transaction data elements will reflect the updated values. 

[b] If the transaction was input via direct web input, this means that the corrected 
information will be contained in the remarks block. (Web corrections do not yet support full 

correction capability. Include the remarks from the corrected web transaction in the forwarded SDR.) 

[3] Follow-up and request for reconsideration will work in the same way as corrections 

(depending upon method of input). 

[4] If a cancellation was posted prior to forwarding request, electronic forwarding will 

not be allowed. 

 (3) Update DLMS manual, chapter 17, as revised by Change 4, and the joint instruction. 

Changes are identified in bold italics (paragraph numbering below is for the DLMS manual – only 

excepts are shown below for context):

 C17.3.20. DAAS SDR Processing 

 C17.3.20.2. DAAS shall edit SDR transactions prior to passing/routing, to ensure minimal 

standards of acceptability. Reject to the generating activity SDR and follow-on transactions that do 

not meet the following conditions: 

 C17.3.20.2.9. SDR follow-ups must comply with follow-up submission timeframes. 

Follow-ups submitted without allowing sufficient action activity response time will be rejected (a 

minimum of 30 days will apply). Reject with Disposition/Status (Reply) Code 933. 

 C17.3.20.2.10. Reply Code 504 forwarding action may not be used to forward SDRs where 

incomplete information is available, to construct the new forwarded SDR, or the SDR is otherwise 

not suitable for automated forwarding action. Reject with Disposition/Status (Reply) Code 935. 

(4) Establish new Disposition/Status (Reply) Codes as shown below (Reply code 934 prohibits 

forwarding and is still pending approved procedures): 

933, SDR Follow-up submitted before current action activity response time 

has elapsed. 

935, Forwarding action cannot be processed as an automated action. Contact 

originator to resubmit with updated action activity. 

 d. Reason for Change: The above changes will improve communication with customers, 

processing efficiency, and reduce unnecessary workload, to respond to premature follow-ups, and 

resend SDRs which could not be forwarded. 

5. ADVANTAGES AND DISADVANTAGES: 

 a. Advantages: Better communication with the user.

b. Disadvantages: None identified.

6. ALTERNATIVES: None identified.

7. IMPACT: 

a. Data Content/Procedures: Primary impact is on DOD WebSDR. Component applications 

should be updated to accept new reject reply codes. Phased implementation at DAASC to implement 

the various elements of the change at different times is authorized. 

b. Publication(s): DLMS manual and joint instruction.