Various document types VS. One document type

[ptc-3006345]

Hello,

We are working to control our documents objects using WTparts with product structures. We are at a cross roads on whether we should create different document object types for each corresponding document i.e. specification, first articles, capability, quotes, test results or just create an attribute under document with a drop down for each type. Anyone have a best practices they would recommend?

Thanks!

Take care,

Jeremy Handler
Hunter Industries
Mechanical Engineer
1960 Diamond Street
San Marcos, Ca 92078
(760) 591-7318
[Description: Description: Grren] Consider the environment. Consider the impacts.

[achukwuka]

Jeremy,

During my time supporting Windchill, we just created an attribute under document with a drop down for each time of document we had on the system. We did not feel that it was a good idea to have multiple document object types for our specific use case.

Hope this helps.
Thanks

Alexius C. Chukwuka
IT Analyst, Global SAP Basis
Technical Change Management (TCM)
Deere & Company World Headquarters
400 19th St, Moline, IL 61265
Office: (309) 765-3133
Mobile: (319) 429-5336

[AL_ANDERSON]

With types you get a different Icon that you can make for yourself. You
get different access control options for different types in the same
context. You have the option of having different IBAs for each type. You
can limit your searches, particularly with saved searches, by type and
then tailor those saved searches to the type-specific IBAs. You can have
different OIRs by type for each type in the same context. There are a lot
of options available with type that you will not have with an IBA. If you
need or may ever need this flexibility, then make different light types.

On the other hand, if all attributes for two documents are the same, and
all access rules apply equally to both documents, and if the OIRs in any
context they reside are always the same, including lifecycle, numbering,
etc, then those two documents are actually the same "type" and to
differentiate between two categories of the same type, then you should use
an IBA with a drop down box of allowable options.

Al Anderson







[solutions] - Various document types VS. One document type

Jeremy Handler

[MikeLockwood]

Well stated by Al.

Keep in mind that you can also assign a different lifecycle, numbering, etc. to the same type in a different Product or Library. We do this in many special-purpose Libraries such that the root document type has a completely different process depending on where it has been created.

One workaround that we use (and we know that many others do as well) is to limit what type(s) can be created in any given Product or Library. There are no tools from PTC to do this, but this technique works perfectly. Simply specify in the OIR for each type that you do not want to allow a lifecycle that does not exist. The system pre-validates against valid lifecycle(s). If there is only one valid lifecycle, it skips past.

Example - we prevent Patent Documents (which is a sub type) from being created in the Library where this OIR exists:

[cid:image002.png@01CD3763.37C3EF10]

[mjohnson-5]

I agree, Al outlined the trade offs fairly well.

One thing I would add is (if you can use the same lifecycle scheme) that the attribute is generally easier to support.

Meaning, if (when) users create the wrong type they don't have to start over, they can just change the attribute.

Depending on the situation, this approach can save the business a lot of time and effort. Enough that using a combined set of IBAs for the needs of the different types would not be a big deal.

Mike Johnson

[DarrenStorey]

If the document type attributes, number and version scheme are consistentbut you want to apply a selection of differentlifecycle and team templates within a given context there is another option you could consider.

You can configure the object initialization rule for documents to allow the document creator to select the lifecycle and team template from a pull-down when creating the document. (If you trust them to pick the right one)

See attched screenshot of resulting document create wizard, sample OIR xml below

Regards Darren

<attrvalue id="lifeCycle.id"&lt;br"/> algorithm="com.ptc.core.foundation.lifecycle.server.impl.LifeCycleTemplateAttributeAlgorithm"
ignore="false"
force="false"
final="false">
<arg>Lifecyle A</arg>
</attrvalue>

<attrconstraint id="lifeCycle.id"&lt;br"/> algorithm="com.ptc.core.rule.server.impl.GatherAttributeConstraints"
ignore="false"
force="false"
final="false">
<value algorithm="com.ptc.core.rule.server.impl.GetServerPreGeneratedValue"/">
<value algorithm="com.ptc.core.foundation.lifecycle.server.impl.DiscreteLifecycleTemplateSetAlogrithm">
<arg>Lifecyle A</arg>
<arg>Lifecyle B</arg>
<arg>Lifecyle AC</arg>
</value>
</attrconstraint>

<attrconstraint id="lifeCycle"&lt;br"/> algorithm="com.ptc.core.rule.server.impl.GatherAttributeConstraints"
ignore="false"
force="false"
final="false">
<value algorithm="com.ptc.core.rule.server.impl.GetServerAssignedConstraint"/">
</attrconstraint>

<attrvalue id="teamTemplate.id"&lt;br"/> algorithm="com.ptc.core.foundation.team.server.impl.TeamTemplateAttributeAlgorithm"
ignore="false"
force="false"
final="false">
<arg>Team A</arg>
</attrvalue>

<attrconstraint id="teamTemplate.id"&lt;br"/> algorithm="com.ptc.core.rule.server.impl.GatherAttributeConstraints"
ignore="false"
force="false"
final="false">
<value algorithm="com.ptc.core.rule.server.impl.GetServerPreGeneratedValue"/">
<value algorithm="com.ptc.core.foundation.team.server.impl.DiscreteTeamTemplateSetAlogrithm">
<arg>Team A</arg>
<arg>Team B</arg>
<arg>Team AC</arg>
</value>
</attrconstraint>

<attrconstraint id="teamTemplate"&lt;br"/> algorithm="com.ptc.core.rule.server.impl.GatherAttributeConstraints"
ignore="false"
force="false"
final="false">
<value algorithm="com.ptc.core.rule.server.impl.GetServerAssignedConstraint"/">
</attrconstraint>