Object Rename During Life Cycle State Transition

[BF_13811900]

Version: Windchill 13.0

Use Case: I have the following requirements relating to how a custom workflow I have implemented treats objects as they are moved from state 1 to state 2. 1. The part number should be given a prefix which communicates the date and time its state was changed. 2. A check is made to ensure the part has not historically been at a state of "Released" before allowing the transition to complete.

Description:

Has anybody got a suggestion on how I can implement these aspects into my workflow?

[Fadel]

you can use an expression robot to change the object identity within the WF 

https://www.ptc.com/en/support/article/CS145098 

[joe_morton]

Just know that the part number is part of the master record, meaning that updating the number updates every version of that part going all the way back. 

In general, it's not good practice to change a part number. I'm curious for the reasoning for the business requirement 

[BF_13811900]

Hi Joe. I was to rename the object to give it a prefix when it moves to a state that will hide the part from the users but will still be available in the system in the event that recovery is required. The reason for the change in part number means that the original part number will be un-consumed and could be assigned to a new part.

[joe_morton]

That's a huge data concern.. You shouldn't be reusing numbers! That's a recipe for confusion and a mess if you were to get audited. 

[BF_13811900]

Hi Joe. My requirement to re-number objects no longer exists but I was wondering if you could educate me - what are the concerns exactly? I was only looking to re-number these objects after users decide that they need to be removed from the system. As far as the user is concerned, they would be changing the state of the object to emulate the object being deleted. However, the state change would not delete the object. It was just make it invisible to them and change its number to include a prefix of a timestamp of when its state was changed. This would be useful in the event that a user needed to recover any of these objects as this would not be possible if the user was to have done a permanent delete on it. Referring to my original post, I would only allow users to transition to this state that makes the object invisible to them if it had not been released into the production domain before. Consequently, there would be no risk of two different objects of the same type being released against the same number. Are you able to provide any adverse scenarios that this approach could lead to, given that the GUI of Windchill produces a comprehensive audit trail against objects and we could develop more comprehensive reports using SQL queries?