Influencing the pegging before start of the Optimizer

[Former Member]

Hallo,

thanks for reading this mail.

Due to a backlog of some products, we get a planning result after

optimization which is not totally explainable. (Production lots can be started

several weeks earlier as the result shows.)

The cause of this result is in the pegging of the elements for requirements

and receipts.

We noticed after the net change that several planned orders were placed

at the end of the planning time fence with the same date and time.

Due to this effect the pegging is undetermined und randomised in these cases.

Which means for example. A planned order is pegged with the first requirement

but on the component side with a later delivery. And the other one with a later

requirement but on the component side with an earlier delivery.

I called it a "crossed pegging" and not in sequence.

The only criteria for the pegging is the date-/time stamp and there is no

additional one. It seems so, but I cannot believe it.

A manual influence by changing of the planning time fence or fixing of planned orders

with different date/time stamp is not what we needed or is usefull.

Now we are looking for an automatical influence of the pegging in these

situations of products with a backlog.

Any suggestions to solve this problem is appreciated.

Best Regards and thanks for help

M. P.

[Former Member · Accepted solution]

Hello,

not really sure that I understood problem correctly, but try the next:

- analyse optimizer log file, it lists all pegging relationships that have been broken if any. Check orders/products and try to undertand why it was happen, i.e. resource unavalability, Maximum Earliness of a Receipt is too short or there are too many orders with priority 1.

- check planning results: if there are already orders in the past, i.e. pegging is already broken. If the pegging is already broken, optimizer will NOT re-establish it.

- set "Ignore upstream orders" and "validity period of orders as soft constraint " in the optimizer profile

kind regards

Alla

[Former Member · Accepted solution]

Hello Alla,

thanks for your answer.

A brief check of the log file shows no broken pegging.

It seems that I have forgotten something to mention.

Our planning run has the following main steps

1. net change

2. fixing the pegging

3. optimization

in above sequence.

So the problem we are focussing is in step 2.

The only thing why we do the pegging fixing is to ensure that all production orders

will be prioritised for planned orders.

Best regards

M. P.

[Former Member]

hello,

may be it will be easier to avoid to use fixed pegging and just use order priority? in receipt view, you set priority 1 to all process orders and after optimize with cost priority?

kind regards

Alla

[kenneth_snyder]

Are you talking SNP Optimizer or PP/DS Optimizer?

When you mention "Fixed" peggins, it seems like you are referrring to PP/DS Optimizer?

Ken Snyder

[Former Member]

It is the PP/DS Optimizer.

We do not use SNP.

Best Regards

M.P.