In this activity, you can create a transport
request which lets you transport objects to a target system.
Once you have made your CO-PA settings, you can
collect the objects which are linked to these settings (table entries, data
elements, domains, tables, and so on) in a transport request.
With this function, the system collects all the
dependent objects in the source system and places them in a transport request.
After importing the objects to the target system, it automatically activates
the necessary objects in the ABAP Dictionary (the data structures of the
The source and target systems must be of the
same release and update level.
1. Choose a
transport object class.
2. Enter a
3. Select the
objects you want to transport.
4. Select the
dependent object classes.
the transport request using the tools provided for this.
With this function you create a transport
request based on the current settings. Consequently, no new CO-PA objects
should be added and no settings changed while the transaction is running.
Furthermore, in R/3 you can create a transport request (what you want to
transfer) and carry out the actual transfer at different points in time. If
you change any settings between the time when you create the transport request
and when you carry out the transport, the system recognizes some of the
changes but does not add any new objects to the transport request. This can
lead to inconsistencies in the target system following the
SAP therefore recommends that you make no
further settings in CO-PA between the time when you create the request and
when you export the settings.
When you create the transport request, the
system is not able to check which of the objects to be transported already
exist in the target system. If objects already exist there, the system may
import these objects and overwrite the ones which were created in that system.
To avoid this, you should set up one source system first, and then transfer
the settings to your other system(s). Do not create any new CO-PA objects
(operating concern, characteristic, value field, and so on) in the target
on transports into CO-PA covering the following topics:
- Automatic transport versus manual
- Transporting client-specific and cross-client
- Transporting translated settings (settings in
- Postprocessing following import
- Notes on the individual transport
transport versus manual transport
As in other applications, many CO-PA
customizing settings are automatically collected in a transport request.
However, this does not apply to all settings.
For information on the transport type, see the
following IMG activity: Additional Information -> Technical data ->
Transport type. Settings for manual transport can usually be
transported using the transport options with the individual transactions or by
using this transport transaction. Which one you choose will depend on the
purpose of the transport as well as the number of objects to be
In contrast to the
standard transport functionality, the current transport function allows you to
transport larger amounts of objects. This usually means that more may be
transported than is necessary. If the source and target systems are identical,
this poses no problem. If you only want to transport individual table entries
or settings, you sh ould use the transport function available from the
relevant customizing transaction or create a transport request
objects (reports, forms, and so on) later with this function means that
objects that have been deleted in the meantime will not be found.
The first time you
transport an operating concern, you can do so most easily using the function
If a transport
request is generated in the process, you can also release this following the
- "Delta" transport (changes)
If you later add
customizing settings that are automatically recorded in a transport request,
you can transport them using that transport request. All other settings must
be transported manually.
and cross-client settings
In CO-PA, Customizing consists of cross-client
settings (such as tables and data elements) and client-specific settings (such
as Customizing value flows). Two request categories are usually used in the
- The Customizing settings in CO-PA are split by
default into these two request categories, depending on whether they are
cross-client or client-specific settings. You can deactivate this splitting
function in the transport settings (found under Goto ->
Settings). Read the documentation on the
Split Objects into Workbench and Customizing Requests
translated settings (settings in different languages)
If objects exist in different languages, these
languages can also be taken into account during the transport. For this, you
need to set the corresponding indicator in the settings. All languages are
transported by default.
If only some of the languages should be
transported, you can add just those particular languages to an existing
transport request by choosing "Edit -> Add languages". You cannot do this
with Data Dictionary objects because the language transport for those objects
uses the system settings.
No postprocessing is
necessary when you transport settings that have nothing directly to do with
the structures of the operating concern. These include reports, forms, key
figure schemes, layouts, and so on. However, these objects require you to have
a compatible operating concern in the target system.
In Release 4.5A, the
system automatically carries out some postprocessing actions ("after-import
methods") directly when you import certain Customizing settings. This means
you no longer need to carry out these steps manually in the target system. You
can find information about what methods were carried out - and any error
messages issued - in the import log.
settings are transported, it is necessary to regenerate the client-specific
environment of the operating concern. Generation occurs the first time the
transaction is called up (after not after the import phase).
- Summarization levels are not automatically
activated after the import. You need to activate them manually and then
populate them with data.
- Number ranges are generally not transported.
Consequently, you need to define them in the target system following the first
transport. However, it is possible to transport the number range groups that
are assigned to the CO-PA record types (using "Structures: Number Range
Groups"). It is recommended that you only transport these groups if the source
and target systems have the same record types and number ranges. Otherwise you
should define them manually in the target system.
- For technical reasons, the system cannot
transport any reports whose names contain special characters. To get around
this problem, you need to create a new report without special characters, and
copy the old report.
To ensure that your
entire system is consistent, the system transports all the tables and table
entries which CO-PA references. The system transports only those ABAP
Development Workbench objects which are generated by CO-PA, and the table
entries which are managed by CO-PA and those changed by the user. Those
settings which you can make in CO-PA, but which also affect other applications
outside of CO-PA, are not transported. This ensures consistency in the target
- If characteristics or value fields have been
deleted from an operating concern that is to be transported to a system that
already contains the old version of the operating concern, proceed as
- Transport all Customizing requests containing
objects for that operating concern.
- In a separate transport request, transport all
reports, forms, key figure schemes, and planning layouts from which the
deleted fields have been removed. If you have deleted steps or rules from the
derivation strategy or from other strategies (such as planning), transport the
entire strategy by choosing Extras -> Transport. In general, the f ollowing
applies: If the maintenance transaction does not have an automatic link to
transport, check whether a manual transport option is available. If such an
option is not available, use the Customizing transaction Transport
Objects to perform the transport.
- In the target system, choose Tools
-> Analysis -> Check Customizing Settings to access the
where-used list, and use this function to determine whether the deleted
characteristics und value fields are still in use anywhere. It may be
necessary to use the corresponding maintenance transaction (which you access
by double-clicking the object from within the where-used list) to remove the
deleted fields from the objects.
- You may only import the changed data
structures for the operating concern when the deleted fields are no longer
referenced in the target system.
- Below is a list of the objects which are
- Master data tables for characteristics that
were not created manually in the operating concern (this applies to
characteristics copied from reference tables)
Notes on the
individual transport objects
For more detailed information on the following
see the section
Details on the individual transport objects (including
information such as a list of the subobjects that can be included in the