In this age, having a model without nested KMATs (multi-level configuration) is a thing of the past. Because of that, I wanted to do a quick post about transferring values between the different levels of the bill of material structure. There are 2 methods to accomplish this (at least using the standard ERP functionality).
1. Procedure: $SELF.X = $PARENT.X or $SELF.X = $ROOT.X
2. Constraint:
Object:
mod1 is_a(300) mod,
mod2 is_a(300) mod,
Assy is_a(300) mod_component
Condition:
part_of (Assy, mod1, ‘0100’) or
part_of (Assy, mod2, ‘0100’)
Restricitons:
Assy.X = mod1.X,
Assy.X = mod2.X
Inferences:
mod1.X,
mod2.X
This rule is a very generic way to show you how to pass values down to a lower level cstic. This variation goes one step further and actually checks to make sure that the nested KMAT is a at certain position in the bill of material. This is not required, but can be very handy if is the same class exists in multiple positions in the BOM. Notice, we copied down, but you could just as easily copy back up by reversing the restriction. While not a common practice, the option is still there.
You’ll notice that the first method is far more simple, and will do the trick. the constraint is more complicated to write, but has more power. Personally, I’m a constraint kinda guy, so I tend to use that method. But you need to use what fits your situation best.
Now, whenever you need to transfer characteristics between levels, you NEED to test early on in the process how it behaves in a sales order, planned order, production order and sales order costing. Many times the behavior that works great in CU50, doesn’t translate the same way in a production order. You may have assign the constraint/procedure at a different configurable material in order to get the rules to fire in all scenarios.
Happy configuring.
Remember, if there is anything we can do to help, please click the contact us button at the top of this page.
Mike