cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Efficient creation of Parts from already existing WTDocuments

NA_9341349
6-Contributor

Efficient creation of Parts from already existing WTDocuments

I am using Windchill PDMLink Release 12.0 and Datecode with CPS 12.0.2.3

There is no efficient means of creating Parts (wt.part.WTParts) from existing WTDocuments that will be the describing document of the Part and have similar attributes. For example, when creating a part, there is a checkbox at the bottom called "Create CAD Document" which allows the user to create a CAD Document (wt.epm.EPMDocument) with the same Number, Name, File Name, and Version as the Part. This creates the Part and CAD Document at the same time with same relevant attributes.

We want a similar function but for already existing WTDocuments and creating a Part with using the attributes within the WTDocument. For example, we would want users to go into the related objects tab of the WTDocument, click on "Associate New" in the Describes Parts table, and have the new "New Part" window appear with as much attributes from the WTDocument as possible. Most importantly we would like the Name, Number, CAGE Code, Description and Version taken from the WTDocument and automatically filled in for the new Part.

How can this process be improved as there is a lot of rework to create the Part (wt.part.WTParts) and WTDocuments with the same attributes.
8 REPLIES 8

There are a number of paths you can take. First question to ask is which comes first, the part or the doc. It appears you would like to create a WTDocument and have a corresponding WTPart be created from it and associated.  Or are you creating the WTPart first and want that checkbox similar to CAD docs?

 

All options I can think of involve some level of UI customization. You can create custom actions to make a 1 button click create which takes the default attributes and say makes the part. This can work in either direction. One option we did many years ago was to add a step to the document create and edit wizard (hidden step).  This keys of a special soft-type we created call "General Drawing". If a user creates a WTDocument of type "General Drawing" or a sub-type of that, a WTPart is created and associated.  If the part exists, it links to it. It does as you describe, takes the number, name, CAGE Code and Version from the WTDocument to build the part. 

 

Over the years, I have had to make some improvements and add complexity such as what if I wanted the numbers to be different? This involve more rules to not just recreate that same Part all over again if I changed the Part number. 

 

Also consider loading via spreadsheet to backfill any existing objects and links that might have been missed through OOTB means.

I don’t think you even need the spreadsheet to do the bulk Part creation.

If the WTDocs exist the code can:

  • find the WTDocs
  • create the Parts
  • pass attributes values from WTDoc to Part
avillanueva
20-Turquoise
(To:d_graham)

Right, I only suggested that if they had  a backlog of uncreated parts.

Hi @NA_9341349,

This is Bhushan from PTC Customization Technical Support Team.

 

Based on your requirement, @avillanueva has given some insights on how one can proceed with such type of customizations.

 

If users create WTDocument first and populate the information required to be propagated on WTPart while working on document then finally proceeding with WTPart creation, it would be a good idea to develop a custom Wizard on WTDocument which can be enabled only when there is no WTPart related to WTDocument.
The wizard can be invoked to populate the pre-filled information in custom Create Part steps, once user validates information is correct Form Processor can be used to create and link the WTDocument with WTPart using the link type preferred.


If you need any assistance developing the customization, you can reach out to PTC Partners, PTC Professional Services.

 

Thanks,
Bhushan

Thanks for your reply avillanueva.

Typically we found that our users create the document first as they'll receive data and create a document to store the file/s and relevant metadata. We want to reduce the amount of rework required to create the Part object that will be described by said document. Users will be more likely to create document and part pairs if it is easier for them to create the part using the information from the document already. 

What you have described sounds similar to what we already have for CAD Documents while creating Parts but for Parts while creating a new document. So when users select "General Drawing" as a document type and select finish, Windchill creates a Part with similar metadata and with the document already set as the describing document? That would work for our needs as well.

Yes, the additional step to the wizard (for create and edit jsp files)

<%-- process if matches drawings as documents --%>
<jca:wizardStep action="process_drw_docs"  type="document" />

relates to the custom-actions.xml entry:

 <objecttype name="document" class="wt.doc.WTDocument" resourceBundle="com.ptc.windchill.enterprise.doc.documentResource">
        <action name="process_drw_docs" preloadWizardPage="false" hidden="true">
            <command class="customization.electrical.DrawingDocumentProcessorDelegate" windowType="no_content"/>
        </action>
   </objecttype>

It calls a postProcess method of my custom class above and once in code, you can do what you please. If this is the right path, please accept as solution. 

Hi @NA_9341349,

 

If you wish to create WTPart directly from WTDocument wizard, the best way to do this would be extending Out-Of-The-Box Create Document Form Processor, you can either override doOperation() method and add your logic after running super.doOperation() or postProcess() method and add logic after super.postProcess() in your custom Form Processor which will create the WTPart by deriving values from WTDocument.

Also, you can always check the Document Type selected while creating WTDocument so that code only runs on specific subtype.

 

In this case you only need to update action with custom form processor, no need to add new steps and develop delegate.

 

I hope this helps in your journey to decide best suited solution.

 

Thanks,

Bhushan

PTC Technical Support

We had a very similar need.

We solved the problem by running code in workflow that would create/revise the part and link part to doc and pass attribute values as well including version.

 

If the part already existed (based on doc number) the code would find the part and make sure it was linked properly and that attribute values were correct.

 

So, let’s say you are revising doc to rev D, if necessary, the code would create or revise the part to rev D, make sure attribute values are correct and that all links are correct.

The Rev D part was then checked to make sure no iteration of it was linked to revisions other than D. If links to revisions other than D were found on any iteration of part D these links would be deleted (without iterating the part).

 

Fully automating this prevented a lot of headaches.

 

This could be done with a listener too but we felt doing it in our workflow was the best way for us as we only cared about this if the doc was to be released.

 

Announcements