We have encountered an odd aspect of MRP. Looking for some guidance on the best way to develop a workable solution.
What is happening (as far as I can tell) is that after a particular MRP run, we get a good end item schedule along with raw material incoming schedule that corresponds. But, on a subsequent MRP run, due to lot size variability, we get smaller lot sizes, which affects the incoming material schedule, generally delaying. On a following MRP run, we get larger lot sizes, which again affects our incoming material schedule, generally expediting. We see this lot size variability in cases where the demand is unchanged - if the demand changed we fully expect changes to the incoming material schedule. But, we do not expect to see significant changes when our demand does not change.
Both plans will be valid, and meet customer need, but telling our suppliers to expedite an item one week, and two weeks later telling them to postpone an item is not an ideal situation for our suppliers.
I’m trying to understand this behavior, so we can develop a proper method to control/minimize “boomerang” purchase suggestions.
I do realize that fixed lot sizes could be a part of the solution. But Days of Supply can play a role as well (if on a subsequent MRP run, an extra demand line falls within the Days of Supply range).
Any thoughts on this? Have you experienced anything similar at your installation? What tools might you have tried to minimize purchase schedule variation that is driven by lot size variability?
A final note - our core raw materials are quite expensive, this is an aspect of Epicor planning that we want to nail down as much as is possible.
consider playing with the reschedule in/out deltas to eliminate the extra reschedule messages… example, if you set the reschedule out delta to 21 days, the system will ignore any reschedule out message unless they are over 3 weeks different. Same for Reschedule in delta.
The other option is to change the planning timefence, which will stop any suggestions within the timefence window (time fence is calculated as days from today). if you set the timefence for 14 days, then anything between now and 2 weeks from now will be ignored. personally i do NOT like the timefence, because the system will also never tell you to expedite within that window.
I hear you, Tim, but these changes are a lot more extreme than the deltas would explain. We have added delta-in and delta-out in order to reduce the overall glut of suggestions, but we proceeded with caution as that can hide activity that needs to occur. I think we are in a better spot on those items now.
There is something else going on here. We had a part that told us to push material out five months, which we negotiated and got our supplier to agree to. Now we have suggestions to move it to almost the exact date it was originally scheduled.
I do appreciate your prompt reply. We’ll figure this one out, in the meantime, I’ll keep updating this thread as we learn more. I’m starting to think this could be an “us” problem, as the part affected has some unusual inventory transactions that we perform to delay invoicing to the customer. Don’t get me started on that one.
The inventory transactions referred to are being done at the correct time and in the proper way. I had theorized that the transaction was done after MRP ran, but that is not the case. That is not what is causing this, it appears to be a relationship between days of supply and variable lot sizing. We have a second part that boomeranged, it does not have the same set of inventory transactions as the first part that exhibited the behavior.
I have seen “urgent” purchasing suggestions (made when inventory currently below SS) to behave differently than non urgent suggestions. For example, below SS the part is due immediately and it is not ordered based on minimum order quantity that’s not input in urgent parameter area. Could this be part of the problem?
Showing a screen capture of your timephase might help the group make suggestions as well.
We have a rather unique set of transactions that occur due to delayed invoicing. The end result of the three teams of folks who do the actual transactions was - a bad schedule prior to our weekend MRP runs.
Explains everything, and I’m grateful to our IT guy who did the heavy lifting to find out what is occurring. He actually pulled daily backups, restored them to the test environment, and parsed the transactions. What he found is that although we run MRP on Sunday evenings, the reconcilitation of the prior week’s transactions occur during the business day on Monday - after we’ve already started working the suggestions!
We’ll flowchart that process this week, and come up with a set of transactions that allow the other areas of the business to operate without screwing up our demand profile.
