quick guide to co pa profitability analy

8/17/2019 Quick Guide to CO PA Profitability Analy

http://slidepdf.com/reader/full/quick-guide-to-co-pa-profitability-analy 1/215

https://books.google.com.tr/books?id=TVHuBgAAQBAJ&hl=tr



HH

espresso

||tutorials

Sean Eſler

Quick Guide to SAP CO-PA

( P r o f i t a b i l i t y

A n a l y s i s )

Successfully implementing a - Optimizing planning t o o l s

c o n t r i b u t i o n margin a n a l y s i s

-

Defining

the

a c t u a l

value

flow

-

Includes

5

wideo

tutorials



S t e f a n

E i f l e r :

Quick

Guide

t o

SAP®COPA

rofitability Anal y sis

ISBN:

9783943546132

(kindle)

9783943546149 (epub)

Copyediting: Martin Munzel

Translation: Tracey Duffy

Cover

design:

Philip

E sc h,

Martin

Munzel

Cover p h o t o :

iStockphoto

A l l rights reserved.

1.

Edition 2013,

Gleichen

©

Espresso Tutorials

GmbH

URL: w w w.espressotutorials.com

This work

i s

subject

to

copyright

i n

i t s

entirety.

A l l

rights

reserved, especially

t h e

rights of translation,

r e c i t a l ,

reproduction, and duplication. Espresso Tutorials GmbH,

ZumGelenberg

11,

37130 Gleichen, Germany.

Regardless

of

t h e

care t aken

i n

producing texts and

i l l u s t r a t i o n s ,

t h e

publisher,

t h e

authors,

and editors accept

no legal

l i a b i l i t y

whatsoever f o r

possible

mistakes

and

t h e i r

consequences.

Feedback:

We are

happy

to

receive

any

questions

o r

comments

you

may

h a v e.

Please send

any

feedback

t o :

[email protected].



For

my family



Table Of Contents

1

Introduction:

COPA

h e

Supreme

Module

2 Structures

i n

COPA

2.1

The Intent and Purpose

of

COPA

2.2

The

Operating

Concern

2.3

Master

Data

i n

COPA

2.4

Cos tingBased

o r

AccountBased

P r o f i t a b i l i t y

Analysis?

2.5

Setting

Up

an

Example

Operating

Concern

2.5.1

Description

of

t h e

Main

Example Data

2.5.2 Cust o mizin g t h e Example O pera ting Concern

Maintaining

operating

concerns

Assigning

t h e

operating concern

3 Characteristic

Derivations

3.1

What Are

Characteristic

Derivations?

3.2

Methods of Characteristic Derivation

3.3

Characteristic Derivations

f o r

Our Example

3.3.1 Assignment

3.3.2 Ta ble Lookup

3.3.3

SAP

Enhancement

3.3.4

I n i t i a l i z a t i o n

3.3.5

Derivation

Rule

4

Valuation

4.1

Valuation

Types



4.1.1 Valuation via Material Co s ti n g

Define Access

to

Standard Cost

Es tima t es

Assig n

Co s ti n g Keys

to

Material Types

Assig n

Value

Fields

4.1.2 Valuation via

a

Pricing Procedure

i n

SD

o r

COPA

4.1.3 Valuation via

User Exits

5

Actual

Value

Flows

5.1

The

Most

Important Interface

to

COPA:

The SD

Interface

5.1.1

Handling

of

Quantity Fields

5.1.2

Transferring

Invoice Data

5.1.3 Transferring Incoming

S a l e s

Orders

5.1.4

SD

Interface f o r

Our

Example

Data

5.1.5

Cust o mizin g t h e

SD

Interface

5.2

Settlement

to

COPA

5.2.1 Cust o mizin g t h e Settlement

to

COPA

f o r Our

Example

5.3

FI

Interface

5.4

Cost Cen ter Assessments

5.5

Direct

Line

Item

Corrections

i n

COPA

5.5.1

Types

of

Errors and

How to Correct Them

5.5.2 Security

Measures

5.5.3

Simplifications

i n

Line

Item

Corrections

6 Planning

i n

COPA

6.1

S h or teni n g

t h e

Planning

Process without Lo sing

Quality



6.1.1

Reducing

t h e

Planning

Effort ip

1

6.1.2 Reducing

t h e

Planning Effort

ip

2

6.1.3 Reducing

t h e

Planning Effort

ip

3

6.2

F a s t

Yearly

Planning

i n

Detail

6.2.1 Recording Yearly Planned Quantities

6.2.2 Valuation of Planned

S a l e s Quantities

6.2.3 Adjustment

Phase

6.3

Planned Cost Center Assessments

6.4

Distributing t h e

P l an nin g o v er

Months

6.5

Planning

Our

SAP

Example

6.5.1

P l a n Version

and Planning

Valuation

S tra tegy

6.5.2 User

Exit

f o r Planning

Valuation

6.5.3 Manual Planning Layout

6.5.4 User Exit ZXKKEU14.5.5

Automatic

Planning

7

Dynamic

Reporting

7.1

Information System

Components

7.2

Example

Cust o mizin g

of

Report

Components

7.2.1

Key

Figure Scheme

7.2.2

Report

Variables

7.2.3 P r o f i t a b i l i t y Report

Forms

7.3

Drilldown Reports

7.4

Line Item La y ou t s

7.5

Structure

of

a


Report

f o r Our

Example

7.6

Example of Dynamic

Reporting



8

T o o ls

i n

COPA

8.1

Summarization

Levels

8.1.1 Example

Cust o mizin g

f o r

a Summarization

Level

8.1.2

Activating

Summarization

Levels

8.2

Analyzing Value Flows

8.2.1 Checking t h e Cust o mizin g

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

t h e

Supreme

Module

I f

you work

in

a company that uses SAP R/3 or,

more

recently,

SAP

ERP,

o r

in a company t h a t

is

intending

t o

implement SAP, you

may

have already encountered

CO

PA.

This

might

be

because you

work

i n

accounting

(finance,

controlling) and

y our

tasks

therefore

involve COPA

automatically. However,

i f

you work

i n

logistics—for

e x a m p le,

i n

sales

and

d i s t r i b u t i o n ,

materials

management,

or

i n

production—you

may

also

have heard

of

COPA, even

i f only

i n

discussions

o r

meetings

with

t h e

controllers

responsible f o r COPA. Alternatively,

you

may

be

a junior or

senior consultant

i n

an

SAP

consultancy

and

receive

a

request

to

implement COPA

i n

a

company or

to

support

t h e

implementation

i n an

advisory capacity.

At

t h i s

point

at t h e

latest

t h i s

book

w i l l

h elp y o u:

I

w i l l

no t

only

explain what

CO

PA

i s ,

but, using

an

ongoing example, I w i l l also show

you

how

to

implement COPA and

how

to

work

with

i t .

However,

t h i s book

does

no t

claim

to

cover a l l

of t h e

tools

available

i n

COPA:

there

are

sufficient

specialist books

available

that

can

do

t h a t . This book

w i l l give you

t i p s and

show you

t r i c k s

f o r implementing a

simple

COPA

i n

your company, and w i l l

show

you

how

to

work with

i t

effectively after

implementation.

You

may ask what

gives

me

t h e r i g h t

to

make such a claim

f o r t h i s b o ok.

To

answer y our 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 Weiße. I also have

many

years

of

experience

as

an

inhouse consultant and



controller

at

Berentzen. These positions have enabled

me

to

ga t her a

l o t

of

experience

i n

using

COPA,

as

well

as

consultancy

expertise. I

am

currently employed as

an

i n

house consultant

at

Sartorius AG. Therefore, I have

extensive knowledge

of b o t h

sides and w i s h

to

s h a r e

my

w e al t h

of

experience.

You w i l l pr o ba bl y

be

wondering when I

am

going

to

get

to

t h e point?

Well,

I

w o n’t

keep

you

i n

suspense any longer

l e t

me

explain t h e

t e r m

COPA:

t h e

SAP system

i s

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 j u s t a f e w.

In

turn, each

of

t h e s e

modules

has i t s

own

individual submodules: f o r

example,

t h e

CO

module

includes

t h e

submodules

Overhead Cost

Controlling (COOM), which

i n

turn co vers co s t cent er

accounting

and

internal orders, or Product Cost Accounting

(COPC).

But

t h e

“supreme”

module, no t

only

i n

CO

but

acro s s

t h e

entire

SAP

s y s t e m ,

i s

COPA

r o f i t a b i l i t y

Analysis.

Why

i s i t t h e

supreme module? Because

i t

represent s t h e

end point

i n t h e

SAP s y s t e m :

i t

i s

where

a l l

t h e threads

f r o m

t h e

SAPsystem

come

together.

F o r t h e

fact

that

you

have

t h e

pleasure

of

reading t h i s book

at a l l , I am grateful

to

Espresso Tutorials

and i t s

two

managing directors, Martin Munzel

and

Jörg Siebert. I would

l i k e

to

e x p re s s

my

heartfelt

t h a nk s

to them

f o r

giving

me

t h e

opportunity

to

s h a r e

my

experience and

knowledge

i n

CO

PA with

you.

The

examples

i n t h i s

book were created

on an

SAP system

at consolut. Many t h a nk s also

to

Ms. Ulrike Pe ter s

f o r

h er

help

with t h e

successful co v e r de s ig n

of

t h i s

b o o k .

In

t h e

text

we

use boxes

to

highlight

important

information.

Each

box

also has an icon

to

identify

i t more

precisely:



Notes offer

practical

t i p s

f o r

dealing

with

t h e

respective

topic.

Examples

i l l u s t r a t e a topic more

clearly.

Warnings

draw

your

attention to

possible

sources

of error

or

stumbling

blocks

i n

connection with a topic.

Press

on

a

video

icon to

play

a

video.



2

Structures

in COPA

In

this

chapter

I

will

f i r s t l y

address

t h e

actual

purpose

o f

COPA. I will

then

explain

t h e

or g ani za ti on al

structures

and

master

data

t h a t

a r e r equir ed

f or

COPA.

The chapter

closes

w i t h

a

p r e s e n t a t i o n

o f

t h e definition

o f

an

example

operating

concern t h a t

is

t h e

basis

f o r a l l

further examples in this book.

2.1

The Intent and

Purpose

o f

COPA

In

addition

to

mapping contribution

margin

accounting

with

actual

and

planned figures,

t h e

purpose

of

COPA

i s to

answer various bu sines s questions,

f o r

example:

Which

customer

do

Iearn t h e

most money from?

Which

p ro duct s a re

t h e

key

to

my

bu sines s

success?

Which

specific

p ro duct s a re successful with which

specific customers?

Wasmy

l a s t

marketing

campaign

successful?

What

effect has

my

new

price strategy had on t h e

purchasing

be ha vi or

of

my

customers?

Should

I grant

a customer further

discounts

to

increase

t h e

sales quantity?

Are

my

contribution

margins

i n a

bu sines s area

sufficient

to

cover

t h e fixed cost s a s si g n ed t here?

What

do

I

give my

customers

i n

sales p r o m o t i o n s

and does

t h i s

lead

to

a

higher sales

quantity?

Where

do

my

deviations

to planned

figures come

from?

These are

j u s t

some

of t h e

questions

that

COPA

can



answer

rovided

you

have cus tomized

i t

correctly.

As you

w i l l

recognize

f r o m t h e

various

questions, COPA

i s

designed

as

a

sales controlling t o o l .

In

principle,

however,

i t

can

map

a l l

of

t h e

elements

of

contribution margin

accounting

down

to

earnings

b e f o re

interest

and

t ax

(EBIT).

Which COPArelevant organizational structure

i s

advantageous here?

2.2 The

Operating

Concern

In

an

SAP s y s t e m , t h e o perat ing concern

i s

t h e

organizational

unit

responsible

f o r


Analysis

(CO

PA).

What

are organizational units i n t h e SAP system? You

usually use organizational units

to

map

your company

structure:

you set

up

company

codes

f o r

y our

independent

accounting units;

you

create sales areas

i n SD;

you define

plants

etc.

f o r MM

and PP.

The

entire

remaining

customizing

of

your

SAP

system

i s

based

on

t h i s

organizational

representation

of

y our

company

structure.

The organizational structure

i s

t h e

backbone

of

y our

s y s t e m .

Common error in

practice

I f

you

do

no t

think

t hr ou g h

t h e

mapping

of t h e

organizational

structure

i n t h e SAP

system

t h oroughly f r o m

t h e

very

beginning, meaning that

you

have

to make

changes l a t e r ,

you

w i l l

have

to

check

t h e customizing

that

i s

based

on

t h i s

structure

whenever you

make changes.SAP projects often

take

longer

and

become

unnecessarily

e x p e n si v e

because

t h e

management thinks

a b ou t

changes

to

organizational structures durin g t h e SAP



implementation p h a s e . The SAP implementation

i s

l a t e r

deemed

to

have

taken v ery lo ng and been

t o o

expensive,

b ut i n

r e a l i t y ,

i t

i s

t h e management

decisions

that

have

caused

t h e extended

time

frame. Consultants,

on

t h e

o t her h and, are very

h a p p y .

In

an

operating

concern, you define

a l l

operating

concern

relevant master

data

that

you need

f o r

y our subsequent

work with COPA. You

t h e n

assign

t h e

operating

concern

to

one

o r

more controlling

areas. Here I would

recommend a

1:1

relationship

. e . ,

assign

t h e o p era t in g

concern

to

only

one controlling

area.

You

may

wonder whether

i t

makes

sense

to

define

a

1:1

relationship h e r e

when

you

w i l l want

to

evaluate data

acro s s

t h e

group

o r

company l a t e r

o n.

Your

thinking

i s

correct, b ut

t h e

clue i s

i n

t h e assignment

of

controlling areas

to

company codes: a controlling

area

i s

t h e

organizational

unit

of t h e

COmodule you can

a s si g n

one

or more

company

codes

to one

controlling

area.

To

e n a b l e

you

to

perf o rm evaluations across t h e group

o r

company

( a n d

no t

only

i n

Excel

o r

a

bu sines s warehouse,

which

would

lead

to further

costs),

you have

to

assign

a l l

of

y our

“ l i v e ” company codes

to

one controlling

area.

You t h e n

assign

t h i s

controlling

area to t h e o pera tin g

concern. This

ensures that

you

can

see

no t

only

your

cost s acro s s t h e

group, but

also

y o ur r ev e nue s ,

contribution

margins,

and

of

course, your

p r o f i t .

Anecdote/common error



A

fellow

consultant once told

me

that he

was called

to

a customer

who

had

already

gone

l i v e

with

SAP

b ut was h a ving problems

with

his

Report Writer reports.

The

customer wanted

to

evaluate

his

cost s acro s s t h e

group,

but t he

reports

did

no t allow him to do

t h i s .

Unfortunately

my

colleague

could

no t help

him:

t h e

customer

had s et up

one

controlling

area

f o r

each company code, meaning that

he

could only

see t h e cost s

of

t h i s

company

code

i n

t h e

Report

Writer reports

f o r t h i s

controlling

area.

This

example shows how important

i t

i s

to

think

a b ou t

y our organizational structure i n t h e

SAPsystem

t h oroughly

i n

advance.

However,

to

work with only

one

operating

concern,

a l l

controlling

areas

and

company

codes must

work

with

t h e

same

f i s c a l

year

variant,

generally

K4

(here,

t h e

f i s c a l year

corre sp o nd s to

a calendar year with four

special periods).

A l l

company

codes

must also use

t h e

same chart

of

accounts.

In t h e next section I

w i l l

explain

t h e

master

data i n

COPA.

2.3

Master

Data

in

COPA

There are

two

f o r m s

of

P r o f i t a b i l i t y Analysis: costingbased

and accountbased

P r o f i t a b i l i t y Analysis.

The costingbased

f o r m works with

value

f i e l d s

and

t h e accountbased

f o r m

works with accounts.

As

t h e

name

indicates,

a

value

f i e l d i s

a

f i e l d

i n which

v alues are entered.

F o r example, f o r each l i n e

of

contribution margin accounting (unless

t h e l i n e

can

be

calculated

as a formula), you define a

value

f i e l d . This

f i e l d

i s t h e n

f i l l e d

with

data

“automatically,” regardless

of whether



you

are

compiling actual

or

planned

figures.

In

t h e

same

way, quantity f i e l d s ,

as

t h e name indicates,

are f i l l e d

with

quantities,

e . g . ,

sales quantities.

Mapping contribution

margin

accounting

i s

part

of

management

accounting.

In

contrast

to

financial

accounting,

there

are

no

legal

requirements

as to

t h e p res en ta tio n

of

contribution margin accounting

each

company maps i t s

structure

i n

accordance

with i t s own

needs. This

individuality

i n

mapping contribution margin accounting

i s

(naturally) possible

i n

o ur supreme module COPA.

In accountbased P r o f i t a b i l i t y

Analysis, you

would define

y our

contribution

margin

structure

using

accounts

that

you

also create

as

cost elements.

Both

f o r m s of

P r o f i t a b i l i t y Analysis work with characteristics.

But

what i s a characteristic?

You

use

characteristics

to

enter selections f o r

your


Analysis

dataset. SAP

has a number

of predefined

characteristics, such

as

company

code,

sales

organization,

distribution

channel,

customer,

o r

product,

to

name

j u s t

a

f e w.

You

can also

define

characteristics

that

are

important

f o r control

i n

y our

company yourself.

F o r

e x a m p le,

i f

you

want

to

look

at

t h e

data

of

customer

XY i n

a period

to see

whether

he

purchased products

f r o m product group

4711,

you

can

use

t h e

characteristics

to

select y o ur dat a and present

i t i n

reports.

You

w i l l

see

no t only

t h e

sales

quantity

and

t h e

sales, b ut

also

a l l

cost s that

you can

directly

a s si g n

to t h i s

customer and

t h e

related products, product

groups

etc.

We

w i l l look

at

t h i s

more

closely l a t e r

on

i n t h e

b o o k .

2.4 CostingBased

o r

AccountBased Profitability

Analysis?

There are companies that use

b o t h f o r m s

of


Analysis, b ut

on

a longterm

basis,

t h e y

often

decide

to

use

only costingbased P r o f i t a b i l i t y Analysis:

i t

certainly

meets

t h e

requirements

s u f f i c i e n t l y .

In

contrast,

t h e

accountbased



f o r m a t tem p t s

to

build

a bridge

to t h e

operating p r o f i t

of

t h e

p r o f i t

and

loss s t a t emen t ( P&L),

and

i s

therefore a t y p e

of

additional

control

instrument.

Do

you really

have

to

subject

yourself

to t h e

additional

onetime

and

subsequent ongoing

e f f o r t involved

i n

setting

up

accountbased P r o f i t a b i l i t y

Analysis?

Just

to

confirm

t h e operating

p r o f i t

of

t h e

P&L?

In

my

opinion,

you do

no t have

to do t h i s

articularly i f

you

also

use

P r o f i t

Cen ter Accounting, which p er f o r m s t h i s

control function anyway.

In every company there

are

busines s transactions that have

to

be

p o s t e d

automatically

i n

F I .

Normally, you

w i l l have

defined

t h e

related

controllingrelevant

account

assignment

via

t h e

account determination, substitution,

o r

validation

automatically

so

that

there

i s

no

interruption

to

automatic

runs. COPA takes

p r i o r i t y o v e r a l l

o t her

controllingrelevant

account a s s i g n m e n t s :

i t i s real

t h e o t her account

assignments are only

s t a t i s t i c a l .

Automated account

assignment

of

a

p r o f i t a b i l i t y

segment

( as t h e

controlling

relevant

account

assignment

to


Analysis

i s

known)

could

take

place

at

b e s t

at

a high, a g g re g a t ed l e v e l .

But

which

additional information

do you

have

i n

account

based


Analysis that

you

do no t

already have

i n

P r o f i t Cen ter Acco un tin g? I f you use accountbased

P r o f i t a b i l i t y Analysis,

you

also need large

volumes of

memory

storage.

Believe me,

y our

SAP Basis support

colleagues

w i l l

no t

be

your

b e s t

friends,

and

at

t h e

latest

when you

have to

archive your

data,

you

w i l l

be

t h e

one

with

t h e

greatest

s t o r a ge requirement of

a l l ( I

speak f r o m

experience). When defining

t h e

operating concern therefore,

use t h e

costingbased

f o r m and create

t h e

value

f i e l d s

and

characteristics

that

you

need

i n

your

COPA. Here too,

you

s h ould think t h oroughly b e f o r e h a n d a b o u t which

characteristics and

value

f i e l d s

you

need. Changing a

l i v e

operating

concern

l a t e r

on

i s

no t e a s y .

In

my

previous

work,

I have

only

done t h i s f o r release upgrades

o r

o t her SAP

new

s t a r t s .

I f

you change or e x t e nd t h e o p er at in g concern

i n

a

l i v e

s y s t e m ,

you

run

t h e

r i s k

of

h a ving

to

import

y our



previous data

backup and t h e entire day’s

work

of

your

SAP

colleagues h a ving

to be

repeated.

In t h e further course

of t h i s

b o ok, I r e s t r i c t

m y s el f

to t h e

description and setup

of

t h e costingbased

f o r m

of


Analysis.

2.5 S e t ti n g

Upan

Example Operating

Concern

Nowwe w i l l

s et

up

COPA

f o r

a company that manufactures

products

that are

i n i t i a l l y s t ored b ef o re t h ey are s old

to

customers (maketostock (MTS)

process).

2.5.1

De scription

o f

t h e

Main Example

Data

F o r t h e MTS

process,

most customers

b e l o n g

to

trading

groups; there are also small and

large

customers who

do

no t necessarily b e l o n g

to

large customer constellations.

Which

characteristics that

you

can use

l a t e r

f o r

data

selection

can

we

define

f r o m

t h i s

small

amount of

information?

On

one

h and, SAP provides default fixed characteristics,

such as

t h e

controlling area, company

code,

e t c . ; I have

l i s t e d

t h e

most important

of

t h e s e

i n

Ta ble 2.1. They

also

appear

i n

o ur

example.

Fixed characteristic Value(s)

i n

t h e

example

Controlling area ET01 (E. T.

Company)

Company

code

ET11 (E. T. Company)

S a l e s organization ET15 (E. T.

Company)

Distribution

ch a n n e l

MTS

p r oce s s

01

Division

00

Plant ET11 (E. T.

Company)



As already

stated,

when

you

create

an

operating

concern,

t h e system genera t es t h e fixed

characteristics

automatically,

meaning

that

you

do

no t

have

to do

anything

f o r

t h e s e when

you

define t h e o p era t in g

concern. However, you

do

have to

maintain t h e us e rde f in ed characteristics that

you

want

to

see,

and

t h e

value

f i e l d s that you want

to

define.

F i r s t

you

have

to

define your operating concern.

Na viga t e

to

customizing

via

TOOLS

• CUSTOMIZING •

IMG

•

EXECUTE

PROJECT. Press

to

navigate

to

t h e

I mplemen t a ti o n

Guide.

Transaction codes

Instead

of

following

t h e

menu

path, you can

enter

transaction

code

SPRO. Whenever

you

enter

a transaction, always place

/ N i n

front

of t h e code

i t s e l f

h e

transaction

t h e n

appears

on

a

new

screen. Therefore,

to

access

customizing, enter /NSPRO.

Via

t h e

pa t h CONTROLLING •

PROFITABILITY

ANALYSIS •

STRUCTURES •

DEFINE

OPERATING

CONCERN

•

MAINTAIN

OPERATING CONCERN,

give

y our

operating concern a name:

i n o ur

example,

t h i s

i s

Z111.

Once you

have

added

t h e

name,

place

a checkmark next

to

t h e

f o r m

that t h e

operating

concern s h o u ld take:

i n o ur

example, we are only looking at

t h e costingbased

for m.

Save y our entries.

Press

to

display t h e

CHARACTERISTICS

(CHARS)

tab. Using t h e button, f r o m

t h e

default characteristics,

transfer t h o s e

characteristics

that you want

to

use

( s e e

Figure 2.1).



©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

2.1:

Userdefined

characteristics

for operating concern

Z111

Proceed

i n

t h e same way

on

t h e

VALUE

FIELDS t ab

to

a s si g n

t h e value

f i e l d s

required

( s e e

Figure 2.2).



©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

2.2:

Value fields for

opera ting

concern

Z111

I f

t h e

te m pla te tables

do

n o t co nt a in a l l

of

t h e

characteristics

or value

f i e l d s

that

you want

to

use,

you

have

to

define and

activate t h o s e that

you want

be f ore hand.

To define and

activate t h e characteristics,

return

to

customizing

via

t h e

I mplemen t a ti o n Guide

and

choose

CONTROLLING

•

PROFITABILITY

ANALYSIS

•

STRUCTURES

•

DEFINE

OPERATING

CONCERN

• MAINTAIN CHARACTERISTICS.

Give y our

new

characteristic a

name.

New characteristics

always

begin with

“WW ;

new

value

f i e l d s begin with

“VV.”

The new characteristics and value

f i e l d s

must have f i v e

characters.

F o r o ur example,

i n

Figure

2.3

l e t us look

at

characteristic WWPGR, which

we

want

to

use

l a t e r to

p res en t p ro duct g ro up s.

By

pressing CREATE/CHANGE,

we

navigate

to

maintenancemode f o r t h e characteristic.



©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

2.3: I n i t i a l

screen

for

maintaining

characteristics

When creating

characteristics,

you

have to

decide

whether

you

want

to

create

an

existing f i e l d f r o m

an SAP

table

as

a

characteristic,

o r

alternatively, whether

you

want

to

define a

completely new

characteristic with separa t e

value

m ain ten ance.

I f

you

decide f o r t h e l a t t e r

( as

i n

o ur exa mple),

you also have

to

specify

t h e

description

of

t h e characteristic.

Once

you

have

done

t h i s ,

save and

activate

your

new

characteristic.

The

system

automatically creates

a

check

table

f o r

your

new characteristic. Figure 2.4 shows t h e

results

of

your w ork.



©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

2.4: The

result of

characteristics maintenance

The

procedure

f o r

defining

value

f i e l d s

i s

t h e

same

as

that

f o r characteristics. New value

f i e l d s

always begin with “VV.”

When you define a value

f i e l d ,

you have

to

decide whether

i t

w i l l

l a t e r

be

used

to

represent

a

quantity

o r

an

amount.

Once

you

have

defined

new

characteristics

and

value f i e l d s ,

you can

use them

when

you maintain y our

operating

concern o

do

t h i s , a s si g n

them

to t h e o p era t in g

concern,

as

explained

a b o v e .

Now save

y our

operating

concern.

The

system

creates

new

structure tables that contain

t h e

data

of t h e

operating

concern,

f o r

example, t h e structure

CE1Z111.

Now

pres s

h e

system executes a mass activation.

I f

you pres s

“Ba ck” ( g r ee n arr o w pointing l e f t ) ,

t h e

question shown

i n

Figure

2.5

a ppears.



©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

2.5:

Generating

t h e environment

Con firm

with YES.

The

system g enera te s c l i e n t

independent

and

clientspecific objects and

t h e

following

message

a ppears:

THE

ENVIRONMENT

WAS

GENERATED

SUCCESSFULLY.

Make

sure

that

you

also

maintain

t h e

at trib ut es o f t h e

operating

concern. F o r

o ur

example,

we

are

using

t h e

operating concern

currency

EUR and f i s c a l

year

variant

K4

( 12 periods plus

four

special periods).

Once

you have

completed

t h e

maintenance

of

t h e

operating

concern,

a l l

of

t h e t r a f f i c

l i g h t s

visible s h o u ld

be

green ( o n

t h e ENVIRONMENT t ab

as

well) see

Figure

2.6

and

Figure 2.7.



©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

2.6: O pera ti ng

concern

green l i g h t



©

Copyrigh t

SAPAG.

A l l

rights

reserved.

Figure

2.7:

Green

lig ht s f or

t h e

opera ting

concern

environment

Assigning

t h e

operating concern

The operating concern

i s

an organizational unit

i n t h e

SAP

s y s t e m . Therefore,

i t

must

be embedded

i n

t h e

organizational

structures

of

t h e SAP s y s t e m .

F o r

o ur

simple

e x a m p le,

we

w i l l

use

one

company

code ET11,

one

controlling

area

ET01, and

t h e

operating concern we have

j u s t maintained, Z111.

In

t h e

I m p le m e nt a t io n Guide,

under

ENTERPRISE STRUCTURE • ASSIGNMENT •

CONTROLLING,

f i r s t

assign t h e company

code

to

t h e controlling

area.

Then

assign

t h e

controlling

area

to t h e

operating

concern

( s e e

also Figure 2.8 and Figure 2.9).



©

Copyrigh t

SAPAG.

A l l

rights

reserved.

Figure

2.8:

Path for

assigning

t h e

controlling

area

to

t h e

opera ting

concern

©

Copyrigh t

SAPAG.

A l l

rights

reserved.



Figure

2.9:

Assignment of

Z111 t o ET01

By

assigning t h e o pera tin g concern to t h e

controlling

area,

you

make

t h e o pera tin g concern active. You can

also

see

t h i s

assignment under t h e p a t h

shown

i n

Figure 2.10.

©

Copyrigh t

SAPAG.

A l l

rights

reserved.

Figure

2.10: Path

in

t h e

Implementation Guide

for

activating t h e

opera ting

concern



When

you execute

t h e

s t e p

ACTIVATE

PROFITABILITY

ANALYSIS, t h e system

takes

you

to

an extended screen

f o r

assigning

t h e o p era t in g concern

to

t h e

controlling

area

( s e e

Figure 2.11).

©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

2.11: P r o f i t a b i l i t y

Analysis

active

flag

The

ACTIVE STATUS

“2”

means

that costingbased


Analysis

i s

active; “4”

would

mean

that

b o t h

costingbased and accountbased

P r o f i t a b i l i t y Analysis

are

activated.

I f t h e

ACTIVE STATUS

column i s blank,

t h e

operating concern

i s no t

active.

See

also Figure 2.12.

©

Copyrigh t

SAPAG.

A l l

rights

reserved.



Figure

2.12:


Analysis

active

flag

In

t h e

video b e l o w ,

you can see a demo n s t ra tio n

of

how

to

create

your

own characteristics and value f i e l d s , and how to

s et up

an

operating concern

with

t h e m .

Video 1:

Creating

an

Operating Concern

Note:

Should

y our

reading device

no t be

able

to

show

t h i s

video,

you

can use

y our

computer

to

watch

i t on

t h e

internet.

To do

t h i s ,

head

to

o ur

web

page

at

http://video1.copaen.espressotutorials.com.

In Chapter 2, I have given

you some information a b ou t

t h e

structures

and

master

data

i n

COPA.

In t h e

following

chapters,

we

w i l l continue

to

f i l l

t h e o pera tin g concern that

we have

created.

I

w i l l

show

you

how

to

derive defined

characteristics (Chap ter 3 ) , how

to

valuate y our

value

f i e l d s

(C h a p t er

4 ) , how to f i l l

your

value

f i e l d s

with

actual

(C h a p t er

5)

o r

planned

(C h a p t er

6)

figures,

and

f i n a l l y ,

how

you can

present t h e

results

of

your

efforts

(C h a p t er

7 ) .



3 Characteristic

D e ri v a ti o n s

In

this

chapter

we

will

look

at

how

t o

f i l l

and

derive

characteristics.

I will explain

what characteristic

derivations

are,

and

then show

you

five

possible

forms

o f

characteristic derivation

f o r our ongoing example.

3.1 What Are Characteristic D e ri v a ti o n s ?

I f

you

ask

yourself

what

t h e

deepest

level

i s

at

which

i t

makes sense

to

evaluate

cost s

and

revenues

i n

COPA, you

w i l l arrive

at t h e

answer that

t h e

deepest level

i s

achieved

with

t h e

combination

customer/product.

What

does t h i s

mean? Let us look

at an

example:

you

s e l l

y our

product A1

to t h e corner store, customer K1. You can

t h e n

create,

f o r

e x a m p le,

an

analysis

or

contribution margin

accounting

f o r

product

A1

at

customer

K1.

I f

you

want

to

see

t h e

data

at

a

somewhat higher

l e v e l ,

you could, f o r example, report

on

customer group KG1,

to

which customer

K1

belongs. But

how does

t h e

data

get to

customer

group KG1?

A l l you

have done,

f o r

example, i s issue

an

invoice

to

customer

K1,

who

purchased product A1. The answer

i s

characteristic

derivations. When t h e po s t ing was

entered,

t h e

system

derived

customer group

KG1

f r o m

t h e

customer

master

record

of

customer K1

and

f i l l e d

i t

as

an

additional

characteristic.

I f

f o r example,

you

now c a l l

up a report

using

t h e selection customer group KG1,

you

w i l l

see

t h e

a n al o g

data of customer K1. Reporting

at

higher aggregated levels

i s

obviously interesting

when numerous

individual

documents have

been

p o s t e d

to

COPA and

you want

to

evaluate

t h e s e

at

a

higher

l e v e l .

Characteristic derivations

are p e r f o r m e d f o r a l l COPArelevant transactions.

3.2

Methods

o f

Characteristic D eriva tio n



Depending

on t h e


you

have decided

to

use

i n t h e

future, COPA allows different methods

of

deriving t h e s e

characteristics

o r ,

more

precisely,

of

also

specifying

t h e

values

f o r t h e characteristics when

you p o s t

documents.

The

following methods

are

available:

Assignment

Ta ble

lookup

SAP

enhancement

I n i t i a l i z a t i o n

Derivation

rule

I

w i l l

explain

t h e

meaning

of

t h e s e methods

i n

t h e

next

section using o ur example data.

You

can

also p r oce s s

t h e

defined

characteristic

derivations

stepbystep

i n

a logical sequence

i n

a characteristic

derivation strategy.

What i s a characteristic derivation strategy?

F o r

characteristic derivation, COPA

e n a b l e s

you

to

execute

a l l

derivation s t e p s

i n

a

logical sequence.

You

create

a

characteristic derivation strategy

i n

customizing. The

p a t h

i s

as follows: CONTROLLING

•

PROFITABILITY

ANALYSIS

•

MASTER DATA •

DEFINE

CHARACTERISTIC DERIVATION.

The

table that appears

i s

i n i t i a l l y

e m p t y ,

as

t h e system does

no t

know yet

what

you

want

to

derive.

Stepbystep

you can

define

t h e

logical sequence that

t h e SAP

system

i s to

follow

to derive t h e characteristics. F o r example, you can define

dependencies

i n

y our

strategy,

such

as:

f i r s t derive

characteristic XY; t h e n

derive

characteristic

YZ based

on

characteristic

XY. Figure

3.1

shows

an

example

of

a

characteristic derivation strategy table.



©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

3.1: Example

of

a characteristic derivation

strategy

The characteristic derivation strategy

i s

a mandatory

prerequisite

f o r


i n

COPA.

The

derivation does no t

work without

t h i s strategy.

In

case characteristic derivation

s t e p s

are to be

b rough t

f o r w a rd

at

any

point,

i n

o ur example

we

s t a r t with

s t e p

16.

3.3 Characteristic

Deriv a tion s

f o r

Our

Example

In

t h e

following

table,

f o r

o ur

example data

we

have

described which

characteristics

are

to

be

derived

and

with

which

characteristic

values.

Via

t h e

customer

master

record,

we want

to

derive

three

customer hierarchy characteristics

as

well

as

t h e

customer

group

and

t h e

sales

employee

of

t h e

customer,

as

shown

i n

Table 3.1.

Customer

Cust.

ier.evel

1 Cust.ier.

evel

2 Cust.ier.

evel

3 Cust.

p

Sales

employee

K1

KH11

KH21

K1

KG1 50995

K2 KH12 KH23

K2

KG1 50995

K3 KH11

KH22

K3

KG2 81000



K4

KH12

KH23

K4

KG2 50995

K5 KH11 KH21

K5

KG3 81000

K6

KH11 KH21

K6

KG3

50995

Table

3.1: Characteristic

assignments for customers

3.3.1

Assignment

F i r s t l y ,

we

derive

t h e

customer hierarchy

f o r

t h e three

characteristics

Customer

hierarchy

1, 2,

and

3

f r o m

t h e

customer master record

via

assignment

f

you

use

t h e

SAP ERP

module

SD

( Sales

and

Distribution),

you

can

create

t h e s e

customer

hierarchies i n SD.

Excursus:

How

do

you maintain a

customer hierarchy

i n

SD? You

can

arra nge

your

customers hierarchically using

customer hierarchies. In accordance with

o ur

example

a b o v e ,

o ur

customer

K1

i s

reflected

at

customer

hierarchy

level

3.

The customer

b e l o n g s

to

customer hierarchy KH21

at level 2, and

i n

turn

to

customer hierarchy KH11

at

level

1.

You

can

maintain customer hierarchies

via

LOGISTICS •

SALES

AND

DI STRIBUTION • MASTER

DATA

•

BUSINESS

PARTNER • CUSTOMER HIERARCHY • E D I T

o r

using

transaction

VDH1N.

The

selection screen

i s

shown

i n

Figure

3.2.



©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

3.2: Editing customer hierarchies

In

o ur

example

we

maintain

t h e

customer

hierarchy

f o r

t y p e

A

( y o u can

define

different t y p e s

f o r

standard

hierarchies,

t y p e A

i s

t h e SAP standard) and define a v a l i d i t y

date

f o r

which we

want

to edit

t h e

customer hierarchy.

F o r

example,

we

maintain

t h e

hierarchy

f o r customer

K1.

Hierarchy

nodes

You

must f i r s t

create a l l nodes

that you

want

to

r e f l e c t

as

hierarchy nodes

via K1

as

customer

masters

i n

t h e sales

area

beforehand

( i n

t h e

current

example,KH11

and

KH21).



of

t h e customer ma s t e r.

To

define

a

derivation

s t e p i n


m ain ten ance,

create a

new

s t e p

and

t h e n

select

DERIVATION

RULES. In

d e t a i l ,

t h e

strategy

s t e p

appears

as

shown

i n

Figure

3.5.

©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

3.5: Detail derivation

s t e p of

a customer hierarchy

The definition contains source f i e l d s and target

f i e l d s .

The

source

has

to be

defined

i n t h i s

way

because

we

want

to

derive

t h e

hierarchy f r o m t h e customer master.

In SD,

a

customer

i s

always

created

f o r a sales

area.

The sales

area

always consists

of t h e

three

f i e l d s SALES ORGANIZATION,

DI STRIBUTION CHANNEL,

and

DIVISION. Therefore t h e s e



f i e l d s are also

i n t h e s o ur ce .

The correct

hierarchy

level of

a

customer

i s

transferred

to

t h e GENERAL DATA

of t h e

customer master via t h e

HIERARCHY ASSIGNMENT

f i e l d

( s e e

Figure 3.6).

©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

3.6:

Hierarchy

assignment f i e l d

in

t h e customer

master

Each

customer

hierarchy

i s

therefore

created

as

a

normal

customer master.

I t i s t h e

additional maintenance

to

customer hierarchy

t y p e

A i n t h e

SD

customer hierarchy

and t h e f i l l i n g

of

t h e

HIERARCHY ASSIGNMENT

f i e l d

that

distinguishes

t h i s customer master

as

a

customer hierarchy.

Since

we

only want

to

work with

three customer

hierarchy

levels

i n o ur

example,

o ur

original customer masters

K1 to

K6 also represent

t h e

l o w e s t

customer hierarchy

level

here.

In

t h e

customer m as t er, t h ey

receive

hierarchy assignment

number

3.

Customer KH11 was

also

created

as

a

customer

master

and

also

receives

1

i n

t h e

HIERARCHY

ASSIGNMENT

f i e l d ,

and

so

o n.

To check that

t h e

configuration

i s

correct, simulate a

bu sines s

transaction

using

transaction KE21.

You

can

use

t h i s transaction

to

create a

l i n e item

i n

COPA m anuall y



to

do

t h i s , as

a

f i r s t

s t e p

enter

t h e

master

data

f r o m which

t h e derivation s h ould take place, f o r example, customer,

sales

organization, etc.

( s e e

Figure 3.7).

©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

3.7:

Billing

document

header

data

of

t h e

simulation

document

Then

p r es s D E RI VAT IO N :

you

w i l l

see

that

f o r

customer K1,

including Logistics data,

you can

derive

t h e

customer

hierarchy

to

a l l

three levels,

as

prescribed

i n

Section

3.3

( s e e

Figure 3.8).

©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

3.8: Evidence

of

t h e derivation

of t h e SD

customer hierarchy

in

CO

PA

Once t h e derivation

s t e p i s

co mplet e, o ur characteristic

derivation

strategy

looks

as

shown

i n

Figure

3.9. In

case


s t e p s

are

to be

b rough t

f o r w a rd at

any point,

i n o ur

example

we

s t a r t

with

s t e p

16.



©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

3.9: Derivation

s t e p for

deriving

t h e

customer hierarchy

3.3.2

Table

Lookup

As

an

example

f o r

table

lookup, l e t us

select

characteristics

that

can

be

derived

f r o m

t h e

p ro duct m a s t e r.

The

basic

data

vie w

of

a p ro duct m a s t e r, which you create

i n t h e

SAP

ERP

module

MM,

contains

t h e PRODUCT

HIERARCHY

f i e l d

(the

technical name

of

t h i s

f i e l d i s

MARAPRDHA).

This

f i e l d

can

contain

up to 18

characters.

As per

Section 2.5.1, we want

to

derive

two

characteristics

f r o m

t h e

p ro duct m a s t er:

kind

of product and p ro duct g ro up . According

to

t h e i r

d e f i n i t i o n ,

b o t h

characteristics s h o u ld have three

characters each. F o r

e x a m p le,

t h e

PRODUCT

HIERARCHY f i e l d

of

product A1

contains

t h e

combination PA1PG2.

Within

t h e

framework

of

table lookup,

t h e

f i r s t three

characters

of

t h e

PRODUCT

HIERARCHY

table

f i e l d

are

a s si g n ed

to

t h e

target

characteristic

kind of

product,

and

t h e

l a s t

three

characters

to

t h e

target

characteristic p r o duct g ro up . Thus, product

A1

b e l o n g s

to kind of

product

PA1

and product group PG2.

P ro vided

t h e PRODUCT

HIERARCHY

f i e l d f o r product master

A1

i s no t

changed,

f o r

each p os ting

f o r

product

A1,

t h e s e

characteristics

are

also

derived

and are

available,

f o r

e x a m p le, f o r evaluations.

I f

t h e

f i e l d i s

changed, t h e COPA

characteristics

a re p ro v ided

with new

characteristic values

f r o m

t h e

date

of

t h e

change.

I

w i l l now

show

you

t h e

required

s t e p s

i n

customizing.

We

w i l l

proceed

f r o m

t h e starting position shown

i n

Ta ble

3.2.

Product Kind

o f

product Product

group

A1

PA1

PG2

A2 PA2 PG1

A3 PA2

PG3

A4

PA1

PG3



A5 PA1 PG2

A6 PA2

PG1

Table

3.2:

Example

for

a product

hierarchy

In

t h e

basic

data

vie w

of

products

1

to

6,

t h e

PRODUCT

HIERARCHY

f i e l d was f i l l e d

by

your

master

data

team

o r

e x a m p le,

f o r

product A1,

with

t h e value

PA1PG20000 ( s e e

Figure 3.10).

©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

3.10:

Product hierarchy

in

material

master

Using t h e characteristic

derivation

strategy described

i n

Section 3.3.1,

we

now

want

to

read,

f o r

e x a m p le,

t h e

PRODUCT HIERARCHY

f i e l d

f o r product

A1

with i t s

value

PA1PG20000

such

that t h e

f i r s t

three

characters

are

read

f o r

t h e

characteristic kind

of

product ( i . e . ,

PA1),

and f o r

t h e

characteristic

p ro duct g ro up ,

t h e

characters 46,

i . e . ,

PG2.

Since

t h e

PRODUCT

HIERARCHY

f i e l d

can

be

up to

18

characters long,

b ut

we

only need

t h e f i r s t

six

characters

i n

o ur

e x a m p le,

t h e

remaining characters

i n t h e example

are

f i l l e d with “ 0 .

We

w i l l

now define

a

further

derivation s t e p

i n

t h e COPA



customizing:

i n

t h e e x a m p le,

s t e p 17 ( s e e

Figure

3.11).

©

Copyrigh t

SAP

AG.

A l l

rights

reserved.

Figure

3.11:

Product hierarchy derivation

s t e p

We

can

use

t h e

magnifying gla ss

to

look

at t h e

detail

of t h i s

derivation

s t e p

( s e e

Figure

3.12).

Here

t o o

you

must define

a s ource and a

target.

We

can find

t h e

source

i n t h e

basic

data

view of

t h e

material

master. The

relevant

SAP

table

i s

MARA.

The

COPA

characteristic

product

(ARTNR)

corre sp o nd s

to

t h e material number

of

t h e material master

.

In t h e

target,

we

a s sig n o ur userdefined

characteristics

WWPAR

andWWPGR

to t h e

PRODUCT

HIERARCHY

f i e l d

of t h e material master (MARAPRDHA)

and

state that

characteristic WWPAR

i s

to be

read

f r o m

t h e

f i r s t three

characters

of

t h e

f i e l d

MARA-PRDHA and characteristic

WWPGR

f r o m

characters

four

to

six

(+3(3))

.



©

Copyrigh t

SAPAG.

A l l

rights

reserved.

Figure

3.12:

Detail derivation

s t e p

of

a product hierarchy

Therefore,

f o r

product

A1,

COPA

reads

PA1

f o r

t h e

characteristic

kind

of

product and PG2

f o r

t h e

characteristic

product group. But

what

do PA1

and PG2 mean? When we

created operating concern Z111,

we

defined

t h e s e two

characteristics

freely and with

no

template table. Therefore,

we have

to make

t h e

corresponding characteristic values

known

to

COPA.

We

do

t h i s via transaction KES1

o r

via t h e

p a t h

i n

t h e

application

menu:

ACCOUNTING

•

CONTROLLING

•

PROFITABILITY

ANALYSIS • MASTER DATA • CHARACTERISTIC

VALUES • CHANGE CHARACTERISTIC VALUES

( s e e

Figure

3.13).



©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

3.13: Maintenance of characteristic

values

By doubleclicking

t h e

respective

characteristics, you can

maintain

t h e

values

f o r that

characteristic ( s e e

Figure

3.14

and Figure 3.15).

©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

3.14:

Characteristic

values

of

t h e

characteristic

kind

of

product

©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

3.15:

Characteristic

values

of t h e

characteristic product group




3.3.3

SAP

Enhancement

In

a l m o s t

every SAP module you can maintain

user

e x i t s .

Here,

SAP

offers

t h e

option

of

finding

exits

i n

t h e standard

SAP

s o f t w a r e

xits

i n

which

a user can

i n s t a l l his own

programming using

t h e

ABAP programming language

without

changing

t h e

SAP

s t a ndard s o f t w a r e

and

potentially

endangering

t h e SAP

warranty.

Of

course,

t h i s

t y p e

of

user

e x i t

i s

also available i n COPA. There

i s

a user

e x i t

f o r

characteristic

derivations t h a t ,

with

t h e

normal

standard


methods,

do

no t

achieve

t h e

objective.

In o ur

e x a m p le, I had i n i t i a l l y

decided

no t

to

describe a user e x i t f o r characteristic derivation

did

no t

want

to

co n fu s e

any

COPA

beginners

o r

cause them

to

s t o p

reading at t h i s point.

I f

t h e information

i s

t o o technical

f o r you, you

can skip

t h i s

chapter; however,

i t may show

some

new

op tion s

f o r

any

interested

users.

I

may also

excite

your

imagination...

As stated,

we

w i l l also convert

t h e

sales quantities

into

alternative

quantities

to

e n a b l e

comparison

of

t h e individual

products.

The

alternative quantity requires a quantity unit

that i s no t

f i l l e d

automatically. F o r

o ur

example

we

assume

that each product

can be

compared

with

o t her

products

by

means

of

t h e

weight.

Therefore,

we

choose

KG

(kilogram)

as t h e

alternative

quantity u n i t .

Now

we

have

to

give

each

sales product a conversion factor

f o r

translating

t h e

base

quantity

unit

into

t h e

alternative

quantity.

We

do

t h i s

i n

t h e

SAP

module

MMi n

t h e

additional

specifications

f o r

a product. Via transaction

MM02,

go to t h e

BASIC DATA 1

view of

t h e product and

f r o m

there

to t h e

additional

data.

Here,

choose

t h e

UNITS

OF

MEASURE

tab;

t h e screen shown

i n

Figure

3.18

appears.



©

Copyrigh t

SAPAG.

A l l

rights

reserved.

Figure

3.18:

Alternative

quantity

units

for

a product

Product

A1

weighs

100 KG per

item.

F o r

o ur

user

e x i t , t h i s

means that

t h e

alternative quantity

unit

KGmust

be

derived.

A COPA user

e x i t

i s

available i n

t h e

customizing f o r

CO

PA,

under

TOOLS

• SAP ENHANCEMENTS. Create

a

project

and a s si g n component COPA0001.

By

doubleclicking t h e

component, navigate

to t h e

Include ZXKKEU11.

I f you

have

a developer key

i n y our

s y s t e m ,

you

can

f i l l t h i s

Include.

F i r s t

maintain

t h e

header

of t h e

user

e x i t

a n al o g

to

Figure

3.19.

©

Copyrigh t

SAPAG.

A l l

rights

reserved.

Figure

3.19:

User

exit

header

for

characteristic

derivation



Then

insert t h e

l i n e

CASE I_OPERATING_CONCERN.oll o w

t h i s

with

t h e

coding shown

i n

Figure 3.20.

©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

3.20:

User

exit

coding for

deriving t h e

quantity

unit

To ensure that

t h e

user

e x i t f o r deriving t h e quantity unit

KG

i s

als o

f ou nd

i n

your

operating

concern, you

have

to

make

t h e

user

e x i t known

i n

your characteristic

derivation

strategy

i n

s t e p 19 ( s e e

Figure 3.21).



©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

3.21: Enhancement of

t h e

characteristic derivation strategy for

t h e

user exit

By

doubleclicking l i n e

19

you

navigate

to t h e

detail screen

f o r t h i s

derivation

s t e p

( s e e

Figure

3.22).

©

Copyrigh t

SAPAG.

A l l

rights

reserved.

Figure

3.22:

Derivation of user exit

I

We are

accessing

t h e quantity units

of t h e

product master

and therefore t h i s

master must

be

named

i n

t h e source.

The

objective

of

t h e

derivation

s t e p

and of

course

t h e

user

e x i t

i s

to

give t h e

quantity f i e l d VVAMG that

we

have defined

a

quantity

u n i t .

In t h e co din g, we specified

t h e

derivation

s t e p “AMG”

( s e e

t h e coding

i n

Figure

3.20

“CASE I_STE P_I D ) .

We



specify t h i s

s t e p

on t h e

ATTRIBUTES

t ab

( s e e

Figure

3.23).

©

Copyrigh t

SAPAG.

A l l

rights

reserved.

Figure

3.23:

Derivation

of t h e user exit

attributes

Check whether

t h e

derivation

works (using KE21, f o r

exa mple) . The

aim i s

f o r t h e quantity unit

to

be derived

f o r

t h e

ALTERNATIVE

QUANTITY

UNIT

f i e l d .

You

can

see

t h e

evidence

i n

Figure

3.24.

©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

3.24: Evidence

of t h e correct

derivation

of t h e


unit

via

t h e

user

exit

3.3.4 Initialization



I f you

want to

use

auxiliary characteristics

o r

f i e l d s

to

derive

characteristics,

you can

delete t h e s e characteristic values

again b e f o r e a further characteristic derivation

by

means

of

i n i t i a l i z a t i o n .

When

are

auxiliary

f i e l d s

useful?

I f

f o r

example,

you

want

to

derive

a

specific characteristic f r o m

an

SAP

f i e l d ,

b ut t h i s

characteristic

i s to

have

different characteristic values

to

t h e

SAP

f i e l d , you

can use

auxiliary f i e l d s . Usually, t h e s e are

global

variables, f o r example, USERTEMP1.

In t h e

f i r s t

step,

you

create a

derivation

f r o m

t h e SAP f i e l d

to

t h e

auxiliary

variable

USERTEMP1.

In

a second step,

you

create

a

derivation

f r o m

your

auxiliary

f i e l d

USERTEMP1

to

t h e

characteristic

that

i s to

be

f i l l e d .

Now

you can add a t h i r d

derivation

s t e p

that i n i t i a l i z e s your auxiliary

f i e l d

USERTEMP1

so that

i t

i s empty

again

f o r t h e

next


and can accept

new

characteristic

values. F o r o ur

example, however,

we

w i l l no t create a

special i n i t i a l i z a t i o n .

3.3.5 D erivation

Rule

In

practice, derivation rules

are

often used

to

derive

a

characteristic f r o m a characteristic value of a n o t h e r

characteristic.

Th is t y pe

of

derivation

i s

often applied, f o r

e x a m p le, to

derive a

higher level characteristic,

such

as

t h e

continent

( e . g . , Europe)

f r o m

t h e

characteristic

value

(here

Germany)

of

t h e country

characteristic.

However,

i n o ur

simple

example, we merely

want

to

derive t h e

customer

group

characteristic

f r o m t h e customer characteristic via

derivation rules, f o r example: customer

group KG2

i s

derived f r o m

customer K3.

I

w i l l

show

you

t h e

derivation

via

derivation rules

f o r

t h e

customer group

characteristic

(userdefined).

F i r s t

we

have

to define

a s t e p

(here

s t e p

18)

i n

t h e

derivation

strategy

( s e e Figure 3.25).



©

Copyrigh t

SAP

AG.

A l l

rights

reserved.

Figure

3.25:

Derivation

strategy

for

derivation

rules

After selecting l i n e 18, c l i c k

t h e

magnifying gla ss . The

following

screen

appears (Figure

3.26).



©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

3.26: Example

of

a

derivation

rule

for t h e

customer group

As t h e source,

t h e

fixed characteristic customer

i s

s u f f i c i e n t ;

as

t h e

target, enter

t h e

userdefined characteristic customer

group.

As

t h e

target

i s

a

characteristic

that

you have

defined

yourself,

i n

t h e

same way

as

f o r t h e

characteristics

kind

of

product and product group described

a b o v e ,

you

have

to

maintain characteristic values

via

transaction KES1 ( s e e

Figure 3.27).

©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

3.27:

Rule

entries

for

t h e customer

group derivation

rule

I f

you

now

create

a

COPA

document, you w i l l

see

that

t h e

customer group characteristic (userdefined) was derived

with

t h e

characteristic

value KG1

f o r customer K1 (again

via

simulatio n wit h KE21,

see

Figure

3.28).

©

Copyrigh t

SAP

AG.

A l l

rights reserved.



Figure

3.28: Evidence

of t h e

derivation of

t h e

customer

group

D eriva tio n

rules

I f

when defining

t h e

derivation

rules, you select

i n t h e

attributes

that

t h e

system

s h o u ld

always

report

an

error i f

no

values

are

f ou nd f o r

t h e

r u l e ,

t h e SAP

system

w i l l

implement

t h i s

attribute

s t r i c t l y

meaning that

under

some

circumstances, you w i l l n ot crea te a

s a le s o rder

o r

b i l l i n g

document. Therefore, check

whether t h e p ar a m e t er Issue error

message

i f no

value f o u n d

i s

deactivated

i n

t h e attributes

( s e e

Figure 3.29).

I t

i s a ls o im po r ta nt t h a t , regardless

of

which

method

of

derivation you

c h o o s e ,

t h e

characteristic

values f o r the userdefined

characteristics

are

defined

i n

COPA, o t h e r wi se

an error w i l l occur.



©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

3.29: Attributes of

t h e rule

definition

In

t h i s

chapter you

have become familiar

with t h e

important

settings

f o r

characteristic derivation.

In t h e

next

chapter, I

w i l l

explain

how

you can

valuate

value

f i e l d s .



4

Valuation

In

this

chapter,

we

will

look

at

t h e

t opic

o f

valuation.

How can you

v aluate value fields?

Again, I will

use

examples

t o

show

you

how

t o con figure v aluations.

You

may be

wondering when numbers

w i l l

actually f i n a l l y

appear

i n

COPA. I w i l l explain t h i s

i n

detail

i n

Chapter

5.

However,

COPA

also gives

you

t h e option of creating

figures

by

valuation:

i n

o t her w o rd s, entering values

f r o m a

valuation

into

your

value

f i e l d s .

The

great

thing

a b o u t

t h e

costingbased

f o r m

of


i s

that

you

can

present no t

only

p o s t e d

values,

but

also costingbased

o r

planned figures.

As

part of a valuation strategy,

you

can

even define

t h e point

i n time

at

which

COPA

i s

to

perf o rm

t h e

valuation:

when

a

document

i s

posted,

at

t h e

time

of

manual planning, or at t h e

time

of

automatic planning. Here,

manual

planning

really

does

mean

manual

and

thus very

laborious

ut I

w i l l

explain

more

a b ou t

that

i n

Chapter 6.

What

i s

important

i s

t h a t ,

i n

contrast to characteristic

derivations,

valuations

are

only

performed

f o r

transactions

to which

a v alua tio n s t ra teg y

i s

assigned.

Characteristic

derivations

run f o r

every COPArelevant bu sines s

transaction

even

manual entry

of

COPA

l i n e

items

o r

t h e

transfer of

data

f r o m

an

external

data

interface.

How

do you p er f o r m valuations?

What

can

you

valuate

without

h a ving

to

p o s t

i t ?

Here too,

i n

t h e

supreme module

COPA,

you

can cust o mize t h e spectrum

i n

which

a

controller has free reign individually.

4.1 Valuation Types

There are

three t y p e s

of

valuation:

Via

material costing (also known

as

“material cost

estimate”)



Via

a pricing

procedure

i n SD o r

COPA

Via

user

exits

I

w i l l

now explain

t h e s e

i n

more

detail i n

t h e

following

sections.

4.1.1

Valuation

via Ma terial

Costing

Every profitbased

company

w i l l cost

t h e

products that

i t

s e l l s .

Th is t ype

of

costing,

at

least

f o r

determining t h e co s t

of

goods

s old f o r

a product,

i s

offered

by

COPC, Product

Cost Accounting,

i n t h e

SAP

module

CO.

Within

t h e s e

costings, you

can

crea te co s t components that you can use

to

differentiate

t h e individual s t a g e s

of

y our

product

costings.

Classic

cost components are

direct

material

cost s

and material overhead costs, direct p ro duct io n co s t s

and

production overhead

costs,

and external

a c t i v i t i e s .

These

cost components make

up

t h e

cost

of

goods

sold, that

i s ,

t h e cost s that you s h ould a ch iev e as a

minimum

when

selling

y our

product

i f

you want

y our busines s

to

survive

i n

t h e

longterm.

F o r t h e

cost

of

goods sold, y our

finished

p ro duct s t o cks

i n

t h e b alance s h e e t

are

also valuated. Why

am I

t e l l i n g

you

a l l this? Because

as

part

of

t h e valuation via

material costing, you can access

precisely

t h e s e predefined

cost components

by

g uidin g t h e values determined to

t h e

value

f i e l d s intended.

This a l l

sounds

very

theoretical e t

us make i t

clearer

using

o ur

example:

i n

Section

2.5.1

we

described a

contribution margin

accounting

that we

want

to r e f l e c t .

I t

contains

t h e lines

Material Costs and

Production

C o s t s.

Let

us assume that

you use COPC

and have defined t h e

abovementioned cost components.

The

cost components

direct

material

cost s

and

material

overhead

costs,

as

well

as

external

a c t i v i t i e s , were a s si g n ed

to t h e

value f i e l d

MATERIAL

COSTS;

t h e

direct pro ductio n co s ts

and

production overhead costs

were a s si g n ed to

t h e

value f i e l d

PRODUCTION

COSTS.



Furthermore,

f o r

t h e product

that

you want

to s e l l ,

you

have

at

least

an

earmarked, ideally released costing

(released

costing means that t h e s t ock

of

t h i s

product

i n

t h e

b alance

s h e e t

i s

valuated

with

t h e

price

released

f o r

t h e product).

In

y our

valuation strategy,

you

have defined that you want

to

run

material

costing

f o r

t h i s

product

at

t h e

time

of

invoicing

(invoice

=

b i l l i n g documen t ), f o r example.

Each cost

component

i s

t h e n valuated

with t h e b i l l i n g document

quantity automatically, that i s , multiplied

and

p re sen ted

i n

t h e respective value f i e l d

i n

t h e contribution margin

accounting.

I f

you

think a b o u t

my

explanations i n Section

3.1 again, no t o nly

are

various

value

f i e l d s f i l l e d

at

t h e

time

of

invoicing,

b ut

i n

o ur

example,

also

material

and

production costs.

By adding

t h e customer

and

product

(they

s h o u ld

be

included on

t h e

invoice as

a

minimum)

and

your

special

characteristic derivat ions ,

you can

also see t h e s e costs

on

characteristics t h a t ,

at

f i r s t

glance, have

nothing

to

do

with

product

costing.

F o r

example,

you

see

material

or

p ro duct io n co st s

on t h e

customer group characteristic.

Which material

and

p ro duct io n co s ts

were

created f o r

customer

group

KG1 i n

period XY?

This i s

a question

that

you w i l l soon

be

able

to

answer at

t h e push of

a but t o n

i f

you decide

to

use t h e supreme module

COPA.

In

customizing you

f i r s t have

to

define a valuation

strategy.

You

t h e n

a s si g n

t h i s

strategy

to

one

o r

more

points

of

valuation

( I w i l l

explain

what a point

of

valuation

i s

l a t e r

on

i n t h i s chapter).

A v a lua t io n s t ra t eg y

i s

essential

i f

you

want

to

undertake

valuations.

Depending

on

how

many

s t e p s

you build

i n to

y our valuation

strategy,

they are

run

f o r

every

COPA

valuation

operation

i n t h e

predefined

sequence.

Fo r

o ur

customizing,

we

w i l l build

up t h e

v aluation s trategy

successively. I n i t i a l l y ,

we

w i l l

only

show t h e

s t e p

that we

need

f o r t h e

valuation via material costing.

In

o ur

example customizing,

i n t h e

COPA

I mplemen t a ti o n



Guide

(transaction

ORKE),

via

MASTER DATA •

VALUATION

•

DEFINE

AND

ASSIGN VALUATION STRATEGY,

define strategy

Z01,

which you

f i l l

as

shown

i n

Figure

4.1.

©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

4.1:

Valuation

strategy

for

material

costing

In t h i s

step,

place

a checkmark

i n t h e

MAT.

CSTG

column.

This

t e l l s COPA that

you want

to

perf o rm material

costing

f o r

t h i s

valuation

step.

As

a quantity

f i e l d ,

enter

t h e

quantity

f i e l d

with

which

t h e

cost components

of

t h e material costing

are

to be

multiplied

f o r t h e

valuation.

In o ur

example,

t h i s i s

t h e quantity

f i e l d

ABSMG.

Assig n

t h i s

valuation strategy

to

a

point

of

valuation

( P V,

see Figure 4.2): you

do

t h i s under

t h e

same customizing

item

as

f o r defining

t h e

valuation

strategy.

©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

4.2:

Assignment

of

t h e

valuation strategy

to

a ct ua l p o in t s

of

valuation

Point

of

valuation

01

i s

t h e

actual valuation;

i t

i s

combined

with individual transaction

types.

F o r example, valuation

strategy Z01

i s

run f o r

an

incoming

s ales o rder (transaction



t y p e

A)

i n

SD.

You

must

now

set

up

t h e

valuation

via

material

costing

(that

i s ,

via COPC) i n customizing, using

t h e

customizing

structure

as

per Figure 4.3. You

have

to

p r oce s s t h e points

i l l u s t r a t e d

h e r e

i n sequence.

©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

4.3: Customizing

structure for

valuation

via CO-PC

D e fin e

Access

t o

Standard

Cost

Estimates

F i r s t

make

an

entry

i n

t h i s

table

f o r t h e

costing key;

i n

o ur

example

t h i s

entry

i s

Z01

( s e e

Figure

4.4).



©

Copyrigh t

SAPAG.

A l l

rights

reserved.

Figure

4.4: Definition

of t h e

costing key I

F o r

a

v a lua t io n w it h m at erial costing, t h e costing

key

defines

t h e access p ar a m e t er s used f o r

t h e

s earch f o r a

valid

product costing

( s e e

Figure 4.5).



©

Copyrigh t

SAPAG.

A l l

rights

reserved.

Figure

4.5: Details

of t h e costing

key

F o r

o ur

e x a m p le,

we

define

that

we

want

to

access

standard

cost estimates. The system searches

f o r

standard

cost

estimates

of

costing

variant PPC1

f o r

costing

version

1 and

ongoing

standard cost

estimates

f r o m

t h e entry

i n t h e

material

master

of

t h e

product

to

be

s old

are

accessed.

The

product costings are plantspecific;

we

w i l l

use t h e plant

f r o m

t h e

COPC

l i n e

item.

Assign

Costing

Keys t o Material

Types



We

assign

t h e defined costing

key

Z01

to

material

t y p e

FERT ( s e e Figure 4.6). The sales products A1

to A6

used

i n

o ur example

have

a l l been

created

f o r

material t y p e FERT

i n

MM.

©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

4.6: Assignment

of

t h e

costing key

to t h e

material

t y p e

What

do

t h e s e entries

i n

Figure

4.6

mean? The material

costing

of

t h e

finished

product

i s

f ou nd

f o r

t h e

actual

point

of

valuation

01

i n

combination with record

t y p e

A

and

F,

and

f o r planned points

of

valuation

03

and 04, b ut

I w i l l come

back to t h o s e l a t e r .

Assign

Value

Fields

To

be

able

to

access

a

material

costing

at

a l l ,

you must

f i r s t

create

t h e

material

costing, f o r e x a m p le,

with a quantity

structure ou

do

t h i s using transaction CK11

o r

CK11N

i n

COPC.

F o r a costing l o t

size,

a i l l

of

material and a routing

are processed

f o r

a finished product,

f o r e x a m p le,

and

v a rio us co s t components

are

f i l l e d . COPA value

f i e l d s

were

a s si g n ed

to

t h e s e cost components

i n

t h e FIELD NAME 1

column

under

ASSIGN

VALUE

FIEL D S

( s e e

Figure

4.7).



©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

4.7:

As s i g n in g v a l ue

fields for

CO-PC

What happens now?

F o r

product

A1,

f o r

example, I have

a

material cost rate of

EUR

1500

per

u n i t . F o r

a

sales quantity

of

10

units, t h e MATERIAL INPUT value f i e l d

i s

valuated

with

EUR

15000


©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

4.8: Evidence

of

t h e

valuation

of material

in put v ia CO-PC

A

further example that

also

p r o v e s t h e

valuation

using t h e



v a lua t io n s t ra t eg y f o r p ro duct io n co s t s

i s

shown

i n

Figure

4.9.

F o r

product

A5,

a production cost rate of EUR2 per unit

i s

assumed.

©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

4.9: Evidence

of

t h e

valuation

of

p r o ducti o n co s t s

Now

you

may s ay:

H e’ s

go t a

l o t

to

say b ut

i s

i t

reliable?

However,

i f

you

have created

material costings

f o r

your

products

i n

COPC ( e . g . , via

transaction CK11N

with

costing

variant PPC1),

and

have t h e n flagged

and

released t h e s e

costings,

t h i s

cost

of

goods

s old

rate

i s

updated

as

t h e

standard

price

i n

your

product

master

record

provided

you

maintain t h e product by s t a ndard price. In

o ur

simple

e x a m p le, f o r product

A5

we

have

a material input

of EUR

2

per

unit

and

pr oductio n co s t s

of

EUR

1

per

u n i t .

This

means

that

we

update a

standard price

of EUR 3 per unit i n t h e



material master

( s e e

Figure

4.10). I f

t h e

material costing

i s

released,

t h i s

standard price i s

used

to

valuate y our product

s t ock

and

therefore

has

a direct impact

on

t h e

inventory

valuation

i n

y our balance

sheet.

©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

4.10:

Accounting

view

1

for

product

A5

In

t h e

video b e l o w , I w i l l d e m o n s t r a t e

how to

s et

up

a

valuation

via

material costing.

Video 3:

Valuation

via

material

costing

Note: Should

y our

reading device

no t

be

able

to

show

t h i s



video,

you

can use y our

computer

to

watch

i t on

t h e

internet.

To do

t h i s , head to o ur web page at


4.1.2

Valuation v ia a Pricing

Procedure

in

SD

o r

COPA

You

can also create valuations

via

pricing procedures

that

are created

i n

o t her modules such

as

SD

o r

directly

i n

CO

PA. Normally,

you

do

no t

have to

include an

SD

pricing

procedure

i n

your valuatio n s t rategy

i f

you

have

maintained

t h e SD interface

to

COPA. However, t h i s

may be

useful

i n

some cases. I w i l l explain an example

i n

Chapter

6,

Planning

i n

COPA. The

SD

module calculates values i t s e l f

i n

i t s

pricing

procedure. Via

t h e SD

interface, we can access

t h e s e values

and

transfer them

to

COPA.

In

o ur

simplified contribution margin structure,

f o r

two

lines

we

assume

that

t h e y

are

f i l l e d

by valuation: cash

discount

and rebate.

You

grant customers cash discount

via

t h e

payment

terms.

I f

t h e

customer pays quickly,

t h e y

receive

cash

discount.

When

you

enter

a sales order, create an invoice, or settle a

s ales o rder

to

COPA,

you

usually only

know f r o m

experience whether

t h e

customer pays quickly

and

deducts

cash discount

o r

not.

You s h ould create a contribution

margin accounting

i n

COPA as

a w o r s t case invoice,

that

i s ,

you

s h ould

assume

t h e

w o r s t

possible scenario.

Specifically,

t h i s

means

that

y o ur cus t o mer,

to

whom you

grant cash discount,

actually deducts

cash discount.

Usually, i n

t h e SD

pricing

procedure,

you

create a condition

t y p e

Cash

discount

that

receives a “ s t a t i s t i c a l ” checkmark.

Here,

s t a t i s t i c a l means that

at

t h e

time

t h e SD pricing

procedure

i s

executed,

no t hing

i s

p o s t e d

i n

FI

f o r

cash

discount

but t he

cash

discount

amount

calculated

i s

adopted

i n

COPA.

The

situation

i s

different f o r

rebates.

Let us

assume

that

rebates

are

gran ted based

on

sales quantities or



p ercen tage s

i f

t h e customer f u l f i l l s specific requirements.

Again, you only know whether t h e customer has earned

t h e

reba te once

you

have

issued

t h e invoice

to

t h e

customer.

The w o r s t case

principle also

applies h e r e ( w or st case

because

we have to b e a r

a l l

possible costs).

You

assume

that

t h e

customer

receives

a l l

rebates.

We

include

t h e s e

i n

t h e REBATE value f i e l d

i n

COPA.

You

may

wonder

what

I

am talking

a b ou t

as

t h e s e

are

completely

normal

calculations

of imputed

cost s that

we

used

to

p o s t

m anuall y

b e f o re

I T .

Correct.

In

t h e

case

of

t h e

rebate,

you can

calculate imputed cost s

with

every invoice i f

you

have

entered rebate agreements

i n

SD,

have

created condition

t y p e s

f o r

t h e m ,

and

have

cus tomized

revenue

account

determination

i n

SD. At

some

point

your

customer

gets

i n

touch and wants

his

rebate because he

has

f u l f i l l e d t h e

requirements.

The SD rebate

agreement

i s

t h e n settled and

t h e customer

receives

his

money.

I s

t he s et tlement

t h e n

transferred

to

COPA?

I f s o, t h e

rebate would

be

deducted

twice

i n

COPA

once

f o r

t h e

calculation

of

imputed

cost s

and

once

f o r

t h e

settlement.

Naturally

you have

to

av oid

t h i s

error b ut t h i s

i s no t

d i f f i c u l t

i n t h e

costingbased

f o r m

of


You

simply

transfer

t h e

calculation

of

imputed

cost s

but no t t h e

settlement.

I

w i l l give

you

details

of t h i s b e l o w .

How

many

rebates were gran ted

i n

period

XY i n

kind

of

product

PA2

overall,

o r

only

i n

customer

hierarchy

KH12?

You

are j u s t one

pres s

of

a button

away

f r o m

t h e answer...

I f you use t h e SAP module

SD

( Sales and Distribution),

pricing procedures and condition

t y p e s

are defined

there

f o r

pricing. SD usually uses

t h e s e

to

find

t h e

valid

prices

and

conditions f o r

an

incoming s ales o rder or f o r

an

invoice;

i n

t h e

case

of

revenues,

discounts,

or

f r e i g h t , t h e s e are usually

also

p o s t e d

to

corresponding

FI

accounts

automatically.

F o r

o ur

example customizing,

we

want

to

show t h e

valuation

via SD

once

f o r

a

condition

t y p e

ZSKT that

i s

indicated

as

s t a t i s t i c a l

i n t h e SD

pricing procedure.

This



means

that t h e

value determined i s no t

p o s t e d

automatically. However, we s t i l l want

to

display

t h i s

value

i n

COPA.

In

Figure 4.11,

we

see a relevant extract f r o m t h e SD pricing

procedure

that

I

have

customized

f o r

o ur

example.

Note

t h e

condition

t y p e

ZSKT.

Do

you see

t h e s t a t i s t i c a l

flag?

©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

4.11:

Presen tation

of t h e

condition t y p e

ZSKT in t h e SD

pricing

procedure

Condition t y p e ZSKT

i s

a s si g n ed

to

value f i e l d

VV070 (Cash

Discount)

via

t h e

SD

interface.

You

make

t h i s

assignment

i n

customizing

f o r COPA

(transaction

ORKE)

via

FLOWS OF

ACTUAL VALUES • TRANSFER OF BILLING DOCUMENTS •

ASSIGN

VALUE FIEL D S

see

Figure 4.12.

©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

4.12:

SD

interface



In SD,

via

transaction VK11,

you

create condition records

f o r condition

t y p e

ZSKT.

F o r o ur

example,

cash discount

i s

gran ted to three

customers

( s e e

Figure 4.13).

©

Copyrigh t

SAPAG.

A l l

rights

reserved.

Figure

4.13:

Cash

discount condition

records

F o r

a

COPArelevant posting,

i n

Figure

4.14,

f o r

customer

A6

we

see

that

f o r

g r o s s sales

of EUR

124 after

deduction

of

discounts

i n

t h e

amount

of

EUR

4.99

t h e

net sales

are

EUR 119.01. The cash discount amount

calculated

i s

EUR 1.20,

which

i s

exactly

1

cash discount

.



©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

4.14: Evidence

of t h e

valuation

of

cash

discount

via

SD

4.1.3

Valuation v ia

User

Exits

As

explained

i n

Chapter

3,

COPA

also

contains

SAP

enhancements

f o r

t h e valuation. Again,

with

y our

own

programming, you

can

e n a b l e valuations

that are

no t

available

i n t h e SAP

standard

s y s t e m .

The

important

thing

i s that

you

name t h e exits

i n

your ABAP

coding ( f o r

e x a m p le, U01, U02, e t c . ) and include t h e s e

user

e x i t codes

i n

t h e

valuation strategy.

F o r

o ur

simplified P r o f i t a b i l i t y Analysis,

we

w i l l f i l l

t h e

additional

quantity

f i e l d

ALTERNATIVE

QUANTITY

via

user

e x i t .

I t

often makes

sense

to compare

y our dat a

with

an


reference.

Examples

of

quantity



references

can

be

hectoliter

f o r

b rew eries , 0.7

l i t e r s

f o r

s p i r i t s , l i t e r s

f o r

manufacturers

of

alcoholfree drinks, etc.

( as

you can see,

I have

s p e n t a large part

of

my

professional

l i f e to

date

i n

t h e beverages industry).

You

s h ould

also

consider

an

alternative

quantity

factor

f o r

y our

company. Why

i s

that?

This

i s

so that when comparing

contribution margin accounting l a t e r , you can consider

contribution margin 1

per HL

(or

E07 or

L

o r

kg , and

so

on).

This

e n a b l e s

you

to assess precisely how

you

are

doing

with y our products, customers,

o r

o t her

derived

characteristics

with

reference

to an

alternative

quantity

factor,

b o t h

with

regard

to

actual

as

well

as

planned

figures,

i n comparison to previous years, forecasts, etc. Amongst

o t her

things,

t h i s

helps

you

to find

errors

i n

t h e actual

or

planning data

quickly

i f

at some

point you

think that

y our

contribution margin accounting i s no t r i g h t . . .

In

o ur

example, we

w i l l

concentrate

on

t h e

alternative

quantity unit kilogram (kg). You can

see

t h e example

customizing

i n

Section

0.

There

I explained how

you can

use user

exits

f o r


to add

t h e

quantity unit

of

o ur quantity

f i e l d

ALTERNATIVE

QUANTITY.

You may also

be

interested

i n

seeing no t

only

t h e quantity

u n i t , b ut also t h e

alternative

sales quantity

i t s e l f .

I

w i l l

explain

t h e

customizing

required b r i e f l y here.

F i r s t

you

have

to

enhance

t h e

valuation strategy

i n

order

to

t e l l t h e system that you want

to

p r oc e s s a

user

e x i t ( s e e

Figure

4.15).

©

Copyrigh t

SAP

AG.

A l l

rights reserved.



Figure

4.15:

Valuation

strategy

with access

to

user exit U01

To

evaluate

a

COPA

user

e x i t

you also

proceed

via

t h e

customizing f o r COPA,

via

TOOLS • SAP ENHANCEMENTS.

Create

a project and a s si g n

component COPA0002.

By

doubleclicking

t h e

component,

navigate

to

t h e Include

ZXKKEU03. I f you have a

developer

key i n y our

s y s t e m ,

you can

f i l l

t h i s

Include. You can

see

t h e

example coding i n

Figure 4.16.

©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

4.16:

Actual user exit

for

valuation

of

t h e

value

f i e l d VVAMG

After coding,

s a v e,

check,

and

activate

t h e

include. User

e x i t U01 now

has

t h e

effect that at

t h e time

valuation

strategy Z01 i s f o und, t he coding

of

user e x i t

U01

i s

processed.

In

t h e

simple

example

co din g, t h e

SAP

system

searches

i n

table

MARMf o r

t h e

alternative quantity unit

KG

(kilogram) that

you

have maintained

f o r

each product,

as

described

i n

Section

0.

F o r example,

one

unit of

t h e

product

A1 weighs 100

kg. I f

you

t h e n

s e l l

eight units,

800 kg

s h ould



be visible

as

alternative

sales quantity

( s e e

Figure 4.17)

(marmumren =

100/marmumrez

= 1 *

8 ) .

©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

4.17: Evidence

of

valuation

via

user

exit

U01

In

t h e

l a s t two chapters, you

have now

learned a b ou t

characteristic derivation and

t h e

valuation

of

value f i e l d s . In

t h e

next two

large

chapters

we

w i l l look

at how

actual and

planning

data

get into COPA.



5

Actual Value Flows

There

a re

many

ways

o f controlling

actual

data

in

Profitability Analysis. On

one

hand, this depends

on

your business model; on

t h e

o t h e r

hand,

i t

a l s o

depends

on

t h e

contribution

margin accounting

scheme that

you

want

t o

s et

up .

Alternatively, i f in your

company,

you

have decided not t o use

a l l

SAP

R/3

o r

ERP

modules,

you may

a l s o

use third p a r t y interfaces,

f or

example,

from

an

external

billing

o r

CRM

system.

In

practice,

t h e

following methods

of

controlling data

are

frequently used:

SD

interface

Settlement

to

COPA

FI

interface

Cost center assessment

Direct entry of

l i n e

items (correction option)

Third party

interfaces

How does

COPA

know which of

t h e s e

methods was

used?

I t

knows

t h i s

f r o m

t h e

fixed characteristic

record

type. The

record

t y p e

shows which method

was

responsible

f o r

feeding

t h e data

into COPA. Invoice data

i s

adopted with

record

t y p e

F,

sales orders with

A, FI

postings

with

B,

cost

center assessments with

D ,

and

set tlement s

with C.

You

can also define characteristic values

f o r

t h e record

t y p e

yourself

f

you

want

to

see everything

that

has been

included

via

possible

l i n e

item

corrections

(that

hopefully

occur

only

infrequently),

f o r

example.

5.1 The Most Important Interface

t o

COPA: The SD

Interface



As

you

have seen

f r o m

my

previous

explanations,

you

usually

use

COPA

to

present y our results

on

t h e market

and

to

assess them according

to

various c r i t e r i a

and

bu sines s requirements.

I t

w i l l

therefore

pr o ba bl y

no t

surprise you that

t h e

interface

to t h e SAP

module SD ( Sales

and

Distribution)

i s

very

important.

This

important

function

i s

also

clearly

visible

i n

t h e SAP

system f r o m

t h e fact

that

you

can use

t h i s

interface f o r

two

different times

of data

transfer

to

COPA:

at

t h e

time

t h e s ales o rder i s received and

at

t h e

time

of

invoicing.

Transferring

actual

data

at

t h e

time

of

t h e

incoming

sales

order

i s

interesting

f o r

companies

f o r

which

t h e

time

of

t h e

incoming sales

order

and t h e

time

of invoicing are

quite

f a r

apart.

You

may

work

f o r

a company that wants

to

see

at

t h e

time

t h e

order

i s

received

how t h e

future

bu sines s

situation

w i l l devel op without h a ving

to

wait

f o r

in v oice da t a. These

companies often

s e l l

products f r o m projectrelated

production,

variant configuration,

maketoorder production,

or

maketostock

production,

i . e . ,

products

f o r

which

manufacture

takes

a long

time

o r

products that are no t

produced

u n t i l

after

t h e

order

i s

received.

In

contrast,

i f

you

s e l l MTS (maketostock)

products, you can

usually

deliver

products

f o r

incoming sales orders quickly

f r o m

your

warehouse

and

t h e n invoice t h e m .

In

t h e s e cases,

transferring

t h e

SD

data

at

t h e

time

of

invoicing

i s

usually

s u f f i c i e n t

as

you

do no t

gain

any

new

information

i n

comparison

to

transferring t h e data

at t h e

time

of

t h e

incoming sales order.

I f a company

does

no t

s e l l

MTS

products, i t usually decides

to

use b o t h dat a

transfer times.

However,

there

are

also

companies that

use t h e

s ales o rder

i n SD as

a cost and

revenue

collector and settle

t h i s

s ales o rder

to COPA

l a t e r

( f o r

more information,

see

Section

5.2).

The

invoice

i s

t h e n

issued, b ut

t h e

invoice

data

i s

no t transferred to COPA

u n t i l

t h e s et t lement

of t h e

s ales o rder and

no t

at

t h e

time t h e

invoice i s issued.



5.1.1

Handling o f

Quantit y

Fields

In

order

to

transfer

s a les o rder

quantities

o r

sales quantities

to COPA,

you

have

to

name

certain SAP

f i e l d s

that

you

want

to

assign

to

y our

quantity f i e l d s .

You

can find

t h e s e quantity

f i e l d s

i n

customizing

f o r COPA

i f

you

want

to

a s si g n

your

COPA quantity f i e l d s .

In

t h e

configuration menu

f o r

COPA

(transaction ORKE), you

maintain

t h e SD

interface f o r t h e quantity

f i e l d s

via

FLOWS

OF ACTUAL VALUES • TRANSFER

OF

BILLING DOCUMENTS•

ASSIGN

QUANTITY FIELDS.

The

SD

quantity f i e l d s shown

i n

Figure

5.1

are

available.

©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

5.1: Selection

of SD

quantity fields for

CO-PA

quantity

fields

S a l e s quantities f r o m t h e invoice are

i n

f i e l d

FKIMG

o r

FKLMG,

and

s ales o rder quantities

i n f i e l d

KWMENG. F o r

o ur example,

we

a s si g n t h e s e

two

SD quantity

f i e l d s

to

o ur

COPA quantity

f i e l d

ABSMG ( s e e Figure 5.2).



©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

5.2: Assignment

of

SD

quantity f i e l d

to

CO-PA

quantity

f i e l d

Can

we assign b o t h f i e l d s

to t h e

SALES QUANTITY

quantity field? I f

you

want

to

transfer

b o t h

t h e sales

orders

and t h e

invoices

to

COPA,

i n

COPA

you can

create one

quantity f i e l d f o r

t h e

sales

order

quantity and one

f o r

t h e

invoice quantity

and

t h e n

a s si g n them

either

to

KWMENG

o r

FKIMG.

The

advantage

of

t h i s i s that

you can separa t e

b o t h

quantity transfers

i n

COPA reports and treat

them

d i f f e r e n t l y

i n

t h e

valuation

strategies.

5.1.2

Transferring

Invoice

Data

I f

you

decide

f o r y our company

to

transfer

t h e

actual data

to

COPA at t h e

time

of

t h e

invoice,

t h e

advantage

i s

that

you

can transfer

and

p o s t t h e

data

i n

realtime. A great

advantage

of

t h e

SAP system

i s

that

t h e data that you

enter

i s often available

i n

o t her modules

and

reports

when

you

save

i t

. e . ,

immediately

i n

realtime. A further resulting

advantage

i s

that you usually only

have

to

enter

a data

record once

to

be able

to

see and use

i t

i n

multiple

modules.

Duplicate entries are

a thing

of

t h e

past,

b ut

t h i s

may

well

be why you

have

decided

to

use

SAP.

Back

to

t h e invoice transfer: SD works with SD pricing

procedures

to

determine

prices

and

conditions.

These

pricing

procedures

use condition

types.

During

invoicing

( a n d

during

entry of t h e sales order), t h e system

runs

t hr ou g h t h i s pricing

procedure

finding

t h e

required prices,

discounts,

cash

discounts,

rebates, freight charges, sales



pr o m o ti o n s, etc. f o r

t h e

customer/product combination that

you want

to

invoice.

We

ad op t t h i s

f o r m

of

pricing

and

condition determination

i n

COPA

by assigning

t h e

condition t y p e s

to

o ur

value

f i e l d s

defined

i n

t h e o pera tin g

concern.

Anecdote

During

my

time

as

a

consultant, I

had

a project

at

a very large

customer.

I

was

responsible

f o r

t h e

implementation

of

CO,

and

my

b e s t

friend was responsible

f o r

t h e implementation

of

SD.

I

had j u s t

completed

t h e SD

interface and created a test invoice: and what

happened?

COPA was

e m p t y

I

asked

my

friend

i f

he had

cus tomized

everything

correctly

i n

SD.

After some

time,

I discovered

t h e

following: I

had

forgotten

to

create

t h e

relevant

accounts

that

are

p o s t e d

to

during invoicing

i n

FI

as

cost

elements

of t y p e 11 and 12

my

friend was completely

innocent

( a n d

s t i l l

remindsme of i t

even

n o w ) .

What

do

we

learn f r o m

t h i s

anecdote? During

invoicing,

data

i s transferred

to

COPA, b ut

an

accounting document

i s also created

i n

FI f o r t h e revenue and discount posting.

These

accounts

must also

be

created

as

cost elements,

o r

more

precisely,

as

primary

cost

elements. F o r

revenues,

cost element t y p e 11 applies, and

f o r

discounts, cost

element

t y p e

12.

Primary

cost

elements

are

used

i n

b o t h

FI

and

CO,

but

secondary

cost

elements

are

used

only i n CO.

When

an

invoice

i s

automatically

p o s t e d

to

a

primary

cost

element, a controllingrelevant account assignment

i s

also

specified

i n

t h i s

case

a p r o f i t a b i l i t y

segment. A



p r o f i t a b i l i t y segment comprises

t h e

combination

of

a l l

specified and derived characteristic values. This account

assignment

i s

r e a l ,

but

a l l

o t her account

assignments

are

only

s t a t i s t i c a l howing t h e supreme module again.

You

may

now

be

wondering

what

I

am

t e l l i n g

you. I

previously sta ted that

you can

collect cost s

and

revenues

on

sales

orders

and t h e n

settle

them

to

COPA.

We

have

also

learned that

t h e

assignment

of

condition

t y p e s

to

value

f i e l d s

applies f o r

b o t h

s ales o rders and invoices.

However,

when we invoice,

we

transfer

t h e

invoice

data

to

COPA at

t h i s

point

and do

no t wait f o r t h e

settlement

of

t h e sales

orders.

F o r

t h i s

situation,

t h e

normal

SAP

standard

system

sets a block: i f you have used

an

account assignment

category

to

define that your s ales o rder

can

collect cost s

and revenues,

t h e

SAP

system

automatically

allows an

a ddit io nal t rans fer of

t h e

related invoice to COPA.

Therefore, you do no t

have

to

settle

t h e

sales

order.

You

may remember my

explanations

i n

Section 4.1, where I

provided

some

information

a b ou t

valuation

strategies.

I f

you

have defined

valuation strategies, t h e s e strategies

are

a s si g n ed

to

a

bu sines s event. The b us in es s ev en t

i s

a

combination

of

two or

three

characteristic values.

01

(actual

valuation)

i n

combination with a record

t y p e

03

(manual

planning)

i n

combination with

a

record

t y p e

and

a

plan

version

04

(automatic

planning)

i n

combination with a record

t y p e

and

a plan version

I f

you now a s si g n a valuatio n s t rategy

to

b us in e s s e v en t

01

i n

combination with reco rd t y pe F, no invoice data

i s

transferred

to

COPA f o r

t h e

sales

orders

to

be

invoiced

i f

t h e s e

sales

orders

collect

cost s

and

revenues.

I f

you

want

to

settle sales orders

to

COPA

as

cost

and

revenue

collectors,

you

have to a s si g n bu sines s

even t 01

i n

combination with record

t y p e C

to an

a ct ua l v alua tio n

strategy and define a corresponding settlement

strategy.



5.1.3

Transferring

Incoming Sales

Orders

I have

already

covered

a

l o t

of

information

on

t h i s

topic,

b ut

t h e impo rt ant

thing

to

emphasize

i s

that

you

have

to

e x p l i c i t l y activate t h e transfer of incoming sales orders

to

COPA

as

part

of

customizing,

o t h e r wi se

i t

does

no t

w ork.

You

also

have to

assign your actual

valuation

strategy

to

b us in es s ev en t

01

i n

combination

with

reco rd t y pe

A.

Record t y p e A identifies

t h e

COPA documents

that

originate

f r o m

t h e incoming sales

order.

I f

you forget

to

assign valuation b us in es s ev en t

01

i n

combination

with

record

t y p e A

f o r

a valuation

strategy,

when

you

transfer

incoming

sales order

documents

to

COPA,

no

additional

value

o r

quantity

f i e l d s are

valuated.

5.1.4

SD

Interface

f or Our

Example Data

F o r o ur e x a m p le,

we

want

to

use

t h e SD

interface

to

f i l l

t h e

following

value

f i e l d s :

S a l e s Quantity

Revenue

O t h e r Discounts

Cash Discount

Annual

Rebates

Outgoing Freight

S a l e s

Promotion

As

already

described, condition

t y p e s

are

defined

i n

t h e

SD

pricing

procedure

to

f i l l t h e s e

value f i e l d s .

F o r

revenues,

discounts,

and

rebates,

there

are

also simultaneous

postings

to

G/L

accounts

i n

Financial

Accounting.

Cash

discounts,

freight charges,

and sales

p r o m o t i o n s are

marked

as

s t a t i s t i c a l

i n

t h e

SD

pricing procedure.

This

means

that t h e

data

that

i s

transferred to

COPA

via

t h e s e

condition t y p e s

i s

no t

simultaneously p o s t e d

to F I . This

only



happens

i n

t h e

costingbased

f o r m of


( s e e also Section 2.4). You may also discover that sales

p r o m o t i o n s

s h o u ld

also be

transferred

via t h e SD

interface.

S a l e s

p r o m o t i o n s are

products that we

give

to t h e

customer

free of charge

i n

t h e hope

of

higher sales. These products

are

invoiced

to

t h e

customer

with

a

value

of

zero;

i n

COPA,

t h e y are

transferred s t a t i s t i c a l l y

( i . e . ,

costingbased)

with

t h e

value

at

which t h e s e

products

are

also valued

i n

t h e

b alance sheet.

Incoming

s a l e s

order

P o s ti n g s only

occur

to

FI

accoun t s

i f

you use

t h e SD

interface f o r invoice transfer.

S a l e s

orders

are

transferred

with

record

t y p e

A,

i f everything

i s

customized

correctly,

without

being

p o s t e d

i n F I .

5.1.5

Customizing t h e

SD

Interface

In

t h e

configuration menu

f o r

COPA

(transaction

ORKE),

maintain

t h e SD

interface

f o r t h e

value

f i e l d s

via FLOWS

OF

ACTUAL VALUES • TRANSFER OF BILLING DOCUMENTS•

ASSIGN

VALUE

FIELDS.

Then double

c l i c k

t h e

entry MAINTAIN

ASSIGNMENT

OFSD

CONDITIONS

TO

COPA VALUE FIELDS.

Duplicate function



This

interface

i s

also valid f o r

incoming sales orders.

Now

you

see

an

o verview

i n

which

t h e

condition

t y p e s used

i n

y our

SD pricing procedure

are

a s si g n ed

to

COPA value

f i e l d s ( s e e

Figure

5.3).

©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

5.3: Assignment

of

SD

interface

to

value fields

I f

t h e

data

f r o m SD

i s

simultaneously

p o s t e d

i n

FI

i n

addition

to

t h e

transfer

to

COPA, t h e related

accoun t s must

be

defined

as

cost

element

of

t y p e

11

( f o r

revenues )

o r

t y p e

12

( f o r sales deductions). S t a t i s t i c a l condition t y p e s

can be

transferred directly

to

COPA.

The assignment

of

quantities

to

quantity

f i e l d s

i s similar

( s e e

Figure

5.4) and

you can

access

i t

under

t h e

same

path.



©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

5.4:

SD

interface, quantity

fields

Now

i t

i s

time

to

p r o v e

that

t h e

cus t o m iz in g de s cr ib e d

w ork s:

i n

a

s ales o rder

o r

invoice,

select

an

item

and

t h e n

proceed

to

t h e

CONDITIONS

tab. There

you

w i l l see t h e

screen

shown

i n

Figure

5.5.

©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

5.5: Example analysis of standard

order

12134

I f

we

look

at

t h e

actual

l i n e

items

record

f o r

record

t y p e

A i n



COPA,

we

see

values

i n t h e

quantity and value

f i e l d s

according

to

Figure

5.6 and

Figure 5.7.

©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

5.6: CO-PA line

items

for

order 12134

(1)

©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

5.7: CO-PA line

items

for order 12134

(2)



The

f i e l d s

SALES QUANTITY, OUTGOING FREIGHT,

REVENUE,

and OTHER DISCOUNTS come via t h e SD interface. And

t h e

o t her

two? From

t h e

valuation

of

course ( y o u

knew t h a t ) .

5.2 Settlement

t o

COPA

What can you settle

i n

COPA?

Alt h ough there

are no

l i m i t s

here, I w i l l

r e s t r i c t

m y s el f

to

four options

f r o m

different

m odules:

Settlement

of

internal

orders:

You

can

use internal

orders

to

check t h e

costs

of

internal a c t i v i t i e s ,

such

as

development

costs,

costs

of

promotional

events,

etc.

You

p o s t

and

collect t h e s e cost s

on

internal

orders

to

t h e n settle them

to

p r o f i t a b i l i t y segments after closing.

As I w i l l

show i n t h e

next

section,

i n

your

settlement

p r o f i l e ,

define PSG

( f o r p r o f i t a b i l i t y

segment)

as

t h e

account

assignment pr op o s al and specify exactly

to

which characteristics settlement

i s

to

take place.

You

can also

settle

cost s

and

revenues collected

on

a

project

to

COPA f r o m t h e module PS (Project S y s t e m ) .

Companies

that

act

as

maketoorder manufacturers

use

an

SD s a les o rde r as a collector

f o r

revenues and

cost s

i n

order

to

settle t h e order

to

COPA after delivery

and

invoicing.

A fourth

option

i s

that

you can

settle production

orders

and product

cost

collectors to COPA p r o f i t a b i l i t y

segments f r o m PP using production cost collectors.

In

t h e s e cases,

you

are

usually

using

variance

determination

i n

cost

object controlling.

You can

settle

production variances

f o r

completed orders or transfer

deviations

f r o m

longrunning

production orders

to

CO

PA. You

can

t h e n

display

t h e s e

items

separately

according

to

individual

variance

categories.

I have now

i l l u s t r a t e d

four

settlement methods

f r o m

CO,

PS,

SD, and

PP to

COPA showing also that

i n

COPA,

t h e



data

f r o m many

different SAPmodules

i s

merged.

Which

settlement

method

do we

want

to

select

f o r

o ur

example? F o r

t h e

marketing costs

we

w i l l

use internal

orders

that

we

t h e n settle

to

COPA.

5.2.1

Customizing t h e

Se t t lemen t

t o

COPA

f or

Our

Example

In

t h e

configuration menu f o r COPA (ORKE),

set

up

a


( PA ) transfer structure. The

p a t h

i s

shown

i n

Figure

5.8.

©

Copyrigh t

SAPAG.

A l l

rights

reserved.

Figure

5.8:

Customizing

path

for settling

orders

A PA transfer structure i s 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 f i e l d s .

In t h e

e x a m p le,

we

have

created

PA

transfer structure

10

with assignment

10

( s e e

Figure

5.9).



©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

5.9:

Access to PA transfer

structure

10

In

t h e PA

transfer structure a s signmen t,

you

f i r s t

define a

source,

that

i s ,

you define which cost

elements

you

want

to

assign

to

COPA

i n t h i s

settlement

s t e p

( s e e

Figure

5.10).

In

t h i s example, we

only

want to settle expense account

478000.

In

o ur

chart

of

accounts t h i s account

contains t h e

marketing

e x p e n s e s .

As ,

i n

t h i s case,

t h e

account

i s

a

p r im a ry a cco un t , G/L account 478000 must also

be

created

as cost

element

with

cost

element

t y p e 1 (primary costs).

©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

5.10: Assignment

of

cos t

element

to PA transfer structure

10



In

a second

step,

we

a s si g n

a

further COPA value

f i e l d

VV380

to PA

transfer structure

10.

The marketing cost s

are

to

be

settled

to

t h i s value f i e l d

(Figure

5.11).

©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

5.11: Assignment

of value f i e l d

VV380

to PA transfer structure 10

You t h e n assign

t h e PA

transfer structure

to

a settlement

p r o f i l e

( s e e

Figure 5.12).

©

Copyrigh t

SAPAG.

A l l

rights reserved.



Figure

5.12: S e t t l e m e n t

profile

for

marketing

orders

PA transfer structure

10

i s

a s si g n ed

to

settlement

p r o f i l e Z1

i n

o ur

example .

In t h i s

settlement p r o f i l e , you have

defined that

you

want

to

settle

to


segments

nd

that when

you create a

settlement

r u l e ,

a p r o f i t a b i l i t y

segment

i s

proposed

as

settlement

receiver

.

The

marketing orders are created i n

t h e

moduleCO-OM-OPAas

internal orders f o r

order

t y p e

Z400.

F o r orders, a settlement p r o f i l e i s transferred

f r o m

t h e

order

t y p e

to t h e

settlement

r u l e .

The

internal order

t y p e

f o r

o ur

internal orders

i s

created with

Z400

(Figure

5.13).

©

Copyrigh t

SAPAG.

A l l

rights reserved.



Figure

5.13:

Order

t y p e Z400

Every internal

order

created

contains a

settlement r u l e ;

you

create t h e s e f r o m

t h e

maintenance

of

t h e master

data

via

t h e SETTLEMENT

RULE

button ( s e e Figure 5.14).

We

have

created

t h e

orders

400217, 400218,

and 400219

f o r

o ur

e x a m p le.

©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

5.14: Internal order 400217 with settlement

rule

The settlement

rule

also

def in es t h e

characteristics

that are

specified

with

t h i s

settlement

to

COPA




©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

5.15:

Characteristics in

settlement rule for

order

400217

F o r

t h e

p os ting

to

cost

element

478000

(Marketing

and

sales

costs),

t h e

internal o rders crea ted als o receiv e t he

account a s signmen t. This

i s

visible

i n t h e

reports f o r internal

order

accounting

( s e e

Figure

5.16).

©

Copyrigh t

SAPAG.

A l l

rights

reserved.

Figure

5.16:

Costs

visible

in

CO-OM-OPA

In

t h e

settlement

rules

f o r t h e internal

orders,

account



©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

5.19:

Drilldown

from

kind

of

product

t o

product

for

marketing

co s t s

Naturally t h e s e cost s

are

also

visible

contribution margin accounting

( s e e

Figure

5.20).

i n

an

overall



©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

5.20:

Actual

contribution margin

accounting

with marketing

c o s t s

You can also review internal order settlement

to

COPA

i n

t h e

video

b e l o w .



Video

4:

Valuation

via

material costing

Note:

Should

y our

reading device

no t be

able

to

show

t h i s

video,

you

can use y our computer

to

watch

i t on

t h e

internet.

To

do

t h i s ,

head

to

o ur

web

page

at


Now that I have

p re sen ted

t h e

settings

required

f o r

settlement, we w i l l look

at

t h e FI interface.

5.3 FI Interface

From a customizing

perspective,

t h e

FI interface works

i n

a

similar way

to

t h e

settlements

to COPA. You simply

use

t h e

PA transfer structure F I .

You need t h i s interface i f when

you p o s t

to an

FI

account

that

i s

also

created

as

a primary cost element, you specify a


segment

as

controllingrelevant

account

a s s i g n m e n t .

As

described

i n

Chapter 2.1,

your

accounting

colleagues may no t

be

your b e s t friends

when

i t

comes

to

t h e direct account assignment

of

a


segment

within

t h e

scope

of

manual postings

i n FI

t

means

additional

e f f o r t

f o r

y our

colleagues

and

appears laborious.

Any automatic

account

assignment

that

you may

have

cus tomized

i s

a ls o o nly

beneficial as

long

as t h i s

aut o m a tion

i s

no t

interrupted.

F or a cco un t

assignment

to

a


segment, companies

that

choose t h e

FI

interface to

p o s t

directly

to

COPA

w i l l a l m o s t certainly only specify

characteristics

that are at

a high,

a g g re g a t ed

l e v e l .

Seen

f r o m t h e o p p o si te

perspective,

t h i s

also

means that

value



f i e l d s

that

are

f i l l e d

by

t h e

FI

interface

can

no longer be

evaluated

i n

great

d e t a i l . This gives

us

l i t t l e

more

information

t h a n

we

already h a v e. Therefore,

f o r

o ur

e x a m p le, I

w i l l

no t

set up

an

FI

interface

to

COPA.

5.4 Cost

Center Assessments

I f you want

to

display your cost s that you

have

no t already

absorbed

i n

y our balance s h e e t

completely

i n

COPA,

within

t h e

scope

of

periodend closing, you can transfer

your costs

to COPA

as part

of an

actual assessment.

The

co m bina tio n

of

cost element/cost center

i s

t h e sender,

and p r o f i t a b i l i t y

segments

are

t h e

receivers.

An

assessment,

i n

contrast

to

a

d i s t r i b u t i o n , works with secondary cost elements. This

means that

t h e

original

v alues are also visible on

t h e

primary

cost

elements after

t h e

assessment.

F o r

an

actual cost

center

assessment, you

can

select

different tracing f act ors f o r t h e assessment: variable

portions, fixed portions,

p ercen tage

values,

o r

fixed

amounts.

The

more

detailed you

are

here,

t h e

greater

t h e

possible detail f o r

your

co s t e v alua tio n s l a t e r .

F o r o ur e x a m p le,

we

w i l l f i l l

t h e Fixed Costs

l i n e via

cost

center

assessment.

We

assume

that

fixed cost s

are

a s si g n ed

to

cost centers.

The

fixed cost s

are

therefore

present

i n

Cost Ce n t e r Acco un t in g (COOMCCA)

and are

to

be

reallocated

to

p r o f i t a b i l i t y segments

i n

COPA.

To

do

t h i s

you

have

to

create an

assessment cycle

( s e e

Figure

5.21).



©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

5.21: Path

for

assessment

of

cos t

centers

Execute

t h e

s t e p DEFINE STRUCTURE

OF

COST CENTER

ASSESSMENT/PROCESS

COST

ASSESSMENT

and

t h e n

c l i c k

CREATE ACTUAL

ASSESSMENT.

Once

you

have specified

an

assessment cycle including starting date,

by

pressing

ENTER,

you

navigate

to

t h e

header data

f o r

your

assessment cycle

( s e e Figure

5.22).



©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

5.22: Header data,

actual

assessment

cycle

In

o ur

example,

we

assume that t h e following cost centers

have

been

p o s t e d

to

account

476500 (Administration

Cost s),

which

i s

also

created

as

a

cost

element

of

t y p e

1

( prim ary co s t elem en t) ( s ee

Figure

5.23). From

t h i s

simple

da t a b a se,

we

now

want

to

build up

o ur

assessment cycle

segments.

©

Copyrigh t

SAPAG.

A l l

rights

reserved.

Figure

5.23:

Fixed

co s t s

at cost

center/cost

element level



You

use

an

assessment cycle

to

reallocate t h e cost s p o s t e d

to

t h e

combination cost center/cost

element

to

COPA.

In an

assessment cycle

you

create assessment cycle segments.

I f

you

want

to

allocate different senders

to

different

receivers using

an

assessment cycle, you

have

to

create

different segments.

In

t h e

f i r s t

segment

of t h e

cycle,

t h e

fixed costs

of t h e

sender

cost

center KS1 are

to

be

allocated

to

general

characteristics

of

t h e o perat ing concern Z111 and

t h e

characteristics

of

customer

K1

to

100% using

cost

element

476500.

In

t h e

second

segment, we

want

to

allocate t h e

sender

cost center

KS2

according

to

variable

portions

using

cost element 476500, specifically according

to

sales

quantities

actually recorded.

We

want

to cust o mize

t h e s e

segments.

Before

we

do

t h i s , we have

to

create two

assessment

cost

elements

of

t y p e

42.

This

i s

a

cost element that

i s

only valid

i n t h e Controlling module. Cost element t y p e 42 i s used f o r

assessments.

Wit h

an

assessment

cost

element,

t h e

primary cost s remain

visible

i n cost

center accounting;

credit

i s

via t h e

assessment cost element. The segment header

of

t h e

f i r s t

segment

i s as

shown

i n

Figure 5.24.



©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

5.24: Segment header, segment 1

Here I have a s si g n ed value f i e l d

VVFIX and entered t h e

ASSESSMENT COST ELEMENT

.

In t h e

p ar a m e t er s under

SENDER

VALUES I

define

that

t h e

t o t a l amount

of

t h e

co st s p o s t e d

to t h e

cost center i s

to be

passed o n. The

a pp o rtio nmen t

to

t h e

receivers

i s

based on fixed percentage

rates .

The senders and receivers

are set

up i n

accordance

with

t h e requirem e n t s ( s e e Figure 5.25).

Here

you

can

see that I

have entered

cost center KS1

as t h e sender

with

cost

element 476500 ;

i n

doing

s o,

I have determined

that

a l l

cost s p o s t e d

to

cost

center

KS1 under

t h i s

cost

element

are

to

be allocated.

I

have

entered

some

characteristic

values

as receiver, including customer

K1

.



©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

5.25: Senders/receivers

of

segment

1

Now

we

have

to

set

up

t h e

receiver

tracing

factor

( s e e

Figure

5.26). A receiver tracing factor

defines

t h e

distribution factors used

to

select

a

receiver, i . e . , how

much

of t h e assessment goes

to

t h e receiver.



©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

5.26:

Receiver

tracing

factor,

segment

1

Now we

s et

up

segment

2. F i r s t we

maintain t h e segment

header ( s e e Figure

5.27).

©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

5.27:

Segment header, segment 2

In

accordance with

t h e

requirements, assessment i s

to be



according

to

variable portions. Using a prede fined v alue

o r

quantity

f i e l d

as

tracing

factor,

t h e

sender

can

be

allocated

to t h e receiver.

F o r

example,

you want

to

distribute

according

to

actual

sales

quantities

of

t h e

period

to

be

closed. As

we

generally

do

no t

know how

t h e quantities

f a l l

i n

a

period when

we

define

t h e

assessment

cycle,

we

refer

to variable portions ls o because

t h e

segment can

be

applied

to

multiple periods.

In t h e

same

way as f o r

segment

1,

we now have

to

define

t h e senders/receivers, receiver tracing factor, and receiver

weighting factors

f o r

segment

2 ( s e e Figure 5.28).

©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

5.28: Sender/receiver

of segment

2



We

want

to

allocate f r o m

t h e

sender cost

center

KS2,

i n

combination

with

cost

element 476500,

to

products

A1

to

A5

and customers

K1

to

K6.

In

t h e

receiver tracing factor,

we

define

t h e

reference dates

used f o r

t h e

assessment.

Distribution

i s to

be according to p o s t e d actual order

quantities.

©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

5.29:

Receiver

tracing

factor, segment 2

Due

to

t h e

v aria ble po rt io n

r u l e ,

you now

also

have to

specify

t h e

receiver weighting factors. Using

t h e

tracing

factor,

COPA

proposes

a l l

possible

characteristic

combinations that you can weight:



©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

5.30:

Receiver

weig h ting

factors,

segment

2

Depending

on

how

many receivers

you

specify on

t h e

SENDERS/RECEIVERS tab, t h e

same number

of

receiver

weighting

factors

i s

created

f r o m

t h e

combination

of

t h e s e

receiver characteristic values. After saving, you can execute

t h e cycle

via

transaction

KEU5

( s e e

Figure 5.31).



©

Copyrigh t

SAP

AG.

A l l

rights

reserved.

Figure

5.31:

Execution

of

actual

assessment

cycle

Execute

a

test

run

of

t h e assessment according

to

Figure

5.31

and

look

at t h e

subsequent

lo g ( s e e

Figure 5.32).

©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

5.32:

Test run log,

CCA assessment

You

s h o u ld

a n a l y z e

t h e

senders, receivers,

errors,

and



segments b e f o re

t h e

update run. Now that

we

have

executed

t h e update run,

we

want

to

a n a l y z e t h e r e s u l t .

What has

happened

i n

Cost Ce n t e r Acco u n t in g ?

Let us

look

at a s t a ndard co s t cen t er report

( s e e

Figure

5.33).

©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

5.33: Assessment

cycle result in CCA

You

can see

that

t h e

primary cost s are visible

i n

Cost

Cen ter

Accounting

i n

t h e amount

of

EUR 30,000, b ut t he

cost centers

have

been completely credited. You can also

see

t h e s e

cost s

i n

COPA

i n

t h e

FIXED

COSTS

value

f i e l d


I f you

look

at t h e

fixed cost s

i n more

detail there, you w i l l see that

i n

accordance with t h e

distribution

requirements

f r o m

segment

2,

fixed cost s

have

also

been allocated to l o w e r level characteristics.



©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

5.34:

The

actual fixed

co s t s have

arrived

in

CO-PA

via

assessment

This

c o m p le t e s

t h e

section

on

settlement

and

we

w i l l

now

turn

to

t h e

l i n e

item

corrections.

5.5 Direct Line

Item

Corrections

in

COPA

People work with

t h e

SAP

s y s t e m .

People t end

to

make

mistakes f r o m

time

to

time.

When errors are made i n t h e

SAP

systemand

t h i s leads

to

incorrect

data

i n

COPA,

good

advice

i s

often

expensive.

As

already

sta ted

several

times,

COPA

i s t h e

f i n a l

point

i n

t h e

SAP

s y s t e m ,

and

therefore,

any

errors

made

up to

t h i s

point

s h o u ld

become visible

h e r e

at t h e

l a t e s t .

F o r any

errors

det ect ed, t h e following principle applies:

correction

at

t h e

source.

What

does that

mean?

I t

means

that

any

errors

detected

s h o u ld

always

be

corrected

i n

t h e

module

i n

which

t h e y

arose. F o r example,

i f

incorrect

amounts

o r

characteristics were transferred

f r o m SD,

t h e

incorrect SD document s h o u ld

be

reversed

and recreated.

The reversal document and t h e new document are



transferred

to

COPA, and everything

i s

as

i t s h ould

be

again. But what

i f i t

i s

no

lo nger po s sib le

to

perf o rm t h e

correction at t h e

source? This

could

be

t h e

case

i f

t h e

customer b i l l i n g document has already been

sent,

o r

t h e

periodend closing has been completed

b e f o re

t h e error i s

detected

(or any

o t her

reason

that

makes

a

correction

at

t h e

source impossible

o r

only

possible

with

an

enormous

amount

of

e f f o r t ) ,

f o r

example.

One solution can

be to

correct

t h e l i n e

item directly

i n

COPA.

Some

of

you w i l l

now

s h o u t o ut that you can present

t h e

figures

i n

COPA any

way

you

w a n t .

In

t heory

t h i s would

perhaps

be

possible

i f

you have

mastered

some

security

measures

as

part

of

t h e customizing settings, b ut

i n my

opinion,

i s

i t

i s

no t

possible f r o m a practical

perspective.

In

principle,

SAP

has

planned

a data inconsistency

as

part

of COPA:

i n

a

l i v e s y s t e m , deletion of

p o s t e d actual

data

l i n e items f r o m COPA

i s

no t allo w ed. Wit hin t he

scope

of

l i v e

starting

preparations,

you can s t i l l

do t h i s at an

a g g re g a t ed

l e v e l ,

b ut

at

t h e

latest

when

you

go

l i v e

i t

i s

no

longer possible.

You

can

always

enter

data

i n

COPA, but

you can n e v e r

change or delete

i t

You

cann ot

change i t ? Then

how are

you

supposed

to

perf o rm corrections

i n

COPA? You

can

only create corrections

i n

COPA by recording

data i n

CO

PA.

5.5.1

Types o f

Errors

and

How

t o Correct

Them

There are

two

t y p e s

of

errors that can

arise

i n

COPA:

Incorrect characteristics or

characteristic

derivations

Incorrect

data

transfer

o r

incorrect

valuations

Let us

look

at

t h e

f i r s t

t y p e

of

error:

characteristics or

characteristic

derivations

are

incorrect. Incorrect What

an

awful w ord.

Sometimes, characteristic values

have

been

defined

as t h e y

were

“uptodate”

at

t h e

time

of

t h e



derivation; at t h e current point

i n time,

t h e y appear o b s o l e t e

and

incorrect. Here

too,

you

have

to

decide whether

an

error

occurred

at

t h e time

of

t h e

transfer and derivation,

o r

whether

t h i s i s

some t y p e of t e m p o r a r y view.

I

do

no t

l i k e

correcting

characteristic

derivations

that

were

once valid retrospectively, perhaps also f o r t h e period

i n

which

t h e y

were

v a l i d . What

does t h i s mean?

This

i s

b e s t

explained

with t h e

example

of t h e

customer hierarchies:

when

t h e

invoice was created, a customer was a s si g n ed

to

customer hierarchy KH1.

At

some point,

t h e

customer was

s old

to

a n o t h e r customer

hierarchy

KH2. F o r

t h e

assessment

of

customer

hierarchy

KH2,

f o r

management

reasons

i t may

be useful

to

change t h e original


of

t h e customer f o r t h e original

invoice

to

KH2

so

t h a t , f o r example,

t h i s

data

i s

available

f o r

planning.

However,

i f we

did

t h i s ,

incorrect

information

would

be

reported

f o r

t h e

lev el of

sales

that

was

achieved

with

customer

hierarchy KH1

i n t h e

period

i n

which

t h e

invoice

was created.

Therefore,

you

s h o u ld

make

sure

that

you

do

no t perf o rm

t h i s

t y p e

of

backwards assignment

change

i n

your

ERP

s y s t e m .

You

may be able

to

do

t h i s

i n

y our

management information s y s t e m , which you

may

have

connected

to t h e

SAP

s y s t e m , b ut no t

i n

your ERP s y s t e m .

Back

to

error t y p e 1:

i f

characteristics

o r

characteristic

derivations

have

been

transferred

to

COPA, b ut

at t h e time

of

t h e

transfer

they

were

different

i n

r e a l i t y

b ut

can

no

longer

be

corrected

at

t h e source,

t h e y

have

to be

corrected

by

means

of

data entry

i n

COPA.

You

can

enter

actual

l i n e

items

i n

COPA

with

transaction

KE21

(or

KE21N). F o r

t h e

correction, you have

to

create two data

records:

t h e

f i r s t

data

record

contains

a l l

characteristic values specified

i n t h e

original

document. A l l

specified values

i n

t h e value

f i e l d s are

entered

with

reversed

leading

signs

( t h i s

i s

t h e

same

result

as

you

would achieve

by

rev ers ing t he document

at

t h e

source).

The

second

data

record

contains

new

and

corrected characteristic

values

as well

as a l l

values

i n

t h e

value

f i e l d s that

were

created

i n t h e

original document.



Error t y p e

2:

incorrect

data

was

transferred.

I f

t h i s

data

i s

also

important

f o r

o t her

m odules, you

w i l l

pr o ba bl y no t

be

able

to

av oid making

a

correction

at t h e

source

o r

would

have

to also

make

corrections

i n

t h e s e o t her modules.

However,

l e t

us

assume

that an

evaluation

of

y our

costing

based

COPA data

was

incorrect: you

could

t h e n

use direct

data

entry

i n

COPA

(transaction KE21

or KE21N)

to

correct

t h i s inconsistency o r t h e same characteristic values

that

you

specified

i n t h e

source,

you

enter t h e

delta

to

t h e

correct

value of

a

value f i e l d and enter

zero

i n

t h e remaining

value f i e l d s . This sounds more complicated

t h a n

i t

i s :

i n

a

l i n e

item,

you

have

entered cash discount

of EUR

10, b ut

i t

s h ould

have

been

EUR

12.

Fo r

t h e

same

characteristic

values

as

i n t h e

original document,

i n t h e

cash discount

value f i e l d

you

enter

a delta amount

of EUR

2. You

do

no t

make

any

entries

i n t h e

remaining

quantity

and

value

f i e l d s

and

they

are

f i l l e d with z e r o s when

t h i s l i n e item i s

po sted.

In t h e even t

of

a

combination of error

t y p e 1

and

error

t y p e

2, you have

to

apply

a

combination

of

b o t h

correction

methods

. e . ,

you

have

to

correct errors f r o m

incorrect

characteristic

values

and t h e n correct

incorrect values.

5.5.2 Security Measures

In t h e COPA information

system

you

can

also define l i n e

item

layouts.

After

entering

a

l i n e

item

correction

directly

i n

COPA,

you

s h o u ld

always

check that everything was

entered

correctly

by reading

y our

l i n e items and t h e related

l i n e item layout.

F o r

example, t h e t o t a l of

t h e

value f i e l d s

i n

t h e correction l i n e items

s h ould

b alance

to

zero

i f

you

have

processed

error

t y p e 1.

I f you want

to

perf o rm actual

l i n e

item corrections

directly

i n

COPA,

I

also

recommend

defining

and

using

a

separa t e

record type.

You

can

create a

new

record t y p e

i n

customizing

f o r

COPA

via t h e p a t h

shown

i n

Figure

5.35.



©

Copyrigh t

SAPAG.

A l l

rights

reserved.

Figure

5.35:

Defining y ou r

own

record

t y p e s

in CO-PA

Any reco rd t ypes

that

you

define

can

have

a

number

between 0 and 9; l e t t e r s are

reserved

exclusively

f o r

SAP.

You

t h e n

have

t h e

option

of

displaying exactly what you

have changed

i n

evaluations.

I f

necessary,

you can

show

an

auditor

exactly

what

was

changed

at

t h e

touch

of

a

button

5.5.3

Simplifications

in

Line

I t e m

Corrections

Once

errors have

been detected

i n

COPA,

i t

i s

usually no t

s u f f i c i e n t

to

simply enter

a

few

data

records.

Depending

on

t h e

size

of

t h e

original

document

and

how

long

t h e

error

was

undiscovered,

up

to

several

hundred

data

records

may

be

affected.

I f

you

now give

someone

i n

your

company t h e

t a sk

of

correcting t h e

data

records

as

described a b o v e , you

w i l l make

t h i s person

very unhappy.



To p er f o r m mass corrections,

use

a b a tc h input p r o g r a m , f o r

e x a m p le. Define

l i n e

item

layouts that e n a b l e you

to

present

a l l

characteristics

and

value

f i e l d s

one

after t h e

other.

I

w i l l

explain how

to

define

l i n e

item layouts

i n

Section 7.4.

One

layout w i l l

often

be

i n s u f f i c i e n t ; you s h ould use t h e

COPA

document

number

as

lead

column

f o r

t h e

layouts.

Exp or t

incorrect documents

f r o m

COPA

(transaction

KE24)

and

run a download

to

Excel

f o r each

layout.

In

theory, you

would

have

to

l i n k t h e

layouts with one a n o t h e r

i n

Excel

via

VLOOKUP

using t h e document number, b ut t he downloads

are usually arran ged and s orted correctly (but you s h o u ld

check t h i s ) .

Now have

y our consultant, developer,

o r

colleague

who

knows how

to

program batch input programs

using

ABAP

write

a

program f o r transaction KE21. The value

and

data

length

of t h e

characteristics

and

value

f i e l d s s h ould

be

defined precisely

i n

advance. Prepare

t h e

Excel

columns

of

y our

downloaded

data accordingly

and

maintain

t h e

data

reco rds creat ed

automatically

i n

COPA

using

y our

p r o g r a m .

In

t h i s

chapter

I

have

now

explained

how

to

include actual

values and actual quantities

i n

COPA.

In

t h e next

chapter,

we

w i l l

look

at

how that

works

with

planned values

and

planned quantities.



year,

and

n o t

only

a

sales quantity planning, b ut also planning

right down to

t h e contribution

margin. We w i l l also p e r f o r m

this

planning no t

only

at

a

high,

aggregated

level

( e . g . , company

code o r sales

area);

for

each individual cus tomer,

we w i l l

plan

with

t h o s e products that

you

believe

y our

customer w i l l

purchase

ne x t

year.

We

w i l l

plan

a l l

customerspecific

and

productspecific

characteristics

as

well. We w i l l also consider

individual monthly distributions. We w i l l assume an overall

planning process of a ppr o xi ma te l y

four

weeks.

How are

we

supposed to do a l l of that in such

a

s hor t time?

Including

an

adjus tmen t phase? You w i l l

be

amazed...

6.1

Shortening

the

Planning

Process

without

Losing

Quality

Your management w i l l o f ten t e l l

you

that you only

have

a

few

weeks for planning,

and that t h e

results

of t h e planning

(that

i s ,

t h e

quality

of y our

w o rk,

n o t t h e

planned

operating

p r o f i t

that

management wants to achie ve for ne x t year) s h ou ld be at least

as

good

as

t h e

previous

year,

b ut

preferably

even

better

t h a n

last year.

How can you s h o r t e n t h e

planning process?

In principle, you

would enter sales

quantities for

t h e

periods

to be planned and

valuate t h e s e

with

prices,

conditions, and cost

rates. You

would

t h e n

consider

t h e result, and

in

a frequently recurring

pr oce s s,

would change

details

such

as

sales quantities,

prices,

conditions,

o r

cost

rates

u n t i l

a

desired

o r

practical

result

i s

achieved. There i s

no

way

of

s hortening

t h e

pr oce s s, i s

t here?

Of

course t here i s

6.1.1

Reducing

the

Planning Effort ip1

I n i t i a l l y , management i s interested in t h e pos sible operating

p r o f i t for

t h e planning

year.

How t h e

p r o f i t i s

spread

o v e r

t h e

individual months of t h e planning y e a r

i s

i n i t i a l l y irrelevant. This

i s t h e f i r s t approach that

you

use to s h o r t e n y our planning

process: you

plan y our

entire year’s planning in

one plan period,

i . e . ,

one planning month. You can spread i t o v e r t h e months of

t h e y e a r l a t e r .



6.1.2

Reducing

the

Planning

Effort

ip

2

Ent erin g t h e

planned prices,

planning conditions, and planned

cost

rates

that you

want

to use to

valuate

t h e

planned

sales

quantities involves

a

great

deal

of w o rk. Many

people

do this

work

b e f o re

management

giv es t h e

goahead

for

planning,

especially i f planning i s to be done on

characteristics

such as

customer

or

product. Why

no t

use

prices,

conditions, and cost

rates that

are already

in t h e

s y s t e m ,

i . e . , actual

prices,

conditions, and cost rates valid now? Then you would

only

have

to enter planned sales quantities and valuate t h e s e

with t h e

actual

prices

to get y our f i r s t

result. You

can t h e n make specific

changes to

t h e

existing planning where sales quantities have to

be adapted,

or

where higher prices, conditions,

or

co s t s are

anticipated (or

feared) u n t i l

you get t h e result that management

w a n t s .

6.1.3

Reducing

the

Planning Effort ip3

You

can

als o save time when entering

t h e

planned sales

quantities.

Usually,

t h e sales

and

distribution

department

o r

key

account management w i l l plan t h e

planned

quantities. I f you

are

t h e

sales controller responsible, t h e y w i l l ask

you

for historical

values for p a s t

sales

in order

to

plan, where applicable,

t h e

sales quantities

for

respective

key

accounts on t h e b as is of

specific product

groups

( i d e a l l y ,

specific products). I t i s up to

you how you

provide

t h e s e

historical values.

Many companies

use

Microsoft

Excel;

others

use

various

management

information

s y s t e m s , CRMs y s t e m s ,

etc.

Let us assume

you use

Microsoft

Excel and

als o receiv e

t h e

data

from y our

sales

colleagues via

Microsoft

Excel. I f

I

were

y ou,

I

would t h e n use

t h e historical values ( e . g . , t h e previous r o l l i n g year) to

download

t h e

sales quantities for

specific

customers

and products to

Excel

and

als o

transfer

o t h er

characteristics such

as key

account o r

product group. Using

a

pivot table (controllers w i l l know what

I

mean),

put

t o g e t h er

t h e s ales

quantities

for

each

customer

hierarchy

and

product

group

at

customer/product

level.

Now use

VLOOKUP to a s si gn t h e planned quantities from y ou r

colleagues.



Using

a

manual planning layout defined in

COPA,

ideally you

import

t h e

planned quantities for

t h e

specific customers and

products

via

b a tch input program.

As a

result of t h e

characteristic

derivations that you have s et up

for

customers

and products, a l l

relevant

characteristics

are

derived, meaning

that

you see

a l l

planned

quantities on

a l l

pos sible

characteristics.

I t

i s easier

to

explain t h e

last planning

t i p

with an

example:

Your key account managers give

you t h e

planned quantities

that

you

see in

Table

6.1:

Cust.hier.lev.1

Kind o f

roduct

Pl a n.

ty

Cust.hier.lev.1 Kind o f

roduct P lan.

qty

KH11

PA1

140nits

KH12 PA1

30

units

PA2

50

nits

PA2

30

units

Table 6.1:

Example

f o r p l an n ed quantities

From t h e

r o l l i n g

y e a r ( e . g . , period 10 of t h e previous y e a r up to

period

9

of

t h e

current

year),

you

have downloaded

t h e

quantities shown in

Table

6.2 from t h e actual

data:

KHb1

Kind

o f

roduct CustomerProductActualquantity

KH11

PA1

K1 A1

10

KH11

PA1

K1 A5 15

KH11

PA2

K1 A3

20

KH12

PA2

K2 A2 10

KH12

PA1

K2 A4

5

KH11

PA1

K3 A1

30

KH11

PA1

K3 A5 25

KH12

PA1

K4 A1 10



KH12

PA1

K4 A4 25

KH11

PA2

K5 A2 40

KH11

PA2

K5 A3

5

KH11

PA2

K6 A3

10

KH11

PA2

K6 A2 15

Table 6.2: Actual

data

of t h e r o l l i n g

f i s c a l year

As

a

pivot table, this corresponds to t h e values that you can see

in Table 6.3.

Cust.hier.lev.1

Kind o f

roduct

Act.

ty

Cust.hier.lev.1 Kind o f

roduct

Act.

qty

KH11

PA1

80nits

KH12

PA1

40

units

PA2

90nits

PA2

10

units

Table 6.3:

Pivot

table f o r t h e

actual

data of t h e r o l l i n g f i s c a l

year

Therefore,

according

to Table

6.1,

we

want

to plan

a

t o t a l of

250

units. In accordance with t h e r o l l i n g

year,

this planned quantity

i s to be distributed proportionately to

t h e

corre s p onding

customers and products. You

can do this using t h e

rule

of

three.

This

results

in t h e following planned quantities ( s e e

Table

6.4)

at customer/product level proportionately according to

t h e

r o l l i n g

year.

Customer Product

Planned

quantity

K1 A1 17

K1 A5 26

K1 A3 11

K2 A2 30

K2 A4

4

K3 A1 53



K3 A5

44

K4 A1

8

K4 A4

18

K5 A2

22

K5 A3

3

K6 A3

6

K6 A2

8

Table 6.4: Proportionate planning based on actual

data

6.2

Fast Yearly

Planning

in D et a il

In

this

section,

I

w i l l

f i r s t describe t h e

further

procedure

b e f o re

providing you with

t h e

technical

details

from Section 6.5

onwards.

6.2.1

Recording

Yearly Planned Quantities

The

tips f or

reducing t h e

work involved in planning sound great,

b ut how do t h e y

work

in

detail?

According

to t i p 3, you import

t h e

calculated planned sales quantities

into

a

previously

created

manual planning layout via transaction

KE11,

and, in

accordance with

t i p

1, into

a

planning period, e.g., 010.20CY

(CY s t a n d s for current

year),

with

t h e

plan version XYY

(yearly

plan

version)

that

you

have

als o

created

in

advance. For

each

com bination of

customer/product,

t h e b a tc h input program

imports

t h e planned quantity and saves each

entry

as

a

planning line

item

in

COPA. As

you

learned in Chapter

3, a l l

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 o ur

example, customer

group, sales

employee,

kind

of

product,

and

product

group.

For example,

in

t h e

characteristic

sales

employee

V1

you w i l l

see a l l planned

quantities

for

customers 1, 2, 4, and 6, i . e . , in t o t a l 139 units.

6.2.2

Valuation o f Planned

Sales

Quantities



Now we w i l l look at t i p

2

for

reducing

t h e planning e f f o r t : we

valuate

t h e

planned sales quantities recorded with

t h e actual

prices and conditions that

are a lrea dy def in ed

in y our

SAP

s y s t e m .

The planned sales quantities are

located

in plan version

XYY in planning

period 010.20CY.

As

you

are in

t h e

current

year,

i t

i s

very

p r o b a b l e

that

a l l

prices

and

conditions

are

available:

from a

logical perspective, we are doing n o t hi n g more

t h a n

pretending

to invoice y ou r planned quantities.

Remembering

Section

4.1.1, create

a

v aluat io n s trat egy

containing t h e

pricing

procedure defined

for

actual invoicing in

SD.

Then,

in

t h e

same way as for actual figures, add

a

valuation

of y our

current

material

costing. Assign this

valuation

strategy

to

t h e points of

valuation

03

(manual

planning) and 04 (automatic

planning) in com bination

with y our

plan version

XYY.

Using

t h e

o ld COPA

planning

transaction

KE1B

(Change

Automatic

Planning),

which i s thankfully s t i l l available in t h e new

SAP

releases, you

can

valuate

y our

recorded planned sales

quantities completely.

In just

a

few

s tep s, you

have

valuated

y ou r planned sales quantities

specifically, right down to

contribution

margin

1

in

accordance

with

o ur example

contribution

margin

structure.

The

valuations

are

also

visible

on

a l l derived characteristics.

Condition types t h a t

are not

characteristics

In SD, access sequences

are used

to

find

t h e

valid

condition

record

for

each

condition t y p e

defined

in

t h e

SD

pricing

procedure. But what happens

i f

t h e

access sequences

contain

fields

for condition record

determination

that

are

n o t

als o

characteristics

in

y our

operating

concern?

I f that

i s

t h e case, t h e

condition

record for t h e valuation of y ou r planned sales

quantities i s

n ot f o un d.



You

may

ask why

I

am t e l l i n g you about this fast planning i f

t here

i s

no

certainty

that, as indicated by

t h e n o t e

above, a l l

valid condition records

w i l l be found

for

t h e planning valuation.

Here too,

SAP

has

provided a

solution using

a

special

planning

user e x i t . You use this user exit to t e l l COPA

about

fields that

are

in

t h e

SD access

sequences

b ut

that

are

no t

characteristics

in y our operating

concern so that

COPA

finds t h e valid

planning condition records.

For b o t h actual order entry

and

actual invoicing in

SD,

i t i s o f ten

t h e

case that some

a ct ua l p rices o r a ct ua l

condition records are

defined at t h e l o w e s t

level,

that i s , at t h e level of

customer/product. To

provide

assurance for y our planning

valuation

that

t h e

SAP

system

has

found

a l l

pos sible

and

valid

condition records,

you

have

to

trigger

t h e planning valuation at

this l o w e s t

level.

As

I

w i l l

show

you in t h e

example,

with

transaction

KE1B

this i s n o t

a

pr ob lem.

6.2.3

Adjustment

Phase

Once

you

have

p r e s e n t ed

y ou r

management

with

a

f i r s t

planning

result,

t h e

adjus tmen t phase starts: quantities,

prices,

conditions, cost rates, and possibly a ls o in no v at io n s

or

product

changes are discussed. Some

companies

save

t h e respective

planning s t a g e in

a

s e p a r a t e

version

b e f o re making any

changes so that t h e y

can

make t h e changes in t h e adjus tmen t

phase v i s i b l e . The

o ld

COPA

planning transaction

KE1A (Copy

Automatic

P lan ning

D a t a )

w i l l

h elp

you here. You can use i t to

copy

a l l

o r

parts

of

a

planning.

Let

us return

to t h e adjus tmen t phase: i f y our management

asks

y ou, for example, to increase

y our

entire sales

quantity

planning

by

x%, t here

i s

no need to

panic.

You

can use t h e

revaluation

key

tool available to make t h e s e changes. You define

revaluation keys

with t h e

(old and new) transaction

KE1F.

In

a

revaluation

key, you

define

which

quantity

or

value

f i e l d

you

want

to change

by

x%.

For

au t o ma tic

planning

via

KE1B,

you

als o specify

t h e

characteristics

(or even

characteristic

values)

for which

you

want

to

make

this

planning

change. I f you wis h,

you

can

execute planning changes at

high, aggregated

levels

( a l l underlying characteristics are als o co ns idered) , o r on



individual characteristics such as customer or

product.

I t a l l

depends

on t h e

management

requirements.

You can now proceed to

valuate

t h e revalued quantities in

accordance with y our

valuation strategy,

and

in

just

a

s hor t

time

you

have

a

new planning result that

you

can

pre sen t

to

management.

When changing planned sales

quantities, you can

als o use

a

mathematical effect: i f you change y ou r

planned

quantity

by

x%,

provided you do

no t

change

prices

and conditions at

t h e

same

time,

t h e

sales qua n t it y de p en de n t v a lue

fields

w i l l

also change

by

x%. For y our planning, this means that you could

als o

consider

this

effect

when defining

y ou r revaluation key by

considering

no t

only t h e quantity f i e l d b ut also a l l sales

quantity

dependent value

f i e l d s ,

and

as signing

factor x to a l l

f i e l d s .

In

one s t e p in automatic planning,

you

can t hus

n o t

only

increase

t h e planned sales quantity

by

x%, b ut

als o

a l l

dependent

value

f i e l d s .

And y our new planning result i s ready....

When you

change

prices

o r conditions,

t h e

situation

i s

a

l i t t l

more

d i f f i c u l t b ut t h e principle

i s

similar: i f you

are

planning,

for

example, price increases,

revaluate

t h e

value f i e l d

GROSS

SALES

accordingly.

You

may now

wonder what happens

with

t h e value fields that

are,

for example,

dependent on t h e g r o s s

sales based on percentages? They als o have to be adjusted,

don’t

t h e y ?

You are

right

again.

I f

this adjus tmen t

cannot be

calculated due to t h e complexity o r

for

o t h er r e a s o n s ,

we

have

to use a n o t h e r t r i c k : in

SD,

copy

t h e

actual

SD

pricing

procedure

used so

far in

t h e

v alua tio n s t ra teg y

into

a

new

pricing

procedure

that you

want

to use only for y our planning

valuation (to be on

t h e

s a f e side, coordinate this

with y ou r

SD

colleagues so that t here

are

no

ar gume nt s ).

In

y ou r own pricing

procedure,

integrate separate,

s t a t i s t i c a l condition

t y p e s

that

contain,

for example,

t h e

g r o s s

price

increase. Include this

new

pricing

procedure

in y ou r valuation

strategy

and

valuate

y our

planned quantities again using

KE1B.

With

some

planning

changes

requested

by management, even

t h e b e s t system w i l l no t

help

you i f you have no t t h o u g h t about i t

in advance and done some

preparatory

w o rk. Innovation s

require,

for example,

new product numbers, new

product



costings (with

corresponding

b i l l s of material and

work

plan

prerequisites), new

prices,

and new

conditions.

These

w i l l

p r o b a b l y n o t be available y et in period 010.20CY and

so

t h e y

have to be created.

At

some point, management

i s

satisfied with

y ou r sales

quantity

planning

and

t h e

resulting

valuations and t h e adjus tmen t phase

i s i n i t i a l l y complete for

you.

6.3 Planned Cost

Center Assessments

Up

to

this

point in y ou r p lan nin g p ro ces s , you have

no t

considered planned

co s t s that are

independent of

t h e s ales

quantity.

This t y p e

of

planned

cost

i s

usually

planned

i n i t i a l l y

in

o t h er CO modules such as cost center accounting

or

internal

order

accounting. Th is plan ning

can

and

p r o b a b l y

w i l l be

executed

in parallel with y o ur a dj us t m en t phase. At some point

t h e s e fixed co s t s are als o planned.

They

are

t h e n

allocated to

COPA

using

a

planned assessment cycle.

The principle

i s

t h e

same

as for t h e

actual co s t s assessments described in Section

5.4.

6.4

Distributing

the

Planning

over

Months

After a l l of t h e s e explanation s

about

planning,

you

are perhaps

now

right

to

s a y ,

that

i s

a l l well and good

b ut

t h e entire planning

for

next y e a r i s

currently

in one month, specifically, in t h e

current

y e a r

in

period

010.20CY.

We are planning for

t h e

entire

ne x t

year,

so therefore

I

need

planning data

for

months

001

to

012

for

ne x t year, e.g.,

001.20PY

to 012.20PY

(PY =

planning

year).

Howdo

I

get t h a t?

Normally,

you use distribution

keys

to

specify

t h e

distribution

to

precise months. Caution: i f

you

want to

create

planning data in

COPA

using

distribution keys,

t he perio d

for planning must

match t h e p erio d in

t h e

distribution key. What does that mean?

At

t h e

moment o ur planning i s in one

period—010.20CY—and

we want to

distribute

i t to months

001.20PY

to

012.20PY.

The

two

periods

do no t match. The sender has one

period,

and t h e

receiver

12

periods.

This

means

that we

can

forget

about

using

distribution keys

here



But

how can we

s o l v e o ur

problem?

Again, I

have

a

t i p for

you:

use t h e

o ld

COPA

transaction

KE1A (Copy Automatic

Planning).

At t h e same time,

work

with

revaluation

keys ( y o u

know t hese: transaction KE1F). Now copy y ou r

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

y our

yearly

planning in January . D ef in e

a

revaluation key

of

90%

for

January

for

a l l planned

quantity and

value

fields

and t h e n ap pl y this

revaluation

key to y ou r

copy

planning:

t h e result

i s that in January you have only 10 of y ou r

planning.

Repeat

t h e s e

s t e p s

for

t h e o t h er 11 planning

periods

and you w i l l have y our yearly planning distributed o v e r planning

months.

I t ’ s

simple

But what happens when management

requirements

are

no t so

easy?

I t

i s o f te n

t h e

case that

t h e

s maller

t h e

company,

t h e

more complicated

and t hus

more

d i f f i c u l t t h e

requirements are.

Then

you have to

break

down t h e

revaluation

keys

o r t h e

planning copies to l o w e r level characteristics. And i f

you

want

to do this

quickly?

In

a

w o r s t case scenario,

in

which

customer/product

com bination s

have to

be

distributed

individually,

you

w i l l

s t i l l

be distributing

when t h e

planning

y e a r

i s

over

Again,

no

need for

panic: t here

i s

always

more

t h a n one

way to do s o m e t h i n g . Using

Micro s of t Ex cel,

for example,

prep are

t h e

planning

s tep s,

write

a

b a tch input program for

transaction

KE1A,

and

have

t h e

program

create

t h e

distributions

automatically.

You’ll be finished

quicker

t h a n you think.

You

may

have

someone

in

y our

company

who

knows

a l l

about

b a tc h

input. Using t h e relevant

recorder,

you can

record

t h e

s t e p s that you would have executed for each

distribution

process.

You

convert

this

record

entry

into

ABAP

coding in

t h e

b a tc h input

framework

created by

y ou r colleague, and you

would already be ab le to

use t h e

b a tc h input program.

Regardless of whether you have

executed

t h e distribution

manually

or

automatically,

at

t h e

end,

t h e

plan

version

with

t h e

monthly

distribution

( he r e XYM) must contain

t h e same

overall

result

as

y our

yearly

plan

version

XYY.

I

w i l l show you

how to view

t h e planning

data

in

Chapter 7.



6.5 Planning Our SAP

Example

Now that you have had t h e pleasure of

my theoretical

planning

approach in

Sections

6.1 t o 6.4, in this section

I

w i l l describe

t h e

technical

details of how to implement

t h e

planning approach

I

may

also

excite

y ou r

imagination

f u r t h e r . . .

6.5.1

Plan

Version

and

Planning Valuation Strategy

Below,

I

w i l l use t h e example to

show

how you can execute

y ou r

yearly

planning.

F i r s t l y ,

some

preparations

are necessary

as

shown

in

Figure 6.1.

©Copyright

SAP

AG. All

rights re ser ved.

Figure

6.1:

COPA planning

Implementa tion

Guide

On

one

hand

you

have

to

define

number ranges that

w i l l receive

y ou r

planning

line

items

for

t h e

planning.

You

also have to define

a

plan version. You

can

usually define

an entire planning in one plan version. I f

you

use several

plan

versions, you

can

compare

several

plans.



For o ur

example,

we are us in g plan

version

Z01

( s e e

Figure

6.2).

©CopyrightSAPAG. All rights re ser ved.

Figure

6.2:

P l a n

version

Z01

The

DERIVATION DATE

in this plan

version

i s

important. I t

determines

t h e date

on which further

characteristics

in y ou r

planning

are derived.

In t h e

example,

characteristics

such as

customer

hierarchy

are derived on 06/15/2012 even i f you enter

planning

data

in July

2012,

for example.

Bef ore

you

enter

planning

data

in t his

plan

version,

you

s h ou ld

define

a

planning valuation

strategy

for

y our

planning ( s e e

Figure 6.3) and

a s si gn i t

to points of

valuation

03 and 04

in

connection with

record

t y p e

F


I

have

already

explained what

a

valuation

strategy

i s in detail in

t h e

“Valuation”

section

of this b o ok .




Figure

6.3: Planning valuation

strategy

©Copyright

SAP

AG. All

rights re ser ved.

Figure

6.4:

Assignment

of t h e planning

valuation

strategy

I f we look at t h e planning

v a lua tio n s t r at e gy in Figure

6.3

more

closely, we can see in t h e COSTG

SH

( = pricing procedure)

column that in s t e p

10,

we want to access o ur actual SD pricing

procedure

ZEIF01.

Material costing t h e n

runs in

s t e p

20, and

f i n a l l y ,

we

have user exit U02, w hich, in t h e same

way as for

actual

figures, calculates

t h e

alternative

quantity

for

t h e

planning. You

can

l o ok

at t h e

details

again

at

y our

leisure in

t h e

“Valuation”

chapter.

6.5.2

User

Exit

f o r

Planning

Valuation

You are w orking in

t h e

same project as described in

Section

4.1.3.

You are

also using

component COPA0002.

In

this

component, doubleclick

EXIT_SAPL_KEAB_002

and

n a vigat e



to t h e include

ZXKKEU04.

This

user exit i s intended by

SAP

for

y ou r planning valuation. Now

you can

i n s t a l l

y our

coding

( s e e

Figure 6.5).


Figure

6.5:

P l an n in g us e r

e x i t

6.5.3

Manual Planning

Layout

You

create

a

manual

planning

layout

for

t h e following r e a s o n s :

on one hand to be ab le to enter t h e planned quantities at

customer/product level in

accordance with

Section 6.1.3, and on

t h e

o t h er

hand to have

a

tool that you can

use

to

check

y our

characteristic

derivation and

valuation

in

t h e

shortterm.

A

planning

layout

i s an individually designed planning screen that

you

can use

to

enter planning

data

manually.

The

planning

layout s h ou ld run at point of

valuation

03

(manual

planning) in

com bination

with

r eco rd t y p e

F

and plan version Z01.

You create

a

manual planning layout via t h e

COPA

Im plemen ta tion

Guide

under

PLANNING

•

MANUAL ENTRY OF

PLANNING

DATA

• DEFINE

PLANNING

LAYOUT.

In

t h e

example,

I

have created t h e

layout

Plan GP. Our planning

layout

looks as

shown below


Similarly

to Report

Painter

reports, this layout also has t hree main components: lines ( f o r

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 re ser ved.

Figure

6.6:

Planning layout, Plan GP

Use y ou r value fields as lines. You define

a

line by double

clicking

a

dot.

Now

you can

select

VALUE

FIELD

WITH

CHARACTERISTICS

as

t h e element t y p e

( s e e

Figure 6.7).


Figure

6.7: Definition of

lines

I

Then select

t h e corresponding value f i e l d and, i f applicable,



r e s t r i c t

further

characteristics (here, r e s t r i c t means: select via

characteristics).

In

o ur layout,

we

have

only

selected value

fields for

t h e

lines

and have n o t

restricted

any

further

characteristics

in t h e lines ( s e e

Figure

6.8).


Figure 6.8: Definition of revenue l i n e

You

define

t h e

Planning

Data

column

by

doubleclicking

t h e

dotted

line and

selecting t h e characteristics to be

applicable for

this column

( as

p er Figure 6.9).



©Copyright

SAP

AG. All rights re ser ved.

Figure

6.9: Definition

of t h e “Planning

D a t a ” column

In

o ur example, we

r e s t r i c t

using

t h e

following

characteristics:

planned/actual

indicator,

record

type,

and

plan

version. The

column in t h e planning layout

s h ou ld

only

take

planning data

for

re co rd t y p e

F

in com bination with plan

version

Z01.

For

COPA

to

know

how you want to distribute

y ou r

planning

values o v e r

several

periods (where

applicable),

you have to

define

a

distribution

column

in t h e

planning layout when you

define t h e planning column.

You include

t h e

distribution

column

via

E D I T

•

COLUMNS

•

APPEND

ADD.

FIELDS

and

t h e n selecting t h e

DISTRIBUTION

KEY

f i e l d

offered by

SAP.

Using this

column,

when you enter t h e

planning values, you can define whether

you

want to

distribute

o v e r t h e p er io ds e v e nl y

o r

in some

o t h er

way.

When

you

define

t h e

planning layout,

via

E D I T

•

GEN. DATA

SELECTION

•

GEN.

DATA

SELECTION

you can

define

t h e

general

selections in accordance with

Figure

6.10: t h e general

selections define

t h e

characteristics

that

you see when

you c a l l

up

y ou r planning

layout and

n a vigat e

to t h e f i r s t selection

screen.



©Copyright

SAP

AG. All

rights re ser ved.

Figure 6.10: Planning layout general selections

On

t h e selection

screen,

we want to be able

to select

t h e

variables period/year,

cus tomer,

and

product. As

t h e

pos sible

characteristic

values

for

plant (ET11), sales organization

(ET15),

distribution

channel

(01),

and

division

(00)

are

always

identical

for

a l l planning

values,

you

can define them as

fixed in

t h e general selections.

We

can see

t h e

result of t h e general

selections when

we access t h e

planning layout via transaction

KE11

and navigate to t h e selection

screen

( s e e

Figure

6.11).

Save

y ou r

planning

layout.




Figure 6.11:

KE11

selection

screen

f o r

o ur planning layout

You can now use

transaction

KE11

to enter planning data in t h e

layout. A l l you have to do i s choose t h e planning period,

a

cus tomer,

and

a

product

for

t h e selection ( s e e

Figure

6.12).

©Copyright

SAP

AG. All

rights re ser ved.

Figure 6.12: Manual planning selection

In

accordance

with

Section

6.1.3, 17

units

of

A1

s h ou ld be

planned

for customer K1

( s e e

Figure

6.18).




Figure 6.13: S a le s

quantity

manual

planning

Now

check

t h e

characteristic

derivation

by clicking

CHARACTERISTICS ( s e e Figure 6.14 and Figure 6.15).


Figure 6.14:

Characteristic derivation f o r

planning

I




Figure

6.15: Characteristic derivation

f o r

planning

I I

You can see that a l l

characteristic

derivations

described

in

Chapter

3

have been processed for planning. Now we want to

see i f we

have

t h e same luck with t h e planning

valuation.

In

y ou r planning

layout,

p r e s s

VALUATE.

The following screen

appears

( s e e

Figure 6.16):




Figure 6.16:

Planning result

We

are

happy

with

this

planning

result.

We

can see

that

t h e

alternative

quantity

was found

via user e x i t , and

CO-PC

was

processed for

t h e

material

usage. The

revenue,

discounts,

and

freight charges were found

via t h e

a ct ua l co n dit io n s of t h e

condition

t y p e s of t h e actual

SD pricing

procedure ZEIF01.

I f you do no t

agree

with t h e planning result, via

EXTRAS •

VALUATION

ANALYSIS

you can

p r e s s

ANALYSIS

to look a t , for

example,

t h e

f i r s t

valuation

s t e p

more

closely.

SDaccess

sequence

The SDaccess

sequences

( a n

access

sequence in

SD

defines

how

t h e

SAP

system

finds a

condition

record)

can

contain fields that

are

n o t

created as

COPA

characteristics

in

y ou r

operating concern. You

t hus

have

to t e l l CO-PAabout t h e s e f i e l d s .



I t i s important that t h e

SD

actual conditions a re e nt ere d for t h e

f i r s t day of t h e month

for which you want

to enter y our planning

data.

6.5.4

User

Exit ZXKKEU14

The SD access sequences may use fields that are no t

characteristics

in

y our

operating

concern. In t h e

user

exit

ZXKKEU14

of t h e

component

COPA0002, you can

make t h e s e

fields known to CO-PA to ensure that t h e actual conditions are

als o

found

for

t h e

planning valuation.

6.5.5

Automatic Planning

I f

you

have

en tered

y our planned sales

quantities

individually

via

KE11 o r using

a

b a tc h input program and do n o t want to

have to

p r e s s

t h e

VALUATE

bu t t o n

e v e r y

time, you

can

also

execute t h e

valuation via

au t o ma tic

planning.

First

we

w i l l

check

whether

t h e

planned

quantities

have

been

e nte red

correctly

in

accordance

with

t h e

plan ning requiremen t s.

You can check this using

a

COPA report, for

example ( f o r more

details

about

COPA reports

see

Chapter

7

of this

book)

see

Figure 6.17.




Figure 6.17: Check

of

t h e

p l an n ed quantity

at

cu s t o mer

hierarchy

level

1

In

COPA

reports,

you

can

doubleclick a

characteristic

to

n a vigat e to t he underly ing characteristic. This

i s

called

drilldown. Nowwe

d r i l l

down on t h e kind of product

( s e e

Figure

6.18

and

Figure 6.19).


Figure

6.18: Planned quantity KH11 with kinds of product



©Copyright

SAP


Figure 6.19:

Planned

quantity KH12

with kinds

of

product

You can

see

that al t h ou gh you have only

en tered

t h e

planned

quant it ies v ia

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

t h e

requirements

of y ou r key account managers 1:1.

Now

we

want to

valuate

t h e

planned quantities automatically.

To do this

we

use t h e old

transaction KE1B.

The screen shown

in Figure

6.20 a p p e a rs .



of

various characteristic values.

I f

a

derivation

exists,

t h e

characteristic

i s derived

again.

I f you

choose

COPY,

t h e

values

of t h e

characteristic

are

copied

d i r e c t l y .

I f you

want

to make

entries

for

a

characteristic in

t h e selection

c r i t e r i a ,

you s h ou ld

copy

this characteristic;

o t h e r w i s e

you can

summarize.

A

pr oce s si ng instruction variant could l o ok as

shown in

Figure

6.21.




Figure 6.21:

Processing

instructions

f o r

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

i s ,

t h e

l o w e s t level o f

a

customer/product

combination),

o r

you can valuate a l l of y ou r

planned quantities

immediately

(Figure 6.22 represent s t h e minimum specifications).




Figure 6.22:

Selection c r i t e r i a f o r

automatic

planning

Now c l i c k

VALUE

FIELDS.

On

this

screen,

you

define t h e

value

fields that

you

now want to plan. I t makes

sense

to select t h e

value

fields

that you

want

to

valuate using y ou r valuation

strategy ( s e e Figure 6.23).

©Copyright

SAP

AG. All

rights re ser ved.

Figure 6.23: Definition of t h e value f i e l d s f o r

automatic

planning

Saving

variants

Bef ore

you

execute, you s h ou ld save

everything

as

a

variant. The

ne x t

time

you c a l l up

transaction KE1B,

a l l you

have to do

i s l o ad

t h e variant

and

straight away

you have t h e

pr oce s si ng instructions, selection

c r i t e r i a ,

and

value

f i e l d s .

Now check y our entries and t h e n execute. H o pef ully t h e

following lo g w i l l appear ( s e e

Figure

6.24).



©

CopyrightSAP

AG.

Figure 6.24: Log of automatic p l an nin g run

All rights re ser ved.

Now you know that t h e au t o ma tic planning run was somehow

successful

b ut

do

you

have

t h e

desired planning

result?

Again,

you

can view t h e planning

result

via

a

CO-PA

report, for

example ( s e e Figure

6.25).

Figure 6.25: Planning result down to GP1


Did you see how quickly

we

created

an i n i t i a l planning result

down

to GP1?

I t can be

displayed

on

a l l pos sible characteristics

( s e e Figure

6.26,

Figure

6.27,

and

Figure

6.28,

which show

a

drilldown):


Figure 6.26:

Drilldown

f r o m

cu s t o mer

hierarchy

I

to kind

of

product



©

CopyrightSAP

AG.

All rights re ser ved.

Figure 6.27: Drilldown

f r o m

kind of product to

cu s t o mer

©Copyright

SAP


Figure 6.28:

Drilldown

f r o m

cu s t o mer

to product

Naturally you can also view y our planning result at

aggregated

level

( s e e

Figure

6.29).




Figure 6.29:

Planning result

at

ag g r e g a t ed

level

For

further

i l l u s t r a t i o n , t h e

video

below once

more

explains t h e

planning process in d e t a i l .

Video 5:

Planning

No te:

Should

y ou r reading

device no t be able

to show this

video, you

can

use

y ou r

computer to

watch

i t on t h e

internet.

To

do t h i s , head to o ur web page at http://video5.copa

en.espressotutorials.com.

I

w i l l

explain

how

you can

create

y ou r

own

COPA

reports

and

execute

drilldowns in

them

in t h e

next chapter of

this b o o k .

You can now execute specific planning changes

( e . g . ,

with

transaction

KE1B)

or

l a t e r ,

as described in Section

6.4,

distribute t h e planning

o v e r

months with

transaction

KE1A.

Plea t o

SAP

As an

inhouse

consultant and

controller,

t h e f i r s t thing

I

do with

a

new

release i s check

whetherKE1A

andKE1B

are

s t i l l available Only i f

t h e y

are

can

I

e nj o y

t h e

new

release....

Hopefully

SAP

w i l l never remove t h e o ld planning

transactions

KE1B o r KE1A

from

t h e

SAPERP

system in new

releases

P lan ning

in

COPA

with t h e



new planning tools i s more cumbersome and takes

a

l o t

longer.

I f

I

had to

p e r f o r m

sales and

turnover

planning for

a

company again, and

t h e

o ld planning transactions

no

longer existed,

I

would no longer recommend

planning in

COPA.



7

Dynamic Reporting

Many

o f

t h e

modules

in t h e

SAP

system

now

have their

own in f o r m a ti o n system.

This

includes, embedded

in at

least

t h e

standard reports, Report

Pai n ter

o r

Report

Writer rep or t s that

provide t he in f orm a t io n

o f t h e

respective module.

I deliberately refer

to

more t h a n

j u s t

t h e

CO

module here.

F o r example,

there

are also separa t e information systems

i n

Logistics

modules

including

t h e

Customer

Service

o r

Project

System

modules.

COPA also

has

an

information

system

ut

no

standard

reports.

The

COPA information

system

i s

dynamic. You

can create y our

own p r o f i t a b i l i t y

reports at any time.

Why

are

there

no

standard reports?

As

you

learned

i n

Chapter

2

of

t h i s

b o o k,

i n

COPA

you

define

y our

own

value

f i e l d s

and

characteristics. You want to map

y our

own individual

contribution margin

structure

why

would you need

predefined

s t andard s?

You

want

to

evaluate your

dataset

according

to t h e

characteristics

you

define and

thus

create a

multidimensional

information

system

how

would

a

standard report recognize y our

characteristics? Therefore,

you

define

y our

own

multidimensional


reports.

In

t h e s e reports, you navigate between detail

l i s t s

and

drilldown

l i s t s , f r o m

which

you

can navigate

to

t h e COPA

l i n e

items

and

f r o m there

to t h e

original modules

i n

which

t h e data arose. Using t h e drilldown function, you can

navigate

t hr ou g h

a l l

characteristics

that

you

have a s si g n ed

to

y our

p r o f i t a b i l i t y report,

f r o m t h e

highest customer

hierarchy t hr ou g h a l l further customer hierarchy levels down

to t h e

cust o mers.

You

have

access

to

classic functions

f o r

interactive processing:

f o r example, sorting options,

t o p

N

functions, ABC analyses,

and

much more. You can create

plan/actual

comparison reports, f i s c a l

year co m p a ri s o n s, or



individual reports that perhaps

consider only

one

special

value

f i e l d . You can also download your

data to

Microsoft

Excel

o r

o t her s p r e ad s h e e t

programs f o r a l l

o r

selected


you

have a s si g n ed

i n

t h e report.

But

that’s

enough

praise

f o r

t h e

reporting

i n

COPA.

I t

a l m o s t sounds

l i k e

an

SAP

marketing b r ochure. At

t h i s

point

h o w e v e r , I must

point

o ut

that t h e COPA reports are only

useful

as

a

pure management information

system

to

a

limited

extent. Many companies

transport

t h e

data

created

and collected

i n

COPA

to

o t her management information

systems

via

interfaces.

With SAP

BW,

SAP

i t s e l f offers t h i s

t y p e

of

additional

system

i n

which

you can

use,

f o r

example,

management cockpits

to

no t

only

supply

y our

management

with

t h e

data required

f o r

controlling t h e company,

b ut

also

to

spoil them

with, f o r e x a m p le,

easy

to

use graphical

interfaces.

This l a t t e r

luxury

i s

only

available

i n

t h e COPA

information

system

i n

a

limited

f o r m (consider

t h e

possibility

to

display

diagrams);

i t

does however

offer controllers

who

want

to

work

seriously

with

i t

numerous and

dynamic

options.

The p r o f i t a b i l i t y reports that I describe below

are

drilldown

reports. They

allow

you

to

toggle

between

t h e

characteristics

p re sen ted

once

you

have executed

t h e

report.

This

makes drilldown reports easier

to

handle

than,

f o r example, Report Painter reports that youmay

know

f r o m

o t her

CO

submodules.

To get

as

f a r

as

being able

to

create your

own


report, however,

you need

modules that

need a


report.

This

t y p e of

module

i s

called

a

report component and

i s described i n t h e next section.

7.1

I n f o r m a t i o n

System

Components

I f you want

or have

to

create

p r o f i t a b i l i t y reports

i n

COPA

because,

as

described i n t h e

previous

section, there are

no

standard reports

i n

COPA, you need report components



that

you also

have

to

create

i n

advance.

You

need

t h e

following report

components:

Key

figure scheme

Reporting

variable

P r o f i t a b i l i t y report f o r m

F i r s t l y ,

I

recommend

that

you create a

key

figure scheme

by

defining

y our

contribution margin structure. This saves

you

h a ving

to

constantly

repeat

t h e

contribution margin

structure

i n

every

report

form.

Secondly,

I

recommend creating separa t e variables

f o r

t h e


you

want

to

use

to

evaluate

and select

y our data. This e n a b l e s you

to

c a l l

up

individual


o r

intervals when you

c a l l

up

reports.

I f

you also

define t h e s e variables as s electio n o ptio ns ,

you

can c a l l

up

individual characteristic values, characteristic

value

intervals, or multiple selections

f o r

different

characteristic

values,

similarly

to

t h e

situation

that

you

already know

f r o m

o t her selection screen s

i n t h e

SAP

s y s t e m .

As a

t h i r d

reporting component, I recommend

t h e f o r m s

f o r


reports.

You

w i l l

no t need a l l

of

t he f orms ,

only

t h e

f o r m

f o r t h e two

axes

(matrix) structure.

Th is t ype

of


report

f o r m

e n a b l e s

you

to

establish

a

basis

f o r

a p r o f i t a b i l i t y report

that

provides

t h e

advantages

mentioned

i n t h e

previous section. The f o r m s h ould

be

viewed similarly

to

a Report Painter

form,

t h e difference

being

that i n

contrast to o t her SAP

information

s y s t e m s ,

you

do

no t

navigate

to

individual

classic

sets

(infosets, single

set, e t c . ) . Your “sets”

are

t h e

characteristics

and

value

f i e l d s

that

you

define

i n

your

operating

concern.

A

COPA

f o r m consists

of

three main

parts:

Lines



Columns

General

selections

In t h e lines

you define your contribution margin

structure.

Here

you

can

also access

t h e

elements

of t h e

key

figure

scheme

that

you

pre viousl y created. You

use

t h e

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

i n

COPA

via

a specific record

t y p e

( e . g . ,

A, t h e n you only see your incoming sales orders).

In

t h e

general

selections, you can define

t h e

characteristics

that

you

want

to

use

f o r navigation

i n t h e

subsequent report.

Wherever you

decide

to

specify

a

characteristic,

i t

i s

advisable

to

work with

t h e

previously defined variables

so

that

you

only

select

t h e

characteristic

when

you

c a l l

up t h e

report

o r

no t at

a l l , and can create

t h e

report f l e x i b l y .

In

t h e

next sections,

I

w i l l

use

o ur

example

to

show

how you can

crea t e t h e report

components

that I have described.

I f

you

require

more

detailed

information

specifically

f o r

Report

Writer

and

Report Painter

Reports,

I

recommend

t h e

book

“P r a x is h a n d b uch Re p o r t Painter/Report Writer”

by

my

Espresso

Tutorials publishers Martin

Munzel and Jörg

Siebert (published by

SAP

Press

i n

2012,

available

i n

German language only).

7.2

Example

Customizing

o f

Report

Components

As

stated

i n t h e

previous section,

I

w i l l

now

describe

t h e

information report

components

that

you

need

f o r

a

COPA

report.

7.2.1

Key

Figure

Scheme

You

use a key

figure

scheme

to

map y our

contribution

margin structure,

f o r

example.

A

key

figure scheme

e n a b l e s

you

to

define frequently used

arithmetic

operations

so

that

you

can

use

them

repeatedly

i n

reports.

The f ormulas i n a



key

figure scheme

can be

based

on b o t h

value

f i e l d s

and

on

already defined f ormulas

of t h e same

key figure scheme.

You

can

define

a

key

figure scheme

i n t h e

COPA

configuration menu, via

INFORMATION

SYSTEM • REPORT

COMPONENTS

•

DEFINE

KEY

FIGURE

SCHEMES.

F o r

o ur

e x a m p le, I have created t h e

key

figure scheme

Z1

f o r

t h e

contribution

margin

accounting

(GP

Accounting) that

we

want

to

map


©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

7.1: Definition

of

a

key figure

scheme

in accordance

with

o ur

example

contribution margin structure

In Figure

7.1, i n

t h e ele m e n t s

50

to 900

you

can

see

t h e

names

of

t h e elements

of

t h e key figure scheme h e s e



elements contain certain

key

figures.

F o r each

element, you

now define

a

basic

formula.

You

do

t h i s

by

selecting

an

element

and

t h e n

clicking BASIC

FORMULA ( s e e Figure 7.2).

©

Copyrigh t

SAPAG.

A l l

rights

reserved.

Figure

7.2:

Detailed definition

of t h e

element

of

a

key figure

scheme

We

w i l l

do that now

using

t h e

example

of

element 50,

S a l e s

quantity. On t h e next screen, define t h e basic formula

f o r

t h e

sales

quantity.

I t

s h o u ld

be

p re sen ted

as

a

positive

figure;

you

control

t h i s using

t h e

plus

s y m b o l . The

system

a s si g n ed element 9001

to t h e

sales quantity

f i e l d

defined

i n

operating concern Z111. You

now

select

t h i s element

( s e e

Figure 7.3).

©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

7.3:

Key

figure

scheme

element,

sales

quantity

Do

t h e

same

f o r

t h e

remaining elements

that

you

have



already defined as quantity and value f i e l d s .

The procedure i s different f o r

t h e

subtotals i n

y our

contribution margin scheme.

As an

example, l e t

us

look at

element

300, BILL REVENUES

( =

invoice sales).

We

want

to

calculate

t h e s e

invoice

sales

as

t h e

difference

between

g r o s s

sales

and

discounts. Gross sales

and

discounts

are

separa t e

value

f i e l d s

i n

your

operating

concern, which

means

that t h e system

has

already a s si g n ed elements

9003

and 9004 accordingly. Figure 7.4 shows

t h i s i n

more d e t a i l .

©

Copyrigh t

SAPAG.

A l l

rights

reserved.

Figure

7.4:

Key

figure

scheme element,

invoice

s a le s

You

can see a further

example of

a subtotal

i n

Figure

7.5.

We

calculate

t h e

subtotal

Gross

P r o f i t

1

(GP1),

that

i s ,

key

figure scheme

element

650.



©

Copyrigh t

SAPAG.

A l l

rights

reserved.

Figure

7.5:

Basic

f ormula

for key figure

scheme

element

GP1

The s pecial f eat ure

of t h i s

formula i s that

i t

combines

elements defined

by

t h e

system

and

elements defined i n t h e

key

figure

scheme. The

s y s temdefined elements

9006,

9007,

and

9008

are

deducted

f r o m

t h e

key

figure

scheme

element

300 to

calculate t h e key figure scheme element

650,

which

represents

t h e

subtotal GP1.

The

system

proposes t h e s y s temdefined elements

(9000+)

when

you

create t h e basic formula

i f

you open t h e

adjacent

matchcodes.

In

t h e

next section, I

w i l l

describe

how

to

create report

variables

that

you

also

need

f o r

y our


reports.

7.2.2

Report

Variables

I f

you

want

to define

reports

o r

f ormulas f l e x i b l y , work with

variables. You

do

no t

f i l l

specific

f i e l d s

u n t i l you define

o r

execute a

report.

You

can

define variables f o r reports either

f r o m

t h e

application

menu

or

f r o m

t h e

COPA

configuration

menu.

In t h e

l a t t e r case, you

do

t h i s via

INFORMATION

SYSTEM • REPORT COMPONENTS • DEFINE VARIABLES FOR

REPORTS. After

clicking NEW ENTRIES,

you

f i r s t have

to

select

a

variable

type.

F o r

o ur


reports

we

need



e x a m p le,

you

want to

see

an

interval

of

cust o mers,

you

would

have

to

enter

two

variables ( F r o m Cu s t . and

ToCust.)

to

make t h i s

possible.

©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

7.7: Multiple

selection

options

via

selection

option

I

recommend creating characteristic variables

f o r

a l l


you

want

to

use

i n

your


reports.

The

t h i r d

report component

that you

need f o r COPA reports

are t h e p r o f i t a b i l i t y report

f o r m s

that

I w i l l describe

i n

t h e

next

section.

7.2.3

Profitability Report Forms

A


report

f o r m

describes

t h e content

and

f ormal

structure

of

a

report.

As

explained at

t h e

beginning of t h i s

chapter, I recommend

using

only

f o r m s

of

t y p e “Two axes

(matrix)”

as

t h e

f o r m

f o r

y our p r o f i t a b i l i t y reports.

You

create

f o r m s via transaction

KE34

( s e e

Figure 7.8).



©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

7.8: Creating p r o f i t a b i l i t y report

forms

Before

I

describe a l l

of t h e

s t e p s

that

you

have

to

execute

to

create

a

for m,

Figure

7.9

shows how

t h e

f o r m

s h o u ld

look

when complete:



©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

7.9: Completed p r o f i t a b i l i t y report

form

As I explained regarding

t h e

planning layout

i n

t h e “Planning

i n

COPA”

chapter,

t h i s f o r m

consists

of three parts:

Lines

Columns

General selections

F o r

o ur e x a m p le,

l e t us

s t a r t

with

t h e

l i n e s .

The

aim of o ur

f o r m

i s to

display

t h e

actual

and planned

figures

f o r

contribution

margin

accounting.

As

lines

we

use

t h e

lines

of

t h e

key

figure scheme previously

created.

We do

no t

make

any

restrictions using additional characteristics.

In an empty

form,

t h e

lines

are displayed as dots.

Simply

doubleclick a

dot.

In

t h e

dialog box that a ppears, select

KEY

FIGURE

SCHEME ELEMENT

( s e e

Figure 7.10).



©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

7.10:

Selection

of

t h e

element t y p e for a

line

definition

A further window a ppears, and

h e r e

you

can

select

t h e

key

figure scheme

element

at

t h e

top.

As

stated a b o v e ,

you

do

no t need

to

make any further characteristic selections

( s e e

Figure

7.11).

©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

7.11: Element

definition,

sales

quantity

line



Once

you

pres s

CONFIRM, y our

l i n e

( i n

o ur

example

t h e

“Sales quantity”

l i n e )

i s

defined. Proceed

i n

t h e same way

f o r

a l l

lines

of

y our

contribution

margin scheme u n t i l

you

have defined

a l l

l i n e s .

In

t h e

next

step,

define

your

colum n s.

Remember:

we

want

an

actual

data column

and

a

planned

data

colum n,

a

variance column, as well

as

an

actual

and

planned column

per

kilogram.

Let us

s t a r t

with t h e actual data column.

In

a

b l a nk

form,

again

you see

only

dots

where

you can create

colum n s.

Doubleclick

a

do t

and

a

dialog

box

appears ( s e e

Figure

7.12).

©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

7.12:

Definition of

t h e “Actual

D a t a ” column

F o r t h i s column we have

selected two

characteristics: t h e

Planned/actual

indicator

and

t h e

characteristic

Period/year.

The characteristic value

0

( =

actual)

i n t h e

Planned/actual

indicator characteristic

defines

that t h i s

column

i s only to

accept actual values.



Via

t h e

Period/year

characteristic,

f o r

each

column

you can

control

which

period

i s to

be

presented.

As we do no t

want

to

define t h e period selection when we

are

defining t h e

form,

f o r t h e

f i r s t

time

we

work

with t h e

previously

created

report variables here.

We use t h e

variable PERIO,meaning

that when

you

run

t h e report, you

have

multiple selection

options f o r periods.

In o ur e x a m p le,

we

have introduced

t h e

alternative sales

quantity. The sales quantities are also co n vert ed

into

kilograms

and

presented.

I t i s

no t

up

to

me

to decide

whether

i t

makes sense

i n

y our

company to compare

products

and

t h e i r

conditions

using

t h e

weight. You

may

have o t her unit sizes that

you

can use

to

compare

your

products. The important

point

f o r

t h i s

book

i s

that I have

showed

you, via t h e

customizing and coding,

how

to

present

alternative

quantities.

Let

us

assume

that

you

could

compare using “kilogram.” Now

at t h e

intersection

of

t h e

ACTUAL

DATA

column

you

have j u s t

defined and t h e

ALT.

QUANTITY

l i n e ,

you have

to

present

t h e

c e l l

as

selected. To

do

t h i s , c l i c k

t h e

corresponding

c e l l and

c l i c k SELECTED

( s e e

Figure

7.13).

©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

7.13:

Selecting

a

c e l l in

a

form

In t h e for m,

t h e c e l l now has

a checkmark ( s e e Figure

7.14).



©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

7.15:

Formula

editor

for “Actual/kg”

column

As

i t

i s

to

be

a

formula

f o r colum n s, with

t h e

name

X001

e t c . ,

t h e

columns

you

have created

are

proposed

f o r

use

i n

t h e

formula.

Now

you can see

why

we

selected

t h e

c e l l

f r o m

t h e intersection

of

ACTUAL

DATA/ALT.

QUANTITY.

The

selection makes

t h e c e l l

known

to

t h e formula editor: h e r e i t

i s

c e l l

Z001.

In t h e

upper

b o x ,

write

t h e

formula f o r

t h e

ACTUAL/KG colum n: X001/Z001. The result i s that

a l l

cells

i n

t h e columns

w i l l

accept

t h e

actual values

of t h e

actual

column

divided

by

t h e value of c e l l Z001. Once

you

confirm

t h e

formula

editor

t h e

column

i s

defined.

Similarly,

define t h e columns f o r

PLANNING

DATA and

PLAN/KG.

In t h e

planning colum n, use 1

( =

plan)

f o r t h e

planned/actual

indicator. As every plan

s h o u ld

be

saved

with

a plan

version,

so

that

you

can

compare different plans

l a t e r , specify

t h e

characteristic

P l a n version

i n

t h e

characteristic selection

( s e e

Figure 7.16).

©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

7.16:

Definition of

t h e “Planning D a t a ” column

in t h e form



Use

a

variable

that

you

have defined

f o r t h e

version

as

well,

so that

you

do

no t

have

to

decide

now

which plan version

you

want

to

see ( y o u

decide

when you

c a l l

up

t h e report).

The VARIANCE column

i s

also a formula: actual data minus

planning

data.

Again,

c l i c k

t h e

next

free

point,

define

t h e

column as a formula, and again, t h e formula editor appears

automatically.

Here

you

can

state: actual data minus

planning data.

The lines

and

columns now

look

l i k e

t h e

target definition

as

p re s e n t ed

i n

Figure 7.9.

Intersection o f

line

and

column

formulas

I f

you create f o r m s

without using

a

key

figure scheme,you also

have to work with f ormulas i n

some

l i n e s ,

f o r

example, f o r

subtotals.

The

SAP

system

may

no t know

which

formula has

p r i o r i t y :

t h e l i n e formula o r t h e

column

formula. Inform t h e c e l l

concerned at

t h e

intersection

of t h e l i n e and

column whether t h e

l i n e

o r

column

calculation

has

p r i o r i t y

by

double

clicking.

Now you have

to

define

t h e t h i r d

f o r m

element:

t h e

general

selections. These

are i n

t h e f o r m under

E D I T

• GEN.

DATA

SELECTION • GEN.

DATA SELECTIONS.

F o r

o ur

example,

we

have

included t h e

characteristics

that

you

want

to

select

when

calling

up

a relevant report

and

that

you can

use

f o r

drilldown

i n

a report

( s e e

Figure

7.17).



©

Copyrigh t

SAPAG.

A l l

rights

reserved.

Figure

7.17:

General

selections

in

a form

Here too,

you

s h ould

use variables

so

that

you

do

no t have

to decide u n t i l you

c a l l

up

t h e

report whether you want

to

see

a l l o r

only certain characteristic values

of

a

characteristic

i n t h e

report.

Then you can

check

and

save t h e

for m.

You

can use i t i n

as

many p r o f i t a b i l i t y

reports

as you

w a n t .

7.3

D ri lld o w n

Reports

The reports that

you s et

up based

on t h e

“two axes (matrix)”

structure

of

t h e

p r o f i t a b i l i t y report

f o r m s

are

called

drilldown

reports. These drilldown

reports

offer

t h e

functionalities

that

I described i n t h e introduction

to t h i s

chapter.

I f you want to create t h i s

t y p e

of drilldown report, you

can

define

t h e

characteristics

to be

used

f o r

navigation

and

drilldown.

You

can

also

use

t h e

characteristics f o r

sorting

t h e drilldown. You

can

use

t h e

characteristics f r o m

y our

form,

o r

o t her

characteristics.

To

av oid

long

waiting

times



when

you

are

selecting

your

dataset,

i n

t h e report

you can

configure whether

i t

has

to

access data

at

a

su m m a ri z a ti o n

level o r not. You

need


levels to summarize

t h e COPA dataset

i n

advance

so

that

you can

c a l l

up t h e

required

information

quickly. I w i l l explain

t h i s

further

i n

Section

8.1.

You

can

also

s p l i t


reports.

F o r

example,

you

i n i t i a l l y

c a l l

up

a p r o f i t a b i l i t y report

that

contains only

customerspecific characteristics.

In t h e

report,

navigate

down

to

an individual customer. Now c a l l up a second ( s p l i t )


report

f o r t h i s customer that

contains a l l required

productspecific

characteristics.

The

option

of

s p l i t t i n g

reports

i s

useful f o r datasets that are very large and need a

report

s p l i t

as

described

i n

order

to

allow

t h e

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

s et

up

reports

via

a

value

f i e l d o r

multiple

special

value

f i e l d s

to

create

special

analyses.

I

also recommend

creating

p r o f i t a b i l i t y reports

that refer

only

to

general and productspecific characteristics f o r t h e four

f o r m s mentioned a b o v e .

Rep or t s

that

only

contain

customerspecific characteristics

are also useful.

And f i n a l l y ,

you can create reports that contain b o t h productspecific

and customerspecific

characteristics

b ut

that

s h o u ld

really

only

be

used

i f

you

need

information

based

on

t h e

combinations of productspecific

and

customerspecific

characteristics.

7.4 Line

Item

Layouts



In Chapter

5,

“Actual Value Flows,”

I

reported a

great

deal

a b o u t possible

l i n e

item corrections. The prerequisite, of

course,

i s

that you

can

also present t h e

l i n e

items how

you

need t h e m . Thus

i t

i s

useful

to

create individual

l i n e

item

layouts.

Using l i n e

item layouts, you can

display t h e recorded CO

PA l i n e

items i n

l i s t s ,

download t h e m ,

o r

p r i n t

t h e m .

You

can

c a l l

up l i n e

item layouts via

t h e

COPA application menu.

The pa t h

i s

as

follows:

INFORMATION

SYSTEM •

CURRENT

SETTINGS • DEFINE

LINE

ITEM

LAYOUT (transaction KE3F).

When

you

create

a

layout,

you

f i r s t

have

to

give

i t

a

name


©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

7.18:

Creation

of a line

item

layout

I

Then

c l i c k

CREATE and

t h e i n i t i a l

screen

appears

( s e e

Figure 7.19).



©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

7.19: Line

item layout

i n i t i a l

screen

By

doubleclicking

t h e

individual ele m e n t s

( o r ,

i f

you

have

a lready defined

“Element

4 , ” by

clicking

a dot),

you can

add

characteristics and

value

f i e l d s

f r o m

y our

operating

concern.

You can also select date f i e l d s such as

CREATED

ON,

invoicing

date,

etc.

( y o u

do

no t have

t h e s e f i e l d s

i n t h e

drilldown reports). I have created

an

example layout

see

Figure 7.20.

©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

7.20: Example

line

item

layout

You can use t h e s e

l i n e

item layouts

f o r

b o t h actual

and

planning

l i n e

items,

specifically f o r transactions

KE24

(Display

Actual Line

Items)

o r

KE25 (Display

Planning Line

Items).

The SAP system selects

l i n e

items

according to

t h e

selection

c r i t e r i a

( s e e

Figure

7.21)

that

you

specify

when

calling

up KE24

o r

KE25.



Figure

7.22:

CO-PA

actual

line

item s

l i s t

display

©

Copyrigh t

SAPAG.

A l l

rights

reserved.

Now that

you

have become

familiar

with

b o t h

t y p e s

of

f orm s, I

w i l l

show you how to create

t h e

actual reports.

7.5 Structure o f

a

Profitability Report f or Our Example

Using t h e example

f o r m

that

we

have

s et

up

i n

t h i s

chapter,

we

now

want

to

use

transaction

KE31


report ( s e e Figure 7.23).

to

create a



©

Copyrigh t

SAP

AG.

A l l

rights reserved.

Figure

7.23:

Creating

a

p r o f i t a b i l i t y report

F i r s t

you

have to

name

y our

report.

Select REPORT

WITH

FORM

and

specify

which f o r m you want

to

access. Then

c l i c k CREATE.

A

screen with

four different

t a b s

appears

(CHARACTERISTICS,

VARIABLES,

OUTPUT

TYPE,

and

OPTIONS) ( s e e Figure 7.24).

©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

7.24:

I n i t i a l

screen

for creating

a report

To define t h e report completely, you

have

to

work t h rough

a l l

four

tabs.

On

t h e

CHARACTERISTICS

tab,

f i r s t

select

t h e


you

want

to

report

on

via drilldown.

On

t h e

VARIABLES

t ab

you see

t h e report

variables

that

you

selected

i n

your

p r o f i t a b i l i t y report for m. As t h e variables

i n

o ur example

were

mainly

v aria bles w it h s election op tion s,



t h e y are only displayed

gray

here, meaning

that

you cann ot

change them ( s e e

Figure

7.25).

©

Copyrigh t

SAPAG.

A l l

rights

reserved.

Figure

7.25:

Variable

for

creating

a

report

On

t h e

next

tab, OUTPUT TYPE,

you

define

how t h e

report

i s

to

be

executed. Here

we

decide

on

t h e classic drilldown

and

want

to

s t a r t

t h e

report

structure

with

t h e

detail

l i s t

( s e e

Figure 7.26).



©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

7.26:

Definition of

t h e o ut p ut t y p e when creating t h e report

Detail

l i s t

means

that t h e report always starts with t h e

presentation

of

contribution margin

accounting

i n l i n e

form.

In contrast,

Drilldown

l i s t means that

t h e

individual

contribution

margin

items

are

displayed

i n

column

for m.

The

fourth t ab

i s

shown i n Figure 7.27.



©

Copyrigh t

SAPAG.

A l l

rights

reserved.

Figure

7.27: Options

for

creating

t h e

report

In t h i s

image, you can

see

t he v ario us o pt io ns offered

by

SAP

be

t h e y f o r

t h e

p r i n t setup, t h e drilldown l i s t

o r

f o r

comments,

etc. The

important

thing

on

t h i s

tab,

however,

i s

t h e PERFORMANCE block.

The

longer

you

work

with

COPA,

t h e

more

l i n e items you save ( o n a daily basis

pr o ba bl y

hundreds,

i f

no t

t h ou sa nds ) . I f

you

do

no t

work

with


levels

(which I

w i l l

explain

i n

more depth i n

t h e next chapter), calling

up t h e

report

can

take

an

increasingly

lo ng t ime

f o r

performance rea s o n s . Therefore,

when

you

c a l l

up

t h e report,

you

s h ould r ea d s u m m ar iz a t i o n

levels and

at

least receive a w a r n in g

i f

t h e report

does no t

find any su m m a ri z a ti o n levels. Then save

and

execute

t h e

report.

7.6

Example

o f

Dynamic

Reporting

We

are slowly ap pr oachin g

t h e

end

of

t h i s b o ok. I have told



you a

l o t

a b ou t

characteristics, value f i e l d s , derivations,

valuations, interfaces,

data transfers, act ual da t a, planning

data,

report components, and

reports.

I f you

do

no t use any

o t her management information

system

into which,

f o r

e x a m p le,

you

transfer t h e COPA l i n e

items

created,

to

display

t h e

results

you

need

t h e

COPA

information

system

and

thus

t h e dynamic reporting described. Using

t h e

example report that

we

have created, I w i l l

now

show you

everything

we have

created.

Using

transaction KE32,

you

run


reports and a

selection screen appears

on

which

you can

enter t h e

characteristic

values

f o r which

you

want

to see

dat a ( see

Figure 7.28).

©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

7.28: P r o f i t a b i l i t y report

selection

screen

After making

y our

entries, execute

t h e

report. A w a r n in g

may

appear stating that

no

su m m a ri z a ti o n level

was

found.

Ignore t h i s

with

YES

i f

t h e dataset of

your

COPA

data

i s

no t

t o o large. The report starts with

t h e

basic detail

l i s t

( s e e

Figure

7.29).



Figure

7.29:

Basic

detail

l i s t

©

Copyrigh t

SAPAG.

A l l

rights

reserved.

You

can

now

see

t h e

data

f o r

your

entire selection

controllers w i l l be delighted...

Now we

switch

to

t h e

drilldown

l i s t

f o r

t h e

characteristic

sales

organization

( s e e

Figure

7.30)

via

NAVIGATE

•

SALES

ORGANIZATION

(your

characteristic

i s

part

of t h e

path ):

©

Copyrigh t

SAP

AG.

A l l

rights reserved.



Figure

7.30:

Basic l i s t ,

detail

l i s t ,

sales

organization

By pressing

t h e

“cassette recorder

keys”

you

can display your entire contribution

margin structure as

colum n s.

Via

E D I T

• COLUMN(S) •

ON/OFF

you can

display or

hide

t h e

colum n s.

I f you

i n i t i a l l y only want

to

see y our actual

data

i n

t h e drilldown l i s t

f o r

example, select an “actual” column

by

clicking

i t

and t h e n follow

t h e

pa t h

a b o v e .

In

t h e

example

we

want

to

look

at t h e

actual

b i l l

revenues

( =

in v oice s ales )

( s e e

Figure

7.31).

©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

7.31:

Actual b i l l

revenues

for

sales organization

By

doubleclicking

t h e

characteristic

value

we

s t a r t

a

drilldown

consideration

downwards

t h rough

t h e customer

hierarchies

to

customer

5

and

t h e

products

t h i s

customer

has purchased ( s e e Figure

7.32).



©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

7.32:

Drilldown

to

customer

5 and his

products

You

can also

view

t h e

actual

and

planned

contribution

margin

f o r

t h i s combination

of

characteristics as

a

detail

l i s t :

f o r e x a m p le, place

t h e

cursor

on

Product 2

and

choose

NAVIGATE • DETAIL

LIST


Figure

7.33:

Contribution margin

accounting

for

selected

characteristic

©

Copyrigh t

SAPAG.

A l l

rights

reserved.

combination



In t h e next chapter, I w i l l describe some COPA tools,

such

as

t h e


levels addressed

i n

t h i s

chapter,

which

w i l l

make

your work i n COPA easier.



8

Tools in

COPA

COPA

o f fers

various

t o o l s

that

a re

intended

t o make

your work

in

COPA easier

o r t o

support you.

They

include t o o l s

f or

performance

improvement,

t h e

transfer

o f

data

from external systems,

t h e a naly si s

o f

value

flows into

COPA,

live

start prepara tio n s,

authorization

administration,

and,

last

but not least,

SAPenhancements,

t h a t

i s , t h e user

exits

that

you

have

become

familiar

w i t h

in

various

chapters

o f

this

book.

In

accordance

with

t h e p hil o s o p h y

of

t h i s b o o k, which

i s

to

show

you

things

i n

COPA that

you

need

to

s t a r t

working

quickly,

I

w i l l

r e s t r i c t

m y s el f

to

two

important

aspects: t h e

topic

of

performance

improvement

as

a

result

of

working

with su m m a ri z a ti o n levels, and t h e analysis

of

value f l o w s

i n

COPA.

8.1

Summarization

Levels

When

you

c a l l

up

p r o f i t a b i l i t y reports,

you want

to

see

t h e

required

data within

a r e a s o n a b l e

time.

The

larger

t h e

dataset

of

actual

and

planning

l i n e

items

i n

COPA,

t h e

longer i t takes

to

access

t h i s

dataset.

In COPA,

you can

av oid

frustration

when

accessing

t h e

l i n e

items

by

defining


levels

that

summarize new

and

existing

l i n e

items

i n

regular

jobs

and

thus considerably

a cce ler at e t h e

access

to t h e dataset.

I f you want

to

create su m m a ri z a ti o n levels, COPA

offers

you

t h e

opportunity

of

creating prop osals. You

can

accept

t h e s e

pr op o s al s

o r

create

a


level

f o r

every


report.

Based

on

many years

of

experience, I

recommend

only

three su m m a ri z a ti o n levels:

Level

1 contains a l l

productspecific characteristics

plus



t h e characteristics that

are

no t directly dependent

on

customers or products.

Level

2 contains a l l

customerspecific characteristics

plus

t h e


are no t

directly dependent

on

customers

o r

products.

Level

3 contains a l l customerspecific

and

product

specific characteristics

plus

t h e

characteristics

that

are

no t directly dependent

on

customers

o r

products. This

level

i s

a l m o s t identical

to

t h e l i n e item level

i n

COPA.

However,

as

characteristics

such

as

date specifications

etc.

are

no t

summarized,

t h e

level

i s

smaller.

I f you

creat e t he p r o f i t a b i l i t y reports that I recommended

i n

Chapter

7, t h e

three su m m a ri z a ti o n

levels

de scr ib ed a re

s u f f i c i e n t .

Why

only

three

levels? Each

su m m a ri z a ti o n level

w i l l need

additional

disk space

h e

f e w e r

t h e

number

of

levels

you

h a v e,

t h e l o w e r t h e memory

capacity

you

need

f r o m your basis.

Every

night you s h ould schedule a

background

jo b

that

adds

t h e

l i n e

items created

durin g t h e

day

to t h e l i n e items already summarized.

8.1.1 Example

Customizing

for a Summarization

Level

You can

access

t h e su m m a ri z a ti o n level vie w

via

t h e

configuration

menu

f o r COPA (ORKE)

under

TOOLS •

SUMMARIZATION

LEVELS

•

DEFINE

SUMMARIZATION

LEVELS

( s e e

Figure 8.1).



©

Copyrigh t

SAP

AG.

A l l

rights

reserved.

Figure

8.1: I n i t i a l

screen for

defining

summarization

levels

Alternatively,

via

TOOLS • SUMMARIZATION LEVELS • HAVE

PROPOSAL

CREATED

AUTOMATICALLY, you can

have

t h e

SAP

system create a pr op o s al ( s e e Figure 8.2).

Figure

8.2:

Own o r

proposed summarization

levels

©

Copyrigh t

SAP

AG.

A l l

rights reserved.

8.1.2

Activating

Summarization Levels



F o r COPA

to find

t h e su m m a ri z a ti o n

levels

when reading

t h e data

( f o r

example, f o r planning or when calling up a

report),

t h e levels

must

be

active.

You activate y our su m m a ri z a ti o n levels

via t h e

COPA

application

menu

(TOOLS

•

SUMMARIZATION

LEVELS

•

REFRESH),

see

Figure 8.3.

©

Copyrigh t

SAP

AG.

A l l

rights

reserved.

Figure

8.3: Refres hing summarization

levels

8.2 Analyzing Value Flows

Before

you

actually

p o s t

COPA

l i n e

items,

COPA offers

you

t h e

option

of

simulating

your valuations

and

value f l o w s

i n

COPA

i n

advance.

You

can

c a l l

up

t h i s

analysis

directly

f r o m

t h e

COPA

application

menu

( s e e Figure

8.4).



©

Copyrigh t

SAP

AG.

A l l

rights

reserved.

Figure

8.4: Options

for

analyzing value

f l o w s

8.2.1 Checking

t h e

Customizing S e t ti ng s

You

can check

t h e

customizing

settings

of

t h e

organizational structures

of

your

COPA

( s e e

Figure 8.5).

You

may

remember

my

s t a tement:

“The

organizational

structures are

t h e backbone

of

t h e SAP

s y s t e m.”

Using t h i s

m o ni t o r

you can

check further

customizing settings.



©

Copyrigh t

SAP

AG.

A l l

rights

reserved.

Figure

8.7:

Results

of t h e value

f i e l d

analysis

You

can

see

which

f i e l d s

are

s e r v ed

by

each interface.

Using t h e b ut t o ns dis p la y ed

at

t h e t o p

of t h e

screen,

you

can navigate

to

t h e

SD

conditions,

t h e

PA

transfer

structure,

or t h e defined assessments.

Overview o f Valuation

In

t h e next step,

we

check

t h e

valuations

f o r

record

t y p e s

A,

F,

B, and C

at

t h e

actual point

of

valuation

01

( s e e

Figure

8.8).



©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

8.8:

Executing

t h e

valuation

overview

After executing t h e o verview you

see

t h e following result

(Figure 8.9):

©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

8.9:

Results

of t h e

valuation

analysis

In

t h i s

image, you can see which valuation strategies

are

a s si g n ed

to

y our record types.

You can

see that

f o r

each

record

type,

on

one hand

t h e

material costing

i s

processed

and on

t h e

other,

user

e x i t

U01.

This

valuation analysis offers users t h e advantage that

t h e y

can see what

i s

set without requiring customizing

authorizations.



Overview o f D eriva tio n

Figure

8.10

shows

t h e i n i t i a l

screen

f o r

t h e

derivation

o verview.

©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

8.10:

I n i t i a l

screen

of

t h e

derivation

overview

When you run t h e

derivation

o verview,

f o r

each derived

characteristic

you

receive a

lo g

of

t h e

source and target

f i e l d s .

You

can

use

t h e s e

to

a n a l y z e precisely whether

t h e


i s

w orking

correctly ( s e e

Figure

8.11). This

i s

shown

f o r

derivation s t e p

11

as an example.



©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

8.11:

Partial

lo g

as

results

of

t h e

derivation overview

Report

Overview

The i n i t i a l screen

of

t h e

report o verview

i n t h e

Cust o mizin g

Monitor looks

as

shown

i n

Figure 8.12.



©

Copyrigh t

SAP

AG.

A l l

rights

reserved.

Figure

8.12:

I n i t i a l

screen

of t h e

report

overview

When

you

run

t h e

report o verview,

you

receive

an

o verview

of

t h e

f i e l d s

used

i n

a p r o f i t a b i l i t y report together with

information

a b o u t

how

t h e y

are

used

( s e e

Figure

8.13).



©

Copyrigh t

SAP

AG.

A l l

rights

reserved.

Figure

.13:

Results

of t h e

report

overview

R(D) ” denotes a

report

characteristic

f o r

which further

drilldown

i s

possible. “F(N)” denotes a characteristic f r o m a



f o r m

f o r

which drilldown

i s

no t possible.

Summarization Level Overview

In

t h i s

o verview,

you

can see

t h e


levels

created

f o r

your

operating

concern,

as

well

as t h e

characteristics used

f o r


( s e e

Figure

8.14).

©

Copyrigh t

SAPAG.

A l l

rights

reserved.

Figure

8.14:

Overview

of

summarization

levels

8.2.2

Simulating

Documents

Now

that

you

have

been able

to

check

y our

COPA

customizing

intensively

i n

t h e

s t e p s described a b o v e ,

i n t h e

further substeps

of

t h e ANALYZE VALUE

FLOWS

item,

CO



PA e n a b l e s

you

to

simulate documents.

F o r t h e

invoice

transfer

and

s ales o rder transfer items, you have

to

specify

an SD document.

In

t h e

analysis,

you can t h e n trace

t h e

be ha vi or

of

COPA

f o r t h e

p os ting precisely. I

w i l l

explain

t h e

point

SIMULATE

VALUATION

i n more

detail

as

an

example

( s e e

Figure

8.15).

©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

8.15: Accessing t h e valuation simulation

Similarly

to

transaction KE21 (Enter

Actual

Line Items),

you

f i r s t

access

t h e

i n i t i a l

screen

( s e e

Figure

8.16).

©

Copyrigh t

SAP

AG.

A l l

rights

reserved.

Figure

8.16:

I n i t i a l

screen

for

t h e

valuation

simulation

Enter a posting date,

t h e

record type, and t h e point

of

valuation

at

which you want

to

simulate

t h e

valuation.

In

t h e



next step,

specify

some


( s e e

Figure

8.17).

©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

8.17:

En try

of

characteristics

for

t h e valuation

simulation

We

want

to

run

t h e

simulation

f o r customer

K1

and

product

A1 f r o m

o ur

example data. However,

f i r s t we

want

to

check

whether

t h e

derivation w ork s.

By

clicking DERIVATION,

you

can see

that further characteristics have been derived

( s e e

Figure

8.18).



©

Copyrigh t

SAP

AG.

A l l

rights

reserved.

Figure

8.18: Succes s ful characteristic derivation

for

valuation simulation

Characteristics were

derived

f o r

t h e

customer

hierarchy, t h e

product hierarchy, and t h e customer

group.

S wi tch

to t h e

VALUE

FIEL D S

t ab

and

enter a sales quantity. Then c l i c k

VALUATION.

You

get

t h e

result

shown

i n

Figure 8.19.



©

Copyrigh t

SAPAG.

A l l

rights reserved.

Figure

8.19:

Results

of

t h e

valuation

simulation

You have now

go t to

know

two

COPA tools t h a t ,

i n my

opinion, are important. This

i s

a l m o s t

t h e

end of t h e

b o ok.

The

next

chapter contains a

few

closing w o rd s .



9

Closing Words

The

aim

of

t h i s

book

was to

s h a r e

my

experiences

i n CO

PA with

you

i n

a userfriendly way and to give you a quick

guide

to

SAP


You

now

know what

CO

PA

i s . By

t h e

time

you come

to

t h e s e closing

w o rd s,

you

w i l l

be able

to e x p r e s s yourself

i n

discussions and meeting s and

be able

to

s hine

as a

true

COPA expert. I f you want

to

implement

COPA,

use my

t i p s

and

you

w i l l

implement

a

COPA that

you

can

work

with intensively

i n t h e

future.

I

w i s h you every success i n

t h e

supreme module of

t h e

SAP

ERP

s y s t e m .

Göttingen,

September 2012

S t e f a n

E i f l e r



Learn more

about

new ebooks?

Get

exclusive

free

downloads

Sign

up f or our ne w s le t ter



A

The Author

S t e f a n E i f l e r has worked as

an

external and internal SAP

consultant f o r

more

t h a n

17

years, focusing

on

CO. He

specializes i n P r o f i t a b i l i t y Analysis

(COPA).

After completing

his bu sines s studies

degree

at

t h e

Ruhr

Universität

Bochum, Germany,

he

began

work

as

an

external

SAP

consultant

at COPA

GmbH,

a

consultancy

specializing

i n

t h e beverages

industry. He

has implemented

t h e module CO,

always

including COPA, successfully

and

on

schedule

at many

wellknown

companies

i n

t h e

beverages industry, such as CocaCola, Veltins, Schwarze,

Amecke, Berentzen,

and

Schneider Weisse.

After marrying

his wife Karin

and

while awaiting

t h e

b i r t h

of

his

son

Jan

Lukas,

S t e f a n

accepted

an

offer

f r o m

BerentzenGruppe

AG

to

work

there

as

an

inhouse

SAP

consultant. There,

as

lead

f o r controlling

projects,

i n

addition

to many

SAP

projects,

such as

t h e

implementation

of

SAPR/3 when t h e Berentzen

companies

were

merged

into

one

company,

he

led projects



such

as

t h e

implementation

of

international reporting (IFRS)

f o r December 31, 2005.

In

additional

roles such

as

sales

and production controller, S t e f a n

was

able

to ga t her

a l o t

of

practical experience

i n

controlling.

Thanks

to his

h o l i s t i c

bu sines s training,

he

was also

t h e

r i s k manager

f o r

BerentzenGruppe

AG

and

s u p p o r t ed

numerous

internal

and

external

students with

t h e i r

degree

dissertations

and

theses.

S i n ce F e b rua r y

2012,

S t e f a n

has

been w orking

at

t h e global

company Sartorius AG

i n

Göttingen, Germany,

as

an

i n

house consultant

f o r CO

and

PS

(Project

S y s t e m ) ,

enabling

him

to

ga t her

deeper

international

experience.



C

Disclaimer

Names

used

i n t h i s

b o o k,

trade

names,

commodity

names

etc.

can

be

brands even though

t h e y

have

no

marking

and

as such

are

subject

to

legal

requirements.

A l l s c ree n s h o t s printed i n

t h i s book are

subject

to

copyright

of SAP

AG, DietmarHoppAllee 16, 69190 Walldorf,

Germany.

This publication makes

reference to

products

of

SAP

AG.

SAP,

R/3,

SAP

NetWeaver,

Duet, P a rt nerEdge, ByDesign,

SAP Busine ss O bject s Explorer, StreamWork, and o t her

SAP

products

and

services mentioned

i n

t h e t e x t ,

as

well

as

t h e respective logos,

are trademarks

o r

registered

trademarks

of

SAP AG i n Germany

and i n

o t h e r coun t rie s

worldwide. Business

Objects

and

t h e

Busine ss O bject s logo,

BusinessObjects, Crystal

Reports, Crystal

Decisions,

Web

Intelligence, Xcelsius, and o t her Business O bjec t s

products

and services mentioned

i n t h e

text as

well

as

t h e respective

l o g o s

are

trademarks

o r

registered trademarks

of

Business

O bjec t s S o f t w a r e Ltd. Business O bjec t s

i s

a

company

i n

t h e

SAP AG group. Sybase

and

Adaptive Server, iAnywhere,

Sybase

365,

SQL Anywhere,

and

o t her

Sybase products

and services mentioned

i n t h e

text as

well

as

t h e respective

l o g o s

are

trademarks

o r registered

trademarks

of

Sybase

Inc.

Sybase

i s

a company

i n

t h e

SAP

AG

group. A l l

o t her

names

of

products and services are trademarks

of t h e

respective companies. The details i n t h e text are n o t b in din g

and are

f o r

information purposes only.

Products

may

d i f f e r

f r o m

country

to

country.

SAP

Group

shall

no t

be

l i a b l e

f o r

erro rs o r

o m i s si o n s

i n

t h i s

publication.

The

only

warranties f o r SAP Group

products

and services

are

t h o s e

that

are set

forth i n t h e

e x p re s s

w arran t y s t a t e m e n t s accompanying such products and

services,

i f

a n y.

No further l i a b i l i t y

arises f r o m

t h e



information

contained

i n t h i s

publication.



Ulrich

Schlüter

Jörg

Siebert

SAP®HANA f or ERP Financials

Basic principles of SAPHANA



Potential of inmemory tec hn ol og y

Presentation

of

existing

HANA applications

i n

Financials

I l l u s t r a t i v e

examples,

su p p o r t ed

by

videos

Wit h t h e i r

latest

database

tec hn ol og y

High

Performance

Analytic

Appliance

(HANA), SAP

i s

trying

no less t h a n

to

revolutionize

t h e

database market, speed

up

evaluations,

and change busine ss

processes

fundamentally.



Anurag

Barua

First Steps

in

SAP® Cry s tal Reports f or Business Users

When

SAP

acquired

Business O bjec t s

i n

2008

Crystal



Michael

Esser

Investment P r o j ect Co n t r o l lin g

w i t h SAP®

This

book

i s

a

practical guide f o r b us in es s us ers

to

f u l l y