Skip to main content
N
NA_93413497-Bedrock
7-Bedrock
August 9, 2022
Question

Efficient creation of Parts from already existing WTDocuments

  • August 9, 2022
  • 2 replies
  • 3650 views
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.

    2 replies

    avillanueva
    23-Emerald I
    avillanueva23-Emerald I
    23-Emerald I
    August 9, 2022

    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.

    D
    18-Opal
    d_graham18-Opal
    18-Opal
    August 9, 2022

    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
    23-Emerald I
    avillanueva23-Emerald I
    23-Emerald I
    August 10, 2022

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

    D
    18-Opal
    d_graham18-Opal
    18-Opal
    August 10, 2022

    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.

     

      Terms & ConditionsCookie settingsAccessibility statement