Defense Logistics Management Standards (DLMS) Introductory Training This module provides an understanding of DLMS Implementation Convention content. It builds on the content contained in Module 2, where we discussed the X12 standard, how that works, and what the basic building blocks are. Module 4 will now tell you how to apply the X12 standard through the use of DLMS Implementation Conventions. DLMS Implementation Convention Content

DLMS Training Catalog Module 1 - Introduction to the DLMS Module 2 - Electronic Data Interchange (EDI) Basics and ASC X12 EDI Definitions and Concepts Module 3 - DLMS Functionality & Transaction Life-Cycle Module 4 - DLMS Implementation Convention Content Module 5 - IUID & RFID - Emerging Technologies Module 6 - Creating/Reengineering DOD Logistics Business Processes Module 7 - Enterprise Interoperability Tools Module 8 - DoD Activity Address Directory (DoDAAD) Module 9 - Supply Discrepancy Reporting (SDR) Module 10 - DLMS Functional Financial Transaction (standalone) Module 11 - Creating/Reengineering DOD Logistics (standalone) www.dla.mil/does/DLMS This is the fourth installment in the DLMS training catalog. This module will focus on the use and application of the DLMS Implementation Convention content.

Module 4 Objectives Students will gain basic understanding of: The purpose and content of the DLMS ICs How DLMS ICs are used to support DLMS implementation The criticality of DLMS Notes How to read a DLMS Implementation Convention How to use MILS/DLMS mapping By the end of this module you will have a basic understanding of : The purpose and content of the DLMS ICs How DLMS ICs are used to support DLMS implementation The criticality of DLMS notes How to read a DLMS implementation convention and How to use MILS/DLMS mapping and Let’s start with a discussion about DLMS implementation conventions and what they are?  

What is a DLMS Implementation Convention? ASC X12 Transaction Set DLMS Federally Approved IC In Module 2, the focus was on the ASC X12 transaction set as a standard. ASC X12 is a commercial standard, it is in effect a standard template for predefined business uses like ordering, receiving, invoicing, etc. The base standard is the foundation template used by many different industries such as insurance, banking, rental car, etc. The Department of Defense family of trading partners is one such industry that uses ASC X12 as its base EDI standard. Each industrial group of trading partners needs to tailor the base standard for its use by applying business rules that are suited to its specific business context. The DLMS Implementation Conventions are that tailoring - the application of DOD business context and rule applied to the ASC X12 standard. DLMS implementation conventions, while developed by DOD are federally approved and available for use throughout the Federal Government. The standard by itself conveys no specific functional business context. Think of it as a road map or a guidebook that provides you the tools to identify routes/methods to reach your end point. The same applies with the ASC X12 standard; once the specific set of business rules are set in place, the guide is transformed into a DLMS implementation convention. So the answer to our question; what is a DLMS implementation is, that it is the tailoring of a broad transaction standard through the insertion of business rules that give it a specific business context for DOD trading partner usage. business specific interpretation

How is the Broad ASC X12 Standard Tailored to a DLMS IC? Implementation Conventions, while adhering to the standard, tailor the standard by: Defining the structure and content of an ASC X12 EDI standard transaction as it pertains to a particular usage Map application data requirements into specific ASC X12 data fields within the transaction set Establish the parameters for the specific DLMS Implementation Convention business usage DLMS Program Office identifies the structure and content of the IC based on the ASC X12 standard, maps the data elements for the business requirement, and establishes the business rules and parameters for usage. DLMS Implementation Conventions (along with the DLMS manual) constitute DOD's trading partner agreement for use within specific DOD business processes DLMS ICs (along with the DLMS manual) constitute DOD's trading partner agreement for use within specific DOD business processes.

Source of DLMS Functionality ICs supporting DLMS reflect functionality derived from multiple sources MILS capabilities are the baseline functionality Enhanced capabilities ASC X12 standards-based enhancements MILS/DLMS approved changes ICs supporting DLMS reflect functionality derived from multiple sources. First and foremost, all Legacy MILS functionality is contained within the approved ICs. That is the starting point and that foundation guarantees interoperability. This is why a Service still using legacy 80-card column requisition formats can obtain materiel from DLA who is operating under the DLMS. The ASC X12 is also a source of enhancements inherently present in the ICs. Another source of functionality are approved changes with full Component implementation pending. Those enhancements are documented in the IC. Once everything is DLMS, the enhancements will pass through seamlessly. Right now, if the system is legacy MILS based, the enhanced data content will be dropped because there is no place to pass the enhanced data (e.g., IUID) in the legacy MILS transaction formats.

Enhancements ASC X12 Standards-Based 8 digit dates throughout Multiple transactions Longer data elements: quantities, reference and identification numbers Repeating data elements Transmission date/time Full line of accounting as discrete data Flexible addressing Clear text addressing Codified addressing capability expanded: DoDAAC, RIC, CAGE, DUNS, DUNS+4, MAPAC There are several inherent X12 enhancements from use of this commercial standard that are leveraged in our approved ICs. One of the first and most important is the 8-digit date. This was a direct result of Y2K, otherwise known as Year 2000. In legacy MILS transaction formats, dates are typically defined as either Julian or ordinal dates. The Julian date is defined as the three position day within the calendar year; the ordinal date is the last position of the calendar year followed by the Julian date. As you can see, there are inherent limitations with these two tyand Julian/ordinal dates; the mapping is not perfect, but is as accurate as we can support at this point in time. pes of dates, specifically a lack of uniqueness between individual years or decades. These are resolved through the use of eight position dates defined as two position century, followed by the two position year within the century, the two position month within the year, and the two position day within the month. The use of an eight position date creates an enduring uniqueness. For interoperability with legacy systems using MILS formats, complex mapping logic has been developed to convert between 8 position dates Next, many of the X12 EDI transaction standards are structured to support transmission of multiple transaction business events. Using the looping structure discussed in Module 2, we could conceivably carry many requisitions in a single 511 transaction set. This efficiency of design would enable us to economize on transmission size and therefore reduce communications costs. However, due to our interoperability requirements, this is a capability that is very limited in our current DLMS implementations, but is something that can be added once the DOD no longer requires legacy MILS transaction mapping. Another enhancement is the capability to have increased field sizes for data elements, such as quantities and identification numbers. In the MILS legacy transaction formats, we are constrained by the fixed format limitations presented by the 80 record position format. In some cases, such as expressing large quantities, workarounds were developed to use multiplier codes to express quantities larger than five positions. In X12, most quantity field lengths are 15 positions, which is more than ample. However, due to interoperability requirements with legacy MILS formats, this enhancement has limited implementation amongst DLMS capable systems. Once again, when the DOD eliminates the reliance on legacy MILS formats, this functionality can be fully realized. Repeating data elements is another capability available through implementation of the X12 standard in approved ICs. In this situation, the X12 standard provides a capability to repeat multiple instances of particular types of information. For example, in the legacy MILS operating environment only one advice code can be passed to provide additional processing actions to the source of supply. Under DLMS, it may be possible to pass multiple advice codes that apply to a single requisition. Transmission of date and time stamps with every transaction is a major enhancement that is not fully resident in legacy MILS transaction formats. This capability has multiple benefits, namely it provides a clear audit trail documenting the date/time of when the actual transaction was transmitted. A secondary benefit is it improves the logistics metric analysis reporting system, because the date and time can be tracked for measuring logistics response time of all the supply chain pipeline segments, such as depot processing, receipt take-up time, and document how well each of the supply chain pipeline segments are performing. Flexible addressing is another highly beneficial enhancement that we get from implementing the X12 standard in our approved ICs. In legacy MILS formats, we handle clear text addresses as either trailer cards or in offline communications. Under DLMS, we can place the clear text address directly in the transaction data content, when required and authorized under designated business rules. The X12 codified addressing format also enables a clear identification of the type of organization code used to identify an activity, rather than relying on values from other relational data elements. Our approved ICs support identification of DoDAAC, RIC, CAGE, DUNS and MAPAC. And lastly, identification of the complete line of accounting as discrete data elements is a requirement that is gaining lots of traction within the DOD under its Financial Improvement and Audit Readiness requirements. SLOA or single line of accounting is the implementation of this new requirement and leverages the X12 capability to discretely identify all the data elements that comprise a line of accounting. This is an important initiative from DOD, since the Department of Defense has never passed an audit and one of the issues is DOD doesn’t do a good job of managing the money and tying money to what was purchased with it. Now under EDI it is possible to parse and pass all the accounting elements. This ability to track all the elements was not possible under the MILS formats; we only had the capability to pass a two-character data element, known as the fund code. As you can imagine, there are not enough two character fund codes to match all possible permutations of discrete data elements comprising a line of accounting.

(included in most transactions) General Enhancements (included in most transactions) Point of contact information Expanded material identification: national stock numbered material, ammunition, forms, publications, subsistence, preferred and substitute NSNs, part number, description Unique item tracking capability Unique item identifier (e.g. IUID UII Constructs 1 and 2, VIN, etc.) Batch number Lot number Serial Number Document number added to provide unique transaction identification Some of the enhancements available in the X12 standard are common to many of the approved ICs in use today. One of these enhancements is the ability to carry point of contact information, such as names, phone numbers and email addresses. This is very beneficial to anyone researching a problem with an order. Expanded material identification is another useful benefit. In the MILS legacy transaction formats, regardless of the type of materiel identification used, such as stock number, CAGE/part number, the value goes in record positions 30 to 45. The challenge is that it is not readily apparent if you are reading a stock number or a part number, unless you look to other data element values, such as the document identifier code, to make that determination on a referential basis. In the X12 standard, codes are available to discretely identify these various forms of materiel identification, so there is no reliance on other data element values in the transaction. The serialization tracking of material, otherwise known as unique item tracking, is becoming increasingly important within DOD. Today, there are specific procedures for tracking movement of selected items, such as small arms, using the item’s serial number. There are ongoing efforts to improve and expand tracking capability for additional items, perhaps an engine assembly or controlled cryptographic material. In these instances, serial number is not sufficiently unique to describe the item. Additional data elements such as the enterprise identifier, part number, batch number, lot number and serial number may be needed in varying combinations to uniquely identify the item. There is no room in legacy MILS transaction formats to carry all that information. EDI provides a format capable of storing this information. The inclusion of a document number in all DLMS transactions to provide unique transaction identification and an audit trail is a significant enhancement. Historically, not all legacy MILS formatted transactions, especially in the MILSTRAP functional area, carried a document number, due to lack of available space.

(included in most transactions) General Enhancements (included in most transactions) Break-out of embedded data Utilization Code (expressed in document number) Security Assistance data Required Delivery Date/Special Requirements Code Reduction/elimination of multi-purpose data fields Ownership/Purpose Codes With the use of EDI, that embedded intelligence and/or concatenation of values can be broken out into its discrete data elements. When the legacy MILS transaction formats and accompanying business rules were established, the record length was very limited, so the inventers of MILS had to get very creative to store all the data elements necessary. One of the ways they accomplished that task was to create intelligent data elements to embed the additional data elements. Document number, for example, is not just a random series of characters where they spin out the next unique number like FedEx does with their tracking numbers. It contains intelligent data, concatenated into a single data element. The first part of the document number is typically the DoDAAC identifying the requisitioning activity. Next are the ordinal date followed by the serial number. The serial number is also an intelligent data element; the first position of the serial number may contain a utilization code to identify relevant information as to the type of requisition. As you can tell, there is a lot of information conveyed in that document number. Ideally, when the DOD is no longer reliant on the legacy MILS transaction formats, the document number can become what it should be, just a unique number with no embedded intelligence in it. Another example of embedded, intelligent data is the Security Assistance requisitioner data element that is comprised of data elements such as the security cooperation implementing agency, the security cooperation customer code, the mark-for or in-country code, the delivery term code, and the type of assistance/financing code. By breaking out this embedded data it will enable us to expand the underlying code lists for each of the data elements, since the field lengths can subsequently be expanded, vice being constrained as they are today in the legacy MILS formats. A final example of being able to breakout embedded data is the Required Delivery Date on the requisition which may also convey other critical information such as the non-mission capable status of the customer or a request for expedited transportation by entering a special requirements code, such as 999, in the date field. Within ASC X12 only a date may be entered in a date field, so to carry the special requirements codes that are non-date values, the data element is broken out into a new data element with a new code list referred to as special requirements codes, to discretely identify this type of information. Occasionally the legacy MILS formats allowed a single data field in the transaction to be used for multiple purposes. For example, an inventory transaction may reflect the ownership of stored material or the purpose for which it is being stored. Since only one record position is available on the transaction, only one of these may be used at a time. Since there was no additional room to consider expanding the functionality or even the code lists in the legacy MILS formats, a business rule was established that ownership codes must be numeric to distinguish them from purpose codes which are alpha characters. The limited number of possible ownership codes (0-9) is already exhausted. Under DLMS, each code has a separate location in the transaction allowing for future expansion of either codes or functionality.

DLMS Implementation Convention Content

DLMS Notes Detailed DLMS business rules Key transition guidance The Implementation Conventions accept or prohibit options and often add conditions to the use of optional data within DOD logistics. Key transition guidance Governing operation in a mixed MILS/DLMS environment One of the single most critical pieces of information contained within a DLMS IC are the DLMS notes. The DLMS notes carry the detailed business rules for that particular data element or segment or whatever else is happening in the implementation convention. Later in this training, we will show examples of the DLMS notes and how they are used. DLMS notes do not just amplify the usage rules. In some cases, the notes will establish prohibitions, despite what the X12 standard may support. Compliance with these DLMS notes is essential to preserve the interoperability that we are trying to maintain while the DOD and its trading partners go through the transition period from operating with MILS transaction formats and business rules to the greatly enhanced DLMS transaction formats and business rules.

DLMS Introductory Notes - Transition Guidance Identification and instructions pertaining to: DLMS enhancements Approved DLMS changes Field size constraints “Streamlined” MILS data required for legacy system support, but not intended for use in full DLMS environment One category of DLMS notes prevalent in all DLMS ICs are the DLMS introductory notes, found at the beginning of each IC. These introductory DLMS notes provide transition guidance to facilitate interoperability as we transition from the MILS to DLMS transaction formats and business rules. The DLMS introductory notes provide information regarding DLMS enhancements; the new features in DLMS that are not supported in MILS transactions. The introductory notes also reference approved DLMS changes that were incorporated into the DLMS IC. Some changes co-exist in both MILS and DLMS, but others will only exist in the DLMS environment. For example field sizes are constrained to the limits of the MILS transaction and will have to remain constrained while MILS and DLMS co-exist. The opposite is also true. We have notes that talk about streamlined MILS data. This is carryover data not intended for the DLMS environment, but is required during the transition, so DLMS transactions can be mapped back to MILS formats until DLMS is fully implemented.

Streamlining Goals Reduce retransmission of data perpetuated from previously submitted transactions: Already resident in sender’s and receiver’s system Example: Original (non-mandatory) requisition data may be streamlined out of follow-up transactions So what's the goal of streamlining? One of the goals is to reduce the retransmission of data. As an example, if you closely examine the requisition in the legacy environment, you will find 75 percent of the processed order is retransmitted back to the customer in the form of supply status transactions. Shipment status transactions are similar in that the majority of the data is repeated from the original order. Now there was a purpose for this retransmission in the legacy environment. It was done primarily because legacy transmission was not as reliable as it is today and the repeated data allowed missing information to reconstituted. Under DLMS, we really don’t want to carry the duplicate information. With increased reliability of transmission accuracy and enterprise visibility systems, the likelihood of data being lost is a rarity. Also, as we increase the payload of our DLMS transactions due to increasing demands for greater volumes of data, we need to be cognizant of transaction size. Ideally, if you look at the requisition Life-Cycle, you would think that if I'm the customer that placed the order, the only information necessary is to know that the order was processed. It’s not necessary to have all the information from the requisition transaction repeated in the shipment status transaction.

Streamlining Goals, cont. Reduce encoded data content where transaction size constraints was the sole reason for encoding: The DLMS offer capability to communicate more precisely Transitioning is long term goal Another goal of streamlining is to reduce encoded data content; this refers to the discussion we just had on leveraging the X12 capability to eliminate embedded data content, such as the utilization code in the document number, separation of ownership and purpose codes, and separation of required delivery dates that are actual dates from special requirements codes.

Content of DLMS IC Notes DLMS business rules DLMS enhancements Field size constraints Streamlined data Approved DLMS changes (ADCs) In summary the DLMS IC notes contain: business rules, enhancements made to the IC, field size constraints and which (if any) approved DLMS changes are associated with that business rule. The notes also provide information on which elements contain streamlined data in the DLMS, which is important for programmers and for future systems planning purposes.

DLMS Notes - Examples DLMS Conventions Now that we’ve taken a look at some of the kinds of notes you’ll encounter when looking at a DLMS Implementation convention we’ll look at how they will appear within a DLMS Implementation Convention. Before we do that, here are some additional pointers to keep in mind when reading and applying those notes. First, notes will always have a gray background. Second, on some ICs you may see Federal Notes as a heading, these notes will go away in future revisions to the ICs. The Federal Notes will, if applicable become DLMS notes. With the recent reissuance of DOD Directive 8190.01E, the published DLMS Implementation Conventions are for Federal-wide usage.. Lastly, the location of the note within the implementation convention denotes its applicability. A note may apply to the entire implementation convention; when it does, it will be in the very front of the IC. It may apply to a specific segment within the transaction, a specific loop, a specific data element, or a specific code value. In each of the forgoing cases it will appear exactly where it applies. Lets move on and take a look at what the notes look like in an implementation convention. DLMS Conventions

DLMS Notes - DLMS Business Rules Example 1 – DLMS Introductory Notes Notes delineate appropriate functional application for a particular transaction This is our first look at a DLMS IC cover sheet. The first page of a DLMS IC contains DLMS introductory notes. These notes apply to the entire IC. Think of it as a table of contents. Where there are notes that pertain to specific rules intermittently referenced throughout, they are all cited by reference number from the front page, so the notes don't have to be inserted every time. Even though a lot of people like to skip the first page, everyone should stop and read it. Note that in the 940R DLMS IC we’re using as an example, you see that it still contains a Federal Note which will go later be renamed to a DLMS Note.

DLMS Notes - DLMS Enhancement Example 2 Data associated with a DLMS enhancement may not be received or understood by the recipient’s automated processing system DLMS procedures may have not been developed Components must coordinate requirements and business rules with DLMS Program Office prior to use Here is an example of a DLMS enhancement note that's on the first page of the document and is here referenced later on inside the implementation convention. This example is Code 92, Reason for Disposal Code. Here you see a note that is being applied to a specific code value. The first DLMS note explains the usage which is to identify the reason the disposal action is required. The second DLMS note states this is a DLMS enhancement and refers to DLMS introductory note 4a. This is a reference to a DLMS introductory note on the first page of this IC. In this example, DLMS Introductory Note 4a tells us that this data element is a placeholder and cannot be used at this time, because this enhancement may not be received or understood by the recipient system. Everything done within the DLMS is about procedures first. In this case, a placeholder was added and the note informs you it is just a placeholder and there are no procedures for its use at this time. So why are these “don’t use” notes present? They are there to let you know if you do have a need, you need to send a proposed DLMS change to DLMS Program Office so the procedures can be staffed and coordinated across the enterprise. DLMS Program Office added the placeholder in anticipation of possible future requirements.

DLMS Notes - Field Size Constraints Example 3 Data elements which have an expanded field size above existing MILS capability may not be supported by the recipient’s automated processing system Components must coordinate implementation with DLMS Program Office prior to use This is an example of a field size constraint DLMS note. In this case we see the quantity ordered field. The concept of field size constraints was mentioned earlier. The DLMS is constrained by restrictions of the MILS environment. The DLMS note tells the user the maximum length is restricted to only five positions, even though DLMS will ultimately allow fifteen positions. The reason for this is, if more than five positions are used, downstream systems still operating in MILS formats will not be able to receive the data content. It will either be dropped during translation or truncated. Until DLMS is used one-hundred percent, there will be certain restrictions placed on the DLMS transactions. This is an example of a note that applies at the data element level.

DLMS Notes - Streamlined Data Example 4 MILS data is retained in the DLMS for a transition period to support transaction conversion in a mixed MILS/DLMS environment This data will be “streamlined” out once full DLMS implementation is reached Components may coordinate with DLMS Program Office for early termination (or retention) of specific data requirements for users operating in a full DLMS environment This DLMS note speaks of future streamlined data. The idea of streamlined data was to retain selected MILS required data elements within the DLMS, until full DLMS implementation was achieved. In this example, we will explore the use of Signal Code. Signal code is an interesting data concept. It is one of the most brilliant workarounds our MILS forefathers devised back in 1962. A signal code is literally what it says - it's a signal; it points. The signal code will tell you, if the value in question is a “ship-to” or “bill-to” address. If it's a credit transaction, then who will receive the credit. It is a single data value and the reason for that is, there were only so many positions to work with on a keypunch card, so a single value occasionally had dual purposes. According to the DLMS notes, signal code is marked as a potential streamlined data element. The thought was, whenever we get to a full DLMS environment, we can be explicit and don't need this intelligent element serving a dual purpose. The “bill-to” and “ship-to” of the requisition could be identified as separate data elements, even if the values are the same. The key is, that the value carries a different connotation when identified as the billing activity versus the ship to activity. Will this automatically happen? No, there will be a proposed DLMS change if this is ever desired, and there will be staffing coordinated to clearly outline the amended rules.

DLMS Notes - Approved Change Example 5 Data associated with an approved DLMS change may not have an established implementation date. This data may not be received or understood by the recipient’s automated processing system Components must coordinate implementation with DLMS Program Office prior to use This DLMS note references specific ADCs. Approved changes may or may not have an established implementation date. The DLMS introductory notes will tell you if you must coordinate implementation prior to use. In this example, it states that the unit of use indicator is an authorized DLMS enhancement under ADCs 381 and 434. This means that only those systems involved in the implementation of ADC 381 and 434 are authorized to immediately implement the change as indicated in the ADCs. There is no harm in implementing the change, but the full benefit of the change is not achieved until both ends of the process make the change. Then the data can be utilized.

DLMS Notes - Repetition of Data Example 6 Repetition of data is not compatible with existing MILS/DLMS capability This data may not be supported by the recipient’s automated processing system Components must coordinate implementation with DLMS Program Office prior to use Repetition of data is another type of a DLMS introductory note. On the requisition, DLMS Program Office is frequently asked: “Why can't we pass multiple requisitions in one 511 transaction?” The short answer is, because we are in a mixed operating environment with both MILS and DLMS transactions flowing between systems via DAAS. All of our requisitioning processes are predicated on single line item requisitioning, to include not only the requisition, but supply status to those order, shipment status, receipts and billing. So a change to one part of those, impacts the entire life cycle of that order. DAAS has built maps that assume a single 511 requisition will correspond to a single MILS document identifier code A0_ transaction. It’s a one- to-one relationship. If multiple requisitions were submitted in a single 511 requisition under one document number, it would become very complicated to break that out. Each corresponding A0_ requires a unique document number, which would then have to be assigned by DAAS, without knowledge of the requisitioner who originated that particular requisition. When subsequent supply and shipment status transactions return to the requisitioner, they will have unmatched document numbers. Additional challenges would be how to handle suffixed document numbers. What if each of the line items in the multi-line order has to go to a different source of supply? How do you handle the required recording of financial obligations and any subsequent changes to individual lines during the order fulfillment process? When you process a receipt, how do you know which line item was received? To handle this problem, we currently have a built-in business rule in place that states even under DLMS we do single line item requisitions. So, while it’s possible to create loops, as these are supported by the X12, we are not exercising that feature at this point in time.

DLMS Notes - Authorized Enhancement Example 7 Data associated with an Authorized Enhancement should be included as part of the modernization when applicable Inclusion of this data should not cause an inappropriate rejection of the transaction Prior coordination is not required prior to use Here we have yet another example; the authorized DLMS migration enhancement. In this example, the first DLMS note states that X12 code U3 is used to identify the UII. The second DLMS note states that this is an authorized DLMS migration enhancement and to see DLMS introductory note 5g, which says, when you modernize your system, implement this enhancement. This is basically known as a staggered implementation of that data element. When you can do it, go ahead and implement. Until that point, no harm will occur if you ignore the enhancement. Also, you don't have to coordinate with the DLMS Program Office in advance, because the DLMS Program Office gives you blanket permission to implement when you’re ready. However, be advised that failure to implement the authorized enhancement will leave you unable to receive that information, as it will likely get dropped without being processed. So, it is to your benefit to schedule implementation within your impacted systems as soon as viable.

Overview of Reading The DLMS 511R IC Now that we’ve taken a look at some of the notes you’ll encounter when looking at a DLMS Implementation Convention, we’ll do a quick walk-through of the DLMS 511R IC starting on the first page and working our way through the reading of an IC. Since we’ll be looking at pieces of the IC and jumping around, you may want to print yourself a copy of the entire IC so you can keep track of where we are in the context of the entire IC. If you want to do that, you can go to the resources page of this Module or pull it down from the DLMS Program Office web site by clicking on the provided link: http://www.dla.mil/Portals/104/Documents/DLMS/Transformats/Supplements/4010/004010F511R5RA50_Mar2917_ADC_1176.pdf Conventions DLMS 511R IC: http://www.dla.mil/Portals/104/Documents/DLMS/Transformats/Supplements/4010/004010F511R5RA50_Mar2917_ADC_1176.pdf

DLMS 511R IC, Requisition What you’re looking at, is the first page of the DLMS 511R IC . Every page of a DLMS implementation convention is packed with valuable information. For the purpose of this course we will go into enough detail to give you some familiarity and hand’s on experience reading the DLMS 511R IC. The format, notations, and methodology for reading this particular implementation convention is the same for all the DLMS ICs.

DLMS 511R IC, Requisition A B C D E Here’s the top of the first page of the DLMS 511R Implementation Convention. Notice in the top left corner where it says DLMS Implementation Convention 511R Requisition directly above the larger print 511 Requisition; the R after the 511 indicates, that the DLMS Program Office has tailored the broad generic X12 511 transaction standard through the application of specific business rules for DOD trading partner usage. The X12 standard can be tailored and used for more than one type of business event. Within the DLMS there are two differing business events that use the 511 standard; one is the “511R, Requisition” which we’re looking at here and there is also the “511M, Requisition Modification” which is also founded on the basic 511 X12 transaction set standard. Now look to the right; there you see a long series of ADC numbers listed on three lines. These are the numbers of each of the approved DLMS changes that have caused revisions to this DLMS 511R IC. You can consider this the ADC change history of the 511R. These lines at the very top are repeated at the top of every page. Moving down the next thing you see is the large font 511 and the word Requisition, this is the ASC X12 standard number and name given to this transaction set. Below that you see the words Functional Group = RN. This tells you that this is a member of a group of functionally related transaction sets. What’s significant about this is, that the X12 standard allows transactions within a functional group to be transmitted together within the same functional group header segment (GS) and a functional group trailer segment (GE). Each transaction set is assigned a functional identifier code, which is the first data element of the header segment. Functional groups must contain like transaction sets for a single trading partner. • Below that you see the ANSI standard purpose statement for the 511. This reads exactly as it does in the ANSI standard. If there is any extension, clarification, modification of this stated purpose, that information would be documented in the DLMS notes which follow the purpose section. Note the words Draft Standard for Trial Use; this is standard ASC X12 terminology that is software generated at the beginning of the purpose on all transaction sets since they tend to have frequent changes. You can ignore this phrase, any published DLMS Implementation Convention published on the DLMS Program Office web site is available for use. Specific DLMS Implementation Convention ADC numbers that have caused revisions to this IC ASC X12 assigned transaction set number and name ASC X12 assigned Functional Group, which is RN ASC X12 defined purpose of this transaction set Note the words “Draft Standard for Trial Use”. This is standard ASC X12 terminology that appears on all transaction sets since they tend to have frequent changes. You can ignore this phrase, any published DLMS IC is available for use.

DLMS 511R IC - DLMS Introductory Notes Moving down the first page you’ll see the gray background area that tells you your in the notes section. We talked about the importance of notes earlier and we specifically looked at the ones that appear at the front of the IC as being applicable to the entire IC. We also mentioned that the Federal notes you see on this DLMS 511R IC will be eliminated or renamed as DLMS notes if applicable, since DLMS ICs are now for Federal-wide use. Now lets take a look at page two of the DLMS 511R IC. Gray background area: DLMS Introductory Notes – applicable to the entire IC Federal notes will be eliminated or renamed as DLMS Notes if applicable, since DLMS ICs are now for Federal-wide use.

DLMS 511R IC - DLMS Introductory Notes Here’s the top of the second page of the DLMS 511R Implementation Convention. Remember, we just saw the list of ADC numbers for change history on the top of the first page and that list appears at the top of every page. However, on page two and continuing into page three of this IC, we see in the notes section both the ADC number and the actual titles of those ADCs. The titles allow you to do a word search on this PDF document. For example if you were interested in ADCs dealing with Item Unique identification you could do a search on a word like “unique” and find some hits on the ADC list that you might want to note and then go to the DLMS Program Office web site to take a look at those specific ADCs. All ADCs that have affected the IC are listed by number and name Word searches can be preformed to determine ADCs that may be of particular interest

DLMS 511R IC - Transaction Set Table Diagram Starting about halfway down on page three and continuing through page four you see the transaction set table hierarchy diagram for the DLMS 511R. The table hierarchy diagram was addressed in Module 2. So in the middle of page two, we see a bold title that says “Heading.“ Remember from Module 2 that means we’re in Table 1 of the IC. Directly below the Heading you see the segments contained in the Heading. The segments are listed with the positions they are in within Heading, that is Table 1, the two character ID of the segments, names of the segments, whether they are required or optional, the maximum times they can be used and the usage column. For Loops you see the LOOP ID, such as LM and the maximum number of times the LOOP can be repeated in the transaction. Under the LOOP ID you see the segments in the LOOP and all the information described for a segment with the addition of the Max Use identifying the number of times each segment can be repeated within a LOOP. Note that the first segment within the Heading is the ST or Transaction Set header that denotes the beginning of this 511R. Also note that it is in position 10 of the header. A little further down you see the bold heading that says Detail, that’s the beginning of Table 2 and that portion of the diagram contains the same information for each segment and LOOP as discussed for the Heading. However, note that the position number starts over; so the first position within the Detail starts over with position 10 within Table 2. This table hierarchy diagram gives you a quick overall view of this IC’s architecture. The two primary differences between the ASC X12 standard we saw in Module 2 and the DLMS IC we’re looking at here are: First, the critical DLMS notes that we’ve discussed give this 511R specific business context for use by the trading partners using it and; Second the table hierarchy diagram above identifies the segments and loops that are used in the DLMS 511R. Any segments or loops that the ASC X12 standard itself may contain but are not used in the DLMS are either not shown or are labeled as not used. Transaction set table hierarchy diagram Identifies the segments and loops that are used in the DLMS 511R.

DLMS 511R IC - Transaction Set Table Diagram This is page four of the 511R where you see the rest of the transaction set table hierarchy diagram. Note the last segment as we learned in Module 2 is the SE, Transaction Set trailer, denoting the end of the transaction set. The entire 511R IC is 69 pages long, so this diagram provides a quick summary of the remaining 65 pages. Sometimes, in reading an IC, it’s difficult to keep in mind where you are in the context of the entire IC. It’s oftentimes helpful to flip back to the this diagram to help orient yourself. On the following series of charts we’re going to look at select pages of the 511R detailed information, that is the information that follows the transaction set table hierarchy diagram.

DLMS 511R IC - ST Segment Here’s the top of page five of the DLMS 511R Implementation Convention. Every segment that was marked “used” or “must use” in the transaction set table hierarchy diagram table is going to start at the top of a new page. This is the first segment of the 511R transaction, it’s the Transaction Set Header segment. Let's look in the upper right hand corner. This box has a lot of valuable information in it. First thing it's going to tell you in the upper left of the box is, what position of the transaction set this segment is in. It's in position 10. Note, this coincides with the transaction set table diagram that we looked at on pages three and four. This box helps you to stay oriented with regards to where you are, relative to the entire transaction. So the box is telling you you’re in position 10 of the Heading, that its mandatory, and that the Maximum use is 1. This box also tells you the ST is in the heading, which means it's table 1. It's maximum use is 1. So you can only use this ST segment once, no repeating of it. The number of data elements that we are using from the ST segment will be annotated in the lower right-hand corner of the box. In this case, it's 2. If there was a loop associated with this segment, it's going to tell you the loop ID. In this particular case, there is no loop, therefore the loop is annotated as N/A. So now let's go down to the ST01. Within X12 there are many transaction set standards, that is three character numeric codes, each identifying a different transaction. So If you were to look at data element 143 from the X12 standard versus the DLMS, you would see all numbers that the standard says are authorized. However, note that the DLMS IC only identifies one code value here. You see the 511 as the only authorized value. We're telling you in this IC, the only number you can use under this IC is 511. You can only use 511 because this is the DLMS IC for the 511R and nothing else is authorized. It’s important to note that in DLMS Ics. Regardless of the data element, only the authorized values will be shown, if it’s not listed in the IC then its not authorized for use within the IC. So what we do in the IC is, we pare down the list of authorized codes. ST02 is where the transaction set control number is. And do you see grey notes box? That's an example of a note that provides amplifying information. It’s also an example of a note that will become a DLMS note; remember in the future there will be no separately identified Federal notes. Now we will proceed to page six.

DLMS 511R IC - BR Segment On page six, we see the BR segment, which is the beginning segment. Notice, since it’s a new segment it started at the top of a new page. The top right hand box tells you that the BR segment is in position 20 of the heading and it is mandatory. It can only be used once, there is no associated loop, and this segment is using five data elements. The entire segment spans over pages six and seven and shows the data elements BR01, BR02, BR03, BR06, and BR09. Data elements BR04, BR05, BR07, and BR08 are not shown, which tells you that of the nine data elements in the ASC X12 standard, this DLMS IC is only authorizing the use of five. Now let's look at data element BR01. Note that this IC is authorizing the use of only three code values for this particular data element. They are 00, 77, and ZZ. Also see the DLMS notes associated with 77 and ZZ. These notes are necessary to clarify the meaning of these values within the DLMS which differs from the definition of those code values within the X12 standard. No note is necessary for the code value 00, since the DLMS usage definition matches that of X12. Let's look at code value ZZ. The ASC X12 definition is “Mutually Defined”. That’s not very precise. So that’s where the DLMS note comes into play. The first note says: Under DLMS, if we use a ZZ, it means it's a unit of use indicator. Now if you see a ZZ in a 511R in the BR01, that means that the person is telling you, I'm using unit of use in this transaction. Notes two and three explain that this is an enhancement. So when it says authorized DLMS enhancement under DLA industrial activities supporting unit, it means, if you are implementing this transaction under the DLA industrialized support agreement, you can use this and it's going to mean unit of use. If you want details of how that's used, go to ADC 381. If you're operating this under DLA Disposition Services, they also have an authorized DLMS enhancement in place to use unit of use, and it is described within ADC 457. Next we will take a look at page nine.

DLMS 511R IC – N1 Segment Here we have the N1 segment. Looking at the top right hand box, you will see that we are still in the Header of Table 1 and that the segment is mandatory. You can use it only once, and this DLMS IC is using four data elements. The N1 segment exists within the loop named N1. Lets look at the syntax rules. The first one is telling us that we must at least use the N102 or N103 data element or we can use both. The second syntax rule expresses that if either N103 or N104 is present, the other must also be present. Next let's examine the first gray notes box. We’ve talked about this before, this Federal note will become a DLMS note when this IC is revised. This note is what we would call segment note. Since it proceeds all the data elements in the segment, it applies to the entirety of this segment. The note is telling us that this segment is used to identify the organization originating the transaction set. Let's go further down and look at the N101. This data element has both a Federal note as well as a DLMS note. At first glance it looks like they conflict with one another. But the Federal notes as we said earlier will either be removed or modified as a DLMS note. In this case the Federal note might become a DLMS note that could read that Federal non-DOD users can use any code, but DOD DLMS users are only authorized the codes listed below. Let's go to the next slide and look at code OB, which is one of the authorized code values within data element N101.

DLMS 511R IC – N1 Segment Code Value OB “Ordered By" is the X12 name for code value OB. What does this really mean? The DLMS note provides clarification and states that OB is used to identify the requisitioner. So that's the DLMS usage for that, which just so happens to be the first six positions of the document number. Now let’s go to page eleven.

DLMS 511R IC – G61 Segment Point of Contact Here we are on page eleven of the DLMS 511R IC. We’re looking at code value IC as authorized code in data element G6101. The code IC is used to identify the point of contact. There was a DLMS change that was approved for a specific use of this code value. The related DLMS note says that code value IC is used by DLA Disposition Services in conjunction with the “Ordered By DoDAAC” to perpetuate the customer's contact name and phone number from the RTD web application. The note refers to ADC 466. DLA Disposition Services specifically requested this capability for a specific use of this code value as defined in ADC 466. Let’s continue with page fourteen.

DLMS 511R IC – N9 Segment Within LX Loop We’re now looking at the N9 Reference Identification segment. As you can see in the upper right hand box, we’re in the Detail or Table 2, it’s a mandatory segment that uses four data elements and is part of the LX Loop that we can use as many times as we want since the maximum usage is greater than one. The actual maximum usage is in the context of the DLMS, which is the number of code values that are authorized by this DLMS IC. So that’s an example of a segment within a Loop, used to convey a series of codes. On page 15 of the DLMS 511R IC shown on the next chart you’ll see a partial list of the code values listed under this data element.

DLMS 511R IC – N901 Data Element Document Number Here are some of the code values that can be used in the repeating Loop LX for data element N901. Lets take a look at the code TN and read the notes. This is another good example where ASC X12 has named and defined the code value one way and in DOD we are using it to represent something different but meaningful to DLMS users. The notes explain that in the DLMS the code value TN is the document number. That's another good example of where we define very specifically; while X12 calls it transaction reference number, in the DLMS world, we call it the document number, which is the back bone of the supply world. Now let's jump the LM segment on page 41 of the DLMS 511R IC.

DLMS 511R IC – Industry Code Source As you’re well aware, DOD makes use of many codes and code values that are unique to the DOD business and understood only by DOD trading partners. These code values are not maintained within ASC X12. Instead, ASC X12 has made provision for the industry users of the standard to establish and maintain their own code values. ASC X12 makes this provision through the use of the LM and LQ segments and looping structure. Step one of introducing industry specific codes is accomplished by the LM segment you see here. In the case of DOD, the LM segment points to the Department of Defense as the code value source and specifically to DLM 4000.25, the DLMS manual. Note that this segment only has one data element and it is within the LM Loop As you can see in the element summary, there is a ASC X12 data element LM01. If you were to look up table 559 for LM01 in the ASC X12 standard you would find a very large list of codes for the various industry sources. In the case of the DLMS and this DLMS 511R only one code is authorized and that is DF – Department of Defense. The source information is DLM 4000.25, available from the DLMS Program Office web site. The DLMS Manual provides a comprehensive set of concepts, general guidance, and codes related to EDI processing in the DOD logistics system in ASC X12 syntax. So the Department of Defense is the by ASC X12 designated source of the code values that will be identified in the LQ segment. Let’s look at the LQ segment on page 42 next.

DLMS 511R IC – Industry Codes Here’s the LQ segment. This is where the DOD unique codes are identified. Remember the source of the values that any of these codes can have is maintained within DLM 4000.25. There are two data elements in this segment - the LQ01 and LQ02. Notice the syntax rule that states that if the LQ01 is present, the LQ02 must also be present. This makes perfect sense, since the LQ01 will identify the code name or qualifier and the LQ02 will identify the specific value from the DLM 4000.25. On this chart you see the first data element LQ01. If you were to go to the ASC X12 table for LQ01, which is Id 1270, you would find the Code List Qualifier Codes and the code value sources. For example, code 78 identifies the Project Code, and the source of the values that the project code can be, are identified as code source 350, which is the DLM 4000.25. Next we’ll take a look at some of the codes that are available for use in the LQ02 data element.

DLMS 511R IC – Industry Codes cont. Here are just a few of the codes that can be in the LQ02. Notice that code 0 is the Document identifier Code or DIC, which identifies one of the legacy MILS transactions that the 511R is replacing. The MILS DIC is retained as a data element within the DLMS to support interoperability and to facilitate the DAAS Maps, which we’ll cover at the end of this module. You also see code 78 - Project Code and code 79 - Priority Designator Code, if you look at your hard copy or PDF of the IC beginning on page 42 and running through page 48, you can see all of the codes that are currently authorized for use within the DLMS 511R in the LQ02. We’re going to wrap up our quick survey of the DLMS 511R on the next chart.

DLMS 511R, Requisition ST*511*00000001 BR*00*A0*20000729******131708 N1*OB**10*FB2300**FR LX*1 N9*TN*FB230093070001 PO1**1*EA***FS*5910001234567 DD*R*74 LM*DF LQ*80*2A LQ*0*A0A LQ*AL*777 LQ*DF*2 LQ*DE*A LQ*78*XZZ LQ*79*02 LQ*A9*YBLDG1 LQ*AK*F N1*Z4**M4*S9E**TO N1*Z1**10*FB2060 N1*Z1**10*FD2040 N1*BS**10*FB2300 FA1*DY*D340 FA2*B5*KZ SE*24*00000001 So we’ve looked at several segments, data elements, codes, and code values, as well as DLMS notes in the DLMS 511R implementation convention. Hopefully you’re more comfortable on how to read a DLMS IC. We’re not trying to make you an expert in one sitting but now you should be able to look at the IC shown here and see how that standard causes the data on the right to form the DLMS 511R EDI transaction that gets transmitted. The last topic in this module will be about the DAAS Maps.

MILS to DLMS Mapping DAAS MILS DLMS Now let’s move onto the our next topic – mapping. Exactly what is mapping? We aren’t talking about cartography. Maps have been used historically to define, explain, and navigate. Maps have generally been pictorial but looking at them in a broader sense, they are a series of directions to get us from point A to point B and back again. Mapping is a huge mission that DAAS supports and they provide the foundation for interoperability. DOD is currently in a period of transition from the MILS to the DLMS. Some systems are using DLMS X12 transactions and some system are still using the MILS transactions and have not yet transitioned to the DLMS. The Maps allow each system to operate, using the transaction format that it is currently programed to use, without regard for the format that the other systems it interfaces with are using. Remember from Modules 1 and 3 that all transactions pass through the Defense Automatic Addressing System (DAAS). DAAS has profiles of all the systems that connect to the DAAS. One of the things in a system’s profile is what format it uses, MILS or DLMS. That profile knowledge and the use of the DAAS Maps allow DAAS to receive one format from system A and convert it to the format that system B uses, in case they are different. The maps are also useful to system program managers who are migrating a MILS transaction based system to the DLMS. They are helpful because the maps allow the developers to identify MILS data element by MILS data element and see exactly which DLMS data elements need to be used and populated to carry the same data in the DLMS transaction that replaces that MILS transaction. One last thing to remember, DAAS Maps are specific to a system and the precise Map versions to be used for a system are specified by the performance based agreement between DAAS and the program office responsible for the system. The map used by DAAS for a system does not change until the system program office requests a change and updates the performance based agreement for its system interface with DAAS.

MILS to DLMS DAAS Implements program logic to accommodate conversion between MILS and DLMS Identifies data content and location within MILS and DLMS Uses conditional rules to determine data content and location DAAS stores the program logic to handle the translation of MILS to DLMS and DLMS to MILS transaction formats. The logic is very detailed and not only addresses field-to-field mapping, but the conditional rules applied to the data embedded within the transactions that dictates what fields are required and how to mine and reformat the data needed to satisfy the appropriate output format. Does this mean that systems don’t have to be DLMS compliant, because DAAS will handle the translation? No. DAAS is handling translation to support interoperability as an interim transition measure to provide a minimum baseline of interoperability. However, DAAS cannot replace the need for Components to attain DLMS compliance, because the DLMS include hundreds of enhancements to processes supported by data that cannot be mapped to a MILS transaction.

DAAS MAP DAAS Maps are proprietary for official use only and are available only from DAAS. Those logical maps are used to develop computer code that executes the mapping on the fly as transactions pass through DAAS You might want to go to the resources of this training and print out the full DAAS 511R Map. We’ll be looking at pieces of the map on the next series of slides. This is the first page of the 511R DAAS Map. All maps are structured and read the same way, so when you understand how to read this one, you will be able to read and understand any DAAS Map. Note that the bottom of the first page of a DAAS Map always identifies the date this particular map was last updated. Let’s continue by going to page two of our DAAS Map for 511R. The logical maps are used to develop code that executes the mapping on the fly as transactions pass through DAAS.

DAAS Map Configuration Control Page Due to their criticality, the maps are very tightly managed by DAAS. Every time the map is changed, it is documented in a change log as part of the map. Here you’re looking at a portion of the change log on page 2 of the 511R Map. The actual change log for this map goes on for four pages with the last change document occurring on August 1, 2014. This log provides the date of the change, the reason for the change, as well as linked bookmarks. Most importantly it provides the number of the Proposed or Approved DLMS Change that caused the need to change the map. Next we’ll go to the first page of the actual mapping, which is page 6 of the actual document.

DLMS 511R Logical Map Here you see the top of page six of the logical map. This is where the mapping actually begins. The top grey area tells you that it’s for the 511 requisition map to and from all the MILS document identifier codes listed below it. Under that you see the column headings. The first heading “Field Name” identifies the DLMS field names. The second column “Record Position” identifies the record positions where the first column’s information is found in a MILS transaction. The third column identifies the conditions that, if present, will cause information to be mapped and entered into the fourth column, the equivalent DLMS data elements. The fifth column identifies the DLMS Table - 1 for Heading, 2 for Detail and 3 for Summary. The last column just denotes the ADC or PDC number that caused a change to the row on this map. We’re going to read the map from left to right, so we are mapping a MILS transaction into a DLMS transaction. The map can also be read from right to left to Map a DLMS transaction into a MILS transaction. Let’s begin. Notice that the first two field names in column one have the word “None” in the record position column. All that means is, there is no equivalent data field in the MILS. If you look at column four you see that the map inserts a constant 511 in the DLMS ST01 data element, since this is a 511 transaction. In the second field name, the Transaction Set Control Number, the map automatically inserts a computer generated serial number in the ST02 DLMS Data element. Now lets look at the third data field, the Beginning Segment. There again is no equivalent data field in the MILS, so the record positions column shows “None”. However, there is program logic in the conditions field. The conditions make use of the data found in the identified record positions of the MILS transaction. The data content, when matching the condition, causes the preprogramed logic that fills the BR01, BR02, BR03, BR06 and BR09 with the appropriate code values. Now lets look at the field name “Ordered By”. This is the first field name that has data in both the MILS and the DLMS. “Ordered By” in a MILS requisition is in record positions 30 thru 35. That’s actually the first six positions of the document number in a MILS requisition, which is a DoDAAC or MAPAC. The conditions state that, if the first two characters of the document number contain an A0 and position 30 does not indicate a foreign military sales customer, and positions 74 and 75 do not contain an Army Edit Action Code of IV, then populate the 511 DLMS N1 segment data elements as follows. Populate OB in the N101 indicating the qualifier “Ordered By”, put a 10 in the N103 indicating that the requisitioner will be identified using a DoDAAC, populate the N104 with the DoDAAC from positions 30 thru 35 of the MILS transaction, and populate the N106 with FR which indicates that the requisition is from the DoDAAC in N104. On the next series of charts we’ll take a look at how the item identification is mapped.

Requisition Materiel Identification The MILS Fixed Format Requisition RPs Field Legend 01-03 Document Identifier 04-06 Routing Identifier 07 Media and Status 08-22 Stock Number 23-24 Unit of Issue 25-29 Quantity 30-43 Document No 44 Demand 45-50 Supplementary Address 51 Signal 0102030405060708091011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465656768697071727374757677787980 52-53 Fund 54-56 Distribution 57-59 Project 60-61 Priority 62-64 Reqd Delivery Date 65-66 Advice 67-69 Blank (Date of Rcpt on Referral/Passing Order) 70-80 Blank (Intra-Service use) Here you see the record positions and field names in a MILS requisition. We’re going to see how the materiel identifier labeled “Stock Number” in record positions 8 thru 22 gets mapped into a DLMS 511 requisition. You’ll see on the next chart that the information in record positions 8 thru 22 isn’t always a stock number.

Requisition Materiel Identification MILS DIC A0_ (RP 8-22) Depending on the third position of the Document Identifier Code A0_, the requisition may hold any one of the following forms of materiel identification in record positions 8 thru 22. It could be: A National Stock Number known as NSN, which can also be used for NATO stock numbers, or An NSN plus codes (these are unique to individual Components), or A part number (comprised of, when applicable, the Commercial and Government Entity code or CAGE code and the manufacturer’s part number), or A Subsistence Number, which includes, when applicable, the Subsistence Identification Number and the Subsistence Type of Pack, or Other types of numbers, that can be difficult to distinguish because the document identifier code doesn’t specify and the format is not prescribed. This includes plant equipment number or a locally assigned number. We learned that within the DLMS we can very distinctly specify what kind of identification number is being used in a particular transaction to identify the materiel that the customer is requesting.

Materiel Identification Mapping 511R, Requisition Materiel Identification Mapping PO106: A1 Plant Equipment Number A2 DOD Identification Code (Ammunition) A4 Subsistence Identification Number FB Form Number FT Federal Supply Class FS National Stock Number MG Manufacturer's Part Number YP Publication Number ZZ Mutually Defined Remember in MILS the Document Identifier for the requisition indicates whether the required materiel is an NSN, a part number, or one of the other forms of materiel identification. The 511R permits a much broader range of discretely identified pieces of information, including what type of materiel identification is being used. The P0106 (box on left side of screen) offers various qualifiers to identify materiel. For example, when requisitioning by part number, the P0106 would identify qualifier MG, manufacturer’s part number. Since a part number alone is not sufficient, the PO108 (box on the right) would also be used to provide the manufacturer’s CAGE code. The DLMS are flexible and allow for a virtually unlimited expansion of codes to identify materiel identification nomenclatures as well as lengthening field size of the identifier itself. Next you’ll see how this flexibility is used within a DAAS Map to identify the materiel being ordered. PO108: CN Commodity Name JP Package Type Code ZB Commercial and Government Entity (CAGE) Code

Mapping Document MILS DIC A0_ to DLMS 511R DAAS 511R Map Example: MILS DIC: A0B  part numbered item For this example we assume the Document Identifier in record positions 1 and 2 of the MILS transaction contains A0 and record position 3 is a B, indicating that the item requested in the requisition is for a part numbered item. The map would then move the values from MILS record positions 13 thru 22 into the P0107 with qualifier MG (part number) in P0106. The map would also move the values from MILS record positions 8 thru 12 into the P0109 with qualifier ZB (CAGE) in P0108. That’s how the DAAS maps work.

Summary DLMS provides a new logistics data exchange format Commercial vs. DOD proprietary standard Variable length vs. 80-record position records W3C compliant XML schema formats Supports new data content to meet DOD needs Provides opportunity to reengineer logistics business processes Supports emerging business/electronic commerce capabilities So in summary, here is what we have covered in this module. We introduced you to the DLMS Implementation Convention or IC format and how it supports the new data content to meet DOD’s emerging and evolving needs. We looked at how the DLMS are created, starting with the commercial standard and how that standard is tailored to create the DOD proprietary standard (DLMS). Reviewed the fixed length MILS transactions and the variable length EDI transactions and talked about how the DLMS are enabling us to reengineer our business processes and support new processes and data content like single line of accounting, IUID and radio frequency identification.

Module 4 Quiz Question 1: Where do you look to find DLMS specific business rules? DLMS Implementation Convention Yellow Pages ASC X12 transaction set The sky Question 2: If implementing a DLMS enhancement, which of the following must be done? Read DLMS Implementation Convention Notes Coordinate with trading partner Cross your fingers Check for an implementing ADC or check with DLMS Program Office Question 3: What does DAAS do to facilitate MILS/DLMS conversion? Implements program logic to automate conversion Identifies data content and location within the MILS/DLMS formats Reflects conditions that impact data content and location All of the above Question 1: Where do you look to find DLMS specific business rules? The correct answer is A, DLMS Implementation Conventions. Question 2: If implementing a DLMS enhancement, which of the following must be done? The correct answer is A, read the DLMS IC notes. Question 3: What does DAAS do to facilitate MILS/DLMS conversion? The correct answer is D, all of the above.

End of Module 4