Transactional Track-and-Trace


Jim Clark
Microsoft Corporation

August 2005

Applies to:
   Enterprise Architecture
   Solution Architecture
   Radio Frequency Identification (RFID)

Summary: This paper addresses the influence of Radio Frequency Identification (RFID) technology on consumer goods and products, manufacturing, retail, and supply chain processes. Jim Clark discusses the impact of improved process and product visibility as well as several approaches used to improve the visibility of goods and services in supply and value chains with focus on the transactional based approach. (10 printed pages)

Click here to download the Microsoft Electronic Product Code (EPC) Information System Demo.


Target Audience
The Approaches
Transactional Track-and-Trace Scenario
For More Information


This paper is the second installment in a series of articles addressing Radio Frequency Identification's (RFID) impact on consumer goods and products, manufacturing, retail, and value chain processes. Here I introduce the impact of improved process and product visibility; specifically, the several approaches used to improve the visibility of goods and services within supply and value chains with the focus on the transactional based approach. I will develop the implementation details in a downloadable EPCIS demo and upcoming papers. The demo is based on industry standard schemas and will include scenario overviews, technical requirements, a user manual, and a security document.

Target Audience

The target audience for this document is:

  • Business clients from Consumer Packaged Goods (CPG) manufacturers.
  • IT Managers from CPG manufacturers.
  • Application developers doing RFID-related applications.


In any decision making process, decisions depend on the availability and accuracy of key information. In the case of business, much of this information is provided by and shared among partners, manufacturers, distributors, retailers, and agents. Keeping this information fresh, accurate, and available is a key challenge for many businesses and enterprises.

As manufacturers introduce new products, they have to share the product information with the downstream distributors and retailers. A retailer has to constantly share its forecast, which is based on many factors such as seasonality, price, promotions, and advertising. An enterprise's departments and organizations must keep the state of goods and services flowing through their internal processes. These include elements such as identification, status, location, and custody.

In all traditional approaches, the information to be shared is placed in a centralized database that keeps the current state of products and services on a case-by-case basis, even if this was just a markerboard or spreadsheets. This information is provided through on-demand queries and notifications of status change. With the advent of modern distributed systems and services and architectures such as the Business Collaboration Framework1, business can now share information across their supply/value chains using distributed transactions.

The Approaches

Microsoft recommends several approaches to help partners and customers realize this information-sharing opportunity. Better information sharing provides greater visibility into the process and helps align the process with the real time status of the goods or process. Such visibility helps the business decision maker (BDM) with forecasting, management, compensation if things go wrong (renegotiation), and so forth.

Centralized Track-and-Trace

If you have ever been referred by a customer service representative to a product shipper, who then refers you to a transport or trucking company, which has no idea where the truck transporting their product is, you can relate to the frustration of not have shipping status readily available. Track-and-trace information provided in a centralized service improves this transport process visibility and product delivery status. Having one place where consumers, agents, or shipping receivers can see the status of the product shipment gives them confidence that their goods will be delivered on time and in good condition.

This approach relies upon a global centralized service that is updated by shippers and their agents. It stores a unique identifier, called an Electronic Product Code (EPC), which acts as a license plate, pointing to more information of the tagged item stored in a database. This provides a globally synchronized registry of products, identification numbers, and codes providing a product line lookup service, similar to Internet DNS servers. For a given equipment product code and tag number it would return a universal resource identifier (URI) that could be later queried to get more info about the product. This registry is updated when new products are released and consulted by retailers and distributors when a product arrives with an unknown code.

The server that provides this product information is called an Electronic Product Code Information Service (EPCIS). A supplier provides identification, locality, and status information to the EPCCIS in order to enable track-and-trace functionality. This information is stored into a hosted repository. In order to optimize this process, users can maintain a localized cache, allowing partners to query each other for the current status and reducing network congestion. If the information becomes stale or out of sync the local EPCIS resynchronizes using the central system.


Figure 1. GDS Architecture

Transactional Track-and-Trace

While a centralized track-and-trace service greatly improves visibility into the process, there are two specific issues that crop up: inaccurate data and unintentional sharing of private information. Both of these undermine customer confidence. Errors can occur, as periodic updates by transport agents may lag behind customer queries. Private information access vulnerability comes from storing information from multiple customers concurrently within a potentially common context. This can and does expose private and confidential information to incidental and deliberately inappropriate access risks.

Both of these issues can be mitigated. In the case of the latency and accuracy, rather than using a querying of shipment status approach, the use of a proactive event-driven-notification approach provides optimal timing of updates to readily detect and correct inaccuracies. I call this approach transactional track-and-trace. In the case of information access, using transactional track-and-trace allows for information rights management. By pushing the information, rather than having it queried, we can make sure that only the relevant parties get their relevant information. Yet, this approach still lets us share public information.

Rather than keeping synchronized with a centralize source, transactional track-and-trace provides an architecture and approach to facilitate business state alignment among the various parties involved on a process-by-process basis. The difference between track-and-trace and traditional querying systems is that a traditional system may or may not update a database (say through RFID tag readers located throughout the value chain), which must then be queried to find information. If there is a problem, for instance, you would not discover it until you ask the system. In track-and-trace, the system pushes the data to you as the transactions occur. This ensures that the state of the business process and the information remain synchronized. In the event of an error, such as a missed delivery, the responsible party can take corrective actions as soon as he or she is notified.

Localized, distributed agents/servers maintain state and status. Shipment status/state is maintained by event forwarding, and queries compensate when state misalignment occurs. For instance, if you received notice that your product left the warehouse, but you did not receive the product, you could then query the system. From this query you could determine the problem and then re-align our states. If we had a service level agreement (SLA) that specified penalties for late delivery, then we would determine the problem and realign our states (you now owe me a penalty).

Privacy is protected because only you and the relevant parties in the value chain would be able to see the information relating to your transactions. Tracking the process locally also minimizes latency in updates and facilitates business decision making at higher business process levels. For example, it may be important for a store manager to know where the merchandise is for accounting and inventory purposes, but it is also important to have visibility into the process and accurate lead times for things like forecasting and advertising.


Figure 2. Architecture supports higher level decision processes

Transactional Track-and-Trace Scenario

Here, I will describe an approach for implementing an EPC event information sharing system in the value chain to enable track-and-trace. This scenario deals with ABC Corp, a manufacturer of gaming consoles, which dispatches goods from a manufacturing distribution center (DC) to a retailer. The goods dispatched from ABC Corp to the receiver go through the value chain as shown in Figure 3.


Figure 3. The ABC value chain

The case or pallet loads arrive at ABC's Distribution Center (DC) from the import point without RFID tags. Goods are tagged at both the case and pallet level with a Global Trade Item Number (GTIN) and Serial Shipping Container Code (SSCC).

On arrival at ABC Corp's distribution center, the tags are scanned and the data is captured for track-and-trace. The cases are then put away.

Picking at the distribution center is done on an order-by-order basis and the goods are shipped to stores on pallets.


Figure 4. Recording pallet information into data depository

Before loading and shipping, the pallets are scanned by an RFID reader (Figure 4). The case and pallet information are stored in ABC Corp's data repository. At the same time, an EPC Information Event is created. This EPC Information Event contains the date and time when the Pallet and the Case EPCs were scanned at the Distribution Center. This event is then dispatched to the receiver for automated notification and is also stored in the data repository.

Information Flow—Manufacturer's Notification

When the goods are ready to be shipped from the manufacturer's premises to the receiver, the following information flow takes place (Figure 5):

  1. EPC information related to the goods ready to be shipped is saved to the local data repository at the manufacturer's premises.
  2. A notification request for shipping goods is sent to the shipping agent.
  3. The shipping agent saves the notification information to its local data store and sends back an acknowledgement for the "receipt of notification" to the manufacturer.
  4. The manufacturer saves the acknowledgement to its local data store.


Figure 5. Manufacturer's notification information flow

Information Flow—Shipping Agent Pick Up

When the shipping agent picks up the goods from the manufacturer's premises, the following information flow takes place (Figure 6):

  1. Shipping agent picks up goods from manufacturer's warehouse and updates the local database as "goods picked up by shipping agent."
  2. Shipping agent sends good pickup event to the manufacturer, which updates the local database.

In this step, the data stores of the manufacturer and the shipping agent are synchronized with respect to the track-and-trace status for the EPCs.


Figure 6. Shipping agent picks up information flow

Information Flow—Shipping Agent Delivery

When the shipping agent delivers the goods to the receiving agent, the following information flow takes place (Figure 7):

  1. The shipping agent sends the event notification called 'Notification of Goods Shipment' to receiving agent.
  2. The receiving agent acknowledges receipt of notification of goods shipment.
  3. Upon delivery of goods to the receiving agent, the shipping agent updates its local database with "goods delivered to receiving agent."
  4. The shipping agent sends the updated status to the manufacturer. (Example—"goods delivered to receiving agent.")
  5. The shipping agent sends a "goods delivered" event notification to the receiving agent, which updates its local database.
  6. The manufacturer updates its local database with the new status. (Example—"goods delivered to receiving agent.")
  7. Upon receival of goods from the shipping agent, the receiving agent updates the status of the EPCs in its local database. (Example—"goods received by receiving agent.")


Figure 7. Shipping agent delivery agent flow

In this step, the data stores of the manufacturer, the shipping agent, and the receiving agent are synchronized with respect to the track-and-trace status for the EPCs.

Information Flow—Receiving Agent Delivery

When the receiving agent delivers the goods to the receiver, the following information flow takes place.

  1. Upon delivering goods to the receiver, the receiving agent updates its local database with "goods delivered to receiver."
  2. The receiving agent sends a "goods delivered" event notification to the receiver, which updates its local database.
  3. The receiving agent sends notification of "goods delivered to receiver" to the shipping agent, which updates its local database.
  4. The shipping agent sends notification of "goods delivered to receiver" to the manufacturer, which updates its local database.
  5. The receiver updates the status of EPCs in its local database to "goods received."


Figure 8. Receiving agent delivery information flow

In this step, the data stores of all the value chain members are synchronized with respect to the track-and-trace status for the EPCs.

Extrapolation of the Above Scenario to a Real Life Scenario

In actuality, there could be several value chain members interacting with each other as goods move through the supply chain. Figure 9 illustrates this information flow.


Figure 9. Value chain elements sharing information

The EPC information in the respective local data stores is updated when the goods reach a node. This also triggers a sharing of updated status with the previous nodes in the chain. This synchronizes all nodes at each transaction. Notification cascades through the supply chain, giving visibility into the chain. I like to think of this as flipping the chain on its side. So, instead of querying the chain and just getting the status of the last node, I can look at the entire chain, and the state of the last node is an aggregation of the previous nodes' substates. This includes, for example, any renegotiations that have occurred to keep the states aligned.

For More Information

An implementation of this scenario along with source and example code and reference specifications can be downloaded from the URLs referenced below.

Microsoft's Smarter Retailing Initiative

Microsoft's Retail & Hospitality Web site

Microsoft's Smarter Retailing Initiative

Information About RFID Technology:

EPCGlobal Inc.

Value Chain Council

EAN International

1The Business Collaboration Framework is a set of architectures that has been in whole or part adopted by ISO, UN/CEFACT, and RosettaNet to facilitate business transaction and state alignment.