Best strategy for BOM/part number/ drawing number/file name...

Thanks for this concise answer, very clear.
I got your point and I will happily match your way to keep it as simple as possible. I fully agreed about the fact that the description carry more information than anything else and such field is an important one.

However there is one point that I can't understand, is the limitation of the configuration Specific property.
Using your system, my demo will now be :
Body box small -> part number 101a1
Body box Medium -> part number 102a1
Body box Big -> part Number 103a1
Lid small->part number 104a1
Lid medium ->part number 105a1
Lid big ->part number 106a1
Lock->part number 107a1
Hinge-> part number 108a1

But because the size are done inside the same drawing part, by using configuration, I will face two problems:
1- I am unable to link the description of such configuration to the title block drawing.
I can pop it up inside a BOM by activating "use in bill of material", but it doesn't make sens to insert a BOM table into a single part drawing.
2- The part number, while in configuration property, is read from the configuration manager, by renaming the value inside the configuration manager. That means that the extra information link to the part number like the major revision "a" and the version "1" inside the part number must be done manually.
This doesn't sounds right and will end up with error for sure.

Thanks Robert, I tried several time to get something close to your system, but I may not get the logic behind the mechanism or I'm too short on solidworks, anyway, I can't get it 100% working.
What's exactly the meaning of : "These additional custom properties can be coded into title block and other notes so they read how you want them to".
What kind of code are you referencing too?

In my title block, there's 3 separate cells, part#, Major rev, and Minor rev, but often in notes I code the note so it includes part# and major rev together.
How did you do that?

Thanks

I name the big assembly with the suffix "00". Other assemblies with a suffix by order: "01,02,03 etc ...

The pieces may have a name that begins with the name of the assembly in which they are used followed by a description of the part. This requires planning the denomination before modeling. I have never regretted this procedure!

In other words: knowing where we are going makes the path much easier!
Is a picture worth a thousand words?

1. Using 'configuration specific' properties within the main part should take care of this issue for you. The configuration specific property will override the main property, thus you don't have to always create duplicate properties in multiple configurations, just the ones that differ.

2. I use some additional custom properties in the part for the major revision (mine is called 'majorrev') and one called 'axno' for the MRP number, which changes if the major rev changes, but not the minor. I should have called it 'mrpno' because they're switching to SAP. Live and learn.
The 'minor rev' cell in the title block is driven by the drawings system property 'revision', which increments automatically if you're using the Solidworks Revision table. Right click>add revision If it goes 'a,b,c,' instead of '1,2,3' you can change that in options>document properties>tables>revision

These additional custom properties can be coded into title block and other notes so they read how you want them to.

In my title block, there's 3 separate cells, part#, Major rev, and Minor rev, but often in notes I code the note so it includes part# and major rev together.

This works great for balloons or arrow notes that point to parts to call them out, such as in an exploded assembly drawing.

Does that get you all set?

edit: included screenshots of all the usual properties and driven stuff.

Coding was a bad word, Solidworks calls it "linking"

Linking custom properties into the title block cells and other notes is how one "automates" drawing information so that there is less chance for error.

Any text on the drawing that wants to match a custom property either must be edited by hand when the property updates (such as when something goes from rev A to rev B) OR, it takes care of itself because it's "linked".

Doing so isn't a requirement of the BOM system I laid out above but it is extremely nice to have, again, to prevent human typographical errors when properties update.

If you search your Solidworks help for "link to property", it spells it out pretty good.

You tell Solidworks the "secret code" and it knows to replace that secret code with the associated custom property.

The codes look like:
$PRP:
$PRPSHEET:
$PRPMODEL:
etc...
which tells the system where the property is linking from.

In my example, say I want to call out a component on an exploded print by it's current part number and major revision, I wouldn't just type in the part number and revision into the callout, I would type:
$PRPSHEET:"PartNo"$PRPSHEET:"majorrev"
and the note would appear as
10001A, as shown in the attached image.

The reason is, someday when the part changes to major revision "B", I only have to change the custom property in one place (the custom properties of the specific part) and it automatically updates in all title blocks, notes, arrow callouts, etc...

That's what the "coding" I mentioned was all about. Again, not a must-have, but a nice-to-have.

Saving often used notes and callouts as annotations in your design library saves a lot of time, lets you drag and drop them right onto the print, and is very satisfying as they drop in with the proper text.

Wow, what a can of worms you just opened up my friend!

You've looked into it a lot it sounds, that's good.

You are correct, no smart numbers, just sequential numbers of as few digits as you think you'll ever need in your database. Set up a "master" excel spreadsheet or other list to be the one-and-only place for everyone to pull numbers from. It should include at the very least the number, description, date, and person who pulled the part number. Keep it in a backed up location.

I had the joy of migrating us from a fully broken down smart numbering system (there were so many sub-sub-sub categories nearly every single part number was xxxxx-0001)

Also, right now, right this very second, forget anything and everything you read or anyone ever told you about "form fit and function".

From now on think in terms of "interchangeability". More on this later.

We use 5 numeric digits and an alpha character, because sometimes you want to make a non-interchangeable change to a part that is already tooled/certified/whatever and you don't want to have to update a bunch of documentation referring to it.

So, our first number is "10001a1"

"10001" is the 'root' or 'base' part number, and what gets referred to in downstream documentation, and "a" is the 'version' or 'design level' or 'major revision' it goes by many names, but it indicates a group of parts that share one thing in common. They are interchangeable.

The numeric suffix indicates the minor revision level thus 10001a1 would be revision 1 of the first part released for production. Note, prior to production release, we use version "x" to indicate parts/assemblies under development and not change controlled by the system)

All subsequent revisions of 10001a, (1,2,3 etc...) are by definition "interchangeable". That means if I put them all in a box and shake it up, I can reach in while blindfolded and pull any part and assemble it and it will work.

Most of the time changes to released parts are tweaks to tolerances, notes, typos, etc. and doesn't affect part geometry.

Sometimes however, a change does affect part geometry but doesn't affect it's interchangeability. (Form Fit Function, Fail!)

If a change causes a part to no longer be interchangeable then the 'a' becomes 'b', and the revision resets to 1. eg, 10001b1

Utilizing system and custom properties for part number and other metadata type information in solidworks allows automated BOM's, drawing title blocks, notes, etc. saves time, and reduces chance for human error.

So that's how the numbering works. We didn't come up with it ourselves, I basically stole it from a book called "The Engineering Documentation Control Handbook" by William Andrew . Worth every penny.

Now what to call the Solidworks file is something else entirely. Many want to just use the part number, but I hate that.

I like filenames to be somewhat human readable, but if "shaft" is already taken and you want to use it again, that can be a problem so what we do here is combine the part "description" with the part number, so,

shaft_10001.sldprt

Adding the root portion of the part number allows multiple shaft parts to be created and live together, play nice, etc.

This method can break down too though because sometimes it's easier to drive multiple part numbers with a single model, so then what? I don't know the best answer.

Ultimately, I end up not caring so much about what the solidworks file name is, most of the time it's description_partno.sldprt style, but sometimes it isn't and if nobody insists I change it, then it lives happily ever after.

It just doesn't matter that much because all the real action we care about is done with system and custom properties.

If anyone ever bothers to care, I'll offer to change it if they'll do all the downstream re-referencing and they quickly back away never to return.

As long as the drawings display the correct info, what the model is called is irrelevant. It is helpful to have an unobtrusive cell in the title block that references the system property FILE: $PRPSHEET:"SW-File Name" , so if ever anyone just hands you hard copy you'll be able to see what solidworks model is used in that drawing.

YIKES, this ended up being a big answer, let me know if anything is unclear or seems problematic, I've done TONS of research and thinking about these matters and have years of experience dealing with the ins and outs of where CAD databases meet MRP systems, and can brainstorm this stuff pretty well if your situation is unique and my advice falls flat.

I'm always open to a better way, but the above has been the most reliable in my situation.