COPA - Switching to another Operating Concern or use existing Op.Concern

[chengshiong_kwan]

Dear all experts,

I have a question regarding whether to use back the existing Operating Concern or a new OC.

The scenario is like this:

My user has activated COPA in production system without any setting.

Only Revenue and COGS is flowed to COPA.

No derivation rules being setup at all.

This is because they were trying to implement COPA by their own but they do not know how to set it up.

Since they think there is no impact on their daily operation, they decided to activate it in production.

Now they want to have a proper implementation.

They do not need to have the old data that were already posted into the COPA table since it is all dummy data.

From the OSS note 199959-Change assignment of operating concern, it seems not easy.

Any advice if I am going to use a new operating concern instead of the existing one so that I will have a cleaner data in COPA tables?

Thanks,

Sebastian

[ajaycwa1981 · Accepted solution]

Hi

I would suggest use the existing Op concern

Existing data can be deleted using KE4S00 or achived

Br, Ajay M

[chengshiong_kwan · Accepted solution]

Hi Ajay,

Thanks for your suggestion.

So if I execute KE4S00 with "Logical Delete" being checked, I will get a clean COPA table CE1xxx - CE4xxx right?

I have tried to remove the characteristics that have been assigned to old OC but the system doesn't allow. Seems like once it is assigned and posted with data, there are some dependency or derivation rules created for the those characteristics with reference to SAP table. Any advice to resolve this issue or de-link the dependency quickly?

Thanks.

Regards,

Sebastian

[ajaycwa1981 · Accepted solution]

Hi

Ke4s00 gives you clean ce1

For ce4, you can archive them. Or leave it as it is if they are not many

Search scn to archive ce4 or sap notes. You will find it

Ajay M

[Former Member]

Hi..

You can delete all actual data and plan data in co-pa using t-code KEDB.

[ajaycwa1981]

Hi

KEDB must not be used in a Productive system.

Read the program documentation

RE RKEDELTEST

____________________________________________________

Short Text

Deletion of Test Data in CO-PA

Purpose

In the specified operating concern XXXX, the program deletes the transaction data from tables CE1XXXX (actual line items), CE2XXXX (plan line items) and CE3XXXX (segment level). Data records are not deleted from the table CE4XXXX. Once the deletion has been carried out, a log appears displaying the number of deleted records.

Note
The program is only intended to be used to reset test data. In productive systems, you should use the archiving or reorganization tools.

Br, Ajay M

[ajaycwa1981]

Hi

To delete PSG, reffer note 1038939 - Archiving profitability segments II. . For system ECC 6.0, there is a remark mentioned at the end

So, I will summarize again for your easier understanding

1. To Delete CE1 - Use KE4S00

2. To Delete CE4 - Avoid if the no of entries are not huge.. If you want to do, refer the above note...

Br, Ajay M

[Former Member]

Hi..

I think that dummy data is a kinds of a test data posted to operating concern before it is set up productively.

[chengshiong_kwan]

Hi Big Choi,

Those are actual data posted after it is activated in production.

Just that they don't need it because the info is useless to them.

Thanks.

Regards,

Sebastian

[chengshiong_kwan]

Hi Ajay,

Thanks for the the summary.

Really need it

If I choose to archive, I will have to do it in all clients: development, quality and production right?

Another suggestion I found is delete the operating concern.

In your opinion, which one is easier or less technical?

Thanks.

Regards,

Sebastian

[chengshiong_kwan]

Hi Ajay,

Anyway I can choose not to archive the profit segment right?

Just that it will have unwanted data remained in CE4xxxx.

It won't clash the whole system right?

Thanks.

Regards,

Sebastian

[ajaycwa1981]

Yes, Sebastian, you are right

[ajaycwa1981]

Hi

If I archive, i will archive only from Production

But leave it, in my opinion

Br, Ajay M