Transaction Variants and Screen Variants: Restrictions
Leave to Transaction/Call Transaction
If a LEAVE TO TRANSACTION XYZ or CALL TRANSACTION XYZ is processed in an application transaction where XYZ is the transaction and not the variant transaction, the reference to the variant is lost. This means that from this point on, values can no longer be imported from the variant.
Using a standard variant is one solution to this problem. No new transaction codes are necessary with standard variants. However, be aware that in this case all transaction users will automatically be provided with the standard variant's values and attributes.
Differing Display Attributes in Different Step Loop and Table Control Lines
Transaction variants can only change step loop and table control display attributes column for column.
If step loop or table control fields from different lines have different display attributes (for example, the initial line is ready for input and the subsequent line is display only), the following may occur:
Step Loops and Table Controls Extending over Multiple Pages
If a table control extends over several pages on your screen, no values can be set for it since the system cannot determine where (in which line) the value should be set.
The same is true for step loops.
Re-Sorting Entries in Step Loops and Table Controls
If step loop or table control fields are re-sorted internally in an application transaction (alphabetically, for example), the transaction variant's values appear more than once and overwrite those entries entered manually.
The transaction variant's values can only be determined statically for specific line numbers in the step loop. If you want to allow further changes to be made, no field contents can be adopted here.
Consolidating Screens
You cannot use transaction variants to hide fields in various screens and subsequently consolidate these screens into a single new screen.
Technical background: One of the advantages of transaction variants is that the program logic of the application transaction in question does not need to be altered. Consolidating multiple screens into a single screen would make it necessary to alter flow logic and SAP discourages this.
Additional Screen Elements
You cannot use transaction variants and screen variants to add additional elements to a screen. Variants should be used to simplify transaction flow by reducing the complexity of screens and transactions. You may, however, add certain elements to a screen by creating a corresponding GuiXT script (see
GuiXT).No Screen Sequence Control in Transaction Variants
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. (
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.