With The multi level pegging process most of the time it works well. I am seeing an issue where the Multi Level Pegging process is pegging supply that is being drop shipped to demand that is needed onsite. Is there any way to change this? I do not see why that would be a logical thing to peg to each other when the supply isn’t coming here and never will. Realistically I would like to turn off the logic of it trying to peg supply that is purchase direct since we make those purchase/make direct for a reason.
The only way around this that I see is for me to rebuild the multi level pegging process based on logic that works for my company like only peg items that are requesting from inventory to inventory and if it is purchase direct/make direct make sure those are pegged to each other since they already have a hard link (Cross docked)
Anyone else have issues with this? Any settings that I am missing to resolve this issue so I do not have to create this custom logic?
3 Likes
Are the sales orders marked drop ship?
Yes it is. Regardless any PO that is marked drop shipped should be disregarded for demand that is needed onsite because it is not viable supply for that demand.
I’d be curious what support has to say about it.
I reached out to support and waiting to hear with what they have to say. If ultimately I have to create my own pegging process that fixes these underlying issues I could always share it with anyone who is interested.
1 Like
My guess would be that multi level pegging is simply pegging earliest demand with earliest supply and there is no other major logic built around it and that it is working as intended. Maybe I am in for a surprise though. I just cannot imagine I am the only one who has come across this being an issue…Although I do find it odd that it does not consider purchase direct PO suggestion as supply but warehouse PO suggestions it does consider as supply.
I gave up on multi level pegging long ago. It’s soooooo close to being amazing but that last 5-15% is a deal breaker. It’s right just often enough that you really start to trust it, and then something comes along and blows up all the confidence in it.
I think it just uses the horseshoes and hand grenades approach.
1 Like
Just got off the phone with Epicor support…their answer “well it is just pegging to demand nothing else”.
Off to writing my own custom code to make it make sense. 
Here is my Epicor Idea if yall want to vote for it: Log In - Epicor Identity
In news that is not shocking . . . working as designed lol.
1 Like
After a few hours of development I have created a multi level pegging with more complexity.
Easy Part:
- Create a query pegging direct demand to direct supply (jobmtl/orderrel table direct/buytoorder = true)
- Populate into UD table
- Create query with parts that have allocations/reservations pegged (part alloc table)
- Populate into UD table
More Complex Part:
5) Create a query for nondirect demand that doesn’t include reservations/alocations
6) Create a query for nondirect supply that doesnt include reservations/allocations
7) for each loop on the demand and supply and compare earliest supply and earliest demand and create new records for each pegging and decrease supply/demand as you are looping through supply.
8) Populate into UD table
This whole process takes about 30 seconds to run versus 10 minutes that Epicor takes to run through the multi level pegging process. Then each time I run the custom multi level pegging process it deletes the entire UD table to start fresh.
Need to do some more data validation with this but looks pretty good so far. If anyone else is having issues with the multilevel pegging process I would recommend this route to allow for accurate pegging.
1 Like
