You are on page 1of 215




Sean Eler

Quick Guide to SAP CO-PA

(Profitability Analysis)
| Successfully implementing a
contribution margin analysis

- Optimizing planning tools

- Defining the actual value flow

- Includes 5 wideo tutorials

Stefan Eifler:
Quick Guide to SAP COPA Profitability Analysis

9783943546132 (kindle)
9783943546149 (epub)


Martin Munzel


Tracey Duffy

Cover design:

Philip Esch, Martin Munzel

Cover photo:


All rights reserved.

1. Edition 2013, Gleichen
Espresso Tutorials GmbH
This work is subject to copyright in its entirety. All rights
reserved, especially the rights of translation, recital,
reproduction, and duplication. Espresso Tutorials GmbH,
Zum Gelenberg 11, 37130 Gleichen, Germany.
Regardless of the care taken in producing texts and
illustrations, the publisher, the authors, and editors accept
no legal liability whatsoever for possible mistakes and their
Feedback: We are happy to receive any questions or
comments you may have. Please send any feedback to:

For my family

Table Of Contents
1 Introduction: COPA the Supreme Module
2 Structures in COPA
2.1 The Intent and Purpose of COPA
2.2 The Operating Concern
2.3 Master Data in COPA
2.4 CostingBased or AccountBased Profitability
2.5 Setting Up an Example Operating Concern
2.5.1 Description of the Main Example Data
2.5.2 Customizing the Example Operating Concern
Maintaining operating concerns
Assigning the operating concern
3 Characteristic Derivations
3.1 What Are Characteristic Derivations?
3.2 Methods of Characteristic Derivation
3.3 Characteristic Derivations for Our Example
3.3.1 Assignment
3.3.2 Table Lookup
3.3.3 SAP Enhancement
3.3.4 Initialization
3.3.5 Derivation Rule
4 Valuation
4.1 Valuation Types

4.1.1 Valuation via Material Costing

Define Access to Standard Cost Estimates
Assign Costing Keys to Material Types
Assign Value Fields
4.1.2 Valuation via a Pricing Procedure in SD or COPA
4.1.3 Valuation via User Exits
5 Actual Value Flows
5.1 The Most Important Interface to COPA: The SD
5.1.1 Handling of Quantity Fields
5.1.2 Transferring Invoice Data
5.1.3 Transferring Incoming Sales Orders
5.1.4 SD Interface for Our Example Data
5.1.5 Customizing the SD Interface
5.2 Settlement to COPA
5.2.1 Customizing the Settlement to COPA for Our
5.3 FI Interface
5.4 Cost Center Assessments
5.5 Direct Line Item Corrections in COPA
5.5.1 Types of Errors and How to Correct Them
5.5.2 Security Measures
5.5.3 Simplifications in Line Item Corrections
6 Planning in COPA
6.1 Shortening the Planning Process without Losing

6.1.1 Reducing the Planning Effort Tip 1

6.1.2 Reducing the Planning Effort Tip 2
6.1.3 Reducing the Planning Effort Tip 3
6.2 Fast Yearly Planning in Detail
6.2.1 Recording Yearly Planned Quantities
6.2.2 Valuation of Planned Sales Quantities
6.2.3 Adjustment Phase
6.3 Planned Cost Center Assessments
6.4 Distributing the Planning over Months
6.5 Planning Our SAP Example
6.5.1 Plan Version and Planning Valuation Strategy
6.5.2 User Exit for Planning Valuation
6.5.3 Manual Planning Layout
6.5.4 Automatic
User Exit ZXKKEU14

7 Dynamic Reporting
7.1 Information System Components
7.2 Example Customizing of Report Components
7.2.1 Key Figure Scheme
7.2.2 Report Variables
7.2.3 Profitability Report Forms
7.3 Drilldown Reports
7.4 Line Item Layouts
7.5 Structure of a Profitability Report for Our Example
7.6 Example of Dynamic Reporting

8 Tools in COPA
8.1 Summarization Levels
8.1.1 Example Customizing for a Summarization Level
8.1.2 Activating Summarization Levels
8.2 Analyzing Value Flows
8.2.1 Checking the Customizing Settings
Value Field Analysis
Overview of Valuation
Overview of Derivation
Report Overview
Summarization Level Overview
8.2.2 Simulating Documents
9 Closing Words
A The Author
C Disclaimer

1 Introduction: COPA
the Supreme Module
If you work in a company that uses SAP R/3 or, more
recently, SAP ERP, or in a company that is intending to
implement SAP, you may have already encountered CO
This might be because you work in accounting (finance,
controlling) and your tasks therefore involve COPA
automatically. However, if you work in logisticsfor
example, in sales and distribution, materials management,
or in productionyou may also have heard of COPA, even
if only in discussions or meetings with the controllers
responsible for COPA. Alternatively, you may be a junior or
senior consultant in an SAP consultancy and receive a
request to implement COPA in a company or to support the
implementation in an advisory capacity. At this point at the
latest this book will help you: I will not only explain what CO
PA is, but, using an ongoing example, I will also show you
how to implement COPA and how to work with it. However,
this book does not claim to cover all of the tools available in
COPA: there are sufficient specialist books available that
can do that. This book will give you tips and show you tricks
for implementing a simple COPA in your company, and will
show you how to work with it effectively after
You may ask what gives me the right to make such a claim
for this book. To answer your question, as a trained
economist, I have many years of experience as an external
SAP consultant with a focus on COPA including at
CocaCola, Veltins, and Schneider Weie. I also have many
years of experience as an inhouse consultant and

controller at Berentzen. These positions have enabled me to

gather a lot of experience in using COPA, as well as
consultancy expertise. I am currently employed as an in
house consultant at Sartorius AG. Therefore, I have
extensive knowledge of both sides and wish to share my
wealth of experience.
You will probably be wondering when I am going to get to
the point? Well, I wont keep you in suspense any longer
let me explain the term COPA: the SAP system is divided
up into numerous individual modules, including FI (Financial
Accounting), CO (Controlling), SD (Sales and Distribution),
MM (Materials Management), and PP (Production Planning
and Control) to name just a few. In turn, each of these
modules has its own individual submodules: for example,
the CO module includes the submodules Overhead Cost
Controlling (COOM), which in turn covers cost center
accounting and internal orders, or Product Cost Accounting
(COPC). But the supreme module, not only in CO but
across the entire SAP system, is COPA Profitability
Analysis. Why is it the supreme module? Because it
represents the end point in the SAP system: it is where all
the threads from the SAP system come together.
For the fact that you have the pleasure of reading this book
at all, I am grateful to Espresso Tutorials and its two
managing directors, Martin Munzel and Jrg Siebert. I would
like to express my heartfelt thanks to them for giving me the
opportunity to share my experience and knowledge in CO
PA with you.
The examples in this book were created on an SAP system
at consolut. Many thanks also to Ms. Ulrike Peters for her
help with the successful cover design of this book.
In the text we use boxes to highlight important information.
Each box also has an icon to identify it more precisely:

Notes offer practical tips for dealing with

the respective topic.

Examples illustrate a topic more clearly.

Warnings draw your attention to possible

sources of error or stumbling blocks in
connection with a topic.

Press on a video icon to play a video.

2 Structures in COPA
In this chapter I will firstly address the actual purpose
of COPA. I will then explain the organizational
structures and master data that are required for COPA.
The chapter closes with a presentation of the definition
of an example operating concern that is the basis for all
further examples in this book.

2.1 The Intent and Purpose of COPA

In addition to mapping contribution margin accounting with
actual and planned figures, the purpose of COPA is to
answer various business questions, for example:
Which customer do Iearn the most money from?
Which products are the key to my business success?
Which specific products are successful with which
specific customers?
Was my last marketing campaign successful?
What effect has my new price strategy had on the
purchasing behavior of my customers?
Should I grant a customer further discounts to increase
the sales quantity?
Are my contribution margins in a business area
sufficient to cover the fixed costs assigned there?
What do I give my customers in sales promotions
and does this lead to a higher sales quantity?
Where do my deviations to planned figures come from?
These are just some of the questions that COPA can

answer provided you have customized it correctly.

As you will recognize from the various questions, COPA is
designed as a sales controlling tool. In principle, however, it
can map all of the elements of contribution margin
accounting down to earnings before interest and tax (EBIT).
Which COPArelevant organizational structure is
advantageous here?
2.2 The Operating Concern
In an SAP system, the operating concern is the
organizational unit responsible for Profitability Analysis (CO
PA). What are organizational units in the SAP system? You
usually use organizational units to map your company
structure: you set up company codes for your independent
accounting units you create sales areas in SD you define
plants etc. for MM and PP. The entire remaining
customizing of your SAP system is based on this
organizational representation of your company structure.
The organizational structure is the backbone of your

Common error in practice

If you do not think through the
mapping of the organizational
structure in the SAP system
thoroughly from the very
beginning, meaning that you have
to make changes later, you will
have to check the customizing
that is based on this structure whenever you
make changes. SAP projects often take longer
and become unnecessarily expensive because
the management thinks about changes to
organizational structures during the SAP

implementation phase. The SAP implementation

is later deemed to have taken very long and been
too expensive, but in reality, it is the management
decisions that have caused the extended time
frame. Consultants, on the other hand, are very

In an operating concern, you define all operating concern

relevant master data that you need for your subsequent
work with COPA. You then assign the operating concern to
one or more controlling areas. Here I would recommend a
1:1 relationship i.e., assign the operating concern to only
one controlling area. You may wonder whether it makes
sense to define a 1:1 relationship here when you will want to
evaluate data across the group or company later on. Your
thinking is correct, but the clue is in the assignment of
controlling areas to company codes: a controlling area is the
organizational unit of the CO module you can assign one
or more company codes to one controlling area. To enable
you to perform evaluations across the group or company
(and not only in Excel or a business warehouse, which
would lead to further costs), you have to assign all of your
live company codes to one controlling area. You then
assign this controlling area to the operating concern. This
ensures that you can see not only your costs across the
group, but also your revenues, contribution margins, and of
course, your profit.

Anecdote/common error

A fellow consultant once told me

that he was called to a customer
who had already gone live with
SAP but was having problems
with his Report Writer reports.
The customer wanted to
evaluate his costs across the
reports did not allow him to do this.
Unfortunately my colleague could not help him:
the customer had set up one controlling area for
each company code, meaning that he could only
see the costs of this company code in the Report
Writer reports for this controlling area. This
example shows how important it is to think about
your organizational structure in the SAP system
thoroughly in advance.

However, to work with only one operating concern, all

controlling areas and company codes must work with the
same fiscal year variant, generally K4 (here, the fiscal year
corresponds to a calendar year with four special periods).
All company codes must also use the same chart of
In the next section I will explain the master data in COPA.
2.3 Master Data in COPA
There are two forms of Profitability Analysis: costingbased
and accountbased Profitability Analysis. The costingbased
form works with value fields and the accountbased form
works with accounts.
As the name indicates, a value field is a field in which
values are entered. For example, for each line of
contribution margin accounting (unless the line can be
calculated as a formula), you define a value field. This field
is then filled with data automatically, regardless of whether

you are compiling actual or planned figures. In the same

way, quantity fields, as the name indicates, are filled with
quantities, e.g., sales quantities.
Mapping contribution margin accounting is part of
management accounting. In contrast to financial accounting,
there are no legal requirements as to the presentation of
contribution margin accounting each company maps its
structure in accordance with its own needs. This
individuality in mapping contribution margin accounting is
(naturally) possible in our supreme module COPA.
In accountbased Profitability Analysis, you would define
your contribution margin structure using accounts that you
also create as cost elements.
Both forms of Profitability Analysis work with characteristics.
But what is a characteristic? You use characteristics to
enter selections for your Profitability Analysis dataset. SAP
has a number of predefined characteristics, such as
company code, sales organization, distribution channel,
customer, or product, to name just a few. You can also
define characteristics that are important for control in your
company yourself. For example, if you want to look at the
data of customer XY in a period to see whether he
purchased products from product group 4711, you can use
the characteristics to select your data and present it in
reports. You will see not only the sales quantity and the
sales, but also all costs that you can directly assign to this
customer and the related products, product groups etc. We
will look at this more closely later on in the book.
2.4 CostingBased or AccountBased Profitability
There are companies that use both forms of Profitability
Analysis, but on a longterm basis, they often decide to use
only costingbased Profitability Analysis: it certainly meets
the requirements sufficiently. In contrast, the accountbased

form attempts to build a bridge to the operating profit of the

profit and loss statement (P&L), and is therefore a type of
additional control instrument. Do you really have to subject
yourself to the additional onetime and subsequent ongoing
effort involved in setting up accountbased Profitability
Analysis? Just to confirm the operating profit of the P&L? In
my opinion, you do not have to do this particularly if you
also use Profit Center Accounting, which performs this
control function anyway.
In every company there are business transactions that have
to be posted automatically in FI. Normally, you will have
defined the related controllingrelevant account assignment
via the account determination, substitution, or validation
automatically so that there is no interruption to automatic
runs. COPA takes priority over all other controllingrelevant
account assignments: it is real the other account
assignments are only statistical. Automated account
assignment of a profitability segment (as the controlling
relevant account assignment to Profitability Analysis is
known) could take place at best at a high, aggregated level.
But which additional information do you have in account
based Profitability Analysis that you do not already have in
Profit Center Accounting? If you use accountbased
Profitability Analysis, you also need large volumes of
memory storage. Believe me, your SAP Basis support
colleagues will not be your best friends, and at the latest
when you have to archive your data, you will be the one with
the greatest storage requirement of all (I speak from
experience). When defining the operating concern therefore,
use the costingbased form and create the value fields and
characteristics that you need in your COPA. Here too, you
should think thoroughly beforehand about which
characteristics and value fields you need. Changing a live
operating concern later on is not easy. In my previous work,
I have only done this for release upgrades or other SAP
new starts. If you change or extend the operating concern in
a live system, you run the risk of having to import your

previous data backup and the entire days work of your SAP
colleagues having to be repeated.
In the further course of this book, I restrict myself to the
description and setup of the costingbased form of
Profitability Analysis.
2.5 Setting Up an Example Operating Concern
Now we will set up COPA for a company that manufactures
products that are initially stored before they are sold to
customers (maketostock (MTS) process).
2.5.1 Description of the Main Example Data

For the MTS process, most customers belong to trading

groups there are also small and large customers who do
not necessarily belong to large customer constellations.
Which characteristics that you can use later for data
selection can we define from this small amount of
On one hand, SAP provides default fixed characteristics,
such as the controlling area, company code, etc. I have
listed the most important of these in Table 2.1. They also
appear in our example.
Fixed characteristic

Value(s) in the example

Controlling area

ET01 (E. T. Company)

Company code

ET11 (E. T. Company)

Sales organization

ET15 (E. T. Company)

Distribution channel

MTS process 01




ET11 (E. T. Company)


K1, K2, , K6


A1, A2, , A6

Record type (indicates at a

later stage where the data
comes from)


Table 2.1: Examples of fixed characteristics and their values

For an overview of the userdefined characteristics, that is,

those that you can define yourself, see Table 2.2.
Userdefined characteristic

Value(s) in the example

Customer hierarchy 1

KH11, KH12

Customer hierarchy 2

KH21, KH22, KH23

Customer hierarchy 3

K1, , K6

Customer group

KG1, KG2, KG3

Sales employee

50995 81000

Kind of product

PA1, PA2

Product group

PG1, PG2, PG3

Table 2.2: Examples of userdefined characteristics and their values

For our example company I will use the contribution margin

structure as presented in Table 2.3. As you can see, the
individual lines represent value fields that I have shown in
the second column.
Simplified contribution margin structure

Value field/formula


Value field ERLOS

/ Other Discounts

Value field RABAT

= Invoice Sales


/ Cash Discount

Value field VV070

/ Annual Rebates

Value field BONUS

= Net Sales


/ Outgoing Freight

Value field VV100

/ Material Input

Value field VV150

/ Production Labor. Var.

Value field VV180

= Contribution Margin 1


/ General Market. Costs

Value field VV380

/ Sales Promotion

Value field VVVKF

= Contribution Margin 2


/ Fixed Costs

Value field VVFIX

= Operating Profit


Table 2.3: Contribution margin structure

In addition to the value fields above, our example company

requires the quantity fields shown in Table 2.4.
Quantity field

Technical name in our

operating concern

Sales Quantity


Alternative Quantity


Table 2.4: Quantity fields used

2.5.2 Customizing the Example Operating Concern

Now we want to define the operating concern described

above in the SAP system.
Maintaining operating concerns

As already stated, when you create an operating concern,

the system generates the fixed characteristics automatically,
meaning that you do not have to do anything for these when
you define the operating concern. However, you do have to
maintain the userdefined characteristics that you want to
see, and the value fields that you want to define.
First you have to define your operating concern. Navigate to
to navigate to the
Implementation Guide.

Transaction codes
Instead of following the menu
path, you can enter transaction
code SPRO. Whenever you enter
a transaction, always place /N in
front of the code itself the
transaction then appears on a
new screen. Therefore, to access
customizing, enter /NSPRO.


OPERATING CONCERN, give your operating concern a name:
in our example, this is Z111. Once you have added the
name, place a checkmark next to the form that the operating
concern should take: in our example, we are only looking at
the costingbased form. Save your entries. Press
tab. Using the
button, from the default characteristics,
transfer those characteristics that you want to use (see
Figure 2.1).

Copyright SAP AG. All rights reserved.

Figure 2.1: Userdefined characteristics for operating concern Z111

Proceed in the same way on the VALUE FIELDS tab to assign

the value fields required (see Figure 2.2).

Copyright SAP AG. All rights reserved.

Figure 2.2: Value fields for operating concern Z111

If the template tables do not contain all of the characteristics

or value fields that you want to use, you have to define and
activate those that you want beforehand.
To define and activate the characteristics, return to
customizing via the Implementation Guide and choose
Give your new characteristic a name. New characteristics
always begin with WW" new value fields begin with VV.
The new characteristics and value fields must have five
characters. For our example, in Figure 2.3 let us look at
characteristic WWPGR, which we want to use later to
present product groups. By pressing CREATE/CHANGE, we
navigate to maintenance mode for the characteristic.

Copyright SAP AG. All rights reserved.

Figure 2.3: Initial screen for maintaining characteristics

When creating characteristics, you have to decide whether

you want to create an existing field from an SAP table as a
characteristic, or alternatively, whether you want to define a
completely new characteristic with separate value
maintenance. If you decide for the latter (as in our example),
you also have to specify the description of the characteristic.
Once you have done this, save and activate your new
characteristic. The system automatically creates a check
table for your new characteristic. Figure 2.4 shows the
results of your work.

Copyright SAP AG. All rights reserved.

Figure 2.4: The result of characteristics maintenance

The procedure for defining value fields is the same as that

for characteristics. New value fields always begin with VV.
When you define a value field, you have to decide whether it
will later be used to represent a quantity or an amount.
Once you have defined new characteristics and value fields,
you can use them when you maintain your operating
concern to do this, assign them to the operating concern,
as explained above.
Now save your operating concern. The system creates new
structure tables that contain the data of the operating
concern, for example, the structure CE1Z111. Now press
the system executes a mass activation. If you press
Back (green arrow pointing left), the question shown in
Figure 2.5 appears.

Copyright SAP AG. All rights reserved.

Figure 2.5: Generating the environment

Confirm with YES. The system generates client

independent and clientspecific objects and the following

Make sure that you also maintain the attributes of the

operating concern. For our example, we are using the
operating concern currency EUR and fiscal year variant K4
(12 periods plus four special periods).
Once you have completed the maintenance of the operating
concern, all of the traffic lights visible should be green (on
the ENVIRONMENT tab as well) see Figure 2.6 and
Figure 2.7.

Copyright SAP AG. All rights reserved.

Figure 2.6: Operating concern green light

Copyright SAP AG. All rights reserved.

Figure 2.7: Green lights for the operating concern environment

Assigning the operating concern

The operating concern is an organizational unit in the SAP

system. Therefore, it must be embedded in the
organizational structures of the SAP system. For our simple
example, we will use one company code ET11, one
controlling area ET01, and the operating concern we have
just maintained, Z111. In the Implementation Guide, under
assign the company code to the controlling area. Then
assign the controlling area to the operating concern (see
also Figure 2.8 and Figure 2.9).

Copyright SAP AG. All rights reserved.

Figure 2.8: Path for assigning the controlling area to the operating concern

Copyright SAP AG. All rights reserved.

Figure 2.9: Assignment of Z111 to ET01

By assigning the operating concern to the controlling area,

you make the operating concern active. You can also see
this assignment under the path shown in Figure 2.10.

Copyright SAP AG. All rights reserved.

Figure 2.10: Path in the Implementation Guide for activating the operating

When you execute the step ACTIVATE PROFITABILITY

ANALYSIS, the system takes you to an extended screen for
assigning the operating concern to the controlling area (see
Figure 2.11).

Copyright SAP AG. All rights reserved.

Figure 2.11: Profitability Analysis active flag

The ACTIVE STATUS 2 means that costingbased

Profitability Analysis is active 4 would mean that both
costingbased and accountbased Profitability Analysis are
activated. If the ACTIVE STATUS column is blank, the
operating concern is not active. See also Figure 2.12.

Copyright SAP AG. All rights reserved.

Figure 2.12: Profitability Analysis active flag

In the video below, you can see a demonstration of how to

create your own characteristics and value fields, and how to
set up an operating concern with them.

Video 1: Creating an Operating Concern

Note: Should your reading device not be able to show this

video, you can use your computer to watch it on the
internet. To do this, head to our web page at
In Chapter 2, I have given you some information about the
structures and master data in COPA. In the following
chapters, we will continue to fill the operating concern that
we have created. I will show you how to derive defined
characteristics (Chapter 3), how to valuate your value fields
(Chapter 4), how to fill your value fields with actual (Chapter
5) or planned (Chapter 6) figures, and finally, how you can
present the results of your efforts (Chapter 7).

3 Characteristic Derivations
In this chapter we will look at how to fill and derive
characteristics. I will explain what characteristic
derivations are, and then show you five possible forms
of characteristic derivation for our ongoing example.
3.1 What Are Characteristic Derivations?
If you ask yourself what the deepest level is at which it
makes sense to evaluate costs and revenues in COPA, you
will arrive at the answer that the deepest level is achieved
with the combination customer/product. What does this
mean? Let us look at an example: you sell your product A1
to the corner store, customer K1. You can then create, for
example, an analysis or contribution margin accounting for
product A1 at customer K1. If you want to see the data at a
somewhat higher level, you could, for example, report on
customer group KG1, to which customer K1 belongs. But
how does the data get to customer group KG1? All you
have done, for example, is issue an invoice to customer K1,
who purchased product A1. The answer is characteristic
derivations. When the posting was entered, the system
derived customer group KG1 from the customer master
record of customer K1 and filled it as an additional
characteristic. If, for example, you now call up a report using
the selection customer group KG1, you will see the analog
data of customer K1. Reporting at higher aggregated levels
is obviously interesting when numerous individual
documents have been posted to COPA and you want to
evaluate these at a higher level. Characteristic derivations
are performed for all COPArelevant transactions.
3.2 Methods of Characteristic Derivation

Depending on the characteristics that you have decided to

use in the future, COPA allows different methods of
deriving these characteristics or, more precisely, of also
specifying the values for the characteristics when you post
documents. The following methods are available:
Table lookup
SAP enhancement
Derivation rule
I will explain the meaning of these methods in the next
section using our example data.
You can also process the defined characteristic derivations
stepbystep in a logical sequence in a characteristic
derivation strategy.
What is a characteristic derivation strategy? For
characteristic derivation, COPA enables you to execute all
derivation steps in a logical sequence. You create a
characteristic derivation strategy in customizing. The path is
table that appears is initially empty, as the system does not
know yet what you want to derive. Stepbystep you can
define the logical sequence that the SAP system is to follow
to derive the characteristics. For example, you can define
dependencies in your strategy, such as: first derive
characteristic XY then derive characteristic YZ based on
characteristic XY. Figure 3.1 shows an example of a
characteristic derivation strategy table.

Copyright SAP AG. All rights reserved.

Figure 3.1: Example of a characteristic derivation strategy

The characteristic derivation strategy is a mandatory

prerequisite for characteristic derivation in COPA. The
derivation does not work without this strategy.
In case characteristic derivation steps are to be brought
forward at any point, in our example we start with step 16.
3.3 Characteristic Derivations for Our Example
In the following table, for our example data we have
described which characteristics are to be derived and with
which characteristic values. Via the customer master record,
we want to derive three customer hierarchy characteristics
as well as the customer group and the sales employee of
the customer, as shown in Table 3.1.
Customer Cust.
level 1

level 2

level 3

Cust. Sales





































Table 3.1: Characteristic assignments for customers

3.3.1 Assignment

Firstly, we derive the customer hierarchy for the three

characteristics Customer hierarchy 1, 2, and 3 from the
customer master record via assignment if you use the
SAP ERP module SD (Sales and Distribution), you can
create these customer hierarchies in SD.
Excursus: How do you maintain a customer hierarchy in
SD? You can arrange your customers hierarchically using
customer hierarchies. In accordance with our example
above, our customer K1 is reflected at customer hierarchy
level 3. The customer belongs to customer hierarchy KH21
at level 2, and in turn to customer hierarchy KH11 at level 1.
You can maintain customer hierarchies via LOGISTICS
transaction VDH1N. The selection screen is shown in Figure

Copyright SAP AG. All rights reserved.

Figure 3.2: Editing customer hierarchies

In our example we maintain the customer hierarchy for type

A (you can define different types for standard hierarchies,
type A is the SAP standard) and define a validity date for
which we want to edit the customer hierarchy. For example,
we maintain the hierarchy for customer K1.

Hierarchy nodes

You must first create all nodes

that you want to reflect as
hierarchy nodes via K1 as
customer masters in the sales
area beforehand (in the current
example, KH11 and KH21).

If you execute according to the selection above, you can

use the CREATE or EDIT buttons to maintain the customer
hierarchy for customer K1 (see Figure 3.3).

Copyright SAP AG. All rights reserved.

Figure 3.3: Maintaining the customer hierarchy for customer K1

Once you have maintained the customer hierarchies for all

of our end customers K1 to K6, your screen appears as
shown in Figure 3.4.

Copyright SAP AG. All rights reserved.

Figure 3.4: Complete customer hierarchy for our example

Is the customer hierarchy maintained in SD sufficient for

COPA? No first you have to do the
1. Define a derivation step in your characteristic derivation
2. Fill the HIERARCHY ASSIGNMENT field in the general data

of the customer master.

To define a derivation step in characteristic derivation
maintenance, create a new step and then select
DERIVATION RULES. In detail, the strategy step appears
as shown in Figure 3.5.

Copyright SAP AG. All rights reserved.

Figure 3.5: Detail derivation step of a customer hierarchy

The definition contains source fields and target fields. The

source has to be defined in this way because we want to
derive the hierarchy from the customer master. In SD, a
customer is always created for a sales area. The sales area
always consists of the three fields SALES ORGANIZATION,

fields are also in the source.

The correct hierarchy level of a customer is transferred to
the GENERAL DATA of the customer master via the
HIERARCHY ASSIGNMENT field (see Figure 3.6).

Copyright SAP AG. All rights reserved.

Figure 3.6: Hierarchy assignment field in the customer master

Each customer hierarchy is therefore created as a normal

customer master. It is the additional maintenance to
customer hierarchy type A in the SD customer hierarchy
and the filling of the HIERARCHY ASSIGNMENT field that
distinguishes this customer master as a customer hierarchy.
Since we only want to work with three customer hierarchy
levels in our example, our original customer masters K1 to
K6 also represent the lowest customer hierarchy level here.
In the customer master, they receive hierarchy assignment
number 3. Customer KH11 was also created as a customer
master and also receives 1 in the HIERARCHY ASSIGNMENT
field, and so on.
To check that the configuration is correct, simulate a
business transaction using transaction KE21. You can use
this transaction to create a line item in COPA manually

to do this, as a first step enter the master data from which

the derivation should take place, for example, customer,
sales organization, etc. (see Figure 3.7).

Copyright SAP AG. All rights reserved.

Figure 3.7: Billing document header data of the simulation document

Then press DERIVATION: you will see that for customer K1,
including Logistics data, you can derive the customer
hierarchy to all three levels, as prescribed in Section 3.3
(see Figure 3.8).

Copyright SAP AG. All rights reserved.

Figure 3.8: Evidence of the derivation of the SD customer hierarchy in CO


Once the derivation step is complete, our characteristic

derivation strategy looks as shown in Figure 3.9. In case
characteristic derivation steps are to be brought forward at
any point, in our example we start with step 16.

Copyright SAP AG. All rights reserved.

Figure 3.9: Derivation step for deriving the customer hierarchy

3.3.2 Table Lookup

As an example for table lookup, let us select characteristics

that can be derived from the product master. The basic data
view of a product master, which you create in the SAP ERP
module MM, contains the PRODUCT HIERARCHY field (the
technical name of this field is MARAPRDHA). This field can
contain up to 18 characters. As per Section 2.5.1, we want
to derive two characteristics from the product master: kind
of product and product group. According to their definition,
both characteristics should have three characters each. For
example, the PRODUCT HIERARCHY field of product A1
contains the combination PA1PG2. Within the framework of
table lookup, the first three characters of the PRODUCT
HIERARCHY table field are assigned to the target
characteristic kind of product, and the last three characters
to the target characteristic product group. Thus, product A1
belongs to kind of product PA1 and product group PG2.
Provided the PRODUCT HIERARCHY field for product master
A1 is not changed, for each posting for product A1, these
characteristics are also derived and are available, for
example, for evaluations. If the field is changed, the COPA
characteristics are provided with new characteristic values
from the date of the change.
I will now show you the required steps in customizing. We
will proceed from the starting position shown in Table 3.2.
Product Kind of product Product group


















Table 3.2: Example for a product hierarchy

In the basic data view of products 1 to 6, the PRODUCT

HIERARCHY field was filled by your master data team for
example, for product A1, with the value PA1PG20000 (see
Figure 3.10).

Copyright SAP AG. All rights reserved.

Figure 3.10: Product hierarchy in material master

Using the characteristic derivation strategy described in

Section 3.3.1, we now want to read, for example, the
PRODUCT HIERARCHY field for product A1 with its value
PA1PG20000 such that the first three characters are read
for the characteristic kind of product (i.e., PA1), and for the
characteristic product group, the characters 46, i.e., PG2.
Since the PRODUCT HIERARCHY field can be up to 18
characters long, but we only need the first six characters in
our example, the remaining characters in the example are
filled with 0."
We will now define a further derivation step in the COPA

customizing: in the example, step 17 (see Figure 3.11).

Copyright SAP AG. All rights reserved.

Figure 3.11: Product hierarchy derivation step

We can use the magnifying glass to look at the detail of this

derivation step (see Figure 3.12). Here too you must define
a source and a target. We can find the source in the basic
data view of the material master. The relevant SAP table is
MARA. The COPA characteristic product (ARTNR)
corresponds to the material number of the material master
. In the target, we assign our userdefined characteristics
of the material master (MARAPRDHA) and state that
characteristic WWPAR is to be read from the first three
characters of the field MARAPRDHA
and characteristic
WWPGR from characters four to six (+3(3))

Copyright SAP AG. All rights reserved.

Figure 3.12: Detail derivation step of a product hierarchy

Therefore, for product A1, COPA reads PA1 for the

characteristic kind of product and PG2 for the characteristic
product group. But what do PA1 and PG2 mean? When we
created operating concern Z111, we defined these two
characteristics freely and with no template table. Therefore,
we have to make the corresponding characteristic values
known to COPA. We do this via transaction KES1 or via the
path in the application menu: ACCOUNTING CONTROLLING

Copyright SAP AG. All rights reserved.

Figure 3.13: Maintenance of characteristic values

By doubleclicking the respective characteristics, you can

maintain the values for that characteristic (see Figure 3.14
and Figure 3.15).

Copyright SAP AG. All rights reserved.

Figure 3.14: Characteristic values of the characteristic kind of product

Copyright SAP AG. All rights reserved.

Figure 3.15: Characteristic values of the characteristic product group

If you now create a COPA document, you can see that the
product hierarchies for your new characteristics are derived
(again, via simulation using transaction KE21), see Figure
3.16 and Figure 3.17.

Copyright SAP AG. All rights reserved.

Figure 3.16: Billing document item data of the simulation document

Copyright SAP AG. All rights reserved.

Figure 3.17: Evidence of the derivation of the product hierarchy in COPA

In the following video, you have the opportunity to watch in

detail how to create a characteristic derivation.

Video 2: Characteristic derivation

Note: Should your reading device not be able to show this

video, you can use your computer to watch it on the
internet. To do this, head to our web page at
3.3.3 SAP Enhancement

In almost every SAP module you can maintain user exits.

Here, SAP offers the option of finding exits in the standard
SAP software exits in which a user can install his own
programming using the ABAP programming language
without changing the SAP standard software and potentially
endangering the SAP warranty. Of course, this type of user
exit is also available in COPA. There is a user exit for
characteristic derivations that, with the normal standard
characteristic derivation methods, do not achieve the
objective. In our example, I had initially decided not to
describe a user exit for characteristic derivation I did not
want to confuse any COPA beginners or cause them to
stop reading at this point. If the information is too technical
for you, you can skip this chapter however, it may show
some new options for any interested users. I may also
excite your imagination...
As stated, we will also convert the sales quantities into
alternative quantities to enable comparison of the individual
products. The alternative quantity requires a quantity unit
that is not filled automatically. For our example we assume
that each product can be compared with other products by
means of the weight. Therefore, we choose KG (kilogram)
as the alternative quantity unit.
Now we have to give each sales product a conversion factor
for translating the base quantity unit into the alternative
quantity. We do this in the SAP module MM in the additional
specifications for a product. Via transaction MM02, go to the
BASIC DATA 1 view of the product and from there to the
additional data. Here, choose the UNITS OF MEASURE tab
the screen shown in Figure 3.18 appears.

Copyright SAP AG. All rights reserved.

Figure 3.18: Alternative quantity units for a product

Product A1 weighs 100 KG per item. For our user exit, this
means that the alternative quantity unit KG must be derived.
A COPA user exit is available in the customizing for CO
PA, under TOOLS SAP ENHANCEMENTS. Create a project
and assign component COPA0001. By doubleclicking the
component, navigate to the Include ZXKKEU11. If you have
a developer key in your system, you can fill this Include.
First maintain the header of the user exit analog to Figure

Copyright SAP AG. All rights reserved.

Figure 3.19: User exit header for characteristic derivation

in Figure 3.20.
Then insert
this with

Copyright SAP AG. All rights reserved.

Figure 3.20: User exit coding for deriving the quantity unit

To ensure that the user exit for deriving the quantity unit KG
is also found in your operating concern, you have to make
the user exit known in your characteristic derivation strategy
in step 19 (see Figure 3.21).

Copyright SAP AG. All rights reserved.

Figure 3.21: Enhancement of the characteristic derivation strategy for the

user exit

By doubleclicking line 19 you navigate to the detail screen

for this derivation step (see Figure 3.22).

Copyright SAP AG. All rights reserved.

Figure 3.22: Derivation of user exit I

We are accessing the quantity units of the product master

and therefore this master must be named in the source. The
objective of the derivation step and of course the user exit is
to give the quantity field VVAMG that we have defined a
quantity unit.
In the coding, we specified the derivation step AMG (see
the coding in Figure 3.20 CASE I_STEP_ID"). We

specify this step on the ATTRIBUTES tab (see Figure 3.23).

Copyright SAP AG. All rights reserved.

Figure 3.23: Derivation of the user exit attributes

Check whether the derivation works (using KE21, for

example). The aim is for the quantity unit to be derived for
the ALTERNATIVE QUANTITY UNIT field. You can see the
evidence in Figure 3.24.

Copyright SAP AG. All rights reserved.

Figure 3.24: Evidence of the correct derivation of the alternative quantity

unit via the user exit

3.3.4 Initialization

If you want to use auxiliary characteristics or fields to derive

characteristics, you can delete these characteristic values
again before a further characteristic derivation by means of
When are auxiliary fields useful? If, for example, you want to
derive a specific characteristic from an SAP field, but this
characteristic is to have different characteristic values to the
SAP field, you can use auxiliary fields. Usually, these are
global variables, for example, USERTEMP1. In the first
step, you create a derivation from the SAP field to the
auxiliary variable USERTEMP1. In a second step, you
create a derivation from your auxiliary field USERTEMP1 to
the characteristic that is to be filled. Now you can add a third
derivation step that initializes your auxiliary field
USERTEMP1 so that it is empty again for the next
characteristic derivation and can accept new characteristic
values. For our example, however, we will not create a
special initialization.
3.3.5 Derivation Rule

In practice, derivation rules are often used to derive a

characteristic from a characteristic value of another
characteristic. This type of derivation is often applied, for
example, to derive a higher level characteristic, such as the
continent (e.g., Europe) from the characteristic value (here
Germany) of the country characteristic. However, in our
simple example, we merely want to derive the customer
group characteristic from the customer characteristic via
derivation rules, for example: customer group KG2 is
derived from customer K3.
I will show you the derivation via derivation rules for the
customer group characteristic (userdefined). First we have
to define a step (here step 18) in the derivation strategy
(see Figure 3.25).

Copyright SAP AG. All rights reserved.

Figure 3.25: Derivation strategy for derivation rules

After selecting line 18, click the magnifying glass

following screen appears (Figure 3.26).

. The

Copyright SAP AG. All rights reserved.

Figure 3.26: Example of a derivation rule for the customer group

As the source, the fixed characteristic customer is sufficient

as the target, enter the userdefined characteristic customer
group. As the target is a characteristic that you have defined
yourself, in the same way as for the characteristics kind of
product and product group described above, you have to
maintain characteristic values via transaction KES1 (see
Figure 3.27).

Copyright SAP AG. All rights reserved.

Figure 3.27: Rule entries for the customer group derivation rule

If you now create a COPA document, you will see that the
customer group characteristic (userdefined) was derived
with the characteristic value KG1 for customer K1 (again via
simulation with KE21, see Figure 3.28).

Copyright SAP AG. All rights reserved.

Figure 3.28: Evidence of the derivation of the customer group

Derivation rules
If, when defining the derivation
rules, you select in the attributes
that the system should always
report an error if no values are
found for the rule, the SAP
system will implement this
attribute strictly meaning that
under some circumstances, you will not create a
sales order or billing document. Therefore, check
whether the parameter Issue error message if no
value found is deactivated in the attributes (see
Figure 3.29).
It is also important that, regardless of which
method of derivation you choose, the
characteristic values for the userdefined
characteristics are defined in COPA, otherwise
an error will occur.

Copyright SAP AG. All rights reserved.

Figure 3.29: Attributes of the rule definition

In this chapter you have become familiar with the important

settings for characteristic derivation. In the next chapter, I
will explain how you can valuate value fields.

4 Valuation
In this chapter, we will look at the topic of valuation.
How can you valuate value fields? Again, I will use
examples to show you how to configure valuations.
You may be wondering when numbers will actually finally
appear in COPA. I will explain this in detail in Chapter 5.
However, COPA also gives you the option of creating
figures by valuation: in other words, entering values from a
valuation into your value fields. The great thing about the
costingbased form of Profitability Analysis is that you can
present not only posted values, but also costingbased or
planned figures. As part of a valuation strategy, you can
even define the point in time at which COPA is to perform
the valuation: when a document is posted, at the time of
manual planning, or at the time of automatic planning. Here,
manual planning really does mean manual and thus very
laborious but I will explain more about that in Chapter 6.
What is important is that, in contrast to characteristic
derivations, valuations are only performed for transactions
to which a valuation strategy is assigned. Characteristic
derivations run for every COPArelevant business
transaction even manual entry of COPA line items or the
transfer of data from an external data interface.
How do you perform valuations? What can you valuate
without having to post it? Here too, in the supreme module
COPA, you can customize the spectrum in which a
controller has free reign individually.
4.1 Valuation Types
There are three types of valuation:
Via material costing (also known as material cost

Via a pricing procedure in SD or COPA

Via user exits
I will now explain these in more detail in the following
4.1.1 Valuation via Material Costing

Every profitbased company will cost the products that it

sells. This type of costing, at least for determining the cost
of goods sold for a product, is offered by COPC, Product
Cost Accounting, in the SAP module CO. Within these
costings, you can create cost components that you can use
to differentiate the individual stages of your product
costings. Classic cost components are direct material costs
and material overhead costs, direct production costs and
production overhead costs, and external activities. These
cost components make up the cost of goods sold, that is,
the costs that you should achieve as a minimum when
selling your product if you want your business to survive in
the longterm. For the cost of goods sold, your finished
product stocks in the balance sheet are also valuated. Why
am I telling you all this? Because as part of the valuation via
material costing, you can access precisely these predefined
cost components by guiding the values determined to the
value fields intended.
This all sounds very theoretical let us make it clearer
using our example: in Section 2.5.1 we described a
contribution margin accounting that we want to reflect. It
contains the lines Material Costs and Production Costs. Let
us assume that you use COPC and have defined the
abovementioned cost components. The cost components
direct material costs and material overhead costs, as well as
external activities, were assigned to the value field
MATERIAL COSTS the direct production costs and
production overhead costs were assigned to the value field

Furthermore, for the product that you want to sell, you have
at least an earmarked, ideally released costing (released
costing means that the stock of this product in the balance
sheet is valuated with the price released for the product). In
your valuation strategy, you have defined that you want to
run material costing for this product at the time of invoicing
(invoice = billing document), for example. Each cost
component is then valuated with the billing document
quantity automatically, that is, multiplied and presented in
the respective value field in the contribution margin
accounting. If you think about my explanations in Section
3.1 again, not only are various value fields filled at the time
of invoicing, but in our example, also material and
production costs.
By adding the customer and product (they should be
included on the invoice as a minimum) and your special
characteristic derivations, you can also see these costs on
characteristics that, at first glance, have nothing to do with
product costing. For example, you see material or
production costs on the customer group characteristic.
Which material and production costs were created for
customer group KG1 in period XY? This is a question that
you will soon be able to answer at the push of a button if
you decide to use the supreme module COPA.
In customizing you first have to define a valuation strategy.
You then assign this strategy to one or more points of
valuation (I will explain what a point of valuation is later on
in this chapter).
A valuation strategy is essential if you want to undertake
valuations. Depending on how many steps you build in to
your valuation strategy, they are run for every COPA
valuation operation in the predefined sequence. For our
customizing, we will build up the valuation strategy
successively. Initially, we will only show the step that we
need for the valuation via material costing.
In our example customizing, in the COPA Implementation

Guide (transaction ORKE), via MASTER DATA VALUATION

Z01, which you fill as shown in Figure 4.1.

Copyright SAP AG. All rights reserved.

Figure 4.1: Valuation strategy for material costing

In this step, place a checkmark in the MAT. CSTG column.

This tells COPA that you want to perform material costing
for this valuation step. As a quantity field, enter the quantity
field with which the cost components of the material costing
are to be multiplied for the valuation. In our example, this is
the quantity field ABSMG.
Assign this valuation strategy to a point of valuation (PV,
see Figure 4.2): you do this under the same customizing
item as for defining the valuation strategy.

Copyright SAP AG. All rights reserved.

Figure 4.2: Assignment of the valuation strategy to actual points of


Point of valuation 01 is the actual valuation it is combined

with individual transaction types. For example, valuation
strategy Z01 is run for an incoming sales order (transaction

type A) in SD.
You must now set up the valuation via material costing (that
is, via COPC) in customizing, using the customizing
structure as per Figure 4.3. You have to process the points
illustrated here in sequence.

Copyright SAP AG. All rights reserved.

Figure 4.3: Customizing structure for valuation via COPC

Define Access to Standard Cost Estimates

First make an entry in this table for the costing key in our
example this entry is Z01 (see Figure 4.4).

Copyright SAP AG. All rights reserved.

Figure 4.4: Definition of the costing key I

For a valuation with material costing, the costing key defines

the access parameters used for the search for a valid
product costing (see Figure 4.5).

Copyright SAP AG. All rights reserved.

Figure 4.5: Details of the costing key

For our example, we define that we want to access standard

cost estimates. The system searches for standard cost
estimates of costing variant PPC1 for costing version 1 and
ongoing standard cost estimates from the entry in the
material master of the product to be sold are accessed. The
product costings are plantspecific we will use the plant
from the COPC line item.
Assign Costing Keys to Material Types

We assign the defined costing key Z01 to material type

FERT (see Figure 4.6). The sales products A1 to A6 used in
our example have all been created for material type FERT
in MM.

Copyright SAP AG. All rights reserved.

Figure 4.6: Assignment of the costing key to the material type

What do these entries in Figure 4.6 mean? The material

costing of the finished product is found for the actual point of
valuation 01 in combination with record type A and F, and
for planned points of valuation 03 and 04, but I will come
back to those later.
Assign Value Fields

To be able to access a material costing at all, you must first

create the material costing, for example, with a quantity
structure you do this using transaction CK11 or CK11N in
COPC. For a costing lot size, a bill of material and a routing
are processed for a finished product, for example, and
various cost components are filled. COPA value fields were
assigned to these cost components in the FIELD NAME 1
column under ASSIGN VALUE FIELDS (see Figure 4.7).

Copyright SAP AG. All rights reserved.

Figure 4.7: Assigning value fields for COPC

What happens now? For product A1, for example, I have a

material cost rate of EUR 1500 per unit. For a sales quantity
of 10 units, the MATERIAL INPUT value field is valuated
with EUR 15000 (see Figure 4.8).

Copyright SAP AG. All rights reserved.

Figure 4.8: Evidence of the valuation of material input via COPC

A further example that also proves the valuation using the

valuation strategy for production costs is shown in Figure

4.9. For product A5, a production cost rate of EUR 2 per unit
is assumed.

Copyright SAP AG. All rights reserved.

Figure 4.9: Evidence of the valuation of production costs

Now you may say: Hes got a lot to say but is it reliable?
However, if you have created material costings for your
products in COPC (e.g., via transaction CK11N with costing
variant PPC1), and have then flagged and released these
costings, this cost of goods sold rate is updated as the
standard price in your product master record provided you
maintain the product by standard price. In our simple
example, for product A5 we have a material input of EUR 2
per unit and production costs of EUR 1 per unit. This means
that we update a standard price of EUR 3 per unit in the

material master (see Figure 4.10). If the material costing is

released, this standard price is used to valuate your product
stock and therefore has a direct impact on the inventory
valuation in your balance sheet.

Copyright SAP AG. All rights reserved.

Figure 4.10: Accounting view 1 for product A5

In the video below, I will demonstrate how to set up a

valuation via material costing.

Video 3: Valuation via material costing

Note: Should your reading device not be able to show this

video, you can use your computer to watch it on the

internet. To do this, head to our web page at
4.1.2 Valuation via a Pricing Procedure in SD or COPA

You can also create valuations via pricing procedures that

are created in other modules such as SD or directly in CO
PA. Normally, you do not have to include an SD pricing
procedure in your valuation strategy if you have maintained
the SD interface to COPA. However, this may be useful in
some cases. I will explain an example in Chapter 6,
Planning in COPA. The SD module calculates values itself
in its pricing procedure. Via the SD interface, we can access
these values and transfer them to COPA.
In our simplified contribution margin structure, for two lines
we assume that they are filled by valuation: cash discount
and rebate.
You grant customers cash discount via the payment terms.
If the customer pays quickly, they receive cash discount.
When you enter a sales order, create an invoice, or settle a
sales order to COPA, you usually only know from
experience whether the customer pays quickly and deducts
cash discount or not. You should create a contribution
margin accounting in COPA as a worst case invoice, that
is, you should assume the worst possible scenario.
Specifically, this means that your customer, to whom you
grant cash discount, actually deducts cash discount.
Usually, in the SD pricing procedure, you create a condition
type Cash discount that receives a statistical checkmark.
Here, statistical means that at the time the SD pricing
procedure is executed, nothing is posted in FI for cash
discount but the cash discount amount calculated is
adopted in COPA.
The situation is different for rebates. Let us assume that
rebates are granted based on sales quantities or

percentages if the customer fulfills specific requirements.

Again, you only know whether the customer has earned the
rebate once you have issued the invoice to the customer.
The worst case principle also applies here (worst case
because we have to bear all possible costs). You assume
that the customer receives all rebates. We include these in
the REBATE value field in COPA. You may wonder what I
am talking about as these are completely normal
calculations of imputed costs that we used to post manually
before IT. Correct. In the case of the rebate, you can
calculate imputed costs with every invoice if you have
entered rebate agreements in SD, have created condition
types for them, and have customized revenue account
determination in SD. At some point your customer gets in
touch and wants his rebate because he has fulfilled the
requirements. The SD rebate agreement is then settled and
the customer receives his money. Is the settlement then
transferred to COPA? If so, the rebate would be deducted
twice in COPA once for the calculation of imputed costs
and once for the settlement. Naturally you have to avoid this
error but this is not difficult in the costingbased form of
Profitability Analysis. You simply transfer the calculation of
imputed costs but not the settlement. I will give you details
of this below.
How many rebates were granted in period XY in kind of
product PA2 overall, or only in customer hierarchy KH12?
You are just one press of a button away from the answer...
If you use the SAP module SD (Sales and Distribution),
pricing procedures and condition types are defined there for
pricing. SD usually uses these to find the valid prices and
conditions for an incoming sales order or for an invoice in
the case of revenues, discounts, or freight, these are usually
also posted to corresponding FI accounts automatically.
For our example customizing, we want to show the
valuation via SD once for a condition type ZSKT that is
indicated as statistical in the SD pricing procedure. This

means that the value determined is not posted

automatically. However, we still want to display this value in
In Figure 4.11, we see a relevant extract from the SD pricing
procedure that I have customized for our example. Note the
condition type ZSKT. Do you see the statistical flag?

Copyright SAP AG. All rights reserved.

Figure 4.11: Presentation of the condition type ZSKT in the SD pricing


Condition type ZSKT is assigned to value field VV070 (Cash

Discount) via the SD interface. You make this assignment in
customizing for COPA (transaction ORKE) via FLOWS OF
ASSIGN VALUE FIELDS see Figure 4.12.

Copyright SAP AG. All rights reserved.

Figure 4.12: SD interface

In SD, via transaction VK11, you create condition records

for condition type ZSKT. For our example, cash discount is
granted to three customers (see Figure 4.13).

Copyright SAP AG. All rights reserved.

Figure 4.13: Cash discount condition records

For a COPArelevant posting, in Figure 4.14, for customer

A6 we see that for gross sales of EUR 124
, after
deduction of discounts in the amount of EUR 4.99
, the
net sales are EUR 119.01. The cash discount amount
calculated is EUR 1.20, which is exactly 1% cash discount

Copyright SAP AG. All rights reserved.

Figure 4.14: Evidence of the valuation of cash discount via SD

4.1.3 Valuation via User Exits

As explained in Chapter 3, COPA also contains SAP

enhancements for the valuation. Again, with your own
programming, you can enable valuations that are not
available in the SAP standard system. The important thing
is that you name the exits in your ABAP coding (for
example, U01, U02, etc.) and include these user exit codes
in the valuation strategy.
For our simplified Profitability Analysis, we will fill the
additional quantity field ALTERNATIVE QUANTITY via user
exit. It often makes sense to compare your data with an
alternative quantity reference. Examples of quantity

references can be hectoliter for breweries, 0.7 liters for

spirits, liters for manufacturers of alcoholfree drinks, etc.
(as you can see, I have spent a large part of my
professional life to date in the beverages industry).
You should also consider an alternative quantity factor for
your company. Why is that? This is so that when comparing
contribution margin accounting later, you can consider
contribution margin 1 per HL (or E07 or L or kg, and so on).
This enables you to assess precisely how you are doing
with your products, customers, or other derived
characteristics with reference to an alternative quantity
factor, both with regard to actual as well as planned figures,
in comparison to previous years, forecasts, etc. Amongst
other things, this helps you to find errors in the actual or
planning data quickly if at some point you think that your
contribution margin accounting is not right...
In our example, we will concentrate on the alternative
quantity unit kilogram (kg). You can see the example
customizing in Section 0. There I explained how you can
use user exits for characteristic derivation to add the
quantity unit of our quantity field ALTERNATIVE
QUANTITY. You may also be interested in seeing not only
the quantity unit, but also the alternative sales quantity itself.
I will explain the customizing required briefly here.
First you have to enhance the valuation strategy in order to
tell the system that you want to process a user exit (see
Figure 4.15).

Copyright SAP AG. All rights reserved.

Figure 4.15: Valuation strategy with access to user exit U01

To evaluate a COPA user exit you also proceed via the

customizing for COPA, via TOOLS SAP ENHANCEMENTS.
Create a project and assign component COPA0002. By
doubleclicking the component, navigate to the Include
ZXKKEU03. If you have a developer key in your system,
you can fill this Include. You can see the example coding in
Figure 4.16.

Copyright SAP AG. All rights reserved.

Figure 4.16: Actual user exit for valuation of the value field VVAMG

After coding, save, check, and activate the include. User

exit U01 now has the effect that at the time valuation
strategy Z01 is found, the coding of user exit U01 is
processed. In the simple example coding, the SAP system
searches in table MARM for the alternative quantity unit KG
(kilogram) that you have maintained for each product, as
described in Section 0. For example, one unit of the product
A1 weighs 100 kg. If you then sell eight units, 800 kg should

be visible as alternative sales quantity (see Figure 4.17)

(marmumren = 100/marmumrez = 1 * 8).

Copyright SAP AG. All rights reserved.

Figure 4.17: Evidence of valuation via user exit U01

In the last two chapters, you have now learned about

characteristic derivation and the valuation of value fields. In
the next two large chapters we will look at how actual and
planning data get into COPA.

5 Actual Value Flows

There are many ways of controlling actual data in
Profitability Analysis. On one hand, this depends on
your business model on the other hand, it also
depends on the contribution margin accounting
scheme that you want to set up. Alternatively, if, in your
company, you have decided not to use all SAP R/3 or
ERP modules, you may also use third party interfaces,
for example, from an external billing or CRM system.
In practice, the following methods of controlling data are
frequently used:
SD interface
Settlement to COPA
FI interface
Cost center assessment
Direct entry of line items (correction option)
Third party interfaces
How does COPA know which of these methods was used?
It knows this from the fixed characteristic record type. The
record type shows which method was responsible for
feeding the data into COPA. Invoice data is adopted with
record type F, sales orders with A, FI postings with B, cost
center assessments with D, and settlements with C. You
can also define characteristic values for the record type
yourself if you want to see everything that has been
included via possible line item corrections (that hopefully
occur only infrequently), for example.
5.1 The Most Important Interface to COPA: The SD

As you have seen from my previous explanations, you

usually use COPA to present your results on the market
and to assess them according to various criteria and
business requirements. It will therefore probably not
surprise you that the interface to the SAP module SD (Sales
and Distribution) is very important. This important function is
also clearly visible in the SAP system from the fact that you
can use this interface for two different times of data transfer
to COPA: at the time the sales order is received and at the
time of invoicing.
Transferring actual data at the time of the incoming sales
order is interesting for companies for which the time of the
incoming sales order and the time of invoicing are quite far
apart. You may work for a company that wants to see at the
time the order is received how the future business situation
will develop without having to wait for invoice data. These
companies often sell products from projectrelated
production, variant configuration, maketoorder production,
or maketostock production, i.e., products for which
manufacture takes a long time or products that are not
produced until after the order is received. In contrast, if you
sell MTS (maketostock) products, you can usually deliver
products for incoming sales orders quickly from your
warehouse and then invoice them. In these cases,
transferring the SD data at the time of invoicing is usually
sufficient as you do not gain any new information in
comparison to transferring the data at the time of the
incoming sales order.
If a company does not sell MTS products, it usually decides
to use both data transfer times. However, there are also
companies that use the sales order in SD as a cost and
revenue collector and settle this sales order to COPA later
(for more information, see Section 5.2). The invoice is then
issued, but the invoice data is not transferred to COPA until
the settlement of the sales order and not at the time the
invoice is issued.

5.1.1 Handling of Quantity Fields

In order to transfer sales order quantities or sales quantities

to COPA, you have to name certain SAP fields that you
want to assign to your quantity fields.
You can find these quantity fields in customizing for COPA
if you want to assign your COPA quantity fields. In the
configuration menu for COPA (transaction ORKE), you
maintain the SD interface for the quantity fields via FLOWS
ASSIGN QUANTITY FIELDS. The SD quantity fields shown in
Figure 5.1 are available.

Copyright SAP AG. All rights reserved.

Figure 5.1: Selection of SD quantity fields for COPA quantity fields

Sales quantities from the invoice are in field FKIMG or

FKLMG, and sales order quantities in field KWMENG. For
our example, we assign these two SD quantity fields to our
COPA quantity field ABSMG (see Figure 5.2).

Copyright SAP AG. All rights reserved.

Figure 5.2: Assignment of SD quantity field to COPA quantity field

Can we assign both fields to the SALES QUANTITY

quantity field? If you want to transfer both the sales orders
and the invoices to COPA, in COPA you can create one
quantity field for the sales order quantity and one for the
invoice quantity and then assign them either to KWMENG or
FKIMG. The advantage of this is that you can separate both
quantity transfers in COPA reports and treat them
differently in the valuation strategies.
5.1.2 Transferring Invoice Data

If you decide for your company to transfer the actual data to

COPA at the time of the invoice, the advantage is that you
can transfer and post the data in realtime. A great
advantage of the SAP system is that the data that you enter
is often available in other modules and reports when you
save it i.e., immediately in realtime. A further resulting
advantage is that you usually only have to enter a data
record once to be able to see and use it in multiple modules.
Duplicate entries are a thing of the past, but this may well
be why you have decided to use SAP.
Back to the invoice transfer: SD works with SD pricing
procedures to determine prices and conditions. These
pricing procedures use condition types. During invoicing
(and during entry of the sales order), the system runs
through this pricing procedure finding the required prices,
discounts, cash discounts, rebates, freight charges, sales

promotions, etc. for the customer/product combination that

you want to invoice. We adopt this form of pricing and
condition determination in COPA by assigning the
condition types to our value fields defined in the operating

During my time as a consultant, I
had a project at a very large
customer. I was responsible for
the implementation of CO, and
my best friend was responsible
for the implementation of SD. I
had just completed the SD
interface and created a test invoice: and what
happened? COPA was empty! I asked my friend
if he had customized everything correctly in SD.
After some time, I discovered the following: I had
forgotten to create the relevant accounts that are
posted to during invoicing in FI as cost elements
of type 11 and 12 my friend was completely
innocent (and still reminds me of it even now).

What do we learn from this anecdote? During invoicing,

data is transferred to COPA, but an accounting document
is also created in FI for the revenue and discount posting.
These accounts must also be created as cost elements, or
more precisely, as primary cost elements. For revenues,
cost element type 11 applies, and for discounts, cost
element type 12. Primary cost elements are used in both FI
and CO, but secondary cost elements are used only in CO.
When an invoice is automatically posted to a primary cost
element, a controllingrelevant account assignment is also
specified in this case a profitability segment. A

profitability segment comprises the combination of all

specified and derived characteristic values. This account
assignment is real, but all other account assignments are
only statistical showing the supreme module again.
You may now be wondering what I am telling you. I
previously stated that you can collect costs and revenues on
sales orders and then settle them to COPA. We have also
learned that the assignment of condition types to value
fields applies for both sales orders and invoices. However,
when we invoice, we transfer the invoice data to COPA at
this point and do not wait for the settlement of the sales
orders. For this situation, the normal SAP standard system
sets a block: if you have used an account assignment
category to define that your sales order can collect costs
and revenues, the SAP system automatically allows an
additional transfer of the related invoice to COPA.
Therefore, you do not have to settle the sales order.
You may remember my explanations in Section 4.1, where I
provided some information about valuation strategies. If you
have defined valuation strategies, these strategies are
assigned to a business event. The business event is a
combination of two or three characteristic values.
01 (actual valuation) in combination with a record type
03 (manual planning) in combination with a record type
and a plan version
04 (automatic planning) in combination with a record
type and a plan version
If you now assign a valuation strategy to business event 01
in combination with record type F, no invoice data is
transferred to COPA for the sales orders to be invoiced if
these sales orders collect costs and revenues. If you want
to settle sales orders to COPA as cost and revenue
collectors, you have to assign business event 01 in
combination with record type C to an actual valuation
strategy and define a corresponding settlement strategy.

5.1.3 Transferring Incoming Sales Orders

I have already covered a lot of information on this topic, but

the important thing to emphasize is that you have to
explicitly activate the transfer of incoming sales orders to
COPA as part of customizing, otherwise it does not work.
You also have to assign your actual valuation strategy to
business event 01 in combination with record type A.
Record type A identifies the COPA documents that
originate from the incoming sales order. If you forget to
assign valuation business event 01 in combination with
record type A for a valuation strategy, when you transfer
incoming sales order documents to COPA, no additional
value or quantity fields are valuated.
5.1.4 SD Interface for Our Example Data

For our example, we want to use the SD interface to fill the

following value fields:
Sales Quantity
Other Discounts
Cash Discount
Annual Rebates
Outgoing Freight
Sales Promotion
As already described, condition types are defined in the SD
pricing procedure to fill these value fields. For revenues,
discounts, and rebates, there are also simultaneous
postings to G/L accounts in Financial Accounting. Cash
discounts, freight charges, and sales promotions are
marked as statistical in the SD pricing procedure. This
means that the data that is transferred to COPA via these
condition types is not simultaneously posted to FI. This only

happens in the costingbased form of Profitability Analysis

(see also Section 2.4). You may also discover that sales
promotions should also be transferred via the SD interface.
Sales promotions are products that we give to the customer
free of charge in the hope of higher sales. These products
are invoiced to the customer with a value of zero in COPA,
they are transferred statistically (i.e., costingbased) with the
value at which these products are also valued in the
balance sheet.

Incoming sales order

Postings only occur to FI
accounts if you use the SD
interface for invoice transfer.
Sales orders are transferred with
record type A, if everything is
customized correctly, without
being posted in FI.

5.1.5 Customizing the SD Interface

In the configuration menu for COPA (transaction ORKE),

maintain the SD interface for the value fields via FLOWS OF
ASSIGN VALUE FIELDS. Then double click the entry MAINTAIN

Duplicate function

This interface is also valid for

incoming sales orders.

Now you see an overview in which the condition types used

in your SD pricing procedure are assigned to COPA value
fields (see Figure 5.3).

Copyright SAP AG. All rights reserved.

Figure 5.3: Assignment of SD interface to value fields

If the data from SD is simultaneously posted in FI in addition

to the transfer to COPA, the related accounts must be
defined as cost element of type 11 (for revenues) or type 12
(for sales deductions). Statistical condition types can be
transferred directly to COPA.
The assignment of quantities to quantity fields is similar (see
Figure 5.4) and you can access it under the same path.

Copyright SAP AG. All rights reserved.

Figure 5.4: SD interface, quantity fields

Now it is time to prove that the customizing described

works: in a sales order or invoice, select an item and then
proceed to the CONDITIONS tab. There you will see the
screen shown in Figure 5.5.

Copyright SAP AG. All rights reserved.

Figure 5.5: Example analysis of standard order 12134

If we look at the actual line items record for record type A in

COPA, we see values in the quantity and value fields

according to Figure 5.6 and Figure 5.7.

Copyright SAP AG. All rights reserved.

Figure 5.6: COPA line items for order 12134 (1)

Copyright SAP AG. All rights reserved.

Figure 5.7: COPA line items for order 12134 (2)


and OTHER DISCOUNTS come via the SD interface. And the
other two? From the valuation of course (you knew that).
5.2 Settlement to COPA
What can you settle in COPA? Although there are no limits
here, I will restrict myself to four options from different
Settlement of internal orders: You can use internal
orders to check the costs of internal activities, such as
development costs, costs of promotional events, etc.
You post and collect these costs on internal orders to
then settle them to profitability segments after closing.
As I will show in the next section, in your settlement
profile, define PSG (for profitability segment) as the
account assignment proposal and specify exactly to
which characteristics settlement is to take place.
You can also settle costs and revenues collected on a
project to COPA from the module PS (Project System).
Companies that act as maketoorder manufacturers
use an SD sales order as a collector for revenues and
costs in order to settle the order to COPA after delivery
and invoicing.
A fourth option is that you can settle production orders
and product cost collectors to COPA profitability
segments from PP using production cost collectors. In
these cases, you are usually using variance
determination in cost object controlling. You can settle
production variances for completed orders or transfer
deviations from longrunning production orders to CO
PA. You can then display these items separately
according to individual variance categories.
I have now illustrated four settlement methods from CO, PS,
SD, and PP to COPA showing also that in COPA, the

data from many different SAP modules is merged.

Which settlement method do we want to select for our
example? For the marketing costs we will use internal
orders that we then settle to COPA.
5.2.1 Customizing the Settlement to COPA for Our Example

In the configuration menu for COPA (ORKE), set up a

Profitability Analysis (PA) transfer structure. The path is
shown in Figure 5.8.

Copyright SAP AG. All rights reserved.

Figure 5.8: Customizing path for settling orders

A PA transfer structure is used to settle orders. You can

make any number of PA transfer structure assignments as
required. These assignments assign cost or revenue
elements to COPA value fields. In the example, we have
created PA transfer structure 10 with assignment 10 (see
Figure 5.9).

Copyright SAP AG. All rights reserved.

Figure 5.9: Access to PA transfer structure 10

In the PA transfer structure assignment, you first define a

source, that is, you define which cost elements you want to
assign to COPA in this settlement step (see Figure 5.10). In
this example, we only want to settle expense account
478000. In our chart of accounts this account contains the
marketing expenses. As, in this case, the account is a
primary account, G/L account 478000 must also be created
as cost element with cost element type 1 (primary costs).

Copyright SAP AG. All rights reserved.

Figure 5.10: Assignment of cost element to PA transfer structure 10

In a second step, we assign a further COPA value field

VV380 to PA transfer structure 10. The marketing costs are
to be settled to this value field (Figure 5.11).

Copyright SAP AG. All rights reserved.

Figure 5.11: Assignment of value field VV380 to PA transfer structure 10

You then assign the PA transfer structure to a settlement

profile (see Figure 5.12).

Copyright SAP AG. All rights reserved.

Figure 5.12: Settlement profile for marketing orders

PA transfer structure 10 is assigned to settlement profile Z1

in our example
. In this settlement profile, you have
to settle
to profitability
and thatthat
a settlement
a profitability
segment is proposed as settlement receiver
. The
marketing orders are created in
module COOMOPA as
internal orders for order
For orders, a settlement profile is transferred from the order
type to the settlement rule. The internal order type for our
internal orders is created with Z400 (Figure 5.13).

Copyright SAP AG. All rights reserved.

Figure 5.13: Order type Z400

Every internal order created contains a settlement rule you

create these from the maintenance of the master data via
the SETTLEMENT RULE button (see Figure 5.14). We have
created the orders 400217, 400218, and 400219 for our

Copyright SAP AG. All rights reserved.

Figure 5.14: Internal order 400217 with settlement rule

The settlement rule also defines the characteristics that are

specified with this settlement to COPA (see Figure 5.15).

Copyright SAP AG. All rights reserved.

Figure 5.15: Characteristics in settlement rule for order 400217

For the posting to cost element 478000 (Marketing and

sales costs), the internal orders created also receive the
account assignment. This is visible in the reports for internal
order accounting (see Figure 5.16).

Copyright SAP AG. All rights reserved.

Figure 5.16: Costs visible in COOMOPA

In the settlement rules for the internal orders, account

assignment is given for three products:

Marketing costs of EUR 10,000 for product A1 (order
Marketing costs of EUR 50,000 for product A5 (order
Marketing costs of EUR 30,000 for product A3 (order
At periodend closing these internal orders are settled to
COPA via transaction KO88 (see Figure 5.17).

Copyright SAP AG. All rights reserved.

Figure 5.17: Example selection screen for KO88

You can see the results of the settlement in COPA reports

or in the actual COPA line items (see Figure 5.18).

Copyright SAP AG. All rights reserved.

Figure 5.18: Settled marketing costs in COPA

In the settlement rule of an internal order, the account

assignment was to products and their derivation, that is, the
marketing costs are not visible on customer characteristics
but are visible on all product characteristics (see Figure

Copyright SAP AG. All rights reserved.

Figure 5.19: Drilldown from kind of product to product for marketing costs

Naturally these costs are also visible in an overall

contribution margin accounting (see Figure 5.20).

Copyright SAP AG. All rights reserved.

Figure 5.20: Actual contribution margin accounting with marketing costs

You can also review internal order settlement to COPA in

the video below.

Video 4: Valuation via material costing

Note: Should your reading device not be able to show this

video, you can use your computer to watch it on the
internet. To do this, head to our web page at
Now that I have presented the settings required for
settlement, we will look at the FI interface.
5.3 FI Interface
From a customizing perspective, the FI interface works in a
similar way to the settlements to COPA. You simply use the
PA transfer structure FI.
You need this interface if, when you post to an FI account
that is also created as a primary cost element, you specify a
profitability segment as controllingrelevant account
assignment. As described in Chapter 2.1, your accounting
colleagues may not be your best friends when it comes to
the direct account assignment of a profitability segment
within the scope of manual postings in FI it means
additional effort for your colleagues and appears laborious.
Any automatic account assignment that you may have
customized is also only beneficial as long as this automation
is not interrupted. For account assignment to a profitability
segment, companies that choose the FI interface to post
directly to COPA will almost certainly only specify
characteristics that are at a high, aggregated level. Seen
from the opposite perspective, this also means that value

fields that are filled by the FI interface can no longer be

evaluated in great detail. This gives us little more
information than we already have. Therefore, for our
example, I will not set up an FI interface to COPA.
5.4 Cost Center Assessments
If you want to display your costs that you have not already
absorbed in your balance sheet completely in COPA, within
the scope of periodend closing, you can transfer your costs
to COPA as part of an actual assessment. The combination
of cost element/cost center is the sender, and profitability
segments are the receivers. An assessment, in contrast to a
distribution, works with secondary cost elements. This
means that the original values are also visible on the
primary cost elements after the assessment.
For an actual cost center assessment, you can select
different tracing factors for the assessment: variable
portions, fixed portions, percentage values, or fixed
amounts. The more detailed you are here, the greater the
possible detail for your cost evaluations later.
For our example, we will fill the Fixed Costs line via cost
center assessment. We assume that fixed costs are
assigned to cost centers. The fixed costs are therefore
present in Cost Center Accounting (COOMCCA) and are
to be reallocated to profitability segments in COPA. To do
this you have to create an assessment cycle (see Figure

Copyright SAP AG. All rights reserved.

Figure 5.21: Path for assessment of cost centers


CREATE ACTUAL ASSESSMENT. Once you have specified an
assessment cycle including starting date, by pressing
ENTER, you navigate to the header data for your
assessment cycle (see Figure 5.22).

Copyright SAP AG. All rights reserved.

Figure 5.22: Header data, actual assessment cycle

In our example, we assume that the following cost centers

have been posted to account 476500 (Administration
Costs), which is also created as a cost element of type 1
(primary cost element) (see Figure 5.23). From this simple
database, we now want to build up our assessment cycle

Copyright SAP AG. All rights reserved.

Figure 5.23: Fixed costs at cost center/cost element level

You use an assessment cycle to reallocate the costs posted

to the combination cost center/cost element to COPA. In an
assessment cycle you create assessment cycle segments.
If you want to allocate different senders to different
receivers using an assessment cycle, you have to create
different segments.
In the first segment of the cycle, the fixed costs of the
sender cost center KS1 are to be allocated to general
characteristics of the operating concern Z111 and the
characteristics of customer K1 to 100% using cost element
476500. In the second segment, we want to allocate the
sender cost center KS2 according to variable portions using
cost element 476500, specifically according to sales
quantities actually recorded. We want to customize these
Before we do this, we have to create two assessment cost
elements of type 42. This is a cost element that is only valid
in the Controlling module. Cost element type 42 is used for
assessments. With an assessment cost element, the
primary costs remain visible in cost center accounting credit
is via the assessment cost element. The segment header of
the first segment is as shown in Figure 5.24.

Copyright SAP AG. All rights reserved.

Figure 5.24: Segment header, segment 1

Here I have assigned value field VVFIX

and entered the
parameters under
, I define that the total amount of the
costs posted to the cost center is to be passed on. The
apportionment to the receivers is based on fixed percentage
The senders and receivers are set up in accordance with
the requirements (see Figure 5.25). Here you can see that I
have entered cost center KS1 as the sender with cost
element 476500
in doing so, I have determined that all
costs posted to cost center KS1 under this cost element are
to be allocated. I have entered some characteristic values
as receiver, including customer K1

Copyright SAP AG. All rights reserved.

Figure 5.25: Senders/receivers of segment 1

Now we have to set up the receiver tracing factor (see

Figure 5.26). A receiver tracing factor defines the
distribution factors used to select a receiver, i.e., how much
of the assessment goes to the receiver.

Copyright SAP AG. All rights reserved.

Figure 5.26: Receiver tracing factor, segment 1

Now we set up segment 2. First we maintain the segment

header (see Figure 5.27).

Copyright SAP AG. All rights reserved.

Figure 5.27: Segment header, segment 2

In accordance with the requirements, assessment is to be

according to variable portions. Using a predefined value or

quantity field as tracing factor, the sender can be allocated
to the receiver. For example, you want to distribute
according to actual sales quantities of the period to be
closed. As we generally do not know how the quantities fall
in a period when we define the assessment cycle, we refer
to variable portions also because the segment can be
applied to multiple periods.
In the same way as for segment 1, we now have to define
the senders/receivers, receiver tracing factor, and receiver
weighting factors for segment 2 (see Figure 5.28).

Copyright SAP AG. All rights reserved.

Figure 5.28: Sender/receiver of segment 2

We want to allocate from the sender cost center KS2, in

combination with cost element 476500, to products A1 to A5
and customers K1 to K6. In the receiver tracing factor, we
define the reference dates used for the assessment.
Distribution is to be according to posted actual order

Copyright SAP AG. All rights reserved.

Figure 5.29: Receiver tracing factor, segment 2

Due to the variable portion rule, you now also have to

specify the receiver weighting factors. Using the tracing
factor, COPA proposes all possible characteristic
combinations that you can weight:

Copyright SAP AG. All rights reserved.

Figure 5.30: Receiver weighting factors, segment 2

Depending on how many receivers you specify on the

SENDERS/RECEIVERS tab, the same number of receiver
weighting factors is created from the combination of these
receiver characteristic values. After saving, you can execute
the cycle via transaction KEU5 (see Figure 5.31).

Copyright SAP AG. All rights reserved.

Figure 5.31: Execution of actual assessment cycle

Execute a test run of the assessment according to Figure

5.31 and look at the subsequent log (see Figure 5.32).

Copyright SAP AG. All rights reserved.

Figure 5.32: Test run log, CCA assessment

You should analyze the senders, receivers, errors, and

segments before the update run. Now that we have

executed the update run, we want to analyze the result.
What has happened in Cost Center Accounting? Let us look
at a standard cost center report (see Figure 5.33).

Copyright SAP AG. All rights reserved.

Figure 5.33: Assessment cycle result in CCA

You can see that the primary costs are visible in Cost
Center Accounting in the amount of EUR 30,000, but the
cost centers have been completely credited. You can also
see these costs in COPA in the FIXED COSTS value field
(see Figure 5.34). If you look at the fixed costs in more
detail there, you will see that in accordance with the
distribution requirements from segment 2, fixed costs have
also been allocated to lower level characteristics.

Copyright SAP AG. All rights reserved.

Figure 5.34: The actual fixed costs have arrived in COPA via assessment

This completes the section on settlement and we will now

turn to the line item corrections.
5.5 Direct Line Item Corrections in COPA
People work with the SAP system. People tend to make
mistakes from time to time. When errors are made in the
SAP system and this leads to incorrect data in COPA, good
advice is often expensive. As already stated several times,
COPA is the final point in the SAP system, and therefore,
any errors made up to this point should become visible here
at the latest.
For any errors detected, the following principle applies:
correction at the source. What does that mean? It means
that any errors detected should always be corrected in the
module in which they arose. For example, if incorrect
amounts or characteristics were transferred from SD, the
incorrect SD document should be reversed and recreated.
The reversal document and the new document are

transferred to COPA, and everything is as it should be

again. But what if it is no longer possible to perform the
correction at the source? This could be the case if the
customer billing document has already been sent, or the
periodend closing has been completed before the error is
detected (or any other reason that makes a correction at the
source impossible or only possible with an enormous
amount of effort), for example. One solution can be to
correct the line item directly in COPA.
Some of you will now shout out that you can present the
figures in COPA any way you want. In theory this would
perhaps be possible if you have mastered some security
measures as part of the customizing settings, but in my
opinion, is it is not possible from a practical perspective.
In principle, SAP has planned a data inconsistency as part
of COPA: in a live system, deletion of posted actual data
line items from COPA is not allowed. Within the scope of
live starting preparations, you can still do this at an
aggregated level, but at the latest when you go live it is no
longer possible.
You can always enter data in COPA, but you can never
change or delete it! You cannot change it? Then how are
you supposed to perform corrections in COPA? You can
only create corrections in COPA by recording data in CO
5.5.1 Types of Errors and How to Correct Them

There are two types of errors that can arise in COPA:

Incorrect characteristics or characteristic derivations
Incorrect data transfer or incorrect valuations
Let us look at the first type of error: characteristics or
characteristic derivations are incorrect. Incorrect! What an
awful word. Sometimes, characteristic values have been
defined as they were uptodate at the time of the

derivation at the current point in time, they appear obsolete

and incorrect. Here too, you have to decide whether an
error occurred at the time of the transfer and derivation, or
whether this is some type of temporary view.
I do not like correcting characteristic derivations that were
once valid retrospectively, perhaps also for the period in
which they were valid. What does this mean? This is best
explained with the example of the customer hierarchies:
when the invoice was created, a customer was assigned to
customer hierarchy KH1. At some point, the customer was
sold to another customer hierarchy KH2. For the
assessment of customer hierarchy KH2, for management
reasons it may be useful to change the original
characteristic derivation of the customer for the original
invoice to KH2 so that, for example, this data is available for
planning. However, if we did this, incorrect information
would be reported for the level of sales that was achieved
with customer hierarchy KH1 in the period in which the
invoice was created. Therefore, you should make sure that
you do not perform this type of backwards assignment
change in your ERP system. You may be able to do this in
your management information system, which you may have
connected to the SAP system, but not in your ERP system.
Back to error type 1: if characteristics or characteristic
derivations have been transferred to COPA, but at the time
of the transfer they were different in reality but can no longer
be corrected at the source, they have to be corrected by
means of data entry in COPA. You can enter actual line
items in COPA with transaction KE21 (or KE21N). For the
correction, you have to create two data records: the first
data record contains all characteristic values specified in the
original document. All specified values in the value fields are
entered with reversed leading signs (this is the same result
as you would achieve by reversing the document at the
source). The second data record contains new and
corrected characteristic values as well as all values in the
value fields that were created in the original document.

Error type 2: incorrect data was transferred. If this data is

also important for other modules, you will probably not be
able to avoid making a correction at the source or would
have to also make corrections in these other modules.
However, let us assume that an evaluation of your costing
based COPA data was incorrect: you could then use direct
data entry in COPA (transaction KE21 or KE21N) to correct
this inconsistency for the same characteristic values that
you specified in the source, you enter the delta to the
correct value of a value field and enter zero in the remaining
value fields. This sounds more complicated than it is: in a
line item, you have entered cash discount of EUR 10, but it
should have been EUR 12. For the same characteristic
values as in the original document, in the cash discount
value field you enter a delta amount of EUR 2. You do not
make any entries in the remaining quantity and value fields
and they are filled with zeros when this line item is posted.
In the event of a combination of error type 1 and error type
2, you have to apply a combination of both correction
methods i.e., you have to correct errors from incorrect
characteristic values and then correct incorrect values.
5.5.2 Security Measures

In the COPA information system you can also define line

item layouts. After entering a line item correction directly in
COPA, you should always check that everything was
entered correctly by reading your line items and the related
line item layout. For example, the total of the value fields in
the correction line items should balance to zero if you have
processed error type 1.
If you want to perform actual line item corrections directly in
COPA, I also recommend defining and using a separate
record type. You can create a new record type in
customizing for COPA via the path shown in Figure 5.35.

Copyright SAP AG. All rights reserved.

Figure 5.35: Defining your own record types in COPA

Any record types that you define can have a number

between 0 and 9 letters are reserved exclusively for SAP.
You then have the option of displaying exactly what you
have changed in evaluations. If necessary, you can show an
auditor exactly what was changed at the touch of a
5.5.3 Simplifications in Line Item Corrections

Once errors have been detected in COPA, it is usually not

sufficient to simply enter a few data records. Depending on
the size of the original document and how long the error
was undiscovered, up to several hundred data records may
be affected. If you now give someone in your company the
task of correcting the data records as described above, you
will make this person very unhappy.

To perform mass corrections, use a batch input program, for

example. Define line item layouts that enable you to present
all characteristics and value fields one after the other. I will
explain how to define line item layouts in Section 7.4. One
layout will often be insufficient you should use the COPA
document number as lead column for the layouts. Export
incorrect documents from COPA (transaction KE24) and
run a download to Excel for each layout. In theory, you
would have to link the layouts with one another in Excel via
VLOOKUP using the document number, but the downloads
are usually arranged and sorted correctly (but you should
check this).
Now have your consultant, developer, or colleague who
knows how to program batch input programs using ABAP
write a program for transaction KE21. The value and data
length of the characteristics and value fields should be
defined precisely in advance. Prepare the Excel columns of
your downloaded data accordingly and maintain the data
records created automatically in COPA using your
In this chapter I have now explained how to include actual
values and actual quantities in COPA. In the next chapter,
we will look at how that works with planned values and
planned quantities.

6 Planning in COPA
I also want to remain true to the title of the book, Quick
Guide to SAP COPA in this chapter, and will therefore
only present the most important planning options and tools
that are available in COPA.
Planning functions have been available in COPA ever since I
have known it. In the newer SAP releases, you have to define
what you want to plan before you actually do your planning. You
have to set up a planning framework, select characteristics to
be planned and that you want to plan with, and create planning
packages in order to define your task areas. In doing so, you
give those persons tasked with planning the framework in which
to do the planning. You also define precisely the planning
methods that these planners may use. You define all of this in
customizing that is, you make these settings in the test
system and transport them to a quality assurance system before
transporting everything to your live system. Any changes that
you make, even if these are only in individual characteristic
values, are customizingspecific and must be transported.
You may think that sounds complicated how does it tie in
with a quick guide or a convenient way of planning in COPA?
In principle, the procedure described is correct and useful for
large companies in which many people are involved in the
planning process. But what if you work in a smaller company
that has only a few controllers who have to plan in COPA, you
only have a limited amount of time in which to do the planning,
but still have to integrate change requests from management in
the planning quickly and efficiently? The planning phase is
usually an adjustment phase, i.e., you create the planning
according to specific requirements and then constantly adjust it
until you achieve a desired or practical result. In this phase, fast
planning is important: management often does not have time to
wait days or weeks for planning changes.
Below I will explain planning in COPA for precisely this case.
We will assume that we want to create the planning for next

year, and not only a sales quantity planning, but also planning
right down to the contribution margin. We will also perform this
planning not only at a high, aggregated level (e.g., company
code or sales area) for each individual customer, we will plan
with those products that you believe your customer will
purchase next year. We will plan all customerspecific and
productspecific characteristics as well. We will also consider
individual monthly distributions. We will assume an overall
planning process of approximately four weeks.
How are we supposed to do all of that in such a short time?
Including an adjustment phase? You will be amazed...
6.1 Shortening the Planning Process without Losing
Your management will often tell you that you only have a few
weeks for planning, and that the results of the planning (that is,
the quality of your work, not the planned operating profit that
management wants to achieve for next year) should be at least
as good as the previous year, but preferably even better than
last year.
How can you shorten the planning process? In principle, you
would enter sales quantities for the periods to be planned and
valuate these with prices, conditions, and cost rates. You would
then consider the result, and in a frequently recurring process,
would change details such as sales quantities, prices,
conditions, or cost rates until a desired or practical result is
achieved. There is no way of shortening the process, is there?
Of course there is!
6.1.1 Reducing the Planning Effort Tip 1

Initially, management is interested in the possible operating

profit for the planning year. How the profit is spread over the
individual months of the planning year is initially irrelevant. This
is the first approach that you use to shorten your planning
process: you plan your entire years planning in one plan period,
i.e., one planning month. You can spread it over the months of
the year later.

6.1.2 Reducing the Planning Effort Tip 2

Entering the planned prices, planning conditions, and planned

cost rates that you want to use to valuate the planned sales
quantities involves a great deal of work. Many people do this
work before management gives the goahead for planning,
especially if planning is to be done on characteristics such as
customer or product. Why not use prices, conditions, and cost
rates that are already in the system, i.e., actual prices,
conditions, and cost rates valid now? Then you would only have
to enter planned sales quantities and valuate these with the
actual prices to get your first result. You can then make specific
changes to the existing planning where sales quantities have to
be adapted, or where higher prices, conditions, or costs are
anticipated (or feared) until you get the result that management
6.1.3 Reducing the Planning Effort Tip 3

You can also save time when entering the planned sales
quantities. Usually, the sales and distribution department or key
account management will plan the planned quantities. If you are
the sales controller responsible, they will ask you for historical
values for past sales in order to plan, where applicable, the
sales quantities for respective key accounts on the basis of
specific product groups (ideally, specific products). It is up to
you how you provide these historical values. Many companies
use Microsoft Excel others use various management
information systems, CRM systems, etc. Let us assume you use
Microsoft Excel and also receive the data from your sales
colleagues via Microsoft Excel. If I were you, I would then use
the historical values (e.g., the previous rolling year) to download
the sales quantities for specific customers and products to Excel
and also transfer other characteristics such as key account or
product group. Using a pivot table (controllers will know what I
mean), put together the sales quantities for each customer
hierarchy and product group at customer/product level. Now use
VLOOKUP to assign the planned quantities from your

Using a manual planning layout defined in COPA, ideally you

import the planned quantities for the specific customers and
products via batch input program. As a result of the
characteristic derivations that you have set up for customers
and products, all relevant characteristics are derived, meaning
that you see all planned quantities on all possible
It is easier to explain the last planning tip with an example:
Your key account managers give you the planned quantities
that you see in Table 6.1:
Kind of qty
Plan. Cust.hier.lev.1 product
Kind of Plan.
Cust.hier.lev.1 product










Table 6.1: Example for planned quantities

From the rolling year (e.g., period 10 of the previous year up to

period 9 of the current year), you have downloaded the
quantities shown in Table 6.2 from the actual data:


































































Table 6.2: Actual data of the rolling fiscal year

As a pivot table, this corresponds to the values that you can see
in Table 6.3.
Kind of qty
Act. Cust.hier.lev.1 product
Kind of Act.
Cust.hier.lev.1 product


units KH12







Table 6.3: Pivot table for the actual data of the rolling fiscal year

Therefore, according to Table 6.1, we want to plan a total of 250

units. In accordance with the rolling year, this planned quantity
is to be distributed proportionately to the corresponding
customers and products. You can do this using the rule of three.
This results in the following planned quantities (see Table 6.4)
at customer/product level proportionately according to the rolling





































Table 6.4: Proportionate planning based on actual data

6.2 Fast Yearly Planning in Detail

In this section, I will first describe the further procedure before
providing you with the technical details from Section 6.5
6.2.1 Recording Yearly Planned Quantities

The tips for reducing the work involved in planning sound great,
but how do they work in detail? According to tip 3, you import
the calculated planned sales quantities into a previously created
manual planning layout via transaction KE11, and, in
accordance with tip 1, into a planning period, e.g., 010.20CY
(CY stands for current year), with the plan version XYY (yearly
plan version) that you have also created in advance. For each
combination of customer/product, the batch input program
imports the planned quantity and saves each entry as a
planning line item in COPA. As you learned in Chapter 3, all
characteristic derivations that you have defined are also
executed. The planned quantities are now also visible on
derived characteristics such as customer hierarchies, product
hierarchies, or as in our example, customer group, sales
employee, kind of product, and product group. For example, in
the characteristic sales employee V1, you will see all planned
quantities for customers 1, 2, 4, and 6, i.e., in total 139 units.
6.2.2 Valuation of Planned Sales Quantities

Now we will look at tip 2 for reducing the planning effort: we

valuate the planned sales quantities recorded with the actual
prices and conditions that are already defined in your SAP
system. The planned sales quantities are located in plan version
XYY in planning period 010.20CY. As you are in the current
year, it is very probable that all prices and conditions are
available: from a logical perspective, we are doing nothing more
than pretending to invoice your planned quantities.
Remembering Section 4.1.1, create a valuation strategy
containing the pricing procedure defined for actual invoicing in
SD. Then, in the same way as for actual figures, add a valuation
of your current material costing. Assign this valuation strategy to
the points of valuation 03 (manual planning) and 04 (automatic
planning) in combination with your plan version XYY. Using the
old COPA planning transaction KE1B (Change Automatic
Planning), which is thankfully still available in the new SAP
releases, you can valuate your recorded planned sales
quantities completely. In just a few steps, you have valuated
your planned sales quantities specifically, right down to
contribution margin 1 in accordance with our example
contribution margin structure. The valuations are also visible on
all derived characteristics.

Condition types that are not characteristics

In SD, access sequences are used to
find the valid condition record for
each condition type defined in the SD
pricing procedure. But what happens
if the access sequences contain fields
for condition record determination that
are not also characteristics in your
operating concern? If that is the case, the condition
record for the valuation of your planned sales
quantities is not found.

You may ask why I am telling you about this fast planning if
there is no certainty that, as indicated by the note above, all
valid condition records will be found for the planning valuation.
Here too, SAP has provided a solution using a special planning
user exit. You use this user exit to tell COPA about fields that
are in the SD access sequences but that are not characteristics
in your operating concern so that COPA finds the valid
planning condition records.
For both actual order entry and actual invoicing in SD, it is often
the case that some actual prices or actual condition records are
defined at the lowest level, that is, at the level of
customer/product. To provide assurance for your planning
valuation that the SAP system has found all possible and valid
condition records, you have to trigger the planning valuation at
this lowest level. As I will show you in the example, with
transaction KE1B this is not a problem.
6.2.3 Adjustment Phase

Once you have presented your management with a first

planning result, the adjustment phase starts: quantities, prices,
conditions, cost rates, and possibly also innovations or product
changes are discussed. Some companies save the respective
planning stage in a separate version before making any
changes so that they can make the changes in the adjustment
phase visible. The old COPA planning transaction KE1A (Copy
Automatic Planning Data) will help you here. You can use it to
copy all or parts of a planning.
Let us return to the adjustment phase: if your management asks
you, for example, to increase your entire sales quantity planning
by x%, there is no need to panic. You can use the revaluation
key tool available to make these changes. You define
revaluation keys with the (old and new) transaction KE1F. In a
revaluation key, you define which quantity or value field you
want to change by x%. For automatic planning via KE1B, you
also specify the characteristics (or even characteristic values)
for which you want to make this planning change. If you wish,
you can execute planning changes at high, aggregated levels
(all underlying characteristics are also considered), or on

individual characteristics such as customer or product. It all

depends on the management requirements.
You can now proceed to valuate the revalued quantities in
accordance with your valuation strategy, and in just a short time
you have a new planning result that you can present to
When changing planned sales quantities, you can also use a
mathematical effect: if you change your planned quantity by x%,
provided you do not change prices and conditions at the same
time, the sales quantitydependent value fields will also change
by x%. For your planning, this means that you could also
consider this effect when defining your revaluation key by
considering not only the quantity field but also all sales quantity
dependent value fields, and assigning factor x% to all fields. In
one step in automatic planning, you can thus not only increase
the planned sales quantity by x%, but also all dependent value
fields. And your new planning result is ready....
When you change prices or conditions, the situation is a little
more difficult but the principle is similar: if you are planning, for
example, price increases, revaluate the value field GROSS
SALES accordingly. You may now wonder what happens with
the value fields that are, for example, dependent on the gross
sales based on percentages? They also have to be adjusted,
dont they? You are right again. If this adjustment cannot be
calculated due to the complexity or for other reasons, we have
to use another trick: in SD, copy the actual SD pricing
procedure used so far in the valuation strategy into a new
pricing procedure that you want to use only for your planning
valuation (to be on the safe side, coordinate this with your SD
colleagues so that there are no arguments). In your own pricing
procedure, integrate separate, statistical condition types that
contain, for example, the gross price increase. Include this new
pricing procedure in your valuation strategy and valuate your
planned quantities again using KE1B.
With some planning changes requested by management, even
the best system will not help you if you have not thought about it
in advance and done some preparatory work. Innovations
require, for example, new product numbers, new product

costings (with corresponding bills of material and work plan

prerequisites), new prices, and new conditions. These will
probably not be available yet in period 010.20CY and so they
have to be created.
At some point, management is satisfied with your sales quantity
planning and the resulting valuations and the adjustment phase
is initially complete for you.
6.3 Planned Cost Center Assessments
Up to this point in your planning process, you have not
considered planned costs that are independent of the sales
quantity. This type of planned cost is usually planned initially in
other CO modules such as cost center accounting or internal
order accounting. This planning can and probably will be
executed in parallel with your adjustment phase. At some point
these fixed costs are also planned. They are then allocated to
COPA using a planned assessment cycle. The principle is the
same as for the actual costs assessments described in Section
6.4 Distributing the Planning over Months
After all of these explanations about planning, you are perhaps
now right to say, that is all well and good but the entire planning
for next year is currently in one month, specifically, in the
current year in period 010.20CY. We are planning for the entire
next year, so therefore I need planning data for months 001 to
012 for next year, e.g., 001.20PY to 012.20PY (PY = planning
year). How do I get that?
Normally, you use distribution keys to specify the distribution to
precise months. Caution: if you want to create planning data in
COPA using distribution keys, the period for planning must
match the period in the distribution key. What does that mean?
At the moment our planning is in one period010.20CYand
we want to distribute it to months 001.20PY to 012.20PY. The
two periods do not match. The sender has one period, and the
receiver 12 periods. This means that we can forget about using
distribution keys here!

But how can we solve our problem? Again, I have a tip for you:
use the old COPA transaction KE1A (Copy Automatic
Planning). At the same time, work with revaluation keys (you
know these: transaction KE1F). Now copy your planning from
plan version XYY, period 010.20CY into plan version XYM,
period 001.20PY. Let us assume that management wants to
see 10% of your yearly planning in January. Define a
revaluation key of 90% for January for all planned quantity and
value fields and then apply this revaluation key to your copy
planning: the result is that in January you have only 10% of your
planning. Repeat these steps for the other 11 planning periods
and you will have your yearly planning distributed over planning
Its simple! But what happens when management requirements
are not so easy? It is often the case that the smaller the
company, the more complicated and thus more difficult the
requirements are. Then you have to break down the revaluation
keys or the planning copies to lower level characteristics. And if
you want to do this quickly? In a worst case scenario, in which
customer/product combinations have to be distributed
individually, you will still be distributing when the planning year
is over! Again, no need for panic: there is always more than one
way to do something. Using Microsoft Excel, for example,
prepare the planning steps, write a batch input program for
transaction KE1A, and have the program create the distributions
automatically. Youll be finished quicker than you think.
You may have someone in your company who knows all about
batch input. Using the relevant recorder, you can record the
steps that you would have executed for each distribution
process. You convert this record entry into ABAP coding in the
batch input framework created by your colleague, and you
would already be able to use the batch input program.
Regardless of whether you have executed the distribution
manually or automatically, at the end, the plan version with the
monthly distribution (here XYM) must contain the same overall
result as your yearly plan version XYY.
I will show you how to view the planning data in Chapter 7.

6.5 Planning Our SAP Example

Now that you have had the pleasure of my theoretical planning
approach in Sections 6.1 to 6.4, in this section I will describe the
technical details of how to implement the planning approach. I
may also excite your imagination further...
6.5.1 Plan Version and Planning Valuation Strategy

Below, I will use the example to show how you can execute
your yearly planning. Firstly, some preparations are necessary
as shown in Figure 6.1.

Copyright SAP AG. All rights reserved.

Figure 6.1: COPA planning Implementation Guide

On one hand you have to define number ranges that will receive
your planning line items for the planning.
You also have to define a plan version. You can usually define
an entire planning in one plan version. If you use several plan
versions, you can compare several plans.

For our example, we are using plan version Z01 (see Figure

Copyright SAP AG. All rights reserved.

Figure 6.2: Plan version Z01

The DERIVATION DATE in this plan version is important. It

determines the date on which further characteristics in your
planning are derived. In the example, characteristics such as
customer hierarchy are derived on 06/15/2012 even if you enter
planning data in July 2012, for example.
Before you enter planning data in this plan version, you should
define a planning valuation strategy for your planning (see
Figure 6.3) and assign it to points of valuation 03 and 04 in
connection with record type F (see Figure 6.34). I have already
explained what a valuation strategy is in detail in the Valuation
section of this book.

Copyright SAP AG. All rights reserved.

Figure 6.3: Planning valuation strategy

Copyright SAP AG. All rights reserved.

Figure 6.4: Assignment of the planning valuation strategy

If we look at the planning valuation strategy in Figure 6.3 more

closely, we can see in the COSTG SH (= pricing procedure)
column that in step 10, we want to access our actual SD pricing
procedure ZEIF01. Material costing then runs in step 20, and
finally, we have user exit U02, which, in the same way as for
actual figures, calculates the alternative quantity for the
planning. You can look at the details again at your leisure in the
Valuation chapter.
6.5.2 User Exit for Planning Valuation

You are working in the same project as described in Section

4.1.3. You are also using component COPA0002. In this
component, doubleclick EXIT_SAPL_KEAB_002 and navigate

to the include ZXKKEU04. This user exit is intended by SAP for

your planning valuation. Now you can install your coding (see
Figure 6.5).

Copyright SAP AG. All rights reserved.

Figure 6.5: Planning user exit

6.5.3 Manual Planning Layout

You create a manual planning layout for the following reasons:

on one hand to be able to enter the planned quantities at
customer/product level in accordance with Section 6.1.3, and on
the other hand to have a tool that you can use to check your
characteristic derivation and valuation in the shortterm. A
planning layout is an individually designed planning screen that
you can use to enter planning data manually. The planning
layout should run at point of valuation 03 (manual planning) in
combination with record type F and plan version Z01.
You create a manual planning layout via the COPA
Implementation Guide under PLANNING MANUAL ENTRY OF
have created the layout Plan GP. Our planning layout looks as
shown below (see Figure 6.6). Similarly to Report Painter
reports, this layout also has three main components: lines (for
details see Figure 6.7 and Figure 6.8), columns (details in

Figure 6.9), and general selections (details in Figure 6.10).

Copyright SAP AG. All rights reserved.

Figure 6.6: Planning layout, Plan GP

Use your value fields as lines. You define a line by double

clicking a dot. Now you can select VALUE FIELD WITH
CHARACTERISTICS as the element type (see Figure 6.7).

Copyright SAP AG. All rights reserved.

Figure 6.7: Definition of lines I

Then select the corresponding value field and, if applicable,

restrict further characteristics (here, restrict means: select via

characteristics). In our layout, we have only selected value
fields for the lines and have not restricted any further
characteristics in the lines (see Figure 6.8).

Copyright SAP AG. All rights reserved.

Figure 6.8: Definition of revenue line

You define the Planning Data column by doubleclicking the

dotted line and selecting the characteristics to be applicable for
this column (as per Figure 6.9).

Copyright SAP AG. All rights reserved.

Figure 6.9: Definition of the Planning Data column

In our example, we restrict using the following characteristics:

planned/actual indicator, record type, and plan version. The
column in the planning layout should only take planning data for
record type F in combination with plan version Z01.
For COPA to know how you want to distribute your planning
values over several periods (where applicable), you have to
define a distribution column in the planning layout when you
define the planning column.
You include the distribution column via EDIT COLUMNS
field offered by SAP. Using this column, when you enter the
planning values, you can define whether you want to distribute
over the periods evenly or in some other way.
When you define the planning layout, via EDIT GEN. DATA
SELECTION GEN. DATA SELECTION you can define the general
selections in accordance with Figure 6.10: the general
selections define the characteristics that you see when you call
up your planning layout and navigate to the first selection

Copyright SAP AG. All rights reserved.

Figure 6.10: Planning layout general selections

On the selection screen, we want to be able to select the

variables period/year, customer, and product. As the possible
characteristic values for plant (ET11), sales organization
(ET15), distribution channel (01), and division (00) are always
identical for all planning values, you can define them as fixed in
the general selections. We can see the result of the general
selections when we access the planning layout via transaction
KE11 and navigate to the selection screen (see Figure 6.11).
Save your planning layout.

Copyright SAP AG. All rights reserved.

Figure 6.11: KE11 selection screen for our planning layout

You can now use transaction KE11 to enter planning data in the
layout. All you have to do is choose the planning period, a
customer, and a product for the selection (see Figure 6.12).

Copyright SAP AG. All rights reserved.

Figure 6.12: Manual planning selection

In accordance with Section 6.1.3, 17 units of A1 should be

planned for customer K1 (see Figure 6.18).

Copyright SAP AG. All rights reserved.

Figure 6.13: Sales quantity manual planning

Now check the characteristic derivation by

CHARACTERISTICS (see Figure 6.14 and Figure 6.15).


Copyright SAP AG. All rights reserved.

Figure 6.14: Characteristic derivation for planning I

Copyright SAP AG. All rights reserved.

Figure 6.15: Characteristic derivation for planning II

You can see that all characteristic derivations described in

Chapter 3 have been processed for planning. Now we want to
see if we have the same luck with the planning valuation. In
your planning layout, press VALUATE. The following screen
appears (see Figure 6.16):

Copyright SAP AG. All rights reserved.

Figure 6.16: Planning result

We are happy with this planning result. We can see that the
alternative quantity was found via user exit, and COPC was
processed for the material usage. The revenue, discounts, and
freight charges were found via the actual conditions of the
condition types of the actual SD pricing procedure ZEIF01.
If you do not agree with the planning result, via EXTRAS
VALUATION ANALYSIS you can press ANALYSIS to look at, for
example, the first valuation step more closely.

SD access sequence
The SD access sequences (an
access sequence in SD defines how
the SAP system finds a condition
record) can contain fields that are not
created as COPA characteristics in
your operating concern. You thus
have to tell COPA about these fields.

It is important that the SD actual conditions are entered for the

first day of the month for which you want to enter your planning
6.5.4 User Exit ZXKKEU14

The SD access sequences may use fields that are not

characteristics in your operating concern. In the user exit
ZXKKEU14 of the component COPA0002, you can make these
fields known to COPA to ensure that the actual conditions are
also found for the planning valuation.
6.5.5 Automatic Planning

If you have entered your planned sales quantities individually

via KE11 or using a batch input program and do not want to
have to press the VALUATE button every time, you can also
execute the valuation via automatic planning.
First we will check whether the planned quantities have been
entered correctly in accordance with the planning requirements.
You can check this using a COPA report, for example (for more
details about COPA reports see Chapter 7 of this book) see
Figure 6.17.

Copyright SAP AG. All rights reserved.

Figure 6.17: Check of the planned quantity at customer hierarchy level 1

In COPA reports, you can doubleclick a characteristic to

navigate to the underlying characteristic. This is called
drilldown. Now we drill down on the kind of product (see Figure
6.18 and Figure 6.19).

Copyright SAP AG. All rights reserved.

Figure 6.18: Planned quantity KH11 with kinds of product

Copyright SAP AG. All rights reserved.

Figure 6.19: Planned quantity KH12 with kinds of product

You can see that although you have only entered the planned
quantities via transaction KE11 at customer/product level,
further characteristics such as customer hierarchy level 1 and
kind of product have been derived and you have implemented
the requirements of your key account managers 1:1.
Now we want to valuate the planned quantities automatically.
To do this we use the old transaction KE1B. The screen shown
in Figure 6.20 appears.

Copyright SAP AG. All rights reserved.

Figure 6.20: Initial screen, transaction KE1B

You can remove the test run indicator if you want to post
planning data. The automatic planning (point of valuation 04) is
to take place in period 007.2012, in plan version Z01, and for
record type F (do you remember the assignment of your
valuation strategy in Section 6.5.1?).
You must select the VALUATE parameter, otherwise nothing will
happen. Now click PROCESSING INSTRUCTIONS. All of the
characteristics of your operating concern appear. For each
characteristic, you have to decide whether you want to copy it or
summarize it. Summarizing means that you aggregate the data

of various characteristic values. If a derivation exists, the

characteristic is derived again. If you choose COPY, the values
of the characteristic are copied directly.
If you want to make entries for a characteristic in the selection
criteria, you should copy this characteristic otherwise you can
summarize. A processing instruction variant could look as
shown in Figure 6.21.

Copyright SAP AG. All rights reserved.

Figure 6.21: Processing instructions for automatic planning

Now click SELECTION CRITERIA. You now choose precisely what

you want to plan. You can make selections at a very low level
(that is, the lowest level of a customer/product combination), or
you can valuate all of your planned quantities immediately
(Figure 6.22 represents the minimum specifications).

Copyright SAP AG. All rights reserved.

Figure 6.22: Selection criteria for automatic planning

Now click VALUE FIELDS. On this screen, you define the value
fields that you now want to plan. It makes sense to select the
value fields that you want to valuate using your valuation
strategy (see Figure 6.23).

Copyright SAP AG. All rights reserved.

Figure 6.23: Definition of the value fields for automatic planning

Saving variants
Before you execute, you should save
everything as a variant. The next time
you call up transaction KE1B, all you
have to do is load the variant and
straight away you have the
processing instructions, selection
criteria, and value fields.

Now check your entries and then execute. Hopefully the

following log will appear (see Figure 6.24).

Copyright SAP AG. All rights reserved.

Figure 6.24: Log of automatic planning run

Now you know that the automatic planning run was somehow
successful but do you have the desired planning result?
Again, you can view the planning result via a COPA report, for
example (see Figure 6.25).

Copyright SAP AG. All rights reserved.

Figure 6.25: Planning result down to GP1

Did you see how quickly we created an initial planning result

down to GP1? It can be displayed on all possible characteristics
(see Figure 6.26, Figure 6.27, and Figure 6.28, which show a

Copyright SAP AG. All rights reserved.

Figure 6.26: Drilldown from customer hierarchy I to kind of product

Copyright SAP AG. All rights reserved.

Figure 6.27: Drilldown from kind of product to customer

Copyright SAP AG. All rights reserved.

Figure 6.28: Drilldown from customer to product

Naturally you can also view your planning result at aggregated

level (see Figure 6.29).

Copyright SAP AG. All rights reserved.

Figure 6.29: Planning result at aggregated level

For further illustration, the video below once more explains the
planning process in detail.

Video 5: Planning

Note: Should your reading device not be able to show this

video, you can use your computer to watch it on the internet. To
do this, head to our web page at http://video5.copa
I will explain how you can create your own COPA reports and
execute drilldowns in them in the next chapter of this book.
You can now execute specific planning changes (e.g., with
transaction KE1B) or later, as described in Section 6.4,
distribute the planning over months with transaction KE1A.

Plea to SAP

As an inhouse consultant and

controller, the first thing I do with a
new release is check whether KE1A
and KE1B are still available! Only if
they are can I enjoy the new
Hopefully SAP will never remove the old planning
transactions KE1B or KE1A from the SAP ERP
system in new releases! Planning in COPA with the

new planning tools is more cumbersome and takes a

lot longer.
If I had to perform sales and turnover planning for a
company again, and the old planning transactions no
longer existed, I would no longer recommend
planning in COPA.

7 Dynamic Reporting
Many of the modules in the SAP system now have their
own information system. This includes, embedded in at
least the standard reports, Report Painter or Report
Writer reports that provide the information of the
respective module.
I deliberately refer to more than just the CO module here.
For example, there are also separate information systems in
Logistics modules including the Customer Service or
Project System modules.
COPA also has an information system but no standard
reports. The COPA information system is dynamic. You
can create your own profitability reports at any time. Why
are there no standard reports? As you learned in Chapter 2
of this book, in COPA you define your own value fields and
characteristics. You want to map your own individual
contribution margin structure why would you need
predefined standards? You want to evaluate your dataset
according to the characteristics you define and thus create a
multidimensional information system how would a
standard report recognize your characteristics? Therefore,
you define your own multidimensional profitability reports. In
these reports, you navigate between detail lists and
drilldown lists, from which you can navigate to the COPA
line items and from there to the original modules in which
the data arose. Using the drilldown function, you can
navigate through all characteristics that you have assigned
to your profitability report, from the highest customer
hierarchy through all further customer hierarchy levels down
to the customers. You have access to classic functions for
interactive processing: for example, sorting options, top N
functions, ABC analyses, and much more. You can create
plan/actual comparison reports, fiscal year comparisons, or

individual reports that perhaps consider only one special

value field. You can also download your data to Microsoft
Excel or other spreadsheet programs for all or selected
characteristics that you have assigned in the report.
But thats enough praise for the reporting in COPA. It
almost sounds like an SAP marketing brochure. At this point
however, I must point out that the COPA reports are only
useful as a pure management information system to a
limited extent. Many companies transport the data created
and collected in COPA to other management information
systems via interfaces. With SAP BW, SAP itself offers this
type of additional system in which you can use, for example,
management cockpits to not only supply your management
with the data required for controlling the company, but also
to spoil them with, for example, easy to use graphical
interfaces. This latter luxury is only available in the COPA
information system in a limited form (consider the possibility
to display diagrams) it does however offer controllers who
want to work seriously with it numerous and dynamic
The profitability reports that I describe below are drilldown
reports. They allow you to toggle between the
characteristics presented once you have executed the
report. This makes drilldown reports easier to handle than,
for example, Report Painter reports that you may know from
other CO submodules.
To get as far as being able to create your own profitability
report, however, you need modules that need a profitability
report. This type of module is called a report component and
is described in the next section.
7.1 Information System Components
If you want or have to create profitability reports in COPA
because, as described in the previous section, there are no
standard reports in COPA, you need report components

that you also have to create in advance.

You need the following report components:
Key figure scheme
Reporting variable
Profitability report form
Firstly, I recommend that you create a key figure scheme by
defining your contribution margin structure. This saves you
having to constantly repeat the contribution margin structure
in every report form.
Secondly, I recommend creating separate variables for the
characteristics that you want to use to evaluate and select
your data. This enables you to call up individual
characteristic values or intervals when you call up reports. If
you also define these variables as selection options, you
can call up individual characteristic values, characteristic
value intervals, or multiple selections for different
characteristic values, similarly to the situation that you
already know from other selection screens in the SAP
As a third reporting component, I recommend the forms for
profitability reports. You will not need all of the forms, only
the form for the two axes (matrix) structure.
This type of profitability report form enables you to establish
a basis for a profitability report that provides the advantages
mentioned in the previous section. The form should be
viewed similarly to a Report Painter form, the difference
being that in contrast to other SAP information systems, you
do not navigate to individual classic sets (infosets, single
set, etc.). Your sets are the characteristics and value fields
that you define in your operating concern.
A COPA form consists of three main parts:

General selections
In the lines you define your contribution margin structure.
Here you can also access the elements of the key figure
scheme that you previously created. You use the columns
to select whether you want to see actual or planning data, or
whether you only want to present specific data that has
been incorporated in COPA via a specific record type (e.g.,
A, then you only see your incoming sales orders). In the
general selections, you can define the characteristics that
you want to use for navigation in the subsequent report.
Wherever you decide to specify a characteristic, it is
advisable to work with the previously defined variables so
that you only select the characteristic when you call up the
report or not at all, and can create the report flexibly. In the
next sections, I will use our example to show how you can
create the report components that I have described.
If you require more detailed information specifically for
Report Writer and Report Painter Reports, I recommend the
book Praxishandbuch Report Painter/Report Writer by my
Espresso Tutorials publishers Martin Munzel and Jrg
Siebert (published by SAP Press in 2012, available in
German language only).
7.2 Example Customizing of Report Components
As stated in the previous section, I will now describe the
information report components that you need for a COPA
7.2.1 Key Figure Scheme

You use a key figure scheme to map your contribution

margin structure, for example. A key figure scheme enables
you to define frequently used arithmetic operations so that
you can use them repeatedly in reports. The formulas in a

key figure scheme can be based on both value fields and on

already defined formulas of the same key figure scheme.
You can define a key figure scheme in the COPA
configuration menu, via INFORMATION SYSTEM REPORT
example, I have created the key figure scheme Z1 for the
contribution margin accounting (GP Accounting) that we
want to map (see Figure 7.1).

Copyright SAP AG. All rights reserved.

Figure 7.1: Definition of a key figure scheme in accordance with our

example contribution margin structure

In Figure 7.1, in the elements 50 to 900 you can see the

names of the elements of the key figure scheme these

elements contain certain key figures.

For each element, you now define a basic formula. You do
this by selecting an element and then clicking BASIC
FORMULA (see Figure 7.2).

Copyright SAP AG. All rights reserved.

Figure 7.2: Detailed definition of the element of a key figure scheme

We will do that now using the example of element 50, Sales

quantity. On the next screen, define the basic formula for
the sales quantity. It should be presented as a positive
figure you control this using the plus symbol. The system
assigned element 9001 to the sales quantity field defined in
operating concern Z111. You now select this element (see
Figure 7.3).

Copyright SAP AG. All rights reserved.

Figure 7.3: Key figure scheme element, sales quantity

Do the same for the remaining elements that you have

already defined as quantity and value fields.

The procedure is different for the subtotals in your
contribution margin scheme. As an example, let us look at
element 300, BILL REVENUES (= invoice sales). We want to
calculate these invoice sales as the difference between
gross sales and discounts. Gross sales and discounts are
separate value fields in your operating concern, which
means that the system has already assigned elements 9003
and 9004 accordingly. Figure 7.4 shows this in more detail.

Copyright SAP AG. All rights reserved.

Figure 7.4: Key figure scheme element, invoice sales

You can see a further example of a subtotal in Figure 7.5.

We calculate the subtotal Gross Profit 1 (GP1), that is, key
figure scheme element 650.

Copyright SAP AG. All rights reserved.

Figure 7.5: Basic formula for key figure scheme element GP1

The special feature of this formula is that it combines

elements defined by the system and elements defined in the
key figure scheme. The systemdefined elements 9006,
9007, and 9008 are deducted from the key figure scheme
element 300 to calculate the key figure scheme element
650, which represents the subtotal GP1. The system
proposes the systemdefined elements (9000+) when you
create the basic formula if you open the adjacent
In the next section, I will describe how to create report
variables that you also need for your profitability reports.
7.2.2 Report Variables

If you want to define reports or formulas flexibly, work with

variables. You do not fill specific fields until you define or
execute a report. You can define variables for reports either
from the application menu or from the COPA configuration
menu. In the latter case, you do this via INFORMATION
REPORTS. After clicking NEW ENTRIES, you first have to
select a variable type. For our profitability reports we need

variable types 1 and 3.

You use a variable for characteristic values (variable
type 1) to allow the entry of values for characteristics
only when the user calls up the report.
You use a text variable (variable type 3) in the same
way as variables for characteristic values but to display
texts instead of characteristic values.
After the variable type, you determine a variable name. This
name defines how the variable is found in the application.
We will now create a variable for the characteristic
Customeras an example (Figure 7.6).

Copyright SAP AG. All rights reserved.

Figure 7.6: Selection variable for KNDNR

Tip: if, under PARAMETER/SELECTOPT., you select the value

Select Option, when you execute a report you can make
multiple selections (see Figure 7.7). If you select Parameter,
when you execute a report, you can only leave the
CSTOMER field blank or enter a specific value. If, for

example, you want to see an interval of customers, you

would have to enter two variables (FromCust. and ToCust.)
to make this possible.

Copyright SAP AG. All rights reserved.

Figure 7.7: Multiple selection options via selection option

I recommend creating characteristic variables for all

characteristics that you want to use in your profitability
The third report component that you need for COPA reports
are the profitability report forms that I will describe in the
next section.
7.2.3 Profitability Report Forms

A profitability report form describes the content and formal

structure of a report. As explained at the beginning of this
chapter, I recommend using only forms of type Two axes
(matrix) as the form for your profitability reports. You create
forms via transaction KE34 (see Figure 7.8).

Copyright SAP AG. All rights reserved.

Figure 7.8: Creating profitability report forms

Before I describe all of the steps that you have to execute to

create a form, Figure 7.9 shows how the form should look
when complete:

Copyright SAP AG. All rights reserved.

Figure 7.9: Completed profitability report form

As I explained regarding the planning layout in the Planning

in COPA chapter, this form consists of three parts:
General selections
For our example, let us start with the lines. The aim of our
form is to display the actual and planned figures for
contribution margin accounting. As lines we use the lines of
the key figure scheme previously created. We do not make
any restrictions using additional characteristics. In an empty
form, the lines are displayed as dots. Simply doubleclick a
dot. In the dialog box that appears, select KEY FIGURE
SCHEME ELEMENT (see Figure 7.10).

Copyright SAP AG. All rights reserved.

Figure 7.10: Selection of the element type for a line definition

A further window appears, and here you can select the key
figure scheme element at the top. As stated above, you do
not need to make any further characteristic selections (see
Figure 7.11).

Copyright SAP AG. All rights reserved.

Figure 7.11: Element definition, sales quantity line

Once you press CONFIRM, your line (in our example the
Sales quantity line) is defined. Proceed in the same way
for all lines of your contribution margin scheme until you
have defined all lines.
In the next step, define your columns. Remember: we want
an actual data column and a planned data column, a
variance column, as well as an actual and planned column
per kilogram.
Let us start with the actual data column. In a blank form,
again you see only dots where you can create columns.
Doubleclick a dot and a dialog box appears (see Figure

Copyright SAP AG. All rights reserved.

Figure 7.12: Definition of the Actual Data column

For this column we have selected two characteristics: the

Planned/actual indicator and the characteristic Period/year.
The characteristic value 0 (= actual) in the Planned/actual
indicator characteristic defines that this column is only to
accept actual values.

Via the Period/year characteristic, for each column you can

control which period is to be presented. As we do not want
to define the period selection when we are defining the
form, for the first time we work with the previously created
report variables here. We use the variable PERIO, meaning
that when you run the report, you have multiple selection
options for periods.
In our example, we have introduced the alternative sales
quantity. The sales quantities are also converted into
kilograms and presented. It is not up to me to decide
whether it makes sense in your company to compare
products and their conditions using the weight. You may
have other unit sizes that you can use to compare your
products. The important point for this book is that I have
showed you, via the customizing and coding, how to present
alternative quantities. Let us assume that you could
compare using kilogram. Now at the intersection of the
ACTUAL DATA column you have just defined and the ALT.
QUANTITY line, you have to present the cell as selected. To
do this, click the corresponding cell and click SELECTED (see
Figure 7.13).

Copyright SAP AG. All rights reserved.

Figure 7.13: Selecting a cell in a form

In the form, the cell now has a checkmark (see Figure 7.14).

You can now use this selected cell in the next column.

Copyright SAP AG. All rights reserved.

Figure 7.14: Selection of a cell

We now want to define the ACTUAL/KG column. Again,

doubleclick the next free column dot and choose FORMULA,
as this column is to be a formula. A formula editor appears,
and here you can enter your formula (see Figure 7.15).

Copyright SAP AG. All rights reserved.

Figure 7.15: Formula editor for Actual/kg column

As it is to be a formula for columns, with the name X001

etc., the columns you have created are proposed for use in
the formula. Now you can see why we selected the cell from
the intersection of ACTUAL DATA/ALT. QUANTITY. The
selection makes the cell known to the formula editor: here it
is cell Z001. In the upper box, write the formula for the
ACTUAL/KG column: X001/Z001. The result is that all cells
in the columns will accept the actual values of the actual
column divided by the value of cell Z001. Once you confirm
the formula editor the column is defined.
Similarly, define the columns for PLANNING DATA and
PLAN/KG. In the planning column, use 1 (= plan) for the
planned/actual indicator. As every plan should be saved
with a plan version, so that you can compare different plans
later, specify the characteristic Plan version in the
characteristic selection (see Figure 7.16).

Copyright SAP AG. All rights reserved.

Figure 7.16: Definition of the Planning Data column in the form

Use a variable that you have defined for the version as well,
so that you do not have to decide now which plan version
you want to see (you decide when you call up the report).
The VARIANCE column is also a formula: actual data minus
planning data. Again, click the next free point, define the
column as a formula, and again, the formula editor appears
automatically. Here you can state: actual data minus
planning data. The lines and columns now look like the
target definition as presented in Figure 7.9.

Intersection of line and column formulas

If you create forms without using
a key figure scheme, you also
have to work with formulas in
some lines, for example, for
subtotals. The SAP system may
not know which formula has
priority: the line formula or the
column formula. Inform the cell concerned at the
intersection of the line and column whether the
line or column calculation has priority by double

Now you have to define the third form element: the general
selections. These are in the form under EDIT GEN. DATA
For our example, we have included the characteristics that
you want to select when calling up a relevant report and that
you can use for drilldown in a report (see Figure 7.17).

Copyright SAP AG. All rights reserved.

Figure 7.17: General selections in a form

Here too, you should use variables so that you do not have
to decide until you call up the report whether you want to
see all or only certain characteristic values of a
characteristic in the report.
Then you can check and save the form. You can use it in as
many profitability reports as you want.
7.3 Drilldown Reports
The reports that you set up based on the two axes (matrix)
structure of the profitability report forms are called drilldown
reports. These drilldown reports offer the functionalities that
I described in the introduction to this chapter.
If you want to create this type of drilldown report, you can
define the characteristics to be used for navigation and
drilldown. You can also use the characteristics for sorting
the drilldown. You can use the characteristics from your
form, or other characteristics. To avoid long waiting times

when you are selecting your dataset, in the report you can
configure whether it has to access data at a summarization
level or not. You need summarization levels to summarize
the COPA dataset in advance so that you can call up the
required information quickly. I will explain this further in
Section 8.1.
You can also split profitability reports. For example, you
initially call up a profitability report that contains only
customerspecific characteristics. In the report, navigate
down to an individual customer. Now call up a second (split)
profitability report for this customer that contains all required
productspecific characteristics. The option of splitting
reports is useful for datasets that are very large and need a
report split as described in order to allow the presentation of
customerspecific and productspecific information together.
The following are usually useful as drilldown reports:
Actual/plan comparisons
Yearly comparisons
Planning reports
Variable period reports
As already mentioned, you can also set up reports via a
value field or multiple special value fields to create special
I also recommend creating profitability reports that refer only
to general and productspecific characteristics for the four
forms mentioned above. Reports that only contain
customerspecific characteristics are also useful. And finally,
you can create reports that contain both productspecific
and customerspecific characteristics but that should really
only be used if you need information based on the
combinations of productspecific and customerspecific
7.4 Line Item Layouts

In Chapter 5, Actual Value Flows, I reported a great deal

about possible line item corrections. The prerequisite, of
course, is that you can also present the line items how you
need them. Thus it is useful to create individual line item
Using line item layouts, you can display the recorded CO
PA line items in lists, download them, or print them. You can
call up line item layouts via the COPA application menu.
The path is as follows: INFORMATION SYSTEM CURRENT
When you create a layout, you first have to give it a name
(see Figure 7.18).

Copyright SAP AG. All rights reserved.

Figure 7.18: Creation of a line item layout I

Then click CREATE and the initial screen appears (see

Figure 7.19).

Copyright SAP AG. All rights reserved.

Figure 7.19: Line item layout initial screen

By doubleclicking the individual elements (or, if you have

already defined Element 4, by clicking a dot), you can add
characteristics and value fields from your operating concern.
You can also select date fields such as CREATED ON,
invoicing date, etc. (you do not have these fields in the
drilldown reports). I have created an example layout see
Figure 7.20.

Copyright SAP AG. All rights reserved.

Figure 7.20: Example line item layout

You can use these line item layouts for both actual and
planning line items, specifically for transactions KE24
(Display Actual Line Items) or KE25 (Display Planning Line
The SAP system selects line items according to the
selection criteria (see Figure 7.21) that you specify when
calling up KE24 or KE25.

Copyright SAP AG. All rights reserved.

Figure 7.21: KE24 selection screen

The result could look as follows (Figure 7.22):

Copyright SAP AG. All rights reserved.

Figure 7.22: COPA actual line items list display

Now that you have become familiar with both types of

forms, I will show you how to create the actual reports.
7.5 Structure of a Profitability Report for Our Example
Using the example form that we have set up in this chapter,
we now want to use transaction KE31 to create a
profitability report (see Figure 7.23).

Copyright SAP AG. All rights reserved.

Figure 7.23: Creating a profitability report

First you have to name your report. Select REPORT WITH

FORM and specify which form you want to access. Then
click CREATE.
TYPE, and
OPTIONS) (see Figure 7.24).

Copyright SAP AG. All rights reserved.

Figure 7.24: Initial screen for creating a report

To define the report completely, you have to work through

all four tabs. On the CHARACTERISTICS tab, first select the
characteristics that you want to report on via drilldown.
On the VARIABLES tab you see the report variables that you
selected in your profitability report form. As the variables in
our example were mainly variables with selection options,

they are only displayed gray here, meaning that you cannot
change them (see Figure 7.25).

Copyright SAP AG. All rights reserved.

Figure 7.25: Variable for creating a report

On the next tab, OUTPUT TYPE, you define how the report is
to be executed. Here we decide on the classic drilldown and
want to start the report structure with the detail list (see
Figure 7.26).

Copyright SAP AG. All rights reserved.

Figure 7.26: Definition of the output type when creating the report

Detail list means that the report always starts with the
presentation of contribution margin accounting in line form.
In contrast, Drilldown list means that the individual
contribution margin items are displayed in column form. The
fourth tab is shown in Figure 7.27.

Copyright SAP AG. All rights reserved.

Figure 7.27: Options for creating the report

In this image, you can see the various options offered by

SAP be they for the print setup, the drilldown list, or for
comments, etc. The important thing on this tab, however, is
the PERFORMANCE block. The longer you work with COPA,
the more line items you save (on a daily basis probably
hundreds, if not thousands). If you do not work with
summarization levels (which I will explain in more depth in
the next chapter), calling up the report can take an
increasingly long time for performance reasons. Therefore,
when you call up the report, you should read summarization
levels and at least receive a warning if the report does not
find any summarization levels. Then save and execute the
7.6 Example of Dynamic Reporting
We are slowly approaching the end of this book. I have told

you a lot about characteristics, value fields, derivations,

valuations, interfaces, data transfers, actual data, planning
data, report components, and reports. If you do not use any
other management information system into which, for
example, you transfer the COPA line items created, to
display the results you need the COPA information system
and thus the dynamic reporting described. Using the
example report that we have created, I will now show you
everything we have created.
Using transaction KE32, you run profitability reports and a
selection screen appears on which you can enter the
characteristic values for which you want to see data (see
Figure 7.28).

Copyright SAP AG. All rights reserved.

Figure 7.28: Profitability report selection screen

After making your entries, execute the report. A warning

may appear stating that no summarization level was found.
Ignore this with YES if the dataset of your COPA data is not
too large. The report starts with the basic detail list (see
Figure 7.29).

Copyright SAP AG. All rights reserved.

Figure 7.29: Basic detail list

You can now see the data for your entire selection
controllers will be delighted...
Now we switch to the drilldown list for the characteristic
sales organization (see Figure 7.30) via NAVIGATE SALES
ORGANIZATION (your characteristic is part of the path!):

Copyright SAP AG. All rights reserved.

Figure 7.30: Basic list, detail list, sales organization

By pressing the cassette recorder keys

can display your entire contribution margin structure as
Via EDIT COLUMN(S) ON/OFF you can display or hide the
columns. If you initially only want to see your actual data in
the drilldown list, for example, select an actual column by
clicking it and then follow the path above. In the example we
want to look at the actual bill revenues (= invoice sales)
(see Figure 7.31).

Copyright SAP AG. All rights reserved.

Figure 7.31: Actual bill revenues for sales organization

By doubleclicking the characteristic value we start a

drilldown consideration downwards through the customer
hierarchies to customer 5 and the products this customer
has purchased (see Figure 7.32).

Copyright SAP AG. All rights reserved.

Figure 7.32: Drilldown to customer 5 and his products

You can also view the actual and planned contribution

margin for this combination of characteristics as a detail list:
for example, place the cursor on Product 2 and choose
NAVIGATE DETAIL LIST (see Figure 7.33).

Copyright SAP AG. All rights reserved.

Figure 7.33: Contribution margin accounting for selected characteristic


Now switch back to your drilldown list (via NAVIGATE

key (or F3) to return to the
PRODUCT) and use the
distribution channel in your original drilldown, for example.
There, choose NAVIGATE SWITCH DRILLDOWN and select a
characteristic that you now want to see, for example, kind of
product. Select PA1 and switch back to the detail list (see
Figure 7.34).

Copyright SAP AG. All rights reserved.

Figure 7.34: Contribution margin accounting for kind of product PA1

The possibilities for displaying the selected dataset are

infinite. You may wonder why my publisher and I decided on
a threedimensional cube as the cover for this book...
In COPA there are a number of other options for working in
the information system. However, as this book does not
claim to be a complete compendium of all options, in my
descriptions of the tools and methods I have restricted
myself to the most useful (in my opinion) that you can use in
practice in your Profitability Analysis.

In the next chapter, I will describe some COPA tools, such

as the summarization levels addressed in this chapter,
which will make your work in COPA easier.

8 Tools in COPA
COPA offers various tools that are intended to make
your work in COPA easier or to support you. They
include tools for performance improvement, the
transfer of data from external systems, the analysis of
value flows into COPA, live start preparations,
authorization administration, and, last but not least,
SAP enhancements, that is, the user exits that you have
become familiar with in various chapters of this book.
In accordance with the philosophy of this book, which is to
show you things in COPA that you need to start working
quickly, I will restrict myself to two important aspects: the
topic of performance improvement as a result of working
with summarization levels, and the analysis of value flows in
8.1 Summarization Levels
When you call up profitability reports, you want to see the
required data within a reasonable time. The larger the
dataset of actual and planning line items in COPA, the
longer it takes to access this dataset. In COPA, you can
avoid frustration when accessing the line items by defining
summarization levels that summarize new and existing line
items in regular jobs and thus considerably accelerate the
access to the dataset.
If you want to create summarization levels, COPA offers
you the opportunity of creating proposals. You can accept
these proposals or create a summarization level for every
profitability report. Based on many years of experience, I
recommend only three summarization levels:
Level 1 contains all productspecific characteristics plus

the characteristics that are not directly dependent on

customers or products.
Level 2 contains all customerspecific characteristics
plus the characteristics that are not directly dependent
on customers or products.
Level 3 contains all customerspecific and product
specific characteristics plus the characteristics that are
not directly dependent on customers or products. This
level is almost identical to the line item level in COPA.
However, as characteristics such as date specifications
etc. are not summarized, the level is smaller.
If you create the profitability reports that I recommended in
Chapter 7, the three summarization levels described are
sufficient. Why only three levels? Each summarization level
will need additional disk space the fewer the number of
levels you have, the lower the memory capacity you need
from your basis. Every night you should schedule a
background job that adds the line items created during the
day to the line items already summarized.
8.1.1 Example Customizing for a Summarization Level

You can access the summarization level view via the

configuration menu for COPA (ORKE) under TOOLS
(see Figure 8.1).

Copyright SAP AG. All rights reserved.

Figure 8.1: Initial screen for defining summarization levels


SAP system create a proposal (see Figure 8.2).

Copyright SAP AG. All rights reserved.

Figure 8.2: Own or proposed summarization levels

8.1.2 Activating Summarization Levels

For COPA to find the summarization levels when reading

the data (for example, for planning or when calling up a
report), the levels must be active.
You activate your summarization levels via the COPA
REFRESH), see Figure 8.3.

Copyright SAP AG. All rights reserved.

Figure 8.3: Refreshing summarization levels

8.2 Analyzing Value Flows

Before you actually post COPA line items, COPA offers
you the option of simulating your valuations and value flows
in COPA in advance. You can call up this analysis directly
from the COPA application menu (see Figure 8.4).

Copyright SAP AG. All rights reserved.

Figure 8.4: Options for analyzing value flows

8.2.1 Checking the Customizing Settings

You can check the customizing settings of the

organizational structures of your COPA (see Figure 8.5).
You may remember my statement: The organizational
structures are the backbone of the SAP system. Using this
monitor you can check further customizing settings.

Copyright SAP AG. All rights reserved.

Figure 8.5: Customizing Monitor for checking the organizational structures

Value Field Analysis

Let us start with the value field analysis (see Figure 8.6).

Copyright SAP AG. All rights reserved.

Figure 8.6: Value field analysis initial screen

After clicking EXECUTE you can analyze your settings

completely (see Figure 8.7).

Copyright SAP AG. All rights reserved.

Figure 8.7: Results of the value field analysis

You can see which fields are served by each interface.

Using the buttons displayed at the top of the screen, you
can navigate to the SD conditions, the PA transfer structure,
or the defined assessments.
Overview of Valuation
In the next step, we check the valuations for record types A,
F, B, and C at the actual point of valuation 01 (see Figure

Copyright SAP AG. All rights reserved.

Figure 8.8: Executing the valuation overview

After executing the overview you see the following result

(Figure 8.9):

Copyright SAP AG. All rights reserved.

Figure 8.9: Results of the valuation analysis

In this image, you can see which valuation strategies are

assigned to your record types. You can see that for each
record type, on one hand the material costing is processed
and on the other, user exit U01.
This valuation analysis offers users the advantage that they
can see what is set without requiring customizing

Overview of Derivation
Figure 8.10 shows the initial screen for the derivation

Copyright SAP AG. All rights reserved.

Figure 8.10: Initial screen of the derivation overview

When you run the derivation overview, for each derived

characteristic you receive a log of the source and target
fields. You can use these to analyze precisely whether the
characteristic derivation is working correctly (see Figure
8.11). This is shown for derivation step 11 as an example.

Copyright SAP AG. All rights reserved.

Figure 8.11: Partial log as results of the derivation overview

Report Overview
The initial screen of the report overview in the Customizing
Monitor looks as shown in Figure 8.12.

Copyright SAP AG. All rights reserved.

Figure 8.12: Initial screen of the report overview

When you run the report overview, you receive an overview

of the fields used in a profitability report together with
information about how they are used (see Figure 8.13).

Copyright SAP AG. All rights reserved.

Figure .13: Results of the report overview

"R(D) denotes a report characteristic for which further

drilldown is possible. F(N) denotes a characteristic from a

form for which drilldown is not possible.

Summarization Level Overview
In this overview, you can see the summarization levels
created for your operating concern, as well as the
characteristics used for summarization (see Figure 8.14).

Copyright SAP AG. All rights reserved.

Figure 8.14: Overview of summarization levels

8.2.2 Simulating Documents

Now that you have been able to check your COPA

customizing intensively in the steps described above, in the
further substeps of the ANALYZE VALUE FLOWS item, CO

PA enables you to simulate documents. For the invoice

transfer and sales order transfer items, you have to specify
an SD document. In the analysis, you can then trace the
behavior of COPA for the posting precisely. I will explain
the point SIMULATE VALUATION in more detail as an example
(see Figure 8.15).

Copyright SAP AG. All rights reserved.

Figure 8.15: Accessing the valuation simulation

Similarly to transaction KE21 (Enter Actual Line Items), you

first access the initial screen (see Figure 8.16).

Copyright SAP AG. All rights reserved.

Figure 8.16: Initial screen for the valuation simulation

Enter a posting date, the record type, and the point of

valuation at which you want to simulate the valuation. In the

next step, specify some characteristic values (see Figure


Copyright SAP AG. All rights reserved.

Figure 8.17: Entry of characteristics for the valuation simulation

We want to run the simulation for customer K1 and product

A1 from our example data. However, first we want to check
whether the derivation works. By clicking DERIVATION, you
can see that further characteristics have been derived (see
Figure 8.18).

Copyright SAP AG. All rights reserved.

Figure 8.18: Successful characteristic derivation for valuation simulation

Characteristics were derived for the customer hierarchy, the

product hierarchy, and the customer group. Switch to the
VALUE FIELDS tab and enter a sales quantity. Then click
VALUATION. You get the result shown in Figure 8.19.

Copyright SAP AG. All rights reserved.

Figure 8.19: Results of the valuation simulation

You have now got to know two COPA tools that, in my

opinion, are important. This is almost the end of the book.
The next chapter contains a few closing words.

9 Closing Words
The aim of this book was to share my experiences in CO
PA with you in a userfriendly way and to give you a quick
guide to SAP Profitability Analysis. You now know what CO
PA is. By the time you come to these closing words, you will
be able to express yourself in discussions and meetings and
be able to shine as a true COPA expert. If you want to
implement COPA, use my tips and you will implement a
COPA that you can work with intensively in the future. I
wish you every success in the supreme module of the SAP
ERP system.

Gttingen, September 2012

Stefan Eifler

You have finished the book.

Did you like what you read?

Then please write a review for this book!

Learn more about new ebooks?

Get exclusive free downloads

Sign up for our newsletter!

A The Author

Stefan Eifler has worked as an external and internal SAP

consultant for more than 17 years, focusing on CO. He
specializes in Profitability Analysis (COPA).
After completing his business studies degree at the Ruhr
Universitt Bochum, Germany, he began work as an
external SAP consultant at COPA GmbH, a consultancy
specializing in the beverages industry. He has implemented
the module CO, always including COPA, successfully and
on schedule at many wellknown companies in the
beverages industry, such as CocaCola, Veltins, Schwarze,
Amecke, Berentzen, and Schneider Weisse. After marrying
his wife Karin and while awaiting the birth of his son Jan
Lukas, Stefan accepted an offer from BerentzenGruppe AG
to work there as an inhouse SAP consultant. There, as lead
for controlling projects, in addition to many SAP projects,
such as the implementation of SAP R/3 when the Berentzen
companies were merged into one company, he led projects

such as the implementation of international reporting (IFRS)

for December 31, 2005. In additional roles such as sales
and production controller, Stefan was able to gather a lot of
practical experience in controlling. Thanks to his holistic
business training, he was also the risk manager for
BerentzenGruppe AG and supported numerous internal
and external students with their degree dissertations and
Since February 2012, Stefan has been working at the global
company Sartorius AG in Gttingen, Germany, as an in
house consultant for CO and PS (Project System), enabling
him to gather deeper international experience.

C Disclaimer
Names used in this book, trade names, commodity names
etc. can be brands even though they have no marking and
as such are subject to legal requirements.
All screenshots printed in this book are subject to copyright
of SAP AG, DietmarHoppAllee 16, 69190 Walldorf,
This publication makes reference to products of SAP AG.
SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign,
SAP BusinessObjects Explorer, StreamWork, and other
SAP products and services mentioned in the text, as well as
the respective logos, are trademarks or registered
trademarks of SAP AG in Germany and in other countries
worldwide. Business Objects and the BusinessObjects logo,
BusinessObjects, Crystal Reports, Crystal Decisions, Web
Intelligence, Xcelsius, and other Business Objects products
and services mentioned in the text as well as the respective
logos are trademarks or registered trademarks of Business
Objects Software Ltd. Business Objects is a company in the
SAP AG group. Sybase and Adaptive Server, iAnywhere,
Sybase 365, SQL Anywhere, and other Sybase products
and services mentioned in the text as well as the respective
logos are trademarks or registered trademarks of Sybase
Inc. Sybase is a company in the SAP AG group. All other
names of products and services are trademarks of the
respective companies. The details in the text are not binding
and are for information purposes only. Products may differ
from country to country.
SAP Group shall not be liable for errors or omissions in this
publication. The only warranties for SAP Group products
and services are those that are set forth in the express
warranty statements accompanying such products and
services, if any. No further liability arises from the

information contained in this publication.

Ulrich Schlter & Jrg Siebert

SAP HANA for ERP Financials
Basic principles of SAP HANA

Potential of inmemory technology

Presentation of existing HANA applications in
Illustrative examples, supported by videos
With their latest database technology High Performance
Analytic Appliance (HANA), SAP is trying no less than to
revolutionize the database market, speed up evaluations,
and change business processes fundamentally.

Anurag Barua
First Steps in SAP Crystal Reports for Business Users
When SAP acquired Business Objects in 2008 Crystal

Reports became a standard part of SAPs software and

menu of reporting tools. This book written specifically for
business users provides an introduction to SAP Crystal
Reports using a realworld business reporting scenario and
will enable you to create your first report. Well cover:
Overview, history and evolution of Crystal Reports
Basic enduser navigation
Creating a basic report from scratch
Formatting to meet individual users presentation needs
Analysis techniques such as using formulas,
sorting/filtering, grouping, summarizing, and creating
Best practices for report distribution
Detailed screenshots and explanations paired with a
business reporting scenario will prepare you step by step to
work efficiently with SAP Crystal Report version 2011.

Michael Esser
Investment Project Controlling with SAP
This book is a practical guide for business users to fully

leverage the functionality of SAP PS for controlling major

SAP PS explained
Project Concepts, Roles and different scenarios
Effective planning and reporting