About Dependency Stacking

You can use one effectivity definition for a range of units in a BOM and then use additional definitions to modify specific units within that range. This is called "dependency stacking" since you use multiple effectivity definitions may be dependent on the ranges and lifecycle states of each other.

The sections describe how you can use dependency stacking. For more information on dependency stacking and other types of dependency, see Change Management User's Guide: About Change Dependencies.

This page discusses:

Cutting Instances

When you assign effectivity to a change action, you define a range of instances for which the change is to be applied. Using dependency stacking, you can use one or more additional effectivities to cut out specific ranges of instances that you don't want to include.

For example, consider the BOM below, which includes the part CH-100. Change action CA1 has a proposed effectivity for instance range 1-10.

Parent Part Child Part Change Action Proposed Effectivity Current Effectivity
P-100
CH-100 CA1 Mod[1-10]

Suppose that you want to cut certain instances, such as 6-10, from the original range. You would create another change action, CA2, with an applicability of Mod[6-10]. The net proposed effectivity would be:

Parent Part Child Part Change Action Proposed Effectivity Current Effectivity
P-100
CH-100 CA1 <- CA2 Mod[1-5]

You could use more change actions as required to cut other ranges from the original range.

Note: The change actions must be released in order. Release the initial CA (CA1 in this example) before you release the CA that you use for the cut.

Replacing Instances

Replacing instances using dependency stacking is similar to cutting instances.

For example, consider the BOM below:

Parent Part Child Part Change Action Proposed Effectivity Current Effectivity
P-100
CH-100 CA1 Mod[1-10]

Using another CA, call it CA2, you can replace instance 6-10 of CH-100 with another, such as Child200:

Parent Part Child Part Change Action Proposed Effectivity Current Effectivity
P-100
CH-100 CA1 <- CA2 Mod[1-5] Mod[1-10]
CH-200 CA2 Mod[6-10]

To release the changes, you must release CA1 before releasing CA2.

Note: Before releasing either CA, you must establish CA2 as a dependency. To assign a change object as a dependency to another change object, see Change Management User's Guide: About Change Dependencies.

You can replace other parts using additional CAs:

Parent Part Child Part Change Action Proposed Effectivity Current Effectivity
P-100

CH-100

CA1 <- CA2

CA1 <- CA3

Mod[1-3]

Mod[1-10]

CH-200 CA2 Mod[6-10]
CH-300 CA3 Mod[4-5]

As with CA2, you must establish CA3 as a dependency to CA1 before releasing either any of the CAs. To release the changes, you must release CA1, CA2, and CA3 in order.

Constraining Instances

In some cases, the effectivity range of the dependent CA may not fall entirely within the range of the independent CA.

Consider the BOM used above:

Parent Part Child Part Change Action Proposed Effectivity Current Effectivity
P-100
CH-100 CA1 Mod[1-10]

If you add a dependency, such as CA2, with a range such as Mod[8-15], the net effectivity of CA2 is limited to the range of CA1. Such as:

Parent Part Child Part Change Action Proposed Effectivity Current Effectivity
P-100
CH-100 CA1 <- CA2 Mod[1-7] Mod[1-10]
CH-200 CA2 Mod[8-10]