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

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

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

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

Middleware settings:

Tcode R3AC1:

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

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

Tcode SMOEAC:

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

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

Tcdoe SM30 View SMOFFILFLD:

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

Tcode SMO8FD

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

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

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

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

TPM Fund usage

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

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

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

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

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

Funds Management Integration in CRM Trade Promotion Management

Accounting assignment

In Tcode IAOMC:

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

Accounting determination

customizing:

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

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

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

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

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

Accrual creation(calculation) by CRM fund management

Hi expert,

I am developing an enhancement for a client, when the user creates a new sales quote, the currency could be CNY, HKD or USD. I need to convert the quotation to USD based on the EXCHANGE RATE FOR FORREIGN CURRENCIES in C4C system.

Please give me advice how I can get the data/value from that EXCHANGE RATE FOR FORREIGN CURRENCIES (BO)?

Thanks a lot.

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

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

Status Management Customizing

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

Customer Relationship Management

Marketing

Marketing Planning and Campaign Management

General Settings

Define Status Profile for User Status

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

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

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

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

Customer Relationship Management

Marketing

Marketing Planning and Campaign Management

Basic Data

Define Types/Objectives/Tactics

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

User Status Management

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

This comes from the user status profile customizing.

From this status system allows to set the following status.

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

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

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

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

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

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

System Status

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

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

The following system status are available:

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

Business Transaction System Status Dependencies

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

The following table shows the dependencies:

Status Design in Marketing Plan Objects

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

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

CL_CRM_MKTPL_VH_BOL_PROXY_UTIL=>GET_STATUS_LIST

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

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

There are no changes allowed other than status changes.

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

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

Status Management in Trade Promotion Management

Status Driven Events

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

Customer Relationship Management

Trade Promotion Management

Basic Data

Define Status-Driven Events

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

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

1521715  Warning messages for certain Status-Driven Events

1308738  Event handler setup for TPM Fund Integration

1269223  Missing definitions for event handlers

Status for Funds Management Integration

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

As a brief overview the following event handlers are required:

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

Status for Generating Conditions

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

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

Status 'in simulation'

The status 'in simulation' is available for trade promotion objects only. Trade promotions with status 'in simulation' have the system status I1327 CSIM 'In Simulation' assigned. This is used to simulate the conditions generation in trade promotions. The trade promotion generates PR and CD conditions but cannot be used - the condition records are generated for simulation reasons only.

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

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

Delete Trade Promotions

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

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

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

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

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

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

An error is raised accordingly.

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

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

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

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

Status Management in Campaign Management

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

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

Status Dependencies in Marketing Plan Hierarchies

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

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

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

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

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

Known issues

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

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

2060455  Cannot Reset Rejected with CRM_MKTPL_COND_IF_R001 report

2032766  Check for higher level campaign on releasing element

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

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

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

1940193  Campaign with user status allowed to be released

1901364  TPM: System status change not saved automatically

1900066  User status change cannot be saved

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

1853257  Marketing Search Status - IS NOT Filter Not working

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

Hi there,

We have TSM and ECC integration. When an activity is released in CRM, Rebate agreement with condition records are created in ECC. This is working fine.

Issue is for a particular condition type and for materials, the condition records are created with Accruals value. We expect the accrual value as zero in the condition records.

I am more of an SD consultant and have little knowledge on CRM/TSM. I did search online help and unable to get any clue.

Appreciate any leads.

Thanks in advance.

Hello All,

We have the following requirement from Business, We have coupon campaign in CRM. The Coupon will be distributed to customer , where customer can redeem that coupon for his next order. Sales orders will be created in ECC. How the coupon will get determined in ECC sales order creation.

I know that we can determine the campaign in ECC sales order. Whereas i would like to know if need to redeem the voucher against ECC sales order How to link Voucher with ECC sales order.

Regards

Ashwin

Hi Champions ,

I am new as SAP CRM Functional Consultant and currently implementing CRM Project. I have theoretical concept of IC but not any technical and configuration expertise .

My client has following requirements about IC:

1. IC Agent will receive call from different prospects , w/out any integration on IC.

2. On CRM there would be several BP data records like prospects, applicants , students , alumni , agents , staff (Integration with HCM) and others

3. For example any prospects call , and IC agent search his record and then record his query on IC and then send to relevant dept for solution.

My concerns are:

• How any Request / complaint can be maintained on SAP CRM IC ?

• How compliant can be send to relevant Dept and person for solution ?

• How Knowledge base system can be maintained on SAP CRM  comprises of different messages which IC use to integrate or send to contact person.

Please guide

Thanks

Dear Experts,

We have a requirement to create and use Control Groups to compare the effectiveness of a Campaign Execution. I would like to know how to use this Control Group concept in a E-Mail Campaign Execution.

The requirement is also to create a control group based on % of an existing target group. If the Target Group has 100 BP's, then the control group should be a random 10% of this target group, so the control group should contain 10 BP's.

All I could get from SAP help site is the below link where in not much information is shared.

Control Groups - Target Groups - SAP Library

Could you please share your expertise in working in this topic. It would be of great help.

Thanks,

Siraj

Hi ,

In standard CRM can we link more than one campaign or campaign element to a lead .

The business case will be the Lead is created with one link to one specific campaign or campaign element . But after that other marketing events for the same contact will have to be linked to the same leads (if open) . If not too many leads can be open with the same contact .

Thank you

Hi ,

Looking at the Release note of CRM 7.0 Enhancement Package 3 , it seems we can have the Social Media Integration in Marketing , I understand by that the Twitter , Facebook, etc ,, link and feed .

Of course maybe to have the mapping and explode some of the data we have to paid a fee to  SAP , Twitter , Facebook, or a 3th Party (Integrator).

Do you have a presentation on this topics , or somebody we could contact is order to understand more and have an overview of this functionality , ....

I did look at the release note and http://help.sap.com/ but the documentation is very limited

Thank you .

Hi Experts,

I have a requirement where I have to fetch records from ECC-DBM.

Details:

To fetch customers who were invoiced in a date range (say monthly) from a particular service station.

Now i was able to find the tables in ECC-DBM:

invoice: VBRK

service order: /DBM/VBAK_DB

document flow:/DBM/ORDER03   - this may not be necessary

I used the t code sq02 to create infoset joining the first two tables as shown below:

Now I have to extract "customer" from "invoices" created within a "date range" from a particular "service station"

The fields I have identified here are: sold to party for customer; billing document for invoices ; billing date for billing index and print out  for date range and plant for service station

I saved the infoset (with package as local object) and generated the infoset.

Later in CRM I created attribute list with the above infoset.

On using it for segmentation I am not able to see any count hitting in the segmentation profiles.I have a feeling something is not right in infoset creation/design.

I would really appreciate if some one can have a look and suggest me a way out :-)

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

Overview

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

Rebate Processing Application

Rebates can be processed either in CRM or ERP.

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

Spend Value Types

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

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

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

Account Dimension

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

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

Rebate Recipient

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

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

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

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

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

Split Criteria

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

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

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

Status Dependencies

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

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

• trade promotion in 'released' status generates the rebate agreement in status 'open'
  
• if the trade promotion gets 'rejected' of 'finished' the rebate agreement gets the status 'released for settleent'
  

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

• manually generate conditions
  
• manually release rebate agreement for settlement
  

Customizing:

CRM or BI rates:

In the following customizing it needs to be defined wheater CRM or BI rates are used.

Customer Relationship Management

Trade Promotion Management

Basic Data

Define Rates' Origin

This customizing defines where to maintain the spend values. In case of CRM rates the spend value is to be entered in the trade spend assignment block, wheras for BI rates the spend value is to be entered in the planning layout.

Trade Spends

In the following customizing is required for defining the trade spends that are to be used in the trade promotion.

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Trade Spends

Define Trade Spends for Values

The customizing defines the possible spend type, spend category and spend method. This customizing holds the mapping to the key figure used in the planning layout.

Condition Generation Customizing

The condition generation is depending on the condition generation type. The condition generation type is mapped to a the trade promotion type and the sales organization, distribution channel and division data. The mapping is done in the following customizing:

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Condition Maintenance

Assign Condition Generation Types

The BO conditions customizing is linked to the condition generation type and needs to be maintained in the following customizing:

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Condition Maintenance

Define Condition Generation

The BO rebates specific customizing is available in the 'Pricing Condition Types' dialog.

This contains a mapping from the trade spend type, spend category, spend method to the condition type. The condition type from usage BO are rebate conditions.

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

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

Different condition generation types may have different rebate application, so this is not a system wide setting but related to the condition generation type.

CRM Rebate Processing

The customizing specific to CRM Rebates are to be maintained in the following customizing path:

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Condition Maintenance

CRM Rebate Processing

ERP Rebate Processing

The customizing specific to ERP Rebates are to be maintained in the following customizing path:

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Condition Maintenance

ERP Rebate Processing

Rebate Condition Type

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

SAP Customizing Implementation Guide

Customer Relationship Management

Rebate Processing

Set Up Rebate Determination

Create Condition Types

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

Condition Tables

The condition tables are available in the following customizing path:

Customer Relationship Management

Master Data

Conditions and Condition Technique

Condition Technique: Basics

Create Condition Tables

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

Condition Customizing Dependencies

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

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

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

A warning message will be raised:

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

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

An error will be raised:

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

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

An error will be raised:

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

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

This reads the following customizing:

Customer Relationship Management

Master Data

Products

Product Category

Pricing

Assign Field Catalog Fields to Pricing-Relevant Hierarchy

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

If this is not fulfilled an error will be raised:

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

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

An error will be raised:

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

Data Exchange

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

BAdIs

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

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

Additional Information

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

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

No data for condition generation available [CRM_MKTPL_COND_IF 044]

Known Issues

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

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

2101756  Prohibit posting of manual accruals in an ERP Rebate Agreement

2145334  Run time error while closing long term Promotions

2108699  Rebate status is not set while closing Trade Promotion

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

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

2023128  Trade Spend value is not distributed correctly on conditions

1871427  Trade promotion with Target Grp generates redundant rebates

1799381  Planning account hierarchy not checked for rebate relevant

1745805  TPM fixed Trade Spend: Incorrect distribution of spend value

1722429  Generate multiple rebates on target group not possible

General Information

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

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

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

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

2111673  Fund posting from none existing fund usage

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

2093937  Error on finalize posting in case of missing accrual profile

2090209  Double clearing the reserved amount of a fund usage

2094576  Wrong posting against logically deleted items

2064326  Wrong Accruals after change of transfer date

2058494  Fund posting not cancelled upon document cancellation

2031014  Accrual items wrongly created or no accrual postings get created

2021587  Double reserved or pre-reserved amount posted

1989720  Performance improvement - Funds management reports

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.

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

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

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

The PMDC report works the following way:

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

Product Assignment

Product Category change

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

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

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

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

The product master data gets changed the following way:

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

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

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

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

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

Unable to delete product HT-1000 because promotion already started

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

Unit of Measure change

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

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

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

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

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

Known Issues:

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

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

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

1871966 - PMDC program deletes products instead of update them

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

1780957 - PMDC report deletes products with invalid Unit of Measures

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

Dear all,

Please explain me how to create the planning profile and assign it to planning profile group in budgeting in marketing plan.I am unable to create the planning profile while creating the planning profile group.Please brief me.

Hi Gurus,

Please Clarify who all are the teams involved in marketing segmentation as i am confused a bit ,as marketing segmentation is basic for the reporting purpose & to know the various segmented (small areas performance & their reviews) .so to know the clear picture & compare for the decision making purpose

Is this much associated with BI teams ?

what are the limitations for SAP CRM in marketing segmentation as i found BI is involved in this as well .

Thanks

Bishal

Hi Gurus,

Please Clarify who all are the teams involved in marketing segmentation as i am confused a bit ,as marketing segmentation is basic for the reporting purpose & to know the various segmented (small areas performance & their reviews) .so to know the clear picture & compare for the decision making purpose

Is this much associated with BI teams ?

what are the limitations for SAP CRM in marketing segmentation as i found BI is involved in this as well .Please help for the same .

Thanks

Bishal

Dear Experts,

I have created few RRG and reward rules in a loyalty program. As I understand from SAP documentation, we use transaction CRM_FDT_TRANS to transport rule.

However, when I run this transaction, nothing is pulled out. And when I observe table CRMD_FDT_RULE, the TRANS_FLAG is (blank). I would assume it should hold "Y" (to be transported).? Is this the correct assumption ?

The question is: how do I transport my reward rules from DEV client to PROD client ?

Any advice will be much appreciated.

Cheers,

Rgds,

Benny

Hello Experts,

I am trying to set up segmentation based on objects in SAP CRM 7.0 EHP1 but do not know how to continue settings.

We retract BI query result list from BI to CRM using APD-ADS technik which contains IS-U Point of Delivery external ID.
On the basis of ADS and ISU_POD table (it contains POD internal ID) I have created an infoset where the link is EXT_UI between these two tables. I have created datasource based on the newly created infoset and set POD internal ID as object guid.

When I create target group and try to display relevant objects I can not see anything in the table and I get only a message that link between BP and Object is missing.

Could you please help me to get object segmentation work. Maybe I missed some steps but based on available documents I am not able to continue settings.

Thanks a lot!

Kind regards,
Tom

Dear Champions,

For proper execution of following Scenarios on SAP CRM 7.0 , please confirm whether we required an  installation of TREX  or it can work through alternate solution :

1. Our requirement is to add new search line by selecting “+” button during creation of Knowledge Article . Through TREX we can find the drop down list of different options as search criteria and can select as we required or we can do without TREX. (Please refer screen short of KA1 , KA2)

2.    Selection of fields which are created in info set for Segmentation. There is standard option of TREX for selection of particular filed for segmentation          but on our GUI no option of TREX exists. Or any other alternate solution (Please refer screen short of Standard Seg)

Please guide , so i can communicate with Technical Team that whether TREX is rqd or nt:

Thanks

HI Gurus

Need your help !

I have doubt regarding Marketing plan & Campaign and its integration with PS system.We creating Marketing Plan & campaign in CRM & then replicate it to PS for Budget Tracking & cost estimation.My question is Will Marketing plan be created as Project in PS followed by Campaign as its WBS element. or else how is it that their integration gets reflected from CRM to PS.

Thanks & Regards

Rohit