How to Understand the Flow of STRs and PRs Through APO with a Custom Deployment Solution

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

Executive Summary

There is a flow of orders through the supply network and order categories in the Planning Book.
When not using the SNP deployment solution, there is a different way of understanding the Planning Book Key Figures.
APO can be integrated into a deployment application when TLB is Performed in APO and when it isn’t.

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 the Flow of Requisitions in SNP

SAP SNP has a standard way of displaying and controlling the flow of distribution demand through the supply network. It does this internally by creating new objects and changing the state of order categories. The stock movements show a series of distribution demands and delivery receipts at each product location in the planning book. For instance, demand at a DC is converted to a distribution demand.

Both of these order categories are shown in a row or key figure in a planning book. The planning book shows demand key figures at the top of the planning book, supply key figures in the middle of the planning book, and stock at the bottom of the planning book.

This is shown in the planning book mockup below, along with what type of order categories are displayed in which key figures.

This is a mockup of the planning book.
The key figures listed above are not all the key figures in the planning book, just the most common ones.
There is an inconsistency in the planning book in that even internal movements are shown as purchase requisitions in the Distribution Receipt key figure at the receiving location. They are shown this way even though they are, in fact, stock transport requisitions. The same stock transport requisition shows a stock transport requisition (not a purchase requisition) as the Distribution Demand key figure at the sending location.

The Flow of the Supply Network, Order Categories, and the Planning Book

Except for at the very top of the supply network (where the forecast and sales orders are entered for distribution centers) and at the production locations (where dependent demand and planned orders are created), stock transport requisitions.

They appear as shown in the spreadsheet screenshot below. Most of the movements between facilities are shown as either distribution demand or distribution receipts (two sides of the stock transport requisition):

As shown in the screenshot above, SNP has a standard workflow, which starts with unconfirmed requisitions, finishing with orders. All of this can happen (although it is just one option) before the orders are sent over to SAP ERP.

However, while this process flow works when standard SNP functionality is used when part of the functionality is not utilized, things change. For instance, some companies cannot meet their requirements with the deployment functionality provided in SNP. See this article on why I consider only the deployment heuristic to be useful deployment functionality in SNP.

When Deployment is Not Used in SNP

The deployment heuristic is a relatively simple approach to performing the deployment. Even still, the deployment heuristic can meet the needs of most companies. The deployment heuristic is entirely disconnected from initial supply planning methods, including CTM and the cost optimizer. This topic can be an area of confusion for those that come from another planning system.

The role of the initial supply plan is to create planned stock on hand. The role of deployment is to move planned stock on hand down through the supply network. The heuristic deployment starts to pick up after the initial supply plan has been created and performs this second step that follows mostly a very different set of rules.

Understanding the Limitations of the Deployment Heuristic

The deployment heuristic works by stock aggregates and cannot see various STRs or PRs, or prioritize individual orders or even order categories.

The deployment also does not use the peggings created in the initial supply plan run, and in effect, destroys these pegging relationships to deploy based on either a push or a pull method.

Method #1: Push

Push means that the planned stock on hand is moved as soon as it is available.

Method #2: Pull

Pull keeps the stock at the sending facility until a criterion must be met at the receiving location (pull) (based upon demand, target stocking level, etc. a ). This does not have to be based on demand. For instance, performing a pull deployment based upon a target stocking level at the receiving location will mean postponing the deployment until the planned stock level. A planned stock level at the receiving location drops below the target, and the deployment, which is created, can meet the minimum lot size requirement.

Prioritizing Orders

If a company wishes to prioritize past due orders or provide a manual category such as “super-priority” to some deployments, there is no way of doing this with the deployment heuristic.

Regarding the geographic flexibility afforded by the deployment heuristic, the deployment heuristic works on a very strict parent to child relationship. Deployments cannot be created based on conditions outside of these two locations.

If a company wishes to make deployment at the first echelon based upon the third echelon’s information, there is no way to do this with the deployment heuristic. There is the ability to perform a customized deployment based on user-defined criteria. Once a company diverges from the fundamental way the deployment heuristic operates. The work required to bring in custom criteria can become more effort than creating a custom deployment application. Some companies also want the ability to control the deployment more manually.

This means some user interface where the STRs and PRs can be flexibly sorted or deselected. The deployment heuristic operates much more like a black box. The requirement for greater visibility into the deployment before confirmation can also drive a company in a custom application direction.

The Following Activity of TLB

Once a company decides not to use the deployment heuristic, use the transportation load builder.

TLB is a first load building application, but it is often one of SNP’s most popular components with SNP users.
From companies that upgrade from ERP, the SNP TLB provides a real load builder, which many users may never have experienced using.
TLB is a bit curious regarding its location because it’s an execution tool sitting in a planning system.

The standard rule that the external planning system only creates recommendations and the ERP system converts recommendations to orders does not apply in this case. In fact, some SAP development decisions cast APO as more of a replacement for many functions previously performed in ERP rather than as a traditional external planning system. This provides more alternatives for companies and projects; however, it also complicates the matter of clearly delineating what happens in APO and what occurs in ERP. The existence of the TLB “application” in APO allows STRs and PRs to control the shipping and be converted entirely in APO.

The Options for Converting Requisitions into Orders

Although there are many options for how requisitions are converted to orders, they can be automatically saved when sent to ERP, allowing all of the planner activity in APO. This is a significant advantage for the following reason:

APO has better views and user interfaces than what is available in ERP. (and of course, many of these views in ERP are stable and no longer being enhanced by development)
Peggings that APO creates can only be checked in APO – they do not display in the Stock Requirements List in ERP. The Stock Requirements List only shows peggings that ERP creates.

The Conversion in TLB

TLB converts confirmed STRs and PRs to STOs and POs (PRs are converted to POs in TLB if the company running APO wants to perform TLB for vendor locations. If not, PRs tend to be turned to POs in ERP) and do so in a way that respects the basic volume and weight limitations of different equipment types.

Once a company decides not to use the deployment heuristic, they must determine whether to bring STOs and POs back into APO to process them with TLB.

The STRs and PRs are essentially converted to STOs and POs in ERP (which can be automated or manually performed) and then deployed based upon a custom application. Once STOs and POs exist, the company can either process them into shipments with TLB or with another custom load building the application (companies have many choices here, including the Ortec, which is fully integrated into APO, or much other inexpensive and quite a good load building programs.)

Go to top

Conclusion

The standard workflow for requisitions in SNP is to have unconfirmed STRs converted to confirmed STRs by the deployment heuristic. The deployment heuristic will most often alter the STRs generated by the initial supply planning run. This is because the deployment heuristic follows a different logic than the initial supply plan methods, which create the unconfirmed STRs.

If the deployment heuristic is found not to meet its deployment requirements, the company must either purchase another application specifically for deployment or create its own. Buying an application would mean evaluating the best breed supply planning applications to determine the best fit with the company’s deployment requirements. But in either case, it means integrating SAP into the deployment solution.

With planned stock positions at all locations and forecasts and another date necessary for decision-making being extracted from SNP. The stock transfer and purchase recommendations that result from the deployment process must be brought back in as confirmed STRs and established PRs, which would appear in the Confirmed Distribution Receipt and Confirmed Distribution Demand key figures of the SNP planning book. TLB could then be run from that point in APO. A second approach would be to perform both deployment and TLB outside of APO. In this case, the ERP system would receive the STOs and POs, which would then automatically be through to APO, validating or adjusting (in the event of a change to an STR or PR date) the planned stock on hand.