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 running the variant, you receive the termination
MS 419: Error in Variant: Dynpro XXX nn was processed more than 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 conists of 2 screens: the entry screen A and a consecutive screen B. If you use the function Back in the consecutive screen, you taken back to the entry screen A. Now you should use a variant to hide the screen A: When calling the transaction, A is processed invisibly, and B is processed directly after that, this is the first visible screen of the 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. (siehe auch: 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. (also see: Which Screens are Included in the Variant?) This means that you cannot create a transaction variant for the following transaction flow: The user would like to select different menu entries in succession. The user branches from screen A to screen B, and from there to screen C. If the users selects a different menu entry, then he/she branches from screen A to screen B, and then to screen D. The user wants to collect different values for screen B. On principle, the last entered values for screen B are saved at entry time and overwrite the previously entered values.
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.
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.
Weitere Informationen finden Sie unter What Settings can be Copied for Which 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.
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.
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.
There are several different ways to simplify user interface layout in the SAP System (application-specific field selection control, SPA/GPA parameters, screen and transaction variants, and GuiXT). For details, see Interface Design in the SAP 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 value
· 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.
· 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.
· as of 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.
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.
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.
You can create and run batch input folders for variant transactions.