Skip to Content

Mapping of Logical Systems


                  This is going to be a simple and clear cut understanding on “Clients and Logical systems & How to handle them in our landscapes”. I have seen many posts in SCN about various transport errors due to logical systems and clients. So, I have decided to make this simple blog which can explain you clearly.

We will start with definitions of Client and Logical Systems.


         A Client is a subset of data in a SAP System. We can secure/deal our data with respect to various Clients in a System. Eg: 100, 200 etc..

         We basically have Clients in both ECC and BW landscapes.

What if both Client no.s are same? Eg : ECC Client is 100 and BW Client is also 100

That’s exactly is the need for Logical Systems in both landscapes. Why a logical system is required? Logical Systems can communicate/identify perfectly between the various systems by pointing to right system with the combination of Logical System and Client No.

Eg: We can connect our one BW system (100) with multiple clients of source system  like 100, 120, 300 etc..

Now we will see the definition of Logical System.


Logical System

                            A logical system is an application system in which the applications work together on a common data basis. In SAP terms, the logical system is a client. 

This means, we have to assign logical systems to Clients to make them to communicate correctly via RFC connection definitions in RSA1–>Source Systems. This has to be done in all your Dev, Qua and Prod systems.

This is what we have to do in SPRO

Logical System 1.JPG

Coming to the key point of this blog

Why we have to convert our logical systems  during transport ?

                      I will give you an instance to make us understand clearly. Let’s say we have created a transport request in Dev BW system and the naming convention of TR is DBWK90001.

                      If we transport the same TR to Qua BW, it will return you an error saying that “Conversion of Logical System Names” has not been done. It basically checks for the source system reference in target systems. That’s the reason we have to define them like below. The same entries can be found in RSLOGSYSMAP table.

Logical System 4.JPG

What has to be maintained in Dev BW System?

Logical System 2.JPG

       If you try to create transport requests directly in Qua system, then the naming convention of TR will be like QBWKXXXXX. The reason Why I am saying this, when you define conversion definitions like above, your DBWK90001 gets imported into Qua by identifying its source system reference with respect to “logical system conversion definitions after the transport”. This will avoid our transport errors due to logical system issues. 🙂


     If you observe the above screen shot, you can see Original Source system as PBW and Target System as DBW and the same scenario for PEC and DEC.

How come original Source system as PBW and Target as DBW? 😕

     Because, The landscape here in my example is D–>Q and D–>P which is a quite standard landscape. My screen shot settings(in Dev) will help in case we want to do reverse transports from Prod to Dev.

What has to be maintained in Prod BW System?

Logical System 3.JPG

Your original source system should be your Dev logical system and target should be Prod logical system. Because you want to transport from Dev to Prod.

Landscapes may vary from company to company. You have to define entries accordingly. Suppose if your landscape is D–>Q–>P, then your original Source system should be Qua Logical System and Target should be Prod Logical System.

What has to be maintained in Qua BW System?

The original source system should be Dev Logical system and target should be Qua Logical System.


               These are very basic settings to be done before starting our BW project. I have just shared my understanding about what is happening internally between the systems. Hope this will help all..

Thank you for reading my blog 🙂

You must be Logged on to comment or reply to a post.
  • Hi suman,

    Once again well explored the very basic settings of system which we usually fail to maintain.Really handy when we  do fresh implementation or pull the data from new SAP server.

    Thanks for sharing.



    • Hello Anshu,

      Really appreciate your response 🙂 . Yeah, we tend to miss some basic settings and start landing up into lot of issues during transports. Thanks a lot for your valuable feedback 🙂



  • Not a bad blog, but my biggest issue is that you are not following good change management practice – most if not all your transports should flow Development to QAS to Production. You should not be creating any transports directly in QAS or Production. This is bad practice and should be discouraged as much as possible.

    Also your explanation of why Logical systems were created is wrong, as I understand it, logical systems were created so the applications could route traffic to the right host. For example if a customer took a copy of Production, but did not change the SID, then it may think it is Production. A Logical system name allows that system, and communicating systems to direct communication to the copy without a SID, System number or Client number change but a Logical System name change. Although changing a Logical System name is not easy either, so it did not quite have the right effect.

    • Hi Chris,

      I did not say that I am creating TRs directly in Target systems. I wanted to show How a TR looks like if you create them in target systems directly. You misunderstood me.

      My blog is to focus on transport errors due to non-conversion of logical systems, but not about all scenarios as you are talking about SIDs etc.. I just taken a simple landscape of D–>Q and D–>P. I have pointed about D->Q–>P as well. It depends on the company network, right? I am not the manager who decides to follow a strategy like D–>Q–>P only. I have tried to explain with whatever I have.

      Even my bottom line concept is also identification/communication of systems in a network with the help of logical systems. What’s wrong in that?



  • Very good blog Suman this is the same mistake i have done in my first implementation and faced lot of problems during transports…good one for those who are doing there First implementation…


    Praveen Kumar.V

    • Hello Praveen,

      Thanks a lot 🙂 After observing so many posts on SCN about TR errors, I have decided to make it. This is one time setting if your landscape is fixed.



  • Hi Suman,

    Ur Blogs always gives clear understanding about the subject knowledge with simple language.

    Infact i personally likes ur each and every blogs & doc.

    Thanks for Sharing…



    • Hi Mahesh,

      I am enlightened by ur valuable words 🙂 🙂 . My intention is to always use simple language to make everybody understand. Thanks for noticing that.



  • Hi Suman,

    Very nice blog! Neat presentation and i liked the way of documentation.

    Keep up the good work!

    Keep sharing new updates! 🙂


    Hari Suseelan

  • Hi Suman,

    I have read your blog. It’s really good. I liked the way you are presented.It will definitely useful to many. 🙂 🙂 ..Keep it up!


    Ganesh Both

    • Hi Nayab hussain ,

      It’s a small understanding. I have explained this in the introduction and definitions. Logical systems are unique. That uniqueness comes with Client Nos. If you observe our tables in the system, you will find MANDT field which is Client-dependent table. You can differentiate records with MANDT field, then the representation of data meaning changes as per Client Nos.



  • Hi Suman,

    Thanks for the detailed explanation.

    Just a clarification:

    If i want to reverse transport source system relevant objects(Data sources, info packages and DTPs) from Production to Development, then do i need to maintain the logical system conversion in both prod or dev environment or is it enough if i maintain in Dev environment.

    Thanks in advance


  • Nice blog Suman! very informative.

    I have a related scenario in my mind to discuss.

    Lets say a single BW Dev client (100) is connected to 2 ECC Dev clients (100 and 120)  

    – In ECC 100, we activate the required Datasources and collect them in TRs.
    – We replicate all the Datasources in BW Dev 100, so all the infoproviders there are connected to the ECC-100 Datasources.
    – After that we changed the connection of the infoproviders from ECC-100 to ECC-120 datasources (So the Source System became ECC Dev 120)

    – Now, we need to transport the the TRs in ECC, should we release the TRs from ECC Dev client 100 or 120?

    Note that the TRs are created in ECC Dev Cleint 100, but as this activity is cross-client, the same TRs are available in both clients 100 and 120.

    • Hi Pooja Singh,

      Thanks for appreciating my blog 🙂 I invite your question. You have to release TRs in ECC Client 100. Always remember, wherever you create TR, you have to release in that client only.



    • Thanks and congratz Suman for this article.

      I’ve a similar doubt as Pooja:

      When I activated the business content, I pointed to the ECC clnt 100, because it automatically logon in ECC (via the RSA1 from BW) and activated the necessary datasources, as saved on the request. I could not do this with ECC clnt 110, although it has data, it can be modified and activate the data sources…

      So I’ve replicated the ECC clnt 110 at the BW system, and it’s ok, recognized the ECC 100 activated datasources (by the way its cross-client). But now I’ve to copy all transformations from the ECC clnt 100 datasource to ECC clnt 110 datasource.

      It’s the best way? I mean, its a common practice? I think it’s strange because in my RSA1 tree I always have 2 transformations (1 from ECC clnt 100 datasource and another to ECC clnt 110 datasource)

      Thanks for all!

      • Hi Leonardo Ribeiro ,

        Thanks for your cheerful comments 🙂 .

        Coming to your query, When your BW system is linked to two ECC Clients, you will have to replicate them separately and create/copy new transformations pointing to Client 110. So you will find two transformations each for all your data targets(first layer or ODS Layer). Subsequently, the data flows to your other layers.



        • Thank you Suman for the reply.

          Only a curiosity: when you activate a cube in business content, and all of its data flow descendent, you point to the development client (100) and after replicate the transformations from datasources for the sandbox client (110) or you point to the sandbox client (110) and activate all data sources manually (login manually  on ecc 100)?

  • Dear Suman,

    Thank you very much for the details you’ve shared above really appreciate.. I have one query .. when both ECC and BW of source system located in same client how can we maintain system conversion ? (any idea) .

    Thanks in advance,


  • Hi Suman,

    This blog is a fantastic example of explaining things in least simplest manner. Thanks for that!!

    I am new to this conversation. I have a doubt and thought I could present it here.

    Can we be able to transport objects/anything requires to be done from one client to another client? All i know so far is that we can transport things from Different systems like Dev to Quality to Prod but will there any scenario at all like we should transport from one client to another client? eg : Client 100 ecc to Client 110 ECC? if at all we could do, why and what could be the reasons for that?

    Sorry if my question is not well written but i hope you catch the overall meaning.

    Thanks, looking forward to your answer.


    • Hi Rohit Ayinaparthy ,

      Really amazed by your wonderful comments 🙂 🙂 . For your doubt, you can simply copy the TRs from one Cline to another by using SCC1 t-code. No transport is required. Because Clients are part of a logical system(single). But if the changes what you make are cross client, then they will appear in next client automatically.