Planning, tracking, and evaluating a discount program or any promotional activity can be accomplished using the SD module in concert with the CO-PA ledger in much the same way that the two work together to book orders and billings. While the SD module together with the CO-PA ledger are often used to analyze incoming orders and invoicing, many are not aware that you can combine them to manage and monitor a promotional campaign.

SAP’s SD module provides the functionality to record and analyze the prices and discounts associated with promotions. The SD module generates separate condition types to identify discounts and promotional prices. These condition types can be mapped to separate value fields in the CO-PA ledger. By closely integrating the SD data with the CO-PA ledger, you can plan and follow a campaign and evaluate its performance.

The key to this functionality relies on two types of pricing agreements — promotions and sales deals. You may be aware of these pricing agreements if you are familiar with the SD module, but you may not know that they can also be transferred to the CO-PA ledger. Using a technique similar to transferring sales bookings and invoicing information, the planned values for promotions and sales deals can be established in SD master data and passed to the CO-PA ledger. You can configure the system to transfer promotion and sales deals values as characteristics to the CO-PA ledger. This data can be monitored along with booking and invoicing data to get a complete picture of a marketing campaign from sales planning through invoicing, complete with reporting capabilities.

This article examines how SD uses the special pricing agreements to accommodate discount programs and promotions. I will show you how these agreements can be transferred into the CO-PA ledger, and point out some of the obstacles and confusion points that may arise in the process, including the problems associated with transferring lesser-known G record types from SD to CO-PA. I will also discuss how the data can be analyzed in the CO-PA ledger at various stages of the campaign, and show you how to configure your system to support this functionality.

Promotions and Sales Deals

Promotions and sales deals are pricing agreements¹ that form a hierarchical relationship. Promotions can consist of various sales deals, and sales deals can act as finer categorizations for promotions. For example, promotions can represent discounts related to a set of product lines such as those found in high-level marketing plans, while sales deals can represent individual customer discounts as well as specific products or product lines with special prices.

I have created an example (Christmas Promotion 1000 in Figure 1) to illustrate the hierarchical relationship between promotion and sales deal agreements. In this example, Sales Deal 1001 is for customers and Sales Deal 1002 is for product lines. Note that Sales Deal 1001 represents both customer discounts (condition type K007) along with customer/product discounts (condition type K005), while Sales Deal 1002 is for product lines (K004). Each condition type maintains condition records – e.g., Discounts (K007) for Wal-Mart is 5.00 percent, whereas Discounts (K007) for Kmart is 3.00 percent. You use the standard condition maintenance screens (transaction code VK11) for updating these discount conditions.

Figure 1

Typical promotion and sales deals

Whenever a sales order is entered, SD automatically applies the appropriate discounts (if available) in the pricing procedure. In addition, the system captures the relevant promotion number and sales deal number. It stores the information in the Sales Document: Item Data (VBAP) table, which allows you to write basic reports listing the discounts and special prices offered for specific promotions and sales deals. KNUMA_PI is the technical field name for promotions and KNUMA_AG is for sales deals.

After you create the two pricing agreements in the SD module, you can pass them to the CO-PA ledger as characteristics. Once they are transferred, you can generate drill-down reports to analyze the performance of an entire promotional campaign or to determine how well a discounted price on an individual product is driving sales.

Tapping the Analysis Functionality

In addition to entering special prices and discounts, users can enter the planned values expected to result from the discounted terms in the SD module, and analyze this data relative to the actual results in CO-PA. This combined functionality allows you to plan, monitor, and analyze the performance of your promotional programs from beginning to end.

Consider the following example: A marketing plan is created that calls for a 5 percent discount for specific customers, which is expected to generate €1 million in sales for a total of €50,000 in customer discounts. These target figures are entered into the SD module using transaction VK11 as Planned values (Figure 2). By transferring these values into CO-PA, the program can be scrutinized to see how close the campaign came to hitting the €1M/€50K target.

Figure 2

Budget planning for condition record

As I indicated earlier, transferring planned values from SD to CO-PA is accomplished in much the same manner that sales bookings and invoices transactions are transferred. When the Incoming sales orders bookings function is activated in CO-PA via the transaction code KEKF, condition values for sales orders entered in the source system are transferred to the CO-PA ledger as record type A (Record types in CO-PA identify the source transactions as shown in Figure 3). Similarly, planned values are transferred to CO-PA as commitments identified by the record type G (Customer agreements). Use transaction code KES4 to activate the transfer of discounts from SD to CO-PA. The condition types specific to the promotional campaign are set in the Activate Budget Assignment screen.

Figure 3

CO-PA record types to identify source transaction

Configuring your system to transfer promotion and sales deal data to the CO-PA ledger as characteristics makes reporting available throughout the lifecycle of the campaign, as shown in Figure 4. You can configure your system to transfer SD data to CO-PA at the time of sales planning (KES4), sales booking (KEKF), and invoicing.

Figure 4

With data from SD, CO-PA can provide details throughout the process, from sales planning through invoicing

In CO-PA, you can design reports to analyze the campaign and track how it is performing at various levels. For example, you can design a report to show how the overall campaign is performing in terms of sales, with the ability to allow users to drill down to see how individual customers are performing. Figure 5 shows the total revenue for a campaign along with the revenue broken out by customer. In this example, Wal-Mart and JC Penney are performing better than expected, while Macy’s and Sears are behind budget, suggesting a strategy change may be in order.

Passing Pricing Agreements from SD to CO-PA

Configuring your system to allow the SD module to pass pricing agreements to the CO-PA ledger is not overly complicated, although the practice is not well known.

You need to add two user-defined characteristics for promotion and sales deals to your operating concern so the values for the pricing agreements in SD transaction table VBAP (VBAP-KNUMA_PI and VBAP-KNUMA_AG) can be passed into the CO-PA ledger. Although the fields in SD are from a standard SAP table (VBAP), you cannot add them as standard fields in the operating concern. Because the KNUMA_PI and KNUMA_AG fields are eight characters long, you get an error message (“Field name must have between 04 and 05 characters”) if you try. I named my user-defined fields WWPRO and WWSDL, but you can use any name as long as it starts with WW and is four or five characters long.

Use transaction code KEA5 or menu path COPA IMG>Structures>Operating Concern>Maintain Characteristics>Create/Change to access the screen shown in Figure 6, which is from the IDES 4.5B system. Click the User-definition radio button and enter your user-defined characteristic name, in this case WWSDL, along with the description Sales deal. Next, select the button With reference to existing values and select the Data element KNUMA_AG. Save and activate the characteristic. Following the same steps, create your second characteristic (WWPRO) using Promotion in the description field and KNUMA_PI as the Data element.

Figure 6

Create user-defined characteristic for a sales deal

Once the two characteristics are created, you need to add them to the operating concern structure using transaction code KEA0 or menu path COPA IMG>Structures>Operating Concern>Maintain Operating Concern. Enter the name of your operating concern, in this case IDEA, choose the Data Structures radio button, and click on the change icon. Because the characteristics and key figures of the operating concern are the same in all clients, you see an informational message indicating that these changes will be reflected in all clients.

Transfer the two newly created characteristics from the field catalog to the data structure of the operating concern, as shown in Figure 7. Save and activate the changes, and generate the operating concern when prompted. At this stage, you have successfully added these two characteristics and the CO-PA structures have been modified to receive promotion and sales deal values.

Figure 7

Transfer characteristics from the field catalog and add to the data structure

Maintain TKEZU Entries

The new user-defined characteristics require that you maintain your rules in order to transfer the values to CO-PA. Table TKEZU maintains the mapping of transfer values from the source tables in SD to CO-PA. The topic is covered broadly in SAP note 33968; however, I have put a finer point on it in the following few paragraphs. To maintain table TKEZU (Table 1), use the view maintenance transaction code SM31 or transaction code SM30 (View V_TKEZU).

In this example, I used XXXX as a dummy name for the operating concern and WWPRO and WWSDL represent the user-defined promotion and sales deal characteristics. SD00, SDIN, and SDOR are the business transactions related to the sales processes and must be maintained. SD00 is the business process identifying a billing document, and SDIN and SDOR are the business processes to create a billing document and a sales document, respectively. You need to create entries for these three business processes if you are running R/3 version 4.6B or older. Note, however, that for implementations of 4.6C and newer, you only need to create an entry for business transaction KEDR.

PAPL is the business process to identify profit planning, and it is used for maintaining condition records for planning. You must have PAPL entries in table TKEZU. Condition maintenance records are not stored in the Sales Document: Item Data (VBAP) table like SD00, SDIN, and SDOR. Instead, these values are picked from the KOMP structure.

Transferring G Records and Setting Discounts

Next, the system must be configured to allow the transfer of record type G customer agreements for discounts and offers from SD to CO-PA. Use transaction code KES4 or menu path CO-PA IMG>Flows of Actual Values>Set Up Transfer of Customer Rebate Agreements and check the appropriate Budget as... for specific condition types, as shown in Figure 8.

Figure 8

Activate transfer of customer rebate agreements for budget assignment

Assign Valid Condition Types

After determining all of the discount rates for a sales deal or promotion, you can manage them more easily by collecting the condition types in a condition type group. A condition type group limits the number of discount-related condition types that show up when creating a new sales deal master.

Use IMG menu path Sales and Distribution>Basic Functions>Pricing>Pricing Agreements>Set up Sales Deals>Assign Condition types/Tables to Condition Type Groups to assign condition type to condition type group 0020, which is available specifically for sales deals (Figure 9). When defining condition types, make sure to include those custom condition types that you may have created for your client for special customer discounts such as the ZDIS condition type in Figure 9.

Figure 9

Assign valid condition types for sales deals

Business Example

Once your configuration is complete, you can test it with the following basic business example, which includes creating promotions and sales deals agreements, planning discount values, creating a sales order, and billing.

The first step calls for creating a promotion in the standard system via transaction code VB31 (menu path Logistics>Sales and Distribution>Master data>Agreements>Promotion> Create), and entering the appropriate description and validity period for the promotion along with its organizational data. Via transaction code VB21, you next create a sales deal, enter its description and validity period, and link it to the appropriate promotion.

At the Sales Deal screen (Figure 10), click on Conditions to maintain conditions for discounts or special prices, choose the condition type assigned to sales deals, and enter the discount ercentage offered to the customer. Using the Planned basis field in the Planned values block, enter the total amount of sales expected from the discount. Save the conditions, which are transferred to CO-PA as record type G along with the planned value amounts. In addition to the planned values, the promotion and sales deal numbers are transferred to CO-PA. You can use transaction code KE24 (display actual line items) to view the record type G data.

Figure 10

Sales deal details and assignment to promotio

Now you can create a sales order and test the system to determine if it correctly applies the discounts. When a sales order is created via transaction code VA01, the system checks whether newly offered special prices and discounts are in effect. If so, it gets the appropriate promotion and sales deal numbers and applies these discounts automatically to the order. These sales order details, along with promotion and sales deal numbers, are transferred to CO-PA ledger as record type A. Once the order is billed, the details are passed to CO-PA ledger as record type F.

In this business example, I am using transaction code KE24 just to review CO-PA line items. You can create a drill-down CO-PA report to do detailed analysis. For example, you could create a CO-PA report to monitor the commitments in record type G, then slice-and-dice on promotion and sales deals. You also could create a CO-PA report to compare commitments and sales bookings and analyze whether you are able to attract business based on planned discounts.

¹ Note that pricing agreements are not the same as pricing conditions

Mitresh Kundalia

Mitresh Kundalia heads the SAP practice at Quality Systems & Software (www.QSandS.com), a consulting firm specializing in SAP S/4HANA, SAP General Ledger, and complex System Landscape Optimization (SLO)-type reorganizations. Mitresh is widely acknowledged as a leading SAP expert, with multiple publications and an SAP-PRESS book to his credit. He has published more than 50 peer-reviewed articles and white papers, and he has given presentations at various SAP conferences and events. Mitresh is the chief solutions architect of General Ledger Migration Optimizer (GLMO), a leading product to accelerate and jump-start the SAP S/4HANA and SAP General Ledger initiatives; SAP Data Reorganization Optimizer (SDRO), an SLO-type product for managing complex system landscape reorganizations; and Group Currency Activation and Conversion (GCAC), a product suite to manage introduction of parallel currencies and conversion of data in a live SAP system.

You may contact the author at Mitresh@QSandS.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.