Including document numbers in dash-number part numbering scheme

tim_hess427

At my company, we're taking a look at our part (and document) numbering systems, and I'd like to know what others here think about the topic.

I've been reading Watt's book (Engineering Documentation Control Handbook), where he advocates for a dash number system. My understanding is that it would look something like this (please correct me if I understand this wrong!):

• 123456 is the base item number and does not have any significance
  
• 123456-00 = Drawing
  
• 123456-01 = released part
• 123456-02,-03,-04 = could be a variants (color, material), or non-interchangeable part revisions.
  

This seems like a reasonable approach. However, I have a few questions. What if I also have other specification documents I need to tie to this particular part (3D printer settings, material specs, etc.)? I suppose I could give those documents a dash-number. But, if I have a spec that is used for multiple parts, I'd want it to have its own document number. It seems like this inconsistency would be confusing over time.

On the other hand, some people recommend having a complete non-significant part number. In those cases, how do you manage part variants and document references? Do you just create cross-references on the drawing as necessary?

Cris_Bowers

I've been involved in coming up with part numbering schemes for multiple employers. At first I was a big advocate for smart numbers where every portion had a significance. Eventually though you will run into a scenario you didn't think of and have to add a new dash to it and then you forget what something means and have to have a lookup table to figure out what it all means anyways. After that I jumped on the non-significant train. Every part/document gets a unique identifier and a detailed description which can include all the information needed to manufacture the part. If you have parts or documents that fall into a family I don't see a problem with adding a suffix, but you'll need to decide on how many digits you think you will need and add an extra digit because you will probably underestimate. So if you think you will never have more than 99 related parts, then you should use 3 digits, 000-999.  So your document number would end up looking like 123456-001, 123456-002 etc. I like only using revisions during the design and review process, where you just add an R1, R2, R3 etc. Once the part/document is approved drop the revision indicator. If something changes down the line, make a new part number that covers the changes.

tim_hess427

@Cris_Bowers - thanks for the feedback. I was thinking more about using the suffix to tie different document types back to the part. So, for example:

• 123456-00 (or maybe just "123456") = part
• 123456-01 = Drawing
• 123456-02 = STL file export
• 123456-03 = 3D printer build file, G-code, etc.
• 123456-04 = Relevant specifications...
• etc.

I don't think I would say "-01 is always a drawing file", but rather, I would increment the suffix sequentially. The goal being, I want to look up "123456" in my system and see all the relevant information for that part without having to open up a lookup table or cross references.

However, I can see issues with this system as well:

• What if specification 123456-04 applies to other parts as well?
  
• What if I change part 123456? Do I duplicate all of the documents just to give them the new number?

In the case of the completely non-significant numbering system, where do keep the lookup table to know which documents go with which part?

owen_sparks

Hi.

Just throwing options around, we use a prefix to handle that:-

Type Prefix - Project Number - Other Stuff - Revision

eg MD-141-0001-A

MD = Mechanical Drawing

GA = General Assembly aka BOM

3DP = 3D Printed Part

Cheers, Owen S

tim_hess427

Hi @owen_sparks, thanks for the perspective! We've actually got the prefixes now, but reading some books had me looking at the suffixes. I'm likely thinking too hard about this

Do you enforce a rule that files related to the same part share that part of the number?

So, for example: Do MD-141-0001-A and 3DP-141-0001 refer to the same part?

Cris_Bowers

In the case of the completely non-significant numbering system, where do keep the lookup table to know which documents go with which part?

@tim_hess427 You'll want some sort of database/ERP system

tim_hess427

Agreed - and we are looking at a variety of systems. 

One thing that's come out of that research is different systems have different levels of capability for dealing with the engineering documentation. They all reference part numbers, but don't always have ways to tie the part number back to all of the documentation that goes along with it (perhaps this is really the domain of a PLM system instead). This starts to bring me back to every part number having a drawing with the same number that calls out all of that documentation. 

Cris_Bowers

Now this might sound kind of silly, but what about creating a part studio with a dummy part as a stand in for your engineering documentation, say an extrusion that is 8 1/2" x 11", representing a piece of paper. This can be inserted into an assembly and also show up on the BOM if it is something you need done. If you are using Google Docs, you can create a link to the actual documentation with the LinkTab app. I'm just not sure if there is a where used query in Onshape.

David van der Meer

@tim_hess427 I have read Watts' Engineering Documentation Control Handbook front to back, and looked at the suggested part numbering in quite some detail as well and how this can be applied at the organisation I work for (we have something similar to what Watts describes). I think it has a lot of merit, but you would still need to be careful when/how to use this tab, because it's tempting to get a bit too clever with it.

The book suggests to use this tab for "similar" items documented through tabulated drawings (with a dimensional variable for example), different colors/finishes, etc., as well as for non-interchangeable changes. If you combine the two however it starts to get more complex (what happens when you make a non-interchangeable change to parts on a tabulated drawing, with different sizes and different finishes?).
At my organisation there have been attempts to add some significance to the "tab" number as well (e.g. -02 = primed, -08 painted blue, -21 = galvanised etc.), but this is also not helpful in the long run, and it would be better to number sequentially for the different finishes as required.

What you are describing however is a need for different document "types". If your part has P/N 123456-01, and the corresponding drawing number is 123456-01 as well, wouldn't it be helpful if your STL file is 123456-01.stl, your DXF is 123456-01.dxf, and your 3D Printer build code file is 123456-01.xyz as well?
Then if your design changes non-interchangeably and becomes PN 123456-02, then the relevant STL and build files will update to that number as well.

The book suggests that a document-only part gets tab -00, so its part number is 123456-00. It would be a safe option to simply keep these documents standalone and refer to them on any component you might need them, and not risk the confusion of grouping the document with another part the first time you create it. Unless it applies uniquely only to that one part, similar to an STL file.
If you consider that a specification document has a part number, then you can reference this document like you would any other part in a parts list. With a proper PLM/ERP system you will then get full used-on availability. This is covered in "Chapter 2 > Assembly Parts List" which has an example of what such a parts list would look like including reference documents which have part numbers, and again in Chapter 5 on BOM.

Doug_Jones

@tim_hess427
Just came across this discussion from last winter... Did you ever implement the Watts numbering system? Just wondering how it worked out. I wrestled with the idea of pushing that system off and on.

romeograham

I'm a proponent for the non-recipe but unique part number as well. I've spent parts of my career trying to make part numbers that have significance to the part / assembly etc, but

1. quickly ran into new scenarios that required changes to my base system 
2. forgot what the numbering meant. 
3. I ended up with way too many parts that were 51mm, so too many numbers started with "51..." and the "51" lost its meaningfullness to finding a unique result. It definitely found a category of parts quickly, but didn't narrow it down enough to be useful.
4. It became nearly impossible to communicate to a new person the importance of the various bits, or have them internalize enough to create new part numbers correctly on their own.

So it became clear for me that sequential, unique, SHORT numbers were the easiest way to number things.

Since search (together with limited ability to recall part numbers over time) is so important in data management inside an organization, I felt that the most efficient way to structure part / item numbers is to have the most unique information at the front of the number. That way, you can find the unique item you're looking for with the fewest digits remembered, and the fewest digits entered into whatever search box you're using to find those parts / items.

I have adopted Onshape's default approach to Prefixes (which basically works for me) P1234 for Part, A1234 for assembly, D1234 for Drawings.
Generally works except that I can't easily see if a drawing is for a Part or an Assembly (since there's no indication in the part number for Drawings...I need to make a change here). I like the idea of a Suffix or something that could give a bit more info or categorize the item. However, I feel that 1 level of extra categorization is as far as it should go, to make it easier to create new items).

I've since added two more prefixes:

1. WIP1234 for parts that are undergoing an internal process that transforms them from P1233 to P1234
2. V1234 as the "Visualization" state of P1234 (many of my parts can't be rendered in their "as-built" state since they are manipulated or folded or flexed or collapsed during final assembly, so I have to have a separate configuration of every part to be able to share the design while in development). 

Before Onshape generated numbers for me, I used a Google Sheet as my "part number builder" which kept track of anything I needed. Now that Onshape generates my sequential, unique numbers, I have to remember to keep the Google sheet up to date.

The downside to this system is that parts that are physically related don't always share part numbers ranges (for instance, my Assembly might be A1951, but the parts are P2041 & P2145 because I assigned numbers to parts in that assembly after doing a bunch of work on other assemblies or parts in between). However, it also doesn't matter at all, because my part numbers don't mean anything! It's just a little harder to see a part number and remember what assembly it might belong to. The advantage to setting these up on a separate Google Sheet (or other system) is one could block off groups of numbers (but then have to reserve the right number of them, and remember to go back to use those numbers later).

Since so many of my stakeholders do NOT go into Onshape to find the correct revision of a part / drawing, I feel it's critical to export parts / drawings with the Revision as part of the File Name.

Drawings often get revised at a different rate than parts / assemblies, so I use Letters (P1234-A) for parts and numbers for Drawings (D1234-1). Onshape's Release Management help pages show how to set up a custom Revision Numbering scheme.

Slightly off-topic, but similar to "meaningful" or "random but unique" part number discussion:

Along with "front-loading" part numbers with uniqueness (to facility efficient search) I've done a similar thing for other types of documents etc
I use

YYDDD.x.CODE
(YY is year)
(DDD is day number - today, November 2, 2019 is 306)
(x is incremental number for today - for instance the third number I generate today would be "3")
(CODE is a human readable helpful bit describing the Record Type, but is NOT required to find the unique item. Like RECD (for received), TST for Test, PS for Packing slip, REL for items released etc)

With this, with 6 keystrokes I can find a document anywhere in Drive (YYDDD.x), Gmail, or anywhere else.
For a slide deck created yesterday, the number could be: 19304.2.DECK. However, to find that document, I only have to search for 19304 (it will likely show up) or 19304.2 (that uniquely identifies that Slide Deck).

I use a Google Sheet to generate and keep track of these numbers. There's an automatic formula that builds a search URL for each row in that sheet as well, so it becomes a good central repository. As long as these numbers appear somewhere in a document, title, email, they can be found. The ones that I NEED to remember over time get remembered - because there's only 6 digits to remember.

~~
If you're interested in setting up something like this, put your Date in column A (YYYY-MM-DD) and your record type "CODE" in Column E, and use this formula in Column B (replace 2204 with the row number you paste this in):

=if(A2204<>"",(join(".",CONCATENATE(mid(A2204,3,2),text(A2204-DATE(YEAR(A2204),1,0),"000")&"."&if(A2204=offset(A2204,-1,0),INDEX(split(offset(B2204,-1,0),"."),0,2)+1,"0")),E2204)),"-")

The Codes in ColE are a Data Validation (drop down) field, pulling codes from a list on another Tab.

Over to the right are all the other fields that would be helpful for you to understand (in the future) what the record was about. I think it's important to be able to create these records with the least amount of cognitive overhead so that they get used....if it's not in this sheet, it's harder to find. 

The "Find" link in ColD is automatically built using a the Record Number in ColB, and putting together a URL that shows search results in Google Cloud Search (could search in Drive too).

Curious about anyone's thoughts on this approach to home-grown record numbers.

DavidvanderMeer

@romeograham What does the document number convention you use currently solve that a meaningless sequential number wouldn’t do just as well, if not better? If you numbered that same list like this:
100001
100002
100003
100004
Etc. 
You would have a short 6-digit number of consistent length, and your spreadsheet tells you any other properties you need to know (Date, Record Type).
Personally I would to start at 100001 and not 000001; I'm not a fan of reference numbers with leading zero's. If this number is too generic, at best put a letter in front of it like G100001 (G for Google Docs or something) to make it more recognisable. And use less numbers if you don't expect to create that many documents (depending on how long it would take you to reach 9000/90.000/900.000 documents created).

Looking at your convention:

YYDDD – Why convert from MMDD to DDD? That looks like an over-complication to reduce the number length by one digit. Are you really saving on keystrokes here? If I was to build the date into the document number, I would go with YYYYMMDD or YYMMDD, then at least you’d know the exact date without having to go through some conversion. Sort order will still be chronological as well.

That said, is knowing the date the document was first created of value when you try and find this document? Don’t you already have this recorded in the “Date” column in your spreadsheet? If you wanted to filter/search on that, you could simply do it through that spreadsheet.

X – How valuable is knowing whether the document was the first/second/third/etc. document created that day? If you do more than 10 that day, does it become a 2 digit position in your document number convention?

CODE -  I can see some value in this if you are going to use that for finding specific document types, but like the date,  you already have this this in your spreadsheet for filtering. It also makes for a messy, variable length document number. It’s also not needed for making the document number unique, because the YYDDD-X component of your document number already ensures that. Can’t the “Record Type” instead be a folder in your filing structure where you put your documents instead, rather than putting it in the record number? (for lack of a database "label" of some sort)

Over the years I have worked with so many different document number conventions (both significant and non-significant), that the significance of the numbers became completely meaningless to me and many others using it. It also resulted in the meaning behind the number being applied incorrectly very often (due to the many people not knowing how to apply it correctly), making the meaning behind the number meaningless. And I've see the smart numbers run out of smarts many times as well; guaranteed to happen to all smart numbers.

At the end of the day, all that these many different numbers were used for by me and most end users, was to tell me what system or platform to go to in order to find the actual object/document. The document number itself doesn’t have to tell me what’s in the document; the title of the document and the contents within the document will take care of that. 

I manage my office-type documents through SharePoint, and that does give me the capabilities of a database with auto-assigned meaningless document ID’s, and other configured properties like Document Type, Application Type, etc. That said, I still build my Document Title in such a way that it’s consistent and can easily find things; the title itself is essentially my classification. Also, with the contents of the documents indexed, it helps find what I’m after as well.

My filename is the same as the meaningless document ID, and that will never change through the life of the document and can consistently reference that elsewhere. The filetype is also a means of filtering; if I’m after a presentation specifically, I’ll filter on .IPT/IPTX format. For you this should also work just as well as putting “DECK” in the document name?

If I was to introduce Onshape to an organization I would use one number type for all Onshape objects generated. I wouldn’t use their different A/P/D prefixes as I’m not sure how that would be helpful. If I have the item number I’ll find it in Onshape regardless of whether it’s an Assembly, Part or Drawing wouldn’t I? If anything, I would expect Onshape to have an ability one day to filter my searches based on Parts/Assemblies/Drawings, regardless of the document number prefix. That along with a full where-used of all objects (once Onshape gets this capability) should get me to anywhere I need to be quickly.

romeograham

Good points @david_van_der_meer.

The recognizability (year / date) and short form of the date came about because these numbers were regularly hand-written on samples or retains (undergoing testing / archiving / etc) and then stored. Later (years later, often) the samples are pulled out and reviewed. The date number is useful to give a person a general idea of when the sample / part was prepared. This person may / may not know where to go for the spreadsheet where the rest of the information is.

The DDD for the date was used for two reasons:

1. 1 less digit makes a difference when hand-numbering 100's of samples. Often our materials are not suitable for any type of inkjet printer, too small for a label, etc. So: Sharpie it is.
2. DDD also eliminates issues with date format between US and Canada (I work with teams in both areas). Folks are remarkably "sticky" on their date format - and if they know it's a date their writing, muscle memory takes over and we end up with different codes than are necessary. With the DDD, they at least have to go to the Sheet (the easy way) to figure out what DDD "today" is.

The X is not useful in its position in that day, but only to create several numbers that day that are unique. You're right: there's no intrinsic or valuable information in the X (other than reflecting later: "huh, we must have been busy that day...").

SharePoint (or something that creates numbers for everything) sounds perfect - but I didn't have that type of thing. Also - this system was supposed to work for all different types of office documents (Microsoft Office, Google Docs, PDFs, boxes of samples / product that arrive by Courier, collections of files (images, documents, drawings, STEP files) that are sent out by email etc etc etc). Would something like Sharepoint track different types of objects?

Back to the handwriting of a number: it's handy, when rooting through the boxes of closure samples years later, to be able to relatively easily / quickly get a sense of how old it is ("15302.2.RECD - we got these way back near the end of 2015 - they must be for XXX project").

I agree that allowing Onshape to take care of the numbering for stuff inside Onshape is awesome, and jumped on it immediately for parts / assemblies / drawings. I haven't really started putting other stuff in Onshape much yet though. I was trying to build some type of Bates numbering system for all kinds of objects, both physical and virtual (documents etc).

Though - to be honest, this system (like many others) has a very limited uptake with teams. It is remarkably challenging to get all types of users to incorporate new systems, unless you build it so there is literally no other way to perform the task.  

Thanks for the thoughtful feedback!

Sorry @tim_hess427 for the long-winded hijacks of your original question!

tim_hess427

I love this discussion. To give you an update, @Doug_Jones, we have not fully implemented the Watt system. Since creating that post, our company has partnered with another company and we have adopted their existing system rather than trying to build a new one and re-training everybody. The system we're using now uses a prefix for each client (as we have to keep documentation separated) as well as a prefix for the "type" of item (document/spec, part, drawing, assembly). Then, the base part number is sequential, non-significant. We also have dash-codes used for variants (primarily different sizes of components or configurations of assemblies). 

I think really going all-in on the non-significant numbering scheme will require a good database to properly tie all the desired metadata to each part number, which we don't have at the moment. 

So, if it were up to me to build something from scratch, I'd probably still implement something closer to what Watt describes, but I think it's important to keep in mind that a key part of his system is shifting efforts from "creating numbers" to "database management". If you don't have a good database to use, and someone to keep it up-to-date, some level of significance is still valuable.