Dear SAP Community Member,
In order to fully benefit from what the SAP Community has to offer, please register at:
Thank you,
The SAP Community team.
Skip to end of metadata
Go to start of metadata


With the following steps, you will be able to create a test landscape to practice the Enhanced Retrofit functionality in SAP Solution Manager 7.2.

Also, I will try to give tips and tricks for the configuration of this scenario in SAP Solution Manager 7.2 and how to analyze possible issues using this functionality.

Note: For the new Standalone Retrofit functionality in SAP Solution Manager 7.2 please check KBA 2488168 - Standalone Retrofit - SAP Solution Manager 7.2




Software changes are done in one system and will be transported to the system landscape which is linked to this system by transport routes of the Transport Management System. But sometimes it is necessary to implement these changes in another system landscape but without using the import function of the transport requests.

Imagine this scenario with a Maintenance landscape and also an Implementation landscape. Here, PRD would be the system that is already go live.

Now you want to implement a new functionality for your system. You will use a second development system DV2 to work in this new implementation. By working in DV2, you will not disturb the maintenance of the PRD done in DV1 system.

Usually DV2 and QA2 are created initially as system copy from PRD system.

If a change is done in DV1, this change must also be done in DV2 to maintain the synchronization--this is the reason for retrofit, to bring the changes made in DV1 to DV2.

Changes of a Maintenance cycle also should be duplicated in an Implementation cycle that provides the same Production system of the Maintenance landscape.

The main new features and advantages of the Enhanced Retrofit Functionality can be summarized:

1. Automatic Categorization of Objects (Auto Import, Semi-automatic, and Manual)

During the release of the transport request that contains the changes done in DV1, the enhanced retrofit functionality will check all objects contained in the transport request and categorize them one by one. According to this categorization, different retrofit data wil be generated for each object: 

- Auto Import (Support of 100% of transportable objects!):

• Applies for all Objects of a Transport Request which have no conflict. They have not been changed in the retrofit system so there is no CSOL lock entry for them in the Solman system.

 • Retrofit is performed through a transport of copies (TOC) which is automatically created and released, and contains only the objects without conflicts .The retrofit tool imports this TOC into the retrofit system and copies the objects into the indicated retrofit transport request). This TOC is created after the release of the transport requests in DV1 system. 

- Semi-Automatic Retrofit with Correction Workbench (Note Assistant) or BC-Sets

• Applies for all Objects of a Transport Request which have a conflict and which are supported by one of the tools (Repository Objects with Correction Workbench, customizing via BC-Sets). This was available with the "old" version of the retrofit (supportability of 70-80% of objects).

• Both tools offer the possibility to do adjustments, which are necessary in case of a conflict to not simply overwrite a change in the Implementation Project (Release Development).

-Manual retrofit

• Objects with conflicts which have no support tool.


2. Conflict Detection is performed via Cross System Object Lock CSOL at object level

- Possibility to perform retrofit on object level


3. Detection of technical sequence dependencies

- Detection of same objects to be retrofitted in which order

- Advanced Control of Retrofit Sequence


4. Additional Features

- Enhanced Logging of Messages

- Comparison of compatible objects before retrofitting

- Various Customizing Possibilities

- Implementation of Customer Specific Requirements via Standard SAP BADIs



The configurations given here are valid for Solution Manager 7.2 SP07.

The configuration is done in two parts:

  1. Solman_setup → Change Control Management → Change Request Management → Set Up Downgrade Protection and Retrofit  → Configure Retrofit
    Perform these activities:
    1.1. Define Retrofit Parameters (View /TMWFLOW/RCONFIG): Read documentation of the activity for detailed description of each parameter


Important parameters are:

      • NO_CSOL: The system does not create entries in the cross-system lock for automatically created import objects in the target system.
      • WARN_TOC: Imports of transports of copies are handled as successful even if there are warnings. When active, the import is marked as successful even if there is a return code 4.
      • SCEN_CROSS: Enables cross-release retrofit. Systems need to be specified under Define System-Specific Retrofit Settings. 

1.2. Status Customizing for Retrofit Objects Optional (View /TMWFLOW/EDT_CST): In this configuration activity, you can allow or forbid certain manual changes to the objects in the retrofit object list of a transport request. You can activate a warning or an error message for any possible status change in the object list.

1.3. Define Values for Retrofit Scenarios Optional (View /TMWFLOW/RSCEN)

In this configuration activity, you define which objects are selected for the manual processing in a retrofit.

You can do this for the following scenarios:

      • Retrofit scenario for manual processing (SCEN_MAN) You can use this as a blacklist defining the objects that you want to exclude from automatic retrofit.
      • Retrofit scenario for Business Warehouse objects (SCEN_BW)

1.4. BAdI: For the Creation of Retrofit Data Optional (BAdI /TMWFLOW/RETRO_EXTENDE_DEFAULT): You can use this Business Add-In /TMWFLOW/RETRO_RELEASE_IMPL to implement customer-specific changes that are performed before the retrofit.

1.5. BAdI: During the Retrofit Optional (BAdI /TMWFLOW/RETRO_DURING_IMPL

1.6. BAdI: After the Retrofit (BAdI /TMWFLOW/RETRO_EXTENSION_ENH)

2. Solman_setup → Managed System Setup→  Configure Extended Function → Configure Retrofit

2.1. Activate Domain Links

For the retrofit scenarios, you need to activate a domain link between the domain controller of the maintenance landscape and the domain controller of the implementation landscape.

You have to connect the domain this system belongs to with a domain link.

2.2. Define System-Specific Retrofit Settings (View /TMWFLOW/RCFGSYS): Required if you have activated the Cross-Release Retrofit parameter under Define Retrofit Parameters).

2.3. BAdI: Activate BAdI in Managed System: required only for Standalone Retrofit

2.4. Prepare Implementation Landscape for Retrofit: required only for Standalone Retrofit

2.5. Prepare Maintenance Landscape for Retrofit: required only for Standalone Retrofit

Despite these are the configuration points in solman_setup I miss some configurations so allow me to define step by step how to configure retrofit scenario for this test landscape:

Maintenance landscape: EYE:100->EYE:200->EYE:300

Implementation landscape: EYE:101->EYE:102-> EYE:100

EYE:101 is called the retrofit system.

Step 1. Create the additional clients

EYE is a Solman system, client 001 is the client where ChaRM is configured.

I want to use these landscapes in TMS:

Maintenance landscape: EYE:100->EYE:200->EYE:300

Implementation landscape: EYE:101->EYE:102-> EYE:100

So, create these fice additional clients in EYE, like local client copy from client 000 with SAP_ALL profile, for clients 100, 200, 300, 101 and 102.

Ensure you set the correct roles for these clients in SCC4, more details in this link.

Note: when using the  Semi-Automatic Retrofit with BC-Sets there must not be any client with client role P Live in the retrofit system.


Step 2. Create the test landscape in TMS

Please see how to create this test landscape in this link

Key points

Transports are supported in the standard transport layer of each client. When you configure the transport routes, note that only consolidation routes that are assign to the standard transport layer of the relevant exporting client are taken into consideration.

For each exporting client, exactly one target client and one target group are permitted.

We recommend that you assign exactly one development system to a production system, and that these two systems are connected by exactly one unique transport track.

If a development system and a production system are connected by more than one transport track, this may lead to inconsistencies within the transport distribution.

In the SAP Solution Manager system, in client 000, call /nSTMS (the TMS configuration should be done in the domain controller system of your real TMS managed landscape). In our example, SMD is the only system and so it is the domain controller.

Configure transport routes and transport strategy

In EYE client 000 call /nstms and get these transport routes created:

Note: EYE client 001 does not need to take part of your TMS landscape.

Follow the indications in this link to create these transport routes. 

No transport route between source Dev system in the maintenance landscape and Target Dev system in implementation landscape (retrofit system) is needed.


It is very important to establish a domain link between these two TMS landscapes!

 You need a domain link between the maintenance TMS landscape and the TMS implementation landscape (if not you will have problems later while importing the TOC created in EYE:100 to client EYE:101). Even if you are using Harmonizing infrastructure for Enhanced Retrofit scenario, the domain link between both transport domains are required.

Ensure Trusted services are activated in both domain controller systems.

Domain links between these two TMS landscape with the SAP Solution Manager landscape is no required.


Step 4. Create the RFC destinations for these clients in LMDB

In LMDB in Technical Systems tab enter the systems and create the RFC destinations for them in Destinations section.

In our case for EYE:100, 200 and 300 and EYE:101, 102.

Follow the information in this link.

You will need these connections for each client:


Step 5. Check the ibase components  

Ensure that the ibase components are created in /nib53 for the systems:clients involved in the maintenance and the implementation landscapes.


Step 6. Create the logical component group for these two landscapes

In the wiki page How to create a solution for Change Request Management in SAP Solution Manager 7.2 you will see the steps to create a solution, branches and logical component group LCG for this test landscape in /nSLAN:

Maintenance landscape: EYE:100->EYE:200->EYE:300

LCG can be regarded as a projection of managed system infrastructure into SAP Solution Manager system, so it must represent the real landscape and the system roles should be consistent to system roles at TMS level. That is, for development system, the Type of Role should be Source Systems; for test systems, the Type of Role should be Target Systems; for production system, the Type of Role should also be Production Systems.

Ensure that there are consolidation routes defined from the source system to the first target system and delivery routes created between target systems and from the last target system to production system.

For the implementation landscape: EYE:101->EYE:102-> EYE:100 you will need to create a Development branch to locate EYE:101 and EYE:102, see details in this link

As both landscapes mantenance and implementation landscapes are for the same SAP Product please put all systems from maintance and from implementation landscapes under the same logical component group name.

Note: EYE:100 is in this LCG under Maintenance- Development system. This is ok, I mean a system:client inside one LCG can only appears one time.

As in the TMS you have a Delivery route from EYE:102 to EYE:100 later when creating the implementation cycle the EYE:100 will appears in the production system position.


In a real scenario you will have for example:

Maintenance landscape: DV1->QA1->VA1->PRD

Implementation landscape: DV2->QA2 -> ….

Finally the changes done in the implementation landscape, TRs created in DV2, need to arrive in PRD; you can decide in which way to get these TRs imported into PRD. Depending on this decision you can create different implementation landscapes like:

DV2->QA2->VIR or

DV2->QA2->DV1 or




Step 7. Create a cycle for the maintenance landscape

You need to create a cycle for the maintenance landscape EYE:100->EYE:200→EYE:300.

In the Solution Manager system in the WebClient UI, /nsm_Crm, create a new change cycle, follow the indications of this link.

You need to get this final picture:

Key point is that you need to enter during the task list creation the Retrofit system EYE:101 under Retrofit Systems area:

You could retrofit to several Post-processing systems.

Note this particular line from EYE:100 to EYE:101 ( remember that you don´t need to create any transport route from maintentance development system to implementation development system=retrofit system):

In the task list you need to see your retrofit system under Systems Without Transport Connection- Post-Processing systems:

Unlock the Group also for Systems Without Transport Connection.


Step 8. Create a cycle for the implementation landscape

You need to create a cycle for the implementation landscape EYE:101 ->EYE:102 ->EYE:100.

In the Solution Manager system in the WebClient UI, /nsm_Crm, create a new change cycle, follow the indications of this link.

You need to get this final picture.

Select Development branch.

See that EYE:100 is located under Production Systems area, even being located under Development System column in the LCG.

You need to have in the implementation cycle a system:client under Production Systems to get CSOL scenario working, CSOL requires that the is a production system.


Step 9. CSOL activation for the Retrofit system

We need to activate CSOL for the implementation development system DV2=retrofit system and also globally.

The point is that you need to get a lock entry for every object is changed in the retrofit system, in the development system DV2 of the implementation landscape (EYE:102).

Then if the same object is modified in the DV1 system (EYE:100), the lock entry is detected and autoimport retrofit option will not be available for this object.


Globally activate the cross-system object lock by following the indications in this link.


Locally actívate the cross-system object lock for the retrofit system by following the indications in this link.

Note: for the Retrofit scenario  "On (Legacy CSOL)" setting is enough.


Then perform the configuration in the retrofit system for CSOL according to this link.

Please execute report TMW_CONTROL_PROJECT_LOCK on your retrofit system and select option Read Client Data "X" to ensure that CSOL is activated correcty.


Step 10. RFCs connections required for Retrofit

Initially you don´t need to create these RFC manually, the first time a retrofit is triggered using SCWB or BC Sets from the Start Retrofit popup these RFC destinations will be created automatically.

  • CWBADM_<SID>_<client>: from the retrofit system to the development system in the maintenance landscape, in our example from EYE:101 to EYE:100. Used by the SAP Correction Workbench, SCWB is doing a remote delta comparison from the retrofit system to the development maintenance system. Therefore a trusted RFC-Connection from Retrofit System to Development System needs to be established. User running this retrofit action in the Solman system needs to exist in the maintenance development system with trusted authorizations

  • RETRO_<SID>_<client> - from maintenance project development system to retrofit system, from EYE:100 to EYE:101. Used by the BC-Set tool, BC-Set tool is locally created on the development maintenance system, during the retrofit process it is transferred to the retrofit system and activated there. To support this process it is necessary to establish a trusted RFC Connection from Development System to Retrofit System. User running this retrofit action in the Solman system needs to exist in the retrofit system with trusted authorizations.

Check if the retrofit RFCs are created automatically when you perform the first retrofit activity with SCWB and BC-Set.

User executing this first retrofit activity needs to have enough authorization to create RFC destinations on the managed system(s).

Ensure that you activate TMS Trusted Services in both domain controller systems.

See also:

Note 1484719 Retrofit - Retrofit failed because of RFC-Destination


Retrofit Workflow

Once the configuration is done this is how the scenario works:

At the time of the release of the transport request, created from a ChaRM document for the maintenance cycle where a retrofit system was specified or from the task list of this maintenance cycle, all objects included in the transport request, like DV1K9*, are checked and the retrofit data is created for the objects depending if there are entries or not for the same objects in the CSOL tables like /TMWFLOW/LOCK*.

If there are not entries for the objects in /TMWFLOW/LOCK* tables then a transport of copies TOC is automatically created and released in DV1 system with target DV2 system and will contain these objects without conflicts.

If the objects included in the TR created in DV1 have been changed already in the retrofit system DV2 then they will be entries for the objects in /TMWFLOW/LOCK* tables. 

If this is the case and depending of the object type the retrofit data created in the DV1 system will be a BC-set for customizing objects. For workbench changes we will need to use SCWB tool.

In some particular cases no retrofit data could be created.

When you have objects in the transport request with different categories the retrofit data will be created accordingly.

Note: The transport request release needs to be triggered from ChaRM for getting this objects check performed.

Note: In general the recommendation is to process the retrofit as soon as the transport request is released and retrofit data is created.


Check in section Retrofit tables 7.2 how to see at table level the data created when the retrofit data is generated.

Later when you start the retrofit you need to select a TR created in the retrofit system DV2.

Retrofit process will make that the changes included in TR DV1K9* arrive to the retrofit system DV2.  These changes will be recorded into the DV2K9* transport request.


You can start the retrofit process from:

• An urgent change when the status is "Authorized for Production" from the action list.

• A normal change when the status is "Successfully Tested " from the action list.

• The task list that contains a Post-Processing retrofit system.


We are going to see examples for the use of auto import, semi-automatic and manual retrofit.


1. Auto Import

If no conflict (lock entry) exists then auto import can be used for customizing and workbench transport requests.

The objects included in the TR released in DV1 have not been changed in the retrofit system DV2 so there is no lock entry for them in the Solman system.

At the time of the release of the transport request all objects included in DV1K9 * are checked. If there are objects without lock entries in /TMWFLOW/LOCK* tables then a TOC is automatically created and released and will contain only the objects without conflicts.

Retrofit auto import tool will import this transport of copies into the retrofit system, changes will arrive in retrofit system and objects will be recorded in the retrofit request. After a successful import the status of the request is set to Retrofitted automatically.


  • Create an urgent change UC for example for the maintenance cycle, and create a TR for this UC in EYE:100 Development system of the maintenance cycle.
    You could also create a TR directly from the task list of this cycle.

Note Due to the test scenario selected, different clients of the same system EYE, we are going to test with customizing transport requests.

Note: For workbench change you could create a function group in se80 or a program in se38.

  • Make a change in sm30 V_T005K for example and save it into TR1

  • Release TR1 task
  • Release the TR1 from the task list or from the change document
  • Was there a lock entry in Solman system in /TMWFLOW/LOCKPCN for this WB function group or for the view V_T005K? No! you can check for the lock entries also in the Administration Cockipt- CSOL tab

Then a TOC will be created and exported at the time the TR is exported. You can check this in table /TMWFLOW/TR_TROBJ. As the objects included in the TR1 and TR2 has obj_category 2 then the retrofit data will be created using TOC.

See also table /TMWFLOW/TOCASNG where you can see the created TOC per each TR:

For TR1 see that the target system of the TOC is the retrofit system SS7:100:

In case of errors creating the retrofit data you will see them in the Release TR logs:

  • Now I create a couple of TRs in SS7:100 to retrofit the content of the TOC to these TRs. I need one for WB and another for customizing. I can do this quickly from the I* task list of implementation project I02055_RE2:

Requests TR3 and TR4 created.

  • Start retrofit from the task list:

As all objects in this TR1 had obj_category 2, you can see a Green bullet under Critical Retrofit column.

I need to assign to TR1 the retrofit TR3 where I want to save the content of the TOC. To do this, select the row and click on Auto-import button.

You can see the logs under Additional Functions-> Display logs

See also table /TMWFLOW/RFITC: here you can see original TR, TR where you retrofitted the objects and if the retrofit is done or not and when:

TR3 is getting the content of the TOC:

As TOC is imported into SS7:100:

Do the same for TR2.

According to the parameter NO_CSOL value in SM30 ->/TMWFLOW/RCONFIG:

You can decide if the object retrofitted in the retrofit system should create a CSOL entry or not.

If parameter NO_CSOL is inactive then a lock entry will be created, as now the object is really changed in SS7:100.

Decide the best option for your scenario.

In my testing scenario I was using NO_CSOL with X Parameter Active, so I was not creating lock enties for the function group Z_DOLORES1 and also not from my entry in T005A 950.


2. Semi-Automatic Retrofit with BC-Sets or Correction Workbench (Note Assistant) - Standard retrofit

If a conflict (lock entry) exists then BC-Set/SCWB tools need to be used.

We call this “standard retrofit”, the one used in SAP Solution Manager 7.0.


The objects included in the TR created in DV1 have been changed in the retrofit system DV2, so there is a lock entry for them in the Solman system.

At the time of the release, the Solman system detects this lock and a BC-set will be created in SMM:100 system for customizing objects, for workbench changes we will need to use SCWB tool.


2.1. Customizing changes – BC-Set tool

Prerequisite: Ensure that user creating the BC-Set in the development maintenance system and in the retrofit system has the Deletion functionality for BC-Sets activated.

Logon to all the development systems -> Transaction SCPR20 -> Utilities -> User Settings -> Maint. Transaction -> Deletion Functionality -> Select “Switch On”

This setting is user specific so all the developer accounts need to activate it individually, otherwise if you delete some customizing changes they won’t be supported by B-Sets. As a result you would not be able to Retrofit them.


For customizing request, the BC-Sets are generated during the release of the transport request. So check always the task list release transport request log:


See in SMM:100 in /nscpr20 that BC-Set is created.

Note: not all object are supported by BC Sets, please see Case 3. Manual retrofit will have to be used for this situation.

Later during the retrofit process with BC-Set tool, the corresponding BC-Set ZCHARM* will be created and activated in the retrofit system, changes will arrive in retrofit system and objects will be recorded in the retrofit request in SS7:100. After a successful import, the status of the request is set to Retrofitted automatically.


  • Create a customizing TR1 for SS7:100 in the task list of project I02055_RE2 directly and enter there an initial change in sm30: T005A for entry 960. Release the task of the TR1. You can release the TR1 or not. The only difference is that now you will see a lock entry for the customizing entry in /n/TMWFLOW/LOCKMON:

So we have initial entries in the retrofit system SS7:100 so now we go to create the same entry in T005A for 960 in SMM:100.

  • Create TR2 from M* task list in SMM:100 and create an entry in T005A for 960, save the changes in the TR and release the task.
  • From M* task list release also the TR1.
  • Call now start retrofit from the M* task list:

See that the lock is detected and Critical Retrofit has a YELLOW triangle.

You can create a new TR3 in the retrofit system or try to use the TR1 with the initial changes.

Select “Retrofit for all Categories”.

The following pop ups will appear:

As there were already lock entries you get the popup informing about these lock entries:

In SS7:100 you can see the BC- Set is created and activated.

A new entry is created in /tmwflow/lockmon.

2.2. Workbench changes – SCWB tool

For workbench changes, since SCWB is adopted to carry out the automatic copy process, Retrofit could only support those objects which are supported by SCWB. Detail information can be found in the supported object list.

For every workbench (repository) request, Retrofit will check transport request object list and report non-supported objects (transport-critical objects) via the error messages in column “Critical Retrofit”.

We have created function group ZDOLORES1 in Case 1 and we retrofitted it to SS7:100 using autoimport option, changes were saved in TR SS7K900451.

We are going to release this TR from the I* task list.

Note: when releasing the TR you can get an error saying that the package of this TR does not exists in SS7:100, create it and assign to transport layer ZSS7, at least I was not able to see the place where to change the package for this TR...

 Then make a modification to this function group in the SS7:100 system and save the changes in TR1:

This will create a lock entry in /TMWFLOW/LOCKMON too.

Now we will go to SMM:100 to make also changes to this function group. We save the change to TR2, release the task and later release the TR2 from the M*:

As the lock exists we will get the Yellow triangle in the Start Retro entry:


I release the TR in SMM:100 containing this change.

Call now start retrofit from the M* task list:

See that the lock is detected and Critical Retrofit is having a YELLOW triangle.

Go to see the objects:

Compare Source and Target System:

In the FG in SS7:100 I cannot see the CHANGES!! Text because the TR1 is not released.

I retrofit TR2 to TR1,  where the changes were done initially in the retrofit system:

Select “Retrofit for all Categories”. The following pop up will appear:

The mechanism of SCWB merge editor is to calculate the “delta” changes from the source transport request, and try to manipulate them in the target system’s same object. This requires the target system’s object to have the same version as the original version in the source system before the change is performed. Only in this way we can ensure all those “delta” can be handled correctly. Otherwise you might get a message saying not all changes can be copied.

Check the logs.

Changes arrived to SS7:100:

3. Manual Retrofit

If a conflict (lock entry) exists and the object is not supported by SCWB/BC-Set, then we need to use Manual retrofit.

Objects with conflicts which have no support tool:


The objects included in the TR released in DV1 have been changed in the retrofit system DV2 so there is a lock entry for them in the Solman system.

In this case you cannot use retrofit tool to get your changes in the retrofit system. You need to do it manually.

  • Create a customizing TR1 from the I* task list for project I02055_RE2 and save here a new entry for view V_CLG in the retrofit system SS7:100

An entry is written in Solman in /n/tmwflow/lockmon:

I go to see if this view supports BC-Set tool or not: /nSOBJ

This view is not supporting BC-Set tool.

  • Create TR2 in SMM:100 and modify the same entry for the view V_CLG. Release the task and then the TR2 from the M* task list.
  • Create a new TR3 in SS7:100 or used the initial TR1 to retrofit the changes MANUALLY.
  • Now when we start the retrofit the line has red bullet. Select “Additional Functions”-> Retrofit Manual


The list of workbench object not supported byt SCWB can be found in

4. Retrofit for mixed types of objects

When you have objects in the transport request with different categories please always Select “Retrofit for all Categories”

The objects that allows autoimport will be retrofitted via TOC and the objects already changed in the retrofit system will be retrofitted using tools like BC Set and SCWB.

Start Retrofit – Other functions



  • Display Logs: This will display the retrofit logs.
  • Object List of Transport Request: This will display the list of the objects included in the transport request and the retrofit options.
  • Consistency check: System will check whether your selected request obeys release sequence to perform the Retrofit, and also whether there is a target request entered for it.
  • Reject Retrofit: In case you feel the change is not needed for the target system, there is another button “Change Retrofit Status” which can set the status to “Retrofit Rejected”.
  • Place Transport in Import Buffer Again: If the retrofit was not completed successfully, for example, because an auto import option reported errors, you can choose "Place Transport in Import Buffer Again". You are now able to repeat the retrofit process for auto-import objects. Note that you cannot use this function for manual retrofits.
  • Create Retrofit Data Again: report RETRO_SERVICE_CREATE_RFIT_DATA: This will create the retrofit data again for the selected transport request. Note that the newest version of the relevant objects from the database will be used, this version could not be the same that the version of the objects when the original transport request was released. 


If Development Systems, DV1 and DV2 retrofit, are in Different Domains, ensure that you create a domain link between the two domains. If transport groups are also different you need to forward the created TOC to the retrofit system.

The retrofit for NON-ABAP (e.g. Java, Business Objects, HANA Content) is not supported at the moment (SAP Solution Manager 7.1 SP13).

For Business Warehouse objects: In spro activity "Define Values for Retrofit Scenarios" you can decide which BW objects need to be retrofitted always manually.


Authorization object

Super user authorization object /TMWFLOW/A

Super user is allowed to:

  • Perform all categories at once

  • Ignore sequence violations

  • Place Transport in Import Buffer Again

  • Create Retrofit Data Again

Retrofit tables 7.2

As soon as the retrofit data is generated when the source request is released, retrofit data will be entered in these tables:

  • /TMWFLOW/RFITCT is the Retrofit header table, it contains the information about source system, source request, target system and target request. Also it has the “TR _ERROR” which determines how it will be Retrofitted.

As a summary we can say that an object of a transport request can have these different categories:

      • TR_ERROR= 2:  It can be an auto import object (Retrofit Category 2, color green): The object has not been touched in the Retrofit system and has no conflict in the Retrofit system
      • TR_ERROR= 1: It can be a retrofit object (Retrofit Category 1, color yellow): The object has been touched in the Retrofit system or has a conflict in the Retrofit system, but there is a tool supporting the Retrofit (SCWB or BC-Set)
      • TR_ERROR= 4: It can be a manual object (Retrofit Category 4, color red): Object does not fit into the above categories and has to be Retrofitted manually
      • Other TR_ERROR values indicates that the transport request contains objects with different categories, Enhanced Retrofit is able to determine the correct retrofit way automatically by executing “Retrofit for all Categories”.

In this table you will see also if the retrofit is done or not in RETROFIT_DONE .

  • /TMWFLOW/RTROBJT is the table to store the object level information from the source request.
  • /TMWFLOW/TOCASNT is the table to store automatic ToC created for the source request in the case that objects get category 2, auto import.

F means Request imported successfully into all systems


Other important tables:

  • /TMWFLOW/TRORD_N: Central Table ChaRM Transports
  • /TMWFLOW/LOCKPRN: CSOL table for Workbench requests
  • /TMWFLOW/LOCKPCN: CSOL table for Customizing requests
  • /TMWFLOW/PROJMAN: CTS-Project Relations
  • AIC_RELEASE_CYCL: Relation between Cycle, Tasklist and CRM-Document, Branch


Related Content

Related Documentation


Related Notes

Managed systems:

1703391 - General note for managed systems in Change Management

1468044 -  Retrofit extensions - for managed systems


SAP Solution Manager system:

1175098 - Change Request Management retrofit configuration

1818628 - Retrofit Conflict Calculation

2004134 - CSOL - RFC from managed system to Solution Manager system

1584174 - CSOL: RFC to client 000 is required for activation in case of problems seeing all clients

1175098 - Change Request Management retrofit configuration

1484719 - Retrofit - Retrofit failed because of RFC- Destination

2190740 - How to analyze errors when using Enhanced Retrofit functionality



  • No labels