How to handle simple BOM changes regarding 'different' parts

[berg_lauritz]

It's a thing that we come across more & more and it's creating completely unnecessary work for us:

Example (in quotes for emphasis):

We have a TV that has an assigned part number: 123-1234
Now we get a new TV and it has a different part number: 123-4567
The outer measurements are EXACTLY the same. The only thing that changed is in this case the resolution of the TV. It was 720p and now it is 1080p.

We get a new furnace. Same outer measurements, same requirements etc.
Only the BTU changes by 4000 for the new one and of course that means it is a different part number.

Do you handle this on your BOM side of things or in SolidWorks?
Is there a good practice for us to 'swap' parts like that easily?
Should we make a 'placeholder' for all of this that does get replaced in case we upgrade?
We have so many parts that we have to regularly change only for BOMs sake and the constant PDM check in/out and changing states is killing our productivity.
There has to be a better way with SolidWorks PDM or is there not?

I am open to all kinds of suggestions!

We do have a workaround for colours in our case:
Our parts in SolidWorks are only one colour and they have a special 'material' assigned to them which generates 3 different colours for us automatically (not in SolidWorks but in our BOM section).
But this is only because we knew it would happen and we could prepare it.

[Glenn Schroeder]

The simplest way to handle that would likely be to have multiple configurations in the model. Reference whichever is appropriate in the Assembly, which would be reflected in the BOM. This method also has the least potential for errors, lost links, mates, etc when switching from one to another.

[XHawkeye]

The simplest way to handle that would likely be to have multiple configurations in the model. Reference whichever is appropriate in the Assembly, which would be reflected in the BOM. This method also has the least potential for errors, lost links, mates, etc when switching from one to another.

Have do place occasional computer monitor and use Glenn's method. Have 12 different configs showing different sizes/types. The only thing that's correct are the outside dims to the VESA mounting.

[mattpeneguy]

The simplest way to handle that would likely be to have multiple configurations in the model. Reference whichever is appropriate in the Assembly, which would be reflected in the BOM. This method also has the least potential for errors, lost links, mates, etc when switching from one to another.

This could work and can accommodate if some dimensions change by using configured dimensions.
But, you have to check to see if using configurations will cause problems with your PDM implementation. When we looked at DDM, I remember something like it wanted 1 file per configuration for whatever reason. In other words, IIRC, the above wouldn't work well with that system. Maybe it would and I misinterpreted the situation, regardless, you need to test the workflow and make sure it won't screw something else up.

[berg_lauritz]

The simplest way to handle that would likely be to have multiple configurations in the model. Reference whichever is appropriate in the Assembly, which would be reflected in the BOM. This method also has the least potential for errors, lost links, mates, etc when switching from one to another.

Yes, we thought about configurations specifically because of possible broken links etc.
PDM data cards are fairly painful (@bnemec can sing you a whole song of it!) when it comes to configurations though:

• You have to be very accurate what you put into your cfg specific custom properties
• All the fields have to be set up to only change the cfg specific fields and nothing else on the data card
• Our parts are named like the part number - it is counter intuitive to search for part number B and then go through all the properties of part A to see if there is part number B available as a configuration
• Any change to this part (even if it is only adding cfgs) means a lot of exclamation marks from PDM (impacts i.e. performance, possibly wrong BOMs in PDM, 'edited on open' from PDM, etc.)

It also feels useless to do this in SolidWorks. We get a change notice and we only have to go in there and change a part/add a configuration for (in our case currently) 10 different main assemblies? What a waste of time.
There has to be a better way! I wish we could only change a text field & be done with it.

@mattpeneguy, we discussed this multiple times too and we are reluctantly (so much work!!!) coming to the same conclusion that we need 1 part for 1 part number. It seems impossible to have everyone have enough knowledge & diligence to make it work otherwise.

[XHawkeye]

My boss wants configs saved in DDM so base file part/asm file needs to be a different name then the configs. So we name the base file -000 if the file with configs.

[HDS]

[*]Our parts are named like the part number - it is counter intuitive to search for part number B and then go through all the properties of part A to see if there is part number B available as a configuration

Do you have the option for parts numbers with an extension like 1234-yy? Then you can have a single file full of configurations with the file name something like 1234-XX.

[Glenn Schroeder]

Yes, we thought about configurations specifically because of possible broken links etc.
PDM data cards are fairly painful (@bnemec can sing you a whole song of it!) when it comes to configurations though:

• You have to be very accurate what you put into your cfg specific custom properties
• All the fields have to be set up to only change the cfg specific fields and nothing else on the data card
• Our parts are named like the part number - it is counter intuitive to search for part number B and then go through all the properties of part A to see if there is part number B available as a configuration
• Any change to this part (even if it is only adding cfgs) means a lot of exclamation marks from PDM (impacts i.e. performance, possibly wrong BOMs in PDM, 'edited on open' from PDM, etc.)

It also feels useless to do this in SolidWorks. We get a change notice and we only have to go in there and change a part/add a configuration for (in our case currently) 10 different main assemblies? What a waste of time.
There has to be a better way! I wish we could only change a text field & be done with it.

@mattpeneguy, we discussed this multiple times too and we are reluctantly (so much work!!!) coming to the same conclusion that we need 1 part for 1 part number. It seems impossible to have everyone have enough knowledge & diligence to make it work otherwise.

Have I mentioned how happy I am that we don't use PDM?

[bnemec]

Yes, we thought about configurations specifically because of possible broken links etc.
PDM data cards are fairly painful (@bnemec can sing you a whole song of it!) when it comes to configurations though:

• You have to be very accurate what you put into your cfg specific custom properties
• All the fields have to be set up to only change the cfg specific fields and nothing else on the data card
• Our parts are named like the part number - it is counter intuitive to search for part number B and then go through all the properties of part A to see if there is part number B available as a configuration
• Any change to this part (even if it is only adding cfgs) means a lot of exclamation marks from PDM (impacts i.e. performance, possibly wrong BOMs in PDM, 'edited on open' from PDM, etc.)

It also feels useless to do this in SolidWorks. We get a change notice and we only have to go in there and change a part/add a configuration for (in our case currently) 10 different main assemblies? What a waste of time.
There has to be a better way! I wish we could only change a text field & be done with it.

@mattpeneguy, we discussed this multiple times too and we are reluctantly (so much work!!!) coming to the same conclusion that we need 1 part for 1 part number. It seems impossible to have everyone have enough knowledge & diligence to make it work otherwise.

In my short 3 year crash course in SW PDM (heavy on the crash) I have learned that PDM is a >FILE< management tool. PDM handles files. Speaking to the conceptual object modeling line of thought here, any relation between CAD file(s) and physical object/part number is done through metadata and data card variable setup. As in "This file represents this/these part(s). Or in other words, PDM does not have an inherit notion of a physical part object. So when you start trying to make the >File< objects (which PDM was designed around) represent more than one physical >Part< object things start to crumble.

Of course they tell you PDM supports configurations and all that, which it can. But it all falls apart quickly if you want the other parts of the system to function as expected. Configs work okay so lang as they are all representing the same physical part object. After several attempts at having more than one part number per file; hardware like screws and nuts, as well as "configured" top level products, we gave up on it. I have not seen a full example of having more than one part number per file in PDM that works well throughout. Unless you have highly automated product configurator such as drive works or the like; but even then I think it just cranks out new files for each order/project rather than adding configurations. There may be a way to get PDM to work well having 1:n file to part number relation; but I picture it like walking a tight-rope.

What you're speaking of is a big reason why we have tens of thousands of assembly files that represent the same number of welded parts or sub-assembly parts; and then several more scores of top-level assembly files. If one TV is different from another then it's a different part number. In our case even screws will have different part numbers due to plating spec and or locking patch type and coverage. I think it's a 3/8-16X1.25" HHCS that we have four or five part numbers for. In our data set the 720 and 1080 TVs would have different PNs and would be options, even if the model is identical. Except for us we would also have a 4k option along with different sound bars and they would be in "kits" with the mounting brackets and hardware that attach them to the chassis. You guys might be able to benefit from a product configurator. We've looked at a couple but it falls apart because our products have no predefined set of rules.

[berg_lauritz]

@HDS , @XHawkeye

After reading this post from @bnemec , we might have to revise our policy that we do not want any associations of a part number to an attribute.

[...]
In my short 3 year crash course in SW PDM (heavy on the crash) I have learned that PDM is a >FILE< management tool. PDM handles files. Speaking to the conceptual object modeling line of thought here, any relation between CAD file(s) and physical object/part number is done through metadata and data card variable setup. As in "This file represents this/these part(s). Or in other words, PDM does not have an inherit notion of a physical part object. So when you start trying to make the >File< objects (which PDM was designed around) represent more than one physical >Part< object things start to crumble.
[...]

That would at least solve the issue that there is otherwise no connection between those two parts (which is a step in the right direction!).


It still does not solve the problem that this is a (in my humble opinion) stupid thing to do within SolidWorks. Does anybody solve this problem NOT on a SolidWorks level?



Currently I agree with you 100%, @Glenn Schroeder . Part of it is, that D'assault says it's only a "file-management system" and nothing more........ That's of course what it should ONLY be!

[...]
Have I mentioned how happy I am that we don't use PDM?

Edit: @bnemec , a product configuration like driveworks is useless for us. We have to tweak our BOM heavily already because of the different colours we use. Having this as configurations would let our work load explode into more than [colour amount] times of what it is currently. Unacceptable. Our sister company does this (only) for their trailer tailgates and they have more than 100 configurations for EACH one of them.

[bnemec]

@HDS , @XHawkeye

After reading this post from @bnemec , we might have to revise our policy that we do not want any associations of a part number to an attribute.

Never make changes based on one person's experience, especially mine! I'm just sharing what we have learned how PDM reacts to our use case. Please corroborate with other sources before making shifts in practices. It is very hard for others to fully understand your exact use case without being there, walking in your shoes so you have to vet the info. This is why consultants exist and seem expensive. If we could have had someone involved that is experienced in PDM, PLM, CAD and MES systems as well as practices AND experienced in our use case AND unbiased, I bet my song would be to a different tune.

[AlexB]

We've implemented configured parts that represent multiple part numbers for our hardware items. With that said, it is extremely cumbersome. We also typically use the "one part file = one part number" motto in almost every other case.

So, for the configured hardware items, they are driven by a customized design table template that ensures all fields are applied to the configuration specific custom property and the standard (base) part number is applied to the default and global custom property pages. This isn't easy to keep track of, and it is even less easy to make a drawing with a table showing the configurations that each part has.

In my opinion, it would be vastly easier to keep each separate part number as a separate file. If you really want to have configurations with separate PNs, you could have an assembly that will act as your configured assembly and then import one configuration into a new assembly that will act as your end item for that PN. This way, you have one source for your TV that feeds into however many sources for your various end items. (Setting the configuration BOM setting to "Promote" would help in this case too for the configured file)

Just thinking out loud, don't take anything I say too seriously

[AlexLachance]

It's a thing that we come across more & more and it's creating completely unnecessary work for us:

Example (in quotes for emphasis):



Do you handle this on your BOM side of things or in SolidWorks?
Is there a good practice for us to 'swap' parts like that easily?
Should we make a 'placeholder' for all of this that does get replaced in case we upgrade?
We have so many parts that we have to regularly change only for BOMs sake and the constant PDM check in/out and changing states is killing our productivity.
There has to be a better way with SolidWorks PDM or is there not?

I am open to all kinds of suggestions!

We do have a workaround for colours in our case:
Our parts in SolidWorks are only one colour and they have a special 'material' assigned to them which generates 3 different colours for us automatically (not in SolidWorks but in our BOM section).
But this is only because we knew it would happen and we could prepare it.

If it's completely unnecessary work for you, then it shouldn't be in your drawings, but that's obviously not something that is up to you. If it's not on your drawing, it's because someone somewhere else is providing along the required information that is missing. From this point on, we will refer to the missing "dimensions" as "variables".

If you're obligated to do it on the drawings:
-You could use promoted assemblies and/or configurations to call the desired variables. Just know, this most likely will force some changes in your assemblies as your promoted assembly and/or configured component will need to be mated accordingly so that no references are lost and that things stay as you desire when switching between configurations.Careful not mixing too much, it gets easy to do a mistake. What I mean by that is, if you use part configurations and promoted assemblies and end up switching configurations for both, try not having your configured parts inside promoted assemblies so that someone doesn't mistakenly change the part configuration inside an assembly inside the promoted assembly.

In the case of the TV, I would go with configurated parts only, with the configuration name calling out the part number and have a configuration specific property that would call out the required resolution.


If you're not obligated to put it in your drawings:
-Keep your drawings as is, have whatever spec that follows along with the part/product have the desired variables called out on it, inform production to refer to the specs when producing orders.