cancel
Showing results for 
Search instead for 
Did you mean: 

Overriding a $root value via object dependency

jez_lawson
Participant
0 Kudos

Hello Experts,

I have a situation where I require to change a characteristic at the $root level via an object dependency.  I use partially configured materials based off a configurable material.  The configuration profile is set for the configurable material, and based off Z tables changes specific characteristics in the partially configured material.

I want to default a characteristic in the configurable material by setting the characteristic at a plant level in the MRP3 configuration.  However for specific customers I wish to override this in the configuration profile.

I can change the $self value of the characteristic within my object dependency, but the $root value is being taken from MRP3 and I do not appear to be able to change this within the dependency.  Am I missing something?  It there is no value in the MRP3 config characteristic, the $self value I set in the dependency is passed back to the root.

I believe the hierarchy in characteristics is user entered > Material Master > object dependency but I was hoping I could break this hierarchy somehow.

Regards,

Jez

Accepted Solutions (0)

Answers (3)

Answers (3)

jez_lawson
Participant
0 Kudos

Hi Ritesh,

So as an example I have a configurable material A, and based off this material A I have 3 partially configured material B, C and D.

Each of the materials has a characteristic BACKING which has 10 options (1 to 10).  For the most part material B will always use BACKING 3 at plant X and BACKING 5 at plant Y.  However we have a customer specific BACKING 10.  Materials C and D have their own unique defaults.

The intention is that when a sales order for B is entered the BACKING automatically defaults to 3 at plant X, 5 at plant Y and 10 if the order is for the specific customer.

In my current setup an object dependency sets the BACKING type to 10 if the order is for the specific customer.  The customer default cross reference is held in a Z table and a function has been written to retrieve the value.  At the moment though a standard default in MRP3 for BACKING is not set.

The hope was to put the plant default in the MRP3 configuration, but this breaks the customer override.

I put a trace on the object dependency via CU50 and I can see that when I set $self.BACKING to my value, this is passed back to the $root.BACKING  but only if the $root.BACKING is blank.  By putting a value in the MRP configuration the $root.BACKING already has a value assigned hence the altering of the $self value does nothing to the value held in the sales order.

Having slept on it, I am considering introducing another characteristic DEFAULT_BACKING, and in the object dependency passing this into the $self.BACKING only if no customer default has been returned, and passing the $self value to $root each and every time.  This is a messy solution really, but I am now doubting whether I can actually change a value stored directly on the material (at MRP3) via an object dependency, and even if I could would it then overwrite any user update to the field at sales order time when configuration profile logic is triggered.

Regards,

Jez

Ritz
Active Contributor
0 Kudos

Jez Lawson,

Can you add and example to your issue, so it will be easy to understand and reply.

My initial understanding is your configurable material have deafults values maintained at MRP3 level with partial configuration, and in MRP3 you have  assign an value to characterstic which you expact your customer will change while creating sales order?

The part i didnt understand is , what you are referimg as root? does you have 2 levels and you are expecting a value assignment at second level and transfer it to top which you are refering as root?

Also , whats the role of Z table in this value assignment.

Please reply adding some more details and hope you will get favourable replies from forum.

Thanks

Ritesh

Caetano
Product and Topic Expert
Product and Topic Expert
0 Kudos

Thread moved to the space SAP ERP PLM - Classification and Variant Configuration.