The cross-selling functionality in R/3 prompts a dialog box upon sales document entry, displaying a list of items that the user can suggest to a customer. You can set it up so that a dialog box is triggered automatically by an addition of a new line or manually via a functional button at the bottom of the sales document entry screen. The list of items that is displayed in the dialog box can be determined via "fixed" allocations, whereby a set of master data condition records is maintained linking relevant products, and through the use of product proposal functionality that uses customer order history and general buying patterns.

Step 1. Configure the condition technique. Those already familiar with the inner workings of the SAP proprietary concept known as "condition technique" should find the steps detailed below quite familiar. Although the term is most often used in relation to pricing functionality within R/3, it is also utilized in a variety of other areas, including output determination, material determination, and cross-selling. Refer to the article "Condition Technique: Meet Complex SC Pricing Requirements More Easily" by Mitresh Kundalia in the SCM hub of SAPexperts for a more detailed explanation of how the condition technique works.

In reference to the cross-selling functionality of R/3, the condition technique can be used for the maintenance of "fixed" rules. For example, whenever a customer buys a CD player he or she should also be offered the option to purchase a pack of batteries.

Follow the IMG menu path Sales and Distribution>Basic Functions>Cross Selling>Define Determination Procedure For Cross Selling or simply use transaction codes OV40 through OV47 to access the individual configuration steps directly. Start by defining all the necessary condition tables. While creating a new condition table, make sure to assign it a number that is within the customer number range 501 through 999. Figure 1 provides an example of a custom condition table 510 that has two fields as part of the key, Sales organization and Material. Proceed to the maintenance of the field catalog (transaction code OV40), if the field that you would like to use as part of the condition table key is not in the list of available fields.

Figure 1

Create a Condition Table

Once all the necessary condition tables have been defined, create an access sequence (transaction code OV41). Use a four-character/-digit abbreviation that starts with either a Y or a Z for the name. Assign all the relevant condition tables to the newly- created access sequence, putting the more specific condition tables above the less specific ones. Figure 2 shows an example of a custom access sequence Z001.

Figure 2

Maintain an Access sequence

Once the access sequence has been created, maintain the custom condition type. Use transaction code OV42 for quicker access. The configuration here is very basic. Give the new condition type a name within a customer namespace (starting with either a Y or a Z), provide a helpful description, and assign the relevant access sequence that this condition type should use. Refer to Figure 3 for an example of a condition type ZS01.

Figure 3

Define a condition type

Lastly, proceed to the definition of the procedure by using transaction code OV43. Following the same logic, create a new procedure by providing a description and a name within the customer namespace, and assign all of the relevant condition types. Figure 4 demonstrates an example of a custom procedure ZS0001.

Figure 4

Maintain a Procedure

Step 2. Create a product proposal. Some of the features of the dynamic product proposal functionality can be incorporated into the cross-selling configuration as well. In a nutshell, various function modules can be used to pull historical sales data in R/3 and come up with a list of possible cross-selling opportunities. For example, we can use product proposals to map the now-famous "Customers who bought this item were also interested in…" business process.

Follow IMG menu path Sales and Distribution>Basic Functions>Dynamic Product Proposal>Define Product Proposal Procedure and Determine Access Sequences. I'll use the standard product proposal procedure CSPV1. Figure 5 displays the configuration behind it.

Figure 5

Define a Product proposal procedure

Function module SD_DPP_CROSS_ SELLING is used to come up with a list of the most popular item combinations. For example, you can determine that when customers bought a personal computer they also bought a monitor 85 percent of the time. Note the FM attributes assignment of CROS. This refers to an identifier that was assigned to a particular listing that was generated through the companion sales analysis functionality in R/3.

To generate a list through the companion sales analysis, proceed to transaction code SDVK. The name of the program is SDCRSL01. Once the report is executed and completed successfully, it generates a list of companion sales items. Refer to Figure 6 for an example of the selection criteria for this report.

Figure 6

Companion Sales Analysis selection criteria

As mentioned before, the Identifier field in the selection criteria corresponds to the FM attributes assignment in the configuration of the product proposal access sequence and is physically saved with the results of the companion sales analysis. This is how the product proposal access sequence knows which results to look at to produce a list of possible cross-selling opportunities. The companion sales analysis report should be executed periodically to update the listings that are used by the product proposal functionality.

The results of a typical companion sales analysis run are displayed in Figure 7. Generally speaking, the report reads sales documents (table VBAK) and corresponding line items (table VBAP) and determines the combinations of materials that show up in a single sales document together most frequently. The Sup. (%) column displays the percentage of time that a particular combination appeared in a sales document as compared to all sales documents that were captured during the analysis based on the initial selection criteria. The Conf. (%) column displays the percentage of time that the second material was also requested whenever the first material was purchased. For example, Figure 7 provides the information that the Headphones and CD Player combination existed in 50 percent of all orders analyzed. It also shows that whenever headphones were purchased, a CD player was also purchased on the same order 100 percent of the time.

Figure 7

Results of the Companion Sales Analysis

Step 3. Maintain the configuration of the cross-selling profile. If necessary, you can specify the cross-selling functionality for the customer or sales document type. Several keys must be defined that will be used later during cross-selling profile determination. Follow the IMG menu path Sales and Distribution>Basic Functions>Cross Selling>Maintain Customer/Document Procedures For Cross Selling. If necessary, define a number of valid keys for customers and sales document types. Sales document types can then be assigned to the relevant keys in the same place in the IMG. The customer key is assigned to each individual sold-to party in customer master data.

To define and assign a cross-selling profile, proceed to IMG menu path Sales and Distribution>Basic Functions> Cross Selling>Define and Assign Cross-Selling Profile. Figure 8 shows an example of a custom cross-selling profile. Start by giving the new profile a name within the customer namespace (starting with a Z or Y) and an informative description. The Product proposal procedure assignment allows the use of the companion sales analysis. The Cross-selling procedure assignment allows the use of the "fixed" rules, where the cross-selling combinations are physically maintained in condition records. You can use the Pricing procedure assignment to use a different pricing procedure on the items that were added to the sales document as a result of the cross-selling functionality. Use the next two indicators to determine how you want the cross-selling pop-up window to be displayed in a sales document and whether availability (available-to-promise [ATP]) should be considered during the cross-selling execution.

Figure 8

Define a Cross-selling profile

Once the cross-selling profile has been defined, proceed to the assignment configuration step at the same location on the IMG menu path. Figure 9 provides an example of an assignment.

Figure 9

Sample Cross-selling profile assignment

Step 4. Put cross-selling into action. To maintain "fixed" rules for cross-selling items, proceed to the maintenance of cross-selling condition records by using either SAP Easy Access menu path SAP menu>Logistics>Sales and Distribution> Products>Cross selling>Create or use transaction code VB41. Figure 10 demonstrates a possible entry in one of the condition tables: A customer will be offered batteries whenever a CD player is purchased. The UoM column can be used to force a particular unit of measure on the material that is being added to the sales document as a result of the cross-selling functionality. You can use the Cross-Selling Delivery Control column to determine whether the delivery of the added item is possible without the delivery of the original item.

Figure 10

Maintain a Cross-selling condition record

To see it all come together, create a sales order and enter the CD Player material number as one of the line items. Upon pressing Enter, you should be presented with a pop-up window similar to the one shown in Figure 11.

Figure 11

aCross-selling functionality in action

Headphones are proposed as a result of the product proposal functionality through the use of companion sales analysis, while Batteries are suggested as a result of the condition record that was maintained manually. The user can then propose the items to the customer and either enter the necessary order quantity for each of the proposed items or cancel the cross-selling proposition altogether.

Anton Karnaukhov

Anton Karnaukhov is a senior IT manager at Pacific Coast Companies, Inc., in Sacramento, California. He earned an MBA degree at Heriot-Watt University and a BS/BA degree with a specialization in computer information systems at Western Carolina University. Anton has more than eight years of SAP implementation and development experience focusing on business intelligence and logistics modules in the manufacturing and resale industries.

You may contact the author at anton.karnaukhov@paccoast.com.

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