The Differing Supply Network and Unmatched STOs and STRs in APO

Table of Contents: Select a Link to be Taken to That Section

Executive Summary

In SNP, there is an issue with mapping stock transport orders desired to be made in ECC but not planned in APO.
The approach explained in this article is often recommended by SAP consultants but works against APO’s normal functioning.
This is an issue that dovetails with stock redeployment.

Preparatory Reading

Please see this article for those unfamiliar with transportation lanes or those that need a refresher, please see this article.

Our References for This Article

If you want to see our references for this article and other related Brightwork articles, see this link.

Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.

This is published by a research entity, not some lowbrow entity that is part of the SAP ecosystem.
Second, no one paid for this article to be written, and it is not pretending to inform you while being rigged to sell you software or consulting services. Unlike nearly every other article you will find from Google on this topic, it has had no input from any company's marketing or sales department. As you are reading this article, consider how rare this is. The vast majority of information on the Internet on SAP is provided by SAP, which is filled with false claims and sleazy consulting companies and SAP consultants who will tell any lie for personal benefit. Furthermore, SAP pays off all IT analysts -- who have the same concern for accuracy as SAP. Not one of these entities will disclose their pro-SAP financial bias to their readers.

Background on Planning Versus Execution Location to Location Movements

On the surface, it can seem straightforward how transportation lanes are created in APO. The basic concept is that any valid location-to-location combination is set up as a transportation lane. Source of supply can be controlled with either quota arrangements (75% of demand over a particular time interval sourced from location A, 25% sourced from location B) or priorities (location A as a primary source of supply, and location B as a secondary source of supply). I will not get into multi-sourcing with the SNP optimizer because it’s a distraction, but I cover this article’s topic.

The Importance of Incorporating Reality Into a Design

The previous paragraph, however, makes an important assumption and omits important information. This omission type is almost universal in all published information on APO (except for the SAP message boards such as SNC.SAP.COM where people facing problems in the field tell the real story). The omission which I am referring to is that the functionality described above is available to companies — if and it is a big if – they are willing to put in the considerable work to maintain all of the master data necessary to enable the functionality. It certainly sounds logical that the company would be willing to do this because it wants the desired functionality, right?

Well, it’s not that simple.

SAP has created a complex and high-maintenance set of master data objects that make up the transportation lane. A transportation lane is made up of a variety of master data categories. They are all part of the APO transportation lane but are also their objects. In just one of the transportation lane master data categories (the Means of Transport Transportation Lane) – combined with an externally determined master data object, there are 77 fields. Transportation lanes were not designed to be efficiently implemented or easily understood – they were designed to offer the maximum functionality and allow SAP to say “yes, we can do that” during the sales process.

The Complexity of the Transportation Lanes

The complexity of transportation lanes encourages many companies to minimize the number of transportation lanes they must maintain. For instance, many companies want to plan from one set of locations but then change the locations that are the source of supply in execution. They want to create confirmed stock transport requisitions (from deployment) from location A to destination B in APO) and eventually create stock transport orders from location B to destination C.

This is not the only example of a discrepancy in the area of locations. Even within APO, there can be differences between locations. For instance, some companies place forecasts on to locations within the DP, which is different from how the supply will eventually be sourced. The demand planning department does not “care” where the product is sourced from (A or C), only that it is fulfilled from some location. Location B, in this case, may not even be a “real” location.

There can be several reasons for the design above. Not only are transportation lanes significant maintenance, but more locations for DP means more characteristic value combinations (CVCs), which means more hardware space and more processing. Companies can reduce the number of CVCs by not forecasting non-essential locations. This is a weakness in general with APO. The maintenance effort required to represent reality fully is too overwhelming, so various shortcuts are often taken to reduce this overhead.

The Problem With the Design

While the design seems reasonable at first blush, unfortunately, APO is not designed to work this way. APO is designed to have an STR created along a transportation lane and then either create a matching STO along the transportation lane or receive an STO from ECC along the same transportation lane. If the STO and STR do not match across the transportation lane, then errors will result.

How this Topic Dovetails with Redeployment

Interestingly I ran into a similar issue several months ago related to mismatched STRs and STOs and discussed the topic in good detail with another APO resource. The question is mainly a subcategory of creating STOs in ECC along transportation lanes that do not match STRs created in APO and the problem with reconciliation. Redeployment is a planning thread that does not exist in SNP (although it does exist in SPP), and most companies that implement SNP have at least some redeployment needs.

Redeployment is explained in the following article.

This is part of a larger topic which is covered in a future book titled “Multi Method Supply Planning in SAP APO,” and I include only a small snippet of the overall topic in this article to show the reoccurring issue of unmatched stock transport orders and STRs in a variety of areas.

I have included a quotation of the other APO resource from this discussion below:

“In order to reflect an externally determined or manually created redeployment, redeployment stock transport orders are necessary between DCs. This means transportation lanes must be set up in SNP in order for stock transport orders to come over from SAP ERP to SAP APO / SCM. This is true if STOs are created in SAP ERP. In fact, the CIF —which moves STOs from SAP ERP to SAP APO / SCM—will not be able to bring STOs over to SAP APO / SCM that are created in ECC.”

Go to top

Conclusion

Issues with maintaining transportation lanes and other categories of master data promote companies to take shortcuts and leave out things like locations and transportation lanes from their APO models. When this happens, there is a discrepancy between not only the master data of the supply network between APO and ECC but also a discrepancy in transactional data – as, for example, STRs that are created in APO – result in stock transport orders that are created in ECC on different transportation lanes. This creates a reconciliation problem because APO is designed to have matching STRs and stock transport orders on transportation lanes. This problem of mismatched supply networks and mismatched STRs and stock transport orders relates to many processes in APO. Increasingly I am finding that mismatched supply networks are quite common designs on APO projects and that they bring many challenges.