Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
Showing results for 
Search instead for 
Did you mean: 
Active Contributor
ComponentSupport Package


In my previous blog Add/manage complex help searches on Conditions views in Web UI I explained how you can use complex search helps in the Web UI conditions maintenance, now is the turn to enable/disabel fields. As you already realized, the condition doesn't relay on the Web UI configurations, depends customizing and coding. So if a customer ask to disable fields on some critera what should we do?

Scenario 1 view CRMCMP_CND/CondRecEditConfView

There's no major problem here,  as you alread know, Just put the logic on each GET_I* method, as easy as this.

Scenario 2 view CRMCMP_CND/CondRecEditListView

Here is where the party starts, the properties of the table view can not relay on the GETTERS/SETTERS because each condition fields can have different( mandatory enabled/disabled fields, etc.) as they relay to customizing and how you have defined the condition tables.

I know the language doesn't help, but for what I whant to show, doesn't need to be in english :wink:

As you see in the first screenshot, the conditions is "Dto. Producto Establ/ID Pr.." this conditions refers to a condition table which has a specific key and specific fields, In the second screenshot I add a row which points to a different condition, "Dto Val. Cant. Distr/Produ...", as you are realizing some columns are grayed out and some other not, this is due the condition table related to the second condition has his specific fields and his specific key, which doesn't have to be the same as the previous condition and viceversa, this is the main reason the GET_I* will not be used, GET_I is columm dependent, not column/row dependent, now you will say: "ok, ok, I get it, now give me the solution" unfortunately the standard is "not prepared" for that I said "prepared" because in some way it is, but won't cover our scenario without an "extra efffort". :twisted:

You have the BADI /SAPCND/MNT_USAGE which you can control this behaviour with the method SET_EDIT_STATES_ITEM,good news until you read the BADI interface documentation(/SAPCND/IF_EX_MNT_USAGE) :sad:

This feature is available for the following methods: HIDE_ATTRIBUTES_ITEM,  PUT_BEFORE_IMAGE_TO_DBA, SCALE_DEFAULT_CHECK, SCALE_F4_HELP, SCALE_ADD_DIMENSION, SCALE_SET_SCALE_BASE_TYPE, SCALE_SET_SCALE_UNIT. For all other methods, overriding is not possible. The following holds true for the methods that can be overridden:

It's a bit weird because the BADI is not meant for multiple usage, but you can implement your version as long as you use the methods which SAP specifies in the resume, this won't work for us because we need the method SET_EDIT_STATES_ITEM.

The class CL_IM_FGD_USAGE_CND_CRM is the one who manages the SET_EDIT_STATES_ITEM method, so if you need to enable/disable fields on some criteria you will need to create a enhancement spot at the end of the method to edit the changing parameter CT_ITEM_LINE_FCAT.

The good news is this changes will apply as well to the view CRMCMP_CND/CondRecEditConfView!

As is an implicit enhancement spot, you should do it with care and of course with your own resposability!!

I hope you find this usefull.



Labels in this area