Skip to Content
Author's profile photo Frank Jungmann

Some Hints to Status Dependent Import Control

Status dependent import control is a part of the flexible ChaRM. It was introduced with Solman 7.1 Sp5.

The functionality it offers is to perform import only to transports that belong to specific Change document that has a specific status.

So it changes the import behavior of the usually used IMPORT_PROJECT_ALL as it performs an import subset of all selected Transports (relevant because of their corresponding Change documents status). The import method of this subset is IMPORT_ALL again but in comparison to the usual behavior of IMPORT_PROJECT_ALL it offers the possibility to have some TRs stay in buffer.

As this means what you have tested is not necessarily the same as what you will be going to transport it’s absolutely mandatory to switch on the Downgrade Protection (DGP). Technically DGP is no prerequisite for status dependent Import, but logically it is. So please always switch on DGP first before you start to use status dependent import.

You can activate the DGP here in SPRO:


Choose “Globally Activate Cross-System Object Lock and Downgrade Protection” in the popup.

Then Activate DGP here:


Please be aware that Cross-System Object Locking is active, this is prerequisite for DGP activation.

Now let’s switch to the customizing of status dependant Import. After DGP was enabled you can start to setup this here:


As said above, what you want to reach is to have transports only being part of an import for the project if the corresponding Change document has a certain status.

e.g. you want to make sure Urgent Changes Transports will only be consolidated and part of the project import if the status is “Authorized for production”.

btw. this setting makes perfect sense and is highly recommended as with this setting we can avoid that for Urgent Changes the consolidation Import with the project happens earlier than the original transport which normally is triggered in dialog directly from the Urgent Change document. So in this scenario status dependant import control even improves the standard behavior. 🙂

But as you also want to make sure that the consolidation happens after the transport was triggered in dialog from the Urgent correction you must not forget to also maintain the status of the urgent change that comes in sequence after “Authorized for production”.

In Standard SMHF Urgent change process flow that’s: “Imported into Production”; “confirmed”; “completed”.

It’s crucial that you do not forget to maintain these extra values, as if not available the Urgent change consolidation with the project import will never happen and the transports that are waiting for re-import will be staying in the buffer for ever!

You can maintain status values for transaction types in the customizing for a combination of Project, System, Client and  System Role.

So you could setup the status dependant import e.g. for a specific project only. Or make a difference in system role for the behavior of import to QAS system in comparison to PRD system.

If you want to set it up in a generic way, meaning it should be available for all projects, systems and clients, you can use wildcards “*”


only the system role has to be specified. (in this case p = production)

Going further you can then maintain the transaction types and status values for that combination of project, system, client and system role were you activated the “Import by status of selected elements”.

For our example that looks like this:



To get the full picture of all standard transaction types for status dependant import to production systems it looks like this:


So it also includes into the import all Transports form Normal changes (SMMJ) in status E0009 = “successfully tested” and Defect Correction (SMTM) in status E0009 = “confirmed”.

Withe the customizing including theses status values for the standard transaction types you ensure you do not forget consolidation for Urgent changes nor the corrections from defects.

Of course you can also use that customizing for you own newly created status in the Z or Y namespace.

Good luck!

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Esteban Hartzstein
      Esteban Hartzstein

      Hi Frank,

      Thanks for your article.  We have came across with the problem that some Urgente modifications transport keep in the Transport Queue for one cycle to the next.  Then we realized that it happens that the customizing of the table in production did not take into consideration the status completed and confirmed.  So, we have a bunch of OTs in transport queue.

      Then we are a bit afraid of what would be the behavior of we modify the customizing and put those status in the Import Strategy table.  Those OTs will be selected to be imported in the next cycle, causing a downgrade in production.

      We want to clean up those OTs from the transport queue.  Which is your recomendation to do it correctly.

      I appreciate your comments.


      Esteban Hartzstein

      Author's profile photo Frank Jungmann
      Frank Jungmann
      Blog Post Author

      Hello Esteban,


      following best practice the correct behavior would be to import all OTs from the buffer together with the next project import. (like the customizing described in my blog)

      Now in your situation it's a little bit different as the changes are eventually already outdated.

      The main question is, did you touch the same objects again so there is the possibility of a newer version. If that is true CSOL and DGP should have given you a lot of popups and conflicts to cancel. If yes and you canceled all of these you have a high risk of downgrade if you import the OTs into production. If that did not happen you can be sure that no newer version of the objects touched is available and like this it's save to import them into PRD.

      In case you decide not to import but delete the OTs from the buffer you also need to make sure you clean up the CSOL table. So please store the Transports that you deleted and search for the CSOL entries of those Transports and delete them from the Locking table. The same would happen automatically in case you import them via project import, but if you skip that process CSOL has to be cleaned up manually.

      No matter how you proceed to solve the situation, after clean up you should set the correct customizing settings (Completed and confirmed for Urgent) and like this ensure you do not run into this situation again.


      Best regards,