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.

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)

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