Pegging

This macro will create pegging links (material dependencies) between operations which respectively consume and produce a semi finished product. A good understanding of the ROB-EX BOM module is vital to understand the concepts of the pegging macro.

Background

A helpful way of picturing “Pegging” is by comparing it to “Genealogy Tracking” in manufacturing. If “Genealogy Tracking” is the process of recording the history of what components went into what products, then pegging can be thought of as a dynamic or active form of genealogy tracking, i.e. trying to predict what manufacturing orders will feed which requirements.

The APICS dictionary defines pegging as: “In MRP and MPS, the capability to identify for a given item the sources of its gross requirements and/or allocations.”.

We can translate that into an example: An order is producing product X in a quantity of 10. A BOM-line on the order states a requirement of 20 product Y components. Pegging will tell me what orders will supply the component requirement of Y.

And what does it give a planner ? Creating pegging links between orders will provide

• the ability to analyze the impact of changing a supply or demand order at any level of your bill of material. In the event of delayed delivery of an intermediate product order then it can be immediately identified which next BOM level orders are affected. This will make it easier to both re-plan and provide instructions on the effect of a delay.
• the ability of advance confirmation of the validity of inventory and released orders so surprises during manufacturing execution is avoided.
• in a batch production environment pegging may also be an important step in carrying out detailed tank planning, since the ROB-EX pegging functionality includes features to automatically update the BOM line with information about what warehouse (=tank) incoming material is drawn from.

How does it work in practice?

The Pegging function exists in ROB-EX as a macro-command which can be configured to appear on the toolbar above the Gantt chart. So the Pegging can be manually executed by a click on a button or automatically at a certain time interval – or it could even be triggered in combination with a different action (for instance import from ERP).

When Pegging is executed it will try to match orders together which respectively consume and produce the same material. So if we for instance have an order consuming product “A” it will look for orders producing product “A”. When a match is found it will create a “Pegging link” between the producing operation and the consuming operation.

A Pegging link is also called a “Material dependency” and is illustrated by a blue, dotted line connecting the two operations. A material dependency is considered a planning constraint and is thus respected by the automatic scheduling functions.

Basically you can run Pegging with two different approaches (see parameter onlyPegSelectedDestinations )

1. First, manually select the consuming orders to peg and then run the Pegging function
2. Or let the Pegging function find the orders to peg

In the first approach it is up to the planner or a macro (SelectComponents) to select the consuming operations in the Gantt chart which need to be pegged. This approach gives the planner more control of the Pegging process, for instance which consuming operations should have their demand fulfilled first. But this approach also includes more manual work.
In the other approach the Pegging will find the orders to peg automatically based on a configuration. Primarily it is based on a time period (i.e. run pegging on orders from Monday in this week and two weeks ahead).

When do you run Pegging?

In most cases the pegging is executed after order import from an ERP system. Secondly if the plan is changed significantly then a re-pegging might be needed because other orders might have a new better match. If Pegging is performed on orders already pegged (unless parameter ignoreAlreadyPeggedOrders is used), it will remove the Pegging links first and then run the Pegging as if it was the first time.

If the ERP system provides a delivery date on both the intermediate orders and the end product orders it is just a matter of making an initial planning in ROB-EX with backward from delivery date and then run Pegging. But in the case where the ERP system only provides a delivery date on the end product orders, some actions must be done before the Pegging:

One approach could be:

• To plan the end product backward from delivery date and intermediate orders forward from now (or from material calendar). Then when we run the Pegging, it will tell us if it is a valid plan (if enough intermediate product has been produced in order to let the end product order start).
• By default the Pegging expects a producing intermediate order end-time (scheduled or actual end) to be ahead of the time of the requirement – and thus only in that case a pegging link will be created. A warning message will be shown if an end product order does not get its complete demand fulfilled.
• In the case where we cannot expect that the initial plan will have intermediate orders to finish before the end product orders we can “relax” the pegging so it will accept producing intermediate orders to be in the future (see parameter allowNegativePeggingWindow). In that case links would always be created and the plan can be fixed afterward by the normal bottleneck or scheduling function.

A different approach could be

• To use the BOM scheduling feature to schedule the end product orders forward with respect to available material in stock. This will ensure that the end product orders will not start before there is material available (in other words that the intermediate orders have produced enough intermediate material). And then Pegging could be run afterward.

Example parameter configuration

Example output

The above picture shows how as an example order 4268309 (bottom left) is pegged to source order 210828. Meaning the input to order 4268309 will come from order 210828. The different BOM lines assigned to respectively 4268309 and 210828 in combination with the currently projected inventory, is used by the pegging algorithm when determining what semi orders serves which end product orders.

Preconditions

The pegging routine searches for materials where the “Use in pegging” flag is true. So unless this flag is set for the material being pegged, then no pegging will be performed.

Operations producing a product must have the producing material added as a BOM line on the “Materials” tab on the “Edit Operation” dialog (double click on an operation). See example below.

Consuming operation.

Other pegging parameters such as the Pegging window etc. must be set up to match the actual plan – see parameters explained further below.

Hint
Add the special Pegging columns to the order list in order to identify orders not pegged etc.

Developer notes
It is possible to force which source -and destination operations to peg together. Consider below Java script example, where two orders should be forced pegged together. Also notice how to run it on UI thread.

GanttMacro peggingMacro = pAPI.getMacroManager().getMacro("Pegging");
Map dataForMacroContext = new HashMap();
List sourceOperations = new ArrayList();
List destOperations = new ArrayList();
sourceOperations.addAll(sourceOrder.getOperationList());
destOperations.addAll(destOrder.getOperationList());
dataForMacroContext.put("sourceOperations", sourceOperations);
dataForMacroContext.put("destOperations", destOperations);
//Force the macro to be executed in same thread
dataForMacroContext.put(MacroExecutionContext.RUN_ON_UI_THREAD_ATTACHMENT_KEY, new Boolean(true));
MacroExecutionContext macroContext = new MacroExecutionContextImpl(peggingMacro, dataForMacroContext);
peggingMacro.execute(macroContext);

Parameter descriptions

(* = configuration required)

adjustToCountingLevel

Only relevant if pegToCountings is false.

If true, the calculated BOM-line quantity to consume from a producing order, is reduced by the amount that a possible counting – placed in the time period between the consuming operation and the producing order – supplies. I.e. simulate that part of the semi-product requirement is supplied by existing inventory.

Default: false

allowNegativePeggingWindow

If true operations will be pegged even though the consuming starts before the producing. See also pegFromSourceStart and allowPeggingOnSameDayEvenStartBefore.

Default: false

allowPeggingFromFirstOrderInBatch

Only relevant if groupSourceOrders is true.

If true a destination order can be pegged to a source product group at the end-time of the first order in the group. Otherwise the entire source group must be have a latest end-time ahead of destination orders it can feed. See also pegFromSourceStart and allowPeggingOnSameDayEvenStartBefore.

Default: false

allowPeggingOnSameDayEvenStartBefore

Relax the pegging so a destination order is allowed to be pegged to a source order even though the destination starts ahead of the end-time of the source – as long as it’s on the same day. Se also pegFromSourceStart.

Default: false

calculateOverlapOnDestination

This is normally used together with calculateOverlapOnSource or createVerticalLinks.

Example:

The destination (C100) consumes 100 from the two sources. It takes 80 from the first one and the remaining 20 from the last one. Then the offset of the destination anchor is calculated to 8 hours after the start of the consuming operation (which on this case corresponds to an overlap on 80%).

Hint: Make a bottleneck planning from the source operation in order to start consuming as soon as possible.

Default: false

calculateOverlapOnSource

This is normally used together with calculateOverlapOnDestination. Does not work with createVerticalLinks ! In case both is true createVerticalLinks has the highest priority.

Example:

In this example overlap is calculated both on sources and destinations. Notice that this will only be realistic if the production -and consumption rate is the same!

Otherwise use createVerticalLinks together with calculateOverlapOnDestination.

Notice that allowNegativePeggingWindow and/or pegFromSourceStart should be enabled.

Possible values are: true/false/start/end

true and start: each added constraint offset by the time it would take to produce the material needed for any existing constraints.
end: each added constraint offset by the time it would take to produce the material needed by itself and any existing constraints.
false: no overlap calculated

Default: false

consumeExcessProduct

Create consumption operations which will consume any possible overproduction. Sequences of orders on same resource producing/consuming the same product are compared and if a destination group consumes less than it’s pegged source group produces – an operation will be created after the last order in the destination group which will consume any excess product.

See also the following three parameters.

The parameters groupSourceOrders and groupTargetOrders must be set to true. Otherwise the pegging and the creation of the excess product consumption will not match.

Default: false

createVerticalLinks

Normally used together with calculateOverlapOnDestination. But NOT with calculateOverlapOnSource

Example:

This can be used if consuming orders are already scheduled with respect to BOM constraints (see screenshot below) so they start as soon as possible where there are enough material in stock.

Also macro UpdateMaterialDates can be used to move consuming operations to where enough material is in stock. This macro can also be used to move producing operations to where there is available space in the warehouse(s).

Notice that allowNegativePeggingWindow and/or pegFromSourceStart should be enabled.

Default: false

debug

Some debug information can be printed. One or more of below keywords can be specified as a comma separated list.

Keyword “all” will print full debug.

Example: “General, Pegging, RemovePegging”

Possible key words:

all
General
Split
RemovePegging
RemovePeggingJoin
Pegging
PeggingDisableOrgAccesses
restBatch

Empty by default, i.e. no debug.

destOprOnlyConsumeQtyLeft

If true the destination operations in progress should only consume material from their sources corresponding to their quantity left.

Default: false

excessProductConsumptionOprName

Only relevant if consumeExcessProduct is true.

Specify the name of the excess product consumption operation. The operation will be named with this value if a later destination order on same resource consuming the same product was found. If no order was found the operation will be named with the value in the subsequent parameter.

If an order was found the order number of this will be saved on an optional field on the consumption operation. See excessProductOrderReferenceField .

Default: R

excessProductConsumptionOprNameNoProductAfter

Only relevant if consumeExcessProduct is true.

Specify the name to give the consumption operation if no later destination order was found consuming the same product.

Default: RA

excessProductOrderReferenceField

Only relevant if consumeExcessProduct is true.

Specify the field where the order number of the later destination order must be saved. See also excessProductConsumptionOprName .

SeeVariable list for a list of possible fields.

Default: {opr_custom_text1}

excessProductConsumptionOprNameNoProductAfter

Only relevant if consumeExcessProduct is true.

Specify the name to give the consumption operation if no later destination order was found consuming the same product.

Default: RA

excludeDestOperationsWithStateLevels

Enter the statelevels for destination operations to be excluded.

groupSourceOrders

If true source orders producing same product in sequence on same resource will be grouped together. Among others this can be used if it generally takes more than one source order to fulfill one destination order. Thus the pegging link will be created from a destination order to the last order in the source group. This option is also relevant if the product is produced in batches of multiple orders and thus the pegging is not allowed ahead of the latest end-time of the batch/group.

See also pegIndividuallyEvenGroupSourceOrders , and maxDurationHours .

Default: false

groupTargetOrders

If true destination orders consuming same product in sequence on same resource will be grouped together. This option is normally used together with groupSourceOrders. If both is true entire groups are pegged instead of individual orders. (however pegging links will be created from each destination order). This ensures that a certain sequence of destination orders will empty the source group it has begun with instead of flickering around between different resources. Notice that this will lower the priority of the useOldestFirst parameter and the default peg-to-nearest algorithm.

Default: false

horizonBackwardFromNow

The parameters horizonBackwardFromNow and horizonForwardFromNow decides the period where destination orders to be pegged must be within. Thus destination orders outside this period will not be pegged and any existing pegging information on orders outside the period will be retained. See also useMatAndDelDateAsOprStartAndEnd .

horizonForwardFromNow

Default: 90 (days)

ignoreAlreadyPeggedOrders

If true then preserve any existing pegging links and only peg operations which are not already pegged. An operation is pegged if at least one of the following criteria’s are true

1. a consuming BOM line is disabled or
2. a consuming BOM line is using fixed quantity as the consumption strategy

Default: false

ignoreOrderInPeggingFieldName

Orders can be skipped in the pegging. These settings applies to both source (producing orders) and destination (consuming orders). This field is optional. The field deciding if an order should be skipped, is specified using a layout item variable. SeeVariable list for a list of possible fields.

Example: Using the default parameter, all source and destination orders with a “true” value in its order_custom_boolean1 field will be skipped.

Default: {order_custom_boolean1}

Note that it is possible to specify custom programmed layout item variables. This will allow an integrator full flexibility on which orders are pegged in a certain situation. As an example a layout item could exclude completed orders from being pegged.

Important: this setting is ignored if parameter onlyPegSelectedDestinations is true .

ignoreOrderInPeggingFieldValue

Specify the value for which the return of ignoreOrderInPeggingFieldName should match, in order for the order to be skipped.

If the layout item in ignoreOrderInPeggingFieldName returns a string, a regular expression can be specified in this field. As an example specify the reqular expression .* in order to match any string or character. For more info see for instance http://en.wikipedia.org/wiki/Regular_expression

Default: true

layoutItemMatch (from v7.0.0.116/v6.4.0.1027)

Specify an id of a column which return value must equal between the source and destination transaction. If it does not equal a pegging link is not created, even though all other conditions would allow it. If as an example a layout item like “opr_quantity”, which returns the operation quantity, is used, then a pegging is only made if the source operation has the same quantity as the destination operation.

This option is often most useful if the layout item is programmed using scripting/user plugin or FlexRules. In that event it is possible to code functionality like hard coding a producing transaction to be pegged only to a specified consuming order. Or limiting pegging to happen only between producing and consuming transactions within the same project. Note that the input to the column is the material transaction, i.e. the column must be able to handle material transactions as input.

maxDurationHours

Only relevant if groupSourceOrders is true. This is used when grouping source orders.

Specify as a floating point number, the maximum allowed duration in hours between source orders in sequence producing same product on same resource. If the duration between two orders is exceeded the latter order is put to a new source group.

Default: 48 (hours)

maxEndVsDelDiff

Only relevant if useMatAndDelDateAsOprStartAndEnd is true.

If the difference between operation end date and delivery date exceeds this value (integer value in days) a warning message will be displayed in the log viewer. It’s possible to jump to the order from the log viewer.

Default: 3 (days)

maxStartVsMatDiff

Only relevant if useMatAndDelDateAsOprStartAndEnd is true.

If the difference between operation start date and material date exceeds this value (integer value in days) a warning message will be displayed in the log viewer. It’s possible to jump to the order from the log viewer.

Default: 3 (days)

onlyPegSelectedDestinations

If this is true only the selected destination operations (consuming operations) will be pegged. It will first remove pegging information from the selected and then (re)peg. The selected operations will be paired with possible source operations according to the normal pegging procedure, thus the same restrictions such as pegging window are followed.

If groupTargetOrders is true the selected destination/target operations are considered one group!

Setting this parameter to true will overrule any setting imposed by parameter ignoreOrderInPeggingFieldName . I.e. if an order is selected, it will be pegged no matter what ignoreOrderInPeggingFieldName specifies.

Default: false

pegFromSourceStart

By default a source order (operation) must have an end-time ahead of a target requirement, in order to allow pegging. If this option is set to true, pegging is allowed to a source order as long as the producing time interval overlap the consuming time interval.

See also allowPeggingOnSameDayEvenStartBefore.

Example when true:

In the above example the destination order (4276801) begins before the source order (211065) ends. And if this option is true this is allowed, otherwise those two orders would not have been pegged.

Default: false

pegFullAmountField

Specify on this field a layout item name (e.g. {material_custom_boolean_1}) pointing to a field which the pegging during execution will consult to learn if the BOM line being pegged can make partial pegging links to different sources or if the amount must be supplied by a single source.

As an example a product XX delivered in a tank truck or rail car tank has the requirement that the origin of the content being shipped must all come from the same QA lot. In ROB-EX a packaging order has been created producing product XX and consuming the intermediate product YY. It is the intermediate product YY we want to peg making sure YY all comes from the same QA lot.

To configure this on a per product basis

1. set pegFullAmountField={material_custom_boolean_1}
2. add the Custom Boolean 1 field to the Edit->Material table and set the value to “true” for product XX
3. optionally set groupSourceOrders =true (to collect multiple intermediate production orders into a single QA lot)
4. during execution of the pegging macro, the pegging algorithm needs to find a pegging source for intermediate product YY and it queries the field pointed to by pegFullAmountField to decide how to fulfill the demand of YY.
   • if pegFullAmountLookupReference =endProduct then Custom Boolean 1 on the end product (in this case XX) is queried
   • if pegFullAmountLookupReference =peggedLine then Custom Boolean 1 on the BOM line being pegged (in this case YY) is queried
5. If pegFullAmountField is a valid layout item and the value it points to is true, then we either consume the full requested demand or 0 (zero) if we cannot get the full amount.
   If pegFullAmountField does not contain any valid layout item or the value returned is false, we’ll consume as much as we can from the source and then (if needed) move on to consume the remaining amount from a different source.

If pegFullAmountField points to a String field, then the value of the field must be “true” (any other value is interpreted as meaning false)

If pegFullAmountField points to a number field, then a value of zero (0) is intrepreted as “false”, and any other value as “true”

Also see parameter pegFullAmountLookupReference

pegFullAmountLookupReference

Allowed values for this field is

• endProduct – obtain the value that pegFullAmountField points to from the end product of the order being pegged
• peggedLine – obtain the value that pegFullAmountField points to from the current BOM line being pegged

See usage example of this parameter in the description of parameter pegFullAmountField.

pegIndividuallyEvenGroupSourceOrders

Only relevant if groupSourceOrders is true. If groupTargetOrders is also set to true this option is ignored (fixed to always true).

Example when true:

Each order in the source group is pegged.

Example when false:

Only the last order in the source group has pegging links.

pegToCountings

Take stock level countings into consideration. A consuming order can peg to one or more counting rows. If both a producing order and a counting is on the same warehouse and the counting is placed first in time, the parameter useOldestFirst” should be set to true – in order to consume from stock first and then the rest from the producing order.

See also adjustToCountingLevel.

Default: true

pegToPurchases

A consuming order can peg to (consume from) a purchase.

Default: true

peggingBalanceCategoryName

Target orders which have unfulfilled demands will consume the missing amount from a certain category of the current intermediate product. In that way it’s illustrated on the BOM graph when insufficient amount of an intermediate product exists.

Here the name of the category can be specified. See also peggingBalanceCategoryValueName. Specify a blank peggingBalanceCategoryValueName in order not to specify any category.

See Categories/material types for more information about categories.

Default: PeggingBalance

peggingBalanceCategoryValueName

Here the name of the category value can be specified. If a blank value is specified (default) the consumption will NOT be consumed from any category – just the common product. A good name/value could be “Unfulfilled”.

See Categories/material types for more information about categories.

Default: (blank)

peggingWindow

This defines the maximum time difference between a destination order and a possible source order.

Pegging window illustration:

The red rectangle illustrates a pegging window on 5 days with respect to the selected destination order (4270712). Thus source orders ending outside the window are not considered for the selected destination order.

Parameters which influence the pegging window: allowPeggingFromFirstOrderInBatch, allowPeggingOnSameDayEvenStartBefore and pegFromSourceStart.

Default: 5 (days)

posTanksOprTemplateFirstPartName

Specify a prefix in the master operation names, deciding the possible/allowed transfers between tanks/resources.

Example:

If the following resources exist: SourceResource1-5 and DestinationResource1-5.

Then Creating a template operation with the name _PosTanks_DestinationResource1 and assigning resources SourceResource1 and SourceResource2 as alternative resources for that master operation, will result in the fact that operations assigned to resource DestinationResource1, can be pegged only to orders on the SourceResource1 and SourceResource2 resources.

Default: _PosTanks_

productFamilyIncludeFilter

If the parameter is not empty then only materials being a member of the specified product family (name field) will be pegged. If a material is not assigned to a product family, it is assumed the product family name is the empty string “.

This setting does not overrule a possible “Use in pegging” flag set on the material master. I.e. if “Use in pegging”=_false_ for a material, the material will never be pegged, even if it matches a product family specified with this parameter.

The value specified for this parameter is interpreted as a regular expression. E.g. specifying “family1|family2” will match on either a product family with name “family1” or “family2”. Use of a regular expression will also allow to specify anything not matching. E.g. specifying ^(?!family1).*$ will match on anything not belonging to a product family with name “family1”.

releaseToolsOnCompleteConsumption

If true the pegging will “release” tool materials on the consuming operations. If the producing operation consumes a tool material in order to produce the semi finished product the consuming operations will produce the same amount of tool material again – so the tool can be used again later on. The tool will be released on the time where the complete production is consumed. Tools will also be released on excess product consumption operations – if the last part of the production are consumed on those.

Default: false

removeAllMaterialConstraintsUponRemovePegging

If this is true all pegging links (Material Constraints) that could not be removed by the normal pegging function will be removed.

Default: false

removeExcessProductConsumptionsOprs

If this is true all excess product consumption operations will be deleted.

Default: false

removePegging

If this is true the pegging information (links) will be deleted. Only pegging info in the period defined by horizonForwardFromNow and horizonBackwardFromNow will be removed.

Hint: Create a new Pegging macro with a large pegging period with the sole purpose of removing pegging information.

Default: false

showPeggingConfirmation

If true, a message is shown to the user when pegging is done (in the log viewer).

Default: false

simultaneouslyFillingAndEmptyingResTypeBitFlagNo

Specify this in to order control if simultaneously filling and emptying should be enabled on the resources. Any resource type with a bit from 8 to 15 set will enable this.

Here the bit number must be specified.

Otherwise specify this in the resource specification field:

SimultaneouslyFillingAndEmptying=“true” (or false)

Default: (empty). If empty this setting is enabled on all resources.

sourceAnchor

Here the outgoing anchor on the source operation can be overwritten by specifying this parameter on the link/constraint it self. This does NOT work if “calculateOverlapOnSource” or “createVerticalLinks” are enabled.

Possible values (case does not matter): start, setup_end, switchover_start, end

Default: (empty)

splitDestOprPerConsumption

If true, only allow one consumption (pegging link) per target operation. So split the original destination operation into the number of consumptions to be created.

Default: false

targetGroupsCanOnlyPegToOneSourceGroup

Only relevant if groupSourceOrders and groupTargetOrders are true.

If set to true one-to-one relations between source and target groups are ensured. Thus a target group can only consume from one source group.

Default: false

updateConditionalValues

If true notify possible value providers – about which resources have been affected by the pegging.

Default: false

updateWarehouseOnBOMLine

If true then set the actual warehouse on the consuming BOM line. The warehouse is fetched from the resource of the operation the source BOM line is assigned to.

Default: false

useMatAndDelDateAsOprStartAndEnd

If true material and delivery dates are used instead of operation start- and end date.

See also maxStartVsMatDiff and maxEndVsDelDiff.

Default: false

useOldestFirst

If this is true destination orders will be pegged to the oldest source orders within the pegging window. Otherwise destination orders will be pegged to the nearest source orders.

Example oldest:

Example nearest:

Default: false

Copyright © 2023 ROB-EX A/S