I’m part of an implementation team for Epicor 10 and facing an issue with revision control. Everything is built to order based on customer drawings for aerospace so a number of hoops to jump through for traceability. The company is not making use of internal part numbers and using the customer’s part number instead. One of the requirements to account for is tracking past configurations.
My initial thought was use the scheme of “Part Rev X” and utilize the revision control through engineering as the internal revision. If a new customer revision were released, the part would be duplicated and the internal revision process would restart. Unfortunately, a customer part number can only be associated with one part so we can’t have the same customer part number with different revisions. It is possible for different customer revs of the same part to be active and in production at the same time.
One of the team members suggested including customer and internal revision in the rev field, but then that requires customization to ensure our internal rev isn’t going to be on external facing documents.
Has anyone ran into a situation like this before or have a suggestion on how to approach this?
Have you looked at the customer part cross reference? You can use your own internal part number in the part master and link all the customer parts you want to it. You can even print the customer part number on all your documentation.
The second customer part reference with a different revisions give an error saying there can’t be duplicates. Definitely a bummer since it seemed like a clean way to handle this situation.
John, I see that you had posted a similar thing back in 2017. Did the alternate methods end up working out for you? Playing around in part entry is making this seem like a great solution, but I need to run through the whole process to see how it shakes out.
That was a while ago. The plant ended up closing because it was losing money so I never got it fully implemented. What we had laid out and tested it did seem promising. Let me know if you have any questions and I will do my best to dredge up those memories
I implemented something like this a year ago. I went with combining customer and internal revs in the one field, delimited with a “/” so I could parse it out later. So rev A would increment to A/01 the next time they modded it. I enforced this with some BPM’s. It took like a day to test it all out.
Bigger issue was enforcing actual rev control in the system. Epicor is lousy about that. Check-out, make change, check-in on same rev. So I had to build a whole customization that disabled that and forced them to make a new rev each time, but also made it easy to pull the old MOM (including all alt methods) forward. That one took a while to hash out and I’ll have to rework it when we go Kinetic as a custom button triggers all the magic.
If I was doing it over, I might just override the check-in method to auto-increment the rev if it already exists. Probably would’ve been easier, though that’s hindsight talking. That’s likely the route I’ll take when I have to rework it.
That is another approach we are looking at, but I’m attempting to limit amount of customization and as much as possible out of the box which is probably silly, but with the last system we had that went sideways I’d rather be overly strict about things to start.
As for parsing out the rev was that mostly on the external facing items?
I do like the idea of auto incrementing the internal rev and removing that bit of decision making away from the users. Maybe less prone to break that way.
The alternate method is looking good so far. A primary alternate can be set on the Site/Planning tab for the part which should pull that end of the base method. Quick Job Entry automatically pulls up that alt method, but haven’t tested with the many other means of creation. Why it allows the primary alt to be something isn’t approved is beyond me, but a simple BPM can address that. Once you unapprove an alt method the system rightfully complains if you try to use it which is good.
I could just be blind, but I’m not finding an ID for the method details used to populate the job once created. If Get Details is called from the Action bar then then Memo program will reference the rev and alt method ID, but the source for the details on initial creation doesn’t appear to be captured. Do you recall what your plan was for getting that ID once the job was created? The memo part is great for changes after creation, but without capturing the ID it will be harder to sell.
We also try to minimize customization, and when it’s unavoidable, tailor it to use the built-in functions as much as possible to minimize the amount of custom code within the customization. This also means sticking to the BPM widgets whenever possible. Knock on wood, but I haven’t had to redo a single line of custom code through 2 point updates and numerous patches.
Having said that, I prefer a customization that brings clarity to the system over a more boxed solution that just kinda hacks around the problem. In this case, a rev is a rev regardless of whether or not it was revised by customer change order or internal process improvement. People grasp that quickly enough. Alt methods aren’t quite revs, and you’re having to work around that fact PLUS you now have to train everyone on something that isn’t entirely intuitive on its own.
The alternate method ID. It gets logged when get details is used on a job, but the initial creation doesn’t appear to store that anywhere.
Part of the company’s requirements is to have a unique ID for the configuration used on a job.
So if we had:
Part: Foo Rev: A Alt Method: 01
Part: Foo Rev: A Alt Method: 02
…
Part: Foo Rev: A Alt Method: 11
If we have to go back for an audit, we wouldn’t be able to say job 99 used alt method 01 for Rev A and this job 103 used alt method 02 for Rev A.
The revision on a job will narrow it down some, but without a comparison to the methods it would take more than a passing glance to discern what method was used.
