Examining Additional Topics in Production Planning

Objectives

After completing this lesson, you will be able to:
  • Explore firming in SAP S/4HANA PP/DS
  • Explore pegging in SAP S/4HANA PP/DS
  • Explore a setup time matrix
  • Explore the reduction of planned independent requirements

Firming in SAP S/4HANA PP/DS

Firming a Planned Order

Planning Time Fence and Manual Firming Date

The graphic illustrates the planning time fence and the manual firming date, which is explained in the text that follows.

The planning time fence is calculated in working days from today’s date into the future. It is transferred from the SAP S/4HANA material master.

If a planning time fence is used, production can be protected from automatic changes within a certain time period. Within the planning time fence, only manual changes to the receipt elements are permitted. Automatic changes by a heuristic are not implemented within the planning time fence.

You can maintain an individual value for the planning time fence for each product. The end of the planning time fence can also be interactively set in planning to a fixed date for each product. The fixed area is then determined from the maximum of the planning time fence and the time fence.

Planned orders created by the system that are outside of the planning time fence can be changed by the system at any time. Within the planning time fence, changes can only be made manually by the MRP controller. Planned orders that are firmed using the planning time fence or time fence are firmed dynamically. Therefore, they do not acquire the indicators for date fixing or order quantity fixing.

If, in the example, a new requirement is added to the planning time fence, the system generates a planned order and places it at the end of the planning time fence. This ensures that the existing plan is not affected. Planned orders that arrive in the planning time fence due to time elapsing are firmed as soon as their finish date is in the planning time fence.

Explore Firming in SAP S/4HANA PP/DS

ExerciseStart Exercise

Explore Pegging Functionality in PP/DS

Pegging can be dynamic (with a pegging strategy) or fixed.

Pegging establishes a link between the receipt and issue elements of a product in a location. The system uses pegging to assign receipts to relevant requirements. This is called the "pegging network".

Pegging network:

  • Assignment between receipts and requirements
  • Changes are propagated to all dependent orders; the system searches for order quantities that are not yet assigned.Changes are propagated to all dependent orders; the system searches for order quantities that are not yet assigned.

The pegging strategy defines how requirements are covered when receipts are assigned. There are two strategies that can be entered in the product.

There are two different types of pegging relationships: fixed and dynamic. Fixed pegging enables you to fix a pegging relationship, that is, the pegging relationship will not be changed automatically by the system during planning. You can fix a particular quantity of a product receipt (manually or with heuristics) to a specific requirement. You can manually fix the pegging for a receipt / requirements element by editing the pegging structure from the product view.

Pegging Across the Entire BOM Structure

The graphic illustrates pegging across the entire BOM structure.

The system creates a pegging network of orders linked to one another, which represents the relationships between the receipt and issue elements of a BOM structure. For pegging relationships to be created, the product, location, account assignment (make-to-stock and make-to-order production) and planning version (active or inactive version) must be the same. Pegging relationships are only created within one pegging area. Furthermore, in characteristics-based planning, the characteristics must be the same.

The requirements and receipt elements are assigned according to the availability date / time and requirement date / time. Consequently, dynamic pegging relationships change if the requirements or receipts change. Pegging enables a multilevel transfer of changes.

The pegging structure for an order is an evaluation that is ordered according to the BOM structure of all related products and represents the relationships between the receipt elements and the issue elements. It provides an overview of the orders that are required to produce a finished product or assembly for a certain requirement.

Conditions for Dynamic Pegging

The conditions for dynamic pegging include maximum earliness of a receipt: 72 hours, alert threshold for earliness: 6 hours, maximum delay for a receipt: 24 hours, alert threshold for delays: 2 hours.

The maximum earliness of a receipt specifies the maximum period of time by which a receipt element can precede requirement element. This allows the system to create a pegging relationship in spite of the time interval. However, pegging relationships cannot be created in the case of long intervals. You similarly set the level of earliness as of which a date/time alert is issued.

Similarly, the maximum delay specifies the maximum period of time by which a requirement element can precede a receipt element. This allows the system to create a pegging relationship in spite of the time interval. However, pegging relationships cannot be created in the case of long intervals.

The format for all time entries is HHHHHH:MM, with HHHHHH standing for hours and MM for minutes. This means that a maximum of 999999 hours and 99 minutes can be entered. An uninterrupted time stream is used to calculate the duration, which means a factory calendar or shift model are not taken into account.

If a pegging relationship cannot be created between a requirement and a receipt element, a quantity alert is generated.

More on Pegging and Alerts in the Product Master

Fixed Pegging Inheritance

You must activate this function in SAP S/4HANA Customizing to transfer a pegging relationship from a production order to on-hand stock (Customizing step Activate fixed pegging for stocks).

In total, note that fixed pegging is purely a function of PP/DS that is not integrated with SAP S/4HANA. This means that relationships between requirement and receipt elements that are created in SAP S/4HANA can not cause fixed pegging relationships in PP/DS.

Note the following process-related restrictions: the shelf life process, the limited capacity of a container resource, and PP/DS production confirmations are not supported. In addition, a fixed pegging relationship is not transferred from a planned independent requirement to the sales order for consumption. For more information, read SAP Note 704583.

Heuristics for Creating Fixed Pegging

You can create fixed single-level or multilevel pegging relationships. You can delete automatically or manually-fixed pegging relationships.

Fixed pegging relationships can be created manually (interactively from the product view) or automatically with the SAP_PP_019 heuristic, "Fixing pegging relationships". The heuristic can be executed individually and creates single-level fixed pegging for the selected products. In addition, it can be combined with an MRP run to create a multilevel fixed pegging network.

When you create fixed pegging relationships, you can define criteria with user-defined settings in the sort profile that are used for sorting the selected documents in processing. The sorting assigns priorities to the documents. Documents at the beginning of the sorting have a higher priority (they are processed first) than documents at the end.

You can delete fixed pegging relationships with the SAP_PP_011 heuristic, "Deleting pegging relationships". If necessary, the deletion can be limited to manually or automatically fixed pegging relationships.

Fixed Material Flow: Sample Process

The graphic illustrates a sample process with fixed material flow using the MRP.

This figure, Fixed Material Flow – Sample Process 1, shows a sample process with fixed material flow using the MRP.

The graphic illustrates a sample process with fixed material flow using the optimizer.

This figure, Fixed Material Flow – Sample Process 2, shows a sample process with fixed material flow using the optimizer.

Explore Pegging

ExerciseStart Exercise

Explore Setup Matrix

The graphic summaries setup times in scheduling, which is described in the text that follows.

Maintenance:

  • Directly from PPM/PDS according to setup time, or...
  • Sequence-dependent via setup time matrix

The duration of the setup activity for an operation may depend on the setup status of the resource at the time of rescheduling, that is, on the operation that was processed prior to this on the same resource.

When scheduling or rescheduling an operation using a single resource, the system can automatically adjust the duration of the setup activities of the operation to be scheduled to that of its predecessor. A setup matrix is defined (with setup keys or setup groups as setup transitions) for this in the production planning master data.

You enter the setup matrix in the primary resource for which sequence-dependent setup times are to be used (you can only use single resources to map sequence-dependent setup times).

In addition, the following data should be maintained in the PDS for the sequence-dependent operations that are to be set up with the single resource:

Parameters in the setup matrix include setup transition type, setup group/key of predecessor operation, setup group/key of successor operation, setup duration, and setup costs.

The setup matrix is a transition matrix that contains the setup duration and the setup costs for each possible setup transition at a single resource that are necessary to change the setup status of the resource to another setup status.

In the setup matrix, you define all transitions between the various setup statuses of the resource. A setup status is determined by the setup group or the setup key for the operation processed with the resource: you use setup groups to define the standard setup transitions for the resource. You use setup keys to define the exception setup transitions for standard setup transitions.

For performance reasons, it is advisable to define setup matrices that are as small as possible, with only a few setup transitions. Therefore, you should only maintain the setup statuses using setup groups and setup keys in as much detail as is required, use as few exception setup transitions as possible and use setup groups/setup keys for different operations / products with similar setup times and setup costs.

Reorganization of Planned Independent Requirements

Adjusting the Planned Independent Requirements

The graphic illustrates adjusting planned independent requirements created in SAP S/4HANA .

The period of adjustment determines a period in which planned independent requirements are not taken into account in the requirements calculation but merely have an MRP effect for customer requirements. However, the planned independent requirements remain on the database (hide function).

You maintain the period of adjustment in working days in Customizing for the MRP group. The corresponding adjustment indicator defines whether the period of adjustment points to the past or to the future. The adjustment indicator also specifies whether the adjustment is valid for planned independent requirements for all strategies or only for those that are planned using a strategy in which customer requirements and planned independent requirements are consumed.

The adjustment can be used to eradicate planning errors, for example. The period of adjustment could, therefore, correspond to the period in which only the customer requirements that exist up to now are to be covered, and no new ones are expected.

Reorganizing Planned Independent Requirements

The procedure has three steps: Adjust requirements, reorganization, delete history.

During the adjustment, planned independent requirements that lie within the period of adjustment are simply ignored in material requirements planning but remain on the database. The aim of reorganization is to delete old planned independent requirements from the database.

Reorganizing of planned independent requirements is carried out in the following steps:

  1. Adjust requirements (transaction code MD74)

    Quantities that have not been assigned before the specified reorganization key date (this date can also be in the future) are set to 0 and flagged for reorganization.

  2. Reorganize schedule lines (transaction code MD75)

    Schedule lines that have a quantity of 0 before the key date are deleted from the database.

  3. Delete history (transaction code MD76)

    The history can be deleted by determining a (further) key date.

Hint

As an alternative to the key date, you can maintain a reorganization period per plant (in the Customizing activity for demand management). This is calculated backwards from the current date.

It is recommended that you carry out reorganization periodically, for example, once a month.

Reorganize Planned Independent Requirements

ExerciseStart Exercise

Log in to track your progress & complete quizzes

Learning

SAP FacebookSAP YoutubeSAP LinkedIn