Skip to end of metadata
Go to start of metadata

Item Unique Identification is a policy initiative created by the U.S. Department of Defense (DOD) designed to give all items (such as machinery, vehicles, weaponry, and technology assets) as well as embedded items (which are built in components) globally unique identifiers known as Unique Item Identifiers (UIIs). These unique identifiers can include as many as 50 characters.

These identifiers are assigned to an item and subitem at the time of its production and remain with the item or subitem through its lifecycle until it is scrapped. The identifiers are used as the principle means of identifying items and embedded items within a registry created by the U.S. DOD and carries with them information about the supplier, current owner, and other relevant information for the tracking and managing of items and embedded items.

The Item Unique Identification ES bundle provides enterprise services that allow SAP ERP to communicate with U.S. DOD suppliers and the UII registry system. The bundle also provides connectivity between SAP ERP and third-party systems and applications used by suppliers to administer and consolidate UII information. In short, the bundle enables suppliers to attach a UII to a specific item or subitem as well as engage in the necessary communication of the UII and related information in an automated way.

It should also be stated that IUID policy and functionality has been included within a draft NATO standardization agreement, STANAG 2290, which would extend this initiative to NATO partner countries. IUID could well become a global standard, affecting NATO nations and all related suppliers, providing a far broader scope to the relevance and utility of the Item Unique Identification ES bundle.

Item Unique Identification (click to enlarge)


The Item Unique Identification ES bundle is designed to support adding and maintaining registry updates by both suppliers and the U.S. DOD in three areas:
Registry Communication. The bundle provides the business objects and enterprise services necessary to:

  • Create UII entries
  • Change UII entries
  • Read UII entries
  • Check the existence of UII entries

These services are new and unique to this bundle.

Master Data Maintenance. Business objects and related enterprise services included in this bundle enable users to:

  • Create equipment master records, including UII assignments
  • Change UII assignment of equipment master records
  • Read equipment master records by UII

These services to maintain equipment master records already exist and are enhanced in this bundle in order to support Item Unique Identification functionality and processes.

B2B Interfaces. This bundle provides business objects and enterprise services to support customer-supplier communication of UII assignments and related information, which includes:

  • Sending purchase orders from the customer (military department) and creating a sales order within the supplier's system
  • Changing a sales order based on a purchase order change made within the customer's system
  • Sending Advanced Shipping Notifications (ASNs) that include UII assignments and related information.

These B2B enterprise services already exist and are enhanced either to carry UII information or to carry a flag item from a customer noting to a supplier that UIIs are required for the items and relevant embedded items.

In general, this ES bundle provides enterprise services that provide interfaces between SAP ERP and a third-party UII management application as well as with the U.S. DOD run and maintained UII registry system, with functionality to enable propagating UIIs into the registry system as well as communicating necessary information.

For example, the U.S. DOD is providing a number of technically unique channels for suppliers to feed UIIs and related information into the registry system. These include the ability of a supplier to simply type information in, use a web service, use an electronic data interchange (EDI) interface, or another interface, such as iDOCs.

By enhancing and supporting the interface level with IUID functionality, the Item Unique Identifier ES bundle facilitates handling UIIs in a heterogeneous landscape.

Given that the IUID policy is relatively new, there are likely millions of legacy items (main items and embedded items) that must be fed into the registry. The bundle supports interaction on the U.S. DOD side to create, assign, and feed UIIs for these items into the registry system.

This is handled via the SAP provided monitoring program that assigns a status to all items. The status reflects whether the UII of an item is:

  • generated,
  • physically marked
  • sent to the registry system or is
  • confirmed by the registry system.

In addition, there is a status to reflect that the IUID status is undefined. Therefore, as items are marked with an assigned UII and given the status "physically marked," the U.S. DOD can feed, as a bulk operation, all items with that status into the registry system.

Using enterprise services, the Item Unique Identification ES bundle leverages enterprise SOA through communications between SAP ERP, third-party item unique identification support systems, registry servers, and other specialized components of the related landscape that are used to generate, administer, scan, and print UIIs.

Audience

All defense organizations and affiliated suppliers will find the Item Unique Identification ES bundle essential for creating, finding, reading, modifying, and updating unique item identifiers for the products they make, buy, sell, and use.

For details on Service Operations, Business Objects and Process Components, please check the ES Workplace.


How to Use This ES Bundle

Prior to the initiation of the U.S. DOD's IUID program and the advent of the Item Unique Identification ES bundle, there did not exist an automated way for suppliers to communicate with and feed new information into a centralized registry system. In fact, while disparate systems for the cataloguing and maintenance of serialized items did exist, a universal and comprehensive registry with the capacity to follow an item from the time of its production and delivery to its ultimate decommissioning did not.

It is anticipated that the IUID program will help drive an integrated set of logistics, acquisition, and financial requirements that can be used to track and identify item information throughout the defense supply. In all, a comprehensive registry of marked items will provide accurate and accessible information about items and embedded items to make acquisition, repair, and deployment faster and more efficient.

Essentially, the UIIs will be generated by suppliers and attached to the item at the time of production, or by the owner (i.e., military) in the case of legacy items and attached during maintenance of the items. The UII includes attributes such as price, name, and weight. In all, approximately 50 attributes can be used to describe an item. Importantly, the current holder of the item (for example, DOD, supplier, subcontractor) is an attribute that is attached to all items.

Further, suppliers will also be responsible for creating hierarchies of items and related UIIs. For example, a plane will have a top-level UII followed by all of the UIIs for the mission-critical components such as engines, weapons systems, and etc.

What all of this means, is that not only will military organizations be affected by this policy, but all suppliers to these organizations as well. For this reason, the Item Unique Identification ES bundle is not industry-specific because so many industries must comply with IUID policy.

Therefore, as IUID support is defined by the U.S. DOD - and soon by NATO and its member nations - as an integral prerequisite for many logistical processes, all military organizations and suppliers must incorporate IUIDs into their standard processes. The capability to support a number of registry system interfaces - the crucial link for military organizations and supplier companies - can be solved in an efficient and cost-effective manner using the services in this ES bundle.

Cost Savings. Efficient interfaces to registry systems and web service-based customer/supplier communication that supports UII processing and management provides SAP customers with an easy and comprehensive solution to support required IUID functionality.

Improved Efficiency. Electronic messaging rather than manual processes reduces the likelihood of errors and increases throughput of UII creation, consolidation, and propagation to the registry.

Further, the Item Unique Identification ES bundle plays an important role to support:

  • Providing item visibility regardless of platform or solution owner
  • Supplying item data necessary for top-level logistics and engineering analysis based on registry information
  • Providing an accurate source for property and equipment valuation/accountability
  • Improving access to historical data for use during systems design and throughout the life of an item.

Without electronic interfaces such as those supported by this bundle, companies would be forced to manually type information into the IUID system via a web-based front-end of the registry. Given the length of the identifiers, up to 50 characters, such manual data entry is untenable for all but the smallest suppliers.

This section will explore a series of use cases for the Item Unique Identification ES bundle. Each scenario will show how different outcomes can be achieved by using the enterprise services in different combinations. While these examples illustrate a few of the ways that this ES bundle could be used, the intention is to show the flexibility and re-usability of these business objects and enterprise service operations so that you will have a clearer understanding of how to best deploy them in your own environment. This wiki is also a space for you to share knowledge and collaborate with others who are implementing the Item Unique Identification ES bundle.

Use Case 1: Purchasing Items Marked with UIIs

Whenever a defense organization purchases items from suppliers, it can decide whether it wants those items to be marked with UIIs that can then be submitted to and stored in the IUID registry. The organization will specify not only that an item should be marked with a UII, but also what embedded items should be marked, the hierarchy and attributes that should be included.

This request is made in the purchase order submitted by the military customer to the supplier. The supplier receives the purchase order, converts it to a sales order with the relevant information, the items are produced, marked with UIIs, and then the items are prepared for delivery, at which point the UIIs are fed into the registry.

In this use case, a defense organization wishes to buy 500 personal computers from one of its regular suppliers and would like each of the computers marked with its own UII.

The purchasing agent creates a purchase order in its ERP system. He flags the purchase order item to be IUID relevant and submits it electronically to the supplier by invoking the Request Purchase Order Creation enterprise service, which uses the Purchase Order business object. This service has been enhanced with the flag indicating that the computers being ordered must have assigned UIIs.

B2B Interfaces for Customer/Supplier
Communication to Create a Sales Order
for a Purchase Order
(click to enlarge)


Once the supplier's ERP system receives the purchase order, it automatically creates an accompanying sales order with the UII request flag by invoking the Create Sales Order service operation, which uses the Sales Order business object.
If, for example, after the purchase order has been submitted the customer decides to amend the purchase order in some way - such as increasing the number of computers ordered or adding hardware or some other aspect to the computers - the change can be made in the customer's ERP system and replicated to the supplier's ERP system and included with any UII flags to an amended sales order. The enterprise service invoked on the customer end to support this change is Request Purchase Order Change, which also uses the Purchase Order business object.

B2B Interfaces for Customer/Supplier
Communication to Change a Sales Order
for a Purchase Order
(click to enlarge)


As before, once the supplier's ERP system receives the modified purchase order, it can update the original sales order by invoking the Change Sales Order service operation, which also uses the Sales Order business object.
Once the computers have been produced, the supplier creates the outbound delivery and goods issue and sends an ASN (Advanced Shipping Notice) to the customer. At this point, the system invokes the Notify of Outbound Delivery enterprise service.
The customer's ERP system receives the ASN, which invokes the Maintain Inbound Delivery based on Despatched Delivery Notification_V1 enterprise service. This service creates an inbound delivery based on inbound delivery information, which contains the UII information in the ERP system and refers to the original purchase order.
The following table summarizes these steps and the associated enterprise services.

Step

Enterprise Service Invoked

Step 1: The customer creates a purchase order and sends it to the desired supplier

Request Purchase Order Creation

Step 2: The supplier receives the customer's purchase order and creates a sales order

Create Sales Order

Step 3: The customer modifies its purchase order and sends it to the supplier so that it can update the respective sales order

Request Purchase Order Change

Step 4: The supplier receives the modified purchase order and makes the requested changes to the respective sales order

Change Sales Order

Step 5: The supplier produces the product(s) and creates an outbound delivery and goods issue and sends an ASN.

Notify of Outbound Delivery

Step 6: The customer's ERP system receives the ASN and creates an inbound delivery with UII information.

Maintain Inbound Delivery Based on Despatched Delivery Notification_v1

Use Case 2: Creating Registry Entries for Items Marked with UIIs

Frequently defense organizations are affiliated with suppliers whose products are made from components purchased from second- and third-tier suppliers. As stated earlier, these components are termed "embedded items" and often are required to be marked with their own unique UII and each of these unique embedded item UIIs must be placed in a predefined hierarchy.

For example, an airplane manufacturer will likely build each airplane - the top level item with its own UII - from components - engines, weapons systems, electronic components, and so on - that it purchases from other, second tier, suppliers. While not all of the parts of an airplane will be IUID relevant, characteristics and rules help determine the IUID relevance for any item and embedded item.

These second tier suppliers must be notified when a component is required to have a UII and communicate the UII and related information to the first tier supplier. The first tier supplier will receive the UII and place it in a hierarchy when it assembles the airplane.

When the hierarchy is complete and the plane - usually a shipment of planes - is shipped, the UII hierarchy information is fed into the IUID registry system. The top of the hierarchy is the plane and then followed by the embedded items in order of importance. Further, this information is held in the supplier's ERP system and a bulk service for the registry feed can be used.

Integration of External UII Administration
System and Creation and Changing of
UII-Related Data (click to enlarge)


To begin, upon completion of the sales order for a set number of planes, the first tier supplier creates an outbound delivery, which is a business process used to support all shipping activities such as picking, packing, transport, and goods issue.
Next the UIIs are assigned to the outbound delivery, which includes the hierarchy of embedded items.
Once the UIIs are assigned, a goods issue is created, which is the trigger for the ERP system to feed UII information into the IUID registry. At this point the Request Individual Material Registration enterprise service is invoked, which uses the Individual Material Registration business object.
Initiation of a goods issue also triggers the ERP system to generate an ASN and send it to the customer, which invokes the Notify of Outbound Delivery_v1 enterprise service, which uses the Outbound Delivery business object.
The customer's ERP system will receive the ASN with all relevant UII information, which causes the ERP system to invoke the Maintain Inbound Delivery Based on Despatched Delivery Notification_v1 enterprise service, which uses the Inbound Delivery business object. This service supports the creation of an inbound delivery, which is a business process used to support all of the tasks concerning the delivery process. The inbound delivery also refers back and pulls information from the original purchase order.
Once the airplanes are received at the customer's site, the customer will have received information related to the UIIs that have been shipped, officially receive the items, create equipment information in its system, and reassign the UIIs.

Next, the customer queries the registry system to check whether all items have been registered by the supplier. The customer then requests that the status of the UIIs be changed from "Sent" to "Confirmed" using the Query Individual Material Registration Status enterprise service, which uses the Individual Material Registration business object.

The following table summarizes these steps and the associated enterprise services:

Step

Enterprise Service Invoked

Step 1: The supplier creates an outbound delivery.

(no enterprise service is invoked during this step)

Step 2: At the same time, UIIs are assigned to the outbound delivery.

(no enterprise service is invoked during this step)

Step 3: A goods issue is created and the items are stored in the IUID registry.

Request Individual Material Registration

Step 4: An ASN is generated and sent to the customer.

Notify of Outbound Delivery_V1

Step 5: The customer receives the supplier's ASN and the ERP system creates an inbound delivery that pulls information from the original purchase order.

Maintain Inbound Delivery based on Despatched Delivery Notification_V1

Step 6: The customer receives its purchased items from the supplier

(no enterprise service is invoked during this step)

Step 7: The customer creates equipment information in the system, reassigns the UIIs, and checks to be sure the supplier has correctly entered the UIIs into the IUID registry.

Query Individual Material Registration Status

Use Case 3: Changing the Configurations for UIIs

Defense organizations perform maintenance on various items, which includes removing and replacing various components. Often these components are embedded items with their own UII, which requires amending the parent/child information of that particular UII to reflect that it is no longer a component in another item. When a new component is installed, the parent/child information of its UII must be amended and the UII for the new component added to the hierarchy.

As such, the removed component becomes a top-level item - it is its own entity and no longer a component of an airplane, for example - and the new component's parent/child information must reflect its change from being a top-level item to being an item within a hierarchy of components listed in the IUID registry for that airplane.

In this scenario, the maintenance person working on the engine of a fighter jet has determined that an engine must be replaced. Since the replacement engine has its own UII, once the repair is complete, the maintenance person must submit the change in parent/child information of the UIIs for both the old and new parts in the central registry.

When the old engine is removed, the maintenance person must change its parent/child information in the registry, which invokes the Request Individual Material Registration service operation, which uses the Individual Material Registration business object. When the new pump is installed, the maintenance person must change its parent/child information in the registry, which triggers the Request Individual Material Registration service operation yet again.

Alternatively, the composite application could be designed to automatically invoke these services as part of the normal business process of replacing an engine. See the Maintenance Processing ES bundle for more information about that process.

The following table summarizes these steps and the associated enterprise services:

Step

Enterprise Service Invoked

Step 1: The engine is removed from the airplane. The faulty engine must now be updated in the registry, changing it from an embedded item to a top-level item.

Request Individual Material Registration

Step 2: The new engine must be put in the airplane. As a result, its registration must be changed to reflect that it's no longer a separate component (a top-level item), but an embedded item in a hierarchy.

Request Individual Material Registration

Use Case 4: Creating Master Data Externally

Many suppliers affiliated with defense organizations deploy customized production systems in which they can store the UIIs of the products they manufacture. Later, the UIIs and the master data must be propagated to the sales systems used by the supplier to conduct business with its partner defense organizations, in this case, SAP ERP. This use case includes the following steps:

  1. The production system produces the item and assigns a UII
  2. Using an enterprise service, the production system registers the UII
  3. The production system transfers the master data for the item including its UII to SAP ERP

After a supplier has manufactured an item and assigned it a UII within a production system, for example, the supplier can replicate the UII and all its related data to the IUID registry. In this instance, the production system invokes the Request Individual Material Registration service operation, which uses the Individual Material Registration business object to feed the registry system.

The production system, in an A2A communication, then replicates the UII information to SAP ERP along with information that creates equipment master data. In this step, the production system invokes the Create Individual Material enterprise service, which uses the Individual Material business object.

Now from the ERP side, the supplier checks to ensure that all the UIIs for the new items have been properly submitted to the central registry by triggering the Query Individual Material Registration Status service operation, which uses the Individual Material Registration business object. If the registry system knows the UII and gives a positive answer to the query, the ERP system sets the status of the UII to "Confirmed".

The following table summarizes these steps and the associated enterprise services:

Step

Enterprise Service Invoked

Step 1: A supplier manufactures its products, marks them with UIIs, and assigns the UIIs in the production system.

(no enterprise service is invoked during this step)

Step 2: The supplier feeds the UIIs from its production system to the IUID registry.

Request Individual Material Registration

Step 3: The production system replicates the UII assignment and master data about the items produced to SAP ERP.

Create Individual Material

Step 4: From SAP ERP, the supplier runs a check to ensure the UIIs are stored correctly in the IUID registry and sets the IUID status to "Confirmed"

Query Individual Material Registration Status

Future Directions

All future directions for the Item Unique Identification ES bundle will be based on changes to current standards, as well as on evolving industry requirements.

System Requirements

Related ES Bundles

SOA Homepage on SDN
SAP Community Network BPX community for Defense

IUID within Procurement and acquisition: information from US DOD
IUID Toolkit
IUID Business Forum