Dynamic Pegging 

Use

Dynamic pegging is a function with which the system automatically links requirements for a location product with suitable stocks or receipts for the location product. If planning for the location product changes, for example, if you have created new requirements or receipts or changed dates, the system can use dynamic pegging to create new dynamic pegging relationships that are adjusted to the changed planning. In general, therefore, dynamic pegging relationships are not maintained for long.

Dynamic pegging relationships are evaluated by various SAP APO applications; for example, to analyze the planning situation, to identify planning problems, or to perform specific planning tasks. Therefore, these applications perform dynamic pegging automatically, if required. Here are some examples of these applications:

·         Capable-to-Match Planning (CTM)

CTM planning can identify uncovered requirements, for example, for which it has to find stocks and receipts, based on dynamic pegging relationships.

·         Creation and display of alerts in interactive Production Planning and Detailed Scheduling (PP/DS) and in the Alert Monitor

If you call up an interactive PP/DS planning tool, or update planning interactively, the system calculates the dynamic pegging relationships and displays the current, pegging-related alerts (quantity and date/time alerts) on the planning interface.

·         PP/DS optimization

Based on dynamic pegging relationships, PP/DS optimization can minimize delays or storage costs. Therefore, the system performs dynamic pegging at the start of an optimization run.

·         Detailed Scheduling

Based on pegging relationships, in Detailed Scheduling, the system can take into account the time relationships between orders on various production levels and, if necessary, propagate date changes to dependent orders on a multilevel basis.

·         PP/DS heuristics

Various PP/DS heuristics process pegging relationships, depending on their planning task, and therefore perform dynamic pegging in the heuristic run. For example, based on pegging relationships, the heuristics for sales order oriented planning SAP_PP_014, SAP_PP_015 and SAP_PP_016, can determine open planned independent requirements that have no sales orders, and reduce these planned independent requirements and the dependent planned orders accordingly on a multilevel basis. The following table contains a list of heuristics that process pegging relationships:

Heuristic	Description	Algorithm
SAP_PP_005	Part period balancing	/SAPAPO/HEU_PART_PERIOD
SAP_PP_006	Least-Unit Cost Procedure: External procurement	/SAPAPO/HEU_PUR_PLANNING
SAP_PP_012	Changing order priorities	/SAPAPO/HEU_PRIO_CHANGE
SAP_PP_013	Groff procedure	/SAPAPO/HEU_PART_PERIOD
SAP_PP_014	Requirements ascertainment of planned independent requirements	/SAPAPO/HEU_REQ_ASCERTAIN
SAP_PP_015	Adjustment of orders and planned independent requirements	/SAPAPO/HEU_ORGANIZE_VIA_PEGID
SAP_PP_016	Adjustment of special orders	/SAPAPO/HEU_ORGANIZE

For more information, see the system documentation for the heuristics.

Prerequisites

If you want the system to be able to perform dynamic pegging for a location product, you should not have set the Deactivate Dynamic Pegging indicator, which you will find in the location product master on the Demand tab page, under Pegging. For more information, see Deactivation of Dynamic Pegging.

Features

The system pegs receipt elements or stock elements with requirements elements in accordance with the following system standard or user-defined values:

·         The system may only peg pegging-relevant requirements, stock and receipt elements that belong to the same pegging area

In characteristics-dependent planning (CDP), the characteristic requirements and characteristic value assignments of the requirements or receipts have to be compatible. Note: Dynamic pegging is not specific to storage location or batch.

·         For a requirements element that is not in the past, the system may only use stock and receipt elements, whose availability date/time lies in the user-defined pegging interval of the requirements element.

The availability date/time of a stock element is the planning time-spot.

For a requirements element that is in the past, the system may also use a stock element, if the availability date/time of the stock element lies outside the pegging interval of the requirements element. However, receipt elements must be in the pegging interval.

·         The system must assign stock elements to a requirements element first.

·         The system must peg requirements elements and receipt elements, in accordance with the pegging strategy defined by the user for the product (for example, it must first use the earliest receipts in the pegging interval)

·         During pegging, the system takes into account the pegging-relevant quantities

·         The system may only use existing stocks and receipts whose quantities have not yet been assigned, or are only partially assigned, to other requirements

·         The system can assign several receipt elements and stock elements to one requirements element or one receipt element or stock element to several requirements elements, depending on the required or available quantities (see graphic under Pegging)