A number of people have asked me lately, "In a Product Cost Estimate, is it possible to highlight the estimated inbound freight costs for the purchased material components without resorting to crazy workarounds such as putting dummy lines in the Routing and/or Bill of Material (BOM) masters?"

The answer is an unequivocal yes! In fact, as of release 4.6, this is a standard R/3 option called "Delivery Costs."

What Is the "Delivery Costs" Option?

Compare the Product Cost Estimate "Cost Component report" screen displays of my manufactured material # CP_5001 in Figures 1 and 2. In both cases the total value of the Standard Cost Estimate is 57.16 Euros per unit. Now look closely at Figure 2. The inbound freight cost is broken out from the total cost and is highlighted in line 25.

Figure 1

Cost Component Report When Inbound Freight Is Not Uniquely Visible

Figure 2

Cost Component Report When Inbound Freight Is Uniquely Visible

This is also obvious in Figure 3, which shows the itemization report from a Standard Cost Estimate for just one purchased material (# CP_1005). Note that the Cost Element # for both rows in Figure 3 is the same (# 400000), but the Origin Group value is different ("PB00" vs. "FRA1"). This difference comes from our "Delivery Costs" calculation instructions to R/3, which include mapping instructions directing the 10.00-Euro purchase price to "Raw Materials" (row 10 of Figure 2) of our Standard Cost Estimate and the 5.00-Euro estimated charge for inbound freight expense to "Freight Costs" (row 25 of Figure 2).

Figure 3

Detail View of the Estimated Freight Costs (Row 25 in Figure 2)

Six Steps for Activating the "Delivery Costs" Option

The "Delivery Costs" option requires one integration point from Controlling/Product Costing (CO-PC) to the Purchasing module. In the remaining sections, I’ll walk you through the six steps required to activate this integration point.

As I show you how to activate the "Delivery Costs" option, I assume that you have a general understanding of the questions involved in a Product Cost Estimate and how R/3 finds answers to those questions. However, Figure 4 provides a refresher by outlining the basic process.

Figure 4

Basic Process for a Product Cost Estimate — A Quick Reference

Step 1. Identify the Cost Element # for the Consumption of Your Purchased Materials

When purchased materials are issued to Production Orders (usually via Movement Type 261), R/3 credits an Inventory Balance Sheet G/L account and debits an expense FI G/L account based on rules in your automatic accounting setup. The Product Cost Estimate calculation program will refer to this same automatic accounting path when deciding which account # (in CO, called a Cost Element #) to associate with the purchased materials of your finished good’s BOM. Ultimately, if you want to use the "Delivery Costs" function to separate the purchased material’s total cost into two or more pieces — purchase price and freight price, for example — you have to supplement the account # (Cost Element #) that the program finds with one additional value called an Origin Group. First things first, though:

 For any purchased materials for which you want to see the total cost split into at least two pieces, identify the G/L account # that the Product Cost Estimate program is going to associate with those purchased materials. To do this, you need to look up the "Value Class" code in the Accounting view of those materials’ Material Masters. Then, access transaction code "OBYC" and double-click on the row for the process "GBB." You'll next see a table with many, many entries of G/L account #’s. Find the account #’s you need by scrolling through the list until you find the row(s) that contain both the modifier "VBR" and the "Value Class" code(s) you found in the Material Masters.

 Then, verify that this G/L account number is also set up in the CO module as a Primary Cost Element number.

Step 2. Identify the Condition Type Code(s) Used for Freight in the Purchasing System

In the "automatic pricing" area of the MM module’s Purchasing applications, the different costs associated with the acquisition of goods and services are represented as various Condition Type codes. R/3 comes with a variety of Condition Type codes ready-to-use. However, you can also create your own codes. Since it’s possible to create new codes for each site, Step 2 is to identify which Condition Type codes are being used at your site for inbound freight costs.

My example uses the Condition Type Code "PB00," since it is often used to represent the gross purchase price of an item, and the code "FRA1" to represent the freight costs for shipping an item from a vendor’s location to yours.

Step 3. Instruct the R/3 Controlling Module to Look at the Purchasing Module’s Condition Type Records

When calculating a Product Cost Estimate, R/3 CO-PC needs to know where to find the unit cost rates for the different items (Figure 4). To allow the "Delivery Costs" functionality to work, you need to instruct CO-PC to first look at the Purchasing module’s Condition Types for unit cost rates for materials in the Finished Goods’ BOM. If it finds no rates in the purchasing records, CO-PC needs to know where else to look for the rates, such as the material master’s Standard Cost field.

To carry out this process, follow these instructions:

 To give this instruction to R/3, first determine which "Costing Variant" the end user will choose when performing the "Create a Product Cost Estimate" transaction (CK11N). For this example, I’ll assume that PPC1 is the variant in use.

 To address the customization screen for PPC1, use transaction code "OKKN" or the IMG menu path Controlling > Product Cost Controlling > Product Cost Planning > Material Cost Estimate with Qty Structure > Define Costing Variants.

 On the first screen, locate PPC1 (or the one you’re using) and double-click on it.

 On the next screen, you will see several tabs: "Control," "Qty. Struct," Additive Costs," and so forth. Choose the "Control" tab.

 You will now see a button called "Valuation Variant." Click once on that button.

 This brings up a screen with more tabs: "Material Val.," "Int. activits/processes," etc. Choose the "Material Val." tab. Here you tell R/3 where and in what priority to look for the unit cost rate. Set the first priority to the option "Price from Purchasing Info Record." This setting ensures that CO-PC will look first to the purchasing records for the unit cost rate. If it finds nothing, the next source for values examined could be the planned price field in the material master as reflected by the settings in Figure 5.

 Now look below that box and find another box called "Sub-Strategy Sequence with Purchasing Info Record Valuation." (If it’s not there after completing the settings highlighted in Figure 5, press ENTER. It should then appear.) In this "Sub-Strategy" section, you need to tell CO-PC where to look in the Purchasing Info Record. You can tell R/3 to look at either the "Conditions Table" section of the Info Record itself, or at the "Conditions Table" section of the most recent Purchase Order that was created in reference to the Info Record. Figure 6 shows an example of this. Note that one of SAP’s terms for the Purchasing module’s Info Record is "Quotation."

Figure 5

The "Material Val." Tab Definition Screen

Figure 6

The "Material Val." Tab’s Sub-Strategy Definition Screen

Step 4. Link Your "Freight" Condition Types to an "Origin Group" Code

Take another look at Figure 3. Notice that what distinguishes the gross price of a purchased item from its inbound freight cost is not the Cost Element # alone, but the combination of Cost Element # and Origin Group code. The next step is to associate the identified Condition Type code(s) from Step 2 with one or more of these Origin Group codes.

 On the "Material Val." tab of the Valuation Variant (Figure 5), a button called "Delivery Costs" should be in the lower-left corner. (If you don’t see this button, you need to go back to Step 3; you must have skipped an instruction.) Click once on this button.

 You should now see a screen where you can map a combination of Condition Types + Valuation Variants + Controlling Areas + Company Codes + Valuation Areas (i.e., Plant code) to one Origin Group. (If the screen is completely blank, click once on the "New Entries" button.)

An example of this mapping is shown in Figure 7. Note that to keep things simple in my example, I gave the Origin Group code and the Condition Type code the same name. Origin Group codes are created in R/3 using transaction code "OKZ1" and Condition Type codes via the "Purchasing > Conditions" section of the Material Management IMG menu path.

Figure 7

The "Condition Type to Origin Group" Mapping Table

Step 5. Verify That the Purchased Materials Have Purchasing Info Records

In Step 4, I configured CO-PC to look for unit cost rates first in the "Conditions" section of a Purchasing Info Record. Now I must verify that when CO-PC looks into Purchasing, it will find at least two kinds of Condition Types — one for the gross price and one for the freight expense.

 To check on these settings in Purchasing, use a material # that is acquired by Purchasing. In my example, the manufactured good is material # CP_5001 and the purchased material is material # CP_1005. At this time, you will also need the Vendor Number, the Purchasing Org. ID, and the material plant.

 Once you have the required data, use the transaction code "ME13" (Display an Info Record), as shown in Figure 8.

Figure 8

The First Screen of the "Display an Info Record" Transaction

 Enter the required data and then press the ENTER key to bring up a screen with many data fields and three buttons: "Purch. Org Data 1," "Conditions," and "Texts." Select the "Conditions" button and navigate to the screen that CO-PC looks at based on the configuration completed earlier in Step 3 (assuming you followed the same settings as discussed in Step 3).¹

 In the Purchasing Condition Table example shown in Figure 9, note that there are two rows — one each for gross price and freight. Also note that the condition code of the Freight Condition Type is exactly the same code we mapped to an Origin Group back in Step 4. Also note when condition type FRA1 was established, it was designed as a percentage calculation. In this example, freight costs are estimated at 50 percent of the gross price of the material CP_1005.

Figure 9

The "Condition Table" Screen of the "Display an Info Record" Transaction

Step 6. Link the Cost Element and Origin Group Code and Place the New Data to the "Freight" Row of the Product Cost Estimate Report

Now that CO-PC knows where to look for freight costs, the final step is to link the selected cost element and the Origin Group code, and finally to tell the estimating system what row in the CO-PC reports to display this new data. In other words, pull everything together and break out the estimated freight costs and map them to line 25 in the cost estimate as shown in Figure 2.

Specifically, the final step is to tell CO-PC on which row of the cost estimate report it should display the freight costs associated with the combination of Cost Element #400000 and Origin Group "FRA1."

 For this step, access the IMG using transaction code "OKTZ." This will take you to another product costing configuration section. By defining the "Cost Component Structure," all the various pieces are tied together. The first screen in this IMG section is displayed in Figure 10.

Figure 10

The First Screen of the "OKTZ" Transaction

Note that there is normally more than one Cost Component Structure. Each Cost Component Structure represents a unique way to sub-group the costs of a finished good’s Product Cost Estimate into report rows for differing cost display views.

 On the left side of the screen are multiple folders. Double-click on the folder called "Assignment: Organiz. Units – Cost Component Struct" to bring up a screen where different combinations of Company Code + Plant + Costing Variant are mapped to one of the Cost Component Structures.

 For demonstration purposes, let’s use Cost Component Structure "01." Next, check Cost Component "01" to view the actual report row names, and with luck one will be named Freight Costs. First, click once on the gray square on the left of the "01" code (the whole row will light up), and then double-click on the "Cost Components with Attributes" folder. Once you’ve clicked the attributes folder, the row names will be displayed. If no row is titled Freight Costs, click on the "New Entries" button and configure it.

 Now check or configure the cost element assigned to the report row. Just click once on the gray square on the left of the "Freight" row, and then double-click on the "Assignment: Cost Component – Cost Element Interval" folder.

In the example shown in Figure 11, two cost- element ranges (400000 to 400010 and 890000 to 890000) have been mapped to the Freight Expense row 25. Note that the origin group FRA1 is also mapped to row 25. This setting means that cost estimating will see the FRA1 condition type value from the Purchasing Info record, and any actual freight costs charged to the cost elements via an FI transaction will flow to row 25 in the actual cost reports.

Figure 11

An Example Definition of the "Freight" Report Row of the Cost Component Structure

Figure 12 shows another example where the report row for the Raw Materials expense includes only the items that are associated with the Cost Element from/to range of 400000 to 400010 — the field "Origin Group" is left blank as it is not required because materials are linked directly to cost elements in other configuration settings.

Figure 12

An Example Definition of the "Raw Materials" Report Row of the Cost Component Structure

 Finally, go back to cost estimating (CK11N) and re-run a cost estimate for your material to check your configuration settings. The results should look like Figure 2.

As always, getting your Product Cost Estimating system design to do what you wish will require a bit of trial and error. Implementing the "Delivery Costs" option into your design is no exception to that rule. You might need to walk through the steps I’ve outlined here more than once, and possibly even adjust some of my recommended settings to better fit with your own requirements.

Keep in mind that if your goal is to convince R/3 to separate out "Freight Expense" from "Purchase Price" on the Product Cost Estimate report, then in my opinion, the "Delivery Costs" feature in R/3 release 4.6 is the easiest way to achieve it.

At the very least, I hope this article has given you some new ideas on how to expand the usefulness of SAP’s CO-PC function. If you have additional questions or comments about this option, you can contact me at the e-mail address below.