• The Purpose of Creating a Multi-clients S/4HANA System

During large scale S/4HANA implementation projects for On-premise or Private Cloud versions, it is by far the common practice to establish multiple ‘working’ clients in each SAP systems of the 3 tiers (Dev, QA, Prod) or 4 tiers (Dev, QA, Preprod, Prod) landscape. This is to cover the many different system usages which are often parallel and intensive during the project execution, e.g. Mock Data Load, System Integration Test, Training, User Acceptance Test, Performance Test, Dress Rehearsal etc.

• Client Copy and Client Copy Data Profiles

The most efficient way to establish these clients is a Basis activity which is called ‘Client Copy’. It can either be done locally in one system or remotely across two different systems. This procedure helps to save the effort to rebuild the configuration (or technically the content in client specific configuration tables) within the newly created client by retaining configuration of the source client.

SAP has given a couple of ‘Client Copy Profiles’ which can be used by Basis consultant to specify the scope of data to be copied from the source client to the target client in a client copy execution.

Among these many options the mainstream ones are

SAP_ALL: All client specific tables except change documents

SAP_CUST: Customizing including users, roles and authorization

SAP_USER: Users, roles and authorization only

• The Demand of a Clean Client and Recommended Approach

From a requirement perspective, it is very common for someone to request a ‘Clean’ client to be setup during the project execution: all configurations, settings and coding that has been built by Functional and Technical Consultants are retained in the client, but no master or transactional data is retained. So that a new data load, a new testing activity can be started on a clean baseline. From a technical perspective, this requirement can also be translated to a more straightforward way. Every (client specific) table that is supposed to be populated by transports imports should be retained in this new client, and everything else that is locally populated by some sort of manual steps in the client should not be retained in this new client.

It is a strong recommendation from me to always retain a ‘Reference’ client in each and every system including production. This client should be created as a blank client by ways of Basis installation/setup. This client should always be updated by all the transports moved across the landscape and strictly nothing more! No one should ever be given user access to this reference client to do anything. This client can thus be used at any time to create a ‘Clean’ client or clean down the data in an existing client by a client copy activity using ‘SAP_ALL’ profile.

• SAP_CUST Client Copy Profile and Its Side Effect

In an unfortunate case, the ‘Reference’ client might not have been established from the beginning in a system, or a compromise had been made to populate the client with data for some purpose either due to system size restriction or project timeline restrictions. Under these circumstances when a request to establish a ‘Clean’ client comes it might be considered by some Basis consultant as a workable approach to copying from an existing ‘working’ client using ‘SAP_CUST’ profile, hoping it will retain configuration but clean data. Yes this included myself. But you should be aware of these things that might surprise you:

• Content that should have been retained but are not:

– House banking customizing

The configuration is accessible via path: IMG->Financial Accounting->Bank Accounting->Bank Accounts->Define House Banks or FI12 tcode.

And it is absolutely transportable between systems. However the underlying tables (e.g. T012) are categorized as ‘A’ therefore will not be retained in a ‘SAP_CUST’ client copy.

It is at the same time not a ‘current setting’ configuration means you have to open the client (SCC4) for this configuration to be amended by a banking function consultant.

– Event linkage activate status

Event linkage is widely used in business workflow to allow an event to trigger a workflow task. Tcode used to active event linkage is SWETYPV and it is transportable. However the underlying table SWFDEVENA is categorized as ‘A’ (for security reasons? According to note 2851092).

Update: seems from S/4 2020, the table has now become ‘C’ thus included in ‘SAP_CUST’ profile.

– TVARVC
Entries in TVARVC table are defined in tcode STVARV, one of a convenient place to maintain global parameters to be used in ABAP code or batch job variant definition. It is a transportable configuration including both the parameters’ definition and the values. However, surprisingly it is also not retained in a ‘SAP_CUST’ client copy.

– Fiori UI Adaptation

Since the launch of Fiori UI, user adaptation has been a widely welcomed feature. In reality, these adaptations are mostly done by IT consultants instead of end users because it is still too ‘technical’ for a user to take on this task. If some fields have been added to a standard Fiori UI in Dev, it can be transported across systems by Transport Requests, however be ready these fields won’t be there in a newly created client by ‘SAP_CUST’ profile. The underlying tables are not categorized as ‘C’.

What is the fix:

Of course, if the time allows, these configurations can be manually redo in the client. But often it is a frustration thing to fit in a tight timeline

A relatively automatic way to bring back these configurations is to do a copy by transport to move the content from source client to target client. This procedure involves following steps:

1. Identify the original transport requests which have brought these configurations to the source client. They should ideally include these configurations only. But if they are combining many different configurations together, it’s not the end of the day, after all, you are just aligning them again between the source client and target client.
2. Create a new transport request in the source client by including the content of the transport requests identified in step 1… cautious this is often an exceptional transport which does not originate from Dev, so it should never be included in the production build list and should never be released and transported anywhere.
3. In the target client, use SCC1 tcode and copy the content of the transport request created in step 2.

• Content that should not have been retained but are retained

– G/L account master data

I have never come across a project in which G/L account master data is not considered as part of initial data load. So it is always an expectation that a ‘clean’ client shouldn’t have G/L account master data. This is especially useful when this master data undergoes a big change during project execution.
However this is retained by a ‘SAP_CUST’ client copy.

– MDG staging tables

In the scenario where master data is governed in an embedded MDG module, MDG staging tables are populated before the relevant master data are populated in the S/4HANA tables.

You would expect that if the S/4HANA master data tables are not retained during ‘SAP_CUST’ client copy, then the corresponding staging tables in the MDG module should not either. However, this is not true!

You would find after the ‘SAP_CUST’ client copy, a supposedly clean client already contains data in MDG stage tables for things like Profit Centre and Cost Centre and their respective hierarchy. This will cause tremendous confusion when the data is reloaded via MDG staging tables and bulk replicated to S/4HANA master data tables, as alien data from the ‘unclean’ staging tables will appear in S/4HANA master data tables. MDG staging tables names are often started with /SMD/…. you would find most of them are categorized as ‘C’ tables.

What is the fix:

Unlike the flip side of the story, there isn’t an universally applicable ‘civilized’ way to clean data in these circumstances. You might be lucky to find an existing standard tcode to clean these data or mark them as deleted, but in the end you have to ask your basis team to do a data cleaning of the relevant tables which is obviously an exceptional and risky approach.

• Conclusion:

It is a best practice to keep a ‘reference’ client in a system with all transports moved into it but no master/transaction data gets loaded or created in it. Using this client it is easy to set up a new ‘clean’ client or ‘clean up’ an existing client.

While a ‘reference’ client does not exist, it is suboptimal to use SAP_CUST profile to create a ‘clean’ client. There will be either too much data in some areas or too less data in some other areas. Remedial methods have to be taken to deal with these inconsistencies and gaps during project execution, which can impact the project timeline and budget and sometimes even the quality.

Thanks for spend time reading this blog, I look forward to your feedback, comments or questions.

Please remember that you can always post or answer questions on Basis Technology category using below link

https://answers.sap.com/tags/7bf2eaed-4604-44ae-bad7-d2d2d5c58c54

You can also read other posts on the Basis Technology category using this link

https://blogs.sap.com/tags/7bf2eaed-4604-44ae-bad7-d2d2d5c58c54/