Version comparison of customization objects is a cakewalk!!!

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…

Your valuable feedback on this document is most welcome

Best regards,

Vinod Vemuru