You need to be familiar with central concepts of all SAP modules in order to

implement data transformations in SAP ERP. In this chapter we will introduce

the most important concepts and terms.

1   SAP  ERP:  Basics  

In this chapter we give you an overview of the most important concepts and
terms of the SAP ERP world. It would be wrong to expect to achieve this with-
in 10 pages in depth. SAP applications, most of all SAP ERP, are used to im-
plement all standardizable business processes in companies of all sizes and
industries. Even though the complexity needed to do this cannot be covered
within such a short chapter we want to give you an overview of relevant terms
and definitions. This will make it possible to understand the concepts in the
other chapters of this book.
In order to understand and implement data transformations using SAP LT it is
important to understand the integration within the SAP system: a transfor-
mation is not limited to a single application or module. It involves all data rele-
vant to certain business scenario of all SAP applications. We introduce these
concepts of different ERP modules and SAP applications within this chapter.

1.1   The  technical  basis  

The SAP-software-Stack SAP Netweaver is used to run the SAP ERP solution. SAP NetWeaver
This stack consists of several layers, but not all of them have to be provided by
SAP itself. The essential components are a database server running an operating
system and a database. One or several application servers running the SAP
software itself. These application are in most cases programmed in ABAP,
SAP’s own programming language. The task of the application server is to
process and run ABAP programs.
Users are working on their local PCs or laptops, usually using SAP GUI. This
user interface is also referred to as presentation server. This classical client /
server technology was used by SAP when implementing SAP R/3, making
SAP the first major software company using this technology in large scale.

Alternatives to SAP GUI

Many of the new SAP developments are not dependent on SAPGui as user
interface for the end user. In the course of the last years, many different tech-

1
nologies were built by SAP and gradually improved to enable access to SAP
applications using web browsers. Many SAP users criticize SAPGui for being a
bulky client with a footprint, rendering it into an outdated dinosaur. The new
web based technologies by SAP are:
§   BSP-Applications (Business Server Pages)
§   The SAP Business-Client, which was built as a simplified ERP user inter-
face for SAP all-in-One.
§   Web-Dynpro, a technology available for Java and ABAP
§   Fiori, a modern technology based on HTML5, which includes concepts and
technology to create user friendly applications.
Even though all these new technologies make working with SAP applications
easier, SAPGui remains the user interface of choice for experienced power
users. For administrating and running SAP systems SAPGui will remain to be
used in the coming years.
Data of SAP systems is stored in the central database of the database server.
SAP customers can choose the database technology to be used. Depending on
the business and the experience of data center employees or of the outsourcing
partner customers often choose a technology which is already available in their
company when implementing SAP to run their business processes. The SAP
software stack supports many databases:
SAP
SAP itself is offering three different database systems: MaxDB, ASE and since
some time SAP HANA.
˗   MaxDB has evolved from ADABAS and was purchased by SAP and is
distributed using different names by SAP (e.g. SAP-DB). The technolo-
gy was sold by SAP to mysql, but purchased back and renamed to
MaxDB some years later. You will find the abbreviation “ADA” fre-
quently In configuration files and profiles because of this turbulent histo-
ry.
˗   ASE is a classical SQL database which is related and similar to Mi-
crosoft’s MSS database, because both have evolved from the same code
base in the late 1980s. ASE is part of SAP’s portfolio since the acquisi-
tion of Sybase.
˗   HANA is SAP’s new and innovative in memory database.

2
§   Oracle
The database system most widely in use is still Oracle. The database is the
company’s flagship product. In memory extensions are available for Oracle.
§   IBM
IBM offers classical SQL databases with the DB2/DB4/DB6-software fami-
ly. DB2 Blue is a in-memory database by IBM.
§   Microsoft
MSS (Microsoft SQL Server) is the database available from Microsoft. This
technology has evolved from the same root as SAP’s ASE, but heavily was
optimized and improved by Microsoft. While other databases are available
for various operating services, MSS is available exclusively for MS Win-
dows.

1.2   The  Client  

When logging on the SAP system using SAPGUI you have to specify a user
name and a password as well as the client number. This number is a three digit
code which is sometimes referred to as the highest organizational unit in SAP.
In this section we want to explain the underlying concept. This is important for
data transformation scenarios because this concept influences the way of trans-
forming data.
All data in the SAP database can be categorized into several groups. All appli-
cation data is client dependent. When logging on the system the SAP user
chooses the client in which he will be working. The client concept clearly di-
vides data into several clients, where users logged on to a client cannot see the
data of other clients. This way, several datasets can coexist within one SAP
system.
The technical solution for this is usually that the first key field of the database
tables is the client number. This way, the data of client dependent tables is sep-
arated into separate datasets. The Open SQL interface of SAP is built so that
ABAP SQL statements automatically add the client field and use the client a
user is working in. This way, data of other clients is invisible for SAP end us-
ers.

The client concept

Clients in SAP systems are defined in the customizing table T000. Usually
several clients exist in SAP systems, even when only one client is used produc-

3
tively. Client 000 is used for administrating SAP systems. The client 066 is a
SAP client which is used in the context of the Earlywatch-Service. The client
with production data is defined by the SAP customer in the initial SAP imple-
mentation within the company.
Application data within a SAP client is not visible for users of other clients.
Therefore, clients can be used to keep and use datasets separately.
Numerous tables containing primarily technical information exist in any SAP
system, e.g. for storing the source code of ABAP programs. These tables do not
contain a client field and therefore are client independent. This is mostly the
case for technical tables without a business background or purpose.

1.3   Customizing  
Settings and configuration which adjust the SAP system to the requirements of
a company are called Customizing. Such settings are stored in so called custom-
izing tables. Naturally, the majority of these tables is client dependent because
the data used to adjust and configure the SAP system is business driven and
may differ between different clients. However, there are both client dependent
and client independent customizing tables. The latter usually contain technical
settings of the SAP system. There are a few areas which are exceptions to this
rule. Factory calendars for example are stored client independent.

Naming conventions for customizing tables

The naming convention for customizing tables in SAP systems is such that they
start with the letter “T”. Company codes for example are stored in table T001.
For historical reasons tables starting with the prefix “T9” are defined customiz-
ing tables and are similar to the “Z”-name space. Such tables mostly originate
in the R/2 era and are therefore a rare thing in these days.
The way how data is stored in SAP systems, especially with regards to the sep-
aration between client dependent and independent data is described in depth in
chapter 8 of this book. This chapter is dedicated to system consolidations where
naturally data needs to be moved and merged between clients within one or
across several SAP systems.
Client dependent data contains system settings (customizing), but also master
data, transactional data and so-called “current settings”. We will introduce these
concepts in the following sections.

4
1.4   Master  and  transactional  data  
Master data in SAP ERP is data which is the foundation for transactional data
created by business transactions. Postings require master data as basis. Some
examples for important master data objects are:
§   Customers
§   Vendors
§   Business partners
§   Materials
Master data usually consists of several segments. The A-segment contains the
general data of the objects. For a customer, this is for example the name of the
customer. Other segments contain organizational dependent data.
A customer may have one or more B-segments containing company code de-
pendent data. Vendor master data is stored very similar to customers and also
have B-segments. Additionally, purchasing relevant data exists for vendors
while customers have data concerning their credit control data and payment
terms.
Material numbers do not contain a B-segment as no company code relevant
data is required for them. Instead, materials have C-segments which contain
plant relevant data.
Any kind of posting is referred to as transactional date . Examples are:
§   Finance postings, e.g. invoices to customers
§   Deliveries
§   Purchase requisitions, purchase orders, and scheduling agreements
§   Contracts
§   Offers
Master data is “created” by SAP users, while transactional data is “posted”.
Number ranges determine the numbering of transactional data. Number range Number ranges
objects are defined and used in the various SAP modules and applications. The-
se number ranges determine the continuous numbering of postings like FI doc-
uments, purchase orders, or customer orders. These number ranges are defined
in the SAP system’s customizing and transported into the production system.
Number ranges for transactional data are usually defined with internal number-
ing, meaning that the SAP system will automatically the next free number for
new postings. The current level of the number range is then automatically in-
creased to store the level as preparation for the next posting.

5
Number range objects are also used for the numbering of master data. However,
such objects are sometimes used with internal numbering and sometimes with
external numbering. Such external numbering means that the number can be
freely selected by the SAP user. Such a number must of course fit into the
number range and must not be used yet when new data is created. Number
ranges may include numbers and letters, thus making the naming of master data
and transactional data very flexible.
Current settings are a hybrid between customizing and master data. While cus- Current settings
tomizing is generally done in a development system and subsequently trans-
ported with a transport request into productive SAP systems, master data and
transactional data is created by users in the production system.
Current settings can be created in a development system and moved to produc-
tion using transport requests, or such data may be created directly on the pro-
duction system. Such data includes for example the definition of cost centers.

1.5   Organizational  units  

The customizing of SAP systems is determined and initially created in the SAP
ERP implementation project. All settings in the configuration of the SAP ERP
system are created in this phase to adjust the system to the business processes
and the organizational structure. Part of this customizing is the organizational
structure. In this section we introduce the most important organizational units.

6
Figure 2.1: Hierarchy of organizational units in SAP ERP

Figure 2.1 illustrates the organization of a business in SAP ERP graphically as

a tree structure. We explain details to these organizational units in the following
paragraphs.
§   Company code
Company codes represent legal entities with a balance sheet and P&L.
Company codes are the basic organizational unit used in the FI-module (ex-
ternal accounting). A company code is represented by a four character al-
pha-numerical code name in the SAP system. Usually, most customers are
using purely numerical company codes. The customizing associates a de-
scriptive name with the four digit code – this is generally true for all organi-
zation units.
§   Depreciation area
Depreciation areas are used in asset accounting. Strictly speaking, these are
not organizational units. Instead, they implement and reflect different legal
and accounting standards to store the values and depreciation of the assets of
a company (e.g. buildings, a company car fleet, machinery, …).

7
§   Business area
Business areas are organizational units, which can be used optionally in ex-
ternal accounting. Business units have their own P&L sheet. However, this
sheet is only used internally. Segments of different company codes can be
combined into one business area.
§   Controlling area
Controlling areas group several company codes and are used in the CO
module for controlling purposes (i.e. internal accounting). All company
codes assigned to the same controlling area have to match in their basic cus-
tomizing settings. They have to be created using the same chart of accounts
and the same fiscal year variant. The reasons for this are obvious: the chart
of accounts defines the general ledger accounts used for postings within the
company codes. These accounts are represented as primary cost elements in
the controlling module. Secondary cost elements can be added to the con-
trolling area to extend the granularity of controlling, but these cost elements
will only exist in CO without a corresponding account in FI.
§   Cost centers and profit centers
Cost centers and profit centers are organizational units in controlling. Both
are linked directly to controlling areas. Their definition is time dependent,
meaning that their definition may differ based on time slices (e.g. the person
responsible for a cost center may change from year to year). The names of
these organizational units are not necessarily unique within the SAP system:
their numbers alone do not define the cost center. The number of a cost cen-
ter or profit center is only complete when used in combination with a con-
trolling area. This is not the case for other organizational units, e.g. the
number of a company code is unique by itself within a client of a SAP sys-
tem. 10 characters are available for the technical names of cost centers and
profit centers.
§   Operating concern
Controlling areas are grouped into operating concerns. An operating concern
is an organizational unit used in the CO-PA module (profitability account-
ing). This module can analyze the profitability of market segments. Four
digit codes are available to name operating concerns, similar as for control-
ling areas and company codes.
§   Valuation area

8
 Valuation areas are organizational units used for logistics. Sometimes they
are confused with depreciation areas in asset accounting as in some lan-
guages the names tend to be similar. A valuation area groups several plants
including their storage locations. Usually, all plants defined within one
company code are grouped into one valuation area. The code names of valu-
ation areas within SAP ERP can have four characters. A valuation area col-
lects the values of stocks from different plants and storage locations.
§   Plant
Plants are the most important organizational units used in logistics. Several
plants can be assigned to a company code can via valuation areas in between
the company codes and the plants. Plants contain storage location. Like for
most organizational units, the code names of plants are defined with 4 char-
acters.
§   Storage location
Storage locations are defined dependent on plants. Similar as with cost cen-
ters, the technical name of a storage location is only fully defined in combi-
nation with its plant. Stocks are being kept in the MM module based on
storage locations.
§   Purchasing organization
Purchasing organizations are used in module MM-PUR (purchasing). They
are used to obtain materials or services from vendors. Purchasing conditions
are negotiated with vendors, and based on these purchase requisitions can be
used to trigger purchase orders or scheduling agreements. Purchasing organ-
izations can be used across company codes or for single company codes. It
is also possible to set up a purchase organization for single plants.
§   Sales organization
Sales organizations in the module SD (Sales & Distribution) are used to or-
ganize selling finished goods or services to customers. Distribution channels
and divisions are created and assigned to sales organizations. Divisions are
used to group materials into product groups. Divisions allow for separate
conditions and pricing agreements with customers as well as for reporting
on division level to generate detailed sales statistics and marketing activities.
Divisions have a two character technical name while for the naming of sales
organizations four characters can be used. Sales organizations are linked to
single company codes.
§   Sales area

9
 Sales areas provide a very granular way of structuring sales and distribution.
They are defined as a combination of sales organization, distribution chan-
nel, and division.
§   Personal area
Employees are organized into personal areas within the HR (Human Re-
sources) module. Such personal areas are linked to company codes. Em-
ployees changing their employment within the company (i.e. from one per-
sonal area to another one) are sometimes an important topic within trans-
formation projects. Data within several personal areas will exist for such
employees.
Table 2.1 provides an overview of the most important organizational units with-
in SAP and where to find them in the customizing of the ERP system.
Organizational Mod- International Cus- Linked to
unit ule names tomiz- organization-
ing ta- al unit
ble
Company Code FI Buchungskreis T001 Controlling
(DE) area
Code société (FR)
Business Area FI Geschäftsbereich TGSB Company code
(DE) / controlling
Domaine area
d´activité (FR)
Controlling area CO Kostenrechnung- TKA01 Operating
skreis (DE) concern
perimètre ana-
lytique (FR)
Cost Center CO Kostenstell (DE) CSKS Controlling
Centre de coûts area
(FR)
Profit Center CO Profit Center CEPC Controlling
(DE) area
Centre de profits
(FR)

10
Operating con- CO- Ergebnisbereich TKEB
cern PA (DE)
périmètre de ré-
sultat (FR)
Valuation Area MM Bewer- T001K Company code
tungsbereich
Plant MM Werk (ENDE T001W Valuation area
Division (FR)

Storage Loca- MM Lagerort (DE) T0011 Plant

tion Magasin (FR)
Purchasing Or- MM- Einkaufsorganisa- T024E Plant, compa-
ganization PUR tion (DE) ny code, con-
trolling area
Sales Organiza- SD Verkaufsorganisa- TVKO Company code
tion tion (DE)
Organisation
commerciale (FR)
Division SD Sparte (DE) TSPA Sales organi-
Secteur d'activité zation
(FR)
Tabelle 1.1: Organizational units within SAP systems

This table also contains German and French terms for these organizational
units. Experience shows that it helps a lot in international projects to be familiar
with the terminology also in different languages to avoid misunderstandings.
For example, the French term for plant is division, which is the English term for
German Sparte. Being aware of such terminology helps to ease the communica-
tion with customers and colleagues.
Furthermore, the table includes the header table within the SAP system’s cus- Customizing
tomizing which stores the definition of the organizational unit. Knowing these
helps when you are forced to get a fast overview of a customer system (even
with limited authorizations or within the development system only) because the
data is easily available in SE16. Such tables help to gain quick insights into
countries, regions, or other organizational units within the system. When creat-
ing or changing customizing, the transaction SPRO is used in the development
system of the SAP system landscape (see figure 2.1).

11
Figure 2.2: Definition of organizational units within the SAP customizing
transaction SPRO.

Unfortunately there is no easy way within the SAP ERP system to quickly gain
a fast, graphical representation of the hierarchy of organizational units as de-
fined in the SAP system’s customizing. To get an overview, you need to collect
the data either using the Data Browser (transaction SE16) or better using a
ABAP program to collect & display the data. This is not a difficult challenge; a
simple ABAP program can achieve this task in any customer system. Such a
program should always be readily available within the “tool box” of ABAP
programs of any data transformation consultant.
Figure 1.2 illustrates with an example how such a program can look like. You
can find the program from which the screen shot was taken in the download
area for this book. We also give some help on installing the program in your
SAP system.

12
Figure 2.3: Graphical representation of the SAP organizational structure as
tree using a custom ABAP program.

We will show you the possibilities of SAP LT for changing the organizational
structure in SAP systems in the following chapters. You will be able to use this
chapter as a reference for looking up basic concepts when going through the
following chapters whenever required.

   

13