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):
- Characteristics: CE1xxxx, CE2xxxx, CE4xxxx,
CE4xxxx_KENC and CE4xxxx_ACCT
- Amount fields: CE1xxxx, CE2xxxx and
CE3xxxx
- Quantity fields: CE1xxxx, CE2xxxx, CE3xxxx,
CE4xxxx, CE4xxxx_KENC and CE4xxxx_ACCT
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 |
|
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.