Supply Chain Management Blogs by Members
Learn about SAP SCM software from firsthand experiences of community members. Share your own post and join the conversation about supply chain management.
Showing results for 
Search instead for 
Did you mean: 
Former Member

This is cross posted from

Today I'm going to talk about a topic that could not be further away from the great new functionalities that we have recently seen being talked about in TM 9.0: The TM Organisational Structure.

In SAP TM, one of the pre-requisites to carrying out any process and in some cases perform configuration, is to maintain your company’s Organisational Structure (maintained via transactions PPOCE / PPOME).  As far as I know, SAP does not offer an easy and automated way of transporting the Organisational Structure in its entirety (definition and assignments) from one client to another. I find this very hard to fathom because you need to be able to accurately predict the internal number of all your organisational units throughout your landscape (configuration is done based on this value and authorisations are maintained based on this value). In addition, quite often and as abhorrent as it is, it seems that most people will tediously, manually replicate their organisational structure in all their systems.

Take our landscape for example. We operate a 4tier landscape (that can go up to 5 when we run lengthy projects) - each system having one or more clients. If I was to setup my Organisational Units manually in our current landscape, I would have to do it seven times (once in every client). Multiply that by the number of Organisational units you need to create, factor in an element of human error and you are looking at a problem waiting to happen.

Whilst I have no silver bullet to propose, I will attempt to list out available SAP tools and functionalities that make this process less painful and I'll say it again, help you predict your Organisational Units's internal numbers throughout your landscape.

Basic pre-requisites

The first thing you need to do is setup the number ranges for organisational objects – you’ll need to do this irrespective of which method you use. Setup your leading system (the one where you will create the organisational units) with and internal number range. That same number range should then be created as an external number range in the other target systems.

To change the number ranges call transaction SNRO.  Select object RP_PLAN , then click ranges.  ScreenShot006

Select subgroup 01$$, then click ‘change intervals’.


What you want to do, is to go from something like this in your leading system:  ScreenShot004

To something like this in your target system:


Now that we've got that out of the way, let's look at our options.

Option 1 - via data legacy file and download/upload

Once you have created your Organisational Structure in your leading system, use transaction OOMV to create a data file. What you are doing here is selecting those Organisational Units that you want to capture (write) to a datafile. You can configure the logical filename PD_DATASET or use the physical filename option and be sure to name your file pd_dataset. You can then ask your basis team to download the file for you, or you can use a transaction such as SXDB to download the file to your PC or network drive yourself. Now go in the target system and upload your file. Again, ask your basis team to do so or once again use transaction SXDB to upload it yourself (once again making sure the file will be called pd_dataset). Now use transaction OODT to import the legacy file in your system. This will create a BTCI session for you that you can elect to process immediately or later, as you wish. Once executed, and if there are no errors, you should find your Organisational Units in your target system.

Option 2 – Via (basis - STMS) Transports

This method consists of using the good old (STMS) transport system. To do so execute program RHMOVE30 to select and include in a transport the Organisational Units you want to transport. Use the usual basis methods to release and import that request in other target clients.

Option 3 – Via ALE

This is not covered here, but you need to maintain the basic ALE settings between your sending and receiving systems (logical systems, RFC connections, distribution model, etc..). You need to setup the ALE exchange for ALE message type HRMD_B & HRMD_ABA (either one will do , they both work).


Unfortunately, none of the above mentioned methods allow me to fully transfer an Organisational Unit in its entirety. By that I mean that any of these methods, will happily transfer all the information contained in the ‘Basic Data’ tab but never the information contained in the ‘Org. data’ tab.  ScreenShot013

You can therefore use a tool such as LSMW to upload the remaining data or another method that sounds promising is to extend one of the ALE message types mentioned above so as to include the information contained in the infotype 5561 (this is the information contained in the Org Data tab – you will also find this information in table /SCMB/HRP5561).

In closing

As I said to begin with, this is no silver bullet. The aim here is to guarantee that you Organisational Units’ internal numbers will be identical throughout your landscape. If you are going to use any of the methods above, I suggest you test, test and test them again (I take no responsibility if you overwrite your Organisational Structure). A big negative, is that I found that all these methods are destructive, i.e Transferring an Organisational Unit works well and let's assume that you maintained the 'Org Data' tab information.  If you transfer the same Organisational Unit a second time, it will delete the 'Org. data' tab information in the target system. These methods work well though if you use them to transfer delta changes.

If you know of a standard SAP method or an easier method to do this, then please do let us know. If it does indeed not exist, then SAP, please do deliver this functionality!