PLEASE HELP ME TO FIND THE SOLUTION REGARDING "LOGICAL SYSTEM CHANGED"

[Former Member]

HAI EVERYBODY,

PLEASE HELP ME TO FIND THE SOLUTION REGARDING "LOGICAL SYSTEM CHANGED" during the material master replication by using middleware parameters.

step1 : i have taken SRM client 810 and named it as CHINNISRM

step2 : i have taken r3 client 810 and named it as CHINNIR3

step3: During material master replication i maintained tables like crmconsum,crmrfcpar,crmparoltp in r3 and smofparsfa in srm client and filtered the objects and loaded the objects through r3ac3,r3ac1,r3as.

step4 : And later i have checked in r3 queues to activate the objects,but i have seen a message like "LOGICAL SYSTEM CHANGED:SEE 588701".according to the oss instructions i have checked in CRMPRLS table in se16 in R3 .there i found out there is one logical client named with T90CLNT810.

oss :588701

Solution

There are different cases in which different forms of processing are

required or where several options exist:

- The logical system name of an R/3 Backend client was changed in

current operation. In this case, the data hangs in the outbound

queues of the R/3 Backend system as specified under point 1 of

the symptom. In this case, the logical system name must be

changed back to the original value. Then the outbound queues

can be reactivated. If no data was transferred to the EBP/CRM

server before the change, also a correctioin of the check table

is possible.

- The same logical system name was used again in a new client of

an R/3 Backend system that was linked to the EBP/CRM server. In

this case, the data is in the inbound queue of the EBP/CRM

server with the exception GUID_FOR_LOGSYS_CHANGED. In this

case, the queue entries which have status SYSFAIL must be rejected, however, not the entire queues. If the new client of the R/3 Backend system you have linked has exactly the same

data as the old client and if it is meant to replace the old

client (that is, this was deactivated), also a correction of

the check tables is possible. In this case, the inbound queues

can be reactivated after the correction.

oss:765018

1. If the situation in your system corresponds to the situation described

under "Reason and Prerequisites" and if symptom 1 occurs, you can

delete the table entry from table CRMPRLS table (there is just one

entry). Since there is no maintenance dialog for this table and you

cannot maintain it using transaction SE16, you must use a report to

delete it. This report is attached to this note as correction

instructions.

Create the report ZZ_DELETE_CRMPRLS in your system and copy the source

code from the correction instructions. You cannot implement this

source code using transaction SNOTE.

You can use the report in every plug-in or plug-in basis system, even

if it is not specified in the validity section.

After you have run the report, you can trigger existing queues again

in transaction SMQ1.

2. If the situation in your system corresponds to the situation described

under "Reason and prerequisite" and if symptom 2 occurs, you can

delete the entry from table CRMMLSGUID (there is just one entry).

Since there is no maintenance entry for this table and you cannot

maintain it using transaction SE16, you must use a report to delete

it. This report is attached to this note as correction instructions.

If they do not yet exist, add the following messages to message class SMOF in your logon language:

Message Message short text

303 User &1 is not allowed to change table &2.

304 User &1 IS not allowed to display table &2.

305 Logical system &1 was not found in table &2.

306 System error! The current client was not

found in table T000.

Create the report ZZ_DELETE_CRMMLSGUID in your system and copy the

source code from the correction instructions. You cannot implement

this source code using transaction SNOTE.

You can use the report for every release of the CRM system, even if it

is not specified in the validity section. The only exceptions are CRM

releases with Support Package versions that are too low such as CRM

Release 3.0 with Support Package 12.

After you have run the report, you can trigger existing queues again

in transaction SMQ1 of the R/3 back-end system or transaction SMQ2 of

the CRM system.

so what should i do to do the replication.please suggest me .untill and unless i solve my problem i cant move to the further activity.i hope you people can solve my problem.thanks in advance.

thanks and best regards,

n.chakradhar

[pratap_l]

Hi chakradhar,

Did you find a solution to your issue? We are facing a similar issue and looking to figure out how this can be resolved.

BR// 420

[matt]

Please do not post subject in ALL CAPITALS.