Skip to main content
B
BrianToussaint19-Tanzanite
19-Tanzanite
October 1, 2014
Question

Revise Action in Change Notice Only

  • October 1, 2014
  • 1 reply
  • 2724 views

Is there a way to remove the Revise selection from the Action menu and force them to Revise through a Change Notice? We are currently on 10.1.

Thank you,

Brian

1 reply

D
DarrenStorey12-Amethyst
12-Amethyst
October 2, 2014

Brian we would also like to do this. Maybe even perform the revise action programmatically on the affected items in each change task, via an expression in the change notice workflow. That way the new revisions are created at the last possible moment. To stop the revision being created only for the change notice to be rejected.

Removing the revise action from the UI is a customization. Revise from change and revise are different actions.

Watch out though, you cannot remove the revise from within CAD so easily, if at all. If anybody knows otherwise please share.

I thought to simply remove the revise transition on the lifecycle, and then rely on the programmatic revise in workflow. Not sure if this is possible if there is no revise tranistion defined in the lifecycle.

Darren

M
22-Sapphire I
MikeLockwood22-Sapphire I
22-Sapphire I
October 2, 2014

The team at Alcon struggled with this for a good long time in the past as a fundamental requirement for the system. Seems that it's helpful to consider this from a lttile bit broader perscpective.

The posted question is how to manage Revise permissions / actions such that people have this available only on an approved change. Added to that is an additional desire to Revise programmatically.

Bottom line - After being immersed in this for 15 years, I strongly recommend using a two-phase lifecycle / Revision scheme (e.g. Numbers, then letters or the reverse). This has to be set up with "state based versioning" such that the following are accomodated:

- During development, Revise is freely allowed and there is little downside. Give the permission to all Engineers. The permission is Revise from a specific state used only for Development.

- For every object, there is a one-time step such that the next Revision jumps to the next "seed" (e.g. from Rev 3 to Rev A); further Revisions are B, C... The permission is given to a much smaller group, Revise from the state used to get to production.

- Once "Production Released" a different set of states (within the same Lifecycle) is used. Revised is from Production and this permission is given to only those Engineers authorized to make production changes.

Separately, the collector preferences used for Revise (and for populating Change Objects) have to be fine tuned. Recommendation is to err on the side of less automatic collection and put the responsibility for correct collection on the CAD user assigned to make the change. Note: Have to be very careful about programmatic Revision where new objects are created as part of the change and other objects are obsoleted and/or allowed substitutes are involved.

////

So - If you are already in production, this is of no use, right? Lots of these in using Windchill - by the time you decide how you want to configure it you can't make those changes. In this case, you probably can in fact add addtional states to your existing lifecycle, along with additional Revisions for development. All this is far easier with a few good diagrams - I'm thinking of writing this up carefully and publishing to the world. May in fact make this one of my consulting specialties going forward.

D
DarrenStorey12-Amethyst
12-Amethyst
October 2, 2014

Mike

Hope life is treating you well as a consultant?

I completely agree with a 2 phase lifecycle. The ability to enter revision control before engineering change control is a use case shared by us. Whether you need state based versioning is another discussion.

Restricting who can revise in phase 2 compared to phase 1 is certainly easier to implement than programmatic revise.

I may have completely overlooked something here, but I do not currently understand the use case whereby the list of affected objects could be different to the list of resulting objects. When is it not OK to revise all affected?

My understanding is that new objects may be “required” because of a change but “new” objects are not affected or resulting from change. Similarly obsoleted parts are not changed, you just decided not to use them anymore and removed them from your product configuration, by changing where used.

Do you perhaps have some downstream activity that only responds to a new revision rather than a change of state?

Darren

Terms & ConditionsAccessibility statement