Business partners occur in different functions (business and organizational) for mySAP CRM business transactions such as sales, activities, or service notifications. For example, when processing an order, you need at least a sold-to party (person ordering), a ship-to party (person receiving the goods), a bill-to party (person receiving the invoice), and a payer (person that pays).

All transactions in mySAP CRM involve business partners. Partner processing allows you to work with these partners consistently. The aim of partner processing is to enter different business partners for each business transaction and to manage their functions. Partner processing also ensures that the business partners carry out the minimum number of required functions in a document. For example, an order without a ship-to party would be incomplete, so the system could not process it.

Business partners also have relationships with one another. Business partners, such as the ship-to party, forwarding agents, or payers, have relationships with other business partners. Business partners (companies) also have normal employees and employees with more specific roles, such as contact persons or consultants. These business partners can also have relationships with one another. You can define these relationships in the master data in a mySAP CRM or R/3 system and you can use them in a business transaction to determine business partners for functions automatically.

Although documentation about partner determination in mySAP CRM exists, my clients often ask me how to implement the business logic involved with partner determination. Let me introduce you to the partner process and explain its components. I’ll explain how to configure a partner function and map it to a partner determination sequence. Then I’ll show you how you can use a partner determination Business Add-In (BAdI) to determine partners based on your business requirements.

Partner Determination

Partner determination is an aspect of partner processing that allows you to:

• Define partners with your company’s terminology
  
  
• Specify many aspects of how the system handles partners in transactions
  
  
• Set how mySAP CRM and R/3 exchange partner processing information
  
  
• Manage addresses for the business partners

Figure 1 shows an example of how partner determination works in a transaction. First, a user creates a sales order and enters the sold-to party (Step 1). Next, the system looks in the business partner master data to find the necessary partners and enters them in the sales order (Step 2). After that, the system looks in the organizational data for your company. It finds the employee responsible and enters that employee in the sales order (Step 3).

Figure 1

Example of partners determined in the sales order

Partner processing contains four building blocks (Figure 2). These blocks include partner functions, partner function categories, access sequences, and partner determination procedures.

Figure 2

Building blocks of partner processing

Partner functions: Terms that you use to describe your business partners. You assign the freely definable partner functions to partner determination procedures.

Partner function categories: Hard-coded classifications that you assign to partner functions. They often correspond to business partner relationship categories.

Access sequences: Search strategies that list data sources for partner determination. You assign the freely definable access sequences to partner functions.

Partner determination procedures: List which partner functions are mandatory and optional in transactions. In these procedures, the system assigns access sequences to partner functions. You assign partner determination procedures to transaction types.

These four components interact with each other in a transaction to find the right partners, as shown in Figure 3. In this figure you can see the customizing settings and the determination processes that occur when you create a document. Now let’s see how the partner processing deals with partners in their business functions within documents.

Figure 3

Customizing settings and determination processes

Partner Functions

The main target for partner processing is to handle business partners in their business functions. You can define these business functions by defining partner functions in Customizing. Examples of these functions include the Sold-to party or the Ship-to party (Figure 4). You can access this configuration by following menu path IMG>CRM>Basic Functions>Partner Processing>Define Partner Functions.

Figure 4

Assign partner functions to categories and indicate usage

SAP delivers many predefined partner functions, but you also can define new partner functions as your business requires. Say you are running mySAP CRM in a hospital and you want to create a sales order for each patient. In this case, you would not want to call a patient a “sold-to party;” rather, you would like to change this to “patient.” The doctor assigned to the patient becomes “doctor” instead of “sales person.”

You assign each partner function to a partner function category and a Usage (scenario), as shown in Figure 4. For example, in Figure 4 Sales assistant is a partner function that is assigned the partner function category Employee. The usage for this scenario is Customer Relationship Management. After you assign each partner function to a partner function category and usage, the standard SAP business logic starts to work in a transaction. I explain partner function category in more detail in the next section.

When you select the partner function category and usage, the system populates the relationship category (Relatshp Cat.) in Figure 5 automatically. This is a relationship that is available in the business partner master data. For example, if in Figure 4 you define a new partner function called Doctor and assign to it partner function category Contact Person, then the system selects the Is Contact Person For relationship category automatically (Figure 5).

Figure 5

Relationship category

The system uses this relationship category in the business partner master data, which you can access by following menu path SAP Menu>Master Data>Business Partners>Maintain Business Partner (Figure 6). For example, imagine that after you define the new partner function Doctor, you would like to set a particular doctor as the patient’s family doctor. When you go in the business partner master data and create a new record for a Doctor, as in Figure 6, you can see this relationship in the Relatshp Cat..

Figure 6

Relationship category in business partner master data

You can block a partner function to prevent the partner from performing a particular function. You can block partner functions in two different ways. One method involves editing the master data to prevent a partner from ever performing that function. The other method involves creating a partner process to prevent the main partner in a transaction (e.g., the sold-to party in a sales order, or the activity partner in an activity) from performing another function in that transaction.

For example, say your opportunity transactions include the partner functions sales prospect, contact person, employee responsible, and competitor. To ensure that no one mistakenly enters a sales prospect as a competitor, in Figure 4 check the Block column for the partner function Competitor. This setting applies to the competitor in any transaction, not just an opportunity.

Partner Function Categories and Scenarios

Application programmers cannot code on the partner function because you define it in Customizing. This is a big difference between the partner handling in R/3 and in mySAP CRM. In R/3, programmers hard code partner functions, so you can define your own partner functions. However, these cannot replace the ones SAP delivers. In mySAP CRM, you can replace the standard SAP partner functions. This allows you to define your own partner functions according to your business requirements. You can use them in the transactions, while retaining the use of SAP-delivered business logic behind the partner function.

To enable this, you must assign each partner function to a partner function category and a scenario (usage) as shown in Figure 4. SAP developed the partner function categories based on common business processes. If you have a business case that does not fall within the standard partner function categories, SAP provides the partner function category Undefined Partner.

Other examples of partner function categories include:

• Sold-to party
  
  
• Ship-to party
  
  
• Payer
  
  
• Bill-to party
  
  
• Contact person

Although you cannot define your own partner function category, you can create your own partner functions that you can link to one of the standard partner function categories. For example, in the case of a hospital, say you define the partner function Patient. As I explained in my earlier example of a patient in a sales order situation, the patient represents the sold-to party. Hence, the system maps the Patient partner function to the partner function category Sold-to party. This ensures that the SAP-delivered business process for the sales order can work.

Business coding is related to the partner functions’ categories. Also, it defines their semantics (the meaning of the category terms). Semantics may vary by business use, so you must define the partner functions by scenario (usage) as well. For example, a ship-to party within mySAP CRM may be any business partner in the system, including employees, customers, or organizational units. However, in SAP Enterprise Buyer Professional (EBP), only employees or organizational units should act as a ship-to party. Depending on the usage, the partner function categories have different business coding.

Use of the individual function usage depends on the application, so I will not go into more detail here. After you set up your partners, you can set up partner determination procedures to enable mySAP CRM to automatically determine business partners in transactions.

Partner Determination Procedures

To set up rules for the system that define how to handle partners in business functions in different processes, use a partner determination procedure. The partner functions tell the system in which functions the business partners should appear in business transactions. Partner determination groups these functions to assign to the individual transactions or transaction items. mySAP CRM represents the partner determination procedure with an eight-digit alphanumeric ID that is not language dependent. To define the partner determination procedure, follow menu path IMG>CRM>Basic Functions>Define Partner determination Procedure (Figure 7).

Figure 7

Partner determination procedure

You can change this procedure according to your needs or create your own partner determination procedures by selecting the appropriate settings in Figure 7. Here are some of the key fields in this screen:

• Block Determin. (block determination): Select this check box if you want to block the system from performing partner determination in the documents to which you attach this procedure.
  
  
• Log: Select this check box if you want to know how the system determined the partners in the transaction. You should not switch it on in production systems because this can reduce system performance.
  
  
• Permitted Functions: Unlike R/3, in mySAP CRM you can define the procedures as Only Functions assigned in the procedure (restrictive) or All Defined Partner Functions (open).

Next I’ll explain the individual characteristics that you can define for each partner function in a partner determination procedure.

Partner Control Data

In addition to the individual partner functions, you also can assign characteristics to the corresponding functions. This includes, for example, labeling the partner function as a mandatory role (must be available and assigned) or restricting the partner functions’ changeability.

Follow menu path IMG>CRM>Basic Functions>Define Partner determination Procedure. Select the partner determination procedure, then click on Partner Functions in Procedure in the Dialog Structure menu. In Figure 8, the partner determination procedure has five partners in it.

Figure 8

Partners in the partner determination procedure

Select a partner function, such as Activity Partner, then click on the lens icon to enter the characteristics (Figure 9). Each of the fields in this screen affect how the system determines a partner function and how the partner function behaves in a transaction. The link between partner function and transaction is the partner determination procedure. What follows are descriptions of some key characteristics.

Figure 9

Characteristics of the partner functions in the procedure

Block Entry on Interface: You use this characteristic if you want the system to determine a partner function and you do not want the user to manually enter it.

Changeable (if Correct After Entry or Determination): Indicates whether the user can change or delete the partner who has this function in a transaction.

No. of Occurrences (Lowest or Highest): Defines how many partners the system determines for this partner function. For example, in the hospital scenario, the sales order document must have at least one patient. I entered 1 in the Lowest field for this partner function. If a user does not enter a patient in the sales order, then the system returns an error.

Selection Limit (Select.Screen): With this parameter, you can indicate whether you want a partner selection pop-up screen to appear that limits the number of partners you can choose.

Calendar maintenance: Particularly in activity processing, the system maintains calendar entries for business partners automatically. You can use this indicator to denote whether the system should maintain a calendar for the business partner by default.

Changeable addr: Determines if the user is allowed to change the partner’s address in the document.

Address for Trans. (address for transaction): Specifies which address the system should use as a source for the business partner address. A default value for this indicator comes from the partner function category assigned to this partner function. If the business partner has not maintained a corresponding address, the system uses its standard address.

Standard address only: If you set this indicator, the system determines only the business partner’s standard addresses automatically.

No Effects on Address Changes to Preceding Documents (Trigger Address Change References in Change Case): You can set this indicator if the system should not change a manually changed address in a follow-up document. In this case, the address should be duplicated. The default value is blank. This field has no effect on master data.

Access sequence: Specifies the access sequence that the system should use to determine the partner function.

Determination tm.: Specifies the point at which the system should carry out partner determination. The user, who also determines the point at which it takes place, triggers determination. Partner determination has three time points: recurring, product entry, and on save.

Block Determin.: Denotes whether the system pre-assigns a partner function automatically. If the function is not pre-assigned, the system carries out a search if the partner function is manually entered in the document (without the user pre-assigning it).

Access Sequences

Automatic partner determination is the most complex functionality that partner processing offers. It enables the automatic determination of partners from sources, such as the business partner model, to prevent the user from entering already known information that the system has stored elsewhere. You use access sequences to find this information in the system. Unlike R/3, mySAP CRM partner processing uses multiple sources to determine a single partner to place in a partner function. You can define your own access sequences and attach them to the partner functions in the partner determination procedure.

In mySAP CRM it is also possible to define access sequences similar to text determination to enable a search. For a partner function in the partner determination procedure, you can enter only one source partner function (which is similar to R/3). In this case, you would define an access sequence that tries to assign the relevant partner function.

Access sequences represent a kind of search strategy. You can find access sequences by following menu path IMG>Customer Relationship Management>Basic Functions>Partner Processing>Define Access Sequences (Figure 10).

Figure 10

Access Sequences defined in the system

Access sequences define where to look in mySAP CRM for a partner and, if it is not found there, where else to look. An example access sequence would be to:

1. Try to get the partner from the preceding document
   
   
2. Try to get the partner from the business partner relations of the sold-to party

Select a sequence in Figure 10 and click on Individual Accesses in the Dialog Structure menu to view the access sequence details (Figure 11). The system continues searching for the partner according to the areas listed in sequence.

Figure 11

Details of the access sequence

The following describes the general individual indicators in an access sequence and their effect on the system:

Batch Seq.: This is the same as sequence, except that the batch sequence must have a single sequence. Each batch sequence value may occur only once. This is necessary to achieve deterministic behavior for determination in the batch.

Dialog Seq.: Specifies the sequence in which the accesses should occur. Accesses with the same sequence values are interpreted as alternatives. The system delivers these results simultaneously as a results quantity.

Source: Specifies the sources. SAP defines many sources — here are some of them:

• Preceding Document: This source is only important when creating with reference (to another document). You can use the indicator Partner Function in Source to assign the current partner function with a different source partner function from the preceding document. The system assigns the partner function provided with the access sequence. Alternatively, you can enter the combination Function Category in Source/Usage in Source if you only know the function type or subtype in the preceding document. When you have several options, and only one is required, the system evaluates the MAINPARTNER indicator from the source function. If a source is not contained in the access sequence for a partner function, the system does not copy the partner function when creating with reference.
  
  
• Organizational data model: You can use the organizational data model only for partner functions with specific partner function categories.
  
  
• User: The system uses the current user (in the case of an online user) to determine the related business partner (central person) and assign the partner function.
  
  
• BAdIs: You can set the source as BAdI, which means that the system determines the partner based on the rule in the BAdI.
  
  

After you set these fields, select an access sequence and click on the lens icon to view the details (Figure 12). In this screen, you have several settings to consider:

• Allow Incorrect Source: Indicates whether this determination step should take place or not if the source partner has a related error (e.g., does not exist, does not have all of the necessary master data)
  
  
• PartFunct in Source (partner function in source): Specifies which partner function the system should assign to evaluate the source. You cannot use it for all sources. If the system assigns several partners to the given partner function in a transaction, the partner is used with the MAINPARTNER indicator set.
  
  
• Funct. Cat. in Source (partner category in source): Specifies the partner function category that the system uses to evaluate the source. It is not permitted for all sources. A prerequisite for using the partner function categories in this indicator is the uniqueness of the function categories. When you enter the partner category in source, the usage in source is also necessary.
  
  
• Usage in Source: Specifies the subtypes that belong to the partner function categories to better specify the source function categories.

Figure 12

Individual accesses in an access sequence detail view

Assign Partner Determination Procedure

After you complete the access sequence settings, attach this partner determination procedure to the transaction type of your document. You can assign the partner determination procedure in Customizing for partner processing to various document header roles (e.g., activity, sales) as well as item roles (e.g., sales, service). As shown in Figure 13, I assigned the partner determination procedure 00000002 to transaction type Business Activity. You can access these settings by following menu path IMG>Customer Relationship Management>Transactions>Basic Settings. After you complete this configuration, the system determines partners automatically in your transaction based on the rules you configured.

Figure 13

Link partner determination procedure and transaction type

Amit Khanna

Amit Khanna has six-and-half years of experience with mySAP CRM. He joined SAP Labs India in February 2000 as a developer, where he managed a team 17 developers in the area of mySAP CRM. He moved to SAP CRM Consulting in June 2005 and is involved in several mySAP CRM projects.

You may contact the author at amitk76@yahoo.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.