BP and ORG Model Integration

SPRO > CRM > BP > Integrating Business Partner > Organization Management > Set Up Integration with
Organization Management.

ORGANIZATIONAL MANAGEMENT IN THE CRM SYSTEM

Organizational Management offers you a flexible tool for displaying your companys task-related, functional
organizational structure as a current organizational plan.
CRM organizational management has many options for linking to your organizational units.
The organizational units (for example, sales organization, service organization) are not already specified: You can
include your own organizational levels and leave levels out.
The R/3 organizational units (for example, sales organization, distribution channel, division, maintenance
processing plant) are shown as attributes in CRM and are assigned to the organizational units. By doing this, you can
see the significance of the organizational unit. These attributes are not obligatory for planning the organizational
structure. However, they are required for automatically determining organizational data in documents.
You can activate an organization to be used for several scenarios, enabling it to be a sales organization and a
service organization at the same time.
The organizational plan is time-dependent. This enables you to plan organizational changes in the future.
Organizational units can occur as business partners. The system automatically creates a business partner record for
an organizational unit with the organizational unit role (For you to use your existing organizational units in orders,
the system must create business partners from these organizational units. The system uses BP role Organizational
unit for the business partners it creates from organizational units.)

APPLICATION AREAS IN CRM THAT USE ORGANIZATIONAL MANAGEMENT:

DATA TRANSFER
You can copy organizational data such as distribution channels, divisions and sales areas with the relevant text from
the R/3 system into the CRM system. You can find further information in the implementation guide (IMG) for
Customer Relationship Management under Master Data > Organizational Management > Data Transfer > Create R/3
Sales Structure.
You have more freedom when setting up your organizational structure in the CRM System than you would in
application component Sales and Distribution (SD) in the R/3 system. However, to make sure that data exchange
with the R/3 system works, it is recommended that you use the rules for creating an SD structure from R/3 in CRM
as well.

DIFFERENCES IN THE ORGANIZATIONAL DATA IN R/3 (SD) AND CRM

The following overview lists the main differences between maintenance and use of organizational data in the R/3
application component Sales and Distribution (SD) and the CRM component Organizational Data.

Function
/Feature

In R/3 System SD

In the CRM System

General
You maintain the sales organization in
Customizing under Enterprise Settings.

You maintain the organizational plan once

for all applications in CRM. Scenariospecific data in the structure is assigned by

You maintain the organizational plan for HR

and Workflow independently in Business
Management (Basis).

attributes to the organizational units.

These attributes are passed on to subordinate
organizational units.

Organizational data in Sales and Distribution is

static, changes in organizational
Organizational structures can be maintained
and adapted dynamically.
data lead to major changes in Customizing.
Responsibilities are defined independently
Responsibilities are proposed from the sales
from the business partner master and are
area-related data from the customer master.
determined, if required, from the
organizational structure.

Sales area

when creating a sales document

when creating a transaction document

entered manually or

entered manually or

determined using the customer master

for the sold-to party

determined using organizational

data determination.

The division field is empty at header level of

a document in the sales area, as there is no
division at header level of a document (see
R/3 replacement division).
A business partner master must therefore
have data for at least one sales area with an
empty division, so that it can be used at
the header level of documents (see IMG).

Distribution chain
(sales organization
and distribution
channel)

is obligatory in sales documents

Can be labeled as obligatory in Customizing

(org. data profile) We recommend that you
label the distribution chain as obligatory for
sales documents

Sales organization

only one sales document can occur in a sales

organization This organization is responsible
for processing a business transaction.

The organizational unit responsible for the

document need not be a sales organization. It
can also be, for example, a sales office.
You can assign the business partner directly

to the sales organization

Distribution
channel

is an organizational object
is defined in Customizing

Is not an independent object. It is an

attribute that can be assigned to an
organizational unit.
Can be replicated from the R/3 System
(during the initial download), or, can be
defined in the CRM System in Customizing.

Division
must be used. If a company does not use
division schedule lines, a general division
(cross-division) must be set up and used.
is defined in Customizing

Use of the division can be switched off

throughout the system
can be replicated from the R/3 System
(during the initial download), or, can be redefined in the CRM System in Customizing.

is an organizational object
can only be assigned to one distribution chain
and not to a sales organization.
Sales document has a sales area, therefore also
a division at header level (header division).

The division is not an organizational unit, it

is an attribute. Several divisions can be
assigned to a sales organization
independently of the distribution channel.
There is no header division. The division
only exists at item level. It is always derived
from the product.

Sales office
is assigned to a sales area
can be assigned to a customer in the customer
master.

The sales office can be directly assigned to a

sales organization.
Business partners and other attributes (for
example, postal code area) can be assigned
to the sales office, independently of the sales
area.

Sales group
can be assigned in the sales data of the
Business partners and other attributes can be
customer master to a customer as a responsible assigned to the sales group.
group

Assignment of an employee to the sales group,

sales office and/or sales organization takes
place in personnel master via Info type 900, an
employee can only be assigned to one
organizational unit (sales group)

Assignment of employees to an
organizational unit using positions in the
organizational model This makes it possible
to assign an employee to different positions
and organizational units.

Service
organization

displayed as maintenance planning plant

own entity, comparable with sales

organization in Sales scenario, is responsible
for processing service transactions

Determination of
employee
responsible (ER)

via customer master for sold-to party (or

another partner in accordance with partner
determination procedure)

via the sales area-dependent partner function

Employee responsible in the BP master
via the BP relationship defined in the
business partner master
via assignment in the organizational
structure

Organizational unit not possible; a customer master record must be possible; when creating an organizational
as business partner created for the organizational unit
unit, a business partner master (organization
(cross-company)
category) is automatically created.

Sales district
(customer district)

is defined in the customer master and copied

from there into the document

is assigned to an organizational unit in the

organizational structure as an attribute and,
if required, is copied from the responsible
organizational unit into the document.

ORGANIZATIONAL OBJECTS
The following object types are available in CRM
ORGANIZATION UNIT (Organizational object (object type key O), which is used to form the basis of an
organizational plan. Organizational units are functional units of a company. Depending on how task distribution is
organized in a company, these can be, for example, departments, groups or project teams.)

 POSITION (Organization object (object type key S) which shows the functional task distribution of individual
items and their report structure in the organizational plan. Positions are concrete items in a company, set by holders
(employees or CRM users),

An organizational unit also has its own specific features (attributes).

You maintain important data like address, validity period
You define attributes for each organizational unit of each scenario, for example, currency, region, product group
By assigning attributes, you maintain sales areas by assigning the attributes distribution channel and division to a
sales organization or its subordinate organization.
CRM distinguishes between organizational and business attributes:
organizational attributes define the type of organizational unit, for example, whether it is a sales organization or a
service group.
business attributes define the responsibility of an organizational unit, for example, for which distribution channel
or product group an organizational unit is responsible.
Attributes can have one or more values

DETERMINING ORGANIZATIONAL DATA

When processing a business transaction, certain organizational data is mandatory depending on the transaction type.
In the CRM System you have the following options for determining organizational data in the document. These can
be set in Customizing and are dependent on the transaction type:
No automatic determination
1. You have created an organizational data profile in Customizing, in which no determination rules have been
entered.
2. You have assigned this organizational data profile to the required transaction type.
Automatic determination
1. You have created a determination rule in Customizing for each determination path with the corresponding rule
type.
2. You have defined one or two determination rules in the organizational data profile for evaluating the
organizational data profile of a business process.

3. You have assigned the organizational data profile to a transaction type.

You carry out the settings in Customizing for CRM. Organizational Data Organizational Management Choose
Master Data Determination. You can find further information in the documentation there.
When determining organizational data, the system takes the organizational data profile defined in Customizing and
the determination rules from this profile. These determination rules specify which fields are taken into account when
the system determines organizational data from the document data (for example, business partner number, telephone
number).
There are two determination paths provided in the CRM system
Responsibilities Rule Type
You would use the responsibilities rule type if you
Want to determine organizational data for individual responsibilities
Havent created an organizational plan but want to create one
Have a lot of organizational units and must only assign a few attributes
For the system to determine organizational data using the responsibilities rule type, you need to use organizational
units. However, these do not need to be linked. Therefore you do not need to create an organizational structure for
this determination path. The attributes are defined directly in the rule container.
If you use rule resolution using responsibilities, you must not assign attributes in the organizational structure, other
than the distribution channel and division attributes that are necessary for showing the sales area.
Organizational Model Rule Type
You would use rule resolution using organizational model if you
Have created an organizational plan or have distributed a plan into the CRM system and want to use this for
determining organizational data.
Assign a lot of attributes to the organizational units and these are to be evaluated.

Org Data Determination

Posted by crmQ on August 4, 2008
In R/3 SD, during Order entry, we have always wanted users to determine or select Sales Org/Dist Channel/division
that is appropriate.
CRM can relieve the users of having to determine the Org Structure and determine that automatically. You
essentially store some canned rules for organization determination and let the system run these rules to determine the
the appropriate Org Structure in transactions.
Two types of rules. Generic and Specific.

In Generic Rule, called also a organization Model rule, you say (as an example) when I enter the customer, look
at the country and region attributes of customer. Then with these values search organization attributes and determine
the right Org Units.and then update the transaction org values accordingly. The good thing about generic rule is,
it does not require too much maintenance unless the Logic for determination of the org structure itself is being
overhauled. One disadvantage of using the generic rule is that, it does not account for typical Business Exceptions
like though this pericular customer belongs to Belgium, John has been hanling this account from beginning and he
would like it to be treated differently because the CEO of thisetc. Especially if there are more exceptions
than generic rules, you go to Specific Rule.
Specific Rule also called Responsibilities. This is more or less Hard Coding the responsibilty matrix and making
the system look up this matrix to determine the appropriate Org Structure in transactions. The clear disadvantage is
the frequent maintenance of this matrix when there are changes.
It is important to check in the Attributes section of the Organization Definition, you check the box for Obj
Permitted for Org Determination. If this is not checked, even if the rules meet the requirements, these Org
structures will not be fetched
Create these OrgDeterminationProfiles( ie Rules). Assign them to transaction types.
SPRO>CRM>MasterData>OrganizationManagement>OrgModel>Tools Use this to check consistency. To check
which determination Rule/what are the containers in the rule/what is the profile etcc.. provide transaction type and
you can see how the transaction runs the Org Determination Check.
Transaction /nCRM_ORG_PROUVE
While creating or changing the transaction, go to Organization tab and look for details to find out what rule and
how the organization was determined.

Check List if Organizational Data not found

The system does not determine the organizational data for a transaction document (for example, telesales order) as
expected (org data screen is partly or completely empty or the required organizational units were not found).
This can have various causes. You can use the following checklist to check the settings for determining
organizational data.
In the Internet Sales scenario, the organizational data is always read from the product catalog variant. The following
Customizing settings are therefore not valid for internet orders.
Check List
1. Organizational data model
Is the organizational data model maintained and are the organizational units provided with attributes?
Are the organizational units Sales organization, sales office, sales group, service organization and purchasing
organization marked as such?
Make sure that the organizational units have been activated for the required scenario during maintenance of the
organizational model (for example, the service organization for the Service scenario). On the Attribute tab page in
the field Object is permitted for scenario, activate

2. Attribution
Are the organizational model and attributes uniquely maintained?
When attributing organizational units overlapping may occur, for example, in the following cases:

If you evaluate attributes at a higher level of the organizational model (for example, the root), these
attributes and the assigned values are passed on to all subordinate organizational units for the corresponding
scenario, if they are not overwritten by another value. In some cases therefore several organizational units
have the same value and attribution overlaps. In organizational data determination all of these organizational
units are determined with the searched value.
You can avoid this type of overlapping by overwriting the subordinate organizational units that have inherited
values with other values, or, by providing them with restricted values. To make restrictions, you can use the
exclusion flag Excluded.

If you go over the value areas for attributes, there will be overlapping:
You assign the postal areas 1 12000 to organizational unit 1, the areas 5000 to 25000 to organizational unit
2. Both organizational units are responsible for a sold-to party with the postal code 10 000.

If the system determines several organizational units for a document, a selection screen appears in which you can
select the required organizational unit for the current document.
3. Organizational data profile
Has an organizational data profile been created and defined in these determination rules?
4. Organizational data profile assigned?
In order that organizational data is determined at header level for the transaction, the organizational data profile must
be assigned to the corresponding business transaction type.
If the organizational data at item level should be copied from the header data, an empty organizational data profile
(without determination rules) must be assigned to the corresponding item category.
If no organizational data profile is assigned, the organizational data set in the business transaction document is
empty at header and/or item level and the screens for organizational data are not displayed.
It is not possible to carry out organizational data determination independently from the header data for the item
level. This means that no organizational data profile can be assigned to an item category if it contains a
determination rule.
5. Source data
Is the source data that is required for determining organization data available in the document?
If, for example, the determination rule states that the responsible sales organization should be determined using the
postal code of the sold-to party but no address has been defined here, the system is not able to determine the sales
organization.