ADC 187 

Revise SDR Reply Procedures for Forwarding SDRs to 

New Action Activity, E-mail Addresses, and SoS 

1. Originator 

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

 b. Sponsor: 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. Requested change 

a. Title: Revise SDR Reply Procedures for Forwarding SDRs to New Action 

Activity, E-mail Addresses, and SoS 

b. Description of Change: This change documents current procedures for 

forwarding SDRs within the DOD WebSDR and proposed changes to accommodate 

more appropriate transaction design. This ADC documents use of WebSDR to 

generate/distribute a new report when the original was sent to the wrong action activity 

and distribution of reports and replies via e-mail based upon e-mail address extracted 

from the incoming transaction. This change also reflects identification of the source of 

supply on the reply transaction (added subsequent to proposal). Significant changes 

subsequent to proposal staffing are highlighted below. 

c. Background: 

 (1) Functionality for forwarding SDRs received at the incorrect action 

activity were discussed during the design and early implementation of DOD WebSDR. 

The resulting agreement on procedures was constrained by available programming within 

the Distribution Standard System (DSS) and the DLA BSM. Because neither system 

could accommodate multiple addressing for identification of multiple activities to receive 

the transaction, a solution was proposed to identify the new action activity Routing 

Identifier in place of the original customer DODAAC on the reply transaction 

(1/N101/1200/Code ZD, Party to Receive Report). This was feasible because the 

database at DAAS already had the customer identification that would normally appear in 

this location. The reply code 504, “SDR Forwarded To New Action Activity As Shown,” 

would trigger the DOD WebSDR process for forwarding whereby the customer (already 

known from the original report) would receive the reply with the designated message and 

the new action activity identified. A secondary action would be taken by WebSDR to 

generate a brand new report transaction from the original report substituting the new 
action activity. All processes associated with a new report would follow, such as 

generation of appropriate information copies. 

 (2) A similar process was created for the web-based reply function. 

When the user selects the reply code 504, an addition window is provided for 

identification of the new action activity. 

 (3) The WebSDR programs to support above concept have been 

completed. However, neither DSS nor BSM completed programming as described. 

Since this process was intended as a “work-around” due to limitations at the time, this 

proposal is provided to modify the above agreement and establish more appropriate 

structure in the 842 reply transaction. 

(4) Background for E-mail Distribution 

(a) Currently, the 842A/W transaction allows for PER segments 

with the CZ, Claim Recipient qualifier. The Air Force Security Assistance Command 

AFSAC-A SDR application is currently programmed to send PER segments with the CZ 

qualifier to identify the e-mail address of the FMS focal points intended to receive the 

transaction via e-mail under special routing rules requested by AFSAC. This is sufficient 

for AFSAC’s primary POC information. However, they would like to send additional 

POC information for use as a backup when a secondary e-mail copy of the transaction is 

required. AFSAC is currently programmed to send PER segments with the secondary 

e-mail address using the FC, Forwarder Contact qualifier. This is not the intended use for 

the FC qualifier. A new qualifier is needed to better reflect the use of the backup POC 

information. This proposal clarifies the use of the CZ and adds a new secondary 

qualifier. Both are added to the 842A/W and 842A/R formats. 

(b) If an SDR is submitted to the action activity outside of 

WebSDR and the original report is not available, the action activity’s reply could still be 

processed and distributed by WebSDR if the reply included the e-mail address of the 

customer. This situation may occur at BSM where the SDR is submitted via the 

Warfighter interface or key entered manually. This proposal provides a unique qualifier 

for the report initiator which would trigger an e-mail from the reply when only the reply 

information is available. [Under current processing, the e-mail distribution to the report 

initiator is provided based upon the original SDR input.] 

 (5) Under WebSDR design the report carries the identification of the source 

of supply (SoS). When the SDR is input by the user the SoS is inserted by DAAS from 

logistics transaction history under defined business rules. When the necessary records 

are not located in history the SoS is left blank. It is also possible that a blank SoS may be 

caused by an SDR transaction from a Service SDR application. When the SDR is 

directed to the Distribution Standard System (DSS) because the shipper is a Distribution 

Depot (DD), the SoS is usually available and can be included in the reply format which 

DSS returns to DAAS for transmission to the customer. The WebSDR design provides 

an information copy of the DSS response to the SoS under established business rules 
established. Inclusion of the SoS in the reply (when not otherwise available) will 

facilitate this process. 

d. Procedures: 

(1) Reply Code 504. Modify SDR reply transaction to include a new 

qualifier to identify the new action activity for use with Reply Code 504. The new 

qualifier for this purpose will be TT, Transfer To. The customer will be identified as the 

ZD, Party to receive Report, as normally done in a reply transaction. When Reply Code 

504 is designated, the WebSDR process will recreate and transmit the original report to 

the designated new action activity. The new report transaction (BNR01=00) will include 

the three additional pieces of information to distinguish it from the original version: 

• Reply Code 504. The new report will retain the reply code 504, SDR forwarded 

to new action activity as shown. 

• Date Forwarded. The Preparation Date will be the same as the original report, but 

a new date will be added to indicate the date the SDR was forwarded by the 

original action activity. This data element is generated by DOD WebSDR for the 

new report transaction based on the date of the 504 reply. 

• Forwarding Action Activity. The new report will identify the party responsible 

for forwarding the SDR. This data element is generated by DOD WebSDR for 

the new report transaction based on the where the original report was sent for 

action. 

• For future consideration. These additional changes are not urgent, but would 

improve procedures and data integrity. The first two item are approved for 

implementation pending resource availability. 

o If SDR reply containing 504 provides both new action activity (TT) and 

identifies a new shipper (2/N101/2800/SH), update the new report with the 

new shipper (as a replacement if applicable). 

o If both the original report and the reply containing 504 identifies BSM as 

the source of supply (2/N101/2800/SUS=SMS), suppress sending an info 

copy of the new report to SMS. The new report will not post to BSM 

since it contains the same WebSDR control number and it is considered a 

duplicate. Manual effort is required to research and resolve. BSM will 

capture the new action activity from the 504 reply transaction and does not 

need additional info copy. 

o During discussion, it was identified that future consideration should be 

given to perpetuating the original action activity’s reply comments to the 

new forwarded report. This will be evaluated separately. 

(2) E-mail Address. As a separate unrelated change, modify the SDR report 

and reply to specifically identify new qualifiers for contact information including e-mail 

address. These new codes will be used to trigger a DAAS/DOD WebSDR process which 

will push the transaction to be distributed to the e-mail address listed in the transaction. 

This allows for specific transactions to be targeted for distribution to specific e-mail 
addresses derived from the transaction (rather than from a table/database or external 

source when this is appropriate. 

• Customer. Specifically indicate the contact information including e-mail address 

of the customer on the reply transaction. If there is no history of the SDR in the 

DAAS database, the e-mail address from the reply would be used to route the 

response to the customer if the qualifier CT, Claimant, is used to identify the 

customer. [The customer POC information is not normally identified in the reply 

transaction, because it was provided on the original report.] 

• Special Routing SDR Recipient. Specifically indicate the contact information 

including e-mail address of parties requiring e-mail distribution by 

DAAS/WebSDR. This is beyond the standard business rules distribution where 

WebSDR determines where to distribute SDRs. As defined here, this will be a 

new standard process available to any using application. It will allow for e-mail 

recipients identified as primary using qualifier CZ, Claim Recipient, and an 

alternate/backup using qualifier ES, Electronic Submission Recipient. This will 

be applicable to the report and the reply formats. 

• These new contact information qualifiers are provided for optional use. They are 

intended for communication with DAASC to trigger outgoing e-mail distribution. 

The e-mail address may be provided without other contact information (name, 

phone, etc.) if this is functionally desirable. The contact information associated 

with CZ or ES qualifiers on a transaction received by a Component application 

need not be stored by the receiving system if not necessary for Component 

processes. 

(3) Source of Supply (SoS) . The DD will include the SoS in the reply when 

available. The SoS in the reply will be used to trigger an information copy to the SoS. 

The information copy of the reply from WebSDR is required when the SoS is BSM (not 

other DLA SoS), USAF, or Navy (does not impact SDRs processed under the direct 

Navy-DSS interface). The DD does not provide direct responses to the customer on 

behalf of USA and USMC SoS, so these are not affected by this process. Other SoS not 

specifically mentioned here should receive the WebSDR transmitted information copy. 

When SoS is left blank on a response from the DD, an e-mail information copy will be 

generated to a default address (to be determined) with the SoS field filled with the 

message “SoS not identified.” 

e. DLMS 842 Changes: 

(1) Revise the DLMS Supplements 842A/R, DOD SDR Reply, as follows: 
 

SDR Reply 

# Location Revisions Reason 

 

1 2/N101/4100 Add new qualifier and note: 

TT Transfer To 

DLMS Note: Use to designate the Routing 

Identifier of the new action activity to which the 

original SDR is to be forwarded (use with Reply 

Code 504 (2/LQ01/4650/HD)). 

Specifically identifies new 

party involved in SDR 

resolution. Identified as a new 

N1 loop in the transaction 

detail. 

2 1/PER01/1700 Add new qualifier and note: 

CT Claimant

DLMS Note: Use to identify the contact 

information of the customer. Include an e-mail 

address for distribution of the SDR reply via 

 e-mail by DOD WebSDR. Use when the original 

report was not entered in WebSDR and, therefore, 

a customer e-mail address is not otherwise 

available. If an e-mail address is associated with 

the customer, WebSDR will make e-mail 

distribution of the reply to the address provided. 

(Use with 1/N101/4100/ZD). 

Adds flexibility. Will permit 

use of WebSDR distribution 

when the original report was 

not submitted in WebSDR. 

WebSDR will be able to send 

the transaction to the customer 

via e-mail using this address. 

Any contact information 

provided using this qualifier 

will be displayed as the 

customer/report preparer 

would be. The only difference 

is this qualifier will trigger an 

outgoing e-mail when no 

e-mail would ordinarily be 

provided due to the absence of 

the initiator’s e-mail address. 

CT qualifier used to 

distinguish intended purpose to 

trigger outgoing e-mail (PU 

qualifier used on incoming 

report transaction would not 

trigger an outgoing e-mail). 
3. 1/PER01/1700 Add new qualifiers and notes: 

CZ Claim Recipient 

DLMS Note: Use to identify the recipient of the 

SDR reply transmitted by e-mail. DoD WebSDR 

will make e-mail distribution of the SDR 

transaction to any party identified as a claim 

recipient. If both qualifiers CZ and ES are used, 

CZ will be considered the primary recipient and 

ES will be considered the alternate/backup 

recipient. (May be used with any 1/N101 

addressee.) 

ES Electronic Submission Recipient 

DLMS Note: Use to identify the recipient of the 

SDR reply transmitted by e-mail. DOD WebSDR 

will make e-mail distribution of the SDR 

transaction to any party identified as an electronic 

(e-mail) submission recipient. If both qualifiers 

CZ and ES are used, CZ will be considered the 

primary recipient and ES will be considered the 

alternate/backup recipient. (May be used with any 

1/N101 addressee.) 

Adds flexibility. Adds CZ 

qualifier for specific use to 

trigger outgoing e-mail. This 

code is used by AFSAC-A 

SDR application to designate 

an e-mail recipient of the SDR 

reply. May be used by others 

as part of a standard process. 

Adds flexibility. Adds ES 

qualifier for specific use to 

trigger outgoing e-mail. This 

code is used by AFSAC-A 

SDR application to designate 

an e-mail recipient of the SDR 

reply. May be used by others 

as part of a standard process. 

4. 2/N101/4100 Add new qualifier and note: 

SUS Supply Source

DLMS Note: Use to identify the supply source by 

Routing Identifier; this is the party that directed the 

shipment.

Perpetuates SoS to the reply. 

Allows the action activity to 

include the SoS in the reply 

when not present in the report. 

Facilitates WebSDR 

generation of required 

information copy to the SoS 

when appropriate. 

(2) Revise the DLMS Supplements 842A/W, DOD Standard SDR, as follows. 
SDR Report 

# Location Revisions Reason 

1 2/DTM01/0600 Add new qualifier and note: 

514 Transferred 

DLMS Note: Use on forwarded SDRs to 

identify the date the SDR was forwarded to a 

new action party by the action party 

designated on the original submission.

WebSDR/DAASC will include in new 

SDR (BNR01=00) when forwarded to a 

new action activity as a result of a 

Reply Code 504. This code identifies 

the date forwarded to distinguish it from 

the date the customer created the report. 

2 2/N101/2800 Add new qualifier and note: 

Z6 Transferring Party 

DLMS Note: Use on forwarded SDRs to 

identify the Routing Identifier of the previous 

action party. This is the party forwarding the 

SDR.

WebSDR/DAASC will include in new 

SDR (BNR01=00) when forwarded to a 

new action activity as a result of a 

Reply Code 504. This code identifies 

the original action party that forwarded 

the report and is retained for 

information only. The system receiving 

the 00 report does not need to store this 

information. 

3 1/PER01/1700 CZ Claim Recipient 

DLMS Note: Use to identify the recipient of 

the SDR report or follow-on action 

transmitted by e-mail. WebSDR will make 

e-mail distribution of the SDR transaction to 

any party identified as a claim recipient. If 

both qualifiers CZ and ES are used, CZ will 

be considered the primary recipient and ES 

will be considered the alternate/backup 

recipient. (May be used with any 1/N101 

addressee.) 

ES Electronic Submission Recipient 

DLMS Note: Use to identify the recipient of 

the SDR report or follow-on action 

transmitted by e-mail. WebSDR will make 

 e-mail distribution of the SDR transaction to 

any party identified as an electronic 

submission recipient. If both qualifiers CZ 

and ES are used, CZ will be considered the 

primary recipient and ES will be considered 

the alternate/backup recipient. (May be used 

with any 1/N101 addressee.) 

Adds flexibility. Qualifier CZ was 

included in prior format, but context of 

its use was slightly different. Clarifies 

use of CZ qualifier for specific use to 

trigger outgoing e-mail. This code is 

used by AFSAC-A SDR application to 

designate an e-mail recipient of the 

SDR transaction. May be used by 

others as part of a standard process. 

Adds flexibility. Adds ES qualifier for 

specific use to trigger outgoing e-mail. 

This code is used by AFSAC-A SDR 

application to designate an e-mail 

recipient of the SDR transaction. May 

be used by others as part of a standard 

process. 

 f. Alternatives: No alternatives identified. 

4. Reason for change: This change will improve DOD WebSDR 

processing/business rules by ensuring the transactional communication between all 

parties is clear and includes required functionality. 
5. Advantages and Disadvantages: 

 a. Advantages: This will improve SDR processing allowing DLA systems to 

trigger specific actions related to SDR resolution. 

 b. Disadvantages: None specifically identified other than expense of system 

modification. 

6. IMPACT: 

 

 a. Data Content/Procedures: This change will impact current processing of 

DAAS/DOD WebSDR and DLA ISDR/DSS, DLA BSM system, and any pending SDR 

transaction exchange by other parties. 

 b. Publications: This change will also impact DOD 4000.25-M, DLMS 

publication and 842A and corresponding DLMS Supplement.