Documente Academic
Documente Profesional
Documente Cultură
7 to ECC
6.0
Common issues faced during SAP Upgrade
Introduction
While working on the upgrade projects, we came across many issues for which we found some
responses on SDN but all were scattered & there is no single source/document. Hence this article so
that other SAP folks who are working on upgrade would have the benefit of a reference document
which they would find of some help in case of crisis. Hope this will help you to reduce some
sleepless nights J during your upgrade project. All the best!
This is presented in a Q & A format so that it doesnt become more descriptive but directly talks
about the issue & its resolution.
Workflows
Q : Will the upgrade affect open work items
A : It is perfectly fine to have open work items when upgrading. Any open work items of old version
can be executed in the upgraded ECC 6.0 version. Ensure that all the associated notes listed in Note
1068627 are applied in your system. [1068627 - Composite note about workflow upgrade].
Spool SP01
Obsolete Tables
Q : Are any table made obsolete in ECC 6.0 as compared to R/3 4.7
A : Yes. Table TVARV is replaced with TVARVC & table TTXER is replaced with TTXERN.
Table TVARV is replaced with TVARVC
Check if any entries are read from table TVARV in any of the custom programs. If yes then all
those custom programs have to be changed to read data from TVARVC. Refer note 557314.
Execute program RSTVARVCLIENTDEPENDENT. This program transfers entries of table
TVARV to TVARVC (program doesnt have selection screen. Check the number of entries in both
the tables before & after executing the program).
Table TTXER is replaced with TTXERN
Check if any entries are read from table TTXER in any of the custom programs. If yes then all
those custom programs have to be changed to read data from TTXERN.
Execute program SDTXT1AID to copy entries from table TTXER to table TTXERN. Check the
number of entries in both the tables before & after executing the program. Refer note 900607.
Output of program SDTXT1AID. There could be some entries which wont get copied from
TTXER to TTXERN. They either would be duplicate or incorrect entries which you can ignore.
Program Variants
Q : Are variants affected due to upgrade.
A : Yes, variants are affected after upgrade. After Upgrade, run program RSVCHECK which will list
down all the variants which are affected. Run program RSVARDOC_610 with necessary values to
adjust those variants. However if a selection screen field has become mandatory for a tcode due to
upgrade it has to be addressed by assigning a value to it manually.
Screen of RSVARDOC_610. Here we are fixing variant BOM_X of program
ZMM_BOM_REPORT. If you want to fix all the variants of the program, then give * in S_VARI.
ABAP Queries
Q : After upgrade, the query dumps when we try to execute it
A : ABAP Queries are affected due to upgrade. We need to regenerate the queries post upgrade. We
can re-generate the queries using FM RSAQ_GENERATE_PROGRAM which uses work area,
query name and user group as input. If the queries are more in number we can write a small program
using above FM and table AQGQCAT- for global query and table AQLQCAT- for local/client
specific query
Q : ALV layouts previously created from SAP queries no longer function correctly after
upgrade
A : Refer note 725468
SPDD
Q : There are many objects reflected under DELETED OBJECTS node. How do we fix this?
A : Objects reflected under DELETED OBJECTS should be ignored & need not be fixed.
Q : How to handle the transport of SPDD as BASIS wants the SPDD TR to be imported at OS
level
A : Ensure that all the fixes wrt SPDD are captured in a single Transport. Multiple transports are not
acceptable for SPDD fixes. While releasing the task of your SPDD TR, click on SELECT FOR
TRANSPORT button which is in SPDD tcode 2nd screen. System will prompt to confirm the TR
for subsequent system. Confirm the TR number & proceed. The SELECT FOR TRANSPORT step is
extremely important else your BASIS team wont be able to import the SPDD TR at OS level in the
subsequent system.
Obsolete Transactions
Obsolete FMs
Q : How do I know if any of the custom programs are using obsolete FMs?
A : Table TFTIT would reflect obsolete FMs. Please use following steps to get the list of obsolete
FMs. You may create a small program to check all your custom programs for usage of obsolete
FMs. Such FM calls should be replaced with appropriate replacement FM.
6.0. Hence all the custom programs which are using SO_OBJECT_SEND should be replaced with
appropriate FM.
Customers should create a tool to identify a list of custom programs where non-released (Internal
SAP ) FMs are being used. Programs which are calling such FMs should be modified to point to
suitable replacement FM.
If a FM was released to customer in old version (say 4.7) & later on was changed to Internal SAP
only, then in such case SAP would provide a note.
Cloned Programs
Q : Do we need to fix cloned programs as well?
A : Well there would be some cloned programs which have few standard includes & few Z Includes
which are copy of standard includes. If these standard includes have undergone some change /
deletion / modification etc, then there is a possibility of the cloned program giving dump/error.
Hence as a preventive step, all the cloned programs should be validated (syntax check) & tested.
There is a possibility of the Main program undergoing lot of changes due to upgrade. Customer has
to take a call to decide if they want to create a clone program of the upgraded version of std. program
or would like to continue with the old version of the cloned program.
Replacing WS_DOWNLOAD FM
Q : WS_DOWNLOAD FM should be replaced with GUI_DOWNLOAD FM?
A : Yes, the new replacement is FM GUI_DOWNLOAD. While replacing check if the MODE
parameter is passed with value A in the program. If yes then you need to ensure that for FM
GUI_DOWNLOAD APPEND parameter is set to X.
Similarly check if the FIELDNAMES is assigned to any internal table. If yes, then in
GUI_DOWNLOAD pass the same internal table to FIELDNAMES.
SAP Notes
Q : Notes listed under INCONSISTENT node are reflected as "Obsolete version implemented"
in SNOTE
A : Ignore the notes reflected under SNOTE-Inconsistent Notes as the notes are already applied
during upgrade
Q : New TR number conflicts with transports created from other development systems.
Basically the TR number generated in the current dev system (that is a copy of existing dev
system) is having a corresponding TR no. in the original system that would have reached
Prod/Quality.
A : If system id is changed after upgrade and not before upgrade, transport request number conflicts
will arise. To prevent this, ask the basis team to increase the transport number sequence to such a
number that the conflict will not arise at all.