Color key:  **Red**=Original DLMSO, **Blue**=DAASC, **Green**=IPT meeting discussion

DoD Questions:

(All of the entries for Phase II and beyond are definitely not specific enough or contain enough details to warrant existence in an RS.  The RS as it stands now, fits the description of a Operational Concept Description (OCD) and not an RS.  Recommend renaming this document)  

This is a valid comment.    Although it would have been appropriate to consider the document an OCD when first distributed, we have been working to expand the detail.   It will have more substance the next time you see it, but not a complete RS.  We are still planning to work individually with the Services to incorporate their interface requirements so we can finalize.

1. If a record has an/a attachment(s), how will the documents be sent to/from DAAS?  *Navy will need to modify NSDRS and the Navy XML in order to accommodate this new requirement, however there is concern over the length of the attachments mentioned in the DLMS Mapping spreadsheet.  NSDRS will save attachments as Oracle BLOB data types, will this cause any problems?*

*We will probably use Oracle BLOB for storing the attachments also.*

2. The DLMS mapping has the length of attachments set to be no larger than 100 characters, however the planned implementation by NSDRS will store the attachments as a BLOB data type.  What support will DoD provide for this? Don’t know where the limitation of 100 Character originated but the attachments are not likely to be in Characters. 

Please identify where the 100 character reference is located so we can update it.

We will probably use BLOB for storage.

Attachments will be resident on the web and will not be sent with the transaction. If a requirement exists to send the transactions, DLMS/DAASC will work with the activities to determine the best way to accomplish.  Activities that receive email in lieu of transactions will have a hyperlink to access SDRweb (login required) to view the attachment.

3. NSDRS has the potential to reject records based on Navy business logic, how will DAAS handle these errors?  Will the transaction originator be alerted to the error? 

The DoD WEB SDR can also Reject based on Navy Business Rules. If Originator uses WEB Reject would be On Line. If originator uses the 842A/W we will Reject using the 842A/R.

4. Will the DAAS translation process be done in ‘real-time’? 

YES.

5. NSDRS will use IBM WebSphere MQ for all transactions, will DAAS support this? 

DAAS Sends and Receives using MQ Series.

6. How will DAAS process the multiple line items that are in NSDRS, paying attention to the fact that line item order is important?  

Need more information on this.  In what context are you referring to line items?

The primary NSN is the NSN as originally requisitioned.  In addition, for wrong item SDRs, up to two wrong item NSNs (or part number/descriptions) are allowed in the 842 transaction and on the Web.  Components should identify additional requirements.

7.  (RS page 8, #6) Will the capability for follow-up for credit not received come from DAAS or is this required of the component system(s)?   

See item 8 response.

8.  (RS page 8, #7) Will the capability for verification of credit processed come from or be initialized by DAAS or is this required of the component system(s)?****

**Outline for SDR/MILSBILLS interface requirement:**

1.Whenever an SDR customer wants to know whether his or her refund has been processed by the seller, the customer should have the capability on the SDR status report or other page to query DAASC billing history by document number to identify detail billing records with the matching document number and suffix.

2.Whenever an SDR customer wants to submit a follow-up for credit for an SDR, there should be a follow-up for credit button on the SDR status report or other page.  This button would generate an 812, with advice code 026 and an optional reply-to e-mail.  DAASC would map the 812L transaction to the recipient’s transaction requirement.

3.The more comprehensive desired requirement which SDR and other DLMS customers might use is to provide A web based capability for any user with an account to generate a billing adjustment request at DAASC.  The screen form and web application would 

a.Include the data and rules prescribed in AP3.1.

                     (1)        Capture document number and suffix and, from a drop-down list, the billing advice code.

                     (2)        Pre-load standard FAE or FAF type data (more detailed capture requirements will be provided) from the matching billing record if a matching document number is found, 

(a)  if no document match and advice code is 26, obtain from the SDR record, otherwise, have user complete data. 

                      (3)        Capture optional reply-to e-mail address for use of the Seller or DAASC.

(a)  Send an e-mail text message to the e-mail reply to acknowledging processing of the request by DAASC and forwarding to the seller—this will also confirm the validity of the address.

b.When a valid reply-to e-mail is provided, electronic replies to adjustments request should be sent via e-mail provided.

The above is not directly associated with the BIC requirement, but was included in the Functional Requirements Document for consideration during Phase II or III.

9. NSDRS does not differentiate between EMALL and other requisitions, will this be a problem for DAAS?  No, not a problem.  This is considered ‘extra’ information to provide assistance to those working the SDR.  EMALL requisitions which process under MILSTRIP rules really have no distinguishing issues, but those that use purchase card for payment are different and we were trying to capture that up front.  

10. (RS page 8, #4) Where will this interactive POC directory be housed, will Components be required to use this directory, if so, how will this access occur? If Components are not required to use this directory, how will discrepancies between Component POCs and DAAS POCs be resolved?   DLMSO and DLA currently maintain manual lists of POCs for SDR processing.  The DLMSO information is currently outdated as the SDR guidance has not been updated in several years.  DLA provides new information yearly.  We were hoping to set up a POC directory that could be maintained by everyone as changes occur, so information will always be current with no duplication of effort. 

       This functionality is under consideration for Phase III.

11. NSDRS currently does not process shelf-life discrepancies, will DAAS send these types of discrepancies to NSDRS and if so, how should NSDRS respond to these? 

Since we have no access to Shelf Life data we would not be sending in the SDR.

If Navy manages shelf-life material, an SDR might be prepared for transmission to Navy.  We will need a work around procedure.

12. (RS page 8, #5) Will NSDRS be required to provide anything other than our XML transactions to foster these reports?   Eventually, we would like to have copies of all SDRs (even when processed internally within the Service) forwarded to DAAS for history.  This will build the data base we would need to produce the reports on a DoD level.  Within the IPT, we would like your help us create requirements for reports by sharing what you are doing today.  We just beginning to examine this area, and would like you to provide report requirements as known today or as desired in future.

      Navy agreed to provide input.

13. (RS page 8, #8) Will Components be required to provide access to these ad hoc/canned queries on their GUI? Or is this a DoD Web SDR requirement only?  We believe the Ad Hoc Queries are for the DOD WEB SDR System. Yes, we are only discussing DAAS web queries against DAAS database (no pushback into Service systems).

14. (RS page 8, #11) This entry seems to be more of a benefit of the BIC SDR IPT than a real requirement....what is its purpose?   We are working with the Wide Area Program Office and DLA to sort through just what is needed.   For now, we are planning that the acceptance report will use the current MILSCAP shipment/acceptance discrepancy explanation report (with one new code for UID discrepancies) to alert that there is a problem and that the receiver  should then submit an actual SDR.  No details resolved beyond this.

15. (RS page9, #12) NSDRS has not capability to accept UID transactions. Will these types of SDRs be required of NSDRS?  They will be required by policy which is being phased in.   We would work with DAAS to accommodate your timing (such as by moving UID discrepancy information to the remarks block until some future time when you can handle discrete data).  UID is a major initiative and since OSD policy is not fully defined we do not expect NSDRS changes any time soon.  You should know that OSD has directed that the DLA Distribution Depots prepare for receiving UID information on vendor shipments in January.  Discrepancies will occur and will be identified by SDR. 

16. (RS page 9, #13) NSDRS does not process SA SDRs, will DAAS send these types of SDRs to NSDRS?  Yes, presumably a small number would reach your system, but most will be directed to the DLA depots shipping the material.  AFSAC has been working with DAAS directly to build some additional functionality to support their requirements.  Those things that impact the ICP and shipping activities are being coordinated. 

The AF ILCO has designated the ICP as an ACTION Activity when DSS is not the Shipper.

17. (RS page 9, #15) What does this entry mean, why is it in the RS?  There are data elements which are obsolete and yet are still on the forms and some Service systems.  For example, not all the check boxes on the reverse of the SF 364 are still valid.  We are trying to identify what is still current and remove those that are not from all SDR related processes.   Clearly, this is something that would be phased in over time on your side, but that we want to address up front as we build new transactions and screens.

18. (RS page 9, #16) What does this entry mean to the components? If it is to be in the RS, it must be much more specific.  True, that statement was just intended to indicate that everything that we implement under Phase I is still subject to modification for improved functionality under Phase II.

19. Statement about the POAM: NAVSISA is a fee-for-service activity and typically an estimate is provided giving the number of hours that it will take to complete a particular project, as opposed to being given an implementation date.  An estimate cannot be made at this time because of the lack of firm requirements definition.  If the requirements cannot be finalized in a timely manner, there stands a distinct possibility that the May 2005 implementation date will be jeopardized.   Understood.  This must be communicated to OSD.

PAGE  

4