EPICOR picks the newest revision when creating MRP Jobs even when the Sales Order has an older revision on it. This is not what we want as it could result in us building/buying the wrong revision.
Is there a way to change this behavior or other suggestions?
Below is our current MRP process settings.
Check the parts in part maintenance, there’s a setting there “Use Part Rev” that needs to be unchecked to pull from the sales order.
From Field Help:
Use Part Rev
Select this check box if the Material Requirements Planning (MRP) should use the highest (most current) revision available of the part. If the check box is selected, an entry of the part number automatically specifies the most current revision.
If you clear this check box, you can manually create demand in MRP for different revisions of the same part, and the Epicor application honors the different revisions.
This option does not apply to requirements for stock. This check box has no effect if you do not use MRP.
From MRP user guide:
The Use Part Revision modifier indicates how you want the MRP engine to determine the revision level for
non-stock parts. You define this value on each part record that is defined as a non-stock part.
Select or clear the check box to use this calculation. This is how the MRP engine uses this modifier:
• When this check box is selected, the MRP engine calculates the suggestions using the current revision of the
part. The part number on the suggestions automatically displays the most current revision; the application
calculates this by using the most recent Effective Date on an approved revision. Also note that if an unfirm
job exists and a new revision is approved, the MRP engine creates the suggestions using the new revision.
• If this check box is clear, the MRP engine uses the revision level that is defined on the sales order that created
the requirement. Thus, the MRP engine creates job suggestions based on the revision required for each
customer.
If you do not use MRP, this check box is not available. This functionality is also not available for make to stock
part quantities; it only runs if the Make Direct check box is selected on the order release.
if the sales order is not make direct, then it will always use the current effective rate based on the effectivity date. It doesnt matter if the Sales order references a different revision for “Stock” items. This is because the system does not track qty by revision.
Wow that needs a much better name than “use part rev.”
Yet another setting I never knew existed. Or rather, I was incredibly off the mark in understanding what it did.
I know at least for our company, we use a configurator, and all our orders are “make direct”. It doesn’t matter if that box is unchecked. Sales order revision always drives what’s in the resulting configured Job. So I’ve never had much use for it.
samsies
@timshuwy it sounds like if we uncheck “Use Part Rev” in Part Maintenance it will force MRP to pull the rev from the sales order in the case that we have more than one approved rev. Is my understanding correct?
If we want to test this out I’m thinking I can go to this one part and change this setting then wait for MRP to run and verify it now uses the rev on the sales order. Am I on the right track?
@timshuwy Thanks!!!
If the order is not make direct and say we have two approved revs, rev D and rev E. If we want MRP to chose rev D until Jan 2021 could we set the effective date on rev E as Mar 2021? If not what would be the right way to go about this?
@embedded All your revisions can stay approved. MRP will use the most recent effective date if approved. In other words in your example it will use REV D up until you reached REV E’s effective date. If you want REV E to start showing up in MRP in January you would set it’s effective date to Jan 1.
Yup… what @JimA said…
Rev D is approved, effective 9/1/2020
Rev E is approved, and has a future effectivity of 1/1/2021
MRP will continue to make Rev D until 1/1/2021 when it will start making Rev E. So… you could have two revs in JOBS at the same time, but it doesn’t matter what the sales order says. the system will make the current rev, and will ship whatever is in stock, even if it is the old revision.
@timshuwy We tested this out but it didn’t work. Please see screenshots below.
We verified the Sales order was make direct, and we verified the part had Use Part Rev flag cleared(on both the parent and child part). We then reran MRP but the MRP suggestions for the child part are still the wrong rev(not the rev on the sales order).
Please note the sales order is for the parent part that we sell(TS-INGERSOL Rev D), the MRP suggestion if for us to build more of the child part(UT-INGERSOL). The way we use revs is the child part rev corresponds to the parent part rev(so rev D child rev goes with rev D parent). We’re wanting the MRP suggestion for the child part to have the correct rev(the same rev as the parent part on the sales order). This leads to another question(possibly the source of our problem), a parent part calls out the child part in method tracker but doesn’t call out a rev. How does it know what rev to use(for a child part)?
Time Phase:
I think this fights against the classical notion of a “revision.”
My view/training on a revision is that it a newer one should always be backwards compatible with an older one. So the idea of demanding that your shop floor using an old revision to build something new is going against this notion.
I get what you are after - you can specify a rev at the sales order, so how to cascade that down the chain (the indented BOM), or why can you not do that.
But if the designs are that far apart, it seems like you really need different part numbers.
Look, we are guilty of that here, too. Revisions that should be new parts and new parts that are really just revisions. It can become a matter of preference.
I guess to that end, though, I don’t really get why a sales order should specify a revision. I don’t really understand what business it is of anyone except to use up old revs and ensure that only the newest ones are being built or bought.
I guess I danced around this. I’m pretty sure it uses standard logic - newest (?) approved rev as of date needed. So it seems the part rev on the sales order can only go so far. I mean, how else would it know to use a different rev, except for dates?
Thanks so much for your response. I see what you are saying, but I believe our situation is different than what you describe. That is the two revs are not very different, rather it’s a matter of our customers working in a highly regulated industry(e.g. medical), so changing revs requires lots of approvals on their end.
As an example in the medical industry, if we have an established customer purchasing volume of a product (rev A) and they make a minor change request such as if you could change this connector(think of a motherboard) to a 90 degree connector(rev B) it would make it easier for us to plug in our cables. In this scenario regulations state they need to receive rev B boards and verify / validate them before they can use them in production. As a result they will need to continue to place orders for rev A boards for production, and rev B boards for engineering / quality purposes possibly multiple times in case additional changes are need for Rev B before they can get them certified for use in production.
If there are any suggestions on how we can manage these situations other than for people to keep a close eye on what rev to use when MRP makes a suggestion(people remembering = error prone in my experience) it would be greatly appreciated.
Ah, no kidding. I never imagined the end user would know and care about revisions.
To be cynical, I would say that even if there was a way for Epicor to manage that, you’d still be better off creating new part numbers (even if the number is 12345revC).
I think sometimes we try so hard to make the system jump through hoops when in the end it’s still a human gatekeeper that controls it all anyway.
The problem is that out-of-the-box, Epicor does not let you define a revision at the component level. By default, MRP will always choose the most recent Approved revision for a component part (using Effective Date).
To make this an automated process, you’d have to add UD fields to both ECOMtl and PartMtl tables, and then add a Data Directive BPM onto the JobMtl table so that MRP can use that revision instead. I’ve never actually taken it that far, but I have discussed it with a couple of clients who had the same need.
BPMs on the MRP Process are somewhat less daunting than they used to be, but they still make me break out in a cold sweat. <<WHAT COULD POSSIBLY GO WRONG?>>
Definitely sweating after reading BPMs and MRP.
Thanks for the options, I’m not confident enough to mess with MRP via a BPM. For our standard products the standard functionality works well it’s just for custom designs that we run into these issues so I’m thinking we might just go the route @jasonmcd recommended - encode the rev in the part number.
I would be cautious and careful going the route of adding the Rev to the Part Number. We have sadly taken it a bit to an extreme and are now working to walk it back a little to lessen the noise in Supply Chain, Production Planning, and ECOs. We’re starting with changing the mindset and forcing UAI changes to be a new Part Rev instead of a new Part Number. We’ll be tracking inventory by Revision by using Lots that will include the Rev received to stock.
Personally I think some additional datapoints can be added to the PartRev table along with Eng WB to strengthen the link between Material Part Revs and their parent parts as well as the Epicor references that are Part Specific out of box. This could then really free up the Part Number from needing numerous changes for things that ultimately don’t have a huge impact to it’s Form, Fit, or Function. This should also help us avoid needing customizations or BPMs to MRP, which honestly sounds like a nightmare.
How does this work if the items are a part of a sales kit, since you cannot make a sales kit “make direct”?
