I see what you’re saying. a bottoms-up approach instead of a top-down approach.
That might be a big pill for my company to swallow, hahaha.
For us, we go top-down.
Create a “Part” for the final “Machine” and kick off a job. We then engineer portions of the “Machine” as sub-assemblies (with their own part numbers, BOMs). As they’re engineered, they’re then added to the job as SubAssemblies.
Pretty straight forward… but there are times things get missed and the finger-pointing starts. Engineering gets completed but it never hits the job. Was it ever communicated to the manufacturing group? Did manufacturing forget? Did they sit on it?
Exactly David, because when you think about it, you are going up, you’re building up to the final idea and starting at the bottom. Truly, we are. And when you look at it all when it’s finished haha it IS top down!
Also, if the customer starts to work on idea 2, then engineering has to add idea 1 as a material to it and then release it to production, nothing could be missed cause idea 2 always includes idea 1…
Well, for us, we know the top level. We know we need a “Machine” with a specific design.
For example, we know we’re making a truck. We know it needs a transmission, (4) wheels, electrical etc. So we kick off the job for the truck. Engineering determines the required speed and power of the transmission… releases it. Engineering determines the size of the wheels, and releases them. Engineering determines the electrical requirements, and then releases them.
So… its relatively straight-forward. But yes, the customer may always make changes. “I wanted a 8-Track player, not DVD player”. “We need 18” rims, not 16". So… changes are always possible. But at the end of the day, we know the overall structure of the build… just have to wait for Engineering to design where all the cup holders go.
One way to do that is to create a dummy job, then get details on the top level part. If it’s all set up to go together in the master bom, then that job will pull in all of the stuff, and you’ll have apples to apples to compare to. You’ll still need to do a dashboard to compare them, and the assembly seq number and all that are not going to match, so you’ll probably have to do some summarizing to look for changes.
You also could get details in a quote which would be a little less dangerous as far as getting suggestions by accident.
So if you don’t want to make a CTE to build the BOM, you can do it that way. You would have to have a “Check” process that someone goes through to do that though, in building the job or quote and getting details. If you go about with the CTE then you can just run the query.
There’s a “Revision Compare” menu which, I thought just compared one part revision to another. But it looks like it WILL compare a Part Revision to a Job…
Could be a promising start, I just need to try to figure out how it is presenting the results of the comparison.
We created a solution for this but it hasn’t gotten great traction for use, so I’m not completely sure that it hits the mark. I suspect that the person who requested isn’t the person who should be managing it, so you know how that goes. Anyway, it might be useful for you to see our solution to get ideas. (We found the rev compare too noisy.) In summary:
Upon add material or add operation to a Job, a BPM checks whether there’s an approved method and if so, it automatically checks added operation or added material upon the addition. (note users can uncheck if seems erroneous to mark as added) Another BPM saves any deleted operation or material from a job that has an approved method to UD25.
After that, there’s the Job Added Matls or Opers TUSA dashboard that provides the interface for reviewing the additions and deletions for closed jobs. It’s under engineering.
Here is a screenshot of the dashboard along with instructions and ability to checkoff review.
We are in the middle of an Epicor implementation and your process sounds similar to ours. We engineer the machine and release items as we design. Typically releasing items early is dictated by lead time. A manufactured weldment may have a couple thousand hours of weld so we want to get started as soon as it is engineered. However, the upper assembly may not be completed in engineering yet. This has been a sticking point for us in our implementation so far.
Is this similar to the process you are describing? If so, how does your company handle this process?
Side note: “Release” is our term for notifying manufacturing that a part or assembly is ready for them to begin building.
Yes, you’re 100% with me on how we handle things. We also use the term “release” when items get passed from Engineering to the manufacturing job.
I would say, for the most part, Epicor manages this type of activity well. We’re still doing the engineering release notifications outside of Epicor, communicated internally via email. So, Engineering completes a subassembly and they notify manufacturing that it is released, and then someone in our manufacturing group adds it to the job.
Where Epicor appears to be lacking is in a good way to compare the Engineering BOM vs Job BOM. In their defense, it can get pretty ugly. As subassemblies get attached to a job, they’re assigned the next available assembly number… same with material parts. So this makes it tough when trying to compare the bills side-by-side. The order they appear may differ.
Another thing that throws everything for a loop is… Engineering releases a subassembly to manufacturing… Manufacturing decides to sub that subassembly out (subcontracted). So, we often go searching the job for an assembly, only to find the part number as a Material (purchased) part in the Job BOM.
I don’t think there’s an “easy” solution. Our guys have gotten… decent?.. at comparing manually. I think the real concern is, again, Engineering “releasing” something but it never gets added to the job, so it doesn’t get manufactured / purchased until someone catches the discrepancy.
something @Chris_Conn showed me a few months ago is to use BomSearch.GetDatasetForTree to get the current bom. if you started with a baq of the job you could make it updatable and use the tableset to match parts and operations in code.
I could provide the dashboard but I’m not sure how useful it will be to you. Per the details in my post above, you need to use a UD table, mine in baq/db/bpm is UD25 to note the deleted rows of data. Also, my current version of Epicor is 2022.2, would this work for you? We are not using Kinetic screens / dashboards yet.
Let me know. Also, if you want to provide info on what problem you are experiencing, you might get additional recommendations from folks here that you may not have thought about.
@dcamlin
Have you looked at Revision Compare Process - standard functionality?
You can put in a quote, part, job, or engineering group and compare to another.
Click the compare button to see what is different.
Hi @LarsonSolutions. Yeah, I did mention that dashboard above in this thread. It has come a long way! It was very difficult to decipher initially but they made some improvements in 2024.1 or 2024.2 that makes it a little more clear.
I guess I can’t say I use it personally (to many other things to worry about)… but I did introduce it to our engineering team, so, hopefully they’ve explored it!
One issue is that we saw with the Revision Compare Process is that when compaing old revisions the material revisions are not correct for us. The child revision shows current child revisions, vs. the revision of the child when the parent was at the selected revision.
We did have to create a custom compare tool to “fix” that.
