Considering Dynamic Pegging Relationships
Use
If you are working with dynamic pegging, you can define in the
detailed scheduling strategy whether the system should consider the dynamic pegging relationships to other objects, when
scheduling or rescheduling an object (activity, operation or order). After scheduling or rescheduling, the system carries out dynamic pegging, in which it deletes the existing dynamic pegging relationships and creates new ones. Considering dynamic pegging relationships means scheduling or rescheduling an object and its dependent objects such that,
You can only consider dynamic pegging relationships together with
fixed pegging relationships. You have the following options:If you have
deactivated dynamic pegging in the location product master, there are no dynamic pegging relationships. Therefore, the system cannot consider any dynamic pegging relationships, and schedules or reschedules an order without the corresponding time constraints.Prerequisites
If the system should consider dynamic pegging relationships, you must also define in the detailed scheduling strategy that it has to
consider fixed pegging relationships and
time relationships between operations.
Features
Do not consider dynamic pegging relationships
The system schedules or reschedules an object without time constraints, that is, without considering the
pegging interval. After scheduling or rescheduling, the system carries out dynamic pegging in accordance with the pegging settings in the location product master (for example, pegging interval and pegging strategy). Since the pegging interval was not considered during scheduling or rescheduling, the original pegging relationship, that is, the original link between receipt elements and requirements elements can be lost. If the system is not able to create a new corresponding pegging relationship, quantity problems may now occur. If, for example, no receipt is assigned to a requirement of an order, there is a shortage for the order. If a receipt is not assigned to the requirement of any order, the order creates a surplus. If the system was able to maintain the pegging interval during scheduling or rescheduling, new date problems may occur if the deviation of the availability date/time from the requirements date exceeds the alert threshold for date/time alerts specified in the product master.Consider dynamic pegging relationships in the propagation range
The system must not consider a dynamic pegging relationship between an object in the
propagation range and an object outside the propagation range; the system can schedule or reschedule the object in the propagation range without time constraints (see above).However, the system must consider dynamic pegging relationships between objects within the propagation range; the system must schedule or reschedule an object such that the dynamic pegging relationship to a dependent object in the propagation range is maintained, and that the availability date/time is as timely as possible, or is at least between the beginning of the pegging interval and the requirements date. If the object has a dynamic pegging relationship to an
unfixed object, the system must schedule or reschedule this dependent object accordingly; for an unfixed deallocated activity, the system must also adjust the dates and modes. A fixed dependent object defines a fixed availability date/time or a fixed requirements date which restricts the scheduling or rescheduling of the object. If it is not possible to schedule or reschedule the object and its dependent objects accordingly, because the resources are occupied, for example, the system does not carry out scheduling or rescheduling.
As, with this option, the system maintains the pegging interval for a dynamic pegging relationship within the propagation range, the system creates (with all probability) the same dynamic pegging relationship after scheduling or rescheduling in dynamic pegging.

If pegging relationships exist between receipts and requirements, the optimization can
minimize delays of receipts. If there is no longer a pegging relationship between a requirement, for example a sales order, and a planned order for this sales order, the sales order date cannot be considered during optimization.