Superseded Objects

TomU · ‎Oct 16, 2019

For those of you who are using Windchill for CAD file management, and not using WT Parts, how do you handle communicating that one object has been superseded by another? Do you remove all access to the previous object?

We currently use a pretty simple lifecycle template with only four states:

In Work --> Under Review --> Released --> Obsolete

Permissions are configured such that engineering can see everything and those outside of engineering can only see 'Released'. We've talked about setting the superseded object to 'Obsolete', but right now the only way for something to get set to 'Obsolete' is for an administrator to manually change the object's state. Since changing the state only affects the current revision, setting something to 'Obsolete' actually requires setting every (previously 'Released') revision of the object to 'Obsolete'. This really limits it's usefulness and why this is currently an admin only function.

I'm considering maybe adding a fifth state called 'Superseded'. This would be different from 'Obsolete' in the sense that it would still be visible to those outside of engineering, but like 'Obsolete', engineers would not be able to revise anything that has been set to 'Superseded'. Of course the problem with this approach is that there is nothing telling anyone what the new object is called that is replacing this superseded one.

Curious what others are doing. How do you handle superseded objects?

MikeLockwood · ‎Oct 16, 2019

Lots of posts like this for ~ 20 years.

All seem to have similar needs and approach various ways.

Edwards Lifesciences is discussing again also - this time attempting to fully take into account what happens in ERP and elsewhere. Nothing substantial to report yet.

Note: Learned the hard way many years ago not to use this simple approach:

- Configure LC to promote (or Change) to Obsolete

- restrict READ access to Obsolete state

- undesired (chaos) result is that all see the previous Rev at Released and don't know that last Rev is Obsolete 🙂

Seems that discussion has to circle around to some use cases by roles of people. Compare before / after setting to SuperCeded (or similar), what does / can a person in these roles do differently?

- CAD designer making changes to Released data

- CAD designer working on new conceptual approach, using the data which has been superceded (currently in their workspace)

- Person responsible for ERP system changes (automated / manual)

- Buyer in Purchasing

- person on mfg floor

- inventory control person

- people responsible for procedures with Part Numbers typed in

- Suppliers who currently have PO's and drawings for data that has just gotten set to Superceded

… list goes on

TomU · ‎Oct 16, 2019

@MikeLockwood wrote:

- undesired (chaos) result is that all see the previous Rev at Released and don't know that last Rev is Obsolete

Yep, this is exactly why when I (administratively) set something to 'Obsolete', I do so for every revision.

I guess this is why I'm trying to decide if I want to automate this process. Could I build a promotion request process that sets all versions of an object to 'Obsolete'? I'm assuming so, but I've never tried...

Of course the challenge with this approach is that two separate promotion requests would be required since only one target state can be selected per promotion request. One promotion request would need to be created for the objects being released and another promotion request would need to be created for those items being superseded (or set to 'Obsolete'), with no relationship whatsoever between the two requests.

I suppose this is what full blown change management and the related change objects are designed for - moving some things to 'Released' and setting other things to 'Obsolete', and doing so all together in a single process. I'm just not sure as a company we're ready to make the leap from promotion requests to full blown change management. Every demo I've ever seen is crazy complicated, has multiple steps and objects to deal with, requires manually collecting data on different screens, etc. We don't want or need a complicated release process and I'm not sure we can keep it simple and easy to use if we switch to full blown change management.

BrianToussaint · ‎Oct 16, 2019

Except for family table objects, which are there own problem, I move all my obsolete items to a library that only has rights for those that need to see obsolete objects. I only obsolete the latest. I do this since it moves all the revisions to the library. The shortcoming here is that if you orphan and obsolete a family table instance, you cannot just move the single item over to a library. It works in most of my cases but as I am starting to obsolete purchased items that are obsolete but in tables so that users cannot use them, this is starting to be more of an issue.

JHall · ‎Oct 18, 2019

@TomU

In my old company, all former revisions of the WTPart, CAD object, WTDocument, whatever went to Superseded and were only visible by Engineering when an Object was Revised.

Outside of Engineering could see Prototype and Released. There was also an Obsolete state, but as I recall that may have been viewable by Engineering as well, but I can't quite recall.

James
Windchill 11.0

TomU · ‎Oct 29, 2019

Well, the decision has been made by management, now I just have to figure out how to best implement it.

1.) All released versions of active objects may continue to remain accessible to everyone. (No change.)

-.0 In Work

-.1 In Work

-.2 Released (visible to everyone)

A.0 In Work

A.1 Released (visible to everyone)

2.) All released versions of superseded objects must have their states changed to either 'Obsolete' or 'Superseded' (if we add that state) and no longer available for ordering or revising.

-.0 In Work

-.1 In Work

-.2 Obsolete (only visible to engineering)

A.0 In Work

A.1 Obsolete (only visible to engineering)

The question now is, how to do this? Does anyone have any suggestions on how to use out-of-the-box promotion request or change management functionality, or write a workflow expression that will collect all released versions of the selected objects and change all of their states from one state to another? I definitely don't want the users to have to manually collect each revision of every superseded object...

DmitryC · ‎Dec 10, 2019

Hi Tom,

Hopefully, this can help:

wt.maturity.StandardMaturityService p = new wt.maturity.StandardMaturityService();
wt.maturity.PromotionNotice pn =(wt.maturity.PromotionNotice)primaryBusinessObject;
wt.fc.QueryResult pn_targets;
pn_targets = (wt.fc.QueryResult) p.getPromotionTargets(pn);

while (pn_targets.hasMoreElements()) {
  Object obj = pn_targets.nextElement();
  String objType = obj.getClass().getName();

  if (objType.equals("wt.epm.EPMDocument")) {	
    wt.epm.EPMDocument doc = (wt.epm.EPMDocument) obj;

    wt.fc.QueryResult versions = wt.vc.VersionControlHelper.service.allIterationsOf(doc.getMaster());
    while (versions.hasMoreElements()) {
      wt.epm.EPMDocument docIteration = (wt.epm.EPMDocument) versions.nextElement();

      if (docIteration.getLifeCycleState().toString().equals("RELEASED")) {
        docIteration = (wt.epm.EPMDocument) LifeCycleServerHelper.service.setState((LifeCycleManaged) docIteration, wt.lifecycle.State().toState("YOUR_STATE_HERE"););
        wt.fc.PersistenceHelper.manager.modify(docIteration);
      }
    }
  }
}

I didn't test it, but, at least, it can give you a direction.

TomU · ‎Dec 10, 2019

Cool! Thanks!!!