Logical system name to be updated while client copy--URGENT HELP REQUIRED

[Former Member]

Hello All,

I have a query regarding the "Logical System name" updation during Client copy.

When we make a client copy(SRM Masters) for the Production system(SRM),the Old Logical system name for backend(which is attached to the SRM masters) gets copied to the new Client (Copy) which needs to be updated.

There is a std transaction BDLS through whcih w e can change the current Logical system name to a new one but this seems to work fine for System copy but not for Client copy.

So when i make a client copy of SRM masters for Production system,is there any other std way wherein i can change the "Logical system name " for the backend or do i have to write a CUSTOM program wherein entries for the Backend Logical system name in tables like CRMMLSGUID will be updated with the new Logical system name?

Any help on this is appreciated.

Thanks & Regards,

Disha.

[Former Member]

Hi Disha,

from my customer site, I set "same" logical system name for DEV/QAS and PRD system.

for example,

logical system name for SRM DEV/QAS and PRD = SRM

logical system name for R/3 DEV/QAS and PRD = R3

But be carefully if you went to change your "exist" in <SCC4> insert of <BDLS>.

best regards,

Dean

[Former Member]

Hi Dean,

Can you pls elaborate what did u mean by --"But be carefully if you went to change your "exist" in <SCC4> insert of <BDLS>."?

regards,

Disha.

[Former Member]

Hi,

Anybody..anymore thoughts on this??

Regards,

Disha.

[Former Member]

Hi Disha,

run BDLS twice in SRM:

- to change old SRM LS to new SRM LS

- to change old R/3 LS to new R/3 LS

And same in connected R/3 system (if also copied).

For table CRMMLSGUID, delete its content in SE14 (activate & adjust --> delete data): entries have incorrect GUIDS, and will be re-created with the first replication process.

Otherwise the replication will stop because GUIDs are different between SRM and R/3.

For all steps involved in a client copy, look at the corresponding documentation "Transporting EBP system" we already discussed about in this forum.

Rgds

Christophe

[Former Member]

Hi All,

We checked up with SAP for manual deletion of entries from the table CRMMLSGUID but they recommended that this may cause inconsistencies in the system which SAP is not responsible for.

But now we have planned a different stategy wherin we shall be carrying out the Master data Load again in SRM(new client copy) but not in R/3(since R/3 data is huge!).

Our main concern was that we didn't wnat to upload the masters again in R/3 and if by any means we could avoid the master upload in SRM too then such a method would be suitable for us..hence this query raised...But thanks a ton to all the members for their valuable inputs to our queries.

Regards,

Disha.

[Former Member]

Hi Disha,

In your initial question, you say that BDLS is ok for system copy, but not for client copy.

I disagree: BDLS is also used for client copy.

So first execute BDLS.

If the SRM copy (from Prod to Dev) is not linked to a R/3 copy (fro prod to dev), then in that case the master data in not aligned anymore and you need to delete/replicate it again.

But if a R/3 copy is done in parallel, then BDLS will solve your issue.

BDLS will scan all tables using the "Logical System" domain.

CRMMLSGUID is part of them, so the field CRMMLSGUID-R3_LOGSYS will be adapted as well.

The GUID will be incorrect: in that case I delete the entry and let the system re-create it: I did this for 2 customers after system and client copies and it worked well.

Rgds

Christophe

[Former Member]

Hi Christophe,

But we have been recommended that the manual deletion for GUID is not to be done...but then you mean to say that this method had been adopted by some of ur customers and it worked fine for them??

Regards,

Disha.

[Former Member]

Disha,

Yes, I did it twice and it worked fine.

The R/3 GUID is sent by the OLTP system (R/3) in R/3 message header.

SRM checks this GUID in CRMMLSGUID table.

If is not the same one, then replication process fails.

The only solution I found was to delete this entry. It is automatically recreated with the new GUID with the next replication, with FM CRMT_OLTP_LOGSYS1, called in BAPI_CRM_SAVE.

Look at OSS note 588701 & 765018 for deletion of CRMMLSGUID.

The issue is exactly ours: around system/client copy.

In an CRM environment, this is more critical, because we make a huge use of the middleware. But in our case, and especially after system/client copies, we can go, even if SAP does not guaranty anything, because we don't care about "old" replicated data (I don't care about old BDOCs, that should even be deleted after processing).

We have to take some risks sometimes...

Rgds

Christophe

[Former Member]

Hi Disha,

can you give us a feedback on this URGENT HELP REQUIRED ?

Sundeep has got similar issue on CRMMLSGUID.

Rgds

Christophe

PS: please reward points for helpfull answers

[samar_jose2]

Hi Guy's We have same issue. And seems like to change logical system, Guid etc should be okay. However what happens to the transactional data. As in our case the test client is refreshed every 3 weeks. In this case will we loose the linkage to the trn data?.Please can anyone shed some light.

Rgds

Samar

[Former Member]

Hi BDLS converts the logical backend system name in tables. There are some references to logical backend system that doesn't get updated. There are few areas to look at :

Attributes

Logical back end system in SPRO

these are to the best of my knowledge manual tasks but there are not to many of them that need to be done. You will also have to check your idocs, distribution models etc...

All in all the manual tasks should not really take more than an hour or two after a client copy.

I don't know if you can write a program that will do these for you.

Sorry but as far as I know after a client copy there is always going to be some manual tasks to complete.

Tracey

[Former Member]

Hi Tracey,

Thanks for the quick response...Even i feel that BDLS should work for our problem of "Logical System" but just wanted to know the opinions of the Experts in this forum who have already implemented SRM and might have come across this issue....

Regards,

Disha.