Quantcast
Channel: SCN : All Content - SAP CRM: Marketing
Viewing all articles
Browse latest Browse all 1578

Rebate Conditions in CRM Trade Promotions

$
0
0

A CRM trade promotion may generate different types of conditions. Depending on the trade spends a trade promotion will generate price determination relevant conditions such as pricing conditions (PR), rebate conditions (BO) and free goods conditions (FG). This article contains information about BO conditions only.

 

Overview

 

A rebate is a special discount granted to an account as a trade promotion incentive. The rebate amount is paid out after the trade promotion has been executed rather than off-invoice. A rebate may be granted for a fixed amount or may be variable depending on the account's sales volume within a specified time period. The rebate is paid out to a certain rebate receiver, even if the trade promotion is created for a account hierarchy, just one account may act as a rebate receiver.

graph rebate agreement.jpg

 

Rebates can be processed either in CRM or ERP.

  • CRM Rebates:
    CRM rebates are used in the CRM standalone scenario. The BO conditions and rebate agreements are generated in CRM. Also the sales order processing and billing happens in CRM.
    CRM rebates are processed via the rebate due list for generating the rebate settlement.crm rebate processing.jpgrebate due list.jpg
  • ERP Rebates:
    The trade promotion generates a rebate agreement with rebate condition records that are transferred to the ERP system automatically when the trade promotion is saved. Sales orders and billing happens in ERP.
    erp rebate processing.jpg

 

 

Rebates can be created for a fixed spend value. A fixed amount is granted for any specific perfomance such as displays used or the product visibility in the store. The rebate is settled with the fixed amount.

graph fixed spend value.jpg

In case there are several rebate agreements generated due to any split criteria, or in case of product exceptions existing in the trade promotion, the fixed amount is distributed among the rebate agreements.

graph fixed divided.jpg

Rebates can also be created for a variable spend value. The amount is depending on the sales volume.

graph variable spend value.jpg


Account Dimension

 

The trade promotion can be created for different account dimensions. The promotion can be created for an account, for an account hierarchy and a target group. For account dimension the BO records are always generated on the account level. For account hierarchy and target group dimension the BO records are either created for the whole account hierarchy or target group, or are created for each account individually. The account hierarchy and the target group are then exploded to all members. There are the following options:

 

  • Trade Promotion created for an account - the rebate conditions are generated on account level.
    graph account dimension 1.jpg
  • Trade Promotion created for an account hierarchy
    • rebate conditions are generated on account hierarchy level. The underlying condition table contains the account hierarchy as condition table field.
      cust cond table hier node.jpg
      graph account dimension 2.jpg
    • rebate conditions are generated on account level. The underlying condition table contains any condition table field on customer level such as sold to, ship to, bill to party. The account hierarchy is exploded in its members.
      cust cond table sold to.jpg
      graph account dimension 3.jpg
  • Trade Promotion created for a target group
    • rebate conditions are generated on target group level. The underlying condition table contains the target group as condition table field.
      cust cond table tg2.jpg
      graph account dimension 4.jpg
    • rebate conditions are generated on account level. The underlying condition table contains any condition table field on customer level such as sold to, ship to, bill to party. The target group is exploded in its members.
      graph account dimension 5.jpg

Rebate Recipient

 

After the trade promotion execution the rebate amount is paid out to the rebate recipient. The rebate recipient is determined based on the account dimension while generating the BO conditions. Depending on the account type there is the following design.

  • Account 
    The planning account is selected as rebate recipient
  • Account hierarchy node
    When only one account is assigned to the hierarchy node, this account is selected and the rebate recipient is determined similar to the account scenario.
    When more than one account is assigned a random selection is made and the rebate recipient is determined using account rules.
  • Target group
    With the target group, the rebate recipient is determined using account rules. If the account has not been maintained, then the owner of the target group is selected.

 

The rebate recipient determination can be influenced using BAdI /BON/RECIP_DETERMINE (of ERP rebates) and CRM_MKTPL_CRMR_IF (for CRM

rebates).

 

Split Criteria

 

Split criteria define if a new rebate agreement is generated for a trade spend.

 

The trade spends are separated from each other because the payment time can differ for each trade spend. Payment is also often linked to a certain requirement that has to be checked, for example, reserving a certain shelf space for a product. The variable rebate agreements are normally settled separately for all accounts at the end of a trade promotion.

 

When having product exceptions in the trade promotion the rebate agreements are also splitted.

tp exception.jpg
tp exception 2.jpg

 

Status Dependencies

 

Rebate conditions are auto-generated when releasing the trade promotion, the status 'in simulation' won't generate BO conditions.

 

Depending on the trade promotion status there is the following design for rebate agreements.

  • trade promotion in 'released' status generates the rebate agreement in status 'open'
    status relesed.jpg
  • if the trade promotion gets 'rejected' of 'finished' the rebate agreement gets the status 'released for settleent'
    status finished.jpg

 

Additionally the following manual steps can be performed for rebate conditions.

  • manually generate conditions
    manually generate conditions.jpg
  • manually release rebate agreement for settlement
    manually release for stl.jpg


Customizing:

 

CRM or BI rates:

 

In the following customizing it needs to be defined wheater CRM or BI rates are used.

 

Customer Relationship Management

Trade Promotion Management

Basic Data

Define Rates' Origin

pr cust rates.jpg

This customizing defines where to maintain the spend values. In case of CRM rates the spend value is to be entered in the trade spend assignment block, wheras for BI rates the spend value is to be entered in the planning layout.

 

Trade Spends

 

In the following customizing is required for defining the trade spends that are to be used in the trade promotion.

 

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Trade Spends

Define Trade Spends for Values

cust ts.jpg

The customizing defines the possible spend type, spend category and spend method. This customizing holds the mapping to the key figure used in the planning layout.

 

Condition Generation Customizing

 

The condition generation is depending on the condition generation type. The condition generation type is mapped to a the trade promotion type and the sales organization, distribution channel and division data. The mapping is done in the following customizing:

 

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Condition Maintenance

Assign Condition Generation Types

 

The BO conditions customizing is linked to the condition generation type and needs to be maintained in the following customizing:

 

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Condition Maintenance

Define Condition Generation

 

The BO rebates specific customizing is available in the 'Pricing Condition Types' dialog.

cust cond bo.jpg


This contains a mapping from the trade spend type, spend category, spend method to the condition type. The condition type from usage BO are rebate conditions.

 

The 'Conditions Table' dialog holds the mapping for the account dimension and product dimension to the condition table that is used for generating the BO condition records.

cust bo cond table.jpg

The 'Rebate Application' dialog is to define wheather to user CRM or ERP rebate processing.

cust crm  erp rebate.jpg

 

 

Different condition generation types may have different rebate application, so this is not a system wide setting but related to the condition generation type.

 

 

CRM Rebate Processing

 

The customizing specific to CRM Rebates are to be maintained in the following customizing path:

 

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Condition Maintenance

CRM Rebate Processing

 

ERP Rebate Processing

 

The customizing specific to ERP Rebates are to be maintained in the following customizing path:

 

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Condition Maintenance

ERP Rebate Processing

 

Condition Tables

 

The condition tables are available in the following customizing path:

 

Customer Relationship Management

Master Data

Conditions and Condition Technique

Condition Technique: Basics

Create Condition Tables

 

The condition table contains the combination of fields used for the conditions generation.

 

Condition Customizing Dependencies

 

When ERP rebates are used system ensures that the conditions customizing between CRM and ERP is in sync.

 

When entering condition generation customizing the entered conditions table is checked agains certain criteria that need to be fulfilled for BO conditions. The check is called from include L0CRMC_MKTPL_CONDF02 form CHECK_CRMC_MKTPL_OTB_KOTABNR.

 

*     Rebate tables (usage BO) should not contain two multi-value fields
*     otherwise, it will lead to performance issues in ERP (especially with
*     retroative rebates, the VBOX table might blow up).  CAMPAIGN_GUID,
*     PROD_SEG_GUID and TG_BP_GUID are mutli-value fields.

 

A warning message will be raised:

 

CRM_MKTPL_TGRP005 'Condition table &1 &2 &3 is not recommended for trade promotion rebates'

 

* For product level 'PRODUCT' the condition table has to contain the
* field 'PRODUCT'.


An error will be raised:

 

CRM_MKTPL_COND_IF046 'Condition table &1 not suitable for product level &2'

 

* For product level 'PRODUCT GROUP' the condition table has to contain
* the field 'PRC_GROUP#' (with # = 1,2,...5).

 

An error will be raised:

 

CRM_MKTPL_COND_IF046 'Condition table &1 not suitable for product level &2'

 

* For product level 'PRODUCT HIERARCHY' the condition table has to
* contain at least one of the fields from product category customizing
*   get customizing information from CRMC_PRCATCNDFRL:
*   condition fields for R/3 product category

 

This reads the following customizing:

 

Customer Relationship Management

Master Data

Products

Product Category

Pricing

Assign Field Catalog Fields to Pricing-Relevant Hierarchy

 

At least one of the pricing fields defined for the product hierarchy needs to be inclduded in the condition table used. In case any custom pricing hierarchy is used in the conditions table this needs to be defined in the above customizing.

 

If this is not fulfilled an error will be raised:

 

CRM_MKTPL_COND_IF046 'Condition table &1 not suitable for product level &2'

 

* For product level 'PRODUCT SEGMENT' the condition table has to contain the
* field 'PRODUCT SEGMENT'.

 

An error will be raised:

 

CRM_MKTPL_COND_IF046 'Condition table &1 not suitable for product level &2'

 

Data Exchange

The data exchange for conditions and rebates must be working in case ERP rebates are used.

 

BAdIs

 

The BAdI CRM_MKTPL_COND_IF provides method CHANGE_WORKING_SET_PR to modify the BO condition records while creation. This may be used to change or add addional attributes.

 

The rebate recipient determination can be influenced using BAdI /BON/RECIP_DETERMINE (of ERP rebates) and CRM_MKTPL_CRMR_IF (for CRM rebates).

 

 

Additional Information

 

Rebate Conditions can never be generated without spend value assigned. The conditions generation is failing with the following error messages in that case:

 

No data for condition generation available for &1, &2, &3. [CRM_MKTPL_COND_IF 109]

No data for condition generation available [CRM_MKTPL_COND_IF 044]

 

 

 

Known Issues

 

There are some known issues that should be solved with the following SAP notes:

 

2145334  Run time error while closing long term Promotions

2108699  Rebate status is not set while closing Trade Promotion

2074961  Error in condition generation when BO and PR trade spends exist and one has conditions at customer level

2035429  In Trade Promotion, when generating conditions, if trade spend value is 0, in certain circumstances no error message is triggered.

2023128  Trade Spend value is not distributed correctly on conditions

1871427  Trade promotion with Target Grp generates redundant rebates

1745805  TPM fixed Trade Spend: Incorrect distribution of spend value

1722429  Generate multiple rebates on target group not possible

 

 

General Information

 

This document should provide an overview about BO conditions in trade promotions. In case you feel anything is missing, or anything is unclear please let me know.

 

A similar document is available for Campaign Determination Conditions in CRM Trade Promotions and for Pricing Conditions in CRM Trade Promotions.


Viewing all articles
Browse latest Browse all 1578

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>