A Client is the top-most organizational structure, which has its own set of master

records and Tables. The main objective of the client is to keep the data isolated or we
can say it is a way to have different groupings of data within one database. Clients can
be used for separating data for multiple companies or multiple divisions or just created
for testing a process or data load. In a SAP system there can be multiple clients. Each of
these clients can have different objective or each client represents a unique work
environment. One of the first things SAP asks for at the time of login is the client
number. A number of clients are created in one R/3 database to maintain differentiation
in customization, testing, quality assurance and production data. R/3 client can be
identified with three digit numeric number starts from 000 to 999, and is a mandatory
element. The settings made at the Client level are available across all the Company
Codes. A Client should have at least one Company Code defined. Clients can be created;
copied and deleted.

For purposes of SAP R/3, a client can be company, corporation or even a business unit.A
client is organizational and legal entity in the SAP system. All the business management
data is protected here because other clients can not access them. The data in a client
can be only visible within that client; it can not be displayed or changed from another
client. All the business management data is protected, SAP R/3 comes inbuilt with three
standard clients viz. 000, 001 and 066. Let us see all the three different client's in SAP R/3 in
detail. It is a way to have different groupings of data within one database client is the work
area for particular process. example we can take the 800 client for particular work.810 for
debit process.800 for credit process.

Typically, in SAP, you will have different ‘types’ of Clients; namely:

1. Development Client
2. Test Client
3. Production Client

 Is an organizational unit, which has its own data base table to store information & structure
 SAP system maintains database table to store the information.
 Each table contains the client field.
 Client is technical information.
 Client is a top most hierarchy in an enterprise structure.

Z
A client is simply the first field of every data record in tables that are not overall system-related. It is
a way to have different groupings of data within one database. Originally multiple companies ran
SAP from one system and database in a time sharing fashion. The 'client' was the company they
were doing business with. They added more companies and they became more clients in the system.
The design created to separate one company's information from another a dded a 'client' or mandt
field to each client-related data table. Behind the scenes any data access additionally specifies the
client number that the user logged into.
Clients can be used for separating data for multiple companies or multiple divisions or just created
for testing a process or dataload. Clients can be created, copied and deleted.
client is the work area for particular process. example we can take the 800 client for particular
work.810 for debit process.800 for credit process.

Data which can be accessible through a client in which it was created is called as client
dependent data or client specific data. Ex: user data, authorization data, application data. As
per above two types, the R/3 client maintains differentiation with respect to client dependent
data. A number of clients are created in one R/3 database to maintain differentiation in
customization, testing, quality assurance and production data. R/3 client can be identified
with three digit numeric number starts from 000 to 999 Default clients.

After installation there are three default clients configured in database. Which are (for
Non-Ides Software)
1. 000 Master Client
2. 001 Copy of master client
3. 066 Early watch client
4. For IDES Software we have clients 800, 810, 812.

1. - Client 000 is a special client in SAP since it has client independent

settings. Client 000 in SAP R/3 comes with a simple organizational structure. It is a
sort of Test Company. Client 000 contains all standard configurations, parameters,
standard transactions, etc. that are normally used in the SAP R/3 business
environment.

2. - Client 001 is a copy of client 000. Client 001 also includes a test
company. Client 001 can be customized to prepare it to move it into the production
environment. However, once client 001 is customized, it does not behave like client
000.

3. - Client 066 is used to perform "Early Watch" service for customer

systems.

One important thing to remember is that during SAP R/3 implementation, once SAP is
installed, the first thing to be done is copy a standard client included in SAP R/3
package. With the help of this, SAP users can start using SAP for creating tests, training,
or even start using it for customization.

Means if you create that data in one client is limited to that client only and it is not
accessible in other clients. In simple we can say Data which only applies to one client is
stored in client-specific or dependent data. Examples of this type of data include any
business type of data such as customers, invoices, purchases, in short its user data.
Means the data if you create in one client that is available in that as well as in other
clients. In simple we can say Data which can be accessible through entire R/3 database
from any client is called as client independent data or cross client data. For examples
ABAP programs, and standard tables. The data which is common for all the clients in the
system is called as client independent or crossed client data. Examples of client-
independent data include data dictionary objects (tables, views), ABAP source code,
screens, and menus.

Client dependent tables contain the column mandt as the first column whereas client
independent tables don't have this column.

Basis transactions, ABAP development are mostly client independent

Users/user management, application transactions are client dependent Ex: screen data,
transaction data, repository data and dictionary data. Ex: user data, authorization data,
application data. Ex: Transaction code

There are two types of tables in an R/3 database: client-dependent and client-
independent. A table is client-dependent if the first field is of type CLNT. The length will
always be 3, and by convention, this field is always named mandt. If the first field is not
of type CLNT, the table is client-independent. This program selects rows from table lfa1
and writes out lfa1-lifnr. When this program is run, only two rows are selected: only
those where mandt equals 800. This happens automatically because the first field in the
table is of type CLNT. There are five rows in the table, but the program writes out only
those rows where mandt equals 800. If the user were to log on to client 700 and run the
same program, three rows of data would be found and written out. If the user were to
log on to client 900, only one row of data would be found. The logon client mechanism
divides the rows within a client-dependent table into distinct groups. To access a
different set of data, the user logs on and specifies a different client number.

The user master records (containing R/3 user IDs) are client-dependent. Therefore, to
gain access to a client, the security administrator must create a new user ID for you
within that client. Developers and testers use the logon client mechanism to create and
access multiple, independent sets of data within a single table. For example, assume
two typical, asocial programmers are working on an enhancement to the billing system.
Jim is modifying the update transaction and Jane is creating a new report to go with
Jim's modifications. Jane sets up data for her test run, executes her report and obtains
output. Jim works in the next cubicle, but due to his antisocial tendencies is blissfully
unaware that his transaction uses the same tables as Jane's report. He runs his
transaction and updates the data. Jim got what he wanted, but Jane then modifies her
code and runs her program again. Her output differs from the last run, and the
differences many not result from her changes, but rather they may result from Jim's
changes. What we have here is a failure to communicate.

If the tables used by Jim and Jane's programs were client-dependent, they could each log
in to separate clients, set up independent sets of data, and test their programs without
ever talking to each other. They could perform all of their testing in the comfort of their
cubicles and in isolation from their coworkers. To make their table’s client-dependant,
they only need mandt as the first field and the R/3 system will take care of the rest.
When records are added to the table, the system automatically moves the current logon
client into the mandt field when the record is send to the database. Their Open SQL
select statements will only return rows where the client number in the table is equal to
the current logon client number. The Open SQL database statements insert, update,
modify, and delete also provide automatic client handling.

If the tables involved are all client-dependent, there can be more than one group of
testers working at a time in one test system. Two teams of testers can test divergent
functionality in the same set of programs at the same time provided they log on to
different logon clients. The updates done by one team will not change the data
belonging to the other team. All data resides in tables. To determine if a particular
table is client-dependent or client independent, the table structure needs to be
reviewed. The table structure can be viewed by the data dictionary (SE11). If MANDT
(client in German) is the first key field of the table, then the table is client-dependent;
otherwise, the table is client-independent.

When you log on to an SAP System, you log on to a particular client of this system. Any activities you
carry out in the system are always carried out in one client. When you plan your SAP system
landscape, you must consider which clients you need for which activities.

By assigning activities to be performed in a client, you give each client a particular role. This section
describes the most important client roles.

Since you need to adapt the SAP software for your own business needs, each SAP system landscape
requires a client where Customizing settings, and possibly ABAP Workbench developments, can be
made. This client is known as the Customizing and development client, or Customizing client for
short. The abbreviation CUST is used for this client.

Before you can use the Customizing settings and Workbench developments productively, you need to
test them extensively for errors. Any faulty settings can seriously disrupt productive operations, and at
worst, lead to the loss of productive data. The integrated nature of the various SAP applications
means that there are many dependencies between the different Customizing settings. Even an
experienced Customizing developer may not discover these dependencies immediately. The
correctness of the settings can only be guaranteed with extensive testing. The client where these
tests are made is the Quality Assurance Client, QTST for short.

A separate client is required for productive use of the SAP System. So that this client can be used
without disruption, it is essential that no Customizing settings or Workbench developments are made
here, and also that no tests are carried out. This client is known as the Production Client, PROD for
short.

These three clients, CUST, QTST and PROD, are the central clients that exist in every system
landscape. Standard system landscapes have precisely one client for each of these client roles.

We recommend that you make all your Customizing settings in a single Customizing client, and then
use the CTS to transport them to the other clients.

We also recommend that you do not make any Customizing settings or Workbench developments in
the quality assurance or production clients. You can make sure of this by making appropriate..

In addition to the central clients, you can also set up other clients for other tasks. However, you must
remember that each extra client takes up additional system resources (main memory and database
space). They also need to be administrated. For example, you need to set up and administrate
access authorization for the users, and also distribute any changes to other clients with the CTS. You
must weigh up the advantages and disadvantages of setting up other clients.

Examples of other client roles are:

Development test client (TEST): Developers can use this client to test their Customizing settings
and Workbench developments, before they release their change requests. In this client the
developers can create test application data for realistic tests. If they discover errors, they can remove
them in the Customizing client. A development test client is always set up in the same SAP System as
the Customizing client. This means that any changes that are made to cross-client data in the
Customizing client are also immediately visible in the development test client. Changes to client-
specific data are copied from the Customizing client to the development test client using a special
client copy function. The client copy function uses the unreleased change requests from the
Customizing client to do this. The development test client is set so that you cannot make changes to
Customizing data and Repository objects.

Prototype or sandbox client (SAND): You can use this client to test any client-specific Customizing
settings if you are not sure whether you want to use them in this form. Any settings that you want to
keep are then entered in the Customizing client. To prevent conflicts between the prototype client
settings and real settings in the Customizing client, you cannot make changes to cross-client
Customizing data and Repository objects in the prototype client. The CTS does not record changes
made to client-specific Customizing data, and does not transport them from the prototype client. You
can make sure of this by making appropriate client settings.

Training client (TRNG): To prepare end users for new functions that are to be transported into the
production client, you can set up a training client. The users can use the new functions in this client
with specially created application data. This client is set so that you cannot make changes to
Customizing data and Repository objects.

The system change option controls whether Repository objects and cross-client Customizing objects
are modifiable or not.

The system change option does not affect client-specific Customizing changes. To set whether these
changes can be made or not, go to Client Control. ( Client Control
You can use the Transport Organizer to record all changes to Customizing settings in change
requests and mark them for transport.
The transport of Customizing settings to another SAP System is prepared. You only need to release
the change request.

However, it is not always a good idea to record every single change made to the system. That is why
many SAP Systems have a test, training, or demo client in addition to the production client. Recording
changes is not appropriate here. In extreme cases, this could even result in unintentional transports
that could destroy the target client.

To meet these sometimes contradictory requirements, you can assign each client appropriate
attributes, which you can maintain in table T000 (transaction SM30):

 Role of the client: Indicates whether the client is a production, test, training, demo, or
Customizing client.

 Changes and transports for client-specific Customizing objects: You can specify for
each client whether you want the changes to be recorded. As with the system change option
in the Transport Organizer, changes can also be forbidden here altogether. You can make the
following settings:

o Changes without automatic recording

o Automatic recording of changes
o No changes possible
o Changes without automatic recording; no transports allowed

The setting selected for a client applies only to changes to its client-specific
Customizing settings, not to client-independent settings. The changes made to client-
independent Customizing settings are recorded together with the changes to
Repository objects and do not require a client-specific entry in table T000.

In a production client, client control does not influence the current settings
(Customizing activities that can be accessed directly from the application menu). You
can always change these settings in a production client; they are not recorded in
Customizing requests.

 Changes to cross-client objects: You can specify for each client whether you want to allow
changes to Repository objects and/or cross-client Customizing objects.

Different request types in the Transport Organizer allow you to distinguish between the two modes.
Changes to cross-client Customizing objects and to Repository objects are recorded in Workbench
requests; changes to client-specific Customizing objects are recorded in Customizing requests.

If you use only Customizing requests, you make sure that the results of a Customizing project can be
transported to the target client of another system without affecting other clients there.

In contrast, no guarantee can be given that the results of transporting Workbench requests will be
restricted to one client. In this case, the import must be checked to establish whether it includes any
cross-client objects. If such objects are found, we recommend that you adjust the corresponding
settings in the source and target systems in order to assess the affect on all other clients.

Other features that affect the client are:

 Flag that locks the logon procedure. It is set in the target client by the client copy program.
This means that no work may be carried out in the target client when client copy is in
progress.
 Only the users SAP* or DDIC are permitted to log on. Other regular users are warned with a
corresponding message when they attempt to log on.

 Protection against SAP upgrade means that the client is no longer provided with SAP
upgrades. Users can no longer work actively in the client after the system has been
upgraded. The flag can only be set for a test client or an SAP reference client (
EarlyWatch). This function is only intended for exceptional cases, when, for example, the
basis for an adjustment is needed after an upgrade has been performed. Every "normal"
client must be updated by an SAP upgrade, since otherwise data resources from system and
Customizing tables required for transactions may not be available. However, you can prevent
clients that need to contain certain tables purely for backup purposes (backup clients) from
being supplied with SAP upgrades that are not necessary or not wanted. To maintain this flag,
you require the administration authorization for the Transport Organizer (authorization
S_CTS_ADMIN).

 Restricted permission to execute CATT procedures. CATT (Computer Aided Test Tool) allows
you to restart recorded test runs repeatedly. This process changes the database and it is
therefore necessary to declare this as a property of the client. )

You can make more precise settings for Repository objects: each Repository object is in a software
component (

software component (BC-UPG)

Upgrade - General (BC-UPG)

Set of software objects that are grouped in development classes and can only be delivered together.

Typically, there are usually several release versions of a software component. These components are
updated by upgrades.

You can import Support Packages separately for each software component.

) and a namespace (

namespace (BC-CTS)

Change & Transport System (BC-CTS)

An ID assigned exclusively by SAP that allows SAP customers, SAP partners and SAP to develop
SAP components and products using SAP applications, without the danger of naming conflicts.
(Naming conflicts can occur during transports to external SAP Systems, or when importing external
products into your own systems.)

You assign objects to a namespace in the ABAP Workbench by placing the namespace prefix in front
of the object name. The namespace ID begins and ends with a delimiter ("/"), and can have up to 10
characters.

)or name range. (

name range (BC-CTS)

Change & Transport System (BC-CTS)

A subset of a namespace.

Typically, a name range is defined by an interval within a namespace. Instead of an interval, you can
also specify a generic string.

) For a Repository object to be modifiable, all the following settings need to be set to modifiable as
well:

 the global setting

 the software component of the object
 the namespace or name range

You can set the Repository objects in a particular software component to Modifiable, Restricted
modifiability or Not modifiable. Restricted modifiability means that you can create Repository objects
in this software component as non-original objects only.

Restricted modifiability is the same as Modifiable for packages.

You can set the Repository objects in a particular namespace to Modifiable or Not modifiable.

The SAP System logs this activity. Choose Log to display the settings log.

Prerequisites
To set the system change option, you require the administration authorization in the CTS. It is
contained in the delivered standard authorization S_CTS_ADMIN.

Procedure
To set the system change option, proceed as follows:

1. In the Workbench Organizer, choose Goto  Transport Organizer tools.

This takes you to the Transport Organizer tools overview.

2. Go to Administration and start the program Set System Change Option.

The Global setting option allows you to determine whether objects from the Repository or
client-independent Customizing are globally modifiable or not.

Only if the global setting is set to modifiable, can you set the system change option of the
software components and the namespaces and name ranges.

By choosing Edit  Namespaces modifiable and Edit  Own namespaces modifiable, you
can set the namespaces and name ranges to Modifiable for all objects or for your own
objects.

If you want to change the objects in your customer name range, set the software
components LOCAL and HOME and the customer name range to Modifiable. This
customer name range includes, for example, all reports beginning with Z or Y.

If you want to create or edit local objects in your SAP System, you must set the
software component LOCAL and the customer name range to Modifiable.