This document explains the variant set up from functional side while setting up a back ground job. The other aspects are dealt with in the 2nd part in the series
Many programs within SAP are set up as back ground jobs be it custom or standard. The setting up of such jobs removes manual intervention for execution thereby automating it. So, the user need not be available say to close an FI period at 12AM, if a background job is set up for the same already in the system.
The frequency of job execution may vary – daily, weekly, monthly, yearly etc. But, the aspects of job set up are almost the same as explained below.
Variant set up
One of the first steps while setting up a back ground job to be executed at a particular frequency is to set up the variant for the program for which the job is being set up.
For illustration purposes, we will consider the transaction code F103, transfer posting for doubtful receivables which is used for bad debt processing. This will be a monthly job.
The first part of the variant set up is fairly known to everyone. We enter the parameters that are needed for running the transaction code. In this case, we enter the parameters which will be used when the job is run – details like customer number, company code, provision method etc will be constant for every month the job is run.
The next part comes into play when the save button is pushed. The next screen that appears is the Variant Attributes screen. Here first we enter the variant name and description.
- If the “Only for Background Processing” check box is selected, the variant is available to be executed only in background mode. Otherwise, it is available for execution both in background and foreground modes
- If the “Protect Variant” check box is selected, only the person who created the variant or last changed it can change the variant
- If the “Only Display in Catalog” check box is selected, the variant cannot be seen in general input help, however, it appears on the directory
The last part in variant set up is the setup of dates like posting date, document date, key date etc which are available based on the program for which variant set up is being done. These dates vary for each month. In the sense, company code remains A010 for every month. But, the key date for February may be 28.02.2013, for March 31.03.2013 and for April 30.04.2013. In such a case, we select the Dynamic variable option as shown below.
Once the Dynamic date calculation is selected, the exact date for the variable can be chosen with F4 in the last column as shown below. As seen, there are multiple options. For the example sighted above where the key date is the last date of every month, we select the last option “Last day of the current month” or “Last day of the previous month” depending on when the job execution takes place. If the job is to be executed on the first day of every month, then the key date chosen would be “Last day of the previous month”. If the job is to be executed on the last day of the month, “Last day of the current month” or even the “current date” can be chosen. Please note that the dynamic date selection is always hand in hand with the job execution day of every month.
Also, current date +/- a certain number of days or even working days can be chosen. If a positive value is given for ??, it becomes current date + days or working days. . If a negative value is given for ??, it becomes current date – days or working days. Please note again that the current date is the date on which the job execution takes place.
Life is easy when we have the dynamic date calculation option for variant set up of programs. In such cases, the variant can be directly setup in the production system immediately. But, such options are not allowed in every case. For variants where instead of a date, the period or fiscal year need to be selected, the case becomes slightly more complicated.
For illustration purposes, we will consider variant set up for the depreciation posting program RAPOST2000. The job is to be executed on the last working day of every month. In this case, also, parameters like company code, planned testing run radio button etc remain constant for every month the job is executed.
The next part is where the save button is pushed and we are in the variant attributes screen. The first step is to give the variant name and description as we have already seen. The next step is to select fiscal year and period as dynamic as these values will change once every month for posting period and once every year for fiscal year.
As seen above, no such option is available for fiscal year and posting period. So, we will use one of the available options, a TVARVC. A TVARVC is similar to a variable which holds values that we use in any of the programming languages. To look at the TVARVC’s available in the system, use transaction code STVARV.
As seen, there are 2 tabs – Parameter and selection options. The variables in parameter tab, can hold only one value at a time, while those in selection options tab can hold more than one. The TVARVC’s are generally created by ABAPers. The best practice is to create these in Development system and then transport to Production system so that the landscape is consistent.
For the depreciation run, we need 2 TVARVC’s, one for posting period and another for fiscal year. The created ones are as shown below. From the below screen shot, note that only one value can be maintained at a time. So, the TVARVC needs to be updated monthly, before the execution of the background job. A TVARVC created in the system can be used by multiple programs.
Below screen shot shows the variant that has been set up for the depreciation run program using TVARVC’s.
So, the values in the variables Z_A_CURR_YEAR and Z_A_CURR_MNTH will be used when the job is executed.