Skip to end of metadata
Go to start of metadata

In the process, discrete, and repetitive manufacturing industries, occasional oversights can result in finished products that are defective. The Batch Traceability and Analytics ES bundle enables businesses and plant personnel to analyze and find the root cause of the faulty materials in these products quickly and easily across the entire supply chain without logging into multiple enterprise and plant systems or modules that track the parameters and flow of materials and products. It also provides the capability to trace batches by going beyond company IT boundaries. Once a defective or corrupted batch is discovered, business and plant personnel can recall the defective batch (if has been supplied to customers) and return any remaining raw materials to suppliers (if the supplier is the source of the defective material).

The visibility and flexibility these services enable when troubleshooting is extensive. Users can drill down step-by-step from any vantage in the batch network to investigate related plant inventories, laboratory analyses, and information about the movement of stock, within and across company boundaries. Data related to all phases of the manufacturing process is accessible on demand, from raw-material vendor, to manufacturer, to distributor. Users can analyze the complete life cycle of a product as well, including how corrupted batches were made and the relationships between them and their affiliated stock transfers and sales, and production orders, both inbound and outbound.

Available data can be as general as noting whether a corrupt batch came from in house or from a third-party supplier. Alternatively, it can be as specific as detailing the precise stages of production in which a material was used in any given batch, along with the amount used and the ambient humidity at the time of production.

Finally, once the source of the problem has been determined, users can deploy the bundle's services to withdraw the defective batch before it generates further complications, allowing companies to be proactive in handling such issues.
The benefits provided by the Batch Traceability and Analytics ES bundle include:

  • Batch tracking across the entire corporate landscape, through all phases of production and warehousing
  • Integration of SAP ERP 6.0 functionality with relevant shop floor automated systems
  • Means to safely quarantine corrupted batches
  • Support for legal requirements such as Good Manufacturing Practice (GMP), as well as for defect tracking, call-back activities, and regression mandates
  • The ability to broadcast batch information to a third-party system to enable cross-company batch tracing across the entire supply chain
  • The ability to search through documents that have been archived
  • The ability to, given a batch identifier from a supplier, find the company's own batch identifier and vice versa, helpful for tracing batches back to suppliers

Batch Traceability and Analytics (click to enlarge)

The Batch Traceability and Analytics ES bundle leverages Enterprise SOA through the use of enterprise services that enable communication with SAP ERP 6.0, manufacturing execution systems, and, with the help of SAP MII, historian databases.


All businesses that use batch-oriented procedures in the process, discrete, and repetitive manufacturing industries will benefit from this bundle.

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

How To Use This ES Bundle

The Batch Traceability and Analytics ES bundle was created to meet an obvious need: to rapidly locate the source and cause of faulty materials in batches of products identified as defective. Furthermore, companies must be able to recall those corrupt batches from anywhere in the corporate landscape and they must be able to inform customers who have purchased such materials. They must also be able to quarantine faulty batches pending a final solution.

Until now, this has not been possible for the simple reason that businesses have not had a clear view into all the systems that must be integrated to provide this information. To successfully trace a batch, a solution must provide visibility into the following systems:

  • SAP ERP 6.0, so that materials can be traced back to a defective source if needed and forward to customers so that they can be notified of the batch's status
  • Quality management systems, so that issues related to the batch's inspection and any quality issue notifications can be examined
  • Shop floor systems, including manufacturing execution systems and historian databases, to get a complete view of the manufacturing of a given batch and to trace all its elements to determine exactly what is defective

SAP's current solution, the Batch Information Cockpit, does not provide this cross-system visibility and, without enterprise services, the required integration is very time-consuming (in fact, SAP is planning to release an application based on the functionality of the services in this bundle; see Future Directions). The current solution does provide visibility into the manufacturing stage, but it is limited. For example, the current Batch Information Cockpit is unable to integrate with manufacturing execution systems or the historian database that provides connectivity to the myriad shop floor automated systems commonly used in today's plants. As a result, access to such basic information as the production schedules for a given product may remain closed to those company personnel working with material lists, and vice versa. More critically, it may be that while creating a food product, for instance, the system on hand was unable to record and store the behavior of vital process parameters such as time cooked, temperature, and ambient humidity. All of these factors must accord with strict specifications if the finished product is to meet established standards for quality and value. For troubleshooting teams to resolve a crisis, they must be able to confirm that such standards have been met. The services in the Batch Traceability and Analytics ES bundle enable companies to gather all this information.

Quality management processes have remained opaque, as well. For instance, whereas information may have been recorded during inspections and consequently used to generate quality issue notifications, it is still unavailable to users in real time because the current solution has not been integrated with quality management systems. Moreover, in many cases, available data has not been aggregated with related objects in the SAP ERP 6.0 backend. Inspection logs containing results that may be critical to a given tracking process are just one example of the many types of data that have remained difficult to obtain without great trouble and expense. The Batch Traceability and Analytics ES bundle provides the services necessary for examining the quality management data that is so important to proactively tracing defective batches.

The enterprise services in the Batch Traceability and Analytics ES bundle are designed to enable troubleshooting teams to quickly and efficiently track the lifecycle of an unsatisfactory product, determine the responsible culprit, and then quarantine it until a solution has been found.

Furthermore, as of Enhancement Package 4, slated for delivery at the end of 2008, a number of services in this ES bundle will be enhanced to allow companies to search for documents that have been archived, providing additional flexibility when tracing batches through the system. Services that will provide an option for searching or reading archived documents include:

The services in this ES bundle provide visibility both within an organization as well as back to suppliers and forward to customers. Another enhancement package 4-related feature of this ES bundle is its ability to associate a supplier batch identifier with the company's own batch identifier. The Read Batch service supplies both of these identifiers; the Find Batch by Elements service can accept a supplier's batch identifier as input to the service.

A third-party solution, discussed in use case 3, could enable cross-company batch tracing across an entire supply chain. The services in this ES bundle allow companies to participate in such a system, which further extends the reach of companies and their ability to trace batches throughout a product's lifecycle.

This section will explore a series of use cases for the Batch Traceability and Analytics ES bundle. Each use case 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 reusability 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. Please note that the use cases may refer to people invoking enterprise services directly. This helps illustrate how business processes relate to enterprise services flow, but in fact, the services are invoked through a user interface or via program-to-program communication. This wiki is also a space for you to share knowledge and collaborate with others who are implementing the Batch Traceability and Analytics ES bundle.

Use Case 1: Tracing a Customer Complaint with Regard to a Batch

The customer service representative for a manufacturer of cocoa has just received a complaint from a customer that buys cocoa for use in its chocolate bars complaining that all of the bars made in a two-day period are defective because of a problem with the cocoa. The customer identifies the defective cocoa as coming from a particular sales order. The customer service representative invokes the Read Sales Order_V1 service operation, provides details about the sales order, including the relevant batch information. Having found the batch numbers, the customer service rep then invokes the Read Batch enterprise service, which returns batch characteristics and their master data. This enterprise service uses the Identified Stock business object.

Helpful Tip

The business object for a batch is called Identified Stock

Trace the Batches

Now that the customer service representative has determined that the candy bar maker bought seven total batches of cocoa, the production or quality manager can begin to find out exactly which among those batches are corrupt. First, she needs to learn where the batches came from and what other ingredients were added to them. If in her initial investigation the manager sees that the batches in question were tagged by an inspector with a quality issue notification and that the batches were inadvertently sold because of an oversight, for example, she can immediately change the status of the batches to "restricted" by invoking the Change Batch service operation, which uses the Identified Stock business object. At this point, the batches will have been safely quarantined pending a final solution.

On the other hand, the manager may not be able to trace the cause of the defect so easily. In this case, she must drill down still deeper into the production process by invoking the Find Batch Genealogy Register Predecessor by Batch service operation, which uses the Batch Genealogy Register business object. This service enables the manager to investigate all batch-relevant objects such as stock transfer orders, goods receipts and issues, and the like. Any one of these objects may contain data that would point to the nature of the problem.

Check Information from the Shop Floor Systems

Through communications with SAP MII (an optional component of this bundle that is required if integration with historian databases is needed), this service can fetch details related to process parameters associated with the cocoa's production from shop floor systems. These details may include associated ingredients, cooking temperatures, cooling times, on-site barometric details such as ambient humidity, and so forth. It is worth noting here that although the Batch Traceability and Analytics ES bundle can be deployed without SAP MII, businesses must use it if they intend to integrate with shop floor systems.

The manager also looks into the quality management systems to review any quality issue notifications and inspections relating to this data. She looks for quality issue notifications by invoking the Find Quality Issue Notification Product by Elements service operation, which uses the Quality Issue Notification business object. The manager looks to see if any quality issue notifications about this batch or its ingredients were issued; such a quality issue notification could explain the source of the problem.

She also reviews inspection data for all ingredients used in the defective batches of cocoa. The cocoa and all constituent ingredients should have undergone inspection prior to being shipped. The Find Material Inspection Basic Data by Elements enterprise service operation returns the results of these inspections in the form of inspection logs.

Once the manager has compiled a list of all relevant inspection logs, she can drill down into the minutia associated with every single batch of each ingredient by invoking the Read Material Inspection Subset Operation Activity Result and Finding service operation, which uses the Material Inspection business object. As a result of her analysis, the manager has found something that explains the source of the corrupt batches of cocoa and hence of the defective candy bars, as well. It turns out that the preservative added to the batch came from a supplier in a country that provides cheap goods, but which has been recently in the news for shipping low quality-products. This preservative is the source of the problem. The manager then quarantines the batch by invoking the Change Batch enterprise service and setting the batch's status to restricted. She then uses the Find Batch Genealogy Register Successor by Batch enterprise service to find what other batches the defective ingredient was used in and quarantinee all those batches as well. The problem is now contained; all batches have been quarantined. But the work isn't done yet.

How Much of Our Inventory Is Affected?

Now she must trace the batches into inventory so they can be pulled from inventory. The manager must first determine their inventory positions by invoking the Find Inventory by Location and Material service operation, which uses the Inventory business object. To locate the corrupt batches that were in fact packaged into handling units, the manager can invoke the Read Handling Unit, Read Handling Unit Batch Assignment, or Find Handling Unit By Batch service operations, both of which use the Handling Unit business object.

Where Have Defective Batches Been Shipped?

Before the batches can be quarantined in the other companies, the manager needs to see a list of sales orders associated with all pertinent outbound deliveries. She can view this list and execute other related queries by using a variety of service operations, including Read Sales Order_V1, Find Sales Order Item Batch Data by Batch, Find Outbound Delivery by Batch, Read Outbound Delivery, and, so she knows who at each customer location to tell, Read Customer Relationship Contact Person.

Where Did the Bad Ingredient Come From?

In addition to executing the aforementioned functions as they related to the corrupt batches of cocoa, the manager must also execute them as they relate to the defective preservative that was added to the cocoa, which was purchased from another vendor. Additionally, she must examine a list of all purchase orders and inbound deliveries related to the defective preservative. The service operations to be invoked for these processes include Find Purchase Order by Seller and Product and Organisational Data, Find Purchase Order Item by Batch, Read Purchase Order, Find Inbound Delivery by Batch, Read Inbound Delivery, and, to find details about who to contact on the vendor side, Read Supplier Relationship Contact Person.

Use Case 2: Tracing a Customer Complaint with Regard to a Handling Unit

In the previous use case, a cocoa manufacturer inadvertently sold corrupt batches of cocoa to a manufacturer of candy bars. Because the cocoa contained a defective preservative, the candy bars manufactured with it have gone stale prematurely. Fortunately, the candy bar manufacturer noted this flaw early in the process and was able to quarantine most batches of the defective bars before shipping. Several batches, however, were shipped to their distributor as part of handling units, and now the distributor has contacted the manufacturer to inform them of the situation. The only difference between this use case and the previous one is the point of reference for the complaint. The last use case dealt with a complaint about a sales order; this use case describes the same process as it applies to a complaint about a handling unit.

A handling unit consists of goods and packing materials. Handling units have associated batch information so that products can be traced after they have been packaged. Figure 1 illustrates the concept of a handling unit. In Figure 1, HU stands for handling unit. Each handling unit has a unique scannable identification number that follows a standard such as EAN 128 or Serial Shipper Container Code (SSCC).

Figure 1. Handling Unit Example (click to enlarge)

The first action taken by the quality manager at the candy bar manufacturer will be to locate the stock-transfer orders that list all of the questionable handling units shipped to the distributor. He can do this by invoking the Read Handling Unit service operation, which uses the Handling Unit business object. Once he has located the pertinent stock-transfer orders, he will then cross-reference the handling units listed on them against the batches they contain. To do this, he can invoke the Read Handling Unit Batch Assignment, which also uses the Handling Unit business object.

Since in the previous use case the manager at the cocoa factory was able to determine the specific batches of defective cocoa that were shipped to the candy bar maker, along with the respective sales and purchase orders, the quality manager at the candy bar maker needs only check the list of batches in the handling units against the list of corrupt batches of cocoa to determine which among them the warehouse manager ought to quarantine. To view the purchase order that lists the corrupt batches of cocoa sold to the candy bar manufacturer, their quality manager can invoke the Read Purchase Order service operation, which uses the Purchase Order business object. The manager now knows which batches of candy were made with the corrupt batches of cocoa and can cross reference them against the batches of candy shipped to the distributor via the handling units in question.

Use Case 3: Cross-Company Batch Tracking

So far the use cases we've described provide batch traceability throughout a company's plants and warehouse locations as well as forward to customers and backward to vendors. But today's supply chains are often long and complex and in fact many companies may be affected by the need for batch traceability. In this case, third party software is needed to provide cross-company batch tracking.

Each company has its own unique batch numbering system. By reporting their batch numbers to a third-party solution provider, supplier and customer companies can correlate their batches as they move through the supply chain, enabling cross-company batch tracking. If all partners in a supply chain use this third-party system, visibility across the entire supply chain could be achieved in this way.

One of the most common difficulties that businesses encounter when deploying opposing systems is how to reconcile the batch numbers associated with a product in one system with different batch numbers for the same product in a second system. For example, when the cocoa vendor sells a batch to a manufacturer of candy bars, it tracks that batch using an exclusive batch number. Because the candy bar manufacturer deploys a different batch numbering system, however, it receives this incoming batch and subsequently tracks it using its own unique batch number.

To protect against error-generating discrepancies and ensure that both shipping and receiving parties can trace the same batch with equal facility, each company's system needs to broadcast the appropriate data to a third-party system that stores and links the two respective batch numbers.

When the vendor ships a batch of cocoa to the candy bar manufacturer, for instance, it simultaneously propagates the name of the company to which it has sent the batch, as well as the batch number and any other related data, to the third-party system. It does so by invoking the Inform of Outbound Delivery Creation service operation, which uses the Outbound Delivery business object. On the other hand, when the candy bar manufacturer receives that same batch of cocoa from the vendor, it too simultaneously propagates all related batch data to the same third-party system by invoking the Inform of Inbound Delivery Creation service operation, which uses the Inbound Delivery business object.

By the same token, should either company decide to cancel an order or shipment, or to change the parameters of an order or shipment, such as the number of batches, they would notify the third-party system by invoking the appropriate service operations. To cancel an order or shipment, either company would trigger the Inform of Outbound Delivery Cancellation or the Inform of Inbound Delivery Cancellation service operations, which use the Outbound Delivery and Inbound Delivery business objects, respectively. To change an order or shipment, either company would trigger the Inform of Outbound Delivery Change or the Inform of Inbound Delivery Change service operations.

Whenever the third-party system receives notice of such cancellations or changes, it automatically updates its systems, ensuring that should cross-company batch traceability be required, the data is up to date. All data sent by both vendor and manufacturer is stored in the third-party system and is subsequently available on demand to all companies involved in the supply chain.

Future Directions

In the future, this ES bundle may be enhanced with additional services. In addition, SAP plans to create an application that uses these services to provide a productized batch traceability solution and obviate the need for companies to create their own user interface to the services in this ES bundle.


The Batch Traceability and Analytics ES bundle achieves connectivity between ERP and the shop floor through SAP MII. Thousands of shop floor systems, including logistics inventory management systems, plant data historians, plant maintenance systems, control systems, quality management, and manufacturing execution systems can be connected with the backend in this way. SAP MII communicates with ERP using services.

SAP MII is a powerful composite application (xApp) that is capable of extracting data, transforming it, and visualizing it. This gives SAP MII the ability to consume manufacturing services as well as enterprise services. It can be used to fetch trend data or tag value, for instance.

Another advantage to SAP MII is that it does not require constant connectivity to ERP. SAP MII can buffer data-from a day to a week's worth of orders-and retain those values until a connection is established again. This opens the possibility of round-the-clock operation, which is a critical advantage in today's competitive manufacturing businesses.

System Requirements

Related ES Bundles

End-to-end Processes Where This ES Bundle Is Used

SOA Homepage on SDN

Wikipedia's page on Good Manufacturing Practice

1 Comment

  1. Unknown User (fd45n26)

    We have multiple process centers in our company that machine place small electrical components onto serialized circuit cards which are then assembled into higher level serialized assemblies. Most of these components are so small that they don't have part number, date code, or lot marking. Many are packaged on trays or reels for the convenience of machine usage. These parts are backflushed automatically and multiple lots could be in use on different machines at the same time. The parts are almost always warehouse managed but the build levels are not until final assembly. We have a requirement to track date/lot codes for some of these parts, from the point of receipt through multiple levels of build to final customer, whether machine placed or hand placed. We are looking for suggestions on how to accomplish this in SAP.  Please contact Jackie Seals at or 319-295-3582.