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

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

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

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

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

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

please refer the document link below:

Accrual creation(calculation) by CRM fund management

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

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

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

Settlement
integrated to Claim management

Customizing:

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

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

• Assign billing item category

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Account Determination for Accruals

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

Customizing:

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

• Maintain Account Determination Types
• Maintain Access Sequences

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

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

For the actual account determination the process looks as below:

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

Other relevant customizing:

For Company code determination:

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

- > Assign Billing Units to Sales Organizations

- > Assign Company Codes to Billing Units

Samples:

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

user also can check this from CRM WEB UI.

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

CRM Web UI marketing assignment block.

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

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

Tcode FB03 to check the accounting document from the claim

settlement document.

Accruals
Handled Externally in SAP ERP

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

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

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

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

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

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

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

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

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

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

please refer the document link below:

Accrual creation(calculation) by CRM fund management

Customizing：

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

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

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

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

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

Scenario 1

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

Scenario 2

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

Scenario 3

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

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

For settlement to invoice scenario:

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

SPRO -> CRM -> Billing -> Configure Application

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

Handling of Cancellation Documentson ERP side

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

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

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

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

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

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

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

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

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

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

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

Middleware settings:

Tcode R3AC1:

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

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

Tcode SMOEAC:

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

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

Tcdoe SM30 View SMOFFILFLD:

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

Tcode SMO8FD

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

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

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

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

TPM Fund usage

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

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

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

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

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

Funds Management Integration in CRM Trade Promotion Management

Accounting assignment

In Tcode IAOMC:

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

Accounting determination

customizing:

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

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

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

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

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

Accrual creation(calculation) by CRM fund management

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.

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.

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' or 'finished' the rebate agreement gets the status 'released for settlement'
  
  
  For long term trade promotions there is the following design on setting the status to 'rejected' or 'finished':
  • rejected: the BO condition record gets deleted and the rebate agreement gets 'released for settlement'
  • finished:
    • for future trade promotions (when the start date is not yet reached, so the rebate agreement was never active) the BO condition record gets deleted and the rebate agreement gets 'released for settlement'
    • for active trade promotions (when the start date is reached but the end date is not yet reached, so active rebates exist) the rebate cannot be deleted. The following error is raised:
      
      'Rebate conditions with future date exists; Status change not possible' [CRM_MKTPL_COND_IF 108]
      
      
      The rebate end date needs to be changed first to be able to finish the trade promotion. Active rebate agreements must not exist as those may apply for sales orders. Once the end date is changed, those trade promotions are considered as past dated trade promotions and the status can be set to 'finished'
    • for past dated trade promotions (end date already reached) the rebate agreement gets 'released for settlement'.

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

• manually 'generate conditions'
  
• manually release rebate agreement for settlement
  
  
  If the rebate agreement is 'released for settlement', no more changes can be made on the affected trade spend.

Customizing:

CRM or BI rates:

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

Customer Relationship Management

Trade Promotion Management

Basic Data

Define Rates' Origin

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

Trade Spends

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

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Trade Spends

Define Trade Spends for Values

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

Condition Generation Customizing

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

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Condition Maintenance

Assign Condition Generation Types

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

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Condition Maintenance

Define Condition Generation

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

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

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

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

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

CRM Rebate Processing

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

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Condition Maintenance

CRM Rebate Processing

ERP Rebate Processing

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

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Condition Maintenance

ERP Rebate Processing

Rebate Condition Type

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

SAP Customizing Implementation Guide

Customer Relationship Management

Rebate Processing

Set Up Rebate Determination

Create Condition Types

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

Condition Tables

The condition tables are available in the following customizing path:

Customer Relationship Management

Master Data

Conditions and Condition Technique

Condition Technique: Basics

Create Condition Tables

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

Condition Customizing Dependencies

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

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

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

A warning message will be raised:

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

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

An error will be raised:

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

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

An error will be raised:

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

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

This reads the following customizing:

Customer Relationship Management

Master Data

Products

Product Category

Pricing

Assign Field Catalog Fields to Pricing-Relevant Hierarchy

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

If this is not fulfilled an error will be raised:

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

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

An error will be raised:

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

Data Exchange

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

BAdIs

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

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

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:

Issues related to rebate conditions generation:

2195430  Not able to generate conditions: infinite loop

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

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

1871427  Trade promotion with Target Grp generates redundant rebates

Issues related to wrong spend value:

2023128  Trade Spend value is not distributed correctly on conditions

1745805  TPM fixed Trade Spend: Incorrect distribution of spend value

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

Decimal issues in BPS Planning for CRM Marketing Objects

Issues related to planning account:

1799381  Planning account hierarchy not checked for rebate relevant

1722429  Generate multiple rebates on target group not possible

Issues related to date shift:

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

Issues related to TP status change:

2145334  Run time error while closing long term Promotions

2108699  Rebate status is not set while closing Trade Promotion

Issues related to funds integration process:

When having funds management integrated in the TPM process the accrual customizing needs to be set up properly for the trade promotion type and expense type. Since the rebate aggreement is supposed to generate the accruals the accrual profile needs to be set up properly in the following customizing:

Customer Relationship Management

Trade Promotion Management

Trade Promotions

Funds Integration

Define Settings for Funds Integration

==> Expense Type to Accrual Profile

More detailed information is available in the following SCN document:

Funds Management Integration in CRM Trade Promotion Management

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

2176038  TFM integration is not checked on TPM Rebate creation

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

2101756  Prohibit posting of manual accruals in an ERP Rebate Agreement

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.

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. With having business function CRM_TPM_1 activated it is controlled via the customizing whether it is allowed to process retroactive trade spends. 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, there is the following customizing:

• Retro-Active Trade Spend Allowed
  • Past dated off-invoice trade spends can be added
  • Products can be added for past dated trade spends
• Retro-Active Trade Spend not Allowed
  • Off-invoice trade spends with dates in the past must not be added or processed
  • Effective dates for products that are in the past must not be added

The design is documented in the following KBA:

2181744 - Error "Cannot add or modify retroactive off-invoice trade spend "in Trade promotion with Retroactive Dates

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.

Using the 'Relate Date Range' maintenance dialog any of the additional date range can be used as condition dates.

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.

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.

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.

The plan dates and the actual dates are stored in table CGPL_PROJECT, whereas all additional dates such as the buying date are stored in table CRMD_MKTPL_DATE. In the tables the dates are stored in UTC timestamps. The start date is converted with having time as 00:00:00, the end date is converted with having time as 23:59:59.

Without having fixed timezone conversion set the dates appear as following in the tables. The sample trade promotion is created with start as 01.01.2016 and and end date as 01.01.2016. For different creation time zone the values in the tables appear as following:

• TP created in UTC time zone
  
  
  
• TP created in EST time zone
  
  

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:

• Shifted trade promotion dates do not affect trade spend exception dates
  If the trade spend exception dates still lie within the new trade promotion dates, the trade spend exception dates are not affected, hence remain unchanged.
  
• Shifted trade promotion dates fall outside the trade spend exception dates
  • with getting a later start date - the trade spend exception start date is updated accordingly.
    
  • with getting an earlier end date - the trade spend exception end date is updated accordingly.
    
• shifted trade promotion dates are completely outside the trade spend exception dates
  If the trade spend exception dates lie completely outside the new trade promotion dates, the trade spend exception dates are not shifted for released trade promotions.
  
  In that case the following error is raised:
  
  Exception dates need to fall within the corresponding trade spend dates [CRM_MKTGS_TRADESPEND]
  
  For trade promotions that are not released the exception date is adjusted.
  
  This design was introduced with the following notes:
  
  2076772 - In Trade Promotion, when changing the plan dates, the trade spend exception dates may change to an undesirable date.
  2238850 - Copying Trade activities and shifting the dates doesn't shift the Trade Spend Exception dates
  
  

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:

Trade Spend / Product Exception Dates

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

Time Zone Issues

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

TP Template Issues

1901919  Duration value changed while creating promotion template

1855835  Date range change don't propagate for Promotion Template

General Date Issues

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

1968576  Wrong Defaulting/ Determination based on project Dates

1785945  Defaulting of date ranges for trade spends is not performed

Issues with Daylight Saving Time

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

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

The content of this document was moved to the CRM Marketing SCN Wiki Space:

TPM Prozess Overview - CRM - SCN Wiki

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

Date Shift with TS Exceptions:

With having the following note implemented the design for date shift for trade promotions with TS exceptions changed:

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

The current design is documented in the following document:

Dates in CRM Trade Promotions

This design influences the mass copy process as well. When using the mass copy function with date shift for trade promotions with having trade spend exceptions and the new date falls outside the exception dates of the source trade promotion the following error is raised:

Exception dates need to fall within the corresponding trade spend dates [CRM_MKTGS_TRADESPEND 077]

This is raised since TS exception dates are not shifted in case the TS exception falls completely outside the new date.

If this is required for the business one of the following solutions (among others) needs to be implemented:

1. Implement the following note:
   
   2238850 - Copying Trade activities and shifting the dates doesn't shift the Trade Spend Exception dates
   
   This enables copying and adjusting of the trade spend exception dates in the mass copy process.
   
   
   
2. Reject copying of TS exceptions on copying the trade promotion - using BAdI CRM_MKTPL_OL_ASG interface method COPY_BEFORE. In that case no TS exceptions are copied on copying the TP. The copying of TS exceptions can either be rejected for all TS exceptions or only in case of TP date change.
   
   
3. Adjust TS exceptions on copying - using BAdI CRM_MKTPL_OL_ASG interface method COPY_AFTER. This approach can be used to influence the TS exception assignment on copying. The TS exception dates may be shifted according to any business rules after copying the TP in case the TP dates changed.

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

Background Job Issues:

Executing the mass change or mass copy in background is no longer working. The job is not released, nor can be released from SM37.

On executing the mass change in background, the job is scheduled using an RFC call to function module SUBST_WRITE_UPGRADE_VARIANT. Due to security reasons the RFC call is now replaced by a call of function module CRM_MKTPL_CREATE_VARIANT. This design change is enabled with the following note:

2327392 - RFC enablement of function module SUBST_WRITE_UPGRADE_VARIANT was removed

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.

Planning Account

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

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

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

Discounts for different planning account dimensions

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

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

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

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

Campaign Determination Conditions in CRM Trade Promotions

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

Trade promotion search via planning account

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

Trade Promotion search in SAP CRM

This explains the design and contains several known issues.

Employee Responsible

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

Automatic Payer derivation in trade promotions

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

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

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

There is the following design for different account dimensions:

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

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

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

Wholesaler determination for Indirect Trade Promotions

When having indirect trade promotions the wholesaler is determined automatically.

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

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

Customizing

Assign account hierarchy

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

Customer Relationship Management

Trade Promotion Management

Basic Data

Assign Planning Account Hierarchies

Partner Determination

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

Customer Relationship Management

Basic Functions

Partner Processing

Define Partner Determination Procedure

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

Customer Relationship Management

Marketing

Marketing Planning and Campaign Management

Basic Data

Define Types/Objectives/Tactics

Known Issues

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

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

2076667  Employee Responsible is cleared unexpectedly

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

1950295  Wrong wholesaler determination and wrong error messages

1949598  Performance issue on planning account change

1946479  Invalid error message during wholesaler determination

1945729  Wholesaler determination fails for TGR with long description

1945728  No wholesaler assigned error persists

1940857  Wholesaler deletion message not logged correctly

1940855  Wholesaler relationships not determined for target group owner

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

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

1935409  Indirect account relationships search is not displaying all the Wholesalers

1926556  Wholesaler relationships not determined correctly

1921117  Wholesaler partners are not copied after Trade Promotion copy

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

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

The content of this document was moved to the CRM Marketing SCN Wiki Space:

TPM Prozess Overview - CRM - SCN Wiki

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 content of this document was moved to the CRM Marketing SCN Wiki Space:

FM process overview - CRM - SCN Wiki

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 'cancel'
  cancelling the campaign, also is also cancelling the fund usage. The prereserved amount is released and the fund usage gets the status 'cancelled' assigned. The campaign may be cancelled with fund usages in status 'preliminary'.
• 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' or 'rejected'
  setting the status finished or rejected 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. The status must not be set for fund usages in status 'preliminary', the fund usage must be 'released' to get 'balanced'.
  

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

2090209  Double clearing the reserved amount of a fund usage

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