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.

PRECONFIGURED SCENARIOS

Preconfigured scenarios are like business scenarios templates for key areas of CRM – Marketing, Sales, Service and Analytics. These scenarios illustrate the typical business process in each area. Some of the Preconfigured scenarios are:

For details and downloads goto – http://help.sap.com/bp_crmv12007/CRM_DE/HTML/index.htm. Choose the Preconfigured scenarios under Business Information on the left menu

Sales

C62 – Activity Management

The Activity Management scenario supports the sales and service process in all phases and provides information about all activities carried out to serve the customer. The purpose of this document is to describe an activity management scenario that supports a sales process with various types of activities and tasks.

C66 – Account & Contact Management

The Account and Contact Management scenario supports the sales process and shows how to create and change accounts and contacts, what options are available and which functions can be used.

C63 – Opportunity Management

The Opportunity Management  scenario creates a framework for pursuing sales projects from the start, and as they progress, and provides the basis for a target-oriented analysis and optimization of your sales processes.

C67 – Pipeline Performance Management

The Pipeline Performance Management  scenario helps sales managers and sales representatives to analyze their sales pipeline, to identify gaps and critical opportunities. It also helps to identify and monitor opportunity changes in the pipeline. In addition, the sales managers and sales representatives can simulate what-if scenarios and immediately trigger the right actions to resolve issues and meet their targets.

C79 – Territory Management

The Territory Management  scenario enables you to structure and organize your territories according to criteria of your choice. You do this using the territory hierarchy.

C82 – Interaction Center Sales

The scenario shows how the agent processes a call list as a basis for outbound phone calls to selected customers in order to offer them certain products. During the conversation the agent is guided by an interactive script.
The whole scenario takes place in the Web-based environment for the Interaction Center.

C39 – Lean Campaign Management

The Lean Campaign Management scenario describes the planning, execution and analysis of a marketing campaign, for example in connection with a product presentation event.

 

C69 – Service Order Management

The process starts with the creation and printout of a service quotation and goes on with the appropriate service request related steps like creation, planning and dispatching, confirmation, completion, billing (via ERP backend system), invoice printout, and service evaluation.

 

C38 – Complaints and Returns Management

The SAP Best Practices scenario Complaints and Returns Management  illustrates the entire process flow from creation of a customer’s complaint in the system, inbound delivery of a defective product to the creation of a credit memo for the customer.

CRM BUILDING BLOCKS

The following table shows some of the building blocks and their functionality available for SAP Best Practices for CRM – V1.2007.

For the complete list; click – http://help.sap.com/bp_crmv12007/CRM_DE/HTML/index.htm. Choose Technical Information of the left menu

BUILDING BLOCK NAME	DESCRIPTION
B01: CRM Generation	The building block CRM Generation  describes the activities to generate all necessary runtime objects for SAP CRM. This building block is a prerequisite for the installation of all CRM scenarios delivered by SAP Best Practices for CRM.
C71: CRM Connectivity	Connectivity refers to the interface, transfer of data, and configuration settings between the different components of SAP Business Suite. This building block describes the activities that are necessary to connect the various components of an SAP CRM system landscape. This building block is the prerequisite for the installation of all business scenarios delivered by SAP Best Practices for CRM.
B09: CRM Customizing Replication	The building block CRM Customizing Replication  contains the configuration steps that are essential to perform the necessary activities to replicate data from the ERP system to the CRM system and vice versa. This building block is a prerequisite for the installation of all CRM scenarios delivered by SAP Best Practices for CRM.
C01: CRM Organizational Model	Organizational Management in CRM offers you a flexible tool for handling your company’s task-related, functional organizational structure as a current organizational model. You can maintain the company structure including the positions and employees in an application and assign specific data (attributes) to the organizational units. The organization model will be especially used for organizational data determination within the CRM scenarios for marketing and sales. Compared to ERP, the use of the organizational model in CRM is more comprehensive, flexible and dynamic. A synchronization of the organizational structure for sales in ERP and CRM is possible via mapping of organizational units. This is a prerequisite for integration of master data and transactional data between ERP and CRM. The building block CRM Organizational Model  describes the setup of a sample organizational structure which is the basis for all SAP Best Practices scenarios.
C03: CRM Master and Transaction Data Replication	The building block CRM Master and Transaction Data Replication  contains the configuration steps that are essential to perform the necessary activities to replicate data from the ERP system to the CRM system and vice versa. This building block is a prerequisite for the installation of all CRM scenarios delivered by SAP Best Practices for CRM. This building block is not required if you run CRM in a standalone mode, that is without an ERP back-end system.
C11: CRM Marketing Master Data	The building block CRM Marketing Master Data  provides the master data that is relevant for the CRM Marketing scenarios.
C23: CRM Basic Sales	The building block CRM Basic Sales  contains central sales-specific configuration of those process steps that are relevant for all sales scenarios.
C36: CRM Account and Contact Management	The building block CRM Account and Contact Management contains the configuration of those steps that are essential to perform the specific process steps of the Account and Contact Management scenario.
C32: CRM Opportunity Management	The building block CRM Opportunity Management  contains the configuration of those steps that are essential to perform the specific process steps of the Opportunity Management  scenario.
C26: CRM Service	The building block CRM Service  contains the configuration of those steps that are essential to perform the service-specific process steps concerning all service scenarios of SAP Best Practices for CRM using also an ERP system as back-end system.
C41: CRM Interactive Reporting	The building block CRM Interactive Reporting  provides a simplified customer intelligence reporting framework without the need of a SAP NetWeaver BI system.

SAP puts a Web 2.0 spin on CRM upgrade

CRM 7 will feature an easy-to-use Web 2.0-style interface that SAP hopes will help increase usage rates in the enterprise

SAP on Tuesday announced an update to its customer relationship management software with a Web 2.0-style interface that could help to increase usage rates among workers.

Companies often report that usage levels for their business software is lower than they would like, with salespeople managing accounts in Microsoft Outlook instead of their more expensive CRM software, for example. SAP hopes to address that with CRM 7, an update to its CRM (customer relationship management) product that will be widely available early next year.

People accustomed to using easy-to-use Web applications in their personal life are starting to expect that same ease of use in their business software, said Stefan Haenisch, SAP’s vice president of CRM product management.

“We’re trying to bridge the gap between a cool, user-driven Web application, and an enterprise software application,” he said.

CRM 7 has a portal-like interface that workers can customize with information from within the CRM system, such as reports, or from external sources, such as publically available newsfeeds and maps. They can change the color and “theme” of the interface by clicking through different designs, or skins.

The idea is to make the software more appealing to work with, but also to provide information that might increase productivity. A salesperson might add a feed showing news about companies he plans to visit that week, Haenisch said.

The software also looks different inside. The content is laid out in task windows that users can drag and drop to rearrange. The interface is built on SAP’s NetWeaver and uses AJAX (asynchronous JavaScript and XML), a popular interface technology on the Web.

There are also new CRM tools, including a pipeline management tool that can run “what if” scenarios on upcoming deals. A salesperson can view quarterly sales in a bar chart, and then move deals from one quarter to the next, or push expected targets up or down, to see the effect on the quarterly totals, Haenisch said.

CRM 7 will also include telephony software that uses Internet Protocol, a technology SAP acquired when it bought Wicom Communications last May. The software lets companies set up a virtual call center that could include workers in remote locations, without having to invest in specialized telephony hardware, Haenisch said.

There is also an updated trade promotions management tool, which can help marketing departments manage hundreds of concurrent programs with retail stores.

The global CRM market is growing quickly, according to Datamonitor, pushed along by organizations that recognize the benefits of creating a positive experience for their customers. The analyst company expects worldwide CRM sales to hit $6.6 billion in 2012, up from $3.6 billion in 2006, with a compound growth rate of 10.5 percent per year.

SAP and RIM team to bring native CRM to BlackBerry

SAP AG and Research in Motion Ltd. (RIM) today revealed a partnership to run SAP’s CRM application natively on the BlackBerry and eventually to bring the full SAP suite to the device.

“In 2004, RIM and SAP announced a strategic partnership around SAP CRM where a sales professional could access CRM by using the BlackBerry device as a browser,” said Bill McDermott, president and CEO, SAP Americas and Asia Pacific/Japan. “Today’s a different day, a very different solution. Today we’re talking about CRM natively integrated into the BlackBerry device itself.”

For example, with the new partnership, mobile sales professionals can have leads and opportunities pushed to their BlackBerrys directly from SAP CRM. Similarly, when a mobile user clicks on a contact, the BlackBerry can access up-to-date service or sales orders.

Source – http://searchcrm.techtarget.com

Hottinger Baldwin Messtechnik Implements SAP CRM 2007

Hottinger Baldwin Messtechnik (HBM) now handles its customer relationships with SAP Customer Relationship Management 2007 (SAP CRM 2007).

The company is now implementing SAP components for marketing, sales, and analytics at a total of 18 locations worldwide. SAP CRM 2007 is already integrated into HBM’s British subsidiary, which is the global leader in high-tech measurement and testing products. The company is also currently rolling out the application in Scandinavia and the Benelux countries; overseeing the implementation of this project is the SAP partner Sybit. SAP CRM 2007 is to replace the Siebel system HBM has been using for CRM.
According to Frank Hölscher, manager of sales applications at HBM, the company’s users have warmed in particular to SAP CRM 2007’s intuitive interface. In addition to the application’s ease of use, HBM is looking forward to major advantages based on its integration in SAP ERP: Hölscher cites the software’s ability to design end-to-end quotation processes – including product configuration – and eliminate redundant entries of quotations and orders.

Source – http://sap.info/en

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)

 

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.

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 /Feature	In R/3 System SD	In the CRM System
General	You maintain the sales organization in Customizing under Enterprise Settings. You maintain the organizational plan for 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 sales area-related data from the customer master.	You maintain the organizational plan once for all applications in CRM. Scenario-specific data in the structure is assigned by attributes to the organizational units. These attributes are passed on to subordinate organizational units. Organizational structures can be maintained and adapted dynamically. Responsibilities are defined independently from the business partner master and are determined, if required, from the organizational structure.
Sales area	when creating a sales document entered manually or determined using the customer master for the sold-to party	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).
Distribution chain (sales organization and distribution channel)	is obligatory in sales documents	Can be labeled as obligatory in Customizing (org. data profile) We recommend that you label the distribution chain as obligatory for sales documents
Sales organization	only one sales document can occur in a sales organization This organization is responsible for processing a business transaction.	The organizational unit responsible for the document need not be a sales organization. It can also be, for example, a sales office. You can assign the business partner directly to the sales organization
Distribution channel	is an organizational object is defined in Customizing	Is not an independent object. It is an attribute that can be assigned to an organizational unit. Can be replicated from the R/3 System (during the initial download), or, can be defined in the CRM System in Customizing.
Division	must be used. If a company does not use division schedule lines, a general division (‘cross-division’) must be set up and used. is defined in Customizing is an organizational object can only be assigned to one distribution chain and not to a sales organization. Sales document has a sales area, therefore also a division at header level (header division).	Use of the division can be switched off throughout the system can be replicated from the R/3 System (during the initial download), or, can be re-defined in the CRM System in Customizing. The division is not an organizational unit, it is an attribute. Several divisions can be assigned to a sales organization independently of the distribution channel. There is no header division. The division only exists at item level. It is always derived from the product.
Sales office	is assigned to a sales area can be assigned to a customer in the customer master.	The sales office can be directly assigned to a sales organization. Business partners and other attributes (for example, postal code area) can be assigned to the sales office, independently of the sales area.
Sales group	can be assigned in the sales data of the customer master to a customer as a responsible group Assignment of an employee to the sales group, sales office and/or sales organization takes place in personnel master via Info type 900, an employee can only be assigned to one organizational unit (sales group)	Business partners and other attributes can be assigned to the sales group. Assignment of employees to an organizational unit using positions in the organizational model This makes it possible to assign an employee to different positions and organizational units.
Service organization	displayed as maintenance planning plant	own entity, comparable with sales organization in Sales scenario, is responsible for processing service transactions
Determination of employee responsible (ER)	via customer master for sold-to party (or another partner in accordance with partner determination procedure)	via the sales area-dependent partner function Employee responsible in the BP master via the BP relationship defined in the business partner master via assignment in the organizational structure
Organizational unit as business partner (cross-company)	not possible; a customer master record must be created for the organizational unit	possible; when creating an organizational unit, a business partner master (organization category) is automatically created.
Sales district (customer district)	is defined in the customer master and copied from there into the document	is assigned to an organizational unit in the organizational structure as an attribute and, if required, is copied from the responsible organizational unit into the document.

 

ORGANIZATIONAL OBJECTS

The following object types are available in CRM

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

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

 

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

· You maintain important data like address, validity period

· You define attributes for each organizational unit of each scenario, for example, currency, region, product group

· By assigning attributes, you maintain sales areas by assigning the attributes distribution channel and division to a sales organization or its subordinate organization.

CRM distinguishes between organizational and business attributes:

· organizational attributes define the type of organizational unit, for example, whether it is a sales organization or a service group.

· business attributes define the responsibility of an organizational unit, for example, for which distribution channel or product group an organizational unit is responsible.

Attributes can have one or more values

 

DETERMINING ORGANIZATIONAL DATA

When processing a business transaction, certain organizational data is mandatory depending on the transaction type.

In the CRM System you have the following options for determining organizational data in the document. These can be set in Customizing and are dependent on the transaction type:

No automatic determination

1. You have created an organizational data profile in Customizing, in which no determination rules have been entered.

2. You have assigned this organizational data profile to the required transaction type.

Automatic determination

1. You have created a determination rule in Customizing for each determination path with the corresponding rule type.

2. You have defined one or two determination rules in the organizational data profile for evaluating the organizational data profile of a business process.

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

You carry out the settings in Customizing for CRM. Organizational Data® Organizational Management ®Choose Master Data Determination. You can find further information in the documentation there.

When determining organizational data, the system takes the organizational data profile defined in Customizing and the determination rules from this profile. These determination rules specify which fields are taken into account when the system determines organizational data from the document data (for example, business partner number, telephone number).

There are two determination paths provided in the CRM system

Responsibilities Rule Type

You would use the responsibilities rule type if you

· Want to determine organizational data for individual responsibilities

· 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)

MIDDLEWARE

 

PURPOSE and ADVANTAGES

• Provides seamless back-end integration
• Provides Groupware Integration
• Synchronizes Mobile Client
• Is an integral part of the CRM Server

Requires:

• No Extra Software
• No Extra Installation
• No Extra Server

CRM Server contains the CRM Middleware which handles the data exchange with internal applications and external major components like SAP R/3, SAP BI, Non-SAP Systems etc

CRM Middleware can exchange messages with non SAP ERP Systems via standard interfaces like XML, SOAP etc

The data exchange between CRM Middleware and external systems is performed via adaptors. The adapters map and convert data between various formats

Load Objects ( BP Master data, Orders, Product Master data etc) can be exchanged between source ( eg. SAP R/3) and target systems (eg. CRM).

Load objects are stored in the SMOFOBJECT Table. Load Objects are grouped as follows:

- Business Objects

- Customizing Objects

- Condition Objects

 

BDOC’s

BDOC’s (Business Documents) are data containers that are used for processing business objects that logically belong together ( Eg. All data about one order, one partner etc)

BDOC Terminologies:

1. BDoc Type – This the structure of the BDoc that defines the business object ( Sales Order, BP, Contact Person etc). BDoc Types are defined and managed in the BDoc repository with the BDoc Modeler

2. BDoc Message – This contains the Modified fields only. These include new and deleted fields.

3. BDoc Classes

- Messaging BDoc’s

- Synchronization BDoc’s ( for Mobile only)

ADAPTERS

Adapters are special services that provide connectivity to external systems in order to exchange BDoc messages between Middleware and SAP R/3, Mobile Clients or other systems

 

DATA CONSISTENCY BETWEEN SYSTEMS:

Following Tools can be used to maintain Data Consistency

Solution Manager

- Customizing Scout and Distribution

Data Integrity Manager

- Synchronization of Transactional Data

- With the Data Integrity Manager, you can detect and repair inconsistencies between Objects across components within the SAP CRM system landscape

- TCODE – SDIMA

Requests:

- If you are aware of the inconsistencies, then you can use Requests. Requests loads the required data from SAP R/3 to CRM or vice versa. ( Request for some Objects may not be supported from CRM to SAP R/3)

TCODE –

R3AR2 ( To define a Request)

R3AR4 ( To Start a Request)

 

ADMINISTRATION

Replication

The replication takes place in a star-like fashion from the CRM Server to the Mobile Clients, SAP R/3. Non-SAP systems

Data is replicated to Sites (local databases) and not to individual persons.

This Replication model is created and administered in the Administration Console (TCODE – SMOEAC)

Site

Every receiver is represented by an Site. (TCODE – SMOEAC)

Publication

Grouping of BDoc types to be distributed by distribution type are categorized under Publication. (TCODE – SMOEAC)

Subscription

Assignments of Sites to Publications are Subscriptions. (TCODE – SMOEAC)

 

DATA LOAD and MONITORING

Initial load:

You can load Customizing and Business Objects from SAP R/3 to SAP CRM

Usually a Customizing Load is started before the Business Objects are loaded.

Due to dependency of Objects, a specific sequence during data load is necessary like –

- Customizing

- Business Objects

- Parent/Child relationship between different objects

To start the initial load goto – SAP Menu – Architecture and Technology – Middleware – Data Exchange – Start Initial Load

 

LOAD FILTERING

The objects to be exchanged between CRM & R/3 can be filtered using Filter Criteria

Filetr settings are stored in the table – SMOFFILTAB

Filters for Business Objects are pre defined ( Table – SMOFFILFLD)

Filters for Customizing and Conditions objects can be set on existing fields

Filter options allow the filtering at the Source, at the Target.

Business Objects – Can be filtered at Source, at Target, At Source & Target

Business Data – Usually filtered at Source

Customizing Objects – Can be filtered at Source only

Conditions Objects – Can be filtered at Source only

Filter Criteria settings – SAP Menu – Architecture and Technology – Middleware – Data Exchange – Object Management – Business Objects / Customizing Objects / Consition Objects

 

MONITORING TOOLS

· Monitoring Initial Load: R3AM1

· qRFC Monitoring:

o Outbound Queue Scheduler: SMQS

o Outbound Queue: SMQ1

o Inbound Queue Scheduler: SMQR

o Inbound Queue:SMQ2

· Middleware Trace: SMWT

· Middleware Portal: SMWP

 

TROUBLESHOOTING – CRM and ECC

 

In ECC:

- Check assigned logical system name – 3-digit system name – i.e. ECC

- Create RFC Destinations – SM59 or SALE

- Maintain table CRMCONSUM – to activate either R/3 or CRM as a consumer of the system you are maintaining the table in

- Maintain table CRMRFCPAR – Through this table the determination of the RFC destination for the data transfer is connected with the consumer, client, object name and transfer type

 

In CRM:

- Check assigned logical system name – CRM

- Create RFC Destinations – SM59 or SALE

- Maintain table CRMCONSUM

- Create a Site definition – SMOEAC – start the administration console in CRM