Extended selection for (almost) any transaction

[Former Member]

Even if SAP makes its best effort to provide useful selection screens that may appeal to all its customers, the options could feel limited for your own selection needs.

In this article I explain how to use a query with code to extend the selection of almost any transactions in order to run it for a list of cases that meet a complex and non-standard criteria.

I call the approach a “variant update query” and it is fundamentally that: a query that updates a dynamic variant that is then used in the transaction where you want to apply the extended selection.

This is particularly useful for background processing where you can use one step - of the job or process chain - to run the query that updates the variant, and a second step to run the actual transaction using the newly updated query.

It can also be used while working interactively if you run the query before running the transaction with the updated variant or if the query is designed to launch the transaction from within.

Let’s see an example

This is the block of the selection screen that determines which cases will be included in an APO deployment run (transaction /SAPAPO/SNP02)

Even with the option for a profile some selections are impossible to define in general terms with this screen.

Let’s say that you want to deploy only materials that are classified as “A” for the ABC indicator in the target plant. Or maybe a combination between a condition in the source plant and a different condition on the target plant. This is only an example of a universe of complex conditions you may need to use for the very particular characteristics of your business.

In my experience I have found that this is a great approach if your want to include any customized field, values stored in LiveCache or variant configuration values that generally are not part of standard selections.

One manual option is to select the cases with other tools (e.g. extracting data to Excel to cross and filter there) and copy paste a list of materials in the product selection field.

This is basically what the variant generation query does. It uses a generic selection that produces - in this case - a list of materials and then appends the list into the deployment transaction variant.

The selection of the query can look something like this:

This selection in this screen (that includes the variant to be updated) is populated and saved in a variant for the query. Do not get confused by the fact that there are two different variants: one for the query and one for the transaction.

Running the query selects the materials that comply with the criteria and adds them as a list in the product field of the deployment transaction variant.

I use queries in this article because I love queries. I think queries are powerful and underutilized by many. You can do so many things with queries that I have focused myself and my company into the interesting niche of “query consulting”.

However, you can apply the approach with a regular ABAP program as well.

If you liked this idea, you can find some others in my blog sapppyw.co.uk. 

The technical details

The details will vary accordingly to your requirements, but the approach is similar.

1. The query functionality is used to collect a list of objects to add to the variant, in this case materials but can be orders or other objects. The functionality is so flexible that you can incorporate any criteria and complex links and rules, although you may need to add embedded code in some cases.
2. In the code block at the end of the query run (END-OF-SELECTION before list) use function RS_VARIANT_CONTENTS to extract the current parameters in the variant to be updated.
3. Add the list of collected objects into the required data structure. If you are not sure where they should be I suggest you update the variant with dummy values and debug the function to see where the values are stored.
4. I also suggest you add a value that is not real, for example “NOMATERIAL”, to the list. This is to prevent the transaction from running for all materials if the query result happens to be null.
5. Use function RS_CHANGE_CREATED_VARIANT to update the variant with the new values. Now the variant should be ready to use in its transaction.
6. SAP supports a limited number of individual values in a selection. This value varies depending on the transaction so you may need to experiment until you know what number doesn’t gives you a predefined error or causes the transaction to dump. You can then split the job into several variants. 

Enjoy