Variants are a way to store the (field) settings (or values) a report can be executed with. Most reports can use variants. 

An example: a particular report is only used for... the document types "RE" and "EZ". Thus the values "RE" and "EZ" will always have to be entered when executing the report. These values can be stored in a variant; starting the report with this variant would result in a selection screen with "RE" and "EZ" already filled in.

"Getting a variant" from the report selection screen is also very common: in effect the parameter settings for the report were stored and can be retrieved any time. There is one small requirement: the report must have a selection screen (at least 1 parameter or select-option field). 

Creating a variant

Is a very easy action: an end user can do it him/her self. Start the report and fill in the selection data. This data can be saved as a variant by selecting the save button on a reports's selection screen.

Each user can create and/or select (use) variants. Variants can probably be used for more that the end user desires; therefore it is possible to add some extra flags:

• Background only indicates that the variant may only be used for background processing (call from another ABAP or the batch-job mechanism).
• Protect variant only the creator of the variant can modify.
• Do not display variant indicates that the variant will be invisible when selecting possible variants.

It might also be useful to exclude fields from importing or even make them completely invisible. Especially for reports called from another ABAP can benefit from the end user's not filling in irrelevant data. With the checkbox "Protected" and "Invisible" you can indicate beforehand what fields to exclude.

Variable variant field content

Variables can be linked to selection fields. These variables may be constant (e.g. today's date) or may come from the table with variant variables, table TVARV. The variables from TVARV can be created/modified via transaction STVARV, from the create variant menu: Environment => Maint.sel.variables or directly from an ABAP table update. Transaction STVARV.

Note that SAP has introduced table TVARVC in release 6.10. OSS notes 557314 and 655316 provide detail for this. It is in fact the client-dependant version of TVARV.  A conversion program RSTVARVCLIENTDEPENDENT is available to copy entries from old TVARV to new TVARVC. 

Report transactions.

If you have a report that should be used with a certain predefined set of select option settings, a Report transaction can be created for it. This is effectively a transaction code for the report on which the variant name to be used is specified. Sap does this standard: check out transaction F.13 for example. A powerfull concept for muscle reports. Simply set up your new transaction code via SE93.

To do this, a "system variant" is needed. This is much like any variant, with the exception that it is transportable and usable on transaction variants. System variants also have to adhere to naming convention SAP& or CUS& (SAP or Customer). Create your system variant in client 000.

Delete multiple variants

Variants that are no longer useful can be removed with the SE38 transaction, where each variant would need to be selected and deletion needs to be confirmed. Note however that there is a mass-processing method as well:

• Start transaction SE38 and select the radio button "Variants" and then "Change" (button).
• In the menu there is an option Variants .> Catalog, find it and select it
• The variants are listed. Click on the button "Delete selection" where "Delete" is in fact the dustbin icon.
• From the popup that is shown, the variants you want to delete can be selected by checkbox, or all checkboxes can be selected at once.

Transporting a variant

Do you need your variant to be available throughout the landscape ? Report RSTRANSP is available to add it to your customizing transport.

• Next