Skip to main content
M
MikeLockwood22-Sapphire I
22-Sapphire I
March 21, 2012
Question

Released >> Superseded??

  • March 21, 2012
  • 6 replies
  • 3416 views

I've been in 1,001 discussions about whether or not to leave for example Rev C at Released when changing from Rev C to Rev D, or move Rev C to "Superseded" or some variation. Always lots of emotion. Most don't make the change.


We don't do this but are now considering again.


Please comment if you leave old Reviisions at Released or change their state when a new Rev comes along.

    6 replies

    D
    ddemay1-Visitor
    1-Visitor
    March 22, 2012

    Leftover from pre-PLM era.

    Think it screws up effectivity.

    Something effective for one lot still possibly built/tooled or warranty/aftermarket purposes is released. Next model comes along doesn't entirely provide identical fit form or function.

    It is superceding technically on redesign. Same part number though?

    I think old processes don't die until all employees, technology or data allow it to die.



    Sent from my Verizon Wireless BlackBerry
      P
      pwilliams-313-Aquamarine
      13-Aquamarine
      March 22, 2012
      Mike,
      When revision B set to RELEASED we promote the previously RELEASED revision A to RELEASED_HISTORY. The advantage to this approach is that when a user has revision A in their workspace and they are notified that their object is out of date, they will see that their revision A is now at RELEASED_HISTORY. This tells them "why" their object is out of date. In this case it's because revision B was set to RELEASED and they should update to the new revision A. If their object at revision A remains at RELEASED and they get the out of date notification, they know that there is a later revision B but it hasn't been released yet.

      If we did not promote previous revisions to RELEASED_HISTORY then the user would have to take the time to investigate the newer object to determine if they should update their object to the latest.

      Patrick Williams | Engineering Systems | o: 616.698.3766 | c: 616.947.2110
      [cid:image003.jpg@01CD0800.C78B4DB0]
      P
      pwilliams-313-Aquamarine
      13-Aquamarine
      March 22, 2012
      Typo...
      In this case it's because revision B was set to RELEASED and they should update to the new revision A.

      Should be:

      In this case it's because revision B was set to RELEASED and they should update to the new revision B.

      Patrick Williams | Engineering Systems | o: 616.698.3766 | c: 616.947.2110
      [cid:image001.jpg@01CD0801.36DB8CC0]
      L
      lgrant16-Pearl
      16-Pearl
      July 15, 2016

      Patrick,

      How do you set the Affected data to Released-History?

      I assume you use "change" in the lifecycle to set the Resulting Items to Released on the higher version?

      L
      LewisLawrence13-Aquamarine
      13-Aquamarine
      March 22, 2012

      Mike,


      When we create a new version/revision we automatically set the previous version to another state. We are always build to latest rev, and our business rules state that if B is not interchangeable with A, then it should be a new part number, which in turn means a revision of any assembly using the component. Clearly there are special cases where this does not need to apply, like in the case where something has only just been designed and there is no inventory anywhere.


      Procedurally we state that Customers of Engineering data must access content from Windchill, and they cannot access documentation that is not released. So the state change on old versions is done to ensure that things only get built to the latest version and that new inventory doesn’t get built while undergoing revision. So while something is “out” for revision they have to ask Engineering for documentation they don’t currently have permission to.


      If it was possible to build access control rules explicitly around “Latest version” (and also “Latest Iteration” for that matter) the state change would not be necessary for us. That is functionality we would really like.


      -----

      Lewis

      In Reply to Mike Lockwood:



      I've been in 1,001 discussions about whether or not to leave for example Rev C at Released when changing from Rev C to Rev D, or move Rev C to "Superseded" or some variation. Always lots of emotion. Most don't make the change.


      We don't do this but are now considering again.


      Please comment if you leave old Reviisions at Released or change their state when a new Rev comes along.






      J
      JoePriest10-Marble
      10-Marble
      March 23, 2012

      We only have one released object at any given time. Only one thing can be released. If something is newer that is released, the older thing that was released is now "superseded". It means a couple of things here. First, it's still manufacturable meaning that if there's WIP on the floor, you can still continue making it to the earlier rev. The second thing is that does is what I've already stated: If you see something superseded, there's a newer one that's released. In Med Device terms, that's preventing unintended use.


      We use Division Productview with Pro/INTRALINK and we had a lot of problems with people accidentally pulling out earlier revs that were still showing released when they meant to pull the latest. By definition, only one can be released.

      In Reply to Mike Lockwood:



      I've been in 1,001 discussions about whether or not to leave for example Rev C at Released when changing from Rev C to Rev D, or move Rev C to "Superseded" or some variation. Always lots of emotion. Most don't make the change.


      We don't do this but are now considering again.


      Please comment if you leave old Reviisions at Released or change their state when a new Rev comes along.


      Terms & ConditionsAccessibility statement