In most cases, the safety stock calculation methods in the SAP APO SNP and Production Planning and Detailed Scheduling (PP/DS) applications operate in the same way. However, subtle differences exist in the way the planned safety stock is displayed and in the calculation of the safety stock values. This is a source of confusion when calculating safety stock in PP/DS that I would like to clear up.

Safety stocks in SNP are always displayed as a quantity. This applies directly when you use quantity-based safety stock methods (SB, MB, AS, AT, BS, and BT). For demand-based safety stock methods (SZ and MZ), a macro translates the required safety days' supply into quantities before viewing them in the SNP Interactive Planning transaction. The same applies to the quantity-and-demand-based safety stock methods (SM and MM). Earlier articles in this series on safety stock planning describe these safety stock methods in detail.

The display of safety stock values within PP/DS — for example, in the Product View transaction (menu path Production Planning>Interactive Production Planning> Product View, or transaction code RRP3) — is not always this easy to understand. The quantity-based safety stock method results are displayed in the transaction as requirement quantities, just like any other order, while the demand-based safety stock methods do not create any entry at all. The quantity-and-demand-based safety stock methods create a requirement entry reflecting only the quantity-based safety stock portion of the total safety stock requirement. The available safety stock methods for PP/DS are also driven by the settings in the Lot Size tab on the Product Master screen.

I will explain the PP/DS functionality while highlighting the differences between PP/DS and SNP by each safety stock method. I will then look at common PP/DS-specific safety stock issues. The following information applies to APO 3.0 SP26, APO 3.1 SP17, and APO 4.0 SP04.

The static (time-independent) safety stock methods in APO (SB, SZ, and SM) can be used only after the usage of safety stock definitions has been activated for a given planning version (menu path Master Data>Planning Version Management>Model and Version Management, or transaction code MVM). As Figure 1 shows, select your planning version and set the value of the field PP/DS Take Safety Stock into Account to 1 if you use only static safety stock methods, or otherwise to 2.

Figure 1

Set the safety stock definitions for the planning version

Now let's look at how the safety stock methods work within PP/DS.

Static Safety Stock Methods

SB: With this method, a requirement with the available-to-promise (ATP) category CB is created at the beginning of the planning horizon (i.e., the current date and time). This safety stock requirement can be viewed, for example, in the Product View transaction and is accommodated by the PP/DS planning just like any other requirement. Changes in the product master safety stock settings are immediately reflected in the product's planning situation.

SZ: No specific safety stock entry can be seen in the Product View transaction with this method. The Safety Days' Supply setting of the Product Master is used as a time offset that determines how many days earlier the receipt element must be created in relation to the demand. Because demands are matched with early supply elements, a safety stock is built up. In most cases, the calculations carried out in PP/DS provide a similar build-up of safety stocks as those calculated within SNP. You need to watch out for a few points, though. PP/DS moves all supply elements (e.g., planned orders) in accordance with the Safety Days' Supply setting. These supply elements normally cover the same demand elements used in the SNP macro calculation. The standard SNP macro uses the Total Demand key figure, but this might have been changed to consider only part of the demand. In this case, the SNP-calculated safety stock is lower than that calculated by PP/DS.

While offsetting the supply element in accordance with the Safety Days' Supply value, PP/DS uses the production calendar from the location master. When using the standard-delivered macro for the SNP safety stock calculation, the shipment calendar of the location master is used. In cases where the production and the shipment calendars use different definitions for the working days, additional discrepancies between SNP and PP/DS might occur.

SM: This method combines both procedures as explained above. A safety stock requirement with the ATP category CB is created and, additionally, demand is satisfied early. Note that this approach is different than the one used in SNP where the higher of the two results determines the safety stock. Using this method, PP/DS first creates a safety stock requirement and then shifts all supply elements, even the one to satisfy the safety stock requirement, by the period as defined in the Safety Days' Supply value.

Dynamic Safety Stock Methods

Before dynamic (time-dependent) safety stock methods (MB, MZ, and MM) can be used in PP/DS, you must do some customization on the system. The key figures SAFETY (for dynamic quantity-based safety stock methods) and SVTETY (for dynamic demand-based safety stock methods) are linked to the functions Safety Stock and Safety Days' Supply. You must use the same planning area in these definitions as the one defined in the global PP/DS parameters.

Open the APO customization (transaction SPRO) and follow the menu path SAP Advanced Planner and Optimizer>Supply Chain Planning>Production Planning and Detailed Scheduling>Make SNP Key Figures Available. Carry out steps 1 through 3 below if you use the dynamic safety stock methods MB or MM or any extended safety stock method.

Step 1. Select the New Entries button and select your SNP planning area and the planning object structure 9AMALO. This is mandatory; do not use any other planning object structure.

Step 2. Type in the SNP key figure in which the safety stock values are defined. This is usually the key figure SAFETY (Safety Stock (planned)) and not SAFTY (Safety Stock). Note that these key figures are not displayed as a possible entry!

Step 3. Select the function Safety Stock and save the settings.

Carry out the additional steps 4 through 6 if you use the dynamic safety stock methods MZ or MM.

Step 4. Select the New Entries button and select your SNP planning area and the planning object structure 9AMALO. This is mandatory; do not use any other planning object structure.

Step 5. Type in the SNP key figure in which the Safety Days' Supply values are defined. This is usually the key figure SVTETY (Safety Days' Supply (planned)). Note that the key figure is not displayed as a possible entry!

Step 6. Select the function Safety Days' Supply from the top of the list and save the settings.

Your screen should now look like Figure 2. The special considerations for using dynamic safety stock methods in PP/DS follow:

Figure 2

You should see a screen similar to this one once you successfully customize APO PP/DS to use dynamic safety stock settings

MB: With this method, a requirement with the ATP category CB is created at the beginning of the planning horizon. PP/DS uses an SNP key figure (see the customization steps on page 9). As a result, the same safety stock value seen within SNP for the first day can also be seen in PP/DS for that particular day. PP/DS then calculates the difference in required safety stock per day. In the case of increasing safety stock requirements, a delta requirement with the ATP category CB and a negative value is automatically created by the system to indicate the higher safety stock requirement. In the case of decreasing safety stock requirements, a delta requirement with the ATP category CB and a positive value is created to indicate the lower safety stock requirement. Thus, the safety stock requirement becomes a virtual safety stock receipt

MM: This method combines methods MB and MZ. A safety stock requirement is created per day and all demand in addition to the safety stock requirement is satisfied early. Note that this approach differs from the one used in SNP where the higher of the two results determines the safety stock.

The usage of extended safety stock methods requires the same setup as method MB. In technical terms, there is no difference between method MB and the extended safety stock methods in PP/DS. PP/DS reads an SNP key figure to determine the dynamically changing safety stock requirements in both cases.

PP/DS Heuristics

Note that the selected PP/DS heuristic, with its embedded net requirements calculation, determines whether or not the safety stock settings are used. Some heuristics use the safety stock settings, others don't. Table 1 provides an overview of the standard delivered PP/DS heuristics.

For further information, check the individual PP/DS heuristics description. Open the APO customization (transaction SPRO) and follow the menu path SAP Advanced Planner and Optimizer>Supply Chain Planning>Production Planning and Detailed Scheduling>Heuristics>Maintain Heuristics. Select the Information button to obtain further information on the PP/DS heuristic.

Safety Stock and Shelf-Life Planning

When using the PP/DS heuristic HEU_PLAN_STANDARDLOTS and planning in accordance with the product's shelf life, no dynamic quantity-based or extended safety stock methods should be used. The problem is that delta safety stock requirements with a positive value (such depicting a reduced safety stock requirement) cannot have a remaining shelf life and thus cannot be used to satisfy any demand. The PP/DS run does not create any warning or error, but the planning result is not usable.

Safety Stock and Pegging

The pegging functionality in APO is a powerful but sometimes difficult-to- understand tool. The pegging algorithm links, or pegs, supply with demand elements that exist in the liveCache. Safety stock requirements, which are created when using safety stock methods other than SZ and MZ, are not modeled as requirements in the liveCache and can therefore not be seen by the pegging algorithm. This has positive and negative implications:

• The safety stock requirement is seen by the net requirements calculation, and a receipt covering this requirement is calculated. This receipt is seen by the pegging algorithm, but the corresponding safety stock requirement is not, since it is not modeled in liveCache. As a consequence, an unwanted alert indicating overcoverage is generated. It is possible to disable this alert, but then no alerts are generated even in the most peculiar overcoverage situation. Using the pegging strategy FIFO (first in, first out) with an adequate setting for the maximum earliness of the receipt usually results in the alert being generated toward the end of the PP/DS horizon. It is then easy to not display such alerts that are generated for the end of the PP/DS horizon.
  
  A similar false overcoverage situation (and workaround solution) exists when demand-based safety stock methods are used. In this case, the supply elements are created in such a way that they cover known demand too early for the pegging algorithm.

• An overcoverage situation exists for the pegging algorithm when safety stocks are defined. Consequently, the pegging algorithm creates undercoverage alerts only after the perceived overcoverage is used up. This is a wanted behavior, as it successfully avoids the creation of alerts as long as a demand can be satisfied through the reduction of safety stock.

• APO also offers the possibility to create safety stock orders directly in liveCache. These safety stock orders, which constitute requirements, are planned for by the net requirements calculation, and they are also seen by the pegging algorithm, so no unwanted alerts are created. The problem with this solution is that any safety stock usage triggers a safety stock shortage alert. This is in most cases undesired, as the usage of safety stock is normal in the short term. Also note that this option works only in conjunction with safety stocks defined in the product master and not with dynamic safety stocks. The creation of safety stock orders in liveCache using a special report is described in SAP notes 374624 and 578839.

Wolfgang Eddigehausen

Wolfgang Eddigehausen is a highly experienced expert in the areas of business process design, re-engineering, and user adaption, as well as process realization in complex SAP-centric environments. He has experience in solution and enterprise architecture and project management (PRINCE2 certified) domains defining enterprise capabilities with a focus on delivering effective and efficient solutions to organizations. Wolfgang's industry knowledge includes public sector, utilities, mining, distribution, general manufacturing, process and steel industries, and consumer goods.

In most roles his task is not only to architect a solution but also to evaluate and define strategic options with a focus on end-to-end solutions rather than systems. This also includes strong emphasis on the user acceptance through an innovative user experience and mobility enablement.

His career includes successful participation and management of projects in Australia, Europe, India, Japan, Singapore, South Africa, Taiwan, and the US. These projects required interaction with all levels of an organization, from the shop floor or office through to the CxO level. Throughout his career, Wolfgang has put emphasis on a holistic approach bringing together people, processes, information, and systems in project management, architecture, and implementation roles.

You may contact the author at we@avox.com.au.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.