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

How is the TP currency determined?

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

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

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

CL_CRM_MKTPL_HEADER_ITEM=>DEFAULT_CURRENCY

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

Which currencies can be used in a trade promotions?

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

CL_CRM_MKTPL_HEADER_ITEM=>CHECK_CURRENCY

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

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

Can the TP currency changed?

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

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

The currency change design is controlled by the following method:

CL_CRM_MKTPL_HEADER_ITEM=>IS_CURRENCY_CHANGEABLE

How are decimals considered for currencies?

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

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

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

What to be considered with funds integration?

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

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

CL_CRM_MKTPL_FPLAN_ITEM=>CHECK_CURRENCY

What to be considered with claims integration?

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

Imagine having a trade promotion planned with USD.

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

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

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

CL_CRM_FM_FPO_CURR_CONVERT=>CONVERT_TO_FOREIGN_CURRENCY

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

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

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

2170820 Wrong decimal point for amount on funds assignment block

2106896 Decimal issues in Planning Layouts when working with exceptional currencies

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

2094790 Trade promotion search not showing spend currency values

2073534  Wrong decimal point for amount on Claim Processing Documents

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

1963366  Currency decimal settings not considered in Spend Value Overview AB

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

1817618  TPM versions don't show correct spend values

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

1775791  Settled amounts wrongly displayed for non decimal currencies

1730452  Wrong spend value due to currency conversion

1712649  Spend Value and OI Cap with Currencies like TWD

1650994  Default currency code of Purch Item from parent object

1650481  Issue with exceptional currencies in Product Causals

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

1607017  Handling exceptional currencies in Trade Spends Values

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

2106736 Error messages on invoice claims do not show correct amounts

2096111 Resolution tree root node with wrong currency format

2073534 Wrong decimal point for amount on Claim Processing Documents

1837253 Currency conversion issue during settlmenet

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

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:

2170820  Wrong decimal point for amount on funds assignment block

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

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

Funds Plan

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

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

Funds

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

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

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

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

TP Fund Association

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

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

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

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

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

In case more products or more expense types are used in the trade promotion the number of different funds returned depends on the fund association level.

Fund Association Levels

Funds can be associated at the following levels

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

Fund Determination

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

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

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

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

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

Fund Usages

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

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

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

Availability Check

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

Fund Postings

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

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

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

Fund Posting Transactions

There are the following different posting transactions available.

• Reserve Budget
  • triggered from changing the trade promotion status
  • holds PRERESERVED '20' and RESERVED '21' value category postings
• Update Claim
  • triggered by approving claim
  • holds APPROVEDCLAIM '32' and RELEASEDTOSETTLE '40' value category postings
• Settle Claim
  • triggered by CRM claim settlement
  • holds SETTLED '41', RELEASEDTOSETTLE '40' and EXPENSED '44' value category postings
• External Settlement
  • holds EXTERNALLYSETTLED '42', SETTLED '41' and EXPENSED '44' value category postings
• Balance Fund Usage
  • triggered by any TP status that balances the fund usage, or on manually balancing the fund usage
  • holds UNCONSUMEDBUDGET '15', ACCRUALBALANCE '48' and EXPENSED '44' value category postings

Fund Posting Value Categories

Some of the fund posting value categories are calculated based on some other fund posting key figures.

• Unconsumed budget: The UNCONSUMEDBUDGET '15' value category holds the still available budget for a fund usage (Budget - Actuals)
  • calculated with formula: unconsumed budget = reserved - (approved claim - expired approved claim + externally settled).

Accruals

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

There are two types of Accruals:

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

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

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

Accruals can be calculated based on the following calculation methods:

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

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

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

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

• RCRM_FM_ACL_ACCRUAL_UPLOAD_DIS
  
  The report reads table S060 in ERP using the Condition record number KNUMH and returns the statistics values to CRM for generating the posting. In case there are no values in S060 table for the affected conditions type the same needs to be checked from SD side. A known issue is solved with the following note:
  
  1491854  Condition update: Incorrect values in copied documents

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

• RCRM_MKTPL_TPM_DISC_FRGOODS

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

• RCRM_MKTPL_TPM_EXT_ACCRUALS

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

• CRM accruals
  
• ERP accruals
  
• Off-invoice scenario or Free goods scenario
  

When balancing a fund usage there is the following design based on the accruals profile - depending on the accrual profile on the fund usage has the external accrual set there is the following design:

• CRM accruals
  When the accruals are handled in CRM the accruals are balanced in CRM when balancing the fund usage.
• External accruals
  When the accruals are handled in ERP the promotional rebates are built and reversed in ERP. The accruals are uploaded to CRM using the external accruals load report. Since the accruals are reversed at the time the rebate agreement is finalized in ERP, there is no need not reverse the accrual balance in CRM when the fund usage is balanced. The accrual reversal should be brought to CRM using external accruals load.

Further useful information about accruals is available in the following document:

Accrual creation(calculation) by CRM fund management

Trade Promotion Status dependencies

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

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

Deleting Trade Spends or Products

Deleting products or trade spend is not allowed for released trade promotions. However for approved trade promotions it is allowed. Since for approved trade promotions there may be fund usages with budget reservation posting available, there is the following design:

• deleting products: the prereserved budget of the deleted product is released again, and added to the prereserved budget of the remaining funds. In case there are no further funds for the postings - this is the case if one single product is used and gets deleted - the prereserved amount gets released.
• deleting trade spends: since the trade spend is the main driver for the fund usages, deleting the trade spend is balancing the fund usage. Any prereserved amount gets released. In case the funds integration is set up a way that the fund usage contains reserved amount this is not released again, but the not used budget is posted to the unconsumed budget. Reserving the amount should happen on releasing the trade promotion. In that case deleting the trade spend is not longer allowed.

Customizing

Fund Plans and Funds

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

Customer Relationship Management

Funds Management

Funds Plans and Funds

This customizing in not trade promotion specific.

TP Funds Integration

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

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Funds Integration

Define Settings for Funds Integration

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

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

Status Driven Events

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

Customer Relationship Management

Trade Promotion Management

Basic Data

Define Status-Driven Events

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

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

1521715  Warning messages for certain Status-Driven Events

1308738  Event handler setup for TPM Fund Integration

Fund Determination

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

Customer Relationship Management

Funds Management

Fund Determination

Define Fund Determination Profiles

Availability Control (AVC)

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

Customer Relationship Management

Funds Management

Availability Control (AVC)

Define Availability Control (AVC) Profiles

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

Accruals

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

Customer Relationship Management

Funds Management

Accruals

Define Accrual Profiles

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

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

In CRM the following steps are required:

A subscription for the replication object CRM_FM_EXTDATA from transaction SMOEAC needs to be maintained under the publication 'Enhanced Rebates

Data Transfer'. The subscription should be created for the connected ERP site.

If there are duplicate active versions of publication 'Enhanced Rebates Data Transfer' the following note needs to be implemented:

1462672   Duplicate publilcations for Enhanced Rebates Data Transfer

Then the replication objects services for CRM_FM_EXTDATA needs to be generated from transaction SMOGGEN.

In transaction R3AC1 the adapter object CRM_FM_ENH_REB the filters need to be in sync with ERP.

On ERP side an entry in table CRMOBJECT need to be available:

Common Issues

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

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

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

          1681596  Inconsistent fund postings

• CRM_FM_FU_CORR_BALANCE_ACL: This report is used to create the balance fund usage posting in case there are balanced fund usages without having the fund posting. Further information on the report is available in the following note:
  
  1577209  Correction of possitive accruals on balanced fund usage

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

2170820 Wrong decimal point for amount on funds assignment block

2168095  Fund usages get erroneously copied while copying a trade promotion

2111673  Fund posting from none existing fund usage

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

2093937  Error on finalize posting in case of missing accrual profile

2090209  Double clearing the reserved amount of a fund usage

2094576  Wrong posting against logically deleted items

2064326  Wrong Accruals after change of transfer date

2058494  Fund posting not cancelled upon document cancellation

2031014  Accrual items wrongly created or no accrual postings get created

2021587  Double reserved or pre-reserved amount posted

1989720  Performance improvement - Funds management reports

1974922  Wrong fund posting upon deletion of a trade spend from a trade promotion

1971614  TP with Funds: AVC error when TP status is set to rejected

1962993  TPM: Fund posting bdocs failing when accruals are handled in ERP

1947138  Deleted fund usage item accrual not reversed

1937330  No fund posting created on fund usage balancing

1650841  Discount Load Program issues error - No valid currency

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

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.
  With implementing the BAdI the TIMEZONE_CREATED from the trade promotion can then be used as CONVERSION_TIMEZONE. With this approach user time zones are not considered, but the trade promotion is simulated to be processed in the same time zone.

A trade promotion is created in CET time zone and the dates are stored accordingly:

When now a user with any different user time zone access the trade promotion it may happen that the trade promotion has different validity dates since the time stamp is converted to the user time zone:

Therefore it is recommended to user the fixed time zone conversion customizing if the trade promotion is supposed to be accessed across different time zones.

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

2003542  Users in different time zones accessing Trade Promotions causes incorrect behaviour with rebate agreements and condition records.

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.

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

The mass change scenario is available for campaigns as well. The process is the same.

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

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

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

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

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

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

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

Attributes available for Mass Change

System provides the following attributes for the mass change scenario:

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

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

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

Customer Relationship Management

Trade Promotion Management

Activate Attributes for Mass Copy and Change

Parallel Processing

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

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

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Parallel Processing

Define Settings for Parallel Processing

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

This is documented in the following SAP note:

1582214  Mass Update Fails on Large Record Sets

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

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

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Parallel Processing

Business Add-Ins (BAdIs)

BAdI: Job Processing Enhancements

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

Known Issues

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

Product Issues:

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

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

Condition and Rebate Issues:

1883508  TPM Condition Generation during mass processing

1867183  Conditions not generated during mass processing

1819337  Mass Change Status doesn't generate conditions for all TPM

1761463  Mass change: additional save of the Trade promotion

Date Shift Issues:

2144663  Mass Copy or Change a TPM and date time shift in months does not work

1912420  Changing all dates with mass copy or mass change

BPS Planning Issues:

2024499  Planning layout contains the old product replaced by mass change

2007156  Planning layout contains the old product replaced by mass change

Campaign Mass Change related Issues:

2137644  Mass Change for priority, tactic and objective attributes of campaigns doesn't work if run in background

System Resources Issues:

1807935  Success message when mass change operation fails

1792954  Issue msg when Mass Change fails for lack of ressources

1582214  Mass Update Fails on Large Record Sets

General Issues:

2190918  Locks are kept after mass change of marketing projects

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

1916291  Mass change or mass copy popup has invalid status behavior

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

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
  
  For product categories the UOM is validated against the single product assigned to the product category. The product category UOM needs to be available for at least 1 product assigned to the category.

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

In case the check for the product assignment is to restricitive the same can be turned off using a BAdI approach. The BAdI CRM_MKTPL_OL_ASG interface method CHANGE_CHECK_MODE can be used to skip the check.

Using method CHANGE_CHECK_MODE the CHECK_MODE needs to be set to 'N' for the product assignment.

This is enabled with the following note:

2193438  No Check (CHECK_MODE = 'N') scenario is not handled in method CHECK of class CL_CRM_MKTGS_ASG_COLLECTION

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:

Issues related to product checks:

2193438  No Check (CHECK_MODE = 'N') scenario is not handled in method CHECK of class CL_CRM_MKTGS_ASG_COLLECTION

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.

1919259  Trade Promotion: Territory check on Sales Category fails

Performance issues:

2023700  Performance issue when checking products consistency

Issues related to conditions:

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

1983655  Exclusion of Product  Category does not delete campaign determination records

1443903  Product Exclude Flag does not delete CD Conditions

Issues with product search:

1978393  Products with a sales category assigned are not found

1899400  Search Criteria for product segment incorrect in TPM

Issues with BPS Planning:

2185630  The unit of measure is wrong for product categories or groups of a trade promotion

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.

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 having product effective dates, chaging the trade promotion date is not changing the Pr condition dates. Those are still created based on the product effective dates.

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:

Retroactive Trade Spends

A past dated trade promotion (with having the end date earlier than today's date) has so called retroactive trade spends assigned. Depending on the customizing it must be allowed to further edit those trade spends. There is the following design:

There is a check if off-invoice trade spends exist in the trade promotion. When off-invoice trade spends with dates in the past already exist, it is not allowed to add the following:

• Off-invoice trade spends with dates in the past
• Effective dates for products that are in the past when off-invoice trade spends with dates in the past exist

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.

Retroactive Trade Spends

The following customizing enables for trade promotions created in a specific sales area:

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Trade Spends

Define Sales Areas for Off-Invoice Check

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:

Conditions cannot be generated due to overlaping condition records

Date Shift not working

There is an issue happening for long term trade promotions - for trade promotions without having campaign determination records and without having the campaign guid available as field in the underlying condition table. Whenever there are similar conditions existing that were deleted earlier (technically got the deletion flag) conditions cannot be generated properly on releasing the newly created trade promotion, nor on shifting the trade promotion dates. The reason is an overlap issue with the existing deleted condition records.

The deleted condition records may come from old 'finished' ttrade promotions. Those deleted records should not be considered in the overlap checks.

The issue can be solved with implementing BAdI /SAPCND/MNT_CHK_R3C.

Using the following filter settings:

Appl.     = CRM

Usages    = PR

Cond.Type = *

Table     = *

MaintCont = 'CAMPAIGN'

The interface method PREVENT_PROCESSING_DELETED_WSI needs to be implemented - the following can be taken as a template:

--------------------------

* By default method was executed and everything was ok

 
e_was_executed = ctcus_true.

e_result       = 0.

* TP excludes deleted condition records from processing

* Overlap check will not take deleted records into consideration

e_is_processing_allowed = ctcus_false.

---------------------------

Error on generating conditions

2195430  Not able to generate conditions: infinite loop

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

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

1901912  Condition generation errors

Error on changing TP status

2145334  Run time error while closing long term Promotions

Error on shifting TP dates

2064219  In Trade Promotion, changing the Effective To date of a product category change the 'TO' date of all product category condition records

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

1644003  Cannot change End Date of a released Off-Invoice Promotion

Amount issues with BI rates:

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

Decimal issues in BPS Planning for CRM Marketing Objects

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.

IAfter the installation of the required software component for the Marketing Executive Dashboard in SAP hybris Marketing, two additional steps must be carried out:

1. You have to import the configuration file for the SAP Smart Business, executive edition. In this document you can find the necessary file for the dashboard configuration. To import the file into your system please follow the description in the Installation guide (help.sap.com/mkt -> Installation) of Smart Business, executive edition, which can be found in the SAP Help Portal.

2. For the KPIs Brand Awareness, Leads, Opportunities, Pipeline Acceleration, Market Share, Net Promoter Score, Sales Pipeline, Converted Pipeline, Revenue, Return on Marketing Investment, Sales Forecast, Web Visits, Web Downloads the underlying business data must be uploaded from external sources. This can be achieved by using CSV-files in a certain format. In this document one can find files for examples of that business data. These files can used to set up a demo or test-environment, but cannot be used for productive use .
To do so, please follow the description in the Installation and/or Application Operations-Guide which can be found on the help portal http://help.sap.com/mkt#section2.

Note: The configuration file as well as the sample data files can be downloaded from this link.

1) Brief Background

2) Most Frequent  Accrual Related issues during Month end

3) Proactive steps to handle such issues.

1) Background :

Fig-1

Trade promotions are incentives paid by the Consumer Product Manufacturers to Retailers/shops for merchandizing support.

Above Fig-1 shows , Overall Trade Promotion Management process.

In SAP CRM, Accruals are calculated for particular Trade promotion based on various “spend types” like Display, BB Scan etc.

Manufacturers of products (retails), gives lot of promotional schemes to increase sales, get growth volume, launch new products etc.

Retailers (Shops) gives sales orders to get possible discounts and to get promotional scheme benefit. During month end lot of such orders are placed by the customers to the sales persons of Manufacturer.

It is observed that , the volume of such sales orders are relatively higher during end of scheme, as retailers are keen to get qualified for particular discount or promotional fees. ( Ref. Fig.2 )

Fig.2

1)      Possible issues During Month end.

We are referring here, a typical standard SAP CRM-TPM Landscape, where SAP CRM is integrated with Backend ECC System.

In typical post-go-live support scenario, it has been observed that, there is increase in number of Sales order from Retailers either during month end or end of Promotion period.

Issues frequently occurs for various Trade promotions,

1)      - Accruals not calculated for reserved amounts

2)      - Accruals posting not done to ECC

Accrual calculations are very important as it is the amount retailer will get, for participating the trade promotion for particular period.

Since, retailers are placing lot of sales orders during month end, they want to utilize the Accrual amount for trade by putting claim for accrual amount.

Fig.3

Fig.3 shows , Accruals calculations are very important to various stake holders .

1)     3) Proactive steps to handle such issues:

Below are some proactive steps taken by SAP CRM admin /functional.

i.                     In order to accrue the amount properly, we need to run/execute following programs in sequence at the end of business hours. It can be achieved by scheduling the background jobs in proper sequence. For best results, work out these steps every day, for 3 days till actual month end date.

Fig.4

ii. Check if all jobs are executed successfully without any errors.

iii.Please ensure after one job is executed, then only next subsequent job is executed as per sequence given above.

Below diagram ( Fig 5 ) shows Accrual is calculated properly

Fig.5.

After executing these jobs successfully, check in SAP CRM, if there are any BDOC errors  -

• SMW01: to find any BDoc in error state /successfully processed
• SMQ1: Out bound Queue in SAP CRM
• SMQ2: In-Bound Queue in SAP CRM

It has been observed that, by following steps above mentioned, the number of issues related to accrual are reduced significantly during month end period, in post go live support project.

Disclaimer

 

This tutorial is intended as a guide for the creation of demo/test data only. The sample script provided is not intended for use in a productive system.

Purpose

The main purpose of this document is to show you how demo or test data can be provided for SAP hybris Marketing Data Management 1511 and up.

This tutorial explains one way of collecting tweets from Twitter based on a search term so that they can be used in the Sentiment Engagement workset of SAP hybris Marketing Data Management. A Python script for harvesting is executed from SAP HANA Studio (alternatively, you can use an Eclipse IDE such as Aptana Studio). The script inserts the collected tweets directly into interactions using an Odata service. If you run the script with the default settings, it will harvest 100 posts in one run for a given search term. However, you can change the script settings to retrieve more data per run.

To run the script, you will need to make a few customizing and configuration settings in order to use the PyDev plug-in in SAP HANA studio.

Prerequisites

Make sure that the following prerequisites are met before you start out:

• Installation of SAP HANA studio

       Install SAP HANA studio

Please check SAP help file https://help.sap.com/hana/SAP_HANA_Studio_Installation_Update_Guide_en.pdf for more information about SAP HANA studio installation.

Tested with SAP HANA studio 64bit with minimal Version: 1.0.7200 and SAP HANA client 64bit, Microsoft Windows 7, 64 bit version.

• Download Python that contains SSL Library.
  Download Python fromhttp://www.python.org/downloadand install it. The recommended version is Python 2.7.8. This was tested using 64bit Windows installer.

• Application Registration in Twitter
  If you don't already have them, register your application and get your consumer key and consumer secret as follows:
  1. Open the URL: https://apps.twitter.com/ and register your application.
  2. Note down the consumer key and the consumer secret.

• User and Role

        To import the tweets using Odata service, the SAP hybris Marketing user needs the role SAP_CEI_ECOMMERCE_INTEGRATION.

  Setting up the Editor to Run the File

     Carry out the following steps:

1. Install Pydev plugin to use Python IDE for Eclipse
   The preferred method is to use the Eclipse IDE from SAP HANA studio. To be able to run the python script, you first need to install the Pydev plugin in SAP HANA studio:
   1. Open SAP HANA studio, click Help on menu tab and select Install New Software...
   2. Click the button Add... and enter the following information:
      
      • Name: pydev
      • Location : http://pydev.org/updates
   3. Select the settings as shown in this screenshot:  
      
      
   4. Press Next twice
   5. Accept the license agreements, then press Finish.
   6. Restart SAP HANA studio.
2. Configure the Python Interpreter
   In SAP HANA studio, carry out the following steps:
   1. Select the menu entries Window -> Preferences.
   2. Select PyDev -> Interpreters -> Python Interpreter.
   3. Click New... button, type in an Interpreter Name. Enter in field Interpreter Executable, the following executable file from the newly installed python location  C:\....\Python\Python.exe. Press ok twice.
3. Create a Python project
   In SAP HANA studio, carry out the following steps:
   1. Click File -> New -> Project..., then select Pydev project.
   2. Type in a project name(example: TWITTER_DATA_COLLECTION), then press Finish.
   3. Right-click on your project. Click New -> File, then type your file name (for example: data_harvest_tweets.py). Press Finish.
4. Create an external library path
   In SAP HANA studio, carry out the following steps:
   1. Right-click on your project, select properties and Pydev-PYTHONPATH.
   2. Select the tab External Libraries, then click on Add source folder C:\...........\Python\Lib.
   3. Press Apply, then OK.
      
5. Import the script
   1. Copy the  Python script which is available at the end of this Document.
   2. In SAP HANA Studio,Open your newly created Python file from your project and paste the script.
   3. Click Save.

        Alternatively you can save the python script with .py extension in your file location and import this file to your project.

Customizing and Running the Script

1) Customizing and User Input for Python Script

1. In your Eclipse editor, open the file data_harvest_tweets.py and maintain the following parameter in the CUSTOM PARAMETERS section of the script:
   
   
2. Save the file.
   Feel free to adopt the search query and its options to your needs. Now you are ready to run the script.

2) Executing the Script

1. Run the script from your editor.
   
   
2. Enter the search term(s).
   Now you will receive data from Twitter, as you can see in your Eclipse IDE.
   The script can be run multiple times: It can extract data based on a search term for up to the last 7 days.

        You have now set up harvesting.

REFERENCES:

https://help.sap.com/hana/SAP_HANA_Studio_Installation_Update_Guide_en.pdf

https://apps.twitter.com/

https://dev.twitter.com/docs/using-search

http://scn.sap.com/community/developer-center/hana/blog/2012/06/08/sap-hana-and-python-yes-sir

http://help.sap.com/saphelp_hanaplatform/helpdata/en/6f/c3f05ba62b49859377c0f28cdd1513/content.htm?frameset=/en/6f/c3f05ba62b49859377c0f28cdd1513/frameset.htm&current_toc=/en/00/0ca1e3486640ef8b884cdf1a050fbb/plain.htm&node_id=347

#Python Script starts here
import urllib2;
import urllib;
import sys;
import json;
import time;
import binascii;
import copy;
import calendar;
#===============================================================================
#     CUSTOM PARAMETERS:
#===============================================================================
# 1. Target System
username = 'XXX'    # hybris Marketing user
password = 'XXX'   # password for your user
cuan_url = "XXX"
# EXAMPLE: cuan_url = "https://my.system:8080/sap/opu/odata/sap/CUAN_IMPORT_SRV"
# 2. Twitter OAuth Tokens
# https://apps.twitter.com/app/new (register your application to get an access tokens) 
c_key        = 'XXX'  # CONSUMER_KEY
c_sec        = 'XXX'  # CONSUMER_SECRET
# 3. Proxy settings
proxy = ''
# EXAMPLE: proxy = 'http://proxy:8080'
# proxy = ''
# 4. Additional settings
language = "en"             # Tweet language (ISO 639-1 language code)
socialmediachannel = 'TW'   # Social media channel name like 'TW'.                            # You can enter Maximum 3 characters,                            # this has to be in sync with SCI customizing
#===============================================================================
#     PREDEFINED DATA STRUCTURES:
#===============================================================================
contact_prefab = {    "Id": "",    "FullName": "",    "Timestamp": "",    "Facets": [],    "ImageURI": ""
}
facet_prefab = {    "Id": "",    "IdOrigin": socialmediachannel
}
interaction_prefab = {    "CommunicationMedium": socialmediachannel,    "ContactId": "",    "ContactIdOrigin": socialmediachannel,    "ContentData": "",    "ContentTitle": "",    "InteractionType" : "SOCIAL_POSTING",    "Timestamp": "",    "SourceObjectId" : "",    "SourceObjectType" : "",    "SourceSystemId" : "",    "SourceSystemType" : "",    "Tags": []
}
tag_prefab = {    "TagType": "SearchTerm",    "Tag": ""
}
payload_prefab = {    "Id": "",    "Timestamp": "",    "UserName": "USER",    "SourceSystemType": "EXT",    "SourceSystemId": "PYTHON",    "Interactions": [],    "Contacts": []
}
#===============================================================================
#     UTILITY FUNCTIONS:
#===============================================================================
# Generate the Bearer Token for use in the Authorization Header when making
# calls to the Twitter API. This is done via Application-only authentication,
# see 'https://dev.twitter.com/oauth/application-only' for more details
def generateTwitterHeader():    api_url = "https://api.twitter.com/oauth2/token";    # step 1. generate bearer token credential    bearer_token_credential =  "%s:%s" % (c_key, c_sec);    # step 2. generate Base64 encoded credential    base64_bearer_token_credential = binascii.b2a_base64(bearer_token_credential)[:-1];    # step 3. connect    bearer_token = "";    if proxy is not None and proxy != '':        handler = urllib2.ProxyHandler({'http': proxy, 'https': proxy});    try:        opener = urllib2.build_opener(handler);        opener.addheaders = [ ('Content-Type', "application/x-www-form-urlencoded;charset=UTF-8"),                              ('Authorization', "Basic %s" % base64_bearer_token_credential)];           data = opener.open(api_url, data="grant_type=client_credentials").read();        # step 5. parse json string        json_data = json.loads(data, encoding="utf-8");        bearer_token = json_data["access_token"];    except:        print "[ERROR]\n%s" % ("\n".join("%s" % info for info in sys.exc_info()));        return None;    return "Bearer %s" % bearer_token;
# URL Encode a String
def escapeParameter(text):    return urllib.quote(str(text), safe="~");
# Extract all "set-cookie" headers from a given urllib2 response Info end create
# a single String containing all those Cookies. This is done using a variety of
# String operations. The Cookie String can later be send as a Cookie Header
def extractCookies(info):    final_cookie = "";    cookie_list = info.getallmatchingheaders("set-cookie");    for i in range(0, len(cookie_list)):        cookie_str = cookie_list[i].split(": ", 1)[1];        final_cookie += cookie_str.split(";", 1)[0];        if i < (len(cookie_list) - 1):            final_cookie += "; ";    return final_cookie;
# Extract the value of the 'x-csrf-token' Header in the given urllib2 response
# Info
def extractCSRFToken(info):    token_str = info.getfirstmatchingheader("x-csrf-token")[0];    return token_str.split(": ", 1)[1][:-2];
# Convert the timestamp returned by Twitter to a CUAN_IMPORT friendly timestamp
def twitterToCUANTimestamp(string):    t =  int( calendar.timegm(time.strptime(string, "%a %b %d %H:%M:%S +0000 %Y")) * 1000);    return intToCUANTimestamp(t);
# Wrap a given timestamp (can be an Integer)
def intToCUANTimestamp(t):    return "/Date(" + str(t) + ")/";
#===============================================================================
#     MAIN PROGRAM LOGIC:
#===============================================================================
# Prompt the user to Input a search query
while True:    resp = raw_input("Please enter your search term:\n")    if resp == "":        resp = raw_input('Enter your search term or "stop" to exit:\n')    if resp == 'stop':        sys.exit();    if len(resp) > 0:        break;    if not resp:        continue
search_term = resp;
search_url = "https://api.twitter.com/1.1/search/tweets.json"; 
apiurl = "https://api.twitter.com/oauth2/token";
# Setup to make a call to the Twitter API with the given query
params = [("q", search_term),("count", "100"),("lang", language),("result_type", "recent")];
handler = urllib2.BaseHandler();
header = generateTwitterHeader();
# Handle Proxy settings
if proxy is not None and proxy != '':    handler = urllib2.ProxyHandler({'http': proxy, 'https': proxy});
opener = urllib2.build_opener(handler);
opener.addheaders = [('Authorization', header)];
http_url = ("%s?%s") % (search_url, "&".join(['%s=%s' % (param, escapeParameter(value)) for (param, value) in params]));
# Call the API and convert the returned JSON Object into a Python Object
data = opener.open(http_url, data=None).read();
json_data_tweets = json.loads(data);  
# Construct the Payload for the CUAN_IMPORT service
replication_created_at = intToCUANTimestamp(int(time.time()));
payload = copy.deepcopy(payload_prefab);
payload["Timestamp"] = replication_created_at;
contact_ids = [];  
user_count = 0;
tweet_count = 0;  
# Process Tweets
for tweet in json_data_tweets["statuses"]:    # Extract information    tweet_id = tweet['id'];    from_user_lang = tweet['lang'];    id_str = tweet['id_str'];    user = tweet['user'];    from_user_id = user['id'];    from_screen_name = user['screen_name'];    from_user_name = user['name'];    userProfileLink = 'https://twitter.com/%s' % (from_screen_name);     socialPostLink = 'https://twitter.com/%s/status/%s' % (from_user_id, id_str);     profile_image_url = user['profile_image_url'];    created_at = tweet['created_at'];    if created_at is None:        continue;    created_at = twitterToCUANTimestamp(created_at);    user_created_at = twitterToCUANTimestamp(user['created_at']);    text = tweet['text'].encode('utf-8')    text = text.replace('\n', '');    socialmediachannel = socialmediachannel;    if len(text) == 0:        continue;      # Create a contact for every Tweet (only if it does not exist already) and add a facet    if not from_user_id in contact_ids:        contact_ids.append(from_user_id);        contact = copy.deepcopy(contact_prefab);        contact["Id"] = str(from_user_id);        contact["FullName"] = from_user_name;        contact["Timestamp"] = user_created_at;        contact["ImageURI"] =  profile_image_url;              facet = copy.deepcopy(facet_prefab);        facet["Id"] = from_screen_name;        facet["IdOrigin"] = socialmediachannel;        contact["Facets"] = [facet];        payload["Contacts"].append(contact);        user_count = user_count + 1;      # Create an interaction for every Tweet    interaction = copy.deepcopy(interaction_prefab);    interaction["ContactId"] = from_screen_name;    interaction["ContentData"] = text;    interaction["Timestamp"] = created_at;    interaction["SourceObjectId"] = str(tweet_id);    interaction["SourceDataUrl"] = socialPostLink;      # Create a tag for the search term and add it to the interaction    tag = copy.deepcopy(tag_prefab);    tag["Tag"] = search_term;    interaction["Tags"].append(tag);      tweet_count = tweet_count + 1;      payload["Interactions"].append(interaction);  
# Convert the Payload to JSON
json_payload = json.dumps(payload);
# Create HTTP Basic Auth Header
cuan_user_creds = binascii.b2a_base64(username + ":" + password)[:-1];
user_auth = "Basic %s" % cuan_user_creds;
# Fetch a CSRF Token and store the Cookies of the response (for later use)
opener = urllib2.build_opener();
opener.addheaders = [('x-csrf-token', "fetch"), ("Authorization", user_auth)];
response = opener.open(cuan_url);
csrf_token = extractCSRFToken(response.info());
cookies = extractCookies(response.info());
# Create a POST request and execute it. The Request will contain the payload,
# the previously fetched CSRF Token and the Cookies
opener.addheaders = [('x-csrf-token', csrf_token), ("Authorization", user_auth), ("Cookie", cookies)]; #, ("Cookie", cookies)
import_headers_url = cuan_url + ("/" if cuan_url[-1] != "/" else "") + "ImportHeaders";
data = json.dumps(payload);
req = urllib2.Request(import_headers_url, data, headers = {    "Content-Type": "application/json",    "Content-Length": len(data)
});
response = None;
try:    response = opener.open(req);
except urllib2.HTTPError as e:    # Something went wrong. Display information to the user and exit    error_message = e.read()    print "An Error occurred:";    print error_message;    sys.exit();
# Success
print "Imported %d tweets by %d users" % (tweet_count, user_count);

EXTERNAL LIST MANAGEMENT

For business scenarios there is a deal with large amounts of data, customers require solutions that are scalable and robust. This is vital especially in the case of marketing where newsletters and special campaigns are addressed to millions of customers through communication channels like e-mail or SMS. ELM serves for this purpose.

External List Management is used to pull data from external sources such as Flat files (text, csv) and upload the same in System for Creation of Business Partners or Marketing Prospects, Activities, Leads, and Target Groups.

The Steps involved in ELM are:

1. Get the data from the data source.
2. Map the data as per the requirement
3. Create Business Partner or Business Transactions

The data comes from the different source with different formats. It is categorized and mapped with the corresponding fields. Therefore, before uploading we need to know the headers to which it is mapped. Hence mapping format comes into picture.

MAPPING FORMAT:

The use of mapping format is to create a header for the data that is uploaded in the ELM.

First, let us see the WebUI part and then move on to the functionality and the code involved.

Go to Transaction code “CRM_UI” in SAP-GUI
Choose “Marketing PROF” in the business role.
Select “Marketing” from the left panel
Choose “Create Mapping Format”.

The above image is the page from creating the Mapping Format.

The field “ID” is mandatory, in some systems it has to start with ‘0’ (optional).

The next field “Mapping Format” gives the description of it.

The field “Filter Criterion” tells how the field names are categorized.

The field “Category” helps users to find products or fields, which is most, related to their interests.

The different types of category available are:

Addresses:

An address is a contact address. It consists of address-relevant data about the person (for example, the first and last name) or the organization (for example, the company name), and the postal address (for example, the postal code and city).

Activity:

The time during the CRM lifecycle. The business activities keep a record of any interaction that has taken place between your company and its customers.
For more:  http://help.sap.com/saphelp_crm50/helpdata/en/57/e90d3888a11c10e10000009b38f8cf/frameset.htm

Leads:

A lead is a business transaction which describes, stores, updates, and manages the potential interest of (and interaction with) a business partner over a certain timeframe. In other words, a lead represents a potential chance to make business.
For more: http://help.sap.com/saphelp_crm50/helpdata/en/42/b66d0ad5951d65e10000000a1553f6/frameset.htm

Marketing prospects:

If marketing attributes are need in the ELM, then MP comes into picture. A marketing prospect is a potential customer. Marketing prospect is a new category of mapping format added to support the upload of large amounts (high-volume) of address data in an efficient manner.
For more: http://scn.sap.com/community/crm/marketing/blog/2014/01/03/use-marketing-prospect-or-business-partner-for-storing-prospect-data-in-sap-crm

Note: The combination of above categories display all their fields under Available Target Fields.

In this mapping format, we can also create some fixed values or constants for certain fields.

For example, if the person who involves in this activity is ‘Male’, then each time in the file we do not need to specify that it is male. We can assign it as a constant value. You use the mapping rule "Constant" to assign a constant value to a field.

All mapped records will then get the value you enter in the Constant field, irrespective of the field's original value in the external list.

Select the row for which you need the constant.
Click on the “Add Mapping Rule”.
Select “Constant” under the Mapping Rule.
Assign the constant value and click on back button, which is on the left.

You use the mapping rule "Values" to assign certain values to a mapped field.

You use the mapping rule "Code" to maintain ABAP code for mapping fields that need data or value conversion before mapping.

Finally once the constants or values or code is applied the Mapping Format page looks like this (below).

Functionalities involved in Mapping Format:

Once the mapping format is created, each and every unit(like fields, constants, codes, etc…) have GUID which is seen in the package “CRM_MKTLIST_MAPPING_DESIGN”.

Once the mapping format is created, the following table are affected:

• CRMD_MKTLIST_MA [Marketing attributes] >>> Affected when there is “Marketing Attributes” in the ‘Filter Criterion’.
• CRMD_MKTLIST_MF [Mapping format] >>> Contains the fields name and the position of the field name.
• CRMD_MKTLIST_MH [Mapping Header] >>> Holds description, tells about the type of format
• CRMD_MKTLIST_MS [Mapping survey] >>> If there is any Questionaire purpose
• CRMD_MKTLIST_MT [Mapping Header Description] >>> Same as MH, but describes about the language.
• CRMD_MKTLIST_MV [Mapping Value] >>>  for values assigning.
• 
  

Let us consider the following example:

A mapping format (ID: 0ARA0) [in AG3 system] is created. Now let us see what are the tables affected on creation of this format.

Once the Mapping format is created, its details (like Mapping format ID, Description, format type) are stored in the CRMD_MKTLIST_MH table and a GUID is created for this. This is the starting point for us to trace the entire case.

With the help of Format GUID, it is easy to find what the fields associated with it.

The fields are found in the table CRMD_MKTLIST_MF. The “Position_Source” in this table tells at which position the field is located.

In the mapping format, which we took as example, contains Marketing Attributes (MA), so the table CRMD_MKTLIST_MA is also registering this activity.

Similarly, if the mapping formats contains any Questionnaire or survey question, CRMD_MKTLIST_MS will be reflected.

The table CRMD_MKTLIST_MT is same as the CRMD_MKTLIST_MH but the extra thing it has is the language.

Let us assign some values to the mapping format for the field “TITLE”.

The table CRMD_MKTLIST_MV stores these values.

External List Management

In short, External List Management involves procuring external data, defining mapping formats, checking and preparing the data, updating existing data, creating business partners, creating marketing prospects, using these business partners and marketing prospects in marketing campaigns, and analyzing (reporting) the methods used.

The data from external providers could include information on:

• Business partner and marketing prospect addresses
• Marketing attributes of business partners and marketing prospects
• Business transactions-related information, such as activities and leads
• Survey details

Implement Workflow Customizing

Before you go to ELM step you need to go to SWU3 (T-code) for automatic Workflow customizing and make proper settings.

You need to go to PFTC and open WS14000029 then go to Workflow builder then go to its Basic Data and in Agent assignment Task you need to check “General Task”.

Understanding WebUI

The field “ID” is mandatory.

The field “External List Origin” tells from whom the data is taken or collected.

The field “External List Type” tells how the data is collected the data either created or rented or bought.

You can also use the External List for certain number of days by specifying the date in field “Permitted End-of-Use”.

The field “Permitted No. of Uses” tells how many times the External List can be used.

The next field is “Mapping Format”, which describes which type of mapping format you are going to use. (Either for creating Business Partners or Business Transactions).

The “Delimiter” is a character used to specify the boundary between separate, independent regions in plain text or other data streams. The commonly used delimiters are: comma, semicolon, tabulator. But the user can also use any delimiter by choosing the option “other characters”.

Then, if the Mapping Format is of type “Address”, the process steps shown are:

If it is of type “Marketing Prospects”,

If it is of type “Activity” or “Lead”,

If it is of type “Addresses and Activity” or “Addresses and Lead”, the responsible steps are combined.

Read File: This will read the data from the file and store the data in the CRM system

Map Data: This will start mapping the data from the file using the map that you created in the the system to the BP information

Maintain Business Partner: This will Create BP if the mapping format is meant for creating a new ID to the person or Maintain the BP information if BP already existing.

Create Marketing Prospects: Similar to BP Creation, involved when Mapping format is concerned with marketing prospects.

Create Business Transactions: This will create leads or activities when creating or uploading the BP information.

Check for Duplicates: The previously mapped data is read from the tables holding data and checked.

Check for Postal Correctness: You check the address data for postal correctness. The system scans through the address data and if the postal data is found to be incorrect or incomplete, the data is marked as erroneous and not used to create business partners.

Once the file is uploaded, the Scheduling must be set to either “Immediately” (if the process wants to run at once) or “Date & Time” (if the process wants to run on particular date and time).

Once all the process are done, the resulting page is shown below:

Delete list in CRM:

The user marks the step for the deletion of the list, gives a start date / time and saves the list. A workflow is started that processes the data.

Understanding the Tables

As already stated, for each unit a GUID is created. The below table diagram shows where the various GUID’s are stored.

The above example is taken for the demonstration.

The table CRMD_MKTLIST_H contains the GUID for the External List, which is said as LIST_GUID, which represents the whole date that is uploaded in ELM.

The table CRMD_MKTLIST_PH contains the GUID for Package. (Here, the package is collection of Mapping format ID, ELM ID, Target Group, Separator and the file that is uploaded)

The table CRMD_MKTLIST_S contains the steps that are done during ELM process step and the status of each step.

The table CRMD_MKTLIST_I contains the Item GUID for the Business Partner for Person, Organization. Moreover, flag for Postal Check and the Duplicate Check is set in this table.

The table CRMD_MKTLIST_T contains the text language of ELM.

The table CRMD_MKTLIST_L maps the LIST_GUID and PACKAGE_GUID.

The table CRMD_MKTLIST_C contains the actual data record.

The table CRMD_MKTLIST_PER, CRMD_MKTLIST_ORG, CRMD_MKTLIST_ADR contains the person details, organization details and address details respectively, which is uploaded via ELM.

Check for Duplicates: The previously mapped data is read from the tables like CRMD_MKTLIST_ORG, CRMD_MKTLIST_PER, CRMD_MKTLIST_ADR and checked if records of the lists exist already as business partner in the system.

Delete list in CRM:

The data in the tables

• CRMD_MKTLIST_E
• CRMD_MKTLIST_C
• CRMD_MKTLIST_ORG
• CRMD_MKTLIST_PER
• CRMD_MKTLIST_ADR
• CRMD_MKTLIST_S
• CRMD_MKTLIST_L
• CRMD_MKTLIST_PH
• CRMD_MKTLIST_I

are deleted.

In the table CRMD_MKTLIST_H, the delete flag is set.

This step is optional for the processing of the data. It is necessary for rented data.

If errors occur, the step can be repeated for the erroneous records.

Where Data’s are exactly stored?

• The data of the organization and person must be in a single record in the file.
• The table below lists details of organization-related and person-related mapping fields.
  • The column BP Table contains a list of table names where mapped entries are stored during business partner processing.

• The table below lists details of activity-related mapping fields. The column Activity Table contains a list of table names where mapped entries are stored during business transaction creation.

• The table below lists details of lead-related mapping fields. The column Lead Table contains a list of table names where mapped entries are stored during business transaction creation.

• The table below lists details of response-related mapping fields. The column Table contains a list of table names where mapped entries are checked against the tables under Table and the fields under Field during data mapping.

Classes, Function Modules and Reports for ELM

Process Steps:

The steps involved in this process belongs to Function Module CRM_MKTLIST_STAGING_PROCESS

1. Upload

Calls the method UPLOAD

In this function module the data (given by form routine UPLOAD) is saved into the database table CRMD_MKTLIST_C.

2. Map Data

Calls form routine CONVERT

This function creates the items for the table CRMD_MKTLIST_I.

The form routine CONVERT_DATA_CACHE distinguishes two cases:

• If the mapping format contains fields or advanced mapping rules (values mapping etc.) the function module CRM_MKTLIST_MAP_CONVERT is called.
• If the mapping format contains no fields and no advanced mapping rules the BAdI method MAP_AND_CONVERT_DATA is called.

3. Postal Check

Calls form routine POSTAL_CHECK

In the form routine ranges are built. The range describes the first record number and the last record number of entries in table CRMD_MKTLIST_C.

4. Duplicate check

Calls form routine DUPLICATE_CHECK

In the form routine ranges are built. The range describes the first record number and the last record number of entries in table CRMD_MKTLIST_C. This range is used in the following function module.

• BADI_CALL_DUP_CHECK

In this form routine the BAdI method DUPLICATE_CHECK is called. In the default implementation of this BAdI method the function module CRM_MKTLIST_DUP_CHECK_INT is called.

5.     Maintain Business Partner

• Calls form routine CREATEBP

In the form routine ranges are built. The range describes the first record number and the last record number of entries in table CRMD_MKTLIST_C. This range is used in the following function module.

• Calls function module CRM_MKTLIST_STAGING_CREATE_BP

In this function module the records (described in the range table) are read from the different tables of the staging area, dependent on B2B or B2C data records.

6. Create Business Transaction

• Calls form routine BADI_CALL_CREATEBTX

In this form routine the BAdI method CREATE_BUSINESS_TRANSACTIONS is called. In the default implementation of this BAdI method some private methods are called in order to create activities or leads.

7. Maintain Target Group

• Calls form routine MAINTAINTG

In the form routine a new profile set is built (if needed)

• Calls function module CRM_MKTLIST_STAG_MAINTAIN_TG

In this function module a new target group is created (if needed).

• Calls BAdI method AFTER_TG_CREATION

In the default implementation this BAdI method is empty.

8.     Delete List

• Calls form routine DELETE
• Calls function module CRM_MKTLIST_STAGING_DELETE

In this function module the content of the staging area is read. The created business partners are checked (because only rented business partners can be deleted).

BAdI Methods:

The first place where the breakpoint hits is CL_DEF_IM_CRM_MKTLIST_BADI

Thanks for your patience to read the above document.

>>> Aravindanne.

Background:

The consumer products manufacturers usually runs lot of trade promotions in order to promote their products through retails stores, shops etc.  The major part of their marketing budgets are used in “Trade spend “ , which is “incentive” given to “Retailers “ for participating in “Trade Promotions” .

When retailer participates in particular “Trade promotion “, at the end of Promotion period, the retailer submits the “claim “to get “decided amount” to manufacturer.

When Claim processing agent /executive, gets claim, he starts processing claim in “Trade Promotion Management “ system , let’s say SAP CRM TPM .

Since the number of trade promotions and number of retailers are large in numbers -

1. It has been very challenging for Consumer Product companies to keep a track
   &
2. To ensure that max claim amount is not exceeding Promotion amount.

It has been observed that if we do not incorporate functionality to identify duplicate claims, company might lose
their money unnecessarily in processing false /duplicate claims. It also reduces the overall effectiveness of Trade spend.

In Typical SAP CRM TPM landscape, where you can use “Claim De- Duplication functionality “which  enables you to identify duplicate claims and
helps you to avoid duplicate payments.

Configuration settings in SAP CRM :

1)  Activate  the business function  Claim and Fund Management (CRM_CF_1)

T-Code : SFW5 
 
 

Fig-1

2) Define De-Duplication Profile

SAP CRM Configuration Path: SPRO -> CRM-> Claim Management à Claim De Duplication

Fig.2

Then assign claim deduplication profiles to

• Claim and
• Claim submission transaction types.

To identify duplicate claims, the system uses these deduplication profiles.

Fig.3 – Screenshot for Claim transaction

Fig.4 – Screenshot for Claim Submission
transaction

Please note , that only claims and claim submissions with the same deduplication profiles are
checked against each other.

-> Checking criteria

To identify duplicate claims, the system uses checking criteria, for example,

• Claiming Account,
• External Reference Number,
• Claimed Amount.

How it Works:

You can also define your own checking criteria from a predefined list of options.

Deduplication checks

You can start the deduplication check automatically in the following ways:

• Initial:When you create or make changes to a claim but before you add a trade promotion, the system starts the initial claim deduplication check.
•    Complete:When you save a claim that has one or more trade promotions assigned, the system starts the complete claim duplication check.

You can also start the deduplication check manually at any time by clicking the refresh button.

•   Ignore duplicate reasons :When a duplicate claim is found by the system and there is a valid reason for the duplicate claim, you can choose the reason for continuing to process the claim.

Please Note that, if a claim has the status Canceled or Corrected, the claim is excluded from the duplicate checks.

  SAP CRM has also provided BADI: CRM_CLA_DUP_CHECK

You can use this BAdI to enhance the initial and the complete check types in the claims deduplication profiles.  The BAdI modifies the search criteria before the search of duplicate claims in order to restrict the results.

This  useful functionality can help consumer product  Manufacturing Companies to save a good amount of money , by avoiding  unnecessary duplicate claims processing

Topic Covered in this Document:

• How to Activate marketing Permissions

SAP CRM Marketing in EHP2

Topic: How to Activate Marketing Permissions in GUI

System: SAP CRM 7.0 EHP2.

To activate Marketing Permissions, Follow below steps:

• Login to SAP CRM with credentials Provided
• Goto T.code SFW5 and Click on Continue.
• Highlight CRM_CORE Industry Business Function and Check corresponding Checkbox under Planned Status
• Highlight CRM_MKT_PERMISSIONS, CRM_MKT_HVS Business Functions and Check corresponding Checkbox under Planned Status.
• Click on Activate Changes

Once Business Functionalities are activated we‘ll get all the Functionalities related to Marketing Permissions in GUI.

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 offers the following design to select trade promotions:

1. Search for Marketing objects base on select options
   system fetches selected trade promotions from DB, that fall into the plan start and plan to date range. In case the plan start and plan end dates are not filled the range is defaulted with 01.02.1900 to 31.9999.
2. Filter by statuses enter in selection screen
   1. filter by stystem status
   2. filter by user status
3. Validate Selection: No Mkt found, post message

For the selected 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 the trade promotion selection in PMDC report are solved with the following SAP notes:

2175710 - PMDC program is not working for User Status

1932503 - PMDC requires values for the status selection option

1928400 - PMDC program ignores the status range option

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.

The Loyalty Member is a copy of Business Partner with minimum information from the Business Partner tables.

NOTE:1178046 (This note is the Loyalty installation Guide)

> The customer is already using the CRM and newly installing the Loyalty, he has to update/activate few BAdI’s in order to copy the BP from CRM to the Loyalty Member table.

> If the customer is installing the CRM and LOY for the first time, then he just needs to activate few BAdI’s, so that whenever the BP is created, Member table is also updated with member ID.

Architecture

Two-Box Approach

The two-box approach tells that the data must be replicated from one system to another system with standard data transfer structure. Here we transfer data from BP tables of CRM system to the Member table of Loyalty box. The member able is only used for search purpose, no updates can be made on the member table, therefore the data transfer from Member table to BP tables is not required, and hence it is not supported.

In our system, data are technically exchanged with SAP CRM System and SAP LOY System.

Single-Box Approach

Here, we use the CRM Middleware for initial copy of BP's to Member Tables as in the case of Two Box approach. The customer shall use the CRM middleware for only performing an Initial Load of BP into the LOY system.

The implementation “LOY_MEMBER_UPDATE” of the interface “IF_EX_PARTNER_UPDATE” will copy any changes to BP header data on BP save to the member table.

The implementation “LOY_MEM_ADDR_UPDATE” of the interface “IF_EX_ADDRESS_UPDATE” will copy any changes to BP address data on BP save to the member table.

The three important packages are:

• LOY_MEM_DB - Package for member tables.
• LOY_MEM_RFC - Package for the RFC Function Modules to access, create, modify the member tables.
• CRM_LOY_MEM_SYNC - Package for the Function modules, classes and BAdI implementations used for keeping the BP and the Member tables in sync.

LOY_MEM_DB

This package holds the two important member tables which is used throughout the Loyalty member and its respective table types, structures, data elements and domains.

The two tables are: LOYD_MEM_MEMBER and LOYD_MEM_ADDR

Transaction Code

• LOY_APPL_MODEL => Loyalty Application Model. Transaction for developing Loyalty application models

• CRM_LOYIL_MODEL => Loyalty Interaction Layer. Transaction for developing loyalty GenIL layer.

Few Important Function Groups

• LOY_MEM_RFC => This function group has all the RFC FMs related to member object.

• LOY_MEM_MEMBER_UPDATE => The FM’s of this function group are “LOY_MEM_MEMBER_UPDATE” & “LOY_MEM_MEMB_ADDR_UPDATE”. These are the FM’s which are used to actually update/modify the database tables. These FM’s are called by the whitefield framework.

• CRM_LOY_MEM_API => This function group has all the API’s needed for member and its child object address.

Member Search

The member search can be objects can be found by using LOY_APPL_MODEL.

Thanks,

>>> Aravindanne.

Activate marketing Permissions in SAP CRM GUI

System Used: SAP CRM 7.0 EHP2

Marketing Permissions controls that customers are contacted only via those communication channels for which they agree i.e. E-mail or SMS and marketing material is only sent to customers who explicitly agreed to receive such material.

This business function is used to comply with legal requirements i.e. permission from customers before sending them unsolicited marketing messages.

Marketing Permissions play a big role in:

•      External List Management  

•      Segmentation

       Maintenance of Marketing Permissions

•

Marketing Permissions can be created in:

•      Accounts (Individual, Corporate, Group)

       Contacts or Marketing Prospects

       Marketing Permissions per communication Channel, Such as Telephone or E-mail during Segment Builder

Hence a Marketing Organization is agreed with consumers on basis of:

•Communication Channel

•Form of Consent

•Date of Consent

•Consent Status

On the basis of above criteria's Marketing is basically made more specific which helps in executing the campaigns\Promotional events in a more systematic manner as to achieve high efficiency further benefiting the organization

To Activate Marketing Permissions , Follow below steps:

•     1) Goto T.code SFW5 and Click on Continue.

•      2) Highlight CRM_CORE Industry Business Function and Check corresponding Checkbox under Planned Status

•      3) Highlight CRM_MKT_PERMISSIONS , CRM_MKT_HVS Business Functions and Check corresponding Checkbox under Planned Status.

•      4) Click on Activate Changes

Once Business Functionalities are activated we ‘ll get all the Functionalities related to Marketing Permissions in GUI

  To assign Marketing Permission to business partner, We can follow below steps:

  1) Identify Account by entering different search criteria’s

         2)Once account is identifiable , Confirm the Account and contact person associated to it.

         3) Once account and contact person are successfully confirmed , Click on More Fields.

•        4)After navigating to this screen, Click on Marketing Permission hyperlink.

         5) Once we click on this link, we can enter the marketing permissions for Contact person and Account as shown in below screenshot

           Here we can provide information like Communication channel, Consent ,form of consent for Contact and Account

     Once Marketing Permissions are assigned to Contact and account , we can view them in Marketing Permission assignment block in account overview page and contact  Overview Page.

           ThankYou !!

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 Status Profile needs to be enabled for each MKTPL Object type:

The status profile can be used for the allowed object types only.

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

Hide System Status

It might be required to hide the system status for the user. In that case the user status should be displayed. There are the following options available:

• Hide system status customizing set for the campaign type.
• Using BAdI CRM_MKTPL_OL_OBJ interface method CHANGE_VALUEHELP_ENTRIES. This approach is documented in the following notes:
  
  1335228 - Hiding System Status in Marketing Applications
  1338896 - Sample BAdI Implementations: Hide system status

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.

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
  
  For product categories the UOM is validated against the single product assigned to the product category. The product category UOM needs to be available for at least 1 product assigned to the category.

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

In case the check for the product assignment is to restricitive the same can be turned off using a BAdI approach. The BAdI CRM_MKTPL_OL_ASG interface method CHANGE_CHECK_MODE can be used to skip the check.

Using method CHANGE_CHECK_MODE the CHECK_MODE needs to be set to 'N' for the product assignment.

This is enabled with the following note:

2193438  No Check (CHECK_MODE = 'N') scenario is not handled in method CHECK of class CL_CRM_MKTGS_ASG_COLLECTION

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:

Issues related to product checks:

2193438  No Check (CHECK_MODE = 'N') scenario is not handled in method CHECK of class CL_CRM_MKTGS_ASG_COLLECTION

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.

1919259  Trade Promotion: Territory check on Sales Category fails

Performance issues:

2023700  Performance issue when checking products consistency

Issues related to conditions:

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

1983655  Exclusion of Product  Category does not delete campaign determination records

1443903  Product Exclude Flag does not delete CD Conditions

Issues with product search:

1978393  Products with a sales category assigned are not found

1899400  Search Criteria for product segment incorrect in TPM

Issues with BPS Planning:

2185630  The unit of measure is wrong for product categories or groups of a trade promotion

Issues with Product Exceptions:

2292783  TPM: Trade Spend Exception Dates are getting copied wrongly while creating Product Exception

2238850  Copying Trade activities and shifting the dates doesn't shift the Trade Spend Exception dates

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

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

Known issues related to Dates in TP Product Assignment are listed in the following document: Dates in CRM Trade Promotions

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

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

Funds Plan

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

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

Funds

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

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

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

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

TP Fund Association

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

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

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

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

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

In case more products or more expense types are used in the trade promotion the number of different funds returned depends on the fund association level.

Fund Association Levels

Funds can be associated at the following levels

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

Fund Determination

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

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

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

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

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

Fund Usages

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

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

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

Availability Check

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

Fund Postings

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

The amout is retrieved from BW planning (BPS or PAK) from the key figure mapped to the expense type. If BW planning cannot be reached or no data is available no fund posting can be done.

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

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

Fund Posting Transactions

There are the following different posting transactions available.

• Reserve Budget
  • triggered from changing the trade promotion status
  • holds PRERESERVED '20' and RESERVED '21' value category postings
• Update Claim
  • triggered by approving claim
  • holds APPROVEDCLAIM '32' and RELEASEDTOSETTLE '40' value category postings
• Settle Claim
  • triggered by CRM claim settlement
  • holds SETTLED '41', RELEASEDTOSETTLE '40' and EXPENSED '44' value category postings
• External Settlement
  • holds EXTERNALLYSETTLED '42', SETTLED '41' and EXPENSED '44' value category postings
• Balance Fund Usage
  • triggered by any TP status that balances the fund usage, or on manually balancing the fund usage
  • holds UNCONSUMEDBUDGET '15', ACCRUALBALANCE '48' and EXPENSED '44' value category postings

Fund Posting Value Categories

Some of the fund posting value categories are calculated based on some other fund posting key figures.

• Unconsumed budget: The UNCONSUMEDBUDGET '15' value category holds the still available budget for a fund usage (Budget - Actuals)
  • calculated with formula: unconsumed budget = reserved - (approved claim - expired approved claim + externally settled).

Accruals

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

There are two types of Accruals:

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

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

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

Accruals can be calculated based on the following calculation methods:

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

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

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

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

• RCRM_FM_ACL_ACCRUAL_UPLOAD_DIS
  
  The report reads table S060 in ERP using the Condition record number KNUMH and returns the statistics values to CRM for generating the posting. In case there are no values in S060 table for the affected conditions type the same needs to be checked from SD side. A known issue is solved with the following note:
  
  1491854  Condition update: Incorrect values in copied documents

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

• RCRM_MKTPL_TPM_DISC_FRGOODS

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

• RCRM_MKTPL_TPM_EXT_ACCRUALS

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

• CRM accruals
  
• ERP accruals
  
• Off-invoice scenario or Free goods scenario
  

When balancing a fund usage there is the following design based on the accruals profile - depending on the accrual profile on the fund usage has the external accrual set there is the following design:

• CRM accruals
  When the accruals are handled in CRM the accruals are balanced in CRM when balancing the fund usage.
• External accruals
  When the accruals are handled in ERP the promotional rebates are built and reversed in ERP. The accruals are uploaded to CRM using the external accruals load report. Since the accruals are reversed at the time the rebate agreement is finalized in ERP, there is no need not reverse the accrual balance in CRM when the fund usage is balanced. The accrual reversal should be brought to CRM using external accruals load.

Further useful information about accruals is available in the following document:

Accrual creation(calculation) by CRM fund management

Trade Promotion Status dependencies

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

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

Deleting Trade Spends or Products

Deleting products or trade spend is not allowed for released trade promotions. However for approved trade promotions it is allowed. Since for approved trade promotions there may be fund usages with budget reservation posting available, there is the following design:

• deleting products: the prereserved budget of the deleted product is released again, and added to the prereserved budget of the remaining funds. In case there are no further funds for the postings - this is the case if one single product is used and gets deleted - the prereserved amount gets released.
• deleting trade spends: since the trade spend is the main driver for the fund usages, deleting the trade spend is balancing the fund usage. Any prereserved amount gets released. In case the funds integration is set up a way that the fund usage contains reserved amount this is not released again, but the not used budget is posted to the unconsumed budget. Reserving the amount should happen on releasing the trade promotion. In that case deleting the trade spend is not longer allowed.

Customizing

Fund Plans and Funds

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

Customer Relationship Management

Funds Management

Funds Plans and Funds

This customizing in not trade promotion specific.

TP Funds Integration

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

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Funds Integration

Define Settings for Funds Integration

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

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

Status Driven Events

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

Customer Relationship Management

Trade Promotion Management

Basic Data

Define Status-Driven Events

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

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

1521715  Warning messages for certain Status-Driven Events

1308738  Event handler setup for TPM Fund Integration

Fund Determination

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

Customer Relationship Management

Funds Management

Fund Determination

Define Fund Determination Profiles

Availability Control (AVC)

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

Customer Relationship Management

Funds Management

Availability Control (AVC)

Define Availability Control (AVC) Profiles

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

Accruals

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

Customer Relationship Management

Funds Management

Accruals

Define Accrual Profiles

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

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

In CRM the following steps are required:

A subscription for the replication object CRM_FM_EXTDATA from transaction SMOEAC needs to be maintained under the publication 'Enhanced Rebates

Data Transfer'. The subscription should be created for the connected ERP site.

If there are duplicate active versions of publication 'Enhanced Rebates Data Transfer' the following note needs to be implemented:

1462672   Duplicate publilcations for Enhanced Rebates Data Transfer

Then the replication objects services for CRM_FM_EXTDATA needs to be generated from transaction SMOGGEN.

In transaction R3AC1 the adapter object CRM_FM_ENH_REB the filters need to be in sync with ERP.

On ERP side an entry in table CRMOBJECT need to be available:

Common Issues

Fund Posting Inconsistencies

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

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

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

          1681596  Inconsistent fund postings

• CRM_FM_FU_CORR_BALANCE_ACL: This report is used to create the balance fund usage posting in case there are balanced fund usages without having the fund posting. Further information on the report is available in the following note:
  
  1577209  Correction of possitive accruals on balanced fund usage

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

Fund Usage and Fund Posting Issues

2168095  Fund usages get erroneously copied while copying a trade promotion

2111673  Fund posting from none existing fund usage

2094576  Wrong posting against logically deleted items

2090209  Double clearing the reserved amount of a fund usage

2058494  Fund posting not cancelled upon document cancellation

2021587  Double reserved or pre-reserved amount posted

1974922  Wrong fund posting upon deletion of a trade spend from a trade promotion

1937330  No fund posting created on fund usage balancing

Accrual Issues

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

2093937  Error on finalize posting in case of missing accrual profile

2064326  Wrong Accruals after change of transfer date

2031014  Accrual items wrongly created or no accrual postings get created

1962993  TPM: Fund posting bdocs failing when accruals are handled in ERP

1947138  Deleted fund usage item accrual not reversed

Currency issues

Any known issues related to exceptional currencies are documented in the following document:

Currency issues in CRM Trade Promotion Management

Additionally the following notes may help:

2170820  Wrong decimal point for amount on funds assignment block

1650841  Discount Load Program issues error - No valid currency

There are issues with fund postings resulting in the following error message:

[CRM_FM_POST_SRV 001] No valid currency has been provided for the transaction

This issue may happen if products are excluded for the trade promotion, or whenever there is no planning data available for the product dimension. Those issues are usually solved with the following notes:

2090209  Double clearing the reserved amount of a fund usage

2010658  Product exclusions not accounting for Fund Usage items

1661643  Error message 'No Valid Currency' raised with fund posting

1800863  No valid currency has been provided for the transaction

AVC issues

1971614  TP with Funds: AVC error when TP status is set to rejected

General issues

1989720  Performance improvement - Funds management reports

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

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