Logical System Level vs Logical System Group level Configuration
In SAP GTS, when it comes to configuration especially mapping of elements like Organization Structure, Partner Structure etc. from feeder system to SAP GTS,there are two options available:
1) Mapping at feeder system level
2) Mapping at feeder system group level
This blog focuses on these two options and explores pros and cons of each.
In principle, SAP GTS can be connected to multiple feeder system and this is where feeder system group level configuration comes handy to reduce configuration and master data required to be setup in GTS.
Even if we have one feeder system and one GTS system, it is mandatory to create logical system group in GTS because all the master data elements from feeder system like material master, business partner etc. are setup at logical system group level in GTS. Now in such scenario, we have 2 options to do configuration i.e. at feeder system level or feeder system group level. We will be exploring more on each options to see which one is more beneficial to go with.
Logically speaking, if we have only one feeder system and one GTS system, we should go with mapping at feeder system level to keep it simple and many a times, in such scenarios, the naming convention used for feeder system group is same as feeder system (i.e. Logical system group name = logical system name). Although this keeps the configuration more simple and easy to understand, but it has downside as well which we will explore now.
In typical implementations, we have system landscape like development system, quality system and Production system (Live system). In some cases we have staging system as well which is used for regression testing. These non-production systems gets refreshed time to time and this is where the main impact of the two configurations can be seen.
If feeder system level mapping is implemented, below are the typical issues observed:
1. Transport of new Company Code or Plant. In this case, either you have to include configuration of each logical system (as per system landscape) in development box and transport it all the way to Production system. This means that production system always has some redundant entries of non-prod system, else you do a direct configuration in each system.
2. Whenever there is a refresh of non-prod system from production system and if you have not used a common logical system group, you need to re-transfer all your master data again to GTS from ECC.
3. After system refresh, basis team does BDLS and it is most likely to fail for table /SAPSLL/TCOOVS because it will already have some entries with new logical system name and it requires manual correction of these entries before BDLS can be executed for this table.
All the above issues can simply be avoided by doing configuration at feeder system group level and using a common logical system group in all the landscape. This configuration provides following benefits:
1. Create transport without any duplicate entries and transport it all the way to production system without a need of direct configuration and avoids redundant data in production system
2. Non prod system refresh are really smooth and does not require any manual intervention
3. No need to retransfer master data from ECC to GTS upon system refresh.
4. Initial configuration is simple too and easy to transport
In case you are on feeder system level configuration and want to move to feeder system group level configuration this is how you can proceed to make sure that this transition is really smooth:
1. Create a TR to include configuration at feeder system group level.
2. Transport the configuration to production system. Please note that both the configurations can coexist. System first checks configuration at feeder system level and if not found, it goes to feeder system group level.
3. Once feeder system group level configuration is transported, you can subsequently create another transport to remove configuration at feeder system level and move this TR to production. This will ensure that the transition is really smooth.
4. If you are also changing logical system group to make it in sync in all the landscape, make sure that you retain or use logical system group of your production system so that master data already in production system is not impacted by this transition.
From Production system or Business perspective, this transition might not add too much value, but from support perspective and system maintenance perspective, this will definitely add value and make the job lot easier, simpler and effective.