Hi All ,

Every organisation has a time-consuming and demanding task associated with reconciling SD & COPA, then COPA & FI. Before beginning, we must confirm that COPA is accurate. I made an effort to describe how COPA data and reports may be modified without affecting the SD module.

Corrections by COPA to a subset of billing documents (record type “F”)

When COPA with a costing basis is active, billing documents from SD flow directly to COPA. For this reason, each condition type in SD is mapped to a COPA value field. The SD-FI-COPA mismatch occurs when one or more condition types are absent from COPA, though. Once more, on occasion, it is discovered that the condition type has moved to a value field for which it is not tailored. The primary causes of these missing value fields are:

  • The customisation, which maps the SD condition type to the value field, is modified over time.
  • A modification to the condition type within SD itself
  • Mapping of various condition types to a single value field.

In some cases, it’s not possible in SD, however SAP advises reversing the billing document and releasing it to FI/COPA once more.

The COPA reposting option is accessible in these circumstances without compromising SD or FI. RKERV002 is the relevant programme, and KE4S is the t code. The fact that it generates 2 more documents—the inverted document and the updated proper document—is the fundamental issue. The COPA tables ultimately contain 3 documents. After that, using the T code KE4S00, we can remove the original and reversed document. Since a physical deletion from the database is not possible, cancelling these two documents results in the creation of two additional cancelled documents. Five COPA documents and one billing document are all that are left at the end.

We must remove the problematic COPA doc from the database and publish the identical billing doc to COPA without checking in order to avoid multiple doc scenarios. This requires three tasks: deleting, posting, and reconstructing.

The steps are as follows:

1. Before deleting the records in the CE1xxxx table, verify the billing documents one last time (xxxx = operational concern):


2. Launch SE38 and enter RKEDELE1 into the software.

Remove “test run” and carry out


3.JPG3. Verify the billing documents in the CE1xxxx database once again for confirmation; upon execution, we should receive a message similar to


4. We now have to re-post the billing documents to COPA without any checks. We will utilise KE4S for this.



5. The CE1xxxx table has been updated, but the deletion and publishing are now complete. The major profitability segment table, CE3xxxx, needs to be updated in order for the COPA report to reflect the modifications. Reconstruction of CE3xxxx table is what this is known as.

We must first create a blank file on the desktop called “ABC.txt” before proceeding. During the rebuilding step, SAP keeps the intermediary data in this file.


Run RKEREO31 to begin:


In test mode, we can see the outcome:


If the test goes well, we’ll execute the software in actual mode:


The tables CE1xxxx and CE3xxxx have both been revised. The COPA report will reflect all the modifications we wished to make.