When you are working in R/3, what screen do you access most often? I’ll bet it’s one that you use several times per day, most every day of the week. I’ll also bet that you would like to change something about that screen. Maybe you would like to default a value for a particular field or make the field “display only.” If you are in charge of the support of the FI/CO modules, you might have new users who are sometimes confused by certain fields. Maybe you would like to suppress those fields so that they are never seen.

For me, the despised transaction was CJ88 - Actual Settlement: Project. I was trying to debug a particular process and had to execute CJ88 about 200 times over the course of a week. Every time I executed the transaction, I had to select the Detail List indicator at the bottom of the screen to view the details of the resulting settlement. After I settled about 25 projects in the course of an hour, selecting the indicator began to annoy me, and I wanted to figure out how to default the value as “active” so that I didn’t have to keep selecting it manually. I tried using a parameter ID, but this particular indicator didn’t have one. I thought I would be required to set this indicator manually forever, until I found out about transaction variants.

Transaction variants can help solve some of these usability problems by preassigning values to often-used fields and hiding unnecessary fields and even entire screens. They can also be used to disallow user maintenance of a field by making it “display only.”

Transaction variants are useful, because a given transaction may not need all the screens and fields that are in the standard R/3 system. Every SAP customer is different and uses the system in different ways. Therefore, what you need from the standard screens might be different from what SAP intended. Using transaction variants, you can tailor the screens to contain just the fields and screens that are applicable to your unique business process.

What do you gain from manipulating the standard R/3 screens? Easier and quicker data entry, easier training and support of new users, and a more personalized R/3 experience.

What transactions are good candidates for customized transaction variants? I think any transaction that contains even a single field that needs to be hidden, defaulted, or marked as “required” is a good candidate. Other criteria could be any transaction that:

• Is used often, especially by a large number of users

• Has a long process — for example, transactions that span numerous screens/tabs, such as ME21 - Create Purchase Order

• Is the most complex — for example, transactions that contain numerous indicators or fields that could be prefilled with a default value.

(For a method to personalize R/3 systemwide, see the sidebar, “Use Global Values to Personalize R/3 Systemwide,” below.)

Before I create a transaction variant, I’m going to show you the standard screen for Actual Settlement: Project/WBS Element/Network, to give you a “before” image (Figure 1). At the bottom of the CJ88 screen, you can see a section titled Processing Options that contains three checkboxes and a button. In the standard R/3 system, the Test Run indicator is the only one that is set active.

Figure 1

"Before" image of Actual Settlement: Project/WBS Element/Network screen with just Test Run set as active

Create a Transaction Variant

To access transaction variant maintenance, go to the IMG menu path General Settings>Field Display Characteristics>Configure Application Transaction Fields, or use transaction code SHD0.

Once you access the Transaction and Screen Variants screen (Figure 2), enter the relevant transaction code in the Transaction Code field and a descriptive name in the Transaction Variant field. Then click on the create button.

Figure 2

Transaction code and descriptive name entered in Transaction and Screen Variants screen

You should now be looking at the normal CJ88- Actual Settlement: Project/WBSElement/ Network screen (Figure 3). Similar to the Computer Aided Test Tool (CATT) or the Batch Data Communications (BDC) recorder, R/3 is now “recording” the sequence of screens, fields, and field values you are working with. In this example, I’m working with a single screen, but it’s possible to record a transaction variant that covers multiple screens, such as VA01 - Create Sales Order.

Figure 3

Setting the indicator for Detail List

Use Global Values to Personalize R/3 Systemwide
Other methods of personalizing R/3 in addition to the transaction variant include global values, area menus, user menus, user defaults, parameter IDs, and parameter transactions. Most of these R/3 features are already well known, but I haven’t seen many R/3 customers actively using global values.

Global values are similar to parameter IDs in that they are used to prefill a field’s value. Unlike parameter IDs, global values are not user-specific; instead, they apply for the entire R/3 system. That makes them especially useful if the field often has a single value, such as the chart of accounts, controlling area, operating concern, chart of depreciation, purchasing organization, functional area, funds management area, and so on, for all users.

Another benefit of global values is that they are much more effective in prefilling a field’s value than a parameter ID. Only with rare exceptions does a global value not prefill a field correctly, whereas parameter IDs often fail to populate SAP’s parameter memory and prefill the field value for you. However, parameter IDs override the global values, thus allowing you two ways to prefill a value for the entire organization or at a user level.

Step 1: Set Server Profile Parameter

Someone from your technical team should handle this step, as it involves the setting of a system parameter. The R/3 server profile parameter dynpro/global_fields must be set to “Yes” for global values to work.

Step 2: Define Global Values

To access the Global Fields: Component Selection screen, use transaction code SHDG or the IMG menu path Global Settings>Global Field Display Characteristics>Set Global Field Display Characteristics. For this example, I’m going to define a global value for Operating concern (Domain ERKRS).

When you initially enter the transaction, you see the R/3 Application Components hierarchy (APCO). Navigate through the hierarchy until you find a node that is highlighted (usually in orange). To view the global fields that have been assigned to this section of the APCO, select the line and click on the change Global fields button. Since Operating concern is generally associated with CO-PA, I’m going to navigate to the Profitability Analysis section of the APCO, as shown in Figure 1.

Figure 1

Component Selection screen

Figure 2

Activating the global value

You should see a dialog window requesting which operating concern to use. Enter an appropriate value. After returning to the screen in Figure 2, you can manipulate either of the two checkboxes that precede it. The “No entry” flag makes the field “display only,” which is useful for fields that have only one value, so users can’t make a change. The second checkbox makes the field invisible, which might be of use if you want to “remove” the field from all of the R/3 transactions. This might be desirable if you don’t want to confuse an end user with fields that only have one value and never change, such as Operating concern. When done, click on the generate button to the right of the traffic light to activate the global value.

 

To add new global values, you can click on either the create Domain or create Data element buttons that you see in Figure 2. You are then prompted to enter a technical ID of the domain or data element, such as KOKRS - Controlling Area or KTOPL - Chart of Accounts. Keep in mind that you can use domains in multiple modules, so the value you define will be more “global” in nature and will potentially affect more areas. A good example of this is company code. The domain BUKRS is used as a base for other data elements, such as SBUKR - Sending Company Code, and EBUKR - Receiving Company Code.

I now set the indicator for the Detail List function and enter any other required information for this particular transaction, such as Settlement period, Posting period, and Project Definition.

Once I press the enter key to validate the information on the screen, a dialog window appears (Figure 4). This window lists all the fields that are contained in the screen as well as the values that were input manually while the transaction variant was being recorded.

Figure 4

Dialog window with list of fields and values

At this point, I’m going to specify a description for the screen variant and manipulate the appropriate indicators. The items that you need to pay attention to are:

• Copy settings — This should be set by default. It makes sure that the values that are maintained on this dialog window are copied into the transaction variant. If you deselect this indicator, the values and settings that you specify are not included in the variant.

• Do not display screen — It is possible to skip an entire screen during a transaction by selecting this indicator. This is especially useful during a process that contains several screens that might not be needed, such as VA01 - Create Sales Order. What is nice about this functionality is that if the screen contains only a few predictable values, you can suppress the screen but still prefill a field value.

• Field — This is the field that is contained in the screen. It should list the field text, but on some older R/3 releases, the field’s technical name, such as BUKRS, is output instead.

• Contents — This column specifies the field values that were used when the transaction variant was recorded. As you can see in Figure 4, the period and year values have been recorded, in addition to the setting of the Detail List indicator.

• W. content — If you want to default the field with the value that was used when you were recording the variant, select this field. This is the most often used feature of transaction variants, and one that I advise using whenever possible.

• Output only — A better description for this field would be “Display only” or “Read only,” since activating this indicator makes it so the field cannot be changed. When this field is used in conjunction with the W. content field, the user is not able to change the value that has been preassigned to this field by the transaction variant. In this case, the field value might be informative for the user executing the transaction.

• Invisible — If you want the field to be hidden or suppressed, select this indicator. For demonstration purposes, I have chosen to hide the Layouts button and the Check trans. data indicator.

• Required — Selecting this indicator makes the field a mandatory entry during processing. This is useful for fields in FI processing that otherwise would require a custom validation rule to force user input.

Once you have maintained all the settings for each field, click on the enter button to continue to the next screen. This launches you back to the normal processing of the transaction, where you can record more field values. Keep progressing through the transaction’s normal screen sequence until the transaction is complete. After each screen, you are prompted with the dialog window (shown in Figure 4) to maintain the screen’s field characteristics.

Alternatively, if you have reached the last screen for which you want to maintain field values, you can click on the exit and save button instead of enter. In this case, I only want to maintain the fields for the initial screen, so I’m choosing Exit and Save.

You should now be looking at the screen shown in Figure 5. This screen serves as a review of all of the different screens, fields, field values, and their settings that were transferred into the transaction variant. You also have the option to change some of the settings that were maintained at each individual dialog window. This is especially helpful if you are recording a variant for a transaction that spans several screens/tabs, since all of the values can be maintained again on a single screen.

Figure 5

Review of items transferred into the transaction variant

To finish the variant, specify a descriptive text in the Screen variant short txt field and click on the save button.

Click on the back button to return to the Transaction and Screen Variants maintenance screen. Now that you have created the variant, you have two options for using it:

• Create a variant transaction (not to be confused with transaction variant)

• Specify the variant as the standard variant for this transaction code

The second option means that whenever someone accesses transaction code CJ88, they see the same screen, but it will be altered per the settings in the transaction variant. The first option leaves the CJ88 transaction alone and instead assigns the variant to a new transaction code. For instance, you could create a new transaction (such as ZJ88 or ZPS_SETTLE) that displays this new screen. Creating a variant transaction is quite simple, but it is beyond the scope of this article. If you are interested, have someone on your technical team create one; all they need is the base transaction code CJ88 and the transaction variant that you’ve created.

To proceed with the second option, navigate to the Standard Variants tab (Figure 6), enter the variant name, and click on the activate button. You should receive the message, Standard variant also set at beginning of transaction without variant.

Figure 6

Entering the variant name

You can view the end result by going back to transaction CJ88. The screen (Figure 7) should now have the Detail List indicator active. The Layouts button and the Check trans. data indicator are nowhere to be seen.

Figure 7

Viewing the end result, with Detail List selected

This may seem like a small change, but sometimes it’s the small items in R/3 that can be the most frustrating. This functionality can be used to create custom variants for more robust transactions such as FB50 - GL Document Entry, F110 - Payment Program, or VA01 - Create Sales Order.

Nathan Genez

Nathan Genez is an SAP FI/CO- and SAP BW-certified consultant who has worked with SAP ERP since 1996, with an emphasis on the capital accounting modules: PS, IM, and FI-AA. A former platinum consultant with SAP America, Inc., he has worked with SAP BW since release 1.2B. He is currently a managing partner at Serio Consulting in Houston, Texas.

You may contact the author at nathan.genez@serioconsulting.com.

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