9/20/2020

Controlling (CO)
Generated on: 2020-09-20

SAP S/4HANA | 1909 FPS02 (May 2020)

PUBLIC

Original content: https://help.sap.com/viewer/5e23dc8fe9be4fd496f8ab556667ea05/1909.002/en-US

Warning

This document has been generated from the SAP Help Portal and is an incomplete version of the official SAP product
documentation. The information included in custom documentation may not re ect the arrangement of topics in the SAP Help
Portal, and may be missing important aspects and/or correlations to other topics. For this reason, it is not for productive use.

For more information, please visit the https://help.sap.com/viewer/disclaimer.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a4… 1/85
9/20/2020

Margin Analysis
With the Margin Analysis functionality, cost and revenue information is always current and 100% reconciled with the income
statement.

This ensures greater transparency and makes the information easy to use.

Transparency is achieved by means of journal entries, which represent the single source of truth for nancial data. Pro tability
reporting is based on income statement items, allowing drilldowns on any characteristic, for example the product group:

Income Statement for Legal and Management Reporting

In addition to income statement items which carry a true account assignment to a pro tability segment, a pro tability segment
can also be derived for additional income statement items and recorded in the journal entry. This is based on the “best-guess”
principle, using the information that is available at that point in time. A re nement of the pro tability characteristics at period end
is still possible with the closing transactions such as settlement, allocation, and top-down distribution.

 Note
The technical basis for Margin Analysis is account-based pro tability analysis. Therefore, when you activate pro tability
analysis you need to select the account-based type of pro tability analysis.

See: Activating Pro tability Analysis

The pro tability characteristics are determined through the operating concern and can be re ned by the tools of pro tability
analysis. When the operating concern is generated, all characteristics not yet available, including customer-speci c
characteristics, are appended to the journal entry and lled during posting.

Example: Sell from stock with the processes Delivery and Billing
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a4… 2/85
9/20/2020
The powerful CO-PA derivation tool is also available, allowing completely new evaluations on a timely basis at the point of posting.

 Example
Cost center C100 performs work exclusively for product group P1. You create a derivation step that assigns product group P1 to
cost center C100. When postings are made to cost center C100, such as for labor costs or credits from time reporting, product
group P1 is selected and persisted in the corresponding income statement item. These journal entry items are then read in
product group reporting.

By assigning the market segment to primary postings based on such derivations, it is possible to report not only on the account
assignment but also on the market segment for certain primary accounts.

Derivation of market segments early in the process will generally eliminate the need for some of the period closing activities.

The cost of sales, which in the sell-from-stock scenario is posted to inventory changes upon delivery, is based on the cost estimate
from the cost component split with its speci c income statement items.

The price differences from production can be broken down into individual items. See De ning Accounts for Splitting Price
Differences.

This achieves multilevel gross margin reporting in the income statement with drilldown on any market segment.

 Note
Be aware of the difference between income statement items with true account assignment to a pro tability segment and so-
called attributed items:

Income statement items with true account assignment to a pro tability segment are part of processes such as
settlement, allocation, and top-down distribution.

Attributed items only appear in reports.

An income statement item has a true account assignment to a pro tability segment in cases such as the following:

The item is already determined in a logistical document such as a sales order or billing document.

A manual account assignment is performed via the CO-PA account assignment screen, for example for manual FI
postings.

For the G/L account referenced in the income statement item, automatic account assignment to a pro tability segment
has been de ned in Customizing.

For income statement items without a true account assignment to a pro tability segment (for example, items assigned to
orders, WBS elements, or sales order items), an attributed pro tability segment can be determined when the journal entry is
created. This functionality can be activated in Customizing. Further information can be found in Pro tability Characteristics in
Journal Entries.

In both cases the available data is enriched, for example by accessing CO-PA derivation, and the result is written to the income
statement item based on certain restrictions. Details can be found in Pro tability Characteristics in Journal Entries.

More Information
Pro tability Analysis

Structures and Master Data

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a4… 3/85
9/20/2020
Pro tability analysis requires structures and master data as its basic elements. This document describes the different elements of
the account-based type of pro tability analysis, which is the basis of Margin Analysis.

To use the functions of pro tability analysis, you rst need to create structures. The possible reporting levels are determined by
the creation and derivation of characteristics.

Features
To create the structures, you de ne:

The operating concern

The characteristics belonging to the operating concern

For example, in the operating concern you can de ne your structures such that the revenues and sales deductions (income
statement line items) correspond to the Customer, Customer Group, Sales Office, and Product levels (characteristics).

Integration
Structures are closely linked to master data. Master data consists of the individual values that the characteristics can assume.

The particular combination of characteristic values determines the analysis object, and therefore the reporting level. The analysis
object is the pro tability segment.

The gross margin structure can be displayed for each pro tability segment. The gross margin structure is also determined by the
income statement entities G/L Account and Functional Area. Both characteristics are required for multilevel contribution margin
accounting.

Operating Concern
An operating concern represents an organizational unit for which the sales market has a uniform structure. It is the valuation level
for pro tability analysis.

Structure
The operating concern is structured into characteristics and value elds.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a4… 4/85
9/20/2020
Characteristics

Decide which level you want to analyze, such as the sales organization, region, product, or customer.

Value Fields

Decide which values and key gures you want to analyze, such as revenues, sales deductions, costs, or quantities.

 Note
Value elds are used only in costing-based pro tability analysis. They are not used in account-based pro tability
analysis, which is the basis of Margin Analysis.

This structure will vary from one company to another. For example, the structure of total production costs in a manufacturing
company differs from that in a wholesale or retail company. Consequently, you need to model pro tability analysis in Customizing
by de ning the characteristics and value elds that you want to analyze.

The system then generates the necessary database tables for CO-PA transaction data and access programs based on how you
de ned your operating concern.

For information on the procedure for de ning an operating concern, in Customizing for Pro tability Analysis, choose
Structures De ne Operating Concern .

Characteristics for Pro tability Segments

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a4… 5/85
9/20/2020
All the characteristics in the operating concern are used in the costing-based line item. However, you can restrict the
characteristics for a pro tability segment that forms the basis for valuation. This is because it is unnecessary and impractical for a
pro tability segment to use characteristics that are almost always populated and each has a different value. You can deactivate
such characteristics when creating a pro tability segment. Otherwise the data volume of the pro tability segments may become
too large and reduce system performance.

One characteristic that should not be used in pro tability segments is the sales order in repetitive manufacturing.

Assignment of Characteristics to Pro tability Segments

You specify in Customizing which characteristics belong in which pro tability segments.

For more information, see Customizing for Pro tability Analysis under Flows of Actual Values Initial
Steps Summarization Summarization of Account-Based Line Items and Pro tability Segments . More information can be
found under Pro tability Analysis Flows of Actual Values Initial Steps Summarization .

Characteristics
Characteristics are the criteria based on which you analyze your operating results and perform differentiated sales and pro t
planning.

A combination of values for the characteristics in an operating concern is called a pro tability segment.

Source of Characteristics

The characteristics you de ne are stored in a eld catalog. Use the function Maintain Operating Concern to select characteristics
from this eld catalog to de ne your operating concerns. You can access this function in Customizing under
Controlling Pro tability Analysis Structures De ne Operating Concern Maintain Operating Concern .

Structure
The semantic meaning of a characteristic is determined by the data element to which it is assigned. The data element contains
the texts that appear on the screen and in lists for the characteristic.

The technical attributes (data type, length of the values, and value set) of a characteristic are determined by the domain. The valid
characteristic values determined in the value set by the data type and value length can also be speci ed explicitly in a check table.
If a characteristic is assigned to a check table, it can only take on those values that are contained in the check table. You can
assign texts to the values contained in the check table. These texts are displayed on the screen whenever you work with those
values.

You can arrange the values for a characteristic into a hierarchy.

 Note
Characteristics are valid in all clients.

Characteristics are available for all operating concerns.

Standard Characteristics

Fixed characteristics and prede ned characteristics are provided in the standard system.

Fixed characteristics

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a4… 6/85
9/20/2020
A number of fundamental characteristics are automatically prede ned in every operating concern. These include for
example Product Number, Company Code, Billing Type, Business Area, Sales Order, Customer, and Controlling Area.

You can see the xed characteristics in Customizing under Controlling Pro tability Analysis Structures De ne
Operating Concern Maintain Characteristics . Select the option All Characteristics, then Display Extras Fixed elds .

Prede ned characteristics

In addition to the xed characteristics, a number of other prede ned characteristics are available in the eld catalog. These
include Customer Group, Customer District, and Country. They can be added to your operating concern if desired.

De ning Your Own Characteristics

You can also de ne your own characteristics. You de ne these in the eld catalog (independent of the client or operating concern)
and can later add them to your operating concerns.

You de ne characteristics in Customizing under Controlling Pro tability Analysis Structures De ne Operating
Concern Maintain Characteristics .

There are a number of ways to de ne characteristics. The way you de ne a characteristic in uences its attributes.

Adopting Characteristics from SAP Tables

You can de ne your operating concerns by using characteristics that already exist in other applications. For example, you can
select elds from the tables for customer master records, material master records, and sales documents. You can also select the
partner roles de ned in the structure PAPARTNER in the Sales and Distribution (SD) application and use them as characteristics
in Pro tability Analysis.

The table that you take a characteristic from is referred to as that characteristic’s origin table. Characteristics that you take from
the SAP table are then derived automatically from the key elds in the SAP table. The necessary derivation steps are generated
automatically.

 Example
Your operating concern contains the characteristic Customer District, which comes from the sales data in customer master
table KNVV. The key elds of this table are the customer number, sales organization, distribution channel, and division. When
you make a posting that contains these four characteristics, the system automatically derives the correct customer district.

 Note
CO-PA characteristics can also be transferred from the structure for customer-speci c elds of coding block CI_COBL so that
these characteristics can be accessed in CO-PA as well. Structure CI_COBL is only shown in the list of SAP tables for new CO-
PA characteristics if the customer has already created the structure in the SAP system. In contrast to the characteristics that
are taken from a delivered SAP table, no derivation rules are created since these characteristics cannot be lled through CO-PA
derivation. The characteristics can only be entered manually within the application on the account assignment screen. The
elds however are available as sender characteristics in derivation.

The characteristic transferred either from SAP tables or from the CI_COBL structure inherits all the technical attributes of the
eld in the origin table, including the valid values that exist for that characteristic. These values are stored in a check table or in the
corresponding domain. In Pro tability Analysis, the characteristic can only take on values from this value set. In most cases, texts
also already exist for a characteristic with a de ned value set.

You can use the function Transfer from SAP table to transfer special characteristics such as customer hierarchies and product
hierarchies into CO-PA. You can nd speci c elds in the appropriate SAP tables.

Custom Characteristics

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a4… 7/85
9/20/2020
If the characteristic categories are insufficient for your needs, you can de ne completely new characteristics for exclusive use in
Pro tability Analysis. To derive values for these new characteristics, you need to create your own derivation rules.

To de ne such a characteristic, you specify the technical name, description, short text, title, and the data type and length of its
values. The texts you enter for this characteristic are used to identify the characteristic on transaction screens and in lists.

If you only want a characteristic to have a xed number of values (which should generally be the case), you need to create this
characteristic by maintaining corresponding values. When you do, the system automatically creates a check table and a text table
for this characteristic. You maintain the permitted values and their texts in Customizing under Controlling Pro tability
Analysis Master Data Characteristic Values Maintain Characteristic Values .

If you don't want to limit the values permitted, you can create the characteristic without maintaining any corresponding values.
Values entered later for these characteristics will only be checked by the system to see that they use the correct data type. No
texts exist for these values.

Another way of de ning characteristics is to use the option that references existing values. This lets you create a characteristic by
referencing a data element that already exists in the system. The characteristic inherits all the attributes of the data element.

 Note
It is not possible to use two characteristics with the same data element in the same operating concern.

Dependency of User-De ned Characteristics (Compounding Characteristics)

You can have a user-de ned characteristic be dependent on another characteristic in your operating concern by compounding
them. You do this in Characteristics maintenance with the Display compound function, where you specify one or more higher-level
characteristics for a user-de ned characteristic. The subordinate characteristic can only be de ned in connection with the higher-
level characteristic. This means that a characteristic value for the subordinate characteristic can only be determined when a
dependency exists linking it to the value of the higher-level characteristic. A subordinate characteristic can thus never be used on
its own.

 Example
A region de ned as Northeast only has meaning in the context of a country. The region therefore has a dependent relationship
with the country. In this example, you would assign the higher-level characteristic Country to the characteristic Region. The
characteristic Region could not, for example, be copied to a report on its own; you would have to copy the characteristic
Country as well, otherwise you would not be able to use the region as a basis for analysis.

Overview of Characteristic Categories

Characteristic Description Value De nition Example

Fixed Characteristics required by the In external applications (such as Company code

system organizational structures)

Prede ned Sample characteristics delivered In external applications (such as Customer group
by SAP MM) or in CO-PA

Copied from SAP table Reference to table eld (such as In external applications (such as Material group (MATKL)
material grouping from material MM)
master)

Custom Fields speci c to CO-PA without In CO-PA Strategic business unit (WWxxx)
origin

Related Information
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a4… 8/85
9/20/2020
Characteristic Derivation

Assigning the Operating Concern

When you transfer data to Pro tability Analysis, the appropriate operating concern is derived from the controlling area, and the
controlling area is derived from the company code.

You therefore need to assign at least one controlling area to each operating concern. Generally, you assign multiple controlling
areas to each operating concern.

 Note
Since the operating concern should re ect the structure of your sales market, a single operating concern should normally be
sufficient for your entire organization.

Prerequisites
You need to specify the data structures for the operating concern in Customizing for Pro tability Analysis under
Structures De ne Operating Concern .

Activities
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a4… 9/85
9/20/2020
Assign controlling areas to an operating concern in Customizing for the company structure under Enterprise
Structure Assignment Controlling .

Activating Pro tability Analysis

Activation of pro tability analysis for the controlling areas assigned to your operating concern is required in order to transfer
actual postings to pro tability segments and to make special plan postings.

 Note
Before you can activate pro tability analysis, controlling areas need to be assigned to an operating concern in Customizing for
the enterprise structure under Enterprise Structure Assignment Controlling .

You activate pro tability analysis for the assigned controlling areas in Customizing under Controlling Pro tability Analysis Flows
of Actual Values Activate Pro tability Analysis .

The Active indicator has the following settings:

Setting Meaning

_ Pro tability analysis is not active

2 Only costing-based pro tability analysis is active

3 Only account-based pro tability analysis is active

4 Both costing-based and account-based pro tability analysis are

active (combined pro tability analysis)

The Margin Analysis functionality is based on the account-based type of pro tability analysis. Therefore, you need to select 3 or 4
to use it.

 Note
Costing-based pro tability analysis is not integrated with journal entries and is therefore not reconciled with the income
statement.

You can specify the scal year beginning with which pro tability analysis is active for the controlling area.

When pro tability analysis is active, you can transfer actual postings to pro tability segments. For example, you can transfer
billing document data from Sales and Distribution (SD), postings from Financial Accounting (FI), or settlement of orders and
projects.

Special plan postings can also be made and transferred to pro tability analysis, for example period-based allocations such as the
transfer of planned overhead or settlement of planning data from orders and projects.

Setting the Operating Concern

Some of the functions in Pro tability Analysis require you to specify the operating concern and the type of pro tability analysis
(costing-based or account-based) you wish to use.

 Note
In order to use Margin Analysis, you need to select account-based pro tability analysis.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 10/85
9/20/2020
You set the operating concern by de ning its settings and specifying the desired type of pro tability analysis in a dialog box. The
settings in this dialog box are then valid until you log off or reset the operating concern.

There are two ways of accessing the dialog box:

In the menu of Pro tability Analysis, by choosing Environment Set Operating Concern .

In Customizing for Pro tability Analysis by choosing Structures Set Operating Concern .

When you rst call up a function that requires an operating concern, the dialog box appears automatically if the operating concern
has not yet been set.

 Tip
If you generally only work with one operating concern, it is helpful to enter this operating concern and the required type of
pro tability analysis in your user master data. The dialog box will then no longer appear the next time you log on, and the
system will use the operating concern and the type of pro tability analysis stored in your master data.

You can still access the dialog box at any time to switch to a different operating concern or to the other type of pro tability
analysis.

Master Data
In Pro tability Analysis, master data represents the basic content within the structures which you have de ned by means of
characteristics.

Features
Market segments (the pro tability segments being posted to) are created automatically based on combinations of characteristic
values. The values you specify for the characteristics form the basis for the automatic determination of pro tability segments.

You can:

Specify the possible values for the characteristics you have de ned.

Arrange characteristic values into a hierarchy.

Specify how additional, logically dependent characteristic values are derived when data is posted to CO-PA.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 11/85
9/20/2020

Characteristic Derivation
Characteristic derivation attempts to determine the values for all pro tability-relevant characteristics in business transactions.
Some characteristic values are transferred automatically and then used to determine other, logically dependent characteristics.
The derivation process uses information in the source document as well as information outside it.

The pro tability segment to which the account assignments are made is generated using the characteristic values as determined
by the derivation process.

Characteristic values that are not known in the business transaction are derived in CO-PA

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 12/85
9/20/2020

 Example
You are using Customer Group eld from the material master (table KNA1) as a characteristic in your operating concern. The
system recognizes that the customer group depends on the customer number and is therefore able to determine the customer
group KG1 for customer K1 by reading the customer master record.

Features
Characteristic derivation is performed with the following:

Manual account assignments, including:

Settling orders and projects

Direct postings from FI

Direct postings from CO, such as direct activity allocation

Only a few characteristic values have to be entered manually. The remaining characteristic values can be derived.

Automatic transfer of data from other applications, such as:

Billing documents

Overhead

Some source applications can supply values for only a few of the characteristics used in an operating concern. Characteristic
derivation lls in the remaining characteristic values, provided that they can be derived from those supplied by the source
application.

Characteristic derivation consists of a series of derivation steps (the derivation strategy). Each step can be used in turn to derive
values from other characteristics.

For each operating concern you de ne, the system generates standard derivation steps that automatically contain all known
dependencies between characteristics. The standard derivation strategy contains:

Steps for deriving xed characteristics

Steps for deriving the characteristics you selected from SAP tables

In general, you can copy the standard derivation strategy as it is. If you have created user-de ned characteristics, you should
nevertheless enhance the standard derivation strategy with several additional derivation steps, provided that logical dependencies
exist. For information on additional options for changing the standard derivation strategy, see Changing the Standard Derivation
Steps.

Each derivation step describes how a group of target elds can be populated with values derived from a group of source elds.
One or more values are derived from the combination of values in the source elds and then entered into the target elds. For
information on which elds are valid as source elds and target elds, see Source and Target Fields.

There are different derivation types to represent the different logical dependencies between source and target elds. For more
information, see Derivation Types.

You can modify the order for processing the individual derivation steps by entering conditions governing how the step is carried
out and by specifying step and eld attributes. For more information, see In uencing the Standard Derivation Procedure.

Activities

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 13/85
9/20/2020
To access characteristic derivation, in Customizing for Pro tability Analysis, choose Master Data De ne Characteristic
Derivation .

Then, by choosing View Display All Steps , you can see all derivation steps in the derivation strategy for your operating concern.

 Note
Even though you need to specify (apart from the operating concern) the type of pro tability analysis upon starting
characteristic derivation, the derivation strategy is independent of the type of pro tability analysis you entered.

As most of the characteristics coincide between costing-based and account-based pro tability analysis, this normally leads to
the same results for costing-based and account-based postings. Nevertheless, some elds differ between the two types, such
as the unit of measure.

Therefore, for an account-based posting, derivation steps concerning elds only known in costing-based pro tability analysis
would still be executed but would have no effect on the posting itself and vice versa.

Activities
You access the settings for characteristic derivation in Customizing for Pro tability Analysis under Master Data De ne
Characteristic Derivation .

By choosing View Display All Steps , you can display all derivation steps in the derivation strategy for your operating concern.

Derivation Types
Each step in the process of deriving characteristic values can be realized by a different derivation type. The available derivation
types are:

Derivation Rule

Table Lookup

Move

Clear

Customer Hierarchy

Customer Enhancement

Features

Derivation Rule

A derivation rule represents an IF-THEN condition that speci es which source characteristic values (or combinations of values)
result in which target characteristic values.

For example, the Strategic Business Unit can be derived from the Product Group:

Product Group 100 to 105 → Strategic Business Unit Electronics

Product Group 106 to 110 → Strategic Business Unit Multimedia

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 14/85
9/20/2020
To create a derivation rule, rst enter the source and target elds in Customizing for characteristic derivation, along with the
conditions and step attributes. You can enter the actual characteristic values either in Customizing by choosing Maintain Rule
Values or in the application by choosing Master Data Maintain Derivation Rules . In either case, you can also enter the validity
period.

Table Lookup

Table lookups allow you to read individual records of any table to determine characteristic values. Here the source elds must
make up the key of a speci c table, from which the system can copy certain contents to the target elds.

When you generate the environment for your operating concern, table lookups are generated automatically for all characteristics
that you choose from prede ned SAP tables.

Move

Moves allow you to copy a constant or the content of any source eld to a target eld. For example, you can copy the value of a
characteristic to another eld if certain conditions are ful lled.

Clear

Clears allow you to delete the value of a characteristic, setting that eld back to its initial value (blank for CHAR elds, 0 for NUMC
elds).

Customer Hierarchy

 Note
This derivation type can only be used if you have maintained the assignment of the customer hierarchy in SD to the CO-PA
auxiliary structure PAPARTNER (see the procedure below).

In Sales and Distribution (SD), you can subdivide your customers into hierarchical structures. You can use characteristic
derivation to transfer these structures (up to ten levels) to Pro tability Analysis. This involves deriving the customer hierarchy
from the customer hierarchy type, the sales organization, the distribution channel and the division.

Derivation with customer hierarchy

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 15/85
9/20/2020
To derive the characteristics of the customer hierarchy, you need to de ne the Customer hierarchy derivation step.

In order to use this derivation type, you rst need to maintain the assignment of the customer hierarchy in SD to the CO-PA
auxiliary structure PAPARTNER. The HIEZU01 to HIEZU10 elds are available as valuation levels in this auxiliary structure and
can be transferred to CO-PA as characteristics. SD customer hierarchy nodes are assigned to the evaluation levels in CO-PA when
the customer master records for the hierarchy nodes in the customer hierarchy are maintained. For this, you need to maintain the
Hierarchy assignment eld on the Marketing screens of the master record. If the eld is locked against manual entry, you need to
unlock it by maintaining the eld status for customer master records.

The characteristics that are used to derive the customer hierarchy are automatically entered in this step as the source elds.
These are: Sales Organization, Distribution Channel, Division, and Customer. The characteristics you de ned for the customer
hierarchy in your operating concern are automatically de ned as the target elds.

All you need to maintain for the Customer hierarchy derivation step is the customer hierarchy type that you want to use for
pro tability analysis.

Customer Enhancement

In cases where the standard derivation types do not ful ll your requirements, you can use a customer enhancement (COPA0001,
component 003). This enhancement can be called up at any point in your derivation strategy, even more than once.

 Note
Before using this enhancement, be sure that you can achieve the desired effect by doing the following:

1. De ne steps with other derivation types that use conditions, step, and eld attributes (see In uencing the Standard
Derivation Procedure) as well as temporary intermediate elds (see Source and Target Fields).

2. Sort the steps properly in your strategy. This will help you avoid any unnecessary reprogramming if you upgrade to a
new release.

You can de ne customer enhancements in the Customizing activity under Tools SAP Enhancements . There you will nd the
technical information needed to set up a customer enhancement.

Examples
The following shows some examples of the use of derivation types.

Derivation Rule

In the following example, Strategic Business Unit is a user-de ned characteristic in your operating concern. The strategic business
unit (target eld) is determined on the basis of the product group (source eld). The Maintain entries using validity date step
attribute is activated.

You enter the following values:

Product Group Valid From Strategic Business Unit

100 January 1 Electronics

200 to 299 January 1 Multimedia

200 to 399 June 1 Multimedia

Table Lookup

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 16/85
9/20/2020
Normally, the Country characteristic is derived using an automatically created derivation step (table lookup in customer master
table KNA1) that takes the Customer characteristic (KNDNR) as the source eld. In the following example, the country (WWCST) is
derived using a table lookup (in customer master table KNA1) with the ship-to party (KUNWE) as the source eld. The Ship-To
Party characteristic has been copied to Pro tability Analysis from the PAPARTNER SD structure.

Table lookups using source elds:

Origin Field Name = Origin Field Name Description

KNA1 KUNNR = CO-PA KUNWE Ship-to party

Moving table elds to target elds:

Origin Field Name = Origin Field Name Description

KNA1 LAND1 = CO-PA WWCST Ship-to country

Move

The following move copies the customer (KNDNR) to the ship to party (KUNWE) if no ship-to party is contained in the ship-to eld:

Source eld KNDNR Customer

Target eld KUNWE Ship-to party

Under Condition, enter the following for this step:

Origin Name Description Operator Value

CO-PA KUNWE Ship-to party =

Clear

Since the Representative characteristic (VRTNR) is not relevant for analysis in certain divisions, you use the following clear so that
this characteristic is not populated for the condition speci ed below.

You therefore want to clear the following eld:

Origin Field

CO-PA VRTNR

Under Condition, enter the following:

Name Description Operator Value

SPART Division = (05) Machine sales

Special Case: Table Lookup in Table VBKD

When you de ne a table lookup for table VBKD (Sales document: Business data), data does not have to be present for every item
in the sales document. If the item data is no different than the header data, it is not additionally stored in the item. In this case, you
can nd the valid values in the header data, which is stored in table VBKD under the item number 000000.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 17/85
9/20/2020
Thus, if you want to read characteristic values from VBKD, you always need to de ne two table lookups.

 Example
You want the system to read the KDGRP eld (customer group) from table VBKD and enter the value contained there in the
temporary eld GLOBAL USERTEMP1, so that you can use the customer group to derive other characteristics.

To achieve this, you create the following steps:

Step Derivation Type

1 Table lookup in table VBKD using the KAUFN key and KDPOS; Copy
content of the KDGRP eld to the GLOBAL USERTEMP1
characteristic.

2 Table lookup in table VBKD using the KAUFN key and KDPOS. For
KDPOS, you de ne eld attributes stating that the constant
000000 should be used here. Then copy KDGRP to GLOBAL
USERTEMP1.

In the rst step, the system attempts to read the item data. But since this information is not stored explicitly, the GLOBAL
USERTEMP1 eld remains blank. The system then carries out step 2, which reads the header data.

If you have used the GLOBAL USERTEMP1 eld for other purposes earlier in the strategy, be sure to clear its contents rst.

Source and Target Fields

You enter the source and target elds for derivation in a derivation step.

Source Fields
You can use the following operating concern elds as source elds:

All xed characteristics

Prede ned characteristics

All user-de ned characteristics (characteristics copied from an SAP table, characteristics created from scratch, and
characteristics transferred from CI_COBL)

All characteristics copied from customer hierarchies (CO-PA HIE01 to HIE10)

All quantity unit elds

Generally, you cannot use technical elds for derivation because these elds are not usually available during derivation. No
technical elds are located at the segment level (table CE4xxxx, where xxxx is the operating concern). Fields at the segment level
serve as the basis for characteristic derivation.

Only the following technical elds are available for use in characteristic derivation:

The sender cost center (CO-PA SKOST) in cost center assessment and cost center activity allocation

The sender business process (CO-PA PRZNR) in process assessment and process activity allocation

Cost element (CO-PA KSTAR) for direct postings from nancial accounting, for actual settlement, and in assessment and
actual activity allocation

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 18/85
9/20/2020
Activity type (CO-PA LSTAR) for actual activity allocation

In addition, you can use as source elds those indicators that lend themselves particularly well in step conditions. This applies to
the following:

The plan/actual indicator (GLOBAL PLIKZ) with actual value 0 and plan value 1.

If you use this indicator, you can de ne derivation steps that only occur in planning, for example.

The account assignment category (GLOBAL ACCASTY) and partner account assignment category (GLOBAL
PACCASTY)

If you have activated the determination of so-called attributed pro tability segments for account-based line items posted
to G/L line item table ACDOCA (see Pro tability Characteristics in Journal Entries), you can use these two elds to de ne
derivation steps which depend on the (partner) account assignment category, which is the category of the true (partner)
account assignment of these line items, for example cost center, internal order, or WBS element.

Both elds therefore use the same value set. Currently only the following account assignment categories are supported for
such line items:

Internal order

Sales order item

WBS element

Cost center

Cost center / Activity type

In the case of account-based line items with true (partner) account assignment to pro tability segment, the corresponding
category is offered as well.

If you want to de ne a condition on these elds, you must enter a three-digit language-dependent code. Input help is
available for this purpose. You can also nd these values in eld OBART_LD of table TBO01.

The internal representation of the account assignment category and partner account assignment category is however only
two digits and can be found in eld OBART of table TBO01.

If you need to code the derivation exit EXIT_SAPLKEDRCOPA_001 (Include ZXKKEU11) in enhancement COPA0001,
you therefore need to consider the internal two-digit representation.

The table below lists the internal representations (the external representations are language-dependent and thus cannot
be listed):

Account Assignment Category Internal Representation

Pro tability segment EO

Internal order OR

Sales order item VB

WBS element PR

Cost center KS

Cost center / Activity type KL

 Note

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 19/85
9/20/2020
The account assignment category GLOBAL ACCASTY is always lled, even in the case of true account assignment to
pro tability segment.

The partner account assignment category GLOBAL PACCASTY, on the other hand, is only lled for internal allocations
where cost or revenue is allocated from a sender to a receiver (for example, direct activity allocations or reposting of
revenues). Even in this case, however, it is only lled when CO-PA derivation is called for the determination of an
attributed pro tability segment directly before posting the account-based line items to table ACDOCA. It is not lled for
processes other than internal allocations. Nor is it lled for internal allocations where the receiver object is a pro tability
segment and where derivation is called for that pro tability segment, because the information about the partner
account assignment is not available there.

An indicator to show whether Pro t Center Accounting is active (GLOBAL PCAACTIVE) using the value " " (SPACE) for
inactive and the value "X" for active.

If you create your own derivation steps for populating your pro t centers, you can set this indicator as a condition.

An indicator using the values " " (SPACE) and "X" to show whether characteristic derivation is being called up from
realignments (GLOBAL REALIGNMENT_MODE).

If certain derivation steps are not to be performed in the case of realignments, or if they are only to be performed in the
case of realignments, you can set this indicator to be called up by the system in the condition.

For more information, see Realignment.

Furthermore the following information is provided:

The dummy pro t center (GLOBAL DUMMYPRCTR), if you want to ll the Pro t Center accordingly.

The calendar year of the derivation date (GLOBAL CYEAR)

The current user (GLOBAL USERNAME)

It can sometimes be useful to store intermediate results for the derivation of characteristics. The temporary elds GLOBAL
USERTEMP1 to GLOBAL USERTEMP8 enable you to do this.

Finally, you can also choose from the characteristics in the variant con guration (con gurable materials):

Characteristics in the variant con guration (VCONF NAME)

If sales order items are entered with con gurable materials, you may wish to determine characteristic values for CO-PA
characteristics independently of the values in the variant con guration. You can also create derivation steps that have
characteristics from the variant con guration as source elds.

When de ning the source elds, you can enter as a source eld name all the characteristics from the variant con guration
system that have character-based or numeric names.

 Note
The possible entries function for the source elds does not list all the characteristics in the variant con guration. Only
the substitute eld VCONF ? is offered.

The values entered for the variant con guration are not checked for compatibility with the derivation logic. This means
that any potentially invalid characteristic values in the variant con guration are not rejected.

The system only executes a derivation step containing characteristics from the variant con guration if a sales order item
contains a con gurable material with which these characteristics were originally entered into the con guration.

 Example
Within variant con guration itself, you de ne the characteristics COLOR and SIZE with which material 1000 is valued.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 20/85
9/20/2020
For the pro tability report, you are interested in whether a standard color or a special color is involved, and which size
category the material has. You therefore de ne in CO-PA the characteristic WWCOL (color type) with the values Standard
and Special, and the characteristic WWSIZ (size category) with the values Small, Medium, and Large.

You then create the following derivation rules:

Derivation rule: Specify color type

Source eld: VCONF COLOR

Target eld: CO-PA WWCOL

Rule values:

RED = Standard

BLACK = Standard

WHITE = Standard

APRICOT = Special

MAGENTA = Special

Derivation rule: Specify size category

Source eld: VCONF SIZE

Target eld: CO-PA WWSIZ

Rule values:

0 – 9.9 = Small

10 – 19.9 = Medium

20 – 100 = Large

Target Fields
You can use the following elds as target elds for derivation:

Prede ned characteristics

All user-de ned characteristics (characteristics copied from an SAP table and characteristics created from scratch)
excluded transferred characteristics from CI_COBL

All characteristics copied from customer hierarchies (CO-PA HIE01 to HIE10)

Only the following xed characteristics:

Customer number (CO-PA KNDNR)

Product number (CO-PA ARTNR)

Business area (CO-PA GSBER)

Pro t center (CO-PA PRCTR)

Partner pro t center (CO-PA PPRCTR)

Sales organization (CO-PA VKORG)

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 21/85
9/20/2020
Distribution channel (CO-PA VTWEG)

Division (CO-PA SPART)

Plant (CO-PA WERKS)

Functional area (CO-PA FKBER)

Temporary elds (GLOBAL USERTEMP1 to GLOBAL USERTEMP8)

In uencing the Standard Derivation

Procedure
The standard derivation procedure runs as follows:

1. If you have speci ed any conditions for running a derivation step (see below), the conditions are checked. If the conditions
are not ful lled, the step is ignored.

2. The source elds are checked to make sure they contain values. If one of the source elds is initial (blank for CHAR elds or
"0" for NUMC elds), no derivation is performed.

3. Provided that some of the target elds for the derivation step are not yet populated with values, the step is carried out. If
values are found, they are entered in the corresponding target elds, provided that those elds do not already contain a
value. Fields that already contain values are not changed.

4. If no target values can be found in the derivation step to match the speci ed source eld values, all the target elds remain
unchanged. For most derivation types no error message is displayed. However, if the step is a derivation rule and no
suitable target values are found, an error message is issued by default.

This means that the default settings no longer allow elds that already contain values to be overwritten in characteristic
derivation.

 Note
The account assignment screen in CO-PA (dialog box Assignment to a Pro tability Segment), in particular, operates
according to its own logic to determine which target elds are to be derived again and which ones do not need to be changed.
You can use the derivation analysis function in the account assignment screen to perceive how this screen interacts with
characteristic derivation.

Features
You can modify the standard derivation procedure by using conditions such as step and eld attributes.

Requirement

For each derivation step, you can specify the condition under which the step should be executed. You do this by choosing
Condition. A condition consists of a series of partial criteria that compare characteristics with the values they must have.

 Example
You want a step to be executed only if the sales organization is 0010 and the product number is greater than or equal to P-100
and less than or equal to P-199. Enter the following under Conditions:

Origin Name Description Operand Value Description

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 22/85
9/20/2020

Origin Name Description Operand Value Description

CO-PA ARTNR Product number >= P-100 Pump 100

CO-PA ARTNR Product number <= P-199 Pump 199

 Note
The product number is a character eld, not a numeric eld. For this reason, the greater than/less than criterion operates
alphabetically according to the computer character set. This means for example that product number 100 is interpreted as
being less than product number 20, since 100 begins with 1 and 20 begins with 2.

Step Attributes

In the step attributes, you can choose Attributes to specify for each derivation step whether an error message should appear if no
target values are found. For derivation rules, this option is automatically set as the default setting. If you do not want to maintain
derivation rule values for every possible combination of source values, you should deactivate this error message display.

You can include the following additional step attributes in the derivation rules:

It should be possible to maintain rule values using the validity date

If you activate this attribute, you can then make derivation rule entries for rules that have a Valid From date.

Optimize callup: no maintenance of from/to values.

If you can do without from/to values for rule entry maintenance, it is advisable that you activate this attribute. This speeds
up characteristic derivation.

Step ID for Direct Call

This attribute is normally not required. It is only useful if you program, for example, a batch input for the data input
transaction KEDE and want to directly access maintenance for a speci c rule. To activate this attribute, choose
Jump Direct call using step ID . You can then enter one of the available step IDs.

Field Attributes

By using , you can specify eld attributes for source and target elds.

For each source eld, you can make a setting allowing it to contain initial values. This enables the system to perform
derivation even if the source eld does not contain a characteristic value.

For each target eld, you can specify whether the step should overwrite the existing characteristic value. This ensures that
the value determined in this step will always be copied to the target eld, even if that eld already contains another value.

In the case of table callups, you can choose further options for selecting eld attributes for source and target elds. For example,
you can choose to consider just one part of each eld.

Changing the Standard Derivation Steps

For each operating concern, standard derivation steps are generated automatically to de ne all known dependencies between
characteristics. You can see these standard derivation steps by choosing View Display All Steps .

You can also change the automatically generated derivation steps and add new steps. For example, you can de ne logically
dependent chains of derivation steps or make it possible to perform multiple derivation attempts for the same target eld.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 23/85
9/20/2020

 Example
Example of a Logical Chain

You have de ned the Market Region and Responsibility Area characteristics. Market Region is derived from the country, and
Responsibility Area is derived from a combination of division and market region.

Source Field Target Field

Country → Market Region

Division, Market Region → Responsibility Area

In this case the order of the derivation steps is essential. First, the country and (if possible) the division are determined. Then
the market region is derived from the country, and then the responsibility area can be found. The sequence of the derivation
steps, including the default steps de ned by the system for deriving the division and the country, is thus as follows:

Step Derivation Derivation Type

1 Customer → Country Created automatically; Table lookup in customer

master

2 Product → Division Created automatically; Table lookup in material

master

3 Country → Market Region User-de ned derivation rule

4 Division/Market Region → Responsibility Area User-de ned derivation rule

 Example
Example for Multiple Derivation Attempts

You have de ned a Customer Group characteristic. You normally want this customer group to be derived from the customer
class, which is stored in the customer master table. For some customers, though, you also want the customer group to depend
on the division.

To achieve this, you need to create two derivation steps:

Step Derivation Derivation Type

1 Customer, Division → Customer Group Derivation rule

2 Customer → Customer Group; Read customer Table lookups

master and copy the customer class

For the rst step, you need to make the corresponding derivation rule entries to de ne all the instances where a differentiated
customer group should depend on the customer and the division. If no customer group is stored for a given combination of
customer and division, the system carries out the second step, which then supplies it from the customer master. If the rst
step is successful, the second step is not carried out, since for each step the system rst checks with each step whether the
target eld has already been lled.

 Note
When you create a new derivation rule, the system always de nes Display error message as the default reaction for instances
where no target value is found. To achieve the effect described above, you need to deactivate the error message in step 1. You
do this by choosing Attributes. See In uencing the Standard Derivation Procedure.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 24/85
9/20/2020

 Example
The following is an example of a useful derivation strategy.

1. Derivation of xed characteristics

2. Derivation using derivation rules

3. Derivation using table lookups

4. Derivation of the customer hierarchy

5. Derivation of the product hierarchy

6. Derivation of the region

7. Derivation via assignment or clear

8. Derivation via SAP enhancements

9. Derivation of units of measure

Features

Adding New Derivation Steps

If you have de ned your own characteristics and want have their values derived automatically from other characteristics, you need
to add your steps to the standard derivation steps. Moreover, it may also be necessary to create additional steps in order to
represent logical chains or multiple derivation attempts.

Changing a Standard Derivation Step

For the standard derivation steps, the system defaults the dependency that usually yields the desired result. In rare instances,
however, it may make sense to change a default derivation step since characteristics can be determined using different alternative
dependencies.

On the other hand, you cannot change all of the standard derivation steps. Only the standard steps for characteristics taken from
SAP tables can be changed. The steps for xed characteristics and unit elds cannot be changed. You can display all modi able
derivation steps by choosing View Modi able Steps .

 Example
You select the Country and Customer Group characteristics from the customer master table KNA1. By default, the values for
these characteristics are derived based on the sold-to party. If you want to derive values for Country and Customer Group from
the ship-to party instead, you need to change the source eld for the standard derivation step accordingly.

Deleting a Standard Derivation Step

You can delete all user-de ned derivation steps. In addition, you can delete the standard steps provided that they are modi able
(see above). Deleting a derivation step makes sense if you want to de ne your own step to derive the values for a characteristic
taken from an SAP table. If you delete a standard step, you should always make sure that you have de ned your own step to derive
values for that characteristic. If no other step exists for that characteristic, the system will recreate the deleted step the next time
you generate the environment of your operating concern.

Sorting Derivation Steps

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 25/85
9/20/2020
It may be necessary to change the order of the prede ned derivation steps in order to achieve a logical sequence of
interdependent steps or to de ne multiple derivation attempts to populate a eld.

Characteristics Hierarchy
Characteristics hierarchies contain the values for a single characteristic arranged into a hierarchical relationship. For example, you
can structure your products or customers into a hierarchy. The hierarchies can be analyzed in the information system.

You can de ne alternative hierarchies for the same characteristic in order to simulate different ways of grouping the characteristic
values. These alternative hierarchies are stored as hierarchy variants.

Structure
Characteristics hierarchies consist of nodes to which values can be posted. It is also possible to de ne nodes that cannot contain
values and only serve to structure the hierarchy (nonchargable nodes).

Characteristics hierarchy

De ning Characteristics Hierarchies

You de ne characteristics hierarchies in Customizing under Controlling Pro tability Analysis Master Data Characteristic
Values De ne Characteristics Hierarchy .

Related Information
Characteristics
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 26/85
9/20/2020

Realignment
Realignments enable you to update and adjust your posted pro tability data following organizational changes, to correct
inconsistencies, or to enrich the data with information that was not available at the time of the original posting.

You can perform a realignment for the following purposes:

To re ect organizational changes in your product, customer, or sales structure

For example, if a customer was originally assigned to sales region North but then reassigned to sales region West,
realignment allows you to have this organizational change updated to the posted pro tability data.

To correct inconsistencies in cases where organizational information was incorrectly assigned at the time of the original
posting

For example, if the wrong customer group was entered in the customer master data, this customer group will be written to
pro tability analysis when billing documents are posted. You can correct this error with a realignment.

To enrich the data with information that was not available at the time of the original posting

Consider a situation where attributed pro tability segment determination is activated for posting to a WBS element in a
customer project. When a time con rmation assigned to the WBS element was posted, however, no sales order assigned to
the WBS element existed. As a result, the pro tability segment in the journal entry generated by the time con rmation is
incompletely attributed. Once the sales order is created, you can use realignment to enrich the posted data with customer
and product information from the sales order.

For more information on attributed pro tability segment determination, see Pro tability Characteristics in Journal Entries.

Realignment

Following a realignment, only the new assignment is available in reports and in planning. The original characteristic values can only
be analyzed for costing-based pro tability analysis, and only in line item reports. Because the existing pro tability segments are
changed to adhere to the new assignment, all objects assigned to those pro tability segments (such as sales orders or projects)
and all existing documents (such as billing documents or FI documents) re ect the new organizational assignment as well.

You can perform realignments on a periodic basis.

Changes to Data in Journal Entries

Journal entries enable a uni ed data model for all areas of accounting. They integrate actual data from General Ledger,
Management Accounting (CO), Asset Accounting, and Material Ledger in a single G/L line item table, ACDOCA. Each journal entry
also includes data of account-based pro tability analysis with the same persistency.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 27/85
9/20/2020
This approach has the following bene ts:

Financial accounting data and management accounting data are stored in the same location (integrated accounting
system).

Each journal entry contains all available information for General Ledger, Management Accounting, Asset Accounting, and
Material Ledger.

Journal Entries

 Caution
Strict rules must be followed to ensure that generally accepted accounting principles and legal regulations are adhered to when
changes are made to posted data. In particular, no data relevant to general ledger may be changed in posted journal entries,
since such changes could result in illegal modi cations to published nancial reports. Data that may not be changed include
G/L accounts, amounts, quantities, tax codes, movement types, pro t centers, segments, and functional areas.

Therefore, all changes resulting from realignments are documented to ensure traceability.

Pro tability Characteristics in Journal Entries

For line items with a true account assignment to a pro tability segment generated by actual postings, the corresponding
characteristic value are written to the ACDOCA line item in addition to the pro tability segment number.

Thus there are two persistencies which have to be modi ed for a realignment:

Pro tability segment table CE4XXXX (where XXXX is the operating concern)

Changes to table CE4XXXX affect not only the pro tability segments but also actual data in costing-based pro tability
analysis, since the characteristics are always read from table CE4XXXX and the quantities and amounts are read from the
costing-based line item table CE1XXXX. This is also the case for costing-based planning data (read from table CE4XXXX
and CE2XXXX) as well as account-based planning data (read from table CE4XXXX and COEJ).

G/L line item table ACDOCA

Changes to ACDOCA affect actual data in account-based pro tability analysis, since account-based pro tability analysis
always reads actual data from ACDOCA (including the characteristics).

Since pro tability segment table CE4XXXX has no direct signi cance for reading actual account-based data, realignments are less
critical than with table ACDOCA. Thus G/L-relevant data such as the pro t center, segment, or functional area can be changed in
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 28/85
9/20/2020
CE4XXXX.

A change to CE4XXXX has the effect that all objects assigned to a changed pro tability segment, such as sales orders or projects,
as well as all existing logistics documents such as billing documents, re ect the new assignment.

 Note
If both costing-based pro tability analysis and account-based pro tability analysis are activated in a controlling area and scal
year, it is not possible to realign costing-based and account-based data separately. In this case both costing-based and
account-based data are adapted with the same realignment.

General Rules for Changes to Characteristics

The following general rules are prede ned:

Which elds can be changed

Which elds can never be changed

In principle, only characteristics of the operating concern can be changed.

 Note
Realignments only change characteristic values. They do not assign new pro tability segment numbers.

G/L Line Item Table ACDOCA

In table ACDOCA, only characteristics that are not relevant to G/L can be changed. These are the following groups of
characteristics:

The xed characteristic Product and characteristics predelivered by SAP that the customer has added to the operating
concern (such as Customer Group or Material Group) can always be changed.

Customer-de ned characteristics except for enhancement elds of the coding block (DDIC Include CI_COBL) that were
added to an operating concern. Such characteristics can always be changed.

Some xed characteristics not relevant to G/L, such as Sales Organization, Distribution Channel, Division, Plant,
Customer, and Billing Type. However, note the restrictions in the table below.

Account assignment objects such as Internal Order, Sales Order, or WBS Element that do not represent a true account
assignment in the ACDOCA line item. However, note the restrictions in the table below.

The following table is a complete list of elds that can be changed, along with the applicable restrictions.

Characteristics in G/L line item table ACDOCA that can be changed

Field Name Characteristic ACDOCA Field Name Restrictions

Volume Rebate Group BONUS BONUS_PA No restrictions, can be changed

Industry Key BRSCH BRSCH No restrictions, can be changed

Sales District BZIRK BZIRK No restrictions, can be changed

Form of Manufacture EFORM EFORM_PA No restrictions, can be changed

Customer Group KDGRP KDGRP No restrictions, can be changed

Country Key LAND1 LAND1 No restrictions, can be changed

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 29/85
9/20/2020

Field Name Characteristic ACDOCA Field Name Restrictions

ABC Indicator MAABC MAABC_PA No restrictions, can be changed

Material Group MATKL MATKL No restrictions, can be changed

Sales Office VKBUR VKBUR_PA No restrictions, can be changed

Sales Group VKGRP VKGRP_PA No restrictions, can be changed

Customer-de ned *_PA No restrictions, can be changed

characteristics (except DDIC
Include CI_COBL)

Product ARTNR MATNR_COPA No restrictions, can be changed

Billing Type FKART FKART Can only be changed if blank

Sales Organization VKORG VKORG Can only be changed if blank

Distribution Channel VTWEG VTWEG Can only be changed if blank

Division SPART SPART Can only be changed if blank

Plant WERKS WERKS Can only be changed if blank

Customer KNDNR KUNNR Can only be changed if blank

Sales Order KAUFN KDAUF Can only be changed if not true

account assignment and blank

Sales Order Item KDPOS KDPOS Can only be changed if not true
account assignment and blank

WBS Element PSPNR PS_PSP_PNR / PS_PSPID / Can only be changed if not true
PS_POSID account assignment and blank

Cost Object KSTRG KSTRG Can only be changed if not true

account assignment and blank

Internal Order RKAUFNR AUFNR Can only be changed if not true

account assignment and blank

Cost Center COPA_KOSTL RCNTR Can only be changed if not true

account assignment and blank

 Note
No elds in ACDOCA can be changed other than those listed in the table above.

Customer coding block enhancement elds from DDIC Include CI_COBL which were added to the operating concern as
characteristics cannot be changed either, since they potentially represent reporting entities.

The rules for writing back changes are de ned in the program code.

The following table lists all characteristics of the operating concern that cannot be changed.

Characteristics of the operating concern that cannot be changed

Field Name Characteristic ACDOCA Field Name

Company Code BUKRS RBUKRS

Controlling Area KOKRS KOKRS

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 30/85
9/20/2020

Field Name Characteristic ACDOCA Field Name

Functional Area FKBER RFAREA

Business Area GSBER RBUSA

Pro t Center PRCTR PRCTR

Partner Pro t Center PPRCTR PPRCTR

Segment SEGMENT SEGMENT

Customer-de ned characteristics from

DDIC Include CI_COBL

Pro tability Segment Table CE4XXXX

In pro tability segment table CE4XXXX, all characteristics can be changed except the following:

Characteristics in profitability segment table CE4XXXX that cannot be

changed

Field Name Characteristic

Company Code BUKRS

Controlling Area KOKRS

Sales Order KAUFN

Sales Order Item KDPOS

Costing-based units of measure *_ME

The reason for the apparent discrepancy that Sales Order and Sales Order Item can be changed in table ACDOCA but not in table
CE4XXXX is described in Process Flow for Realignments under Rederivation of ACDOCA Characteristics for Attributed Line
Items.

Related Information
Process Flow for Realignments
Additional Aspects of Realignments

Process Flow for Realignments

Maintaining and Executing Realignments
You maintain realignment runs and realignment requests in a simple hierarchical display. Open any realignment run to see the
realignment requests belonging to it. You can also see the status of each realignment run.

The following functions for maintaining realignments are available from the hierarchical display:

Create realignment run or request

Save

Execute a realignment run in the background

Restore a successful or canceled realignment run

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 31/85
9/20/2020
Display detail

Copy a realignment run or request

Move a realignment request (within a realignment run or between realignment runs)

Test monitor

Refresh status

Activities

Create Realignment Run

Realignment runs are the executable units for realignments. A realignment run consists of one or more realignment requests.

 Note
Once you have successfully executed a realignment run, you cannot change or repeat it.

It is possible to restore the data to the state it had prior to the realignment run. Status information (who executed the run and
when, nal status) is stored, as well as a log.

When you create a realignment run, you enter a description. This description is displayed in the hierarchy graphic. It is best to
enter a text that clearly describes the content of the realignment run. Since the realignment run is merely the executable unit and
stores only the text and the status information, you do not need to make any other entries. Con rm inserts the realignment run
into the hierarchy.

Create Realignment Request

A realignment request consists of a set of selection criteria, a conversion rule, and a description. Realignment requests are based
on the concept of change documents. That is, you should have one realignment request per change document for smaller master
data changes.

 Note
Realignment requests cannot be executed directly. They can only be executed by means of realignment runs.

Position the cursor on a realignment run or on an existing realignment request. Create realignment request creates a new
realignment request which is then inserted below the cursor position.

You must rst enter a description. This description is displayed in the hierarchy graphic. Enter a text that clearly describes the
content of the realignment request. On the Selection Condition and Conversion Rule tabs you can maintain the corresponding
components of the realignment request.

Selection Condition

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 32/85
9/20/2020

Selection condition and conversion rule

The dataset to be realigned can be restricted by means of selection conditions. A selection condition is a set of characteristics for
which you specify values.

You can specify the following:

Characteristic values for each characteristic in the selection condition

Several technical elds of table ACDOCA to additionally restrict the selected data for the G/L line items of table ACDOCA:

BELNR (Document Number)

GJAHR (Fiscal Year)

BUDAT (Posting Date)

AWORG (Reference Organizational Unit)

AWTYP (Reference Procedure)

AWREF (Reference Document)

 Caution
Specifying a restriction for the elds mentioned above only affects the selection of G/L line items in table ACDOCA. A
restriction does not affect the pro tability segments in table CE4XXXX. For CE4XXXX only the selections of characteristic
values are taken into account. Hence for a line item to be selected from table ACDOCA, both the selection condition for
characteristic values and the selection condition for the technical ACDOCA elds must be true before it is changed by the
realignment.

Use the arrow buttons to move the selected characteristics and technical ACDOCA elds back and forth between the two tables.

For each selected eld in the lower table, you can enter a xed value in the Characteristic Value column. If you don't make any
entries there or in the Selection… column, pro tability segments are selected that do not contain a value for that characteristic
(value #, Not assigned).

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 33/85
9/20/2020
You can enter a complex selection by choosing in the Selection… column. When a multiple selection has been entered for a
selected eld, the arrow in that row becomes green.

Characteristic values you enter here are not checked for validity in their corresponding check table. This means you can use the
realignment function to remove characteristic values which no longer exist. In this case, the text Invalid Characteristic Value
appears.

 Note
If you enter multiple values, you should only enter positive values or intervals. All other selection criteria (Not, Greater or Equal
To, Less Than, and so on) are not written to the database and therefore reduce performance.

Conversion Rule

In the conversion rule, you specify how you want characteristic values to be changed. There are three options that allow you to
control the changes at the level of single characteristics. Use the arrow buttons to move the selected characteristics back and
forth between the tables.

The following options are available:

Characteristics NOT to be changed

This is the initial default setting for all characteristics. Certain characteristics cannot be changed anyway and are therefore
highlighted. Such characteristics are:

Quantity units, if you use costing-based pro tability analysis ( elds *_ME)

Certain characteristics relevant to G/L, such as BUKRS (Company Code) and KOKRS (Controlling Area)

KAUFN (Sales Order) and KDPOS (Sales Order Item)

To ensure that the pro tability data remains consistent with other applications such as Accounting, Controlling, or Sales
and Distribution, these characteristics cannot be changed. The characteristics highlighted cannot be changed in costing-
based pro tability analysis or in account-based pro tability analysis, and therefore they cannot be changed in pro tability
segment table CE4XXXX or in G/L line item table ACDOCA. See also General Rules for Changes to Characteristics in
Realignment. There is an exception for characteristics KAUFN and KDPOS which is described under Rederivation of
ACDOCA Characteristics for Attributed Line Items.

 Note
If a realignment changes G/L-relevant characteristics, these changes (as described above) are updated in pro tability
segment table CE4XXXX and thus become available to actual and planning data in costing-based pro tability analysis
as well as to planning data in account-based pro tability analysis. However, these elds are not changed in the G/L line
item table ACDOCA. If you move such characteristics to one of the other two tables using the arrow keys, a message
informs you that when the reassignment is executed it is possible that costing-based data and account-based data will
diverge.

This will also affect follow-on processes such as reversals or top-down distribution. See the information on potential
inconsistencies between journal entries and pro tability segments in Additional Aspects of Realignments.

Characteristics to have value replaced with

The existing characteristic value is replaced with the speci ed value. If you don't enter a xed value, the existing
characteristic value is removed.

 Caution
You are advised to use this option with extreme caution.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 34/85
9/20/2020
Characteristics to be derived again

Using this option for the selected characteristics CO-PA derivation is reexecuted. The remaining characteristics are not
changed by derivation.

The derivation date is the current date, since pro tability segment table CE4XXXX is not time-dependent. On G/L line item
table ACDOCA it would be possible to use the posting date, but this could lead to differences between table CE4XXXX and
ACDOCA after the realignment if derivation rules were maintained with a validity date.

 Caution
When you run a realignment on a characteristic where CO-PA derivation is called, the rst successful derivation step
overwrites any existing values for that characteristic. This behavior differs from how derivation works when you assign
FI postings to CO-PA or when you otherwise post actual or planning data.

Example: A pro tability segment consisting of the characteristic values Product 1 and Division 01 was created on the
basis of a sales order item. The division was transferred from the order header. The material master for Product 1
contains Division 02. If you run a realignment for this pro tability segment and derive the division again, the information
from the order header is lost and replaced with the division in the material master.

Rederivation of ACDOCA Characteristics for Attributed Line Items

For ACDOCA line items that have a true account assignment to WBS Element, Internal Order, Sales Order, or Cost Center,
you can activate the determination of attributed pro tability segments for the ACDOCA line items in dependency on the
cost object type in Customizing for Pro tability Analysis under Master Data Activate Derivation for Items without
Pro tability Segment .

 Note
For more information on attributed pro tability segments, see Pro tability Characteristics in Journal Entries.

By setting the Rederivation of ACDOCA Characteristics for Attributed Line Items checkbox, you can reexecute the
attribution logic for the selected ACDOCA line items. If attribute assignment is deactivated in Customizing for the cost
object type of an ACDOCA line item, a corresponding message will be logged.

This method enables missing information to be rederived. For an example, see Additional Aspects of Realignments under
Adding Attribute Assignments of Characteristics in Table ACDOCA Without Changes in Pro tability Segment Table
CE4XXXX.

 Note
The option Rederivation of ACDOCA Characteristics for Attributed Line Items only affects line items in table ACDOCA. It does
not affect the pro tability segments in table CE4XXXX.

The options Characteristics to be derived again and Characteristics to have value replaced with, however, do affect tables
CE4XXXX and ACDOCA.

Sequence of the Methods

All three change methods can be used in a realignment request simultaneously.

If activated, the methods run in this sequence:

1. Characteristics to have value replaced with

2. Characteristics to be derived again

3. Rederivation of ACDOCA Characteristics for Attributed Line Items

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 35/85
9/20/2020
These methods interact in the following ways:

Fixed values from step 1 are not overwritten by CO-PA derivation from step 2, since these two options are mutually
exclusive.

Characteristic values that are recalculated in step 3 overwrite those that were derived with the rst two methods.
Exception: characteristics in table ACDOCA that are not overwritten if they are already lled.

 Note
The characteristics that you set under the options Characteristics to be derived again and Characteristics to have value
replaced with have no effect on which characteristics are changed by the option Rederivation of ACDOCA Characteristics for
Attributed Line Items. For the latter option, the characteristics to be changed are determined based on the rules described
under General Rules for Changes to Characteristics in Realignment.

Note that the characteristics KAUFN (Sales Order) and KDPOS (Sales Order Item) can be changed by the option Rederivation
of ACDOCA Characteristics for Attributed Line Items even if these elds cannot be changed by the options Characteristics to
be derived again and Characteristics to have value replaced with.

 Caution
The fact that certain characteristics such as KNDNR (Customer), VKORG (Sales Organization), VTWEG (Distribution Channel),
WERKS (Plant), or COPA_KOSTL (Cost Center) in table ACDOCA can only be overwritten when they are blank can lead to
unexpected results.

This is illustrated in the following example.

Characteristic LAND1 (Country Key) contains the country of the customer and is lled from the corresponding eld of the
customer master based on a xed, predelivered derivation step. The customer master contains the following data:

Values in customer master

records

Customer Country

1000 DE

2000 US

ACDOCA contains a line item to be changed with the following data:

Line item in ACDOCA to be

changed

Customer Country

2000 US

If in a realignment request for characteristic KNDNR the xed value 1000 is set and LAND1 is selected to be rederived, the
result is that LAND1 is lled with the value DE.

The processing state after setting xed values and executing the derivation would be as follows

Processing state after

realignment

Field Value

KNDNR 1000

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 36/85
9/20/2020

Field Value

LAND1 DE

Since KUNNR (which corresponds to the KNDNR characteristic) in the line item to be changed in ACDOCA is lled with 2000,
the xed value 1000 is not used for the customer. Nevertheless, LAND1 in ACDOCA is set to DE, since LAND1 can always be
overwritten. The leads to the following situation in ACDOCA:

ACDOCA after realignment

Field Value

KNDNR 2000

LAND1 DE

Thus the customer and country would no longer match correctly in table ACDOCA. In table CE4XXXX, on the other hand, they
would match since both values are transferred.

It is also possible to change characteristics that are not among the segment-level characteristics. This can be necessary, for
example, if you want to remove the characteristic afterward. In this case, it is recommended that you clear the characteristic in all
existing pro tability segments and ACDOCA line items, so that new pro tability segments do not always need to be created for
later postings.

Once a realignment request is performed on ACDOCA line items, the summarization settings for account-based line items and
pro tability segments are applied to the resulting data. You can nd these settings in the IMG under Controlling Pro tability
Analysis Flows of Actual Values Initial Steps Summarization Summarization of Account-Based Line Items and Pro tability
Segments

In contrast, no summarization settings are applied to table CE4XXXX.

Save Realignment Run or Request

New or changed realignment runs or realignment requests rst appear in the hierarchy graphic only. To change these in the
database, you need to save them.

 Note
A number of functions (such as scheduling and testing) require you to save before you can use the function.

Schedule Realignment Run

You can schedule a realignment directly from the maintenance screen. All functions in Job Administration (immediate or delayed
execution, speci cation of an application server, and so on) are available. To check the job status, use Goto Job overview .

For performance reasons, it is not possible to execute a realignment run online.

The periodic scheduling function in Job Administration is not appropriate for realignment runs, since realignment runs can only be
executed or restored successfully once.

Log

Upon execution in update mode, the original status of the pro tability segments and the G/L line items in table ACDOCA (prior to
execution of the realignment) are stored in separate tables for auditing purposes and in order to be able to restore the original
data. These tables reference the speci c realignment run.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 37/85
9/20/2020
For pro tability segment table CE4XXXX, this data is stored in table CE4XXXX_KENC (where XXXX denotes your
operating concern).

For line item table ACDOCA, the original information is located in table ACDOCA_KENC.

These two tables contain all characteristics and therefore provide a full overview of the original data with regard to these elds.

A log entry is stored for each action performed for a realignment run. The log entry shows the executed action, date and time,
number of changed pro tability segments and ACDOCA line items, and other information.

Restore Successful or Canceled Realignment Run

You can restore a realignment run which has status Successful or Canceled from the menu with Run / Request Restore . Choose
one of the options With starting time or Without starting time. This overwrites the pro tability segments in table CE4XXXX and
the G/L line items in table ACDOCA changed by the realignment run with the original data (prior to the realignment run execution)
stored in table CE4XXXX_KENC and ACDOCA_KENC.

 Note
Always be sure to carry out restores only for the last realignment run executed, since it is not technically possible to determine
whether the data have since been changed again by other realignment runs.

Therefore, if you need to restore a realignment run for which newer successful runs exist, rst restore these runs in reverse
order of their original execution.

Multiple restores cannot be carried out in parallel or at the same time as a realignment run.

If a restore terminates abnormally, you can repeat it later by rescheduling it.

All functions in Job Administration (immediate or delayed execution, speci cation of an application server, and so on) are
available. You can check the job status with Goto Job overview .

For performance reasons, it is not possible to restore a realignment run online.

The periodic scheduling function in Job Administration is not appropriate for realignment runs because realignment runs can only
be executed or restored successfully once.

Archive Realignment Run

Information on the characteristic values of the pro tability segments changed by realignment runs is stored in tables
ACDOCA_KENC and CE4xxxx_KENC (where xxxx = operating concern). If you frequently carry out large-scale realignments,
these tables can become quite large. Therefore, you may wish to archive their contents from time to time.

The archiving object for ACDOCA_KENC is the same as for nancial accounting documents FI_DOCUMNT. Archiving of
ACDOCA_KENC can therefore be executed in the context of archiving nancial accounting documents.

For information on archiving CO-PA transaction data, see Archiving of CO-PA Transaction Data.

For more information on archiving, see Archiving Financial Accounting Data (FI).

Display Detail

To access the selection criteria and the conversion rule from the hierarchy screen, double-click the realignment request.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 38/85
9/20/2020
If you double-click a realignment run, a dialog box is displayed containing the short text of the run and other details. This
information includes the scheduled jobs and status changes. The Detail button for a status change displays further information
about that step, such as the number of pro tability segments and ACDOCA line items changed.

Copy

You can copy a realignment run or realignment request by positioning the cursor on that line and choosing Edit Copy . You must
enter a new text in the copy in order to distinguish it from the original.

When you copy a realignment run, all the requests (with unchanged texts) it contains are copied as well. The copy takes on the
status New, because the status information and the change history are not copied.

When you copy a realignment request, its selection criteria and conversion rule are copied as well.

The Copy function is particularly useful for repeated extensive changes with realignment requests, such as rederiving the
customer hierarchy for a large customer.

Move Realignment Request

If you have not yet scheduled or executed a realignment run, you can sort the realignment requests it contains. To do so, select the
request you would like to move and position the cursor on the request below which you want to insert the request. Then choose
Edit Move . Note that this technique does not allow you to move a request to the rst position. To do so, move the request to the
second position and then move the rst request down one.

It is also possible to move a request to another run, provided that the run has not been scheduled or executed.

Test Monitor

A test monitor is available for simulating complex realignments on individual pro tability segments without writing the changes to
the database. This functionality is only available for Characteristics to be derived again and Characteristics to have value
replaced with. It does not work for G/L line items in table ACDOCA, but only for single pro tability segments or costing-based line
items in table CE1XXXX (where XXXX denotes the operating concern). To do this, position the cursor on a realignment run and
choose Test monitor. There are two ways to specify which pro tability segments you want to test:

Pro tability segments belonging to a reference document (for example sales document or journal entry): For performance
reasons, if you choose this option you should always enter the record type. The item number is optional. If you don't enter
an item number, the run is executed for all pro tability segments in all items of the reference document.

Entering the pro tability segment number directly

The changes the realignment would make on the selected pro tability segments is displayed as an interactive list. By clicking on
the Detail button, you can navigate from the pro tability segment to the realignment request and then down to the individual step.
By clicking on the Expand button, you can display a before/after view of all the characteristic values in one pro tability segment.
The rst level shows only the changed characteristic values. The second level contains all the characteristic values, with the
changed ones highlighted.

Execution Status

Realignment runs make master data changes for a certain set of pro tability segments in table CE4XXXX and G/L line items in
table ACDOCA. These changes can only be made once, so a realignment run can only be executed once (successfully). This is why
each run contains status information New, Scheduled, Running, Successful, Canceled, and Restored. The status of a run can only
change as follows:

Status Explanation

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 39/85
9/20/2020

Status Explanation

New The status of a new realignment run changes to Scheduled when

you schedule it using Execute With/Without starting time or
Restore With/Without starting time .

Scheduled When a scheduled run is started, its status changes to Running.

Running A running job can complete successfully or terminate abnormally. If

it terminates abnormally, its status changes to Canceled.

Successful or Canceled A run that has executed successfully or terminated abnormally can
be restored, in which case its status changes to Restored. If the
restore terminates abnormally, the status becomes Canceled.

Restored A restored realignment run always keeps this status. If you want to
execute the realignment again, you rst need to copy the
realignment run.

You can test a realignment run at any time. This does not change its
status.

Refreshing the Status Information

The current status of a realignment run may differ from the status displayed in the hierarchy if a scheduled job has started in the
meantime. To see the current status, choose Refresh status.

Additional Aspects of Realignments

Sequence of Requests in a Realignment Run
The requests in a realignment run are applied to each pro tability segment in the order in which they appear in the hierarchy.

In some cases, the changes made to a pro tability segment will depend on the sequence of the realignment requests within the
run. This is illustrated in the following example.

 Example
A realignment run New Form of Manufacture 10/1/2018 contains the following realignment requests:

1. Realignment request Product 1:

Selection criterion: Product = 1

Conversion rule: Set Form of Manufacture to xed value PURCH and leave all other characteristic values
unchanged

2. Realignment request Form of Manufacture PURCH to EXTERN:

Selection criterion: Form of Manufacture = PURCH

Conversion rule: Set Form of Manufacture to xed value EXTERN and leave all other characteristic values
unchanged

After this realignment run is executed, the pro tability segment with the characteristic values Product 1 and Form of
Manufacture INTERN will have the values Product 1 and Form of Manufacture EXTERN. The rst request changes Form of
Manufacture to PURCH, the second changes it from PURCH to EXTERN.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 40/85
9/20/2020
If the order of these requests had been reversed, Form of Manufacture would have been set to PURCH.

However, such effects can only occur when characteristic values are overwritten with xed values. If you select only the options
Characteristics to be derived again or Characteristics NOT to be changed for all characteristics, the order of the requests is
irrelevant – provided that characteristic derivation has been customized in such a way that successive derivations do not
repeatedly change the pro tability segment.

Performance, Parallel Processing, and Partitioning

Realignments should not be executed in parallel with processes that post data to pro tability segments. This is true not only for
postings with a true account assignment to a pro tability segment, but also if you have activated the determination of attributed
pro tability segments.

Especially with large data volumes, the con icts that arise between read and write actions usually cannot be reconciled by the
database system. In most cases the read process is forced to terminate (in this case, the realignments). Extensive realignments
can therefore only be processed at times of low system utilization and, most importantly, when no postings are made to
pro tability segments.

 Caution
Realignment runs that change the same data and that are executed in parallel will lead to unpredictable results, since there are
no locking mechanisms on the changed tables CE4XXXX and ACDOCA. Therefore you must take organizational steps to ensure
that this does not happen.

Realignment runs that only rederive some characteristics and do not change the others may be executed in parallel.

To avoid unpredictable results, you should always use partitioned datasets when executing realignment runs in parallel.

Partitioned Datasets

To use partitioned datasets, select one characteristic that divides the dataset into separate parts of the desired size. You then
need to de ne a realignment run for each characteristic values speci ed, and change each realignment request in the run to
include that value as a selection parameter. The characteristic value used to partition the datasets is not changed during the
realignment run.

 Example
The sales view of a customer master record has changed. You create a realignment run called Adapt sales hierarchy which
contains only one realignment request to derive characteristics WWS01 through WWS05 of the sales hierarchy. However, your
experience tells you that the realignment run cannot be completed within the available time window. The existing pro tability
segments are equally distributed between the ve company codes in your organization (0001 through 0005). Your database
hardware, the physical distribution of the data on the hard drives (see Physical Distribution of Data in CO-PA), and the available
application servers suggest to you that it would be possible to execute multiple runs simultaneously.

You create four copies of the realignment run Adapt sales hierarchy and change the names to Adapt sales hierarchy, CoCd
0001, Adapt sales hierarchy, CoCd 0002, and so on. In the realignment request of Adapt sales hierarchy, CoCd 0001 you
specify company code 0001 as a selection criterion. You do the same with the other four realignment requests, each time
specifying the corresponding company code. Then you schedule the realignment runs for simultaneous execution.

Note that if the realignment request already contains selection criteria, you need to add this characteristic value to the existing
ones. If the realignment run you are partitioning contains more than one realignment request, you need to add the partitioning
characteristic value to each of the requests.

The following realignment run is to be partitioned into two parts depending on the company code (1000 and 2000).

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 41/85
9/20/2020

Realignment Run Realignment Request Selection Criteria Conversion Rule

Realign.Run0 Realign.Request1 Material hierarchy 1 between Derive material hierarchy 1

1010 and 1019 again

Derive material hierarchy 2

again

Derive material hierarchy 3

again

Realign.Request2 Material hierarchy 1 = 1010 Derive material group again

This yields the following realignment runs:

Realignment Run Realignment Request Selection Criteria Conversion Rule

Realign.Run1 (CCode 1000) Realign.Request1 Material hierarchy 1 between Derive material hierarchy 1
1010 and 1019 again

Company code = 1000 Derive material hierarchy 2

again

Derive material hierarchy 3

again

Realign.Request2 Material hierarchy 1 = 1010 Derive material group again

Company code = 1000

Realign.Run2 (CCode 2000) Realign.Request1 Material hierarchy 1 between Derive material hierarchy 1
1010 and 1019 again

Company code = 2000 Derive material hierarchy 2

again

Derive material hierarchy 3

again

Realign.Request2 Material hierarchy 1 = 1010 Derive material group again

Company code = 2000

Realignment Strategy
In practice it is often difficult to restrict changes of derivation-relevant master data to speci c dates. These changes have an
immediate effect on postings to Pro tability Analysis and constantly create new pro tability segments, while the corresponding
"old" pro tability segments become obsolete and can no longer receive postings.

 Example
Customer Jones (customer number 1) is assigned to sales representative Smith (representative number 1234) up to 2/7/2018.
For sales of the product 1234.56.78.90 to Mr. Jones, a number of actual postings have been made to pro tability segment
0000000001 which is de ned by the characteristic values Customer Number 1, Sales Representative 1234, and Product
1234.56.78.90.

Due to a restructuring of the sales department, customer Jones is reassigned to sales representative Taylor (representative
number 1235) beginning on 2/8/2018. The next time Mr. Jones buys product 1234.56.78.90, the revenues are posted to a new
pro tability segment 0000000002, which is de ned by the characteristic values Customer Number 1, Sales Representative
1235, and Product 1234.56.78.90. As a result, pro tability segment 0000000001 will no longer receive any postings. Using

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 42/85
9/20/2020
realignment, you can change this pro tability segment so that pro tability segments 0000000001 and 0000000002 have the
same combination of characteristic values.

This type of situation should be avoided where possible, because the redundant pro tability segments reduce performance when
reading from pro tability segment table CE4XXXX and eventually may even constitute the bulk of the data volume.

You should therefore make changes as quickly as possible using realignment runs. Note however that such realignment runs
invalidate the summarization levels (which are normally unnecessary on a SAP HANA database) and the summarization data in
reporting. Therefore, you need to recreate the summarization levels and summarization data afterward. The reason is that when
you navigate between reports using the report/report interface, or when you switch planning screens, it must be ensured that
consistent values are always displayed regardless of whether the data was selected from a summarization level or from a
presummarized form.

Potential Inconsistencies Between Journal Entries and Pro tability Segments

As a consequence of the general rules for changes to characteristics, the G/L line item table ACDOCA and the pro tability
segment table CE4XXXX (and therefore account-based and costing-based pro tability analysis, if active) can diverge after
realignment.

Since pro tability segment numbers are assigned in the upstream logistics applications, in some cases this can result in situations
that require explanation.

As an example, consider an internal order with a settlement rule that speci es settlement to a pro tability segment. If a
settlement document is reversed, the reversal document is generated by the settlement application. The sign of this reversal
document is the opposite of that of the original settlement document. The account assignment of the receiver item is the
pro tability segment of the settlement rule.

If realignment is carried out before the reversal on the original receiver item, for example to change the pro t center from PFC1 to
PFC2, this would only affect pro tability segment table CE4XXXX. It would not affect table ACDOCA.

Situation before realignment:

Table Line Item Pro tability Segment Pro t Center

ACDOCA Receiver item of settlement with 4711 PFC1

true account assignment to
pro tability segment

CE4XXXX 4711 PFC1

Situation after realignment:

Table Line Item Pro tability Segment Pro t Center

ACDOCA Receiver item of settlement with 4711 PFC1

true account assignment to
pro tability segment

CE4XXXX 4711 PFC2

When the reversal is posted, the logistics application evaluates pro tability segment 4711 and sets the pro t center to PFC2 in the
reversal document:

Table Line Item Pro tability Segment Pro t Center

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 43/85
9/20/2020

Table Line Item Pro tability Segment Pro t Center

ACDOCA Receiver item of settlement with 4711 PFC1

true account assignment to
pro tability segment

ACDOCA Reversal of receiver item of 4711 PFC2

settlement with true account
assignment to pro tability
segment

CE4XXXX 4711 PFC2

As a result, the pro t center in the reversal is not the same as that in the original line item. In account-based reporting this
discrepancy would need to be explained.

Costing-based pro tability analysis, on the other hand, reads the characteristics from table CE4XXXX so the pro t center in both
line items would be the same. Only the costing-based line item table CE1XXXX would show a difference, since this table is not
affected by realignments.

Note however that this situation can arise independently of realignments if the pro t center was manually changed in the
settlement rule.

Recommendations for Minimizing Inconsistencies

If you are using both forms of pro tability analysis and you want to minimize inconsistencies between costing-based and account-
based pro tability analysis, follow these recommendations:

Only make changes to characteristics that have no restrictions (for example, Customer Group).

When selecting data, don't include any of the ACDOCA elds, such as BUDAT and GJAHR.

Application Examples
The following examples of realignments show how they update to the G/L line item table ACDOCA and the pro tability segment
table CE4XXXX.

Changes to Characteristics Not Relevant to G/L

If a realignment run realigns characteristics that are not relevant to G/L, such as Product or customer-de ned WW*
characteristics, the new characteristics are changed in table ACDOCA and in the pro tability segment table CE4XXXX.

Unchangeable Characteristics

Attempts to change characteristics that cannot be changed, such as Controlling Area, Company Code, or costing-based units of
measure, are rejected at the point when you create the conversion rule.

Changes to Characteristics in Pro tability Segment Table CE4XXXX Without Changes to Table ACDOCA

Realignments for certain G/L-relevant characteristics which can be changed in costing-based pro tability analysis but not in table
ACDOCA only affect pro tability segment table CE4XXXX.

This applies to the following characteristics:

Pro t Center

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 44/85
9/20/2020
Partner Pro t Center

Segment

Functional Area

Business Area

Enhancement elds of the coding block from Include CI_COBL

Adding Attribute Assignments of Characteristics in Table ACDOCA Without Changes in Pro tability Segment Table
CE4XXXX

With the option Rederivation of ACDOCA Characteristics for Attributed Line Items it is possible to add CO account assignment
objects to line items with attributed pro tability segments in table ACDOCA that are not true CO account assignments of the
particular line item and that are blank.

As an example, consider a sales order item that was missing at the time of a cost posting to a customer project. If realignment is
run after the sales order is created and with the option Rederivation of ACDOCA Characteristics for Attributed Line Items
selected, the sales order and item can be added to table ACDOCA. This change does not affect the corresponding pro tability
segment in table CE4XXXX.

This logic prevents undesirable side effects in costing-based pro tability analysis. There is a rule in costing-based pro tability
analysis that certain attributes such as Sales Order cannot be changed in the pro tability segment. The reason for this rule is that
the pro tability segment might be used in another process which would then show an incorrect attribute.

 Example
The following example in a Professional Service scenario illustrates how characteristic attributes are derived in classical
<pname conkeyref="loio0c75c97a09694e5d976bb38b0b84b016/ERP"/> Financials as compared with SAP S/4HANA.

In classical <pname conkeyref="loio0c75c97a09694e5d976bb38b0b84b016/ERP"/> Financials, when consulting costs or

revenue recognition are posted to a customer project, the resulting CO line items in table COEP do not carry pro tability
characteristics. Only when the customer project is settled to Pro tability Analysis are pro tability characteristics derived and
updated on the receiver line items which carry a true account assignment to a pro tability segment.

If the attribute assignment logic in SAP S/4HANA is activated in Customizing, when consulting costs or revenue recognition
are posted all existing characteristics are read from a sales order item that is uniquely assigned to the project and written to
the ACDOCA line item even if no true account assignment on the pro tability segment exists. Consequently there is no need for
settlement to Pro tability Analysis in this case.

In this example, if no uniquely assigned sales order item exists at the time of the cost or revenue posting, only market
segments with little information can be derived and persisted in the ACDOCA line item.

By means of a realignment run with the option Rederivation of ACDOCA Characteristics for Attributed Line Items selected,
characteristics such as Customer and Product can be derived from the sales order after the sales order item was generated
and the characteristics updated in the ACDOCA line item as attributes. The elds Sales Order and Sales Order Item are lled
as well. This illustrates how realignments can be used to derive missing data.

Pro tability Characteristics in Journal

Entries
G/L line items can carry true or attributed account assignments to pro tability segments.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 45/85
9/20/2020

 Note
A pro tability segment is a combination of values for the characteristics in an operating concern. It corresponds to a market
segment.

For G/L line items with a true account assignment to a pro tability segment, the pro tability segment is normally
determined in the sending application (sales order or billing document, for example). Only the costs and revenues for true
account assignments are available in follow-on processes such as allocations.

For G/L line items with an attributed account assignment to a pro tability segment, the costs and revenues are only shown
in reports. They are not available for most of the follow-on processes. Thus, follow-on processes which read line items from
the database and transform them into new line items, do not take into account any attributed pro tability segments of the
line items read. Instead, the newly created line items are attributed again according to the logic explained below. An
exception is the reversal of a journal entry by reference, where the corresponding line items are read, reversal line items are
created by reversing the amount, and quantity signs and the resulting line items are stored. In this case attributed
pro tability segments are considered when data is read from the database and copied to reversal line items.

The corresponding G/L account for attributed pro tability segments must be one of the following account types:

Primary Costs or Revenue

Secondary Costs

Balance Sheet Account with assigned cost element of category 90 - Statistical cost element for balance sheet
account

There are two special cases where even balance sheet accounts without an assigned cost element, or G/L accounts of type
N – Nonoperating Expense or Income, are attributed:

WIP postings from event-based revenue recognition

External settlement of results analysis data to FI

Except for these two special cases, the derivation of attributed pro tability segments is based on the true account
assignment object of the G/L line item. This object can be of the following types:

Cost Center

Internal Order

Project

Sales Order

Production Order

Maintenance Order

Service documents (service orders or service contracts)

For the two special cases, exactly one of the above account assignment objects must be available in the G/L line item.

The program logic depends on whether true or attributed pro tability segments are involved.

Case 1: G/L Line Item with True Account Assignment to Pro tability Segment
In this case a pro tability segment has already been determined by the sending application and the pro tability segment number
has been transferred to G/L. When the G/L line item is created, the combination of characteristics is read and moved to the item
according to certain rules.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 46/85
9/20/2020
Examples:

Goods issue item or billing document item in a sell-from-stock scenario

Manual FI posting to pro tability segment

Case 2: G/L Line Item Without Assignment to Pro tability Segment

In this case, an attributed pro tability segment, as previously mentioned, is determined only at the time the G/L line item is
created. The requirement is to ll as many characteristics in the item as possible to enable maximum drilldown analysis capability.

This is achieved by taking the CO-PA-relevant data from the G/L line item as a basis and performing the steps described below.
The steps are executed automatically in this case, depending on the account assignment category of the item.

A tool called CO-PA derivation is used, which contains a xed set of rules to derive additional characteristics from the available
data of the G/L line item. The product group for the product sold, for example, is derived from the material master in case of a
revenue line item created by a billing document.

The logic for the determination of attributed pro tability segments depends on the account assignment category of the item:

Cost Center

For account assignment to cost center, CO-PA derivation is called with the available data. The enriched data is written back
to the G/L line item.

Internal Order

For account assignment to internal order:

If a settlement rule to a pro tability segment exists in the order, the corresponding pro tability segment data is
written to the G/L line item.

If no settlement rule exists, but a sales order item is referenced in the master data of the order or the G/L line item,
then the following applies:

If a settlement rule to a pro tability segment exists in the sales order item, the corresponding pro tability
segment data is read and transferred to the G/L line item

If no settlement rule exists in the sales order item, but the sales order item does carry a pro tability
segment, the G/L line item is enriched with the corresponding characteristics.

If no pro tability segment exists in the sales order item either, certain xed attributes such as customer and
product are copied from sales order header and item, and in addition CO-PA derivation is called. The
resulting characteristics are written back to the G/L line item.

If no sales order item is found, but there is at least a unique sales order assigned in the master data of the order, the
customer is copied from the sales order header, CO-PA derivation is called, and the derived characteristics are
written to the G/L line item.

If not even a sales order is found but the current document posted is an SD billing document, the customer and
product are copied from the billing document, CO-PA derivation is called, and the G/L line item is enriched with the
resulting data.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 47/85
9/20/2020

Overview of derivation steps for account assignment to internal order (IO)

Project

For account assignment to a WBS element:

If a settlement rule to a pro tability segment exists in the WBS element, the corresponding pro tability segment
data is written to the G/L line item.

If no settlement rule exists, the next-higher billing element is read and checked for a settlement rule as in the
previous step.

If no settlement rule is found at all, but exactly one sales order item is assigned to the WBS element or the next-
higher billing element, or a sales order item is referenced in the G/L line item, then the following applies:

If a settlement rule to pro tability segment exists in the sales order item, the corresponding pro tability
segment data is read and transferred the G/L line item.

If no settlement rule exists in the sales order item, but the sales order item does carry a pro tability
segment, the G/L line item is enriched with the corresponding characteristics.

If no pro tability segment exists in the sales order item either, certain xed attributes such as customer and
product are copied from sales order header and item, and in addition CO-PA derivation is called. The
resulting characteristics are written to the G/L line item.

If no sales order item is found, but there is at least a unique sales order, the customer is copied from the sales order
header, CO-PA derivation is called, and the derived characteristics are written to the G/L line item.

If not even a sales order is found, but the current document posted is an SD billing document, the customer and
product are copied from the billing document, CO-PA derivation is called, and the G/L line item enriched with the
resulting data.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 48/85
9/20/2020

Overview of derivation steps for account assignment to WBS element

Sales Order

For account assignment to a sales order item:

If a settlement rule to a pro tability segment exists in the sales order item, the corresponding pro tability segment
data is written to the G/L line item.

If no settlement rule exists in the sales order item, but the sales order item does carry a pro tability segment, the
G/L line item is enriched with the corresponding characteristics.

If no pro tability segment exists in the sales order item either, certain xed attributes such as customer and
product are copied from sales order header and item, and in addition CO-PA derivation is called. The resulting
characteristics are written to the G/L line item.

Overview of derivation steps for account assignment to sales order

Production Order

For account assignment to a production order, the same actions are taken as for an internal order.

Maintenance Order

For account assignment to a maintenance order, the same actions are taken as for an internal order.

Service Document (service order or service contract)

For account assignment to a service order item:

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 49/85
9/20/2020
If the service order item is assigned to a service contract item, then the G/L line item is enriched with certain elds
of the service contract item.

If the service order item is not assigned to a service contract item, then the G/L line item is enriched with certain
elds of the service order item.

For account assignment to a service contract item, the G/L line item is enriched with certain elds of the service contract
item.

In both cases CO-PA derivation is called and the resulting characteristics are written into the G/L line item.

Overview of derivations steps for account assignment to a service document

 Example
For G/L line items assigned to a customer project, the assigned sales order is derived along with the corresponding customer
and product using above mentioned logic.

Mapping Rules

After the pro tability characteristics are derived, the resulting data is mapped to the G/L line item. Certain rules apply for this
mapping:

G/L-relevant organizational unit elds of the G/L line item are never overwritten by the pro tability segment data.
Examples:

Company code

Controlling area

Pro t center

Partner pro t center

Segment

Business area

Functional area

The following elds of the G/L line item are overwritten by the pro tability segment data if they are not yet lled:

Account assignment objects such as:

Cost center

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 50/85
9/20/2020
Sales order and sales order item

Order

WBS element

Service document, service document type, and service document item

Organizational units such as:

Plant

Sales organization

Distribution channel

Division

Customer

Billing type

 Note
Exception: For true account assignment to pro tability segment, the elds listed below are always copied from the
pro tability segment into the G/L line item (otherwise data inconsistencies might occur, because for postings from
business transactions posted in logistical applications, such as goods movements or customer invoices, the elds are
sometimes lled with values, which deviate from the ones in the pro tability segment):

Plant

Sales Organization

Distribution Channel

Division

Customer

Billing type

Fields of the G/L line item which represent a custom characteristic (not delivered by SAP) are always overwritten by the
pro tability segment data. Some xed elds, such as the following, are also overwritten by pro tability segment data:

Product (since there is a separate eld with the meaning "Product sold")

Customer group

Material group

Value Flows
Pro tability data comes from income statement line items with true account assignments to pro tability segments or from line
items with attributed account assignments to pro tability segments.

For income statements items with a true account assignment to a pro tability segment, the pro tability segment is
normally determined in the sending application. The costs and revenues for true account assignments are available in
follow-on processes such as allocations.

The costs and revenues for income statements items with an attributed pro tability segment are only available in reports.
They are not available in follow-on processes.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 51/85
9/20/2020
Based on the existing process characteristics and by means of derivation, each of these line items is transferred to Pro tability by
determining the characteristic vector as the pro tability segment and storing the characteristics in the journal entry.

The G/L account and the functional area determine the cross-margin structure. Both characteristics are required for multilevel
contribution margin accounting.

The description of the processes in this section focuses on the options for market segment derivation and determination of the
G/L accounts for the individual line items.

The period closing processes of cost center assessment and settlement into CO-PA are essentially a top-down distribution
function for speci c cost objects.

Examples of Characteristic Derivation

Invoicing generates a journal entry. The differentiated revenue and revenue reduction accounts determine the line item
structure. Differentiated pro tability characteristics such as Customer and Product are available for all line items.

The derivation tool enables you to assign a customer group or region to a marketing cost center, or a product group to a
production cost center. Each time a posting is made to the cost center, the pro tability characteristic is derived and stored
in the journal entry so that it is available in market segment reports.

Features
Margin Analysis enables you to assign to pro tability segments primary, pro t-related postings and activities from the following
application components:

Application Component Examples of Postings/Activities

Financial Accounting G/L account postings

Materials Management Goods issues, invoice receipts, purchase orders

Sales and Distribution Sales orders and billing documents

Period-End Closing
For period-end closing, you can assign internal activities to pro tability segments, assess cost center costs and business process
costs to pro tability segments, as well as settle orders, projects and cost objects to pro tability segments.

See Also
Pro tability Characteristics in Journal Entries

Customer Invoices
Value-Affecting Sales Conditions
Billing documents generate journal entries in Financial Accounting. Income statement items are posted for every billing item and
all FI-relevant SD price conditions. The income statement items provide pro tability characteristics, such as Customer and
Product, if:

The billing document items are already assigned to a pro tability segment

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 52/85
9/20/2020
Or – for different account assignments – if attributed pro tability segments are determined for the corresponding income
statement items.

For more information on attributed pro tability segments, see Pro tability Characteristics in Journal Entries.

Prerequisites
Before you can transfer billing data to Financial Accounting and Pro tability Analysis in real time, the controlling area you are
working in must be activated and for the FI-relevant SD pricing conditions, the Revenue Account Determination must be
completed. You do this in Customizing.

Features
Sales and Distribution (SD) calculates revenues during billing with the help of a pricing mechanism, and then records it in the
billing document. If sales deductions are known (discounts granted, planned cash discount), these are also recorded in the billing
document. In addition, the stock value of the product (delivered price for wholesale or retail goods, or cost of goods manufactured
for in-house products) can also be determined.

By transferring the SD document to the journal entry, the system determines all the characteristics de ned in Pro tability
Analysis based on the information in the billing document, along with the customer and product numbers. It also performs
characteristic derivation for those elds for which derivation logic has been de ned.

If a pro tability segment is derived, every billing document generated in SD (including credit memos, cancellations, and so on)
immediately generates a corresponding journal entry with its pro tability characteristics.

Correcting Errors During Posting

If an error occurs while the billing data is being posted to Financial Accounting (such as an error in characteristic derivation), the
billing document is posted in Sales and Distribution but not in Financial Accounting.

When this happens, you need to correct the error and post the billing document again using ReleaseToAccounting. This function
creates the journal entry as well as the line item in costing-based pro tability analysis if active.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 53/85
9/20/2020

Statistical Sales Conditions

Statistical Sales Conditions are transferred to Pro tability Analysis (CO-PA) at sales order billing to increase and improve
information relevant for management reporting in Finance.

With this feature, you can transfer statistical pricing conditions of customer invoices to Financial Accounting (FI) by using the
regular interface between Sales Billing (SD-BIL) and Financial Accounting. Note that only statistical pricing conditions with status
Active can be transferred to CO-PA.

In the control data for a pricing procedure, select the Relevant for Account Determination indicator for a statistical price
condition. This statistical price condition is then posted as a journal entry to an extension ledger of Financial Accounting.

Any analytical app using journal entries can use data from the extension ledger.

This capability is based on a similar functionality in costing-based CO-PA. It has been implemented through a new indicator in the
pricing scheme that ags a statistical condition as relevant for account determination.

You will need to maintain the con guration in pricing and billing in order for your data to be sent to Finance.

Con guration
The con guration steps are as follows:

1. 1. De ne Condition Types [optional]

Create or reuse existing condition types.

Sales and Distribution Basic Functions Pricing Pricing Control De ne Condition Types

2. De ne Account Keys [optional]

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 54/85
9/20/2020
Create or reuse existing account keys.

Sales and Distribution Basic Functions Account Assignment/Costing Revenue Account Determination De ne and
Assign Account Keys De ne Account Keys

3. Maintain Pricing Procedures

In the pricing procedure, maintain the condition types and account keys. Also set here the 'Relevant for Account
Determination' ag

Sales and Distribution Basic Functions Pricing Pricing Control De ne and Assign Pricing Procedures Set Pricing
Procedures

4. Account Determination

Assign both a debit and a credit account to the account key. Use columns 'G/L Account' and 'Accruals Account'.

Sales and Distribution Basic Functions Account Assignment/Costing Revenue Account Determination Assign G/L
Accounts

5. De ne Extension Ledger

Create or reuse extension ledger(s) of extension ledger type P Line items with technical numbers / no deletion possible
to record postings for Statistical Sales Conditions.

Financial Accounting (New) Financial Accounting Global Settings (New) Ledgers De ne Settings for Ledgers and
Currency Types

6. De ne Ledger Group

Create a ledger group and assign all extension ledgers that the system shall use to record postings for Statistical Sales
Conditions.

Financial Accounting (New) Financial Accounting Global Settings (New) Ledgers De ne Ledger Group

7. Assign Ledger Group

Assign the ledger group to the processing of Statistical Sales Conditions.

Controlling Pro tability Analysis Flows of Acutal Values Transfer of Billing Documents Assign Ledger Group (Margin
Analysis)

Direct Postings from Financial Accounting

You use this function to directly post revenue and expenses for income statement items to market segments (pro tability
segments) in Pro tability Analysis (CO-PA).

Prerequisites
Before you can transfer direct postings from Financial Accounting (FI) to CO-PA in real time, the controlling area you are working in
must be activated. You activate the controlling area in Customizing.

Features
The following methods are available for directly posting revenues and expenses to market segments:

Post Document

With the Post Document function, you can assign revenue, sales deductions, and costs directly from FI to pro tability segments
(such as customers and products) in CO-PA.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 55/85
9/20/2020
You can post the actual costs to the original pro tability segment (sales order or combination of product and customer). If
a detailed assignment is not necessary or no longer possible, you can post to any higher level in CO-PA.

If your system allows dual postings to both a pro tability segment and a cost center or statistical order, the real posting
always goes to the pro tability segment. The other object is posted only for statistical purposes.

Dual postings can be appropriate for example if you want to post expenses for a marketing campaign to a pro tability
segment that represents a certain product group and sales region, and at the same time you need to see the data in the
relevant sales cost center for statistical purposes.

Direct posting also lets you post direct costs or revenue to pro tability segments. This might include for example license
fees for retail goods or costs and revenue for services.

You assign the values to a pro tability segment directly with the posting transaction in FI. For each posting line to be posted to a
pro tability segment, you can call up the dialog box Assignment to a Pro tability Segment (the assignment screen). The
assignment screen contains the CO-PA characteristics from which you can choose to specify the pro tability segment. In
Customizing, you can create a characteristics group to appear in this dialog box and assign the group to the business transaction
RFBU (G/L account postings). The characteristic group de nes which characteristics are displayed for selection.

 Note
To simplify the selection of similar, frequently entered combinations of characteristics, you can create entry aids. For more
information, see Entry Aids for Assignments to Pro tability Segments.

Derivation

Additional characteristic values are derived automatically based on those you speci ed. See also Characteristic Derivation.

 Note
You can only assign a posting to a pro tability segment if the relevant G/L account is assigned to a eld status group that
allows posting to pro tability segments (see Financial Accounting in Customizing).

Entry Aids for Assignments to Pro tability

Segments
Use
For manual assignments to CO-PA in the dialog box Assignment to a Pro tability Segment (the assignment screen), it may be
necessary to it may be necessary to enter similar or even the same combinations of characteristic values more than once. Instead
of having to reenter them each time, you can save such combinations of characteristic values as an entry aid.

Entry aids you have created can then be selected from a tree in the assignment screen. By double-clicking an entry aid, the
characteristic values you have saved are entered into the corresponding elds in the dialog box.

 Note
Batch-input transactions, however, use an assignment screen that does not have entry aids.

Features
Creating Entry Aids

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 56/85
9/20/2020
You can create central entry aids for business transactions in Customizing for CO-PA by choosing Flows of Actual Values
Initial Steps Characteristic Groups Assign Characteristic Groups for Assignment Screen . The entry aid for a particular
business transaction can then be used by any user performing assignments for that transaction. Users can access these
entry aids by choosing Central entry aids.

Individual users can create their own entry aids when making account assignments. These entry aids are then only
available to the user who created them, and only for the business transaction for which they were created. Users can
access their entry aids by choosing My entry aids.

 Note
The following applies to all entry aids:

Derived characteristic values are not saved in an entry aid because the system continually determines new values in
account assignment.

You cannot change characteristic values in an entry aid after you create it. You can only change the entry aid
description.

You should rst enter the characteristic values and then select .

Displaying Entry Aids

Depending on the position of the cursor in the tree, you can display an overview of the characteristic values in one or more entry
aids.

If you position the cursor directly on an entry aid, only the characteristic values for that entry aid are shown in the overview.

If you position the cursor on a node, the characteristic values for all lower-level entry aids are shown in the overview.

 Note
Alternatively to using the pushbuttons, you can use the right mouse button to call up a context menu offering you the same
functions as for a node.

Selecting Entry Aids

When you double-click an entry aid to select it, the characteristic values are treated as if they had been entered manually:

Fields that are locked against entry, such as those transferred from the sender document, are not populated with data.

Any elds that have already been populated but which still remain unlocked for entry are then overwritten if characteristic
values for those elds are stored in the entry aid or if derived values are determined for those elds. Empty characteristic
values in the entry aid will clear any data from elds unlocked for entry in the assignment screen.

If there is no eld in the assignment screen for some characteristic values stored in the entry aid, those characteristic
values are not transferred. This could occur if for example a characteristic line was deleted from the characteristic group
assigned to the business transaction after the entry aid was created.

Characteristics that are not visible in the current page of the assignment screen but that can be shown by scrolling are also
supplied with the characteristic values stored in the entry aid.

You can still overwrite characteristic values that were entered using an entry aid.

Transporting Entry Aids

You can transport central entry aids when you transport an operating concern.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 57/85
9/20/2020

Periodic Overhead Allocation

To be able to see all actual costs from Overhead Cost Controlling in Pro tability Analysis, you need to transfer the cost center
costs and business processes which are not directly attributable to the production process. You can transfer these costs to any
pro tability segments you wish.

The contribution margin line item is hereby de ned by the allocation cost element you de ne. This enables you to assign them to
the level that best re ects the cause of the overhead.

 Example
You can assign the costs that arose in the marketing for a certain customer group to that particular customer group in CO-PA.

The xed costs and the excess costs in production should be assigned to the products or product groups that caused these
costs. Since you want to be able to analyze these costs easily in reports by drilling down, it would not make sense to assign
them to combinations of customer and product.

Transferring Cost Center Costs

This function makes it possible to transfer overhead costs to Pro tability Analysis (CO-PA), such as the variances for production
cost centers (as a whole, not by variance categories) and the costs for sales and administrative cost centers.

Cost center costs are always transferred to one pro tability segment:

Production cost centers

These cost centers are rst credited during production for the activities they perform (such as machine hours and
assembly hours). The credit amount is based on the quantities con rmed by production and on the activity prices (such as
hourly machine rates) usually calculated in cost center planning.

The resulting balances, or the overabsorption/underabsorption remaining for the production cost centers due to the
difference between credits and actual costs, are transferred en bloc in periodic pro t analysis to those pro tability
segments in CO-PA that caused those costs.

Sales and administration cost centers

Many companies transfer the costs from administrative cost centers to CO-PA en bloc instead of allocating them to cost
objects. This reduces the period results of the individual divisions, product groups, or business areas.

It is also possible to transfer postings from Financial Accounting to cost centers and pro tability segments at the same time. In
this case, the postings are statistical in Cost Center Accounting, while the true costs are stored in Pro tability Analysis. The
system ignores these statistical costs in Cost Center Accounting when assessing costs to Pro tability Analysis.

Related Information
Procedure for Overhead Allocation

Transferring Process Costs

Activity-Based Costing (CO-OM-ABC) provides an alternative form of overhead control that is particularly useful when indirect
activities account for a large share of value added.

Whereas traditional approaches allocate machine-hour rates or similar overhead to cost objects, Activity-Based Costing lets you
allocate overhead activities in a way that better re ects the origin of those costs. It uses cost drivers to allocate indirect activities
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 58/85
9/20/2020
to business processes, which can then be transferred periodically to Pro tability Analysis (CO-PA).

 Example
You could transfer the costs of processing orders to Pro tability Analysis based on the cost driver Number of sales orders
processed in order to identify those customers and business divisions that generate the highest sales costs.

These costs can be transferred periodically to Pro tability Analysis using the process assessment function, for example. This
transfers to Pro tability Analysis the overhead allocated to the processes. Reference values for the transfer can be quantities and
values posted in Pro tability Analysis or additional cost driver information, such as the number of sales orders processed.

This method charges the process costs to the pro tability segments, which you can then analyze in detail in terms of their
contribution margins. You can transfer both actual and planned process costs to Pro tability Analysis.

 Note
Before you can transfer process costs to Pro tability Analysis, Activity-Based Costing must be active as an operational
Controlling component in your system.

Related Information
Procedure for Overhead Allocation

Procedure for Overhead Allocation

Use
You can choose between several different methods for the periodic transfer of process costs and cost center costs to CO-PA:

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 59/85
9/20/2020

Methods of transferring process costs and cost center costs to CO-PA

Features
Assessment

Assessment cycles allocate your planned or actual costs for cost centers or business processes to pro tability segments in CO-PA
on the basis of reference values, percentages, or xed amounts.

For detailed information about assessment, see Assessment in the documentation for Cost Center Accounting (CO-OM-CCA).

Indirect Activity Allocation

Whereas assessment allocates cost elements or cost element groups on the basis of reference values, activity allocation allocates
on the basis of the activities performed.

Indirect Activity Allocation with Cost Centers

Indirect activity allocation is especially useful for cost centers whose activities cannot be measured directly, because you can
create a quantity structure based on certain assumptions and then value and allocate this quantity structure just as you would
allocate activities directly.

 Example
The activity of an Order Processing cost center cannot easily be measured. To allocate the costs for this cost center according
to cause, you create a quantity structure based on the number of orders processed and then value this quantity structure with
activity prices.

Indirect Activity Allocation with Processes

Processes can also be allocated using indirect activity allocation. This function is especially useful in cases where the process
quantities cannot easily be measured directly, because you can create a quantity structure based on certain assumptions and
then value and allocate this quantity structure just as you would allocate activities directly.

 Example
The activity of a Creating Quotations process cannot easily be measured . To allocate the costs for this process according to
cause, you create a quantity structure based on the number of quotations and then value this quantity structure with activity
prices.

For detailed information about the indirect allocation of activities, see Indirect Activity Allocation in the documentation for Cost
Center Accounting (CO-OM-CCA).

Template Allocation

In template allocation, you can determine in detail which pro tability segments used the processes (as well as cost
centers/services) and then allocate the costs based on this information. You can use a template to de ne formulas and functions
that select cost drivers from Pro tability Analysis or other sources in order to assign the costs most accurately based on cause.

In Customizing, you assign this template to characteristics, which are used to select the cost drivers. Then you need to assign
update characteristics, which ultimately determine the pro tability segments to which the overhead costs are allocated.

 Example

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 60/85
9/20/2020
Your company uses a process called Customer Service to differing degrees for different customer groups. You de ne a
template for the customer group Wholesale that is used to determine cost drivers. When you allocate these process costs to
CO-PA, you can add further characteristics such as Key Customer. These characteristics are ultimately the ones to receive the
allocated process costs.

You can use template allocation for both actual and planned data.

For detailed information about template allocation, see the section Template Allocation in Actual in the documentation for
Activity-Based Costing (CO-OM-ABC).

Activities
To assess overhead to CO-PA or to allocate activities indirectly, you need to de ne cycles. Cycles let you allocate overhead to
pro tability segments in connection with your period-end closing activities.

For more information, see Use of Cycles in Pro tability Analysis.

When using template allocation for overhead, you need to de ne a template for pro tability segments. For more information, see
the section Template-Allocation for Pro tability Segment in the documentation for Activity-Based Costing (CO-OM-ABC).

Use of Cycles in Pro tability Analysis

For the periodic transfer of overhead to Pro tability Analysis (CO-PA), start an assessment or an indirect activity allocation at the
end of the month. This performs a cycle or several cycles at once. These cycles contain control information and can be maintained
in Customizing for CO-PA.

Cycles for period-based allocation are mainly used in overhead allocation (CO-OM) to allocate cost center costs to other cost
centers or to other receiver objects in CO-OM. In the documentation for Cost Center Accounting (CO-OM-CCA), you can nd
detailed information about the scope of functions for using cycles. This section will concentrate on the special features for using
cycles in CO-PA and includes references to the appropriate and more detailed sections in the CO-OM-CCA documentation.

Cycles
Cycles control how assessment or indirect activity allocation is processed.

For information about the senders, receivers, sender rules, receiver rules, and tracing factors, see Segments.

The individual key for a cycle consists of its name and the initial date.

Use
You use cycles to allocate cost center costs or process costs using assessment or indirect activity allocation to Pro tability
Analysis (CO-PA).

Structure
A cycle contains one or more segments describing combinations of senders and receivers that are to be processed together.

The time required to execute a cycle and the amount of data created depend largely on the following:

Number of segments

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 61/85
9/20/2020
Number of sender cost centers/sender processes

Number of receivers

Type of database selection

Structure of the cycle

 Example
A cycle consists of 100 segments. In each segment, two cost centers are distributed to the independent characteristics
Customer (10,000 characteristic values) and Product (1000 characteristic values) based on variable percentages. Each
customer purchases 5 products in each period. This means that each sender distributes to 50,000 pro tability segments.

The system thus creates 100 × 2 × 50,000 = 10,000,000 line items per period. If each record contains 1150 bytes, the resulting
data volume is about 10 GB.

This cycle cannot be executed.

Recommendations:

Optimize the structure of a cycle for both possible types of database selection, and then use this access strategy to
execute the cycle.

This means that the characteristics for the receiver objects should overlap as much as possible in the segments of a cycle
that is to undergo selection by cycle. You must not de ne a cycle in which one segment distributes to Division and another
segment distributes to Product, for example. Moreover, such a cycle should not consist of more than 100 segments.

In the segments of a cycle that is to undergo selection by segment, the characteristics for the receiver objects should
overlap as little as possible.

Do not distribute to more than one independent characteristic at the lowest level (either Customer or Product).

 Note
During allocation to Pro tability Analysis, the order of the segments in a cycle does not affect the results of the cycle in any
way.

For example, suppose a cycle contains two segments both of which credit the same cost center. Segment 1 works with xed
amounts (sender rule 2), while segment 2 works with the posted amounts (sender rule 1).

This assessment has the following result: The cost center is credited with the amount posted and with the xed amount. If you
just want to credit the cost center with the remaining amount, you need to create two cycles and execute them one after the
other.

In theory, you could create one cycle for transferring all cost centers or processes to Pro tability Analysis. However, for
performance reasons as well as from the point of view of allocation, it may make more sense to create multiple cycles and process
them sequentially in the order entered. The system always ensures that one cycle is completed before the next cycle starts.

You should divide your assessment into several cycles if you want to allocate different areas of your organization to CO-PA at
different times. It also has the advantage that when errors or changes occur, you only need to repeat the affected cycles.

Activities
To de ne a cycle to assess actual overhead to Pro tability Analysis, go to Customizing and choose Pro tability
Analysis Flows of Actual Values Transfer of Overhead Assess Cost Center Costs / Process Costs De ne Structure of
Cost Center Assessment/Process Cost Assessment .

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 62/85
9/20/2020
To de ne a cycle to allocate the actual overhead of indirect activities to Pro tability Analysis, go to Customizing and
choose Pro tability Analysis Flows of Actual Values Transfer of Overhead Direct/Indirect Activity Allocation Set Up
Indirect Allocation of Activities from Cost Centers/Processes .

To de ne a cycle in Planning for assessment, go to Customizing and choose Pro tability Analysis Planning Integrated
Planning Transfer Cost Center Planning/Process Planning Assess Cost Center Costs / Process Costs De ne Structure
of Cost Center Assessment/Process Cost Assessment .

To de ne a cycle in Planning for indirect activity allocation, go to Customizing and choose Pro tability
Analysis Planning Integrated Planning Transfer Cost Center Planning/Process Planning Direct/Indirect Activity
Allocation Set Up Indirect Allocation of Activities from Cost Centers/Processes .

Related Information
Segments
Functions Within Cycle Maintenance

Segments
A segment is part of a cycle. Senders using the same rules to determine the allocated values, and the corresponding receivers
using the same rules to determine the tracing factor, are grouped into the same segment for period-based allocation.

 Example
At the end of each period, the Automotive sales cost center allocates its costs to the product groups in the Cars and
Motorcycles divisions. The Cars division distributes the costs based on the revenues earned by each product group, whereas
the Motorcycles division distributes the costs based on the production costs. Two segments need to be created in this case
because the tracing factors for the two receiver groups are different. In each segment, you specify which share of the costs
should be allocated to the two divisions. The following table illustrates this example:

Segment Sender Receiver

SEGMENT 1 Automotive cost center Cars division

Allocate 70% of actual costs Tracing factor: Revenue

SEGMENT 2 Automotive cost center Motorcycles division

Allocate 30% of actual costs Tracing factor: production costs

Senders in a segment using identical value Receivers in a segment using identical

determination tracing factor determination

If the sum of the percentages of the sender values in the segments within a cycle is more than 100%, an error message is issued
during allocation.

If the sum of the percentages is less than 100%, the remainder is not allocated and remains on the sender cost center.

Structure
The senders of a segment and the rules for calculating the sender values differ according to the type of allocation.

The receivers are always pro tability segments that are created by entering a combination of characteristic values. The rules
(tracing factors) used for allocating to the receiver also differ according to the type of allocation.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 63/85
9/20/2020

You de ne a segment by entering in the segment header frame the sender rules (to be used to determine the sender values) and
the receiver rules (to be used to determine the receiver tracing factors).

The rules that you select will dictate what entries are possible for the allocation characteristics (senders and receivers) and what
entries can be used to specify the tracing factors and sender values. If you select Variable portions as a receiver rule, you can
also carry out entries for the receiver weighting factors.

 Note
Since the relationships between these entries depend on the type of allocation, see the following sections further below for
more detailed information:

Assessment Segment

Segment for Indirect Activity Allocation

Logic for Allocating to Company Codes, Business Areas, and Pro t Centers
The characteristics Company Code, Business Area, and Pro t Center are handled differently depending on whether they are
speci ed explicitly in the segment.

If you don't specify the characteristics as receivers, they are copied automatically from the sender to the receiver pro tability
segments. If you use the receiver rule Variable portions, the tracing factors are aggregated over all company codes, business
areas, and pro t centers.

If you explicitly specify the characteristics as receivers, distribution is based on the receiver rule. In particular, cross-company-
code, cross-business-area or cross-pro t-center postings can be created if the characteristics speci ed for the sender differ from

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 64/85
9/20/2020
those entered explicitly for the receiver. In this case, the tracing factors used for the receiver rule Variable portions are selected
for that particular company code, business area, or pro t center.

Assessment Segment
The senders and receivers in assessment are de ned as described below.

Sender

In assessment, the sender is de ned by:

Either cost centers or business processes (where the data to be allocated originates)

Either a cost element or a cost element group (what is being allocated)

Sender value (the value is being allocated)

You enter the cost centers or business processes on the Senders/Receivers tab.

The sender cost elements are grouped into a single assessment cost element or alternatively into several assessment cost
elements via an allocation structure before being allocated to CO PA. You enter the assessment cost element or the
allocation structure on the Segment Header tab. You enter the sender cost elements to be grouped on the
Senders/Receivers tab under Senders.

The sender value can be calculated using various rules. You also enter the rule you want to use on Segment Header tab.
You must also enter a percentage for the sender value (with which the sender value is to be credited).

The following are possible sender rules:

Posted amounts (rule 1)

Fixed portions (rule 2)

Fixed rates (rule 3)

If you use rule 2 or 3, you have to enter the xed portions or rates for the individual senders on the Sender Values tab.

Receiver

In assessment, the receiver is de ned by:

The pro tability segment (which market segment is being allocated to / what incurred the costs?)

If costing-based CO-PA is active as well: the value eld (which is being allocated to)

Tracing factor (basis for distribution to the receivers)

The pro tability segment for the receiver is de ned by a combination of characteristic values. You enter the characteristic values
on the Senders/Receivers tab.

You can use a characteristic group to restrict the amount of characteristics offered at this point. Furthermore, to assign the
respective characteristic group to the business transaction for indirect activity allocation to CO PA, in Customizing choose
Pro tability Analysis Flows of Actual Values Transfer of Overhead Initial Steps Assign Characteristic Groups to Actual
Cycles . For the allocation of planning data, choose Pro tability Analysis Planning Integrated Planning Transfer Cost Center
Planning/Process Planning Initial Steps Assign Characteristic Groups to Plan Cycles .

If costing-based CO-PA is active as well, you specify on the Segment Header tab the value eld (or value elds for xed and
variable portions, depending on the sender selected in the cycle header) into which the sender cost elements are to be entered.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 65/85
9/20/2020
Alternatively, you can enter a PA transfer structure with which several value elds can be found for each sender cost element.

The tracing factor for allocating to the receivers can be selected using various rules:

Variable portions (rule 1)

Fixed amounts (rule 2)

Fixed percentages (rule 3)

Fixed portions (rule 4)

If you use rule 1, you need to enter an allocation base for calculating the variable portions. The allocation base can be an amount or
value eld. If costing-based CO-PA is active as well, a key gure can be used which is obtained by adding and subtracting value
elds in CO-PA Customizing (by choosing Flows of Actual Values Transfer of Overhead Initial Steps De ne Calculated Values
for Use as Reference Values ). Using rule 1 can sometimes result in a negative tracing factor. You therefore need to specify what
scaling should be used in such instances. With receiver rule 1, you make the other entries for the tracing factor on the Segment
Header tab. You can change and specify your entries on the Receiver Tracing Factor tab.

The variable portion that is produced by the tracing factor can be manipulated again manually on the Receiver Weighting Factors
tab. You can enter receiver-speci c weighting factors, which are multiplied by the portion calculated by the system. Hence the
portion calculated automatically and the receiver weighting factor you enter are both involved in the allocation.

Segment for Indirect Activity Allocation

The senders and receivers in indirect activity allocation are de ned as explained below.

Sender

In indirect activity allocation, the sender is de ned by the following:

Cost centers/activity types or business processes (where the data to be allocated originates)

Sender value (the value is being allocated)

You enter the cost centers/activity types or the business processes on the Senders/Receivers tab. You can only allocate activity
types belonging to the activity type category 2 (indirect entry, indirect allocation) or the activity type category 3 (manual entry,
indirect allocation).

The sender value is an activity quantity. The costs to be allocated are derived from the plan activity price for the activity type. The
sender value can be calculated using various rules. You enter the rule you want to use on the Segment Header tab. You must also
enter a percentage for the sender value (with which the sender value is to be credited).

The following are possible sender rules:

Posted quantities (rule 1; only valid for activity type category 3)

Fixed quantities (rule 2)

Quantities determined inversely (rule 3)

If you use rule 2, you have to enter the xed quantities for the sender objects on the Sender Values tab.

If you use rule 3, the activity quantity for the receiver is determined. You then have to enter the sender-speci c weighting factors
on the Sender Values tab.

Receiver

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 66/85
9/20/2020
In indirect activity allocation, the receiver is de ned by the following:

The pro tability segment (which market segment is being allocated to / what incurred the costs?)

If costing-based CO-PA is active as well: The value eld (which is being allocated to)

Tracing factor (basis for distribution to the receivers)

The pro tability segment for the receiver is de ned by a combination of characteristic values. You enter the characteristic values
on the Senders/Receivers tab.

You can use a characteristic group to restrict the amount of characteristics offered at this point. Furthermore, to assign the
respective characteristic group to the business transaction for indirect activity allocation to CO PA, in Customizing choose
Pro tability Analysis Flows of Actual Values Transfer of Overhead Initial Steps Assign Characteristic Groups to Actual
Cycles . For the allocation of planning data, choose Pro tability Analysis Planning Integrated Planning Transfer Cost Center
Planning/Process Planning Initial Steps Assign Characteristic Groups to Plan Cycles .

If costing-based CO-PA is active as well, the value eld into which the costs are placed is determined automatically using the PA
transfer structure in CO that is valid for direct and indirect activity allocation. The value eld used is the one that is assigned to the
allocation cost element stored in the attributes for that activity type or in the attributes for that business process.

The tracing factor for allocating to the receivers can be selected using various rules:

Variable portions (rule 1)

Fixed amounts (rule 2; not valid for activity type category 3)

Fixed percentages (rule 3)

Fixed portions (rule 4)

If you use rule 1, you need to enter an allocation base for calculating the variable portions. The allocation base can be a quantity or
value eld. If costing-based CO-PA is active as well, a key gure can be used which is obtained by adding and subtracting value
elds in Customizing (by choosing Pro tability Analysis Flows of Actual Values Transfer of Overhead Initial Steps De ne
Calculated Values for Use as Reference Values ). Using rule 1 can sometimes result in a negative tracing factor. You therefore
need to specify what scaling should be used in such instances. With receiver rule 1, you make the other entries for the tracing
factor on the Segment Header tab. You can change and specify your entries on the Receiver Tracing Factor tab.

The variable portion that is produced by the tracing factor can be manipulated again manually on the Receiver Weighting Factors
tab. You can enter receiver-speci c weighting factors, which are multiplied by the portion calculated by the system. Hence the
portion calculated automatically and the receiver weighting factor you enter are both involved in the allocation.

Related Information
Combinations of Sender and Receiver Rules
Functions Within Cycle Maintenance

Performing Period-Based Allocation

Use
To transfer cost center costs or process costs to Pro tability Analysis (CO-PA) at the end of the period, you perform assessment,
indirect activity allocation, or template allocation.

Prerequisites
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 67/85
9/20/2020
Before you can allocate plan or actual costs from cost centers or processes to CO-PA, the controlling area you are working in must
be activated. If you want to allocate process costs, you must have Activity-Based Costing (CO-OM-ABC) implemented as an
operational component in your system.

You need to have completed Customizing for each procedure you wish to use for the allocation. For information, see Procedure for
Overhead Allocation.

Features
Assessment and Indirect Activity Allocation

Since cycles are allocated in assessment and in indirect activity allocation, the same procedure is used for both.

You can allocate cycles online or in the background.

 Recommendation
Assessment cycles that process large amounts of data should always be executed in the background in order to avoid
bottlenecks. It is recommended that you do not execute more than one large cycle in the same job step.

You can perform cycles sequentially or in parallel. If you want to prevent speci c cycles from being performed in parallel (such as
ones that are dependent on other ones), you must assign these particular cycles to the same cycle run group. See also Processing
Cycle Run Groups.

If costing-based pro tability analysis is active in addition, and your controlling area and operating concern use different
currencies, the values are translated during the transfer.

For actual costs, the system uses the mean exchange rate (exchange rate type M). The default setting translates the values
using the rate valid on the last day of the period. By choosing Extras Value date in assessment, you can also enter a date
on which the currency translation should take place.

In planning, the exchange rate type is taken from the de nition of the plan version. The system always uses the rate valid
for the rst day of the period.

Line items are written, being credited to the cost centers/processes and debited from the pro tability segments. To display these
line items, you have different options:

Choose Goto Processed to Date from the menu, double-clicking on a selected entry and doing so again in the Document
column.

Use the Information System

In Customizing, choose Flows of Actual Values Transfer of Overhead Assess Cost Center Costs / Process Costs Display
Cycle Overview of Actual Assessment or Flows of Actual Values Transfer of Overhead Direct/Indirect Activity
Allocation Display Cycle Overview of Actual Activity Allocation and then the Previous processing tab. Double-click on an
entry under Executed or Reversed Cycles and subsequently in the Document column to display the corresponding line
items.

The receiver data in account-based CO-PA is stored using the allocation cost element for the sender (or the assessment cost
element).

For the allocation of actual data, the posting date is the last day of the period. For the allocation of planning data, the posting date
is the rst day of the period.

If you repeat a cycle during a period, data already posted is canceled automatically before the cycle is run a second time.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 68/85
9/20/2020

 Note
Along with the cycle name and the initial data, the sender version is also part of the unique key of a plan cycle. This means that
you can carry out the same cycle repeatedly with different sender versions. Hence nothing is canceled if you change the sender
version in the cycle de nition.

If you want to manually reverse a cycle, choose Indirect Activity Allocation Reverse or Assessment Reverse .

 Note
Reversal is always carried out at the line item level. Once you have archived your data or have deleted the line items in either
Pro tability Analysis or Cost Center Accounting, you can no longer reverse the cycles.

You can check the allocation results (such as the sender and receiver information) by creating detailed lists (sender and receiver
lists as well as journal lists) in which to record the results.

To specify which detail lists should be created, select the Detail Lists indicator and choose List selection. If you perform allocation
in the background, the system generates the following spool les:

A spool le is generated for the basic list, the segment list, and for the receiver and sender lists if appropriate.

If applicable, a separate spool le is generated for the journal list.

If applicable, a separate spool le is generated for the expert trace.

Moreover, you can display a runtime analysis (expert trace) or any messages while allocation is being executed. See also Results of
Periodic Repostings or Periodic Allocations. You can nd more detailed explanations by double-clicking the individual messages.

You can make the following settings by choosing Edit Settings :

Enter the display variant for detail lists

Specify the strategy for database selection

Enter the name under which the detail lists are to be stored with the allocation results

Record the run log and the runtime analysis

Determine system behavior when an error has occurred during the collective execution of cycles

Check whether parallel execution of cycles belonging to different cycle run groups is allowed

Enter a deviating posting period and scal year for reversals

One main difference with allocating planned overhead is that a cycle cannot be de ned by the name and initial date alone. Instead,
the sender version is also an essential part of the key for the cycle to run. This allows you to reuse the same cycle for different
planned versions. All you need to do is simply change the sender version, without having to de ne a completely new cycle for each
version.

Template Allocation

For information on performing template allocation, see Executing Template Allocations in the online documentation for Activity-
Based Costing (CO-OM-ABC).

Activities
You carry out periodic allocation in the CO-PA menu.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 69/85
9/20/2020
You perform allocations of actual data by choosing Actual Postings Period-End Closing Transfer Cost Center
Costs/Process Costs .

You perform allocations of planning data by choosing Planning Integrated Planning Transfer Cost Center
Planning/Process Planning .

Allocating Activities Directly

It is possible to allocate the costs for internal activities directly to pro tability segments. To do so, you need to specify the sender
and receiver along with the quantity of the activity provided. This quantity is automatically valued with the planned price for that
activity type, and the resulting amount is credited to the cost center providing the activity and debited to the receiver pro tability
segment. Both line items are posted with the same G/L Account assigned to the activity type.

This enables the labor hours of a sales employee, for example, to be posted directly to the customer groups or divisions for which
the service was provided. This does not require the use of cost centers or orders.

You can allocate activities to pro tability segments directly on the detail screen for activity allocation or on a list screen.

Activities
To allocate internal activities, in SAP Easy Access menu, under Cost Center Accounting, choose Actual Postings Activity
Allocation .

On the initial screen, you need to enter a screen variant, which de nes the structure of the list screen. By entering a suitable
screen variant, you can specify a sender cost center, the activity quantity, and a receiver pro tability segment for each line.

From the initial screen, you can choose to call up a list screen or a detail screen.

On the detail screen, you can specify a pro tability segment as the receiver by selecting the Pro t. segment eld. When you
press ENTER , the system displays a dialog box in which you can specify the characteristic values to which you want to
allocate the activity.

You can in uence the structure of this dialog box by assigning a characteristic group to the business transaction RKL. You
do this in Customizing.

Once you have made your assignment and con rmed your entries, the Ass'd to prof.seg. checkbox is selected to indicate
that the assignment has been made.

If you want to allocate a number of activities to pro tability segments, you can do this more quickly by calling up the list
screen.

As on the detail screen, you need to call up the dialog box for assigning a pro tability segment. A special checkbox
indicates that a pro tability segment has already been assigned.

Postings Across Company Codes and Business Areas

The characteristics Company Code and (where required by the system) Business Area must be speci ed for allocation to
pro tability segments unless they are set automatically by means of a user parameter. The company code and the business area
of the pro tability segment may differ from those of the sender cost center.

In this case two journal entries are posted for each affected company.

In the sending company, the cost center is credited with the G/L account assigned to the activity type and an ICO
offsetting G/L account is debited.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 70/85
9/20/2020
In the receiving company, the pro tability segment is debited with the activity type G/L account and an ICO offsetting
account is credited.

The cross-company process only works with one controlling area.

Enhancements for Production

You can re ne the settings for splitting the cost of goods sold and price differences with the following Customizing activities:

De ne Accounts for Splitting the Cost of Goods Sold

You can have COGS posted to different G/L accounts depending on the cost components in the underlying costing sheet.

De ne Accounts for Splitting Price Differences

You can have the variance categories for each cost element shown on different G/L accounts. This allows you to see the
reasons for production differences in your income statement, for example.

More Information
De ning Accounts for Splitting the Cost of Goods Sold

De ning Accounts for Splitting Price Differences

Splitting the Cost of Goods Sold

By default, the cost of goods sold (COGS) is posted to a single account that is de ned in the settings for account determination for
material movements. You can however have COGS split up into different G/L accounts based on the cost components in the
underlying costing sheet.

This re nes your cost of goods sold information and enables more detailed cost analysis.

The COGS split is con gured by means of a cost splitting pro le. The cost splitting pro le is assigned to a controlling area, from
which the chart of accounts is derived. You activate the COGS split at the company level by assigning the cost splitting pro le to
the company code.

In the cost splitting pro le, you enter the source accounts to be split and the target account for each cost component. You de ne
the cost splitting pro le in Customizing.

 Example

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 71/85
9/20/2020

The cost splitting profile defines how COGS is split up into different accounts based on cost components

If you haven't de ned a target account for a certain cost component, its costs will be assigned to the target account you marked as
the default.

 Note
When you assign target accounts to cost components, all cost components in the cost component structure are available for
selection, including cost components for sales and administration costs. However, when the COGS split is posted, only cost
components that are marked as Cost of Goods Manufactured are used.

You can choose to have COGS split only for goods movements based on sales orders, or for additional processes as well.
Additional processes include:

Stock transfers

Intercompany sales

Third-party sales

Point-of-sale transactions

Sales processes posted to internal orders

Sales processes posted to projects

Internal processes in Financial Accounting or Controlling, such as FB01 and FB50

Processes that are implemented via IDocs

Depending on the Material Price Determination setting in the material master, the system uses either the cost component split of
the standard cost estimate (Material Price Determination 2) or the cost component split of the actual cost estimate (Material
Price Determination 3).

The COGS split is saved in a separate document, distinct from the original COGS posting. You de ne the offsetting account and
the document type in Customizing.

Actual Cost Component Delta Split

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 72/85
9/20/2020
You also have the option of splitting the COGS actual revaluation amount based on the actual cost component delta (difference)
split instead of the cost component split for the standard cost estimate. The actual cost component delta split is the difference
between the actual cost component split that was used for the goods issue and the actual cost component split based on the
current actual cost estimate, as shown in the example below. The COGS actual revaluation amount is then split during the
revaluation run that takes place with the Post Closing step after actual costing (transaction CKMLCP).

Example of actual cost component delta split

Cost Component Actual Costing 6/2018 Actual Costing 7/2018 Actual Costing Delta 7/2018

1 10.00 15.00 5.00

2 20.00 20.00 0.00

3 30.00 35.00 5.00

4 40.00 25.00 -15.00

5 50.00 50.00 0.00

Total 150.00 145.00 -5.00

Prerequisites
A released material cost estimate or sales order cost estimate must exist unless you are using a Business Add-In (BAdI). You can
con gure how the released cost estimate is selected.

For information on the available BAdIs, see the documentation for the Customizing activity De ne Accounts for Splitting the Cost
of Goods Sold.

Activities
1. Create new G/L accounts to which you want the individual cost components of COGS to be posted.

2. Then de ne a cost splitting pro le in Customizing under Financial Accounting General Ledger Accounting Periodic
Processing Integration Materials Management De ne Accounts for Splitting the Cost of Goods Sold .

De ning Accounts for Splitting Price

Differences
Use
You can have the variance categories for each cost element shown on different G/L accounts. This allows you to see the reasons
for production differences in your income statement, for example.

 Note
You make the settings for this feature in Customizing under Financial Accounting General Ledger Accounting Periodic
Processing Integration Materials Management De ne Accounts for Splitting Price Differences .

When the costs of producing materials are valued based on standard prices, production variances can occur on production orders
where there are differences between the actual costs and the target costs. These production variances are calculated in Product
Cost Controlling (CO-PC) and are split into different variance categories. Depending on the reason for the differences, the system
calculates price variances, quantity variances, lot-size variances, and scrap for example.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 73/85
9/20/2020
When the production orders are settled, you can post the production variances to Financial Accounting (FI) and Pro tability
Analysis (CO-PA). The amount posted to CO-PA can be assigned to different variance categories so that you can see the individual
variance categories in different value elds in costing-based CO-PA.

The amount settled to FI is normally shown as one total amount on a G/L account for price differences. This account is de ned in
the account determination settings for material movements. The variance categories and therefore the reasons for the variances
can normally not be re ected in this FI posting.

Prerequisites
You use standard prices for producing materials.

You have executed the variance calculation in Product Cost Controlling (CO-PC).

You have de ned a settlement pro le that allows the settlement of variances for your order type.

For settlement to costing-based CO-PA, you have de ned a pro tability analysis (PA) transfer structure.

Activities
For a re ned posting of production variances to different G/L accounts in FI, you need to make the following settings:

1. Create new G/L accounts on which you want to re ect the postings of the different production variances.

2. Go to the Customizing activity De ne Accounts for Materials Management.

In the view Con guration Accounting Display, choose transaction PRD Cost (Price) Differences.

Enter your chart of accounts.

Assign the G/L accounts where price differences are normally posted to for the relevant valuation classes of your
materials.

3. Specify a splitting scheme for your controlling area and your chart of accounts.

4. Enter a cost element, cost element interval, or cost element group and/or a variance category and assign one of the newly
created G/L accounts where you want to re ect these differences.

Multiple cost elements and/or variance categories can be re ected at the same G/L account.

5. Select the Default checkbox for one of the entries. If no target account is speci ed for a cost element/variance category,
these amounts are posted automatically to the default G/L account.

6. Assign the splitting scheme to your company code and enter a valid from date.

During the posting of the settlement documents, the system checks if there is a splitting scheme assigned to the company
code for the posting date of the document and if there are entries for transaction key PRD from account determination. If
both requirements are ful lled, the production differences are split accordingly.

 Example
In account determination for material movements, you have de ned the G/L account 231500 for price differences. You re ne
this setting by creating a splitting scheme as follows:

Detailed Price Difference Accounts

Cost Element Variance Category G/L Account Default

400000 Price Differences 231501 Price Differences X

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 74/85
9/20/2020

Cost Element Variance Category G/L Account Default

400000 Quantity Differences 231502 Quantity Differences

400000 Lot Size Differences 231503 Lot Size Differences

According to the re ned setting, a settlement of a production order (quantity variances 100 and lot size variances 200) is
posted as follows:

Line Item G/L Account Amount

01 Changes in Inventory of Finished Goods -300

02 231500 Price Differences +300

03 231500 Price Differences -300

04 231502 Quantity Differences +100

05 231503 Lot Size Differences +200

Because of the default setting in line 1, all other values are posted to G/L account 231501 (Price Differences).

Settling Orders and Projects

Use
You can settle internal orders (CO), sales orders (SD), projects (PS) as well as production orders and run schedules with
production cost collectors (PP) to pro tability segments. These objects are used for various purposes relevant to Pro tability
Analysis.

Internal orders and projects can be used to track the costs of an internal activity such as an advertising campaign. The
costs of the activity are collected on the order. When the activity is completed, the costs are settled to the appropriate
pro tability segments (such as the product range and sales area).

For more information, see the documentation for Internal Orders (CO-OM-OPA).

You can also use CO orders to calculate anticipated values for the purpose of evaluating the accuracy of your accrual
method. First you credit the accrual costs calculated in CO-PA to a special cost order for accruals. When the costs are
incurred, they are posted to that order as well so that the difference between the anticipated costs and the actual costs can
be seen at the order level.

Another possible use of internal orders or projects is in make-to-order manufacturing. If you are dealing with a sales orders
from SD, a customer project, or a CO order to which revenue postings are allowed, you can post costs (such as production
costs and S&A costs) as well as revenue and sales deductions to the order or project. When production is complete, the
costs and revenues can be settled to pro tability segments. It is also possible to transfer accrued values, which are
particularly important for progress billing (such as cost of sales and reserves for imminent losses).

For more information, see the documentation for Cost Object Controlling (CO-PC-OBJ).

In repetitive manufacturing, it may also be useful to transfer the production variances calculated in CO-PC for both nal
production orders as well as run schedule headers (settled periodically) to CO-PA. The individual variance categories can
be transferred separately.

For more detailed information, see Transferring Production Variances and the documentation for Cost Object Controlling
(CO-PC-OBJ).

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 75/85
9/20/2020
Derivation of Attributed Pro tability Segments

If you have activated the derivation of attributed pro tability segments for the relevant cost object (such as internal orders or
projects), costs and revenues that are collected on the cost object do not need to be settled to CO-PA because the characteristics
can be derived directly from the posting based on the settlement rule and written to the journal entry. However, this only works if a
settlement rule has been assigned to the pro tability segment.

 Note
Settlement can nevertheless be necessary in cases where the settlement rule has changed over time, for example because not
all characteristics were known when the settlement rule was rst created.

Thus in order to obtain meaningful results and enable real-time pro tability reporting, you still need to maintain settlement rules
as described below so that the pro tability characteristics of the settlement rule are written to the income statement items which
were posted to the cost object.

For information on activating the derivation of attributed pro tability segments, see Pro tability Characteristics in Journal Entries.

Dual Postings

If your system allows dual postings to a pro tability segment and a statistical object (such as a statistical order), the statistical
object is not settled to CO-PA. Dual postings can be useful if, for example, you want to post the expenditures for a marketing
campaign to a pro tability segment comprising a speci c product group and sales region, and at the same time post the costs to
the relevant sales cost center for analysis purposes.

Prerequisites
Before you can settle orders or projects to pro tability segments in real time, the controlling area you are working in must be
activated. You activate controlling areas in Customizing.

To be able to settle an order or project to a pro tability segment, a settlement rule needs to have been created for the settlement
object with a pro tability segment as a receiver. You do this in master data maintenance for the order or project. If the settlement
pro le of the order or project allows settling to pro tability segments, you can enter an assignment to a pro tability segment when
you create the settlement rule.

Features
In the order or project, you enter an assignment to a pro tability segment for settlement by clicking Settlement Rule. For the
distribution rule, in the Pro tability segment eld, enter an assignment to a pro tability segment. The Assignment to a
Pro tability Segment screen contains the CO-PA characteristics you can choose from to specify the pro tability segment. In
Customizing you can create a characteristics group to appear in this dialog box and assign the group to the business transaction
KABK (settlement account assignment). The characteristic group de nes which characteristics are displayed for selection.

 Note
To simplify the selection of similar, frequently entered combinations of characteristics, you can create entry aids. For more
information, see Entry Aids for Assignments to Pro tability Segments.

Other characteristics are derived automatically from the characteristics you enter. A pro tability segment number is assigned to
the combination of assigned and derived characteristics.

You can assign 100% of the values to one pro tability segment, or you can distribute the values to different pro tability segments
on a percentage basis.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 76/85
9/20/2020

 Note
You can settle orders and projects online or in the background. You can run a simulation settlement or perform an update. The
result of the settlement is stored in a log. For further information on settlement rules and performing settlement, see
Settlement (CO).

A line item is created automatically for each item of the settlement rule that is posted to a pro tability segment. In account-based
CO-PA, the costs are settled to the settlement cost elements speci ed in the allocation structure of the order or project. For more
information, see the description of settlement rules in the online documentation for Internal Orders (CO-OM-OPA).

The line item created in CO-PA can be seen in the application menu under Pro tability Analysis Information System Display
Line Item List Actual , or under Actual Postings Display Line Items .

More Information
Internal Orders (CO-OM-OPA)

Cost Object Controlling (CO-PC-OBJ)

Top-Down Distribution of Actual Data

Pro tability Analysis generally stores sales revenues, sales deductions, and costs of goods manufactured at the customer or
product level. However, many business transactions such as freight invoices, insurance expenses, or advertising cannot easily be
assigned to such a detailed level. Consequently, these transactions need to be posted at a summarized level, for example at the
division, sales organization, or company code level.

Top-down distribution of actual data is a periodic function that lets you distribute this aggregated data to more detailed levels in
CO-PA on the basis of reference information (such as the data from the previous year).

Features
The data is distributed according to existing reference data. You can use either planning or actual data as a reference. You can also
distribute period by period, or aggregate the period values to smooth out variances.

The system distributes the data by value eld or according to how the values in the selected value eld are distributed.

When top-down distribution is executed, values that are not assigned at the higher level (#) are distributed. Characteristic
derivation occurs but only for those characteristics that were used in summarization (in other words, those values for which the
summarized eld in the processing instructions screen was selected).

You can perform distribution in any of the following ways:

You can select values posted to any pro tability segments and in any value elds, and then distribute this data to a
speci ed distribution level.

You can use existing actual or planning data as the basis for this distribution. The basis can be the values in a single value
eld or occur by value elds.

You can also distribute period by period, or aggregate the period values to smooth out variances.

 Note
Top-down distribution of actual data can lead to large data volumes, since the data is distributed to a large number of
pro tability segments. Assessment can be used to obtain a complete view while eliminating data volume at the same time.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 77/85
9/20/2020
For example, if you assess from n cost centers to m pro tability segments in each case, you create nm data records. As an
alternative, you can rst assess from n cost centers to one pro tability segment (or only a few), and then distribute this data to
m segments. If the distribution factors for each cost center are the same, this technique only leads to 2+m records.

 Note
Actual top-down distribution only considers income statement items with a real account assignment to pro tability segment.
Attributed income statement items, which carry a pro tability segment for reporting purposes only, are not taken into account.

Activities
You execute top-down distribution of actual data in the Pro tability Analysis menu by choosing Actual Postings Period-End
Closing Top-Down Distribution Execute .

You can execute top-down distribution for a speci c variant in background by choosing Actual Postings Period-End Closing Top-
Down Distribution Variant Start .

Actual Data

Enter the posting periods that you want to distribute.

Reference Data

1. Enter the periods from which you want the reference data to be selected.

2. Specify whether you want to reference actual data or planning data. If you reference planning data, enter the plan version
from which the data should be selected.

3. Select the Cumulate Periods checkbox if you want to add together the period values of the reference data rather than
distributing them directly. This gives you the same value in each period for each segment, to smooth out incidental
differences which occurred from period to period.

See also Example: Cumulating Periods.

If you select this checkbox, your reference period can be as large as you want. Only if you distribute by period do the
planning period and reference period have to be the same length.

Reference Base

1. If you want to distribute all the value elds in proportion to the values contained in one value eld, select Single value eld.
You can use any value eld.

2. If you selected Single value eld, enter the value eld that you want to use as the distribution factor.

3. If you want to use each single value eld as the basis for how that value eld is distributed, select By value elds. This
means that the value eld Val/COArea Crcy would serve as the basis for how the total values in controlling area currency
are distributed. Total Quantity would form the basis for how the total quantity is distributed, and so on.

4. Handling of Negative Values:

With top-down distribution, both positive and negative values may exist in the selected tracing factor. In such cases, you
can select one of three algorithms that allow you to in uence processing as follows:

The algorithm Delete Negative Values sets all negative values in the tracing factor to zero. Processing then
continues as usual.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 78/85
9/20/2020
With the algorithm Leave Values Unchanged, none of the values in the tracing factor are adjusted. All reference
gures are then processed as they are. In this case, it is possible that some values are not distributed. This always
happens when the reference values have a total of zero.

The algorithm Scale Values scales all values in the tracing factor by setting the lowest negative value to zero and
increasing all other values accordingly.

Options

1. Test run: Select this option if you want to distribute your planning data without making any changes to the database.

2. Distribution Errors: Select this option if you want an error message to be issued in case not all sender values can be
distributed. If processing takes place in the background, the corresponding job is then terminated. If you don't select this
option, only a warning message is issued and the job is completed successfully.

3. Background processing: Select this option if you are distributing for a large number of segments. The function is executed
in the background to reduce the load on your system.

Selection Criteria

Here you can restrict the amount of pro tability segments that you want to distribute. You can enter one or more single values, an
interval or a complex selection for each characteristic. All the values of that characteristic are distributed if you use the default
asterisk (*).

Under Reference Base Selection you can enter a selection for the reference base that differs from the default one for the
pro tability segments that you want to distribute.

Processing Instructions

Here you can specify how each characteristic should be processed in top-down distribution:

Distribution level: The level to which the data is distributed

Retain: The characteristic values remain the same

Summarize: The data for all values of the characteristic is summarized

 Recommendation
For certain characteristics, which are relevant for the general ledger or which may serve as account assignments, the Retain
option is used by default and cannot be changed. These are characteristics like Company Code (BUKRS), Pro t Center
(PRCTR), Business Area (GSBER), Cost Element (KSTAR), Order (RKAUFNR) or WBS Element (PSPNR).

 Recommendation
Units of measure cannot be used with the Distribution level option. If a quantity eld is to be distributed in addition, the
corresponding unit of measure must use Retain.

 Recommendation
For those characteristics that are neither distributed nor distributed to, you should leave the default values for the following:

The selection criteria *

The processing instructions (generally the Summarize option; for some characteristics such as Controlling Area the
Retain option).

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 79/85
9/20/2020
See also Example: Selection Criteria and Processing Instructions.

Value Fields

By default, all value elds except Value TranCurr (WTGBTR) are distributed. This setting cannot be changed as otherwise
inconsistencies could occur in the general ledger.

You can furthermore optionally specify quantity elds of the operating concern that you want to distribute.

Checking or Canceling Top-Down Distribution

After you have executed top-down distribution, you can check the results in the log.

If you executed the run in test mode, the log shows a simulation of the G/L line item postings.

If you executed the run in update mode, the log shows the G/L line items that were actually posted. You also can cancel the
distribution run from the log.

The log is displayed as soon as the distribution run has nished.

You can also display the log in the menu by choosing Actual Postings Period-End Closing Top-Down Distribution History .

From the log, you can display the G/L line items by clicking into the Line Items column in the overview section on the left-hand
side. Furthermore you can run a pro tability report by selecting the Report column.

In the detail section on the right-hand side, you can nd detailed information on the current distribution run.

Canceling a Distribution Run

If you executed the distribution run in update mode, you can cancel the run by clicking into the Cancel Run column on the left
hand side.

Another option is to cancel the top-down distribution run for a speci c variant by choosing Actual Postings Period-End
Closing Top-Down Distribution Variant Start in the menu.

Related Information
Characteristic Derivation

Example: Selection Criteria and Processing

Instructions
The characteristics Product and Product Group are taken into account (where the Product Group is derived from the Product).
The value eld to be distributed is the Total Quantity.

Products P1 and P2 belong to product group PG1, while products P3 and P4 belong to product group PG2.

During top-down distribution, all product groups are to be distributed across the individual products. Reference data should be the
actual data from the previous year and it should be distributed by value elds.

The following reference data from the previous year exists in the database:

Product Group Product Total Quantity

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 80/85
9/20/2020

Product Group Product Total Quantity

PG1 P1 10

PG1 P2 30

PG2 P3 40

PG2 P4 40

The following current data at the product group level should be distributed:

Product Group Total Quantity

PG1 600

PG2 600

In a report with the characteristic Product in the lead column, these values would appear as follows:

Product Total Quantity

# (not assigned) 1200

To distribute the values at both product groups to their products, enter the following parameters:

Processing Instructions

Characteristic Entry

Product group Retain

Product Distribution level

Other characteristics Default value (Summarize or Retain)

Selection Criteria

Characteristic Characteristic Value

Product group PG1, PG2

Product *

Other characteristics *

Each product group is now distributed separately according to the reference data for the individual products in each product
group.

A report with the lead column Product contains the following values after distribution:

Product Total Quantity

# 0

P1 150

P2 450

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 81/85
9/20/2020

Product Total Quantity

P3 300

P4 300

The data at the product group level remains unchanged since the value aggregated at the product level is retained during
distribution:

Product Group Total Quantity

PG1 600

PG2 600

The following line items were created:

Product Group Product Total Quantity

PG1 # -600

PG1 P1 150

PG1 P2 450

PG2 # -600

PG2 P3 300

PG2 P4 300

Looking at product group PG1, which contains products P1 and P2, we can see how the line items came to be:

Of the value 600, product P1 receives 150 = 600 × 10 ÷ (10 + 30), while P2 receives 450 = 600 × 30 ÷ (10 + 30). 600 was the total
value for product group PG1, while 10 is the reference value for P1 and 30 the reference value for P2. The credit posting for 600
was made to the product group level, where Product = # (not assigned).

Example: Cumulating Periods

When con guring top-down distribution for planning and actual data, you have the option of specifying a period aggregation for
the reference data (using the Cumulate Periods checkbox).

The following example demonstrates the difference between distribution with and without cumulating periods. It refers to the
distribution of actual data but can also be applied to planning data.

The actual data for the periods 1/2020 through 3/2020 that is not posted to speci c divisions is distributed to divisions
corresponding to the actual data for the periods 1/2019 through 3/2019.

Actual data to be distributed:

Division Period Value

# 1/2020 24

# 2/2020 30

# 3/2020 40

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 82/85
9/20/2020
Reference data:

Division Period Value

01 1/2019 9

01 2/2019 10

01 3/2019 5

02 1/2019 3

02 2/2019 5

02 3/2019 5

Distribution without period aggregation:

Period Distribution relationship New data records

between division 01 and
division 02 Period Division Value

1/2019 9:3 → 3:1 1/2020 01 18

02 6

2/2019 10:5 → 2:1 2/2020 01 20

02 10

3/2019 5:5 → 1:1 3/2020 01 20

02 20

Distribution with period aggregation:

Period Distribution relationship New data records

between division 01 and
division 02 Period Division Value

1/2019 - 3/2019 24:13 1/2020 01 16

02 8

2/2020 01 19

02 11

3/2020 01 26

02 14

Summarization of Account-Based Line

Items and Pro tability Segments
To avoid performance and data storage issues with large data volumes, you may need to reduce the number of account-based line
items and pro tability segments by de ning a summarization for these elements.

You de ne the summarization in Customizing under Controlling Pro tability Analysis Flows of Actual Values Initial
Steps Summarization Summarization of Account-Based Line Items and Pro tability Segments .
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 83/85
9/20/2020

Features
If account-based pro tability analysis is activated, this has the following effects on the G/L line item table ACDOCA (Universal
Journal Entry Line Items):

All characteristics are generated to table ACDOCA if they do not already exist.

Account-based line items are written to table ACDOCA and characteristics are lled for these line items.

You can de ne a summarization of elds for table ACDOCA. Since the level of summarization in table ACDOCA should be the same
as that of the pro tability segments, the summarization settings are used for account-based pro tability segment determination.

 Note
If you are using costing-based pro tability analysis, the corresponding pro tability segment determination utilizes these
settings as well. In other words, summarization is the same regardless of whether you are using account-based or costing-
based pro tability analysis.

Even if you de ne a summarization of elds for table ACDOCA, costing-based line items continue to be posted to table
CE1XXXX (where XXXX denotes your operating concern). This table uses the existing de nition of line item summarization,
which can be found in Customizing under Controlling Pro tability Analysis Flows of Actual Values Initial
Steps Summarization Summarization of Costing-Based Line Items .

More Information
For more information about this function, see the documentation in Customizing under Controlling Pro tability Analysis Flows
of Actual Values Initial Steps Summarization .

Planning
Use
The Integrated Business Planning applications provide a consistent view of the planning process. From the UI perspective, all
planning applications can be accessed by a Microsoft Excel frontend to provide a homogeneous look and feel.

More Information
For more information on the Integrated Business Planning applications, see the SAP Help Portal at http://help.sap.com SAP
Business Suite SAP HANA Innovations for SAP Business Suite Products powered by SAP HANA SAP Simple Finance Add-On
for SAP Business Suite powered by SAP HANA Application Help SAP ERP Central Component Accounting SAP Simple
Finance Add-On Integrated Business Planning for SAP Simple Finance Add-On for SAP Business Suite powered by SAP
HANA .

Information System
The information system lets you use the drilldown reporting tool for analyzing your pro tability data. The data available in
Pro tability Analysis can be processed individually and analyzed according to any desired view. The reports are de ned in modular
fashion: the individual elements of each report are de ned independently of one another in CO-PA and can be linked in any
combination in different reports.

The following reports are examples of traditional reports:

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 84/85
9/20/2020
Object list, displaying the key gures of all values for a characteristic, such as the numbers of all sales areas in one country.

Contribution margin report for a market segment

Comparison of contribution margin accounting for several market segments

Related Information

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22745197&topics=87b9bd54c3378e21e10000000a… 85/85