FI practitioners are often confused by two vocabulary terms in the Production Planning module: origin and parameter. Understanding what they represent will give them a clearer picture of what their integration options are for PP. The author, a PP specialist, defines the two terms and walks the readers through the different places in R/3 where the PP module might find data related to processing time and weight/volume quantities.
The goal of this article is to explain two of the most confusing product costing vocabulary words in the Production Planning (PP) module: "origin" and "parameter." Anyone who has seen the many different R/3 tables used in product costing knows that a lot more than just these two settings are involved. But in my opinion as a PP consultant who has had many a fight over integration options with you FI/CO folks, it is these two terms that most often cause confusion.
The lessons presented here should not take you more than 10 or 15 minutes to read. They might save a new student to product costing many days of bewilderment, and intermediate practitioners of R/3 product costing many hours of pained confusion.
This lesson on the PP module’s "origin" and "parameter" terms will focus as follows:
- I’ll start with a simple product costing question that has nothing to do with R/3.
- I’ll then show you screenprints of different places in R/3 where we PP folks have options to place data related to processing time and weight/ volume quantities. This becomes an extra layer of product costing variables that, too often, confuses people trying to learn the topic.
- Finally, I’ll present my idea on how the most important settings involved in the PP side of product costing should have been arranged onto a single screen, as a way to allow a costing analyst or other curious person to more easily understand what’s going on, and not to get so completely confused due to the currently hidden role of our two friends, the origin and the parameter.
Basic, Everyday Product Costing Question
My first question should be easy for people with good math skills, even if they have never seen an R/3 system. Suppose you have a factory.
To manufacture 500 pieces of finished good M-12345, how much will the direct labor end up costing you?
Too many undefined variables? Maybe I need to supply a bit more information.
Suppose that your factory requires four hours of one employee’s time operating machine A to manufacture 1,000 pieces of M-12345.
Need more constants? For lot size quantities of fewer than 1,000 pieces, the operator’s time goes down proportionately. For example, machine A must run 0.4 hours when the desired output quantity is 100 pieces. However, any new production run always begins with a half hour of preparation time.
If I now tell you that your internal-labor cost rate at machine A is $20 per hour, then most of you will arrive at the answer shown in Figure 1.
General Equation:
(fixed quantity hours + variable quantity hours) x rate per hour = cost
Fixed quantity hours calculation:
preparation time x number of new runs = hours
i.e., (0.5 hours x 1 run) = 0.5 hours
Variable quantity hours calculation:
(actual units of finished good/base units of finished good) x machine speed@base = hours
i.e., (500 pieces/1,000 pieces) x 4 hours for 1,000 pieces = 2 hours
Labor cost calculation:
(0.5 hours + 2 hours) x $20 per hour = $50
Figure 1R/3 Has a Harder Question to Answer: the Origin and the Parameter
The question I posed in the previous section ultimately became easy to answer once I replaced enough of the undefined variables with unambiguous constants. Of course, not every manufacturing site will have the simple relationships for every finished good that I offered in my example (e.g., four hours for 1,000 units and proportionately less time for 500 units), but that’s no big deal to R/3. As long as you know the exact value of quantity variable X, the exact value of quantity variable Y, and the mathematical relationship between X and Y, you can easily represent that in the system as a custom equation.
In the case of its R/3 product costing functionality, SAP wanted to offer you one extra layer of variables that made sense to PP folks, but that seemed to take most FI/CO folks by surprise: where to look for and find quantity values. It is not true that there will be only one place in R/3 from which to read a setup time/quantity, for example.
I want to show you three screenprints from an R/3 system. Each is of a master data screen that can potentially be used to store quantity values: the work center (Figure 2), the "general" section of a routing’s operation (Figure 3), and the "standard values" section of a routing’s operation (Figure 4).

Figure 2
The work center master

Figure 3
The "general" section of the routing operation master
Notice in these screenprints how many different fields can be used to store a quantity of one kind or another that could, in theory, represent the setup time required by the operator in my machine A example. They are the Formula Constants fields from Figure 2; the Maximum, Min., and Std. wait, queue, and move time fields from Figure 3; and the Setup, Machine, and Labor fields from Figure 4.

Figure 4
The "standard values" section of the routing operation master
Each kind of quantity you might want to use must be declared in the system as a variable. The SAP vocabulary word for these quantity variables is "parameter." The SAP-delivered parameters have confusing names such as SAPC00 and SAP_01. Figure 5 shows a list of standard parameters. Ignore the codes and instead focus on their role as PP quantity variables, and you won’t be confused.

Figure 5
A list of standard PP module parameters for calculating quantities
The way to instruct R/3 as to which specific field you want it to look at when deriving any particular variable value (such as a setup time/quantity) is through the Origin setting inside of the Parameter. In Figure 6, notice how R/3 offers seven different places from which you can direct it to look for a specific value: the Work center constant (setting 1) vs. the General operation value for the routing’s operation (blank setting), for example.1

Figure 6
The Origin indicates a location for R/3 to look for a specific value
Put It All on One Screen
The fact that your SAP R/3 system has things such as origins and parameters doesn’t by itself confuse students learning about product costing. The fact that these two important settings are hidden causes a painful learning curve. Notice in the Work Center: Cost Center Assignment screen shown in Figure 7 how both the Origin and Parameter settings are completely hidden from view.

Figure 7
The work center master’s costing screen
Worse, note that the Setup, Machine, and Labor texts you see are coming from the parameters contained within the Standard value key setting on the Work Center: Basic Data screen (see Figures 8 and 9). Since this screen is also hidden (i.e., not visible from the costing screen), and since what you see is not the parameter code but the parameter text, this adds confusion for people who are trying to figure out how to interpret what they are viewing.

Figure 8
The basic data screen of the work center master

Figure 9
The parameters contained in the standard value key SAP2
If I were in charge of designing the PP integration to product costing, the work center master’s costing screen would bring the Origin and Parameter settings into plain view. With the entire equation right in your face, it’s harder to be confused! Figure 10 shows my idea for how the screen could be designed.
Blending Station: Work Center # 1420 Work Center’s Cost Center = # 4240 Text Description | ORIGIN: | Also Apply a Formula? | Quantity Formula | Get Cost Rate from Activity Type # | Value Source | Field Name | | | | | | | Fixed Qty: Set-Up Time | Work Center | “ZWNOR” | No | —— | 1420 | Variable Qty: Machine Time | Routing Standards | Std Qty #2 | Yes | SAP002 | 1420 | Variable Qty: Labor Time | Order Header | Ordered Qty | Yes | ZMIN3 | 1420 | |
|
Figure 10 Avoid confusion by including the Origin setting on the work center master
1Origin2Standard valuesParameterOrigin13Standard valuesStandard value keyStandard valuesStandard value keyStandard valuesStandard value keycananyallStandard valuesOrigin2 Standard value keyStandard value key Lars Sondergaard
Born in Denmark, Lars Sondergaard has been working with SAP software as an on-site consultant in both Europe and the U.S. since 1995, specializing in all aspects of the PP module and the variant configurator. He is also an avid "catch-and-release" fly fisherman, and semi-professional beer taster.
You may contact the author at LSondergaard@icm.de.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.