Skip to Content

Rebate Conditions in CRM Trade Promotions

The content of this document was moved to the CRM Marketing SCN Wiki Space:


TPM Prozess Overview - CRM - SCN Wiki


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.

Rebate Processing Application

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.
  • 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. The SD order is created and invoiced in ERP. The rebate agreement determines the SD documents eligible for the rebate agreement.


Spend Value Types

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.

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.

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


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.
  • 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.

    • 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.

  • 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.

    • 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.

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).

The rebate recipient needs to be flagged as 'Eligible for Rebate in TPM' in the sales area master data.

The rebate relevance is checked once the BO conditions are generated. The check is performed in function module /BON/RELEVANCE_REBATE_RECIPIEN.

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.


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'
  • if the trade promotion gets 'rejected' or 'finished' the rebate agreement gets the status 'released for settlement'


    For long term trade promotions there is the following design on setting the status to 'rejected' or 'finished':
    • rejected: the BO condition record gets deleted and the rebate agreement gets 'released for settlement'
    • finished:
      • for future trade promotions (when the start date is not yet reached, so the rebate agreement was never active) the BO condition record gets deleted and the rebate agreement gets 'released for settlement'
      • for active trade promotions (when the start date is reached but the end date is not yet reached, so active rebates exist) the rebate cannot be deleted. The following error is raised:

        'Rebate conditions with future date exists; Status change not possible' [CRM_MKTPL_COND_IF 108]


        The rebate end date needs to be changed first to be able to finish the trade promotion. Active rebate agreements must not exist as those may apply for sales orders. Once the end date is changed, those trade promotions are considered as past dated trade promotions and the status can be set to 'finished'
      • for past dated trade promotions (end date already reached) the rebate agreement gets 'released for settlement'.

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

  • manually 'generate conditions'
  • manually release rebate agreement for settlement


    If the rebate agreement is 'released for settlement', no more changes can be made on the affected trade spend.


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

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

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.


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.

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

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

Rebate Condition Type


The settings for the condition type used need to be set in the following customizing:

SAP Customizing Implementation Guide

Customer Relationship Management

Rebate Processing

Set Up Rebate Determination

Create Condition Types

This customizing holds the calculation type and defines if the rebate is enabled for accruals.

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:

Issues related to rebate conditions generation:

2195430  Not able to generate conditions: infinite loop

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.

1871427  Trade promotion with Target Grp generates redundant rebates

Issues related to wrong spend value:

2023128  Trade Spend value is not distributed correctly on conditions

1745805  TPM fixed Trade Spend: Incorrect distribution of spend value

When using BI rates the decimal settings in BPS planning need to be considered as well - the set up is documented in the following blog:

Decimal issues in BPS Planning for CRM Marketing Objects

Issues related to planning account:

1799381  Planning account hierarchy not checked for rebate relevant

1722429  Generate multiple rebates on target group not possible

Issues related to date shift:

1999452  Dates in campaign determination record not adjusted when campaign dates are changed

Issues related to TP status change:

2145334  Run time error while closing long term Promotions

2108699  Rebate status is not set while closing Trade Promotion

Issues related to funds integration process:

When having funds management integrated in the TPM process the accrual customizing needs to be set up properly for the trade promotion type and expense type. Since the rebate aggreement is supposed to generate the accruals the accrual profile needs to be set up properly in the following customizing:

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Funds Integration

Define Settings for Funds Integration

==> Expense Type to Accrual Profile

More detailed information is available in the following SCN document:

Funds Management Integration in CRM Trade Promotion Management

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

2176038  TFM integration is not checked on TPM Rebate creation

2158246  Condition Generation is failing while using some Accrual Profiles in Funds Integration scenario

2101756  Prohibit posting of manual accruals in an ERP Rebate Agreement

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.

Tags: