Best Practices for WTPart Associations to WTDocuments?

[mdebower]

I am wondering what everyone is doing for associating WTParts to WTDocuments...

For example, I am specifically interested in the following use case:

We have a set of WTDocuments that are engineering specifications.  They cover internal standards for painting, plating, etc...  Each one of those WTDocs could potentially be associated to hundreds or thousands of WTParts.  Which seems like it will quickly get clunky and hard to manage...

Questions I have:

1. Do you currently make associations in the above case?
2. If so, what permissions are you giving users to be able to associate WTParts to the WTDocument?   The document is at released and we don't want everybody making changes to it...
   1. Okay, I did some testing with my regular user account and was able to associate the WTPart to the WTDocument at Release.  So this may not be an issue.
3. Do you have an alternate practice instead of associations?

System is Windchill 10.1 m040

-marc

TriMark Corporation

CAD / PLM Systems Manager

[manjunathrv]

We do associate WT docs like process, material etc to WTP as "Reference documents". these associations are made before releasing WTP.

Also these WT docs are in released state and are stored in library folders in Windchill with modify access only for administrators.

So there is no question of modifying these docs while association since only the WTP will be checked out and has to be checked in after associating.

[MikeLockwood]

Couple of thoughts.

1. Make sure that these documents are "Reference Document" or a created sub type of them - such that the Revision of the Document which is retrieved with a WTPart is the latest Rev (Reference relationship to WTPart floats to latest - RELEASED state or as configured).

2. Can load a whole bunch of these relationships from spreadsheet and may be worth doing so- once, but it's a major maintenance headache in general, so may want to consider if all these links are helpful.

3. Might want to associate all that apply only to the End Item for each Product - which is what we did at previous company.  It doesn't directly give the list of documents for each component / sub assembly / assembly but was good enough - from the End Item, get a relationship report and then get the list of all applicable reference documents.  Can supplement with relationships where needed to individual Parts.

4. Create query builder Reports such that people can get the reference documents and output to Excel quickly and easily (same as from the WTPart page but saves a few clicks.

[RandyJones]

Mike Lockwood wrote:

Couple of thoughts.

1. Make sure that these documents are "Reference Document" or a created sub type of them - such that the Revision of the Document which is retrieved with a WTPart is the latest Rev (Reference relationship to WTPart floats to latest - RELEASED state or as configured).

Mike: What are your thoughts on setting  the preference "Part to Document Association Logic" to Yes to allow non Reference Documents to be added as a Reference Document?

[ahamblett]

Re: "from the End Item, get a relationship report"... Q:  is this report only applicable to End Item CAD Objects?  I've never seen such a report. Where would I find such a report? For ref. we're operating in Windchill 10.2 M030.  Thanks in advance!

[kpritchard]

I have implemented associations where appropriate between WTPart and WTDocument previously, which has several benefits;

• The ability to evaluate a "where referenced" for doing an impact analysis if/when any document changes.  One size does not fit all and in some cases a new document may be warranted as the proposed change does not suit all uses.
• The ability to compartmentalize information.  The ability to separate and reuse information rather than repeating (I'm thinking about detailed drawing notes as opposed to a note that references a document).  If separated you can make a change to a single document rather than needing to change many drawings.  This would be problematic without a systematic linkage such as association (see above).
• You get a powerful visual overview of these relationships in a WTPart Structure by being able to show related documents, at all levels within the structure.
• I started to look at being able to automatically assemble and/or print a document package from within the WTPart Structure.  I'll qualify by stating that I did not actually implement but it did look like all the pieces were there (or could be with an add-on)
• You can see linked documents on the Related Tab of an individual WTPart.

I do agree with Mike Lockwood on Reference Document recommendation unless/until there is a compelling reason to use WTDocument.  Also recommend sub-typing the documents.   

[Marco_Tosin]

Marc,

I have an answer for question 2

Our consultants did a customization a few years ago to associate a WTDocument to one or more WTpart.

They created a custom attribute in which the user should write the Number of WTPart, separeted by a semi colon if more than one (123;956;NewPart01).

When the user check-in the document the customization search if the WTPart exist and it's not in check-out state and then build a link using administrator rights, despite the role of the user or the state of the WTPart.

More recently they did another customization for a specific set of users who wants to delete an associated WTPart from a WTDocument.

This is the result.

The two blue icon modified the behavior of the green one, giving the possibility to a specific role in the context to add or delete a WTPart.

I'm sorry but I can't give you more details or a piece of code to use.

[MikeLockwood]

Important decision to set this preference as stated - that to me, seems to throw away very useful functionality.  Even if not useful at the moment, may be very useful to the organization at some future time.

[RandyJones]

Mike Lockwood wrote:

Important decision to set this preference as stated - that to me, seems to throw away very useful functionality.  Even if not useful at the moment, may be very useful to the organization at some future time.

My understanding of this preference "Part to Document Association Logic" = Yes will only change what type of documents can be added as a Reference Document link. It will NOT change how that Reference Document link is handled. So to me what you would lose is the ability to easily search Windchill for documents that could be used as a Reference Document link. Because you couldn't simply search for all documents of type Reference Document (or subtype). You would not lose the functionality of a Reference Document link.

Am I missing something important here? We haven't started using these yet however are close and I would like to know if I am missing out on something here.

Thanks Randy

[MikeLockwood]

Good point, I stand corrected.

But, if at any future time, you reverse the preference, the documents returned may not be as expected.