Find us on Google+ Making Sense of File Numbering Systems - Why do they have to? ~ Inventor Tales

Monday, October 21, 2013

Making Sense of File Numbering Systems - Why do they have to?

“We put forth a very strong number. It's always hard to know, it's impossible to know what numbers are out there.”
Tim Purpura

This weekend has been a busy one, so this weekend's blog post is a short one.  But it's reflecting something that I've been thinking of doing for some time though.

File numbering schemes.  Users spend hours and hours trying to figure out which one to use.

Is it better to use a sequential?  One where the numbers have no meaning with regard to the files they're associated with? 

Or is it better to create one where the file name has a meaning.  A given portion of the file name tells the user this an assembly, or this component is made out of stainless steal, or is a custom part.  The different meanings can go on forever, and are different from company to company.

In my own, personal file structure in Autodesk Vault, I've done what so many are guilty of doing.  I've ignored it.

My own Vault file names are an example of what I'd tell someone not to do.

They have a mishmash of names.  Most have some sort of meaning.  Some are just names I threw in because I needed a name in a hurry. 

Others are names that I changed with Vault's Rename command because I needed to make room for another file with the same name (I have "Enforce Unique File Names" checked).

An example of my similar, but not consistent file names.

I've wanted to clean that up.  I would like more consistency in my file names.  But I just haven't had the time or desire to create one. 

So I decided to steal a number scheme from someone who's already created one.  I'm going to use the one the FAA uses for their Air Worthiness Directives

How does the FAA do it?  They start with the year, then count which two week period in the year the document was issued.  Then finally, number the documents in sequential order.

For example an Air Worthiness Directive numbered 2012-20-06 would mean the document was issued in the year 2012, in the 40th week of the year (20th two week period), and that it was the 6th document issued in that time.

I'm going to give it a try in my own Vault, and see how it works out!  I'll use the file naming scheme, and for searching, I'm going to search for keywords and properties associated to the files. 

An example of the properties I've added.  I'll probably adjust them, but it's a start.
It will require discipline to make sure I fill out my properties, but it's something I should already be doing!

I'll keep you posted on how it goes.  There will be benefits, there will be drawbacks.  The real question is, which will outweigh which?

So what do you think?  Are you a fan of meaningful, or non-meaningful file names?


  1. I'm in favour of an ordered system as I can see straight away where a part is used.

    I created a numbering system based on 2 number sets, a prefix and a suffix, like 12345-67890. The first preceeding 5 numbers are the project number (or job 12345) from our accounting system and is consistent throughout the project. The 2nd set of 5 numbers is where the order is derived. The top level assy is 12345-00000. The first child assy would be 12345-01000 and the 2nd child assy would be 12345-02000 and so on for 99 children of the top level assy (through to 12345-99000). Even on the largest of projects (10000 odd files) I have not gotten anywhere near -99000. Each of the first child assy levels then gets broken into further levels by using 100's and then 10's. So -01000 would have 9 levels (-01100 through to -01900) and each of those levels has 9 levels of steps of 10 (-01110 through to -01190). At each assy level there is room for 99 or 9 individual parts (-001001 through -01099 & -01111 through to -01119). On only 1 occasion in 8 years have I had to break this convention.

    I then have numerous Vault numbering schemes for Frame Generator items, Bolted Connections, Content Centre items (all placed as custom) and so on , all of which stay out of the above scheme.

    1. Interesting way of doing it, Brendan! I like how you've set up the system to keep a large variety of numbers, so you don't run a big risk of running out!

  2. I've been using something similar to Brendan all my life and I thing a "non-meaningful" numbering scheme is best because you don't have to worry about where a part was used (I mean in which project). Saves time on reusing design on other projects. There are companies paying big money to clean up their vault and database systems. These consultants use feature comparison software to identify similar parts and delete duplicate designs.

  3. I’ve fought with many companies over the year about part numbering systems. Every time a new Engineering manager would start, he or she would change the part numbering system to the way the company they left was doing it. Simple is best, maybe a category for fab parts, purchased parts, assemblies and the like. If a new employee takes over five to ten minutes to learn the system it will fail when the creator leaves the department. The next large issue that goes right along this line is descriptions. Now that would be a great topic.

  4. We have 2 different numbering systems in place, but niether is Vault generated. Our engineered projects are all named with the Project number as the prefix along with an alpha character denoting what type of machine it is, followed by a two digit code determining what level of the machine or project these drawings or parts belong to. The remainder of the filename is a descriptive. So, for example, a top level full assembly might be named 19500F-02 Full Assembly.
    The other scheme we use is for parts we manufacture for another line we sell, and in this one the drawings are all named by the part number of the part depicted. That's where it gets messy, the parts are named with a random descriptive filename, making it sometimes hard to find.... gotta look into this one.