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

Community Tip - New to the community? Learn how to post a question and get help from PTC and industry experts! X

Windchill preference values on user & container level are not always showing the correct value

Windchill preference values on user & container level are not always showing the correct value

Windchill preference values on user & container level are not always showing the correct value that confuse Windchill behavior - see article CS351826

 

1. Describe your environment:
What is your industry? 
Automotive
What is your role in your organization? 
Business Analyst
Describe your stakeholders.

Product Owners = what we produce on the shop floor

Manufacturing Owners = responsible for our production and how we produce on the shop floor


2. What version of Windchill are you currently running? 12.1.1.0


3. Describe the problem you are trying to solve. Please include detailed documentation such as screenshots, images or video.
Please see article https://www.ptc.com/en/support/article/CS351826 that state Windchill preference values shown in GUI could not always be trusted and this will never be fixed.

This idea is to always show correct preference value that Windchill will act on for each user in each Product/Library/Organization.

 

As-Is situation

If a preference today is set on site level and delete child instances isused the site value is shown on all sub-levels.

If now you change preference value on Product/Library level Windchill will act on that preference value but on user level it still shows another value.

This problem occurs in many different combinations for Site / Org / Product/Library / User levels when preference value is set different over time.

At the end you cannot trust preference values but you need to test to see how Windchill act and with that point you are in a mess.

Idea

If a preference value is not set on a sub-level, add information from what higher level the preference value is inherited from.

 

Example:

 

A preference is set on site level and delete child instance is used, value shown:

  • Site => value
  • Org => value ( inherited from site )
  • Product/Library => value ( inherited from site )
  • User => value ( inherited from site )

The preference get a new value on one ( 1 ) Product/Library "A" value shown:

  • Site value
  • Org => value ( inherited from site )
  • Product/Library "A" => new value
  • Product/Library "all others" => value ( inherited from site )
  • User => value ( inherited from site ) or new value ( inherited from "A" Product/Library )

The preference get a new value by one ( 1 ) User "B" value shown:

  • Site value
  • Org => value ( inherited from site )
  • Product/Library "A" => new value
  • Product/Library "all others" => value ( inherited from site )
  • User "B" => new user value
  • User "all others" => value ( inherited from site ) or new value ( inherited from "A" Product/Library )

Now we can always trust and understand preference settings and predict Windchill behavior.


4. What is the use case for your organization?
To be able to use Windchill as a PLM-solution, today we doing the work in Excel and legacy solutions because of this GAP in Windchill.
It is always a quality risk when the PLM-solution is showing wrong data for users.

5. What business value would your suggestion represent for your organization?
Remove local isolated Excel files and legacy solution and move into a modern PLM-solution that will help us to shorten project lead time, secure quality in product design and manufacturing preparation.
If not Windchill will solve this we need to select another PLM-solution.

1 Comment
olivierlp
Community Manager
Status changed to: Acknowledged

Thank you @awijkmark for your idea. Based on the information you provided, we are acknowledging it as the Community management team. This is not a commitment from the Product team. Other users may comment and vote your idea up.