Describes doctype vs Reference doctype
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