Dear BW Expert,

I cannot find an InfoSource for pricing conditions for sales documents in the standard business content. Can you point me to an InfoSource that extracts pricing conditions for sales documents from the KONV table in R/3?

Satish Hiranandani, Hewlett-Packard

Dear Reader,

Unfortunately, the current BW system lacks the extract structures you’re looking for to transfer sales document pricing conditions from R/3. The Logistics Extraction Cockpit (LO Cockpit) does not have an extractor for the sales orders or billing document condition values contained in R/3 table KONV.

It’s common for BW practitioners to attempt to make up for the missing extraction technology by writing customer enhancement RSAP0001 (EXIT_SAPLRSAP_001) for transferring pricing conditions. This is a mistake that can cause performance issues because the system reads conditions data in a loop. In addition, EXIT_SAPLRSAP_001 is called at the time of extraction and the conditions can change by the time the data is transferred, causing reporting inaccuracies and other problems.

However, there is an effective work-around based on subtotal fields in R/3 for transferring Sales and Distribution (SD) module pricing conditions into BW. Subtotal variables are used to calculate and temporarily store important condition values during pricing calculations in fields that are accessible for extraction.

What Are Subtotals?

Before I explain my solution, I’d like to tell you a little more about subtotals and what they do in R/3 so you can better understand the workaround. The R/3 system ships with more than 20 subtotal variables, and they are an important component of its pricing procedure. Used to determine an item’s selling price, pricing procedures consist of various condition types such as categories of prices, discounts, surcharges, and taxes that are totaled together. Figure 1 shows an abbreviated example of a typical pricing procedure (RVAA01) with columns for both condition types (CType) and subtotals (SubTo).

Figure 1

Typical pricing procedure

The subtotal code, which is represented as 1 in Figure 1, determines into which variable the subtotal is placed. Figure 2 shows that the value of step 100 is assigned to subtotal variable 1, which means the Gross Value amount is stored in KOMP-KZWI1. Variable codes 1 through 6 indicate that the values are carried over to the KOMP structure. These values are permanently stored in tables VBAP (Sales Document: Item Data) and VBRP (Billing Document: Item Data). In Figure 2, note that subtotals codes 7, 8, 9, and A through C are reserved for special purposes and should not be used for customizing.

Figure 2

Subtotal (SubTo) variables and their corresponding fields

Subtotal variables fulfill a couple objectives in R/3. They are used to total more than one row of pricing procedures when the rows are not sequential (Figure 3). To calculate the sum of ZK11 and ZK12, for example, you would assign subtotal variable E to each of the rows with these condition types. The total is then stored in field XWORKE. Subtotals also perform other roles such as providing access to specific condition-type values when row numbers are not available.

Figure 3

Subtotal variable E totals condition type ZK11 and ZK12 in XWORKE

Subtotals Workaround

Subtotal fields can be used to transfer condition values into BW via sales orders and billing documents screens in SD. These are the KZWI fields numbered KZWI1 through KZWI6 in tables VBAP and VBRP. You can display these tables VBAP or VBRP via transaction code SE11 and review the technical fields (Figure 4).

Figure 4

Technical table structure showing the six subtotal (KZWI) fields

The standard InfoCube 0SD_C03 (Sales Overview) contains all the transaction data from sales orders, deliveries, and billing documents. It is updated via the following InfoSources:

• 2LIS_11_VAITM (sales document)
  
  
• 2LIS_12_VCITM (delivery item)
  
  
• 2LIS_13_VDITM (billing document item)

InfoCube 0SD_C03 contains InfoObjects 0SUBTOT_1S, 0SUBTOT_2S, 0SUBTOT_3S, 0SUBTOT_4S, 0SUBTOT_5S, and 0SUBTOT_6S that correspond to six subtotal fields (VBAP-KZWI through VBAP-KZWI6) in SD.

Let’s say your company uses the pricing procedure shown in Figure 5 on the next page, and you need to extract and transfer the following values:

• *Gross value for Item
  
  
• *Net Value of Item
  
  
• *Net Value of Item 2
  
  
• *Freight
  
  
• *Total Discounts

Figure 5

The column Value display the sample condition values and is not part of an actual pricing procedure

Use transaction code V/08 to tweak the pricing procedure by adding subtotal variables to the Sub. To column as shown in Figure 6.

Figure 6

Pricing procedure with subtotal variables added to specific rows

The pricing procedure is altered such that the Gross value for Item entry is assigned to variable 1, which is stored permanently in table VBAP (or VBRP) as KZWI1. The extract contain fields VBAP-KZWI1 through VBAP-KZWI6 so the value is extracted to InfoObject 0SUBTOT_1S. Similarly, the other values are stored as shown in Table 1.

Limits to the Workaround

This workaround has a couple limitations. The condition values are correctly updated and stored in the table once the revised pricing procedure is in place. However, the workaround will not change values for historical transactions. Table entries for historical transactions are already stored, and the condition values will not be recalculated.

If you are using the Sales Information System (SIS), you also need to see if that information structure uses subtotal values. For example, information structure S001 uses subtotal variable 1 and updates the gross value of incoming orders. If you are making changes to an existing assignment, make sure that it does not affect your SIS.

Rumor has it that SAP realizes the importance of extracting pricing conditions. Watch the release notes to see if and when the functionality becomes available. Until then, you’ll find that my workaround solution does the trick!

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.