You cannot get drop boxes in a BOM.
If you are okay with free form typing values, you could put it in the BOM.
Make a variable, call it something clever like "Purchase_state" and add that column to the BOM column set, but not the data card. Set this variable to "Look for variable in reference specific values".
This gives you the ability to have a unique value for the same part on different assemblies. Your purchase group can now type what they want in this new column if they check out the assembly.
(When looking at the assembly BOM, make sure you are looking at the "Latest" not "As built")
That is a great solution and works. We use that designation for designs of Cable Assemblies done in AutoCAD. We use "Paste as Reference" to build a Cable BOM from Spec sheets(.pdfs) and then Edit the Item Number, QTY and Unit of Measure directly on the BOM Tab.
I do have a problem related to this implementation. Namely I can't figure out how to copy this information across the configurations. Currently I manually type that data across but obviously that is a terrible and time consuming method especially with many page drawings (each layout is handled as a different configuration). I was trying to use Dispatch to do so but it only works for data that is the same across all uses ie things like description.
This could be avoided if I could designate which configuration gets used when I Copy and "Paste as Reference" the Cable Assembly into the Assembly that it reports to. It seems seems to pick the last configuration on the list, most often its Layout2 but this does happen 100%. of the time.
So any input would be helpful.
Johnny, would you consider creating a part file for each cable type (maybe with a configurations representing different cable length, but the same cable type), place it at "Library" dedicated folder, and then create a solidworks assembly file, containing each cable, and a linear pattern to represent the amount of each cable or other part. I use this method when I need non-modeled data at native solidworks format, to be able to access custom properties and other information at BOMs and so on.
Another approach would be to think about Item based BOM, instead of model based, but this is a totally different topic and would not probably win the competition if you work primarily with Solidworks and do not collaborate with other mechanical/electrical engineering packages.
That is a decent suggestion, creating "fake" assembly files. It is an avenue I've trialed multiple times. For the work we do specifically, all the cables are different and custom. These Drawings and their associated BOMs also have to carry all the specific manufacturing data some of it non integer like 0.25 ft heat shrink, 4.7 ft 5 conductor cable. And its a lot of work to create and maintain those files. Plus we still need the AutoCAD Document to carry the manufacturing instruction. So in my experience this workflow of create the AutoCAD drawing, paste as reference the spec sheets, edit the BOM is the easiest for PDM to contain a succinct data set of all the needed PMI documentation. Unfortunately the system integrators who create this documentation use/know/love AutoCAD. So I need to make AutoCAD work well in PDM near term. I'm nearly there with this workflow. Once I nail this down I can focus on replacing AutoCAD with SW Electrical or just Routing and transition that crew away from AutoCAD. In many cases we still model connectors so we can effectively design assemblies around them but with a Modeled solution we can accurately represent those cables and better collaborate.
Jeff Sweeney , thank you so much for the suggestion. I think this can be a solution!
One more thing, though. Having a computed BOM only allows to set the variable for it's children. If there is a subassembly, then the variable for parts of that subassembly can not be assigned from computed BOM (am I wrong?).
Having that in mind, I thought that named BOM might be a solution. But there I noticed a strange behavior:
I saved a computed BOM to named BOM. In named BOM - the values in the column named "Purchase" (which represents the variable with an option "Look for variable in reference specific values") gets cleared out every time I click "Save". The values in other columns stays intact (these intacted columns represent the variables with the setting "Look for variable in referenced configuration and, if empty, in custom properties"). I can not find the problem why values can not be saved in this column. This happens even with "admin" user, so I don't think the problem can be with permissions.
Your method with assigning values in Computed BOM works as you described, but I am trying to find a way to avoid the checking-out a full assembly structure. Is there a reason why column of "Variables in reference specific values" can not be modified in Named BOM? Could you share any advise? This is the screenshot how values gets cleared out in "Purchase" column, but stays intact in other columns, after pressing "Save" :
Jeff Sweeney, thank you for your input again. Your ideas had got me to the route where I got the solution that is satisfactory to my situation. I posted it in Elizabeth thread, and I will repost it here for future reference. Here it goes:
1. Create a separate a separate drawing with an assembly of full project, save it to separate file
2. In this drawing, create an intended type BOM, containing all the elements.
3. Create one additional column and name it "Quantity total", do not assign any value to that column, leave it blank, only write the header of that column. It will be propagated as a "Free text" column inside the PDM BOM.
4. Save, check in this drawing. Now, this BOM inside the drawing can be accessed from PDM BOM tab. This method is better than standard PDM BOM computed type, because, for example, you can have more flexible BOM in the drawing, like "Equation" based columns, combining two or more custom properties, custom text, etc.
5. Save this drawing BOM in PDM as a separate named BOM
6. Now you can enter any value in this column, and it will become orange if edited. You can also change other values, and if you want to come back to original values propagated from original custom properties - clean out that individual cell.