How do you handle purchased assemblies?

[Steve]

Question for all of you:

How do you handle the filing of purchased assemblies?

For example, if I have a purchased assembly that is made up of hundreds of nuts, bolts, washers, and other components, how would I save this into the database as a single item?

I thought I had a solution by saving it into Work Manager as a package. This works fine until you use this assembly in a higher-level assembly and then save that higher-level assembly as 3D data into Work Manager. WM then blow the purchased assembly into individual components into the database with essentially random names (i.e. screw-BHGHZADED, nut-AZDERADFE, etc.)

This presents two problems. First, I now have a bunch of junk in my database that does not correspond to any real corporate part that my company purchases or manufactures.

Secondly, and more importantly, when I send my packet of files off to our release person to release my assembly I have to send all of these "phantom" components along for release, too. This completely freaks out the release person, because they expect to see only the parts in the packet that are listed on the ECN (Engineering Change Notice) to be released.

If I just don't include all the phantom components in the packet I send to the release person, then she releases the purchased assembly but because she has not released the components they can still be modified - in essence the purchased assembly has not really been released.

One solution is to unite all the components together into a single blob that that is a poor solution.

Other CAD systems that I have used allow me to create a single part file that contains multiple, non-connected solid bodies. This lets me model an "assembly" but all the "components" reside in a single part file (i.e. there is no BOM assembly structure).

How do you all handle purchased assemblies?

Steve

[May Kung]

Originally posted by Steve

Secondly, and more importantly, when I send my packet of files off to our release person to release my assembly I have to send all of these "phantom" components along for release, too. This completely freaks out the release person, because they expect to see only the parts in the packet that are listed on the ECN (Engineering Change Notice) to be released.

This is what we do here. Since with purchased assemblies, the child parts rarely need to change, we have instructed our Document Control to change the State for the documents from Sandbox to Released, ignoring revision/version numbers. Only the parent assembly is listed on the paperwork and its revision/version is tracked.

As you said, it's a bit of work, but parts do not need to change often, so it's manageable. Not changing the state to Release caused the same issues you mention, where child parts of a released document are still modifiable.

[Steve]

What kind of naming convention do you use for child components of purchased assemblies?

Or do you just have millions of entries in your database like washer-ASDFBASDF, screw-ADSFBEF, etc.?

And when you send your packet to your release person to change the work state, how do they know what they are releasing? Our release person is used to seeing drawings (and now geometry) that relates to a specific part number. I don't think they are going to be keen on the idea of releasing hundreds of other undocumented parts just because I said so. They only want to release specifically what the ECN says to release.

Steve

[May Kung]

We name child parts (and assemblies) with the same base number, but a different dash number. Usually, our dash numbers are purely numerical, of three digits in length. Only the main part/assembly gets assigned this base number and the main dash number.

For example:

1001-002002 might be the base number for a block of aluminum with two pins press-fit into it.

The full number for the assembly, which happens to have three child parts (block, pin 1, pin 2) is 1001-002002-XXX. The solid model of the assembly is saved into Work Manager using the full number.

The structure might look like this in the Structure Browser:

block_asm_1001-002002-XXX
block_1001-002002-S01
pin1_1001-002002-S02
pin2_1001-002002-S03

We use a different letter for the first digit of the dash number to indicate what type of child part it is.

S=subpart
A=subassembly
P=purchased part/assembly
F=fabricated part/assembly

This way, if a user runs a query in Work Manager for a particular document and sees a whole list, the letter will tell if it's a "true" part, or just a "dummy" or "phantom" part that has to be uploaded into the system so the main assembly will work. We do not relate these subparts to the part number so we can reduce clutter. Only the full assembly is related to the part number.

[dszostak]

Hello Steve and May:
In CoCreate's September release of v12, the data management software has the ability to specify assemblies and models as a purchased, fabricated or reference part. This specification can be done inside Designer Modeling or in the data management system when you pull up the properites of that part. This functionality comes with the integrated product of Model Manager.
If you are interested, you can watch a demo of Model Manager and it's v11.65 BOM functionality on our website - CoCreate Online Demos (http://www.cocreate.com/demos.cfm)

Take a look at the attached screenshot - It shows you that the CAD user is selecting the brake caliper as a purchase part instead of an assembly. When the user does this, this information is sent to Model Manager and the children of the that assembly are not counted in the BOM and it is flagged as one part.