Program variants don't need any introduction. Put simply, instead of entering selection values on a program every time, you save them in a variant. You can create any number of variants for any program and then can use these variants while running the programs and reports.

Although use of variants is common, many people just scratch the surface of what is possible. There is more to the process than just saving a variant by assigning a name and description. Using variables within variants, for example, makes the process more efficient. As noted in the "Key Concept," selection variables are of three types.

I am going to focus on how TVARV variables work, because I have observed that they are underused. One of the reasons may be the way they are described in SAP help documentation. The description says, "These are fixed values from table TVARV. You should use these variables if you want to store static information." This message suggests that these variables are hard-coded and cannot be used for calculations and are more suitable for situations when the period is always "Beginning of the period – 1" and not changing every month.

However, TVARV variables can change. You can maintain the values of the TVARV variables through the report variant screen for each report variant or more efficiently via transaction SM31 (table maintenance) for centrally managing all the variants.

Consider this straightforward example. Say you want to execute the report G/L Account Balances RFSSDL00, as shown in Figure 1, for specific selection criteria. In this example, you are running the G/L balances report for period 11/2004, Company code 0001, account numbers 40000001 to 40000099, and Chart of accounts INT.

Figure 1

Execute a report with selection criteria

To create a variant, click on the save icon. The entered values are saved as a variant. Enter the name for the variant (FICOEXPERT) and description (Test Variant for FI/CO Expert) as shown in Figure 2. Click on save again to save the variant in the system.

Figure 2

Save a report variant

The next time you want to run the report with the same selection parameters, you could run the program with this variant instead of re-entering the selection values again. Now let's introduce some complexity.

Business Case

Say that next month you want to run this report again for similar selection options. The only difference is that you would be running the report for the period 12/2004. Just the period is changed from 11 to 12; all other selection fields remain the same. Changing the variant values for one report sounds easy, but what if you were running hundreds of reports over the month-end with a parameter option for period? Wouldn't it be better if the variants changed the period automatically to 12? Of course! Instead of changing the selections in the variant, you can make system change the variant values automatically.

Business Solution

You can achieve this by using selection variables within variants. As the name suggests, variables are used to vary the values of the selection fields. You can set the variables settings for the fields by checking the Selection variable check box for the selection option fields and the clicking on the Selection variables button, as shown in Figure 3.

Figure 3

Mark the selection fields as selection variables

You then assign the variant variables for the selection fields, selecting one of the three options (Figure 4).

Figure 4

Assign the variant variables to the selection fields

How to Assign a Variable

In my example of a variable for a period (B_MONATE), you assign a TVARV variable to a selection field via the following process. Check the check box for the field (in this case, Reporting periods) and click on Selection variables. On the next screen choose Variant variable for variant, and use the drop-down arrow icon to view the existing variables. Click on create to create a new variable S-CURRENT-REPORT-PERIOD and choose the Select option button. Enter the value of this variable as 11, as shown in Figure 5.

Figure 5

TVARV variable S-CURRENT-REPORT-PERIOD

Create a TVARV variable S-CURRENT-REPORT-YEAR for the field Fiscal year with the value 2004. Save the changes and the variant, as shown in Figure 6.

Figure 6

Choose the variant variables for variant

When you execute the report with variant FICOEXPERT, the program derives the field values from the TVARV variable and replaces the field value for the period with 11 and the fiscal year with 2004. The end result is the same. However, the biggest advantage is that in the next fiscal period, you just change one value within the TVARV table (change the value of S-CURRENT-REPORT-PERIOD to 12). It will be effective in all the reports that are used with this variable.

Best Practices

Refer to Tables 1 and 2 below for potential uses of TVARV variables, their sample values, and business purpose. Remember the following best practices when using TVARV variables:

• Assign prefixes to your variables. Parameters are single-value fields, whereas select options allow you to enter the ranges with multiple values. You must define the selection category of the variables, either parameters or select option, the same as you do the field type. Prefix your TVARV variables with P (parameters) or S (select options), so that it is easy to identify the variables. For example, variable P-REPORT-PERIOD easily conveys that it can be used to select fields of the type parameter.
• Create two variables for parameters and select options. Many programs have the same selection field, either as a parameter or a select option. For example, sometimes you can enter the fiscal period as one value only (a parameter) or sometimes you can enter it as a range (a select option as shown in Figure 1). Create two separate sets of variables, one as parameters and other as select options (e.g., P-CURRENT-REPORT-YEAR and S-CURRENT-REPORT- YEAR). Just by looking at the variable names, it is easy to know which ones are parameters and which ones are select options.
• Maintain the TVARV variables for current values. Instead of maintaining the variable values through report variants individually, it is advisable to maintain these TVARV variables via transaction SM31 for all records.
• If many variables are in a TVARV table or the values of these variables need to change more frequently, update them via a custom program instead of maintaining these TVARV table entries manually. A custom program can update the values based on the business situation — for example, the next business day does not need to be the next day. It can be based on a business calendar of the company.
• Do not use system date variables. This may raise some eyebrows, but do not use the variable SY- DATUM (system date). Instead, create a date variable TODAY and update this value every day. By using a system variable (e.g., SY-DATUM), you lose control over the content of the value and cannot test the interface that is going to run after a few days using that day's value. Using a variable TODAY, you can change the value for a future date and can test the program. To maintain the correct values of such variables, execute the custom program daily at 00:00:01 am in batch. That way all your variables, especially variables like today, last processed day, last completed period, and next processing date have the correct values.
• Create multiple sets of variables for different purposes. During the first couple of days of the financial month-end close process, you would still run reports for the period being closed (i.e., the previous fiscal period) even though you are in the next fiscal period. Create two sets of variables — one for reporting processes (P-CURRENT-REPORT-PERIOD and S-CURRENT-REPORT- PERIOD) and others that require the actual fiscal period (P-CURRENT-FISCAL-PERIOD and S-CURRENT-FISCAL- PERIOD). During the first couple of days, for example, P-CURRENT-REPORT-PERIOD will have the value of 11 and the P-CURRENT-FISCAL-PERIOD will have 12. After the close is over, you may want your reporting period to be the same as the fiscal period. If so, make the value of P-CURRENT-REPORT-PERIOD 12. Manage this via a custom batch program.

Mitresh Kundalia

Mitresh Kundalia heads the SAP practice at Quality Systems & Software (www.QSandS.com), a consulting firm specializing in SAP S/4HANA, SAP General Ledger, and complex System Landscape Optimization (SLO)-type reorganizations. Mitresh is widely acknowledged as a leading SAP expert, with multiple publications and an SAP-PRESS book to his credit. He has published more than 50 peer-reviewed articles and white papers, and he has given presentations at various SAP conferences and events. Mitresh is the chief solutions architect of General Ledger Migration Optimizer (GLMO), a leading product to accelerate and jump-start the SAP S/4HANA and SAP General Ledger initiatives; SAP Data Reorganization Optimizer (SDRO), an SLO-type product for managing complex system landscape reorganizations; and Group Currency Activation and Conversion (GCAC), a product suite to manage introduction of parallel currencies and conversion of data in a live SAP system.

You may contact the author at Mitresh@QSandS.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.