We’ve had some confusion in regards to how Epicor BOMs work. More specifically we had previously thought on an Epicor BOM we could specify the part number and the rev(there was a field in Eng Workbench where you could select a rev), but we were getting suggestions from MRP to build the wrong rev(not what we wanted) in cases where we had multiple approved revs. After digging more into this, my understanding currently is Epicor BOMs call out a part number not a rev(the field in Eng Workbench to specify a rev was added as a customization and didn’t do what we thought). Further, if there are multiple approved revs then Epicor looks at the effective date on the rev to figure out which rev to use. As we learned this we realized we had a problem as we needed more control than what Epicor offered, on some parts we needed to be able to explicitly call out the rev in addition to the PN on the BOM. As a result our plan was to start encoding the Rev in the part number for these parts, so we had the level of control on BOMs we needed(specify pn and rev).
In recent testing by others it was reported all we needed to do to get the level of control we want is to check the view and pull as assembly flags as with those flags checked MRP suggestion for parts with multiple revs were now selecting the rev we want. This has me scratching my head, as I don’t understand how view or pull as assembly would have anything to do with what revision Epicor chooses. I thought view as assembly was a user interface flag to let us see the subassembly, and pull as assembly is how we tell Epicor if we pull this part off the shelf or if we need to manufacture it. Do I have a hole in my understanding and the pull as assembly/view as assembly flags do play a role in what rev Epicor chooses to use for MRP suggestions when we have multiple approved revs?
PS I hid the field in Eng Workbench where we could specify a rev when I found it was added as a customization, so maybe there really was something to that field after all?
I recall a topic from a few years ago about how Epicor determines which is the “latest” rev. I believe it goes by the date the revisions was changedeffective date of the revision.
Say you have three active revs A, B, and C, and they were created in that order. Epicor will assume Rev C is the one to use in BOM’s that specify the part. If Rev B was tweaked, it now becomes the “latest rev”.
In the Part Maintenance program, the checkbox “Use Part Rev” is selected by default, and when selected tells Epicor to use the “most current” revision when MRP runs REGARDLESS of the revision selected in Sales Order Entry (“most current” means the one with the most recent Effective Date).
LIMITATIONS:
This only works for the top-level assembly part number, and only for MRP-created make-to-order jobs . Out of the box, MRP will ALWAYS select the most recent revision of any manufactured subassembly. If you want to specify any other revision for a subassembly, this will require some sort of BPM(s) and Customization(s).
From the system 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.
@Ernie How could we create demand for a part on a bom(not the top level).
So as an example we have part TopLevel that includes a part Child on the BOM. The part Child has approved rev A and rev B. When we get an order for TopLevel Rev A, but based on effective dates rev B is the effective rev how could we create demand to tell MRP we want to build Child Rev A?
My understanding is to get this level of control we need to rename the part Child to Child_RevA(encode rev in part number) so on the TopLevel Rev A BOM we can call out the Child_RevA part so we can be sure MRP always suggests the rev we want. If there are alternative ways to achieve this same result it would be nice to know what our options are.
Eddie,
This kind of hearkens back to the age old discussion of revision control. Do we take a new part out or a new revision? My understanding has always been if a part’s form/fit/function changes, it should be a new part number… which is essentially what you’re doing by appending the revision into the part number. It sounds like your part revision really should be a new part anyway…
Why do you keep multiple revisions approved? I’m asking because our company doesn’t do this so I’ve been brainwashed to unapprove older revisions.
If you embed the revision in the part number, and you sell that part number to other customers, it may have the effect of really screwing you up. If this scenario is customer-specific, then that would be a valid path.
I don’t at all disagree with the form/fit/function theory of revision control, but there are cases where Epicor’s default method of handling that do not fit with what a business has to do.
In one industry I did an implementation for, the customer actually owned the drawings and specified particular revisions on subassembly part numbers. Epicor does not support revisions on material components. We had to customize the Engineering Workbench with a “Revision” UD field, and then also be able to copy that field to the PartMtl table, and then write a BPM so that MRP would recognize that revision and copy it to the job.
In the end this implementation did NOT utilize this functionality, but we had it working.
@dr_dan The main reason I understand is customer requirements, sometimes it’s the industry(e.g. medical ISO 13485 requires this - verification/validation of a new revision before it can be approved and used in production). Although some customers aren’t required to do this it’s the same idea, before they go to mass production they want a first article. Please note I’m not in a customer facing role so don’t hear all the explanations, but I’m told this is a pretty standard requirement(I’m sure there are other reasons). I believe this rarely comes up for standard products, but is primarily an issue for custom products(product developed for a customer).
So the pull as assembly flag would create a make direct subassembly of the lower level mfgd part which would end up on the job as a Assembly 1, 2 3 etc. If you want that job hierarchy then you can mark that lower level mfgd part as nonstock and setup the BOM according. I thought that in this scenario you could specify the revision level of the lower level part becase it is non-stock make direct. I could be wrong and it has been a couple of years since I was with the company that did exactly this.
Brad
@bboes where would you specify a revision level. As far as I know on a BOM in Epicor(Engineering Workbench) you can only specify a part number, where could you specify a rev for a part on the BOM(in what screen)?
Sorry, I cannot replicate what I was remembering. The company used a lot of phantom BOM’s setups as well. The effective date is controlling what revision gets pulled in on the Eng WB and what shows up on jobs. Sorry.
Might be a little late to the party but we utilize Epicor the way you suggest. We came from another ERP system where the revision was separate of the part number, and we set up our SolidWorks PDM that way. We functioned as 12345A and 12345B were two separate part numbers and their form/fit/function may or may not have been similar. We were excited when we saw that Epicor had a true revision control functionality until we learned that revisions needed to be truly interchangeable - we manufacture OEM machines with a slew of subassemblies and machined parts. If a part is changing say an outside process callout (plating instead of anodizing), then we could do a revision bump in Epicor. If a bolt pattern or thickness changed and the part was no longer truly interchangeable, we could not do a revision bump. The way I understood it is that Epicor does not look at the revision of a child in a MOM or a job so it will pull from inventory, pull the subassembly or create a job at the latest approved revision due to it believing all revision are interchangeable. We had to do what you’re suggesting when we transitioned to Epicor - put the revision WITH the part number and use the true Epicor revision as what we call “minor revs”. So if we’re just changing an outside process or print callout, we use a minor rev bump. If it’s truly a different part (form/fit/function), we “create a new part number” 12345B. This is the only way it worked for us.