How to Create Clients in an SAP S/4HANA System

The first step in setting up a new client in SAP S/4HANA is to create its definition. This is done with Transaction SCC4.

The opening screen lists the existing clients.

The transaction always starts in display-only mode. To display the configuration of an existing client, simply double-click its entry in the list. To create a client or modify an existing client, you must first switch to change mode by clicking Display <> Change. Confirm the warning that the table is cross-client.

In the following sections, we’ll explain the settings needed to set up a client as well as the use of client roles.

Client Settings

The menu at the top now shows a New Entries button; click this button to open the client creation screen shown in the next figure.

Let’s walk through all the fields of this screen. 

Client

This is the three-digit number of the new client. You may assign any value that does not yet exist, in this case everything from 002 to 999 (although we advise against using 066). In our experience, many SAP customers use multiples of 100 or multiples of 10, which are easy to remember, but the choice is yours.

City

Enter a city name here; this field is purely informational.

Logical System

The logical system is an identifier used by applications that access the client externally. Examples of this are extractions by SAP BW or SAP BW/4HANA data warehouse systems or data exchange between SAP S/4HANA and SAP CRM or SAP Customer Experience. Specifying a logical system is optional, and the field may be left empty, but if the client is to be in any way involved in external communications, then assigning a logical system to it is necessary. Client 000 does not have a logical system and does not need one. 

Currency

Here you enter the code of the standard currency used by the business, like USD or EUR.

Client Role

This field describes the function of the client. Use (F4) to display a dropdown list that offers the following choices: Production, Test, Customizing, Demo, Training/Education, and SAP Reference. These roles are more or less self-explanatory, except that in development systems the customizing role is usually assigned to both the development client and the client used for actual customizing.

Changes and Transport for Client-Specific Objects

Under this heading, there is a set of four radio buttons. These specify whether client-dependent customizing can be changed in this client. The possibilities are as follows:

• Changes without Automatic Recording: Client-dependent customizing can be changed, but the changes are not automatically recorded in a transport request. However, it is still possible to create a transport request manually and add the changes to this request.
• Automatic Recording of Changes: Client-dependent customizing can be changed, and these changes are recorded in transport requests.
• No Changes Allowed: Client-dependent customizing is not allowed in this client.
• Changes without Automatic Recording, No Transports Allowed: Client-dependent customizing can be changed, but the changes are not automatically recorded in a transport request. Moreover, it is not allowed to record them in a transport request manually. Any customizing changes thus remain strictly local to the client. 

Cross-Client Object Changes

This field sets the ability to make changes to cross-client objects from this client. As you saw before, the two main types of cross-client objects are repository data (development) and cross-client customizing. Use (F4) to show a dropdown list with following options:

• Changes to Repository and Cross-Client Customizing Allowed: Both types of data can be changed—that is, this client can be used both for development and for system-wide customizing.
• No Changes to Repository and Cross-Client Customizing Objects: The opposite of the first option: no cross-client data can be changed at all.
• No Changes to Cross-Client Customizing Objects: Development changes are allowed but cross-client customizing is not. It is not quite clear why SAP uses a negative expression here (why not call it “only repository changes allowed”?), but it has been like this since the beginning.
• No Changes to Repository Objects: Cross-client customizing is allowed but repository changes are not.

Client Copy and Comparison Tool Protection

It is possible to copy the contents of one client to another; actually, that is one of the main subjects in this chapter. Technically it is also possible to overwrite the data of a client with data from another client. There are also tools that enable a properly authorized user to compare the data in two clients (which may be in the same SAP system or in different systems). While this is very useful functionality, it means that the data in the client is exposed to the outside world, which may pose an issue of confidentiality, especially in production systems. This field lets you control to what extent the data in the client should be accessible to the copy and comparison tools. The dropdown list lets you choose among three protection levels:

• Protection Level 0: No Restriction: The data in the client is not protected. It can be copied to another client or compared with the data in another client, and the data can be overwritten by a client copy that uses another client as the source.
• Protection Level 1: No Overwriting: The data in the client can be used as the source for a client copy to another client, and it can also be used in data comparisons between clients. However, it cannot be overwritten by a client copy.
• Protection Level 2: No Overwriting, No External Availability: The data in the client is fully protected: it cannot be used as the source of a client copy, it cannot be compared, nor can it be overwritten.

The table below summarizes the effect of the different protection levels on the availability of the data in a client XXX.

CATT and eCATT Restrictions

Computer Aided Test Tool (CATT) and Extended CATT (eCATT) are powerful tools that allow creating extensive automatic test scenarios. CATT runs within the confines of one SAP system, while eCATT is a script-driven tool that runs in the frontend and can be used to test entire business processes across system boundaries. While primarily intended as test tools in development or acceptance environments, CATT and eCATT are also frequently used for mass data uploads (although more appropriate tools exist for this purpose). Running large tests or large uploads may of course have a great (and, if not handled carefully, devastating) impact on the data in the client, and for that reason their usage can be restricted. From the dropdown list, you can choose among five possible settings:

• eCATT and CATT Not Allowed: Does what it says on the tin.
• eCATT and CATT Allowed:
• eCATT and CATT Only Allowed for Trusted RFC: A trusted RFC connection is a connection between systems that have a trusted/trusting relationship, which for instance allows logging on without the need for a password. With this option, only trusted connections can use eCATT and CATT in the client.
• eCATT Allowed, but FUN/ABAP and CATT Not Allowed: FUN is an eCATT command that allows executing function modules remotely even if those functions are not explicitly enabled for RFC in the repository. This setting allows using eCATT in the client but with the exception of FUN. CATT is not allowed.
• eCATT Allowed, but FUN/ABAP and CATT Only for Trusted RFC: Like the previous with regard to eCATT, but allowing FUN and CATT if originating from a trusted connection.

Locked Due to Client Copy

You cannot change this field. The system sets this flag while a client copy with this client as source or target is active.

Protection Against SAP Upgrade

If this flag is set, the client will no longer be supplied with new data during release upgrades. This effectively makes the client unusable after the upgrade. The only reason you would ever use this flag is if you want to preserve a “frozen” image of a client for backup or archival purposes. This setting is rarely, if ever, used.

Client Roles and Recommended Settings

There are various types of clients in the SAP landscape, and each usage type comes with its own requirements, especially with regard to changeability and access to the data. If we assume a typical three-system landscape with a development, test (quality assurance), and production system, then the organization described here is recommended by SAP and commonly used by SAP customers.

The development system normally has at least two clients (of course, ignoring client 000). The first, known in SAP parlance as the golden client, is where all development and customizing is carried out and from where these are transported to the test system. The golden client is “clean” in that it does not contain any master or transaction data. Another client in the development system has the role of sandbox; this client is used for research and experimentation and also for unit tests of the development and customizing imported from the golden client.

The test system typically has one client, which is used for quality assurance and integration testing. Here the imported changes to repository objects and customizing data are tested in scenarios that resemble the production processes as closely as possible. This client contains a representative set of master and transaction data. In addition, there may be one or more training clients, which are refreshed before each training session, either from the test client or from a “model” client containing master data and a limited amount of transaction data.

Finally, the production system in most cases has just one client, unless the system is used for separate autonomous entities, which is relatively rare.

The next table shows the recommended settings for the different client types. These are the settings the client should have during normal operation; occasional deviations may occur (e.g., temporarily opening the test or even the production system for changes to apply an urgent fix), but these deviations should be temporary.

The settings made with Transaction SCC4 are in database table T000. This table has logging enabled by default.

Editor’s note: This post has been adapted from a section of the book SAP S/4HANA Administration by Mark Mergaerts and Bert Vanstechelman.