The capability to track and trace items accurately in a timely manner is becoming a critical requirement for many industries. This may be required whenever there is, for example, a quality alert and medicines or a particular model of a car need to be recalled by the manufacturer. In this case, the manufacturer must identify the location and status of all affected batches accurately and quickly so that the recall process can be started without any delay.
Before a report can be prepared for a batch or a handling unit, forward or backward genealogy (a bottom-up or top-down where-used list) of the batch or serial number needs to be found out to detect the other batches or serial numbers that are affected. Once the affected batches are found, different reports can be run on them to find their status.
One of the common challenges for companies is that the data related to batch movements often remains distributed among various systems. Sometimes, companies have multiple instances of SAP systems. Sometimes data related to batch movements is tracked partially through non-SAP systems and partially through SAP systems. To make the situation more complex, it can be a combination of all these scenarios. Therefore, it becomes a manual job to combine data from different systems and find out the genealogy. Additionally, sometimes some specific company-specific custom business process causes a gap to be created in the genealogy. It takes manual effort to bridge the gap. It also takes manual effort to combine batch data and handling units in such reports.
SAP Global Batch Traceability (GBT) can receive data from multiple SAP and non-SAP systems. While importing data from these different sources, you can apply organization-specific logic to link them. From SAP ERP Central Component (ECC), SAP GBT mainly receives three types of information:
- Organization data: The active plants are transferred to GBT from ECC through a Remote Function Call (RFC) as business partners.
- Batch where-used data: The batch where-used data is obtained from ECC by using an RFC connection. In ECC, where-used data is kept in a CHVW table. Therefore, whatever movements are captured in the CHVW table are transferred to SAP GBT. Additionally, all movements that involve storage location change or stock type change are picked from an MSEG table. All objects related to these movements, such as purchase order, material document, sales order, or delivery, also are transferred to SAP GBT through RFC connections.
- Master data: Various batch- and batch movement-related master data (e.g., material, batch, batch classification, vendor, customer, address, class, or characteristic) is transferred from ECC to SAP GBT through an IDoc.
From a non-SAP system, SAP GBT can access information through SAP Process Integration as IDocs.
We now explain how a company in the pharmaceutical industry implemented SAP GBT.
Case Study of GBT Implementation by a Company in the Life Science Industry
A pharmaceutical company decided to implement SAP GBT. The company had already been using an ECC system for a long time. It had the requirement of producing traceability reports for two purposes:
- To identify the affected batches and their location in the event of product recall
- To produce the reports for any batch as requested by different regulatory agencies
Before SAP GBT came into the picture, the company had built software based on Visual Basic that was used to fetch data from SAP tables and produce reports from them. This software used to take a very long time to produce every report, and it was not easy to maintain. The company also had requirements around forward and backward genealogy, so it decided to implement SAP GBT.
For an issue batch, the company had an objective of accounting for the whole quantity of the issue batch. Therefore, a batch might be:
- Used for producing another product
- Converted into a different batch
- Delivered to a customer
- Stored in a warehouse
- In the work in process (WIP) stage in which it has been issued for production but the corresponding product has not been received
- In in-transit status in which it has been sent from the sending plant but has not been received at the receiving plant
The company needed to be able to report the above aspects of the issue batch and batches obtained from the issue batch (i.e., forward genealogy). Before the system could report the above aspects, it was necessary to establish correct forward genealogy for the issue batch. The company had specific requirements around genealogy and wanted to design a set of business processes using the standard SAP GBT solution and a set of enhancements around that, including the following:
1. Intercompany stock transfer: The company was transferring stock from the plant of one company to the plant of another company through a purchase order and sales order. The purchase order was created at the receiving plant, and the sales order was created at the sending plant. The purchase order number was mentioned in the Purchase Order field at the header level of the sales order. At the sales item level, a corresponding purchase item was also mentioned. Because these connections were not considered by SAP in creating the where-used list, this link was also not created in SAP GBT. Therefore, an enhancement was done to link the batch in sending the plant to the batch in the receiving plant. Business Add-In (BAdI) /GBT/EX_IL_EVENT_ENHANCE was used to develop this enhancement.
2. Return deliveries: The company had a process of receiving batches returned from customers to a plant or storage location that was different from the one from the batch to the customer was sent. This process created a problem as these returned batches could in turn be sent to some other customers. Because there was no link between a batch in a dispatch location and a batch in a return location, standard genealogy created by SAP GBT could not include a batch in the return storage location. Therefore, an enhancement was done to link the return delivery document item to an outbound delivery document item with the same ship-to party, sold-to party, material, and batch. Another implementation of BAdI /GBT/EX_IL_EVENT_ENHANCE was used to develop this enhancement.
3. Removal of the fully reversed link from the genealogy: The company had the requirement that fully reversed links should be removed from the genealogy. If a batch was issued to a production order and then the goods issue document was cancelled, the net issue quantity for the batch to process order was zero. This was considered as a fully reversed link. Per the company’s requirement, the product of the process order should not appear in the forward genealogy of the issue batch. Therefore, simplification IDs and filtration and aggregation view ID were configured to remove the fully reversed links. Through a simplification ID, we wrote a condition to select the fully reversed links. We used this simplification ID in the filtration and aggregation view ID to remove the selected links from the network view.
4. Event tie for stock transfer order: When batches were sent from one plant to another plant using a stock transfer order, it was done against an outbound delivery created against the stock transfer purchase order. Batches were then received at the receiving plant against an inbound delivery created against the outbound delivery. Therefore, SAP GBT created the link as a batch in sending plant > Outbound deliver item > Purchase Order Item > Batch in receiving plant.
Now, if multiple batches are sent against an outbound delivery item for a batch split item, and multiple batches are received in the receiving plant, a problem happens with genealogy. For example, suppose batches A and B have been dispatched against an outbound delivery item and those batches have been received in the receiving plant. Now per the links in SAP GBT, both batches A and B in the sending plant are connected to two delivery items (batch split items). Both the delivery items are connected to a single purchase item, and the purchase item is in turn connected to both the batches in the receiving plant. As a result, if somebody wants to find the forward genealogy of batch A in the sending plant, both batches A and B in the receiving plant appear. This process is shown in the diagram in Figure 1.
A batch split scenario for stock transfer
To resolve this problem, we created an event tie between the batch split delivery item and the batch in the receiving plant. The event tie is a feature of SAP GBT that connects an issue batch and a receipt batch for multi-batch scenarios. We used the feature and populated event ties for a stock transfer scenario through a custom report. The custom report is running periodically to find newly created entries for the stock transfer and is creating event ties for them. This process is shown in Figure 2.
Creation of an event tie for a batch split scenario
5. An additional event for subcontracting scenario: The account assigned subcontracting orders were created at the pharmaceutical company with reference to a CO production order. As a result, the goods receipt made for the purchase order was not stock relevant. Therefore, to receive the produced batch into stock, an enhancement was in place in ECC to create a movement type 521 against the purchase order. When these movements reached SAP GBT, they looked like the process diagrammed in Figure 3.
Account assigned subcontracting order
The component batch issue and non-stock relevant goods receipt were connected to the CO production order in SAP GBT. The stock relevant receipt was connected to the purchase order. Because batches were being tracked at the storage location level in SAP GBT, the non-stock batch (a batch with blank storage location) and stock relevant batch (batch with a storage location) were different. The subsequent movements happened from the stock relevant batch. As a result, all these movements were omitted from the forward genealogy of the issue batch.
Therefore, an additional event linking the CO production order and the stock relevant batch was created. BAdI /GBT/EX_IL_EVENT_ENHANCE was used to develop this enhancement. This process is diagrammed in Figure 4.
Additional link for account assigned subcontracting order
With the correct genealogy in place, the following reports were developed:
1. Inventory: There was a standard report available that shows inventory details only for input batch. The custom report was aimed to find all available stocks of the issue batch and forward genealogy batches of the issue batch at different locations across different company codes. The report accepted one or multiple batches as input. Then it found forward genealogy for the input batches. For all the input batches and their forward genealogy batches, the report found stocks available at all locations. The stock details involved a special stock indicator for quantities available in a different stock type (unrestricted, quality, blocked, and restricted)
2. Distribution: There was a standard report available that showed limited details about the deliveries. Therefore, the custom report was developed. The report was aimed to find all ship-to parties that had received the issue batch or forward genealogy batches of the issue batch. The report accepted one or multiple batches as input. Then it found forward genealogy for the input batches. For all the input batches and their forward genealogy batches, the reports found all existing deliveries. The details of the delivery included delivery number, quantity, ship-to party, sold-to party, and contact details of the ship-to party as available in delivery and current contact details
3. WIP: The report was aimed to find all WIPs of the issue batch or forward genealogy batches of the issue batch. The report accepted one or multiple batches as input. Then it found forward genealogy for the input batches. And then for all the input batches and their forward genealogy batches, the reports found the process or subcontracting order where the issue batch or one of the batches present in forward genealogy had been issued but a goods receipt for the process or subcontracting order had not been made. It also found all in-transit stocks for plant-to-plant stock transfers and displayed them.
In this way, all the locations and customers where the issue batch or forward genealogy batches may exist were found out. To be sure, however, the entire quantity of the issue batch and its forward genealogy batches needed to be accounted for. Other types of movements such as scrapping, physical inventory movements, and issue to cost center also needed to be considered to tally the quantity. So, a custom bottom-up use report was developed.
4. Bottom-up use: The custom report was designed to show all receipt movements with quantity for the issue batch and its forward genealogy batches. For receipt movements the report considered goods receipt from a process or purchase order, initial stock movements, return delivery movement, physical inventory movement (write on), and batch conversion movements. All goods issue movements including issue to delivery issue to process order, physical inventory movements (write off), issue to cost center were included. This report was developed by enhancing features of standard bottom-up report available with the product.
All these reports together can identify affected batches and locations where the affected batches are located. As these reports can be produced much more quickly, the process of recall can be started and reporting can be submitted to regulatory authority without any delay.