Intended learning outcomes: Differentiate between pegging (or requirements traceability) and demand coverage traceability.
The projected available inventory along the time axis, as defined in Section 12.1, is of relevance to every item. In the case of dependent demand calculations, planned receipts and requirements should be taken into account in addition to open orders and allocated quantities. The projected available inventory calculation extended in this way forms the basis for all exception reports (flagging deviations) and analyses.
Pegging or requirements traceability determines the independent demands that give rise to a dependent demand or a production or procurement order.
Pegging is one of the most important analyses for delayed orders, for example. It can be regarded as active where-used information. It determines the source of demand requirements, determining whether the underlying independent demands are customer orders or whether they stem from uncertain forecasts in the master plan.
To carry out this type of investigation, objects are created in the course of MRP for order connectionpurposes, specifically between item issues (demand positions in an order) and item receipts (positions for demand coverage). These objects can then be used to derive the desired pegging.
Pegging is equivalent to an allocation algorithm that assigns demand (item issues) to orders (item receipts). It is sometimes possible to cover every demand with several positions from different production or procurement orders. Conversely, every position in a production or procurement order can be used for several demand positions in various orders.
Creating the order connection object during MRP results in four types of action messages, or exception messages:
- Order to be pushed forward (speeded up)
- New order proposal
- Order to be deferred (slowed down)
- Superfluous order
The rescheduling assumption assumes that it is more promising to speed up an order already in process than to create a new order, since the remaining lead time is shorter.
As a consequence of this assumption, MRP logic tends to push forward orders that have already been released before it proposes a new order:
For the purposes of pegging, the order identification concerned is entered. One of the algorithms corresponding to the multilevel where-used list (see Section 17.2.3) calculates all the independent demands that are affected by this order. This results in multilevel pegging, which identifies all the intermediate demands and orders. The “leaves” of the resulting tree structure are then independent demands: forecasts, genuine customer demands, or unplanned orders for end products or service parts. For example:
- For bottom-up rescheduling, the planner uses pegging to solve material availability or similar problems. This can entail compressing lead time, cutting order quantity, or making changes to the master schedule.
For quick decision making in procurement situations, it may be necessary to identify the types of independent demand that give rise to a dependent demand, without the help of a pegging algorithm. A possible technique to solve this problem can be found in [Schö88a], p. 117 ff.
The structure of the order connection object can also be used for the opposite purpose.
Demand coverage traceability specifies all the (dependent) demands or orders that are at least partly caused by a particular (independent) demand.
A demand coverage list may be needed if, for example, you have to change the date or quantity for an independent demand (such as a customer order) and want to assess the consequences of this change. The algorithm is thus equivalent to the algorithm that generates a multilevel bill of material (see Section 17.2.3).
Course section 12.5: Subsections and their intended learning outcomes
12.5 Analyzing the Results of Material Requirements Planning (MRP)
Intended learning outcomes: Present projected available inventory and pegging. Produce an overview on action messages.
12.5.1 Projected Available Inventory, Requirements Traceability and Pegging
Intended learning outcomes: Differentiate between pegging (or requirements traceability) and demand coverage traceability.
12.5.2 Action Messages
Intended learning outcomes: Describe various possible action messages, or exception messages.
