Whats your logic behind your part numbers and drawing Numbers

For some reason they don't have any system for part numbers at my work and I want to start using them. How do you guys create your part numbers/drawing
numbers? Do you have any kind of logic behind your part numbers? When naming your parts do you save the file name as the part number or a Name(description)? Which way do you prefer?
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

and I

numbers/drawing
a
If the parts are just sequentially numbered, and there's no "system", then don't change a thing. The company is already doing it the right way. "Intelligent" part numbers *always* break down sometime. It's far safer and simpler to have the part identified by a unique integer, and then all the other "intelligence" is added in other fields within the product database.
My preference for file names is to combine the part number with an abbreviated descriptive name, as in: "12345 Focus Cam". That way, anyone can find the part without even looking at custom properties.
Art W.
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Here, there is a distinction between the SW part file and the manufactured part. For a given project, I will put all my angle iron pieces in one part file called "angles" and make each one a config. The reasoning is that during a development period, things change, and by having them all in one file, along with all of the base, stock sizes available, I can easily change the size of an angle and still not have to update all the properties - they come along with the original, base config for that size.
Then the identification of the part file is mostly irrelevant to the final part number of each part inside - the part number is just a changeable property that is determined by the sheet number on which the part is finally detailed. And, this might change a few times before finishing it, based on how the views fit. Therefore, I usually wait until all views are detailed on a sheet to go fix the properties - that way I only do it once.
So, to answer your question, we assign part numbers based on the particular job, not as standard, keep forever, part numbers. Most of ours are job based, and therefore can change.
WT

Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
I've had to define numerous part numbering systems and there are two *basic* schools of thought. Categorized and plain incremental. Either system involves at least part of the number being incremented for each new part number taken. In the category system you create a more or less static keycode that clues a person in to what type of part it is. A couple of letters or numbers that mean something, as a prefix or suffix... 01 for sheet metal, 02 for machined parts, etc. or A for Assembly, B for off the shelf part... you get the idea. Combine that with an incremental number controlled by a database and you're off. Depending on how you set up the system, you could have A-12345 and B-12345 or A-12345 and B-12346. In the old days this methodology was preferred because you could tell at a glance what kind of part you were dealing with. People just felt more secure with that immediate familiarity. I used to work with a lady who had literally hundreds if not thousands of part numbers memorized. You could ask her for a pn and she'd just know it, going back 15 yrs. She was amazing. But it's likely she couldn't have done that without a mental pattern to the numbers.
The plain incremental number is just that... a number issued by a database (or hand written ledger, eeek) that increments with each new part. There's no built-in intelligence but in this day many people argue that you don't need it. Since everything is pretty controlled by computers anyway, it doesn't matter that 012345 is a sheet metal part and 012346 is a screw. You'll likely be using a computer to utilize the number anyway and the computer will show you what you don't know.
As for saving parts, etc... once a system has become a standard, you should somehow link the part number to the file. Some companies insist on nothing but the part number as the filename and to the engineer, this almost requires a pdm system or something to manage. Other companies prefer the part number combined with a description, rev level, etc. The sky's the limit but whatever you do, create a standard and enforce it.
Hope this helps.
- Eddy

I
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
I had the same dilemma my self. I am in a situation where I must create p/n for both internal projects and external clients. The system I used was originally developed for use with AutoCAD :(, but I adapted it to SWX. One of the problems I had implementing p/n's was that I am in a rapid prototyping environment where part life spans can be measured in hours and there was just no time to keep proper rev controls in development stage, even for parts that were actually manufactured (the unforeseen curse of CNC :) ).
I assign all new parts the symbol:
YYMMDDxx.*
YY = last 2 year digits MM = Month DD = date xx = AA - ZZ (ie the order AA, AB, AC...AY, AZ, BA, BB...) for .SLDPRT and evil .DWG files. For .SLDASM xx = 01-99. This method ensures that I will never run out of part numbers for 100 years (at least in our size facility, maybe GM might need more, but were not quite there yet :) ).
so for the 4th part created today it would be 040202AD.sldprt, or if it was a one time job for a client I might call it 040202AD [Client Name and maybe a description].sldprt
If you have say 4 separate draftsmen you might assign AA-CZ/01-25 to one and DA-GZ/26-50 to the next etc. so you still don't overlap.
I still keep different large projects separated with a 3 digit prefix, but instead of creating part 302-0054, it would just be part 040112AH.sldprt and I have Custom property where I define the project number which would be 302 and have it appear in the title block on prints.
-ºHR=- www.seclorum.us

Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I strongly prefer sequential numbers for the SW filename, and using the description as a custom property. You can display the description in addition to or instead of the filename in the assembly tree. This particularly makes sense if you start using a PDM system.
The main reason for this is so you never get duplicate filenames. Dupe filenames can be a real problem.
matt
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
====== 04003.10.001_partname =====* partname is drawingname
04003 = project number (year 04 project 003)
10 = subcategory like testmodel (10), prototype (20), serie (40), final production (80)
001-010 main assemblies 011-099 sub assemblies 101 - ... parts
We also use our revisions in the filename and use underscores to avoid blank spaces:
04003.10.001_name_rev1.prt 04003.10.001_name_rev1.drw

I
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
What happens when you have more than 10 main assemblies or 89 subassemblies?
What happens when you have parts or subassemblies that are shared by multiple projects?
Avoiding spaces in the filename is generally a hold over from DOS days, but is useful when typing in a filename to have Windows Explorer go to the file. With filenames that long, you probably wouldn't get the the "_" frequently.
Does the filename change when a part moves between "subcategories"?
I'm generally open to different ways of doing things, but the revision in the filename is a big no-no. There are *way* too many implications with that. Only with drawings is this workable, because drawings are not referenced by other SW documents. For the same reason (renaming referenced files), I wouldn't touch your subcategory scheme with a 10 ft power cable.
These are fairly typical examples of why "intelligent" numbering schemes are often problematic, but I have seen some "semi-intelligent" schemes that made purely sequential schemes a little less harsh.
For example, a prefix before a sequential number might connote type of part or document. Still, the types have to be pretty clear, so that documents like schematics and nailboard diagrams don't get confused.
All that other info (job, customer, rev, etc) I generally like to put in PDM or MRP, and can be used as custom properties in SW.
Anyway, I'd hate to see anyone else go through the headaches I went through with the rev-in-the-filename bit.
matt

Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I'd be interested to hear about the problems you've had with "rev-in-filename" .
We've been using it for ~2 years with no significant problems, and have ~1000 parts in the system. I'm curious if it's a problem of scale....
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
The problem with rev-in-filename is that we didn't have a squad of crack SW users. They were more like just a squad of crack users. It is possible to make it work, but you have to be very disciplined.
Every time you up-rev a part, you have to do a File-save-as with the referencing documents open. Either that or be good with the Open dialog References button or SW Explorer. If a part or subassembly is used in more than one assembly or drawing, you have to do a where used search and then have all of the referencing documents open when you save-as in order to update all the links. The only way to do the where used is to use SW Explorer, which only looks where you tell it, and is slow since it's searching through files, not a database.
If you have in-context references, a single screw up could blast them all. Same with split parts, base parts, etc.
We abandoned the system because people simply didn't understand how to make it work. Had to go with a more reliable, less discipline intensive method.
We used the system for Acad drawings, where it worked well, but I think it's a very unreliable method for SW. Eventually we went to a PDM system, which just automates all the hard work of keeping track of files.
Can you describe how many people are working this way and how many changes you make? Do people enjoy working that way?
matt

Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"matt" wrote

SW
Matt:
You owe me a new keyboard. Thanks, you made my day.
Deb
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"Deb Dowding" sez:

I was going to say that some of bob z.'s sayings used to make me spray my monitor with coke, but then I thought that references to coke and crack in the same post would look suspicious.
If you soak your keyboard in parts degreaser, you won't have to worry about the keys being sticky any more.
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
In the past, it's been just me in house, with perhaps 1 1/2 FTE worth of contractors, primarily doing "project" oriented work.... One way I address the problem is that the "released" parts and drawings are all in a read-only directory, which pretty much forces the save-as....
we're on the cusp of expanding, which is why I was interested in your experience. I'm very seriously considering going to a PDM system of some kind BEFORE we add the 2nd seat...
makes the hire pretty expensive tho--$3k workstation, $6.5k new SW seat with Office pro, $1.5k officePro upgrade for me, $2k new server to host the PDM data, blah, blah, blah... I figure it'll be ~$15k before the new guy even sits down. It's kept us with contractors longer than I'd like...
As for the "in-context" problem-- we have lots of parts that get used in multiple assemblies, and as such I try pretty hard to avoid using in-context relationships. We use them in initial development, but once the parts are finalized I make a point of going thru and deleting the relationships. Generally speaking, we put driven dimensions in the development model, and then just make them driving in the released part. One of our ironclad rules is that all released models must be fully defined and stand-alone--otherwise unintentional changes are just to easy....
thanks for the feedback.
ps--the line about your squad of users is hilarious!

Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I
There are pros and cons to every numbering system. I think the size of the company and what you do (manufacturing, machine design, mold design, etc.), have a lot to do with how well a completely random numbering system works.
When I started here approx. seven years ago the company had just changed over from completely random part numbering to semi-intelligent numbering. We develop job process, fixtures, gages, design the tools used to make the parts (when needed), and design and build the machines to make the parts. We also do all of our own electrical and machine maintenance. All of the tooling and machine parts have numbers. Some purchased components have numbers if we have to keep track of inventory for maintenance or manufacturing purposes. Many of the components and tools are used on several machines and jobs. A completely random numbering system got way out of hand. Even with a database, how do you search for a drill used on a certain job? Well, I think it might have been June of '93 - No, '94.... well, it was one of those "J" months, anyway.... AAAAHHHHH!
In seven years, we have amassed over 8200 Solidworks parts in our system.

parts are numbered. We also have >2500 job processing documents and there are over 7800 documents from before there was a system. I can't imagine trying to go through 16,000 random numbers to find what I am looking for.
We now use a semi-intelligent numbering system. All of the numbers are logged into the Visual Manufacturing database and we can search by number or description. We also try to make sure that the first word of the description corresponds to the number - drill, block, plate, whatever. Of course, any system works better if you can get everyone to put good descriptions in the database. As anyone knows, you always have a few people who don't take the time to do this. This is where the numbers that are descriptive are handy. If someone doesn't describe a part very well, you can always search for the number.
Our system works like this - say that I have a block that is numbered 82600159. 8= fabricated component 260 = block (or 307 would be a base, 266 would be a clamp...) 0159 = next available number description would be: block, saddle block used on assembly 1234 for machine 5678
33555001 is a gun drill 3= perishable tool 35=drill 55=gun 001=next available number description would include length, # of flutes, rh or lh, coatings, etc.
So, if I'm looking for a gun drill in the database, I just search for 33555* and I find all of the gun drills. Or if I was looking for just a drill I'd search for 335*. I could also search for drill*, too.
I'm not claiming it's the best system out there. The biggest problem comes when I call something a block and someone else would describe it as a spacer. What do you search on? In that case, you rely on a good description in the database. Hopefully, someone recorded what machine it was used on.
One last thing - whatever system you decide on, try to have the part numbers marked on the components when they are made. That way, when someone plops some broken or worn part on your desk and says, "I need one of these yesterday." you'll know exactly where to find the drawing.
Deb
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
.... When I started here the company had just changed over from random part numbering to semi-intelligent numbering. A random system got out of hand. How do you search for a drill used on a certain job? I can't imagine trying to go through 16,000 random numbers to find what I am looking for. In the database we can search by number or description. This is where descriptive numbers are handy. If someone can't describe a part very well, you can always search by its number.....
Our system works like this - say that I have a block that is numbered 82600159. 8= fabricated component 260 = block (or 307 would be a base, 266 would be a clamp...) 0159 = next available number description would be: block, saddle block used on assembly 1234 for machine 5678
33555001 is a gun drill 3= perishable tool 35=drill 55=gun 001=next available number description would include length, # of flutes, rh or lh, coatings, etc.
Whatever system you use, have the part numbers marked on the components when they are made, so you'll know where to find the drawing.
Deb ________________________________________________________________
That is true: Placing part numbers on parts is a basic responsibility of any company intending to maintain manufacturing control.
If anyone uses a numbering system such as above described, please note:
1.) A one-digit first field limits the system to only 10 posible classes; fabricated component, perishable tool, etc. The system breaks down if any new classes are invented. Also, if there are less than 10 classes, 10 million numbers will be skipped or unused in the database for each unused number class.
2.) Inconsistent use of 2/3 digits in the second and third number fields may lead to conflicting parts. Part number 33555001 could be a 3= perishable tool 35=drill 55=gun 001 =next available number or it could be a 3= perishable tool 355=gage 5001 =next available number
The best case I have seen for strictly sequential database numbers was a disastrous ''semi-intelligent'' system used by a San Diego voting machine maker. Part numbers had letters and digits denoting tool versus product, revision letter, analog versus digital, company division, other descriptors, resulting in a 17-character number. Days were spent arguing about which category to assign to a part number. There was a 2-week memo war and management intervention over whether an alignment tool sold with a machine was a tool or a product. Arguments over whether circuit boards were analog or digital were never resolved.
Modern databases permit the opportunity to create extra descriptor fields far more detailed than even the part name. This is where to look for things.
John E. Ardans Bothell Washington ____________________________________________________________
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
If you are working with relatively small and flexible workforce, and don't want to run a manual (hard copy or database) drawing register that you have to look up and then enter the details into BEFORE you can even consider creating your part/assembly/drawing, then I have found it best to use a number based on the Date & Time e.g. for a part or assembly: 0702041018 - widget (this is 7 Feb 2004 @ 1018 [use 24 hr time]) then a simple description of the part/assembly. The discription at the end of the number is to make it easier for you to find the part when opening it; whereas the part or assembly number is simply the date/time code without the description.
This system is easy for all users to follow, highly unlikely for co-workers to create a widget at exactly the same time as you (if this is a concern, add a single or dual digit 'user code'), does not need a register or database.
The drawing number will be the same as the part/assembly number (auto inserted by setting up your drawing template) - this way the part number shown in the BOM is also the drawing number for the part.
You can explain this system to a new user (or to an outsource contractor) in a couple of minutes.
To make the whole thing truely unique (in the event that other companies are using the same system), you could also add a company/division code to the number.
Merry :-)

I
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
I'm a recent independent and need a numbering system for my own work. I think this will work fine for me, along with the part/assy description on the end.
Thanks Merry.
I guess you haven't out a way of generating this number automaticly when you do a 'saveas'?

have
number
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Opps..

when you

Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.