Customizing Procedure

In an SAP implementation, where customizing and development changes are integral to the SAP system being available, projects must be executed in a structured environment using defined procedures, to minimize the threat of downtime caused by bugs.

The goal of your project organization must be to divide the large number of activities among the project team so that the team members do not interfere with each other's work. You must make sure that work that logically belongs together but is being performed by different team members is still connected. This is carried out by dividing the tasks in a customizing project among three roles, each of which is responsible for performing certain tasks.

Project Team Leader

The project team leader creates the transport requests and assigns the appropriate team members to them. When a team member is assigned to a transport request, the Transport Organizer creates a task. The settings for each team member are recorded in this task. For the transport to other SAP systems, the project team leader can release the created transport requests.

Customizer/Developer

The customizers or developers perform their customizing from the IMG or their development and assign their settings to a transport request and thus, to their individual task. The customizers can copy their settings to a TEST client to test them before the transport request is released (this, of course, only makes sense for client-specific data). They are authorized to release their own tasks in a transport request but are not allowed to release the transport request.

TMS Administrator

The TMS administrator uses the TMS to transport released transport requests to subsequent SAP systems in the SAP system landscape using the predefined transport routes.

Usually, application consultants and employees in the department handle the roles of the project team leader and the customizers and developers. The project team leader decides which customizing settings to perform and how to divide the necessary changes among the project team members, who in turn execute the customizing transactions. The TMS administrator is responsible for the transport between the SAP systems along the transport routes, after the transport requests are released to the TMS.

The Transport Organizer and the Transport Management System are designed for supporting this task split. The sequence of the different customizing steps is shown in the figure above. During usual customizing work, the sequence of the steps is as follows:

1. The project leader first assigns a transport request to a (CTS) project and assigns the subsidiary tasks to the members involved. These members perform customizing changes that are recorded in the transport request.
2. After customizing is completed, the members must release their tasks so that the transport request can then be released from the source system for export to the file system.
3. The transport request can now be imported into the subsequent SAP systems.

So far, you have seen how the creation and assignment of transport requests can be done. In the following sections, you will see how the other steps work.

A customizing transaction is a transaction for setting customizing table entries. To use a customizing transaction, you do not need to know about the technical aspects of where and how a business object is maintained, or which transactions are used to access and change certain fields in specific tables.

After the customizing settings have been changed using a customizing transaction, the settings should be saved as follows:

• When a client is configured to automatically record changes, the settings are automatically saved to a transport request managed by the Transport Organizer.
• If the client is not configured for automatic recording of changes, the settings are saved but not recorded in a transport request. However, they can be included in a transport request manually. This can be done from the specific customizing transaction (for example, using the path Table View → Transport) or from within the Transport Organizer.

All customizing transactions in the IMG also allow entries to be manually saved to a transport request.

To view transport dependencies for items within the IMG: from the initial screen of the SAP system, enter SAP Reference IMG in transaction SPRO and choose Additional Information → Technical Data → Transport Type.

SAP recommends that all customizing changes originate in one client only and all changes be saved to transport requests. This control is put in place by the SAP system administrator via use of the client settings in the Client Administration client change options (transaction SCC4).

Testing of changes in the development system is very important. Only tested and error-free transport requests should be released in the development system. The advantage of these procedure is that the amount of transport requests (fewer correction transports will be needed) and error corrections between the development system and the quality assurance system is dramatically reduced, because most errors are detected early before releasing a transport request and not later during testing in the quality assurance system.

All customizing must be tested prior to production in two ways: unit testing and quality assurance testing. Perform unit testing first.

Unit testing is the testing of individual customizing settings. Quality assurance testing is the testing of all customizing settings together. Unit testing should be performed by the customizer and be completed before the release of the transport requests.

Unit testing typically requires application data. Because many customers find it advantageous to keep their customizing client free of application data, another client is created with the necessary application data for unit testing.

Before releasing a transport request, copy the recorded changes to a separate client for unit testing.

Transaction SCC1 (or its, successor SCC1N, which is available as of SAP S/4HANA 2020), copies changes from one client to another based on:

• A task
• A transport request
• A transport request including its tasks

After unit testing the tasks, a transport request can be released. Unit testing alone, however, is not sufficient for transporting customizing changes to production. After unit testing, the change needs to be tested with all other customizing settings in quality assurance testing in a dedicated SAP system. This is done to ensure that all SAP system settings work properly together.

To copy the contents of a transport request from one client to another client, use transaction SCC1. Log on to the target client, that is, the unit test client. Enter the source client and the transport request to be copied.

With FP01 for SAP S/4HANA 2020 (that is, SAP_BASIS 755 SP01), SAP ships transaction SCC1N as successor for transaction SCC1. With the help of this new transaction it is possible to copy customizing objects recorded in transport requests to several target clients. This can be a local transport request or an imported transport request from another system. In contrast to transaction SCC1, transaction SCC1N can be executed in any client. In addition, a large number of new parameters are available.

If you want to copy transport requests that have not been released with transaction SCC1N, proceed as follows:

• In the Export / Import Time of the Transport Request area, select the Local System Import Date radio button.
• If it is a mandatory field (this depends on the release / SP level), enter a date that is far in the past in the Export / Import Date field.

Create a transport request in transaction SE09 and then create a new country in SAP Reference IMG (with the keys in the screen shot). Then come back to transaction SE09 and expand your transport request.

Promoting changes recorded in a transport request begins with releasing the relevant tasks. Releasing a task indicates that the owner of the task has completed customizing or development work, that the unit testing was successful, and that the appropriate documentation is complete. This means:

• The task contains a recorded object.
• The task has been documented.
• The task is owned by the person releasing it or the person releasing it has the appropriate SAP system authorizations.

To release a task:

1. Enter the Transport Organizer by executing transaction SE09.
2. Check that your user ID is selected in field User, that Modifiable is selected as Request Status and choose Display. The request overview displays.
3. To view all tasks in a specified transport request, expand the tree structure.
4. Position the cursor on the task you wish to release and choose Release Directly in the application toolbar.

By releasing a transport request, you indicate that it has sufficient documentation, the changes recorded in it have been tested, and the changes are ready to be transported using the TMS transport routes. During the export process triggered by the release, the objects recorded in the transport request are copied from the SAP database to operating system level files in the transport directory. In addition, a record of the transport request is automatically added to the appropriate import queues of the SAP systems defined in the TMS.

Releasing and exporting a single transport request generates export logs and import logs when importing it into subsequent SAP systems. Testing in the quality assurance system and QA approval sign off are necessary before the import into the production system takes place. To support the validation process and limit the technical and administrative overhead, SAP recommends that you transport changes that belong to the same project together in a limited number of transport requests. This is ideally done by assignment of tasks within the transport requests by the project team leader or the person responsible for the transport.

Sometimes you want to merge transport requests. You can combine multiple transport requests into one single transport request. Merging transport requests can be done explicitly in the Transport Organizer by choosing Utilities → → Reorganize → Merge Requests... from the menu.

We have learned that the database of the AS ABAP-based SAP system contains not only application data, user data and client-specific customizing, but also repository objects and cross-client customizing.

Client-specific customizing

These are typically entries in customizing tables where the client field is on the first position in the table key. An example of this is the customizing table T005 with the country customizing. The entries in that table only affect the client that is specified in the key field of the entry.

Cross-client customizing

These are typically entries in customizing tables without a client field in the key. An example of a client-specific customizing table is the table T000, in which all clients that exist in an SAP system are stored.

Repository objects

Repository objects are, for example, table definitions in the ABAP dictionary or programs and function modules.

You must distinguish between client-specific and cross-client customizing.

To determine the client dependency of IMG transactions in a project IMG, from the IMG menu, choose (View → ) Additional information → Technical Data → Client-Dependence.

Cross-client customizing affects one of the following:

• Cross-client customizing objects, which are repository objects generated by customizing demands. To ensure proper transport, assign these repository objects to a customer package. Examples of these objects are search helps, condition tables, and hierarchies.
• Global customizing settings are the standard SAP system settings and configurations in various tables whose key value does not contain the client. Examples of these settings are calendars, online help settings, printer settings, communication settings, and schedules.

While client-specific customizing changes are recorded in Customizing transport requests, cross-client changes must be saved to Workbench transport requests. Therefore, changes to cross-client customizing objects, global settings, and repository objects require a Workbench transport request.

Both screen shots are taken from transaction SE09 and transaction SCC4.

There are different types of transport requests with special properties, including:

• The transport request of type Customizing. This is a transport request for transporting settings from client-specific tables. Cross-client customizing or workbench objects can't be assigned to this kind of transport request.
• The transport request is of type Workbench. This is a transport request for transporting repository objects and settings from cross-client tables.

With this, there is a split between client-specific data that can be recorded in transport requests of type Customizing and the transport request of type Workbench. A project leader or a person responsible for the transport can control who is allowed to transfer cross-client changes by assigning tasks inside the workbench requests.

Different customizing tools and the technical settings that are required for the usage of these tools. We will now discuss what is important for planning the customizing change management.

From a process point of view, it is essential to establish policies on how customizing and development will be carried out and by whom.

Customizing is the standard way of adapting the functions of the delivered SAP components to the requirements of a company. Project control tools allow easy documentation and monitoring of each phase of the SAP implementation and customizing.

Customizing is required for implementations of SAP systems. Because customizing is a highly integrated process, both between functional areas and within the areas themselves, all customizing activities must be performed in a single client, usually known as the development client. Development tasks should also be restricted to this client, ensuring that there is a single environment for all implementation efforts.

The project team leader is responsible for creating transport requests for all project team members at the start of a development or customizing project.

After project team members complete their work, they save their changes in the tasks that comprise the transport request, and document the changes in the task. When all project team members have released their tasks, the project team leader releases the transport request for transport to other SAP systems within the SAP system landscape.

The project managers or team leaders are responsible for creating the appropriate project IMGs for the specific business areas and assigning who is responsible for executing the specific customizing transactions. The project management function enables you to assign tasks in the Transport Organizer. The project team leader should activate the CTS functions of the project, create transport requests for recording and transporting the customizing settings, and add users to the transport requests.

The project managers or team leaders are also responsible for training the team members on the tools and processes, as well as establishing and enforcing documentation and unit testing standards.