How do you handle associating documents to controlled Parts?

[sdrzewiczewski]

I was recently asked by some users how they should handle associating some documents to a Part that has already reached a controlled state. These documents are not describing documents. The user would like to be able to do this without Revising the part to move it back to a modifiable state, or having to have an admin add the associations.

[cc-2]

Hi Stephen

What is the question really ?

I guess it is just a question of access permissions to be able to check out the WTpart when it has reached a controlled state

Best regards

[HugoHermans]

A WTPart that is in a controlled state (Released) is not supposed to be
checked out. Permissions should be set that released/controlled WTParts
have to be revised in order to check it out.



But the problem of Stephen is, as far as I see, that later in de life
time of the part, additional information is gathered about the part.
Since the part is already released and so unmodifiable, there is no
option to add additional documents to the WTPart.



Our work-around is to add (empty) placeholder documents to the WTPart
before releasing it. These documents get there own life cycles, so you
aren't dependant from the life cycle state of the wtpart.



Regards, Hugo.

[rmp.pe]

This is not a new problem...anytime you build a link, it is a parent-child relationship, and the parent must be modified in order to create the link. In this case the WTPart is the parent. If the parent is locked, how do you build the link?

People have been bugging PTC about this for years. Some people have created customizations where they can build the link from the document side. I'm not sure what they do under the hood, if it automatically checks out the WTPart and checks it back in or if it operates a different way. Hopefully some people who have created these customizations will reply to this post and provide more information.

We have a similar problem... if you have a describes link between a part and a document, and you revise the document, the revision does not appear on the part page unless you update the link on the part side (I know you "should" use a reference link in that case, it's a legacy 7.0 issue, don't get me started on the whole describes doc type vs reference doc type subject...). There is no reason to "revise" a part just for this, which involves the extra work of updating a drawing and doing distribution of the change, updating MRP systems, etc.... so we created a specific local admin role that has rights to go in, check out the WTPart, update the link and check it back in. Of course this should be documented in an assigned Change Task so you have traceability. We use the role in a way that it is normally empty (no participants), but a Product Manager can assign themselves to it temporarily to perform this task. Then we ask that they remove themselves again so that they don't accidentally do something to a released item that they shouldn't be doing.

Regards,

Robert M. Priest, PE, PMP
Engineering Manager
STERIS Corporation

-
http:www.steris.com

[mkraegeloh]

well,

you can always PersistenceServerHelper.manager.insert(...) the links on
the server - it is just a matter of how you design your customization.

martin

[RajuPulavarthi]

Robert,

You mentioned accurately about the nature of the Part Describe Link. I
had to do a customization (for a client when I was a consultant) in the
Windchill foundation days to control this behavior when Documents are
revised and released (usually along with the Parts) through the Change
Process.



For each Document attached to the CR's Change activities, it would look
for previous versions, get their Described By Parts. If there is a newer
version of Part, I would attach this Document to the newer version of
the Part. Otherwise I would replace the older Document version with the
newer Document version for the same part. This still needed the Parts to
be checked out automatically as Windchill Admin, some of which might be
in the Released state. The end result is probably similar to what you
have described but it was automated in the Change Process



Usage of Reference link in some cases was not useful as the client
needed to track the specific versions of the Document.



Raju Pulavarthi

St. Jude Medical

14901 DeVeau Place

Minnetonka, MN 55435 USA

- <blocked::<a style="COLOR:" blue;=" text-decoration:=" underline&quot;=" target="_BLANK" href="mailto:-">">mailto:->

sjm.com

[patrick.chin1]

With the help of Najanaja.com, we had requirements to create 2 new types of links:

• object to object reference link (latest for both)
• object to object describe link (version specific for both)

the difference between these links compared to the OOTB links is that:

• it does not iterate the part when you associate.
  • some part or documents get released prior to adding additional reference objects. Thus, fit, form and function doesn't change either part or document by adding additional documentation to describe or reference either.
• the link has access controls so that only various users can create and delete depending on conditions:
  • cannot delete only if both sides of the link are released. If both objects are released, only certain groups/admins can delete.
• the object to object link can be created from any side of the link which is either part or document or EPM.

[patrick.chin1]

The next step is to put an approval against the new "link objects", we could then have a process to make sure there is a review process to the technical reviews to approve the link prior to locking it down. Again ask Najanaja.com

[RussPratt]

I certainly understand the core questions within this thread, but the issue is not one of software capability, it is one of business process definition. If you say that "Controlled parts cannot be checked out", and you mean it, then you need to have a process in place to formally modify the part when you "modify its definition" by associating other objects to it. Whether or not this modification should be an interation or a new Revision, is up to your CM rules. I know many people will say that, "associating a document does not modify the part", but I'll challenge that statement on a business logic level. PLM involves managing not just files and objects, but the relationships between those. That relationship management is at the core of PLM. It is important to understand WHY you have rules about Controlled Parts, and consider that the rules may not be fully developed for the PLM world. What worked in a legacy, paper world, may not be sufficient for the PLM world.

Russ

[sdrzewiczewski]

Thanks Russel. I agree that it's not a software capability question, as
much of how we have it configured. I just wanted to understand how others
choose to work around this situation. I have ideas that we'll probably
implement, but love seeing what others in the community have done or are
planning to do.