USER EXITS IN DETAIL

In computer software, a user exit is a place in a software program where a customer can arrange for their own tailor-made program to be called.

In the R/3 system from SAP, a user exit is contrasted with a customer exit and allows a customer's developer to access program components and data objects within the R/3 system. In R/3, some user exits use Include statements to include customer program enhancements that are called from the program.

Other user exits use tables that are accessed through customization.

Overview

Extension of SAP functionality

SAP makes different possibilities available to extend SAP functionality in the R/3 without modifying the delivered R/3-Standard. Thus these extensions are further present also after a R/3-Release-Wechsel.

• User exit
• Field exit
• Text extensions
• Customer exit
• Table extensions

1. User exit

User exits are original one in the selling module (SD) developed expandability.
They consist of empty subroutines (FORM) in special Includes, which can be filled by a ABAP Use developer.

In special places in the SA P-CODE such subroutine references were inserted by SAP. An extension is thus only possible, where SAP planned it.

They usually offer a rather rudimentary expandability, since purely technically objects in the SAP name area are modified.


2. Field exit

Field exits are bypasses of a Dynprofield with data element purchase into a functional module. These will go through when leaving the Dynpros. There are global and local field exits.

Global field exits

are not limited to a Dynpro. If a data element is used on several Dynpros, after activation of the field exit with all this Dynpros to a functional module one branches out.

Local one field exit

work only on a Dynpro limited. There is the possibility of putting on bus to 36 local field exits to a data element.
3. Text extensions
With text extensions it acts around user keywords and user documentation (F1-Hilfe) to data elements. The new keywords can refer to SAP documentation and to user documentation. Thus one has also the possibility of overwriting the keywords delivered by SAP.
With text extensions the changes are global effective for all SAP applications concerned contrary to application extensions after activation.
4. Customer exit
An application function can be extended by application extensions by the customer. Customer exits must be intended by SAP. They consist generally of several components. The interface SAP/Kunde is clearly defined.
With a R/3-Release-Wechsel and/or. Upgrade remain the customer extensions without effort.

• Function exit
• Menu exit
• Dynpro exit

A) Function exit
By functional module exits the customer can implement additional logic in an application function.
SAP built such exits in different places into many application functions. Thus are the interfaces are already given, and/or which data handed over.
These functional modules can be filled now by the customer. It can insert also user Dynpros with associated processing logic and GUI surface and put on user text elements.

B) Menu exit

Menu exits make it for the customer possible to build and occupy with a function code in an SAP application new menu entries.
SAP determined, where in the program additional function codes are queried and like to it is being reacted, either by a functional module exit or by an already firmly given functionality.

C) Dynpro exit

Dynpro exits permit the customer to arrange ranges of a dynpros reserved by SAP. Within these ranges large information can be indicated or data be seized. Those for this force fields by the customer on a user Dynpro are arranged.



In Details

What is User Exits?

The following document is about exits in SAP: -
The R/3 enhancement concept allows you to add your own functionality to SAP’s standard business applications without having to modify the original applications.
SAP creates user exits for specific programs, screens, and menus within standard R/3 applications.
These exits do not contain any functionality. Instead, the customer exits act as hooks. You can hang your own add-on functionality onto these hooks.

Types of Exits

There are several different types of user exits. Each of these exits acts as hooks where you can attach or "hang" your own add-ons.

Menu Exits

Menu exits add items to the pulldown menus in standard SAP applications. You can use these menu items to call up your own screens or to trigger entire add-on applications.
SAP creates menu exits by defining special menu items in the Menu Painter. These special entries have function codes that begin with "+" (a plus sign). You specify the menu item’s text when activating the item in an add-on project.

Screen Exits

Screen exits add fields to screens in R/3 applications. SAP creates screen exits by placing special subscreen areas on a standard R/3 screen and calling a customer subscreen from the standard screen’s flow logic.

Function Module Exits

Function module exits add functions to R/3 applications. Function module exits play a role in both menu and screen exits.
When you add a new menu item to a standard pull down menu, you use a function module exit to define the actions that should take place once your menu is activated.
Function module exits also control the data flow between standard programs and screen exit fields.

SAP application developers create function module exits by writing calls to customer functions into the source code of standard R/3 programs.
These calls have the following syntax:

CALL CUSTOMER-FUNCTION ‘001’.

Field Exits

Field exits allow you to create your own programming logic for any data element in the Dictionary. You can use this logic to carry out checks, conversions, or business-related processing for any screen field. Example: The data element BBBNR identifies a company’s international location number. You might want to set up your R/3 System so that all international location numbers are larger than 100.
The field exit concept lets you create a special function module that contains this logic.
You assign the special function module to the data element BBBNR. You then assign the module to any programs and screens in which users can add new international location numbers. When you activate your field exit, the system automatically triggers your special routine whenever a user enters a company location number.
In 4.6c, you can use "RSMODPRF" program to create field exits.
An example of a user exits :-
MODULE user_exit_0001 INPUT
CASE okcode.
WHEN 'BACK OR EXIT'.
CASE sy-dynnr.
WHEN '100'.
SET SCREEN 0.
LEAVE SCREEN.
WHEN '200'.
******************************************************************************
**** Note that you can write any code that satisfy your needs. ****
**** But in this case, this was wrote as a sample code for reference sake. ****
**** And you can test it. ****
******************************************************************************
SET SCREEN 100.
LEAVE SCREEN.
ENDCASE.
ENDCASE.


SAP User Exits Routine

User exits are routine which SAP allows you to add in additional customized programs process without affecting the standard SAP programs.
SAP user exit are usually declare as a form routine :-
form userexit_xxxxx
........................
endform
In VL01 - Create Delivery Order, standard program SAPMV50A, the standard program did not check for storage location equal to space, and delivery quantity less than one when the user click the save button. Therefore I have to insert the additional checking into the userexit routine.

Steps:-

• Goto transaction VL01 to pick a Sales Order for delivery (you don't have to save the data)
• In the initial screen, click System -> Status -> Double click on Program (Screen)
• In the dialog program SAPMV50A, click Edit -> Search/replace
• Type userexit in the Find field, then click the In program radio button and hit Enter
• A number of userexit routines will be displayed. You'll have to roughly decide which is the correct userexit routine to used.
Another way of determining the list of user exits could be bus executing the Tcode SE80.
For example if U need to search for the user exits for the above mentioned program, execute the Tcode SE80 and enter the above program name,

The highlighted row denotes a user exit, which is used in this program
form userexit_save_document_prepare.
case xlips-pstyv.
when 'TAX' or 'REX'.
* Accept this two Delivery item category
when 'REN'.
if xlips-lgort = space.
* Reject this Delivery item category
message e001.
endif.
when others.
if xlips-matnr <> space.
* Check storage location not space
if xlips-lgort = space.
message e002.
endif.
* Check delivery quantity not zero
if xlips-pikmg < pgmid =" 'R3TR'" object =" 'PROG'" obj_name =" tstc-pgmna." name =" tstc-pgmna." pname =" tstc-pgmna." funcname =" tfdir-funcname." pgmid =" 'R3TR'" object =" 'FUGR'" pgmid =" 'R3TR'" object =" 'SMOD'" devclass =" v_devclass." sprsl =" sy-langu" name =" jtab-obj_name." zzzz =" up">Bus.transactions->Base parameters->Validation
/NORFB->Bus.transactions->Base parameters->Substitution
Example
=ULTE "FI_DOCU 001 "Parked SA,FY,SI=>long text CORRESP. "

=U&VALID_WBS_IN_ZUONR "FI_ITEM 011 Spon.Res: Check WBS valid in ZUONR"

* changed in 4.5B (* Form UFIA -- formerly U&VALID_WBS_IN_ZUONR)
User exits are form routines that the user programs. There are two types of

user-exits:

1. Validation exits are used in the prerequisites and checks. They have either the value 'T' for true or 'F' for false. They are interpreted as a part of the logical statement, like a constant or field comparison. For this type of user exit, you must fill a parameter with the results of your check ('T' for true; 'F' for false).
Example
FORM Uzzzz USING B_RESULT. "'T' or 'F'
from program ZGGBR000 (ZGGBRI03)
2. Substitution exits are used to change one or more fields. However, you can only change those fields that are permitted in the Boolean class for the substitution. You can display these fields by selecting the following menu options in substitution maintenance: Fields for substitutions>
Example
FORM Uzzzz USING COST_CENTER.
from program ZGGBS000 (ZGGBSI02)
Substitution Fields can be found from this window

/NORFB->Bus.transactions->Base parameters->Substitution->Call Pnt 2->Substitution step 3->Extras->Substitution flds
The name of the form pool (e.g., ZGGBR000 & ZGGBS000) that contains your user exit must be stored in table T80D.
Note
1. Data declaration
Tables and field stings cannot be declared in form routines, so that the contents can be used along with the calling transaction.
2. Parameter definition
It is important that you make declare the code generation program for your user exit; how many and what type of parameters you are using for the user exit. You do this by entering your newly defined user exits in the form routine GET_EXIT_TITLES.
found in program ZGGBR000 (ZGGBRTIT)
found in program ZGGBS000 (ZGGBSTIT)
One exception is the parameter for the results of a validation exit. You must not declare this, it is automatically generated be the system. What types of parameters are available and how you use them is described in the online documentation. When creating your user exits, you can use the example form pools delivered by SAP (RGGBR000 for validations; RGBBS000 for substitutions) as a reference. We recommend that you copy the example form pools delivered by SAP when creating your own user exits. In these example form pools, entries already exist in the form routine GET_EXIT_TITLES for the examples delivered. The GET_EXIT_TITLES must absolutely exist in your form pool.
You can find additional information on the creation of user exits in the online documentation on validations and substitutions.
SAP exits
SAP exits are form rountines programmed by SAP. The name of the form pool is SAPFGBEB.
Syntax:
=Szzzz (zzzz = up to four characters)
FORM Szzzz using B_result. "'T' or 'F'
Example
=S01 "SAP exit S01"
Display description of T80D configuration
Return ->
Change Validation: FI_ITEM (Message view)

RELATED POSTS

MODIFICAITONS EXITEDED 57

MODIFICAITONS EXITEDED:


Modifications can be categorized as 'critical' if:

They affect numerous other Repository objects (such as Dictionary objects or function modules) Modification adjustment is either difficult (as with menus, pushbuttons, and GUI interfaces up to 4.5A) or not supported by a tool (transaction codes, message classes, logical databases)

Without the Modification Assistant (prior to Release 4.5A), both modifying GUI statuses and GUI titles, as well as assigning customer function modules to SAP function groups, should be considered 'critical' activities.

SAP only changes the following Repository objects in an upwardly compatible manner. They should therefore be considered 'uncritical' by customers who want to call them:
Function modules that have been released
BAPIs
Includes for user exits
Screen, program, menu, and field exits
After an upgrade, you must test customer reports that call SAP objects, as well as all objects displayed in the upgrade utility SPAU. This is also true for Repository objects that have been automatically adjusted using the Modifications Assistant (from Release 4.5A).
You must be familiar with the processing logic of your application in order to be able to adjust programs properly.
Modification adjustment is not necessary if you avoid making changes to SAP objects.
Use program enhancements and appends with SAP tables to enhance SAP objects in such a way that your changes cannot be overwritten by SAP at upgrade.
From Release 3.0, you can use Online Correction Services to import and cancel Support packages and patches automatically (instead of having to insert preliminary corrections manually).

Modification has the advantage that your live Repository objects do not lose their connection to the SAP standard. Copying, on the other hand, has the advantage that no modification adjustment will be necessary for your live Repository objects during subsequent upgrades.

Choose copying instead of modifying if:

You have to make numerous changes to an SAP program
Your requirements will not be met by the standard in future R/3 releases
During copying, pay attention to a Repository object's environment as well. You should only decide whether to modify or copy after having informed yourself of the consequences for the main program, as well as for all of the includes attached to the main program. The same holds true for function groups and function modules.

ABAP development projects can be evaluated according to the following criteria:

What will implementation cost, measured in manpower (creating the concept, implementation, testing)?
How will the ABAP development project influence:
Production operation performance?
The amount of adjustment at upgrade?
By calling SAP objects in your own Repository object, you can drastically reduce the amount of effort needed to implement your object. However, any changes that SAP makes to the Repository object you choose to call may make extra adjustment necessary after an upgrade. For example, SAP could conceivably change the user interface of a screen for which you have written a batch input program.

Naming conventions allow you to avoid naming conflicts and give your Repository objects meaningful names (that can be understood by others).
The following naming conflicts can occur:
An SAP Repository object and a customer Re pository object conflict
SAP Repository objects and customer Repository objects should be separated from each other by strict adherence to SAP naming conventions. OSS note 16466 gives you an overview of the current naming conventions for customer Repository objects (usually names that begin with either Y or Z).

Two customer Repository objects conflict

Naming conflicts can also occur between customers Repository objects in decentralized
Development scenarios where more than one development system is being used. You can avoid naming conflicts in this area by reserving a special namespace for development areas within the customer namespace. The Workbench Organizer checks to make sure that you adhere to these conventions by making entries in view V_TRESN.

RELATED POSTS

SAP MODIDICAITONS 56

An object is original in only one system. In the case of objects delivered by SAP, the original system is at SAP itself. These objects are only copies in customer systems. This applies to your development system and all other systems that come after it.

If you write your own applications, the objects that you create are original in your development system. You assign your developments to a change request, which has the type
Development/Correction.

This request ensures that the objects are transported from the development system into the
subsequent systems.

Changes to an original are called corrections. They are recorded in a change request whose tasks have the type "Development/correction".

If, on the other hand, you change a copy (an object outside its own original system), the change is recorded in a task with the type "Repair". Repairs to SAP objects are called modifications.

When you repair your own objects (for example, if something goes wrong in your production system), you can correct the original in your development system straight away. When you change copies, you must correct the original immediately!

However, you cannot do this with SAP objects, because they are not original in any of your systems.

You should only modify the SAP standard if the modifications you want to make are absolutely necessary for optimizing workflow in your company. Be aware that good background knowledge of application structure and flow are important prerequisites for deciding what kind of modifications to make and how these modifications should be designed.

Whenever you upgrade your system, apply a support package, or import a transport request, conflicts can occur with modified objects.

Conflicts occur when you have changed an SAP object and SAP has also delivered a new version of it. The new object delivered by SAP becomes an active object in the Repository of your system.

If you want to save your changes, you must perform a modification adjustment for the objects. If you have a lot of modified SAP objects, your upgrade can be slowed down considerably.

To ensure consistency between your development system and subsequent systems, you should only perform modification adjustments in your development system. The objects from the adjustment can then be transported into other systems.

A registered developer must register registers changes to SAP objects. Exceptions to this registration are match codes, database indexes, buffer settings, customer objects, patches, and objects whose changes are based on automatic generation (for example , in Customizing). If the object is changed again at a later time, no new query is made for the registration key. Once an object is registered, the related key is stored locally and automatically copied for later changes, regardless of which registered developer is making the change. For the time being, these keys remain valid even after a release upgrade.

How do you benefit from SSCR (SAP Software Change Registration)?

Quick error resolution and high availability of modified systems
All objects that have been changed are logged by SAP. Based on this information, SAP's First Level Customer Service can quickly locate and fix problems. This increases the availability of your R/3 system.

Dependable operation
Having to register your modifications helps prevent unintended modification. This in turn ensures that your R/3 software runs more reliably.

Simplification of upgrades
Upgrades and release upgrades become considerably easier due to the smaller number of
modifications.

If you want to change an SAP Repository object, you must provide the Workbench Organizer with the following information:

SSCR key
Change Request

We saw above how you get an SSCR key. If you now continue to change the object, you must confirm the following warning dialogs: At this point, you can still cancel the action without repairing the object.

The Workbench Organizer asks you to enter a change request, as it would for your own objects. The object is automatically added to a repair task. The change request has the following functions:

Change lock
After the task has been assigned, only its owner can change the object.

Import lock
The object cannot be overwritten by an import (upgrade or support package).

Versions
The system generates a new version of the object (see below).

After development is finished, the programmer releases the task. At this point, the programmer must document the changes made. The objects and object locks valid in the task are transferred to the change request. If the developer confirms the repair, the import lock passes to the change request. If the developer does not confirm the repair when releasing the task, the import lock remains in place.
Only the developer can release this lock.

Once the project is completed, you release the change request. This removes all of the change request's object locks. This applies both to the change locks and the import locks.

When the change request is released, the objects are copied from the R/3 database and stored in a directory at operating system level. They can then be imported into subsequent systems by the system administrator.

After the modifications have been imported into the quality system, the developer must test them and check the import log of the request.

When you release a change request, a complete version of all objects contained in the change request is written to the versions database.

If you transport the Repository object again later, the current object becomes a Complete copy and the differences between the old and the new object are stored in the versions database as a backwards delta.

Whenever you assign a Repository object to a task, the system checks whether the current version agrees with the complete copy in the versions database. If not, a complete copy is created. This process is also initiated the first time you change an object, since SAP does not deliver versions of Repository objects.

The versions of a Repository object provide the basis for modification adjustment. To support adjustment, information on whether the version was created by SAP or by the customer is also stored.

Encapsulate customer source code in modularization units instead of inserting it directly into SAP source code (with, for example, customer function module calls in program source code, or customer sunscreen calls for additional screen fields).

When encapsulating the customer portions of a program, be sure to use narrow interfaces.

You should define a standard for all of your company's modification documentation (see the following slides).

You should also maintain a list of all modifications to your system (a modification log - see the following slides).

All requests that contain repairs must be released before an upgrade so that all relevant customer versions can be written to the versions database (the system compares versions during adjustment).

Repairs must also be confirmed prior to upgrade, otherwise the object being repaired is locked and cannot be imported.

Any modifications that you make to ABAP Dictionary objects that belong to Basis components are lost at upgrade--- these objects revert to their earlier form and no adjustment help is offered. This can lead to the contents of certain tables being lost.

The aim of the Modification Assistant is to make modification adjustments easier. In the past, the granularity of modifications was only at including program level. Today, a finer granularity is available. Now, modifications can be recorded at subroutine or module level.

This is because (among other reasons) the modifications are registered in a different layer. As well as providing finer granularity, this means that you can reset modifications, since the original version is not changed.

If, in the past, you modified an include for which SAP provided a new version in an upgrade, a modification adjustment was necessary. The modification adjustment had to be performed line by line. The system provided little support.

The Modification Assistant has changed this situation considerably. Modifications are now recorded with finer granularity. For example, if you modify a subroutine, the rest of the include remains unchanged. If SAP delivers a new version of the include, the system looks to see if there is also a new version of that subroutine. If this is not the case, your changes can be incorporated into the new version automatically.

The original version of each software layer comprises the originals from the previous layer plus current modifications.
Above is a list of the tools supported by the Modification Assistant.

n the ABAP Editor, you can use modification mode to change source code. Only a restricted range of functions is available in this mode. You can add, replace, or comment out source code, all under the control of the Modification Assistant.

Changes to layout and flow logic in the Screen Painter are also recorded.

The Modification Assistant also records changes in the Menu Painter and to text elements, as well as the addition of new function modules to an existing function group.

To avoid conflicts in the upgrade, table appends are also logged by the Modification Assistant.

If you want to change an SAP object, you must provide the following information:

SSCR key

Change request
The system informs you that the object is under the control of the Modification Assistant. Only restricted functions are available in the editor.

You can switch the Modification Assistant on or off for the entire system changing the R/3 profile parameter eu/controlled_modification. SAP recommends that you always work with the Modification Assistant.

You can switch off the Modification Assistant for single Repository Objects. Once you have done so, the system no longer uses the fine granularity of the Modification Assistant.

In modification mode, you have access to a subset of the normal editor tools. You can access these using the appropriate pushbuttons. For example, in the ABAP Editor, you can:
Insert

The system generates a framework of comment lines between which you can enter your source code.

Replace
Position the cursor on a line and choose Replace. The corresponding line is commented out, and another line appears in which you can enter coding. If you want to replace several lines, mark them as a block first.

Delete
Select a line or a block and choose Delete . The lines are commented out.

Undo modifications
This undoes all of the modifications you have made to this object.

Display modification overview
Choose this function to display an overview of all modifications belonging to this object.

The graphic shows the result of changes made with Modification Assistant.

The Modification Assistant automatically generates a framework of comment lines describing the action. The comment also contains the number of the change request to which the change is assigned, and a number used for internal administration.

The "modification overview" icon provides you with an overview of the modifications you have made in the current program.

The display is divided up according to the various modularization units. This corresponds to the structure used by the Modification Assistant to record the modifications.

You can reset all of the modifications that you have made to the current object using the
Modification Assistant by choosing this function. The record of the modifications is also deleted.

Remember that you cannot selectively undo modifications to an object. You can only undo modifications based on the "all or nothing" principle.

The Modification Browser provides an overview of all of the modified objects in the system. The Modification Browser differentiates between modifications made with the Modification Browser and those made without.

On the initial screen of the Modification Browser, you can restrict the selection according to various criteria. This allows you to find modifications in a particular area.

The Modification Assistant displays the hit list in tree form. Objects are arranged by:

Modification type (with/without the Assistant)

Object type (PROG, DOMA, DTEL, TABL,)

SAP recommends that you use Modification Assistant to make changes to R/3 objects. Changes without the use of the Modification Assistant should be avoided. However, should this be necessary, you should document your modifications in the source code as follows?

Preliminary corrections SAP note, repair number, changed by, changed on, valid until

Customer functions that have been inserted subject area, repair number, changed by, changed on, INSERTION

Customer functions that have replaced SAP functions subject area, repair number, changed by, changed on, REPLACEMENT The SAP functions that you do not need should not be deleted, but commented out instead

Subject areas are specified in the relevant process design blueprint (for example, subject area SD_001 = pricing).

SAP recommends that you keep a record of all modifications that have been made to your system (that is, of any changes you have made to Repository objects in the SAP namespace).

The following information should be logged for each modification:

Object type (program, screen, GUI status,)

Object name

Routine (if applicable)

Subject area (according to process design blueprint or technical design)

Repair number
Changed on
Changed by
Preliminary correction? (Yes/no)
OSS note number, valid until Release x.y
Amount of time necessary to recreate modification during adjustment (measured in hours).
A module pool is organized as a collection of include programs. This is particularly useful for making the program easier to understand. The organization is similar to that of function groups. In particular, the naming convention, by which the last three letters of the name of the include program identify its contents, is identical.

The main program, as a rule, contains the include statements for all of the include programs that belong to the module pool.
The includes described as "special" includes in the program are themselves only include programs - technically, they are not different. These programs are only delivered once.
User exits are a type of system enhancement that were originally developed for the R/3 Sales and Distribution Module (SD). The original purpose of user exits was to allow the user to avoid modification adjustment.

A user exit is considered a modification, since technically objects in the SAP namespace are being modified.

The SAP developer creates a special include in a module pool. These includes contain one or more subroutines routines that satisfy the naming convention userexit_. The calls for these subroutines have already been implemented in the R/3 program. Usually global variables are used.

After delivering them, SAP never alters includes created in this manner; if new user exits must be delivered in a new release, they are placed in a new include program.
User exits are actually empty subroutines that SAP developers provide for you. You can fill them with your own source code.
The purpose behind this type of system is to keep all changes well away from program source code and store them in include programs instead. To this end, SAP developers create various includes that fulfill the naming conventions for programs and function groups. The last two letters in the name of the include refer to the include that the customer should use: "Z" is usually found here.
Example: Program SAPM45A
Include M45AFZB

This naming convention guarantees that SAP developers will not touch this include in the future. For this reason, includes of this nature are not adjusted during modification upgrade.
The subroutine call is already implemented in the programt. The interface is already defined. Normally, subroutines of this type only work with global data.
If any new user exits are delivered by SAP with a new release, then they are bundled into new includes that adhere to the same naming convention.

You can find a list of all user exits in the SAP Reference Implementation Guide.
There, you will also find documentation explaining why SAP developers have created a particular user exit.
Follow the steps described in the Implementation Guide.

The set of objects for adjustment is derived from the set of new objects delivered by SAP in a new release. This is compared with the set of objects you have modified on your R/3 system.

The intersection of these two sets is the set of objects that must be adjusted when you import an upgrade or support package.

During modification adjustment, old and new versions of ABAP Repository objects are compared using transactions SPDD and SPAU.

You do not have to call transaction SPDD to adjust Dictionary objects if:
No changes have been made to SAP standard objects in the Dictionary
You have only added customer objects to your system. Only SAP objects that have been
Changed must be adjusted using this transaction.

All other ABAP Repository objects are adjusted using transaction SPAU. Upgrade program R3up tells you to start the transaction after upgrade has finished. You have 30 days to use transaction SPAU after an upgrade. After 30 days, you must apply for a SSCR key for each object that you want to adjust.

Transaction SPAU first determines which objects have been modified. Then it determines which of these objects have a new version in the current upgrade. Modification adjustment allows you to transfer the modifications you have made in your system to your new R/3 Release.

Use transaction SPDD to adjust the following ABAP Dictionary objects during the modification adjustment process:

Domains
Data elements
Tables (structures, transparent tables, pool, and cluster table, together with their technical settings)
These three object types are adjusted directly after the Dictionary object import (before the main import). At this point in time, no ABAP Dictionary objects have yet been generated. To ensure that no data is lost, it is important that any customer modifications to domains, data elements, or tables are undertaken prior their generation.

hanges to other ABAP Dictionary objects, such as lock objects, match codes, or views, cannot result in loss of data. Therefore, these ABAP Dictionary objects are adjusted using transaction SPAU after both main import and object generation have been completed. You can use transaction SPAU to adjust the following object types:

ABAP programs, interfaces (menus), screens, match code objects, views, and lock objects.

During modification adjustment, you should use two different change requests to implement the changes you have made: one for SPDD adjustments and another for SPAU adjustments. These change requests are then transported into other R/3 systems you want to adjust. This guarantees that all actual adjustment work takes place solely in your development system.

When upgrading additional R/3 systems, all adjustments exported from the first system upgrade are displayed during the ADJUSTCHK phase. You decide which adjustments you want to accept into your additional systems and these are then integrated into the current upgrade. Afterwards, the system checks to see if all modifications in the current R/3 system are covered by the change requests created during the first system upgrade. If this is the case, no adjustments are made during the current upgrade.

Note: For this process to be effective, it is important that all systems involved have identical system landscapes. This can be guaranteed by first making modifications in your development system and then transporting them to later systems before you upgrade the development system. You can also guarantee that all of your systems have an identical system landscape by creating your development system before upgrade as a copy of your production system and then refraining from modifying the production system again until after upgrade.

Version compare is also used during or after an upgrade for modification adjustment.

During modification adjustment, version compare determines the number of SAP objects that you a) changed in the system and that b) were then overwritten by SAP at upgrade.

Version compare allows you to find where changes were made and transfer them to your new SAP version if you want.

The icons in front of the individual objects that need adjustment show how they can be adjusted.
The possible methods are:

Automatically
The system could not find any conflicts. The changes can be adopted automatically

Semi-automatically
The individual tools support you in adjusting the objects.

Manually
You must process your modifications with no special support from the system. In this case, the modification adjustment does allow you to jump directly into the relevant tool.
Adjusted objects are identified by a green tick.
If you want to use the new SAP standard version, use Restore original. If you do this, you will have no further adjustment work in future.

RELATED POSTS

ENHANCEMENTS USING COSTMER EXITS 54

ENHANCEMENTS USING COSTMER EXITS



Application enhancements allow customers to enhance their application functions. Customer exits are preplanned by SAP and generally consist of several components.

Application enhancements are inactive when delivered and can be completed and activated by customers as they are needed.

Application enhancement characteristics:

Each enhancement provides you with a set of preplanned, precisely defined functions.

Each interface between SAP and customer functions is clearly defined.

As a customer, you do not need in-depth knowledge of how to implement SAP applications.

You do not need to adjust enhancements at upgrade because of new functions that SAP has developed.

The SAP application programmer creates SAP enhancements from function module exits, menu exits and screen exits. A management function is provided for this purpose (transaction code SMOD).

Customers are given a catalog containing an overview of existing SAP enhancements. They can then combine the SAP enhancements they want into an enhancement project using transaction CMOD.

SAP enhancements are made up of component parts. These components include function module exits, menu exits, and screen exits. A specific component may be used only once in a single SAP enhancement (this guarantees the uniqueness of SAP enhancements).

Customer enhancement projects consist of SAP enhancements. Each individual SAP enhancement may be used only once in a single customer enhancement program (this guarantees the uniqueness of a customer project).

The SAP application programmer plans possible application enhancements in an application and defines the necessary components. These components are combined in SAP enhancements.

The programmers document their enhancements as best they can, so that customers can implement the enhancements without having to analyze program source code or screen source code.

First, create an enhancement project and then choose the SAP enhancements that you want to use.

Next, edit your individual components using the project management function and document the entire enhancement project.

Finally, activate the enhancement project. This activates all of the project's component parts.

Transaction CMOD starts the project management function. You must give your enhancement project a name. SAP recommends that you think up a naming convention for all of your projects.

You can, for example, include the project's transaction or module pool in its name. All enhancement project names must be unique.

Next, go to the project's attributes and enter a short text describing the enhancement project. The system inserts the entire project's other attributes (such as created by, created on, or status).

Use the project management function to assign SAP enhancements to customer enhancement projects. Enter the names of the SAP enhancements you want to use on the appropriate screen.

The search function gives you a catalog-like overview of existing SAP enhancements. From there you can select those enhancements that are of interest to you.

Use the product management function to edit the components of your enhancement project.

Depending on whether the component you are editing is a function module, a menu entry, or a SUB SCREEN, you branch to either the Function Builder, a dialog box for entering menu entries, or to the Screen Painter.

Activation of an enhancement project affects all of its components. After it has been activated successfully, the project has the status active.

During activation, all programs, screens, and menus containing components that belong to the project are regenerated (programs at the time they are executed). After activation, you can see the effect of the enhancements in your application functions.

The Deactivate function allows you to reset an active enhancement project's status to inactive.

When the enhancement project was created; you should have assigned it to a change request. Each of the component pieces (include programs, SUB Screens, menu exits, and so on) should be assigned to the same change request. Using the same change request allows you to transport the entire enhancement at the same time.

Function module exits allow customers to implement additional logic in application functions. SAP application programmers define where function module exits are inserted and what kind of data they transfer. SAP programmers also create an exit's corresponding function modules complete with short text, interface, and documentation, as well as describing each function module exit's intended purpose in the SAP documentation.

You write the source code for the function modules yourself. If need be, you can also create your own screens, text elements, and includes for the function group.

The system processes your ABAP code when the enhancement project (of which your function module is a component) is activated. Function module exits have no effect prior to enhancement project activation.

This graphic shows the flow of a program providing an enhancement in the form of a function module exit.

The exit function module is called in the PAI logic of a screen at a position determined by the SAP application developer. Within the function module, the user can add functions in the customer namespace using an include.

SAP application programmers use the ABAP statement CALL CUSTOMER-FUNCTION 'nnn' to call function modules, where nnn is a three-digit number. (Where 'nnn' is a three-digit number). The application programmer must also create the function module he wants to call and its related function group.

These function modules belong to function groups whose names begin with X (X function groups).

The following naming convention applies to these function modules:
Prefix: EXIT
Name: name of the program that calls the function module
Suffix: three-digit number
The three parts of the name are separated by two underscores.

The CALL CUSTOMER-FUNCTION statement is only executed if the enhancement project has been activated. Multiple calls of the same function module are all activated at the same time.

The most frequently asked question concerning enhancements is: how can you see if an application program offers a function module exit? There are a number of ways to find the answer to this question.

To see quickly if an application program offers a function module exit, you can follow the path on the left-hand side of the graphic: (The menu path System Status always displays the name of the current application program). In our example a suitable character string would be "CALL CUSTOMER". Use the Find icon and search globally in the program. If your search does not provide any results, you can define a larger search area. Determine the environment for the corresponding program and look for the specific character string in the program environment.

The right side of the graphic shows you how to find the name of the required enhancement using search tools. You can restrict the search in the R/3 Repository Information System using different criteria: These are:

Development class (also try generic entries)

Technical name of the enhancement

Use the project management (transaction: CMOD) function to edit function modules for function module exits.

Use the button for editing components to go directly to the function module editor (display mode).

DO NOT change the function module itself. It is especially important that you do not alter the interface in any way. The function module, however, contains an INCLUDE statement for an include program that you have to create in the customer namespace.

Double-click on the include name beginning with ZX. This automatically takes you to the editor of the include program, where you can enter your code.

To understand how an X function group works, you need to understand how a normal function group works:

A function group consists of includes. The system assigns unique names to the includes for different objects. Some of the include names are simply proposals and some cannot be changed.

Global data is stored in the TOP include. This include is generated automatically when a function group is created.

Function modules are stored in includes with sequential numbering, and they in turn are all stored in an include ending with UXX.

You can freely choose the names of the includes for all other objects (subroutines, modules, events, etc.). However, we advise you to accept the proposed names.

Exit function groups created by SAP application programmers for enhancement exits contain include programs that begin with either 'LX' or 'ZX'. You can only edit includes beginning with a 'Z', since they are stored in the customer namespace.

No further function modules may be added to the function group.

The include program ZxaaaUnn contains the source code for the function modules of a function module exit.

SAP application programmers can declare global data in include program LXaaaTAP.

You can declare your global data in include ZXaaaTOP.

Include program LXaaaTOP also contains the FUNCTION-POOL statement, which may not e changed. Therefore, you must always include the message class in parentheses when outputting messages - for example, MESSAGE E500 (EU).

The INCLUDE statement for program ZXaaaUnn is in a FUNCTION - ENDFUNCTION block.
Because of this, neither events, nor subroutines (FORM), nor modules (MODULE) are allowed here.

They can, however, be created in separate includes, which is explained later. Data declarations made here with DATA are valid locally in this function module.

The SAP application programmer can also make a proposal for the source text. In this case, an INCLUDE LXaaFnn is created (where nn is the internal number for the function module in the include LXaaaUXX). Documentation is also provided within the SAP enhancement. You can copy the source code from this include into your own customer include program ZXaaaUnn using the project management transaction.

You can create your own text elements for the function group.
SAP applications programmers can supply you with default subroutines in include LXaaaF01.

There could be further includes containing specific sub-objects.

LX...F01 contains subroutines delivered by SAP.

LX...E01 contains the events belonging to the X function group.

LX...O01 contains PBO modules for screens to be delivered.

LX...I01 contains the corresponding PAI modules.

Subroutines, modules, and interactive events (AT…) are created as include programs and included enhancements using include program ZXaaaZZZ.

Additional includes must adhere to the following naming convention:

ZXaaaFnn for subroutines,

ZXaaaOnn for PBO modules,

ZXaaaInn for PAI modules,

ZXaaaEnn for events.

You can use CALL SCREEN to call your own screens. Create the related include programs for the PBO and PAI modules in include program ZXaaaZZZ.

Use forward navigation (select an object and then double -click on it) to create your own screens and modules.

Screens created in this manner are automatically given the name of the function module's main program (SAPLXaaa). The PBO modules for these screens can be found in include
ZXaaaO01, the PAI modules in include ZXaaaI01.

You can enhance SAP applications by adding your own processing logic at predefined points.

Such enhancements can include your own screens with their corresponding processing logic and graphical user interface, as well as text elements created by customers.

Menu exits allow you to attach your own functions to menu options in SAP menus. SAP application programmers reserve certain menu entries in your GUI interface for this. This allows you to define a text for the reserved menu entry and add your own logic, often in the form of a related function module exit. Once you activate menu exits, they become visible in the SAP menu. Whenever this menu option is chosen, the system processes either a function provided by SAP application programmers or your own function that you have implemented in a function module exit.

In order for you to be able to implement menu exits, SAP application programmers must equip the GUI interface with function codes that begin with a plus sign ('+').

These function codes are inactive at first and do not appear in the GUI until you have activated them. They do not appear on the screen.

Menu exits are edited with the project management transaction (CMOD).

The pushbutton for editing components calls a dialog box where you can enter short descriptions and choose a language for each additional menu entry.

You may not make any changes to the GUI interface.
SAP application programmers determine where a program reads additional function codes and how it reacts--- either with a function module exit or with a predefined function.

You can implement menu exits based on reserved function codes. The SA P application programmer defines the relevant function codes, assigns them to menus, and often provides a function module exit.

Menu exits and function module exits are both part of the same SAP enhancement.

No pushbuttons may be assigned to additional function codes.

You can, however, make changes to the various menu entries and activate their function codes.

Screen exits allow you to make use of reserved sections of a main screen (SUB SCREEN areas). You can either display additional information in these areas or input data. You define the necessary input and output fields on a customer screen (SUB SCREEN).

SUB SCREENs are rectangular areas on your screen that are reserved for displaying additional screens at runtime. Each SUB SCREEN area can be filled with a different screen (of type SUB SCREEN) at runtime.

The R/3 System determines which screen will be displayed in a SUB SCREEN area at PBO. The general syntax is as follows:
CALL SUB SCREEN INCLUDING .
For each SUB SCREEN, PAI and PBO events are processed just as if the SUB SCREEN were a normal screen.

The sequence of "CALL SUB SCREEN" statements in your main screen's flow logic directly determines in what order the flow logic of individual SUB SCREENs is processed.

Caution:
Function codes are only processed in the main screen's flow logic
You are not allowed enter a name for a SUB Screen’s command field
You are not allowed to define GUI statuses for SUB Screens
No value for next screen may be entered in a SUB Screen’s flow control

The SAP application programmer can reserve multiple SUB SCREEN areas for a screen.
The SUB SCREEN is called during flow control of the main screen with the CALL CUSTOMERSUB SCREEN statement. The name of the SUB SCREEN area must be defined without apostrophes. The function group to which the SUB SCREEN belongs is defined statically in apostrophes, but the screen number can be kept variable by using fields; it must always have four places.

Screen exit calls are inactive at first, and are skipped when a screen is processed.

Only after a corresponding SUB SCREEN has been created in an enhancement project, and this project has been activated, will the system process the screen exit.

You create SUB Screens in X function groups. Normally, these function groups also contain function module exits.

Whenever the statement CALL CUSTOMER-SUB SCREEN INCLUDING occurs at PBO in the flow control of a screen, a SUB SCREEN is included in the SUB SCREEN area defined by SAP application programmers. At this point, all modules called during the PBO event of the SUB SCREEN are also processed.

The PAI event of a SUB SCREEN is processed when the calling screen calls the SUB SCREEN during its PAI event using the statement CALL CUSTOMER-SUB SCREEN .

The global data of the calling program is not known to the X function group that contains your SUB SCREEN; SAP application programmers use function module exits to explicitly provide this data to SUB Screens.

In order to facilitate data transport, modules is called in the flow control of the calling program that contains function module exits for transferring data via interface parameters.

Function modules belonging to these kinds of function module exits can be found in the same function groups as their corresponding SUB Screens.

Data must be transported in the other direction as well, since global data from the X function group that contains your SUB SCREEN is not known to the calling program either. For this reason, SAP application programmers use function module exits to return any data to the calling program that was changed in the SUB SCREEN.

This is done by calling a module during the main screen's PAI event that contains a function module exit for returning customer data via interface parameters.

SUB Screens are edited with the project management transaction (CMOD).
The technical names of screen exits consist of the name of the calling program, a four-digit screen number, and the name of the SUB SCREEN area, followed by the name of the X function group's program and the number of the SUB SCREEN.

You must create the SUB SCREEN as well as the corresponding PBO and PAI modules. The SAP development environment supports creation with forward navigation.

Make sure that your SUB Screens are of screen type SUB SCREEN the first time you create them.

You are not allowed to change any of the interfaces in the X function group that the SUB SCREEN and the function module exits belong to, nor are you allowed to add any of your own function modules.

See also the restrictions listed on the slide entitled 'Calling SUB Screens'.

Screen exits allow you to determine the layout of certain portions of a screen yourself. You can use these areas to display additional information, or to collect and process data.

Screen exits must be predefined (planned) by an SAP application programmer. Use the statement CALL CUSTOMER-SUB SCREEN to integrate these preplanned SUB SCREEN areas into the flow control of the calling screen at PBO and PAI events.

As soon as you activate an enhancement project that contains a SUB SCREEN as a component, the calling screen is regenerated and the SUB SCREEN is displayed the next time the application function is called.


RELATED POSTS

ENHANCEMENTS TO DICTIONERY ELEMENTS 52

ENHANCEMENTS TO DICTIONERY ELEMENTS

Tables and structures can be expanded in one of two different ways:

Append structures allow you to enhance tables by adding fields to them that are not part of the standard. With append structures; customers can add their own fields to any table or structure they want.

Append structures are created for use with a specific table. However, a table can have multiple append structures assigned to it.

If it is known in advance that one of the tables or structures delivered by SAP needs to have customer-specific fields added to it, the SAP application developer includes these fields in the table using a Customizing include statement.

The same Customizing include can be used in multiple tables or structures. This ensures consistency in these tables and structures whenever the include is extended.

Nonexistent Customizing includes do not lead to errors.

Append structures 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. Whenever a table is activated, the system searches for all active append structures for that table and attach them to the table. If an append structure is created or changed and then activated, the table it is assigned to is also activated, and all of the changes made to the append structure take effect in the table as well.

You can use the fields in append structures in ABAP programs just as you would any other field in the table.

Note: If you copy a table that has an append structure attached to it, the fields in the append structure become normal fields in the target table.

You create append structures in the customer namespace. This protects them from being overwritten at upgrade or during release upgrade. New versions of standard tables are loaded during upgrades.

The fields contained in active append structures are then appended to the new standard tables when these new standard tables are activated for the first time.

From Release 3.0, the field sequence in the ABAP Dictionary can differ from the field sequence in the database. Therefore, no conversion of the database table is necessary when adding an append structure or inserting fields into an existing one. All necessary structure adjustment is taken care of automatically when you adjust the database catalog (ALTER TABLE). The table's definition is changed when it is activated in the ABAP Dictionary and the new field is appended to the database table.

Pay attention to the following points when using append structures:
You cannot create append structures for pool and cluster tables.
If a table contains a long field (either of data type LCHR or LRAW), then it is not possible to expand the table with an append structure. This is because long fields of this kind must always be the last field in their respective tables. No fields from an append structure may be added after them.

If you use an append structure to expand an SAP table, the field names in your append structure must be in the customer namespace, that is, they must begin with either YY or ZZ. This prevents naming conflicts from occurring with any new fields that SAP may insert in the future.

Some of the tables and structures delivered with the R/3 standard contain special include statements:

Customizing includes. These are often inserted in those standard tables that need to have customer specific fields added to them.

In contrast to append structures, Customizing includes can be inserted into more than one table. This provides for data consistency throughout the tables and structures affected whenever the include is altered.

Customizing include programs is part of the customer namespace: all of their names begin with 'CI_'. This naming convention guarantees that nonexistent Customizing includes do not lead to errors. No code for Customizing includes is delivered with the R/3 standard.

You create Customizing includes using special Customizing transactions. Some are already part of SAP enhancements and can be created by using project management (see the unit on 'Enhancements using Customer Exits').

The Customizing include field names must lie in the customer namespace just like field names in append structures. These names must all begin with either 'YY' or 'ZZ'.

When adding the fields of a Customizing include to your database, adhere to same rules you would with append structures.

Every time they define a data element, the SAP application programmers define keywords in different lengths and a short description for each data element.

You create field exits in Project management. Field exits are processed when the user leaves a screen that contains a field which refers to a data element containing a field exit.

SAP lets you create a field exit for every input-ready screen field that has been created with reference to the ABAP Dictionary. The additional program logic is stored in a function module and is executed at a specific point in the PAI logic.

The slide shows the order in which processing takes place. Before the PAI logic of the screen is executed, the system performs the following checks: First the system checks if all the required fields have been filled in. If a required field is empty, the screen is shown again.

The system then checks that data has been entered in the correct format.

Any defined field exits are executed next. For example, by sending an error message you can have the screen sent again.

Once all the field exits have been checked, the screen is processed as normal.

Field transport
Foreign key check
Processing the PAI module

Field exits take you from a screen field with a data element reference to a function module. Field exits can be either global or local:

Global field exits are not limited to a particular screen: If a global exit's data element is used on several screens, the system goes to the function module for all these screens after activating the field exit. Here you can, for example, edit the contents, force a new entry to be made by outputting an error message, or prohibit certain users from proceeding further.

Local field exits are valid for one screen only. If you assign a screen from a specific program to a field exit, then the system will go to the appropriate function module from this screen once the exit has been activated.

You can either create a global field exit or up to 36 local field exits for a data element, but not both.

Each exit number refers to a different function module. Field exit function modules adhere to the following naming convention:

Prefix: FIELD_EXIT_
Name:
Suffix (for local field exit): _0 to _9, _A to _Z
To create field exits; choose Utilities in the ABAP Workbench. Choose Enhancements and then Project management to edit field exits and to implement customer exits. Do not create field exits directly from the Function Builder.

Choose Goto -> Global enhancements -> Field exits to start the transaction for maintaining field exits. To create a new enhancement, use the menu path Text Enhancements -> Create.

Enter the name of the data element to which your screen field refers in the modal dialog box. The Function Builder is started with a special naming convention and interface options. The system specifies the name of the field exit. Do not change this name. Create the function module in a customer function group.

The function module must be assigned to an existing customer function group.

The function module interface is fixed and cannot be changed. The function module has an import parameter INPUT and export parameter OUTPUT. The contents of the screen field are stored in parameter INPUT. The contents of OUTPUT are returned in the screen field when you leave the function module.

Field exits are not transported automatically. Therefore, you must assign the value of INPUT to OUTPUT in your source code. Otherwise the screen field would be blank after executing the field exit.
The following ABAP statements are not allowed in field exit function modules:
CALL SCREEN, CALL DIALOG, CALL TRANSACTION, SUBMIT
COMMIT WORK, ROLLBACK WORK
COMMUNICATION RECEIVE
EXIT FROM STEP-LOOP
MESSAGE I, MESSAGE W
STOP, REJECT

When you debug a screen that is referenced by a field exit, the field exit code is ignored by the debugger. As with any normal function module, you can, however, debug the field exit code in the Function Builder's test environment.

You can create local field exits that relate to a specific screen. A global field exit must already exist.
Edit the local field exit based on the global field exit.

You can create up to 36 local field exits, each of which carries a unique suffix. The system proposes a name for the function module; you should use this name.

Defining local field exits means that the function module of the global field exits initially created is no longer used. However, you must not delete it, for technical reasons. The field exits in the system would be deleted if you deleted the global function module of the field exit from the list.

You must activate the field exit as well as the function module. Also note that field exits are only taken into account during screen execution if the R/3 profile parameter abap/field exit = YES has been set for all application servers. (This profile parameter is set to 'NO' by default).

If you declare field exits for multiple screen fields, you have no control over the order in which they are processed. In particular, you cannot access the contents of other screen fields in a field exit.


RELATED POSTS

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

MODIFICATIONS OF SAP STANDARD OBJECTS

MODIFICATIONS:

An object is original in only one system. In the case of objects delivered by SAP, the original system is at SAP itself. These objects are only copies in customer systems. This applies to your development system and all other systems that come after it.

If you write your own applications, the objects that you create are original in your development system. You assign your developments to a change request, which has the type
Development/Correction.

This request ensures that the objects are transported from the development system into the
subsequent systems.

Changes to an original are called corrections. They are recorded in a change request whose tasks have the type "Development/correction".

If, on the other hand, you change a copy (an object outside its own original system), the change is recorded in a task with the type "Repair". Repairs to SAP objects are called modifications.

When you repair your own objects (for example, if something goes wrong in your production system), you can correct the original in your development system straight away. When you change copies, you must correct the original immediately!

However, you cannot do this with SAP objects, because they are not original in any of your systems.

You should only modify the SAP standard if the modifications you want to make are absolutely necessary for optimizing workflow in your company. Be aware that good background knowledge of application structure and flow are important prerequisites for deciding what kind of modifications to make and how these modifications should be designed.

Whenever you upgrade your system, apply a support package, or import a transport request, conflicts can occur with modified objects.

Conflicts occur when you have changed an SAP object and SAP has also delivered a new version of it. The new object delivered by SAP becomes an active object in the Repository of your system.

If you want to save your changes, you must perform a modification adjustment for the objects. If you have a lot of modified SAP objects, your upgrade can be slowed down considerably.

To ensure consistency between your development system and subsequent systems, you should only perform modification adjustments in your development system. The objects from the adjustment can then be transported into other systems.

A registered developer must register registers changes to SAP objects. Exceptions to this registration are match codes, database indexes, buffer settings, customer objects, patches, and objects whose changes are based on automatic generation (for example , in Customizing). If the object is changed again at a later time, no new query is made for the registration key. Once an object is registered, the related key is stored locally and automatically copied for later changes, regardless of which registered developer is making the change. For the time being, these keys remain valid even after a release upgrade.

How do you benefit from SSCR (SAP Software Change Registration)?

Quick error resolution and high availability of modified systems
All objects that have been changed are logged by SAP. Based on this information, SAP's First Level Customer Service can quickly locate and fix problems. This increases the availability of your R/3 system.

Dependable operation
Having to register your modifications helps prevent unintended modification. This in turn ensures that your R/3 software runs more reliably.

Simplification of upgrades
Upgrades and release upgrades become considerably easier due to the smaller number of
modifications.

If you want to change an SAP Repository object, you must provide the Workbench Organizer with the following information:

SSCR key
Change Request

We saw above how you get an SSCR key. If you now continue to change the object, you must confirm the following warning dialogs: At this point, you can still cancel the action without repairing the object.

The Workbench Organizer asks you to enter a change request, as it would for your own objects. The object is automatically added to a repair task. The change request has the following functions:

Change lock

After the task has been assigned, only its owner can change the object.

Import lock

The object cannot be overwritten by an import (upgrade or support package).

Versions

The system generates a new version of the object (see below).

After development is finished, the programmer releases the task. At this point, the programmer must document the changes made. The objects and object locks valid in the task are transferred to the change request. If the developer confirms the repair, the import lock passes to the change request. If the developer does not confirm the repair when releasing the task, the import lock remains in place.

Only the developer can release this lock.

Once the project is completed, you release the change request. This removes all of the change request's object locks. This applies both to the change locks and the import locks.

When the change request is released, the objects are copied from the R/3 database and stored in a directory at operating system level. They can then be imported into subsequent systems by the system administrator.

After the modifications have been imported into the quality system, the developer must test them and check the import log of the request.

When you release a change request, a complete version of all objects contained in the change request is written to the versions database.

If you transport the Repository object again later, the current object becomes a complete copy and the differences between the old and the new object are stored in the versions database as a backwards delta.

Whenever you assign a Repository object to a task, the system checks whether the current version agrees with the complete copy in the versions database. If not, a complete copy is created. This process is also initiated the first time you change an object, since SAP does not deliver versions of Repository objects.

The versions of a Repository object provide the basis for modification adjustment. To support adjustment, information on whether the version was created by SAP or by the customer is also stored.

Encapsulate customer source code in modularization units instead of inserting it directly into SAP source code (with, for example, customer function module calls in program source code, or customer sunscreen calls for additional screen fields).

When encapsulating the customer portions of a program, be sure to use narrow interfaces.

You should define a standard for all of your company's modification documentation (see the following slides).

You should also maintain a list of all modifications to your system (a modification log - see the following slides).

All requests that contain repairs must be released before an upgrade so that all relevant customer versions can be written to the versions database (the system compares versions during adjustment).

Repairs must also be confirmed prior to upgrade, otherwise the object being repaired is locked and cannot be imported.

Any modifications that you make to ABAP Dictionary objects that belong to Basis components are lost at upgrade--- these objects revert to their earlier form and no adjustment help is offered. This can lead to the contents of certain tables being lost.

The aim of the Modification Assistant is to make modification adjustments easier. In the past, the granularity of modifications was only at including program level. Today, a finer granularity is available. Now, modifications can be recorded at subroutine or module level.

This is because (among other reasons) the modifications are registered in a different layer. As well as providing finer granularity, this means that you can reset modifications, since the original version is not changed.

If, in the past, you modified an include for which SAP provided a new version in an upgrade, a modification adjustment was necessary. The modification adjustment had to be performed line by line. The system provided little support.

The Modification Assistant has changed this situation considerably. Modifications are now recorded with finer granularity. For example, if you modify a subroutine, the rest of the include remains unchanged. If SAP delivers a new version of the include, the system looks to see if there is also a new version of that subroutine. If this is not the case, your changes can be incorporated into the new version automatically.

The original version of each software layer comprises the originals from the previous layer plus current modifications.

Above is a list of the tools supported by the Modification Assistant.

In the ABAP Editor, you can use modification mode to change source code. Only a restricted range of functions is available in this mode. You can add, replace, or comment out source code, all under the control of the Modification Assistant.

Changes to layout and flow logic in the Screen Painter are also recorded.

The Modification Assistant also records changes in the Menu Painter and to text elements, as well as the addition of new function modules to an existing function group.

To avoid conflicts in the upgrade, table appends are also logged by the Modification Assistant.

If you want to change an SAP object, you must provide the following information:
SSCR key
Change request

The system informs you that the object is under the control of the Modification Assistant. Only restricted functions are available in the editor.

You can switch the Modification Assistant on or off for the entire system changing the R/3 profile parameter eu/controlled_modification. SAP recommends that you always work with the Modification Assistant.

You can switch off the Modification Assistant for single Repository Objects. Once you have done so, the system no longer uses the fine granularity of the Modification Assistant.

In modification mode, you have access to a subset of the normal editor tools. You can access these using the appropriate pushbuttons. For example, in the ABAP Editor, you can:

Insert
The system generates a framework of comment lines between which you can enter your source code.

Replace

Position the cursor on a line and choose Replace. The corresponding line is commented out, and another line appears in which you can enter coding. If you want to replace several lines, mark them as a block first.

Delete

Select a line or a block and choose Delete . The lines are commented out.

Undo modifications

This undoes all of the modifications you have made to this object.


Display modification overview

Choose this function to display an overview of all modifications belonging to this object.

The Modification Assistant automatically generates a framework of comment lines describing the action. The comment also contains the number of the change request to which the change is assigned, and a number used for internal administration.

The "modification overview" icon provides you with an overview of the modifications you have made in the current program.

The display is divided up according to the various modularization units. This corresponds to the structure used by the Modification Assistant to record the modifications.

You can reset all of the modifications that you have made to the current object using the
Modification Assistant by choosing this function. The record of the modifications is also deleted.

Remember that you cannot selectively undo modifications to an object. You can only undo modifications based on the "all or nothing" principle.

The Modification Browser provides an overview of all of the modified objects in the system. The Modification Browser differentiates between modifications made with the Modification Browser and those made without.

On the initial screen of the Modification Browser, you can restrict the selection according to various criteria. This allows you to find modifications in a particular area.

The Modification Assistant displays the hit list in tree form. Objects are arranged by:

Modification type (with/without the Assistant)

Object type (PROG, DOMA, DTEL, TABL,)

SAP recommends that you use Modification Assistant to make changes to R/3 objects. Changes without the use of the Modification Assistant should be avoided. However, should this be necessary, you should document your modifications in the source code as follows?

Preliminary corrections SAP note, repair number, changed by, changed on, valid until

Customer functions that have been inserted subject area, repair number, changed by, changed on, INSERTION

Customer functions that have replaced SAP functions subject area, repair number, changed by, changed on, REPLACEMENT The SAP functions that you do not need should not be deleted, but commented out instead

Subject areas are specified in the relevant process design blueprint (for example, subject area SD_001 = pricing).

SAP recommends that you keep a record of all modifications that have been made to your system (that is, of any changes you have made to Repository objects in the SAP namespace).

The following information should be logged for each modification:

Object type (program, screen, GUI status,)

Object name

Routine (if applicable)

Subject area (according to process design blueprint or technical design)

Repair number

Changed on

Changed by

Preliminary correction? (Yes/no)

OSS note number, valid until Release x.y

Amount of time necessary to recreate modification during adjustment (measured in hours).

A module pool is organized as a collection of include programs. This is particularly useful for making the program easier to understand. The organization is similar to that of function groups. In particular, the naming convention, by which the last three letters of the name of the include program identify its contents, is identical.

The main program, as a rule, contains the include statements for all of the include programs that belong to the module pool.

The includes described as "special" includes in the program are themselves only include programs - technically, they are not different. These programs are only delivered once.

User exits are a type of system enhancement that were originally developed for the R/3 Sales and Distribution Module (SD). The original purpose of user exits was to allow the user to avoid modification adjustment.

A user exit is considered a modification, since technically objects in the SAP namespace are being modified.

The SAP developer creates a special include in a module pool. These includes contain one or more subroutines routines that satisfy the naming convention userexit_. The calls for these subroutines have already been implemented in the R/3 program. Usually global variables are used.

After delivering them, SAP never alters includes created in this manner; if new user exits must
be delivered in a new release, they are placed in a new include program.

User exits are actually empty subroutines that SAP developers provide for you. You can fill them with your own source code.

The purpose behind this type of system is to keep all changes well away from program source code and store them in include programs instead. To this end, SAP developers create various includes that fulfill the naming conventions for programs and function groups. The last two letters in the name of the include refer to the include that the customer should use: "Z" is usually found here.

Example: Program SAPM45A
Include M45AFZB

This naming convention guarantees that SAP developers will not touch this include in the future. For this reason, includes of this nature are not adjusted during modification upgrade.

The subroutine call is already implemented in the programt. The interface is already defined. Normally, subroutines of this type only work with global data.

If any new user exits are delivered by SAP with a new release, then they are bundled into new includes that adhere to the same naming convention.

You can find a list of all user exits in the SAP Reference Implementation Guide.

There, you will also find documentation explaining why SAP developers have created a particular user exit.

Follow the steps described in the Implementation Guide.

The set of objects for adjustment is derived from the set of new objects delivered by SAP in a new release. This is compared with the set of objects you have modified on your R/3 system.

The intersection of these two sets is the set of objects that must be adjusted when you import an upgrade or support package.

During modification adjustment, old and new versions of ABAP Repository objects are compared using transactions SPDD and SPAU.

You do not have to call transaction SPDD to adjust Dictionary objects if:
No changes have been made to SAP standard objects in the Dictionary
You have only added customer objects to your system. Only SAP objects that have been
Changed must be adjusted using this transaction.

All other ABAP Repository objects are adjusted using transaction SPAU. Upgrade program R3up tells you to start the transaction after upgrade has finished. You have 30 days to use transaction SPAU after an upgrade. After 30 days, you must apply for a SSCR key for each object that you want to adjust.

Transaction SPAU first determines which objects have been modified. Then it determines which of these objects have a new version in the current upgrade. Modification adjustment allows you to transfer the modifications you have made in your system to your new R/3 Release.

Use transaction SPDD to adjust the following ABAP Dictionary objects during the modification adjustment process:

Domains

Data elements

Tables (structures, transparent tables, pool, and cluster table, together with their technical settings)

These three object types are adjusted directly after the Dictionary object import (before the main import). At this point in time, no ABAP Dictionary objects have yet been generated. To ensure that no data is lost, it is important that any customer modifications to domains, data elements, or tables are undertaken prior their generation.

Changes to other ABAP Dictionary objects, such as lock objects, match codes, or views, cannot result in loss of data. Therefore, these ABAP Dictionary objects are adjusted using transaction SPAU after both main import and object generation have been completed. You can use transaction SPAU to adjust the following object types:

ABAP programs, interfaces (menus), screens, match code objects, views, and lock objects.

During modification adjustment, you should use two different change requests to implement the changes you have made: one for SPDD adjustments and another for SPAU adjustments. These change requests are then transported into other R/3 systems you want to adjust. This guarantees that all actual adjustment work takes place solely in your development system.

When upgrading additional R/3 systems, all adjustments exported from the first system upgrade are displayed during the ADJUSTCHK phase. You decide which adjustments you want to accept into your additional systems and these are then integrated into the current upgrade. Afterwards, the system checks to see if all modifications in the current R/3 system are covered by the change requests created during the first system upgrade. If this is the case, no adjustments are made during the current upgrade.

Note: For this process to be effective, it is important that all systems involved have identical system landscapes. This can be guaranteed by first making modifications in your development system and then transporting them to later systems before you upgrade the development system. You can also guarantee that all of your systems have an identical system landscape by creating your development system before upgrade as a copy of your production system and then refraining from modifying the production system again until after upgrade.

Version compare is also used during or after an upgrade for modification adjustment.

During modification adjustment, version compare determines the number of SAP objects that you a) changed in the system and that b) were then overwritten by SAP at upgrade.

Version compare allows you to find where changes were made and transfer them to your new SAP version if you want.

The icons in front of the individual objects that need adjustment show how they can be adjusted.
The possible methods are:

Automatically

The system could not find any conflicts. The changes can be adopted automatically

Semi-automatically
The individual tools support you in adjusting the objects.

Manually

You must process your modifications with no special support from the system. In this case, the modification adjustment does allow you to jump directly into the relevant tool.

Adjusted objects are identified by a green tick.

If you want to use the new SAP standard version, use Restore original. If you do this, you will have no further adjustment work in future.

EPILOG:

Modifications can be categorized as 'critical' if:

They affect numerous other Repository objects (such as Dictionary objects or function modules) Modification adjustment is either difficult (as with menus, pushbuttons, and GUI interfaces up to 4.5A) or not supported by a tool (transaction codes, message classes, logical databases)

Without the Modification Assistant (prior to Release 4.5A), both modifying GUI statuses and GUI titles, as well as assigning customer function modules to SAP function groups, should be considered 'critical' activities.

SAP only changes the following Repository objects in an upwardly compatible manner. They should therefore be considered 'uncritical' by customers who want to call them:

Function modules that have been released

BAPIs

Includes for user exits

Screen, program, menu, and field exits

After an upgrade, you must test customer reports that call SAP objects, as well as all objects displayed in the upgrade utility SPAU. This is also true for Repository objects that have been automatically adjusted using the Modifications Assistant (from Release 4.5A).

You must be familiar with the processing logic of your application in order to be able to adjust programs properly.

Modification adjustment is not necessary if you avoid making changes to SAP objects.

Use program enhancements and appends with SAP tables to enhance SAP objects in such a way that your changes cannot be overwritten by SAP at upgrade.

From Release 3.0, you can use Online Correction Services to import and cancel support packages and patches automatically (instead of having to insert preliminary corrections manually).

Modification has the advantage that your live Repository objects do not lose their connection to the SAP standard. Copying, on the other hand, has the advantage that no modification adjustment will be necessary for your live Repository objects during subsequent upgrades.

Choose copying instead of modifying if:

You have to make numerous changes to an SAP program
Your requirements will not be met by the standard in future R/3 releases

During copying, pay attention to a Repository object's environment as well. You should only decide whether to modify or copy after having informed yourself of the consequences for the main program, as well as for all of the includes attached to the main program. The same holds true for function groups and function modules.

ABAP development projects can be evaluated according to the following criteria:
What will implementation cost, measured in manpower (creating the concept, implementation, testing)?

How will the ABAP development project influence:
Production operation performance?
The amount of adjustment at upgrade?

By calling SAP objects in your own Repository object, you can drastically reduce the amount of effort needed to implement your object. However, any changes that SAP makes to the Repository object you choose to call may make extra adjustment necessary after an upgrade. For example, SAP could conceivably change the user interface of a screen for which you have written a batch input program.

Naming conventions allow you to avoid naming conflicts and give your Repository objects meaningful names (that can be understood by others).

The following naming conflicts can occur:

An SAP Repository object and a customer Re pository object conflict
SAP Repository objects and customer Repository objects should be separated from each other by strict adherence to SAP naming conventions. OSS note 16466 gives you an overview of the current naming conventions for customer Repository objects (usually names that begin with either Y or Z).

Two customer Repository objects conflict
Naming conflicts can also occur between customers Repository objects in decentralized
Development scenarios where more than one development system is being used. You can avoid naming conflicts in this area by reserving a special namespace for development areas within the customer namespace. The Workbench Organizer checks to make sure that you adhere to these conventions by making entries in view V_TRESN.