We have difficulties keeping our engineering part drawings the same rev as the method in Epicor. Frequently we have changes to a drawing that do not affect the BOO or BOM, but we need and want to have our approved Part Rev Method jive with our drawing (autocad) rev.
For Engineering, the current method of needing to pull details from old rev into new one is a big pain. We have two plants where we do manufacturing of both top level and lower level parts, which makes it even more of a hassle, needing to ensure using Engineering workbench opened on correct site.
Does anyone have a solution they’ve done or thoughts on how best to do this to share?
Where you store the AutoCad drawing rev in Epicor.
On the part master, Rev sheet - PartRev.DrawNum
EngWB, Rev sheet - ECORev.DrawNum
set up the CAD drawings as part masters and include their numbers/revs right on the BOMs as materials
as attachments, CAD viewer, some other?
Who uses drawing revs and what potential issues when a part rev isn’t the same as the drawing rev?
I’m guessing the practice at your site has been to always match part/dwg and users will assume something is wrong if they don’t? And this results in (extra) maintenance whenever the dwg changes, even if it really does not affect the part/methods?
To get around this dilemma, I’ve seen some sites that ended up “decoupling” the drawing numbers/revs from the part number/revs. e.g. assign unique numbers/revs to the drawings and then reference those in the part master or methods. (Which I prefer but… definitely will not be the most popular with everyone when you ask around).
Thanks for your reply.
We store the drawing on the Part record as attachment. We only want the latest revision attached. When we attach we only use the drawing number in the filename (no revision) and it is a visualization file. We run a nightly automated task that copies latest CAD visualization files to the repository that holds our Epicor attachments. We use AutoCad vault for the checking in and out of the drawing and the automatic creation of the visualization file when the drawing gets checked in.
With this method, when a drawing gets bumped up a revision and checked in, Epicor automatically has the most recent approved drawing attached the next day. However, the part revision in Epicor now needs to get bumped up. If a user gets a drawing and the revisions do not match, there is concern about whether it is the latest approved drawing, whether it is the correct drawing (eg sometimes people duplicate parts and forget to remove attached drawing that is not correct) or if something went wrong with nightly automated task… We also have some pdfs of old drawn files attached, and have need for those revisions to jive with Epicor part revision as well. These are few and far between.
It certainly would be easier if the Epicor part revision did not need to match the latest approved drawing revision, but I don’t think the people here will go for that since it has occasionally shown to be erroneous.
Since my original post I’ve been toying with using a DMT w PS script to pull the data (via BAQ export in DMT) and then load it back up via DMT with new rev. It feels a bit brute force, but I think maybe if it can get running smoothly then it could be a viable option. We hope to upgrade within next two years. I’d think that a DMT and PS method should stay feasible…
Please continue to let me know your thoughts and ideas.
Hmmm… now I’m wondering if a BPM could remove attachments when parts are duplicated? (and now that I think about it, there are other things I might like to clear at the same time).
Yes, I personally prefer to “decouple” the part and dwg numbers/revs but if people are aren’t already used to it… good luck trying to convert them.
Possible to query E10/CAD systems and locate only the discrepancies?
One way I have seen Drawing Revs handled is to create a new UD Field in the PartRev table called DrawingRev_c. This field is to store the current drawing revision that is used to make the revision of the part. This allows you to update the drawing revision without changing the part revision. This is especially helpful if you have “key drawings” where the drawing is updated many times because the key drawing actually describes many part numbers. At one company, we actually created a new UD Table to store the Drawing Numbers, and then in THAT table, we also stored the current revision of each drawing. This way, when we updated the drawing, we only had to fix it in the one UD Table… then in the PartRev screen (and job traveler) we looked up the drawing number to find out the current drawing revision.
Thanks for your info on how you’ve seen it done. The “key drawings” functionality with a one to many relationship with parts sounds like it would make it much more palatable to have a separate rev/ud field tracking the Epicor revision. We have one part to one drawing setup… I’ve started down the path of a powershell script for pulling and then reloading the data with new rev. I suspect this’ll be an easier sell than differing rev designations.
Thanks Bruce. I agree, dropping the attachments on duplicate is probably a good idea regardless of direction on this. We also clear out some other data, so why not attachment too?
I have pulled the vault revision data for compare to Epicor and I do plan to get it synced where it is not, via a DMT cleanup. But I still need a means to make it easier for engineering to keep them (drawing rev and method rev) synced, which translates to ease of making new revision on method, as needed.
What engineering would like is to just be able to change Rev.0 to Rev.1 on the Part Rev, when there is no method change associated with drawing rev change… I’d tell them to “suck it up” except they have some sets of parts with same drawing number that only differ in last 4 digitt (matl code) but all methods need updating on single drawing change. It really is kind of nasty. .
I guess that’s what we get when we try to maintain two sets of data in two places the same.
I can sympathize, the engineering dept was my home before I got into IT.
The only other idea off the top of my head… if an updateable dashboard could handle needs?
Thanks Bruce ~
I thought oh Updateable DB would be nice. It will not work using normal tools and widgets from the looks of things… no access to PartMtl or PartOpr tables.
The entire subject of revision control can get really complicated:
Method of Manufacturing Revision - This is a revision in HOW you make it, and what you make it with.
Part Revision - This is a revision to the actual part itself… changing the Method of Manufacturing revision does not necessarily change the part’s revision… fit/form/function doesnt change just because I make it on a different machine, or if I use pre-cut glass vs sheets of glass that need cut up… BUT if I change the type of glass, it changes both the Method AND the Part Revision.
Customer Part Revision - you might have a customer who has their own part number and their own revision. Their revision might have changed because they matched it to your part.
Drawing Revision - the drawing may have its own revision (as in the case of Key Drawings). the drawing revision is updated, but this doesn’t change the finished part’s revision. Also, there are some cases where one part may have multiple drawings, and some drawings my be at different revisions. Drawing revision 5 might be describing revision B of the part. Revision 6 is to correct some wording on the drawing, but doesn’t update the part.
Where I used to work, we had to match all these up when an order was placed to make sure that the customer Rev matched our Rev, and our Drawing’s rev.
Thanks Tim. That’s an excellent description and I plan to bring this up with our interested parties here. It’s as if you’ve been dealing with this stuff for years. Your insight is greatly appreciated!
You described the exact situation we are straggling with.
We have a lot of multi part drawings. Some of them include more that five hundred parts.
When drawing revision changes, it needs to be pushed down to all parts.
For example, Drawing number 2-xxxxx includes the multiple part numbers such as 2-xxxxx-001, 2-xxxxx-002, and etc. up to 2-xxxxx-526. Initially, we do not want to enter the revision for the individual part. Revision needs to be assigned to the base drawing 2-xxxxx only. An individual part must pick-up the revision automatically, because it must be printed on the Purchase Order, Receiver, Work Order, Traveler and etc.
We cannot figure out how to deal with it in Epicor ERP Version 10.2. We used to have JDA Make-To-Order, which handled the multi part drawings and revisions nicely. We moved the entire business to the other site which uses Epicor and had never used the multi part drawings.
I was wondering, if it is possible to to create a Parent-Child relationship between the base part (non production item (drawing) 2-xxxxx) and the production parts 2-xxxxx-xxx in the way, that the revision of the base Parent part/drawing automatically propagates to the all Children parts. Basically, to do a global change. Can the Engineering Workbench be used to accomplish this task?
The User should be able to do that change without asking the Epicor administrator/developer for help.
I appreciate if you or anyone else point me in the right direction.
I read all comments in this chat and did get a feeling that there is no easy way of dealing with it.
I do not like the approach of puling out and reloading the data, especially for the sub-assemblies that have the unique data attached (that can be screwed up), and it requires the administrator involvement.
Disclosure: I am a user and have no knowledge how to administrate the Epicor. The administrator states that there is no way to handle this situation.
Not sure this would work in your environment but at one site the drawings had their own part numbers - and those part numbers were then called out on the “BOM/Rev”. This allowed revising the drawing w/o revising the “BOM” and vice versa.
Mfg ( was supposed to) then made sure they used the correct drawing rev(s)… based on the BOM item(s). ( of course, some people loved this… others hated it… not many with feelings in between)
The system should be a “fool proof” when everything is under the revision control. You should change the revision ones (not 526 times as described in my case above - that what those people are currently doing) and it must propagate itself to all other related data (engineering, purchasing, manufacturing, quality and etc.) Checking things manually is a “recipe for disaster” when you build the multi level assemblies / sub-assemblies containing the thousands parts, which need to be procured and build to correct revision.
We have gone the route of using DMT and running a powershell script on a folder to help make mass changes to methods/revisions. Our process uses a query to see all parts that have same drawing attached and then bump them all up a rev when user chooses to do mass update of revisions.
It’s just a matter of a bunch of import and export queries run with the powershell. It is a little scary because it is so powerful, but it is the only chance of getting our part revisions to jive with our method revisions, which is what our engineering and quality want and they don’t want to do manually. I can’t say we are perfect with it yet, but the DMT runs fairly well. When there is a hiccup, such as an exported dataset that cannot be uploaded back (i.e., it doesn’t like if there’s an old inactive resource along with a resource group ID, though it allows it in Epicor, just not new upload of it, etc), but I monitor for occasional errors and then fix/try make query more robust.
It seems strange to me that a parent rev change requires all children part’s rev to change… that’d be a recipe for disaster for us! You could get the data for which to fix via a BAQ on the partmtl data.
The method is best done by someone who does development in Epicor. Let me know if you’d like any further details on ours. It probably could be started off as half manual to determine if useful then automate more as desired.
Thank you very much for the explanation. I will share it with our Epicor administrator. It is a scary way of working around for us. It will work for some parts (electronic components and materials), but will not work for the assemblies and subassemblies.
Your process “Our process uses a query to see all parts that have same drawing attached and then bump them all up a rev when user chooses to do mass update of revisions” is a killer for us.
That is what I am trying to avoid - attaching the same drawing to 526 parts. Just curious, if your routine replace the drawing as well.
It is a standard practice in an electronic industry to have the multi part drawings. The similar electronic and other components (for example, film resistors with power rating , 0.1 Watt) are grouped into one drawing.
We assign our internal part number(s) and cross reference them to the multiple manufacturer part numbers.
Here is an example: Drawing number is a base for the part number. Complete part number contains the base number and dash number (2-24490-001, …., 2-24490-526).
This specific part has only three vendors (manufacturers). We have parts with seven vendors.
There is a reason for such a complicated structure. Our internal part number is entered in the Bill of Material (BOM). For example, part, 2-24490-001, is used on BOM(s) of 191 subassemblies.
The changes withing the multi part drawing 2-24490 are invisible to BOM(s). We do not need to revise 191 BOM(s) if we add Vendor #4 part number.
We do not use revision number in the AutoCAD filename. Once user attaches drawing to a part in Epicor it stays regardless of changes to part revision. So we don’t need to replace attached drawing in Epicor on rev update.
To keep attached drawings up to date, we use vault for our latest / checked in copies of all drawings. When a user checks drawing into vault a visualization file (someday hopefully a pdf, today a dwf) is made and this vis file gets copied via script to our “epicor repository” of attachments, so that our vault dwg and our vis files in repository are always the latest, in agreement.
Now of course, keeping the Epicor rev the same as the drawing rev and ensuring nobody has messed with the auto creation of the vis file is fun but I guess that’s what we get whenever same data is stored in multiple places…
Do you use these vendor parts numbers as your part master parts or do you use supplier part numbers for your part master parts? We like to use the same part number if form/fit/function is the same from multiple supplies.
Where we get bitten and need to update a bunch of part revisions because of a single drawing upgrade seems similar to yours, but ours are material codes that are tabulated on the drawing but are called 20 part numbers with associated method/revision in Epicor. Frankly that’s the whole reason we developed this DMT “submit to update rev” automation.
Dealing with the files in the native format (SolidWorks, Creo, AutoCAD, Word, Excel, Power Point and some other) is not a problem. I think that they already have the “Epicor repository”.
We do include revision in the native file name (with the exception of SolidWorks and Creo). For example, 2-24490_K is a name of the Word file. We need to keep all revision for the record.
New rev resides in Active folder on the network. Old revision gets moved to Archive. At old company (before the move) we did not have any duplicate drawings / files on the network.
SolidWorks and Creo drawings native files do not have revision, but we “print” them in PDF format and include revision in PDF file name. PDF will get attached to the drawing record.
The Part Master is for our internal part numbers (2-24490-001, and etc.). Three manufacturer part numbers will be entered using Qualified Manufacturer Maintenance window. We are planning to import all that data soon.
.
Your insight is greatly appreciated!
but I guess that’s what we get whenever same data is stored in multiple places…