2

ADC 311 

SDR Attachment Interface 

1. ORIGINATING SERVICE/AGENCY AND POC INFORMATION:

a. System POC for The DoD WebSDR J6D-DAASC Recommendations: Department of 

Defense (DoD) Defense Automatic Addressing System Center (DAASC), 937-656-3783 

b. Functional POC for The DoD WebSDR Recommendations: Defense Logistics 

Management Standards Office (DLMSO), Ms. Ellen Hilert, Chair, Supply Process Review 

Committee and DoD SDR System Administrator, 703-767-0676; DSN 427-0676; or, E-Mail: 

Ellen.Hilert@dla.mil. 

c. Technical POC for The DoD WebSDR Attachments: 937-431-8000 

2. FUNCTIONAL AREA: Supply/The DoD WebSDR 

3. BACKGROUND:

a. The change standardizes the attachment process for all Service/Agencies interfacing with 

the DoD WebSDR. Currently the DoD WebSDR System interfaces cannot transmit or receive 

SDR attachments via the GEX or MQ Series SDR interface connections. This change allows the 

Services and Agencies interfacing with the DoD WebSDR to transmit and receive attachments 

via a standard process. 

b. The DoD WebSDR has an attachment option on-line via the web application. Web users 

have the option to upload supporting images/files, such as pictures, shipping documents, PDF 

files, etc., from their computer. 

c. The Air Force Security Assistance Center (AFSAC) is the only interface that includes 

attachments. The AFSAC format doesn't identify a file name; there is a HL loop reference that 

lets you know there is an attachment associated with the transaction. When the attachment is 

received at DAASC through the AFSAC attachment connection, it is put in the DoD WebSDR 

database. 

d. With the exception of AFSAC described above, the Services and Agencies interfacing via 

machine to machine do not have the option to transmit and receive attachments via their 

connections. 

4. APPROVED CHANGE: This change identifies revisions to the DLMS Supplements (DSs) 

for SDRs to include attachment standard file name(s). Enclosures below identify the DLMS 

Supplement revisions, update to published guidance, attachment flow, and provide example 

transactions. The use of the standard file name applies to both web-uploaded attachments and to 

electronic exchange. The structure of the standard file name will be included in the DLMS 

dictionary definition. 
3

5. REASON FOR CHANGE: 

a. To standardize attachments in the DoD WebSDR for all Services and Agencies using the 

DLMS. 

b. To allow attachment interoperability between the Services and Agencies. 

c. Capability to send/upload attachments for follow-up and cancellation is allowed due to 

FMS requirements to maintain supporting documentation at DAAS. However, since there is no 

need for the action activity to maintain these attachments, DAAS will not forward them. 

6. ADVANTAGES AND DISADVANTAGES:

a. Advantages:

(1) Attachments received by the DoD WebSDR interfaces connected to specific SDRs 

will be viewable for customers using the DoD WebSDR application. 

(2) Attachments connected to specific SDRs will be available for SDRs being 

transmitted into the DoD WebSDR via the MQ Series/GEX connections. 

b. Disadvantages: None identified. 

7. ASSUMPTIONS USED OR WILL BE USED IN THE CHANGE OR NEW 

DEVELOPMENT: 

a. Foreign Military Sales (FMS) customers are only allowed to view the attachment that 

belongs to their own country’s SDR. FMS customers connect via AFSAC on-line and do not use 

the DoD WebSDR application. FMS data is populated into the DoD WebSDR database from the 

AFSAC on-line SDR interface with DAASC. The attachment restriction lies within the 

Service/Agency system. 

b. Attachment business rules will apply to all system interfaces. 

8. DETAILED FUNCTIONAL REQUIREMENTS

a. Standard attachment rules for transmitting attachments via machine to machine using the 

DoD WebSDR/DAASC interface follow. Yellow highlights identify significant revisions 

subsequent to PDC staffing. Refer to Enclosure 3 for examples. 

(1) File Formats. Permitted file formats that can be used in the DoD WebSDR for 

uploading supporting files: BMP, DOC, GIF, JPG, JPEG, PDF, TXT, DOCX, XLS, and XLSX. 

(2) File Size. Maximum file size limit for uploading supporting documentation: 5 MB 

(total for all attachments associated with the transaction). 

(3) Number of Attachments. The breakdown by transaction and number of 

attachments allowed will be: 
4

(a) New reports/forwarded reports (BNR01=00, 22, 49) : maximum of 5 

attachments 

(b) Reply (including historical) (BNR01=11, SU, CN, 49) : maximum of 5 

attachments 

(c) Correction: maximum of 5 attachments. 

(d) Follow-up (BNR01=45): maximum of 5 attachments may be 

sent/uploaded to WebSDR, but will not be forwarded to the action activity. (This will satisfy 

Security Assistance requirements for records retention which is accommodated by DAAS; no 

DoD requirement for sending new attachments with a follow-up.) 

(e) Cancellation (BNR01=CO): maximum of 5 additional attachments may 

be sent/uploaded to WebSDR, but will not be forwarded to the action activity. (This will satisfy 

Security Assistance requirements for records retention which is accommodated by DAAS; no 

DoD requirement for sending new attachments with a follow-up.) 

(f) Request for reconsideration (including FMS 2nd request) (BNR01=15, 

50): maximum of 5 attachments. 

(g) No attachments are associated with ILCO reply rejects (BNR01=44) to 

action activity 

(4) Attachment File Name Format. Refer to the Enclosure 1, DLMS Dictionary, 

for the file name structure and code list for SDR Attachment Originating System Code 

The file name must use prescribed structure and will be machine generated based upon the 

date/time stamp, information inherent to the SDR transaction, and an optional text area for the 

user to include meaningful name information. The file name may be a maximum of 50 

characters (including the file extension). The individual elements of the file name are used to 

ensure that the attachment file, stored in a separate table in DAAS, is both uniquely identified, 

and identifiable to the specific SDR transaction with which it was originated. The user identified 

text name at the beginning of the file name and the hyphens are included to facilitate recognition 

by users of specific attachments when working from a list of available attachments. One element 

of the file name structure is a new code to identify submitting system (multiple systems may 

prepare the same type of transaction for the same document number). For ease of human 

interpretation, the applicable Service/Agency code is used as the basis for the new code value. 

Codes are established for legacy and modernization system and potential future interfaces with 

WebSDR. Additional values will be added as needed. 

(5) Transmission To/From the DoD WebSDR

(a) Unique accounts/methods from 842 data. 

(b) If MQ Series, use separate queue 

(c) If SFTP, different drop off / pick up points 
5

(6) Transaction/Attachment Linking. It is the responsibility of the receiving 

system(s) to determine how the 842 transaction and associated attachments are "linked" within 

their own systems. 

9. IMPACT

a. Impact will vary because capability to send and receive attachments electronically is 

optional. However, it is mandatory that DLMS trading partners support capability to recognize 

attachment flags (so that internal users will be aware that attachments are available. 

b. All Service/Agency Interface Agreement parties will need to coordinate on testing 

attachments. All Service/Agencies interfacing with the DoD WebSDR will need to develop a 

test plan and schedule test scenarios to accommodate DAASC and the various Service/Agencies 

interfacing with the DoD WebSDR. 

c. Implementation. Phased Implementation will be used to transition AFSAC to new 

naming convention. 
1

Enclosure 1, DLMS Manual 

C17.2. POLICY 

 C17.2.1. Use of SDR. The DoD Components shall use the SDR to report 

shipping or packaging discrepancies attributable to the responsibility of the shipper (including 

contractors/manufacturers or vendors) and to provide appropriate responses. The purposes of 

this exchange are to determine cause of such discrepancies, effect corrective action, and prevent 

recurrence. 

 C17.2.2. Electronic Communication. Components are encouraged required to 

maximize the use of electronic reporting and response with the goal of paperless processing of 

supply discrepancies. Until electronic reporting under DLMS is universally available, SDRs and 

associated responses may be reported via hard-copy SF 364, ROD; by electronic means, to 

include automated discrepancy reporting systems and electronic data interchange; customer 

service help lines (e.g. the DLA Customer Interaction Center, dlacontactcenter@dla.mil) 1-

877-352-2255 (1-877-DLA-CALL); email; or any other manner acceptable to the submitter and 

recipient. All manner of reporting must meet the criteria described in this publication. 

Electronic SDRs shall be submitted in accordance with Component-specific guidance via 

appropriate automated systems or via the internet-based DoD WebSDR. Access to DoD 

WebSDR must be requested from the DAAS home page at: https://www.daas.dla.mil/ 

daashome/. While exceptions may be permitted, the DoD goal is that paper submission of SDRs 

and non-standard communication of SDRs will be phased out once full implementation of 

transaction exchange under DLMS has been achieved. 

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

C17.3.21. DAAS SDR Processing

(Intervening text not shown: renumber paragraphs as indicated)

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

facilitate DLMS processes. 

 C17.3.21.4.1 DAAS 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 DD, the original SDR will be retransmitted to the designated DD. The customer will receive 

notification of interim status. 

 C17.3.21.4.2 DAAS 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. 
2

 C17.3.21.4.3 DAAS 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 (ADC 225). DAAS 

will create and forward an information copy of the DLA source of supply for all customer SDRs 

based upon the storage site reply where an information copy was not previously provided (ADC 

225A). 

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

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

 C17.3.21.4.5. DLA Enterprise Business System (EBS) will receive an 

information copy of all SDRs routed to DD for initial action where EBS is the SOS. 

 C17.3.21.4.6. 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.7. DAAS shall accept and forward supporting 

documentation associated with SDRs using DLMS attachment exchange procedures.

 C17.3.21.4.7.1 SDR attachments may be uploaded directly to the 

DoD WebSDR or exchanged electronically in association with the SDR transaction. 

 C17.3.21.4.7.2 SDR attachments must be referenced/uploaded 

under a 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. 
1

Enclosure 2, DLMS Dictionary 

Update the DLMS Dictionary with the following information: 

SDR Attachment File Name 

Alphanumeric with special characters - Maximum Length 50 

Definition: The file name assigned to attachments for supplemental documentation supporting 

SDR information exchange under the DLMS. Hyphens separate individual components of the 

file name for ease of interpretation. The SDR Attachment File Name must be constructed as 

TTTTTTTTTT-DDDDDDDDDDDDDDX-BB-OS-CCYYJJJHHMMS.EXTN 

defined as follows:

TTTTTTTTTT = Text - Optional user-provided name (up to 10 characters), e.g. “SF364” or 

“DD1348” or “WRONG_ITEM” This portion of the file name may be derived from the 

user’s original saved file. The remainder of the file name is system generated by the SDR 

application based upon content of the SDR transaction and internal date/time of transaction 

processing. The generating application must ensure unique values result from file name 

construction. 

D = Document Number (14 position alphanumeric characters) 

X = Document Suffix (1 position alphanumeric character, if blank then use "_" character) 

- (hyphen separating descriptive text name (when used) from next piece of information) 

BB = Beginning Segment value (00, 01, 15, 22, 46, 49, 50, CO, 11, CN, SU, or XX (XX 

indicates SDR-A attachment submitted independent from a DLMS transaction, per ILOC 

requirement.) 

- (hyphen separating document number/suffix from next piece of information) 

OS = SDR Attachment Originating System Code (see list) 

- (hyphen separating originating system from next piece of information) 

CC = Century (2 position numeric characters) 

YY = Year (2 position numeric characters) 

JJJ = Julian Day (3 position numeric characters) 

HH = Hours (2 digit numeric characters) 

MM = Minutes (2 digit numeric characters) 

S = Serial Number (1 digit numeric character). Assigned sequentially; used to ensure unique 

construct. Start with “1.” 

SDR Attachment Originating System Code 

Alphanumeric with special characters - Maximum Length 2 

Definition: Code used in the generation of the SDR attachment file name to identify the system 

which originated the SDR transaction containing the attachment. The following code values are 

available for current or future use: 

00 = DoD WebSDR (direct web upload)

S1 = DLA DSS ADRS 

S2 = DLA DSS ISDRS

S3 = DLA EBS 

W1 = USA LMP
2

W2 = USA GCSS-A 

W3 = USA AEPS 

N1 = USN NSDRS

N2 = USN PDREP 

N3= USN ERP

F1 = USAF ES-S 

F2 = USAF D035K

F3 = USAF ECSS

D1 = ILCO SDR-A (AF Security Assistance)

Z1 = USCG

M1 = USMC

S4 = DoD EMALL 

G1 = GSA 
1

Enclosure 3, DLMS Supplement Revisions 

Item Location Revision to 4030 842A/W Reason 

1. DLMS 

Introductory 

Notes 

Add ADC 311 to DLMS introductory note 5:

- ADC 311, SDR Attachment Interface

To identify 

DLMS changes 

included in 

supplement. 

2 2/PWK/1020 Add new segment level note:

DLMS Note: 

Use a separate PWK segment for each attachment identified by 

filename. Repeat up to five times. 

Clarification of 

usage. 

3 2/PWK01/1020 Add new DLMS Note to existing Code AE

Report Type Code 

 AE Attachment 

DLMS Note: 

1. Use to indicate that supporting documentation has been 

provided electronically in the form of images or files and is 

available for download from the DoD WebSDR. 

2. Use with Code FT (PWK02) when a file is transmitted 

electronically between the DoD WebSDR and the interfacing 

application. 

 R6 Miscellaneous Information 

DLMS Note: 

Use to indicate that additional information is being submitted to 

the action activity off-line. 

Clarification of 

usage. 

4 2/PWK02/1020 Open Report Transmission Code and Add Code FT: 

Report Transmission Code 

 FT File Transfer 

DLMS Note: 

1. Use to indicate attachment is being sent electronically in a 

separate transmission.

2. Up to five attachments may be sent per transaction. 

3. Information copies generated by WebSDR/DAAS (BNR01=22) 

will carry the attachments associated with the original report.

Signifies that the 

attachment 

referred to will be 

sent electronically 

in a separate 

transmission. 

5. 2/PWK07/1020 Add Description Element: 

Description 

DLMS Note: 

1. Use to indicate the SDR Attachment File Name being sent 

electronically in a separate transmission. Refer to ADC 311.

2. WebSDR field length = 50. 

Identifies the 

name of the 

attachment file 

being sent 

electronically in a 

separate 

transmission. 
2

Item Location Revision to 4030 842A/R Reason 

1. DLMS 

Introductory 

Notes 

Add ADC 311 to DLMS introductory note 5:

- ADC 311, SDR Attachment Interface

To identify DLMS 

changes included in 

supplement. 

2. 2/PWK/1020 Mark PWK segment as used The PWK segment 

occurs in two 

locations in the 

X12 standard. 

Prior to Component 

implementation the 

DLMS Supplement 

for the SDR reply 

will be made 

consistent with the 

SDR report and 

DAAS mapping by 

using the PWK at 

position 1020 vice 

position 3800. 

3. 2/PWK01/1020 Mark data element as used and add the following notes:

Federal note: Use any code. 

DLMS note: For DLMS use only the following codes are 

authorized.

Clarification of 

usage.

4. 2/PWK01/1020 Add the following qualifiers and DLMS notes

Report Type Code 

 AE Attachment 

DLMS Note: 

1. Use to indicate that supporting documentation has been 

provided electronically in the form of images or files and is 

available for download from the DoD WebSDR. 

2. Use with Code FT (PWK02) when file is transmitted 

electronically between The DoD WebSDR and the interfacing 

application. 

 R6 Miscellaneous Information 

DLMS Note: 

Use to indicate that additional information is being submitted 

to the action activity off-line. 

Clarification of 

usage. 

5. 2/PWK02/1020 Mark data element as used and add code FT: 

FT File Transfer 

DLMS Note: 

1. Use to indicate attachment is being sent electronically in a 

separate transmission.

2. Up to five attachments may be provided with the reply 

transaction.

Signifies that the 

attachment 

referred to will be 

sent electronically 

in a separate 

transmission. 

6. 2/PWK07/1020 Add Description element: 

Description 

Identifies the 

name of the 
3

DLMS Note: 

1. Use to indicate the SDR Attachment File Name being sent 

electronically in a separate transmission. Refer to ADC 311.

2. WebSDR field length = 50. 

attachment file 

being sent 

electronically in a 

separate 

transmission. 

7. 2/PWK/3800 Mark PWK segment not used at position 3800 Administrative 

update reflects 

relocation of the 

PWK segment 

from 3800 to 

1020 for 

consistency 

8. 2/PWK01/3800 Mark date element not used and remove the following codes and 

DLMS notes:

AE Attachment 

DLMS Note: Use to indicate that documentation has been 

provided electronically in the form of images or files and is 

available for download from the DOD WebSDR. 

R6 Miscellaneous Information 

DLMS Note: Use to indicate that additional information is being 

provided to the SDR action activity off-line. 

Administrative 

update reflects 

relocation of the 

PWK segment 

from 3800 to 

1020 for 

consistency 
1

Enclosure 4, Flow Diagram

Enclosure 4, Attachment Flow Diagram 
2

Enclosure 5, Example Transaction 

ISA*00*NONE *00*NONE *10*S36TST *10*SL4BSM 

*080417*1231*/*00403*000000372*0*T*/ 

GS*NC*S36TST*SL4BSM*20080417*12311263*110*X*004030 

ST*842*000000001*004030F842A0WA00 

BNR*00*Z*20080409*0000**C1 

N1*41**10*V09167**FR 

PER*PU*JOE SMITH*TE*910-999-9999*EM*joe.smilt@usmc.mil 

N1*ZD**10*SW3113**TO 

HL*1**RP 

LIN**FS*6220011298386*ZB*78286*MG*65912-01801-102*CN*PANEL, INDICATING 

DTM*947*20080409 

DTM*003*20080409 

REF*TN*V091678078GN09 

REF*NN*V09167080004*NSDRS 

REF*87*S*NSDRS 

REF*TG*V091678078GN09*NSDRS 

PWK*AE*FT*****WRONG_ITEM-V091678078GN09_-00-N1-200810812311.JPG <= * Approved change*

PWK*AE*FT*****ORDER-V091678078GN09_-00-N1-200810812312.TXT <= * Approved change*

PWK*AE*FT*****DD1349-1A-V091678078GN09_-00-N1-200810812323.PDF <= * Approved change*

LM*DF 

LQ*D*7 

LQ*HB*1A 

NCD**5*1 

NTE*RPT*REQUISITION ITEM FOR A CONTROL STICK..1680-01-129-8385... SQUADRON DISCOVERED 

NTE*RPT*THAT ITEM WAS A CONTROL PANEL UPON OPENING SEALED VENDOR&APOS;S PACK 

NTE*RPT*. REQUEST DISPOSITION AND CREDIT. 

REF*XA*1680011298385 

QTY*75*1*EA 

QTY*86*1*EA 

QTY*39*0 

QTY*87*1 

AMT*10*59 

AMT*Z3*59 

N1*LW*MALS 26*10*V09167 

PER*PU*MARY SMITH*TE*910-449-0000*EM*mary.smith@usmc.mil 

N1*SUS**M4*SMS 

LM*DF 

LQ*HA*W1 

LQ*HA*W6 

SE*39*000000001 

GE*1*110 

IEA*1*000000372 
Enclosure 6, Comment Resolution 

 Submitter Comment Status 1 DFAS 1. Editorial comments provided. 

2. Recommend completely revising the following for clarity and to eliminate redundant 'paper' references, and to bullet the different methods: C17.2.2. Electronic Communication. Components are required to maximize the use of electronic reporting and response. All manner of reporting must meet the criteria described in this publication. SDRs shall be submitted in accordance with Componentspecific guidance via approved automated systems, or via the internet-based DoD WebSDR available on the DAAS home page at: https://www.daas.dla.mil/daashome. SDRs and associated responses may be reported via: 

 electronic means, to include automated discrepancy reporting 

systems and electronic data interchange; 

 customer service help lines (e.g. the DLA Customer Interaction Center, 

dlacontactcenter@dla.mil) 1-877-352-2255 (1-877-DLA-CALL); 

 email; or  any other manner acceptable to the submitter and recipient. 

NOTE: Until electronic reporting under DLMS is universally available, an exception is permitted to allow submitters to use a hard-copy SF 364, ROD. The DoD goal is that paper submission of SDRs will be phased out once full implementation of transaction exchange under DLMS has been achieved. 3. Revised all but the last sentence, which is a bit confusing: 

C17.3.21.4.3 When DAAS receives an SDR-receiver rejected transaction (Reply Code 

926), they respond indicating that (1) no matching original report or information copy of 

the SDR was found in the automated application using Reply Code 926 or, (2) by providing an information copy of the original report to the activity that created the reject. 

DAAS rejects the unmatched requests to the sending organization using Reply Code 926. 

CorrectioRather thaalternativsection wof transitiReworked 
DAAS will create and forward an information copy of the DLA source of supply for all 

customer SDRs based upon the storage site reply where an information copy was not previously provided (ADC 225A). 

2 Navy - 

NSDRS 

Navy SDR would need to come up with a way to transmit attachments to WebSDR. The MQ queues are already in place because Navy SDR was going to include attachments when this interface first started. However, WebSDR wasn't ready to receive/send them, so the queues are still out there waiting to be used. It is recommended this change not be made to the current system, but rather be included as part of ITSR: 00023-001-08242 - SDR Redesign Project. 

Navy dec

 Navy - 

PDREP SDR 

1. Suggestion (Paragraph 10.b) : SDR systems that have attachments in them, should already have a unique numbering system in place for the attachments within its purview. Recommend a less complex file naming convention. For example: PDREP creates a unique ID for every attachment and a generic file name for each file attachment that goes into PDREP. A simpler format might be "System Name.System Unique ID.Generic File Name" "PDREP.089129.Switch 01-063-7138.pdf" Each system should be responsible for ensuring their files/names are unique within their system. Adding the system name (or anywhere else) ensures the file is to WebSDR. If WebSDR ever receives a duplicate it could ignore or overwrite the file it already has. 

PDREP can operate using the naming convention currently in the PDC but it would make it hard to match the file we have in PDREP with the file that would be in WebSDR since both would have substantially different names. If there were ever a security issue you may have to open each record and look at it to 

make sure you found the record in question or create a tracking method for the files with 

1. File nareally moincorporadate/time 2. The Doattachmenschedule. scans all t(every daaccessed/(accordinan updatecomputer infected fdon't matcof the scanext scan quarantin
various names the records may have in other systems and where they were propagated 

too. In principle we agree with the PDC. 2. I am not sure that you can keep a virus from occurring. How about GIF (pictures) 

files? Shouldn't the security requirement be placed on the process. Information should 

only be coming from Trusted Sources (Ex..MIL/.Gov ), using PKI. Trying to put the security on the data would costly and probably in-efficient. 3. Upon closer examination I noticed the max length of the file name should be 45 not 46 as there is a "zero' missing in the counter below the file 

extension name format on page 4. Should be "0" under the S in the name TTTTTTTTTTDDDDDDDDDDDDDDXBBOCCYYJJJHHMMS.EXTN 1234567890123456789012345678901234567890123456  1 2 3 4 Enclosure 1 also says a max of 46... 

3. Concusubsequen

4 Air Force 

Security Assistance Center (AFSAC SDR-A) 

1. First and foremost, implementation of a revised attachment interface in DoD WebSDR must be closely coordinated with program changes to the AFSAC SDR-A interface application. Per telecom with DoD WebSDR program manager/developer, if 

this proposal is approved, AFSAC SDR-A interfaces with WebSDR must be modified to 

receive/pass the revised attachment filename format and data file. However, no change will be required to the existing file names stored in WebSDR or AFSAC’s SDR-A. 2. Approval and implementation of this change requires several program changes to the AFSAC SDR-A automated process and associated interfaces. Per discussion with the AFSAC/SCP database administrator, AFSAC must have a minimum of 120 days advance notification of implementation to incorporate this change into our workload and 

1. DAASimplemen2. Concu3. Concu4. Concu5. Concu
interface test with WebSDR. 

3. Recommend acceptable file formats be expanded to include .docx, .xls, and .xlsx. 4. The 1 attachment limitation on follow-on report types (correction, cancellation, resubmission, contested) is unacceptable. At a minimum, at least 5 attachments must be allowed on all report types, in particular resubmission or contested, where the customer is expected to provide additional supporting documentation to support their claim. Currently, AFSAC can pass unlimited attachments to WebSDR as long as no individual attachment exceeds 5 MB. There are numerous Security Assistance SDRs with more than 5 attachments on them in WebSDR today. The 1 attachment limitation on WebSDR replies is also insufficient for some SDRs. While that limitation is currently in place in WebSDR, AFSAC must manually load additional attachments into our data system on behalf of the action activity if more than 1 

attachment is required to support their response. Recommend this be expanded to at 

least 5 attachments maximum as well if this PDC is approved and the attachment program is under revision. 5. The PDC asks for recommendations on how to add meaningful content to the proposed attachment file name structure. AFSAC recommends that the Transaction Purpose Code be included in the file name. This will enable the user to tell if the attachment is associated with a submission (00), resubmission (15), contested (50), 

historical (18), reply (11), etc. Please note that AFSAC SDR-A has the capability to pass ILCO attachments to the WebSDR system throughout the life of an open SDR. If an attachment is received in this manner, it could include an ‘xx’ in the Transaction Purpose Code field. 6. We cannot create a 'unique' file from only 10 positions; however, if we are able to marry it to the ILCO control # in the EDI, we should be OK. We will rename it with a unique name upon receipt of the physical file and EDI transaction from Sean. On SDRs going out, we will name it uniquely internally, and construct a file name on the EDI going out. It is not ideal, but I think it will work. 

6. The en50) positiwas for thhuman repeople caof info the results, phsomething numbers awould thedocument beginning which attaand which time stamthe entire be saved utransactioname, so 7. DAASproblem wLimit. 
7. RE: File Size. Maximum file size limit for uploading supporting 

documentation: 5 MB (total for all attachments associated with the transaction). The ILCO currently allows up to 5 MB per attachment. We disagree with limiting the MB for all transactions combined? We don't usually have more than 5 MB total, but in some cases we do, and the customer breaks attachments up to <5 MG increments by attaching more than 1 attachment. 

5 DLA - 

DDC 

DSS should be able to accept a flag notifying the user that an attachment is in WebSDR, so I will concur with that part. As far as sending outbound attachments from DSS, I can not concur at the moment. J6 stated that they would need to determine if this is feasible. 

All DLMable to recthe actual attachmenoptional. attachmenactivity/uview. 

6 DLA - HQ Security concerns expressed. See respo7 Army The TACOM AMC RO reviewed and concurs with no comments.