Cross-Client Customizing
The following requirements must be fulfilled for cross-client Customizing if an SAP product is to be considered as multiclient compliant.
A short description exists for all cross-client Customizing objects. This description tells you which function is realized by the object, and how the operator of a multiclient system must react to different requirements from competing clients. If needed, you can call up a list of all cross-client Customizing objects included in an SAP component.
When you operate a multiple client system, it is important to know which Customizing settings apply to all clients, since changes to these objects will always affect every client. This means that providers must know about the functions contained in all cross-client customizing tables maintained in their solutions, so that they can react to the competing demands made by multiple clients. Changes to these objects requested by a single customer can only be incorporated after synchronizing them with the settings in all other clients. The provider might need to define multiple Customizing settings to meet different requests, and then offer these settings to all customers.
A customer can assume that the client dependency requirement for application tables described under Client-Specific Data is fulfilled in the standard SAP delivery, and does not need to take any further action. However, the requirements of cross-client Customizing described in this section are also significant for customers.
Categorization by Usage Type
You can use system tools to help determine an object list. For a description of these tools, see Tool Support for Generating Object Lists. A list of cross-client Customizing objects is generated for a specified component (either software component or application hierarchy component). The objects are categorized by usage type to give you a better overview of which objects are relevant. The usage type is a very generic category that specifies whether the object has a more technical or more business nature. There are six different usage types.
The first two categories belong to the technical settings of the system or its infrastructure (system profile parameters).
Usage Category 1: System Parameters (SYP)
This category contains the settings of system profile parameters. These parameters tune the system to available resources and the technical infrastructure. These parameters have no effect on the business functions of the application.
Technical settings need to be made in contexts such as RFC destinations, client-server configurations, buffers, and the definition of the system clients themselves.
A special form of system profile parameters are those that cannot be changed by the customer, but which the customer is notified of during the IMG implementation of the system. These settings are flagged with the additional ID ro (read only), which makes the ID SYP-ro.
Usage Category 2: Technical Organizational Support (ORG)
These settings are needed for controlling technical processes. This includes all tasks involved in setting up network connections, and also the control parameters for background job scheduling.
The next two categories are closely related with programming logic. In some cases, the process flow control is extracted from the programs and stored in tables. This makes modifications much simpler. Some tables contain metadata for generating Repository objects.
Category 3: Control Data with Program Characteristics (PCH)
This category contains cases where the programming logic is stored in Customizing tables. This makes transaction logic more transparent, and easier for non-programmers to understand. This data is interpreted by the programs at runtime, and controls the responses of these programs. This not only simplifies modifications to the shipped SAP solution; by separating modified flow logic and coded programs, the effort required to restore modifications in update cycles is also reduced considerably. This contributes to a great reduction in costs.
These tables are usually cross-client because they have direct references to Repository objects. Control logic is only located in client-specific tables in exceptional cases, such as screen flow control or screen field control. In this cases, the process flow can be influenced on a client-by-client basis.
Category 4: Meta Data for Generating Repository Objects (MGR)
Some applications have extremely customer-specific functions and interfaces, and cannot be shipped as a complete, predefined system solution. One example is the area Condition Tables for Pricing. All these applications are shipped only as basis software, together with tools for tailoring the application to the needs of the customer. The software is modified using Customizing generation technology; during Customizing, software developer tasks are performed with automated support, but at a level close to the application. This approach makes it possible to adapt the software flexibly to individual applications that cannot be easily standardized, but still provide easy-to-use interfaces with high performance. The generation of program parts ranges from individual functions (reports, program modules) to entire subapplications (pricing, condition tables with dictionary objects, maintenance interfaces, and analysis programs).
Depending on the sensitivity of the data, or with regards to modified interfaces, you can also use client filters. For more details, see Supporting Individual Customer Requirements.
The last two categories represent globally valid rules and characteristics.
Category 5: Basic Business Standards (BBS)
These are fixed parameters for the business processes established in the installed system. These parameters complete the installed SAP solution and cannot be modified for each client.
Category 6: Global Entities (GLO)
These settings are usually independent of a specific enterprise, which means that they are independent of a specific client. Examples of this are currency definitions or municipality keys. This reduces the amount of work needed to operate a multiple client system, since the setting only needs to be made once in each physical system, and does not need to be repeated for each client.