Using parameter transactions

Preventing input errors and speeding up processes – to ensure this, parameter transactions are often a good choice. Today, we will explain to you what you need to consider as an authorization professional and how you can restrict parameter transactions.

A parameter transaction in SAP executes a function or a report with specific parameters that have been defined beforehand. Parameter transactions are mainly used where processes are to be accelerated and simplified. They reduce unnecessary user input and improve replicability. However, they can also pose a high security risk and must therefore be properly restricted on the authorization side.

Good to know: A parameter is a variable input required by a function or report. A parameter can have different data types, such as text, numbers, or date and time.

The user calls the parameter transaction with the corresponding transaction code. When the transaction is called, the default parameter values for the transaction are automatically loaded. The user has the option to change the preset parameter values before the transaction is executed.

Good to know: There are static and dynamic parameter values. Static values are pre-filled and cannot be changed by the user. Dynamic values can be pre-filled, but the user can change them before the transaction is executed. This is a potential security risk that requires further authorization adjustments.

For example, imagine your users want to run a report that shows all material movements in a particular plant and storage location on a particular date. Without a parameter transaction, you would have to manually enter the values for plant, storage location, and date each time you want to run the report. This can be very time consuming and error prone, especially if you need to run the report frequently. One solution is to create a parameter transaction that defines all the required parameter values in advance. When you run the parameter transaction, the preset parameters are automatically loaded, and you can adjust the parameter values as needed.

But be careful: as a rule, users should only see material movements that are within their area of responsibility. To prevent overauthorization by the parameter transaction, you must restrict the relevant authorization objects that control access to plants, for example.

When are parameter transactions a security risk?

Parameter transactions are also used to configure functions or processes within the system. This includes transactions such as SE16 or SM30, which – if not properly restricted – bring with them far-reaching authorizations to view, modify and delete tables. This is not only critical in terms of data breaches, but also risky for the security and stability of the system itself.

Therefore, transactions such as these should:

• be granted only to a small group of users (especially in production environments), such as administrators and developers.
• Be restricted via relevant authorization objects (for the SE16/SM30: S_TABU_DIS or S_TABU_NAM) if the assignment of the transaction is unavoidable.
• Be replaced by Z-transactions that only allow access to relevant table data (especially for users and in production environments).

Configuring parameter transactions

Parameter transactions in SAP are configured using transaction SE93. To configure a parameter transaction so that certain parameters are pre-filled and cannot be changed by the user, proceed as follows:

• open transaction SE93 and enter the transaction code of the parameter transaction you want to configure.
• Click on the “Display” button.
• in the next screen, select the “Parameters” option and enter the parameter you want to prefill. In the “Fixed values” field, enter the value you want to prefill for the parameter.
• Select the “No dialog box” check box to prevent the user from changing the parameter value.
• Click the “Apply” button.
• Click the “Save” button to save the changes.

Once this configuration is complete, the parameter transaction will automatically start with the pre-filled parameters each time it is called and the user will not be prompted to change the parameter values.

For our example, remember those users who wanted to call the stock of a certain material in a certain warehouse on a certain date? For them you could create the one parameter transaction with the following values (or configure an existing one, for example MMBE):

• Plant: “Plant1
• Storage location: “Storage location1
• Date: “01.02.2023”.

When users execute the parameter transaction you have provided, these parameter values will be loaded automatically. This way they can quickly and easily run the desired report without having to manually enter the parameter values each time. However, as long as you have unchecked the “Without dialog box” checkbox during configuration, users can also make changes to these values before running the report.

Reminder: If you need to make multiple plants accessible to users (for example, because users from different plants should use this parameter transaction), remember to restrict access to the plants so that users can only access the plants in their area of responsibility. You can do this, for example, using value roles that contain only the corresponding objects (e.g. M_MSEG_WMB).

Building your own parameter transactions

You can also create parameter transactions yourself, or better: have them created. To do this, you use an existing ABAP function or report as a template and configure it with specific parameters.

The process usually involves the following steps:

• write the ABAP function or report that performs the desired functionality. Make sure it is a function or report that can be called with parameters.
• Create a new transaction with the transaction code SE93.
• Enter a transaction name and a short description.
• select the option “With parameters” and specify the parameters that are needed for the transaction. Here you can also define which parameters should be pre-filled and whether they should be modifiable, as described above.
• Enter the function group or report name to be executed when the transaction is called.
• Test the transaction to make sure that it is running.

When are parameter transactions NOT suitable?

Basically, parameter transactions make work easier: errors caused by incorrect user input are minimized, processes are accelerated because users have to make fewer entries manually, and if parameters cannot be changed, you have an additional backup level.
However, there are cases where you would be better off using a dialog transaction:

If the transaction requires too many parameters

If a transaction requires too many parameters, it can be difficult to execute it correctly. This is especially true if some parameters are only optional, but others MUST be specified. In this case, it might be easier and faster to use a dialog transaction that walks users through the steps to enter the required information.

When users require different parameter values

If users require different parameter values, it may be difficult to create a parameter transaction that satisfies all of them. In this case, a dialog transaction with different steps and options for users, depending on their needs, might be more appropriate.