Show TOC

 Process Pegging Relationships

Purpose

This process describes how the system does the following at the start of the optimization run:

  • Executes pegging

  • Converts the pegging relationships into relationships between receipt elements and requirement elements, or into requirement dates for receipt elements ("due dates").

The relationships and the requirement dates represent hard and soft constraints respectively for the optimization, and based on these, the system must schedule receipt elements on time, or it can minimize the delays for receipt elements .

Prerequisites

The optimization run has started.

Process Flow

  1. The system executes "normal" pegging; that is, the area in which the system creates dynamic pegging relationships is not limited to the optimization range . The system uses the pegging parameters from the product master. Fixed pegging relationships remain unchanged.

  2. The system deletes the dynamic pegging relationships that lie completely within the optimization range.

  3. The system creates new dynamic pegging relationships for the receipt and requirement elements that lie within the optimization range. In doing so, the system can execute backward scheduling. As a default during backward scheduling, the system can link a requirement element to a receipt element that is up to 24 hours late. You can enter another value in the optimization profile or when calling up the optimization. The value set for backward pegging in the product master is not relevant for the optimization.

  4. The system converts the pegging relationships that are partially or completely in the optimization range either into requirement dates for the receipt elements or into relationships between receipt elements and requirement elements as follows:

  • Pegging relationship to a fixed requirement element

A pegging relationship between a receipt element and a fixed requirement element (for example, a sales order or an input node for an activity outside of the optimization range) defines a requirement date for the receipt element. The requirement date is a soft constraint for the optimization that the system is allowed to violate. Therefore, the system is also allowed to schedule the receipt element after the requirement date. However, these delays can be minimized during optimization.

  • Pegging relationship to a non-fixed requirement element

The system converts a pegging relationship between a receipt element and a non-fixed requirement element into a relationship between the receipt element and a requirement element. This relationship is a hard constraint ; during the optimization, it forces the receipt element to be scheduled on time; that is, the receipt date cannot be later than the requirement date. Therefore, the system eliminates, if necessary, the delay of a receipt element for a non-fixed requirement element.

  • Based on the pegging relationships, the system can prevent or minimize delays during optimization. Shortages can only be removed if you have specified in the optimization profile that a follow-up optimization should be executed.

  • The newly created pegging relationships are only valid for the optimization. After adopting the optimized schedule into the planning version, the system creates, if necessary, new pegging relationships.