ADC 296 

Passive Radio Frequency Identification (RFID) Transactions 

1. ORIGINATOR: 

a. Service/Agency: Defense Logistics Agency

b. Originator: DLA J-3YI, Commercial (717) 770-1538

2. FUNCTIONAL AREA: Primary: Automated Identification Technology (AIT); Secondary: 

Supply Chain Visibility

3. REFERENCE: DoD 4000.25-M, Defense Logistics Management System (DLMS), Volume 

2, Chapter 24, Change 5. 

4. REQUESTED CHANGE: 

a. Description of Changes: This change includes an update to Chapter 24, Passive RFID 

Transactions and the requirement to add “Delivered” and “Undelivered/Attempted Delivery” to 

the XML Visibility transaction in support of local delivery. A copy of the revised Chapter 24 is 

provided as an enclosure, with the changes identified by a strike-through for deleted information, 

and red, italicized type to show added information. 

b. Description of Changes in detail: 

(1) This update to Chapter 24 deletes program references in Change 5 about the Alaska 

RFID Initiative (ARI) mentioned in paragraph C24.2. DoD has now deployed passive RFID 

(pRFID) to other sites outside of Alaska, and the use of the referenced pRFID transactions is no 

longer focused solely on the pRFID systems in Alaska. 

(2) This update provides additional details about the use of the Visibility Transaction, 

adding two new events that can be reported, Delivered and Undelivered/Attempted Delivery. 

(3) The rules have been updated to reflect the expanded use of the Visibility Transaction 

and the associated Reader Function Codes to record deliveries and undelivered/attempted 

deliveries. There are two additional Reader Function codes to reflect these new events. Code X 

(Delivered) and Code U (Undelivered/Attempted Delivery) are now added to the Visibility 

Transaction Data Requirements Table. 

(4) A new transaction data table (Table C24.T3, Visibility Response Transaction Data 

Requirements) has been added to identify the data elements associated with the Visibility 

Response transactions sent by DAASC in response to a follow-up request from a site using 

action code “F” (Follow-up) in the Visibility Transaction. 
(5) The authorized values for Shipment Notice Type in the Visibility Response 

Transaction data table have been modified. If the Reader Function Code is F (Follow-Up 

Information), then the Shipment Notice Type field will contain “SHIP” in lieu of “856S”; if the 

Reader Function Code is N (No Information Found), then the Shipment Notice Type field will 

contain “NONE” in lieu of “856”. 

(6) An updated pRFID data flow diagram is provided. 

c. Procedures: The procedures that are added or changed are as follows. 

(1) Local Delivery Event Reporting. The procedures for local delivery have been 

added and will be supported by the use of the pRFID Visibility Transaction. The depot will 

make local deliveries and record the delivery event by reading either a case or pallet pRFID tag, 

depending on the shipment configuration, using a handheld pRFID reader. 

(a) Material will be transported to the customer location for delivery, and will be 

accompanied by a pRFID tag. Application location of the pRFID will depend on shipment 

configuration, customer requirements, or delivery process. For example; for process efficiency 

the shipment parent tag could be applied to a manifest instead of multiple pallets or in the case of 

a single item delivery, the MSL could be the scanned. 

(b) Upon delivery to the customer location, depot drivers will scan the RFID placard 

on the building at the delivery location and then scan a pRFID tag representing the shipment 

during offload. If no delivery was possible, the driver will annotate in the handheld an attempted 

delivery.

 (c) When the local delivery driver returns to the depot or homebase, the pRFID 

handheld device will either be placed in a docking station or connected via wireless to upload the 

delivery data to the pRFID server. 

(d) The pRFID server middleware will process the RFID reads as they do today for 

internal queries and external reporting of the visibility transaction, and make use of the new 

Reader Function Codes for identifying both Delivered and Attempted Delivery (Undelivered). 

(e) DAAS will receive the visibility transaction with these new codes and process 

them as they do today for Arrival, Departure, and Observed events. 

(2) Visibility Response Transaction. This transaction is used to reply to requests for 

data if the pRFID middleware fails to associate the pRFID tag with a previously transmitted 

transaction such as a DS 856S, Shipment Status. 

(a) The middleware will send a Visibility transaction to DAAS with Action Code F. 

(b) If the requested information is found, DAAS will transmit a Visibility Response 

transaction containing the following data elements: RFID Location Control Number (of the site 

initiating the follow-up request), Tag Read Date/Time, Reader Function Code of “F”, Passive 

RFID Tag Number, Shipment Notice Type of “SHIP”, Document Number, Document Number 
Suffix, Transportation Control Number, Shipment Date, NSN/Part Number and Quantity 

Shipped. 

(c) If DAAS does not have the information, the sender will receive a Visibility 

Response Transaction from DAAS with an ‘N’ in the Reader Function Code field indicating the 

corresponding DS 856S or DTEB 856A transaction was not recorded at DAASC. The data 

elements for this type of visibility response will be RFID Location Control Number, Tag Read 

Date/Time, Reader Function Code of “F”, Passive RFID Tag Number, and Shipment Notice 

Type of “NONE”. 

5. REASON FOR CHANGE: The changes are proposed to standardize the pRFID processes 

and related visibility transactions used throughout DoD. In addition, the additions will expand 

the use of pRFID to local delivery and the associated delivery and attempted delivery 

transactions to be implemented under Joint Regional Inventory Materials Management 

(JRIMM). 

6. ADVANTAGES AND DISADVANTAGES: 

a. Advantages: The change creates a standardized automated process for passive RFID 

transactions used in DoD and supports the local delivery process when pRFID tags are used with 

local logistics processes. This capability provides visibility at the point of delivery to the 

customer, when the customer’s system neither is DLMS compliant nor has pRFID middleware to 

bridge the compliancy. The changes will also help clarify the use of pRFID data, and the 

associated visibility, visibility response and reader registration transactions to be used in both 

existing and future applications.

b. Disadvantages: N/A.

7. Impact: 

 a. Modifies DoD 4000.25-M, Defense Logistics Management System (DLMS), Volume 2, 

Chapter 24, Change 5. 

b. Modifies the requirements for the DAAS “V” table to include new Reader Function 

Codes “X” and “U” in support of the delivery and undelivered/attempted delivery processes 

associated with local delivery. 

c. Supports the implementation of the DLA’s Distribution Standard System (DSS) local 

delivery procedures to integrate pRFID as part of the DLA JRIMM implementation. 

d. Adds to the data available for Asset Visibility (AV) reporting capability. When or if the 

new delivery data reported with Visibility Transactions is included for AV reporting purposes, 

changes will be required in order for the AV report database to include the new delivery data. 

 

Enclosure (Chapter 24, Passive Radio Frequency Identification)
 

ENCLOSURE 1 to ADC 296 

(Changes are identified by red, italicized text; deletions are shown with a strike-through) 

C24. CHAPTER 24

PASSIVE RADIO FREQUENCY IDENTIFICATION (RFID) 

TRANSACTIONS

C24.1 GENERAL. This chapter provides procedures for reader registration and visibility 

processing general information supporting the Department of Defense (DoD) RFID 

implementation. The Department of Defense requires integration of passive RFID (pRFID) 

technology in the DoD Supply chain. Visibility is a critical component of this project requirement. 

and The Defense Logistics Management System (DLMS) includes the establishment of data 

requirements that support shipment visibility across the DoD supply chain. The detailed 

procedures pertaining to this program requirement are under development and provided in this 

chapter. will be expanded over time. DoD policy Stakeholder information regarding this passive 

RFID implementation is located may be found on the DoD AIT website (URL): 

http://www.transcom.mil/ait/. 

C24.2. APPLICABILITY AND SCOPE. This guidance is applicable to the Alaska RFID (ARI) 

Program and applies to future pRFID implementations DoD passive RFID system 

implementations. The scope of the project includes systems that currently send, receive, and/or

collect supply and transportation data for the Defense Logistics Agency (DLA) and United States 

Transportation Command (USTRANSCOM) and the business processes used to generate that 

data, technologies to collect new data, software to integrate the data, and tools to visualize the 

information. 

C24.3. PROCESS OVERVIEW. 

C24.3.1. Participating activities shall will register pRFID Readers, as specified below per the 

guidance in paragraph C24.4, for the purpose of identifying the location of the Reader. 

C24.3.2. Once registered, scanned tag reads shall will be reported either by a DoD system or 

middleware to the Defense Automatic Addressing System (DAAS) using the Visibility Transaction 

which provides both the pRFID tag and Reader identification. The purpose of this process is to 

associate the tag identification and location with previously transmitted logistics transactions 

containing pRFID, e.g., DLMS Supplement (DS) 856S, Shipment Status, and Federal Defense 

Transportation Electronic Business (DTEB) Implementation Convention (IC) 856A, 

Receipt/Shipment, Consolidation/Due-in Notice, and any others defined in the future. 

C24.3.3. If the middleware fails to associate the tag with a previously transmitted logistics 

transaction DS 856S and Federal or DTEB IC 856A, the activity will may ask for a follow-up Federal 

IC 856A and DS 856S by sending by sending a Visibility Transaction to DAAS with Action Reader 

Function Code of F (Follow-Up), and DAAS shall transmit a Visibility Response transaction 

containing the data elements defined in C24.9. 
C24.3.4. There are three transactions1 to support this process; one is used for sending 

Reader Registration data, a second for sending Visibility data, and a third for DAASC to respond 

to inquiries for unmatched tag reads. The transaction details are covered in the following 

paragraphs. 

C24.4. READER REGISTRATION PROCESS

C24.4.1. The Reader Registration transaction is applicable to handheld or fixed pRFID 

devices for the purpose of identification of its location and role in the supply chain. The term 

“READER” refers to a specific Reader, group of Readers, or all Readers at a site, depending on 

how a specific site chose to register its Readers. 

 C24.4.2. The registering site shall will provide to DAAS the location registration data, 

described below defined in Table C24.T.1., via the site’s middleware application (Savi Site 

Manager, Globe Ranger, etc.) or via the worldwide web (to be determined). DAAS shall will

establish that Reader in a location table and assign a location control number. The location 

control number shall must be used on every subsequent transaction sent to DAAS from the field. 

C24.4.3. After a Reader is successfully registered, sites are responsible for can updating

point of contact (POC) information and deleting the Reader when no longer required. POC 

information is for restricted use and shall will not be displayed in routine queries. Only registered 

Readers can be updated or deleted. A previously deleted Reader cannot be re-registered with the 

same location control number nor can it be updated. 

 C24.4.4. Anytime a Reader or group of Readers is updated changed, moved, or retired, the 

site shall must send the update transaction to DAAS using the same location registration 

transaction with a delete in the action taken field. If the Reader or group of Readers is just being 

updated changed or moved and will be used at a different location, the Reader or group of 

Readers, after deletion, shall be registered again and receive a new location registration number. 

C24.4.5. Registration actions which are not successfully processed by DAAS shall will be 

rejected and a response sent with the applicable reader registration action code. 

C24.5. READER REGISTRATION DATA REQUIREMENTS. Passive RFID Reader Registration, 

whether conducted via transaction exchange or on-line, shall will encompass the data 

requirements identified in Table C24.T1. 

 

1 The schema files (XSD) can be viewed at: 

 http://www.dla.mil/j-6/dlmso/elibrary/TransFormats/formats.asp
Table C24.T1. Passive RFID Reader Registration Data Requirements

Element Description Man/ 

Opt/ 

Con2

Minimum 

Lgth 

Maximum 

Lgth 

Values 

RFID 

Location 

Control 

Number (LCN) 

DAAS-assigned upon 

initial registration: 

required in update and delete;

blank in the establish 

option

C 16 16 From site to DAAS: 

- Blank for initial 

registration request 

- LCN for update 

requests 

From DAAS to site: 

- LCN 

Reader 

Registration 

Action 

Describes purpose 

of registration 

action or DAAS 

response to the 

registration action 

M 2 2 From Site to DAAS: 

E-establish reader 

U-update reader info 

D-delete reader 

From DAAS to Site:

CE-establish reader 

confirmed 

CU-update reader 

confirmed 

CD-delete reader 

confirmed 

NE-establish reader 

not accepted 

NU-update reader not 

accepted 

ND-delete reader not 

accepted 

Reader Type Location’s reader is 

fixed or mobile 

M 1 1 F = Fixed 

M-= Mobile 

Reader ID 

Number 

Number assigned to 

this reader or group of 

readers by the site 

M 10 10 

Location DoDAAC, CAGE, Water 

Port or Aerial Port code 

for this location 

M 5 6 

Location Text Further description of 

this location 

O 1 50 Free form text; 

Possible entries would 

be Area xxx, Bldg. xxx, 

Post xxx, Door xxx 

Type of 

Location 

Code location is using 

to report by to identify 

type of location 

M 1 1 D = DoDAAC 

V = Cage Code 

A = Aerial Port 

W = Water Port 

 

2 “Man” means “Mandatory;” “Opt” means “Optional;” and “Con” means “Conditional.” 
Element Description Man/ 

Opt/ 

Con 

Minimum 

Lgth 

Maximum 

Lgth 

Values 

Effective 

Date/Time 

Date/Time reported 

action took place 

M 12 12 ZULU 

CCYYMMDDHHmm 

(example: 

200612051459) 

Latitude Latitude of this location M 4 9 CRIF3 or degrees, 

minutes, seconds, and 

direction 

Longitude Longitude of this 

location 

M 4 9 CRIF or degrees, 

minutes, seconds, and 

direction 

POC Name 

and Other 

Information 

Name and other 

information of POC at 

site 

M 20 100 

POC 

Commercial 

Telephone 

Number 

Commercial telephone 

number of POC at site 

M 10 15 

POC DSN 

Telephone 

Number 

DSN telephone number 

of POC at site 

M 7 7 

POC E-Mail 

Address 

Email address of POC 

at site 

M 10 50 

C24.6. VISIBILITY TRANSACTION PROCESS. 

 C24.6.1. When a shipment with pRFID arrives, departs or is observed at a registered Reader 

location, the Reader shall will communicate with the middleware, which shall send the Visibility 

Transaction to DAAS with a Reader Function Code of A (Arrived), D (Departed) or O (Observed). If 

the Reader has an assigned role (e.g., receiving or shipping) the transaction shall be used to will

report that action (e.g. arrived or shipped departed) using the appropriate action codes. If the 

device cannot determine arrival or departure, the action code for Observed shall will be used. 

 C24.6.2. At those sites electing to provide pRFID support for local deliveries, use the new 

Reader Function Codes in Table C24.T2. For local delivery with pRFID, the reader shall either 

record a delivery event or an undelivered (e.g., attempted delivery) event. Delivered is defined as 

the customer accepting the material from the shipping entity. Undelivered is defined as during 

normal operating hours and at no fault of the shipping entity, a shipment is not able to be 

delivered. When a local delivery with pRFID is delivered or undelivered using a mobile handheld 

Reader, the Reader information shall be uploaded to the middleware at the home base, which 

shall send the Visibility transaction to DAAS with a Reader Function Code of X (Delivered) or U 

(Undelivered/Attempted Delivery). 

 C24.6.3. If the middleware fails to associate the tag with a previously transmitted logistics 

transaction, the activity will ask for a follow-up by sending a Visibility Transaction to DAAS with a 

Reader Function Code of F (Follow-Up). 

 C24.6.4. Valid Visibility Transactions shall will be accepted and stored in DAAS. Visibility 

 

3 Enter “CRIF” for undisclosed locations. 
Transactions from non-registered readers or with an invalid location control number shall will be 

returned to the sender with an ‘N’ in the sending location action indicating the transaction had an 

error and was not recorded at DAAS. 

Should the middleware fail to associate the tag with a previously transmitted DS 856S, 

Shipment Status , and/or Federal IC 856A, Receipt/Shipment, Consolidation/Due-in Notice, the 

activity may ask for a follow-up Federal IC 856A and DS 856S by sending a Visibility Transaction 

to DAASC with Action Code of ‘F’. If DAAS does not have the information, the sender will receive 

with an ‘N’ in the sending location action indicating the corresponding DS 856S or Federal IC 

856A transaction was not recorded at DAASC. If DAAS does have the Federal IC 856A or DS 

856S, the appropriate transaction will be sent to the requestor.

C24.7. VISIBILITY TRANSACTION DATA REQUIREMENTS. Passive RFID Visibility Transactions 

shall must contain the data requirements identified in Table C24.T2. 

Table C24.T2. Passive RFID Visibility Transaction Data Requirements

Element Description Man/ 

Opt/ 

Con 

Minimum 

Lgth 

Maximum 

Lgth 

Values 

Passive 

RFID Tag 

Tag ID Value M 50

24 

50 Expressed in 

hexadecimal 

RFID 

Location 

Control No. 

DAAS assigned 

during the registration 

process 

M 16 16 

Reader 

Function 

Code 

Describes process 

associated with this 

Reader 

M 1 1 From site to DAAS;

A – Arrived 

D – Departed 

O – Observed 

F – Follow-up 

X – Delivered 

U – Undelivered/ 

Attempted Delivery 

From DAAS to site:

N – Not recorded for A, 

D, O, and F, (when no 

856A or 856S exists 

for the tag); DAASC 

will send 856A and 

856S in response to 

the “F”

Tag Read 

Date/Time 

Date/Time reported 

action took place 

M 12 12 ZULU 

CCYYMMDDHHmm 

(example: 

200612051459) 

C24.8. VISIBILITY RESPONSE TRANSACTION PROCESS. 

 C24.8.1. If the middleware fails to associate the tag with a previously transmitted DS 856S or 

DTEB IC 856A, the activity will send a Visibility Transaction to DAAS with a Reader Function Code 

of F (Follow-Up). 
 C24.8.2. If the requested information is found, DAAS shall transmit a Visibility Response 

transaction containing the data elements defined in paragraph C24.9. 

 C24.8.3. If DAAS does not have the information, DAAS shall transmit to the sender a 

Visibility Response Transaction with an ‘N’ in the Reader Function Code field indicating the 

corresponding DS 856S or DTEB 856A transaction was not recorded at DAASC. 

C24.9. VISIBILITY RESPONSE TRANSACTION DATA REQUIREMENTS. Passive RFID Visibility 

Response Transactions shall contain the data requirements identified in Table C24.T3. 

Table C24.T3. Passive RFID Visibility Response Transaction Data Requirements

Element Description Man/ 

Opt/ 

Con 

Minimum 

Lgth 

Maximum 

Lgth 

Values 

RFID Location 

Control No. 

DAAS assigned 

during the 

registration process 

M 16 16 

Tag Read Date 

Time 

Date/Time reported 

action took place 

M 12 12 ZULU 

CCYYMMDDHHmm 

(example: 

200612051459) 

Reader 

Function Code 

Describes process 

associated with this 

Reader 

M 1 1 From DAAS to Site;

F – Follow-up 

Information 

N – No Information 

Found 

If N, the conditional 

fields will not be 

populated. 

Passive RFID 

Tag 

Tag Identification 

Value 

M 24 50 Expressed in hexadecimal 

Shipment 

Notice Type 

X12 Transaction 

Type Code 

M 3 4 If F, enter “SHIP” 

If N, enter “NONE” 

Document 

Number 

Requisition Number C 14 14 

Suffix Requisition Number 

suffix 

C 1 1 Populated only if 

Document No. has it 

Transportatio

n Control 

Number 

TCN from Shipment 

notice 

C 17 17 

Shipment Date Date/Time from 

Shipment Notice 

C 12 12 ZULU 

CCYYMMDDHHmm 

(example: 

200612051459) 

NSN/Part 

Number 

Stock Number/Part 

Number cited in 

Shipment notice 

C 13 15 

Ship Quantity Quantity Shipped 

cited in Shipment 

Notice 

C 5 9 
C24.10. DATA STORAGE PROCESS. 

C24.10.1. DAAS shall will store both the Reader Registration transaction and the passive 

RFID Visibility Transaction, in addition to the already stored “R table” data. 

C24.10.2. All error-free Visibility Transactions arriving at DAAS shall will be stored upon 

arrival for approximately 7 months. 

 C24.10.3. All error-free device registrations shall will be stored until the a Reader 

Registration Action value of “D” (Delete Reader) is received by DAAS in a Reader Registration

transaction ‘cancelling’ the device. is received.

 C24.10.4. Figure C24.F.1 (next page) is a diagram which provides a summary of the general 

transaction process flow between a passive RFID system and DAASC. 
Passive RFID Data Flow (Between Site and DAASC)

 

Figure C24.F1. Passive RFID Data Flow 

Passive RFID Server 

System/ 

User

DAASC 

 Middleware 

To DAAS

Visibility 

Transactions 

DB 

Tag Data 

Passive RFID 

Reader 

To DAAS

Reader 

Registration 

Transactions

From DAAS

Visibility 

Response 

Transactions 

From DAAS

Visibility 

Transactions