Reposting And Analysing Controlling

Profitability Analysis Documents - ERP

Financials
Purpose
This page explains the tools used for reposting and analysing historical COPA (Controlling
Profitability Analysis) documents.
Overview
In this page we will explain the usage of below mentioned transactions -
KE4F - Prepare Subsequent Posting Of Incoming Sales Order to CO-PA
KE4T - Post Sales Order Subsequently to Profitability Analysis
KE4TS - Simulation Of Document Transfer From Incoming Sales Order
KE4S - Transfer SD Billing Documents to CO-PA
KE4ST - Simulate Billing Document Transfer
KE4SFI - Document Transfer From Financial Document to Profitability Analysis
KE4SMM - Transfer Of Documents from Materials Managment to Profitability Analysis
KE4F
This transaction is used when COPA is activated subsequently in a already productive environment. In
such cases the already posted SD order will not have profitability segments created already. Before
you can post sales orders subsequently, the system needs to determine profitability segments to which
the order items should be assigned, if this assignment does not already exist. In this step, you make
that assignment so that you can then post the sales orders.
This transaction allows you to provide a selection crieteria for which PA segment should be created
and also provides you with the option to execute the transaction in Test mode.
KE4T
This transaction post sales orders that have already available in the system to Profitability Analysis.
If this is a fresh activation of COPA and profitability segment has not been determined for thesales
order then you must execute transaction KE4F first. Once the sales orders are prepared without errors
transaction KE4T can be used to post the sales oders to COPA. On the selection screen, you can
specify the sales orders you would like to transfer. The system only selects those sales orders that have
been assigned to a profitability segment.
The default system does not protect any sales documents being transferred from any changes being
made during the transfer. You can deactivate this function on the selection screen to prevent changes
from being made to the selected documents. However, the result of this may be that you do not obtain
the most current data in Profitability Analysis. This also has the effect that no sales orders can be
processed in SD while this program is running.
This function also checks whether any of the selected sales orders have already been posted to CO-PA.
If you deactivate this option, and if the system finds orders that have already been transferred, these
orders are canceled and then reposted again to CO-PA.
KE4S / KE4ST
In this transaction you can post billing documents to COPA for which Financial documents have
already been created. This transaction works only for billing documents which have been released to
accounting with transaction VF44.
The program checks whether the billing data has already been posted to CO-PA in order to prevent
documents from being posted twice (first online and then with this function to CO-PA).
After posting the data to CO-PA, the program displays a transfer log and an error log. If any billing
documents contained errors, you need to correct them and run the program again.
In Transaction KE4S you have the following important options -
Redetermine profitability segment
If you select this function, the system will delete and redetermine any existing profitability segments
in the data record to be posted. It does this prior to posting when the transaction is executed.
'Redetermine PA segment' flag basically clears the existing PA segment. Derivation gets called for the
creation of the line item and all characteristics are derived afresh. If the characteristic combination
remains the same as earlier then the same CE4XXXX PAOBJNR as earlier will be used in the
reposted COPA document. However if derivation changes any characteristic then a new PAOBJNR
will be used in the resposted document. 'Redetermine PA segment' flag is normally used if there are
certain characteristics which are only derived during the creation of the PA segment and not during
creation of the line item (like TKEZU characteristics). In case 'Redetermine PA segment' is not
flagged then the existing PA segment is first taken over. Then derivation gets called. If any
characteristic which was not existing earlier gets derived or any existing characteristic gets overwritten
with new value then automatically a new PAOBJNR gets created in the reposted COPA document. If
derivation does not change any existing characteristic taken over from the PA segment then the same
PAOBJNR will be used in the reposted COPA document.
From a technical perspective 'Redetermine PA segment' flag means that FM
COPA_PROFITABILITY_SEGMENT will be called before the document is reprocessed in order to
determine a new profitability segment. The PAOBJNR is newly created before FM
AC_DOCUMENT_CREATE is called. If flag 'Redetermine PA segment‘ is marked a new
CE4xxxx_ACCT segment number is created first by FM COPA_PROFITABILITY_SEGMENT on
the basis of the data of the billing document (instead of using the one from VBRP-PAOBJNR). This
new segment number is afterwards passed to CO-PA for creation of the CE1xxxx line item (but NOT
stored in VBRP as new PAOBJNR) before derivation is called again. So derivation is called twice in
this case: first time from FM COPA_PROFITABILITY_SEGMENT for creation of the
CE4xxxx_ACCT segment number, second time for creation of the CE1xxxx line item.
Check for existing records
This options checks for already posted billing documents in COPA and selects only those documents
which have not been posted to COPA. In a live system where data has already been posted to
Profitability Analysis, you should not select this option for safety reasons, in order to avoid posting the
same billing document twice.
Reversal of Line Items
If you select the option Reversal of line items, the system checks whether each selected billing
document has already been transferred to Profitability Analysis.
All CO-PA line items belonging to billing documents that have already been transferred are reversed.
All selected billing documents are then transferred to Profitability Analysis again.
You should select this option if you want to correct existing data records by reversing existing data
and then reposting it. Note that, if you select this option, the system creates at least two new data
records (reversal and reposting) for each data record you want to post! If you perform this function
more than once, the system does not reverse reversal documents already created. This means that only
the last data record to have been booked is reversed.
Posting Without Check
In this onption No validity check occurs to test whether individual billing documents have already
been posted to COPA. Billing documents that have already been posted are not canceled in COPA.
Analyzing the Log
If you do not want to post the billing documents and just want to simulate them to check the data
transfer from SD billing to COPA then you can use transaction KE4ST.
Once you have similated the billing document you can select the log function in the subsequent screen
to analyze the same. You can find three different tabs on the screen -
Characteristics -
This tab is speacially useful when you are trying to check the derivation of the characteristics in the
billing document. Once you click on the tab you can find the field name, the characteristic value it
contains and the status of the characteristic in the opearting concern.
If you click on the derivation analysis you can find option to check "Value Before/After " and the
Derivation "Steps" that has been called during the transfer of billing document to COPA. The Screen
shot below will explain the scenario -
Simillarly the analysis can be done for Value flow from Condition types and Valuation from billing
document using the tabs Value Flow and Valuation Respectively.
KE4SFI / KE4SMM
KE4SFI and KE4SMM transactions can be used to repost record type B from MM and FI documents
to COPA subsequently. However unlike KE4S transaction there is no option to view log in both these
transactions. In this case also Preliminary check for existing data records.
Related Documents
Insert SAP Help links or other WIKI content link.
Please hyperlink the title of the related document
Related SAP Notes/KBAs
SAP Note 20254: INFO: Values from SD not transferred to CO-PA
SAP Note 2205938: Supportability tools: How to analyze derivation and valuation in CO-PA during
billing using transaction KE4ST [VIDEO]
__________________________________________________________________________________
________________________
 COPA correction
Reconciliation between SD & COPA and thereafter COPA & FI is a time consuming and hectic job in
every organization . Before starting this , we need to ensure the correctness of COPA . I tried to
explain how COPA data and report can be corrected without interfering into SD module .

COPA correction of selected billing docs (record type “F”)

When costing based COPA is active, billing docs from SD flows directly to COPA. For this every
condition type in SD is mapped to a value field in COPA. But sometimes one or more condition types
are found missing in COPA, which result in SD-FI-COPA mismatch. Again on some occassions the
condition type is found to have flown to some other value field for which it’s not customized. The
main reasons behind this missing value fields are:

the customization , mapping SD condition type to value field, is changed during a period

change in the condition type in SD itself

Multiple condition type mapping to single value field.

SAP recommends the reversing of billing doc and releasing of the same to FI/COPA again; in certain
circumstances it’s not possible in SD.

In such cases, in COPA the reposting option is available without affecting SD or FI. The related
program is RKERV002 and t code is KE4S. The inherent problem is it creates 2 more docs, viz. the
reversed doc and the reposted correct doc. So it ends up with 3 docs in the COPA tables. After that we
can delete the original and reversed doc through t code KE4S00. As physical deletion from database is
not possible, cancellation of these 2 docs again create two more cancelled docs. At the end we are left
with five COPA docs against one billing document.

To overcome the multiple doc scenarios we need to delete the faulty COPA doc from database and
post the same billing doc to COPA without any check. This involves 3 activities viz. deletion, posting,
reconstructing.

The procedure is as follows:

1. Open the CE1xxxx table and check the billing docs finally before deletion (xxxx=operating
concern):
2. Run SE38 and input for program RKEDELE1

Remove the “test run” and execute

3. For confirmation check the billing docs in CE1xxxx table again: on execution we should get a msg
like

4. Now we need to post the billing docs to COPA again without any check. For this we will run KE4S
5. Now the deletion and posting is completed, but this only updates the CE1xxxx table. We need to
update the main profitability segment table which is CE3xxxx; otherwise the COPA report will not
reflect the changes. This is known as reconstruction of CE3xxxx table.

Before doing this we need to create a blank file viz. “ABC.txt” on the desktop. SAP stores the
intermediate data in this file during the phase of reconstruction.

Run program RKEREO31:

We see the result in test mode:

As test result is successful we will run the program in real mode :

Now both CE1xxxx and CE3xxxx tables are updated. All changes we wanted to carry out will be
reflected in COPA report.
erpfixers.com

Top 15 COPA User Transactions User Manual

6-7 minutes

TOP 1: Create Actual Line Items

Transaction Code: KE21N

Rationale: The transaction is used to post actual line items in COPA only. This transaction is used to
make any adjustment posting in COPA.

Specify Record Type and press ENTER

Enter the characteristics and value fields and SAVE.

Top 2: Display Actual Line Items

Transaction code: KE24

Rationale: The transaction is used to display actual line items in COPA only with all characteristics
and value fields. This transaction is quite useful to user to display the actual line items.

Specify Co. Code and other additional selection based on the criteria and then execute.

Top 3: Repost Accounting Document

Transaction code: KE26

Rationale: The transaction is used to repost the accounting document into COPA only. This
transaction is quite useful if for some reason the FI document is not transferred into COPA, the user
can access this transaction to repost into COPA.

Enter the FI document number, Co. Code and Fiscal Year and execute.

Top 4: Transfer Cost Centre Costs/Process Costs

Transaction code: KEU5

Rationale: This transaction is used mainly to transfer any under/over absorption on cost centers to be
transferred into value fields. The pre-requisite to this transaction is to define an assessment cycle.

Specify period, fiscal year and cycle. The user can also select the detail lists to display more
information.

Top 5: Periodic Valuation

Transaction code: KE27

Rationale: Periodic valuation is useful, for example, if you posted line items to CO-PA at the
beginning of the periodic using the standard cost of goods manufactured, and want to valuate them
again later using the most up-to-date costs or using the actual costs of goods manufactured determined
in Material Ledger.

Specify period, record type and then execute.

Top 6: Top Down Distribution

Transaction code: KE28

Rationale: Top-down distribution of actual data is a periodic function that lets you distribute
aggregated data to more detailed levels in CO-PA on the basis of reference information

Specify periods, record type and execute.

Top 7: Incoming Orders with Errors

Transaction code: KE2D

Rationale: This transaction is used to display the sales orders which are not transferred into COPA

Specify the organization elements and execute.

Top 8: COPA reports

Transaction code: KE30

Rationale: This transaction used to display the reports in COPA. The pre-requisite to this transaction,
the reports should be developed.

The selection of report might depend on the requirement.

Top 9: Display Plan Line Items

Transaction code: KE25

Rationale: This transaction is used to display plan line items

Specify the organization elements and execute.

Top 10: Check value flow from billing document to FI->COPA

Transaction code: KEAT

Rationale: This transaction is quite useful to compare the value flow from billing document into FI
and COPA

Specify organization elements and execute.

Top 11: Check value flow from FI to COPA

Transaction code: KEAI

Rationale: This transaction is quite useful to compare the value flow from FI to COPA

Specify organization elements and execute.

Top 12: Simulate Billing document transfer

Transaction code: KE4ST

Rationale: This transaction is quite useful to simulate the billing document from SD to COPA without
posting into COPA

Specify organization elements and execute.

Top 13: Simulate Sales Order transfer

Transaction code: KE4TS

Rationale: This transaction is quite useful to simulate the sales order to COPA without posting into
COPA

Specify organization elements and execute.

Top 14: Set Operating Concern

Transaction code: KEBC

Rationale: This transaction is useful when we are using multiple operating concern. The transaction
code will default the current operating concern.

Specify the operating concern and execute.

Top 15: OverviewDerivation Rules

Transaction code: KEDD

Rationale: This transaction is useful to display the derivation rules. This is mostly done by the support
or implementation team but quite useful for user to display the derivation rules.