Profitability Analysis

Profitability Analysis
Explain the organizational assignment in the PA module?

The operating Concern is the highest node in Profitability Analysis.
The operating concern is assigned to the Controlling Area.
Within the operating concern all the transactions of Profitability Analysis
are stored.
The operating concern is nothing but a nomenclature for defining the
highest node in PA.
What is the functionality of the PA module?
PA module is the most important module when it comes to analyzing the
results of the organization.
In this module you basically collect the revenues from the sale order , the
costs from the production order, cost center or internal order and
analyze their results.
The interesting part about this module is that when it collects the costs
and revenues it also collects the characteristics associated with the costs
and revenues and this is what makes it stand out
So for e.g. using PA module you can find out the following:
Profit of a certain product
Profit of a certain product in a certain region
Profit of a certain product in a certain region by a certain customer
Profit of a certain product in a certain region by a certain sales person
And the list can go on in depth
It is one of the most wonderful modules in the SAP
How do you get all those characteristics defined above and how do
you analyze them?
To do so while defining Operating concern one has to define
Characteristics and Value fields.
What are characteristics and Value Fields?
In the operating concern two things are basically defined
a) Characteristics
b) Value Fields
Characteristics are nothing but those aspects on which we want to break
down the profit logically such as customer, region product, product
hierarchy, sales person etc

Value Fields are nothing but the values associated with these
characteristics
Eg Sales, Raw Material Cost, Labour Cost, Overheads etc
Once you define the characteristics and value fields these values are
updated in the table.
From where does the characteristics come from?
The characteristics which are defined above basically comes from either
the Customer Master or the Material Master.
How does various values( revenues and costs) flow into PA?
The Sales Revenue comes from the Condition Type in SD.
We need to map the Condition Type in SD to the respective value fields in
customizing to have the revenue flow into PA.
The Cost comes from Cost estimates which are transferred using the PA
transfer structure which we have covered in the Product costing section.
The various cost components of the cost component structure is assigned
to the value field of PA module and this is how the costs come into PA.
Once the actual revenue and the std cost defined above are captured in
PA the variances are also transferred into PA.
This way the std cost variances equal the actual cost.
So actual revenue- actual cost helps us determine the profit.
How do you configure the assignment of variances from product
costing to COPA module?
The variance categories from product costing along with cost element is
to be assigned to the value fields in COPA
Once you have captured all the costs and revenues how do you
analyze them?
The costs and revenues which we have captured in the above manner are
then analysed by writing reports using the Report Painter Functionality
in SAP.
What is characteristic Derivation in Profitability Analysis Module?
Characteristic Derivation is usually used when you want to derive the
characteristics . An example of this could be say you want to derive the
first two characteristics of product hierarchy.

In such cases you define characteristic derivation where you maintain
the rules, which contain the table names of the product hierarchy fields
and the number of characters to be extracted, and it also specifies the
target characteristic field in PA.
What is the basic difference in customizing in Profitability analysis
as compared to other modules?
In PA when we configure the system i.e. creating operating concern,
maintain structures no customizing request is generated. The
configuration needs to be transported through a different transaction
called as KE3I.
What is the difference between Account based Profitability Analysis
and Costing based Profitability Analysis?
Account based Profitability analysis is a form of Profitability analysis (PA)
that uses accounts as its base and has an account based approach. It
uses costs and revenue elements.
Costing based Profitability Analysis is a form of profitability analysis that
groups costs and revenues according to value fields and costing based
valuation approaches. The cost and revenues are shown in value fields.
What are the advantages and disadvantages of Account based
profitability analysis vis--vis costing based profitability analysis?
The advantage of Account based PA is that it is permanently reconciled
with Financial accounting.
The disadvantages are that it is not powerful as the costing based PA,
since it uses accounts to get values. No Contribution margin planning
can be done since it cannot access the standard cost estimate. Further
no variance analysis is readily available.
The advantages of the Costing based PA are manifold. They are as
follows: Greater Reporting capabilities since lot of characteristics are
available for analysis.
This form of PA accesses the Standard cost estimate of the
manufactured product and gives a split according to the cost
component split (from the product costing module) when the bills
are posted.
Contribution margin can be planned in this module since the

system automatically accesses the standard cost estimate of the
product based on the valuation approaches.
Variance analysis is ready available here since the variance
categories can be individually mapped to the value fields.
Disadvantages:Since it uses a costing based approach, it does not sometime reconcile
with financial accounting.
Can both Account based and Costing based Profitability analysis be
configured at the same time?
Yes. It is possible to configure both types of costing based profitability
analysis at the same time.
What is the advantage of configuring both the type of Profitability
analysis together?
The advantage of activating account based profitability analysis along
with costing based PA is that you can easily reconcile costing based
profitability analysis to account based profitability analysis, which means
indirectly reconciling with Financial accounting.
Is there any additional configuration required for Account based
profitability analysis as compared to costing based profitability
analysis?
No. There are no special configurations required except for activating the
account based profitability analysis while maintaining the operating
concern.
What is the difference between Profitability analysis and Profit
center accounting?
Profitability analysis lets you analyze the profitability of segments of your
market according to products, customers, regions, division. It provides
your sales, marketing, planning and management organizations with
decision support from a market oriented view point.
Profit center accounting lets you analyze profit and loss for profit centers.
It makes it possible to evaluate different areas or units within your
company. Profit center can be structured according to region, plants,
functions or products (product ranges).
What configuration settings are available to set up valuation using

material cost estimate in costing based profitability analysis?
In Costing based Profitability analysis you define costing keys. A costing
key is a set of access parameters which are used in valuation to
determine which data in Product cost planning should be read. In the
costing key you attach the costing variant.
In the costing key you specify whether the system should read the
current standard cost estimate, the previous standard cost estimate or
the future standard cost estimate or a saved cost estimate.
The configuration settings to determine this costing key is as follows:1) Assign costing keys to the products Three costing keys can be
attached to a single product for a specific point of valuation, record
type, plan version.
2) Assign costing keys to Material types
3) Assign costing keys to any characteristics You can use your own
strategy to determine the costing keys. This is through user
defined assignment tables.
Assign your DataSource a unique name for generation. In the default settings, this
name comprises the following elements:
Prefix "1_CO_PA"
R/3 system ID
Client
Operating concern
for client 100, operating concern XYZ the name of the datasource would be 1_CO_PA100XYZ.
For a description of the generation procedure and the tools for generating DataSources for
an operating concern, see the SAP Reference IMG in R/3:
SAP Customizing Implementation Guide >> Integration with Other SAP Components >>
Data Transfer to the SAP Business Information Warehouse>> Settings for ApplicationSpecific DataSources (PI) >> Profitability Analysis >> Create DataSource
Check this.......
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sapportals.km.docs/library/busines
s-intelligence/g-i/how%20to%20connect%20between%20co-pa%20and%20sap%20bw
%20for%20a%20replication%20model.0x
Regards,
Debjani....
o
Helpful AnswerRe: COPA datasource tips
Alert Moderator
o
Like (0)
sujatha sanjeev Dec 23, 2008 12:34 PM (in response to Deepak S)

CO-PA is a generic extraction.So you have to create a generic DataSource depending on the
KPI's for PA
R/3 - SBIW -Generic DataSource -Profitability analysis - Create data source.
CO-PA extracts data from four tables for costing based PA namely
CE1XXXX-Actula line items
CE2XXXX-plan line items
CE3XXXX-summary table
CE4XXXX-segment table
where XXXX is the operating concern
for Account based PA its extracted from
COPE-Actual line items
COEJ-plan line items
COSP COSS-summary table
the field are proposed based on the operating concern you are creating the DataSource on.
the characteristics and value files are proposed based on the OC. Without CO PA being setup
on the R/3 side
its not possible to do PA on BW side.You can choose which ever field you want depending on
OC.
There is a naming convention also for the datasource.
1_CO_PA_(SYSTEM ID)_CLIENT)_(OPERATING CONCERN)
o
Re: COPA datasource tips
hemalatha vetrivel Dec 23, 2008 12:54 PM (in response to Deepak S)

Hi,
I hope this will help.
COPA Extraction Steps
The below are the command steps and explanation. COPA Extraction -steps
R/3 System
1. KEB0
2. Select Datasource 1_CO_PA_CCA
3. Select Field Name for Partitioning (Eg, Ccode)
4. Initialise
5. Select characteristics & Value Fields & Key Figures
6. Select Development Class/Local Object
7. Workbench Request
8. Edit your Data Source to Select/Hide Fields
9. Extract Checker at RSA3 & Extract
BW
1. Replicate Data Source
2. Assign Info Source
3. Transfer all Data Source elements to Info Source
4. Activate Info Source
5. Create Cube on Infoprovider (Copy str from Infosource)
6. Go to Dimensions and create dimensions, Define & Assign
7. Check & Activate
8. Create Update Rules
9. Insert/Modify KF and write routines (const, formula, abap)
10. Activate
11. Create InfoPackage for Initialization
12. Maintain Infopackage
13. Under Update Tab Select Initialize delta on Infopackage
14. Schedule/Monitor
15. Create Another InfoPackage for Delta
16. Check on DELTA OptionPls r
17. Ready for Delta Load
Alert Moderator
o
Like (0)
LIS, CO/PA, and FI/SL are Customer Generated Generic Extractors, and LO is BW Content
Extractors.
LIS is a cross application component LIS of SAP R/3 , which includes, Sales Information
System, Purchasing Information System, Inventory Controlling....
Similarly CO/PA and FI/SL are used for specific Application Component of SAP R/3.
CO/PA collects all the OLTP data for calculating contribution margins (sales, cost of sales,
overhead costs). FI/SL collects all the OLTP data for financial accounting, special ledger
1) Add the fields to the operating concern. So that the required field is visible in CE1XXXX
table and other concerned tables CE2XXXX, CE3XXXX etc.
2) After you have enhanced the operating concern then you are ready to add it to the CO-PA
data source. Since CO-PA is a regenerating application you can't add the field directly to the
CO-PA data source. You need to delete the data source and then need to re-create using
KEB2 transaction.
3) While re-creating the data source use the same old name so that there won't be any
changes in the BW side when you need to assign the data source to info-source. Just
replicate the new data source in BW side and map the new field in info-source. If you recreate using a different name then you will be needing extra build efforts to take the data
into BW through IS all the way top to IC. I would personally suggest keep the same old data
source name as before.
If you are adding the fields from the same "Operating concern" then goto KE24 and edit the
dataaource and add your fields. However if you are adding fields outside the "Operating
concern" then you need to append the extract structure and
populate the fields in user
exit using ABAP code. Reference OSS note: 852443
1. Check RSA7 on your R3 to see if there is any delta queue for COPA. (just to see,
sometimes there is nothing here for the datasource, sometimes there is)
2. On BW go to SE16 and open the table RSSDLINIT
3. Find the line(s) corresponding to the problem datasource.
4. You can check the load status in RSRQ using the RNR from the table
5. Delete the line(s) in question from RSSDLINIT table
6. Now you will be able to open the infopackage. So now you can ReInit. But before you try
to ReInit ....
7. In the infopackage go to the 'Scheduler' menu > 'Initialization options for the source
system' and delete the existing INIT (if one is listed)
Lets the give the answers to questions you have asked.

1)Can we generate more than one COPA datasource ... ?
Yes you can always generate more then one...count may go till 10 and more ...10 I have seen.
2)If more then one datasource can be genrated ... how does the delta function?
Since COPA data source pulls the data from separate COPA specific tables and its built in a way that it
pulls the data from those tables only...so its not dependent upon the operations that are happening at the
same time in the system.It now has generic delta logic...that is the same logic used by the generic data
source.
Delta records are pulled based on the timestamp which is maitained for each records when updating into
the table and there is always a half an hour default safety interval.
Now the delta is maintained through the delta queue and the pointers for the data update is maintained
separately for each data source.
You can check it in the table ROOSGENDUM in R/3 system.:::::depending upon this the data is pulled for
different data source.
try to compare it wth a generic data source and you will understand a lot.In the same was as more then
one generic data source can be built on one table in R/3.
3)If i create COPA datasource at item level ..... can we use DSO + cube
combination?
You can always use DSO to load COPA in overwrite mode....and then load it to the cube..just make sure
that you chose proper keys ...or the semantic combination of keys like used in write optimized DSO.
CO-PA Data Source

The main entity for a Co-PA data source is "Operating Concern", which would be given by COPA
Consultants.
Here, 2 types of operating concerns would be defined. We can check the Operating Concern structure in
the transaction code: KER1/KEAS or KEA0(to create and to display).
1. Cost Based : Used for Product based industries.
2. Account Based: Used in service based industries.
The standard R/3 System contains the sample operating concern "S001". You can copy this operating
concern to create your own operating concern. When you activate the data structures of your operating
concern, the system creates the following objects in the ABAP Dictionary:
Type
Name
Description
Structure CE0xxxx
logical line item structure
Table
CE1xxxx
actual line item table
Table
CE2xxxx
plan line item table
Table
CE3xxxx
segment level
Table
CE4xxxx
segment table
Table
CE4xxxx_KENC
realignments
Table
CE4xxxx_ACCT
account assignments
Table
CE4xxxx_FLAG
posted characteristics
Structure CE5xxxx
logical segment level
Structure CE7xxxx
internal help structure for

assessments
Structure
CE8xxxx
internal help structure for assessments
for Account based PA its extracted from

COPE-Actual line items
COEJ-plan line items
COSP COSS-summary table
In these names, "xxxx" stands for the name of the operating concern.
Creating CO-PA Data Source:
1. After getting the Operating Concern from the functional team, go to the tcode KEB0 or follow the below
mentiond path in SBIW.
Data Transfer to the SAP Business Information Warehouse -> Settings for Application-Specific
DataSources -> (PI)Profitability Analysis -> Create Transaction Data DataSource.
In the COPA DataSource for Transaction Data screen: 1_CO_PA%CL%ERK is automatically generated.
Do not change anything. You can add additional characters.
Note: The name of copa data source always start with the numeric One. Here CL is your client number
and ERK is your operating concern name.
Select Field Name for Partitioning (Eg, Ccode(BUKRS) for cost based Profit Centre(PRCTR) for account
based).
In the transaction bar enter the tcode =INIT . Now, you could be able to select the required fields.
Select all Characteristics from the segment level and Select all Value Fields.
Choose InfoCatalog from the application toolbar.
a). For costing-based Profitability Analysis, select the value fields and calculated key figures that are to be
included in the DataSource. It is useful to include all the value fields of the operating concern. These
value fields are already selected but you can deactivate them if necessary. The system checks that the
units of measure relating to the value fields are also transferred.
Technical notes:
Along with the selected characteristics and value fields, the fiscal year variant and the record currency are
also included in the replication so that the data in SAP BW can be interpreted correctly.
The technical field PALEDGER (currency type) in Profitability Analysis is encrypted as CURTYPE
(currency type) and VALUTYP (valuation) during the transfer to SAP BW.
The plan/actual indicator (PLIKZ) is copied to SAP BW as value type (WRTTP).

2. The Create Object Directory Entry dialog box is displayed requesting the user to enter a development
class. Enter a development class in the customer namespace and choose Save or choose Local object.
3. On the DataSource: Customer version Edit screen:
a. Select all possible checkboxes in column Selection.
b. Choose Save.
4. In the information dialog box, choose Enter.
5. Then replicate the datasource in BW and generate the data flow.
6. To maintain the deltas, maintain the time stamp in KEB2/KEB5.
CO-PA Datasource Enhancement:
You cannot change a DataSource once created. You can, however, delete it and then create a DataSource
with the same name but with different technical properties. You should not upload metadata between
these two steps.
In the ECC System:

1) Add the fields to the operating concern. So that the required field is visible in CE1XXXX table and other
concerned tables CE2XXXX, CE3XXXX etc.
2) After you have enhanced the operating concern then you are ready to add it to the CO-PA data source.
Since CO-PA is a regenerating application you can't add the field directly to the CO-PA data source. You
need to delete the data source and then need to re-create using KEB2 transaction.
3) While re-creating the data source use the same old name so that there won't be any changes in the
BW side when you need to assign the data source to info-source. Just replicate the new data source in
BW side and map the new field in info-source. If you re-create using a different name then you will be
needing extra build efforts to take the data into BW through IS all the way top to IC. I would personally
suggest keep the same old data source name as before.
If you are adding the fields from the same "Operating concern" then goto KE24 and edit the dataaource
and add your fields. However if you are adding fields outside the "Operating concern" then you need to
append the extract structure and populate the fields in user exit using ABAP code. Reference OSS note:
852443
In the BW System:
1. Check RSA7 on your R3 to see if there is any delta queue for COPA. (just to see, sometimes there is nothing here for the datasource,
sometimes there is)
2. On BW go to SE16 and open the table RSSDLINIT
3. Find the line(s) corresponding to the problem datasource.
4. You can check the load status in RSRQ using the RNR from the table
5. Delete the line(s) in question from RSSDLINIT table
6. Now you will be able to open the infopackage. So now you can ReInit. But before you try to ReInit ....
7. In the infopackage go to the 'Scheduler' menu > 'Initialization options for the source system' and delete the existing INIT (if one is listed)
In order to meet more robust reporting needs, solution was designed with
integration of CO-PA and BI, with dynamic data transfer from CO-PA to BW cubes.
Standard precautionary measures were adopted to have a parallel run to make sure
the standard CO-PA solution meets the requirements, prior to de-commissioning the
legacy solution. Benefits Fully allocated P&L by business segments Flexible and
adaptive to current and future reporting needs Highly integrated with SD and FI
and better traceability. Designed Dual CO-PA (both account-based and costbased CO-PA). Designed to meet all company specific reporting requirements.
CO-PA reports with impressive performance and robust analytical functionality
Define Profitability Segment Characteristics (Segment-Lvl Ch

In this step, you specify whether a characteristic in CO-PA is used to create profitability segments.
Characteristics that are used to create profitability segments are available for the information system and in
planning, for example.
Characteristics that are not involved in the creation of profitability segments remain in their line item in CO-PA.
Frequently occurring characteristics that rarely bear the same value (such as the sales order number for a
repetitive manufacturer) can thus be excluded from the creation of your profitability segment. In this way, you
can improve the performance of your profitability analysis considerably.
Furthermore, you can perform profitability analysis at the customer group level or at the product group level by
ceasing to use customers or products in that analysis.
Note
Before you execute the first transfer of productive data to Profitability Analysis, you should make the
appropriate setting specifying which characteristics should be involved in creating profitability segments. The
only type of change that you can make subsequently is the deactivation of more characteristics for the
determination of a profitability segment. If you later include a characteristic in the determination process, your
CO-PA data will then be incomplete for all affected characteristics.
Instead of excluding characteristics generally, you have the option of excluding a characteristic under certain
conditions and thus define exceptions for how characteristics are used. In this way, make-to-order
manufacturers with a spare parts business, for example, can exclude the spare parts business from their
analyses, or wholesale manufacturers with a large number of customers can restrict their analysis at the
customer level to key customers. The purpose of this function is to reduce the amount of created profitability
segments by updating in detail only those values that are relevant for a particular analysis.
Note
This function is a purely technical function with which to reduce the number of profitability segments. It is
intended for allow users with large data volumes to optimize their system performance. It should be used with
caution because it is usually not possible to reverse its effects: these can be undesirable if the function is
applied incorrectly. If you want to use the function, you should first read the section Exceptions concerning
segment-level characteristics, which contains a detailed description of the function, with examples.
Standard settings
Along with "sales order", the origin terms "order", "WBS element" and "cost object" should not be used as
characteristics in the formation of profitability segments. Thus, when you create a new operating concern, the
relevant table is automatically set so that the following characteristics are not used to form the profitability
segments:
- sales order (KAUFN)
- sales order item (KDPOS)
- order (RKAUFNR)
- WBS element (PSPNR)
- cost object (KSTRG)
All other characteristics - including "Customer" and "Product" - are used and therefore are available for
profitability reports, planning, and account assignments to profitability segments, for example. No exceptions
are defined by default.
If you need to make a different setting to these, change the entries accordingly. In this case, you should check
the index to the object table, expecially if you exclude the characteristics "Customer" or "Product". By defining
an index that is most optimally reconciled to how the segment-level characteristics are to be used, you can
improve performance considerably. For more detailed information about indexes, see the application
documentation for Profitability Analysis and choose Technical Aspects of Profitability Analysis -> Index Support
for Determination of Segment Numbers.
Recommendation
To avoid performance problems, we recommend the exclusion of characteristics that occur frequently, have a
different value with each posting (such as "Automobile chassis number") and are thus not relevant for analysis.
Activities
Specify which characteristics of your operating concern should be used to form profitability segments. You do
this by choosing the option "costing-based" or "costing-/acct-based". If a characteristic should not be used,
select "not used".
Best Practice - Operating Concern

This question has been Answered.
Teck Liang Wee

Apr 12, 2013 8:52 AM
Hi Experts,
I would like to seek your opinion on what are the criteria that needs to be taken into
consideration when modeling Operating Concerns and Controlling Areas. I have read some
documentation which says that the best practice is to go with a single OpCon and CO Area.
However, I am not clear as how this became "best practice".
Today, we have four different instances based on geography where in two instances, we
have one OpCon/CO Area per country and in another two, they have single OpCon/CO Area
covering the entire geography. Needless to say, each region has different COPA set up.
However, we are looking at harmonizing the design since the reporting
characteristics/requirements across the different business units are similar.
Having said that they have very high data volume. This is an area of huge concern to us as
we do run COPA assessments and Top Down Distribution in our design - we are worried that
a single operating concern will slow down these allocation process due to the huge number
of profitability segments involved if we were to go with a single operating concern.
Before we make any final recommendations, I would like to hear from you experts on the
evaluation criteria and rationale on choosing between single OpCon/CO Area vs Multiple.
Thank you.
TL
Correct Answer by Jeffrey Holdeman on Apr 15, 2013 9:30 PM

Hi TL,
I believe the question you are asking is vitally important to all SAP enterprise structure
discussions and I am glad that you raised it.
I agree that one controlling area and one operating concern is most often the view which
gets promoted as a best practice. I think the origin of such a design goes all the way back to
the days of having only the R/2 or R/3 system to report managerial accounting results. The
CO reporting tools inside of R/2 and R/3 could not report across controlling areas or
operating concerns, so there was an absolute technical restriction. If an organization
wanted an aggregated view of their enterprise they were encouraged to create a single
operating concern and controlling area. Not only did this design solve the technical problem
of data access, but it also forced the organization to define a common chart of accounts and
global currency, both of which are necessary to have in place to get the desired aggregated
view.
Later with the introduction of SAP Business Warehouse, as well as 3rd party reporting tools
like BusinessObjects, Cognos and Hyperion, pure Business Intelligence consultants would
argue having a single operating concern and controlling area becomes less important
because data access is no longer a restriction. This was because any of the tools I just
mentioned could report across operating concerns or controlling areas. Yet as you point out,
the global design 'best practice" has stood. Why? Two of the main reasons, in my opinon, is
due to the aforementioned need to agree on the chart of accounts and common currency
and capture that in the transaction, rather than dealing with those topics in the data
warehouse.
The third reason I would say CO consultants tend to promote the idea of single controlling
areas and operating concerns is it forces a common design in everything else such as with
master data (e.g. for cost elements, cost centers) and with transaction posting logic (field
status rules, transfer structures, settlement rules, validations, substitutions, etc.). Thus the
configurations that need to be put in place to support the process designs are done once
and are globally consistent. Whereas with separate CO areas and Op Concerns the likelihood
of differences is great. And when you deal with multiple SAP instances then it is nearly
impossible to keep a global design in sync. In your own organization you mentioned that
you have regional differences, so you know this well. For some enterprises these regional
differences are intended, but for others, maybe not.
Some other points to discuss in your analysis include the following:
1) Can the enterprise agree on a common fiscal calendar for a single controlling area and
operating concern? Often I've seen organizations that have to deal with multiple fiscal year
calendars and this drives multiple controlling areas.
2) Can the enterprise coordinate a period closing schedule across a global organization?
With having only a a single controlling area, all month end jobs must be scheduled or run
online in coordination with each other. This is very hard to setup and to make work
effectively in globally dispersed organizations across the globe and the world clock. Locking
the CO area cannot be done by country, region, etc. it must be done globally. Whereas with
country level controlling areas this is much easier to accomplish.
3) Does your organization need to, or does it even allow, cross charging across countries?
Can CO assessments and distributions be used across country boundaries? If yes how would
invoicing and taxes be handled? If no, is it better to block cross country allocation through
validation rules or by defining separate organizational hierarchies, such as having country
level controlling areas?
4) As Piet mentioned above, does the organization desire to have global costing processes?
If yes, then one controlling area is preferred. But again, with external costing software like
SAP Profitability and Cost Management, maybe that "best practice" can be updated with
modern approaches.
5) When we need to talk about a single global CO-PA design, it sometimes can be difficult to
come to agreement on the operaring concern definition. You have a limitation of 50 custom
characteristics and if the enterprise works in several very different lines of business, then it
is easy to chew up a lot of characteristics to meet each unique business need. Similar story
for value fields you are limited to 120 (or 200 with SAP note) value fields, which can be hard
to fit, if your organization does not have a centralized design. When setting up the
derivation strategy for the characteristic values, this can be tricky and have to deal with all
kinds of exception handling if the various business units do not have a common definition of
the cutomer or material master. For what is customer group for one unit, may be customer
class for another. Should both fields be included in CO-PA? Should a custom field be
included that derives from these two? There are many questions like these to be answered.
6) A final perspective to consider is system landscape and system performance. In the past
companies with huge data volumes found benefits from physically separated SAP systems
into regional instances, and they might have logically partitioned data by client and then
further by enterprise structures. However with today's fast CPUs, giant memory capacity,
parallel processing -- all the features we talk about with SAP HANA -- new options and new
designs are possible which support the one controlling area and one operating concern
approach.
Good luck and best regards,
Jeff Holdeman
SAP Labs, LLC
Customer Solution Adoption
See the answer in context
Helpful Answer by Piet Strydom
1408 Views
Average User Rating

(0 ratings)
Helpful AnswerRe: Best Practice - Operating Concern
Piet Strydom Apr 12, 2013 3:57 PM (in response to Teck Liang Wee)
I generally go with one controlling area per country, and one operating concern in total. It
very much depends on the local requirements though.
If for example, costing needs to take place across different countries, then you would need
to use one controlling area. But then you need to be careful with actual postings across
company codes, because there is typically a requirement for FI invoices, and transfer pricing
becomes an issue.
I am not certain that having multiple operating concerns vs a single operating concern is
going to have an impact on you processing, whether the data sits in one or 10 operating
concerns, it still needs to be processed.
Note: You have to import the Missed charecteristics from the Client 000. if at all anything is missed
How to flow SD customized partner in

COPA PAPartner Structure
We have created two customized partner in SD
1) Agent
2) credit manager
and same is not available in PAPARTNER structure in COPA.

Need to create characterstics from PAPARTNER structure but same are not available in PAPARTNER
under kea5.
SAP has recommended some OSS note but they are complex.
request you to guide me on the same.Need to flow from SD to COPA.
We are using Costing based Operating Concern. I am clear that how to get values from SD to COPA Value Fields, I.e.
assignment of Value Fields with condition types. But my confusion is how to get the values of cost element and cost
element groups to COPA Value Fields.
This is not my confusion its my client requirment.
Ans: Cost Elements to view in copa are like: Admin, S&D and Personnel Cost Elements
Where are they currently posted? If posted in IO - use settlement KO88 / KO8G... if
posted in cost centers - Create an allocation cycle from KEU1 and execute from
KEU5
Using of KE4IM Maintain assignment of MM condition

types to CO-PA value fields
I use transaction code Ke4IM to assign MM condition types to CO-PA value fields.
Then I post some purchase orders, goods receipts and invoice receipts, but non of these
postings are displayed in CO-PA reports.
I have executed the following IMG transactions/steps.
1.
KE4IM: MM condition types from MM pricing assigned to CO-PA value fields
2.
KEI2: Maintain PA structure FI (assign price difference accts to CO-PA value fields)
3.
OKB9: Enter price difference accounts + activate PA indicator

Which MM processes (purchase, goods receipt, invoice receipt) or transactions flow to COPA?
I'm implementing this in a SAP ECC 6.0 system.
Ans: You need to understand the nature of the transactions. Purchase orders do not create
postings so there is nothing to show in CO-PA (or even in FI). Goods receipts hit stock, not
the P & L account, so, again, nothing to show in CO-PA. Invoice receipts hit the GR/IR
account, so, once more, nothing to show in CO-PA. On the other hand, when goods are
issued out of stock to CoGS they should hit CO-PA. OK?
Your Purchase Price Variance account should flow to CO-PA if it hits your Profit & Loss account.
That is the basic criterion for all accounts - do they hit your profit? If they only hit the balance sheet
they do not belong in CO-PA. The best person to talk to about this subject is one of your company's
accountants who is responsible for the Profit & Loss account. Ask him what he wants to see in his
CO-PA reports.
SD is the module that feeds CO-PA with most data. For example the VPRS condition which is most
closely related to Cost of Goods Sold (CoGS) and probably the transport, rebate and discount
condition types. It all depends on the structure of the company and what they want. However, it is
good practice to make sure that your CO-PA result agrees with your FI result (with possible
exception of purely financial transactions such as interest and taxes).
Your answer is very good and comprehensive. I like to add one small thing. In case user set
up material master record as direct consumable and user create PO with account
assignment "K". SAP will create financial entry debit to expense GL with combination of cost
center at the time GR. SAP will create both FI and COPA transaction automatically. SAP will
pick GL and Cost Center inform from PO account assignment tab.
The questions on COPA will be like
1. What is the difference between PCA and COPA as both are for profitability reporting ?
2. What are the differences between Account based and Costing based PA . What would you recommend to the client
?
3. How many types of Charecteristics , value fields are there ? what are their purposes ?
4. What the the variou derivation method available .? give examples for each once ?
5. How do you create report in COPA ?
6. How do you do planning in COPA ? How do you export planning value from Excel ?
7. What is profitability Segment Charecters ? how do you define them ??
8. What are the various table used in COPA ?
9. What is valuation ? how do you use ? give an example or scenario ?
1. What is realignment and how does it works.
2. What is key figure Schema?
3. How does the data flows from other modules into COPA.
4. What is characteristic values?
5. What is summarization levels.
One option is to use PAPARTNER.. But its better to avoid that
I prefer to use a derivation rule always
Create 2 derivation rules using table Lookup from VBPA for the same partner function
1. In one Der Rule, make the sale order item KDPOS as constant value 0000
2. In the other one, dont make it a constant....Leave it as it is
Two rules are required because,
a. the partner function is updated in VBPA table without line item if the same is derived from customer master and not
changed in sale order.. In this case line item is 0000 in VBPA table...
b. It updates the table VBPA with line item incase it is changed or entered during Sale order creation...
So, your derivation rule will look like this
Source
VBPA- Sales Order Mapped to COPA-Sales Order

VBPA-Sales Order Item Mapped to COPA - Sales Order Item (Constant 0000 in Der Rule 1)
VBPA-PARVW MApped to COPA-UserTemp1 (Constant XX Partner Function)
Target
VBPA-KUNNR Mapped to COPA-WWXXX Char
In the 2nd derivation rule, every thing will be same except that you wont specify any Constant for Sales Order Item
Derivation rule contains the parameters and conditions as to how to derive a value for a given
characteristic.
it contains
Source Fields - from where the source field is originatingand the field name
Target fields - contains what is the target field in COPA for the relevant source field.
This field is nothing but the charactiristic.
For example:
When an SD document is posted, system will look for all the characterics available in the doucment like
plant, profit center, division, district, country etc
for each of these characteristics, there must be values for example plant - xx18, profict center - 100000,
district - bangalore, country - India etc.
once we define the characteristic values for each of the characteristic, if the values in the document are
available in the characteristic value definition, then system will fetch these values to COPA
Else it will throw error that characteristic value is not defined
Valuation Using Conditions

Use
The condition technique allows you to calculate anticipated values using percentage
additions/deductions, prices, or absolute amounts. As with price determination in
SD, you can use the condition technique to define a set of rules for calculating
anticipated freight costs, for example. In the following section, you can find a
description of how you can define the set of rules to suit your own valuation needs.
For more information, see Pricing and Conditions in the online documentation
for Sales and Distribution (SD) .
Features
To supplement data that is being processed from the Sales and Distribution (SD)
component or from Planning in CO-PA, define a set of rules in Customizing which
you can then use to calculate the appropriate values and to post them to CO-PA. For
example, you could include the following requirements for calculating values:
You wish to assign additions/deductions (percentage or quantity-dependent)

or fixed values to the corresponding value fields.
The additions and deductions should be calculated in relation to certain

combinations of characteristics that you are free to choose (such as customer
and product).
They should also be calculated using a multi-leveled callup logic. A price, for
example, should first be found for special combinations of customers and
products. If this price cannot be found, the system looks through the product
groups for a valid price or searches at the division level.
Instead of taking just those individual value fields that already have been
filled with data in the line item as the basis for calculating additions and
deductions, subtotals or value fields filled with data during valuation should also
be used where applicable.
You wish to calculate the value of goods using a condition from the material
master or the goods issue document.
All these above requirements can be met using the condition technique. Before
going into detail about the procedure for displaying the possible strategies, it is
necessary to discuss various concepts. The possible valuation strategies are then
outlined in an example, followed by a description of how to represent business
requirements.
Costing Sheets
In a costing sheet, you specify which conditions should be used to calculate
anticipated values. This is also where you determine the sequence in which the
conditions are to be considered and the dependencies between them. For example,
you can define the condition that sales commission be calculated on the basis of the
sales revenue.
In Planning, you can use costing sheets from SD alongside those that you created in
CO-PA.
In the costing sheet, you specify the following:
The basis on which the additions or deductions are to be calculated
The subtotals to be calculated
The dependencies between conditions
The sequence in which calculation is to occur
Condition Types, Condition Tables, and Condition Records

A condition type represents one step in a costing sheet. Condition types can
Determine fixed amounts and calculate additions and deductions (percentage

or quantity-dependent)
Read prices (such as the standard price) from master records
Serve as the basis for calculating additions and deductions (base conditions),
or
Find characteristic-dependent values through accessing series of condition

tables (The values that are to be determined on the basis of characteristic
values are stored in this case as condition records in the condition tables).
Each condition record stores the condition data maintained manually for certain
combinations of characteristic values. For example, a condition record could be a
price ("USD 3") for a certain product or a percentage charge or reduction ("3 %") for
a certain customer.
Access Sequences and Condition Tables
During valuation, the system follows an access sequence to find valid condition
records for a condition type. From a technical point of view, these condition records
are stored in condition tables. The condition table determines the key combination
(such as customer and product group) for which the condition record is to be stored
and to be used in valuation.
A condition table can be used in more than one access sequence. Thus, the access
sequence determines:
The condition tables that are used to access condition records, and
The order in which these condition tables are read
How the Elements of the Condition Tool Fit Together
The costing sheet forms the calculation logic for valuation using conditions. Here
you determine the order in which the condition types are processed. Each condition
type can be assigned one access sequence (or none, depending on the condition
category). This access sequence in turn can access one or more condition tables. A
condition table can be used in more than one access sequence. Moreover, it can
store more than one condition record.
Example
You want to calculate a percentage surcharge based on what material group is
involved in a transaction. For certain materials, however, you should define a
percentage surcharge at the material level. You want to apply the surcharge for the
material group only if no surcharge is defined for the specific material being sold.
The surcharge for each material should take precedence over that for each material
group.
To realize this requirement, you need two condition tables: one with the
characteristic "Material group" in the key and one with "Product" in the key. You can
then define one access sequence to access these condition tables. First, the system
uses the product number to read the condition table for the individual product
(since this is to take priority). If no suitable condition record is found in that table,
the system uses the material group to read the other table.
Multiple Costing Sheets
You can use more than one costing sheet with the same valuation strategy. This
makes sense if you want to calculate prices with different quantity fields.
Note that if multiple condition types are assigned to the same value field, the values
are added together. This is also the case when the condition types belong to
different costing sheets.
Multiple Valuation Methods
In valuation, the system never overwrites an existing value (other than "0") in any
value field. This means that values transferred directly from billing documents in
Sales and Distribution (SD) are not changed during valuation. Likewise, values
already taken from material cost estimates cannot be overwritten with the values
calculated in a costing sheet.
Values transferred from the sender document and manually entered values (other
than zero) are consequently never changed during valuation. The only exception to
this is in CO-PA planning, where valuation always overwrites the manually entered
values.
Different valuation techniques - for example, material cost estimate or conditions do not overwrite any value fields that are filled (value <> zero) or add values to the
existing values. You can only add values within one valuation technique.
Activities
To set up valuation using conditions, choose Master Data Valuation Define
Conditions and Costing Sheets in Customizing.
Profitability Analysis allows Management the ability to review information with respect to the companys
profit or contribution margin by business segment. Profitability Analysis can be obtained by the following
methods:
Account-Based Analysis which uses an account-based valuation approach. In this analysis, cost
and revenue element accounts are used. These accounts can be reconciled with FI(Financial
Accounting).
Cost-Based Analysis uses a costing based valuation approach as defined by the User.
1. Maintaining Value Fields
Transaction Code KEA6
IMG Menu Controlling -> Profitability Analysis -> Structures -> Define Operating Concern -> Maintain
Value Fields
2. Maintaining the Operating Concern
Transaction Code KEA0
IMG Menu Controlling -> Profitability Analysis -> Structures -> Define Operating Concern -> Maintain
Operating Concern
3. Maintaining Characteristic Values
Transaction Code OVSV
IMG Menu Logistics General -> Material Master -> Settings for Key Fields -> Data Relevant to Sales
and Distribution -> Define Product Hierarchies
4. Setting Operating Concern
Transaction Code KEBD
IMG Menu Controlling -> Profitability Analysis -> Structures -> Set Operating Concern
Flows of Actual Values:
Defining Number Ranges for Actual Postings
Transaction Code KEN1
IMG Menu Controlling -> Profitability Analysis -> Flows of Actual Values -> Initial Steps -> Define Number
Ranges for Actual Postings
Activating flag for COPA
Transaction Code KEKE
IMG Menu Controlling -> Profitability Analysis -> Flows of Actual Values -> Activate Profitability Analysis
Assigning Value Fields
Transaction Code KE41
IMG Menu Controlling -> Profitability Analysis -> Flows of Actual Values -> Transfer of Incoming Sales
Orders -> Assign Value Fields
Assigning Quantity Fields

Transaction Code KE4M
IMG Menu Controlling -> Profitability Analysis -> Flows of Actual Values -> Transfer of Incoming Sales
Orders -> Assign Quantity Fields
Planning:
Defining Number Ranges for Planning Data
Transaction Code KEN2
IMG Menu Controlling -> Profitability Analysis -> Planning Initial Steps -> Define Number Ranges for
Planning Data
Maintaining Versions
Transaction Code SPRO
IMG Menu Controlling -> Profitability Analysis -> Planning Initial Steps -> Maintain Versions
Setting up Planning Framework
Transaction Code KEPM
IMG Menu Controlling -> Profitability Analysis -> Planning -> Planning Framework -> Set Up Planning
Framework
Information System:
Defining Forms for Profitability Report
IMG Menu Controlling -> Profitability Analysis -> Information System -> Report Components -> Define
Forms -> Define Forms for Profitability Reports
Defining Variables for Reports
Transaction Code KE3E
IMG Menu Controlling -> Profitability Analysis -> Information System -> Report Components -> Define
Variables for Reports
Creating Profitability Report
IMG Menu Controlling -> Profitability Analysis -> Information System -> Report Components -> Create
Profitability Report
Enterprise Structure:
Activating Costing Based Profitability Analysis for Controlling Area

IMG Menu Controlling -> Profitability Analysis -> Flows of Actual Values -> Activate Profitability Analysis
Transaction Code KEKE
Assigning Controlling Area to Operating Concern
Transaction Code SPRO
IMG Menu Enterprise Structure -> Assignment -> Controlling -> Assign controlling area to operating
concern
Master Data
KA01 Creating Additional Cost Elements - New
Transaction Code KA01
SAP menu Controlling -> Cost Center Accounting -> Master Data -> Cost Elements -> Individual
Processing
Changing Additional Cost Elements - Text
Transaction code KA02
SAP menu Controlling -> Cost Center Accounting -> Master Data -> Cost Elements -> Individual
Processing
Changing Cost Element Group
Transaction Code KAH2
SAP Menu Accounting -> Controlling -> Cost Center Accounting -> Master Data -> Cost Element Group
Change
In costing-based CO-PA, you need to assign condition types and quantity fields from Sales and
Distribution (SD) to the value and quantity fields CO-PA.
Activities:
Assign condition types to the desired value fields. These assignments let you transfer "real" conditions
(those that are posted to FI) and "statistical" (fictitious) conditions to CO-PA. Assign value fields.
For real conditions, the corresponding revenue, sales deduction, and cost-of-sales accounts must be
defined as CO-relevant accounts (cost or revenue elements).
Assign the quantity fields in SD to the desired quantity fields in CO-PA. Assign quantity fields.
If desired, reset individual value fields for billing documents of a certain billing type. Reset value fields.
For account-based CO-PA, the system only transfers those posting lines that are posted to FI as well.
Activities:
Only "real" postings that are posted to FI can be transferred to account-based CO-PA. All you need to do
to transfer this data to CO-PA is make sure that the desired revenue, sales deduction, and cost-of-sales
accounts are defined as relevant for CO.
Simulate Billing Document Transfer

In the activity "Simulating the Transfer of Documents from Billing", you have the option of simulating the
transfer of billing document data into Profitability Analysis.
Simulation occurs on the basis of the Customizing settings valid at the time it is carried out. You can view
the characteristics and value fields of the line item to be written to COPA.
The function "Valuation analysis" allows you to perform an analysis of the valuation strategy valid for
valuating billing document data.
You can also restart the simulation of document transfers for billing documents that have already been
transferred. This option should simplify in particular the analysis of error situations that have arisen.
Performing this simulation causes no data to be posted to COPA or to other modules.
<b>Check tcode KEAT also</b>
Check Value Flow in Billing Document Transfer

In this activity, you can compare your actual data in Profitability Analysis with the data posted in Financial
Accounting (FI). This makes it possible to analyze the flow of values from SD billing documents to CO-PA,
find and analyze any differences between the different applications.
Billing data is stored by condition types in SD, accounts in FI, and value fields in costing-based CO-PA.
The reconciliation report yields a list of the balances for value fields, condition types, and profit and loss
accounts.
The basic logic/purpose behind use of COPA is to know the trends in

revenues and profits over various segments.
Therefore basically only those values are transferred into COPA which are
considered as a cost or revenue.
In your case, i think you are trying to transfer the tax amount which is recovered from the
customers and paid again to the Govt. Its neither an income nor a cost to you. And may that
tax amount is going into your current liabilities GL than an income GL.
If the tax which you are recovering in an invoice is posted on a Balance Sheet account it is
not transferred into COPA even though you assign the condition to a value field and also try
this t.code KEA6 if the amount value field not in ke4i. Here you maintain the value field for
amount and then assign
Tcode KE4I
Revenue and Transfer+-
Tcode KE4W
COGS in COPA and FI

Saad Baig
Apr 30, 2013 2:57 PM
I am facing an issue that my COGS in FI is reconciling with the COPA. Let me explain the
settings which I have made in the system before discussing the issue.
I have created separate value field for COGS in COPA and this value field is mapped with the
condition type VPRS in SD. VPRS is a statistical condition. My COGS account in chart of
account is posted at the time of PGI and COPA is posted when invoice/billing is done.
Now let me explain the problem with an example.
Example:
Date of Sales Order Creation:

Date of PGI:
Date of Invoice:
28 January 2013
5 February 2013
9 February 2013
The system post the following accounting at the time of PGI,

COGS
Debit
Stock
Credit
Value posted in COGS is calculated by multiplying the quantity delivered with standard cost
estimate of February 2013. (I belief that system is behaving correctly in this case).
At the time of billing value field COGS is posted in COPA. The value posted in the value field
is calculated according to the following formula.
COGS in COPA = Quantity Delivered x Standard Cost Estimate at the time of Sales
order Creation
(I belief that formula should be,

COGS in COPA = Quantity Delivered x Standard Cost Estimate at the time of PGI)
Because of the difference in above formula my COGS in COPA and FI is not reconciling.
Please let me know is my understanding is correct or not. If correct then what is the solution
to correct the calculation of COGS in COPA.
Regards
Correct Answer by Ajay Maheshwari SAP Trainer on May 2, 2013 2:06 PM

Hi Saad
1. VPRS condition usually stores the value at which PGI has happened. If this is not the case
in your case, then talk to your SD guy.. The VPRS shown in the sales order is for name sake..
The value that flows to COPA is the value at which PGI happens (Ideal Situation)
In billing, if you want to know how the system has fetched the VPRS value, Go to the
condition tab of the billing document, select the VPRS condition type and click on blue lens
at the bottom left.
If the condition control field is set to
'H', the cost was taken from the goods issue (Ideal situation)
'A', it was redetermined from the valuation segment of the material master
in case of 'D' or 'E' it was copied from the preceding document (Sales order)
2. The diff between Period indicator 4 and Current cost estimate will come if the std cost has
changed after PGI and before billing... Say, Std cost at PGI was 100 and at billing say it is
108... If the period indicator is 4, it will bring the cost comp split of 100.. If the indicator is
"Current cost est", it will bring the cost comp split of 108 into COPA
Br, Ajay M
Helpful Answers by Big Choi, Ajay Maheshwari SAP Trainer
4060 Views
Products: sap_erp_financials Topics: enterprise_resource_planning
Average User Rating

(0 ratings)
Helpful AnswerRe: COGS in COPA and FI
Big Choi May 1, 2013 11:05 AM (in response to Saad Baig)
Hi...
You should reconcilie FIs COGS with CO-PAs COGS value field which is valuated using
costing key instead of this value field which is mapped with the condition type VPRS in SD.
You check your configuration, Define Access to Standard

Estimate.(Path:Controlling>Profitability Analysis>Master Data>Valuation>
Set up Valuation Using Material Cost Estimate).
I recommends costing key which have 4 Released standard cost estimate matching
goods issue date" in period indicator field.(COGS in COPA = Quantity Delivered x
Standard Cost Estimate at the time of PGI)
Alert Moderator
Like (0)
Helpful AnswerRe: COGS in COPA and FI
Ajay Maheshwari SAP Trainer May 2, 2013 5:55 AM (in response to Saad Baig)
Hi
COPA gets posted with 2 types of COGS i.e. one through VPRS and the other one as Cost
Component Split of the std cost.... Which of these is not matchiing with FI??
If the VPRS COGS is not matching (Though chances are less) - You can redetermine the
pricing conditions @ Billing,. Ask your SD guy to do those settings
If the Cost Comp Splt is not matching - Use the Period indicator 4 in your costing Key...
however, it seems you are changing std cost estimate each month, without which this
problem cant occur.. Its not a right practice to change it each month
Br, Ajay M
Alert Moderator
Like (0)
Re: COGS in COPA and FI
Saad Baig May 2, 2013 12:48 PM (in response to Ajay Maheshwari SAP Trainer)
Hi
Ajay you are right that there are two COGS in COPA i am actually concerned with the VPRS.
My VPRS calculated in SD is not correct. What do you say, can we correct this from CO ?
I have used the indicator " Current Cost Estimate in Material Master" in the period indicator
in costing key for standard cost estimate. You are saying that Period Indicator 4 i.e.
4 Released standard cost estimate matching goods issue date should be used (SAP also
recommend this for reconciliation with FI) but i am unable to understand the logic behind
indicator "Current Cost Estimate in Material Master".
In other word whats the difference difference between "4 Released standard cost estimate
matching goods issue date" , " Current Cost Estimate in Material Master" and "Cost Estimate
at the time of Posting"
Regards
MOEED
Alert Moderator
Like (0)
Correct AnswerRe: COGS in COPA and FI
Ajay Maheshwari SAP Trainer May 2, 2013 2:06 PM (in response to Saad Baig)
Hi Saad
1. VPRS condition usually stores the value at which PGI has happened. If this is not the case
in your case, then talk to your SD guy.. The VPRS shown in the sales order is for name sake..
The value that flows to COPA is the value at which PGI happens (Ideal Situation)
In billing, if you want to know how the system has fetched the VPRS value, Go to the
condition tab of the billing document, select the VPRS condition type and click on blue lens
at the bottom left.
If the condition control field is set to
'H', the cost was taken from the goods issue (Ideal situation)
'A', it was redetermined from the valuation segment of the material master
in case of 'D' or 'E' it was copied from the preceding document (Sales order)
2. The diff between Period indicator 4 and Current cost estimate will come if the std cost has
changed after PGI and before billing... Say, Std cost at PGI was 100 and at billing say it is
108... If the period indicator is 4, it will bring the cost comp split of 100.. If the indicator is
"Current cost est", it will bring the cost comp split of 108 into COPA
1-How the standard cost estimate value will flow to COPA
Ans- KE4R, Maintaining the value field for each Cost Components from the Cost Components Structure.
And the Point of Valuation is 01.
2-How the CKMLCP run value will flow COPA
Ans-Define Access to Actual Costing/Material Ledger in IMG
3-After executing CKMLCP run do we need to run KE27?
Ans-yes
4-when the material used in sales order at the time of billing copa document get
genared
Ans- Yes
5-so how standard cost or actual cost will flow to COPA?
Ans- refer above 1 and 2&3
6-Please explin me importance of point of valuation 1 and 2?
Ans01
Real time valuation of actual data- All application functions that transfer data to CO-PA are assigned
to one of these points of valuation. For external data transfers, points of valuation 01 and 03 are used for
actual and plan data, respectively.
02
Periodic revaluation of actual data-
If a valuation strategy calls for valuation using material costing, the system uses the point of valuation to
control which cost estimate is read and how the cost components are assigned to value fields in CO-PA.
I hope it helps
There is tons of information available in SCN about this.
Refer below links for example

http://scn.sap.com/thread/1836472
or read some of Ajay's discussion and replies on SCN

http://scn.sap.com/people/ajay.maheshwari
PGI happens with the std cost existing at the time of PGI. Fi doc is posted with this value
In COPA, you can fetch the same value at the time of billing depending on your costing key settings
- Period indicator 4 = Cost estimate on PGI date
- Period indicator 1 = Current Cost estimate i.e cost est on the system dt on which invoice is posted
In Ke27 you access the actual cost est calculayted from CKMLCP
Valuation in COPA Planning

Dhawal Mehta
Jun 28, 2013 3:06 PM
Hello All,
Client has a requirement where he wants to see cost estimates in the COPA Planning report.
Cost estimates are executed during year end and in this process, client will execute a
costing run before year and end and mark prices. Cost estimates will not be released, hence
we will have a price updated as "Future Price" in the costing view of material master.
I have worked in COPA planning earlier but am not familiar with valuation aspect of it.
Hence, I would like to know how the mechanism of valuation works in COPA planning and
what are the config requirement for it.
Will appreciate you response on above query.
Thanks and Regards,

Dhawal Mehta
Correct Answer by Ajay Maheshwari SAP Trainer on Jun 29, 2013 6:30 PM
Hi
You need the steps as below
1. Set up Val Strategy in KE4U for Point of Valuation 03 and 04 / Rec Type F
2. Create a Costing Key in KE40 where in period indicator is "Future Price"
3. Assign the Costing Key in KE4J or KEPC to the reqd material types
4. Assign the VF to Cost Components in KE4R for Point of Val = 03 and 04
Finally, execute the valuation step in KEPM
Br, Ajay M
Helpful Answer by Venkata Sudhakar Reddy Kovuri
479 Views
Products: sap_erp_financials Topics: enterprise_resource_planning
Average User Rating

(0 ratings)
Helpful AnswerValuation in COPA Planning
Venkata Sudhakar Reddy Kovuri Jun 28, 2013 9:11 PM (in response to Dhawal Mehta)
Hi,
Check Profitability Analysis->Valuation-> setup valuation using Material Cost estimate>Define Access to Standard Cost Estimates
In this check settings for costing key, in particular "Period Indicator" where you can select
future cost estimate based on mater master..
Alert Moderator
Correct AnswerRe: Valuation in COPA Planning
Ajay Maheshwari SAP Trainer Jun 29, 2013 6:30 PM (in response to Dhawal Mehta)
Hi
You need the steps as below
1. Set up Val Strategy in KE4U for Point of Valuation 03 and 04 / Rec Type F
2. Create a Costing Key in KE40 where in period indicator is "Future Price"
Like (0)
3. Assign the Costing Key in KE4J or KEPC to the reqd material types
4. Assign the VF to Cost Components in KE4R for Point of Val = 03 and 04
Finally, execute the valuation step in KEPM
Copa valuation strategy - doubt

RAMAN RANA
Apr 21, 2011 3:20 PM
Dear experts,
Pls guide me on the below.

Need to use copa valuation strategy in order to transfer cost to copa through cost
componenet wise.
So i have assigned cost component to value field and i m using standard costing key with
standard setting.
but need to define valuation strategy material,material type or any other characterstics.
which valuation strategy i will use?.
Which record type and point of valuation i will use.i am not doing actual costing and
material ledger.
What are sequence of step in order to t/f cost to copa through valuation strategy not through
vprs.
regards
RR
Correct Answer by Ajay Maheshwari SAP Trainer on Apr 22, 2011 12:35 PM
Hi
Assign it to Rec Type F, PV=01, Mat Type = All those mat types which have Price Control S
(usually FG/SFG)
br, Ajay M
2926 Views
Average User Rating

(0 ratings)
Re: Copa valuation strategy - doubt
Ajay Maheshwari SAP Trainer Apr 21, 2011 5:17 PM (in response to RAMAN RANA)
Hi
a. Select Valuation Strategy 001 in KE4U
In DETAILS tab: Assign it to Appl = KE, Check Mat Cstng, and Qty Field = ABSMG
In Assignment tab: Assigning 001 to Point of valuation 01 and Record Type = F
b. Creating a costing key in KE40
Check : Transfer Std cost estimate

Period indicator =Current Cost estimate acc to entry in mat master
c. assigning costing key to material types in KE4J or KEPC and
d. assigning Cost Comp Structure to Value field in KE4R
br, Ajay M
Alert Moderator
RAMAN RANA Apr 22, 2011 7:37 AM (in response to Ajay Maheshwari SAP Trainer)
Hi ajay,
Thanks for your valuable advice,
Suggested by you
a. Select Valuation Strategy 001 in KE4U
In Assignment tab: Assigning 001 to Point of valuation 01 and Record Type = F
but while doing
Like (0)
system is showing error "Maintain costing sheet for the application"
Guide me on th same
Regards
RR
Alert Moderator
Like (0)
Ajay Maheshwari SAP Trainer Apr 22, 2011 9:05 AM (in response to RAMAN RANA)
Hi Raman
My mistake... dont assign any thing in "Application"... Leave it Blank
br, Ajay M
Alert Moderator
RAMAN RANA Apr 22, 2011 10:06 AM (in response to Ajay Maheshwari SAP Trainer)
Like (0)
Hi Ajay,
Shall i assign costing key to record type 'F' and point of valuation '01 and material
type all or FG/SFG only or need to assign any other record type and point of valuation
also.
regards
RR
Alert Moderator
Like (0)
Correct AnswerRe: Copa valuation strategy - doubt
Ajay Maheshwari SAP Trainer Apr 22, 2011 12:35 PM (in response to RAMAN RANA)
Hi
Assign it to Rec Type F, PV=01, Mat Type = All those mat types which have Price Control S
(usually FG/SFG)
br, Ajay M
Characterstic Derivation in COPA

satish kumar
Dec 29, 2010 11:43 AM
Dear Experts,
could you please give me example and purpose of derivation rule (meaning) in COPA ie., why do we
define derivation..
your replies are highly appreciable..
With Best Regards,

satish
Correct Answer by Sarada Sil on Dec 29, 2010 12:56 PM

Examples :
1. Characteristics Material Group can be taken thru table look up of MARA table from the material
number . Similarly Customer Group can be derived via table look up from KNVV table..
2. Suppose you have Strategic Business Unit as characteristics , and combination of Product Group
and Sales Region derives the same .. In this case you can have a derivation rule which says that if
Product Group = x and Sales Region = Y , then SBU = Z in derivation rule values..
Hope it clarifies..
Regards
Sarada
1473 Views
Average User Rating

(0 ratings)
Re: Characterstic Derivation in COPA
Sarada Sil Dec 29, 2010 12:34 PM (in response to satish kumar)
Hi ,
In COPA , you pull reports based on various dimensions , like product , plant , company code , region ,
division , product group etc... . We define these dimensions as Characteristics in COPA ..
Now , if we have to pull data in these dimensions.. we have to make sure that all these characteristics
are populated in a COPA Document ..All the characteristics are not always are available during creation
of billing document ..hence we need to have a COPA Characteristics derivation strategy ..
Strategy may be :
Derivation of Fixed Characteristics

Derivation from derivation rules
Derivation from table lookups
Derivation from customer hierarchy
Derivation of Product Hierarchy
Derivation of Region
Derivation with move and clear functions
Derivation within enhancement steps
Derivation of quantity units
Regards
Sarada
Alert Moderator
Like (0)
satish kumar Dec 29, 2010 12:53 PM (in response to Sarada Sil)
Dear Sankar,
Thanks a lot for your prompt response, could you elebroate little bit on this.
With Best Regards,

satish.
Alert Moderator
Correct AnswerRe: Characterstic Derivation in COPA
Like (0)
Sarada Sil Dec 29, 2010 12:56 PM (in response to satish kumar)
Examples :
1. Characteristics Material Group can be taken thru table look up of MARA table from the material
number . Similarly Customer Group can be derived via table look up from KNVV table..
2. Suppose you have Strategic Business Unit as characteristics , and combination of Product Group
and Sales Region derives the same .. In this case you can have a derivation rule which says that if
Product Group = x and Sales Region = Y , then SBU = Z in derivation rule values..
Hope it clarifies..
Regards
Sarada
Alert Moderator
satish kumar Jan 10, 2011 5:48 AM (in response to Sarada Sil)
Hi Sankar,
Please accept my appreciation, i have given you full points.
With Best Regards,

satish
Like (0)
Maintain Allocation Structures

During settlement, costs incurred under the primary and secondary cost elements by a sender are
allocated to one or more receivers. When you settle by cost element, you settle using the appropriate
original cost element.
An allocation structure comprises one or several settlement assignments. An assignment shows which
costs (origin: cost element groups from debit cost elements) are to be settled to which receiver type (for
example, cost center, order, and so on).
You have two alternatives in settlement assignment:
You assign the debit cost element groups to a settlement cost element.
You settle by cost element - that is, the debit cost element is the settlement cost element.
Maintain Source Structure

In this IMG activity, you define the source structures used when settling and costing joint products.
A source structure contains several source assignments, each of which contains the individual cost
elements or cost element intervals to be settled using the same distribution rules.
In the settlement rule for the sender you can define one distribution rule, in which you specify the
distribution and receivers for the costs for each source assignment.
Example
The object in question has incurred both direct and overhead costs. The direct costs are to be divided
50% each between a fixed asset and a cost center, while the overhead is to be settled in full to an
administration cost center in CO.
To do this, you would create a source structure with two source assignments:
1. Direct cost elements
2. Overhead cost elements
Maintain Settlement Profile

In the settlement profile , you define a range of control parameters for settlement. You must define
the settlement profile before you can enter a settlement rule for a sender.
If you want to settle the costs each time to just one cost center or just one G/L account, you need a
settlement profile. As you cannot maintain the settlement parameters during settlement to a receiver, you
must save the settlement profile either in the order type or in the model order or reference order.
I am pasting a summary below which would help you in understanding the sign logic between FI/COPA for diff cost ele catg
12: Credit in FI = Minus in COPA (i.e. Cr memo/returns)
Debit in FI = +ve in COPA
11: Credit in FI = +ve in COPA
Debit in FI = Minus in COPA (i.e. Cr memo/returns)
01: Credit in FI = Minus in COPA
Debit in FI = +ve in COPA
i have activated both type of COPA ie ( accounting & costing based copa ) as
i am getting performance issues during the executing of COPA Report.
so i am want to activate only costing based COPA. i wanted to know if any
sap notes on it. do i need to consider any thing before i do it.
Please tell me any implication will i get? in the live production system if i
change from 4 to 2.
Ans: Kindly remove the activation in KEKE and save it without assigning the
costing based COPA. Then in KEA0, select the operating concern and go to
the menupath extras-settings where you will be able to remove the flag on
account based COPA. Then you need to save the settings and generate the
operating concern. After completing this, you may activate the costing based
copa in KEKE.
In the transaction OKKP (in the view activate components/control
indicators) you have to change the customizing to Component active for
costing based profitability analysis (2)
The data for the account-based CO-PA is written into the already existing
CO-tables: COEP, COEJ, COSP und COSS. So there will be no impact on
the tables.
Reposting existing documents ( like invoices) could be a problem since at the
time of posting there was a account based COPA document. So at the time
of reversal system will expect the same else will throw error KI144. This
error message can be changed into an information or a warning message
.Read note 98262 regarding this. This problem could also come for
documents 'in process' i.e if sales order and GI has been done with account
based COPA and at the time of billing it is inactive.
So try and ensure specially that all your sales orders are fully billed before
you deactivate account based COPA.
Right now we are using both cost based and account based copa. In future
we want to deactivate Account based copa as we are not using much
account based copa. Now a lots of questions are coming in our mind like :-
1. Is it suggestable to deactivate account base copa in between the fiscal

year?
2. What would be the impact on FICO and other modules?
3. How to identify which company code is using account based copa?
4. What would be the impact on KE30 reports and other reports?
5. Can we delete account based copa data from tables for the past months,
if yes is there any impact on other database tables?
6. Any SAP best practive or sap notes to deactivate account based copa?
Ans: The main challenge I see is for open Sales orders.. Because the PSG is
determined at SO level, system may try to make a posting in the ABCOPA..
In our project, with no other option we are planning to implement both

costing based and account based COPA. I have been told that it is not
recommended by SAP because for every entry there will two line items, one
in cost based and another in account based (Correct me if I am wrong). But
I could not understand why it is creating 2 line items in COPA. - Please help
to understand this concept with an Example.
Thanks
PMHi
Costing based and account based COPA serve the same purpose... analyze
profitability of the product ....
Costing based COPA should always be preferred over account based COPA,
as it provides greater flexibility, some extra features, some extra planning
mechanism and faster reports
Following are the point of differences between Costing based vs. Account
based copa (ABC)
1. Account based copa uses transaction tables (COEP, BSEG) and hence
affects performance of CO transactions.CBC takes values from CE1XXXX to
CE4XXXX tables. XXXX means Operating Concern name.
2. Estimated / Statistical values not possible in ABC, say, calculating frieght
upon invoice on a thumb rule basis to have better view of profitability per
customer.. no valuation strategy in Accounts based COPA..
3. Reports based on line items not possible in ABC.. possible in CBC.
4 Actual Top Down distribution only available in CBC not in ABC .
5. Revaluation of actual data to plan data is not available in ABC
6. No key figure schemes are available in ABC
7. In ABC, settlement cost elements are used to settle values to prof
segments unlike value fields in CBC
8. Production variance / COGS accounts shud be defined as cost element in
ABC.
System creates a document for each type of COPA as it stores values in
different tables and what you can do with this data also differs like you can
do TOP down in Costing Based Copa..
Hence, you will have two COPA documents always......................
Top-down distribution distributes the costs that are posted at higher-level

characteristics (such as material groups, customer groups, or divisions)
during their initial postings to lower-level characteristics (such as customer
or material). An example is overheads assessed to material groups that also
need reporting at the product level. The costs can be distributed based on
any referenced historical data plan or actual data. This reference must be
available in the profitability analysis (CO-PA) database. The costs are then
distributed based on the reference data proportionately to the respective
individual characteristics pertaining to high-level characteristics. SAP COPA
Top-Down Distribution is a process where in values posted at generic
segments such as Company Code, Product Groups and Customer Groups is
distributed to specific segments such as Customer, Profit Center, Material.
This is month end process.(KE28)
Key Concept
Top-down distribution is a functionality that allows you to allocate values

from higher-level profitability analysis (CO-PA) characteristics (for example,
Division) to lower-level characteristics (for example, Products) based on a
specified reference base (for example, Total Quantity).
Top-down distribution is typically thought to be a functionality that is
available only with costing-based CO-PA. This is actually a misconception,
as top-down distribution has been available for both types of CO-PA since
release 4.7. In account-based CO-PA, top-down distribution works a little
differently from costing-based CO-PA because it does not use value fields as
a reference base. Instead, it uses cost elements. For more information about
account-based CO-PA, refer to my article Things to Consider Before
Activating Account-Based CO-PA.
I always like to describe top-down distribution as the profitability analysis

(CO-PA) answer to an assessment cycle. For those (and there shouldnt be
many) people who do not know what an assessment cycle is, it is the
method of allocating costs from one cost center (or group) to another, based
on some method of apportionment (for example, fixed percentages, fixed
portions, variable portions, or fixed amounts). There are assessment cycles
in CO-PA that are defined using transaction KEU1 and executed using
transaction KEU5. However, these can only allocate costs from cost centers
to CO-PA profitability segments, and not from one profitability segment to
another.
With top-down distribution, you can allocate costs from one profitability
segment (higher-level characteristics) to another (lower-level characteristics).
The purpose of this is to ensure that a CO-PA report can be viewed on a
granular level (for example, by product) even though the original posting
was not made at that level of detail.
This quick guide helps show you how to set up top-down distribution in
account-based CO-PA so that it works exactly the same way as in costingbased CO-PA.
Things to Consider Before Activating

Account-Based CO-PA
As a reporting tool, profitability analysis (CO-PA) is very effective for evaluating the profitability
of your market segments according to various dimensions such as geography, customer, or
product type.
There are two types of CO-PA: costing based and account based. However, most businesses
that use CO-PA implement the costing-based version. In fact when CO-PA is mentioned, that
person is usually referring to costing-based CO-PA. This may be because costing-based CO-PA
was the first to be introduced by SAP, mainly for sales and contribution margin reporting,
whereas account-based CO-PA was subsequently introduced to deal with reconciliation with the
general ledger.
Note
In this tip, when I refer to the general ledger, I mean the classic general ledger and the SAP
General Ledger. However, Simple Finance only uses the SAP General Ledger. In Simple
Finance, you move all data into the same document as you migrate, so you don't need to
reconcile data with the classic general ledger anymore.
I am in project MTO environment by Sales order (sales order as cost object).

I know that billing value (revenue and cogs) is transfer to COPA using VA88 in
MTO environment by Sales order (sales order as cost object).
And it already works in here.
But the billing quantity is not transfer to COPA during VA88.
How we can transfer billing quantity to COPA in MTO environment by Sales
order (sales order as cost object)?
Solution:
In your PA transfer structure, which you are using during settlement of sale order Make the following entries:
1. Add an assignment, say, 10, as Sales Qty
2. Check the box "Qty Billed/Delivered"
3. Do not assign any cost element in SOURCE
4. Assign your Quantity Field in the tab "Value Field"
Now execute VA88, Qty will also be transferred to COPA
Those cost elements which are not part of Prod cost - Need to be allocated to COPA
via Assessment cycle
You can create a PA Transfer Structure in KEI1, and use the same in Assessment
Cycle KEU1... (Execute from KEU5)
BAsed on your PA Transfer Str, the values will be allocated from Cost Center / Cost
Element to Value Fields / CHars in COPA
in KEU1 transaction we have two options. one is Allocation strucuture and other one
is PA transfer structure. What is the relevance of these scenarios and when do we use
these functinalities.
Can you please give business examples for these two options.
When you allocate - The cost center is credited and COPA (prof Segment) is
Debited...
The credit entry is posted to cost center using a secondary cost element (Catg 42)...
This is determined from Allocation Str
The Debit entry to COPA is posted/allocated to COPA in a Value Field.... PA Trf Str is
the place where you map Cost Ele to Value field.. Upon allocation, the value will flow
to the specified value field
Note that in KEU1, you can directly specify "Assessment cost ele" and by pass the
Alloc Str
Note that in KEU1, you can directly specify a Value Field and by pass the PA Trf Str
SUMMARIZATION LEVEL (KEDV)
Summarization level
Summarization levels store a copy of an original dataset in summarized form. In the
original data, the individual profitability segments are defined by a number of
characteristics. Summarization means that selected characteristics are left out. Any
segments that are identical after these characteristics are left out are grouped together
into one segment in the summarization level.
Summarization levels let you improve system performance.

How to create summarization level for a datasource?
You can do this in Transaction - KCDU/KCDV or SPRO
If Statistical Condition type is mapped with value field and its not flowing to COPA ..
you must have some enchancement in your COPA Valuation Strategy ( KE4U) which
is stopping that ..
Simulate the billing document in KE4ST and check the valuation tab to find wether
system is stopping it .. or contact your ABAP Team to check wether valuation
strategy is there in KE4U

Profitability Analysis

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Profitability Analysis

Uploaded by

Copyright:

Available Formats

Profitability Analysis

Explain the organizational assignment in the PA module?

hierarchy, sales person etc

first two characteristics of product hierarchy.

Contribution margin can be planned in this module since the

What configuration settings are available to set up valuation using

Helpful AnswerRe: COPA datasource tips

sujatha sanjeev Dec 23, 2008 12:34 PM (in response to Deepak S)

Re: COPA datasource tips

hemalatha vetrivel Dec 23, 2008 12:54 PM (in response to Deepak S)

Lets the give the answers to questions you have asked.

CO-PA Data Source

logical line item structure

actual line item table

plan line item table

logical segment level

internal help structure for

internal help structure for assessments

for Account based PA its extracted from

Creating CO-PA Data Source:

The plan/actual indicator (PLIKZ) is copied to SAP BW as value type (WRTTP).

In the ECC System:

Define Profitability Segment Characteristics (Segment-Lvl Ch

- sales order (KAUFN)

- sales order item (KDPOS)

- WBS element (PSPNR)

- cost object (KSTRG)

Best Practice - Operating Concern

Teck Liang Wee

Correct Answer by Jeffrey Holdeman on Apr 15, 2013 9:30 PM

Some other points to discuss in your analysis include the following:

Good luck and best regards,

Helpful Answer by Piet Strydom

Average User Rating

Helpful AnswerRe: Best Practice - Operating Concern

How to flow SD customized partner in

and same is not available in PAPARTNER structure in COPA.

request you to guide me on the same.Need to flow from SD to COPA.

This is not my confusion its my client requirment.

Using of KE4IM Maintain assignment of MM condition

KE4IM: MM condition types from MM pricing assigned to CO-PA value fields

OKB9: Enter price difference accounts + activate PA indicator

The questions on COPA will be like

5. How do you create report in COPA ?

7. What is profitability Segment Charecters ? how do you define them ??

8. What are the various table used in COPA ?

9. What is valuation ? how do you use ? give an example or scenario ?

1. What is realignment and how does it works.

2. What is key figure Schema?

4. What is characteristic values?

5. What is summarization levels.

One option is to use PAPARTNER.. But its better to avoid that

I prefer to use a derivation rule always

2. In the other one, dont make it a constant....Leave it as it is

Two rules are required because,

So, your derivation rule will look like this

VBPA- Sales Order Mapped to COPA-Sales Order

VBPA-KUNNR Mapped to COPA-WWXXX Char

This field is nothing but the charactiristic.

Valuation Using Conditions

You wish to assign additions/deductions (percentage or quantity-dependent)

The additions and deductions should be calculated in relation to certain

The basis on which the additions or deductions are to be calculated

The subtotals to be calculated