CHANGING THE SAP STANDARD 51

You can adjust the R/3 System to meet your needs in the following ways:
Customizing: This means setting up specific business processes and functions for your system according to an implementation guide. The need for these changes has already been foreseen by SAP and an implementation procedure has been developed.
Personalization: This means making changes to certain fields' global display

attributes

(Setting default values or fading fields out altogether), as well as creating
user-specific menu sequences.


Modifications: These are changes to SAP Repository objects made at the customer site. If SAP delivers a changed version of the object, the customer's system must be adjusted to reflect these changes. Prior to Release 4.0B these adjustments had to be made manually using upgrade utilities. From Release 4.5A, this procedure has been automated with the Modification Assistant.


Enhancements: This means creating Repository objects for individual customers that refer to Objects that already exist in the SAP Repository.

Customer Developments: This means creating Repository objects unique to individual
Customers in a specific namespace reserved for new customer objects.

Customizing and most personalization are done using tools found in Accelerated SAP; customer developments, enhancements, and modifications are all made using the tools available in the ABAP Workbench.

If your requirements cannot be met by Customizing or personalization, you may either start a development project or try using a CSP solution (= Complementary Software Product).

A development project falls into the customer development category if the SAP standard does not already contain functions similar to the one you are trying to develop. If, however, a similar SAP function exists, try to assimilate it into your development project by either enhancing or modifying it, by using a user exit, or simply by making a copy the appropriate SAP program.

Modifications can create problems, as new versions of SAP objects must be adjusted after an upgrade to coincide with modified versions of SAP objects you have created. Prior to Release 4.0B these adjustments had to be made manually using upgrade utilities. From Release 4.5A, this procedure has been automated with the Modification Assistant.

Thus, you should only make modifications if:
Customizing or personalizing cannot satisfy your requirements
Enhancements or user exits are not planned
It would not make sense to copy the SAP object to the customer namespace.


The Business Engineer is made up of all SAP implementation tools. These include:
The R/3 Reference Model contains all of the models used to describe R/3 (the process model, the data model, the organization model) The Implementation Guide (IMG)
A complete list of all Customizing changes
Personalization accelerates and simplifies how business cases are processed by the R/3 System. During personalization, individual application transactions are adjusted to meet the business needs of your company as a whole or even to the needs of specific user groups within your company. All unnecessary information and functions found in the transaction are switched off.

Global display attributes allow you to define default values for specific screen fields. You can also suppress individual fields or table control columns in a particular transaction, or even a whole screen.

Role-based menus, favorites, and shortcuts allow you to adjust menu sequences to reflect the needs of different user groups within your company.

Modifications are changes to SAP objects in customer systems. They are:
Executed with the help of user exits (these are subroutines reserved for customers that have been inserted in objects in the SAP namespace)
'hard-coded' at various points within SAP Repository objects.

Customer developments are programs developed by customers that can call SAP Repository objects.

Example: A customer creates a program that calls an SAP function module.

The enhancement concepts embody the reverse of this principle: SAP programs call Repository objects that you, as a customer, created or changed. Example: You use a function module exit called by an SAP program. You can enhance your system at the following levels:

in ABAP programs (function module exit)
on GUI interfaces (menu exit)

on screens by inserting a sub screen in an area specified by SAP (screen exit)

on screens by processing customer code that refers to a specific field on the screen (field exit)

in ABAP Dictionary tables or structures (table enhancement)

SAP provides two ways to enhance tables and structures with fields.

Structures

Customizing includes ("CI includes")

Both techniques allow you to attach fields to a table without actually having to modify the table itself.

Append structures may only be assigned to a single table. A table may, however, have several append structures attached to it. During activation, the system searches for all active append structures for that table and attach them to the table.

Append structures differ from include structures in how they refer to their tables. In order to include fields from an include structure in a table; you must add an '.INCLUDE...' line to the table. In this case, the table refers to the substructure. Append structures, on the other hand, refer to their tables. In this case, the tables themselves are not altered in any way by the reference.

Append structures allow you to attach fields to a table without actually having to modify the table itself. Table enhancements using append structures therefore do not have to be planned by SAP developers. An append structure can only belong to exactly one table.

In contrast, CI_includes allows you to use the same structure in multiple tables. The include statement must already exist in the SAP table or structure. Table enhancements using CI_includes do, however, have to be planned by SAP developers.

Field exits need not be prepared by the SAP application developer. You can create a field exit for any screen input field that has a Dictionary reference. The reference object is the data element.

The unit "Enhancements to Dictionary Elements" discusses how the field exits work.

The purpose of a program enhancement is always to call an object in the customer namespace. You can use the following techniques here:

A special exit function module is called by the SAP application program. The function module is part of a function group that is handled in a special manner by the system.

Business transaction events

The SAP application program dynamically calls a function module in the customer namespace.

Business add-ins
The application program calls a method of a class or instance of a class. This class lies in the customer namespace.

Program enhancements permit you to execute additional program logic in SAP application programs. SAP currently provides the techniques outlined above.

The advantages and restrictions of the particular enhancement techniques will be discussed in detail in later units.

Menu enhancements permit you to add additional menu entries to an SAP standard menu. The system provides two options here:

Customer exits

Business add-ins

The additional menu entries are merged into the GUI interface.

When the function code is implemented; you can change the text of the menu entry, and provided the SAP developer specified this option - change the icons.

Screen exits belong to the customer exits. They allow you to display additional objects in an SAP application program screen. The SAP developer must:

Define the sub screen areas

Specify the corresponding calls in the flow logic

Provide the framework for the data transport

Include the screen exit in an enhancement

Maintain the documentation

You can implement screen exits by creating sub screens, possibly with flow logic. You also have to implement the data transport.

How you implement screen exits will be discussed in the "Enhancements using Customer Exits" unit.

Any change that you make your system to an object that has been delivered by SAP is known as a modification.

Modifications can lead to complications at upgrade. When SAP delivers a new version of the object, you must decide whether the new object should be used, or whether you want to continue using your old object.

Prior to Release 4.0B, modifications were only recorded at Repository object level (for example, an include program).

Since Release 4.5A, the granularity for recording modifications has been finer. This has been made possible by the Modification Assistant, as we will see in the "Modifications" unit.

The modification adjustment process has also been overhauled. How modifications are adjusted is also part of the "Modifications” unit.

The SAP System adjusts itself to the user's style of working: When the system is started, the users are only offered functions that are typical in their daily work. There is no unnecessary navigating through functions that are not used. In the past, user menus could be called in the Session Manager or in the dynamic menu in R/3. With Release 4.6A, the role -based menu is output in the form of a tree for each user.

When you select a function, it is started in the same session. This function replaces the role –based menu. The role -based menu appears again automatically when you leave a transaction or when you start a new session.

In the maintenance screen for activity groups (Transaction PFCG), the administrator can combine the menu structure for an activity group consisting of transactions, reports, and Internet/Intranet links to a user menu. You can choose any structure and description for the functions contained.

The enterprise menu is no longer available with Release 4.6A.

Typical questions at a work center are:

What function should be performed at this work center?
Which menus are needed?
What authorizations do the users need?
Which users are involved here?

The goal of personalization is to answer these questions in the R/3 System.

The tools provided by R/3 for this purpose are area menus and activity groups.

We will now see how these tools can be used to adapt the work center to the user's needs as effectively as possible.

Area menus were also included prior to this release. They can contain:
Transactions
References to other area menus
Executable programs (new)
Lists created by programs (new)

From this release onwards, you can include programs in area menus that create lists directly.

You can assign users an area menu as their start menu. These users no longer see the complete SAP menu when they log onto R/3, but only the menu items that they require. By integrating the report trees, users obtain a complete view of their work environment.

Area menus can also be linked to activity groups.

In contrast to previous releases, area menus are displayed in tree form starting with Release 4.6. This gives the user a clearer overview of the available options.

The objects that can be included in the area menu are listed in the right part of the graphic.

Use Transaction SE43 to create an area menu. You can call this transaction with the given path.

Assign a name in the corresponding customer namespace and create the area menu.

You can include the area menus in your list of favorites in the GUI for faster editing at a later time.

You build area menus by creating entries in the tree structure. Position the cursor and choose the corresponding icon for insertion at the same level or one level down. In the popup window that now appears, choose a description and the corresponding transaction code.

You can also insert reports (objects that create lists, such as ABAP programs, querie s, and so on)

You can no longer store lists in report trees as of Release 4.6A. Report trees have been integrated in the new area menus.

With List--> Save --> Report tree you can store lists for the program. Since the lists are stored program-specifically, you can display them in the corresponding area menus.


During an upgrade, existing area menus are automatically migrated to the new structure. You can make further entries in these new area menus.


With Release 4.6, SAP has implemented user-oriented R/3 operations. When the R/3 application is started, a tree structure appears in the initial screen containing the entries the user needs for his daily work.

These role -based menus go beyond the scope of the area menus. Only the menu structure can be defined for area menus. You can define them as you like for role -based menus. They also use the functions of the Profile Generator.

By using specific role -based menus you can set the following individually:

Menu structure
Profiles
User assignments

The term "activity group" is synonymous in R/3 with "role -based menu." You can edit activity groups using the Profile Generator.

Before you create your own activity groups, you should evaluate the predefined workplace examples that SAP delivers in Release 4.6A. You can use these workplace examples just as they are delivered in the SAP System.

Delivered activity groups should not be changed. You can combine several activity groups to form a composite activity group. Which may also include activity groups delivered by SAP?

To create an activity group; choose the appropriate button on the initial R/3 screen.
Assign a name for the activity group in the customer namespace and press Create. The system displays the maintenance screen for activity groups.

The activity group naming conventions are defined as follows:

SAP* delivered by SAP
Rest customer namespace

To create an activity group; choose the appropriate button on the initial R/3 screen.

Assign a name for the activity group in the customer namespace and press Create. The system displays the maintenance screen for activity groups.

The activity group naming conventions are defined as follows:

SAP* delivered by SAP
Rest customer namespace

There are several ways to build the menu for your activity group. You can copy sub-trees and menu entries from
the SAP menu
another activity group
an area menu
You can also maintain single entries. These can be

a transaction code
a report in which a transaction code is automatically generated
a hyperlink (e.g. web address or a path on the local machine)
You cannot maintain single entries if it is a composite activity group.

The system determines the authorization objects used in the given transactions. The assignment of single authorization objects for a transaction using Transaction SU22 provides the basis for this determination.

Transaction SU22 also specifies for the particular authorizations whether or not:
there must be a check
there are default values
Using these default values makes maintaining authorizations much simpler. You only have to maintain authorizations marked with the yellow icon. If you do not do so, full authorization is automatically given.

In the last step, a profile is generated from your entries. The system proposes a name T-, which you can change here, but not later on. Enter a meaningful name.
Next assign the relevant users to the activity group.

Once you have assigned the users, you must adjust the user master profiles accordingly. The profile that was created is automatically assigned to the given users.

A user can be assigned to more than one activity group. Each time you change an activity group, you must also adjust the user masters again.

SAP delivers more than one hundred preconfigured activity groups. Choose the one most suitable for the particular work center and assign the users. Adjust the user master records.

You can change activity groups delivered by SAP. However, these changes are lost during an upgrade. We therefore recommend that you copy the delivered activity groups and adjust the copy.

In the last section we introduced the user-specific appearance of the interface, which is implemented using activity groups. In addition, there are ways to set single transactions to the needs of your enterprise or of individual user groups. In this section we will see how a transaction can be simplified without being modified.
In this example you see two screens of an SAP transaction that should be redesigned using a transaction variant.

Screen 100 is changed as follows: Fields are hidden; field attributes are changed; buttons are hidden.
Screen 200 shows the following changes: buttons moved and screen inserted (with GuiXT). We will be discussing the use of GuiXT in more detail later.
A transaction variant is a reference to a set of screen variants.
You can create any number of screen variants for a screen. The transaction variant consists of these screen variants.

You can create different kinds of transaction variants for an SAP transaction:
a standard variant
any number of "normal" transaction variants

The standard variant is executed at runtime instead of the SAP delivered transaction. No new transaction code is required.

A normal transaction variant will be called with its own transaction code of type "variant transaction".

To create transaction variants, choose the component Personalization from the entry Accelerated SAP in the SAP menu and then Transaction variant. You go to the transaction for maintaining transaction variants.

Enter the name of the transaction from which you want to create a variant. The name of the variant must be unique in the system and be in the customer namespace.

With the menu option Goto, choose whether you want to create a client-specific or a cross-client transaction variant.

To create the variant; choose the appropriate button in the application toolbar.

Pressing "Screen entries" starts the transaction in CALL mode.
Triggering a dialog also triggers PAI of the current screen. The system sends another screen in which you can evaluate the fields of the screen.
Also read the online documentation about transaction variants.
The screen that was evaluated is stored as a screen variant when you continue. This will be discussed next.

A screen variant is an independent Repository object, which has a unique name in the system. The name is constructed as follows:

Variant name
Client (only for client-specific transaction variants)
Screen number

Here you specify whether or not field contents should be copied to the screen variant. You can set various attributes for the individual fields: You can undo or hide the input status of a field. You can find a detailed list of options in the online documentation about transaction variants.

The GuiXT tool permits you to design the individual screens in a more flexible manner. GuiXT uses a script language to
Position objects on the screen,
Set attributes,
Include new objects.

If you press "GuiXT", an editor window appears where you can enter the script. You can also choose GuiXT files stored on your local machine.

You can also import scripts created on the local machine and export them there.
You can change the layout of a screen with the script language used by GuiXT. You can

Move objects
Insert screens
Insert pushbuttons
Insert value helps
Change the input attributes of fields
Delete screen elements

You are provided with a complete documentation of GuiXT with the installation.

You have the following options for starting a transaction variant:

Test environment
Transaction code of type "variant transaction"
User menu

You can test the transaction flow in the test environment of the transaction variant maintenance routine. This is intended primarily for developers creating transaction variants.

To insert a variant transaction in a user menu or activity group, you must create a transaction code of type "variant transaction".

To start a transaction variant from a menu, you must create a transaction code of type "variant transaction". You can navigate there directly from the maintenance screen for the transaction variants. Alternatively you can start the corresponding transaction from the ABAP Workbench.

You can insert the transaction in a menu by choosing one of the following two options: maintenance of

Activity group or
Area menu.

The user can immediately see the changes made in this way.


RELATED POSTS