Can you run/filter multi-level pegging for a single part? And other "WHY" questions about the process

I am dealing with the pegging log right now, so I have ever more questions about multi-level pegging now.

Backstory - I’ve been using the multi-level pegging process - as part of MRP - every weeknight for about 18 months now. Takes an hour in the middle of the night. It’s fine.

Questions
Can you run it for a single part? Literally, no, there is no option for that - or anything!

But I mean like if I suggest this as an Epicor Idea, will that be stupid? Is it just not possible to filter the amount of work to be done?

I get it has ripple effects. But MRP handles this, right? If you wan “a single part” in MRP, it still recalculates the demand for all subcomponents of the jobs it creates, and their components, etc.

Then on that note, I found (long ago) that when you run MRP – say with 7 processes and 7 schedulers – and check the box for pegging to run, then pegging just runs at the end of MRP. It’s not concurrent with MRP (why not?); it only uses one process; it’s just as inefficient as if you had run pegging all by itself. So could pegging not be done more efficiently?

Again, just curious before I embarrass myself with an Idea or two.

I think the biggest problem you will run into is that not every customer uses MLP and what you are suggesting would impact every customer. It might not take long on your system, but it might add hours to another customer.

Why are you running MLP and is there something else that would meet your needs?

I think we are on different wavelengths. I don’t want to change MRP or anything. Just asking if anyone knows why it has to be run after MRP, why not part of it - I mean, if and only if you opt into it.

There are times it adds 3 hours for us. My point is, can it be faster.

Yup, different wavelengths. I thought you meant why does it just not run all the time with MRP.

My guess is that MRP was created first and then they added MLP.

1 Like

Since you asked - though no offense taken if you ignore the response now…

This is the origin story.

When we had all of the MfgSys sales orders as make-direct, we didn’t need to use Pegging. But MRP took too long, so we changed some settings, long story, read that post if interested.

Even then we punted on Pegging because I felt for that single level of top-level demand (level zero in MRP terms), Pegging was overkill. I assumed a clever query could do the math on the fly.

I was not up to that task, so we hired a consultant. He seemed to succeed, but soon it became clear that his query (a SQL, um… stored procedure?) failed on maybe 5-10% of the orders.

So then I went to my original plan of Pegging, and that’s been fine since.

It is inefficient for our needs. At 2 AM, who cares. But it would be nice if I could run it for something smaller when needed.

Good read. Not sure how your methods are built, but you should be able to get what you want with marking subassemblies as Non-Stock, Plan As Assembly, and Multi-Job.

1 Like

I only know OF these.

If you really want to optimize your manufacturing, I would start reading the MRP Tech Ref Guide and the Scheduling Tech Ref Guide. Those contain all of the levers you can pull to get the system to produce what you want. If no one understands them, it becomes very hard to look at how your methods are being built and what to expect as output.

Just as an example, if all of your parts are marked as Pull As Assembly in the methods, entering a job lot size or DOS probably adds time to MRP for no reason. Pull As tells the system to just make everything in the same Job, so it will never try to group anything together.

1 Like