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.
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.
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.
Enter a city name here; this field is purely informational.
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.
Here you enter the code of the standard currency used by the business, like USD or EUR.
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.
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:
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:
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:
The table below summarizes the effect of the different protection levels on the availability of the data in a client XXX.
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:
You cannot change this field. The system sets this flag while a client copy with this client as source or target is active.
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.
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.