Skip to Content

Overview on Party Determination and Involved Parties in SAP Hybris Cloud for Customer

 

The blog should provide you an introduction on features and functions for Party Determination and Involved Parties offered in SAP Hybris Cloud for Customer.

You can determine involved parties for business transactions (documents) via party roles using a party schema that consists of pre-delivered and optional custom party roles with certain configuration options.

CONFIGURE INVOLVED PARTIES

To configure a party schema, open via work center BUSINESS CONFIGURATION the fine-tuning activity for the business transaction, such as Sales Quote, Lead, Opportunity, or Ticket, that refers to “Maintain Involved Parties”.

The screenshot shows an example party schema for Sales Quotes: 

 

Active: Party Roles that are not used in your business should be deactivated. Some roles cannot be configured for certain pre-delivered content (fields are grayed out). NOTE,  the Party Role selection can be controlled via Code List Restrictions. This can be helpful in case a Party Role depends on the document type. The party schema itself is not document type dependent.

Party Role:  You can add to a party schema new custom party roles via button Add Row. NOTE,  new Party Roles need to be defined in fine-tuning activity Party Role Definition first. Standard party roles cannot be assigned to the party schema by the key user. The pre-delivered content should fulfill most requirements.

Mandatory: You can define if a party role is mandatory for a document. NOTE: If a mandatory party role is not added to the document, an error message will show up. This error message will not prevent the user to save the transaction! This is the defined system behavior with the benefit, that the user can still completely save his current data entry on the document. The document will be inconsistent though in case a mandatory party is missing which e.g. prevents to create a follow-up sales order from a sales quote. We realized that this system behavior is confusing for some users and plan to configure this behavior for a future release. Today preventing save on errors in party processing can only be achieved via custom coding using SAP Cloud Applications Studio.

Unique: Party role can only exist ones in the document. NOTE: In case parties are determined via an account’s relationship, the system copies only the main relationship into the document. XXX

Forbid Manual Changes: If you configure a party role as “Forbid Manual Change” it is recommended to restrict the party role from the selection using Code List Restrictions. Party roles that are not automatically determined can still be deleted. The flag will also restrict the maintenance of a document addresses in the transaction for the effected party role.

Inbound Integration: This is important in case you replicate documents with SAP ERP/CRM. Assigning here “Exclude” avoids party re-determination in C4C during inbound processing. The party ownership belongs in this case to the OnPrem system. When doing changes in C4C afterwards party re-determination will still be executed.

Internal: This configuration option is available for Involved Parties for Opportunities. and allows to control if the party can only be added to the Sales Team tab of the Opportunity.

 ACTIONS

Maintain Determinations: Here you activate or deactivate pre-delivered determination steps for the selected party role. The determination steps showing up for the selected party roles depends on the configuration of the party role done in fine-tuning activity Party Role Definition. We recommend to deactivate all determination steps that are not needed for your business.

Add Row: Only custom party roles can be added to a party schema.

Delete: You can only remove custom party roles from your party schema. Removal of activate flag can be used as alternative. Only active party roles will appear in the value help for involved parties.

 

CONFIGURE PARTY ROLES

To configure a party roles, open via work center BUSINESS CONFIGURATION the fine-tuning activity Party Role Definition.

The screenshot shows the fine-tuning activity for party role configuration.

 

Description: This fine-tuning activity allows you to rename existing party roles. A change of description is valid for all assigned business objects. (You can also use Language Adaptation Tool to rename a party role).  TIP: Rename standard party role “39- Employee Responsible” and “142- Employee Responsible- Sales” to “Owner”, since this is the terminology used in transactions.
Party Category: The category allows you to control certain business logic. Party Category Competitor Party control e.g. the role selection on Competitor tab in the Opportunity. Party Category Approver Party allows you to use this party role for work distribution in approval processes. Category Other Org Unit Party will filter only on org units for the party selection and allows determination via rules.

Responsibility Role: If you flag a newly created party role as “Responsibility Role”, you can add this party role to the Account Team and/or Territory Team and if required also use the party role for party determination in the party schema.

Determination steps valid for custom responsibilities roles:

NOTE, that a responsibility role cannot be assigned to a Relationship Type. Once this indicator is set “Relationship Type” becomes non-editable and Sales Data and Unique in Account Team becomes editable. Here you can configure the behavior of the party role in the account team, which controls sales data (sales organization, distribution channel, and division, and if personalized sales office and sales group) dependency for the party role and single entry in the account team. Determination in the transaction will then check on the sales data added to the document with the related party role assigned to the corresponding sales data.

Relationship Type: You can assign a Relationship Type to your newly create party role (you can also define new relationship types in fine-tuning activity General Business Partner. This allows you to use party determination based on the account’s relationship maintained in account master record. Main relationship to Account can be copied to the transaction, if the party role is part of the party schema and corresponding determination step is active.

Determination steps valid for custom roles assigned to a relationship type:

 

 

 

Excursion: Configure New Relationships Types

Open fine-tuning activity “General Business Partner” -> “Maintain Relationships”. New Relationship will be available in account master (Relationship tab) and in fine-tuning table “Party Role Definition”. Make sure you do the correct mapping to the new party role and the direction of the relationship is defined appropriately.

Screenshot shows fine-tuning activity to configure business partner relationships, that could be used for party determination:

 

 

 

DETERMINATION STEPS IN INVOLVED PARTIES CONFIGURATION

We recommend to deactivate the determination steps that are not relevant for your use cases. This improves the overall performance of transactional document processing.  The step sequence is of importance. First hit will be defaulted to a transaction. The standard delivery defaults e.g. the Primary Contact of an Account to a transaction. We recommend to deactivate the determination step, in case this default is in most cases not appropriate.

Determination Step Use Rules for <Party Role Name>: This determination step allows you to default parties based on certain rules that can include extension fields. The rule can be defined in work center ADMINISTRATOR view SALES AND CAMPAIGN SETTINGS: Define Rules for Sales Quote Parties or Define Rules for Opportunity Parties.

 

 

 

Determination Step <Party Role Name> of Account Team from Top Level Account: You can copy a party from the account team of the top level account (via account hierarchy) to the involved parties of a transaction, such as an Opportunity or Sales Quote. Determination step is available for custom parties defined as responsibility role in fine-tuning activity Party Role Definition.

 

Determination Step <Party Role Name> of Account Team: This step copies the party role marked as main from the account team to the document. The step is defined before the Territory Team determination. This implies that direct assignments of party roles to an account will be prioritized in general. Note, if no main party indicator exists in the account team, the system picks arbitrarily an entry. Exception applies for party role Sales Employee (code 46), here all parties will be copied over.

 

Determination Step <Party Role Name> of Territory Team: This step copies the party role marked as main from the territory team to the document. Note, if no main party indicator exists in the territory team, the system picks arbitrarily an entry. Same exception applies for party role Sales Employee (code 46), here all party roles are copied over to the document.

 

Determination Step Current User: Defaults the logged in user to the party role.

 

Determination Step Business Partner Relationship for <Party Role Name>:  This step defaults the main relationship maintained in account master record (Relationship tab) to the document. The step is also standard for e.g. Ship-To, Bill-to, or Payer party role.

 

Determination step Responsibility <Party Role Name>:  This rule offers an additional option to determine a party role.  This determination step is also standard for party role Employee Responsible or Sales Unit.

You can determine the party role based on the setup of the employee work distribution. Navigate to work center ADMINISTRATOR -> GENERAL SETTINGS -> Work Distribution: Employee Work Distribution. Select Account Responsibility by Party Roles. In edit mode, you can assign the responsibility party role to define the rule. Rules can be setup based on account’s address and account’s ABC classification. For the sales unit you need to select link on Organizational Work Distribution.

 

GOOD TO KNOW

Party Re-determination – Party re-determination (standard setup) allows you re-determine party roles once they have been determined by the system. E.g. party role determination changes if the Territory is changed in the transaction. In case Account gets changed in a copied document, all dependent party determination based on the account sales team, sales organization, or relationship will be re-determined. Manual changed party roles stay as basic rule and will not be overwritten or removed in this case.

 

Involved Parties Extensibility – A key user can define extension fields for involved parties tab for e.g. sales quotes/sales orders. Extension fields will be part of Quote-Party-MDAV CODCQTPTYB. 

 

 

Display of Determination Method – A key user can analyze the party determination or re-determination for certain documents by adding field Determination Method to Involved Parties table from hidden field list via Adaptation mode. NOTE, party role Account is treated as manual entry even if the transaction is copied or created as follow-up to control party re-determination once account is changed. In case a document is created as follow-up document e.g. a Sales Quote is created as follow-up from an Opportunity, then the party roles existing in both party schema will be copied over. 

 

 

 

Document Address – Involved Parties tab allows to change the address for parties and contacts to a one-time address for certain business documents. This address will not change any master data and will only be applicable for the document processing itself. Enable address fields on Party Details and Contacts tab via personalization or adaptation mode. You can also change the party in the sub tab Party Details.

NOTE, the value help under involved parties to add a business partner does not yet support a filter on the Account’s relationships. This is a known requirement which should be expected in a future release. For e.g. Ship-to or Bill-to it is therefore recommended to add those party roles to the detailed view.

 

 

Special determination step for party role Sales Unit – Determination step Account’s Sales Data can be used in case complete sales data (also Sales Organization, Distribution Channel, Division and if personalized Sales Office and Sales Group) should be defaulted from the account’s master record. This determination step defaults the sales unit in arbitrary fashion if several sales areas are maintained at account level. The sales unit determination follows the below sequence:

  1. If a sales group is assigned in the account’s sales data then this determination step defaults the sales unit with the sales group.
  2. If only a sales office is assigned to the account’s sales data then the sales unit is defaulted with the sales office.
  3. If no sales office or sales group is maintained, the sales unit is equal to sales organization

It is strongly recommended to deactivate this determination step in case sales data should be defaulted based on matching employee’s and account’s sales data. Please compare details mention in blog: https://blogs.sap.com/2016/05/13/combined-sales-area-determination-in-c4c-sales-transactions/

NOTE: Standard system behavior provides an error message in the transaction if the Sales Unit does not belong to the Sales Organization in the organizational model. You can change the error message to a warning message through fine-tuning activity “Message Severity” already for sales quote and sales order (lead, opportunity, activities will follow).

To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

  1. Sandico Mark

    Thanks this is great information. One question, when configuring the system to be able to represent relationships between an employee and a client contact, what is the proper way to do this? I see two options.

    One, using the Buying Center to create those relationships, but then they are not surfaceable or transferrable.

    Two, defining a custom Relationship Type (as above) and then using that new type in the Relationships facet of the contact object.

    Any insight is appreciated, thanks

    (0) 
    1. Guenter Wilmer Post author

      If you want to determine parties based on an employee – contact relationship, you likely need SAP Cloud Applications Studio (PDI) . Today we only support for the Activity Task via determination step “Business partner relationship of Contact” the determination of the Owner/Employee Responsible party role based on the main Employee – Contact relationship of the Buying Center.

      Other use cases can be evaluated and put to the standard determination if demand is high.

       

      (0) 
      1. Sandico Mark

         

        Hi Guenter,

        That is good to know but maybe I misstated my question. It was more around Relationship Types – I see above that you can configure custom relationship types, but is there one out-of-the-box that can denote an employee-contact relationship (as in ‘This employee knows this contact’)?

        In your screen Relationships above, you created a ‘KNOWS’ relationship which is custom, but is there one out-of-the-box we can use for the same meaning? Thanks in advance

        (0) 
  2. Sandeep Kedarisetty

    Hi Guenter,

    If we maintain multiple employees to same party role in “Account team”, will all of them get copied to “Involved Parties” of an Opportunity?

    I see that only main employee per party role is getting copied to “Involved Parties” of an Opportunity.

    Is there a configuration to copy all the employees of the Account Team to “Involved Parties” of an Opportunity?

    Thanks & Regards,

    Sandeep Kedarisetty

     

    (0) 
  3. Siraj Saibudeen

    Dear Guenter,

    Thanks for sharing this very detailed document. I have a small query related to the maintain determination configuration activity. Is it possible to change the sequence of the determination steps. I see that the steps column is in non-editable mode.

    For example in leads – owner determination logic, I want the determination to happen from the Account Team in the first step and if it does not find any owner then as the second step determine based on the custom rules defined. Since the step column in disabled, we are not able to configure the access sequence in which the party should be determined.

    Regards,

    Siraj

     

    (0) 

Leave a Reply