Skip to Content
Component Support Package



Scenario 1: Add an already existing Standard field: Currency

Scenario 2: Adding BP which points to a partner function

Scenario 3: Use a customer field (enhanced via AET)



Well I hope everybody knows about what is about the GUI transaction MASS, for the ones who doesn’t know, is a transaction to do mass modification, in CRM we can use it to modify sales orders (header and Item).

Wait! Have you said GUI transaction? GUI is not supported anymore in CRM 😉

MASS in GUI dumps when you try to modify massively sales order items, the dump is caused by a standard error, in a normal situation this will be fixed by SAP, but is not supported so you should go through Web UI yes or yes.

soooooo…Where is the MASS alternative in the Web UI? Well… is not very intuitive, you can find it under any Business role which has the following logical Links related:







Business roles:














I’m not going to explain how it works from a “user point of view”, it’s very intuitive, I will focus how you can add new fields.

To manage the fields which will be updated you should go to the following customizing path( I recommend read the help, it’s very complete):


In the sales order scenario you will have to select the structures CRMT_UIU_SLSORD_MASSUPDATE_HDR for the header and CRMT_UIU_SLSORD_MASSUPDATE_ITM for the items, my scenarios are header related so if you check in the dictionary the structure CRMT_UIU_SLSORD_MASSUPDATE_HDR you will see this structre has one customer include CRMT_SALESORD_MASSUPDATE_HEAD2 which also has another CI CRMT_SALESORD_MASSCHNG_HEAD2 I will give you the reason why I’m explaining this in the first scenario, don’t be impatience! 😀

Scenario 1: Add an already existing Standard field: Currency

The component/view for the Header mass process is the BT115MU_SLSO/ChangeHeaderForm which has the context node NEWVALUES, the context node is bind to the CUCO HeaderMassChangeCuCo context node: NewValues in the method IF_BSP_MODEL~INIT of the cuco context node you have defined which fields will be available in the Web UI configuration.


Do you remember the structure CRMT_SALESORD_MASSCHNG_HEAD2? yes, of course! is included in the structure CRMT_SALESORD_MASSUPDATE_HEAD2, so you can not make available in the Web UI any of the fields of the structure CRMT_SALESORD_MASSUPDATE_HEAD2 because the field will be duplicated so you won’t be able to activate the CI, this is the case of the currency, the solution is add the same filed with the ZZ / YY prefix.




Once the field is in the CI and everything is active we need to enhance the CN NEWVALUES of the view ChangeHeaderForm in order to add the field as attribute:


So now is available in the Web Client, notice that you will need to code the search help in case that you need it (usually yes) via GET_V method.

The final step is make the new field available in the mass changes customizing, we create the following entry:


And that’s it!

I was a little upset because I don’t like to duplicate things, so I raised a message to SAP in order to clarify this, they answered “for technical reasons this is the right procedure” so if you want to make available in the Web UI any of the fields which are directly added in the CI CRMT_SALESORD_MASSUPDATE_HEAD2 you must duplicate the field with ZZ / YY prefix in the  CRMT_SALESORD_MASSCHNG_HEAD2 and also duplicate the customizing entry for your field. Nice, isn’t it? 😈

Scenario 2: Adding BP which points to a partner function

This is a very easy scenario, first you enahance the CRMT_SALESORD_MASSCHNG_HEAD2


Then add the field in the customizing:



In this case the Object Key is the partner function id defined in the partner determination procedure config.

The rest UI related steps are like in scenario 1.

Scenario 3: Use a customer field (enhanced via AET)

This not complicated but little tricky, I hope SAP will do something about it in the future.

AET  enahces the context node of the views, but doesn’t enhance the model structures( the ones you use for the customizing, CRMT_UIU_SLSORD_MASSUPDATE_HDR, for example) so you should enhance manually those using in both the same name, otherwise, the value node in the cuco will have the attribute with one name (the one which you used to enahnce the model/customizing structures) and the context node of the view will have another one (the one which you used to enhance the dicctionary via AET) so when the system tries to perfrom the getter/setter for the extension generated by the AET will dump because they not share the same name, wierd, uh? There’s a workaround: define a custom getter and setter to the AET extension in the view and make them point to the right attribute of the cuco, but if you follow my steps, there’s no need for this extra development 😉

I hope you find this useful.



To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply