How to Best Understand Pegging and Net Requirements in SAP

Executive Summary

• Supply and demand pegging elements are critical to supply planning in SAP.
• This article covers how CTM differs in pegging, pegging in PP/DS, two types of pegging, static/fixed and dynamic pegging, and much more.

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. 

What is Pegging?

Peggings are very important for a variety of reasons. Pegging allows a planner to trace the set of demand and supply connections between different echelons within the supply network, including the initial demand (sales order or forecast), all of the stock transport requisitions, and all of the planned (production) orders, and the purchase requisitions.

One of the reasons that pegging is not as fully featured as it could be in SNP is that pegging is a bit demanding to check one by one. This is why some companies toy with the idea of extracting all of the peggings from SNP and placing them into a report making them easier to extract. However, peggings cannot be easily extracted from APO.

Where is Pegging Stored?

The peggings are not stored in a table (for some strange reason which is not apparent to me) but are stored in liveCache—APO’s memory / hierarchical database. Unlike a table, LiveCache cannot be directly queried. For specific items for which customers have requested information, SAP has created a series of BAPIs (Business Application Programming Interface), which allow the extraction to be performed. However, once extracted, the peggings cannot be directly used with ease but must be filtered through a program that can convert many of the system codes (SYSIDs, etc.) into a format that can be read by humans and placed into some report. Peggings are updated when a supply method is applied. In many implementations, this update occurs nightly. It makes good sense to extract the peggings after this run is complete so that the planners have updated pegging information in their pegging report at the beginning of the day.

Overall it’s a hassle, but there is no other way to get this type of information from the system. For those who are particularly interested in the topic of peggings, the vendor Manugistics makes their peggings easy to obtain in a variety of ways, right within the application, without the necessity for any coding.

The pegging report, which would work off of an extract from SNP, would give the planner a lot of flexibility when checking the peggings. For example, the planner could select all of the peggings that met various search criteria, allowing the planner to much more quickly moves through their activities.

The Pegging Report

The pegging report is shown conceptually on the following page:

Peggings exist in ERP systems as well, as the screenshot above demonstrates. The peggings can be arrived at by selecting a line item and then selecting the pegging button at the bottom of the Stock Requirements List. Peggings that are created inside of SAP APO are not shown in the Stock Requirements List in SAP ERP and vice versa. The pegging view in ERP is designed to show peggings that are created by a procedure (such as MRP) within the ERP system.

Supply Chain Planning Expressed As…

Supply chain planning can be expressed broadly as:

• Forecasting demand
• Managing capacity
• Allocating or pegging demand and orders to capacity

If the company finds itself with an overcapacity of inventory or productive capacity in all or most of its product lines, pegging is not all that important of an issue.

Supply Demand Pegging Description

The book Supply Chain Management with SAP APO has an excellent description of pegging, which goes on to describe how pegging connects order objects at different levels. This is an explanation that is often left out of most evaluations of pegging.

Here is the quote:

Pegging describes the attachment of supply nodes to demand nodes within the order liveCache. A helpful notation for explaining planning situations in the order network is shown in figure 3.10. The basis of this figure is pegging areas that represent a product in a location (a locationproduct). ) orders have a supply node in one pegging area for their output and demand nodes for their dependent demands in other pegging areas. The supply nodes and the demand nodes of one pegging area are connected by pegging.

The figure described as 3.10 goes on to show how stock is associated with production orders, which is pegged to transport orders, which is, in turn, pegged to sales orders. The explanation goes on to say that pegging is an association performed in liveCache following the settings on the demand view of the product master.

Pegging is also covered in the SAP white paper “Production Planning and Detailed Scheduling:

“Pegging is a core feature of SAP APO and key to its ability to synchronize activities across the entire supply chain. In essence, pegging refers to the precise matching of supply to demand and ensures that as changes occur anywhere along the supply chain, those changes can be effectively propagated to all orders that are related to them. By using a pegging network, SAP APO can earmark supplies from the moment they are purchased and forecast their destination through production and fulfillment. Set globally as either a static or dynamic state within SAP APO, you can modify pegging characteristics to best suit their particular manufacturing requirements.”

The Two Types of Pegging

There are two types of pegging; dynamic and fixed. Choosing between the two determines the pegging strategy. Dynamic pegging that the peg is essentially temporary and that if a new request comes in, the pegging can be lost. Fixed means just the opposite; once the peg is set, it does not change no matter how many requests or CTM or scheduling runs are performed. Fixed Pegging has the additional benefit of reducing computational load. This means that either CTP or Detailed Scheduling will take less time and be more responsive under fixed pegging than dynamic pegging.

SAP has the following interesting statements on pegging on their help website:

“If you carry out the ATP check on the basis of the fixed pegging, SAP APO can take the scope of the check and the checking horizon into account in the ATP check.

Until now, dynamic pegging sometimes caused unexpected results during detailed scheduling because the assignments between the receipt and requirement elements were recalculated in every process step. Using fixed pegging, the material flow remains stable. This increases transparency and the quality of the planning result.”

Using Dynamic Pegging

This makes perfect sense. I have recommended against dynamic pegging for some time. A fixed pegging, in addition to keeping the system output more stable, also takes considerably less runtime.

“The pegging structure describes the relationships of orders at all BOM levels, and for sales orders from the receipt elements of the ordered products and the required components, to the receipt elements for the raw materials.”

An interesting comment. I think what SAP is saying here is that the pegging applies from the finished goods throughout the BOM, which, of course, would make sense.

I found this description of pegging at the SAP community network very helpful:

“Usually SNP Heuristic and SNP Optimizer is configured for Dynamic Pegging whereas in case of CTM you normally have Fixed Pegging.  You need to understand the Concept of ‘Pegging’ and See Fixed vs Dynamic Pegging in Product-Location Master Demand View and the Pegging Overview Transaction … to see how your Supply Orders Pegs to what Demand Orders in SCM-APO LiveCache.”

Fixed Pegging in CTM

Yes, this makes a lot of sense—fixed pegging in the main functionality in CTM. Now CTM can be run without fixed pegging or with dynamic pegging as the configuration above demonstrates. However, this makes little sense, and I have not seen CTM configured that way….although I am confident it is configured this way someplace as there are so many CTM implementations and so many ways that CTM is used. CTM is, in many cases, run with no priorities whatsoever (no demand priorities, no supply priorities), which is something that I am not sure CTM’s original developers ever predicted when they conceived of CTM.

This quotation is from SAP Press’s book on CTM.

“The main advantage of CTM planning is the creation of fixed pegging relationships. The planning solution can be easily traced using the fixed pegging created by CTM. SNP Heuristics and the SNP Optimizer lack this capability because they work mainly in bucket-oriented planning mode.”

SAP Quotations on Pegging

“The fixed pegging relationships in SAP APO are retained even after a document change in the SAP R/3 system.(emphasis added) For example, if you have created fixed pegging relationships between a sales order and a planned order, then the pegging relationship to the sales order still exists even after the planned order has been converted into a production order.” – SAP Help

This demonstrates how strong the pegging is

“Fixed pegging is not integrated into the SAP R/3 system, meaning that affected assignments in SAP R/3 between requirement and receipt elements are not created as fixed pegging in SAP APO. You carry out batch determination in SAP R/3. This assignment does not automatically lead to a fixed pegging relationship in SAP APO. For the same reason there is no integration of R/3 collective orders. Conversely, a fixed pegging relationship that you create in SAP APO between a requirement and a receipt element does not lead to an assignment in SAP R/3.”– SAP Help

A System Design Flaw?

This is one of the stranger quotes I can recall on pegging. I can’t figure out why you would design the system in this way. I would prefer it if each system respected the other system’s peggings. I think this is fine in the case of MRP, CTM, and PP/DS pegging as if fixed pegging in CTM and PP/DS is used; MRP would not be run, at least for the same level in the BOM as MRP would be run for. However, I am a bit hazier on the effect of fixed pegging in ATP. So if a fixed pegging is created in SD in ATP, then is this not respected in GATP and vice versa?

Where is Pegging Configured in SAP SNP?

Notice the options of Fixed Pegging and Dynamic Pegging towards the bottom of this CTM Profile screen.

Pegging in CTM

Pegging in the SNP Heuristic

Notice pegging selection is not part of the setup for the SNP Heuristic:

Pegging in the SNP Optimizer

The same is true for the SNP optimizer; I don’t want to show all of the optimizer configuration tabs, as I have already documented them in this article. However, there is no setting to differentiate between fixed pegging and dynamic pegging as there is in CTM, as the optimizer does not perform fixed pegging.

Fixed Pegging is available within these areas of SAP APO”:

• Order receipt in the ATP check.
• Order receipt without immediate confirmation in MRP
• In CTM
• In the Detailed Scheduling

Therefore, for SNP, it exists in precisely one place and just one of the three supply planning methods. For DS, fixed pegging is set in the IMG in the Global Parameters.

MRP is usually not performed in SAP APO (it can be emulated with a PP/DS heuristic), so this MRP confirmation is in SAP ERP.

Pegging in the Product Location Master?

Pegging can also be set in the product location master. You can select Concurrent / Fixed Pegging. Below there is a selection to dynamic pegging, which is highly confusing as this would seem to enable fixed pegging, but then one would not need the Concurrent / Fixed Pegging above.

The result is that pegging does not need to be configured in the product location master for SNP, even though it is shown here (confusing, I know). Pegging is set by the method, not by the product location combination. This is the setting for pegging for PP/DS.

Where Does The Pegging Result Appear in SAP APO?

Pegging can be viewed in the Pegging Overview tab in the Product View.

See the pegging field above that is shows the purchase order being the receipt element and the sales order being the requirement element.

It is also available on the menu.

SAP APO Production Planning -> Interactive Production Planning -> Pegging Overview

The Description of Allocations

Understanding the difference between peggings and allocations is essential. Even though SAP APO CTM is called an allocation engine rather than a “pegging engine.” Pegging is an association created between a demand element and a supply element. All the methods in SNP can perform pegging, but only CTM can produce what is called a fixed pegging. A fixed pegging is essentially not reviewed by the planning procedure again after it is set. This means that only a manual intervention can change a fixed pegging once set. Fixed pegging creates a high degree of stability in the plan. It reduces the runtime of each successive supply planning run as the system has fewer product location combinations to process.

When Demand Exceeds Supply

In cases where the demand or the expected demand exceeds the supply – e.g., because of production limitation due to very high investments – allocations help to ensure that customers or customer groups are provided with their share according to the sales and marketing policies. Generally, allocations prevent ‘first come, first serve’ behavior.

1. Thus pegging is used in SAP SCM to describe a connection between demand and actual inventory.
2. Allocations are used to describe a connection between demand and future inventory.

Although I have to admit, the difference between pegging and allocation seems difficult to accept.

How Does CTM Create Pegging Relationships?

CTM can create a fixed or a dynamic pegging, and this is set in the CTM Profile, which is shown in the screenshot below:

More on pegging can be read in this article.

What Happens When Stock, which is Pegged to a Demand Element, is Deployed?

The pegging created by CTM during the initial supply plan run is relatively straightforward to understand. The pegging, which is created by CTM, is the best pegging of all the methods in SNP.

One critical question is what happens to the pegging relationships after the material is produced, when it turns into stock and when it is deployed. This article describes the somewhat disconnected way that the initial supply plan versus the deployment plan works in SNP.

When a product is produced, its pegging relationship is visible within the Product View in APO. There is a special tab for the pegging in the Product View as can be seen in the screen shown below:

How CTM Differs in Pegging

While CTM is one of the three methods for creating the initial supply plan, it is not a standard method for deployment (some SAP consultants will experiment with using CTM to create a deployment and even redeployment, but I have yet to see one of these designs put into practice or live at a company). CTM allows you to deploy with child locations set as different priorities, which is a way almost no company deploys.

By far, the most common method of deployment in APO is the SNP deployment heuristic. I consider it to be the only real alternative available within SNP for deployment.(read this article for the disagreeable outcomes of the SNP deployment optimizer) however, while CTM is concerned with pegging, the deployment heuristic is not.

The Deployment of Heuristic’s Logic

The deployment heuristic’s logic is based upon a variety of options of either pushing or pulling stock between demanding locations based factors such as the target stocking level, the demand, etc. So the question becomes, “what happens to the pegging relationships created by CTM?” or more specifically, “how does the pegging influence or control the deployment that follows?” The answer is that the pegging is “destroyed” or not respected, depending on how you look at it.

While CTM’s pegging logic is very well thought out for the initial supply plan, there is no relationship during the deployment. However, what has happened because sales orders that were lower priority were rejected, those sales orders do not exist in the system to come and take the stock during the deployment stage.

The Supply and Demand Pegging Elements

Pegging connects up receipts with requirements. These elements are as follows:

Requirements (Demand)

• “Sales orders, deliveries, and SD scheduling agreement schedule lines
• Planned independent requirements or forecast requirements
• Dependent demands or reservations
• Stock transfer requirements
• Safety stocks, if necessary” – SAP OSS Note

Receipts (Supply)

“Production orders and planned orders (in-house production)

Purchase orders, PReqs, scheduling agreement schedule lines (external procurement)

Available stock

Inspection stock”  – SAP OSS Note

Pegging in PP/DS

“You can use the heuristic SAP_PP_019 to create fixed pegging relationships for a single level or for multiple levels starting from the finished product. You define the parameters that control how the system proceeds when creating the fixed pegging relationships in the heuristic settings in Customizing for PP/DS. You delete fixed pegging relationships using the heuristic SAP_PP_011. You can use parameters to define which fixed pegging relationships should be deleted.” – SAP Help

This is very interesting and means that pegging can be controlled as a particular step, which is quite different from how it is used in CTM, where it is merely “binary” that is either fixed pegging is used or dynamic pegging is used. The SAP_PP_019 heuristic is different. It can be “whipped out” whenever a dynamic pegging is required. For instance, it could be the last heuristic run that is performed, or it only may be performed very another run.

Pegging for The Initial or Network Supply Plan and the Deployment Plan?

This is a basic problem with CTM. CTM peggings are only in effect after the network planning run is performed and before the deployment run is performed. CTM is not used for deployment, and neither the SNP Deployment Optimizer nor the SNP Deployment Heuristic can deploy based upon or even see allocations or peggings that are created by CTM during the network/MPS planning run. CTM allocations are destroyed as soon as deployment is run in APO. They also cannot be seen or used by ERP.

Transactions for What SAP ERP Calls Pegging

The following transactions relate to pegging in ECC.

• MD09: Pegging Requirements
• PEG01: Collective Process Pegging
• PEG15: Transfer Pegging

Net Requirements Versus Pegging in SAP ERP and SAP APO

It’s good to get into the definition of net requirements calculation and to compare it to pegging.

Here are some interesting points on each.

• Net requirements can be seen as a comparison between supply and demand but is not a specific connection between and supply element.
• Net requirements only tell you if you are over or under your requirements concerning planned inventory. It cannot tell you, as MRP does not create specific connections between demand and supply, as other supply planning methods do.
• In SAP APO, at least, the pegging sophistication differs by the method employed. CTM can perform fixed pegging, whereas the SNP heuristic and the cost optimizer can only perform dynamic pegging. (both pegging types are described in this blog article)
• Some articles that have compared net requirements to pegging seem to be giving too much credit to net requirements as it is not a “comparative” functionality. One blogger who attempted to equate the two is incorrect. Both ERP / MRP, as well as SAP APO, perform net requirements calculation, but only between SAP ERP and SAP APO, APO is the only one to perform pegging.
• Net requirements are performed for either reorder point or forecast planning.

Here I will cover net requirements calculation in both SAP ERP and MRP.

Net Requirements Calculation in SAP ERP / MRP

“Net requirements calculation is carried out in MRP in the planning run after the planning file check at the plant level. The system checks whether it is possible to cover requirements with plant stock and fixed receipts already planned.” – SAP Help

Net requirements from this description can be said to be precisely what the name implies, a comparison of supply to demand. However, it is not a “pegging” of supply and demand elements. Net requirements are calculated for not only MRP but reorder point planning and forecast based planning.

When net requirements planning is run tells you a lot about the procedure:

In reorder point planning the net requirements calculation is only carried out once the stock level has fallen below the reorder level. It is calculated as follows:

Plant Stock + Receipts (POs, firmed planned orders, firmed purchase requisitions) = Available Stock 

Now let us compare this to net requirements in forecast based planning (which is when any supply planning method is used):

The basis for forecast based planning is the forecast of the total requirements.

Plant Stock – Safety Stock + Receipts (POs, firmed planned orders) + Requirements Quantity (forecast requirements) = Available Stock

Looking at the differences between these formulas is straightforward enough and is highlighted in blue. Here is what is different between the two

• Safety Stock
• Firmed Purchase Requisitions
• Forecast Requirements

In this step, various stock types are cobbled together to form “plant stock.” SAP has a page in its help on “Fixed Pegging and Net Requirements Calculation,” which is highly confusing.

Net Requirements Calculation in SAP APO

This requirement calculation is much more complicated than what I showed for SAP ERP.

“All requirements (requirements that lie before the horizon, in the horizon and in the period of adjustment)  – Orders that lie before the horizon (pegging strategy – Use Earliest Receipts)  – Orders for which the order activity in the planning segment in the horizon or in the period of adjustment is firmed (use pegging strategy according to the setting in the product master) – Firmed orders which lie in the period of adjustment (use pegging strategy according to setting in the product master) = Net requirements” – SAP Help

Gross Requirements Planning in SAP ERP

As a means of comparison, there is something called gross requirements planning, which is initiated by

“Make-to-stock prod/gross requirements plng”

which is where planned independent requirements are not compared with warehouse stock, and the system only checks against the expected receipt quantity. The gross requirements plan is displayed as a separate segment in the MRP list.

Conclusion

Net requirements calculation is a method of comparing the overall planned supply to the overall planned demand for a product at a location. Pegging is quite a bit different. Pegging provides a specific and traceable connection created between a supply and a demand element. Net requirements are performed in MRP, while pegging is performed in SAP APO in all of the different supply planning methods, although fixed pegging is only available within CTM. However, CTM can be set with either fixed or dynamic pegging in the CTM Profile. This is unfortunate because dynamic pegging is hugely confusing and applies in far fewer cases. Without a fixed peg, the assignments move around every planning run.

The pegging that is so frequently discussed concerning CTM during the initial supply plan creation breaks down once deployment occurs. The benefit of CTM in the deployment stage exists but is indirect. CTM has not allowed lower priority sales orders to be accepted. Therefore when a deployment occurs, those lower priority sales orders are not in the system to compete with the higher sales orders for the stock as it is deployed. However, this isn’t very reassuring to clients that would like the pegging to persist throughout all of the supply planning processes. Secondly, when the peggings that are created in CTM are passed back to SAP ERP, they don’t have any implications. Therefore, the peggings are truly a logical connection, which is limited to the initial supply plan run created by CTM.