Skip to Content

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.

Capture.PNG

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.

Capture.PNG

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

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

Capture.PNG

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

Capture.PNG

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

Capture.PNG

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.

Capture.PNG

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

Capture.PNG

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”.

Capture.PNG

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.

Capture.PNG

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.

Capture.PNG

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

Capture.PNG

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.

Capture.PNG

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…

Your valuable feedback on this document is most welcome

Best regards,

Vinod Vemuru

To report this post you need to login first.

14 Comments

You must be Logged on to comment or reply to a post.

    1. Vinod Vemuru Post author

      Thanks Godavari. This really helps when projects and support teams work in same system to identify the conflicts at the earlier stages.

      Thanks,

      V V

      (0) 
  1. Kavita Agarwal

    Hi Vinod,

    Nice and useful piece of information.

    But have you used transaction code SCMP to compare the table differences between two systems.. this also highlights the table differences.

    Thanks for sharing.

    Regards,

    Kavita

    (0) 
  2. anil kumar

    hi Friends,

    Plese help me to resolve this issue have a requirement to allow access for Object comparison across the landscape but without providing SCU0 AND SCMP access.  is there any alternative way to provide this access, this is for functional users not for basis users.

    (0) 

Leave a Reply