BP and ORG ModelIntegrationSPRO > CRM > BP > Integrating Business Partner > Organization Management > Set Up Integration with Organization Management.

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

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

GeneralYou 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 areawhen 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 documentsCan be labeled as obligatory in Customizing (org. data profile) We recommend that you label the distribution chain as obligatory for sales documents

Sales organizationonly 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 channelis an organizational object is defined in CustomizingIs 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.

Divisionmust 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 officeis 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 groupcan 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 organizationdisplayed as maintenance planning plantown 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 unitpossible; 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 documentis assigned to an organizational unit in the organizational structure as an attribute and, if required, is copied from the responsible organizational unit into the document.

ORGANIZATIONAL OBJECTS The following object types are available in CRM ORGANIZATION UNIT (Organizational object (object type key O), which is used to form the basis of an organizational plan. Organizational units are functional units of a company. Depending on how task distribution is organized in a company, these can be, for example, departments, groups or project teams.) POSITION (Organization object (object type key S) which shows the functional task distribution of individual items and their report structure in the organizational plan. Positions are concrete items in a company, set by holders (employees or CRM users), An organizational unit also has its own specific features (attributes). You maintain important data like address, validity period You define attributes for each organizational unit of each scenario, for example, currency, region, product group By assigning attributes, you maintain sales areas by assigning the attributes distribution channel and division to a sales organization or its subordinate organization.CRM distinguishes between organizational and business attributes: organizational attributes define the type of organizational unit, for example, whether it is a sales organization or a service group. business attributes define the responsibility of an organizational unit, for example, for which distribution channel or product group an organizational unit is responsible. Attributes can have one or more values

DETERMINING ORGANIZATIONAL DATA When processing a business transaction, certain organizational data is mandatory depending on the transaction type. In the CRM System you have the following options for determining organizational data in the document. These can be set in Customizing and are dependent on the transaction type: No automatic determination 1. You have created an organizational data profile in Customizing, in which no determination rules have been entered. 2. You have assigned this organizational data profile to the required transaction type.Automatic determination 1. You have created a determination rule in Customizing for each determination path with the corresponding rule type. 2. You have defined one or two determination rules in the organizational data profile for evaluating the organizational data profile of a business process. 3. You have assigned the organizational data profile to a transaction type.You carry out the settings in Customizing for CRM. Organizational Data Organizational Management Choose Master Data Determination. You can find further information in the documentation there. When determining organizational data, the system takes the organizational data profile defined in Customizing and the determination rules from this profile. These determination rules specify which fields are taken into account when the system determines organizational data from the document data (for example, business partner number, telephone number). There are two determination paths provided in the CRM system Responsibilities Rule Type You would use the responsibilities rule type if you Want to determine organizational data for individual responsibilities Havent created an organizational plan but want to create one Have a lot of organizational units and must only assign a few attributesFor the system to determine organizational data using the responsibilities rule type, you need to use organizational units. However, these do not need to be linked. Therefore you do not need to create an organizational structure for this determination path. The attributes are defined directly in the rule container. If you use rule resolution using responsibilities, you must not assign attributes in the organizational structure, other than the distribution channel and division attributes that are necessary for showing the sales area. Organizational Model Rule Type You would use rule resolution using organizational model if you Have created an organizational plan or have distributed a plan into the CRM system and want to use this for determining organizational data. Assign a lot of attributes to the organizational units and these are to be evaluated.

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

Check List if Organizational Datanot found

The system does not determine the organizational data for a transaction document (for example, telesales order) as expected (org data screen is partly or completely empty or the required organizational units were not found).This can have various causes. You can use the following checklist to check the settings for determining organizational data.

In the Internet Sales scenario, the organizational data is always read from the product catalog variant. The following Customizing settings are therefore not valid for internet orders. Check List1. Organizational data modelIs the organizational data model maintained and are the organizational units provided with attributes?Are the organizational units Sales organization, sales office, sales group, service organization and purchasing organization marked as such?Make sure that the organizational units have been activated for the required scenario during maintenance of the organizational model (for example, the service organization for the Service scenario). On the Attribute tab page in the field Object is permitted for scenario, activate .2. AttributionAre the organizational model and attributes uniquely maintained?When attributing organizational units overlapping may occur, for example, in the following cases: If you evaluate attributes at a higher level of the organizational model (for example, the root), these attributes and the assigned values are passed on to all subordinate organizational units for the corresponding scenario, if they are not overwritten by another value. In some cases therefore several organizational units have the same value and attribution overlaps. In organizational data determination all of these organizational units are determined with the searched value.You can avoid this type of overlapping by overwriting the subordinate organizational units that have inherited values with other values, or, by providing them with restricted values. To make restrictions, you can use the exclusion flag Excluded. If you go over the value areas for attributes, there will be overlapping:You assign the postal areas 1 12000 to organizational unit 1, the areas 5000 to 25000 to organizational unit 2. Both organizational units are responsible for a sold-to party with the postal code 10 000. If the system determines several organizational units for a document, a selection screen appears in which you can select the required organizational unit for the current document.3. Organizational data profileHas an organizational data profile been created and defined in these determination rules?4. Organizational data profile assigned?In order that organizational data is determined at header level for the transaction, the organizational data profile must be assigned to the corresponding business transaction type.If the organizational data at item level should be copied from the header data, an empty organizational data profile (without determination rules) must be assigned to the corresponding item category. If no organizational data profile is assigned, the organizational data set in the business transaction document is empty at header and/or item level and the screens for organizational data are not displayed. It is not possible to carry out organizational data determination independently from the header data for the item level. This means that no organizational data profile can be assigned to an item category if it contains a determination rule. 5. Source dataIs the source data that is required for determining organization data available in the document?If, for example, the determination rule states that the responsible sales organization should be determined using the postal code of the sold-to party but no address has been defined here, the system is not able to determine the sales organization.