Production and transportation form two important parameters for supply chain efficiency of a consumer packaged goods company. Production constantly reacts to changing demand conditions across different nodes in a supply chain network, factoring various parameters such as inventory levels, production and transportation lead times, changeovers, and production lot size requirements into consideration. In today’s scenario, demand volatility is highly pronounced due to a variety of reasons. Therefore, production schedules are constantly changing even within the short term, to keep up with different supply chain objectives.

The two important aspects of transportation planning include lane and mode. The transportation lane is a supply chain construct that connects a source location with a destination. The mode represents the means of transport, such as truck, rail, ship, air or multi-modal. From a planning perspective, it is important to lock on to a specific lane and mode early, based on inventory positions, production volume, and mix, for greater price flexibility.

While transportation management is not pliable at the last minute, it is possible to project a certain number of trucks based on a production forecast, both in terms of volume and mix. I explain how a dummy stock keeping unit (SKU) can be used to raise requirements of transportation load in terms of mode and lane. The requirements can eventually be replaced with a set of SKUs that is finally produced, thereby making optimal use of available transportation resources. This approach works in the specific context of low production schedule adherence. Although I do not address the causes of low adherence, it could be intrinsic to the industry or organization. I describe how to factor this parameter into the overall transition process from planning to execution. SAP APO provides a platform to align shipment planning with the production planning process.

The Dummy SKU Process

In many instances, specifically typical of consumer packed goods, stock transport orders (STOs) have to be generated in advance of actual production of goods. The STOs represent the shipments planned from the source plant to destination distribution centers. A logical shipment load can be tendered and a carrier can be planned and negotiated with a third-party logistics provider.

For the following reasons, production planning variations (plan versus actual) can happen:

• Raw material or components that are shelf-life sensitive may exist for a SKU that may have to be executed even though the SKU is not planned for production. The scheduling tool may not have visibility to this SKU.
• A production or packaging line for a specific planned SKU may have an unscheduled maintenance, while the labor force could be used on a different production line
• Quality concerns on a specific SKU might require re-producing the SKU, thus disrupting the original schedules.
• Limited warehouse space availability at the producing plant may result in a need to adapt the execution of the schedule.
• Schedule “inserts” due to high priority sales orders may disrupt the planned production schedule.

In such instances, a dummy SKU that is not sold to the end customer is usually used as a placeholder to create STOs in advance. These orders exist in the SAP ERP Central Component (ECC) system and contain important information relevant for warehouse and transportation. It is also possible that there are different external third-party tools used by companies to manage warehouse and coordination with third-party transportation service providers.

An external tool carrying information relevant for execution would also have such information classified in terms of valid STOs in the SAP system. In essence, STO numbers established via the planning process carry important information that cannot be deleted and re-created with new STO numbers because there are different stakeholders involved in the process. To facilitate the warehousing and transportation process, the STO number should not be changed and has to be maintained and preserved even when the actual production schedules do not conform to the original production schedule forecast.

Thus, production of SKU volumes and mixes completely different from those initially forecast at the time of transportation planning is very normal in such situations.

Following are some leading standard options within the SAP system to consider:

• Leverage standard transportation load building (TLB) within SAP Supply Network Planning
• Create STOs in ECC beforehand and manually manage updates to STOs

A custom option that my team additionally considered is to have planners create STOs in ECC using dummy SKUs and then programmatically update the STO based on a TLB simulation. I describe this approach and explain why it is the best in the context of production variability.

First, I walk you through the two standard options listed above.

Standard TLB and Some Deficits

In standard TLB, the load mix is arrived at with the latest position of inventory or projected inventory based on a production schedule. The standard TLB further considers a variety of parameters, such as floor spots, volume, and weight, to arrive at the optimal transport load.

There are some deficits related to using the standard TLB option. First, the standard TLB is interactive in nature, requiring the deployment planner planning the transports to interactively change parameters and check which option works best in terms of load construction. This can be a disadvantage given that 80 percent of loads, for example, could have been automated, requiring no manual intervention based on different constraints imposed on the system. This may be an advantage for those business situations in which planner intervention is mandated prior to execution.

Second, what comes out of TLB is a brand-new STO established in ECC. This STO does not contain any information outside the process that the planners may have used to understand the exact transaction details, such as bill of lading, the actual third-party transportation provider details, and any other warehouse-relevant loading requirement. Therefore, the connection between the old STO containing such information and the new STO coming from TLB is lost, leading to a lot of manual touches.

One way to overcome the deficit described in the section above is to manually update the STO based on a simulation of TLB done interactively. The deployer would then have to manually pick up the SKU list along with the volume and other information and enter that information into a pre-existing STO created in ECC with a dummy SKU. Depending on the number of transports being planned daily, such a process can be convoluted and also prone to many manual errors.

A Custom Approach to Doing TLB Using Dummy SKUs

The following custom approach to doing TLB using dummy SKUs describes how a simulated result of TLB in the background can be used to update a preexisting STO using a Remote Function Call (RFC) to ECC.

Figure 1 describes the sequence of steps that are executed to complete the custom approach.

Figure 1

Custom approach to how the dummy STO update can happen based on simulation TLB

I now explain how each of the steps in Figure 1 works.

Step 1. The deployer may have a two- to three-day window to create STOs based on the visibility of the production schedule, which may not materialize in the context of low schedule adherence. The dummy STOs are created with unique pre-specified dummy SKU numbers. The STOs are transportation documents within SAP containing information such as from and to location, start and end date of transportation, and the means of transport, such as truck, rail, ship, air or intermodal relevant from a planning perspective. Such an order may be established in any external transportation management tool and contain pertinent execution level information, such as bill of lading or the details of the third-party transportation service provider. This order is created well prior to the actual execution of the production scheduler. It is a kind of placeholder for transportation for pre-negotiated rates, assuming that last-minute arrangement of transportation may be costlier than planning in advance by two or three days, or any other window typical of the industry.

Step 2. ZSNP042 is a wrapper around standard SAP transaction /sapapo/SNP042. The SNP042 standard SAP transaction has the option of doing simulation without saving results into live cache. Figure 2 shows what the screen for what a ZSNP042 wrapper looks like. To display this screen, execute custom transaction code ZSNP042.

Figure 2

Custom SNP042 transaction for doing TLB simulation based off of a dummy SKU

There are three fields in the Z transaction:

• The Dummy SKU in STO field specifies the dummy SKU with which placeholder STOs are created in ECC that could subsequently be replaced with the real SKUs relevant for execution.
• The Simulate check box is used to help pause the results after TLB simulation, with an option to go ahead and update the ECC STO carrying dummy SKUs. This is specifically relevant when executing the transaction in interactive mode.
• The TLB Table Update check box is used to update the results of ZSNP042 in a Z table for tracking purposes. This is useful for troubleshooting while deploying the solution.

Step 3. There is a capability in the Z tool to update the results of ZSNP042 to store in a temporary table for tracking and matching purposes.

Step 4. Based on the dummy SKU specified in the front end of ZSNP042 (i.e., the availability dates, modes, and materials specified in ZSNP042), a display is created on the exact matches of shipments proposed by the Z transaction and the pre-existing STOs in ECC (Figure 3).

Figure 3

A matching report of simulation of SNP042 and STOs existing in the ECC system

The report shows a list of the following items:

• Shipments proposed by the custom transaction that have a match in terms of placeholder STOs in ECC with the same mode, start location, end location, start date, and end date
• Shipments proposed by the custom transaction that have no match in terms of placeholder STOs in ECC with the combination of mode, start location, end location, start date, and end date
• The STOs that exist in the ECC side that have no matching shipment proposed by the custom TLB transaction

Step 5. The report that can be executed potentially in simulation mode helps an interactive deployment planner to understand the different possible matches between custom transaction proposals and pre-existing STOs in the ECC system with dummy SKUs. After the report is viewed and analyzed, it is possible for the interactive deployment planner to take the next steps in terms of adjusting different parameters of the pre-existing STO in terms of dates or creating new placeholders for new destinations or modes. The planner thus can run the report in execute mode and the following things would happen:

• The dummy SKU in STO in ECC will be replaced with the simulation results of the Z transaction. A deletion indicator will be placed against the dummy SKU in the order in ECC, and the new list of materials with the right quantities will be created as a new line item record, inheriting attributes from the header in terms of scheduling dates.
• After the RFC to ECC successfully updates the STOs, the existing deployment confirmed orders have to be decremented accordingly. This is done by leveraging SAP code in SNP042. If this is not done, you will have a double supply situation in which you have STOs along with deployment confirmed orders.

For tracking purposes, the results of simulation are logged into a table as shown in Figure 4.

Figure 4

Logging table for simulation results of the custom TLB

Development Objects to Support Auto-TLB Using Dummy SKUs

In this section I explain the different sets of development objects relevant to support auto-TLB using dummy SKUs.

The first development object is aimed at creating a wrapper around the SNP042 transaction, called ZSNP042. As specified above, you have to add a few more fields in the layout for additional functionalities. A copy of the standard transaction needs to be created for selection of data in addition to the standard one. When the transaction is executed in update mode, you want to default the selection to update the Z TLB simulation update. The code changes to the standard TLB transaction to extend new parameters and default behaviors are shown in Figure 5.

Figure 5

Code changes to the standard TLB transaction to extend new parameters and default behaviors

The logic of the selection of valid STOs via RFC that qualify into the report output based on the dummy SKU value in the Z transaction front end is added to the selection logic as shown in Figure 6. Execute transaction code SE38 to display this screen. 

Figure 6

Logic to select and update STOs in a remote system

FM ZMM_OPEN_PO_UPDATE is created in ECC and is also remote enabled. Based on whether the call is simulation based or not, there is logic added to update the STO. The logic in the Z function module is to select a set of open STO documents qualifying a list of criteria that are not delivered yet. Execute transaction code SE38 to display the logic inside the Z function module in ECC to update the STO document (Figure 7).

Figure 7

Excerpt of logic inside the Z function module in ECC to update the STO document

The standard business application programming interface (BAPI) BAPI_PO_CHANGE may be used to change the STO based on the outcome of the Z transaction simulation. The Z transaction for TLB would also have the logic to add records into a custom table for tracking or reporting with the logic described in Figure 8.

Figure 8

Records are logged into a Z table for further tracking purposes

The deployment orders converted to TLB have to be adjusted or deleted as the case may be. Recall that the Z transaction being executed is done in simulation and there is an RFC update to adjust the STO in ECC. There is pre-existing logic in the standard SNP042 transaction that can adjust the deployment orders based on running the transaction in update mode. That piece of logic would now need to be forced to execute when the RFC update to STOs happens in ECC. The outline of the logic is described in Figure 9. FM SAPAPO/MSNP_TLB_ORDER_CHANGE can be further used inside the Perform statement to adjust deployment orders.

Figure 9

Deployment orders converted have to be deleted

You can have a simple logic to adjust or purge entries in table ZTLB_SIMULATION based on how far in the past you want to preserve the entries of TLB simulation.

Other Configurations Relevant in the Solution Context

In some instances, such as the one for which this solution was specifically built, there may be a strict requirement to build trucks based off stock-on-hand instead of planned production elements. In such instances where there is warehouse space in the production facility, you could make sure that the goods receipt (GR) time is kept greater than 0. GR time in the product master is thus a kind of buffer time to accommodate variations in the production schedule. A larger value in GR time indicates higher variance of production planned versus actual. However, having a GR time in the product master does not prevent inventory from being received earlier than scheduled from the production line. This setting complements the strategy around flexible outbound shipment planning and scheduling from the production facility. You also need to ensure that the TLB profiles defaulted in the transportation lanes are relevant and tuned to the requirements of floor spots, volume, and weight parameters recommended for specific mode-lane combinations. This needs to be iterated and figured out using interactive mode.

The Z transaction can be background enabled to ensure that as many trucks as possible are built in automatic mode. The few trucks that are left out in terms of the right parameter combination can be logged and reviewed by the planner or you could wait for the next day for more production stocks to be available in the production warehouse.