As a functional consultant, you probably write functional specifications now and then. Even though the SAP CRM solution offers many ways to customize processes, some enhancements are needed to fulfill the few business requirements that cannot be met by standard functionality. With help of business add-ins or the possibilty to link your own function modules in customizing, SAP CRM can of course also cater for that. But SAP CRM cannot ensure that these enhancements are built in a future-proof way.
Only too often I encounter developments that contain hardcoded values or that apply to the system as a whole. Before we go over the most important options to overcome this in more detail, let's first quickly look at the disadvantages a customer might encounter if enhancements are built in a rigid or hardcoded way. Examples of disadvantages are:
- A change in customizing requires a change in coding
- If new business units want to use the system, but do not want your specific enhancement, a change in that coding is needed
- Once-built logic tends to be forgotten, leading to additional costs when extending or upgrading the system later
So, how can we ensure that enhancements are controllable functionally? With this blog I aim to shed some light on the little-known yet highly powerful parameter options that are standard available in SAP CRM.
Introduction
Parameters can be used to steer logic: programmers can check the value of a parameter before apart of the logic is processed. A parameter can be a simple on/off switch or it can contain a value that would be hard-coded otherwise.
Available parameter types
User parameters
Purpose
If you want certain logic to be only available to certain users, this is the way to go. You can setup additional parameters to your own liking
(Dis)Advantages
Possible to switch on/off or adapt the logic on the lowest possible level: the user. More work to setup and maintain though.
Setup
You can create your own user parameters via SM30 in table TPARA. From then, you can set the value for a user through SU3 (your own user) or SU01 (any user).
What to put in the specification?
From the coding, the parameters and values of a user can be retrieved. Values are stored in table USR05.
Organizational attributes
Purpose
You want certain logic, that might be executed in the background, only to apply to (e.g.) certain sales organizations.
(Dis)Advantages
Can be setup on high level and then inherited to the lowest, where it can be overwritten if wanted. Downside is that the organizational model should be maintained for this.
Setup
You setup your own attributes in table T77OMATTR through SM30. First enter your new attribute (see screenshot). If you enter a description and hit enter, the table and field names are defaulted (SAP delivers a standard table in which all these attributes are saved).
You then link the attribute to the scenario (Sales, Service, or Marketing) and to the object type (for instance O for Organizational Units). You can even setup inheritance from higher- to lower-level objects. This way can you also setup attributes for positions and have those defaulted from the sales organization to which they belong, and overwrite the value if needed. The new attribute is then available in the list of attributes.
What to put in the specification?
You can add the hint to use function module RH_OM_ATTRIBUTES_READ to retrieve all attributes, including your own (if maintained, of course).
WebUI parameters
Purpose
Your end users work through the webUI and you would like specific logic to apply only to certain business roles.
(Dis)Advantages
You can assign parameter values to (big) groups of users rightaway. Needs to be customized and transported though, and only suitable for processes running or initiated in the webUI.
Setup
Parameters can be created through customizing (IMG > CRM > UI Framework > Technical Role Definition > Define Parameter). You assign the parameters and their values to a parameter profile. This profile can then be linked to one or more business roles as a function profile (ID = PARAMETERS, vallue = the parameter profile).
What to put in the specification?
There are standard possibilities to retrieve the business role that the user is logged on for.
Other parameters
Besides the parameter types discussed above, you can also think of other parameters in the system. Example include marketing attributes (freely definable fields in the account), and container parameters in action definitions (more information about actions can be found in my blogs). These will not be described in this blog.
Own table(s)
Purpose
If you have more complex requirements, it can be an option to define your own 'customizing' table. Many customers have one in which they can dynamically add parameters to their coding.
(Dis)Advantages
Much more 'steering' possibilities, but has the risk of being hard to understand.
Setup
Often, these tables are really 'for insiders only', and you know what tends to happen with insiders: they leave the company, forget they ever built it, whatever... The best structure I've seen was a combination of two tables: one in which the link between the object (FM/report/class, for instance) and the parameter was given, and another table with the actual parameters and their values. All programmers were required to use the first table to retrieve the parameter, and this ensured the tables were filled correctly. This enables every new kid to quickly see where what parameters are used.
Which to pick, and how to use them?
Which option you decide to use for the enhancement that you want to have built depends on how you want to limit the logic now, or in the future. The more the SAP CRM solution is used, the more these parameter options will be used. As a company, you should consider setting up guidelines for projects and changes to only build enhancmenets using the parameter options you have chosen based on your company's roadmap (think of: future roll-outs or additional functionalities). By using these parameters in a wise and consequent way, companies can benefit from the enhancement possibilities SAP CRM offers without having the risk that they cannot be managed anymore.
- SAP Managed Tags:
4 Comments
| User | Count |
|---|---|
| 3 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
