Let’s say you have created a query NEW_QUERY in the user group GENERIC.

The key elements that you need are in the previous sentence and the screenshot above – the user group and query

name. As a side note, you also have the ability to hard-code a variant to the transaction code. If you intend to do

so, you’ll need to have that bit of information as well for the next step.

Go to transaction SE93.

In the red box, enter the transaction code name you want to create. You will want to speak to your internal

development team to find out if there are any corporate conventions that must be adhered to when creating a

transaction code. In my example above, I’ve used “Z” as the first character to indicate this is a custom transaction

(you could also use “Y”) and “Q” as the second character to indicate this is based on a query. This is not my

client’s naming convention – it is merely an example.

Click on the button “Create” to proceed.

 In the popup you see in the screenshot above, enter a short text description for your new transaction code and

select the last option in the “Start object” group. That last option is for a parameter transaction. Click on the

green check to proceed.

The next screen has several sections, but you only need to be concerned with two of them.

In the section “Default values for”, fill in the field “Transaction” with the existing transaction

START_REPORT. Put a check mark in the field “Skip initial screen” – this indicator will skip over the selection

screen of the START_REPORT, not your query. You can do that, as well, but that’s not what this indicator

does. Press Enter or click on the green check next to the command line. This will validate the transaction you’ve

entered and pull the correct information for the next step.

You can ignore the section labeled “Classification” – it will populate the necessary values automatically.

At the bottom of the screen, there is a grid with two columns in the section “Default values”. In the first column,

use the dropdown to select the screen field; in the second column, enter the value that should go into that field.

I’ve highlighted the values in the red box that match what is needed for my example. Here’s a recap of the fields:

 D_SREPOVARI-REPORTTYPE – always enter “AQ” here. This is required.

 D_SREPOVARI-REPORT – enter the user group name here. In my example, my user group is
“GENERIC”. This is required.
 D_SREPOVARI-EXTDREPORT – enter the query name here. In my example, my query name is
“NEW_QUERY”. This is required.

This is the extent of the entries you’ll need. There are other fields in this grid that you could put values to. Below

is a screenshot of the dropdown.

The fourth entry in the list (D_SREPOVARI-VARIANT) is the way that you could define a specific variant that

should execute when your new transaction runs. In my example, I left it out. If you look at the transaction

START_REPORT (below), you’ll see all fields in the dropdown above – it might make what I’ve explained above a

little clearer.

Once you’ve added the fields and values, you can save. You’ll have to identify a development class (package) – see

the screenshot below. If you’re not already familiar with which package to use, contact your development

team. I’ll be using a local object because this example won’t be transported out of the client.

Saving with a non-local package will prompt you for a transport. Once you’ve released the transport, you should
ensure that you move your user group, infoset, and query to the appropriate clients. You can have a transaction
existing in a client without the query – but it won’t do anything other than give you an error that the query doesn’t

exist. Make sure that your query and user group in every client matches the values you used in the client where

you made the transaction.

You can see that you do not need the underlying report that SAP generates for the query – the new transaction is

linked only to the user group and query itself.