Summary
Symptom
We call the assignment of product requirements and product receipts pegging. Pegging describes which receipt covers which requirement.This is a non-trivial algorithm which constantly raises questions, such as:
Pegging, alerts, alert, PP/DS, documentation
Reason and Prerequisites
What is pegging required for?
Pegging determines which product requirement is covered from which receipt element.
Pegging relationships are not required to perform product heuristics in the PP/DS.An MRP planning run does not need pegging relationships, it uses the net requirements calculation instead.The reason for this is that the pegging handles fixed and non-fixed receipt elements the same way.However, these must differ in the net requirements calculation.Note 448960 provides information about the net requirements calculation.
What is pegged?
We call the assignment of product requirements and product receipts pegging. Pegging describes which receipt covers which requirement.Receipts and requirements must appear within the same location and same planning version for the same product.We call the combination of product, location and planning version the pegging area.Furthermore, there is also a characteristic-dependent pegging.Only requirements and receipt elements with compatible characteristics can be pegged together.This is part of the Characteristics Dependent Planning (CDP).
The product requirements taken into account in pegging are:
The product receipts taken into account in the pegging are:
Safety stocks only participate in pegging if they are stored in the liveCache. For more information, see note 374624.
Sales orders only participate in pegging if you are not working with the 'Make-to-stock production' strategy (strategy 10) in R/3.In the case of the make-to-stock production, sales orders and planned independent requirements are not consumed.To avoid taking the requirements into account twice, only the planned independent requirements and not the sales orders are considered in pegging (and in the net requirements calculation).
For sales orders, only the confirmed quantities take part in pegging.For more information, see note 163576.
Any dummy assemblies are contained in a planned order or production order in APO as a component not relevant for pegging.This is only valid for planned orders or production orders that were created using iPPE runtime objects.
Fixed pegging and dynamic pegging
In APO, we differentiate between fixed pegging and dynamic pegging.In the case of dynamic pegging, the pegging relationships between product requirements and product receipt elements are calculated again every time a receipt or requirements element changes.With fixed pegging, a relationship set once is retained between a receipt element and a requirements element if other receipt elements or requirements elements change.
Example:
01/JAN Stock 100 units
02/JAN Sales order -100 units
03/JAN Purchase requisition 50 units
04/JAN Forecast - 50 units
At the moment, the stock dynamically covers the sales order.The purchase requisition (PReq) covers the planned independent requirements.If the date of the sales order now changes to a date after the planned independent requirements (January 5), then the stock automatically covers the planned independent requirements.The sales order is partially covered from the PReq and partially from the stock.
If, in the same example, the PReq is fix-pegged with the planned independent requirements, then this pegging relationship is kept even if the date of the sales order changes, as in the example above.Then the planned independent requirements will continue to be covered from the PReq.
Advantages of dynamic pegging:
Advantages of fixed pegging:
This note concentrates on the dynamic pegging.Fixed pegging is described in note 458996.
How is dynamic pegging calculated?
You can use different strategies to calculate dynamic pegging. SAP provides two of these types of pegging strategies:
Example:
01/JAN Purchase requisition 50
02/JAN Planned order 50
03/JAN Sales order 50-
With the FIFO strategy, the sales order is covered from the PReq.The planned order gets an overcoverage alert.With the 'Use punctual receipts' strategy, the sales order is covered from the planned order. The PReq gets the overcoverage alert.If the planner deletes all receipt elements with an overcoverage alert, then he deletes the planned order with the FIFO strategy.The product is kept unnecessarily long in the warehouse.
The overcoverage alert should, to all intents and purposes, be understood as a request to the planner to check whether the receipt element can be deleted. Of course, stocks can no longer be deleted from the planner.Therefore, stocks are pegged in advance.With the FIFO strategy, this is achieved by stocks specifying the earliest possible availability date.With the 'Use punctual receipts' pegging strategy, a check is made for every requirement (starting with the first requirement from a time point-view) to see whether these requirements can still be covered from the stock.If this is not the case, a suitable receipt element is then found, working backwards from the requirements date.
Special problems
In the section about symptoms above, we have given an example where a requirement is covered from several receipt elements.This also includes cover from a receipt element, which would be able to cover the total requirements alone.This behavior is caused by the pegging algorithm described above.With the FIFO logic, the system uses the first receipt it finds to cover a requirement.This also applies if the receipt cannot cover the requirements completely.With the 'Use punctual receipts' pegging strategy, the system first searches for receipt elements in the present.In our example, these receipt elements cannot cover the requirements completely but they are, nevertheless, pegged with each available partial quantity. The system then tries to cover the remaining requirements by searching for suitable receipt elements in the future.
By setting the 'Consume total order quantity' switch in the product master, you can ensure that receipt elements are always completely consumed by a requirement.In this example, you can therefore achieve a better pegging result.
In the section about symptoms above, we have given an example where 3 date alerts are displayed.For other pegging, you could have reduced the number of the date alerts to one alert.This problem is also caused by the pegging algorithm described above.Starting from the first requirement, the system searches for a suitable replenishment element for each requirement.Reducing the number of alerts is a flow optimization problem.For performance reasons, this type of optimization cannot be carried out in dynamic pegging which really changes quite a lot.
How is pegging affected by the 'Use requirement quantity' setting in the SAP_PP_002 heuristic?
Pegging is NOT affected by the 'Use requirement quantity' setting.The 'Use requirement quantity' setting is only used in the heuristic for net requirements calculation.Note 448960 provides information about the net requirements calculation.
Why is the confirmed quantity used in pegging?
The confirmed quantity is used in the pegging up to APO Release 3.1. The reasons for using the confirmed quantity in pegging are provided in note 163576. Historically, the CTP check was implemented in APO before the heuristics.For APO Release 4.0, the pegging for CTP products may be performed on confirmed quantities and the pegging for products planned by heuristics may be performed on requested quantities.The program changes required for this are very extensive and cannot be ported into earlier APO releases.
Solution
*
We call the assignment of product requirements and product receipts pegging. Pegging describes which receipt covers which requirement.This is a non-trivial algorithm which constantly raises questions, such as:
- What is pegging required for?
- What is the difference between fixed pegging and dynamic pegging?
- Receipt elements or stocks with a quantity of 20, 20 and 50 exist for events 1, 2, 3. A requirement with a quantity of 50 for event 2 is covered from the receipt elements 1 and 2, and 10 units from receipt 3. Why?Indeed, the entire quantity could have been taken from receipt 3. If you have to take from receipt 3 anyway, why not take the entire quantity?
- For events 1, 2 and 3, requirements with a quantity of 20 exist in each case. There are also three receipt elements with a quantity of 20 for events 2, 3 and 4. If backward pegging is allowed (a duration that is greater than the interval of 1 and 4 appears in the 'Latest access maximum ... as required' field), then the system assigns access 2 to requirement 1, access 3 to requirement 2 and access 4 to requirement 3. We get three date/time alerts. If the system pegged receipt 4 to requirement 1, we would only have one date alert. Why does the system bother the planner with three alerts?
- How is pegging affected by setting the 'Use requirement quantity' indicator in the SAP_PP_002 heuristic?
Pegging, alerts, alert, PP/DS, documentation
Reason and Prerequisites
What is pegging required for?
Pegging determines which product requirement is covered from which receipt element.
- This information is required to display the shortage/surplus quantity in the product view.The 'Surplus/shortage' column is displayed for each receipt or requirements element, for which the receipt quantity is not needed or for which the quantity of a requirement is not covered.
- The context display shows which finished product requirements are covered from a selected receipt element on any manufacturing level and which receipt elements are required here for the raw materials.
- The surpluses and shortages of location products are displayed in the alert monitor.
- In the graphic planning table, you can also move dependent objects when you are moving an operation.These dependent objects can also be orders for other manufacturing levels, if these are linked with the operation moved through pegging relationships and if the settings in the strategy profile specify that pegging relationships are to be taken into account.
Pegging relationships are not required to perform product heuristics in the PP/DS.An MRP planning run does not need pegging relationships, it uses the net requirements calculation instead.The reason for this is that the pegging handles fixed and non-fixed receipt elements the same way.However, these must differ in the net requirements calculation.Note 448960 provides information about the net requirements calculation.
What is pegged?
We call the assignment of product requirements and product receipts pegging. Pegging describes which receipt covers which requirement.Receipts and requirements must appear within the same location and same planning version for the same product.We call the combination of product, location and planning version the pegging area.Furthermore, there is also a characteristic-dependent pegging.Only requirements and receipt elements with compatible characteristics can be pegged together.This is part of the Characteristics Dependent Planning (CDP).
The product requirements taken into account in pegging are:
- 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
The product receipts taken into account in the pegging are:
- Production orders and planned orders (in-house production)
- Purchase orders, PReqs, scheduling agreement schedule lines (external procurement)
- Available stock
- Inspection stock
Safety stocks only participate in pegging if they are stored in the liveCache. For more information, see note 374624.
Sales orders only participate in pegging if you are not working with the 'Make-to-stock production' strategy (strategy 10) in R/3.In the case of the make-to-stock production, sales orders and planned independent requirements are not consumed.To avoid taking the requirements into account twice, only the planned independent requirements and not the sales orders are considered in pegging (and in the net requirements calculation).
For sales orders, only the confirmed quantities take part in pegging.For more information, see note 163576.
Any dummy assemblies are contained in a planned order or production order in APO as a component not relevant for pegging.This is only valid for planned orders or production orders that were created using iPPE runtime objects.
Fixed pegging and dynamic pegging
In APO, we differentiate between fixed pegging and dynamic pegging.In the case of dynamic pegging, the pegging relationships between product requirements and product receipt elements are calculated again every time a receipt or requirements element changes.With fixed pegging, a relationship set once is retained between a receipt element and a requirements element if other receipt elements or requirements elements change.
Example:
01/JAN Stock 100 units
02/JAN Sales order -100 units
03/JAN Purchase requisition 50 units
04/JAN Forecast - 50 units
At the moment, the stock dynamically covers the sales order.The purchase requisition (PReq) covers the planned independent requirements.If the date of the sales order now changes to a date after the planned independent requirements (January 5), then the stock automatically covers the planned independent requirements.The sales order is partially covered from the PReq and partially from the stock.
If, in the same example, the PReq is fix-pegged with the planned independent requirements, then this pegging relationship is kept even if the date of the sales order changes, as in the example above.Then the planned independent requirements will continue to be covered from the PReq.
Advantages of dynamic pegging:
- By reallocating the receipt quantities to the product requirements following a change to any receipt or requirements element, you get a more favorable planning situation.For example, in the above example, this allows you to move the PReq to the later date of January 5 and, as a result, to possibly choose a more suitable vendor.
- Dynamic pegging is very robust for all types of document changes.
- Dynamic pegging handles underdeliveries and overdeliveries well.
- Dynamic pegging allows you to form lots and, in particular, to also recalculate lots again after changes to requirements.If, for example, you are working with weekly lots and the requirements change within a week, then a heuristic can calculate the new receipt element from the total of requirements in the period.
Advantages of fixed pegging:
- With fixed pegging, a relationship set once is retained between a receipt element and a requirements element if other receipt elements or requirements elements change.
This note concentrates on the dynamic pegging.Fixed pegging is described in note 458996.
How is dynamic pegging calculated?
You can use different strategies to calculate dynamic pegging. SAP provides two of these types of pegging strategies:
- FIFO
- Using punctual receipts
Example:
01/JAN Purchase requisition 50
02/JAN Planned order 50
03/JAN Sales order 50-
With the FIFO strategy, the sales order is covered from the PReq.The planned order gets an overcoverage alert.With the 'Use punctual receipts' strategy, the sales order is covered from the planned order. The PReq gets the overcoverage alert.If the planner deletes all receipt elements with an overcoverage alert, then he deletes the planned order with the FIFO strategy.The product is kept unnecessarily long in the warehouse.
The overcoverage alert should, to all intents and purposes, be understood as a request to the planner to check whether the receipt element can be deleted. Of course, stocks can no longer be deleted from the planner.Therefore, stocks are pegged in advance.With the FIFO strategy, this is achieved by stocks specifying the earliest possible availability date.With the 'Use punctual receipts' pegging strategy, a check is made for every requirement (starting with the first requirement from a time point-view) to see whether these requirements can still be covered from the stock.If this is not the case, a suitable receipt element is then found, working backwards from the requirements date.
Special problems
In the section about symptoms above, we have given an example where a requirement is covered from several receipt elements.This also includes cover from a receipt element, which would be able to cover the total requirements alone.This behavior is caused by the pegging algorithm described above.With the FIFO logic, the system uses the first receipt it finds to cover a requirement.This also applies if the receipt cannot cover the requirements completely.With the 'Use punctual receipts' pegging strategy, the system first searches for receipt elements in the present.In our example, these receipt elements cannot cover the requirements completely but they are, nevertheless, pegged with each available partial quantity. The system then tries to cover the remaining requirements by searching for suitable receipt elements in the future.
By setting the 'Consume total order quantity' switch in the product master, you can ensure that receipt elements are always completely consumed by a requirement.In this example, you can therefore achieve a better pegging result.
In the section about symptoms above, we have given an example where 3 date alerts are displayed.For other pegging, you could have reduced the number of the date alerts to one alert.This problem is also caused by the pegging algorithm described above.Starting from the first requirement, the system searches for a suitable replenishment element for each requirement.Reducing the number of alerts is a flow optimization problem.For performance reasons, this type of optimization cannot be carried out in dynamic pegging which really changes quite a lot.
How is pegging affected by the 'Use requirement quantity' setting in the SAP_PP_002 heuristic?
Pegging is NOT affected by the 'Use requirement quantity' setting.The 'Use requirement quantity' setting is only used in the heuristic for net requirements calculation.Note 448960 provides information about the net requirements calculation.
Why is the confirmed quantity used in pegging?
The confirmed quantity is used in the pegging up to APO Release 3.1. The reasons for using the confirmed quantity in pegging are provided in note 163576. Historically, the CTP check was implemented in APO before the heuristics.For APO Release 4.0, the pegging for CTP products may be performed on confirmed quantities and the pegging for products planned by heuristics may be performed on requested quantities.The program changes required for this are very extensive and cannot be ported into earlier APO releases.
Solution
*
Header Data
| Release Status: | Released for Customer |
| Released on: | 08.10.2003 13:15:37 |
| Master Language: | German |
| Priority: | Recommendations/additional info |
| Category: | Consulting |
| Primary Component: | SCM-APO-PPS Production Planning and Detailed Scheduling |
| Secondary Components: | SCM-APO-BAS Please use SCM-TEC |
| APO-BAS-SCD Finite Scheduling, Pegging | |
| BC-DB-LCA liveCache Applications | |
| BC-DB-LCA-APS Advanced Planning and Scheduling Objects |
Affected Releases
Release-Independent
Related Notes
No comments:
Post a Comment