Professional Documents
Culture Documents
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
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.
1. Open the CE1xxxx table and check the billing docs finally before deletion (xxxx=operating
concern):
2. Run SE38 and input for program RKEDELE1
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.
Now both CE1xxxx and CE3xxxx tables are updated. All changes we wanted to carry out will be
reflected in COPA report.
erpfixers.com
Rationale: The transaction is used to post actual line items in COPA only. This transaction is used to
make any adjustment posting in COPA.
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.
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.
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.
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.
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
Rationale: This transaction is used to display the sales orders which are not transferred into COPA
Rationale: This transaction is quite useful to compare the value flow from billing document into FI
and COPA
Rationale: This transaction is quite useful to compare the value flow from FI to COPA
Rationale: This transaction is quite useful to simulate the billing document from SD to COPA without
posting into COPA
Rationale: This transaction is quite useful to simulate the sales order to COPA without posting into
COPA
Rationale: This transaction is useful when we are using multiple operating concern. The transaction
code will default the current operating concern.
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.