You want set up the print actions for any marketing plan object such as marketing plan, campaign or trade promotion. This provides the possibility to print out or preview the details of the marketing plan object in pdf format.

How to set up the print action is described in the SAP online help:

Print Preview and Form Management - Loyalty Management - SAP Library

Additional documentation how to set up the customizing is available in the following SAP notes:

647087 - Print Preview functionality for Marketing Planner PCUI

1321751 - Print Preview for Marketing Planner CRM 6.0 and up

This document should complete the available documentation.

The printing function uses actions of 'smart form' processing type. Therefore a smart form used for printing needs to be created in a first step. This is to be done using transaction SMARTFORMS.

SAP provides the standard smartform for marketing plan objects:

CRM_MKTPL_DEFAULT_CONSUMER     Mktpl Trade Act Def Form

CRM_MKTPL_DEFAULT_DEAL                Mktpl Trade Act Def Form

CRM_MKTPL_DEFAULT_MDFINI             MDF Initiatives Act Def Form

CRM_MKTPL_DEFAULT_MDFPROG       MDF PGM/SPG  Act Def Form

CRM_MKTPL_DEFAULT_PLAN                Mktpl Trade Act Def Form

CRM_MKTPL_DEFAULT_TRADE             Mktpl Trade Act Def Form

CRM_MKTPL_INVITATION                       Form for Marketing Planning

In a next step the print action needs to be defined and need to be assigned to an action profile. This is done in the following customizing:

SAP provides the following common action profiles for each marketing plan object type:

CRM_MKTPL_CP Object Class CP Common Profile

CRM_MKTPL_IN  Object Class IN Common Profile

CRM_MKTPL_TP Object Class TP Common Profile

The common action profile contains the generic print actions for each marketing object type. The print action can however also be defined under the action profile used for a certain marketing plan object type.

The print action needs to be defined as processing type 'smart form'. Further the smart form needs to be assiged and the processing class. SAP provides the standard method CL_CRM_MKTPL_PROCESS_SMARTFORM=>PROCESS_SMART_FORM for that purpose.

In a last step the action profile needs to be assigned to the campaign type. This can be done directly in customizing:

The action profile can be assigned to the campaign type or the campaign element type directly:

Alternatively the action profile can be assigned to the marketing plan object type using BAdI CRM_MKTPL_OL_OBJ method SET_ATTRIBUTES.

Once those steps are performed the print action together with the preview should work. To test if there is any issue with the action determination the same action can be scheduled manually in the 'scheduled actions' assignment block:

This provides further analyzing tools.

In this document I want to give an overview about how currencies are processed in CRM trade promotion management. This contains some useful information, some process use cases and some known issues.

How is the TP currency determined?

When creating a new trade promotion the currency field is not filled per default.

The currency can either be entered manually or is defaulted by the sales organization assigned to the trade promotion.

The currency is a TP header attribute. The defaulting happens in the following method:

CL_CRM_MKTPL_HEADER_ITEM=>DEFAULT_CURRENCY

The defaulting based on the sales organization happens only if no currency is yet assigned. If the currency is manually inserted before the defaulting no longer takes place. The same rule is valid when changing the sales org. In case this design needs to be changed - so the manual assignment of the currency should get overruled by the default currency from the sales org this needs to be done using BAdI CRM_MKTPL_OL_OBJ interface method SET_ATTRIBUTES_AFTER.

Which currencies can be used in a trade promotions?

Basically there are no restrictions. Each currency defined in table TCURC can be used. The validation of the entered currency happens in the following method:

CL_CRM_MKTPL_HEADER_ITEM=>CHECK_CURRENCY

The currency is not validated against the sales org, nor the planning account in the trade promotion. The only thing that is considered during the check is that if the trade promotion was created from a deal that the TP and the deal currency must match.

In case the check should be done more restrictive and the currency should be checked against some further attributes the same needs to be done using BAdI CRM_MKTPL_OL_OBJ interface method CHECK_ATTRIBUTES.

Can the TP currency changed?

The TP currency can be changed as long no planning profile group is assigned to the trade promotion.

Once a planning profile group is available in the trade promotion the currency can no longer be changed. As long as the TP status allowes removing the planning profile group the currency can be changed. This is usually for trade promotions that are not yet released.

The currency change design is controlled by the following method:

CL_CRM_MKTPL_HEADER_ITEM=>IS_CURRENCY_CHANGEABLE

How are decimals considered for currencies?

Most currencies use 2 decimals per standard. All the amount fields are displayed using the decimals currency settings.

There are however currencies existing with other than 2 decimal places. The so called exceptional currencies are defined in table TCURX. When looking at the JPY (Japanese Yen) this is defined as having 0 decimal places.

The displayed amounts in the trade promotion are using these settings.

What to be considered with funds integration?

When having funds integrated into trade promotion management, the trade promotion must have a funds plan assigned using the same currency as the trade promotion. Having a trade promotion planned on USD with a EUR based funds plan won't work. The TP and the funds plan currency must match.

The check for the TP and funds plan currency is performed in the following method:

CL_CRM_MKTPL_FPLAN_ITEM=>CHECK_CURRENCY

What to be considered with claims integration?

When the trade promotion is used in claims processing we need to distinguish between the planning and execution currency. The TP currency is the planning currency, whereas the claims currency is the execution currency. The planning currency is used in the trade promotion, in the pricing conditions and in the rebate agreement. The execution currency is used in the claim, the claim settlement and used in the claim validation process. The planning and execution currency do not necessarily be the same.

Imagine having a trade promotion planned with USD.

The rebate agreement as well as the fund usages are created with USD currency.

The claim however may use EUR currency. Once a trade promtotion is added to the claim a currency onversion is taking place.

When adding the trade promotion to the claim the amounts are retrieved from the TP fund usages, while retrieving the amounts the currency conversion takes place in the following method:

CL_CRM_FM_FPO_CURR_CONVERT=>CONVERT_TO_FOREIGN_CURRENCY

For any further processing such as settlement creation the claims currency is used.

Are there any typical issues related to currencies in trade promotion management?

For currencies using 2 decimals there are no known issues, however for exceptional currencies there are some issues, most related to the display of the amounts. Known issues are solved with the following SAP notes:

2073534  Wrong decimal point for amount on Claim Processing Documents

2033052  Totals Assignment Block is incompatible with Decimal Notation Y (1 234 567,89)

1963366  Currency decimal settings not considered in Spend Value Overview AB

1954292  Default Trade Spends currency for all condition calculation types, except percentages

1817618  TPM versions don't show correct spend values

1813856  Spend values and OI Cap are not correct in change history

1775791  Settled amounts wrongly displayed for non decimal currencies

1730452  Wrong spend value due to currency conversion

1712649  Spend Value and OI Cap with Currencies like TWD

1650994  Default currency code of Purch Item from parent object

1650481  Issue with exceptional currencies in Product Causals

1632124  Purchasing AB values not correct for ex currencies (TCURX)

1607017  Handling exceptional currencies in Trade Spends Values

This collection will be updated whenever any new correction is released.

Purpose

The purpose of this document is to show steps needed in case coupons/vouchers have been deactivated

Login

• Login in your webui system and choose Marketing pro business role

• Click on Marketing menu from the work list and select vouchers

click on search voucher

Select the voucher that want to activate from the campaign ID

You might all select the all campaign , by clicking on the left corner.

Click on Mass change  to select the attribute

You will get a pop up asking to select the attribute, you have 2 options to choose (active or invalid)

Choose Active option from the drop down menu to reactivate the voucher and apply all changes.

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). Independently from the price determination relevant conditions a trade promotion creates campaign determination conditions (CD conditions). This article contains information about CD conditions only.

Overview

CD conditions are generated for short term trade promotions only. These trade promotions, created for a period of several weeks, increase sales volume and include both price-determination-relevant conditions and conditions for campaign determination. Long term trade promotions don't create CD records. These trade promotions are created for a period of several months to one year, and do not increase sales volume and include only price-determination-relevant conditions.

As we can see in the example of a short term trade promotion the CD records are created for the planning account, for each product, and for the trade promotion validity period:

CD condition records control campaign determination when the trade promotion is executed. CD records are generated independently from the trade spends available in the trade promotion. CD records cannot be generated manually but are generated only through a life cycle change of a trade promotion, namely, released, rejected, cancelled or finished.

There are the following status dependencies:

• Status: CREATED
  In status created there are no CD records created.
  
• Status: RELEASED
  When releasing the trade promotion the CD records are generated automatically.
  
• Status: LOCK / CANCEL / CLOSE
  On locking, cancelling or closing the trade promotion the CD records are deleted automatically. The trade promotion cannot be determined and used in any sales order with one of these status active.
  
• Status: UNLOCK / UNCANCEL / UNCLOSE
  When undoing one of the above status, system behaves like the trade promotion gets newly released and the CD records are re-generated.
  
• Status: SIMULATE / UNSIMULATE
  When setting the simulation status the CD records will be created as well, however the trade promotion won't be used in any sales order yet. When releasing a trade promotion from simulation status the CD records created from the simulation will be deleted and newly created.

The CD record changes triggered by status is called in CL_CRM_MKTPL_APPL_BASE_SERVICE=>CHECK_STATUS_CHANGE_COND.

Within an already released promotion subsequent changes to the PRODUCT or DATES will automatically be reflected in the CD records. This is because Product and Date fields are part of the CD condition key fields. The following graphics will show what happens on a so called date shift:

When the trade promotion execution date is now changed, the existing CD records updated according to the new execution dates:

The CD date shift logic is implemented in CL_CRM_MKTGS_COND_MAINT=>SHIFT_CONDITION_DATES.

There is a similar design on changing the product dimension of the trade promotion. When deleting or excluding a product from a trade promotion, the CD records generated for that one product are deleted, when changing the product effective dates the CD records are re-generated. When adding a new product to the trade promotion or removing the excluded flag for an existing product CD records are generated for the affected product. The same design is valid for all product dimensions, including products and product categories. For product level this logic is implemented in CL_CRM_MKTPL_TPM_PROD_ITEM=>SET_ATTRIBUTES.

Customizing

CD records will be generated based on the following customizing:

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Condition Maintenance

Define Condition Generation

CD records are created for short term promotions only. The condition generation type therefore needs to be defined as short term promotion:

The CD specific customizing is available in the 'Campaign Determination Condition Type' dialog:

This path contains the type of the CD records to be generated and the conflict resolution. The conflict resolution defines what happens in case of similar existing CD records.

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

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 coniditons generation.

The CD conditions customizing is linked to 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

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 CD records are always generated on the account level. For account hierarchy and target group dimension the CD 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.

Depending on the account dimension and the conditions table used there is the following design:

• CD records created on BPH level
  
  In that case a condition table is used that generates the conditions on target group level
  
• CD records created on TG level
  
  In that case a condition table is used that generates the conditions on target group level
  
• CD records are created for each target group member, the TG is exploded to retrieve the sold to parties
  
  In that case a condition table is used that generates the conditions on account level
  

Conflict Resolution

In case a newly created trade promotion overlaps with existing trade promotion, there is the following design to handle overlapping CD records. The conflict resolution provides the following options:

There is one existing trade promotion valid for a certain period.

In case another trade promotion created for an overlapping time period is released there are the following conflict resolution options:

• 01: New condition records always have priority
  The system creates new condition records. The new condition records overwrite existing condition records if they overlap.
  
• 02: No new records are created if there is a conflict
  The system does not create new condition records if the new condition records overlap with existing records.
  
• 03: New condition records are created if they do not overlap
  The system creates new condition records so far as they do not overlap with existing condition records.
  
  The CD records for the newly created campaign are created for non overlaping periods only.

The conflict resolution logic is implemented in CL_CRM_MKTGS_COND_MAINT=>RESOLVE_OVERLAPS and CL_CRM_MKTGS_COND_MAINT=>RESOLVE_VALID_PERIODS. There is some different design for short term trade promotions and long term trade promotions. Long term trade promotions always use conflict resolution 01 whereas short term trade promotions use the conflict resolution from the condition generation type customizing.

The CD conflict resolution is different to the trade promotion overlap check. The CD conflict resolution comes into play once the TP overlap check allows the generation of a trade promotion that has similar CD records than an earlier generated trade promotion.

Additonal Useful Information

Using report CRM_MKTPL_COND_IF_R001 trade promotions can be released from the backend in order to generate CD conditions. This will however work for unreleased trade promotions only. As mentioned there is no way to automatically re-generated CD conditions.

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

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 PR conditions only.

Overview

Pricing Conditions are used in the off-invoice scenario to give a certain discount to the customer when buying the promoted goods. That can be a fixed amount per case (10€ off per sales unit) or a percentage value (2,5% off). The discount is applied on the invoice, the discount is therefore applied in advance. The discount is driven by the trade spend type used. Off-Invoice Trade Spends create condition records from type PR.

The sample promotion contains different trade spends and shows the PR conditions created.

For each trade offinvoice trade spend a seperate PR condition record will be generated.

In case there are exceptions maintained for the products the PR conditions are generated accordingly.

It is therefore possible that several PR condition records are generated for a single product in the trade promotion. This is depending on the product exceptions.

The spend value is taken from the trade spends. There are two different scenarios:

• CRM rates: In case of CRM rates the spend value is stored in CRM on trade spend level. The values can be edited in CRM using the trade spend assignment block.
  
• BI rates: In case of BI rates the spend value is stored in BW only. The values need to be entered in the planning layout of the trade promotion. The trade spend assignment block won't show the values at all.
  
  

PR conditions are either generated when releasing, the trade promotion or can be created manually using the 'generate conditions' button. Using the 'generate conditions' button the PR conditions can be re-generated again after any changes were done to the trade spends.

Using the 'generate conditions' button the conditions are generated or re-generated for the selected trade spend only.

There is the following design based on the status of the trade promotion:

• Status CREATED:
  In status created PR conditions can be generated manually only using the 'generate conditions' button.
  
• Status RELEASED:
  On releasing a trade promotion the PR conditions are automatically generated.
  
• Status LOCK, CANCEL
  Locking or cancelling a trade promotion deletes the PR conditions. The condition records are not deleted physically but get the deletion flag assigned, and cannot be used.
  
• Status UNLOCK, UNCANCEL
  Unlocking or undoing the cancel status will activate the PR conditions again that are flagged for deletion.
  
• Status FINISHED
  Finishing a trade promotion won't affect the PR conditions, the conditions are still valid.

PR condition records are updated automatically when changing the trade promotion execution dates, or when changing the product or trade spend validity.

When the trade promotion execution period gets changed the PR conditions get changed automatically.

When changing the spend value or maintaining any product exceptions for a released trade promotion the the PR conditions need to be re-generated manually.

PR conditions are deleted by one of the above mentioned status. Additionally the conditions are deleted when deleting either the product or the trade spend. This is however prohibited for active released trade promotions, so is allowed either for not yet released or for future dated trade promotions only. PR condition records are not deleted physically but get the deletion flag assigned.

The PR conditions can be deleted manually as well. This happens when using the 'delete' button from the Discounts assignment block. This function can be used to delete the individual PR records manually:

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.

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 PR 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 PR 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 PR are off-invoice 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 PR records.

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 coniditons generation.

Additional Information

Depending on the account dimension of the trade promotion the PR conditions can be created on sold to level, or on account hierarchy or target group level. The same is defined by the condition table used.

Some PR condition records may not include the account field at all, these condition records require the campaign ID instead. The conditions are then identified and applied when the trade promotion is determined using the CD records. This is the case for short term trade promotions.

In this case there is no account information included in the PR record, but due to the condition type used the TP guid is available on the PR condition record.

Using report CRM_MKTPL_COND_IF_R002 PR conditions for trade promotions can be created from the backend.

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

Tiered Growth Rebates are used to provide performanced based discounts or rabates to the customer. Based on different tiers a higher rebate is provided for better performance.

Overview

TGR rebates provide a certain rebate based on different performance indicators such as the sales volume, number of shelves in a store or the growth compared to a reference time period.

TGR rebates are linked to a certain product or product category and a TGR trade spend type. The tiers are defined on trade spend level.

Each TGR rebate has a set of tiers defined. Each tier associates a range of performance values with a specific spend value. The evaluation happens based on a specific key figure that is used to determine the correct tier using a specific calculation method. Each TGR type has one evaluation criterion and one calculation method. The calculation method is used together with the base and comparison dimension to retrieve the correct tier.

The figures considered for determining the correct tier are entered in the corresponding planning layout:

The amount from the tiers is used as a spend value for the provided rebate.

The determination of the tier and the calculation of the TGR rebate needs to be triggered manually by using the 'Transfer Trade Spends' button. This will call the synchronization with BW and renders the planning layout to retrieve the correct key figures for the calculation.

Technically the calculation is triggered after the trade spends are transfered in CL_CRM_MKTGS_IB_COST_TRANS_TS=>EXECUTE. System check if there are TGR items existing and calls CL_CRM_MKTGS_TGR_ITEM=>DETERMINE_REBATES accordingly.

TGR Types

There are the following default TGR Types available in the system. Each type is defined by a specific combination of base dimension, comparison dimension, tier type, spend value type, and calculation method.

• Volume based TGR Types
  For the following TGR Types have the sales volume as base and comparison dimension. All those TGR types provide variable rebates. The evaluation happens based on the number of sold cases. For the following examples there are the following tiers defined. Each example is based on a sales volume of 700 cases.
  
  • Classic tiers
    For classic tiers the spend value is calculated by summing up the spend value multiplied by the volume in each tier.
    
    The calculation happens on the following pattern.
    
  • All tiers
    For all tiers the spend value is calculated by spend value is multiplied by the total volume for the period.
    
    The calculation happens on the following pattern.
    
  • Growth over each tier
    The growth over each tier TGR type is variable rebate based on the number of cases sold.
    
    The calculation happens on the following pattern.
    
• Shelf based TGR Types
  • Shelves
    This provides a fixed amount based on the number of shelves in the store.
    
• Off-invoice TGR Types
  • Off-invoice
    An off-invoice discount (a scale type discount) based on total sales during the year. The discount is provided for each invoice that is received. The number of cases of each invoice is summed up to provide the discount.
    
• Growth related TGR Types
  The following TGR types determine the tiers based this years sales volume (measured in either sales volume, or sales revenue).
  
  The rebates granted may be variable amounts or fixed amounts depending on the calculation method.
  • Variable growth vs last year, total sales
  • Variable growth vs last year, volume
  • Variable growth vs last year, sales
  • Fixed growth vs last year, total sales
  • Incremental growth vs last year, total sales

The evaluation criteria and the calculation happens from the following classes:

CL_CRM_MKTGS_TGR_EVCRIT_DATE   Determine Eval. Crit. For Date range
CL_CRM_MKTGS_TGR_EVCRIT_DET    Parent class to specific evaluation criteria classes
CL_CRM_MKTGS_TGR_EVCRIT_DOLLAR Determine Eval Crit Type
CL_CRM_MKTGS_TGR_EVCRIT_PMON   Percentage in Volume eval criteria
CL_CRM_MKTGS_TGR_EVCRIT_PVOL   Percentage in Volume eval criteria
CL_CRM_MKTGS_TGR_EVCRIT_SHELF  Det. Eval. Crit. type
CL_CRM_MKTGS_TGR_EVCRIT_VOLUME Return the right type of Evaluation Crit.

CL_CRM_MKTGS_TGR_CALC_ALLTIERS All Tiers Calculation Method
CL_CRM_MKTGS_TGR_CALC_CLASSIC  Classic Tier Calculation Method
CL_CRM_MKTGS_TGR_CALC_FIXED    Fixed Amount Calculation Method
CL_CRM_MKTGS_TGR_CALC_GINC     Growth Incremental Calculation Method
CL_CRM_MKTGS_TGR_CALC_GOET     Growth Over Each Tier Calculation Method
CL_CRM_MKTGS_TGR_CALC_GROWTH   Growth Calculation Method
CL_CRM_MKTGS_TGR_CALC_GVOLUME  Growth Volume Calculation Method
CL_CRM_MKTGS_TGR_CALC_METHOD   Generic Calculation Method

Any different TGR Types need to be defined in Customizing, for any different evaluation criteria or calculation method there is the BAdI CRM_MKTGS_TGR available.

Condition Generation

TGR rebates can be used for pricing determiantion conditions (PR conditions) and for rebate conditions (BO conditions).

• BO conditions
  Rebate conditions have the usage BO. BO conditions create rebate agreements.
  
  The rebate is payed out after the trade promotion after the trade promotion is executed. Any sales volumes are collected on the rebate agreement. The rebate may be processed either in the CRM system or in the ERP system.
• PR conditions
  Pricing conditions have the usage PR and used in the off invoice scenario. General information about PR conditions is available in the following document: Pricing Conditions in CRM Trade Promotions
  
  PR conditions hold the scale information in the generated condition record. The details can be checked in the condition record detail view. The scales can be changed manually.
  
  The scales are available for PR conditions only.

Planning Integration

The keyfigures used for determining the tiers are calculated and stored in BW. TGR rebates therefore require BPS planning integration. The values are entered in the planning layout assigned to the TGR Type.

The planning layout needs to be defined in BW in BPS0 and UPX_MNTN and need to contain the mapped key figures.

The calculation of the tiers depend on the entered key figures.

Customizing

Trade Spends

TGR rebates require the following customizing. Since TGR rebates are driven by trade spends the trade spends need to be customized accordingly in the following customizing path:

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Trade Spends

Define Trade Spends for Values

The trade spend type and category needs to be defined.

TGR Types

In the following customizing path the TGR types need to be defined:

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Trade Spends

Tiered Growth Rebates

Define Tiered Growth Rebate Types

This customizing path contains the different dialogs for defining and assigning the base and comparison dimensions, the tier type details, the spend value settings and the used calculation methods. The tier type details defines if the values in the tiers are of monetary, volume based or percentage nature. The spend value defines if the rebate is of monetary or percentage nature. The 'Tier Growth Rebate View' dialog contains the assignment of the above details to the TGR Type.

The following customizing defines the mapping from the trade spend type, spend category and spend method to the TGR type:

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Trade Spends

Tiered Growth Rebates

Define Trade Spend Combinations for Tiered Growth Rebates

Planning Integration

Since TGR rebates require BW planning synchronization the planning integration needs to be set up properly. For TGR rebates there is the following integration customizing required:

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Trade Spends

Tiered Growth Rebates

Define BI Content

In the 'Planning mapping table' dialog the planning profile used for synchronizing the TGR related key figures needs to be maintained:

The 'TGR KFP mapping table' dialog holds the InfoObjects for the required key figures for each TGR type:

This key figures need to be included in the planning layout used by the planning profile. The planning profile defined in the 'Planning mapping table' dialog needs to be assigned to the planning profile group used in the trade promotion. This is to be done in the following customizing:

Customer Relationship Management

Trade Promotion Management

Key Figure Planning

Define Planning Profile Groups

Condition Maintenance

The conditions require the following customizing:

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Condition Maintenance

Define Condition Generation

The TGR spend type, spend category, spend method are mapped to the corresponding PR or BO condition types.

Product Exceptions

In certain scenarios there are exceptions available for the product dimension. The tiers defined on product level overrule the tiers defined on trade spend level. In that scenario the tiers defined in the product exceptions have different spend values as the tiers on trade spend level. The rebate is calculated using the spend value defined in the prouct exception.

In case there are several product used in a trade promotion, the tiers are defined on trade spend level are first considered for calculating the values for the rebate.

For certain products the tiers may differ from the tiers defined on trade spend level. This is to be maintained in the product exceptions view.

The rebate is calculated using the spend value defined in the prouct exception. For products without product exception the spend value defined on trade spend level is used.

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

This document will explain the design of the PMDC report in trade promotions.

Product Assignment

The PMDC report checks if products and product categories used in a trade promotion are consistent with the product master data. Usually a product is assigned to a product category. Product categories may hold several products.

When products are used in trade promotions there are the following different scenarios.

• Product is single assigned
  The product is entered in the product assignment block directly. The product holds the product category information.
  
• Product is mass assigned
  The product category is entered in the product assignment block. The product category is exploded to insert the products assigned to the product category.
  

The product assignment for the trade promotion is hold in table CRMD_MKTPL_PROD. For mass assigned products the information about the selected product category is hold in the field SEL_CATEGORY_G.

The product master data gets changed the following way:

Prodct HT-1000 is moved to a different product category. Product HT-1000 is no therefore longer assigned to product category LAPTOPS but assigned to product category NOTEBOOKS. Furthermore the product HT-1020 gets newly assigned to product category LAPTOPS.

The PMDC report run for the sample trade promotions should dedect the master data changes and perform changes to the trade promotions as per the following design. There is different design for single and mass assigned products:

• Product is single assigned
  The trade promotion is created for the product itself. When running the PMDC report the product category for the product gets updated since this got changed in the product master data.
  
  
• Product is mass assigned
  The trade promotion is created for the products for a certain product category. The planning account is therefore supposed to retrieve discounts for products of the product category.
  
  When running the PMDC report the following happens:
  • all products that were newly added to the selected product category are included in the trade promotion
  • all products that are no longer included in the selected product category are deleted from the trade promotion
    

There is the following design for active trade promotions - a trade promotion is considered as active if it is in 'released' status and has the start date is already reached:

Updating product categories in the single assignment scenario and adding new products to a trade promotion in the mass assignment scenario don't cause any issues. However deleting any product from an active trade promotion is not working. The following error is raised in the PMDC log:

Unable to delete product HT-1000 because promotion already started

Therefore whenever the PMDC is supposed to delete a product from an active trade promotion the whole PMDC process is failing. The trade promotion needs to be corrected manually in that case.

Known Issues:

Known issues related to product design in the PMDC report are solved with the following notes:

2056057 - PMDC: No message is sent to the log when a product is updated.

2021814 - PMDC does not update product when product category changes under the parent mass assigned category

1871966 - PMDC program deletes products instead of update them

This document will be continued. In case there is any further information required please let me know.

“For the KPIs Market Share, Net Promoter Score, Web Visits and Web Downloads of the Marketing Executive Dashboard in hybris Marketing the underlying business data must be uploaded from external sources. This can be achieved by using CSV-files in a certain format. In this document one can find files for examples of that business data. These files can used to set up a demo or test-environment, but cannot be used for productive use . To do so, please follow the description in the Installation and/or Operations-Guide which can be found on the help portal http://help.sap.com/CEI”.

Download Link to Demo Data

Display pallets are special kind of products used in trade promotions. A display pallet consists of multiple quantities of one or more products. In the trade promotions these display pallets can be used independently so the customers buy the whole display pallet and therefore purchase all the products within the pallet. Alternately the products within the display pallet can be sold and promoted separately. In these scenarios each of the products contained in the display pallet might have a different discount structure than the discount pallet itself.

The example shows 2 products.

To provide additional promotion support both products are used in a display pallet.

When used in a trade promotion the display pallet product is entered in the products assignment block. System explodes the display pallet product into the product categories of the assigned products .

The promotion then contains the entered display pallet product together with the products categories included in the display pallet product. In the example there are the following 3 products included in the trade promtion: the display pallet product SWEETS, together with the products categories Cookies and Chocolate Bar.

The trade promotion is then executed the display pallet product, but can also be executed on product level. Discounts may be offered on display pallet level or on product level.

In that example the producer offers the following discounts to the retailer, depending on how the products are purchased. The orders may be placed for the display pallet (50 cases Cookies and 30 cases Chocolate Bars), the retailer then gets a discount of 150€. Alternatively the orders may be placed for the products, the retailer then gets a dicount of 1€ per case for Cookies and 2,5€ per case for Chocolate Bars.

Product Master Data

To be used in the display pallet scenario the products need to be defined as structured product that has items with an item category group defined as display-pallet relevant. This identifies the product as a display pallet. The components have the information about the assigned products together with the quantity.

The display pallet product is modelled as a “structured product”. Structured products consist of a header product and any number of component products. They are used to represent a group of products as a distinct unit in certain logistics processes. Structured products can be created in the CRM Server in product maintenance in the same manner as other products. Components are linked to the product header via relationships. The relationship defines the type of the structured product and the attributes of this relationship.

CRM structured products are uploaded/downloaded to ERP as BOM. A BOM header attribute carry the relationship type information.

Product Assignment

A trade promotion that is enabled for the display pallet scenario allows only display pallet products. The search help only returns products with display pallet item category group.

Products can be entered in the products assignment block only. The product category assignment block is in display mode only. The product categories are automatically populated from the display pallet structured product. They cannot be changed manually as they are derived from the product assignment so all creations, changes and deletions from the products assignment result in an update of the category assignment to keep it in sync.

The product explosion happens in CL_CRM_MKTPL_TPM_PCAT_ASSIGN=>SET_PALLET.

The products are a snapshot of the product master data at creation time, and changes to the master data are not reflected in the trade promotion.

Planning

In the planning layout the display pallet product is exploded as well. Since planning is enabled on display pallet product level and on individual product level the following product lines are created:

The editable display pallet product line is for planning on display pallet level. The read only product lines are created for displaying the product lines in the display pallet scenario. The editable product lines are created for planning on product level. Technically the BOM explostion for the planning layout is happening in BW in BAdI UPX_LAYOUT_RENDER standard implementation UPX_DISPLAY_PALLET in method ADOPT_PLAN_DATA.

The planning layout shows the display pallet product, together with the assigned product categories, and the indiviual product categories.

In this example the product column shows the guid of the display pallet product, the product categories of the assigned products appear with the display pallet product guid in the source product column, whears the individual product categories have the product and the source product column empty. This is as per the definition in BPS0 and UPX_MNTN in BW.

Condition Generation and Funds Integration

Condition generation is similar to the standard condition generation, there is no difference in the display pallet scenario. Planning can be done at the product or product category level, so relevant conditions will be generated for both. The only prerequisite in the Condition Generation framework is, that the display pallet promotions must be configured to use ERP product categories (not CRM categories).

When the trade promotions has funds integrated, both product dimensions, products and product categories are used for funds determination. This includes the BOM product and the exploded product categories. Depending on the available funds in the assigned funds plan the funds are returned for the BOM product or for the included product categories.

Customizing

In a first step the product item category group relevant for the display pallet scenario need to be defined.

Customer Relationship Management

Trade Promotion Management

Basic Data

Products

Select Item Category Groups for Display Pallets

This item category type then needs to be assigned to the relevant products.

To use the display pallet scenario the trade promotion must be defined as display pallet promotion. This is to be done in the following customizing:

Customer Relationship Management

Marketing

Marketing Planning and Campaign Management

Basic Data

Define Types/Objectives/Tactics

The display pallet attribute is linked to the trade promotion type.

In the next steps a minumum level of the product hierarchy to explode to for long and short term trade promotions needs to be defined using the following customizing path:

Customer Relationship Management

Trade Promotion Management

Basic Data

Products

Assign Product Hierarchies

Known Issues

There are some known issues related to the display pallet scenario. The issues should be solved with the following SAP notes:

1910637   Display pallet error for a promotion type that is not a display pallet related

1884200  Display Pallet promotions with multiple categories fail

1835646  Add attribute for Display Pallet scenario in custom xml

1558331  Display Pallet components cannot be corrected

1493107  Remove empty categories from Display Pallet Planning

1487358  List price conversion error with Display Pallet products

1395682  TPM, Display Pallet, Planning, components are displayed

1303373  Display Pallet - Product implosion issues

1302345  Display Pallet - Wrong bill of material explosion

1302240  Display Pallet - Defaulting of Product Planning Basis

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

For several marketing plan objects the status management is one of the key indicators for defining the business process. Depending on the object type, campaign or trade promotion, the current status either triggers any business transaction or determines which business transactions can be executed for that marketing project. In trade promotion management for example the status 'released' triggers the conditions generation, whereas in campaign management a campaign that is not released must not be executed. Depending on the object type the status management does have different meaning and is used differently.

Further there is a difference between user and system status. A user status defines and triggers the process, whereas the execution is controlled by system status only. That means once a user status is set, a business transaction is triggered that sets the corresponding system status. Depending on the customizing the online user can set user status only, system status only or can set both, user and system status.

Status Managent Customizing

The customizing is the same for all marketing plan object types. In case user status are used the same need to be defined in the user status profile. This is available in the following customizing path:

Customer Relationship Management

Marketing

Marketing Planning and Campaign Management

General Settings

Define Status Profile for User Status

The user status profile contains all available user status for a marketing project. This includes the following fields:

• status order number
• status ID and short text
• lowest and highes status number: a status has a certain order number, the lowest and highest status number define which status can be set from a certain user status
• authorization key: defines which authorization is required to set a certain user status
• business transaction: business transaction that is triggered by setting the user status

Table TJ30 contains the mapping of a certain user status to the technical ID such as E0001.

The status profile can be assigned to the marketing plan object type or can be assigned manually. The assignment happens with the following customizing:

Customer Relationship Management

Marketing

Marketing Planning and Campaign Management

Basic Data

Define Types/Objectives/Tactics

This contains the assignment of the user status profile. Further the marketing plan object type defines wheather system status can be set directly or if the control is done via user status only.

User Status Management

The example shows a trade promotion with a user status profile assigned. On creating the trade promotion the initial user status is set.

This comes from the user status profile customizing.

From this status system allows to set the following status.

When the trade promotion type customizing is changed to hide the system status only the user status appear in the status drop down list.

The user status that is available in the drop down list is controlled by the lowest and highest status number in the customizing.

The next user status allows more different status to be set.

Once any user status triggers a business transaction, the same sets the system status as defined in transaction BS33.

Setting the user status APTP 'Promotion Approved' triggers business transaction CAPR 'Approved' which sets the system status I1122 'Approved'.

System Status

In addition to the user status there are several system status that may be set directly in the marketing plan object. The available system status depend on the lifecycle of the marketing object. Depending on the mentioned customizing the system status can be set directly or can be hidden to the user.

The list of allowed system status is built in CL_CRM_MKTPL_STATUS_COLL=>GET_PERMITTED_CHANGES.

The following system status are available:

• Created CRTE: initial status for new marketing projects
• Released REL: released for the operative execution of the marketing activities
  • generates conditions in a trade promotion
• Finished FSHD: the marketing project is finished/completed
  • does no longer allow changes
  • lower level marketing projects need to be finished as well
• Rejected CNC: the marketing project is cancelled
  • rejected status can be set for released projects only
  • lower level marketing projects need to be rejected
• Locked LCK: locks the marketing project

Status Design in Marketing Plan Objects

When a new marketing project the status customizing is read and the status object is generated. This is created in CRM_STATUS_OBJECT_CREATE. Other than for other marketing project data sets the status profile is stored in the general status object table CRM_JSTO only. There is no marketing project specific table available. Depending on the status customizing the initial status entries are created in table CRM_JEST.

Any status that sets business transaction 'Change Attributes' CGCH to forbidden, prohibits any further changes in the marketing project.

There are no changes allowed other than status changes.

Setting any status that sets CGCH is set to forbidden requires a change of the marketing project. This can be from any user status, with the transaction control or from setting system status rejected or finished.

Status Management in Trade Promotion Management

In trade promotion management there are several processes and events that are driven by setting a status. Those so called status driven events are defined in the following customizing:

Customer Relationship Management

Trade Promotion Management

Basic Data

Define Status-Driven Events

These events are triggered depending on a certain user or system status.

Further information on status driven events is available with the following SAP notes:

1521715  Warning messages for certain Status-Driven Events

1308738  Event handler setup for TPM Fund Integration

The status 'in simulation' is available for trade promotion objects only. This is used to simulate the conditions generation in trade promotions. The trade promotion generates PR and CD conditions but cannot be used - the condition records are generated for simulation reasons only.

Trade promotions with status 'in simulation' have the system status I1327 CSIM 'In Simulation' assigned. This status does not allow to move or delete trade promotions. An error is raised accordingly.

The same is valid for released trade promotions. A released trade promotion can never be deleted.

The status 'rejected' and 'finished' can be set for released trade promotions only.

Status Management in Campaign Management

A campaign that is not released cannot be executed. The campaign needs to be relaesed first.

Other than for trade promotions, campaigns that are released but not yet exectued can be delelted.

Status Dependencies in Marketing Plan Hierarchies

If there is a certain marketing plan hierarchy there status dependencies between the different hierarchy levels.

If any lower level project is released the higher level projects need to be in released status as well. Otherwise releasing the lower level project won't work. The same is valid for moving marketing projects. When moving a released project under an unreleased project an error is raised as well.

The check on the higher level projects for any status change is performed in CL_CRM_MKTPL_STATUS_COLL=>OBJECT_CHECK_ACTIVITY. For releasing the check is performed in CL_CRM_MKTPL_STATUS_COLL=>OBJECT_CHECK_RELEASE.

If any higher level project is finished or rejected the lower level projects need to be in rejected or finished status. Otherwise rejecting or finishing the higher level project won't work.

If undoing the rejected status in any lower level project the higher level projects must not be in rejected or finished status. Otherwise rejecting or finishing the higher level project won't work

Known issues

There are some known issues related to the status management in marketing plans. The issues should be solved with the following SAP notes:

2068420  Unable to close a marketing project if it has a child project in system status

2060455  Cannot Reset Rejected with CRM_MKTPL_COND_IF_R001 report

2032766  Check for higher level campaign on releasing element

2011227  Trade Promotion cannot be saved due to missing status object.

1966547  Changing the status is not saved when the Change History assignment block is open.

1947056  Unable to change the user status of a marketing plan or a campaign that has business transaction "Change Attributes" forbidden

1940193  Campaign with user status allowed to be released

1901364  TPM: System status change not saved automatically

1900066  User status change cannot be saved

1899358  Not able to save new user status if attr. change forbidden

This document should provide an overview about status management in CRM Marketing Plan objects. In case you feel anything is missing, or anything is unclear please let me know.

SAP Loyalty Management offers Tier upgrade & downgrade features which can be easily maintained in CRM system. Tier management in loyalty helps you to recognize your most valuable customers. Based on this identification, you can plan incentive program or marketing activities around this. For example Loyalty tiers are: Bronze, Silver, Gold and Platinum. By default, Members will be enrolled into lowest level and based on your upgrade or downgrade rules Tier change can happen.  In this example, you can see, how tier upgrade reward rule can be set up in CRM system?

Define Tier profile, Tier group and Tier levels in customizations.

Reward Rule conditions and Actions:-

Member activity- Earn

System will upgrade the tier based on the above reward rule during Member activity type – Earn.

In the similar lines, you can define Reward rule for Tier downgrade as well.

During one of my consulting assignment, customer was in a dilemma, whether to implement SAP ICM or SAP Loyalty management for their business need.  During the product evaluation discussions, as myself spent on couple of implementations on Loyalty management and worked on SAP ICM, I could not straight away justify the solution. This thought process, invoked me to analyze and provide my take to the customer. Below contents explains my understandings.

SAP Loyalty Management:  

• Used to track customer behavior to identity which customers are more valuable, take steps to retain and encourage specific customer behavior.
• Loyalty management is more of a customer (B2B / B2C) centric solution
• Enables Program partner’s participation in the loyalty program through which customer can earn / redeem loyalty points.
• Benefits to generate more customer insights and generate more revenue
• Multi-channel enabled loyalty business process like Interaction center, Web channel, Mobile etc.,
• Self- service portal for  customers to manage loyalty points,  earn and redemption
• Easy to set up Reward rules for Earn / Redeem / Tier change etc.,
• Sales orders and Complaints management integrated with Loyalty solution
• High volumes of transaction supported for Loyalty Engine

SAP Incentive and Commission Management (ICM):  

• Used to monitor partners and employees with monetary incentives
• ICM maps all types of variable remuneration such as bonuses and brokerage
• Develop commission contracts & Individualize the calculation rules as appropriate
• Manage employees and partners by mapping your enterprise organization in the system based on sales territory
• Calculate and process commissions according to company’s product and service offerings.
• Commission recipients can see current status of their earned and anticipated remuneration.      

With above answers, I could able to come to conclusion that, SAP ICM is more for partners / employees, whereas SAP Loyalty management is exclusively for customers. Finally I must tell you that, customer is implementing both solutions as they felt both are equally important.

This document provides some information about the mass change and mass copy process in trade promotions. In certain business scenarios, such as the mass approval process, it is required to change or copy several trade promotions at once. For trade promotions such a function is available from the trade promotion search view.

In the mass change scenario existing trade promotions can have certain attributes changed.

In the mass copy scenario the trade promotions there are 2 different options. To mass copy several trade promotions with or without any attributes changed. Without changing any attributes the newly created trade promotions are similar to the copied ones.

When using the mass copy function with changing attribues, system first creates a copy of the existing trade promotions and then performs the attribute change.

Technically the mass change and mass copy scenario are designed the same way. I will therefore use the mass change scenario for explaining the process more detailed.

The mass change can be performed in foreground or can be processed in background.

Once background processing is selected, date and time for executing the background job can be selected.

The job is then available in transaction SM37 - and can be analyzed from SM37.

Attributes available for Mass Change

System provides the following attributes for the mass change scenario:

• ACCOUNT  Planning Account
  
  Using the ACCOUNT option the account but also the account type can be changed.
• ACCOUNT_FUND Planning Account With Funds Plan
• CAUSAL  Causal
• DATE  Dates
  The DATE attribute provides a way to either shift the whole trade promotion or set a specific date in the trade promotion.
  
  
• DATE_FUND Dates With Funds Plan
• EMPRES  Employee Responsible
• FUND  Funds Plan
• PRODUCT  Product
• PRODUCT_FUND Product With Funds Plan
• STATUS  Status
  The STATUS attribute retrieves a list of all available status that can be set to the selected trade promotions.
  
• TRADERATE Spend Value
  The TRADERATE attribute allows to set a specific trade spend and / or update the spend value accordingly.
  

If any change is not working in online mode, it is not working in the mass change scenario either. If there is any trade promotion related error raised in the mass change scenario, the same should also happen when performing the same change manually in online mode.

The available attributes are provided per default but can be disabled in the following customizing:

Customer Relationship Management

Trade Promotion Management

Activate Attributes for Mass Copy and Change

Parallel Processing

With business function CRM_TPM_1 activated the mass change function is enabled for parallel processing. When changing more than 5 trade promotions at once, system now processes all these trade promotions simultaneously, whereas 5 or less trade promotions are processed sequentially.

The settings for parallel processing are to be done in the following customizing:

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Parallel Processing

Define Settings for Parallel Processing

Additionally the number range object FM_ACL_JOB must be maintained in SNRO.

This is documented in the following SAP note:

1582214  Mass Update Fails on Large Record Sets

Without having the number ranges assigned the job is failing and the mass change won't work.

With  BAdI CRM_MKTPL_TPM_JOB_PROCESSING additional settings for parallel processing can be defined or the job settings defined for parallel trade promotion processing can be overwritten. The BAdI is available in the following customizing.

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Parallel Processing

Business Add-Ins (BAdIs)

BAdI: Job Processing Enhancements

The BAdI is not enabled for multiple use, therefore only one active BAdI implementation can exist.

Known Issues

There are some known issues related to the mass change scenario. Those are solved with the following SAP notes:

2045879  Mass change of product returns successful message even if Trade Promotion was not changed

2038205  Incorrect success message is displayed if BAdI implementation raises error in mass change.

2024499  Planning layout contains the old product replaced by mass change

2014160  Adding a product to a Trade Promotion via mass change or the product assignment

2007156  Planning layout contains the old product replaced by mass change

1916291  Mass change or mass copy popup has invalid status behavior

1912420  Changing all dates with mass copy or mass change

1883508  TPM Condition Generation during mass processing

1807935  Success message when mass change operation fails

1878520  Report CRM_MKTPL_COND_IF_R001 cannot Unlock or Unclose

1867183  Conditions not generated during mass processing

1792954  Issue msg when Mass Change fails for lack of ressources

1582214  Mass Update Fails on Large Record Sets

This document should provide an overview about the mass copy, mass change and mass approve function in trade promotions. In case you feel anything is missing, or anything is unclear please let me know.

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.

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.
  

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.

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.

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' of 'finished' the rebate agreement gets the status 'released for settleent'
  

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

• manually generate conditions
  
• manually release rebate agreement for settlement
  

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

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:

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

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.

Having funds management integrated in trade promotions enables further planning options within the trade promotion cycle. The trade promotion has a funs plan assigned, that contains several funds. The correct funds to be used for the trade promotion activities are determined based on specific criteria, the particulate funds are associated to the trade promotion at various levels. The expenses expected for the trade promotion are determined and budget is reserved accordingly.

Funds Plan

The funds plan is the most top object in funds management. A funds plan is created as a certain funds plan type, for a certain planning period, for a certain currency and for certain organizational data. Once the funds plan is released it can be used in trade promotions.

The funds plan type defines the technical details of the funds plan and define the scenario where the funds plan is supposed to be used, such as TPM or MDF scenario. The funds plan type further defines which fund types can be assigned within the funds plan.

Funds

A fund is the object used for managing funds. The fund type defines the usage of a fund, the fund type is linked to a specific expense type. Additionally the funds type defines the fund attributes used for funds determination.

Once a fund is in status preliminary any budget may be posted on the fund. The available budget together with several other key figures are available in the fund checkbook.

Several funds are grouped together within a funds plan. Once the funds are released, they can be used in the trade promotion.

The sample funds plan contains 3 funds from different funds types, generated for different product categories.

TP Fund Association

The integration of funds management into trade promotion management starts with the assignment of the funds plan to the trade promotion. Once the funds plan is assigned to the trade promotion, system ensures that the currencies of the trade promotion and the funds plan match, and that the date range for the trade promotion falls within the planning period of the funds plan, and finally that the funds plan is released.

The funds plan is to be entered in the header of the trade promotion.

Once a certain status is reached the fund association is generated. Technically the same happens from the FUND_ASSOCIATION_HANDLER.

The FUND_ASSOCIATION_HANDLER triggers the funds determination and returns the correct fund for each product dimension / expense type combination. System validates the fund attributes against the trade promotion attributes.

If a fund is returned by the fund determination the fund association is generated accordingly.

In case more products or more expense types are used in the trade promotion several different funds may be returned.

Fund Association Levels

Funds can be associated at the following levels

• Root: with funds association at root level, funds are determined based on the data in the trade promotion header. This should be used if the funds don't have product attributes defined. This is used for general purpose as the funds that are not for specific trade expenses.
  
• Product: with funds association at product level, a level suitable fund is determined for each product included in the trade promotion. The system retrieves the funds applicable to the product (also including product category, product group, and product segment) based on the fund determination rules. This assumes that the fund used at the product level is applicable for all the trade spends you set up for the trade promotion.
  
• Trade spend: with funds association at trade spend level, a suitable fund is determined for each trade spend used in your trade promotion. System uses the expense type that is mapped to the trade spend and the fund determination rules to determine a suitable fund from the funds plan. This option should only be used if the funds don't have product attributes defined.
  
• Trade spend/product: with funds association at trade spend level, a suitable fund is determined for each combination of product and trade spend. This is the most precise way to associate a fund to the trade promotion if the funds in the system have both product and account attributes defined. The fund details assignment block is used to associate the funds at this level.
  

Fund Determination

Fund determination searches and evaluates funds of the assigned funds plan based on certain match criteria. The match criteria are evaluated against the funds attributes. The following match criteria are available in the system:

• Sales or marketing organizational data
• Territory hierarchy
• Marketing plan hierarchy
• Account hierarchy
  • top down fund determination: Fund determination searches for funds that are assigned to the same account hierarchy node level and to a specific account hierarchy node level further down in the account hierarchy.
  • bottom up fund determination: Fund determination searches for funds that are assigned to the same account hierarchy node level and to all levels up in the account hierarchy.
• Product hierarchy
  • bottom-up fund determination: Fund determination searches for funds that are assigned to the same product category and to all levels up in the product hierarchy.

Additionally the TP application uses the following information for determining the funds:

• Funds plan: only funds assigned to the TP funds plan are returned
• Fund status: funds need to be in released status
• Expense type

If no fund or more than one unique fund is returned by the fund determination the same can be assigned manually. If one unique fund is determined the same is assigned automatically.

Fund Usages

Whenever a trade promotion reserves any budget of a specific fund this creates a fund usage. The fund usage represents all fund consumption of the trade promotion.

Whenever the trade promotion receives a status that is supposed to reserve a certain budget the fund usages are generated. Technically this happens from the FUND_USAGE_GENERATION_HANDLER. It is the TP status that triggers the generation of the fund usage.

Each combination of fund, expense type, product dimension allow exactly 1 fund usage to be generated. In case 1 fund usage got balanced manually by the user, system won't allow to create a new fund usage for the same trade promotion for the same attributes.

Availability Check

Once fund usage items are generated in the trade promotion the availability for the assigned funds can be checked. This happens based on the AVC profile which has certain check and tolerance rules assigned. If the availability check if failing either a hard error or a warning is raised. The availability check is triggered by the FUND_AVAILABILITY_CHECK_HANDLER. Technically this is a simulation of a fund posting.

Fund Postings

The fund usage holds the postings done to a specific fund. The status of the trade promotion defines which postings happen to the funds. On changing the status of a the trade promotion the FUND_PREPARE_POSTING_HANDLER generates the fund posting transactions, on saving the FUND_POSTING_HANDLER saves the fund posting on database.

Each fund posting has a certain posting transaction, and updates certain value categories. The fund checkbook is updated according to the value category from the fund posting. In that example the status 'approved' creates a 'reserve budget' transaction that updates the prereserved amount in the fund:

The status 'released' puts the amount from prereserved to reserved. The 'reserve budget' fund posting therefore releases the prereserved amount and reserves the amount accordingly:

Accruals

For all committed amounts other than provided for off-invoice discounts the amounts can be accrued to post the expenses.

There are two types of Accruals:

• Volume Based
  Sales Orders are created in ERP and the budget they consume are transferred to CRM.
  • Accrual calculation determine the amount of the rebates based on Sales volume
  • Accrual posting transfers the results from ERP to CRM.
• Fund Based for fixed rebates A fixed amount of money is set for a given period of time (e.g. 1000$ for one year). Small amounts of money are calculated to pay the customer on short period basis (e.g. 250$ per quarter).
  • Accrual calculation determines the frequency and the amount of money of the payments
  • Accrual posting transfers the results from ERP to CRM.

The accruals are not calculated automatically but require scheduling the accrual calculation run as a background job. The accrual method can use various reference data types. Examples include sales volumes (SAP ERP), trade promotion management (TPM) planning data, or funds data. The accrual results are then stored within the accrual staging area. The accruals can then be edited in from the staging area. To create the accruals posting another background job needs to be scheduled.

The accrual calculation happens based on the fund usages generated for a trade promotion. The accrual run results in a fund postings of value category '480 Accrue' for CRM accruals and a fund posting '470 External Settlement' for ERP accruals or for the off-invoice scenario. The fund checkbook is updated accordingly and the fund posting is available in the fund usage:

Accruals can be calculated based on the following calculation methods:

• ERP_SV: Accrues ERP sales volumes and TPM take rates using the ERP sales volume agreement accrual rate
• FIXED_DT: Accrues the amount reserved for the fund usage on a fixed date
• FUNDFIXD: Used for fund-based accruals and accrues the entire amount of the fund on the date the accrual posting is performed (fixed date)
• FUNDRDTA: Spreads fund-based accrual amounts using reference data
• NB_DAYS: Spreads the amount reserved for the fund usage equally over the number of days that it accrues. The number of days can span several periods.
• REF_DATA: Spreads accrual amount using reference data

If accruals are built and calculated in crm the following reports must be scheduled in the following order:

• RCRM_FM_ACL_ACCRUAL_UPLOAD_SV: Uploads sales volumes from ERP to CRM
• RCRM_FM_ACL_ACCRUAL_RUN: Calculates accruals
• RCRM_FM_ACL_ACCRUAL_POSTING_FM: Posts accruals

To retrieve expenses for off-invoice (discount) trade spends there is the following report available:

• RCRM_FM_ACL_ACCRUAL_UPLOAD_DIS

To calculate accruals for free good trade spends there is the following report available:

• RCRM_MKTPL_TPM_DISC_FRGOODS

To bring ERP accruals to CRM there is the following report available:

• RCRM_MKTPL_TPM_EXT_ACCRUALS

Depending on the scenario there following reports need to be used and result in the following fund postings:

• CRM accruals
  
• ERP accruals or off-invoice scenario
  

Trade Promotion Status dependencies

Depending on the trade promotion status there is the following design for fund usages and fund postings.

• Approved: Fund usage will be created (if not yet created) in status 'released' and a 'Reverve Budget' posting is created with 'prereserved amount' value category
• Released: Fund usage will be created (if not yet created)  in status 'released' and a 'Reverve Budget' posting is created with 'reserved amount' value category. The earlier prereserved amount is released again.
• Canceled: A 'Cancel Budget' posting is created that releases the 'prereserved amount' and the 'reserved amount' value categories. Additionally a 'Balance Fund Usage' posting is created with 'unconsumed budget', 'accrual balance' and expensed' value categories. The fund usage gets the status 'balanced' so no more postings can happen for the fund usage.
  
• Finished: A 'Balance Fund Usage' posting is created with 'unconsumed budget', 'accrual balance' and expensed' value categories. The fund usage gets the status 'balanced' so no more postings can happen for the fund usage. The reserved budget is not released again, this is the main difference to the cancellation process.
  

Customizing

Fund Plans and Funds

Settings for fund plans and funds need to be maintained in the following customizing:

Customer Relationship Management

Funds Management

Funds Plans and Funds

This customizing in not trade promotion specific.

TP Funds Integration

To enable funds integration in trade promotion management the following customizing needs to be maintained:

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Funds Integration

Define Settings for Funds Integration

In the 'Trade Spend to Expense Type' dialog the mapping from the trade spend type, spend category, spend method to the expense type is done. The 'Expense Type to Key Figure' dialog holds the mapping from the expense type the the BW key figure used for retrieving the amount. In the 'TFM Integration View' dialog the fund integration settings for each trade promotion type are done. This contains the following maintenance dialogs:

• Fund Association: holds the fund association level, the fund determination profile and the fund plan date range check.
  
• Expense Type to Accrual Profile: holds the accrual profile and the accrual date range maintained for each expense type
  
• System Status to AVC Profile: defines which value category posting is done by the system status set. Additionally this customizing holds the AVC profile and defines if the funds plan is still editable in this status.
  
• User Status to AVC Profile: defines which value category posting is done by the user status set. Additionally this customizing holds the AVC profile and defines if the funds plan is still editable in this status.
• Aggregation Type: the aggregation type defines how product data is aggregated when the system generates fund usage items for a trade promotion. This is relevant in case several products are used rather than product categories or product groups.

Status Driven Events

In trade promotion management most processes related to funds integration are driven by setting the status. Those so called status driven events are defined in the following customizing:

Customer Relationship Management

Trade Promotion Management

Basic Data

Define Status-Driven Events

These events are triggered depending on a certain user or system status.

Further information on status driven events is available with the following SAP notes:

1521715  Warning messages for certain Status-Driven Events

1308738  Event handler setup for TPM Fund Integration

Fund Determination

The following customizing is required to set up the fund determination match criteria:

Customer Relationship Management

Funds Management

Fund Determination

Define Fund Determination Profiles

Availability Control (AVC)

The AVC profile needs to be defined in the following customizing:

Customer Relationship Management

Funds Management

Availability Control (AVC)

Define Availability Control (AVC) Profiles

The AVC profile holds the information about the check rules and the tolerance profile assigned.

Accruals

Settings for accruals need to be maintained in the following customizing:

Customer Relationship Management

Funds Management

Accruals

Define Accrual Profiles

The accrual profile holds the calculation method for calculating the accruals.

Since the accruals retrieve ERP statistics the middleware needs to be set up properly as well.

Common Issues

There may be some inconsistences related to fund postings - once the root cause for the inconsistencies is determined the following reports are available to correct those faulty postings:

• CRM_FM_FPO_CORRECT_FINALIZE: this report needs to be run once after upgrade to CRM 7.0 in order to migrate the unconsumed budget values
• CRM_FM_FPO_CONSISTENCY: this report is used to find fund postings with references to non-existing claim documents
  Please refer to the disclaimer of the report and run the report in simulation mode only, this is documented in the following note:
  1646935  Fund posting with reference to non-existing claims
• CRM_FM_FPO_AGR_CONSISTENCY: this report checks the consistency of the "checkbook", i.e. the fund period and fund usage item aggregates for fund postings.
  Please refer to the disclaimer of the report and run the report in simulation mode only, this is documented in the following note:
  1288073  Fund posting aggregates consistency report
• CRM_FM_FPO_CORRECT_POSTINGS: This report is used to correct individual fund postings for two different reasons:
  • The fund posting is wrong and needs to be reversed. A possible reason for a wrong fund posting might be the abortion of the creation or the status change of a claim. Prior to the correctionof note 1664635 this might have lead to wrong posting.
  • The budget reservation posting for a trade promotion reversed existin external settlements by ERP discount uploads.

          Please refer to the disclaimer of the report and run the report in simulation mode only, this is documented in the following note:
          1681596  Inconsistent fund postings

Additionally there are some known errors related to trade promotion funds integration. Those are solved with the following SAP notes:

2111673  Fund posting from none existing fund usage

2103980  External accrual values are not correct in CRM / Run time error when running External accruals load

2093937  Error on finalize posting in case of missing accrual profile

2090209  Double clearing the reserved amount of a fund usage

2094576  Wrong posting against logically deleted items

2064326  Wrong Accruals after change of transfer date

2058494  Fund posting not cancelled upon document cancellation

2031014  Accrual items wrongly created or no accrual postings get created

2021587  Double reserved or pre-reserved amount posted

1989720  Performance improvement - Funds management reports

1947138  Deleted fund usage item accrual not reversed

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

“For the KPIs Market Share, Net Promoter Score, Web Visits and Web Downloads of the Marketing Executive Dashboard in hybris Marketing the underlying business data must be uploaded from external sources. This can be achieved by using CSV-files in a certain format. In this document one can find files for examples of that business data. These files can used to set up a demo or test-environment, but cannot be used for productive use . To do so, please follow the description in the Installation and/or Operations-Guide which can be found on the help portal http://help.sap.com/CEI”.

Download Link to Demo Data

SAP Loyalty Management offers Tier upgrade & downgrade features which can be easily maintained in CRM system. Tier management in loyalty helps you to recognize your most valuable customers. Based on this identification, you can plan incentive program or marketing activities around this. For example Loyalty tiers are: Bronze, Silver, Gold and Platinum. By default, Members will be enrolled into lowest level and based on your upgrade or downgrade rules Tier change can happen.  In this example, you can see, how tier upgrade reward rule can be set up in CRM system?

Define Tier profile, Tier group and Tier levels in customizations.

Reward Rule conditions and Actions:-

Member activity- Earn

System will upgrade the tier based on the above reward rule during Member activity type – Earn.

In the similar lines, you can define Reward rule for Tier downgrade as well.

During one of my consulting assignment, customer was in a dilemma, whether to implement SAP ICM or SAP Loyalty management for their business need.  During the product evaluation discussions, as myself spent on couple of implementations on Loyalty management and worked on SAP ICM, I could not straight away justify the solution. This thought process, invoked me to analyze and provide my take to the customer. Below contents explains my understandings.

SAP Loyalty Management:  

• Used to track customer behavior to identity which customers are more valuable, take steps to retain and encourage specific customer behavior.
• Loyalty management is more of a customer (B2B / B2C) centric solution
• Enables Program partner’s participation in the loyalty program through which customer can earn / redeem loyalty points.
• Benefits to generate more customer insights and generate more revenue
• Multi-channel enabled loyalty business process like Interaction center, Web channel, Mobile etc.,
• Self- service portal for  customers to manage loyalty points,  earn and redemption
• Easy to set up Reward rules for Earn / Redeem / Tier change etc.,
• Sales orders and Complaints management integrated with Loyalty solution
• High volumes of transaction supported for Loyalty Engine

SAP Incentive and Commission Management (ICM):  

• Used to monitor partners and employees with monetary incentives
• ICM maps all types of variable remuneration such as bonuses and brokerage
• Develop commission contracts & Individualize the calculation rules as appropriate
• Manage employees and partners by mapping your enterprise organization in the system based on sales territory
• Calculate and process commissions according to company’s product and service offerings.
• Commission recipients can see current status of their earned and anticipated remuneration.      

With above answers, I could able to come to conclusion that, SAP ICM is more for partners / employees, whereas SAP Loyalty management is exclusively for customers. Finally I must tell you that, customer is implementing both solutions as they felt both are equally important.

SAPCRM Loyalty Management Important tables  and Reports

Master tables – Business Partner – Member – membership

Product Master –

Member activity

Dynamic Attributes

Function Modules

Reports

In this document I want to give an overview about how currencies are processed in CRM trade promotion management. This contains some useful information, some process use cases and some known issues.

How is the TP currency determined?

When creating a new trade promotion the currency field is not filled per default.

The currency can either be entered manually or is defaulted by the sales organization assigned to the trade promotion.

The currency is a TP header attribute. The defaulting happens in the following method:

CL_CRM_MKTPL_HEADER_ITEM=>DEFAULT_CURRENCY

The defaulting based on the sales organization happens only if no currency is yet assigned. If the currency is manually inserted before the defaulting no longer takes place. The same rule is valid when changing the sales org. In case this design needs to be changed - so the manual assignment of the currency should get overruled by the default currency from the sales org this needs to be done using BAdI CRM_MKTPL_OL_OBJ interface method SET_ATTRIBUTES_AFTER.

Which currencies can be used in a trade promotions?

Basically there are no restrictions. Each currency defined in table TCURC can be used. The validation of the entered currency happens in the following method:

CL_CRM_MKTPL_HEADER_ITEM=>CHECK_CURRENCY

The currency is not validated against the sales org, nor the planning account in the trade promotion. The only thing that is considered during the check is that if the trade promotion was created from a deal that the TP and the deal currency must match.

In case the check should be done more restrictive and the currency should be checked against some further attributes the same needs to be done using BAdI CRM_MKTPL_OL_OBJ interface method CHECK_ATTRIBUTES.

Can the TP currency changed?

The TP currency can be changed as long no planning profile group is assigned to the trade promotion.

Once a planning profile group is available in the trade promotion the currency can no longer be changed. As long as the TP status allowes removing the planning profile group the currency can be changed. This is usually for trade promotions that are not yet released.

The currency change design is controlled by the following method:

CL_CRM_MKTPL_HEADER_ITEM=>IS_CURRENCY_CHANGEABLE

How are decimals considered for currencies?

Most currencies use 2 decimals per standard. All the amount fields are displayed using the decimals currency settings.

There are however currencies existing with other than 2 decimal places. The so called exceptional currencies are defined in table TCURX. When looking at the JPY (Japanese Yen) this is defined as having 0 decimal places.

The displayed amounts in the trade promotion are using these settings.

What to be considered with funds integration?

When having funds integrated into trade promotion management, the trade promotion must have a funds plan assigned using the same currency as the trade promotion. Having a trade promotion planned on USD with a EUR based funds plan won't work. The TP and the funds plan currency must match.

The check for the TP and funds plan currency is performed in the following method:

CL_CRM_MKTPL_FPLAN_ITEM=>CHECK_CURRENCY

What to be considered with claims integration?

When the trade promotion is used in claims processing we need to distinguish between the planning and execution currency. The TP currency is the planning currency, whereas the claims currency is the execution currency. The planning currency is used in the trade promotion, in the pricing conditions and in the rebate agreement. The execution currency is used in the claim, the claim settlement and used in the claim validation process. The planning and execution currency do not necessarily be the same.

Imagine having a trade promotion planned with USD.

The rebate agreement as well as the fund usages are created with USD currency.

The claim however may use EUR currency. Once a trade promtotion is added to the claim a currency onversion is taking place.

When adding the trade promotion to the claim the amounts are retrieved from the TP fund usages, while retrieving the amounts the currency conversion takes place in the following method:

CL_CRM_FM_FPO_CURR_CONVERT=>CONVERT_TO_FOREIGN_CURRENCY

For any further processing such as settlement creation the claims currency is used.

Are there any typical issues related to currencies in trade promotion management?

For currencies using 2 decimals there are no known issues, however for exceptional currencies there are some issues, most related to the display of the amounts. Known issues are solved with the following SAP notes:

2106896 Decimal issues in Planning Layouts when working with exceptional currencies

2103997 Wrong spend value is updated for a percent spend type in the spend overview grid

2094790 Trade promotion search not showing spend currency values

2073534  Wrong decimal point for amount on Claim Processing Documents

2033052  Totals Assignment Block is incompatible with Decimal Notation Y (1 234 567,89)

1963366  Currency decimal settings not considered in Spend Value Overview AB

1954292  Default Trade Spends currency for all condition calculation types, except percentages

1817618  TPM versions don't show correct spend values

1813856  Spend values and OI Cap are not correct in change history

1775791  Settled amounts wrongly displayed for non decimal currencies

1730452  Wrong spend value due to currency conversion

1712649  Spend Value and OI Cap with Currencies like TWD

1650994  Default currency code of Purch Item from parent object

1650481  Issue with exceptional currencies in Product Causals

1632124  Purchasing AB values not correct for ex currencies (TCURX)

1607017  Handling exceptional currencies in Trade Spends Values

Are there any typical issues related to currencies in claims management?

2106736 Error messages on invoice claims do not show correct amounts

2096111 Resolution tree root node with wrong currency format

2073534 Wrong decimal point for amount on Claim Processing Documents

1837253 Currency conversion issue during settlmenet

This collection will be updated whenever any new correction is released.