ORGANIZATIONAL MANAGEMENT

– INTRODUCTION
ORGANIZATIONAL MANAGEMENT IN THE CRM SYSTEM

Organizational Management offers you a flexible tool for displaying your company’s 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 In R/3 System SD
/Feature
General You maintain the sales organization in
Customizing under Enterprise Settings.
You maintain the organizational plan for the structure is assigned by
HR and Workflow independently in
Business Management (Basis).
Organizational data in Sales and
Distribution is static, changes in
organizational data lead to major changes
in Customizing.
Responsibilities are proposed from the dynamically.
sales area-related data from the customer
master.
Sales area when creating a sales document
• entered manually or
• determined using the customer
master for the sold-to party
Distribution chain is obligatory in sales documents
(sales organization
and distribution
channel)
Sales organization only one sales document can occur in a
sales organization This organization is
responsible for processing a business
transaction.
In the CRM System
You maintain the organizational
plan once for all applications in
CRM. Scenario-specific data in
attributes to the organizational
units.
These attributes are passed on to
subordinate organizational units.
Organizational structures can be
maintained and adapted
Responsibilities are defined
independently from the business
partner master and are
determined, if required, from the
organizational structure.
when creating a transaction
document
• entered manually or
• 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).
Can be labeled as obligatory in
Customizing (org. data profile)
We recommend that you label
the distribution chain as
obligatory for sales documents
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
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

· Haven’t 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.

BUFFERING FOR CRM ORGANIZATIONAL DATA

To improve system performance, you can use the HR_BCI_ATTRIBUTES_BUFFER_UPDATE

program for buffering organizational model and attributes. Call up view T77OMATTR via
SM30 and select the buffering field for each scenario to buffer corresponding objects.

Execute the HR_BCI_ATTRIBUTES_BUFFER_UPDATE program every morning (after 0:00

hrs) before starting your systems. This time of after 0:00 hrs is important for starting up
the buffer for the current day, as data for organizational management is time-dependent.
You can also influence performance through Customizing of org data determination by using
the Responsibility rule type. Responsibility determination rules determine the required
organizational unit (or required partner) without evaluating the organizational model. That
is why determination rules of this rule type perform better.

DATA EXCHANGE FOR ORGANIZATIONAL DATA

Within the CRM system group, organizational data (for example, sales organization,
distribution channel) must be available in all systems in order that the exchange of master
data and documents is possible. Additionally, organizational data must be maintained
consistently in all systems concerned.

If you use an R/3 System with CRM, the following organizational data is transferred from
the R/3 System to the CRM System during the initial data transfer for Customizing:

· Distribution Channel

· Division

· Default combinations of distribution channels and divisions

This data is defined as attributes in the CRM System, and not independent units.

During initial data transfer of Customizing data from the R/3 System, the following data is
not transferred:

· Sales organization

· Sales office

· Sales group

· Sales area (a combination of sales organization, distribution channel, division)

You have to transfer this data in a separate process step, or create it manually in the CRM
System.

The following possibilities are available for transfer of organizational data in CRM from one
system to another .

· Copying the sales structure from the R/3 System to CRM Online

You can transfer sales areas as well as sales offices and sales groups from R/3 to CRM with
one program. After transfer, it is often necessary to post-process the structure.

· Creating the organizational model manually in CRM Online

This can be useful, if you only wish to use a part of the sales areas from the R/3 System in
CRM.
· Distributing the organizational plan from the R/3 HR System using ALE

This can be useful if you use Organizational Management in the OLTP R/3 System, for
example with SAP Workflow, and you have already created a detailed organizational model.
(See also SAP Note 312090)

Org Data Determination

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 this……etc…”. 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.

Z ATTRIBUTES IN ORG MANAGEMENT

To create custom attributes, goto TCODE – OOATTRCUST

-OR-

Go to table T77OMATTR (TCODE – SM30), Find an attribute where table = HRT1222.

Create an new attribute by copying. Then add your new attributes. To the correct scenario
(SALE or SERVICE).
Ensure that you have a ‘Z’ preceding the the attribute name

BP – Introduction
BUSINESS PARTNER CONCEPTS

BUSINESS PARTNER CATEGORY

BP GROUPING

BP ROLE

DATA SET

BP RELATIONSHIP

BUSINESS PARTNER CATEGORY

The business partner category denotes whether a business partner is a natural person
(private individual), organization (legal person/entity or part of a legal entity, such as a
department), or a group.

The standard business partner categories are:

· Natural person (private individual)

· Organization (e.g. company, department in a company, club, association)

· Group (e.g. married couple, shared living arrangement)

It is not possible to create any other business partner categories. You cannot alter the
business partner category at a later stage.

By launching the transaction code “BP” you will see the following screen. Note the BP
Category – People, Organization & Group.

Input fields will differ depending on the BP Category chosen

BP Category – Organization

BP Category – Person

BP – GROUPING

Grouping is the container that holds the Number Range settings that is assigned to the BP
Role. When creating a BP internal number assignment is the default. Alternatively if you
want to use external number assignment, you must choose the relevant grouping and enter
the external number.

Whenever a business partner is created it needs to be assigned to a grouping. Grouping

controls the number range which is either Internal or External number range

§ A BP must be assigned to a Group

§ The grouping controls the number range

§ Internal and external number assignment is possible

A Number Range is a range of numbers that you can assign to business objects such as
business partners, orders, products etc., Each number range has a number range intervals
and a number assignment type (Internal / External).

Internal Number Range

When storing a data record, the CRM System assigns a sequential number, which lies in the
relevant number range interval.

External Number Range -

The number is assigned by the user or by an external system, both of which must ensure
that the number lies in the relevant number range interval.
For example:
Domestic business partners -
Number range 01, number range interval 100,000 – 199,999, internal assignment
Foreign business partners -
Number range 02, number range interval 200,000 – 299,999, external assignment

To define number range for BP go to the following path in SAP CRM IMG Menu:
IMG->Cross-Application Components->SAP Business Partner->Business Partner->Number
Ranges and Grouping->Define Number Ranges
Choose – .

BP – ROLES

A business partner role can be used to classify a business partner in business terms. You
can choose one of the many SAP provides roles –or- you can define your own Role/s
IMG > Cross-Application Components ® SAP Business Partner ® Business Partner
® Basic Settings ® Business Partner Roles. à Define BP Roles:

If you need to make custom changes, just copy the existing role that matches your
requirement and then copy it and rename with an prefix ‘Y’ or ‘Z’.

NEVER make changes to the standard roles.

Following is the BP Role structure. The example shown here is for the BP Role – Contact
Person.
All Roles have 2 factors that are important – Role Category and Role View

Role Category

Role category settings (as shown below) determines the BP category that this role is valid
for
Role View

View determines that Data Sets that are valid for the assigned Roles. TCODE – BUSD will
take you to the View area:

Assign the required data sets to the View and then Assign this view to your BP Role. The BP
created for this role will have the following Data sets
Differentiation Types

Application data is generally dependent on the primary key of the application object. For a
business partner, the primary key is the partner number. However, there can also be other
attributes that must be differentiated according to other criteria. If data for an instance is
only ever entered as a way of describing it as a criterion, then it would be called a
differentiation type. Differentiation types are usually entered on the initial screen.

Configure the input screens so that the value of the differentiation type is visible in the
header data if the underlying data is dependent on it

Application objects

Each master data/transaction data object that uses BDT must be known. The maintenance
of application objects is subdivided into the following points:

· Defining application objects

· Assigning application objects à differentiation types

· Settings transactions, task menu

Menu path: BUPT > BDT GENERAL > APPLICATION OBJECTS (BUS0)

Process to Get Partner function (BP Address) related to Sales Order

Using table CRMC_OBJECTS try to locate the entry “partner” and get the corresponding
object type 7.

From table CRMD_ORDERADM_H take the GUID and select the entries in table
CRMD_LINK table. Select the entry which has the objtype set = 7 and objtype_hi = 5.
Get the corresponding GUID_SET entry.

Using the GUID_SET entry, select the entries in the CRMD_PARTNER table. Select the
entry for the partner function you want to investigate. Get the corresponding address
number.

Using this address number we can get the address information for the partner from ADRC
table.

DEFAULT BP ROLE GROUPING

It is not possible to define default Grouping based on BP type (person, org, group). through
customizing. But you can accomplish it through a BDT extension (event ISDAT in
BUS7). However you can have one default ext number range and one int number
range for all BP roles. This is set in the Grouping IMG area.

BP and ORG Model Integration

SPRO > CRM > BP > Integrating Business Partner > Organization Management > Set Up
Integration with Organization Management.
Search for – HRALX and ensure that the value of the OBPON is ON. This will activate the O-
BP integration. BP ID will be created for every new Org unit created.

PARTNER PROCESSING – Introduction

Partner processing controls how the system works with business partners in transactions. It
ensures the accuracy of partner data in transactions by applying rules you specify in
Customizing, and it makes your work easier by automatically entering certain partners

One of the most important aspects of partner processing is partner determination, the
process by which the system automatically finds and enters the partners involved in a
transaction. In most transactions, you manually enter one or more partners, and the system
enters the others through partner determination. Various sources of information make
partner determination possible; two of the most important are business partner master data
and organizational data.

For example, a user creates a sales order, and enters the name of the sold-to party.
Immediately, by checking the sold-to party’s master data, the system enters other required
partners, such as the bill-to party, payer and ship-to party. By checking the organization
data, the system enters the employee responsible for the region where this sold-to party is
located.

The following figure shows this combination of the user’s entry and automatic partner
determination.
Features

. With Partner Functions, you define partners with the terminology used in your area of
business and in your company. For example, if you have a real estate business, you might
define the partner functions Tenant and Mortgage Provider.

· In Access Sequences, you specify the sources of data the system uses for automatic
partner determination, and the order in which it checks those sources.

· In Partner Determination Procedures, you specify which partner functions are involved in a
transaction, assign access sequences to the functions the system should determine
automatically, and set other rules for working with partners in transactions.

· With Partner Teams, you define groups of partners involved in an individual project, or
even in a single transaction. Partner teams are used in opportunity management.

BASIC ELEMENTS OF PARTNER PROCESSING

The basic elements of partner processing are:

· Partner functions / Partner function categories / Relationship categories

· Access sequences

· Partner determination procedures

PARTNER FUNCTIONS / PARTNER FUNCTION CATEGORY / RELATIONSHIP

CATEGORY

Partner functions are terms that describe the people and organizations with whom you do
business, and who are therefore involved in transactions. Partner functions are always
assigned to partner function categories, which are hard-coded in the system.

When you define a partner function, you assign it to a partner function category. Therefore,
the partner function consists of two basic elements: the new term itself and the category.
The new term is your name for the function, and the category is the hard-coded key that
allows the system to identify what the function means, and how to work with it. In some
cases the functions have the same name as the categories to which they are assigned, but
they need not.
Once you enter a partner function category, the system automatically enters the
relationship category. It is able to do so because many partner function categories are hard-
coded to correspond to certain relationship categories. However, if you use the partner
function category Undefined Partner or relationship categories you have created yourself,
you must enter the relationship category manually.

The following table shows several of the partner functions in the system, with the partner
functions categories to which they are assigned, and the corresponding relationship
categories:

INTEGRATION

Partner functions are used mainly in transaction processing, and relationship categories
mainly in master data. The correspondence between them (and the assignment of access
sequences) allows the system to use business partner master data as a source for partner
determination. Partner functions that do not correspond to relationship categories can be
determined from other sources, such as the organizational model, or entered manually.

Example

Your company sells televisions to a store called Hifidelity, and your sales people often talk to
the store manager, whom you refer to as a retail manager. You ship the televisions to
Hifidelity Storage, an affiliate responsible for Hifidelity’s storage needs. You refer to
Hifidelity Storage as a delivery location.

1. In master data, you enter Hifidelity as a business partner. In the Contacts assignment
block, you enter the store manager’s name as the contact person, and in the Relationships
assignment block, Hifidelity Storage as Is the Ship-To Party/Recipient Of.

2. In Customizing for partner processing, you define the partner function Delivery Location,
and assign it to the partner function category Ship-To Party. The system automatically
enters Is the Ship-To Party/Recipient Of as the corresponding relationship category.
3. You define the partner function Retail Manager, and assign it to the category Contact
Person. The system automatically enters Is Contact Person For as the corresponding
relationship category.

4. You define a partner determination procedure that includes these two partner functions,
and assign access sequences to them. In the access sequences, you have specified business
partner master data as the source for partner determination.

5. You create a transaction, and Delivery Location and Retail Manager are displayed in the
header and Parties Involved assignment block. You enter Hifidelity as the sold-to party. The
system automatically enters the manager’s name as the Retail Manager, and enters
Hifidelity Storage as the Delivery Location.

The following figure shows the steps described above.

UNDEFINED PARTNER

The partner function category Undefined Partner is a free category that you can use when
none of the other partner function categories suits your needs. The benefit is that you can
create partner functions, and include them in transactions, even when none of the
predefined categories is appropriate.

The system’s processing of the category Undefined Partner is limited. Normally, there are
certain system functions or rules associated with a function category, for example the
system “knows” that a sales transaction must include a sold-to party. However, in the case
of the Undefined Partner there are almost none.
· You can specify that a partner function assigned to this category must be included in a
certain transaction type, just as you would with any other category. The system then
searches for and enters a partner, or asks the user to do so manually.

· When you assign a partner function to this category, you can choose any relationship
category, either an existing one or one you create yourself, to correspond to it. However,
the relationship category Is the Undefined Partner Of corresponds only to the partner
function category Undefined Partner.

Using “Undefined Partner”

When you have determined that none of the pre-defined partner function categories suits
your needs, undefined partner is the best choice:

1. You have an investment business, and to help keep track of your customers, you have
created the new relationship category Is the Stock Options Analyst. You want the system to
be able to handle partners of this category in transactions, and therefore you need a
corresponding partner function.

2. You define the new partner function Stock Options Analyst, but there is no partner
function category that fits your needs, and so you choose Undefined Partner. You enter Is
the Stock Options Analyst as the corresponding relationship category.

3. You can now enter this partner function in transactions, and the system will recognize
that the partners with the relationship Is the Stock Options Analyst can carry out this
function.

Avoiding “Undefined Partner”

Because the system’s processing of this partner function category is limited, we recommend
you avoid using it when one of the other categories works:

1. You have a real estate company, own several apartment buildings and rent the
apartments to tenants. You want to create the new partner function Tenant, but the partner
function category Tenant does not exist. However, you do not need to use Undefined
Partner or create the new relationship category Is the Tenant Of, as there is a simpler
solution.

2. In terms of the business processes in which they are involved, your tenants are basically
Sold-To Parties. Therefore, you maintain master data for them either with no specific role or
the role Sold-To Party, and you create the new partner function Tenant and assign it to the
partner function category Sold-To Party. There is no corresponding relationship category for
Sold-To Party, so you leave this blank.

3. You can then include this new partner function in transaction documents, enter your
tenants as the partners carrying out this function, and the system automatically enters
other necessary data.

EXCLUDING PARTNER FUNCTIONS IN MASTER DATA

Sometimes a partner should not perform certain functions, and in these cases you can enter
excluded partner functions in the master data for that partner in the Excluded Partner
Functions assignment block.

Features

· If you assign this partner to excluded functions, the system informs you that these
functions are excluded, but allows you to make the assignment. If the partner is entered for
an excluded function in a transaction (either automatically by the system, or manually), the
system displays a message informing you that the function is excluded for this partner.

· After excluding functions for a partner, it is still possible to create relationships that
correspond to excluded functions. For example, if the function Activity Partner is excluded, it
is still possible to enter the relationship Is the Activity Partner. This flexibility is important in
cases where a relationship category corresponds to more than one partner function. This
table gives an example from the system:

Two different partner functions have the same relationship category. If you exclude the
partner Sales Prospect, neither is the function Activity Partner excluded, nor is the
relationship category Is Activity Partner blocked.

Example

Johnson Stereo may order and receive goods, but should never receive invoices or send
payments because the main office, Johnson Electronics, handles all accounting. To help
ensure that invoices are not sent to the wrong place, you enter Bill-To Party and Payer as
excluded partner functions in Johnson Stereo’s master data.

If you then assign Johnson Stereo to these partner functions for the relevant sales areas,
the system informs you that these functions are excluded for Johnson Stereo. If Johnson
Stereo is entered as the bill-to party or payer in a transaction (either automatically by the
system, or manually), the system displays a message informing you that the function is
excluded for this partner.

However, it is still possible to create the relationships Johnson Stereo Is the Bill-To Party Of
and Is the Payer Of.

BLOCKING PARTNER FUNCTIONS IN PARTNER PROCESSING

In the area of partner processing, “excluding” a partner function is known as “blocking”. If

you do not create any relationships or partner function assignments for a partner, it can
automatically perform all functions itself. In some cases this might not be appropriate, and
you might specifically want to exclude certain partner functions.

Features

To turn of the standard setting in Customizing, choose Customer Relationship Management

-> Basic Functions -> Partner Processing -> Define Partner Functions. Then select the Lock
field for the relevant partner functions.

· The main partner in transactions, such as the activity partner in an activity, or the sold-to
party in a sales order, cannot perform the blocked functions in that transaction.

Example

Your opportunity transactions include the partner functions Sales Prospect, Contact Person,
Employee Responsible and Competitor. To ensure that the sales prospect is never
mistakenly entered as the competitor, you set the Block indicator for the partner function
Competitor. This setting applies to the competitor in any transaction, not just an
opportunity.

ACCESS SEQUENCES

Access sequences are search strategies that specify the sources of data the system uses for
finding partners, the order in which it uses these sources, and related details.

Example:

An everyday example of an access sequence occurs when a colleague asks to borrow your
dictionary, and you tell her where to find it. You might say, “Look on my desk”, or “Look on
my desk, and if it is not there, look in the shelves”. When you define access sequences in
Customizing “desk” and “shelves” are replaced with sources of information such as business
partner master data, organizational data and preceding documents.

· Access sequences allow the system to carry out partner determination, the process by
which the system automatically finds and enters partners in a transaction.

· When you define a partner determination procedure, you can assign an access sequence to
each partner function listed in the procedure. Then, when you create a transaction, the
system knows how to search for partners to carry out these functions. If you do not assign
an access sequence, or the system cannot find partners in the sources listed, you enter the
partner manually.

The system includes a number of commonly used access sequences. We recommend that,
before defining your own, you check to see if you can use the existing ones.

To view and define access sequences in Customizing, choose Customer Relationship

Management > Basic Functions > Partner Processing > Define Access Sequences.

Structure
An access sequence is a list of one or more steps called single accesses. Each single access
names a source, such as master data or the preceding document, and specifies other
details. The description of an access sequence lists the sources named in the single
accesses, separated by arrows.

When the system determines a partner, it checks the first source, and, if it does not find a
partner there, it checks the next source. It does this for each partner function in a
transaction, aside from those entered manually. Understanding the sources is crucial to
understanding the access sequences.

The following table lists sources in the system, with a short explanation of each source.

Example

1. An access sequence with the following description is available in the system:

Preceding Document -> BP Relationships By Sales Organization: Sold-To Party -> Business
Partner Relationships: Sold-To Party

2. In a partner determination procedure in Customizing, you assign this sequence to the

partner function ship-to party.

3. A user creates a sales order and enters the sold-to party.

4. The system determines the ship-to party as follows:

1. First, it looks in the preceding document for a ship-to party. If there is no preceding
document or no ship-to party there, it goes on to the second single access.

2. In the second single access, the system looks in the sales area-specific partner function
assignments defined in the sold-to party’s master data. If there is no ship-to party there, it
goes on to the last single access.

3. Finally, the system looks in the relationships defined in the sold-to party’s master data,
for the relationship Is the Ship-To Party/Recipient Of because this relationship corresponds
to the partner function Ship-To Party/Service Recipient.

4. If the system does not find a partner in any of the sources, it frequently enters the sold-
to party itself as the ship-to party in the transaction because, if no relationships are
maintained, a partner can automatically perform all functions itself.

The system does not enter the sold-to party as the ship-to party if ship-to party is an
excluded function in the master data of this sold-to party, or if the Block indicator is set for
the ship-to party in the partner determination procedure assigned to this sales order.

The following figure shows how the system uses an access sequence to determine a partner.

ACCESS SEQUENCE CONFIGURATION

Source Origin for a Document Partner

Specifies where the system searches for data during partner determination, such as the
preceding document or sales organization data.

For example, if you enter preceding document here and assign this access sequence to the
sold-to party, the system looks for a sold-to party in the preceding document.

Reverse Search for Partner Determination from BP

Reversal of the search direction for partner determination that uses business
partner relationships.

This setting is only relevant when you enter either Business Partner Relationships or BP
Relationships by Sales Organization as the source for this single access.
During partner determination using business partner relationships, the system normally
looks in a partner’s master data for the “Has the …” relationship, such as “Has the contact
person”. Marking this field sets the system to look for the same relationship, but in the
reverse direction, such as “Is the contact person for”.

Note

It is not possible to use both “directions” in one partner determination procedure. For
example, if you set the system to determine the contact person from the activity partner,
and the activity partner from the contact person, the system cannot find either partner, and
stops partner determination.

Determine Partner When Error in Source

Indicates whether the system uses the business partner data in this source even when that
data is incomplete or incorrect.

· Leave this field unmarked to allow the system to use only complete and correct data.

· Mark this field to allow the system to use incomplete or incorrect data (Eg. – If the ship-to
party’s address is missing in the preceding document, the system will enter this ship-to
party in the new transaction anyway)

Wait Until Source Is Available

Indicates whether the system waits until the source in this single access (or in a single
access defined as an alternative) is available before continuing partner determination.

For example, if the source for determining the employee responsible is the organizational
model, the system waits until organizational data is entered in the document before
determining the employee responsible. In this context, available means the system has
enough data to find the source.

Determination as Business Partner if Possible

Specifies that, whenever possible, the system enters the partner, which it has found during
partner determination, as a business partner in the document.

Sometimes, for example, the system finds an organizational unit or a user name during
partner determination rather than a person, organizational or group that has been defined
as a business partner. In these cases, if you select this field, the system tries to find the
business partner who corresponds to this unit or user name, and enters this business
partner in the document.

Partner Function

Name the partner function the system should look for in the source

You can use this field to assign a parter function category

Enter a partner function category to provide details about the source you have selected and
allow the system to access it properly.

For example, if Business Partner Relationships is the source, you must specify which
business partner relationships, because the system cannot look in all relationships defined in
master data. Here you can specify that the system looks in the relationships belonging to
the sold-to party, the activity partner or any other partner function category in the system.

· You can specify any partner function category, but remember that a function assigned to
this category must be included in the transaction for the system to be able to carry out this
single access.

· It often makes sense to enter the category of the main partner in a transaction.

o For example, if this access sequence is used for activities, enter the activity partner, or if
it is used for sales transactions, enter the sold-to party.

Examples

1. You choose the Business Partner Relationships by Sales Organization as the source for
this single access.

2. In this field you specify the partner function category sold-to party.

3. You assign this access sequence to the partner function ship-to party.

4. You create a sales transaction.

5. To determine the ship-to party, the system looks in the master data that belongs to this
transaction’s sold-to party. It looks in the business partner relationships (part of master
data) defined specifically for the sales organization involved in this transaction. It finds a
ship-to party and enters it in the sales document.
Organizational Unit as Business Partner

Enter an organizational area to provide details about the source you have selected and allow
the system to access it properly.

For example, if you choose Business Partner Relationships by Sales Organization as the
source, you could specify Sales organization or Service organization here.

No Partner Function Mapping

Indicates whether or not mapping of partner functions occurs during partner

determination.

Use

· Leave this field unmarked to specify that mapping does not occur.

· Mark this field to specify that mapping occurs.

Example

Example 1: No mapping

Normally, the system searches for the partner function to which an access sequence is
assigned.

o You assign an access sequence, with the source preceding document, to the partner
function ship-to party.

o The system looks in the preceding document for a ship-to party.

o It enters the ship-to party from the preceding document as the ship-to party in the
current document.

Example 2: Mapping

Mapping means that the system searches for a partner with a partner function that is
different from the one to which this sequence is assigned.

o You create an access sequence, with the source preceding document, and mark this field,
Mapping.

o Specify the activity partner as the partner function in the source.

o You assign this access sequence to the partner function ship-to party.

o The system looks in the preceding document for an activity partner.

o It enters the activity partner from the preceding document as the ship-to party in the
current document.

PARTNER DETERMINATION PROCEDURES

Partner determination procedures are sets of rules for how the system works with business
partners during transaction processing. They bring together partner functions and access
sequences, and include additional information.

Structure

To define partner determination procedures in Customizing, choose Customer Relationship

Management > Basic Functions > Partner Processing > Define Partner Determination
Procedure.

The settings include:

· Which partner functions are mandatory and which suggested, which are entered
automatically and which manually, and how many partners can be entered for each
function.

· Which access sequence applies to each partner function that is determined automatically
by the system.

· At what point the system starts partner determination for each function. This could be as
soon as you enter data, when you enter a product, or when you save the transaction.

· Whether the system enters an activity in the calendars of the partners involved (relevant
to activities only). For more information, see Working with Activities.

· Whether you can change a partner’s address in transactions, and, when a partner has
more than one address, which address is used.

· Which partner functions are available in a business transaction and which are not.

The procedure consists of three levels:

· Procedure User identifies the transaction categories and item object types to which the
procedure applies.

· Partner Functions in Procedure lists the partner functions involved and specific settings for
each function.

· User Interface Settings allows you to influence which partner function appears in individual
partner fields (such as contact).
Integration

For a procedure to be available for a particular transaction type, both it and the transaction
type must be assigned to the same transaction category.

For a procedure to be available for a particular item category, both it and the item category
must be assigned to the same item object type.

Example

Your company sells televisions to the store Hifidelity, and your sales people often visit the
store and talk to the store manager on the telephone. To enter these visits and calls in the
system, they create business activities.

You have defined the partner functions Electronics Retailer and Retail Site Manager for
transactions with companies like Hifidelity, and have certain requirements for activities with
them. Therefore, you define a partner determination procedure for these business activities.

System Settings

You define a new partner determination procedure and:

1. Assign it to the transaction category Business Activity.

2. Enter the two new partner functions you have just defined, Electronics Retailer and Retail
Manager, plus the existing partner function Employee Responsible. You specify that they are
mandatory, and that the transaction should only include one partner as the Retail Manager.

3. Assign access sequences, specify that partner determination should start as soon as data
is entered, and that activities should be entered in the partners’ calendars.

This table shows possible Customizing settings:

4. Assign this procedure to a transaction type with the transaction category Business
Activity.

5. In the field Permitted Functions on the Partner Determination Procedures screen, select
either Only Functions Assigned in Procedure or All Defined Partner Functions to determine
which partner functions should be displayed and available for use in a business transaction.

Result

1. A business user creates a business activity in the form of a planned visit to this customer.
2. He enters Hifidelity as the Electronics Retailer.

3. The system looks in Hifidelity’s master data and enters the name of the store manager as
the Retail Manager.

4. He tries to enter the assistant manager as a second Retail Manager, but the system
displays a message saying only one partner is possible for this function.

5. Through organizational determination, the system automatically finds the sales group
responsible for Hifidelity’s region. It enters this group in the organizational data.

6. Based on the organizational model to which this group belongs, the system determines
the employee responsible and enters his name.

7. The system enters this visit in the employee’s calendar.

This figure shows how the settings in a partner determination procedure affect partner
processing in transactions.

PARTNER DETERMINATION PROCEDURE -

No Partner Determination for Partner Functions in Part.Proc.

Specifies whether or not partner determination is turned off. When it is turned off, the
system does not carry out automatic partner detemination in transactions to which this
procedure is assigned.

This feature is available to improve possible performance problems, and may be particularly
useful in areas such as Internet Sales.

· Leave the field unselected to carry out partner determination automatically.

· Select the field to turn off automatic partner determination.

Partner Logging

Determines whether or not the system automatically generates a log, documenting partner
determination, which you can view from within a transaction. (You view the log by selecting
the button Call up Log on the partner tab. This button is only available when this field is
selected.)

The log shows how partner determination took place for the transaction, includes links to
Customizing and is intended mainly for Customizing and trouble shooting. Avoid using it in a
productive system due to performance issues.

· Mark this field to set the system to generate the log for transaction types to which this
procedure is assigned.

· Leave the field unmarked to prevent generation of the log.

PARTNER REDETERMINATION

Using this function, you can manually trigger the partner determination procedure from
within a business transaction, such as lead or opportunity, and redetermine all parties, such
as contacts, employees, and other partners, involved in the transaction. This enables you to
ensure that the correct parties are identified and associated with a transaction
This might be necessary because partners determined originally, based on a partner
determination procedure, are no longer up-to-date. You might have switched to new
partners, for example, which in turn might require changes to all dependent partner
functions.

Prerequisites

· You have set up the partner determination procedure appropriately. You do this in
Customizing for Customer Relationship Management, by choosing Basic Functions
Partner Processing Define Partner Determination Procedure .

· You have activated the enhancement implementation ES_CRM_SET_ACTIVE of the

enhancement spot ES_CRM_PARTNER_REDETERMIN.

· You have to set the parameter value X for the user parameter CRM_REDETERMINATION (
System User Profile Own Data Parameters ).

Features

You can start partner redetermination manually from the overview page of a lead or
opportunity. Depending on your Customizing settings, partners are redetermined as follows:

· No Redetermination

The partner functions in the partner determination procedure that have this value are not
changed. All existing partners remain, with no new partners of the given partner function
being determined or added to the partner set. Similarly, any existing partners are not
replaced.

· Add New Partners

The partner functions in the partner determination procedure that have this value are
redetermined. All existing partners remain and any new partners determined based on the
partner function are added to the partner set. Before a new partner is added to the set, the
system checks whether the same partner with the same partner function already exists. If
this is the case, the newly determined partner is not added to prevent a duplicate entry. The
system indicates when the maximum number of partners has been reached.

· Replace Existing Partners

The partner functions in the partner determination procedure that have this value are
redetermined. All existing partners of the given partner function, irrespective of whether
they were entered manually or determined automatically, are discarded and the newly
determined partners with the given partner function are added to the partner set. The
system indicates when the maximum number of partners has been reached.

· Buying Center

All partners in the buying center are partner functions of the partner function category
Contact Person.

If redetermination is allowed for partner functions of this category, this affects the buying
center as follows:

o Where new partners are added, newly determined partners are shown but without any
characteristics, relationships to other partners, or relationship characteristics.

o Where existing partners are replaced, the buying center partners of a given partner
function are replaced completely, resulting in not only the partner being deleted, but also
the associated characteristics, relationships to other partners, and relationship
characteristics.

ALTERNATIVE PARTNER PROPOSAL

This function allows you to trigger partner determination within business transactions to
change previously automatically determined partners, quickly and easily within the
application itself. This means you no longer have to search manually for partners you want
to replace.

Prerequisites

You have maintained the appropriate business partner master data to enable partner
determination.

Features
You use the alternative partner proposal to manually trigger partner determination for
partner functions that have already been automatically determined. You do this for one
partner function at a time:

· The system searches for and displays the current and alternative partner options for the
partner function, based on current document data and the Customizing settings for the
partner function. You make your selection and the system automatically replaces all
partners in the partner function in the transaction.

· Changes made using the function are limited to individual partners and partner functions
in the business transaction and do not affect business partner master data and other data
dependent on this document.

· The function can be used to trigger partner determination for empty partner functions
stored in the transaction. You can use it to determine one partner per empty partner
function at a later date, even if no partners were originally saved for the partner functions in
the document.

· The function can also be used for the same purpose in saved business transactions to
change partners previously saved in the document.

Example

1. You have a created a sales order with the sold-to party Johnson Electronics and saved
the empty partner function Sales Manager in the sales order. The system has read the
business partner master data and entered David Wilson as the contact person for Johnson
Electronics into the sales order.

2. You manually change the sold-to party to Johnson Mechanics. The contact person also
needs to be changed. You select the contact person David Wilson and use the Propose
Alternatives function to trigger the system to redetermine the contact person, based on the
new sold-to party. The system offers you two alternative contact persons for Johnson
Mechanics, James Kahn, and Nicola Smith, in a dialog box for your selection. You select the
contact person Nicola Smith and the system automatically replaces David Wilson with Nicola
Smith as the contact person in the sales order.

3. You select the Sales Manager partner function and click Propose Alternatives. The system
reads the business partner master data and finds and displays three sales managers
relevant to the current document data, James Brown, Lucy Wang, and Jason O’Leary. You
select the sales manager Jason O’Leary and the system automatically enters him for the
Sales Manager partner function in the sales order.

PARTNER PROCESSING AND BUSINESS PARTNER MASTER DATA

Business partner master data is a crucial source of information for partner processing, and
relationships are the most important aspect of this information. Relationships exist in two
forms: general relationships and sales area-specific relationships. A general relationship is a
relationship that does not include any sales area data, while a sales area-specific
relationship includes data on one or more sales areas, and is only valid for those areas:
· A general relationship is valid for situations in which the system does not require sales
area-specific information. You determine that it is general by not assigning it to any sales
areas when you create it.

· A sales area-specific relationship is valid only for sales areas that you specify when you
create the relationship. You can create sales area-specific relationships only for partners
maintained in roles where sales area data is relevant, such as the sold-to party. Sales area-
specific relationships are known as sales area-specific partner function assignments.

When you create a sales area-specific partner function assignment, the system
automatically creates a corresponding general relationship at the same time. For example, if
you define David Wilson as the contact person for Johnson Electronics for sales area 1000,
the system also enters him as a general contact person for Johnson Electronics. The system
sees the sales area-specific partner function assignment as one use of a general
relationship.

It is possible to assign a relationship category in one case and a partner function in the
other based on mapping defined in the system

Example

Creating a general relationship:

1. You create your company’s customer, Johnson Electronics, as a corporate account.

2. You create David Wilson, your contact at Johnson Electronics, as a contact.

3. In Johnson Electronics’ master data, you enter David Wilson as a contact in the Contacts
assignment block.

4. In David Wilson’s master data, the system automatically creates the relationship in the
Work Addresses assignment block.

Although your company has three sales areas, you do not assign the relationship to any of
them. This makes it a general relationship.

Creating a sales area-specific partner function assignment:

1. You create your company’s customer, Smith Plastics, as a corporate account and assign it
the role Sold-To Party.

2. You create Ken Lee, your contact at Smith Plastics, as a contact.

3. In Smith Plastics’ master data, you assign Ken Lee to the partner function Contact Person
in Sales Area 1000/Retail/10.

In Ken Lee’s master data, the system automatically creates the relationship in the Work
Addresses assignment block.

Although your company has three sales areas, this relationship is only valid for the one you
specified.

PARTNER DETERMINATION USING BUSINESS PARTNER RELATIONSHIPS

When the system uses business partner relationships for partner determination, it searches
through the business-relevant connections between various companies and individuals that
you have stored in master data.

Prerequisites

You have created relationships and sales area-specific partner functions assignments in
business partner master data.

Activities

1. You define an access sequence that specifies the source(s) Business Partner
Relationships, or BP Relationships by Sales Organization.

2. You assign this access sequence to the partner functions that should be determined in
this way.
Example

What you do:

1. In master data for Johnson Electronics, you define the general relationship Johnson
Electronics has the ship-to party/recipient Johnson Storage. This relationship corresponds to
the partner function category Ship-To Party.

2. You assign David Wilson as the contact person for Johnson Electronics for sales area
1000/10/00. This means David is the right Johnson Electronics employee to contact for
business within this sales area.

3. You define an access sequence with two single accesses. In the first, the source is BP
Relationships by Sales Organization, and in the second Business Partner Relationships. (The
name of the access sequence could look like this: BP Relationships by Sales Organization ->
Business Partner Relationships.)

4. You assign this access sequence to the partner functions ship-to party and contact person
in the partner determination procedure for a sales order.

5. You create a sales order, and enter Johnson Electronics as the sold-to party.

What the system does:

1. To determine the ship-to party, the system looks first in Johnson Electronics’ sales area-
specific partner function assignments, but finds no ship-to party.

2. It then looks in Johnson Electronics’ general relationships, finds the ship-to party Johnson
Storage, and enters it in the sales order.

3. To determine the contact person, the system looks again in the sales area-specific
partner function assignments. It finds David Wilson and enters him in the sales order.

The following figure shows an example. (The first step inWhat the system does is missing.)
PARTNER PROCESSING AND ORGANIZATIONAL DATA

Organizational units, employees, and users from your company’s organizational model can
act as partners in transactions. In other words, they can perform partner functions in the
same way that other companies or outside people do. In these cases, they are entered in
the Parties Involved assignment block rather than in the Organizational Data assignment
block. For example, a sales representative could perform the partner function Employee
Responsible, or, in inter-company billing, an organizational unit within your own company
could be the Bill-To Party. Therefore, organizational data is a crucial source of information
for partner determination.

To use organizational data in partner determination, the system uses the determination
rules defined in organizational management. Therefore, when you specify organizational
data as the source in access sequences in Customizing for partner processing, you must
enter a determination rule.

Partner processing is able to recognize organizational objects because, when you create an
organizational object, the system automatically creates a corresponding business partner
with the role Organizational Unit. Therefore, an object, such as a sales group, has two
identities: one as an organizational unit and one as a business partner.

ATTRIBUTES AND RULES USED IN PARTNER DETERMINATION

Organizational attributes are characteristics that help define organizational units. You assign
them to units in the organizational model. They define, for example, whether a unit is active
in sales or service, or for which distribution channel or product group it is responsible.

Organizational determination rules find organizational data in transaction processing by

evaluating attributes in the organizational model and information in the transaction.

You can use these rules to determine partners from the organizational model. You must
specify a determination rule whenever you enter the source Organizational Data in an
access sequence. The following rules are used frequently in partner determination.

PARTNER TEAMS

A partner team is a group of individuals or companies involved in a specific sales project, or

even in a single transaction within a project.

Teams are used in opportunities, where they are known as “buying centers”. They support
sales methodology by giving you a way to keep track of people who may influence your
potential customer’s decisions about buying goods or services.

You can create buying centers in the Contacts assignment block in opportunities, and in
accounts. You can do the following:

· Enter the team members, such as contact people on your customer’s side.
· Assign characteristics, such as Technical Knowledge or Influence on the Budget to these
people.

· Record relationships between them, such as X Influences Y.

You can display and change relationships in a graphical view.

· Assign characteristics and ratings to the relationships themselves, such as X influences Y

strongly, somewhat or not at all.

· Choose predefined notes, such as Information is missing, to further describe team

members.

Structure

Customizing for partner teams consists of settings for characteristics, ratings, relationships,
and notes. With these settings you control what entries are available in transactions. For
example, if your Customizing settings include the characteristic Technical Knowledge, this
characteristic is then available to users creating transactions.

To organize characteristics, you assign them to characteristics groups. You can then mark
one of these groups as general, and assign the other groups, not marked as general, to
specific relationships or partner functions:

· Characteristics in the general group are available in transactions to describe partners in all
partner functions.

· Characteristics in groups assigned to specific relationships or functions are only available

for those relationships or partners in those functions.

Example

In Customizing you do the following:

· Create a new characteristics group that contains the characteristics Technical Knowledge
and Influence on the Budget.

· Define the ratings a lot, some and none for both of these characteristics.

· Assign this group to the partner function contact person.

· Define the note Information is missing.

A business user creates an opportunity and:

· Enters a partner as the contact person in the Contacts assignment block.

· Knows this partner has good technical knowledge, and therefore selects this characteristic
and the rating a lot.

· Does not know, however, if this contact person has influence on the budget, so does not
select this characteristic.

· Because he needs more information about this partner, he selects the note Information is
missing.

The data entered is now available to this user and his colleagues any time they open this
opportunity, and can help them plan sales strategy.

CONCEPTUAL DIFFERENCES: PARTNER PROCESSING IN SAP CRM AND SAP ECC

While SAP ECC uses the term “partner determination”, SAP CRM uses “partner processing”.
In SAP CRM, partner determination refers specifically to the process during which the
system automatically finds and enters partners in a transaction.

Maintaining Master Data

When you create a business partner in SAP ECC, you must create it as a customer, vendor,
employee or competitor. The partner type you choose determines what kind of master
records are created, and, later, what partner functions this partner can take on.

You have to create a partner separately for each type that is relevant. For example, if your
company both buys from and sells to a particular company, you have to create this
company as a customer and a vendor.

In SAP CRM, a partner automatically takes on all partner functions unless you specify (by
creating relationships) that other partners should take on these functions for the first
partner. This feature simplifies maintenance of master data because there is no need for
you to enter partner data repeatedly.

Partner Type in SAP ECC and Partner Function Category in SAP CRM
When you create new partners in SAP ECC, your assignment of the partner to a partner type
determines what kind of master records are created and what functions it can have. When
you define a new partner function, you also assign it to a partner type. Only partners of the
same type can have this function. The partner types are hard-coded in the system, and you
cannot change them or create new ones. Sales and distribution includes the commonly used
types customer, vendor, employee, contact person, and mail partner.

The partner function category in SAP CRM is a hard-coded key that is assigned to a partner
function. It allows the system to identify and work with the function. The system includes
commonly used partner function categories, such as sold-to party, payer, activity partner
and contact person. You cannot change them, or create new types.

There are more partner function categories in SAP CRM than there are partner types in SAP
ECC. They do not correspond to each other in any way.

Account Group in SAP ECC and Sales Classification in SAP CRM

The sales classification used for business partners in SAP CRM is also a category, such as
consumer. The sales classification is assigned to a business partner implicitly based on its
role.

If you distribute business partner master data between SAP CRM and SAP ECC, a partner’s
classification in SAP CRM determines its account group in SAP ECC, or the other way
around. If you replicate partners from SAP CRM into SAP ECC, you can only create SAP ECC
master records for those with the following classifications in SAP CRM:

· Consumer

· Customer

· Prospect

· Competitor

You can specify which account group in SAP ECC corresponds to which classification in SAP
CRM using the transaction PIDE in the plug-in for SAP CRM Middleware. Here you can also
make other settings for the distribution of business partner data between SAP CRM and SAP
ECC.

For more information, see Sales Classification.

Business Partner Relationship Category

Business partner relationship categories exist only in SAP CRM. They are the definitions of
business-relevant connections between partners, and include Has the Contact Person or Is
Married To. The system includes a number of relationship categories, and you can also
define your own. Many categories are hard-coded to correspond to partner function
categories.

Sources for Partner Determination

In SAP ECC there are fewer sources for partner determination than in SAP CRM, and you
can specify only one source for each partner function to be determined. The following
sources are available:

· Master data of one of the partners in the transaction

· A customer hierarchy

· Current user

· Table T024P (transaction OB51), which contains data on credit representatives

· User exits

SAP ECC generally uses the master data of the sold-to party, but you can customize it to
use the master data of any partner in the transaction. Other sources that are available in
SAP CRM, such as the preceding document or organizational data, are not available for
partner determination in SAP ECC.

In SAP CRM, there are more sources than in SAP ECC, and you can specify as many of them
as you want for each partner function to be determined. They include:

· Business partner relationships, by sales organization, of a partner in the transaction

· General business partner relationships of a partner in the transaction

· A current partner in the transaction

· Preceding document

· Organizational data

· A pricing hierarchy

· Current user

· Business Add-Ins

Sequences in SAP ECC and Access Sequences in SAP CRM

The sequence in SAP ECC indicates when the partner is determined, in other words, whether
it is the first partner determined in a transaction, or the second or the third, and so on. You
assign sequences to partner functions in partner determination procedures.

The access sequence in SAP CRM defines a search strategy that specifies the sources of data
the system uses when it determines a partner and the order in which it uses these sources.
It does not specify whether this partner is determined before or after other partners. In SAP
CRM, you specify when a partner is determined by making an entry in the field
Determination Time in the Customizing activity Define Partner Determination Procedure.

Product Master
Comprehension questions about the product master

Product Types

- Distinction between the ERP Product and SAP CRM Product

o The CRM product master represents products (for example, a hard disk), services
(for example, PC warranty, PC maintenance), warranties and financings (e.g.
leasing).

- Products can be service packages, bills of material or a combination of these.

- Configurable products, such as personal computers, are only given attributes and attribute
values when

the product is sold.

- Warranty information for individual objects is created with reference to product, for
example, product

registration via e-service. Product type IP (Intellectual property) is available for the media
industry.

- A separate number range can be maintained for each product type.

- Product type IP (Intellectual Property) is available for the media industry.

-1 Which product types exist in CRM?

In CRM, there are six technically different product types.

Materials – physical products, used in different scenarios (for example, Sales and Service)
Service – for example, services used in the service scenario

Financing and Financing Service – used, for example, in banking and the insurance
sector (leasings)

Warranties – used in the Service scenario

IP’s (Intellectual Properties) - media-specific product type

Example of Product

- In SAP CRM product maintenance it is possible to copy products.

- R3PRODSTYP maps the product types present in the ERP system. For this reason, it is
vital to assign

the base hierarchy R3PRODSTYP to make basic data set types available.

- Customer product numbers can be assigned. Customer product numbers are stored in the
relevant

relationships.

- A Global Trade Item Number (GTIN) is used for mapping the European Article Number
(EAN).

- Structured products can be created in SAP CRM in product maintenance in the same
manner as other

products. In addition, structured articles (sets, displays, and prepacks) can be downloaded
from the ERP

systems and represented in the CRM Server as structured products. Structured products can
also be

uploaded to ERP systems for retail and to standard ERP Systems.

Q - Display the relationships for your product. Why are no product relationships displayed?

A - Relationships

- The relationship Accessories plays a large role in the CRM product catalog, which is used in
the Internet sales scenario. If a customer adds a product to her shopping cart, additional
products can be suggested to the customer via the relationship Accessories. On the
Accessories tab page you can also see whether a product is an accessory product (back,
usage).

- Selection of other relationship categories:

o Customers (here, for example, a customer material number can be assigned)

o Financed by
o Manufacturers
o Vendors (here, for example, a vendor material number can be assigned)
o Components (a structured product is mapped with this)
o Services (default products for the service order processing)
o Spare parts (default products for the service order processing)
o Warranties (used in the product registration)

- For downloading the ERP customer material number to SAP CRM, there is the relationship
Customer/distribution chain.

Relationships are generally maintained in the CRM product master and not in the SAP ERP
material master.

In product maintenance for your product, switch from the General Data area to the
Relationships data area.

Go to change mode, if applicable. Use the Locator to search for the accessory product R-
1120.

Select it and drag it to the Accessories tab page.

Accessories are used in the product catalog (E-Commerce) and in the Interaction Center for
product proposal strategies.

Base Hierarchies

SAP R/3 SAP CRM

Material type R3PRODSTYP

Material group R3MATCLASS

Product hierarchy R3PRODHIER

- Before materials can be transferred from the ERP system to the SAP CRM system, base
hierarchies

must be created. This is performed with a Customizing download.

- R3PRODSTYP is the default base hierarchy. Products that are loaded to the CRM system
from the ERP
system should at least belong to this base hierarchy. Assignment to other base hierarchies
is optional.

- If SAP CRM is implemented without an ERP backend system, preparatory steps are
necessary before

product master data can be created in the CRM system. These preparatory steps are
documented in

Customizing: SAP Implementation Guide > Customer Relationship Management >

Master Data > Products > CRM Standalone

- The adapter object for transferring the base hierarchies is DNL_CUST_PROD1.

Maintain Master Data Download

Download of ERP material masters to the SAP CRM system:

o An initial download is performed at the start, when SAP CRM is set up. Existing
Customizing data is a prerequisite for a successful initial download. The middleware
settings act as a filter to control which data should be loaded. During the initial
download, a distinction is made between the object type’s business object,
customizing object and condition object.

During the initial download, product hierarchies are loaded from SAP R/3 into SAP CRM. The
Material group and Product hierarchy fields are compared.

o The delta download ensures that transaction data and master data are
permanently exchanged between the CRM and a back-end system. Customizing
changes are not updated via delta download.

Upload of CRM products to the ERP system:

- The upload of CRM product data is possible, but it can be performed automatically in the
standard

system. It must be carried out manually and individually for each product.

- Upload can be permitted or prohibited for each product in Customizing: SAP

Implementation Guide > Customer Relationship Management > Master Data >
Products > Settings for Product Type > Allow Upload for a Product Type

- After a product has been loaded from SAP CRM to the ERP system, changes are updated
by means of a

delta transfer, but only in the ERP direction.

Competitor Products
A competor product has a lean product master. This is controlled by the product category.
Competitive

products can be created on the portal and can be integrated into business processes for
Activity

Management or Opportunity Management.

_ Competitive product information is exchanged with the mobile client in both directions.

_ The following are standard delivered relationships:

o Competitor – competitor product

o Customer – competitor product
o Own product – competitor product

_ Competitor products are only available in the People-Centric UI.

Q - Display the material master in the SAP CRM system and familiarize yourself with
product maintenance.

A - COMMPR01 - Maintain Products

Q - View the detailed data in the General Data for your product. Has your product master
been created without any errors?

A - For example, are unit of measure, item category group, and sales and distribution data
correctly entered?

You can find the sales price transferred from the backend system on the Condition tab
page.

The product is assigned to both categories MAT_HAWA (R3PRODSTYP) and 00207

(R3MATCLASS). All the information (material type and material group) was derived from the
material master of SAP ERP.

Q - Enhance your product master in SAP CRM. A number of steps are necessary for this.
They should be performed in the following order: (Cross Clients)

A – Enhancing the Product Master: Overview

- The following slides explain the various elements necessary to enhance the product
master:

o Hierarchies
o Categories
o Set types
o Attributes
- Creation of attributes results in the creation of data elements and domains on the
database.

- Creation of set types results in the creation of database tables and other data dictionary
objects, as well

as function groups, function modules and screens.

- Set types can be assigned to categories. It is also possible to assign a view (tab page) on
which set type

information will be displayed. Additionally, it is possible to assign templates along with the
view when

assigning set types. Products that are categorized later thus automatically get predefined
characteristics.
_

1) First, create new attributes.

SAP menu > Master Data > Products > COMM_ATTRSET - Maintain Set Types and
Attributes

Set types and Attributes

- Attributes help describe products or individual objects. They are grouped into set types
and saved there.

A set is a specific instance of a set type. Set types are stored in the system as database
tables. Set types

enable you to perform detailed modeling of products and individual objects in the system.

- Particular set types (SAP standard set types) are predefined in the standard system. If
they are not

sufficient for your needs, you can define further set types of your own and assign attributes
to them. The

attributes can be those predefined in the standard system and also attributes (including
value ranges) that

you have defined yourself. However, it is not possible to assign user-defined attributes to
the set types in

the SAP standard system.

- Set types can be relevant to templates. When you define a template, you can specify
concrete values for attributes and assign them to various products later on by means of
other mechanisms.
- If a set type is already assigned to a product category, it is only possible to change the set
type description and possibly add other attributes.

- Only those set types can be deleted that are not assigned to a category (any more).

- An attribute is defined by its attribute type (for example, integer, character string or
date), its attribute

length and (optionally) its value range (for example, single values or intervals), or by a
value table.

Attribute: ZSIZE_MP3

Choose Create.

Description: mp3

Attribute Type: Integer

Attribute Length: 2

Choose the Value Range tab.

Single Value or Lower Limit: 15, 17, 19 and 21 (one row each)

Fixed Value, Description: 15, 17, 19 and 21 inches

Choose Save and Back.

2) Create a set type ZMP3_FEATURES and assign to it the attributes you created in the
previous exercise

Set Type: ZMP3_FEATURES

Choose Create.

Description: Mp3 Player Features

Product Type: Material (Checkmark)

Choose the Assigned attributes tab

Attribute: ZSIZE_MP3
Save the set type.

3) Create a category hierarchy and two categories.

SAP menu > Master Data > Products > COMM_HIERARCHY - Maintain Categories and
Hierarchies

Categories and Hierarchies

- Product categories are used to group products together according to various criteria.

- Categories inherit the product category and the set types of all superordinate categories.
For example,

the base hierarchy R3PRODSTYP contains the category MAT_. This contains various set
types, such as

basic product data and conversion of units of measure. The sub-category MAT_HAWA
inherits the set

types from MAT_ and has additional set types, for example, sales set types.

- The assignment of a product can be changed or deleted.

- You can maintain condition on the category level, for example, by defining cross-
product surcharges

or discounts.

- Example In the above case, a general set type Set 1 (for example, administrative
information relevant for every product) was assigned to a higher-level category High Tech.
This information is always passed down to all lower-level categories, which can in turn be
described by their own set types. For example, Set 2 could contain information about the
type of hard disk and motherboard. When a product is assigned to a product category, the
attributes stored in the relevant set types are displayed.

Choose New Hierarchy

Hierarchy ID: ZHIER_PME

Description: ZTEST_PME

Choose ENTER.

Select New Category

Category ID: ZTEST_PME

Description: ZTEST_PME
Choose ENTER.

Product Type: Material

Select the Set Types tab.

Choose Add set type ( ) and select your set type ZSIZE_MP3

Save your data.

4) Go to product maintenance and categorize your product by entering and saving the
relevant hierarchy and category in product categories in the SAP Basic Data.

SAP menu > Master Data >Products > COMMPR01 - Maintain Products

If necessary, find and open your product master (for example, using Locator -> Worklist)

Choose the SAP Basic Data view.

In the product category area, enter the hierarchy ZHIER_PME and then select the category
ZTEST_PME in the Category ID field.

Choose ENTER.

After a few seconds you see two new fields in the product master.

Templates on the product master

1) Display the set type ZMP3_FEATURES. Apart from the assigned attributes, what
differentiates this set type from the one you created in the previous exercise?

Set Type: ZMP3_FEATURES

Choose Display

In the characteristics, the indicator Template-Enabled is set.

2) Go to Customizing and call Maintain Mini-Templates (for products).

Display the mini-template CR100 (monitor characteristics).

Find:

By:

ID/Description:

Choose Start.
Expand the first entry Set Types and double-click the template below it.

You should see two attributes containing default values (Loudspeaker output and Maximum
contrast).

3) Display the category 00010 of the product hierarchy PCSHOP_01. Apart from the
assigned set types, what else can you see?

SAP menu > Master Data >Products > COMM_HIERARCHY - Maintain Categories and
Hierarchies

In the field Template (on the right beside the field Set type), you see the value CR100.

4) Now assign category 00010 of the product hierarchy PCSHOP_01 to your product
master.

What do you notice?

SAP menu > Master Data >Products > COMMPR01 - Maintain Products

Choose the SAP Basic Data view.

In the product category area, enter the hierarchy ID PCSHOP_01 and then select the
category 00010 in the Category ID field.

Choose ENTER.

After a few seconds you see two new fields in the product master, this time containing the
default values from the template.

Template Framework

You no longer need to enter and maintain data that is commonly required in a large number
of products, in each of these products individually. Instead, you maintain this data once only
in a mini-template, which the products then reference. Any changes made subsequently to
the mini-template are also reflected in the products that reference it, and in this way you
can make mass changes quickly and easily.

Prerequisites

Before you can work with mini-templates in product maintenance, you have to

 Create set types in transaction COMM_ATTRSET

 Activate these set types so that they can be used in mini-template maintenance by

o Setting the flag Template-Enabled when you create a new set type, or maintain an
existing set type
o Choosing Set Type -> Activate Templates in the menu for set types that have already
been generated or delivered, and that can be called up only in the display mode.

 A differentiation key-independent mini-template and a differentiation key-dependent

mini-template are then generated automatically for each set type.

 Maintain the appropriate data for your mini-templates in Customizing for SAP Product,
by choosing Cross-Application Components -> SAP Product -> Templates -> Maintain Mini-
Templates.

Differentiation Key-Dependent Mini-Template

A mini-template that brings together differentiation key-independent mini-templates with

their appropriate differentiation keys.

You can create data only for differentiation key-independent mini-templates, but not for
differentiation key-dependent mini-templates. However, it is not possible to assign a
differentiation key-independent mini-template to the relevant product set type in which you
want its data to appear. Only differentiation key-dependent mini-templates can be assigned
(via product categories) to set types.

In cases where more than one mini-template exists for a product set type, differentiation
keys determine which mini-template’s data is read at runtime. The information about which
mini-template corresponds to which differentiation key is stored in a differentiation key-
dependent mini-template. Therefore you need to assign differentiation key-independent
mini-templates to a differentiation key-dependent mini-template, which in turn is assigned
to a product set type. In this way, the correct data is read for a product, depending on the
differentiation key you enter.

Example

For the set type ‘Sales’, you define two differentiation key-independent mini-templates with
the relevant data:

 T1, with product group 01 and bonus group 01

 T2, with product group 02 and bonus group 02.

You also create the differentiation key-dependent mini-template D1, which does not contain
any data. Instead, it contains the information that the differentiation key for mini-template
T1 is distribution chain 1000/10, and for mini-template T2 it is distribution chain
1000/20.

The mini-templates T1 and T2 are grouped together and assigned to the mini-template D1,
which is then in turn assigned to the set type
‘Sales’.
When you enter distribution chain 1000/10 for a product during product maintenance, the
data from mini-template T1, which is linked to the differentiation key 1000/10 in mini-
template D1, is then read into the attributes of the set type ‘Sales’. The data in mini-
template T2 is not read in this case, because T2 is linked to another differentiation key.

Structure

The template framework consists of the following parts:

 Mini-template types

A mini-template type signifies the smallest set of attributes you can use to build a mini-
template. It does not contain any values itself, but rather represents a structure in the
application that can be filled with values.

 Mini-templates

A mini-template is a concrete occurrence of a particular mini-template type. Thus, a number

of mini-templates, containing different values in each case, can be based on one mini-
template type. Mini-templates can either be differentiation key-dependent or -independent.

-2 Can product and material masters be exchanged between SAP ERP and CRM? What
possibilities are there to do this and what are the differences between them?

Yes. Material and service masters can be loaded from SAP ERP into SAP CRM.

A customer enhancement can be used to transfer additional SAP ERP-specific data into the
CRM system as well as the standard information.

CRM product masters can be uploaded manually (individually) into SAP ERP.

Only data that is supported in SAP ERP is transferred.

Note: Proprietary set types and attributes are not transferred.

Article Creation
1) Double click on SAP LOGON.
2) Select Client as R/3-218.
3) Enter the User name and Password.
4) Select the language.
5) Enter.
6) A general screen is displayed.
7) Type /nmm41 for article creation.
8) An initial screen (create article) is generated.
9) Select the Article type as trading goods.
10) Enter the Merchandising Category(mdse. category) as 240101001.
11) Select the Article Category(Artl. Category) as single article.
12) Enter Sales Organisation as 0001.
13) Enter Distribution channel as 01.
14) Enter Distribution center 9017.
15) Enter Store as 4000.
16) Enter reference article.( it avoids filling all the important fields in Repetition) as 400000234.
17) In views select: a) Basic Data (b) Listing (c)Sales (d)Logistic-DC
18) Enter.
19) Coming to the view basic data.
20) Note the article number as 400000289.
21) Fill the article name in the field adjoining to the article number as E-bike.
22) In place of category(ct) fill IE.
23) Enter.
24) Coming to next view Listing.
25) Putting assortment grade as 1.
26) Enter the field Listing Procedure as 02 in both Store and Distribution Center.
27) Tick all the option windows expect Restrict listing in listing portion.
28) Click on Execute Listing
29) Click on deselect option.
30) Put the store number in place of Assortments window.
31) Enter.
32) Select the 4000 option from the assortment list.
33) Copy.
34) Save.
35) Enter.
36) Coming to the view Sales.
37) Enter.
38) Coming to the screen Logistics-Distribution Center.
39) Enter.
40) Coming to Logistic Stores .
41) Put Delivery Point as 1 or 2 .
42) Save
43) Article 400000289 is created.

Stock/Requirement List
1) Type /nmd04 for getting stock /requirement list(initial list).
2) Enter Article number as 400000287.
3) Enter .
4) The new Stock is shown .
5) The number of quantity has turned into 20 as 10 new is added to the The previous 10.

To put pricing of the created articles.

1) Go to R/3 218.
2) Type /nvk11.
3) A screen Create condition records is shown.
4) Put VKP0 (vkp0) in place of vacant field condition type.
5) Enter.
6) A window is displayed.
7) Select the option Article per site.
8) Tick.
9) A screen showing Create Sales Price Condition:Fast entry is displayed.
10) Put 9001 in place of Sales Organisation.
11) Distribution Channel as 01.
12) Site as 4000.
13) Put the article number in place of Article
14) Put sales unit as EA-each.
15) Put amount in place of field Amount.
16) Enter.
17) The other fields are displayed automatically.
18) Click on Save button.
19) A window is shown depicting Overlapping Validity Periods.
20) Click on Tick.
21) Conditions records are saved.

Enter Other Good Receipts

1) Type /nmb1c for entering other receipts for specific articles.
2) An initial screen is displayed.
3) Selecting Movement Type as 501.
4) Selecting Site as 9017.
5) Enter.
6) A screen showing new items is generated of movement type 501.
7) Put article number as 400000287 in Article space.
8) Put quantity as 10.
9) Enter.
10)A screen New item 0001 is shown.
11)Put Stor. Location as 1010 if it is from D.C. and 1000 if it is from Store.
12) Enter.

Adapter object overview

Log on to CRM

1) Type r3ac1.
2) Click on Filter settings for Material.Double click.
3) Click on the top left pencil mark.
4) Put the article number 900000011 in the Low category.
5) Save
6) A message asking to continue? Press yes.
7) A message asks whether you want to include the material into transportable change request?
8) Enter no to all.
9)A message is shown that Filters updated in this R/3 back-end.
10) Click on the tick mark also.
11) Enter.

Start initial load

Log on to CRM

1) Type /nr3as.
2) In place of Load Object type Material.
3) Execute.
4) Message displayed : Object is in status running.

Monitor Objects
Log on to CRM

(to see whether object has been loaded)

1) Type /nr3am1
2) Type object as material.
3) Execute.
4) A status :done is given for object name material.

Material change(it is product creation of CRM)

Log on to CRM

1) Type /ncommpr01.
2) It helps to see whether the product has been transferred from From R/3 to CRM.
3) In the top leftmost corner of the screen you have to fill Materials in place of field Find Article
number in place of ID/Description.
4) Click on button Start.
5) In the bottom you would find the Product, Description and Pr. Type.
6) Click on the product item
7) A screen is displayed for the specified product
8) It shows that the product has been transferred from R/3 to CRM.