Deleting in work resulting objects when removing from change task

[smeckstroth]

Does anyone know of a way with (minimal to nocustomization) to have the system delete objects in the system that have been removed from the resulting objects table of a change task? Or maybe some way to efficiently search for all theseorphaned resulting objectsso they could more easily be manually deleted?

My understanding of WC10 out of the box funtionality is that if I decided to revise an object into the resulting objects table of the change task the next rev of the affected object (let's say B) is created in the system and displayedin the resulting objectstable. If I then decide I will not be making a change and do notneed to revise that object toB and removerevB from my resulting objects table, Rev B still exists in the system. I need to find some relatively efficient way of deleting those objects from the system without customizing the system to do it automatically.

Any ideas would be appreciated! Thanks!

[SteveVinyard]

This is typically a lot more work than its worth. Yeah you will have an In Work REV in the system BUT there are about 50 use cases that could cause this too. If you end up chasing and trying to delete those constantly in any system, you'll experience significant diminishing returns in my experience.

At some point a person will want that new REV and simply edit the existing In Work version. If you are worried about users seeing an In Work rev, access controls should be setup for particular roles to prevent this.."Read Only at Released" kind of stuff.

[DarrenStorey]

Sarah

Creating a new revision that is no longer required (or created by mistake) is a real pain. As soon as that new version becomes a dependent of an assembly, or a member of a baseline etc. etc. etc. then deletion becomes completely impractical.

Revise is often a one way street, regardless of whether a corresponding change notice has been created or approved.

I’m interested to hear what others do when a change is started, but then for whatever reason deliberately not completed. Do you update the document revision anyway without an actual change in order to preserve the integrity of the latest configuration?

Regards

Darren

[jrutgeerts]

This is an old thread.

Anybody knows the answer in the meantime?

If there effectively is an option that "in work" objects are automatically deleted upon removal from the resulting objects, this would be a solution to decouple the decision "should it be a new revision of an existing part, or should it be a 'save as' to a new part" from the design phase.

Experience learns that:

1) it is a difficult task for design engineers to start a design change by thinking "revise or save as?" rather than just starting to change CAD objects,

2) In some cases the design starts out with "it is a backwards compatible change" but in the end it turns out not to be backwards compatible after all, due to design constraints or specs that are not clear at the start of the change.

So imo. there is a clear need to make the "new revision or new article" decision at a later time than the start of the design phase. I'm interested in the most straightforward way to do this in Windchill.

Regards,

Johan

[JHall]

@jrutgeerts 

In my opinion, it might be a better way to not think about deleting un-needed Revised objects, but try to find ways to NOT create them in the first  place.  Maybe you could look at your procedures and see how you might be able to hold off on that Revise step.

We set up our ECNs to have Engr Manager approval PRIOR to getting the work started on the ECN itself.  This has prevented quite a few unnecessary Revisions.  They aren't fully gone, but reduced a great deal.

James.