Skip to Content

When your users see for the the first time the transaction CRMD_ORDER which is used for Change Request Management they will be a little bit shocked.

Obviously you have created a document which explains which fields should be used and which fields should be ignored, but why should a developer read a documentation if he/she knows the phone number of the guy who is responsible for this?

So just as a survival action we should elminate all fields we don’t need.

Create a Transaction Variant

To slim down CRMD_ORDER first we call transaction SHD0 (zero, not o) and create a suitable transaction variant for our ZROL users (see Part 1 of this blog) and press “Create”:
SHD0 first screen - new

On the next screen we get the well known CRMD_ORDER; here we make only one entry, we insert “1” as IBase, because we will advance it to a constant.

When we press [ENTER] we will get the first of a series of Pop-Up dialogs “Confirm screen entries” for every sub-screen of CRMD_ORDER. These pop-up dialogs save the single screen variants; we are invited to insert a short text for the variant and get the chance to edit also the menu functions:
Creating screen variants

For example we don’t want our users to delete a change transaction, so obviously we don’t give them the authorization to do it, but to avoid e-mail traffic in the style “I wand to delete ChaRM 5000013500 but am not allowed to; can you please do it for me?” we will disable these menu functions and also the corresponding function keys.

To disable unneeded functions at Screen value SAPLCRM_10_MANAG_UI 0100 (the first screen we get) we press the button “Menu functions” and deactivate the functions we don’t need (Yes, I am very optimistic. A really tough user would write asking why the menu function “Delete” is inactive, instead of reading our documentation …).

One example:
SHD0 deactivate menu functions

By the way: If you have a SDHF clone which is created by a SDCR by approval it is also relaxable if you deactivate CCPY (Copy) and FLWU (Follow-Up Transaction)!

Now we press [ENTER] (“Continue”) and so on, screen by screen, giving short texts to the screen variants

Here we hide the category and make the external reference obligatory:
SHD0 screen service_ui 7153

This is only an example. Making fields obligatory in CRMD_ORDER is a little bit bulky; if you have time for coding it would be better to implement for example a status dependend check (IMG SolMan -> Scenario-Specific Settings -> Change Request Management -> Extended Configuration -> Change Transaction -> Change Transaction Types -> Consistency Checks  in Change Request Management).

The most interesting screen of all is SAPLCRM_SERVICE_ROB_UI 7110! Here we make the IBase 1 a constant, make also the IBase component obligatory and hide other fields which make no sense in our transaction type:
SHD0 IBase, Subject, Product ID

After this screen we press “Exit and Save” because we have served our purpose.

We get an overview of our change transaction variant, and when we save we are asked to create the object directory entries to make all transportable.

I am wondering if it improves performance deleting in the “Transaction Variant” tab all assigned screen variants which were only inserted by the automatic recording but which did’t carry any really variant… May be in a rainy day in the future…

Bind the Transaction Variant

We won only half  the battle as we have now to dig deeeeeep into the CRM customizing to make this transaction variant work. We call SPRO and open CRM -> Transactions -> Basic Settings -> Assign Transaction Types to Transactiono Variants (IMG activity CRM_BTX_TRANSVARIANT).

Here we insert our newly created transaction variant:
assign transaction variant to transaction type

Further Customizing


If you want to make the correlation transaction type <-> variant more dynamical you might have a look at the BAdI CRM_10_TCVARIANT (IMG -> CRM -> Transactions -> Basic Settings ->Business Add-Ins -> BAdI: External Transaction Variant Matching).

You can also make fields read only by implementing the BAdI CRM_ORDER_FIELDCHECK (depending on the user status).

Customer Categories

In our example we hid the field for the category. But we could also have created our own categories, for example we have created for another transaction type which we created to synchronize a parallel track the category “Skip Tests” (a very popular category indeed!).

In this case we left the field visible and created our own category (IMG Solution Manager -> Scenario-Specific Settings -> Service Desk -> Service Desk -> Maintain Categories and Priorities -> Maintain Categories, ID CRM_AKT_001):
Category creation

Also here, this is only half the battle. Deep in the CRM customizing we find the chance, to bing this category to our transaction type hiding all the other ones!

Calling IMG CRM -> Transactions -> Settings for Activities -> Maintain Categories, Goals, and Priorities -> Assign Categories to Transaction Types (ID CRMV_ACT_CAT_***) we can filter our own categories.

To report this post you need to login first.


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

    1. Riccardo Escher Post author
      Thank’s for the flowers.

      Bytheway, there is a little bug in the old CRM_DNO_MONITOR.

      When you select in the monitor list one ChaRM entry the transaction variant which will be used by this ChaRM will be kept for all other entries, independently of their customizing, creating so strong irritation to the user.

      To avoid the bug you should do this implicit enhancement to the beginning of the form routine “DETAIL”:

      FORM detail USING ls_selfield TYPE slis_selfield.
      “””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””$”$\SE:(1) Form DETAIL, Anfang                                                                                                                               A
      *$*$-Start: (1)———————————————————————————$*$*
      ENHANCEMENT 1  ZSV2I_EICM44.    “active version
      * 09.06.2010 Escher Osram GmbH
      * As the transaction type can change, reset the transaction variant, because
      * only the first transaction variant will be taken for all transactions
            VARIANT                       = space
            FLAG_CLIENT_INDEPENDENT       = ‘X’
            OVERWRITE_VARIANT             = ‘X’
      *     BATCH_INPUT                   =

      *$*$-End:   (1)———————————————————————————$*$*

      Another happy user again 🙂

  1. Marco Haseney
    Hello Riccardo,
    very good documentation.
    Following your steps I am able to  set the menu function like follow-up inactive, but the buttons in the menu toolbar  to execute the same function are still available and active?
    I assumed, that setting the function to inactive would impact menu entry AND button, but it did not act in the expected way.
    How can also the buttons set to inactive?
    Thank you for your reply.
    Best regards

Leave a Reply