Describes doctype vs Reference doctype

[rmp.pe]

I made a reference to the difference between describes doctypes and reference doctypes in another thread yesterday, andI have received several private messages asking for more information on this. I thought it would be best if I just started a new thread on this topic, particularly so others more knowledgeable in the details of this can weigh in on the matter.

Most people are familiar with the difference between a "Describes" link between a document and a part and a "Reference" link between a document and a part.

• Essentially, a "Describes" link is version specific... i.e. rev A of the document is linked to rev A of the part. If you revise the document to rev B independent of the part, rev A is still showed as linked to the part (rev B does not automatically appear). If you revise the part, you have to manually select which version of the document you want to link to.
• A "Reference" link is version independent. Once you create the link between a part and a document, the link will always go to the most recent version of the document. So if the link was created from rev A of the part to rev A of the document, and then you later revise the document to rev B, the link automatically goes to the new rev B.

Each link type has its benefits depending on the business use-case and what you are trying to accomplish. My situation determines whether it is best for me to create a reference link or a describes link. This is where my issue with the architecture of the system comes in.

It is my understanding that when you createa document type, you must select whether that document type will be a "Describes document" or a "Reference document". What this means is that if you choose it will be a describes document, anytime you link that document to a part, it will always create a describes link. Similarly, if you create it as a reference document, anytime you link that document to a part it will create a reference link.

I am of the opinion that this is not a good setup. I believe that a document is a document, and the type of relationship you define with the part should be determined by the user and by the business scenario. There are times when different sites use the same document types differently.

A great generic example from within my company: we have sites that manufacture capital equipment and a site that manufactures chemicals. We have a document type of "work instruction", which is usually linked to a part to provide detailed instructions on how to "assemble" that part (be it a piece of machinery or a chemical formulation). Our capital manufacturing sites wish the work instruction to be linked to the part as a describe link, so that the details of the assembly instructions and part number referencesare always updated as they revise the BOM. The chemical manufacturing sites rarely change their formulations, so changes to the work instruction may be for safety reasons or to improve a process, but they don't need to revise their formulation each time, so they prefer this would be linked as a reference link.

The problem is that given the current architecture, we cannot provide both types of links for the same document type, it is one or the other. We could create different document types for each site, but then we end up with hundreds of different document types which creates a difficult andunmanageable user interface. So essentially we manage with one document type and do our best to help the users understand the limitations of the system and how to work with them.

If I've provided any information above that is incorrect, please let me know, but this is my understanding ofhow it works.

Regards,

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

-
http://www.steris.com

[ericstarkman]

Hi Bob,



There is a preference setting, "Part to Document Association Logic", that
determines whether the behavior is driven by type (reference document or
subtype thereof -> reference link; everything else -> describe link) or
whether the user can choose which type of link to create. See p. 6-16 or
7-52 of the Windchill 9.1 business admin guide.



The basic argument against giving users the choice is that many users
can't/won't/don't understand the difference between the link types well
enough to make the right choice. An organization with the right mix of
culture, training, business process, access control settings, and workflow
automation could certainly make this work, though it has been my experience
that most organizations prefer the current default behavior for its
simplicity and consistency.



-Eric

[dtkach1]

Bob,

Thank you for sharing such a good comment. I just want to add my 2
cents that its very important to relate part interchangeability function
to Document Structure and Product Structure.

Thanks,
Dmitry

[AL_ANDERSON]

The other thing to think about is how save as and revise operations on the
parts as well as the document are impacted by the relationships that you
choose.

I do not know of a preference for links on Save As and Revise as far as
carrying over part to document relationships. Let me know if you know of
one.

[patrick.chin1]

Because of many reasons:

1. Cannot find all the legacy documentation during migration of released and obsolete parts and documentation.
2. During an ECN process, there is an executive decision to release theentire from TOP DOWN structure with all selected associateddescribingdocuments andALL EPM association even though some children may not have fully reviewed or missing documentation.
3. Sometimes there is users would like to add additional specifications, certifications, validations to the WTPart for clearity withoutiterating(requires some additional customizations to break access controls) or revising the released part.

With the help of Najanaja.com, we created 2 new links:

• object to object describe link (version specific)
  • either side of the link is version specific and you can add if you are on the document side and part side
    • sometimes users who create documentation like to search multiple parts to be added to their single documentrevision.
  • if you revise either side of the link, the link iscopied to the next object revision. But, the user canhave a choiceto delete the link. If the user keeps the link,either the part or document object is linked to multiple versions of theother side of the link.
  • Afteran ECN, normal users cannot delete the link because both sides of the link is released and baselined.
• object to object reference link
  • either side of the link was only master (latest)
  • Again, the link was access controlled, but there was no need to save the link every time the user revises the part because it was always there.
  • the link did not iterate or modify either side of the link when joining 2 objects together. Sometimes people need to add addtional references after both the document and part was released.
• In the object information page, 2 additional tables were addedand the OOTB document table was rename to be specific to EPM
  • in the table, users had the ability or not (depending on the access) to delete or add new associations.
  • for the describe link table, users had the ability to view latest version or ECN baseline version. We had cases where multiple revisions of the part or document was still released because the effectivity of the ECN was still active and had not expired to send the documentation or part to obsolete/superceded or end of life.
  • The table showed it's revision and its ECN that released it. The part/documentmay have been released by a previous/different ECN.

Eventually, IP controled documentation was mostly associated with describe and most external standards were reference. The reference table was only used by the purchase/non-IP part co-ordinator in the purchase part library and document officestandards library for standards.

We also had to ensure that detailed components parts (non-assemblies) could not be revised according to CMII. If there is any physical change, it is a new part number. Some could debate the differences between casting versus machining. But, if the part did not meet design intent to withstand engineering conditions, and is replaced with a new detailed part, that new detail component part is a new part number. Only assemblies can be revised.

That's about it,

We had to take into consideration of CMII process.

[patrick.chin1]

One more thing,

If any object is deleted on either side of the link, the link is also deleted.

[RussPratt]

A note on background, in old Windchill Foundation, the "doc is a doc" logic existed, and users could create either the Describe or Reference link as desired. What happened, as noted in this thread, is that a large majority of users had trouble understanding that the difference was one of behavior rather than just terminology. So, when PDMLink was created, a decision was made to have the type of link depend upon the type of document; not necessarily a better solution, but not necessarily worse.

That said, the use case described here is valid; sometimes a document that may initially need a reference link, evenually needs to have a describes link. So, in PDMLink 9.1, there are enhanced abilities to manage the links, as well as to use the typeable link for more flexible needs.

Russ