Pegging - determines pegged requirements and covers receipts across the entire supply chain 

 


In order to obtain transparency about the relationships in the entire supply chain in SAP, the production planning cockpit "PPC" dynamically assigns all receipts to the corresponding requirements at several levels (pegging).


General information about pegging 

Effective production planning of the entire supply chain is only possible if there is continuous clarity of the relationships in the chain, which in turn leads to production and delivery of products.

In other words, this means that at every point in the supply chain (sales, production on all levels, purchasing) the pegged requirements have to be known for each receipt or, in reverse logic, the covering receipt (if existing) has to be known for each requirement.

This is necessary for the following functionalities:

  • Establishing transparency and identifying exceptions in the supply chain
  • For multi-level planning , to coordinate the elements of the supply chain
  • Determination of material availability in multi-level manufacturing scenarios, e.g. in mechanical engineering

It is particularly difficult to link the requirements and covering receipts in a make-to-stock (MTS) scenario using pegging, since

  • there are no fixed links between the levels of the supply chain (product levels) and these have to be generated according to a defined logic.
  • the lot sizes can be different at different product levels and partial quantity assignments can occur.
Example:

Helicopter engines with modules, main assemblies per module and individual parts

The pegging functionality in ITeanova's production planning cockpit

Pegging is one of the absolute core components of ITeanova’s “PPC” production planning cockpit, which is fully integrated in SAP. Many functionalities are built around pegging to guarantee efficient planning.

The following points should be highlighted:

  • Flexible rules for pegging (filtering, sorting and inheritance of characteristics for requirements and receipts)
  • Partial quantity pegging, i.e. the entire order quantity is not always required in the network
  • Possibility of dynamic and fixed pegging, mixed scenarios possible
  • Clear presentation over many levels in tabular, hierarchical and graphic form
  • Jump to pegging details from many other views (different aggregated planning data) as an example: starting from multiple orders, displaying several pegging structures at the same time
  • Pegging determines borders (earliest possible start, latest possible finish) of operations and orders that are planned
  • Basis for multi-level planning, also in MTS scenario
  • Pegging as a basis for PPC's own demand coverage (MRP-like functions in the PPC)
  • Pegging as a basis for CTP functionality

There are two basic pegging logics: ATP (available to promise) or FIFO (first-in first-out)


Additional filters and prioritisation rules can be added to these basic logics. An example of this is the horizon within which receipts and requirements can be assigned to each other:




A great advantage of pegging is that even in make-to-stock scenario, you know exactly which receipt meets which requirement. For example, a planned order or a production order can cover a sales order. If the required components are made available late, you can quickly see which receipts have to be postponed and which customers have to be notified.






An important additional feature is partial quantity pegging over any number of levels. If, for example, only part of a receipt (e.g. a production order) is used to cover a requirement (e.g. a sales order), then only a corresponding part of the dependent requirements at the lower level is assigned to the independent requirement and not the full dependent requirement. This can make an enormous difference if large and small lot sizes alternate within a pegging structure.

The example below illustrates how the principle of pegging, the dynamic assignment of requirements and receipts, works at several levels downwards and/or upwards.

Simplified presentation in the two diagrams below:

No differentiation of requirement/receipt per level → only consideration of receipts (here orders) per level.



For the first primary order of 40 bicycles, both the first tyre order (40 pcs.) and the second tyre order (60 pcs.) are needed in case of total quantity pegging in the picture above, whereas only the first tyre order (40 pcs.) is assigned in case of partial quantity pegging in the picture below.




Detailed diagram in the following images:

Requirements and receipts are now displayed in separate lines for each level.




Image Below: Multilevel pegging upwards



Screenshot below

Here, in the "Order network upwards", " Orders on bottleneck" and "Order network down" views, it is made clear that in PPC for a selected order in production (marked order on bottleneck in the view in the middle) both the structure upwards (in this case it covers several independent requirements) and the structure downwards (component overview) are shown at the top of the screenshot and at the bottom of the screenshot respectively.

This separate display of the pegging paths/directions of an assembly order contributes greatly to clarity .


The screenshot below shows a combination of different views in the production planning cockpit "PPC": On the left, one order (either planned or a production order) is displayed per line, and on the right, the pegging structure for that order is displayed .