Distribution of FTOs & LUs to downstream systems

[Former Member]

Hi -

I'm interested in implementing the model which allows the distribution of Foreign Trade Organisations & Legal Units to downstream test and productive systems.

The documentation is clear that the "group of logical systems containing the logical system of the source system has to be a separate group and cannot be identical to the group of other feeder systems."

I'm trying to understand if all GTS logical systems should be contained in the same group of logical systems as the "source system" or if another grouping is expected.

Additionally, the documentation tends to implicitly infer that the model should have a distribution model from only one source...ie from development to the rest of the environments (QA & Prod). Not all implementations allow this type of model. Validated models only allow Dev -> QA -> Prod; thus the source system would have to rotate from Dev to QA to fit a validated model.

Can anyone advise as to how the GTS clients (non feeder systems) should be set up to allow this functionality?

[Former Member · Accepted solution]

Hi Jon:

No problem, use the same group as logical systems across the landscape. However, identification of particular instance is identified by client. This is Simple and easy way. You don't have any problems.

Thanks

Chakri

[Former Member · Accepted solution]

Hi Chakri -

Just want to ensure I understand what you are saying:

Stage all the GTS logical systems into one logical group. And with such a setup, Dev could distribute to QA & QA could distribute to Prod.

Can you confirm the above?

I had considered the above, but wasn't sure if there was any background association between the Source & Target systems that would break when the source system was changed. Was reluctant to test this out in a validated environment.

thanks,

Jon

[Former Member]

Believe I need to reframe the question & finding it a bit difficult; as it involves relationships which I don't really understand.

Have known about the mechanism to move for quite some time, just haven't had a non controlled environment to test.

The model that I'm looking at through validated process does not allow any movements from Dev directly to Prod. They must be validated separately in QA & then moved to Prod.

When I look at a BP in the system via SE16, there are some evident elements which raise my concern about just doing it.....namely 3 data elements:

MANDT - Client (Key field)

BU Partner - Business Partner Number (key field)

BU_PARTNER_GUID - Business Partner GUID

Which may suggest that the system tracks/regulates by these references. IF the Distribute process merely recreates BPs in the down stream system based upon External Number and Address detail only, then this may not be a concern.

If however, it actually passes relationships, then that would be a totally different story. I would have one distribution model/process from Dev to QA & a totally different distribution model/process from QA to Prod & don't want referential integrity concerns to deal with.

The idea is to reduce manual work & possible human error in the Prod environment....it should merely be a cross validation exercise in Prod if the process is followed.

One idea which supports the existing documentation was presented some time back....the inclusion of all GTS systems in the system group; across all envrironments. Are there other options? Could I have one GTS system Group including Dev & QA and another system group including QA & Prod for example. The documentation only states that the system group must be separate from the feeder system group.

Thanks for the replies.

Edited by: Jon Sledge on May 13, 2009 5:42 PM

[Former Member]

This question is specific to Distribution of FTOs & LUs to downstream systems; independent/exclusive of feeder system settings.

[Former Member]

Hi Jon,

If you want to distribute your FTO and legal unit to dwonstream i.e to other subsequent GTS systems using transaction /SAPSLL/BP_DIST_FTO for foreign trade organizations and transaction /SAPSLL/BP_DIST_FTVB for your legal units.

Here you have to just mention the RFC destination so you can treansfer from Dev to QA and from QA to Production.

Kind Regards,

Sameer

[Former Member]

Hey Jon,

If your question is to transfer the FTOs and LUs from development to QA and again development to Production instead of re-creating them on each system, then what ever Sameer suggested was correct. You can use those two transactions in the source system to send these Org Elements to target systems.

More easy way is: in IMG you will find a config., path u2018Transport Foreign Trade Organizations to subsequent systemsu2019 and Transport Legal Units to subsequent systems u2019under u2018Organizational Structureu2019 both will be used for the same purpose.

Hope this helps.

[andreas_lied]

Hi Jon,

I am not quite sure to have understood Your specific problem. So let me try to point out some things that might meet your question.

GTS identifies the backend systems by their specific logicval system name, which is laid down in the backend systems resp. client in table T000.

For systems which use a common master data basis (partners and product masters) there is a chance to group them together. So if backend system A and B have a common master data basis, they can both be assigned a common system group G in GTS. This helps to have a common customer master only once in GTS and not the same master once for each logical system. The documents will be held per logical system anyway.

So there is customizing, mapping settings, in GTS that you can design depending on logical system or group of logical systems. If you decide to define tha mapping depending on each logical system name, you should care to set up the customizing in your GTS-development system 3 times: one for the logical system <backend development>, one for the logical system <backend test> and one for <backend production>. You might care to transport only the last settings to GTS-production.

Another possibility is to transport and run a conversion report, whose name I forgot, in the target system which sets the logical system names to a new value throughout a lot of tables on the system.

If You want to avoid this, you might set up a log. system group consisting of <backend development>, <backend test> and <backend production> and set the customizing using this group of logical systems.

If you are aiming on grouping several logical systems together in one system group within the production level you should be careful: do these systems really not overlap in the use of company codes, plants, master data, document types, item categories a.s.o.and if they do: do they mean identical things with identical keys?

I hope there was at least a bit of information in my answer helpful for you.

Regards,

Andreas

Edited by: Andreas Lied on Feb 8, 2008 2:16 PM

Edited by: Andreas Lied on Feb 8, 2008 2:18 PM

[Former Member]

Good day Andreas.

For the Logical System rename one could use BDLS.

We have different Logical System Groups, for each of our clients. Are aware of a tool that converts GRVSY (Logical System Group) for the tables that use this field?

Pleae advise.

Regards

Anton Sissing