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.

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. This is called for short term trade promotions only. Since long term trade promotions don't create CD conditions the method is not called. Since long term trade promotions don't have CD conditions the method would fails since LR_COND_MAINT_CD is initial.

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

BAdI

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

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 similar document is available for Pricing Conditions in CRM Trade Promotions and for Rebate Conditions in CRM Trade Promotions

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 Generation

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.

When PR conditions are generated the product assignment is validated against the master data. This happens in the call of

cl_crm_mktgs_prod_assign=>reeval_mass_assign. In case the master data got changed conditions cannot be generated and the following error is raised:

CRM_MKTPL_COND_IF 077 Pricing conds not maintained successfully; status change cannot be saved

In that case the PMDC report needs to be used to correct the product master data. Please find further information about the PMDC in the following document: PMDC report in CRM Trade Promotions

Status Dependencies

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 Types

The condition types are available in the following customizing path:

Customer Relationship Management

Basic Functions

Pricing

Define Settings for Pricing

Create Condition Types

The condition type stores the information about the conditions to be generated. For Pr conditions the most important information is the calculation type. The calculation type specifies how the system calculates the conditon value. For PR conditions this is either a fixed amount per quantity or a percentage value.

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.

BAdI

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

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.

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

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

No data for condition generation available [CRM_MKTPL_COND_IF 044]

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

Known Issues

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

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

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

1901912  Condition generation errors

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.

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

A trade promotion can have different date types assigned having a different meaning for the business process. The planned and actual date for the trade promotion are available as per standard design. All additional date ranges are to be defined in customizing. Depending on the business process there are the following date ranges available: buying periods, promotion dates, pre-dip or post-dip date ranges. The dates need to be entered in the dates assignment block.

Technical Background

The planned and actual date technically are considered as HEADER attributes, whereas all other date ranges belong to the DATES assignment. The BAdI CRM_MKTPL_OL_ASG can be used for modifying the dates design.

For the dates assignment block there is the following design. Whenever the trade promotion is in display mode, only maintained date ranges are displayed. Any date ranges that are not filled yet are not displayed unless the trade promotion, respective the dates assignment block is in edit mode.

Technically there are the following date relations processed, the TPMDateRel relation containing all dates ranges that are available in the trade promotion and the TPMDateMaintainedRel relation containing all dates that are maintained in the trade promotion. The date relations are retrieved from method CL_CRM_MKTGS_IB_DATE_NODE_VIEW=>LOAD_ITEMS.

Dates are stored as timestamp with reference to the creation time zone. There are however the following options to influence that design:

• Define Fixed Time Zone Conversion
  Fixed Time Zone Conversion is used for conversion of date and time fields to and from time stamps stored in UTC time zone. This is usually done if dates are to be handled consistently across time zones and no time is to be considered at all.
• BAdI CRM_MKTPL_OL_OBJ=>CHANGE_CONVERSION_TIMEZONE
  Using BAdI CRM_MKTPL_OL_OBJ the interface method CHANGE_CONVERSION_TIMEZONE can be used to initially set the time zone of the trade promotion.

Exceptional Dates

A trade promotion is planned for a certain period of time, any products or trade spends assigned to that trade promotions do not necessarily need to have the same execution dates.

Any different execution dates for products can be maintained as product exceptions. Any discounts are provided for the exception period only. The exceptional periods need to fall into the trade promotion period, otherwise an error will be raised.

The same design is available for products, product categories and trade spends.

Date Dependencies

There are some dependencies related to the trade spend dates.

The buying period is required for BW planning integration. It is the buying period that is synchronized with BPS planning.

All trade spend dates must be within the buying dates of the trade promotion.

Date Shift

Trade promotion dates my be shifted, that means the trade promotion period may be changed. When the trade promotion end date is set to any date prior the current date the trade promotion is considered as ended.

When a trade promotion is shifted the trade spend dates are shifted by the same amount.

After each date shift the discounts are adjusted.

If there are exceptions maintained for the trade spends or the products shifting the trade promotion date has the following design for exceptions:

• Trade Promotion Date Range does not equal Trade Spend Dates
  The trade spend dates are shifted by the same amount as the trade promotion
  
• Trade promotion is shortened
  The trade spend exceptions are shortened as well
  

Customizing

Fixed Time Zone Conversion

Whether to use or not to use fixed time zone conversion is set in the following customizing:

Customer Relationship Management

Marketing

Marketing Planning and Campaign Management

General Settings

Define Fixed Time Zone Conversion

This setting should be done once and should not be changed afterwards.

Additional Date Ranges

Additional Date Ranges are defined in the following customizing:

Customer Relationship Management

Marketing

Marketing Planning and Campaign Management

Basic Data

Define Additional Date Ranges

This customizing is available for different marketing plan objects, for trade promotions the customizing needs to be set in the 'Trade and Deal' maintenance dialog:

TP type specific date customizing

In the following customizing specific date ranges can be assigned to a trade promotion type explicitely:

Customer Relationship Management

Marketing

Marketing Planning and Campaign Management

Basic Data

Define Types/Objectives/Tactics

In the 'Date Ranges' dialog any additional date ranges can be maintained.

In case this is not maintained explicitly all additional date ranges available for trade promotions can be assigned.

Dates Design for Trade Promotion Templates

Trade promotion templates are designed to handle relative dates only. The standard configuration therefore shows the relative dates only but not the absolute dates.

When a trade promotion is generated from a template the trade promotion dates are calculated as per the templates date rules.

Trade promotion templates will fully work with relative dates only. There may be various issues when using absolute dates. Since for trade promotion templates the TPMDateMaintainedRel relation is filled with relative dates only in CL_CRM_MKTGS_IB_DATE_NODE_VIEW=>LOAD_ITEMS display issues may happen when using absolute dates. In display mode it may happen that trade promotion template dates are not visible due to that design.

Common Issues

There are some known errors related to dates in trade promotions. Those are solved with the following SAP notes:

2076772  In Trade Promotion, when changing the plan dates, the trade spend exception dates may be changed to an undesirable date

2051196  Clearing the End Date and changing the number of Weeks ( duration ) results in a error

1968576  Wrong Defaulting/ Determination based on project Dates

1901919  Duration value changed while creating promotion template

1855835  Date range change don't propagate for Promotion Template

1785945  Defaulting of date ranges for trade spends is not performed

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

Marketing Funds Management can be integrated in CRM trade promotions and CRM campaign management. This article provides additional information about the campaign funds integration. Additional information about the funds management integration in CRM trade promotions are available in the following article:

Funds Management Integration in CRM Trade Promotion Management

With having funds integrated into campaign management the campaign costs can be reserved from available funds to do the annual planning and budgeting and tracking the campaign costs. This article will provide information about the main objects and processes.

Funds Plan and Funds

The funds plan is used for a certain scenario and groups several different funds available for that scenario.

Each fund assigned to the funds plan has certain fund attributes required for fund determination and is used for certain expense types. Fund type A for example may be used for expense types EX1 and EX2 whereas Fund type B may be used for expense type EX2 only.

Fund Association

In campaigns funds integration is triggered with using a funds integration enabled campaign type and assigning a funds plan to the campaign.

This will enable the fund assignment block MKTPRJ_FMI/Funds.

This can be used for display reasons. The marketing spends that are mapped to the expense types are to be entered in the planning layout. The planning layout can be accessed from the funds assignment block.

In campaigns the funds association can be done on two different levels:

• Root level
  With fund association at root level the costs are distributed between the funds irrespective of the spends, the funds are determined on campaign level
  
• Marketing Spend
  With fund association at at Marketing Spend level the funds are assigned to a specific marketing spend, the funds are determined on marketing spend level
  

Fund Determination

In campaign management the funds determination needs to be triggered manually. From the planning layout the fund determination can be triggered. Depending on the fund association level there are the following ways:

• Trigger fund determination directly in case of root association level
  
• Trigger fund determination for each marketing spend type in case of mkt spend association level
  

The fund is determined from method CL_CRM_MKTPL_CPG_FUNDS_COLL=>EXECUTE_FUND_DETERMINATION. This calls the general funds determination API CL_CRM_FM_FND_FUND_DETERMINE=>DETERMINE.

In case more than 1 fund is returned from the fund determination a pop up is raised for the user to select the appropriate fund.

Fund Usages and Fund Postings

Whenever a campaign reserves any budget of a specific fund this creates a fund usage. The fund usage represents all fund consumption of the campaign. The fund usage generation is triggered by the status change in the campaign. There is done based on the following design:

Whenever the status is changed, system executes the same steps in simulation mode triggered from the status change and in update mode triggered from the FINALYZE_BEFORE_SAVE handler of the campaign. On status change method CL_CRM_MKTPL_CPG_FUSG_COLL=>CHECK_NEW_STATUS_FOR_FPO executes the following steps in simulation mode, whereas on saving the same steps are executed from method CL_CRM_MKTPL_CPG_FUSG_COLL=>FINALIZE_BEFORE_SAVE in update mode:

1. check if fund plan and assigned funds are valid
2. check if the newly set status has any value category postings
3. check if there is a fund usage available for the posting - if not create a new fund usage
4. perform the fund posting

The following example shows what happens on status change. The status 'to be approved'' has the value category prereserved assigned in customizing, whereas the status 'approved' and 'released' have the value category reserved assigned. The following fund postings are generated based on the status:

• status 'to be approved'
  since this is the first status that has value category assigned, the fund usage is generated. The fund usage is generated in 'preliminary' status. A prereserved posting in the fund usage is generated
  
• status 'approved'
  the status approved has reserved value category assigned, the fund usage is updated with a reserved posting, the prereserved amount is released, since the amount goes to the reserved budget
  
• status 'released'
  since there is no new posting category assigned, no fund posting is generated. Releasing the campaign however changes the fund usage status from 'preliminary' to 'released'.
  
• status 'finished'
  setting the status finished or cancelled with balance the fund usage, and generates fund postings for releasing the prereserved budget, and posting the unconsumed amount from the reserved amount back to the fund.
  

Customizing

Funds Management Customizing

The funds management related customizing needs to be set up in the following customizing:

Customer Relationship Management

Funds Management

Funds Plans and Funds

This includes the definition of expense types and the assignment to the funds types. In addition the fund types need to be assigned to a fund plan type.

The funds determination needs to be set up in the following customizing:

Customer Relationship Management

Funds Management

Fund Determination

Define Fund Determination Profiles

Planning Integration Customizing

In the following customizing the marketing spend types need to be defined:

Customer Relationship Management

Marketing

Marketing Planning and Campaign Management

Key Figure Planning

Define Marketing Spend Types

Since the amounts come from BW planning the planning profiles for funds integration need to be defined in the following customizing:

Customer Relationship Management

Marketing

Marketing Planning and Campaign Management

Funds Management Integration

Define Planning Profile for Funds Management Integration

The planning profile customizing contains the mapping from marketing spend type to BI Info Object. This is to be done in the 'Map Measure to Marketing Spend' dialog.

The planning profile need to be assigned to the planning profile group used in the campaign. This is done in the following customizing:

Customer Relationship Management

Marketing

Marketing Planning and Campaign Management

Key Figure Planning

Define Planning Profile Groups

The planning profile needs to be assigned as plan type '2 Cost Planning'.

Funds Management Integration Customizing

The following customizing is required for setting up the general funds management integration.

Customer Relationship Management

Marketing

Marketing Planning and Campaign Management

Funds Management Integration

Assign Marketing Spend Types to Expense Types

Mapping of Marketing type to the expense type.

Campaign Type related Customizing

The campaign type needs to be enabled for funds integration in the following customizing:

Customer Relationship Management

Marketing

Marketing Planning and Campaign Management

Basic Data

Define Types/Objectives/Tactics

This contains the assignment to the funds management integration profile.

The funds management integration profile needs to be defined in the following customizing:

Customer Relationship Management

Marketing

Marketing Planning and Campaign Management

Funds Management Integration

Define Funds Management Integration Profile Settings

The funds management integration profile defines if the fund is associated at root or marketing spend level. Further the integration profile contains the fund determination profile, and the campaign date range that is checked against the fund plan validity.

The 'Define Posting Status' dialog contains the status to value category mapping. This can contain both, system and user status.

Common Issues

There are some known errors related to campaign management funds integration. Those are solved with the following SAP notes:

2093937  Error on finalize posting in case of missing accrual profile

2078192  In Campaigns, Funds Plan ID is cleared upon SAVE

2046158  BSP error when funds plan is not assigned

2045253  Inconsistent fund determination for campaign if marketing plan is used for fund

2021587  Double reserved or pre-reserved amount posted

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

Please find some related information in the following articles:

Funds Management Integration in CRM Trade Promotion Management

Status Management in Marketing Plan Objects

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

Marketing objects are set up with certain master data and are valid during a specified time frame. Changes in master data are not reflected automatically in these objects. If one wants to have these master data changes reflected in his objects, it would be necessary to identify and change manually all active and planned marketing objects which can be a very time consuming and inefficient task, therefore the PMDC report is provided.

The scope of PMDC is to evaluate certain master data changes and to apply these changes to affected trade promotions.

Product Assignment

Product Category change

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:

Product 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 detect 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.

Unit of Measure change

The unit of measure may gets changed in the master data for a certain product.

For products getting the UoM changed in the master date there is the following design. The trade promotion has a product assigned with the UoM taken from master data before the product master changed.

If the changed product UoM is still valid for the trade promotions sales data, the PMDC updates the product accordingly.

If the updated product master data is not valid for the trade promotion sales data the product cannot be updated but gets deleted.

This design is also valid for locked products. Since the sales data API won't return any data for locked products the product is supposed to be deleted rather than updated.

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

1817606 - PMDC: Design change for products with modified product categories

1780957 - PMDC report deletes products with invalid Unit of Measures

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

This document should provide an overview about the usage of products in CRM trade promotions. The document contains the different types of products and the different ways of assigning products to trade promotions. Further this document contains information about the required customizing and known issues related to products in CRM trade promotions.

Product Planning Basis

The product planning basis in a trade promotion defines the detail level of the product planning. Trade promotions can use the following as product planning basis:

• Product: the planning happens for several individual products
• Product category: the planning happens on a collection of related products. Usually trade promotions are planned for a whole line of products, for all products within a brand.
• Product group:The product group is an attribute in the sales set of the product. When a product group is assigned, all the products for the sales area of the trade promotion are assigned that belong to that product group.
• Product segment: A product segment provides a different way of grouping products together. Whereas the product group is defined in customizing, the product segment is built on free attributes and created in segmentation.

The product planning basis needs to be selected from the TP header attributes when creating the trade promotion.

Selecting the product planning basis enables the corresponding assignment blocks. Based on the product planning basis only the allowed assignment can be entered.

The product planning basis needs to be entered before entering any product assignment. If product assignment is created in the trade promotion the product planning basis must not be changed any more.

A further restriction is valid for saved trade promotions regarding product segments:

• If the current value of the product planning basis is not 'product segment' or 'product segment and product', then delete those two entries from the drop-down list of the product planning basis field.
• If the current value of the product planning basis is 'product segment' or 'product segment and product', then delete the rest of the product planning basis values from the product planning basis drop-down list.

Product Assignment

When using 'product' as product planing basis there are 2 ways of adding a product to a trade promotion. Usually a product is assigned to a certain product category:

• single assign product: when single assigning products the product is entered directly in the trade promotion. The product category is determined on entering the product.
  
• mass assign product: when mass assigning products the product category is entered in the trade promotion. The category is exploded into the assigned products and the products are added to the trade promotion.
  

Product Category Assignment

When using 'product category' as product planing basis the product category is entered in the product category assignment block. Depending on the minimum level of the product hierarchy defined in customizing there is the following design.

• assigned product category is higher or equal as the minimum level of the product hierarchy: If the assigned product category is higher or equal as the minimum level of the product hierarchy the product category is added directly. Additionally if the assigned product category is higher as the minimum level of the product hierarchy the user gets informed.
  
• assigned product category is lower as the minimum level of the product hierarchy: If the assigned product category is lower as the minimum level of the product hierarchy the product category is exploded to the minimum level.
  The product category 'Machines' has level 1, the minimum level is set to 2 in customizing.
  
  When now entering product category 'Machines' the product category gets exploded into level 2 and the user is informed.
  

Product Group Assignment

The product groups available for trade promotions need to be defined in customizing. The product group then needs to be assigned as a product attribute in the sales and distribution data.

The product group can either be assigned in the product group assignment block or can be used to mass assign products. The product group must not be empty, so must contain a product to be used in a trade promotion.

Product Segment Assignment

The product segment needs to be defined using the segment builder. Only segments from type '02 products' and from usage '06 conditions' can be assigned to a trade promotion. Further the segment needs to be active and the validity needs to fall into the trade promotion validity.

Product Effective Dates

The product effective dates do not necessarily have to be similar to the trade promotion dates. A product can be planned for a shorter period of time as the trade promotion.

The product effective dates can either be entered manually or are defaulted based on a certain date type defined in customizing. The product effective dates need to be inside the trade promotion date range, otherwise an error is raised.

In conditions are generated for the trade promotion the condition records are created for the product effective date range, rather than the trade promotion validity.

Product Exceptions

To restrict the product validity in a trade promotion can either be done via the product effective dates, or can be done with excluding the product.

Using product exceptions the trade spend values can be changed for certain periods.

Product Checks

The following checks are performed on products:

• check if product is already assigned: a product must not be assigned twice, if a product exists in a trade promotion the same product cannot be added again. The user is informed accordingly
  
• Status: system check the product status:
  • A product that is inactive must not be added to a trade promotion
    
    
  • A product that is locked can be used in the trade promotion, however since the locked product must not be used in a sales order the user is informed
    
    
• Sales UoM: The product sales unit is validated against the product master data
  
• Product Effective Dates: the product effective dates need to be inside the trade promotion date range
  
• Master Data: once the trade promotion is released to generate conditions the products are validated against the master data

The following checks are performed on product categories:

• check if product category is already assigned
• check for minimum level of the product hierarchy: when entering the product the level of the added product category is checked and expanded if the level is below the minimum level

The following checks are performed on product groups:

• check if product group is empty: the product group must not be empty to be used in a trade promotion
  

The following checks are performed on product segments:

• check if product segment is active
• check if product segment is from usage '06 conditions'
  

There are some checks that are performed once a certain user interaction is performed:

• delete products: products must no be deleted from an active trade promotion. A trade promotion is considered as active once it is released and the start date of the trade promotion is reached. When deleting a product, system check if the trade promotion is active and prohibits the deletion
  
• exclude products: similar to the deletion a check if performed when excluding a product from the trade promotion.
• check for invalid retroactive off-invoice trade spend: if a past dated trade promotion contains any off-invoice trade spend system checks for invalid retroactive off-invoice trade spends exist in the promotion. Depending on the customizing and on the sales area which is assigned to the promotion, retroactive off-invoice trade spends can be allowed. If at least one off-invoice trade spends exists and if the Product Effective Start Date is
  set to a prior date than today, then an error message is raised for the user, saying that it is not possible to add/modify Products when Retroactive Off-Invoice Trade Spends exist. If it is allowed a warning is raised.
  

PMDC report

Trade promotions are set up with certain master data and are valid during a specified time frame. Changes in master data are not reflected automatically in these objects. Updating the changes to the trade promotion need to be done manually using the PMDC (Persistent Master Data Changes) report. The scope of PMDC is to evaluate certain master data changes and to apply these changes to affected trade promotions. Detailed information about the PMDC report is available in the following document:

PMDC report in CRM Trade Promotions

Customizing

Product Planning Basis

The following customizing sets the allowed product planning basis for each object type and defines the default value:

Customer Relationship Management

Trade Promotion Management

Basic Data

Products

Define Product Planning Basis

Product Hierarchy

In the following customizing the product hierarchies that can be used in the trade promotion need to be assigned:

Customer Relationship Management

Trade Promotion Management

Basic Data

Products

Assign Product Hierarchies

This customizing also defines the minimum level of the product hierarchy for both, long term and short term trade promotions.

Product Effective Date

The following customizing contains the date range that is used for defaulting the product effective date:

Customer Relationship Management

Trade Promotion Management

Basic Data

Products

Define Product Default Date Ranges

Product Groups

Product groups are defined in the following customizing:

Customer Relationship Management

Master Data

Products

Special Settings for Sales Operations

Define Product Groups

There are 5 product group categories available in the system. The category used in trade promotions must be assigned in the following customizing:

Customer Relationship Management

Trade Promotion Management

Basic Data

Products

Assign Product Groups

Known issues

There are some known issues related to product assignment in trade promotion, those are solved with the following notes:

2124902  Product Category overlap check does not skip excluded PCat

2042961  Retro Off-Invoice Check not triggering error or warning message when product, product category, product segment, or product group is added to a Trade Promotion.

2014160  Adding a product to a Trade Promotion via mass change or the product assignment block does not generate the condition records

2023700  Performance issue when checking products consistency

1983655  Exclusion of Product  Category does not delete campaign determination records

1978393  Products with a sales category assigned are not found

1919259  Trade Promotion: Territory check on Sales Category fails

1899400  Search Criteria for product segment incorrect in TPM

1443903  Product Exclude Flag does not delete CD Conditions

Known issues related to the PMDC report are listed in the following document: PMDC report in CRM Trade Promotions

This document will be updated regularly. In case you are missing any information please let me know.

Issue: Segmentation Model or Flex Based Graphical Modeler not working in IE11 Browser

If you have following Flex Segmentation Modeler issue:

• Flex Modeler screen does not appear in full size and would rather be displayed in half size.
• When creating a new Model, the cursor in the dialog box would be blinking but the letter won't be displayed when typing.
• Error on clicking any button in toolbar: "TypeError: Object doesn't support property or method 'xyz' where 'xyz' is the name of the method.

To resolve the issue, please follow the SAP Note:2132230

https://service.sap.com/sap/support/notes/2132230

Regards,

Kunal Bansal

The following document explains the design of trade promotion search in the CRM system and lists some known issues.

Search by Account Dimension

Search by CUSTOMER_ID

Trade promotions can be searched by a specific planning customer. The account A may be included in a account hierarchy, and may be used in a target group as well:

When now searching for any trade promotions by account A the search returns trade promotions created for account A directly, but also trade promotions that are created for any account hierarchy including account A and trade promotions created for target groups including account A as target group member. The following trade promotions are returned in that scenario:

The search returns any trade promotions having the account assigned, including assignment in any hierarchy node as well as assignment in any target group.

Search by NODE_ID

A account hierarchy node is included in the account hierarchy.

When searching for the 'Account Hierarchy Node ID' = 1-B-2 system returns all trade promotions created for searched account hierarchy including all trade promotions created for any account hierarchy above the searched node in the account hierarchy.

If looking at an existing account hierarchy in the system and search for account hierarchy node 300016/30203000, all trade promotions having account hierarchy 300016/30203000 or any node above assigned as a planning account.

In case this design needs to be changed so a direct search by account hierarchy needs to be implemented the approach mentioned in the following note needs to be applied:

1298156  Search by Hierarchy Node

The following example shown how the TP search by account hierarchy node search is designed to work:

When searching by account hierarchy the search will only return trade promotions created for account hierarchy node account dimension, so no trade promotions created on account level, nor target group level will be returned.

There is the above account hierarchy with having trade promotions created for each hierarchy node:

The search by any lower level account hierarchy node searches for all parent account hierarchy nodes, and returns trade promotions with account dimension account hierarchy created for for any of the parent account hierarchy nodes:

The search for the top level account hierarchy node, just returns trade promotions created for that account hierarchy node:

When searching for any account hierarchy node from the middle of the hierarchy, system returns all trade promotions with account dimension account hierarchy created for account hierarchy nodes similar to the searched one or above in the hierarchy, but not below - all parent account hierarchy nodes are returned but no child account hierarchy nodes:

Search by Product Dimension

Search by PRODUCT_ID

A product may be included in any product category and may be used in a product segment.

A trade promotion search by a product returns all trade promotions that have the specific product assigned as product, as product category or as product segment.

Known Errors

There are several SAP notes correcting known errors:

1802536  TPM Advanced Search incorrect with Acct Hier Node and DESC

1716437  Multi-criteria search w/ Product Category performance issue

1682112  Wildcard in ERP customer for account hierarchy node search.

1785317  Slow performance when search projects with excluded products

1548887  Search by product group doesn't return all projects

1428167  TPM: Performance of search by Product_ID

1407317  FM CRM_MKTPL_GETLIST_TP_FOR_BP is not working correctly

SAP hybris Marketing provides central access for all contact/ customer-related information. This document

describes how to enable hybris Marketing with own data. This includes data upload, segmentation

capabilities, etc,

All information are explained with a small example from the travel industry.

See the document here.

Planning Account

Trade promotions can be created for different account dimensions. The account dimension is stored as TP header attribute.

The following account dimension can be used, having a different business meaning.

• Account: the TP is planned for a single account.
  
  All discounts are provided for that account only.
• Account Hierarchy: the TP is planned for an account hierarchy node
  
  All discounts are provided the whole account hierarchy node including all child nodes and assigned accounts.
  
• Target Group: the TP is planned for a target group
  
  All discounts are provided to all members of that target group.
  

Discounts for different planning account dimensions

Depending on the account dimension the condition records may be generated on different levels. For a single planning account the condition records are always generated on account (sold to) level.

For account hierarchies or target groups the condition records may be generated on hierarchy or TG level. The condition records are created on a generic hierarchy or TG level:

Alternatively the condition records may also be generated on account (sold to) level. In that case the account hierarchy or target group is exploded to get all assigned accounts.

Further information about conditions generated from trade promotions is available in the following documents - this also contains the configuration of the above mentioned scenarios:

Campaign Determination Conditions in CRM Trade Promotions

Pricing Conditions in CRM Trade Promotions
Rebate Conditions in CRM Trade Promotions

Trade promotion search via planning account

The design of the TP search using the account dimension is explained in the following document:

Trade Promotion search in SAP CRM

This explains the design and contains several known issues.

Employee Responsible

The employee responsible is determined based on the user when creating the trade promotion. On changing the trade promotion type is changed the employee responsible may be re-determined based on the partner determination customizing.

Automatic Payer derivation in trade promotions

Depending on the trade promotion type it is required to derive any payer partner function such as the eligible claiming account. The partner is determined based on the function category 0004 Payer:

If a partner function is assigned to the trade promotion type the planning account is exploded to retrieve the payer partner functions. This results in having the payer partner function determined for the planning account. The partners are then displayed in the parties involved assignment block.

The determination works on account level. The planning account gets all 'is payer of' relationships determined from the business partner master data.

There is the following design for different account dimensions:

• Account: the payers are taken from the account master data
• Hierarchy node: the hierarchy node is exploded to get the underlying accounts. The payers are then taken from the accounts
• Target group: automatic payer derivation for target groups is working only if the target group has a account hierarchy assigned:
  
  The assigned account hierarchy node is taken to determine the payer partners.

Depending on the planning account dimension this explosion may be very time consuming. For account hierarchy nodes and target groups all all account hierarchy nodes need to be read to get the payer partner functions for each node. The underlying coding can be found in CL_CRM_MKTPL_HEADER_TPM_ITEM=>SYNCHRONIZE_PLANNING_ACCOUNT. If very generic account hierarchies are used this process may consume a lot of time (technically due to expensive joins on tables BUT_HIER_STRUCT and BUT_HIER_NODE_D). If the payer derivation is not required for the business scenario there are the following options to disable this function:

• no partner determination procedure assigned to the trade promotion type - in that case the payer won't be derived. This was implemented with the following SAP note:
  
  1949598  Performance issue on planning account change
• partner determination procedure assigned to the trade promotion type. If a partner determination procedure is assigned the payer partner function category is determined per default. In case this is not required the payer partner function determination needs to be blocked from customizing explicitly.
  
  This is documented in the following SAP note:
  
  1882551  Unable to skip automatic partner determination for payer in trade promotion

Wholesaler determination for Indirect Trade Promotions

When having indirect trade promotions the wholesaler is determined automatically.

The determination is either triggered when changing any attribute relevant for the indirect scenario such as planning account, product category, dates or can be triggered manually using the 'Determine Wholesaler' function.

The wholesaler is determined based on the indirect relationship created for the account dimension and the product category.

Customizing

Assign account hierarchy

The following customizing is required to define the account hierarchy nodes to be used in trade promotions:

Customer Relationship Management

Trade Promotion Management

Basic Data

Assign Planning Account Hierarchies

Partner Determination

The partner determination procedure needs to be created in the following customizing:

Customer Relationship Management

Basic Functions

Partner Processing

Define Partner Determination Procedure

This then needs to be assigned to the trade promotion type in the following customizing:

Customer Relationship Management

Marketing

Marketing Planning and Campaign Management

Basic Data

Define Types/Objectives/Tactics

Known Issues

There are some known errors related to partner assignment in trade promotions. Those are solved with the following SAP notes:

2097938  Target group not copied to planning account when searched from Trade Promotion

2076667  Employee Responsible is cleared unexpectedly

1989728  Employee Resp. is defaulted to the User ID instead of appropriate Partner Determ. Proc.

1950295  Wrong wholesaler determination and wrong error messages

1949598  Performance issue on planning account change

1946479  Invalid error message during wholesaler determination

1945729  Wholesaler determination fails for TGR with long description

1945728  No wholesaler assigned error persists

1940857  Wholesaler deletion message not logged correctly

1940855  Wholesaler relationships not determined for target group owner

1937309  Wholesaler determination is triggered even if the key values were not modified

1936616  Incorrect wholesaler determination upon BPHN , TG and/ or plan date change

1935409  Indirect account relationships search is not displaying all the Wholesalers

1926556  Wholesaler relationships not determined correctly

1921117  Wholesaler partners are not copied after Trade Promotion copy

1889088  System times out when assigning Account Hierarchy with many partner relations of type Payer

1882551  Unable to skip automatic partner determination for payer in trade promotion

Trade Promotions can be used to provide Free Goods or Free Products. That can be if a certain amount of product is bought the customer gets products for free.

There are various scenarios for the free goods and free products scenario in trade promotions.

Free Goods or Free Products Scenario

The main difference between the free goods and free products scenario is the time when the free products are given away.

Free Goods Scenario

In the free goods scenario the trade promotion generates free goods conditions (condition usage FG).

The condition type generation is driven from the trade spend, there is any free good trade spend used. On releasing the trade promotion the FG condition is generated and transferred to SD.

In SD a sales order is generated and the FG condition is valid the free good is added to the SD order. On invoicing the SD order the ordered product is billed with the regular net value whereas the free product is billed as free product.

The free good is provided immediately once the sales order is delivered.

Free Products Scenario

In the free products scenario the trade promotion generates rebate conditions (condition usage BO).

The condition type generation is driven from the trade spend, there is any rebate trade spend used. On releasing the trade promotion the BO condition is generated and and a rebate agreement is generated in SD.

In SD a sales order is generated and the invoice is created. At that time the free product is not yet granted. Once the invoice is created and the rebate agreement will be processed a new sales order containing the free product will be created.

The free product is granted once the rebate agreement is processed. The condition type used needs to be flagged as FOC relevant. This enables the rebate to generate free of charge delivery orders.

Product Dependent and Product Independent Scenario

Both free goods and free products may be product dependent or product independent. The way the planning layout is defined determines the scenario. If the free goods planning profile is defined as planning type '6 - Free Goods' the trade promotion uses the dependent free goods scenario. If the planning profile is defined as '9 - Product Independent Free Goods' the trade promotion uses the independent free goods scenario.

Dependent Product Scenario

In the product dependent scenario free goods or free products are given away for a specific product. An example may be, if you buy product A, you get product B for free.

The product assignment block contains the assignment from each product to the free product. The assignment needs to be done for each product that is enabled for the free goods scenario.

The planning profile contains a line for the product and the free product.

Independent Product Scenario

In the product independent scenario the same free good or free product is given away for all products that are part of the trade promotion.

A free good that is valid for all trade promotion products is to be provided in the products assignment block.

In the planning profile the free good column is filled over all products.

Exclusive and Inclusive Free Goods

For free goods there are the following different scenarios available.

Exclusive Free Good Discount

When a certain amount of a product is sold, the same product or a different product is also delivered free of charge. The free products are added to the ordered products. In the exclusive free good scenario the same product can be given away or any different product can be given away.

The Free Product is added in the sales order, and delivered accordingly. The invoice however does not contain any price for the free good item.

Inclusive Free Good Discount

When a certain amount of a product is sold, the customer is not charged for the whole order quantity. The free good quantity is not added to the ordered product quantity but customer is not charged for amount of free products. The inclusive free good scenario is available for the same product as the ordered product only.

The free good is determined in the sales order. The delivery contains the order product quantity, but the invoice is reduced by the amount for the free goods.

In the trade promotion the inclusive indicator needs to be set together with the free good in the product assignment block. The inclusive scenario requires the same product as a free good product.

Customizing

Planning Profile

The free goods planning profiles need to be assigned to the planning profile group with the correct planning type, either '6 - Free Goods' or '9 - Product Independent Free Goods'. This is to be done in the following customizing:

Customer Relationship Management

Trade Promotion Management

Key Figure Planning

Define Planning Profile Groups

The FG planning profile available in the planning profile group determines the product dependent or product independent free goods scenario.

Trade Spends and Condition Generation

The trade spends and the assigned condition types need to be maintained in the following customizing:

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Trade Spends

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Condition Maintenance

The usage for the generated condition type defines either the free goods or free product scenario. The free goods scenario generates FG conditions, whereas the free product scenario generates BO conditions to create the rebate agreement.

Rebate Condition Type

In case the free products scenario is used the rebate type needs to be FOC enabled. This is to be done in the following customizing:

SAP Customizing Implementation Guide

Customer Relationship Management

Rebate Processing

Set Up Rebate Determination

Create Condition Types

Known Issues

There are some known issues related to the free goods and free products scenario. Those are solved with the following SAP notes:

1961062  Free product in Free Goods Promotions may get wrong pricing information

1919699  Perform Volumes/Trade Spends date validations for Free Goods promotions

1909607  Sales organization and the status of  Free Products in Trade Promotion is not checked

1803043  Marketing F4 Help for Free Good Product ID adds extra row

1666400  Incorrect free good check in rebates condition generation

1649123  Issue generating Conditions for Free Goods Promotions

Additional Information

Both the free goods and the free products scenario are designed based on different condition types. The following documents contain more information about different condition types generated from CRM trade promotions:

Campaign Determination Conditions in CRM Trade Promotions

Pricing Conditions in CRM Trade Promotions

Rebate Conditions in CRM Trade Promotions

Accrual calculation run can be scheduled in the batch jobs.
The accrual method can use various reference data types, depending on what you
have defined in customizing. Examples include sales volumes (SAP ERP), trade
promotion management (TPM) planning data, or funds data. The accrual results
are stored within the accrual staging area.

This document will only introduce the accrual calculation process. For the accrual reversal(settlement)

process, please refer to the documents below:

Rebate settlement process part I: Accrual reversed by claim settlement process and directly post to FI accounting.

Rebate settlement process part II: Accrual reversed by CRM claim settlement integrated to SD Billing

With the fund management integrated to TPM, the accrual information could be

found in the fund usage. The accrual amount is shown in he fund checkbook once

the accrual posting is done.

With the accrual posting jobs finished successfully leading to the Fund Posting saved,

this will trigger the CRM middleware process to transfer the required information to ERP

for the system assigns the costs and revenues to different CO account assignment objects.

For the detail introduction of the fund usage integration to ERP please refer the document below:
Fund usage integration with ERP - Accrual posting

Customizing:

SPRO -> CRM -> Funds Management -> Define Accrual
Profiles

SPRO -> CRM -> Funds Management -> Define Accrual
Methods

The accrual profile need to be assign to the expense type in
the customizing ‘Define Settings for Funds Integration’.

SPRO -> CRM -> Trade Promotion Management -> Trade
Promotions -> Funds Integration -> Define Settings for Funds Integration

In TPM planning, user fill the spend value to the planning
layout by different planning level. Once the Trade promotion released, the
rebate condition records will generated and replicated to ECC side.

The rebate condition will be determined when create SD
billing document from the sales order.

Then the sales volume will be accumulated in the rebate agreement.

The CRM accrual calculation process takes the "spend
value" in the accrual calculation for Billback promotions (with accrual
method: ERP sales volume).  For lump sums
(with accrual method "Fixed": accrue the whole amount on the fixed
date), the system takes into account the value from the planning layout.

Within this life cycle, the fund usage will connected to the
rebate condition type through the expense type.

Samples in CRM TPM :

Samples in ERP sales order -> (shipping) ->  billing:

Rebate Agreement verfification level:

Accrual Jobs:

step1. accrual calculation: Calculation period and funds plan need to be specified

step2. Verfiy the accrual results: check the fund usage and the accrual amount could be changed before posting to account.

Step3. Accrual posting: choose the same criteria with step1

“Accruals” are fundamental part of the Claims & Funds processes for TPM.

This document will only introduce the scenario that accrual calculated from CRM

fund management and the posting of the reversal to accounting directly by CRM settlement.

For another popular scenario that reversal of external accruals posted
by SD billing by settlement to invoice integration please refer to the document link below:

Rebate settlement process part II: Accrual reversed by CRM claim settlement integrated to SD Billing

This document will focus on the accrual reversal(settlement) process, for the accrual creation(calculation) process

please refer the document link below:

Accrual creation(calculation) by CRM fund management

The conclusion means that in case the accruals are created in CRM Funds, the reversal happens via

CRM Claims Settlement. However if they are calculated in SD, also the reversal happens
there via SD Billing.

There is also a special scenario of Fund based Accruals.
In this case the Funds Management accrues on Fund level. The Claims handle the accruals
with a different Fund Usage than the expense type which is allocated for the reference
object (Trade Promotion, MDF Initiative).  It will be introduced by another
document will published soon.

Settlement
integrated to Claim management

Customizing:

• Set the claim item category to billing relevant, only the item relevant for billing will be settled from the item due list after
  approval.

SPRO -> CRM -> Transactions -> Basic Settings -> Define Item Categories

• Assign billing item category

SPRO -> CRM -> billing -> Item Category Determination -> Assign Item Categories

• Determine the billing type from the billing item category which determined by the claim item category.

SPRO -> CRM -> billing -> Define Billing Item
Categories

SPRO -> CRM -> billing -> Define Billing Types

To specify the settlement integrated to ERP accounting which
means that CRM settlement will post to FI directly without SD billing
integration.

Also there is the flag to indicate whether the automatically
transfer to accounting is enabled or not.

A Cancellation Copying Requirement can be assigned in the
field ‘Cancel. Copying Req.’. This can be used to specify certain conditions
under which the Settlement Document should not be cancelled. The standard
cancellation copying requirement provided the checking to the fiscal period. If
the period has been closed, then the cancellation settlement document will
specify to current date to transfer date instead of copying the transfer date
from the original settlement document.

The integration from CRM Billing to CRM Claims Management works as the flow chart below.

The processing of the billing due list entry creates a settlement. When the settlement is saved,

the BDoc BEABILLDOCCRMB is written and is processed by both the Outbound Flow M01 and the

Inbound Flow MI0. The Outbound Flow transfers the settlement to ERP. The Inbound Flow
updates the settled status (not settled, partially settled, or fully settled),  and doc flow to the One Order

document, which can be a Claim, a Chargeback, or a Prepayment.

Users  always get the question that the claim items have been approved, however the items still can’t
be found in the settlement due list. The first thing need to be check is tcode /bea/crmb04 ‘Incomplete Billing Due List’,

select the items shown here and check the error log. This check should be considered as the daily administrative
work for the production system.

Account Determination for Accruals

Account determination process in CRM claim settlement
directly post to accounting is similar to the pricing technique.

Customizing:

SPRO -> CRM -> Billing -> Integration -> Transfer
of Billing Documents to Accounting -> Transfer to Accounts Receivable
(FI-AR) and Accounts Payable (FI-AP) –> Enhanced Account Determination –>
Define Access Sequences And Account Determination Types

• Maintain Account Determination Types
• Maintain Access Sequences

SPRO -> CRM -> billing -> Define Billing Types

SPRO -> CRM -> Billing -> Integration -> Transfer
of Billing Documents to Accounting -> Transfer to Accounts Receivable
(FI-AR) and Accounts Payable (FI-AP) –> Enhanced Account Determination –>
Assign Symbolic Account Key

For the actual account determination the process looks as below:

The accrual conditions are statistical and flagged as pricing result
relevant. This information is used to post in financials not on the customer or
vendor account, but only to the G/L accounts “Accrual” to “Expense”. Therefore
Account Determination provides for each condition line “two” accounts, the first
for the “Accruals” and the second for the “Expenses”.

Other relevant customizing:

For Company code determination:

CRM -> Master Data -> Organizational Management -> Cross-System
Assignment of Organizational Units

- > Assign Billing Units to Sales Organizations

- > Assign Company Codes to Billing Units

Samples:

Tcode /bea/crmb11 to check the claim settlement document,

user also can check this from CRM WEB UI.

There is a very useful tab ‘Marketing’ in item detail of settlement document which could also be checked from

CRM Web UI marketing assignment block.

It provide the general information of the trade promotion, funds plan, funds and fund usage.

So user can navigate to the objects directly without first to identify the claim
document from the transaction history and then get the TP and fund information from
the resolution tree.

Tcode FB03 to check the accounting document from the claim

settlement document.

Accruals
Handled Externally in SAP ERP

If you define condition generation types for settling rebates using SAP CRM claims

management and accrual calculation methods for handling accruals in SAP ERP and

want to use both settings together in your trade promotions, you must also define an

integration between SAP CRM billing and SD billing in SAP ERP.

When this integration is in place, you create settlement documents in SAP CRM then

those are transferred to SAP ERP right away for further processing. All subsequent processes,

such as account determination, taxation, and printing, are executed on the SD billing documents
that are created automatically from the SAP CRM settlement documents.

For the scenario that Accrual reversed by CRM settlement posting to accounting directly please refer to the document below:

Rebate settlement process part I: Accrual reversed by claim settlement process and directly post to FI accounting.

This document will focus on the accrual reversal(settlement) process, for the accrual creation(calculation) process

please refer the document link below:

Accrual creation(calculation) by CRM fund management

Customizing：

SPRO -> CRM -> Trade Promotion Management -> Trade
Promotions -> Condition Maintenance -> Define Condition Generation

For each condition generation type, when the rebate application is ERP, it is possible to specify CRM or ERP as the
rebate settlement origin.  When the rebate settlement origin is CRM, it means that Claims Management is used to
validate and settle the rebates.  When the rebate settlement origin is ERP, it means that Claims Management is not
used and that rebates are validated and settled manually in ERP

SPRO -> CRM -> Funds Management -> Define Accrual
Methods

• This flag indicates that this accrual method is “external accrual”

Accruals are built on posting invoices in SAP ERP. The
accrual results are uploaded to SAP CRM Funds Management at the level of Fund
Usage to support an accrual display in the Fund Checkbook.

Scenario 1

• SAP
  ERP Rebate processing (standard or enhanced)
• No
  integrate with SAP CRM Funds and claims Management
• Accruals
  building, rebate settlement and finalization take place in SAP ERP

Scenario 2

• SAP
  ERP Rebate Processing (standard or enhanced)
• Integrated
  with SAP CRM Funds and Claims Management
• Accruals
  building in SAP CRM with Sales Volume collected in ERP by conditions mapping to
  the expense type
• Rebate
  settlement and finalization take place in SAP CRM;

Scenario 3

• SAP
  ERP enhanced rebate processing
• Accruals
  building in SAP ERP, integrated with budget control via Funds and Claims management
• Settlement
  and finalization take place in SAP CRM Claims Management; integrated with
  ERP-SD Invoicing via the “Settlement to Invoice”

SPRO -> CRM -> Billing -> Define Billing Types

For settlement to invoice scenario:

• The integration type must be A Integration to SD Billing.
• The sales document type is used to determine the following for a claim settlement document when it is transferred from SAP CRM to SD Billing.

SPRO -> CRM -> Billing -> Configure Application

Note: once any feature was activated in the billing configuration, there will no way to revert it back.

Handling of Cancellation Documentson ERP side

If a CRM billing document is cancelled, CRM will send the cancellation document to SD as well as the ID of the cancelled billing
document.

From the technical point of view, if the CRM billing document is completely cancelled we will have a two-step approach in the
inbound adapter BILL_DOC_INBOUND of ERP:

1. Try to do a real SD invoice cancellation. The FM RV_INVOICE_CREATE has an input parameter ID_NEW_CANCELLATION which shall be set to ‘X’. Pass the ID of the cancelled document which can be found in field CNC_REF_DOC of VBRKCRM.
2. 
   If for any reason an error occurred during this SD cancellation, we will call  the GN_INVOICE_CREATE with the cancellation document as it was posted by CRM. In this case the parameter ID_NEW_CANCELLATION is empty.

Here users always face the problem and get confused in these two situations, the cancellation billing documents in ERP will be determined to different
billing types. This is because in the first case, the billing type is picked from the original SD billing type customizing. The second case, the billing
type of the cancellation is determined followed the normal settlement to invoice process from the copy control Settlement -> Sales Order -> SD
Billing.

Tcode /BEA/CRMB11 to check the Settlement document from SAP GUI, this could also be done from WEB UI.

SD billing document number was updated to the transaction history of the CRM settlement document.

SD billing then posted to FI and get the accounting document updated to CRM settlement document.

This document will introduce the detail how the Accrual posting in CRM transfer to ERP and how to connect with Controlling
(CO) and Financial Accounting (FI) for assigning costs and revenues to different CO account assignment objects.

In our case, we have to transfer the accrual amounts, resulting from the accrual calculation run and the accruals posting, to Financials and Costing.

From the technical point of view, the main process is that saving the fund posting will trigger the CRM middleware process to transfer the required information to ERP.

In the CRM Claims and Funds scenario, when a fund usage is created and saved, the transfer to ERP is triggered  resulting in the creation of a accounting assignment object in ERP for the fund usage. This accounting assignment is the prerequisite for the fund posting transfer the accrual amount to FI.

Middleware settings:

Tcode R3AC1:

An adapter object was created for the BDoc CRM_FM_FU, the name is “CRMFMACCOUNTING”.
The function module for Mapping Module: CRM to R/3: CRM_FM_ACCOUNTING_MAP_TO_ERP.

An adapter object was created for the BDoc CRM_FM_FPO, the name is “ACCRUAL”.
The function module for Mapping Module: CRM to R/3: CRM_FM_ACCRUAL_MAP_TO_ERP.

Tcode SMOEAC:

In transaction, we defined a Replication object, CRM_FM_FU, which has publication “All Fund Usages (MESG)”. In customer system,
we must add a subscription to the publication “All Fund Usages (MESG)”, and add a site of type R/3 to the subscription.

In transaction, we also defined a Replication object, CRM_FM_FPO, which is similar with CRM_FM_FU.

Tcdoe SM30 View SMOFFILFLD:

In this view for object CRMFMACCOUNTING and ACCRUAL, you will find the allowed filters for R3AC1.

Tcode SMO8FD

This view can also access by click the BDOC type in TCode SMW01 monitor. Here the flow contexts were defined.

• Once the middleware setting is done.The fund usage integration process starts with the saving of fund usage triggered by the status changing of the reference object like TPM Then the BDoc “CRM_FM_FU” will be generated and processed by the outbound flow "mBDoc Notification".  Afterwards, CRM Middleware will call the mapping module “CRM_FM_ACCOUNTING_MAP_TO_ERP” of the adapter object “CRMFMACCOUNTING”, which is associated with the BDoc “CRM_FM_FU”.

• Upon a fund posting is saved, a BDoc message of type CRM_FM_FPO is created and sent to Middleware. Middleware then calls CRM_FM_ACCRUAL_MAP_TO_ERP, which in turn calls CRM_FM_ACCRUAL_MAPPING, which maps CRM fund posting
  structures to ERP billing documents.

• The billing documents are then sent to ERP, by calling function module CRM_FM_ACL_ACCRUAL_R3_IN. It calls CRM_FM_ACL_ACCRUAL_LOAD_PROXY which in turn calls BAPI_ACC_DOCUMENT_POST to post Accounting documents in ERP.

TPM Fund usage

TPM fund usage is the scenario that fund management integrated to trade promotion management.

During the creation of fund usage in the scenario of creating a trade promotion.Fund usages that are linked to a TPM require a TPM to be present in ERP before being transferred over. We had the issue where Fund usages were transferred before TPMs, which caused to the transfer of fund usage to fail.

To check the TP transferred to ERP PS go to Tcode CJ20N.

For the topic Marketing project integration to ERP, a document will be released soon.

For the topic Fund management integration in Trade Promotion Management please refer to the document:

Funds Management Integration in CRM Trade Promotion Management

Accounting assignment

In Tcode IAOMC:

with business scenario “CRMFM” and business key is in the form of “Fund usage ID with leading zeros/Fund Usage Item ID”, i.e. 00000000000000001791/10. The screenshot below shows an example on how to search for account assignment management objects.

Accounting determination

customizing:

SPRO -> CRM -> Funds Management -> Accruals -> Integration -> Transfer Accrual Documents to Accounting

SPRO->CRM->Billing->Integration->Transfer of Billing Documents to Accounting->Transfer to Accounts Receivable (FI-AR) and
Accounts Payable (FI-AP)-> Enhanced Account Determination->Assign Symbolic Account Key

For the detail introduction of accrual calculation and reversal process please refer to the documents below:

Rebate settlement process part I: Accrual reversed by claim settlement process and directly post to FI accounting.

Rebate settlement process part II: Accrual reversed by CRM claim settlement integrated to SD Billing

Accrual creation(calculation) by CRM fund management

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. A user status therefore has only descriptive meaning, the user status describes the process, whereas the user status controls the business process. Depending on the customizing the online user can set user status only, system status only or can set both, user and system status.

Status Management 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 highest 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 whether 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'.

In case the user status that is to be set triggers any business transaction that must not be set with the current status, the user status cannot be set as well. The affected user status is filtered from the drop down list for selecting the status.

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 canceled
  • rejected status can be set for released projects only
  • lower level marketing projects need to be rejected
• Locked LCK: locks the marketing project

Business Transaction System Status Dependencies

If a user status triggers a business transaction, the business transaction may be dependent on any system status. A marketing plan that is in status I1004 'released' must not execute business transaction CREL, since the same system status I1004 is set by business transaction CREL. This is mainly depending in the system status set by the business transactions.

The following table shows the dependencies:

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.

Whenever any marketing plan object is accessed system determines any possible status that can be set to the object. This happens in the following coding:

CL_CRM_MKTPL_VH_BOL_PROXY_UTIL=>GET_STATUS_LIST

The list of available status can be modified using BAdI CRM_MKTPL_OL_OBJ interface method CHANGE_VALUEHELP_ENTRIES.

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.

The status design can be influenced using BAdI CRM_MKTPL_OL_OBJ. Both methods STATUS_CHANGE_BEFORE and STATUS_CHANGE_AFTER provide an option to influence the status processing and can prevent any status or business transaction from being set.

Status Management in Trade Promotion Management

Status Driven Events

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

1269223  Missing definitions for event handlers

Status for Funds Management Integration

If funds management is integrated most function are triggered by status driven events. Further information about the funds management integration set up is available in the following doc: Funds Management Integration in CRM Trade Promotion Management

As a brief overview the following event handlers are required:

• FUND_ASSOCIATION_HANDLER: triggers fund determination, if funds are returned, the fund assocication is generated
• FUND_USAGE_GENERATION_HANDLER: generates fund usage for reserving funds, on setting the relevant status
• FUND_PREAPRE_POSTING_HANDLER, FUND_POSTING_HANDLER: responsible for creating fund postings
• FUND_USAGE_FINALIZATION_HANDLER, CSR_USAGE_FINALIZATION_HANDLER: triggered on finishing or rejecting a trade promotion, balances fund usage, ensures that all claims associated with a trade promotion are settled before the trade promotion

Status for Generating Conditions

Campaign determination conditions and pricing conditions are generated on simulating or releasing a trade promotion. The system status I1004 REL 'Released' can either be set directly or can be triggered by any user status with executing business transaction CREL 'Release'.

Pricing conditions can be regenerated with triggering business transaction CCND 'Generate Conditions'. This can be used for automatically generating conditions after any changes are done. The CCND business transaction can be used for an 're-released' user status.

Status 'in simulation'

The status 'in simulation' is available for trade promotion objects only. Trade promotions with status 'in simulation' have the system status I1327 CSIM 'In Simulation' assigned. 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.

Once the status I1327 CSIM 'In Simulation' is set, the initial status I1001 CRTE 'Created' is deleted. This comes from the business transaction CSIM 'Release for Simulation'.

If no user status profile is used, that set an initial status the the trade promotion is in status  I1327 only, after setting to 'in simulation'. Therefore only business transactions allowed for status  I1327 can be performed.

Delete Trade Promotions

Certain trade promotion status may prevent the trade promotion from being deleted. This can either be controlled by the user status, by the system status or by certain assignments that forbid the trade promotion from being deleted.

From the user status the deletion of the trade promotion can be forbidden with setting the business transaction 'Delete Element' CEDL to forbidden for a certain user status:

For the system status the deletion of the trade promotion must be allowed via the transaction control of the system status.

When trying to delete the trade promotion system checks all active system status in the trade promotion. If none of the active system status does allow the deletion the trade promotion must not be deleted.

This happens for trade promotions in status 'in simulation'. The status I1327 CSIM 'In Simulation' does not allow to delete trade promotions. This comes from the transaction control:

Since the business transaction business transaction 'Delete Element' CEDL is not explicitly allowed for the status, the trade promotion must not be deleted.

An error is raised accordingly.

The same is valid for released trade promotions. A released trade promotion with conditions created can never be deleted. System checks the trade promotion conditions assignment. In case conditions are created the trade promotion must not be deleted. An error is raised accordingly.

A similar design is valid for moving a trade promotion like when setting a new parent element for a trade promotion. System checks both user and system status if the business transaction 'Move Objects' COMV is allowed for the trade promotion. For trade promotions in status  I1327 CSIM 'In Simulation' the COMV business transaction is not allowed explicitly.

The trade promotion therefore must not be moved and an error is raised accordingly.

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 released first.

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

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

1853257  Marketing Search Status - IS NOT Filter Not working

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.

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

Overview

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

Rebate Processing Application

Rebates can be processed either in CRM or ERP.

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

Spend Value Types

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

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

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

Account Dimension

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

• Trade Promotion created for an account - the rebate conditions are generated on account level.
  
• Trade Promotion created for an account hierarchy
  • rebate conditions are generated on account hierarchy level. The underlying condition table contains the account hierarchy as condition table field.
    
    
  • rebate conditions are generated on account level. The underlying condition table contains any condition table field on customer level such as sold to, ship to, bill to party. The account hierarchy is exploded in its members.
    
    
• Trade Promotion created for a target group
  • rebate conditions are generated on target group level. The underlying condition table contains the target group as condition table field.
    
    
  • rebate conditions are generated on account level. The underlying condition table contains any condition table field on customer level such as sold to, ship to, bill to party. The target group is exploded in its members.
    

Rebate Recipient

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

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

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

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

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

Split Criteria

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

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

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

Status Dependencies

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

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

• trade promotion in 'released' status generates the rebate agreement in status 'open'
  
• if the trade promotion gets 'rejected' 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

Rebate Condition Type

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

SAP Customizing Implementation Guide

Customer Relationship Management

Rebate Processing

Set Up Rebate Determination

Create Condition Types

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

Condition Tables

The condition tables are available in the following customizing path:

Customer Relationship Management

Master Data

Conditions and Condition Technique

Condition Technique: Basics

Create Condition Tables

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

Condition Customizing Dependencies

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

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

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

A warning message will be raised:

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

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

An error will be raised:

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

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

An error will be raised:

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

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

This reads the following customizing:

Customer Relationship Management

Master Data

Products

Product Category

Pricing

Assign Field Catalog Fields to Pricing-Relevant Hierarchy

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

If this is not fulfilled an error will be raised:

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

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

An error will be raised:

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

Data Exchange

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

BAdIs

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

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

Additional Information

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

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

No data for condition generation available [CRM_MKTPL_COND_IF 044]

Known Issues

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

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

2101756  Prohibit posting of manual accruals in an ERP Rebate Agreement

2145334  Run time error while closing long term Promotions

2108699  Rebate status is not set while closing Trade Promotion

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

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

2023128  Trade Spend value is not distributed correctly on conditions

1871427  Trade promotion with Target Grp generates redundant rebates

1799381  Planning account hierarchy not checked for rebate relevant

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.

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

Marketing objects are set up with certain master data and are valid during a specified time frame. Changes in master data are not reflected automatically in these objects. If one wants to have these master data changes reflected in his objects, it would be necessary to identify and change manually all active and planned marketing objects which can be a very time consuming and inefficient task, therefore the PMDC report is provided.

The scope of PMDC is to evaluate certain master data changes and to apply these changes to affected trade promotions.

The PMDC report works the following way:

1. Load Trade Promotion
2. Enqueue Trade Promotion - if the trade promotion cannot be locked, the PMDC aborts. The reasons may be different (any other process locks the same trade promotion, TP status does not allow to execute CGCH 'Change attributes' business transaction)
3. Read Product Assignment from Trade Promotion
4. Read Product History according to PMDC parameters
   
5. Performs CCA checks to determine any products to add, delete or change
6. Performs product changes (add, delete or change)
7. Regenerate KPI plan data
8. Regenerate Conditions

Product Assignment

Product Category change

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:

Product 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 detect 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.

Unit of Measure change

The unit of measure may gets changed in the master data for a certain product.

For products getting the UoM changed in the master date there is the following design. The trade promotion has a product assigned with the UoM taken from master data before the product master changed.

If the changed product UoM is still valid for the trade promotions sales data, the PMDC updates the product accordingly.

If the updated product master data is not valid for the trade promotion sales data the product cannot be updated but gets deleted.

This design is also valid for locked products. Since the sales data API won't return any data for locked products the product is supposed to be deleted rather than updated.

Known Issues:

Known issues related to product design in the PMDC report are solved with the following SAP 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

1817606 - PMDC: Design change for products with modified product categories

1780957 - PMDC report deletes products with invalid Unit of Measures

Known issues related to the PMDC log are solved with the following SAP notes:

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

1920673 - PMDC log different when multiple TPMs in non-simulation mode.

1912544 - PMDC different log when report is run in simulation mode.

1895439 - PMDC : Inconsistent log in TEST mode for same TPM

1882547 - Save PMDC execution log for the transaction SLG1

1838417 - PMDC report does not save failure messages in SLG1

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