Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
RiccardoEscher
Active Participant

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":

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:

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:

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:

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:

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:

Further Customizing

BAdIs

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):

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.

5 Comments