Здравствуйте, на текущий момент у нас на боевой системе CRM имеется иерархия продуктов, которая была создана при копировании манданта crd200 на crq300. В связи с этим изменить иерархию продуктов нельзя, т.к. в поле LOGSYS (например, таблица COMM_CATEGORYT) стоит CRDCLNT200, что не относится к текущей продуктивной систему (сообщение иерархию ZUBRR можно изменять только в исходной системе CRDCLNT200).
Что можно сделать?

поменять в исходной системе и перекачать наверное..

Вообще, копирование манданта в crm очень стремное занятие - проблем не оберешься, мы через это прошли. Если уж так случилось, то необходимо произвести процедуру смены логической системы при помощи тр. BDLS (см. ноту 0121163 - BDLS: Converting logical system names). В тр. необходимо указать старую лог. систему, так понимаю что это CRDCLNT200, и новую, которая присвоена вашему манданту в crq300. Тр. сама изменит во всех нужных таблицах запись одной лог. системы на другу.
P.S. Рекоммендую предварительно прогнать тр. в тестовом режиме.

Спасибо попробую.

В ноте 121163 есть такая фраза "After successfully completing the conversion, synchronize the table buffers in the server."
А как выполнить данную синхронизацию?

На вскидку какого-то спец инструмента для синхронизации наши админы не сказали. Самый простой вариант - перезагрузить sap. Нормально настроенная система это сама должна сделать.

Посмотрите ноты 36283 и 14754:

Symptom
Introductory remarks:

Buffer synchronization makes sure that application servers are informed about changes to buffered tables or other buffered objects that were made on other application servers or using transport tools. For technical realization, the change operations are stored in Table DDLOG. On each application server, a process is run periodically to read the current change requests from Table DDLOG and inform the local buffers.


Therefore buffer synchronization is carried out at a delay. The period is controlled using profile parameter rdisp/bufreftime. For performance reasons, the value should never be set to less than 60 seconds. If modifications to tables need to be apparent on the application servers in a shorter period of time, those tables must either not be buffered, or BYPASSING BUFFER has to be added to critical read operations.


Central systems are a special case. Here, changes to buffered objects can only be made using transport tools. For this reason, it does not make sense to log changes to the application server itself in table DDLOG. To prevent this, the profile parameter rdisp/bufrefmode in the central system (and only there) must contain the value "sendoff,exeauto". See also Note 14754.


There are general and specific error symptoms.


General error symptoms

Modifications to table contents are apparently not carried out.
Access to buffered objects yield different results on different application servers.

Specific error symptoms

Error message BY4 in the syslog: SQL error x occurred during INSERT DDLOG.


Reason and Prerequisites
According to the buffer synchronization mechanism, there are two problem zones: the writing to table DDLOG and the periodic buffer invalidation.


Known causes

1. There is more than one application server and on (at least) one of them profile parameter rdisp/bufrefmode is set to "sendoff,exeauto".
2. INSERT DDLOG produces a database error.
3. For database platforms Oracle and SAP DB only: The R/3 system was built incorrectly. Instead of using R/3 tools, the system was created using a database copy from another R/3 system and, before start-up, Table DDLOG was not checked to make sure that it did not contain any records. In such a case, buffer invalidation is generally not carried out.
4. Only for database platform DB2: For testing reasons, the date was set to a future date on the application server. This means that DDLOG entries are written with a time stamp in the future. In this case, there is actually no buffer invalidation.
Solution
Program RSDBBUFF is available as an analysis tool. It can be used, for example, to view the DDLOG and buffer contents.


re. cause 1: On all application servers (including the central instance!), profile parameter rdisp/bufrefmode must be set to "sendon ,exeauto".


re. cause 2: The database error must be corrected. In the case of error message ORA-2289, see Note 185821.


re. cause 3: All application servers must be stopped. Then all records in the table DDLOG must be deleted using the appropriate database tool (in Oracle, for example, use the command TRUNCATE TABLE DDLOG) before the R/3 system can start operating again.


re cause 4: The DDLOG records with time stamps that are in the future must be deleted.

===================================

Symptom
Lack of knowledge on profile parameters of buffer synchronization. The general functioning of buffer synchronization is explained in Note 36283 and is thus assumed to be known.

Additional key words
rdisp/bufrefmode, rdisp/bufreftime

Cause and prerequisites
Lack of documentation or unclear documentation.

Solution
Parameter rdisp/bufrefmode controls whether DDLOG records are written (sendon/sendoff) and whether periodic buffer invalidation is carried out (exeauto/exeoff).


Setting in a central system (one application server only):

rdisp/bufrefmode = sendoff,exeauto


Setting in a distributed system:

rdisp/bufrefmode = sendon,exeauto (on ALL instances!)


Buffer invalidation may be turned off in exceptional cases and with exact knowledge of the consequences only. Otherwise, data inconsistencies may occur.


Parameter rdisp/bufreftime defines the intervals in which buffer invalidation is carried out. The unit is seconds, the recommended value is 120. Unfortunately, the SAP default value meets this recommendation as from release 4.6D only.