ADC 452 Attachment, Page 1

ADC 452

Implementation of DOD WebSDR Automated SDR Rejection Capability

1. ORIGINATING SERVICE/AGENCY AND POC INFORMATION: DLA Logistics 

Management Standards (formerly DLMSO), Ms. Ellen Hilert, SDR System Administrator, 

e-mail: Ellen.Hilert@dla.mil

2. FUNCTIONAL AREA:

a. Primary/Secondary Functional Area: Supply/DOD WebSDR

3. REFERENCES: Defense Logistics Management System (DLMS) Manual, DOD 

4000.25-M, Volume II, Chapter 17, available on DLMS manual Web at: 

www.dla.mil/j-6/dlmso/elibrary/Manuals/DLMS/default.asp. The DLMS manual is the 

authoritative source for discrepancy reporting procedures originally published under DLAI 

4140.55, AR 735-11-2 SECNAVINST 4355.18A, AFJMAN 23-215, Reporting of Supply 

Discrepancies

4. BACKGROUND:

a. SDR Transaction Rejection or Failure Categories:

(1) DOD WebSDR Transaction Rejection Processing Procedures: The DLMS 

manual identifies multiple transaction edits that require the capability within the DOD WebSDR

application to edit and reject transactions systemically based upon the pre-established business 

rules. This applies to basic rules that could be applied external to the action activity based upon 

research or relevant information known only to the action activity. (Refer to the DLMS manual 

extract shown at Enclosure 4.) Implementation of this capability was deferred with the 

understanding that the receiving application could recognize and reject transactions with missing 

or erroneous data content when applicable. This capability was not considered essential for 

initial implementation of the DLMS SDR transaction exchange. However, the delay in 

implementation has placed a burden on the Components because (1) not all Components are 

supported by an SDR application and, therefore, erroneous data must be identified manually, (2) 

not all SDR applications have sufficient edits to systemically identify and reject missing and 

invalid data content without significant manual intervention for some types of errors. 

(2) Transaction Failure during WebSDR Processing: DLA Transaction Services 

identified additional situations where SDR transactions fail during processing and manual 

intervention is required from DLA Transaction Services personnel to notify the SDR submitting 

system personnel off-line due to incorrect structural format or major errors in mandatory content. 

For this scenario, Enclosure 1 contains error statistics for the period March through June 2011. 

Note: Gross failures in electronic data interchange (EDI) transactions may be identified by the 

Global Exchange (GEX) prior to WebSDR processing. These will be reported to the submitting 

systems personnel identified in system interface documentation. 

(3) Functionally Inappropriate SDR Transactions: DLA Supply Centers have

identified additional situations where SDR transactions successfully process through WebSDR 

only to fail in the Component receiving application due to functionally inappropriate content or 
ADC 452 Attachment, Page 2

process. In these situations, systemic rejection by WebSDR (via immediate response for on-line 

users or via reject reply transaction) would have saved significant time, effort, and reduced 

frustration at both the customer and action activity level. 

b. Intent of this Change: The intent of this change is to clarify and implement existing 

business rules for DOD WebSDR automatic rejection and to establish new procedures supporting 

automated rejection where needed.

c. Scenario for which the transaction will be used: 

(1) When WeBSDR system identifies an SDR transaction with missing or invalid 

data content, it will systemically reject the transaction back to the submitter. This includes both 

properly constructed transactions that allow successful processing inside WebSDR and 

improperly constructed transactions that cannot be processed. The most frequent types of invalid 

data errors that prevent WebSDR processing are invalid document numbers and a missing action 

activity (Enclosure 1). Common examples of invalid data errors that are passed on to the action 

activity are invalid DoDAACs or Routing Identifier Codes (RICs) used for action activity, 

submitter, or shipping activity.

(2) Functionally inappropriate transactions will be identified and rejected or blocked 

during WebSDR input. Common examples are submission of a follow-up transaction or a

reconsideration request subsequent to the cancellation of the SDR and submission of Air Force 

maintenance document number SDRs (identified by the AF maintenance site M-series identifier 

in the first six characters of the document number rather than a valid DoDAAC and associated 

with an Air Force submitting activity) external to the Air Force and the supporting distribution 

depot.

d. Procedures, transactions, data elements, processing details in use today: 

(1) Transaction Failure during WebSDR Processing: Receivers of discrepant 

materiel submit an SDR via a Component-sponsored automated SDR system that creates a 

DLMS transaction for transmission to DLA Transaction Services for processing in DOD 

WebSDR. Transactions must be formatted per DLMS requirements for X12 electronic data 

interchange (EDI) or eXtensible markup language (XML) transactions. DLA Transaction 

Services’ error logic statistics for recent months show an increase in SDR submissions with 

invalid data. Data is either missing or inconsistent with the required format of the SDR data 

fields. When data content prevents system processing, the DLA Transaction Services 

programming team receives notification via an automated email message from WebSDR. Each 

of these messages must be researched and resolved manually. The current resolution process 

handled by the DLA Transaction Services team is manual and entails the following steps.

(a) Emails show up in the DLA Transaction Services’ programming team 

member email inbox.

(b) DLA Transaction Services’ programming team member filters through 

emails to determine if errors are from the production side of WebSDR. A review of the details is 

performed to determine if error(s) are submitting system generated and notification is sent back

to the submitting system via email address. At times, analysis of the internal flat file that each 

system submits is required.
ADC 452 Attachment, Page 3

(c) Once the type of error has been determined, the email is forwarded to 

another member of DLA Transaction Services programming team for further research. This 

research involves using the raw EDI data from each submitting system to include archived EDI 

files.

(d) Once the raw data is retrieved from the EDI submission, the data is reviewed 

for the specific type of error(s) and an error information summary is created in a manual 

document/file. The error information includes: 

• the error itself (i.e. missing Document Number),

• area(s) within the X12/XML where the error occurred,

• whether the submission contains malformed X12/XML data with notes on the 

correct structure, and

• invalid data format with notes on the correct format.

(e) The error information is resaved in a file in preparation for sending an email 

attachment back to the submitting system representative.

(f) The error information is then included in an email back to the submitting 

system representative, as well as a copy to the DLA Transaction Services WebSDR Team.

(2) Transaction Failure during Component SDR System Processing: 

Component SDR systems, such as the DLA Enterprise Business System (EBS), may receive a 

transaction that cannot be successfully processed and results in a failed transaction (referred to 

by DLA as a failed iDoc). These transactions accumulate and must be manually worked to 

determine the cause of the error. This can be a challenging process and delays in notifying the 

submitter and/or reprocessing the failed transaction can be significant. Often, a rejection reply

transaction must be manually prepared. This situation impacts the overall processing time for 

corrective action and SDR resolution.

(3) Automated Rejection of SDRs by Component SDR Systems: Some errors in 

SDR content may be found after successful processing by DOD WebSDR only to be identified 

by the SDR application. While this may not result in significant lost time because a reject reply 

transaction is immediately returned to the submitter, it is far less efficient than identification of 

the error upon initial input via WebSDR or rejection of transactions upon initial processing by 

WebSDR. 

(4) Functionally Inappropriate SDR Transactions: Due to the staggered 

implementation plan, there is currently no WebSDR edit that prevents submission and 

distribution of a follow-up or reconsideration request applicable to a cancelled SDR. 

Additionally, there is no WebSDR edit that prevents an Air Force maintenance document 

number SDR from being directed to another Component source of supply. Currently, the 

WebSDR reply screen does not support manual selection of reject reply codes for use by action 

activities. The gap reduces visibility via management reports of the number of scope of data 

rejections. 
ADC 452 Attachment, Page 4

5. APPROVED CHANGE

a. Approved change in detail. Significant revisions subsequent to staffing of PDC 478 

are highlighted.

(1) When the DOD WebSDR identifies an SDR (input via direct user input or via 

DLMS transaction exchange) containing missing/invalid data content or not following DOD 

business rules, forward transmission of that SDR will be prevented. This will require use of online error messages and additional program logic to support creation and return of a DLMS 

842A/R Standard SDR Reply transactions (Transaction Set Purpose Code 11) with the 

appropriate reply disposition code. Additional program logic will also be needed to support 

creation of outgoing email messages to Component SDR application representatives when 

egregious errors prevent posting of the SDR to the WebSDR database and return of a standard 

reply transaction. Whenever possible, transactions containing errors will be posted to the 

WebSDR database so that visibility will be enhanced and metrics can be maintained. The 

following errors are subject to systemic automated reject:

(a) SDR Follow-up or Contested SDR/Reconsideration Request after SDR is 

cancelled. Reject with Reply Code 907. The SDR will include remarks text (or tailored error 

message for on-line WebSDR users) as follows: “SDR Follow-Up (or Reconsideration Request) 

may not be processed after the original SDR has been cancelled. If still required, resubmit the 

original SDR citing Discrepancy Code Z6 and clarification. Staffing Note: Components must 

review internal processing to ensure that the resubmission will be accepted. The business rule is

for the resubmission of the original SDR document number to be assigned the same DOD 

WebSDR control number so that the original SDR, cancelled SDR, Follow-up/Reconsideration 

Request, Reject Reply, and the subsequent resubmission will all be associated. These will be 

displayed on the SDR Composite View in submission sequence. Components should verify that 

the resubmission (using DLMS 842 A/W, Transaction Set Purpose Code 00) will not reject as a 

duplicate if there is already a cancelled SDR in the Component SDR application for the same 

document number/suffix (and potentially other matching content). A new SDR Discrepancy 

Code Z6 has been assigned for use on SDRs that are resubmitted after cancellation so that 

systemic recognition of this situation can be recognized and accepted.

(b) Document Number or Document Number/Suffix Combination. Reject 

with Reply Code 910 if missing, contains spaces or special characters, or Julian day exceeds 365 

(or 366 for leap year), or is not considered a valid document number. A valid document number 

(not including the suffix) must be 14 positions and the first six positions must be a valid 

DoDAAC unless identified as Security Assistance/Foreign Military Sale by the Service/Agency 

Code in the first position of the document number, or as an Air Force Maintenance document 

number. Authorized Service/Agency values indicating Security Assistance are B, D, I, K, P, and 

T. Suffixes must be alphabetic or numeric with the exception that the following alpha and 

numeric characters are not authorized: alpha I, N, O, P, R, S, and Z and numeric 1 and 0. 

Exception: The full document number edit does not apply to transshipper SDRs (Document 

Type W) due to the potential for reporting against the shipment unit rather than a specific 

document number. For these SDRs, the document number must be filled and must be 14

positions. It may contain the first 14 positions of the transportation control number, a purchase 

request number (14 positions) if known, or a constructed document number based upon the 

DoDAAC of the port submitting the SDR. 
ADC 452 Attachment, Page 5

(c) Document Number – Air Force Maintenance. Reject with Reply Code 910 

if an Air Force maintenance document number SDR Action Activity is other than Air Force or 

Distribution Depot. The Air Force maintenance document number is identified by the “M” in the 

first position where the SDR submitter is an Air Force activity. Air Force maintenance 

document numbers are allowed on a temporary basis between appropriate trading partners to 

support legacy Air Force processing. This process is non-compliant with DOD business rules 

and will be discontinued under Air Force modernization. The SDR will include remarks text (or 

tailored error message for on-line WebSDR users) as follows: “SDRs containing the Air Force 

maintenance document number as the primary document number may not be directed outside the 

Air Force or supporting Distribution Depot. If directed to DLA or other Service, the SDR must 

be associated with the original requisition document number.”

(d) Discrepancy Code. Reject with Reply Code 915 if at least one discrepancy 

code is not provided or does not match allowable values under DLMS.

(e) SDR Action Code. Reject with Reply Code 916 if missing or does not match 

allowable values under DLMS.

(f) Discrepant Quantity. Reject with Reply Code 917 if missing or not numeric.

(g) Invalid Quantity. Reject with Reply Code 918 if other quantity fields are 

not numeric. The SDR will include remarks text to identify the specific data field in error.

(h) Invalid POC E-mail Address. Reject with Reply Code 921 if missing or 

contains spaces/incorrect format.

(i) Missing Narrative. Reject with Reply Code 924 if an SDR coded to indicate 

remarks are provided is missing applicable narrative (applicable to Reply Codes 102, 104, 105, 

106, 137, 701).

(j) Disposition/Reply Code. Reject with Reply Code 927 if at least one reply 

code is not provided on SDR reply or does not match allowable values under DLMS.

(k) Supply Condition Code. 

1. Reject with Reply Code 928 if missing when required for condition code 

discrepancy scenario (Discrepancy Code C1, C3, C4, and C5) or does not match allowable 

values as follows, otherwise may be blank.

• A Serviceable

• B Serviceable (with qualification)

• C Serviceable (with priority)

• D Serviceable (test/mod)

• E Unserviceable (restoration)

• F Unserviceable (repairable)

• G Unserviceable (incomplete)

• H Unserviceable (condemned)

• J Suspended (In-stock)

• K Suspended (Returns)

• L Suspended (Litigation)
ADC 452 Attachment, Page 6

• M Suspended (In work)

• N Suspended (Ammo)

• P Unserviceable (Reclamation)

• Q Unserviceable (Product Quality)

• R Suspended (Reclaimed) 

• S Unserviceable (Scrap)

• T Serviceable (Ammunition Suitable for Training Use Only)

• V Unserviceable (Munitions) 

2. Reject if condition code is not applicable to the action activity/source of 

supply as follows. The SDR will include remarks text (or tailored error message for on-line 

WebSDR users) as follows: “Condition code identified is not applicable to the action 

activity/source of supply.”

• T May not be submitted to DLA (RIC SMS)1

• N May not be submitted to DLA (RIC SMS)

• V May not be submitted to DLA (RIC SMS)

(l) Action Activity (To Address). Reject with Reply Code 929 if the Routing

Identifier Code (RIC) or DOD Activity Address Code (DoDAAC) is missing or unmatched to 

the DOD Activity Address Code Directory. The SDR will include remarks text (or tailored error 

message for on-line WebSDR users) as follows: “Missing value for SDR Action Activity. 

Research and resubmit a value authorized by the DOD Activity Address Code Directory.” or

“Unacceptable value used for SDR Action Activity (XXX). Research and resubmit a value 

authorized by the DOD Activity Address Code Directory.” 

(m) Submitter (From Address). Reject with Reply Code 929 if the RIC or 

DoDAAC is missing or unmatched to the DOD Activity Address Code Directory. The SDR will 

include remarks text (or tailored error message for on-line WebSDR users) as follows: “Missing 

value used for SDR submitter. Research and resubmit with a value authorized by the DOD

Activity Address Directory.” or “Unacceptable value used for SDR submitter (XXXXXX). 

Research and resubmit with a value authorized by the DOD Activity Address Directory.”

(n) Owner/Manager/Source of Supply. Reject with Reply Code 929 if the RIC

is unmatched to the DOD Activity Address Code Directory. The SDR will include remarks text 

(or tailored error message for on-line WebSDR users) as follows: “Unacceptable value used for 

identification of the owner or manager. Research and resubmit with a value authorized by the 

DOD Activity Address Directory.”

(o) Shipping Activity. Reject with Reply Code 929 if the RIC is unmatched to 

the DOD Activity Address Code Directory. The SDR will include remarks text (or tailored error 

message for on-line WebSDR users) as follows: “Unacceptable value used for identification of 

the shipping activity. Research and resubmit with a value authorized by the DOD Activity 

Address Directory.”

 1 Refer to ADC 446, Proposed New Supply Condition Code T, Serviceable (Ammunition Suitable for Training Use 

Only).
ADC 452 Attachment, Page 7

(p) Wrong Item Information. Reject with Reply Code 932 if wrong item 

information is not provided in association with W- series Discrepancy Codes.

2

(q) Duplicate SDR. Reject with Reply Code 719 (SDR rejected. Duplicate of 

previously submitted SDR) when a new SDR (Transaction Set Purpose Code 00) matches an 

existing SDR record on document number/suffix, discrepancy code, and transportation control 

number (if provided) (where the original SDR has not been cancelled). The SDR will include 

remarks text (or tailored error message for on-line WebSDR users) as follows: “This new SDR 

matches an existing SDR record on document number/suffix, discrepancy code, and 

transportation control number (if provided). Staffing Note: DOD Components do not currently 

apply the duplicate criteria consistently. The WebSDR criteria as stated here is the approved 

approach for DLMS implementation and Components should transition to these rules when 

feasible. When alternative rules are applied (e.g. rejection based upon document number/suffix

match alone), the action activity must inform the user how to resubmit the SDR if the 

discrepancy report if not created in error.

(r) Other. Reject with Reply Code 701 (SDR rejected. See remarks) when 

rejection conditions not identified by specific reject reply codes are identified. The SDR will 

include remarks text to clarify the error condition. Recurring use of the reply code must be 

reported to the SDR Administrator for evaluation of a new reply code assignment.

(2) New reply codes are established and recognized by Component SDR applications 

for use in additional WebSDR automated edits as follows. Refer to Enclosure 2 for exact text of 

new reply codes.

(a) Transaction Set Purpose Code. Reject with Reply Code 938 if missing or 

not an allowable value in accordance with the applicable DLMS Supplement. Note: This type 

of error cannot be posted to the WebSDR database. Use of this code requires notification to the 

applicable submitting system personnel rather than the transaction originator.

(b) SDR Document Type Code. Reject with Reply Code 939 if missing, not an 

allowable value under DLMS, or not allowable under DLMS business rules. This reply code 

will be used for an SDR identified as a Type 6, but directed to a DLA Distribution Depot with 

remarks: “Distribution Depots cannot accept Document Type 6 SDRs which are applicable to 

vendor shipments. Research for correct Document Type or Action Activity and resubmit.”

(c) Missing Contract Number/Shipment Number. Reject with Reply Code 940

if missing either contract number or contractor-assigned shipment number on SDR Document 

Type 9 [distribution depot receipt, new procurement] or P [storage activity receipt, new 

procurement (non-DSS location)]. Note: Contract Number is not mandatory on Document Type 

6, Direct Vendor Delivery, SDR submissions, but must be inserted by the action activity on the 

reply transaction when not provided by the customer. The specific shipment number should be 

included if known.

(d) Unauthorized Use of Reply Code. Reject with Reply Code 941 interComponent SDR replies citing a 200-series reply code is used for a non-Security Assistance

SDR. Security Assistance are document numbers begin with Service/Agency Code B, D, I, K, P, 

 2 Separate PDC under development to clarify wrong item discrepancy data requirements.
ADC 452 Attachment, Page 8

and T. Note: Use of this code requires notification to the applicable submitting system 

personnel rather than the transaction originator.

(3) WebSDR Enhancement for Online Users: Disposition/reply codes in the 900 

series will be added to the WebSDR drop box for use by on-line action activity users when 

applicable.

b. Approved procedures:

(1) WebSDR procedures:

(a) SDR transactions containing errors that are incompatible with requirements 

for posting to the WebSDR database will be “dead-ended” (not fully processed, the file itself will 

be archived, but not inserted into history/metrics because the nature of the error(s) cause 

database violations).

(b) SDR Reply transactions generated by WebSDR will be constructed as 

follows and returned to the sending system:

WebSDR Control Number (the DOD WebSDR assigned control number)

Activity From = SGA (representing DLA Transaction Services)

Reply Code(s) = Up to three 700/900-series rejection codes

Document Number/Suffix (perpetuated from rejected transaction)

Date of Preparation (DDMMMCCYY)

Reply POC Information (representing DLA Transaction Services Help Desk)

All Control Numbers from rejected transaction

Transaction Set Purpose Code = 11

Action To (representing rejected transaction ‘Activity From’)

Reply Comments = (Reply comments with error description)

All other values from rejected transaction

(c) SDRs with invalid data will post to the WebSDR database and then 

WebSDR will transmit the reject reply. The reply transaction identifying the reject reply code 

and applicable content will also post to the WebSDR database for visibility and metrics. The 

reject reply will be provided in the same method as the rejected transaction, i.e., by transaction to 

submitting Component application or via e-mail if the submitter used WebSDR. Once the 

rejection is posted, a new submission will be required by the submitter.

(d) If posting to the WebSDR database is not possible due to major structural or 

content error, an automated email identifying the nature of the error will be transmitted to the 

responsible Component system representative. The Component system representative will be 

responsible for correction and re-transmission, and notification to the user if retransmission 

within 24 hours is not possible.

c. Alternatives: None.

6. REASON FOR CHANGE: Increased efficiency and responsiveness of the SDR 

processing. To reduce manual processing due to erroneous or improper SDRs.
ADC 452 Attachment, Page 9

7. ADVANTAGES AND DISADVANTAGES:

a. Advantages (tangible/intangible)

(1) Historical data can be used to create management reports for Component process 

improvement and to develop training aides.

(2) Ensures all SDR submissions remain DLMS compliant. 

b. Disadvantages:

(1) Requires additional program logic to generate and receive rejection transactions. 

(2) Looping of transactions could occur if the Component application rejects the 

WebSDR reject reply. DLA Transaction Services will need to be alerted immediately if a reject 

of a reject is returned so the loop can be terminated and addressed off-line.

8. ASSUMPTIONS:

a. All systems must be designed to accept reject codes. Alternative procedures to monitor 

for reject replies must be instituted pending full implementation.

b. Rejections should be handled systemically wherever feasible.

c. WebSDR management report processing will use the most current status in the case of 

a rejected transaction which is later resubmitted (e.g., the original rejected status will not 

interfere with the selection of the report for open SDRs). 

d. The same WebSDR control number will apply to resubmitted SDRs subsequent to 

rejection. 

9. NOTE ANY REGULATIONS OR GUIDANCE: Defense Logistics Management 

System (DLMS) Manual, DOD 4000.25-M, Chapter 17.

10. ESTIMATED TIME LINE/IMPLEMENTATION TARGET: Unknown – phased 

implementation is authorized. New code values are authorized for use beginning January 15, 

2012.

11. ESTIMATED SAVINGS/COST AVOIDANCE ASSOCIATED WITH 

IMPLEMENTATION OF THIS CHANGE: Implementing the WebSDR automated rejection

capability will dramatically reduce the time-consuming (5-15 minutes on average for each SDR 

containing errors) and manual resolution process performed by the DLA Transaction Service 

programming team, allowing their time to be refocused on higher priority programming tasks. 

Additionally, the enhanced programming will prevent failed transactions in other Component 

applications and significantly reduce manual resolution of erroneous transactions. The improved 

overall responsiveness of the SDR program could also result in a significant cost avoidance and 

improved support to the war fighter.
ADC 452 Attachment, Page 10

12. IMPACT:

a. New DLMS Data Elements: There are no new data elements associated with this 

change.

b. Revised DLMS Data Elements: New Disposition/Reply Codes are assigned as shown 

in Enclosure 2. A new discrepancy code is assigned as follows:

Z6 SDR resubmitted following inappropriate cancellation. Must use in combination 

with other discrepancy codes.

c. DLA Transactions Services: Should develop a method to capture metrics/error rates 

for the category of transactions that will “dead end” and cannot post to the WebSDR database 

due to major structural errors.
ADC 452 Enclosure 1, Page 1

Enclosure 1, Rejected Transactions as a result of invalid data on Original SDR submissions

The table below shows a snapshot of rejected transactions that required manual review by DLA 

Transaction Services during the period March, 2011 through June, 2011. 

OVERALL Mar-11 Apr-11 May-11 Jun-11

Activity From - Invalid 0 1 1 0

Activity From - Missing 0 0 0 0

Document Number - Invalid 1 83 11 6

Document Number - Missing 1 2 1 0

Disposition Code - Invalid 0 0 0 0

Disposition Code - Missing 2 8 0 3

WebSDR Number - Invalid 0 0 0 0

Email Address - Invalid 3 1 7 3

Transaction To - Invalid 0 1 0 1

Transaction To - Missing 57 101 107 68

TOTALS: 64 197 127 81

Does not include conditions that would be considered errors after the new logic is in 

place...

Invalid Activity value (DOD Activity Address Directory checked)

Invalid Disposition/Reply Code 

Invalid Action Code 

Invalid Discrepancy Code 

Invalid SDR Submission Type

Invalid Document Suffix 

Looping

Data Source: DLA Transaction Services
ADC 452 Enclosure 2, Page 1

Enclosure 2, SDR Reject Reply Codes (900-series)

DISCREPANCY STATUS OR DISPOSITION (REPLY) CODES

The 900-series codes are intended for system/application use in processing transactions. When SDRs 

are processed manually, these codes may be user assigned as appropriate:

901 Transaction rejected. SDR submitted to wrong source of supply. Resubmit to the correct 

action activity.

902 Transaction rejected. Invalid action code for type of discrepancy submitted.

904 Transaction rejected. Open suffix must be closed before SDR can be reopened.

906 Transaction rejected. Record already closed.

907 Transaction rejected. Record closed, canceled, or a final reply has been provided.

908 Transaction rejected. Record is currently open and cannot be reopened for reconsideration 

until closed.

909 Transaction rejected. SDR must be reopened for reconsideration before it can be contested. 

910 Transaction rejected. Missing or invalid document number (or document number/suffix).

911 Transaction rejected. Missing or invalid case designator.

912 Transaction rejected. Missing or invalid SDR number.

915 Transaction rejected. Missing or invalid type of discrepancy code.

916 Transaction rejected. Missing or invalid action desired code.

917 Transaction rejected. Missing or invalid discrepant quantity.

918 Transaction rejected. Missing or invalid quantity received.

920 Transaction rejected. Missing or invalid point of contact name.

921 Transaction rejected. Missing or invalid point of contact phone number/email.

923 Transaction rejected. Missing or invalid transaction date.

924 Transaction rejected. Narrative missing.

926 Transaction rejected. No record found.

927 Transaction rejected. Missing or invalid disposition/reply code

928 Transaction rejected. Missing, or invalid, or unauthorized use of condition code.

929 Transaction rejected. Missing or invalid DoDAAC, MAPAC, or Routing Identifier Code

930 Transaction rejected. Missing information associated with disposition/reply

931 Transaction rejected. Missing or invalid material identification.

932 Transaction rejected. Missing or invalid wrong item information. 

933 Transaction rejected. SDR follow-up submitted before action activity response time 

 has elapsed. 

934 Transaction rejected. Forwarding action not authorized. Submit new SDR 

935 Transaction rejected. Forwarding action cannot be processed due to incomplete SDR 

history. Contact originator to resubmit with updated action activity. 

936 Transaction rejected. SDR processing suspended. Request DOD WebSDR provide an 

information copy of the original report. 

937 Transaction rejected. DOD WebSDR unable to provide requested SDR information copy.

938 Transaction rejected. Missing or invalid Transaction Set Purpose Code. 

939 Transaction rejected. Missing, invalid, or inappropriate SDR Document Type Code.

940 Transaction rejected. Missing either contract number or contractor-assigned shipment 

number on SDR associated with vendor shipment.

941 Transaction rejected. Unauthorized Use of Reply Code. The 200-series reply codes may 

only be used for Security Assistance SDRs.
PDC 478 Enclosure 3, Page 1

Enclosure 3, Example WEBSDR Email for Automated Rejection Notification

The following example provides a clear text automated reject notification to a WebSDR user. Note: 

Authorized users with an email certificate on file at DLA Transaction Services will receive a more 

detailed version with encrypted text designated as For Official Use Only.

- THIS IS AN SDR REPLY -

*** DO NOT SEND RETURN EMAIL TO THE DODSDR MAILBOX ***

ALL COMMUNICATIONS REGARDING SDRS SHOULD BE DIRECTED TO THE PARTIES IDENTIFIED 

BELOW.

THIS MESSAGE IS PROVIDED BY THE DOD WEBSDR AS PART OF THE SDR TRANSFORMATION 

INITIATIVE.

TRAINING ON THE DOD WEBSDR IS AVAILABLE AT 

HTTP://WWW.DLA.MIL/J-6/DLMSO/EAPPLICATIONS/TRAINING/TRAINING.ASP

SYSTEM ACCESS REQUESTS MUST BE SUBMITTED ON-LINE AT 

HTTPS://WWW.TRANSACTIONSERVICES.DLA.MIL

CONTACT DOD WEBSDR AT: WEBSDRHELP@DLA.MIL

----------------------------------------------------------------------------

 DOD WEB SDR NUMBER: 20092040190

 SUBMISSION TYPE: RESPONSE

 SDR DOCUMENT TYPE: 7 - CUSTOMER ORIGINATED, DEPOT SHIPMENT

 DOCUMENT NUMBER: FB203090289999

----------------------------------------------------------------------------

----- SDR DATE INFORMATION -------------------------------------------------

 RESPONSE DATE: NOV 18 2011

----- SDR REPLY REMARKS/COMMENTS -------------------------------------------

UNACCEPTABLE VALUE USED FOR SDR ACTION ACTIVITY (XXX). RESEARCH AND 

RESUBMIT A VALUE AUTHORIZED BY THE DOD ACTIVITY ADDRESS CODE DIRECTORY

----- RESPONSE INFORMATION -------------------------------------------------

DISPOSITION STATUS CODE: 929 - TRANSACTION REJECTED. MISSING OR INVALID DODAAC, 

MAPAC, OR ROUTING IDENTIFIER CODE.

----- SDR INITIATOR ACTIVITY INFORMATION -----------------------------------

RIC: FB2030 (VIA DOD WEBSDR)

----- REPLYING ACTIVITY INFORMATION ----------------------------------------

 RIC: SGA (FOR DOD WEBSDR)

----- REPLY POINT OF CONTACT INFORMATION -----------------------------------

NAME: DOD WEBSDR AUTOMATED REJECT

CONTACT DOD WEBSDR AT: WEBSDRHELP@DLA.MIL IF FURTHER ASSISTANCE IS NEEDED
ADC 452 Enclosure 4, Page 1

Enclosure 4, DLMS Manual DOD4000.25-M

The following DLMS manual extract reflects text updated by Approved DLMS Changes. Revisions 

are identified in red bold italics.

C17. CHAPTER 17.

SUPPLY DISCREPANCY REPORTING

C17.1.3. DoD WebSDR. The DoD WebSDR supports DLMS implementation via a 

DLA Transaction Services-maintained application which enables SDR transaction exchange; provides 

a web-based entry method to assist users who are not supported by a Component DLMS-compliant 

SDR application; and provides visibility of SDRs for research and trend analysis via management 

report/query capability. The term “DoD WebSDR” (or “WebSDR”) refers to both the overall 

business process and supporting automation, including both direct web-input and transaction 

exchange.

(Intervening text not shown) 

C17.1.3.5. DoD Components with an established interface with DoD

WebSDR shall designate primary and alternate representatives for the Component SDR application 

to DLA Transaction Services. These representatives will be notified via email when transactions fail 

during WebSDR processing due to failure to meet minimum format/content requirements for 

processing. Provide name, telephone, and email address.

(Intervening text not shown) 

C17.3.21. Defense Automated Addressing System (DAAS) SDR Processing

C17.3.21.1. Under DLMS, SDRs shall be integrated with standard logistics 

transaction processing through DAAS. DAAS/WebSDR shall perform the following actions:

C17.3.21.1.1. Pass/route SDR transactions

C17.3.21.1.1.1. Generate and route an information copy of each SDRs

reporting packaging discrepancies associated with USAF-directed shipments to the USAF packaging 

office.

C17.3.21.1.1.2. Route the action copy of SDRs reporting distribution 

depot receipt of PQDR exhibits (Discrepancy Code Q11) to the materiel owner and an information 

copy to Product Data Reporting and Evaluation Program-Automated Information System (PDREPAIS). For USAF owners, an information copy will also be sent via to the Joint Discrepancy Reporting 

System (JDRS) email account.

C17.3.21.1.1.3. Provide special email routing of the action or distribution 

copy of transshipper prepared SDRs upon Component request.3

 3 Refer to ADC 317.
ADC 452 Enclosure 4, Page 2

C17.3.21.1.1.4. Return un-routable transshipper prepared SDRs to the 

submitter for continued processing off-line.4

C17.3.21.1.2. Edit SDR transactions in accordance with business rules specified 

below.

C17.3.21.1.3. Provide translation capability to support a variety of 

communications methods for exchanging computer-readable SDR transactions.

C17.3.21.1.3.1. DLMS transaction formats are available in ASC X12 EDI 

or EDI-based XML. Guidance for transaction content is provided in DLMS Supplements available at: 

www.dla.mil/j-6/dlmso/elibrary/transformats/140_997.asp.

C17.3.21.1.3.2. Until replaced by DLMS, the Army unique transactional 

interface with Army Electronic Product Support (AEPS) Web-Based Tool (WBT) shall be supported.

C17.3.21.1.3.3. No other transactional formats are authorized for SDRs.

C17.3.21.1.4. Convert SDRs for e-mail distribution where computer readable 

SDR transactions are not feasible due to lack of an established SDR application interface.

C17.3.21.1.4.1. Upon determination that an e-mail (vice transaction) is to 

be prepared for a specific SDR communication, DLA Transaction Services will check to determine if 

the appropriate e-mail certificate has been registered. If registered, the SDR e-mail transmission shall 

be encrypted as “FOUO” per paragraph C17.2.2. The e-mail SDR shall contain all associated SDR 

content as well as clear text addresses and code explanations to facilitate use interpretation. If not 

registered, an abridged content SDR report, distribution copy, or reply, as appropriate, will be 

prepared. The e-mail sent to the user will also provide information on how to get access to WebSDR 

and instructions on registering the e-mail certificate.

C17.3.21.1.4.1.1. Abridged SDR. The abridged unencrypted version of 

the SDR e-mail will include the following data content. Coded information will not include the 

corresponding clear-text explanation. The submitter and action activities will not be identified by 

clear-text addresses.

• DoD Web SDR Report Control Number

• Additional System SDR Control Number

• Customer-Assigned Control Number

• Document Number/Suffix

• Contract Number

• Transportation Control Number

• Date of Preparation

• SDR Document Type Code

• DLA Disposition Services SDR Type Code

• Discrepancy Code(s)

• SDR Action Code

 4 Refer to ADC 317.
ADC 452 Enclosure 4, Page 3

• SDR Submitter (Activity From)

• SDR Point of Contact

o Name

o Commercial Phone or DSN

o E-mail

• Attachment/Off-line Flag

C17.3.21.1.4.1.2. Abridged SDR Reply. The abridged unencrypted 

version of the ADR Reply e-mail will include the following data content. Coded information will not 

include the corresponding clear-text explanation with the exception of the Reply Disposition Code 

which must include text for understanding. The submitter and action activities will not be identified by 

clear-text addresses.

• DoD WebSDR Report Control Number

• Additional System SDR Control Number(s)

• Original Reference Number

• Document Number/Suffix

• Contract Number

• Transportation Control Number

• Reply Date

• SDR Document Type Code

• DLA Disposition Services SDR Type Code

• Reply Disposition Code(s)

• Action Activity (Activity From)

• SDR Submitter (Activity To)

• Comments/Remarks

• Reply POC

o Name

o Commercial Phone or DSN

o E-Mail

• Attachment/Off-line Flag

C17.3.21.1.4.1.3. Organizations that are not supported by an SDR

application for transactional reference shall provide to DLA Transaction Services an e-mail address to 

be linked with their DoDAAC/RIC for e-mail distribution.

C17.3.21.1.4.1.4. Each DoD Component shall designate to the DoD SDR 

System Administrator a specific e-mail account or point of contact to receive un-routable SDRs for 

manual attention. This is required to ensure operational support where no SDR application or e-mail 

address has been identifier for an SDR recipient, or an attempted e-mail distribution has failed due to 

an invalid address.

C17.3.21.1.5. Maintain historical records of SDRs and associated transactions.
ADC 452 Enclosure 4, Page 4

C17.3.21.1.6. Provide access to SDR information via Web Visual Logistics 

Information Processing System (WEBVLIPS). 

C17.3.21.1.7. Provide ad-hoc queries and management reports.

C17.3.21.1.8. Maintain the DoD WebSDR as a value-added service to support 

submission, reply, and other functions related to SDR processing.

C17.3.21.1.9. Convert CCP-generated SDRs for email distribution pending 

owner/manager ability to process electronically.

C17.3.21.1.10. Post for history, but not forward SDR replies to the SDR 

submitter (i.e., distribution depots or CCP) identifying passive RFID or WPM discrepancies based 

upon addressing to the DAAS/WebSDR routing identifier (SGA). This will suppress unnecessary 

transmission of SDR transactions where the SDR submitter has closed the SDR with no 

expectation/requirement for a reply under these conditions.

C17.3.21.2. DAAS/WebSDR 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.21.2.1. SDR transactions must contain valid values as appropriate to the 

transaction purpose: discrepancy code, action code, and disposition/status code. Reject with 

Disposition/Status Code (Reply) 915, 916, or 927. 

C17.3.21.2.2. SDR must include materiel identification. Materiel identification may 

consist of the NSN, manufacturer’s part number and manufacturer’s CAGE, or as authorized under 

DLMS for unique business processes (e.g. “mixed” or “unknown” for transshipper SDRs and local 

catalog identification number5

). Where wrong item discrepancies are reported, materiel identification 

of the wrong item must be included. Wrong item received may be identified as previously indicated or 

by description alone (citing “UNKNOWN” as the wrong item part number). Reject with 

Disposition/Status (Reply) Code 931.

C17.3.21.2.3. SDRs reporting materiel received is not in the correct condition must 

include valid condition codes to identify the received conditions. Only valid condition codes shall be 

permitted. The condition code must be appropriate for the discrepant materiel and associated action 

activity or source of supply (i.e., Supply Condition Code N, V, and T may not be directed to the DLA 

ICP). Reject with Disposition/Status (Reply) Code 928. 

C17.3.21.2.4. SDRs coded to indicate narrative is required must provide applicable 

narrative. Reject with Disposition/Status (Reply) Code 924. 

C17.3.21.2.5. SDRs must include minimal point-of-contact information to include 

name and phone/email. Reject with Disposition/Status (Reply) Code 920 or 921.

C17.3.21.2.6. Only valid DoDAACs and Routing Identifiers will be permitted. 

Reject with Disposition/Status (Reply) Code 929.

 5 Refer to ADCs 282, 317, and 322. Local Catalog ID implementation pending.
ADC 452 Enclosure 4, Page 5

C17.3.21.2.7. Quantity fields will only allow entry of numeric values. Reject with 

Disposition/Status (Reply) Code 917 or 918.

C17.3.21.2.8. SDR replies coded to indicate that a ship-to/mail-to address or 

additional information is associated with the reply, must include the specified additional address or 

information as transaction data fields or and must include narrative remarks to reflect the address (due 

to limited implementation of the separate address fields). Reject with Disposition/Status (Reply) 

Code 924.

C17.3.21.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 calendar days will apply). Reject with Discrepancy Status/Disposition Code 933

(implementation pending). 

C17.3.21.2.10. SDR follow-ups and contested SDR/reconsideration requests shall

not be submitted against cancelled SDRs. Reject with Discrepancy Status/Disposition Code 907.

C17.3.21.2.11. Reply with Discrepancy Status/Disposition 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 Discrepancy Disposition/Status (Reply) Code 935. 

C17.3.21.2.12. SDR document numbers and associated suffix codes must conform 

to MILSTRIP standards. A temporary exception is allowed for Air Force maintenance document 

numbers used between the Air Force item manager and the supporting depot. The full document 

number edit does not apply to transshipper SDRs (Document Type W) due to the potential for 

reporting against the shipment unit rather than a specific document number. For these SDRs, the 

document number must be filled and must be 14 positions. It may contain a 14 position purchase 

request number, the first 14 positions of the transportation control number, or a constructed 

document number based upon the DoDAAC of the port submitting the SDR. Reject with 

Discrepancy Status/Disposition Code 910.

C17.3.21.2.13. SDRs must contain valid transaction set purpose codes and 

document type codes as shown in the applicable DLMS Supplement. Reject with Discrepancy 

Disposition/Status (Reply) Code 938 and 939, respectively. Submitting system personnel will be 

notified of invalid transaction set purpose codes.

C17.3.21.2.14. SDRs associated with new procurement (Document Type 9 or P) 

must contain the applicable contract number and contractor-assigned shipment number. Reject 

with Discrepancy Disposition/Status (Reply) Code 940.

C17.3.21.2.15. Inter-Component SDR replies citing 200-series reply codes may only 

be used for Security Assistance SDRs. Reject with Discrepancy Disposition/Status (Reply) Code 

941.

C17.3.21.2.16. Duplicate SDRs defined as a new submission matching an existing 

SDR on document number/suffix, discrepancy code, and transportation control number (if 

provided). Reject with Discrepancy Disposition/Status (Reply) Code 719. Note: DoD Components 

may use this code based internal business rules.
ADC 452 Enclosure 4, Page 6

C17.3.21.3. DAAS/WebSDR will edit SDR submissions via DoD WebSDR at the point of 

entry to improve the accuracy of the data content. All of the above criteria apply. In addition, webspecific functionality includes:

C17.3.21.3.1. The SDR submission process will be facilitated by the auto-population 

of data content based upon the shipment and cataloging data available to DAAS.

C17.3.21.3.2. Address information will be retrieved based upon DoDAAC and 

routing identifiers. User generated updates to initiator’s address are permitted and will be passed to the 

receiving system for information, but will not impact SDR processing.

C17.3.21.3.3. SDR replies coded to indicate that an address or additional information 

is associated with the reply, must include the specified additional address or information. 

C17.3.21.4. DAAS shall provide the support to SDR transaction exchange to facilitate 

DLMS processes.

C17.3.21.4.1. DAAS/WebSDR shall facilitate appropriate distribution when the 

action party receiving the initial distribution employs the Distribution/Status (Reply) Code 504 

indicating the SDR must be forwarded to a new action activity. When the new action activity is a 

distribution depot, the original SDR will be retransmitted to the designated depot. The customer will 

receive notification of interim status.

C17.3.21.4.2.. DAAS/WebSDR shall facilitate appropriate distribution when the 

action party receiving the initial distribution employs distribution status codes in the 300 series 

indicating that the SDR must be sent to the SOS for disposition. The SDR reply will be sent to the 

designated SOS and to the SDR initiator for notification of interim status.

C17.3.21.4.3. DAAS/WebSDR will respond to DAAS-directed rejected reply 

transactions indicating no matching original report or information copy of the SDR is found in the 

automated application (Reply Code 926), by providing an information copy of the original report to the 

activity which rejected the reply. Unmatched requests for an information copy will be returned by 

DAAS reject (Reply Code 926) to the sending organization. DAAS will create and forward an 

information copy of the DLA SOS for all customer SDRs based upon the storage site reply where an 

information copy was not previously provided.

C17.3.21.4.4. DAAS/WebSDR shall provide information copies of SDRs in 

accordance with Component business rules and as designated by the initiator.

C17.3.21.4.4.1. DAAS/WebSDR shall ensure DLA Enterprise Business System 

(EBS) receives an information copy of all SDRs routed to a distribution depot for initial action where 

EBS is the SOS.

C17.3.21.4.4.2. All parties receiving an information copy of the original SDR as

designated by the initiator or by a Component business rule will receive a copy of all changes, 

cancellation, and replies associated with the SDR.

C17.3.21.4.5. DAAS/WebSDR shall accept and forward supporting 

documentation associated with SDRs using DLMS attachment exchange procedures6

.

 6 Refer to ADC 311. Implementation pending.
ADC 452 Enclosure 4, Page 7

C17.3.21.5.1 SDR attachments may be uploaded directly to the DoD

WebSDR or exchanged electronically in association with the SDR transaction.

C17.3.21.5.2 SDR attachments must be referenced/uploaded under an 

SDR Attachment File Name constructed in accordance with DLMS rules. Up to 5 attachments may be 

associated with a new SDR report and subsequent change, reply, request for reconsideration. 

Attachments may be submitted with follow-up and cancellation transactions for archive, but these will 

not be forwarded to the action activity.

C17.3.21.6. DoD WebSDR shall restrict the use of inappropriate discrepancy 

status/disposition reply codes in responses to transshipper prepared SDRs.
ADC 452 Enclosure 5, Page 1

Enclosure 5, Comment Resolution

Originator Concurrence/Comment Response

1. DLA DLA concurs with comment:

1. Could we add an edit for the 200 series 

disposition codes? If there was an edit to 

check for a P, K, D, T, B (and future I) in 

the first position of the document on SDRs 

containing a 200 disposition code it would 

prevent failures. These failures leave an 

SDR open in EBS and I'm not sure if the 

Navy is good with the 206 disposition 

code. I found one that was over $6,000. I 

don't think that should be an administrative 

write off.

2. EBS requests expedited implementation 

of these changes. EBS system 

enhancements go into production 

November 13, 2011 that will create 

workflow for SDRs related to this change. 

Until WebSDR edits go into production we 

are going to have a lot of manual work on 

invalid SDRs.

Consolidated OF/TQ response from DSCC 

(Land and MRTM):

3. A format for the emails should be 

included in the ADC, to make sure the 

correct fields are provided. This will also 

allow the Components to know what 

information to expect from the WebSDR 

support team regarding the SDR error. 

Requesting draft before ADC is sent out. 

Also, a format for the emails should be 

included in the ADC, to make sure the 

correct fields are provided. This will also 

allow the Components to know what 

information to expect from the WebSDR 

support team regarding the SDR error.

4. Paragraph 5. a. (1) (a) SDR Follow-up 

or Contested SDR/Reconsideration Request 

Noted:

1. Concur. ADC updated for new Reply Code 

401. 

2. This will be a priority change to expedite 

implementation.

3. Additional information is provided about 

how this process works. Under the ADC 

version there will either be a standard SDR 

transaction/email for the rejection or a simple 

email identifying control numbers to the 

system personnel. A sample SDR email is

shown at Enclosure 3. 

4. If the follow-up or reconsideration request 

is rejected because the SDR was already 

cancelled, but the customer realizes that the 

cancellation was wrong and wants to pursue 

the SDR, they will need to resubmit the SDR. 

It should end up with the same WebSDR

Control Number to tie together with the 

history. EBS could re-open the SDR or create 

a new SDR record. I definitely don’t want to 

make this into a huge programming change for 

all the systems by creating a new style of 

transaction. That would take years for EBS to 

implement and we want this to go into effect 

immediately. 

If a change transaction is used after a 

cancellation without any special coding, we 

could do that procedurally, but the result 

wouldn’t be good for web-users where all the 

change information goes into the remarks 

(since there are no data fields on the Web 

screens). I think it makes more sense to resubmit as 00 after a cancellation, rather than 

use a change transaction. If WebSDR uses a 

new control number after a cancellation, the 

history will not be easily associated with the 

new SDR. 
ADC 452 Enclosure 5, Page 2

after SDR is cancelled. EBS non-concurs 

with this process. There is no current 

functionality that would allow for this in 

EBS. Transaction Set Purpose Code '00' is 

strictly reserved for a "True" original SDR 

submission. Either a new WebSDR control 

number suffix, Transaction Purpose Set 

Code, or modified correction ‘CO’ logic,

should be established for 

resubmission/reopen discrepancies. 

Recommend a meeting to discuss.

5. Would this also apply to ILCO rejects? 

6. Paragraph 5. a. (1) (b) Document 

Number or Document Number/Suffix 

Combination. The last sentence describes 

the use of a 13 digit Transportation control 

number as the Document number. 

7. The draft ADC doesn't clearly define 

what "another relevant number" is. Clarify 

exactly what data would be sent or 

emphasize that the requirement shouldn't 

be ambiguous.

8. Paragraph 5. a. (1) (m) Submitter (From 

Address). There may be a typo: 

"...Research and resubmit with a valid 

authorized by..." 

9. Paragraph 5. a. (1) (n) Owner/Manager/

Source of Supply. Clarify that 

owner/manager cannot be blank. If 

missing, owner/manager does not receive 

an information copy and no action is ever 

taken on disposition given by the depot 

because 'SMS' has no visibility of SDR.

10. Yes, there should be DoDAAC/RIC 

validation for the shipping activity and the 

distribution copy recipient activity.

11. Paragraph 5. a. (1) (p) Duplicate SDR. 

EBS does not use the same logic from this 

section to determine a Duplicate SDR 

submission. For Depot SDRs (type 5,8,9,R 

and W) EBS uses the ADRS and RIC 

combination. For customer SDRs EBS 

Are there any other options that will work for 

EBS?

DLA Response: EBS could establish “02” set 

code (or another currently unused code) with 

the sole purpose of reversing cancellations. 

This would keep the same WebSDR Control 

Number and the same EBS Control Number 

(a.k.a. QN Number) This programming would 

take less time to test than building logic to 

distinguish between original SDR submissions 

and cancellation reversals.

SDR Administrator Response: New 

Discrepancy Code Z5 added for systemic 

recognition of the resubmitted SDR for valid 

processing.

5. There will be no changes to the ILCO 

reject process.

6. Intent was for the port to use the first 14 

positions of the TCN (if that is all they have)

to populate the document number field on the 

SDR. Fixed.

7. Revised to reference a PR number.

8. Fixed.

9. This is not necessary, DSS already

populates this field if left blank. That is one of 

the reasons why we want to remove invalid 

data; for type 7, DSS will see that it is not 

filled and put the correct value in the 

transaction. EBS will then get the info copy 

based upon the DSS reply, followed by the 

actual reply transaction.

My preference is to leave this to DSS for 

customer SDRs so that we will get valid 

information. Other types of SDRs aren’t really 

a problem.

10. Concur.

11. This change will tighten up the rule a 

little for WebSDR, but does not require 

changes to internal Component rules. The 

standardization of rule across Component 

applications has been discussed by the SDR 
ADC 452 Enclosure 5, Page 3

looks at the WebSDR Control number to 

determine if the SDR is a duplicate. A 

system change would be needed for EBS to 

implement new duplicate check job.

11. Paragraph 5. a. (2) (b) SDR Document 

Type Code. Currently in production EBS 

receives SDR with invalid SDR types (i.e. 

'7P'), does this section address that issue?

12. Paragraph 5. a. (2) (c) Missing 

Contract Number/Shipment Number. 

SDRs with pRFID issues require the 

PIIN/CALL/CLIN. This information is 

required to generate notification to a 

contractor when he is found noncompliant.

Does contractor-assigned shipment 

number" mean TCN? 

13. Type 6 Reply. Change word "must" to 

“may be” inserted by the action activity. 

14. PDC Enclosure 3, Page 1 Add 'Paul 

Selm' to the EBS list as a backup, he can 

assist with EBS SDR support if Jesse is not 

available.

15. The WebSDR team needs to know 

when transactions are erroneously routed to

DSS because of a RIC that is not 

considered a DLA DD. But, we need to 

know via email and not via an automatic 

reject transaction. The "invalid RIC"

situation must be handled manually and, 

therefore, not able to be resolved with an 

automatic reject. We will check further 

into this one to see if routing logic needs to 

be changed within WebSDR.

Subcommittee and will continue to be a topic 

for resolution.

11. Only valid type codes will be allowed. 

We are not editing for appropriate usage based 

upon who the submitter DoDAAC.

12. The reference to a contractor shipment 

number refers to the shipment number 

formatted as three alpha and four numeric 

characters. 

13. Revised wording to say that the contract 

number must be provided. The shipment 

number may be provided if known. The ICP 

must be able to match the document number to 

the direct vendor delivery contract for 

financial processing. If more than one 

shipment number applies, the ICP may not 

know which was discrepant.

14. Added. The specific names will not be 

retained as part of the ADC, but will be 

provided to DLA Transaction Services.

15. We will add the edit to block type 6 SDRs

addressed to a depot. If an SDR is rejected for 

this reason, the info copy will not be sent to 

DLA EBS. A separate email will not be 

needed. 

2. Marine Corps This Headquarters has reviewed the subject 

PDC and concurs with no comments.

Noted.

3. Army HQDA DCS G-4 Concurs with comments 

as stated below:

COMMENT: Clarifying changes are 

suggested on PDC 478 Implementation of 

DoD WebSDR Automated SDR Rejection 

Capability.docx in red and the final one in 

blue to take into consideration for HQ JMC 

'B14' SDRs. Please see attachments.

Noted.
ADC 452 Enclosure 5, Page 4

COMMENT: Reference PDC 478, 

Enclosure 4, page 3, paragraph, 

C17.3.21.1.5, Kim.Paumer, is designated to 

receive un-routable SDRs for manual 

attention, when submitter POC information 

is not reflected, but initiating agency 

(USASAC) is reflected.

4. Navy The Navy concurs with PDC478 as written 

and submits no additional changes or 

amendments.

Noted.

5. Air Force AF concur with comment

1. This PDC could potentially be easily 

implemented in ES-S. Implementation of 

this change would require a ES-S table 

update. 

2. Please provide Web SDR 

implementation date for this PDC. 

3. PDC 478, will impact ECSS in that 

ECSS will need to be programmed to 

accept and respond appropriately to 

(exception out) the new reject codes 

received through DLMS transactions. In 

addition, ECSS will need to be able to reestablish a cancelled SDR using the same 

document number as referenced in 

paragraph 5.a.(1)(a). 

ECSS is unable to provide an estimated 

implementation date due to the lack of 

execution progress on ECSS Pilot C as we 

continue to experience schedule setbacks. 

Execution performance metrics, monitored 

and reviewed by Air Force senior leaders 

on a weekly basis, now reflect a four-to-six 

month delay to ECSS Pilot C completion 

and go-live. The Air Force is considering 

other options to the program for approval 

by the OSD Milestone Decision Authority. 

Until a final decision is made, an 

implementation date cannot be provided.

Noted.

1. ES-S already accepts reply transactions for 

SDRs initiated in ES-S. The automated 

rejection notices will use the same format.

2. This is a priority change and will be 

implemented early in 2012. Components will 

be notified.

3. Concur. Noted.

6. DLA 

Transaction 

Services

Clarification of email generation for failed 

SDRs:

If the transaction is grossly malformed, it 

will reject at the GEX level. When that 

Information used to update the ADC.
ADC 452 Enclosure 5, Page 5

happens, the EDI Group sends an email to 

the POC defined in the SAR for that 

interface. The DLA Transaction Services 

WebSDR team never sees these 

transactions (occasionally cc'd on an 

email).

If the transaction passes GEX edits and 

fails in the SDR Translator, they fall out to 

a reject directory for manual 

review/resolution. That happens rarely and 

requires manual review to determine the 

error. We did not envision these rejects 

being handled by the auto-reject 

processing.

Samples of WebSDR Team generated 

email provided.

7. USTRANSCOM Abstain. Noted.