Skip to end of metadata
Go to start of metadata

 

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 page contains information about BO conditions only.

 

 

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

 

 

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 wiki page.

 

Funds Management Integration in CRM Trade Promotion Management

 

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

 

2403487 - TPM - Condition generation fails if accrual profile is not maintained

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

 

Issue with Rebate Trade Spend

 

2380318 - Not possible to re-enter a rebate trade spend after it was deleted

 

 

  • No labels