SCC4 — Client Maintenance and Client Settings

SCC4 opens the client maintenance table so an administrator can view or edit the attributes of a single client: its short description, currency, logical system link, client role (production, test, customizing, demo), whether changes to client specific customizing and repository objects are allowed, whether cross client object changes are allowed from this client, and protection against client copy or CATT/eCATT execution. The one fact that explains most confusion is that these are advisory metadata flags read by the transport and change control layer, not an independent lock. Setting client specific changes to not allowed in SCC4 stops customizing transactions in that client, but it does nothing to the separate cross client system change option maintained in SE06, and the two are frequently changed in isolation from each other, leaving a client half open or half locked in ways nobody intended.

SCC4 is reached for during client build (assigning role and currency right after a client is created), before and after a customizing freeze (locking a client ahead of a cutover or year end close), and when diagnosing why a transaction is grayed out or throwing a change not permitted message. It is also used to loosen protection temporarily so a client copy or CATT script can run, then to re-tighten it afterwards. Functional consultants do not use this transaction directly; they raise a request describing the desired state (freeze customizing in the test client, unlock production briefly for an emergency change) and Basis executes it here. There is no Fiori app for this; it remains a SAP GUI only administrative task performed rarely and deliberately.

In SE16 or SE16N open T000, filter on the client number in question, and read the row directly rather than trusting what a screen currently displays cached. Confirm the client role field matches what the business expects (production versus test versus customizing), and confirm the changeability flags for cross client and client specific objects. If a change made through SCC4 does not seem to have taken effect for a user, compare the T000 row's current values against what was requested; a stale GUI session on the affected client, not a failed save, is the usual explanation.

SCC4 behaves the same way on S/4HANA as on ECC; the underlying table T000 and the meaning of its flags are unchanged. There is no Fiori app replacing it, since client administration remains a SAP GUI task performed by Basis outside normal business operation. The only practical difference on S/4HANA landscapes is that client freezes tend to be planned around more frequent maintenance and upgrade windows, not a change to the transaction's mechanics.

This is a Basis owned transaction. Functional and ABAP teams request a change of state (freeze customizing, open for a copy, restore protection) rather than execute it. A good handover states the client number, the exact flag to change, the business reason and time window, and explicit confirmation of when it must be reversed.

SCC1 is the natural next stop, since client copy protection flags maintained in SCC4 directly control whether a copy in SCC1 is even allowed to run. STMS matters because cross client object changeability interacts with the transport route configuration when deciding whether a change lands in a request. SLG1 is worth checking after any client level change, since client copy and some administrative operations write application log entries that confirm what actually happened, separate from what T000 currently shows.