Lock the BoM on Released Revisions

[Anonymous]

For the latest released revision of a BoM, there should be no updates to its child components.  The updates should apply to the working version in preparation for a future uprev of the BoM.

Currently, a released revision consumes every new revision of it's children unless revision-pinned:

If we use revision-pinning to prevent the above, we are required to directly edit the BoM which is supposed to be a locked record.  This is not desired by approvers/administrators of the system.

Vault is able to display the BoM in 2 views for a released revision (the below images make use of the 'Uses' tab to represent the BoM, but the results are the same when using the Item Master):

Available views:

Latest view - shows the latest revisions of all children (200-351 at rev C):

Rev B view - shows the view as it was released (200-351 at rev B):

And if we continue updating the assembly it ignores rev C of that part because it was never consumed by the assembly which indicates that the 'Latest' view is never an accurate view of the release:

For FLC I am suggesting the entire BoM is effectively revision-pinned for every released revision, and instead allow the working version to consume any changes as they occur (even though this does not agree with the last image from the Vault example above).

I appreciate there are semi-workarounds for this:  we can manipulate views of the BoM by date of release.  The problems with this are that it requires extra picks and clicks without which the BoM can be misinterpreted.  We also lose traceability if there are 2 or more child revs in the same day.

We can use effectivity on change orders to stagger the consumption, but eventually the BoM will consume this rev if not updated before the effectivity date which leaves us in the same position.

Ultimately I would like to see a closer match with the way Vault presents data, or at least the option to switch this on at the system settings level.  However, I also welcome other perspectives on this issue that will help myself and customers adopt the current logic.

[Anonymous]

In any production environment it is crucial that assembly releases reflect a true vision of sub-component at their current release, so I totally agree with Scott regarding FLM.

… also, Vault scores with it's ECO records as the change state can be shown in both Client and Thin Client to indicate that the file / Item release is currently under change.

It would be nice if Vault had the flexibility of FLM … but that's another story! 😉