The topics related to transaction and screen variants have been
discussed many times in this forum. We still find many discussion
threads and questions regarding how can we make a screen field invisible
or how can we provide a field to a certain group of users in display
mode. This is another attempt to discuss transaction and screen variants
in a detailed manner with an example of CS02 (change material BOM)
transaction code.
Introduction:
Transaction Variants are very important for the following key features:
Restrict access to unnecessary data fields to the users. In an
integrated ERP like SAP, data flows from one module to another and
sometimes it is required to hide few specific data fields to a
corresponding group of users.
Optimized data access and screen access: for example, a group of
users are responsible to update few specific fields, and they are not
interested in other fields irrelevant to them.
Reducing the risk and restricting users to actions: for example, you
do not want a group of users to change the quantities inside a
production order, or change quantities inside BOM, or delete a component
inside BOM etc.
As the name suggests, it is a ‘variant’ of the standard transaction inside SAP.
Scope:
The knowledge:
How to create a transaction and screen variant, and attach it to a custom transaction code.
What are the options available during creation and change?
This is very important to all the functional/ technical/ techno-functional consultants working in SAP.
Process:
The step by step procedure of creating screen variants, transaction
variants and variant transaction codes is discussed in this section with
an example in IDES with EhP 4.
Here we take the case of changing a material BOM (CS02) with the following constraints attached:
The user is authorized to change only the consumption storage location.
The user cannot delete any item, or change any other fields, or delete the BOM itself.
The transaction variant should be created in the development system,
and then transported to quality and production system after prior
testing.
Transaction variants are created in SHD0 transaction code:
After providing the name of the transaction variant you are going to
create, click on the create button or press ‘F5’ to create the
transaction variant. This will take you to the original transaction, and
record the screen fields to the screen variants which are going to be
created in this process.
Press Enter. You will see a pop-up appearing to ‘confirm screen
entries’, you can make the necessary changes during recording, or record
all the screen entries and making decision at the end. We will follow
the second option in this example.
There may be an option for ‘menu functions’ in that pop-up screen. It
is used to deactivate any menu functions (as in this case, we are not
allowing the user to delete any components or the BOM, so we will think
of deactivating the ‘Delete’ pushbutton (a function key), and you can
control what are the menu options you want to be unavailable to the
user.)
This process also shares a great knowledge regarding the flow of the
actual standard transactions; you get to know what are the ‘function
key’s already deactivated in a specific screen.
For example, in standard CS02, the option of deleting BOM is deactivated in the initial screen. In standard CS02:
So, if we try to deactivate it over here, system should let me know
that it is already deactivated. Click on the ‘menu functions’ button to
call the interface variant:
Click on the folder with a ‘+’ sign to expand:
I think the concept of ‘interface variant’ is now clear. We press
Enter to continue to the BOM components screen (General Item Overview).
Press Enter, system will again show up a pop-up screen to indicate the screen fields are being recorded in the screen variant.
The interface variant for this screen will be required, since we do
not want to allow the users to delete a component (or other function
keys or menu options). Click on the ‘Menu functions’ button:
Press Enter.
Continue pressing Enter until you reach the General Item Overview screen again.
In this process we record all the screens inside BOM. The person
creating the transaction variant must have a fair idea of the ways the
user can make changes, all the menu options that he may follow;
otherwise it will not be full-proof and safe.
For example, in this recording we also capture screens from the
component details screens, BOM header screen, all the tabs, and
deactivate menu functions whenever necessary.
After capturing the screens, press the exit key (Shift + F3):
You will reach to the Change transaction variant screen. All thescreen recordings are now complete and you are going to decide:
Which fields will be ‘display only’
Which fields will be ‘invisible’
Which menu functions will be deactivated during this variant transaction
Use ‘page down’ and ‘page up’ keys to navigate through all the screen variants.
Since the user was responsible to change the consumption location, we allow entry in this filed.
Make the settings for deactivated buttons as shown:
The process is complete. We will now save the screen variants and the transaction variant.
Click on the ‘save’ button:
System will ask for a package during save. Provide suitable package to which you are saving.
Press Enter.
System will show a pop-up for a workbench request, so that this can later be transported to quality and production system.
Continue pressing enter to save all the screen variants to this
single workbench request and with the same package, until you reach the
transaction variant screen again.
So, now the transaction variant is saved and we are ready to test the same.
Press the back button (F3).
Press F8 or click on the test button to test this transaction variant:
So, this has successfully been tested now.
Now we will create a custom transaction code (variant transaction), that uses this transaction variant.
From the transaction variant screen, press Shift + F6 or follow the menu path:
Press Enter.
Save the custom transaction code. During save, provide the same package and the workbench request number that we have used.
Now we are ready to use this variant transaction.
Authorizations:
The specific group for which we have created this variant transaction
‘ZCS02’ will now be authorized to this transaction code by BASIS with
proper roles and authorizations.
The following section has been included in version 2 and
this section is inspired by the feedback provided by expert Jeevan
Sagar:
Requirement:
We take here an example case where the ‘material memo’ pushbutton for
long text should be made invisible from MD04 screen for all the users.
Please find the below SCN thread and let us extend this case for all the users:
In this case, we are not going to create a variant transaction.
Instead we will activate this transaction variant to the standard MD04.
Go to the Standard variants tab as shown below.
After entering the transaction
variant, click on the Activate button. System will show an information
message: ‘Standard variant also set at beginning of transaction without
variant!’
Press Enter. Now you will see that the
‘deactivate’ button becomes active. This can be used anytime to
deactivate the usage of the transaction variant to the standard
transaction.
You can now test the MD04 transaction, it will use the transaction variant that has been activated.
