SAP-003-Integration Configuration YR YB

Teach yourself series
SAP®
Cross-Application
Integration Made
Easy
www.justaclick.info
SAP-003 -Integration Made Easy
Integration Made Easy

The integration of the various modules within SAP is sometimes an area where design and
configuration is the weakest. As you might be aware of, the project teams are often divided into
sub-teams by modules which results in inadequate attention being paid the way that the
modules need to work together.
Problems occur for a number of reasons:
• SAP analysts sometimes lack the big picture view of the total business requirements
• There is an inadequate understanding of the
o Impacts that decisions in their modules may have on other modules, and
o The demands that requirements in their area may make on other areas
The key integration areas between the SAP modules are:

• Organization structure
The representation of the enterprise in the SAP modules and definition of relationships
between elements in the various modules
• Periodic Processing and Integration
• Automatic Account Determination
The definition of how and to what level of detail the modules should post through to the
GL accounts. You may see more information in ‘Automatic Account Determination’ e-
book available at ebay.com at
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=110204009553
• Account assignments
This relates to the daily or ad-hoc transactions, primarily from financial accounting to
controlling.
Page 2 of 20
Visit my eBay store for more e-Books on SAP
Organisation structure / relationships between elements in across modules
It is presumed that you are familiar with the various organizational elements across modules. In
case, you are not familiar with the organisation elements and master data, it is recommended
that you review those sections first before proceeding further. You may however, take a look at
the following to have basic understanding of the organization structure.
The FICO organizational elements and their relationships can be depicted as under:
Similarly, the Logistics organization elements and their relationships can be depicted as under:
Page 3 of 20
It is not just the elements that SAP defines as organisation elements (SAP Customizing
Implementation Guide>Enterprise Structure>Definition) that we use to represent our
organisation, but also master data. This means that although the " SAP Customizing
Implementation Guide>Enterprise Structure> Assignment " section is our first point of call, when
considering integration, there is more to it:
• Direct assignment of Relationships
Page 4 of 20
• Indirect Assignment by Substitution or by Master Data (Not all organization element

fields shown on master data control relationship integration - for example orders have
requesting costs centres primarily for grouping and reporting purposes.)
• Periodic Integration:. This may seem like a strange reference for this chapter, because
people expect to see up-front definition or assignment of relationships. However some
mappings are actually done in SAP under the 'Periodic Processing' menus or
configuration.
Representing your Organisation Structure in SAP
At the start of any project one of the first and most important things to be done is that your
current best guess of your businesses organisation structure must be configured in the SAP
System. The sooner you do this and the more accurately you do this, the quicker and better the
project team can get on with prototyping or configuring the rest of the system. Some
functionality is quite dependent on which SAP organisation elements you chose to represent
various aspects of your organisation. So to avoid wasting too much time, it is very important to
get appropriate skills working on this design ASAP in order to ensure that the initial
configuration is reasonably appropriate.
Each module of SAP tends to have its own organisation elements, although some are shared
across modules (plant, division etc).
The organisation structure decisions and issues are presented as:
• Key SAP Organization Elements / Structures

• SAP Master data which represents the Organization Structure
• Flexibility Considerations - designing for or understanding the implications for
organizational change after "go live".
Key SAP Organisation Elements / Structures:
Following is a summary of the key elements for organisation structure and functionality
decisions.
Page 5 of 20
Element Owning Module Brief Description
Company Code FI Mandatory, used for lowest legal entity
Business Area FI Optional, used for sub or cross company Balance Sheet
reporting
Profit Centres CO-PCA Optional, used for profit and return on investment
reporting. See also module decision on CO-PCA vs CO-
PA.
Cost Centres CO Mandatory for responsibility level overhead expense

reporting
Sales Areas SD Mandatory, actually a combination of the SD elements:

Sales Organization, Distribution Channel and Division
Purchasing MM Mandatory - could be just one. See R/3 library.

Organization
Relatively "Uninteresting" SAP Organisation Elements:
Several SAP organisation elements are required purely as the top node of the module providing
an ‘environment’ under which a single set of data exists. Data can usually not be shared across
these 'top node' elements. These elements are usually invisible to the users and can often be
excluded from training or explanatory diagrams.
These elements are:
Controlling Area CO - Controlling
Operating Concern CO-PA - Profitability Analysis
Financial Management Area TR - Treasury
Credit Control Area FI-AR & SD (Credit Management)
Page 6 of 20
SAP Master Data which represents the Organisation Structure
In controlling, the Cost Centre and Profit Centre Hierarchies are also used to represent the
organisation or enterprise structure. SAP considers these as 'master data' though not as
organisation elements. Therefore maintenance of these is not found in the Enterprise Structure
area of the IMG.
Organisation Structure issues relating to these are presented in two sections:
• Use of Profit Centres to provide some balance sheet information

• Cost Centres and Profit Centres
The important question is: Do you need both?
Direct Assignment of Relationships
These are all the organisation structure relationships that are directly assigned in the SAP
configuration (SAP Customizing Implementation Guide>Enterprise Structure>Definition).
It may not look like it, but this is actually quite easy except for a couple of areas with a lot of
flexibility (and remember: flexibility = complexity). These relationships can further be divided
into:
• Core / essential relationships that you should understand or address as a first priority
and the
• Secondary relationships (or module specific) ones you can worry about later if you need
to.
We have also grouped the relationships in what we hope is more logical (since FI is where most
of the integration is heading (because of the financial postings). We have sorted by FI elements
and listed them first. Apart from that you should still be able to follow along fairly easily in the
IMG:
Page 7 of 20
Table of Direct Organization Structure Relationships

SAP Customizing Implementation Guide>Enterprise Structure>Definition / Assignment
Module/ module Element 1 Element 2 Relationship Comment
Core or Primary Relationships:
Financials, Controlling, Treasury
If you have complex currency /

organization reporting
requirements then you should
Company Controlling many to probably read the IMG help
FI / CO
code Area one carefully and test out your scenarios
before you get too far down the
track. Refer to Appendix-1 for more
details.
Even if you are not really using

Financial Treasury, you may want to assign
Company many to
FI / TR management this to use the Basic functions
code one
area (useful if using AR, AP and doing
banking)
Controlling Operating many to

CO / CO-PA Only required if using CO-PA
Area Concern one
many to All company codes assigned to the

Financial one, usually controlling area must also be
Controlling
CO / TR management only one assigned to the Financial
Area
area each Management Area. Required if
though costs etc needed in TR.
Logistics (Materials Management and Sales and Distribution)
Required so the system knows

Company many to
LO / FI Plant which legal entity to post financial
Code one
stock values.
Page 8 of 20
Sales Company many to

SD / FI
Organization Code one
Distribution Sales many to

SD / SD
Channel Organization many
Sales many to
LO / SD Division
Organization many
This is a unique setup. A sales area

is not a new organization element,
but defines a valid combination of
Sales Organization / Distribution
Many to Channel / Division. This is how you
SD / SD Sales Areas
many control what products can be sold
by what methods of delivery and by
which selling groups. This also has a
significant impact on the customer
master data requirements.
Optional - if the company code is

not assigned it will be determined
from the plant. This allows the
many to
Purchasing Company setup of purchasing responsibility
MM / FI many or
Organization Code
none • Corporate wide
• By company or
• By plant
Human Resources
Required so the system can post

Personnel Company many to financial impact of HR postings.
HR / FI
Area Code one Note that personnel areas in
different countries cannot map to
Page 9 of 20
the same company code. It is usual

that different countries would have
different company codes (legal
entities) anyway.
Secondary Relationships:
Financials, Controlling and Integration with FI/CO
Optional
Useful for financial statements by
Company (group) many to
FI group company; however can also
code company one
just use ranges or selections of
company codes.
Optional
Required only when using credit
Company Credit many to
FI management or creating the credit
code Control Area one
management section of the
customer master.
Business Consolidation many to Only required if using the

FI / EC-CS or FI-LC
area business area one consolidation modules.
Here you have great flexibility =

some complexity - worthy of a
separate SD/Business Area page to
explain what's possible. Briefly for
Depends on each Sales Area you could specify :
Business rules chosen many to
FI / SD
Area (Rule 1) for each one • Rule 1: By plant and division
Sales Area • Rule 2: By sales area

• Rule 3: By sales
organization, distribution
channel and item division.
Note that the item division
Page 10 of 20
could be different from the

Division in the Sales Area.
Divisions are a little
'strange' in Logistics - they
have either a sales SD
emphasis or a product MM
emphasis.
If Valuation Only required to enable automatic

Level = business area account assignment.
Company If you are valuing stocks at a
Business many to
LO / FI code, then company code level, you can map
Area one
Plant / each plant to a business area. Note
Valuation the Valuation Area is then the
Area company code.
Only required to enable automatic

If Valuation business area account assignment.
Level = Business many to If you are valuing stocks at a plant
LO / FI
Plant, then Area one level, you can map each plant and
Plant division (essentially groupings of
products) to a business area
Logistics / Sales and Distribution
Optional. Used as defaults only.

many to
SD / SD Sales Offices Sales Areas Note sales office is usually a
many
geographical distinction.
Optional. Sales groups are

many to
SD / SD Sales Groups Sales Offices responsibility groupings rather than
many
geographic.
Sales many to Essentially defines which selling

LO / SD Plants
Organization many organizations can sell, by which
Page 11 of 20
/ Distribution methods out of which plants

channel
Shipping many to Defines which plants can ship from

SD / LO Plants
Points many which locations
Materials Management
Allows a variety of purchasing

Purchasing many to
MM / MM Plant responsibilities and gives control
Organization many
over who can buy for where.
Standard or The system will use the information

Reference one to associated with this purchasing
MM / MM Plant
Purchasing many organization for source
Organization determination of materials.
Allows use of the contracts etc

Standard or
negotiated by this purchasing
Purchasing Reference many to
MM / MM organization as a reference if
Organization Purchasing one
another purchasing organization is
Organization
buying.
Plant / Defines which storage locations are

Warehouse
WM / IM Storage one to one controlled by the warehouse
number
Location management system.
Plant Maintenance
Maintenance Defines which plants do the

Maintenance many to
PM / PM Planning planning of maintenance for other
Plant one
Plant plants.
Human Resources
Employee Employee many to Determines the valid combinations

HR / FI
subgroup Group many for the country groupings
Page 12 of 20
Determining the FI Business Area from SD
There are 3 ways of determining the business area for an SD posting that is trying to post to FI
(i.e. when the system does the revenue account determination. You can define a different way
for each SD Sales Area. This means that you first have to tell the system which 'rule' you want to
use for which Sales Area.
Module/ module Element 1 Element 2 Relationship Comment
Business Plant /
FI / SD one to one Rule 1: By plant and division
Area Division
Business
FI / SD Sales Area one to one Rule 2: By sales area
Area
Rule 3: By sales organization,

distribution channel and item
Sales division. Note that the item division
Business Organization, could be different from the Division
FI / SD one to one
Area Channel and in the Sales Area. Divisions are a
item Division little 'strange' in Logistics - they have
either a sales SD emphasis or a
product MM emphasis.
For example, we could have the following configuration:
Sales Area (Sales Organization, Channel, Rule Plant or Business Area

Division) Division
1000, 01 (internet), 01 (books) 2 (sales area) n/a INET
1000, 01 (internet), 02 (music) 2 (sales area) n/a INET
ELNS
1 (Plant /
2000, 02 (retail), 03 (electronics) Sydney (Electronics in
division)
Australia)
Page 13 of 20
ELVC
Korea (Electronics in
Korea)
3 (Sales
SPEC
Organization / all item
2000, 03 (wholesale), 05 (specialty products) (Specialty
Channel / Item divisions
Products)
Division)
It may look complex and cumbersome, but it will only be so if you have a complicated business
and of course you want to have business areas. If you have a fairly homogenous organisation,
then at worst you will have to put several partially repetitive entries in the configuration table.
With a bit of luck and a stable organisation you will never have to come back to this!!
Indirect Assignment of Relationships
In addition to the organisation structure relationships that are directly defined in the Enterprise
Structure / Assignment section of the IMG, there are further ways that one may need to define
these relationships. These definitions are still done in the IMG, but are buried in a module
somewhere. These are module specific: i.e. only required if one is using that module.
• Profit Center Relationships

• Relationships created in CO-PA (Profitability Analysis)
Note that pure master data relationships and account determination configuration is covered in
other chapters.
Profit Centre Relationships
When one is using profit centre module and the various logistics modules, then one has to
define the relationships in IMG / Enterprise Controlling / Profit Centre Accounting / Assignments
to Profit Centres. However before we get too deep into that...
Page 14 of 20
• If you are using SD and not using CO-PA (Profitability Analysis) either instead of or in
addition to Profit Centers you should have a good business reason. Please see my
chapter on Profit Centers vs. CO-PA for more information.
• If you are not using SD and using EC-PCA (Profit Centers) for Profit Reporting only, then I
suggest you read my chapter on Profit Reporting
Table Describing how transactions and balances are assigned to profit centres
Element /
Module Comment
Item
any One of your first steps in PCA configuration is to define the dummy profit
Default unassigned center. If the system at any stage cannot identify a profit center from
item your configuration, then it will post to the dummy profit center instead.
The first time you do anything in CO (IMG or user menu), the system will
Controlling prompt you to choose a controlling area. This defines the environment
CO
Area for all further CO work. All profit centers will therefore be created
relative to one and only one controlling area.
The profit center is defined on the material master record in the Sales:
General/Plant Data or Storage views. There are tools to do 'fast
assignment' of material masters by plant and then by material type, a
material group or a product hierarchy. See IMG.
Plant /
These assignments are used :
Material
(see Sales • to propose a default profit center when you create a sales order
MM
Order item or a production order (to eventually post the revenue or
substitutions costs); or
too) • to derive the profit center from the material master for internal
goods movements (such as stock transfers or goods issues) and
profit-related postings in Materials Management (such as
inventory differences) if no other assignment is available; or
• When material stocks (raw material, finished and semi-finished
Page 15 of 20
goods) are transferred to Profit Center Accounting (PCA can do

some balance sheet item reporting at period end).
The sales order default is taken from the profit center on the delivering
plant / material master combination. If you do not want this, you can
define substitutions to override this. A substitution is basically where the
Sales Order
SD system allows you to specify your own piece of conditional logic to
substitutions
determine which profit center to post to. You can base your conditions
on a variety of fields available on the Sales Order. Usually used if you
want to base your mapping on Sales elements rather than on products.
The next 4 menu options in the IMG are to do with assigning an

individual business transaction to the profit center. This is something
Business that should happen at the time of entering the business transaction if it
Transactions cannot be determined from the default. Therefore for configuration
purposes, it is suggested that you ignore the "assign to sales orders,
production orders, process orders, CO Production orders".
Master data The next 6 menu options in the IMG relate to master data assignment to
assignments: a Profit center. Basically the profit center should be assigned when you
create the master data record. Some special comments :
If not done manually, there is a 'create profit centers' from cost centers
program which will create an equivalent hierarchy for you - only really
possible at start up of the system - thereafter manually maintained. I
suggest that if you do have such a one to one mapping then the following
is probable:
Cost Center
• You have too many profit centers or not enough cost centers -
their business definition should be different
• If you are not using SD, then maybe you don't need profit
centers?
Fixed Assets Implicitly assigned by assigning every asset to a cost centre.
Page 16 of 20
Assignments needed for Balance Sheet Items in Profit centers
System will determine from the assignments made on the Sales Order -
FI AR Debt
similar to business area processing.
are assigned to the profit center of the material ordered for purchase
FI AP Payables orders to warehouse and to the profit center of the posting for orders
which receive direct postings.
Other
Balance The profit center is actually specified by individual GL journal line item
FI Sheet Items (like the business area). It is not possible (other than by substitution) to
not in a sub- assign a GL account to a profit center.
module
Work in
CO Assigned via the relevant project or order.
process
AM/IM Assets Implicitly assigned by assigning every asset to a cost center.
Material
MM Assigned to profit centers via their master records (see above)
stocks
Relationships created in CO-PA (Profitability Analysis):
In CO-PA it is possible to 'derive' relationships for use in CO-PA. This could be useful for
groupings that are only required for CO-PA reporting. The derivation could be of entirely new
elements or fields that are not being used elsewhere, or perhaps using an existing SAP field that
is not being used by other modules. The derivation can be based on any or a combination of
fields in the data that is being passed to CO-PA. A sophisticated example might be a derivation
based on the SD Customer hierarchy. It is not a good idea to try 'overwriting' values assigned in
other modules as this would be confusing and complicate any reconciliation attempts. See the
configuration documentation on CO-PA for more information. Note that there are 'standard
derivations' that the system does too. We were talking here about creating new derivations.
Page 17 of 20
The sales order default is taken from the profit center on the delivering
plant / material master combination. If you do not want this, you can
define substitutions to override this. A substitution is basically where the
Sales Order
SD system allows you to specify your own piece of conditional logic to
substitutions
determine which profit center to post to. You can base your conditions
on a variety of fields available on the Sales Order. Usually used if you
want to base your mapping on Sales elements rather than on products.
The next 4 menu options in the IMG are to do with assigning an individual
business transaction to the profit center. This is something that should
Business happen at the time of entering the business transaction if it cannot be
Transactions determined from the default. Therefore for configuration purposes, it is
suggested that you ignore the "assign to sales orders, production orders,
process orders, CO Production orders".
Master data The next 6 menu options in the IMG relate to master data assignment to
assignments: a Profit center. Basically the profit center should be assigned when you
create the master data record. Some special comments :
If not done manually, there is a 'create profit centers' from cost centers
program which will create an equivalent hierarchy for you - only really
possible at start up of the system - thereafter manually maintained. I
suggest that if you do have such a one to one mapping then the following
is probable:
Cost Center
• you have too many profit centers or not enough cost centers -
their business definition should be different
• if you are not using SD, then maybe you don't need profit
centers?
Fixed Assets Implicitly assigned by assigning every asset to a cost center.
Assignments needed for Balance Sheet Items in Profit centers
FI AR Debt System will determine from the assignments made on the Sales Order -
Page 18 of 20
similar to business area processing.
Are assigned to the profit center of the material ordered for purchase
FI AP Payables orders to warehouse and to the profit center of the posting for orders
which receive direct postings.
Other
Balance The profit center is actually specified by individual GL journal line item
FI Sheet Items (like the business area). It is not possible (other than by substitution) to
not in a sub assign a GL account to a profit centre.
module
Work in
CO Assigned via the relevant project or order.
process
AM/IM Assets Implicitly assigned by assigning every asset to a cost centre.
Material
MM Assigned to profit centers via their master records (see above)
stocks
Page 19 of 20
Appendix-1
Essentials of Company Code-Controlling Area Assignments
Controlling area -Company 1:1 assignment 1: many assignment

Code assignment (cross Company Code cost
accounting)
Chart of accounts The chart of accounts should be The ‘operative chart of
the same between the controlling accounts’ of the Company
area and the Company Code Codes, and the controlling
area should be the same
Fiscal year variant (special The number of special periods may be different, between the
and posting periods) Company Code and the controlling area, but the number of posting
periods should be the same.
Also, the period limits of posting periods should be identical.
Controlling area currency Same as that of the Company You may use the same
Code currency currency as that of the
Company Code
You may also use another
currency in controlling
Object currency Additional currency, besides the You can choose any object
controlling area currency, can be currency if all the assigned
used for each account assignment Company Codes have the
objects in CO. same currency which is same
as that of the controlling area
currency. Else, the system
automatically assigns the
Company Code currency to
the account assignment
object as an object currency.
Transaction currency Documents are posted in CO in the transaction currency.
Allocations Cross Company Code cost Cross Company Code
allocation in CO is not possible allocation in CO is possible
Page 20 of 20

SAP-003-Integration Configuration YR YB

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

SAP-003-Integration Configuration YR YB

Transféré par

Droits d'auteur :

Formats disponibles

Teach yourself series

Integration Made Easy

Problems occur for a number of reasons:

The key integration areas between the SAP modules are:

Organisation structure / relationships between elements in across modules

• Indirect Assignment by Substitution or by Master Data (Not all organization element

Representing your Organisation Structure in SAP

The organisation structure decisions and issues are presented as:

• Key SAP Organization Elements / Structures

Key SAP Organisation Elements / Structures:

Element Owning Module Brief Description

Company Code FI Mandatory, used for lowest legal entity

Cost Centres CO Mandatory for responsibility level overhead expense

Sales Areas SD Mandatory, actually a combination of the SD elements:

Purchasing MM Mandatory - could be just one. See R/3 library.

Relatively "Uninteresting" SAP Organisation Elements:

Controlling Area CO - Controlling

Operating Concern CO-PA - Profitability Analysis

Financial Management Area TR - Treasury

Credit Control Area FI-AR & SD (Credit Management)

SAP Master Data which represents the Organisation Structure

Organisation Structure issues relating to these are presented in two sections:

• Use of Profit Centres to provide some balance sheet information

The important question is: Do you need both?

Direct Assignment of Relationships

Table of Direct Organization Structure Relationships

Module/ module Element 1 Element 2 Relationship Comment

Core or Primary Relationships:

Financials, Controlling, Treasury

If you have complex currency /

Even if you are not really using

Controlling Operating many to

many to All company codes assigned to the

Logistics (Materials Management and Sales and Distribution)

Required so the system knows

Sales Company many to

Distribution Sales many to

This is a unique setup. A sales area

Optional - if the company code is

Required so the system can post

the same company code. It is usual

Financials, Controlling and Integration with FI/CO

Business Consolidation many to Only required if using the

Here you have great flexibility =

Sales Area • Rule 2: By sales area

could be different from the

If Valuation Only required to enable automatic

Only required to enable automatic

Logistics / Sales and Distribution

Optional. Used as defaults only.

Optional. Sales groups are

Sales many to Essentially defines which selling

/ Distribution methods out of which plants

Shipping many to Defines which plants can ship from

Allows a variety of purchasing

Standard or The system will use the information

Allows use of the contracts etc

Plant / Defines which storage locations are

Maintenance Defines which plants do the

Employee Employee many to Determines the valid combinations

Determining the FI Business Area from SD

Module/ module Element 1 Element 2 Relationship Comment

Rule 3: By sales organization,

For example, we could have the following configuration: