Version comparison:

Comparing an object with in a system (Different versions) or between different systems

(Same/Different versions) to identify if the object data is same or not is called as version
comparison. Object can be an ABAP program, data base table definition, a customization object
etc.
Why should version comparison be done before making any changes
to any object?
It is very important to do version comparison with production system before making any change
to any object in development system. Because, when we do some changes to an object and move
to production, only the intended changes should get moved to production system. For this, we
should ensure that production and development versions are same before making any change.
Eg: There is a live object in production system. Some changes was done in development system,
object is deleted from TR and left like that for a while in development system without reverting
the changes. When a new change comes later, if version comparison is not done, old changes
would be moved to production along with new changes which is unintentional and may cause
many issues like dumps/malfunctioning of program etc.
We all know how to do version comparison of ABAP objects between different systems (Say
between development and production) like programs, includes, tables, structures etc. This is
inbuilt standard SAP functionality. But it is often ignored by most of the functional consultants
while doing the customization changes. Reasons could be unawareness on how to do this or
ignorance.
SAP has given a standard tool (Transaction SCU0) for doing version comparison of
customization objects too. In this document i will explain the step by step process on how to use
SCU0.
Step 1: Identify the customization node in SPRO where changes are being
done and identify underlying database tables that are updated
Eg: I am taking payment terms as the change here.
Go to SPRO path and right click on the node where changes are being done. Select Display
technical info.

In the next screen, select the tab "Maint. Objects". This helps to identify the maintenance view
for the relevant node. As you see in below screen, it is V_T052.

Now let us identify the underlying tables for the view V_T052.

Double click on V_T052 and select other view as shown below.

In the next popup, double click on "Piece list" option.

Now, we can find underlying tables that are updated when we do any change through the
respective node in customization.

Other alternative is to find the list of tables from view definition in t-code SE11/SE12.
Step 2: Find out the version differences.
Go to t-code SCU0, select "Manual selection" option and click on create.

In the next popup, enter the list of table names identified earlier.

In next screen, Enter some description and RFC destination of the system to be compared with.
You can find the destination name from t-code SM59 or your BASIS consultant can help to
identify this. Once the details are entered, click on "Total comparison".

System prompts for user ID and password of destination system. Enter the details and proceed.
After this, A report summary is displayed with the list of differences between the two systems.
This is self explanatory.

Going into details of the differences between the systems, select one table at a time (This is a
restriction) and click on comparison button in tool bar.
Select the appropriate option in next popup. If we select restrict number of entries, addition
popup would appear to ask for selection criteria for filtering.
In this case, I am selecting total table comparison. After this, enter the log in credentials of
destination system again.

Below is the sample output (Part of the output is masked due to confidentiality).

Step 3: Decoding output:

It is very simple to decode the output as SAP has given simplest approach by different colour
coding for different scenarios in addition to code letter.
Below figure shows the different scenarios that are possible which are again self explanatory.

Step 4: Decide to proceed with change or not.

If you are trying to change some existing entry, that should be shown same as the production
entry (White/light gray background). If it is different, further analysis can be done through
change logs t-code SCU3 and proceed accordingly. There shouldn't be any issue if our change
is related to creation of new entries as these entries doesn't exist in target system.
Same procedure has to be repeated for all the tables of the maintenance view to confirm the
dependency. This T-code can be used for any customization change irrespective of module.
There are many other options/t-codes that are being explored further to find out more Gems
hidden by SAP in their treasure...