*DLM 4000.25-4, April 09, 2022*

*Change 7*

**C4. CHAPTER 4**

**Defense Automatic Addressing System (DAAS) PROCESSING**

C4.1.  GENERAL

The DAAS provides all the Department of Defense (DoD) Components/Participating Agencies a single entry point into the DoD Logistics Supply System.  This eliminates the need to maintain multiple communication protocol rules and records and the unique supporting infrastructure necessary to send and receive information to/from multiple trading partners.  All logistics transactions can be sent to DAAS without regard to data content or ultimate destination of the information.  Use of the DAAS infrastructure, also, eliminates any need for the customer to sort transactions by type or destination.  DAAS maintains the necessary trading partner profiles to ensure data is delivered on time, in the correct format, and to the correct destination.  An archive of all messages and transactions processed by DAAS infrastructure is kept on storage media for later user access.  All output transactions are permanently archived for historical, retransmission, audit, and reporting purposes in accordance with DoD Instruction 5015.02.  The DAAS can process all computer-readable logistics transactions with the exception of certain logistics transactions containing narrative exception/supplemental data.  Input and output to/from the DAAS is done by receiving/sending formatted messages through a variety of communications gateways and networks.  The DAAS uses the following indicators to process logistics transactions:

C4.1.1.  Source of Supply (SoS).  As recorded by the Integrated Materiel Manager (IMM), Air Force, Army, and Navy/Marine Corps for each National Item Identification Number (NIIN).  Includes special Naval code.

C4.1.2.  Department of Defense Activity Addressing Code (DoDAAC).

C4.1.3.  Routing Identifier Code (RIC).

C4.1.4.  Military Standard Requisitioning and Issue Procedures (MILSTRIP) Distribution Code.

C4.1.5.  Military Standard Billing System (MILSBILLS) Fund Code.

C4.1.6.  Military Assistance Program Address Code (MAPAC).

C4.1.7.  Project Code.

C4.2.  MESSAGE PROCESSING

The DAAS message handling processes go through a number of steps which may include the following:

C4.2.1.  Receipt.  The DAAS receives Defense Logistics Standard System (DLSS) legacy 80 record position transactions in the Military Standard (MILS) record forma~~t~~, DLMS-based message data in either the Accredited Standards Committee (ASC) X12, eXtensible Markup Language (XML), or User Defined File (UDF) formats through various communication networks.  Additionally, a message traffic ‘pass-through’ service is provided for those customers who have no direct data exchange communications link(s) with each other.  A single input message normally has transactions that could be output in several output messages generated by the DAAS sub-systems.  Multiple input messages from various customers may contain transactions that are combined into a single DAAS output message.

C4.2.2.  Review.  DAAS maintains 90 days of message header information in replicated tables for the purposes of performing a DUPLICATE MESSAGE check.  The tables are queried by DAAS’ servers during the message receive process.  Algorithms are used to determine which, if any, messages should be rejected due to a record of previous receipt.  A communications service message will then be sent to the originating activity saying that the message was deleted and requesting that it be reviewed for determination as a possible duplication.  If it is found to actually not be a duplicate, the transaction(s) need to be resent in a new message.

C4.2.3.  Intercept.  The DoD Components/Participating Agencies are responsible for providing their DAAS’ focal points with Service specific transaction-processing rules.  These activities can also ask for mission critical emergency changes to respond to a new mission or a changing world situation.  Most of these type requests cause transactions to be rerouted to/from a different location than the normal SoS or destination address.  Some of the requests are for DAAS to intercept selected transactions and either redirect/terminate them, or hold them for further directions on dispensation.  For example, if a hurricane is moving toward Hawaii, transactions destined for DoD activities/installations in the affected area can be intercepted and held at DAAS until the storm has passed and then released in the same sequence in which they were received.  DAAS allows the input of the transactions into an activity’s application system(s) to maintain the records as if no interruption had occurred.  As the single point of entry into the DoD Logistics Supply System for our customers, DAAS can intercept any data, make changes to the data content, edit shipping instructions, and support all the DOD Component/Participating Agency contingencies under the following conditions or emergency situations:

C4.2.3.1.  A DoD-directed or customer request.

C4.2.3.2.  Natural disasters or other similar situations. 

C4.2.3.3.  Support for special operations and emergency deployments.

C4.2.4.  Broadcast.  DAAS serves as a gateway for logistics information and as a repository for numerous types of logistics data.  As such, it provides data distribution services to the DoD Components/Participating Agencies for use in their local processing systems.  DAAS receives data at a unique routing address that can trigger distribution of the data to a predetermined set of recipients.  DAAS maintains the information necessary to deliver the data to multiple destinations and is able to effect system changes within a short timeframe.  The originating systems rarely have to make any program changes to support these new distribution requirements.  Some examples of existing data distribution information/codes available for use, by the DoD Components/Participating Agencies, are:

C4.2.4.1.  Communications addressing information.

C4.2.4.2.  Standard Point Location Code (SPLC) data.

C4.2.4.3.  Distribution Standard System (DSS) support.

C4.2.4.4.  Military Surface Deployment and Distribution Command 

(SDDC) support.

C4.2.4.5.  Cargo Routing Information File (CRIF) data.

C4.2.4.6.  Fleet Logistics Center (FLC) support.

C4.2.4.7.  Automated Manifest System (AMS) support.

C4.2.4.8.  Cargo Movement Operations System (CMOS) support.

C4.2.4.9.  Federal Logistics Information Services (FLIS) Portfolio catalog updates.

C4.2.5  Transmission.  The DAAS is designed for transmission of computer-readable logistics messages using secure telecommunications circuits.  Our Non-Secure Internet Protocol (IP) Router Network (NIPRNet) connection to the Defense Information System Network*(*DISN) provides the capability of sending data, using various secure transmission protocols like Secure File Transfer Protocol (SFTP), via Transmission Control Procedure/ Internet Protocol (TCP/IP), web-based forms, or HTTPS.  In addition, DAAS uses ***AS2 Protocol,***SMTP, and IBM MQ, a guaranteed delivery transport from an IBM MQ origin to an IBM MQ configured destination.  This supports customer needs for guaranteed delivery, while continuing to support existing data formats, such as Joint Army-/Navy-Air Force Publication (JANAP) messages and modified DDN file formats.  DAAS electronic data interchange (EDI) applications also make use of IBM MQ and Virtual Private Network (VPN) connections to transport information in the ASC X12 and XML formats.  Specific file naming conventions are used to ensure data integrity and provide a method for identifying, tracking, and accounting for all files and data transferred.  Standard secure internet protocol provide connectivity for small volume customers, legacy e-mail is also used but not recommended due to the deprecated communication protocol used.  Acceptable data formats are depicted in Chapter 3:  Table C3.T1. “Authorized Transaction Formats.”

C4.3  MILS LEGACY TRANSACTION PROCESSING

C4.3.1.  Editing.  When the DOD Components/participating Agencies send DLSS legacy 80 record position MILS format transactions to DAAS they are edited, validated, routed, and delivered to the appropriate destination.  Edits performed include:

C4.3.1.1.  DoDAAC or MAPAC.  Validation of the DoDAAC or MAPAC.  This is the first major edit done by the DAAS and is vital to mailing, shipping, and billing functions.

C4.3.1.2.  NSN or SoS.  The national stock number (NSN) describes the item of supply and is associated with the managing inventory control point (ICP) or SoS.  DAAS uses the SoS and associated management data as part of its on-line processing records and is the designated repository for the last known SoS.  If the transaction’s SoS code is incompatible with the NSN’s SoS code in the repository, the DAAS may change the SoS code in the transaction, sending it to the correct SoS, while sending the supply status information to the submitter in notification of the redirection.

C4.3.1.3.  Fund Code.  Fund codes are edited to ensure MILSBILLS compatibility.  If an invalid code is used, the DAAS may either change the code or reject the transaction, as required by the DoD Component/Participating Agency’s processing rules.

C4.3.1.4.  Project Codes and Priority Codes.  These codes are edited to ensure activities are not abusing code assignments and are authorized to use certain codes.  If an invalid code is used, the DAAS may change the code or reject the transaction, as required by the DoD Component/Participating Agency’s processing rules.

C4.3.2.  Rejections.  Representative examples of business rules that would cause a transaction to reject are depicted below:

C4.3.2.1.  MILSTRIP Transactions Designated for Local Procurement.  The DAAS will reject transactions to be routed by the IMM SoS record when that source is coded decentralized (D9_ or XDG).  This procedure is limited in application to Continental United States (CONUS) requisitions that do not contain Advice Code 2A.  An AE9 transaction with Status Code CP is returned to the originator of the transaction.

C4.3.2.2.  Invalid MILSTRAP Transactions.  The DAAS will validate all MILSTRAP Special Program Requirement (SPR) transactions.  Invalid transactions are returned to the originator(s) using the appropriate reject advice code in card column positions 79-80 as follows:

C4.3.2.2.1.  Reject Advice Code AD, the NIIN cannot be identified.

C4.3.2.2.2.  Reject Advice Code AX, the correct SoS is GSA.

C4.3.2.3.  MILSBILLS Transactions*.*  The DAAS will confirm or reject MILSBILLS transactions as prescribed in DLM 4000.25, DLMS, Volume 4.

C4.3.2.4.  Other.  The DAAS confirms certain elements of input transactions to find the addressee and to ensure the RIC of the activity(s) to receive response transaction(s) are valid.  Invalid data causes the DAAS to reject and return transactions to the originator, with an included narrative description to indicate the reason for rejection.  The rejected transactions must be corrected by the originator and retransmitted to the DAAS in a new message.  Transactions will be returned for the following reasons:

C4.3.2.4.1.  Garbled transactions.  Transaction fields are shifted or unreadable.

C4.3.2.4.2.  Invalid Document Identifier Code (DIC).  The DAAS cannot read/identify the transaction; the transaction is not to be transmitted electronically; or the transaction is not authorized for transmission to the DAAS.

C4.3.2.4.3.  Invalid Service Code.  The DAAS cannot identify the service code entered in the transaction.

C4.3.2.4.4.  Invalid DoDAAC.  The code is not in the master DoD Activity Address File (DoDAAF).

C4.3.2.4.5.  Invalid NIIN.  The NIIN has alphabetic characters or blanks.

C4.3.2.4.6.  Invalid MAPAC.  The code is not in the master Military Assistance Program Address File (MAPAF).

C4.3.3.  Routing and Rerouting.  The DAAS edits, validates, routes, and delivers transactions based on agreed to business rules that have been supplied to DAAS by the DoD Components/Participating Agencies:

C4.3.3.1.  Accepted Transactions.  All processed transactions are delivered to the appropriate destination in the proper format and protocol based upon the customers’ requirements.  After processing, all transactions are collected by destination, based on applicable message precedence and transaction priority, and a new message is prepared and sent through the appropriate communications network to the activity destination address.  The message precedence and content identifier code (CIC) are assigned in accordance with the appropriate correlation table.  

C4.3.3.2.  Item SoS Record.  If the originator of the transaction is other than a United States Army (USA), United States Navy (USN), or United States, Air Force (USAF) activity, routing is determined by examining the IMM column of the SoS record.  If a USA, USN, or USAF activity originated the transaction, the entry in the SoS column of the DoD Component parent is used to determine the routing as follows:

C4.3.3.2.1.  If the SoS in the DoD Component record is an activity of that Component and an active SoS, the transaction is sent to the SoS in the DoD Component record.

C4.3.3.2.2.  If the SoS in the DoD Component record is an inactive source or an IMM source, the transaction is sent to the SoS in the IMM record.  If the IMM record is blank, the transaction is sent to the SoS in the DoD Component record.

C4.3.3.2.3.  If the SoS in the DoD Component record is an activity of another DoD Component, the transaction is sent to the other Component.  If the other DoD Component record is blank, coded as inactive, or contains an IMM source, the transaction is sent to the IMM SoS.  However, if the IMM record is blank, the transaction is sent to the originating DoD Component. 

C4.3.3.2.4.  If the SoS field in the DoD Component record is blank, the transaction is routed to the SoS in the IMM record.  If the IMM record is blank, the transaction is passed to the Routing Identifier’s ‘To’ entry in positions 4 - 6 of the transaction.

C4.3.3.3.  Coding Inactive Items.  As prescribed by the Defense Inactive Item Program, the DAAS decides during requisition processing if the DoD Components/Participating Agencies’ IMM record, used for routing, is coded inactive.  The DAAS inserts an ‘I’ in the demand code field of the transaction, to advise the sender that it pertains to an inactive item of supply.  This procedure is applied by the DAAS for those requisitions routed in accordance with item SoS records.

C4.3.3.4.  National Geospatial - Intelligence Agency (NGA).  Military Assistance Program (MAP) Number Conversions are performed in the following cases:

C4.3.3.4.1.  MAP number to and from NSN.

C4.3.3.4.2.  RIC conversion process for MAP requisitions.

C4.3.3.5.  Transaction Rerouting.  The DAAS may reroute transactions under the following conditions:

C4.3.3.5.1.  Destination Changes.  Transactions routed by the DAAS may be sent to a destination other than that designated by the originator.  When this is done, the DAAS notifies the originator of the change.

C4.3.3.5.2.  Status for Rerouted MILSTRIP Transactions.  When the DAAS reroutes a MILSTRIP requisition, a passing order, or a referral order, the notice to the originator is a standard ‘AE9’ MILSTRIP transaction with Status Code BM in positions 65 - 66 and the changed RIC in positions 67 - 69.  The originator is notified in each instance when the DAAS changes the destination of an excess report DICs FTC, FTE, or FTF transaction.  This notice is a DIC FTQ transaction with Status Code TZ (destination change Federal Supply Class change) in positions 65 - 66, the DAAS RIC in positions 4 - 6 and the changed RIC in positions 67 - 69 of the transaction.

C4.3.3.5.3.  Status for Rerouted MILSTRAP Transactions.  When the DAAS reroutes a MILSTRAP Special Requirement Program (SPR) transaction, the notice is a standard DIC DZ9 MILSTRAP transaction with MILSTRIP Status Code BM in positions 79 - 80 and the RIC of the correct SoS in positions 67 - 69 of the transaction.

C4.3.4.  Images:  During processing, the DAAS makes images of selected transactions, sends them to activities who may be monitoring a project, or the transactions may become part of a DoD Component/Participating Agency logistics database.  Image making has become a major workload for DAAS with millions of images being produced each month.  Frequently, multiple images are made of the same transaction and sent to different databases.  For example, an image of a shipment status transaction will be sent to the Asset Visibility (AV) system, the US Transportation Command’s (USTRANSCOM) Integrated Data Environment/Global Transportation Network Convergence (IGC) System, the USAF TRACKER System, or the US Army’s Logistics Information Warehouse (LIW) System.

C4.3.4.1.  DAAS currently makes transaction images for the following organizations:

C4.3.4.1.1.  Defense Finance and Accounting Service (DFAS).

C4.3.4.1.2.  Defense Logistics Agency (DLA).

C4.3.4.1.3.  Federal Civil Agencies.

C4.3.4.1.4.  USTRANSCOM/GTN. 

C4.3.4.1.5.  Other DoD.

C4.3.4.1.6.  USA (LIW and others).

C4.3.4.1.7.  USAF (TRACKER, Lean Logistics, and others).

C4.3.4.1.8.  USCG.

C4.3.4.1.9.  USMC. 

C4.3.4.1.10.  USN.

C4.3.5.  Determining Destination Addresses.  Transactions processed by the DAAS are categorized as traffic to either be routed or passed as follows:

C4.3.5.1.  Routed Traffic.  This is defined as those transactions for which the DAAS rules and records are used to find the addressee, regardless of the destination cited by the transaction originator.  The DAAS rules and profiles for routing transactions are specifically tailored for the DoD Components/Participating Agencies.  For example, a designated transaction may be routed by one rule/ profile for the USA and by a different rule/record for the USN or USAF.  In addition, the DoD Component/Participating Agency will specify if the DAAS rules/profiles are to apply to all or only some of its activities (e.g., the DAAS routes USN requisition transactions in accordance with the item SoS record for certain USN activities).  The DAAS applies two basic techniques to route transactions:  (1) the use of the DoD Component/Participating Agency special processing rules and (2) the item SoS records.  The former is checked first and, if no processing rule applies, the transactions are routed based on the SoS record.

C4.3.5.2  Passed Traffic.  This is defined as those transactions that are routinely forwarded to the addressee designated by the transaction originator.  Passed traffic includes supply/shipment status, materiel release orders, redistribution orders, most inventory management transactions, and includes some requisitions and referral orders.

C4.3.6.  Batching.  Transactions for a given destination may be batched with a new message being assembled and formatted for transmission through the appropriate communications network to the destination activity.  Normally, DLMS transactions are collected/assembled for up to ten minutes for supply priorities 1 - 8 or for other transactions specifically designated as priority, and for up to 1 hour for all other transactions.  Transmission time intervals are tailored to meet the destination activity’s requirements.  

C4.4.  X12 AND XML TRANSACTION TRANSLATION AND CONVERSION

	C4.4.1.  Translation.  DAAS has a specifically tailored COTS software suite that provides data translation capabilities to and serves as a central transformation processor for all of the DoD.  The capability includes conversion services for DLSS **legacy**80 record position MILS format transactions to DLMS, DLMS to DLSS transactions, XML to XML, DLSS/DLMS/XML to UDF, and UDF to DLSS/DLMS/XML formats.  This allows for implementation of the DLMS as the DoD legacy systems evolve along their own timelines into new and redesigned Enterprise Resource Planning (ERP)-based logistics systems.  This capability has been implemented by the Services for many logistics processes within the DoD Components/Participating Agencies.

	C4.4.2.  eBUS Gateway.  DAAS supports the latest eBusiness (eB) methods and protocols for the DoD Components/Participating Agencies to use in sending and receiving DLMS ASC X12 /XML transaction sets.  The eB gateway provides an interoperable gateway for DoD components to exchange data supporting a variety of business areas including by not limited to procurement, transportation, financial, logistics, and contracting data.  Using this component of the DAAS allows DoD activities to send and receive from a single DoD focal point.  This reduces the overhead of eB trading partners by making it unnecessary for the DAAS partners to maintain addressing and profile information on the DLMS implementation conventions being used by all their individual trading partners.  The DAAS can receive and transmit transactions by using the intra-DoD communications protocols/networks or by using commercial VANs.  For contingency and growth purposes, there are two functional eB distribution gateways, one at each DAAS site.  These eB hubs receive ASC X12, XML or UDF transaction sets from the DoD Components and private-sector vendors conducting business with the DoD community.  DAAS  provides connectivity/mail-boxing/reporting services between DoD/Government procurement, financial, transportation, and contracting activities and their private sector trading partners.

	C4.4.3.  VAN Services.  In addition to providing connectivity to numerous commercial VANs, DAAS own eB VAN provides VAN services for our customer base.  The DAAS eB VAN provides a central eBusiness communications gateway for translation, conversion, connectivity, mail-boxing, and reporting services between the DoD Components/Participating Agencies and their private industry partners.

C4.4.4  DoD eBusiness GEX Consolidation.  DoD made a decision in 2011 to transfer the GEX program management responsibility from the Business Transformation Agency (BTA) to DLA , and to begin consolidation of all GEX functionality at DAAS’ two eBusiness Gateways.  As a result, the process of moving all current eBUS customer connections from the two existing DISA GEX gateways to DAAS has begun.  Once complete, all DoD eBusiness customers/transactions will be routed through the two DAAS’ GEX gateways.

C4.4.5.  Customer Profiles/Trading Partners.  DAAS currently maintains two sets of trading partner profiles, one for MILS customers, and one for DLMS X12 and XML eB customers, as follows:

C4.4.5.1.  DoD Gateway (DGate). DAAS maintains a MILS customer profile for each DLSS legacy 80 record position format transaction customer.  The customer profile has information about a customer’s communication routes and formatting requirements.  Profiles are stored in the DAAS processing system and their upkeep is considered a part of file maintenance.  Profile changes and additions are constantly taking place as existing customers’ environments change.

C4.4.5.2.  DoD eB Gateway.  Trading partner agreements and profiles for each DLMS eB customer identify communication routes and formatting requirements for DoD Components/Participating Activities, along with information on their associated commercial trading partners.  The Trading partner agreements are stored in the eB processing system and their upkeep is considered a part of file maintenance.  Trading partner changes and additions are constantly taking place as new trading partners are identified and existing customers’ environments change.

C4.4.5.3.  Future Vision.  Transaction volumes in both the MILS and the eBusiness areas are expected to continue to increase, in part due to the consolidation of all GEX EDI traffic at DAAS .  Current modernization plans call for DAAS to move towards establishment of only one type of customer or trading partner profile, which will cover all customers/partners regardless of transaction format(s) or end-system configurations.  Finally, the DAAS processing of DLSS transactions and the DMLS X12 and XML transactions will, also, be consolidated through a single gateway employing common transmission and security protocols. 

C4-1	CHAPTER 4