Inaccurate Part Version History - Structure Tab

[Turko]

Version: Windchill 13.0

Use Case:

1. I add two WTParts into Windchill - "Part 1, Revision A" and "Assembly 1, Revision A".

2. I then set the state of "Part 1, Revision A" to "Released".

3. I add "Part 1, Revision A" as a child into the structure of "Assembly 1, Revision A".

4. I set the state of "Assembly 1, Revision A" to "Released".

5. I then create a new revision of "Part 1" to create "Part 1, Revision B".

6. I set "Part 1, Revision B" to "Released".

7. I create a new revision of "Assembly 1" to create "Assembly 1, Revision B". (This was done as I want the new revision of "Assembly 1" to capture the fact that it now includes a new revision of "Part 1").

8. When I look in the structure of "Assembly 1, Revision B" I can see that the version of "Part 1" that features in it has automatically been updated from "Part 1, Revision A" to "Part 1, Revision B".

9. So, I then set the state of "Assembly 1, Revision B" to "Released".

10. I then navigate to the context of "Assembly 1" and select the "History" tab to view the versions associated with it.

11. I choose to "View Information" on the first version of "Assembly 1" that was set to "Released". This was "Assembly 1, Revision A" at the time.

12. I choose to view the "Structure" (under the "Structure" tab) of this version.

13. The structure displays "Part 1, Revision B" in it. However, this isn't accurate as this version featured "Part 1, Revision A" in its structure at the time it was "Released".

Description:

Why am I not being produced with a structure of "Assembly 1" that accurately reflects the state of the "Assembly 1" structure for the selected version? The version that I selected never featured "Part 1, Revision B" in its structure when it was set to "Released". "Part 1, Revision B" was only created after this version of "Assembly 1, Revision A" was set to "Released". Yet when I am looking at the structure for the first version of "Assembly 1, Revision A" that was "Released", it is showing that it featured "Part 1, Revision B", which is not correct.

It seems that the historic versions of WTParts doesn't accurately capture the revisions of child WTParts included in it at the time those versions were created.

Please can anyone shed light on the behaviour that I'm seeing and how I can configure Windchill to show me accurate representations of the revisions of child parts included in the structures of historic WTPart versions?

[Fadel · Accepted solution]

This is expected , the assembly part has an usage link to partmaster ,even if you  open the 1 revision of the assmebly the latest filter (default) will apply to child part and show latest version B.

Bottom line you have to change the filter to capture the part version A instead of B , generally customers use a baseline for capturing the versions A and use the baseline as filter  

[HelesicPetr]

Hi @Turko 

Your words describe how the system works. It is a fact. 

The WTPart structure does not have an as stored history so you have to use different tool to keep your structure history.

For example Baseline is the best way.

Promotion Request can store this information because the PR is also baseline. 

You can choice assembly that you want to release set the target state and collect all subassembly but do not set the target state for the rest of subassembly.

This can keep your structure history and then you can use filter to show the correct structure history configuration. 

PetrH 

[Turko]

Hi @Fadel and @HelesicPetr . Thank you very much for your responses. They have both cleared things up a lot for me and shed light on why the system is behaving as it is.

 @Fadel - I have noticed that the "Latest" filter is only applied when I view the structure of the latest version of a WTPart. When I look at the structure of a historic version, that was created on a different date to that of the latest version, the "As Matured" filter is applied to the historic structure. If I look at the historic version of a WTPart that was created on the same date as the latest version, the "Latest" filter is applied.

The issue with the behavior I have observed is that, if I release "Part 1" and then "Assembly 1" multiple times during the same day, the version history for "Assembly 1" will not keep an audit trail that communicates that it made use of different revisions of "Part 1" each time it was released on this day. If I wish to capture the configuration of a part structure each time the part is released, I should ensure a baseline is captured as part of the business process used to "Release" WTParts. Is my understanding correct?

I am intrigued by the comment from @HelesicPetr  - "Promotion Request can store this information because the PR is also baseline". My understanding is that I will have to rely on users taking baselines at the correct time to capture the exact configuration of each part structure when they are set to "Released". It's likely that users will not do this every time if I cannot enforce it via the configuration in Windchill. I could ensure that users have to raise a promotion request as part of the "Release" process. Would the process of raising/completing a PR automate the process of capturing of a baseline?

[Fadel]

Yes , the best way to keep track is use baselines whenever you release a version.

if you are using change notices to release or promotion you can filter by CN or PR 

[HelesicPetr]

Hi @Turko 

You have two options.

1. Teach users to use Promotion Request to capture a full configuration and It will create the right baseline or

2. you can write a code to create own full Managed Baseline at the end of the workflow .

example PR Wizard 

example structure filter

PetrH 

[Martin_Hill]

You also have the "as stored" configuration specification.

This will use the part versions that were included when that Version of the assembly was stored.

However, if you ever need to purge data from your database (to free up space) these versions might get deleted so better to use baselines as suggested by Petr and Fadel.

[HelesicPetr]

Hi @Martin_Hill 

If you work with WTPart structure, there is no "as stored" configuration . So you have to use baseline and set an internal method instructions for users. 

"as stored" configuration is only used in a CAD Document structure. 

I have a trick for you how to creat the baseline if the WTPart structure is build from CAD Document. 

- go to the CAD structure assembly,

- show the as stored configuration show the WTParts and select all structure

- create the baseline from that configuration.

Baseline will contain the correct wtpart versions and you can use this baseline to show as stored config in the WTpart structure.

- go to the wtpart structure

- set the filter structure with the created Baseline.

  

PetrH

[Martin_Hill]

My mistake!

I am so used to having associated CAD objects.