CN Affected Objects Table To Set State/Transition Obsolete based on the Disposition Value.

[PatrickChin]

Hi All,

Like every Engineering Change Notice/Order.  The from/to table is very close to the affected and resulting table.  Some companies like to set state/transition the affected table of objects to obsolete based on disposition and effectivity.  Also, there are business rules where you can only put released items in the affect table of an CN. While the new or new revisions of objects get production released and applied also based on effectivity, the affected table of objects can remain released or get set to obsolete/supersede based on the disposition.  This is the closed-loop process of a change request to a change notice.  The resolution of a change request is both the obsolescence of the affected table and release of the resulting table in the change activity/notice. 

This should be out-of-the box functionality.  It seems that the functionality is not complete and needs customization to complete the simple very common process.

[d_graham]

Interesting. So, once the current date finally reaches the effectivity date of each Resulting object automatically set the Resulting object’s state and the Affected object (previous version that is in the Affected table) to Obsolete or whatever depending on the disposition.

The Change Notice might have been approved three months ago but wait for effectivity date to set the states to change the states and the state you change to is determined by the disposition.

Is that or something like that the idea?

[avillanueva]

Was hoping someone had a solution posted with code. This is on my list of to do's. My required is less complex and I would use the "Superseded" state as opposed to Obsolete. Tomato tomahto but idea is the same. I would recommend not leaving workflow open waiting for effectivity date since it could be a long time. This means you need a scheduler task to look for when those dates are reached. However, now that I think about it, its that the job of effectivity to not have to change states and let the effectivity drive the BOM generation?

If we ignore effectivity (effective immediately) it can be part of the workflow. Very straight forward to have a robot to set affected items just like it does for resulting items to Released state. If I get around to it on my list, I will post method to set state on affected items via a robot task.

BTW, doing this opens up possibilities on other things like preventing accidental download of old revisions.  There is another thread on this.

[MikeP.]

Hey  @avillanueva, @d_graham, @PatrickChin  dug this up as I'm looking into solid use-cases for the new (12.1.1) "Change Intent" capabilities on the CN, and the Mapping Rules capabilities/Release Targets (driven by release intent on the Change Notice).

Two of the options that just make sense here are "Supersede, and Obsolete"

Was wondering if you've taken a look at how this plays with Effectivity?

If it's not there yet, it seems like a big step in the direction for the use-case described above. I suspect that Obsolete change intent + effectivity date will be coming as an automated flow if it's not already there.

[d_graham]

@MikeP. ,

I could be wrong, but I don't think this is OOTB as of 12.1.2.0.

That said, adding to workflow to wait until effectivity date is reached to set state on Resulting (to Released or whatever) and Affected to Superseded (or whatever) should be easy.

I'd go with workflow approach rather than Scheduling Queue entry as the workflow would give it more visibility.

Scheduling Queue could work however, I'm thinking the scheduled class would run daily, checking the effectivity dates. Those whose date is before tomorrow would have the objects state changed (assuming the CN is Resolved or course). And finally, the class would have to automatically reschedule itself for tomorrows run.

I've done stuff like this for auto remove unreferenced files (1st Saturday or every month) and auto delete Publishing Queue entries (also 1st Saturday of every month).  Both auto reschedule for the next month.

The more I think about it the more I like the Scheduling Queue approach.

If anyone is interested reach out to me from you work email at windchill.developer@yahoo.com 

Until @PatrickChin 's posted this I hadn't thought about it, but I have to say, it makes a lot of sense.  I like it. 👍

David

[MikeP.]

Appreciate your thoughts on the solution. Does seem like the workflow approach would be more straightforward and "native".

Original idea may deserve itself a spot on the Windchill Ideas forum. I might piece something together in the coming weeks and add a link to the suggestion here. After all, this truly started out as a suggestion.