Three settings in a customization piece called the Sales and Distribution (SD) Pricing Procedure will give you greater ability to fine-tune profit-related data that is sent from SD to CO-PA. The article includes a walk-through exercise to help you learn the technique.
Out of the many options available in SAP R/3 for influencing when and what kind of sales data to populate into our FI/CO ledgers, some of the least understood reside in a customization piece known as the SD Pricing Procedure. Figure 1 shows an abbreviated example of one of these and highlights the three settings we will discuss in this article —Statistical: Yes/No (Stat.), Subtotal To (Sub. To), and Alternative Calculation Type (Alt. CType).1
These settings serve multiple functions. However, I would like to focus specifically on their potential use as instruments that can "fine-tune" the profit-related data that gets sent from SD to CO-PA. At the conclusion of this article, you should have a much better understanding of the options offered to you and your profitability analysts from this functionality. I’ll discuss the options one at a time. However, if you feel you would first like to have a bit of a review on what is meant by a "Condition Type" and on how one of them gets populated with money values, I have put a brief background comment about that on page 6. There is also a review comparison of the R/3 Costing-based CO-PA ledger to the R/3 General Ledger on page 5.
| St |
Cond Type |
Description |
From |
To |
Stat. |
Sub. To |
Alt. CType |
Acct. Key |
| 10 |
PR00 |
Base Price |
|
|
|
|
|
ERL |
| 100 |
|
*Gross Value for Item |
|
|
|
1 |
|
|
| 101 |
ZK11 |
Seasonal Discount |
|
|
|
|
|
ERS |
| 110 |
K005 |
Customer/Mat. Disc. |
|
|
|
|
|
ERS |
| 199 |
ZKB2 |
Disc. if Early Pmt. |
|
|
x |
|
|
|
| 200 |
|
*Total Discount |
101 |
199 |
|
|
|
|
| 800 |
|
*Net Value for Item |
|
|
|
2 |
|
|
| 940 |
VPRS |
Internet Cost |
|
|
x |
B |
|
|
| 990 |
|
*Profit Margin |
|
|
|
|
11 |
|
* The SD Pricing Procedure is an instruction to the sales order and sales invoice transaction as to how to calculate a price for the sold items. It is read from left-to-right, and from top-to-bottom. Rows with a Condition Type code get their value from an external source such as the end-user’s data entry, the sold material’s Material Master, or a special form of SD master data called Condition Records. Rows with the “*” symbol get their value from calculations within the Pricing Procedure, and typically represent the addition or subtraction of the values of higher rows. Note that an actual Pricing Procedure will not have these asterisk symbols — I have only added them to Figure 1 to make the distinction more obvious.
|
|
| Figure 1 |
An Abbreviated Example of an SD Pricing Procedure and Its Column Names |
The Two Sections of a Costing-Based CO-PA Ledger
The trick that allows a Costing-Based CO-PA report to offer its reader very fast point-and-click subtotaling and re-subtotaling of revenues vs. expenses, as he or she chooses to rearrange the various combinations of who/what/where factors being shown on the screen (e.g., Customers: Big vs. Small; Products: Line A vs. Line B; Distribution Channels: Direct Sales vs. Internet), is the way the data is stored in the ledger.
General Ledgers, and even Special Ledgers, have a dedicated column that stores the G/L account number of each posted debit and credit. This kind of structure is very useful for reports that do not need to allow much interaction between the report and the report reader, such as a Balance Sheet report or an Income Statement report.
But in Costing-Based CO-PA, the goal is to allow the report reader to search for relationships between profits and potential causes of those profits. So, instead of having a column called “G/L Account Number,” in the CO-PA ledger every kind of a revenue and expense being tracked gets its own column, thereby allowing each row of data to represent an entire event (such as a sales billing) rather than only a single debit or a single credit entry.
In CO-PA, these kinds of “how much” monetary and quantity columns are called “Value Fields.” By comparison, the “who/what/where/when” columns are called “Characteristics.” The Figure below shows examples of each. For the most part, it is up to each R/3 site to decide how many columns in each section to go with and what names to give those. The challenge is to decide which kinds of Value Fields and which kinds of Characteristics will actually be helpful to the profit analysts. And, of course, your decisions will be influenced greatly by your awareness of what kinds of options exist for bringing Value Field-related and Characteristics-related data into the CO-PA ledger from source transactions such as SD Billing.
This article explains three options for automatically populating the Value Fields section from source transactions in the SD module. Awareness of these options might help to give you a better idea both on how many columns to use in that section, and on what to name each.
The Stat. Column Option
For any row in the Pricing Procedure with a Condition Type, putting a checkmark in its Stat. column is your way of telling R/3 that any financial values that might get populated in that row should not affect pricing calculations related to billing your customer (i.e., either gross price or net price of the sales order). And, the value of "statistical" Conditions do not post to G/L accounts when the sales order’s billing document is generated.
So, why bother having these in the Pricing Procedure?
There are two main reasons related to our topic of populating data into CO-PA:
1. The values can be used inside the Pricing Procedure itself for the addition and subtraction calculations represented in the rows that do not have Condition Types. An example of this is the Total Discounts row shown in Figure 1. This internally calculated value can then be used as an input to either of the next two options, Alt. CType or Sub. To, both of which can be used to feed data into CO-PA.
2. The values in these statistical Conditions can also be directly transferred to your CO-PA ledger’s Value Fields. The customization table that allows you to map SD Condition Types to CO-PA Value Fields is found via transaction code KE4I. The example in Figure 2 shows a mapping of the VPRS condition. This condition typically gets its value from the standard price field of the sold material’s Material Master and represents your cost. It is flagged as Statistical because, of course, you do not want it to be part of the sales price calculation to your customer. But, you do want it in the Pricing Procedure, as that allows an easy visual depiction of gross profit (i.e., sales price minus standard cost). And it also allows an easy data update to CO-PA of the sold item’s Standard Cost of Goods Sold.
Figure 2
An Example Mapping of the VPRS Condition Type to a CO-PA Value Field
An Example of How an SD End-User Can Populate a Pricing Procedure’s Condition Types, Directly vs. Indirectly
Quick Background on How an SD End User Populates the Sales Price Variable Known as a Condition Type
To more easily understand an explanation of Pricing Procedure options such as the Sub. To and Alt. CType settings, you should first quickly review what this thing called a “Condition Type” is and where it gets its values.
The purpose for having multiple Condition Type codes (such as PR00 and K005, as shown in Figure 1) is to allow us to represent different kinds of sales revenue, sales discount, and sales expense variables that might need to be applied to any particular sale.
The end users that create sales orders or sales billing documents in the SD module are almost always the source for the financial values populated into these Condition Type codes. This relationship can be either direct or indirect, as shown Figure above.
Finally, it is in the customization settings that you make in the Pricing Procedure and the Condition Type masters that determine three things:
1. Which relationship the end user is given the responsibility for (i.e., direct vs. indirect).
2. Under which circumstances is the relationship to be direct vs. indirect (e.g., creating a new sales order vs. creating a credit memo request).
3. Regardless of how the Pricing Procedure gets populated (direct vs. indirect), what the impact should be of those populated financial values to the FI General Ledger’s G/L accounts and to the CO-PA ledger’s Value Fields.4
The Alt. CType Column Option
For any row in the Pricing Procedure that has a Condition Type, populating the Alt. CType column is your way of telling R/3 that you want that row’s Condition Type financial value ignored and replaced with the result of this second (i.e., alternative) method for determining that row’s financial value.
Your SAP system comes delivered with some of these alternatives ready to use, but you can also create your own via transaction code VOFM.2 At first glance, this kind of option seems strange. What is the point of having a Condition Type row in your Pricing Procedure if you are just going to tell the system to ignore it?
There are two main reasons related to our goal to populate data into CO-PA:
1. None of the standard options for deriving a financial value for a Condition Type row seems to offer what you need. (The standard options include direct data entry by the sales order end-user and indirect derivation of a rate based on other values typed in by the end-user such as Customer, Sales Org, Plant, and Material number). In this case, the alternative allows you to have a non-standard derivation, such as a mathematical formula. The results of that formula can then be mapped into a CO-PA Value Field, using the same customization table (KE4I) I mentioned in the Stat. Column Option section.
2. You want to allow one of the standard options to derive a financial value and then validate (i.e., double-check) that value prior to allowing the actual use and inclusion of that rate and, therefore, also prior to that value being sent to a CO-PA Value Field. An example of this kind of use of an Alternative Calculation instruction is shown in Figure 3. It can be used to verify that any down payment being made by the customer on the sold item does not actually exceed the total sales price of the item. If this should happen, then the user gets a custom error message. Note in the screenprint that the field called komp-netwr represents the Net Value of the sales order, and that xkwert represents how much down payment (if any) the customer is making.
Figure 3
An Example of an Alternative Calculation Type’s Instructions
The Sub. To Column Option
This abbreviation stands for "Create a Running Subtotal: Yes/No?" For any row in the Pricing Procedure — whether or not it has a Condition Type — putting a value in this column is your way of telling R/3 that you want that row’s value stored in a special field that exists only to keep temporary, running subtotals within the Pricing Procedure. Your R/3 system comes delivered with more than 20 of these variables (designated by the codes 1, 2, 3, ... 9, and also A, B, C, ... M, etc.).3 Just type one of the codes into the Sub. To column of any given row, and that variable becomes active. An example would be row 940 shown back in Figure 1 (uses the "B" field subtotaling variable).
But why bother with this option, especially since you already have the option in the Pricing Procedure to add internal calculation rows, such as row 200 shown back in Figure 1?
There are two main reasons related to our goal of populating data into CO-PA:
1. You want to use the financial value of one of the Pricing Procedure rows as a variable in one of your Alternative Calculation routines. An example of this is shown in Figure 4. Notice how no mention is made about row numbers in a Pricing Procedure. Instead, the reference is to one of the standard-delivered subtotaling variables (xworkd, which is also known as subtotaling variable "D"). This is because the Alternative Calculation program has no way to recognize Pricing Procedure rows by row number. It can only recognize the value of a given row number if that value is copied into one of the temporary subtotals variables.
2. You want to calculate a sum of more than one of the Pricing Procedure’s rows, and those rows are not sequentially organized in the Pricing Procedure. As an example, refer back to Figure 1. Suppose that we want the total sales discounts only of the two "Z" conditions, ZK11 and ZKB2. This will not be possible using an internal calculation row, as those can only refer to a sequential range of row numbers, such as the Total Discounts row that subtotals all rows from 101 to 199.
Figure 4
An Example of an Alternative Calculation Instruction Referencing the Standard Subtotaling Variable "D," Field
Summary
If you want to know more about Pricing Procedure options, see "Quick Background on How an SD End-User Populates the Sales Price Variable Known as a Condition Type" above.
For those of you who learn best by doing, I have provided a self-teach exercise you can try out on page 10. Basically, what I have you doing is saving value(s) of specific condition(s) in memory variables, assigning these to Statistical Conditions with help of Formula routines and then mapping Statistical Conditions to CO-PA value field(s).
For everyone else, you should now have a better understanding of three options for automatically populating the Value Fields section of Costing-Based CO-PA. These include the ability to do the following in a sales order or sales invoice document, prior to any transfer of data from that document into CO-PA:
- Create a statistical Condition Type value.
- Deriving and/or validating a Condition Type’s value.
- Generating a temporary running subtotal of one or more Condition Types’ values.
If you have questions or comments about any of these three options, you can contact me at the e-mail address shown in my bio.
Self-Teach Exercise: Using All Three CO-PA Data Fine-Tuning Options
If you like to learn by hands-on experience, here is a simple demonstration exercise that you
can do in your sandbox (non-production) client. Note that some of these work steps involve
customization and ABAP settings, and therefore you might need to do this exercise with someone who has user authorization to access those transactions. That said, here are the steps.
1. In your sandbox client, find an existing sales order document, preferably one that is quite simple (e.g., just one line item). Use transaction code va03 to search for and display that sales order. Access the Pricing (Conditions) screen for the first line item in that sales order. You should see a button after that called Analysis. Click once on that, and R/3 will show you a report with the name of the Pricing Procedure somewhere in the upper-left corner of that report (e.g., Procedure RVAA01). You will temporarily make edits to this Pricing Procedure for this demo and then change it back once you are done.
2. Access transaction code V/06. Once there, copy the condition type PR00 as ZPR0 (highlight the PR00 row, and then choose from the menubar: Edit > Copy as...). You do not require an access sequence for ZPR0, as its value will be calculated separately with the help of a routine. Basically, ZPR0 will be used for storing a value to be passed only to CO-PA and not to the G/L. So, blank out any value in the Access Sequence field that got copied into your ZPR0 condition type and then save.
3. You can next create an Alt. CType routine. SAP provides customer number range 600 to 999 for such routines. Let’s create a customer routine 991. Use transaction code VOFM and then choose from the menubar: Formulas > Condition value to get to a screen where you can type in a number such as 991 (you might have to scroll down a few times to get to some blank rows). Type the number into any blank row, add a text description into the next field, and then press your ENTER key. R/3 will prompt you to supply an Access Key (you will need to register your new routine with OSS to get an Access Key number — ask your Basis resources for help on that, if necessary). Once you type in the Access Key, you can then navigate to a screen where you can create a new formula routine as follows:
form frm_kondi_wert_991.
xkwert = xworkd.
endform.
Activate this routine to make it available for further processing (return to the first screen,
then highlight your routine’s row, and then choose from the menubar: Edit > Activate).
4. Access transaction code V/08. Once there, find your Pricing Procedure from step 1 and then highlight that row. Now, to see the detail definition of that Pricing Procedure, double-click on the Control folder. At that point, you should see a screen with a whole series of pricing rows. Look for the row with Condition Type PR00, and change the value in its Sub. To column to “D.” This instruction tells R/3 that the condition value of PR00 should be stored in temporary variable xworkd (the same variable you used in the definition of our Alternative Calculation form in step 3).
5. Stay in the Pricing Procedure maintenance screen, and click one time on the New Entries button. Add a row number that has not already been used in that Pricing Procedure (such as 910), and link that new row to Condition Type ZPR0 (the one you created in step 2). Also for this new row, set the value in the Alt. CType column to routine number 991 (i.e., the one
you created in step 3). Also, put a checkmark
in the Stat. column, so as to exclude the value of this row from the sales order’s net price and to ensure that its value does not get transferred to any G/L accounts.
Now, your pricing procedure should look something like what’s shown in the Figure below.
6. Access transaction code VA01. Once there, click once on the Create with Reference button to get a pop-up screen where you can type in the sales order number you found from step 1. Once you type that order number into the pop-up window, click once on the Copy button, and R/3 will create a new sales order for you as an exact copy of the old sales order. You will be shown this new sales order’s details and can make edits if you like. For this demonstration, you do not need to edit. You just need to navigate once again to the first line item’s Pricing (Conditions) screen. Once there, click once on a button called New Pricing or Update. This will cause R/3 to rerun the Pricing Procedure’s instructions. If all has gone well, you should now see a row for your Condition Type ZPR0, and due to the instructions from steps 4 and 5, its value should be exactly equal to the row for Condition Type PR00. This ZPR0 value could then be seen in various pricing reports and could also be copied into the sales order’s billing document (where it could then be
posted into a CO-PA Value Field).
This was just a simple example of how the Stat., Sub. To, and Alt. CType options can be used. At this point, you can probably think of much more useful applications of these options for your site’s CO-PA ledger.
| St |
CType |
Description |
Fr |
To |
Stat. |
Sub. To |
Alt. CType |
| 10 |
PR00 |
Base Price |
|
|
|
D |
|
| 100 |
|
Gross Value |
|
|
|
1 |
|
| 110 |
K005 |
Customer/Material |
|
|
|
|
|
| 200 |
|
Discount Amount |
101 |
199 |
|
|
|
| 800 |
|
Net Value for Item |
|
|
|
2 |
|
| 910 |
ZPR0 |
COPA Adjs for PR00 |
|
|
X |
|
991 |
| 940 |
VPRS |
Internal Cost |
|
|
X |
B |
|
| 990 |
|
Profit Margin |
|
|
|
|
11 |
An Example of What Your Pricing Procedure Should Look Like After Work Step 5
1
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.
