Frequently Asked Questions (FAQ) and Answers

The Defense Automatic Addressing System or “DAAS” is an enterprise value-added business transaction processing hub which provides validation, translation, routing, achieving, inquiry, and reporting services to its customer base. Additionally, it hosts a wide range of enterprise reference repositories such as the DoDAAD, MAPAD, Project Code, Distribution Code, and Fund Code Tables. It also provides a host of applications which can query the entirety of the consortium of data that flows through DAAS in order to generate various reports and metrics on the data passing through it. See DLM 4000.25-4.

The United States Transportation Command is the Executive Agent for transportation data and transaction standards. The Defense Transportation Electronic Business (DTEB) Committee identifies and resolves issues and recommends management actions that support the accelerated implementation of the electronic exchange of business information. As the focal point for all defense transportation e-business development efforts, it coordinates e-business standards and requirements with defense and federal organization and commercial industry. The committee represents transportation interests at all levels of the federal government.

The DTEB website is located at http://www.transcom.mil/cmd/associated/dteb/. Just sign in as "guest", then proceed to the DoD Transportation implementation conventions (ICs) hyperlink. The transportation regulation can be found at: http://www.transcom.mil/dtr/dtrp2.cfm.

We have found a couple of situations where people are unable to open documents created with Microsoft Office applications (e.g., Word) from our Website; the user gets a blank screen, even though the status indicates that the operation is "DONE". This problem appears to only impact users on WIN 7/Microsoft Office 2010 platforms.  

When we researched the Microsoft Office 2010 Trust Center settings, we determined that the default setting (unchangeable by the user) is to block binary documents created in 2000, 97, and 95 versions of Microsoft applications. Binary documents created in 2003, 2007, 2010 are free to access. Of note, those users in older versions of Microsoft Office have different default trust settings that allow these older documents to be opened (e.g., not blocked).  

WORKAROUND:

• Rather than selecting "Open" when prompted by Internet Explorer, select "File" => "Save As".
• Save the document to your desktop.
• When the save is done, you will be automatically prompted to either "Open" the document or "Close" the window.
• Select "Open"
• The document should open. Once done, you can go back and move the document from your desktop to the recycle bin.

DLM 4000.25 covers DLMS business requirements. Useful DLMS information is available on the Defense Logistics Management Standards Office website. The DLM 4000.25 and other Defense Logistics Management Standards Office administered publications are available at: DLMS Publications.

The term MILS, Military Standard(s), is used to describe legacy 80-column record position transactions embodied in the Military Standard Requisitioning and Issue Procedures (MILSTRIP), Military Standard Transaction Reporting and Accounting Procedures (MILSTRAP), and Military Standard Billing System (MILSBILLS) manuals. The overarching term is Defense Logistics Standard Systems (DLSS) which is a term that also refers to the MILS procedures. The DLSS are being replaced by Defense Logistics Management Standards (DLMS) manual which documents these procedures in a combined manual along with use of the DLMS replacement transactions, in American National Standards Institute (ANSI) Accredited Standards Committee (ASC) X12 format that contain unlimited record positions. The DLSS to DLMS cross reference can be found on the Defense Logistics Management Standards Office website at: DLMS Cross References.

The MILS are impeding the Department of Defense (DoD) logistics business transformation goals. As the Under Secretary of Defense for Acquisition, Technology and Logsitics (USD (AT&L)) stated in his December 22, 2003, policy memorandum, Migration to DLMS and Eliminate Defense Logistics Standard Systems (DLSS)..." Rigid fixed length EDI formats are functionally constraining, technologically obsolete, and unique to DoD." In order for DoD to expand and improve its logistics business practices, the Department must move away from the MILS as the basis for information exchanges.

DAAS will maintain customer profiles and furnish data to systems based on the system profile until no longer necessary.

Per DAAS, DAMES is designed for MILS transactions only and cannot currently accept ASC X12. If current DAMES users convert to X12 or XML, they shouldn't need a DAMES account any more. DAAS would set-up a file transfer protocol (FTP) or Secure Hypertext Transfer Protocol (HTTPS) account for them, as are currently used for other X12/XML customers. DAAS will continue to support DAMES/MILS processing for as long as it takes DoD customers to convert away from MILS. They will not be arbitrarily cut off.

The DoDAAD has been in existence since roughly 1960, when it largely existed as a paper-based, directory file that was updated manually by unit-level users who submitted TA_ transactions to the Defense Automatic Addressing Systems Center (DAASC) via hard cards that were keypunched at local communication centers. The Directory was originally a File that DAASC maintained, and as such, it was referred to as the DoDAAF until 2005, when the File was automated into the modern database that it is today, now known as the DoDAAD.

The DoDAAF (Department of Defense Activity Address File) was the name used to identify the flat-file version of the DoDAAD that existed prior to the reengineering of the DoDAAD in 2005 from a flat-file into the dynamic database that exists today? It is an archaic term.

The Department of Defense Activity Address Directory (DoDAAD) is an interactive, relational database that contains numeric records that identify activities. It serves as the single authoritative source of identification, routing, and address information for authorized users, including all Departments and Agencies of the Federal Government (DoD Components and Federal Agencies), authorized contractors, and authorized State and local government users. See DLM 4000.25, volume 6, chapter2, paragraph 1.1.

No. When the DoDAAD was reengineered in 2005 into an Oracle® database, it ceased to be “legacy” and is now scalable to meet the ever evolving requirements of a transforming Government information technology portfolio of systems. This is why the DoDAAD is a facilitator of business system transformation and process improvement.

Management of the DoDAAD as a system is the shared responsibility of DEDSO and DAAS; however, management of the data in the DoDAAD is the responsibility of the Components and Agencies who actually own the activities who have DoDAACs (and RICs) in the DoDAAD, and thus the data entered therein for each. The Central Service Points (CSPs) are the caretakers charged to maintain this data on behalf of their respective Services/Agencies. Ultimately, though, each Service/Agency Chief/Director/Administrator owns the data in the DoDAAD for their Service/Agency.

The DoDAAD is considered Controlled Unclassified Information because it has been determined by the Secretary of Defense to meet the criteria for categorization as Critical Infrastructure Security Information (CISI), which is defined by 10 U.S.C. § 130e, to include: ‘…sensitive but unclassified information that, if disclosed, would reveal vulnerabilities in Department of Defense critical infrastructure that, if exploited, would likely result in the significant disruption, destruction, or damage of or to Department of Defense operations, property, or facilities, including information regarding the securing and safeguarding of explosives, hazardous chemicals, or pipelines, related to critical infrastructure or protected systems owned or operated by or on behalf of the Department of Defense, including vulnerability assessments prepared by or on behalf of the Department of Defense, explosives safety information (including storage and handling), and other site-specific information on or relating to installation security.’ See DLM 4000.25, volume 6, chapter2; and DODM 5200.01, Volume 4.

No. The DoDAAD is maintained by DLA but belongs to all of the Services and Agencies who use it. As a system, it is considered a DoD enterprise system and not a DLA system.

The DoDAAD supports business application systems data and interoperability requirements of the DoD and Federal Agencies, including (but not limited to) procurement and acquisition, grants, supply chain, property, materiel management, distribution, transportation, maintenance, financial management, contracting, readiness, and human resource systems. See DLM 4000.25, volume 6, chapter 2.

Central Service Point. The person appointed by their respective Service/Agency as the principal custodian and manager of all of the records of that Service/Agency in the DoDAAD. They are responsible for updating and managing these records using the DoDAAD Update Application, and are usually involved in the DoDAAD PRC either as a member or participant. See DLM DLM 4000.25, volume 6, chapter 2.

When situations arise whereby Services/Agencies determine that DoDAAD management be delegated below the CSP level, DoDAAD Monitors can be delegated by the CSP to allow for lower-level management within the service/agency. This is generally reserved for Services with large numbers of DoDAACs and/or frequent volatility of changes made to their DoDAACs. Monitor responsibilities are generally associated to a particular Major Command (MAJCOM). DoDAAD Monitors are responsible for maintaining DoDAACs/RICs delegated to them by their CSP. Like CSPs, DoDAAD Monitors are appointed in writing but by their CSP.

GSA (Office of Supply Chain Management) serves as the CSP for all Federal Agencies. They represent the equities of the Federal Agencies at the DoDAAD PRC.

The DoDAAD is comprised of two types of records: Department of Defense Activity Address Code (DoDAAC) and Routing Identifier Code (RIC) identifiers.

The DoDAAD consists of both 6-digit DoDAACs and 3-digit RICs which are used to identify activities. These activities are grouped by Series. A Series is the first, first and second, or first through third (or first and last) characters of the DoDAAC. Each Service or Agency who uses the DoDAAD is assigned one or several Series to use for creating records for their Service’s/Agency’s use. The DoDAAD Series Table lays out this structure. Subordinate to the Series is a second “tier” or subdivision of a Service/Agency known as the Major Command Code (MAJCOM -- a.k.a. Bureau Code). These 2-digit codes are not specific to a Series, but they are specific to a Service/Agency. For instance, the U.S. Navy has the Series of N, Q, R, and V DoDAACs. They have MAJCOMS that identify the subdivisions of the Navy. These MAJCOMs apply to all Navy DoDAACs, regardless of Series. So, for instance, a MAJCOM of “N0” (Naval Sea Systems Command) may be used for N, Q, R, and V DoDAACs as necessary. DoDAACs and RICS are comprised of various other data elements that form the pedigree of each type of record. See DLM 4000.25, volume 6, chapter 2, DoDAAD Data Elements.

The DoDAAD Series Table identifies how the DoDAAD is subdivided by Series to the various stakeholder Services/Agencies who use the DoDAAD. Initial Series was limited to the first digit of the DoDAAD/RIC, using numbers to identify Federal Agencies, and letters to designate DoD. DoDAAC and RIC assignment is based on MILSTRIP Service and Agency (S/A) codes identified in DLM 4000.25-1, MILSTRIP, Appendix 2.2 - Service and Agency Codes; and DLM 4000.25 Volume 2, Appendix 7.2. Over time, expansion required developing Series logic beyond just the first character. To provide for expansion for additional agencies that require DoDAACs beyond those identified in MILSTRIP, the DoDAAD Series Table further stratifies S/A codes for use in creating additional DoDAAD Series for Services/Agencies. See DLM 4000.25, volume 6, chapter2, DoDAAD Series Table.

The Department of Defense Activity Address Code (DoDAAC) is a six-position code that uniquely identifies a unit, activity, or organization that has the authority to requisition, contract for, receive, have custody of, issue, or ship government-owned assets, or fund/pay bills for materials and/or services. The first positions of the code designate the particular Service/Agency element of ownership. These codes are particularly important for U.S. Government financial, contracting, and auditing records. The codes are used across the entire Federal Government when ordering supplies from the supply system using MILSTRIP, FEDSTRIP, or DLMS procedures; and for all contracts and orders. When assigned for activities outside the Department of Defense, the codes are often referred to as AACs. The code is comprised of different types of address information and other codes which are instrumental in facilitating business processes. See DLM 4000.25, volume 6, chapter2.

A DoDAAC is the business standard code used to identify an activity within DoD and Federal Agency business systems that span all functional domains of procurement/acquisition, financial management and accounting, supply, property, maintenance, transportation, readiness, human resources, etc. See DLM 4000.25, volume 6, Chapter 2.

An Activity Address Code is a generic term used to identify any code used for addressing but that is not found within the DoDAAD. It is also a term commonly used to identify DoDAACs used by Federal Agencies.

The RIC is a 3-character, alpha-numeric code that uniquely identifies a unit, activity, or organization that requires system ability to route transactions or receive transactions routed to it (e.g., a source of supply) within logistics and financial business systems using DLMS and legacy 80 record position format transactions. The RIC was originally conceived as an abbreviated form of a seven-character Communication Routing Identifier (COMMRI). The first position designates the particular service/agency ownership, the second and third characters are determined by the Central Service Point (CSP).

The RIC was intended to be used for the routing of MILS transactions within a nodal system. The RIC was supposed to identify the specific node in this system to which transactions would be routed to/from. Each RIC, in turn, is supposed to associate to a DoDAAC which is what actually identifies the activity for which the RIC facilitates routing to/from the activity. The RIC is not intended to identify an activity or any functional use other than MILS routing.

A RIC only associates to a single DoDAAC and a DoDAAC can only be associated to one RICs. This is because the RIC is a routing mechanism, and does not necessarily convey identity of or as an activity. That is the purpose of the DoDAAC. NOTE: The rule of a DoDAAC only being associated to only one RIC goes into effect December 31, 2025. Until than there are exceptions (see ADC 1263).

The RIC address is actually meaningless in today’s business environment. The address of the RIC should be the TAC 1 (owner) address of the DoDAAC, but the address was never intended to be used for anything but contact information for the RIC’s owner. Today, people send email and wouldn’t even think of writing a formal letter to contact someone. The RIC or Routing Identifier Code’s primary purpose was to fit on a MILSTRIP record for electronic routing of transactions. The DoDAAC was six characters, the RIC was only three and as such you could use both a TO and FROM RIC on a record that could only hold one DoDAAC. Do you need it? Maybe, maybe not. The RIC has limited uses and I can’t say if you need a RIC. Right now, the only requirement I can say with certainty requires a RIC is the WebSDR process. Most of the time, the DoDAAC can be used. That is the main reason for the change, because the first step in eliminating the RIC is creating a one-to-one relationship between DoDAACs and RICs.

Yes. Contractor DoDAACs are assigned to contractors whenever there is a requirement to identify a contractor within DoD business system transactions. These generally are instances that involve Government Furnished Property (GFP) – whether GFE, GFM, CAP, CFM – and generally include instances where either:

1. a Contractor has been authorized in a contract to requisition from Government sources of supply,
2. a Contractor requires Government property be shipped to them to perform some service (e.g., repair & return, repair & replace, modification, warranty, etc.),
3. a Contractor is performing some third party logistics (3PL) service in support of DoD (e.g., Gov’t owned/contractor run service/facility, a contractor managed inventory control point, etc.).

The Unit Identification Code is a six-character code created by the DoD Components to identify an activity in manpower and readiness reporting systems. Prior to the advent of the DoDAAC (circa 1960), the UIC was a five-digit code used for financial resources, readiness, and manpower. To enable Joint Services interoperability, the code was changed to 6-characters; however, certain Services and systems maintained use of the 5-character construct (Navy). The Office of the Under Secretary of Defense for Personnel and Readiness (OUSD P&R) is the DoD “owner” of the UIC. The database that contains all DoD UICs is the Unit Identification Code Search System (UICSS) which is administered by the Defense Manpower Data Center (DMDC) of the Defense Human Resource Activity (DHRA). This system obtains data from the Components’ manpower systems. The Army uses the 6-digit UIC. Navy uses a 5-digit UIC and applies an “N” to the beginning of their codes. Air Force uses the Personnel Accounting System (PAS), and the Marine Corps uses the Reporting Unit Code (RUC) for personnel reporting, and the UIC for reporting of structure requirements. Currently, however, the Marine Corps system that provides data to UICSS is the Marine Corps Total Force System (MCTFS) which provides the RUC information. Depending on the Service’s internal business processes, this field should be populated with the appropriate UIC to which the DoDAAC is associated, as applicable.

A DoDAAC facilitates business processes across all functional domains and is uniquely associated to the expenditure, distribution, and accounting of resources (i.e., property, goods, services, and funds); whereas, a UIC primarily serves as an identity code, specifically for use in manpower and personnel systems of the DoD.

An activity is any unit, office, organization, facility, or other entity which conducts business processes involving Government resources and for which a DoDAAC is necessary in order for that entity to have an identity in the systems used to facilitate these business processes.

The Series of a DoDAAC identifies the various types of activities, and where necessary, the DoDAAC Assignment Logic is also instrumental in identifying additional characteristics of activities. For instance, any DoDAAC beginning with a number in the first two positions of the code is a Federal activity. Any DoDAAC beginning with a number and a letter in the first two positions is a State or local entity activity. Any DoDAAC beginning with a letter is a DoD activity, but DoD contractors are identified by only certain letters or letter combinations, as identified in the DoDAAD Series Table. Currently, there is no Series or construct for identifying Federal contractors.

DoDAACs are generally used to construct a business event transaction. The most common of these are the Procurement Instrument Identifier (PIID), the standard document number, the MILS document number, or the Transportation Control Number. All of these business event identifiers begin with a DoDAAC. DoDAACs are also used in systems to identify owners of property and/or classes of Supply. They are used to identify activities for billing and payment. Additionally, DoDAACs are used for identifying shippers and receivers across the distribution pipeline. In some instances, DoDAACs are used to identify readiness equities, equipment sets, employer identification, etc. The use of the DoDAAC is always expanding.

The Central Service Points (CSPs) are the only people authorized to create, update and/or assign a DoDAAC. Based on you organization type there are different means to obtain a DoDAAC:

• Military or Government Service/Agency employees, contact your Central Service Point (CSP) or local DoDAAC Monitor at your location to have a DoDAAC assigned. If a DoDAAC Monitor does not exist at your Service/Agency, you may look up the CSP for your Servcie/Agency CSPs. Requests for new DoDAAC or modification to an existing DoDAAC must allow for processing by the CSP in order to be implemented in time for its intended use (e.g. requisitioning, shipping, billing, etc.).
• Private organizations (e.g., contractors) contact the Service/Agency with whom you have a contract. That Service/Agency will determine if you are eligible and assign a DoDAAC (if eligibility requirements are met).  Contractor DoDAACs are only issued for the length of the contract.  When the contract expires, the DoDAAC will be deleted (inactivated). If you contract is extended, you must contact your contract officer. Only a warranted contracting officer can request a DoDAAC change.

There are two methods of looking up a DoDAAC. If the DoDAAC is known, there is a public access site at: https://home.daas.dla.mil/DAASINQ/default.asp. This site requires no special access and you can use it today. There is also a search site available that allows you to find and return multiple DoDAACs at one time, but it requires a System Access Request (SAR) to use. The application name is eDAASINQ and the SAR can be made from DAAS at: https://home.daas.dla.mil/sar/sar_menu.asp. See our "How to Request eDAASINQ Access" guide for more detailed instructions.

Authority codes have been established to restrict requisitioning, shipment, and billing by DoDAAC. DoDAAC authority codes are applicable to all Services. Initially, DLA Transaction Services will assign Authority Code "00" (full authority to requisition, ship-to and bill-to) to all DoDAACs, unless a more restrictive code is already known for a DoDAAC, based upon existing DAAS edits. Following initial implementation, CSPs will update DoDAAC authority codes, as appropriate, and will assign authority codes to all new DoDAACs. Types of authority codes are listed on the DoDAAD Information page.

Go to: DLM 4000.25, volume 6, chapter2.

The list can be found on the DoDAAD Information page.

Contractors DoDAACs can be assigned by setting the Contractor Flag in the DoDAAC to "Yes."  If the DoDAAC is assigned to a Contractor, the Contract Information fields are all required. For all other DoDAACs these fields are disabled.

Yes. The contracting officer can assign as many DoDAACs to one contract as necessary to fulfill the requirements of the contract. Hence the 'many Contractor DoDAACs to one contract' relationship. This is covered in FAR policy at FAR 51.101 (see additional text below). In the case where there may be multiple ship-to locations, for example, there may need to be more than one DoDAAC assigned, even though the contract is awarded only to one contractor.

PGI 251.102-70 says The authorization to use Government sources of supply is unique to each contract and shall not be transferred or assigned to any other contractor or contract. Therefore, the same DoDAAC shall not be assigned to any other contract number during the period of performance for the contract. Which explains the 'one contract per DoDAAC' relationship. DPC has agreed that this limitation will only be enforced for DoDAACs with authority code '00' (meaning they can requisition). FAR 51.101 does not enforce the relationship for 'Ship To' or 'Administrative' DoDAACs. So a KO could change the contract number on a Ship To Only Contractor DoDAAC to a different contract if the first contract was closed. DPC yearly valids the contract DoDAACs to see if there are Contractor DoDAACs associated with closed contracts and will close them out.

FAR 51.101 says that contractors may use the government supply system (for which they need a DoDAAC) **in support of contracts.** (the allowable types of contracts are listed in the policy) It further goes on to say: Upon deciding to authorize a contractor to use Government supply sources, the contracting officer shall request, in writing, as applicable... A MILSTRIP activity address code from the appropriate Department of Defense (DoD) service point listed in Section 1 of the Introduction to the DoD Activity Address Directory... In each authorization to the contractor, the contracting officer --(1) Shall cite the contract number(s) involved; (2) Shall, when practicable, limit the period of the authorization...

You will need the Service who issued your contract to create a requisitioning DoDAAC in order to obtain the security container. Authorization for purchase is OGP 4800.2I, "Fixed-price contractors (and subcontractors) purchasing security equipment. Under 40 U.S.C. § 501, the Administrator has determined that fixed-price contractors and lower-tier subcontractors who are required to maintain custody of security classified records and information may purchase security equipment from GSA. Procedures for such acquisitions are set forth in 41 CFR 101-26.507."

Your problem is most likely related to the DoD WebSDR application and it may be reported to the DAAS Help Desk at DSN 986.3247, commercial (937)656.3247, or via email: websdrhelp@dla.mil. However, the DAAS Help Desk does not provide functional SDR support. If your SDR was submitted to DLA you may contact the DLA Customer Interaction Center (CIC). It is available to take your call 24 hours a day, 7 days a week. You can also contact the CIC at 1.877.352.2255 (1.877.DLA.CALL) or DSN 331.7766, or email: dlacontactcenter@dla.mil. Otherwise, contact the Military Service Source of Supply.

Go to the DAAS web page https://www.dla.mil/Working-With-DLA/Applications/DAAS/ where you can request the location of the WebSDR application. Access to WebSDR requires submission of a system access request (SAR), which may be submitted at any time via DAAS at https://home.daas.dla.mil/daashome/homepage.asp.

All SDR-related codes used in the DLMS process are identified in the DED/D. In addition, a consolidated list is available on the SDR Committee page.

(Note that none of the below policy issuances set a drop dead implementation date. The policy in each were effective upon signature with the presumption that DoD Components would implement expeditiously.)

• December 9, 1998: The DoD goal to adopt and implement commercially based transactional interfaces among DoD business systems was first stated in DoD Initiative Directive (DRID) #48 – “Adoption of Commercial EDI Standards for DoD Logistics Business Transactions,” signed December 9, 1998. DRID stated that the new information exchanges be based on the American National Standards Institute (ANSI) Accredited Standards Committee (ASC) X12 commercial electronic data interchange (EDI) standards in lieu of current proprietary DoD logistics information exchange standards.
• May 5, 2000: The goal established by DRID #48 was formally codified into DoD policy with the issuance of DOD Directive 8190.1, “DoD Logistics Use of Electronic Data Interchange (EDI) Standards.” The Directive stated that the DLMS is the basis for new, replacement, and major modifications to logistics business systems.
• January 5, 2015: DODD 8190.1 was updated retitled and reissued as DODD 8190.01E, “Defense Logistics Management Standards (DLMS).
• The policy continues to state that:
  • DLMS is the DoD standard for electronic data interchange (EDI) (transactional information exchanges) among the AISs that comprise assigned business processes of the global supply chain management system.
  • The American National Standards Institute (ANSI) Accredited Standards Committee (ASC) X12 is the baseline standard that supports the DLMS transactional information exchanges.
  • DoD Component heads shall support the DLMS change management process uniformly implement the DLMS in all AISs that perform business functions that support the global supply chain management, use the services of the DLMS global services providers, and use DLMS for ASC X12 transactions with contractors in accordance with the Federal Acquisition Regulation.

Absolutely not, DAAS will continue to ensure that every DoD system in the supply chain is able to continue to support its customers.

There are also MILS transaction dependent systems outside of DoD (e.g., FMS country representatives) interfacing with DoD systems that will likely require continued Transactions Services translation and mapping support between the DLMS and legacy MILS.

The problem is due to the fact that the information exchange standard that underpins the DLMS is the American National Standards Institute (ANSI) Accredited Standards Committee (ASC) X12. That standard requires that transactions transmitted between system must contain codes published by ANSI ASC X12 in three instances; Unit of Measure which is one you are concerned with, Mode of Transportation, and Unit Pack. In each of those three code structures the values that DoD uses internal to its systems (also used by GSA in its DLMS implementation and former FEDSTRIP) are different than those ANSI ASC X12 requires by used in its transaction sets.

Therefore, in the case of unit of measure DoD's unit of issue code values are maintained within the FLIS as you said and those are the codes used within DoD and GSA systems. However, in order for DLMS transactions to process correctly a sending system needs to convert the DoD code values to the ANSI code values prior to sending; likewise on the inbound side DLMS transactions received by a system must convert the ANSI code values back to the DoD/FLIS values. This process is explained in charts 38 through 41 of the DLMS Module Training slides, note that the slide have notes.  The conversion tables that you need can be found at DLMS ANSI Conversion Guides