Transport operating concern

Hi experts,
We have a question about transporting a new operating concern.
To transport customizing settings of the new operating concern we used Tcode KE3I.
We defined new characteristics and value fields for the new operating concern.
In the customizing request we can see that for the tables TKEF and TKEFD all entries (old and new) were included.
But all old fields already exists in the target system of the transport request.
Should we keep the old fields (existing characteristics and value fields) in the customizing request or should we delete them and leave only the new ones ????
Thanks.

Hi,
For transporting Operating Concern please use transaction code KE3I. You need to create a manual transport request. Many of the CO-PA requests can be included in transport request from this transaction. While incorporating the characterstics and value fields excercise caution and check the transport request regarding the objects included.
There is also an OSS note on CO-PA transports. You can check the same.
Thanks
Murali.

Similar Messages

Operating Concern - Transport

Hi All,
I'm trying to create a New operating concern, new characteristics and value fields in the gold client. But these customizing changes are not "automatically" collected in a transport request.
Can someone tell me what is the right way to go about with configuring CO-PA Organizational elements and Data structures in the gold client and collect all these settings in a transport.
Many thanks for your help
SB

Hi,
For transporting Operating Concern please use transaction code KE3I. You need to create a manual transport request. Many of the CO-PA requests can be included in transport request from this transaction. While incorporating the characterstics and value fields excercise caution and check the transport request regarding the objects included.
There is also an OSS note on CO-PA transports. You can check the same.
Thanks
Murali.

Add value field to existing/ productive operating concern

Dear All,
I need to create a new value field and add it to an existing operating concern, which is already in use (there is already transaction data in the live system).
In my opinion I have to do the following steps:
1. Create new value field (KEA6).
2. Add value field to operating concern (KEA0).
3. Activate operating concern (KEA0).
4. Transport operating concern (KE3I).
Is that strategy ok?
Is it ok, to transport an operating concern, when the system is already "live" and there is transaction data in the system?
Thanks for your answers,
Regards,
Michael

Hi,
first create new value field in KEA6. then take those new Value field in your operating concern Data Structure in t-code KEA0. Then generate the operating Concern.
Regards,
Sreekanth

Transport KE30 reports between operation concerns

Dear all,
I have a problem with the transport of some profitability reports between 2 operation concerns. The reports are confirmed and approved in the first oc, but there's still a dummy copy of these in the second oc.
So here's my process...
I set at first my oc in KEBC. Then I select in KE30 the reports for transport. I chose report definition, report form, key figure scheme and transport all languages. 2 transport requests appeared (customizing and workbench) and they have objects inside (SE01). After that I went to KECP for copy specific objects.
Here's now my problem that I can insert only one transport request. I tried both in separated steps but it didn't work. Also I created a "transport of copies request" in SE01, included the objects of both requets. Also the import from the first to the second oc didn't work.
Can you please give some inputs?
Thanks!
Kind Regards,
Rafael

hello,
did you check
1. Verified that the tnsnames.ora contains a single line entry for the Reports server.
2. Verified that the port is used only once.
3. Verified that the default domain in the sqlnet.ora matches the Reports server entry (.world).
4. Deinstalled and reinstalled the Reports server service.
5. Verified that the Reports server account has a default printer assigned and is set up as a "Use this account" account.
regards,
the oracle reports team

Maintaining operating concern after adding new value field

Hello,
I added a new value field to our live operating concern,maintained the data structure throguh KEA0(Maintain operating concern).The changes are transported from Development to Quality,Changes were reflected in Q system.After testing in Q system transports were pushed to production system.The new value field is added to the operating concern. When i check the log for KEA0 in production system it displayed one message like:
Field VV088 was added to the reference structure
Message no. KE782.You probably either changed the operating concern or SAP-EIS aspect, and added the field VV099 to the definition.
The added a CO-PA value field:
In this case, the field is added to the definition or the summarization levels. This invalidates all existing levels. Consequently, you need to activate them again and fill them with data.
In production system maintaining operating concenr or KEAO is only in display mode.Is it needed to regenerate the operating concern once again in production, how to do it. Is the message talking about the KEDV summarization levels.?
thanks
rahul

Hi,
No no ....KEDV is nothing to do here....that is creation of summarization in CO-PA.
Since you added new value field you necessarily have to Regenerate the operating concern...
Use Tcode KEA0...go to Environment tab...there the status of Cross client part and client specific part both will be in RED....now just click on the Cross client (candle button)...now the system would regenerate the operating concern...once it is over do the same for the client specific...
Beware when you do regenerate the operating concern no body can enter any transaction in that server since it is cross client table ...hence better do it after business hours.
Hope this helps!
Running KEDU with rebuild is relevant only when you already have created summarization and called up the same in the CO-PA report "options" tab. If you did not created the summarization you are nothing to do with KEDU.
Next: The new value field has to be transported to PRD and hence even in PRD we have to do the regeneration manually.
Regards,
Velumani
Message was edited by: Velumani Arunachalam
Message was edited by: Velumani Arunachalam

Adding new value fields to an existing and productive operating concern

Hi,
I would like to have 5 new value fields active in 4 out of 6 operating concerns that I am working with.
Is it correct that I could do this one of the following ways:
1. Use a value field that exists already in an operating concern and rename it?
In this case is it necessary to regenerate the operating concern?
Do I transport the change ?
2. Create an entirely new value field, and assign it to the operating concern?
Is it necessary to regenerate the operating concerns in question?
Do I transport the change?
3. Select a value field that is currently in the system but is not assigned to any operating concern eg some kind of SAP delivered value field? How do I assign it to the op con? Do I need to re gen the op con?
Which way is the best or is there a 4th option?
Thanks for your help in adviance
Regards
Aisling

Hi,
This note is a catalogue of notes of consulting notes where SAP tell you steps, reports to use and son . If you read them (these notes and related notes) you have the steps, guides, reports that you must use. Better advice. Try a solution with all steps in mind and check it in a quality enviroment. As you know there a lot of things in CO-PA concern (you have your own tables, with your own fields, your reports as KE2Rxxxx, and so on), your secondary indexes, etc.. , the best is try the solution in your Quality Enviroment (a quasi-clone of your production enviroment) and check the results (create SO, invoices, after modifications to check possible problems,...).
Regards,
Eduardo
pd: I forgot. If the size of tables (CE4xxxx, CE1XXXX, ...check them with DB02) are so big, get the opinion of a Basis Consultant. Surely in the before note there notes about this issue.
Edited by: Eduardo Hinojosa on Apr 23, 2010 2:41 PM

Operating Concern -COPA.. urgent!!

Hello friends
I've created a couple of new value fields in an operating concern in development box. Also generated the operating concern. It didn't prompt me for any transport request though.
How do I create a trasnport request to transport the new fields to the QAS?
I've tried creating them manually in QAS, but it wouldn't let me to.
I'm sure there are some special transports need to be done in COPA to get the desired results, but don't know what they are..
Can someone help please to resolve this issue?
Thanks a lot.
Message was edited by: Fico Able

Thanks for ur answer, but I cannot retransport the operating concern. The op.concern was established 3 years back and I wouldn't risk touching it.
My question is how would I create a trasnport when i create new value fields in an operating concern, so that I can have the same new value fields in QAS as well.
Thanks very much

Remove Value Field from Operating Concern

Hi all,
I created a new value field in DEV and assigned it to the corresponding Operating Concern.
Now, after some discussions, it is not necessary this value field.
I want to "un-assign" from the Operating Concern they use.
No data is being posted to this value field and nothing has been transported to QA yet.
Is this possible? Any ideas?
Thanks and Regards,
Flower.

I guess you can delete the value field as it was not transported to QA and PRD.
Here is some information given by SAP.
Deleting characteristics/value fields from an operating concern
You can delete characteristics and value fields retrospectively from an operating concern that you have already activated. However, you should only use this deletion function for operating concerns that have not yet been used productively. You should also note that some database systems require the operating concern tables to be converted (database conversion) after the deletion has taken place if data had already been posted to the operating concern. Depending on the data volumes involved, the database conversion can take a matter of seconds or indeed several hours. Moreover, you cannot post data or run reports during the conversion. Due to integration, other applications are also affected when data is postedwith an assignment to profitability segments (such as settlement and direct assignment from FI/MM). If the operating concern has been transported to another system (such as the productive system), then the database conversion must also occur in that target system.
Depending on the fields that were deleted, the following tables need to be converted (where xxxx = operating concern):
Characteristics: CE1xxxx, CE2xxxx, CE4xxxx, CE4xxxx_ACCT, CE4xxxx_FLAG, and CE4xxxx_KENC
Amount fields: CE1xxxx, CE2xxxx and CE3xxxx
Quantity fields: CE1xxxx, CE2xxxx, CE3xxxx, CE4xxxx, CE4xxxx_ACCT, CE4xxxx_ACCT, CE4xxxx_FLAG, and CE4xxxx_KENC
Before deleting fields from an operating concern with a large data volume (more that 10 000 records in a table), you should refer to the section "The Database Utility" in the ABAP dictionary documentation. This section describes the database conversion process.
For database systems that do not require conversion (such as DB2 for AS/400, Informix, MSSQL), it can still take a considerable amount of time for the operating concern to be activated.
To delete characteristics or value fields, perform the following activities:
1. Delete the corresponding characteristics and value fields from Customizing in all clients (this includes forms, reports, planning layouts, and so forth). To locate characteristics and value fields, use the appropriate where-used list in the Customizing Monitor. You can access it by choosing Tools -> Analysis -> Check Customizing Settings. You can jump directly from the where-used list to the relevant Customizing transaction and then delete the appropriate field there.
2. Switch to the screen for maintaining the data structure of an operating concern (Maintain operating concern).
3. If you need to effect other changes to the datastucture for the operating concern before making any deletions, effect those changes and save the data structure.
4. In order to be able to select the fields of the data structure, choose Extras -> Characteristics (or Value fields) -> Unlock.
5. Select the characteristics and value fields to be deleted and remove them from the data structure with the "Reset fields" function.
6. Reactivate the operating concern. The system starts by checking whether the operating concern contains any data and whether the fields to be deleted are still being used in any Customizing settings.
7. If none of the fields are still in use, the system then starts the re-activation. If the operating concern does not contain any data or does not require the database system to be converted, the tables are activated. You are then able to activate the environment for the operating concern. In this case, the following activities no longer apply.
If the operating concern already contains data, a system message tells you that the database needs to be converted. If you proceed, an activation log appears (at the top of the list).
8. Analyze the activation log. If it only contains error messages telling you to convert the tables, proceed with the next activity.
You must otherwise remove the cause of the errors before the tables can be converted. In this case, you should answer "No" to the next prompt, which asks whether the conversion transaction should start.
9. If you still only receive error messages telling you to convert the tables, choose "Back" and start the conversion.
10. Plan a job for the conversion. A list of the tables to be converted is shown for this. If the tables only contain a small amount of data (less than 10 000 records), then all the tables can be converted in one job. In that case, you can select all the tables.
For larger tables, conversion should take place in several jobs. However, you should ensure that table CE4xxxx (where xxxx = operating concern) is the last table to be converted.
Warning. No other changes can be made to the operating concern during the conversion.
A copy of the table is generated during the conversion. The database system should have sufficient memory available for this copy.
To schedule conversion as a job, use the "Schedule selections" function. You can display the current status of the conversion by selecting the "Refresh" icon. Tables disappear from the list once they have been converted sucessfully. If a conversion is taking a while, it is also possible to leave the transaction. You can then continue the conversion using DB requests -> Mass processing in one of the following ways:
With the job overview. You access this by choosing System -> Services -> Jobs.
Using the database utility transaction. You access this by choosing Utilities -> Database Utility in the ABAP Dictionary menu.
You can use the status function to call up the status of the operating concern during operating concern maintenance. You need to activate all tables after conversion.
11. To analyze errors that have occurred during the conversion, you can use the database utility transaction by choosing Extras -> Logs. The log has the same name as the conversion job: TBATG-date. You can also restart the conversion with this transaction.
For more information on the database utility, choose Help -> Application help while still in the above transaction.
12. Once you have activated all the tables in the operating concern, generate the operating concern environment from within operating concern maintenance.
You can then use the operating concern again.
If you want to transport the operating concern into a different system, see the section "Notes on transport"
Note
Hope this helps
Thanks,
Reddy
Edited by: reddy sap on Sep 11, 2009 6:58 PM
Edited by: reddy sap on Sep 11, 2009 7:00 PM

Definition of a new operating concern

Hi experts,
We have a question about transporting a new operating concern.
To transport customizing settings of the new operating concern we used Tcode KE3I.
We defined new characteristics and value fields for the new operating concern.
In the customizing request we can see that for the tables TKEF and TKEFD all entries (old and new) were included.
But all old fields already exists in the target system of the transport request.
Should we keep the old fields (existing characteristics and value fields) in the customizing request or should we delete them and leave only the new ones ????
Thanks.

Cincean:
By old entries you mean the SAP delivered entries/characteristics??
Or the characteristics you previously created?, if so, just keep it that way and transport
Vj
Assign points if info helps

Delete COPA characteristics which not used in any operating concern

Hello SAP experts,
Please advise me on how to delete PA characteristic "WW001" created by mistake that we are hoping to delete if possible. However, when attempting to delete in KEA5, the error log appear as
Data element RKEG_WW001 is used in these table/view
CACS_S_COND_MA
JVKOMP
KOMG
KOMGF
KOMGFNEW
KOMGFOLD
KOMP
KOMPAKE
STR_KOMG
TRCON_IT_KOMP
WB2_EKOMP
And does not allow the deletion
WW001 have already been delete from the operating concerns.
Please shed some light on how to do this?
Thanks in advance for your help
Yang

Hi,
In order to delete a characteristic you should perform
the following activities:
1. Delete the corresponding characteristics and value fields from
Customizing in all clients (this includes forms, reports, planning
layouts, and so forth). To locate characteristics and value fields, use
the appropriate where-used list in the Customizing Monitor. You can
access it by choosing Tools -> Analysis -> Check Customizing Settings
(TA KECM).
You can jump directly from the where-used list to the relevant
Customizing transaction and then delete the appropriate field there.
2. Switch to the screen for maintaining the data structure of an
operating concern (Maintain operating concern).
3. If you need to effect other changes to the datastucture for the
operating concern before making any deletions, effect those changes and
save the data structure.
4. In order to be able to select the fields of the data structure,
choose Extras -> Characteristics (or Value fields) -> Unlock.
5. Select the characteristics and value fields to be deleted and remove
them from the data structure with the "Reset fields" function.
6. Reactivate the operating concern. The system starts by checking
whether the operating concern contains any data and whether the fields
to be deleted are still being used in any Customizing settings.
7. If none of the fields are still in use, the system then starts the
re-activation. If the operating concern does not contain any data or
does not require the database system to be converted, the tables are
activated. You are then able to activate the environment for the
operating concern. In this case, the following activities no longer
apply.
If the operating concern already contains data, a system message tells
you that the database needs to be converted. If you proceed, an
activation log appears (at the top of the list).
8. Analyze the activation log. If it only contains error messages
telling you to convert the tables, proceed with the next activity.
You must otherwise remove the cause of the errors before the tables can
be converted. In this case, you should answer "No" to the next prompt,
which asks whether the conversion transaction should start.
9. If you still only receive error messages telling you to convert the
tables, choose "Back" and start the conversion.
10. Plan a job for the conversion. A list of the tables to be converted
is shown for this. If the tables only contain a small amount of data
(less than 10 000 records), then all the tables can be converted in one
job. In that case, you can select all the tables.
For larger tables, conversion should take place in several jobs.
However, you should ensure that table CE4xxxx (where xxxx = operating
concern) is the last table to be converted.
Warning. No other changes can be made to the operating concern during
the conversion.
A copy of the table is generated during the conversion. The database
system should have sufficient memory available for this copy.
To schedule conversion as a job, use the "Schedule selections" function.
You can display the current status of the conversion by selecting the
"Refresh" icon. Tables disappear from the list once they have been
converted sucessfully. If a conversion is taking a while, it is also
possible to leave the transaction. You can then continue the conversion
using DB requests -> Mass processing in one of the following ways:
With the job overview. You access this by choosing System -> Services -> Jobs.
Using the database utility transaction. You access this by choosing
Utilities -> Database Utility in the ABAP Dictionary menu.
You can use the status function to call up the status of the operating
concern during operating concern maintenance. You need to activate all tables after conversion.
11. To analyze errors that have occurred during the conversion, you can use the database utility transaction by choosing Extras -> Logs. The log
has the same name as the conversion job: TBATG-date. You can also restart the conversion with this transaction.
For more information on the database utility, choose Help -> Application
help while still in the above transaction.
12. Once you have activated all the tables in the operating concern,
generate the operating concern environment from within operating concern maintenance.
You can then use the operating concern again.
Please, refer to the IMG documentation under Controlling ->
Profitability Analysis -> Structures -> Define operating concern
-> Maintain operating concern, for further details.
It is not possible to transport information about 'deleting of
characteristics (value fields)' with transaction KE3I. Only
characteristics and value fields included in operating concern (to be
transported) are transported with KE3I. Deleted characteristics and
value fields are ignored. You have to delete these characteristics and
value fields manually in each system.
Best regards,
Maria Luisa

Adding a ValueField to an existing Operating Concern?

Gurus,
I'm new to CO-PA. I need to add a new Value Field to an operating concern which is already live in CO-PA.
Please let me know the impact of it on an operating concern and the existing reports if any.
Create the new Value Field in KEA6
Add the new field to Data Structure of the new Operating Concern in KEA0.
Are there any other steps that need to be taken care of ?
Any help in this regard is greatly appreciated.
Thanks,
erp warrior

Hi
1. Create the VF in KEA6
2. Add it to the data structure in KEA0 i.e. push it from list on the right side to Left side
3. SAVE and CLick on the CANDLE icon to activate the data strucutre
4. Press back
5. System would give a pop up to generate the OP concern again.. Confirm it and regenrate the op concern
6. Now, generate a transport request from KE3I.. Select all the indicators under "Operating Concern"... Transport the work bench and the customizing requests to prod client
make sure that all users are logged off while you transport the requests
Regards
Ajay M

Do I need to rebuild the operating concern once again.

Hi,
I have added extra field to the COPA data soruce (1_CO_PA_XXX) and written CMOD code to populate the data. But I am not able to see the newly added field while trying to fill the data through RSA3.
1. Why am I not able to see the newly added field.
2. Do i need to rebuild the operating concern once again? If yes, Do i need to resbuilt in every system or can it be transported?
3. I am also seeing another data source (1_co_pa_xxx_oc). What's the difference between data sources 1_CO_PA_XXX and 1_co_pa_xxx_oc?

When you're doing a test extraction in RSA3, is the column there but with no data or is the column not even showing up (you may have to right-click on the columns and click on Show... to get the new column to show in RSA3)? Try deugging the 1_CO_PA_XXX DataSource in RSA3 on your R3/ECC source system to determine why the code in CMOD isn't being invoked, or not providing the data. We have been able to modify our 1_CO_PAXXX DataSource by enhancing the extraction structure with an append and then creating code in CMOD, so you shouldn't have to recreate it.
As for the 1_CO_PA_XXX_CO DataSource, it appears that someone has created a second COPA DataSource. It could be that one was created opposite of the 1_CO_PA_XXX DataSource in that it's account-based v. cost-based or it could be the same basis with different fields.

No attributes exist for operating concern

Dear Friends:
In our configuration client, the operating concern is active and has attributes were defined and transported. But in Unit testing client, the system says
"No attributes exist for operating concern"
How to over the problem?Please advise?
How should i reward the answers?
Regards
MSReddy

First try regenerating the operating concern in KEA0 in the envirionment tab. Select the activate buttons. If that does not work then retransport your operating concern using tcode KE3I.
pls assign points if helpfu;l as a way to say thanks.

Maintain Operating Concern (KEA0)

Hi,
I have created a new value field via KEA0. The problem is how can i transport the changes to production system? Thanks.

Use KE3I to transport your Operating Concern. Then use KE0A to regenerate it. Always test in QA first.
pls assign points if helpful as a way to say thanks.

Info about a new value field in a live operating concern

Hi Team,
I'm working on 4.7 system.
I have a live Operating Concern with 120 value fields in "Active" Status.
Some of them never have been posted until now. I need a new "Quantity type" value field, but I can't create another one because I already have 120.
In addition, the value fields that have not been used until now are "Amount type" ones.
Is it possible to delete or modify one of these value files and create another "Quantity type" one, considering that Operating Concern is productive? And how can I do it? What kind of problems could I have?
Best Regards,
Gio

Hi Gio,
Good evening and greetings,
Please go through the SAP Note No.21207 on Deleting a Characteristic / Value Field from an active Operating Concern. This should clarify your questions.
Please reward points if the note is of some use to you.
Thanking you,
With kindest regards
Ramesh Padmanabhan

Transport operating concern

Similar Messages

Maybe you are looking for