Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
Showing results for 
Search instead for 
Did you mean: 

Screen & Transaction Variant

Former Member
0 Kudos


I was having some query regarding 'Transaction Variant' & 'Screen Variant'.

Can anybody plz provide me some relevant documents. If possible plz provide some example, so that i can try this out...

Thanks in advance.....

Thanks & Regards



Active Contributor
0 Kudos

Hi Sangram,

Check this sap link

<b><a href="">Transaction & Screen Variant</a></b>

Enjoy SAP,

Pankaj Singh.

Former Member
0 Kudos


Whenever a screen for a particular transaction is to be suppressed using a transaction variant, the function code is saved in the variant so that the transaction can resume with the following screen. It is especially easy to use the function Exit and Save to exit the dialog box for value creation and mistakenly save the function code that keeps you on the 'invisible' screen. When this happens, the program is terminated with the message

MS419: Variant error: Screen XXX nn was processed more that 100 times.

If the invisible screen possesses a function code for leaving screens, it may be not be possible to leave the next screen.

Example: A transaction is made up of two screens: Initial screen A and the next screen B. On screen B, the function Back allows the user to go back to the initial screen A. Suppose that a variant is used to make screen A invisible: Now, whenever the transaction is processed, screen A is processed invisibly, immediately followed by B, the first visible screen in this transaction. If Back is chosen on screen B, then A is once again processed invisibly, followed by B. To the user it looks as if screen B has never been left.

Function codes are only stored in transaction variants if a screen is to be hidden using a variant. In all other cases, function codes are not saved, which means that the screen sequence control is not recorded. (see also: What Settings Can Be Copied for Which Fields?) Only the field values and field attributes for specific screens are saved. This allows a transaction variant to be used in different transaction flow. When a screen from the variant is processed, those values stored in the variant are inserted at the appropriate spots. No values are inserted for those screens contained in the variant but not processed at runtime. This does not lead to errors.

Be aware of the fact that each screen can only be saved once per variant. (See also: Which Screens are Included in the Variant? ). This means that you cannot create a transaction variant for the following transaction flow: Say the user wants to select different menu entries, one right after the next. In doing so, the user branches once from screen A to screen B, and from there to screen C. If the user chooses another menu entry, he or she branches from screen A to screen B, and then to screen D. In this example, the user wants to create different values for screen B. This is not possible, because values last entered for screen B are saved and overwrite those entered before them.

Tabstrip Controls

Tabstrip controls are made up of pushbuttons (the tabs) and several subscreens. Each tab has its own subscreen. These tabs are part of the main screen and are therefore displayed in the field list of the dialog box for the main screen. Subscreen fields are displayed in other dialog boxes.

According to how a tabstrip has been constructed internally:

Either a sole dialog box is displayed for the subscreen that belongs to the tab that is currently active, or

Dialog boxes are displayed for all subscreens that belong to the tabstrip control.

If an invisible tab is set to active by the application transaction, different subscreens are selected for those tabs remaining that actually belong to other tabs. If the subscreens are invisible, it is also possible that an empty screen will be displayed.

Technical Background:

The transaction variant sets another tab (the remaining tab furthest left) to active. This additional active tab is, however, unknown in the application transaction, which assumes that its tab is active and selects the corresponding subscreen. If this subscreen has been faded out using the transaction variant, then an empty screen is displayed.


Information on this topic can be found under What Settings Can Be Copied for Which Fields?.

With contents is Not Ready for Input with Input Fields

No values can be transferred for numeric fields since the formatting (decimal representation) for these fields is user-specific and due to technical reasons no user-specific settings can be tampered with during variant processing. Date fields can, however, be transferred. The user-specific setting here is pulled at the beginning of variant processing.

With contents is Ready for Input with Non-Input Fields

If a field only becomes an input field during runtime, all switches in the dialog box are ready for input, but only the switch Invisible takes effect.

Screen Compression

In principle, screen compression works if all screen elements are hidden using a variant. Screen compression can be explicitly switched off for certain application transactions (for example, FB01). Variants are not valid in this case.

Interaction between Application-Specific Field Selection Control, SPA and GPA Parameters, GuiXT, and Transaction and Screen Variants

There are several different ways to simplify user interface layout in the R/3 System (application-specific field selection control, SPA/GPA parameters, screen and transaction variants, and GuiXT). For details, see Designing User Interfaces in the R/3 System.

The following rules apply when using more than one of these techniques concurrently:

Hiding screen elements

Screen elements that have been hidden by a function remain hidden. This is also true if the element is set to Display only by another function.

Default values

SPA/GPA parameters and screen and transaction variants

Default values for SPA/GPA parameters may be overwritten by screen and transaction variant values sometimes.

Default values from screen and transaction variants are given priority if the variant hides a field or revokes its ready for input status. These values also have priority if SET parameter is used to set an initial default value (SPACE, for example). On the other hand, SET parameter default values have priority in ready for input fields since the variant cannot tell the difference between values set by SET parameters and user entries.

GuiXT combined with other functions:

GuiXT values are only set if the field in question has an initial value. This also applies if the value was set by the transaction, SPA/GPA, or a variant.

Hidden screens

All screens hidden using transaction variants or screen sequence control remain hidden.

Upgrade Procedures

Overwriting Variants

Up to Release 4.5B

Up to and including Release 4.5B there was no namespace for transaction variants and they were not attached to the Change and Transport Organizer. Normally, transaction variants were not delivered.

From Release 4.6A

From Release 4.6A a namespace exists for cross-client transaction and screen variants and they are attached to the Change and Transport Organizer. This means that customers' cross-client transaction and screen variants are not overwritten by variants delivered by SAP.

Changing Screens: Possible Problems

Transaction variants are usually tolerant of screen changes. In certain cases, however, it may be necessary to adjust your screen or transaction variant.

Additional screen elements or deleted screen elements

If a screen contains additional screen elements not contained in the screen or transaction variant, the variant ignores these fields. The same is true for screen elements contained in the variant that have been deleted. In this case the settings save for the element cannot be set (adopted). This does not lead to errors.

Exception: If a table control's column sequence has been saved in the variant and columns have been subsequently added, then the variant must be adjusted.

Renamed screen elements, screen elements whose type and/or length has been changed

If screen elements present in the variant have a new name, length, or type, this can lead to errors at runtime. In this case, you must adjust the variant.

Deleted screens

If a variant contains screens that have been deleted, the variant ignores these screens. This does not lead to errors.

Batch Input - Standard Variants

If a standard variant is active for a transaction and the transaction is to be executed during batch input, the values from the standard variant are not inserted.

Batch Input - Variant Transactions

You can create and run batch input folders for variant transactions.