Epicor 9 scheduler ignoring contstrained material. WHY?

We are new to Epicor scheduling and whether the Scheduler runs through MRP or we do it manually, Epicor never moves out jobs that have a constrained material against it. Can anyone shed some light on what me need to check and make sure of in order for the scheduler to take this into consideration. We are wondering if there is a bug in the software or something. We are on 9.05.702A. Thanks

Mike Abell

the same scheduling engine runs in Global Scheduling (which schedules all jobs, firmed or unfirmed) based on the calc global scheduling priority list as it does in MRP (which can only scheduled suggested jobs, not firmed and released jobs). Material constraints are recognized as constrained if the flag constrained material is set in part entry, it is also viewed as constrained if it has a purchase direct PO against it. I feel like I’m missing one other scenario but there should be overrides for constrained material in the parameters on global and MRP to get past this. It hasn’t always done a good job in ignoring purchase constraints though. So in short when you run MRP it will schedule the jobs it creates as suggested job. Both functions have an ignore constrained materials. YMMV by version, but it’s always done well by Part Material Constraint Flag, you may have to verify purchase constraints on your end. Use Time phase to run those down along with purchase advisor.

1 Like

Thanks Rob, the problem we are seeing is the scheduling engine is IGNORING the fact that we have constraints set, it’s not taking them into consideration at all and we don’t understand why. We make sure we DON’T have the “ignore constraints” option ticked when we run the schedule but it doesn’t seem to matter. Epicor hasn’t been any help so far either.

Best regards

Mike Abell
IT Manager

Flexial Corporation
a company of BOA Group
1483 Gould Drive, Cookeville, TN 38506, USA

Phone: +1 931 432 8408
Fax: +1 931 432 1889
Mail: mabell@flexial.com
Website: http://www.flexial.comhttp://www.flexial.com/
http://www.boagroup.comhttp://www.boagroup.com/

are you seeing the same behavior in isolated testing on both sides (MRP and Global)?

Yes, doesn’t matter if we let MRP do it or we kick it off manually.

Best regards

Mike Abell
IT Manager

Flexial Corporation
a company of BOA Group
1483 Gould Drive, Cookeville, TN 38506, USA

Phone: +1 931 432 8408
Fax: +1 931 432 1889
Mail: mabell@flexial.com
Website: http://www.flexial.comhttp://www.flexial.com/
http://www.boagroup.comhttp://www.boagroup.com/

ok, you can kick me for asking this, but i got to… You are licensed for APS right?

I am seeing the same issue in V8. We just licensed APS, and I cannot get material constraint to function at all. When enabling the flags, the parent item (that consumes the material we wish to constrain) gets no planned jobs created at all!

Is there any user out there who has achieved functionality of material constraint?

@Gil_V You can temporarily remove the material from the BOM at issue and try scheduling again, then does the parent product get jobs scheduled or suggested? If so, then you can be sure that this item is the one that’s preventing job scheduling of the parent, and in that case you can look to replenishment and PO suggestions as to why it’s not being counted as being there in the future in Time Phase. Otherwise the parent’s job isn’t being scheduled for some other reason. In our case it’s usually been that we’ve inadvertently forgotten to mark a part revision as approved. HTH

Monty - appreciate your reply. I am really at a tough spot.

The system is just not constraining in the manner we need. So far, we can get the planned jobs to honor the 1st material receipt date (so no jobs get planned to start before that date). But, after that, all bets are off. The system just keeps planning jobs as if there is an endless supply of material. Time phase for the constrained item goes waaaaaay negative.

We’re paying some serious cash to an Epicor consultant (through Epicor) to resolve this. I am of the opinion that material constraint does not work properly in our version (V8, incidentally). That would be a significant problem for our implementation, as material lead time is the majority of our product lead times.

Here’s hoping that I am wrong, and I’ve overlooked something. I have read the entire MRP and Scheduling technical references, and cannot find anything that I might be doing incorrectly.

Hence my original question - has anyone ever successfully seen material constraint function as expected?

Edit - We worked around the parent/child job thing by selecting the “pull as assy” switch on the lower levels. That resolved the issue with different BOM levels not planning appropriately.

Epicor handles constrained purchase parts one way and mfg parts (subcomponents) another way. For the mfg part to be constrained, it has to be a Make Direct part (Make to Job). MRP autocreates these links if you have the part set to non-stock or non-stock and qty bearing. It’s a real shame constrained material doesn’t allow a simple lead time for constrained lower level mfg items without make direct.

Here are the instructions that I’ve written to constrain material in the “current version” of the software. If executed, this will work, as long as the version of the software you are using functions properly. This may be overkill, but we spent an enormous amount of time validating that constraint did not work in V8, and does work in the “current version”.

image

Thank you Gil for sending out this detail. #9 was a surprise to see on your list. I’ve never learned much about the processor and scheduler counts, but I guess I need to do so.

On the subassembly constraints, I was also told the “Multi-Job Scheduling” does a better job than previous versions of making sure the subcomponent job stays a constraint for the parent, but I’ve not looked into it enough yet.

Thanks again for the detail.

It was an enormous effort getting to this point, but I can say with certainty that if these steps are followed, a constrained item will not go below zero in
Time Phase.

image007.jpg