Show TOC

Maintain Operating Concern

In this activity you define and maintain the operating concerns you are going to use in your system.

If you want to create a new operating concern, you need to create the subobjects data structure and attribute and to activate the environment:

Data structure

The data structure determines the structure of the profitability segments that you can analyze and how costs and revenues are organized. All information in the data structure definition is valid for all clients . If you use the operating concern in more than one client, you still only need to define the data structure once. You then need to set the attributes in each client individually.

One of the specifications you make for the data structure is the type of Profitability Analysis. You can only activate the operating concern for the types you specify here.

The structure of the operating concern is defined by the characteristics and - in costing-based Profitability Analysis - by the value fields as well:
Characteristics are the segments of your organization for which you want to analyze your data in CO-PA.
Several fundamental characteristics are predefined in every operating concern. These are called "fixed characteristics". You can display a list of the fixed characteristics by choosing Extras -> Fixed fields.
In addition to these predefined fields, you can define up to 50 of your own characteristics in each operating concern. You can select these from a list of additional predefined characteristics, or you can create your own using the Customizing function Maintain Characteristics.
Value fields are the fields in costing-based CO-PA in which the system stores the amounts and quantities. They thus determine the structure of your costs and revenues.
An operating concern can contain up to 120 value fields. The standard system contains a list of predefined value fields (such as "Sales quantity" or "Sales revenue").
If you want to define additional value fields, you can do this using the Customizing function Maintain Value Fields.

To add fields (characteristics or value fields) to your operating concern, select the desired fields on the Edit Data Structure screen (right side of the screen). Then use the function Transfer fields to copy these fields to the data structure. You can only transfer fields with an active status. AN operating concern cannot contain two fields for which the meaning, the short text, or the field title overlap.

Once you have defined your data structures, you need to activate them. When you activate the data structures, the system creates the tables for plan and actual data in the database system.

If you choose to add new characteristics or value fields at a later stage, you should note that these do not work retroactively. However, you can supply new value fields with existing planning data using the "Automatic planning" function or the "Periodic valuation" function. To fill new characteristics retroactively, you need to perform the "Realignments" function.

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):

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
To finish processing the data structures, use the "Back", "Exit", or "Cancel" navigation functions.

Attributes

The attributes are client-specific parameters of an operating concern. They have different effects depending on the type of Profitability Analysis you are working in. When you create the attributes, you make the operating concern "known" in that client. If the operating concern does not yet contain any transaction data, you can change the attributes at any time. However, you should not change them in a productive system that already contains transaction data.

Note: Whereas actual data can be updated simultaneously in all the combinations of currency type and valuation that are described below, planning data is always updated in one currency only - the currency specified for that particular plan version.
Note also that updating actual data in multiple combinations of currency and valuation significantly increases your data volume with each additional combination.
Operating concern currency
In costing-based Profitability Analysis, actual data is always updated in the operating concern currency.
You can change the operating concern currency as long as no data has been posted in the operating concern. Once data has been posted, however, a change in the operating concern currency would cause the existing data to be interpreted as if it were posted in the new currency (for example: USD 1000.00 in old currency -> DEM 1000.00 in new currency).
Company code currency
In addition to the operating concern currency, you have the option of storing all data in the currency of the relevant company code as well. This makes sense if your organization operates internationally and deals with exchange rates that change daily. It allows you to avoid differences due to different exchange rates and lets you reconcile your CO-PA data directly with FI.
You can activate the company code currency at any time. However, this will not affect data that has already been posted.
If you deactivate the company code currency, you can no longer use plan versions and reports that use the company code currency.
Profit center valuation
In addition to storing data in these two currencies using the legal (= company code) valuation view, you can also store data in both of these currencies valuated from the viewpoint of individual profit centers.
This yields the following possible combinations of valuation view and currency type (so-called valuation approaches):
Currency type Valuation view
Operating concern currency Legal valuation
Company code currency Legal valuation
Operating concern currency Profit center valuation
Company code currency Profit center valuation
You set up actual data valuation from the profit center viewpoint in Customizing under "Flows of Actual Values -> Multiple Valuation Approaches/Transfer Prices ".
Note
Whereas actual data is updated simultaneously in all the selected combinations of currency type and valuation, plan data is always updated in one currency only - the currency specified for that particular plan version.
Note that updating actual data in multiple combinations of currency and valuation significantly increases your data volume.
If you are using account-based Profitability Analysis, the system stores all data in the transaction currency, company code currency and controlling area currency. If the company code currency and the controlling area currency are the same, the system stores the object currency for the individual CO object (cost center, order, project, and so on) in place of the company code currency.
The currencies you specify for the operating concern have no significance for account-based CO-PA.
The fiscal year variant determines the number of posting periods per fiscal year for the operating concern. Since each controlling area assigned to the operating concern -- and each company code assigned to each of those controlling areas -- can have its own fiscal year variant, the variant you choose for the operating concern must agree with the other areas.
If you want to change the fiscal year variant, you can only do so in a way that increases the total number of periods, for example:
from 12 posting periods + 2 special periods
to 12 posting periods + 4 special periods
If the alternative period type is active for the operating concern (see below), you cannot change the fiscal year variant.
If you are using costing-based Profitability Analysis, the operating concern and the controlling area which is assigned to it must have the same fiscal year variant before you can transfer overhead.
If you are using account-based Profitability Analysis, the operating concern and the controlling areas must always have the same fiscal year variant.
If you are using costing-based Profitability Analysis, you can use the alternative period type to store your actual or plan data in weeks. However, activating the alternative period type multiplies your data volume. This could lead to much slower response times in your information system than if you do not use the alternative period type.
You can also activate the alternative period type at a later point in time. The only disadvantage of this is that the data posted up to that point will not be stored according to the alternative period type. That data remains assigned to the posting period.
If you are using account-based Profitability Analysis, you cannot use the alternative period type.

Environment

Whenever you activate the data structures, you also need to activate the cross-client and client-specific environment of the operating concern. If you have added new characteristics to an operating concern in a productive system, you should make sure that no postings are made in that system while you are activating the environment. Activate the environment on the same server that you activated the data structures on.

Standard settings

The standard R/3 System contains the sample operating concern "S001". You can copy this operating concern to create your own operating concern. However, you should not use it productively.

Activities

To define your operating concern, proceed as follows:

1. Enter the name of the operating concern.
2. Enter a text for the operating concern.
3. Specify which type or types of Profitability Analysis you want to use.
4. Create the data structures and activate them
5. Activate the environment.
6. Define attributes in each client in which you want to use the operating concern.

Additional information

1. Generated objects
When you activate the data structures of your operating concern, the system creates the following objects in the ABAP Dictionary:
Type Name Description
Structure CE0xxxx logical line item structure
Table CE1xxxx actual line item table
Table CE2xxxx plan line item table
Table CE3xxxx segment level
Table CE4xxxx segment table
Table CE4xxxx_KENC realignments
Table CE4xxxx_ACCT account assignments
Table CE4xxxx_FLAG posted characteristics
Structure CE5xxxx logical segment level
Structure CE7xxxx internal help structure for assessments
Structure CE8xxxx internal help structure for assessments
In these names, "xxxx" stands for the name of the operating concern.
2. Upgrading your system
When you upgrade your system to a later release, or when you import a support package, the new functions or corrections need to be activated for your existing operating concerns. This is done automatically when you execute the first transaction that uses data from Profitability Analysis. This normally takes a few minutes and is announced by a message at the bottom of the screen you are currently on.
This upgrade includes a number of checks and, where necessary, the automatic correction of inconsistencies. However, the system may encounter situations that it cannot handle automatically. It is therefore recommended that you carry out this upgrade manually by executing a simple function (such as "Environment -> Set operating concern" in the application menu) before you begin working productively again in the new release. This will trigger the upgrade process.

Deleting an operating concern

To delete an operating concern, you need to carry out a number of preparatory steps:

1. Deactivate Profitability Analysis for all the controlling areas that belong to the operating concern to be deleted and in all fiscal years using the function Activate Profitability Analysis.
2. Delete the assignment of controlling areas to your operating concern using the function Assign Operating Concern (Customizing for the Enterprise Structure).

You can access the following steps in the function Operating concern -> Delete.

3. Delete the client-specific Customizing settings.

After completing steps 1 through 3 in all clients, you can proceed with the following steps:

4. Delete the environment.
5. Delete the data structures.
When you delete the data structures, the system also deletes all the transaction data in that operating concern. This data can no longer be recovered.

If you want to delete characteristics and value fields that are not used in any operating concern, you can do this using the Customizing functions Maintain Characteristics or Maintain Value Fields.

Notes on transporting

You can transport the settings you made to your productive system using the CO-PA transport tool.

Note that the generated ABAP Repository objects are valid for all clients. Conflicting names in the target system can also lead to problems in other applications. Therefore you should make all Customizing settings in one (source) system. You can then transport these settings to your other (target) systems. This technique helps you avoid inconsistencies.

If you cannot use this technique for some reason, be sure to observe the following:

1. Characteristics and value fields with the same name must have the same text, the same attributes (type, length), the same check table and the same origin table in each system.
2. For characteristics which were defined manually, enter the number for the check table manually as well. Each characteristic must have the same number in all systems. The assignment of the number to the characteristic must be unique.

For more information about transporting objects, see Transport.