Switching Backend System

[Former Member]

Hello everybody

We've setup SRM 4.0 with SRM Server 5.0 SP08 and CCM 2.0 SP03 on a development/customizing machine called DIM. We connected it to temporary devel./customizing SAP R/3 4.7 backend system called RIS.

Why a temporary devel./customizing backend system? Well, that's a complete other story...

However, we now have to change this connection to the definitive devel./customizing SAP R/3 4.7 backend system.

The problem / question is: after having changed all customizing settings (changed logical and/or RFC destinations everywhere) we are able to replicate DNL_CUST_BASIS3, DNL_CUST_PROD0 but not DNL_CUST_PROD1 from the new backend system.

In R3AM1 it hangs with a yellow status, in SMQ2 it stays in the inbound queue with an error message ":COM_PRODUCT_CUSTMSG:028 R3PRODHIER RISCLNT200".

RISCLNT200 is the logical system name of the old backend system.

Is this error message araising because we already replicated from this (old) backend system? Does anybody out there know this issue? Anyone having a solution to it?

Other question:

Is it somehow possible to wipe out all repliacated data (hierarchies, categories, material, ...) from an SRM server instance without having to reinstall everything from scratch? We're still on development/customizing level and not in production yet!

Thanks in advance for some help. Would be happy to reward with points!

Renaud

EDIT: looking at COMM_HIERARCHY I can see that the product categories were replicated. Any ideas, why I get above error in the inbound queue SMQ2 then?

Message was edited by: Renaud Desarzens

[Former Member · Accepted solution]

Hi Renaud,

when replicating DNL_CUST_PROD1, the system will handle purchasing and product hierarchies differently:

R3MATCLASS

- if one hierarchy is already assigned to purchasing application, middleware updates the existing R3MATCLASS

- otherwise a new one is created and assigned

R3PRODHIER

- if one hierarchy is already assigned to purchasing application, middleware raises an error

- otherwise a new one is created and assigned

So, before replicating DNL_CUST_PROD1 from an another backend, un-assign the R3PRODHIER from product application.

Rgds

Christophe

[Former Member · Accepted solution]

Hi Christophe

Thanks for the tip. Just tried it out, went to COMM_PRAPPLCAT and deleted the entry with application 01 and its assigned hierarchy id (R3PRODHIER). Then went to the pending queue entry in SMQ2 and restarted it.

Now the system returns another error in the inbound queue (SMQ2). It tells me that the hierarchy id R3PRODHIER already exists.

Tried to delete it in COMM_HIERARCHY but of course the system says it may only be maintained in the backend system. This backend system is no more of interest for us. We want to replace it by another one.

What else can I do? Is there a way to wipe out all replicated hierarchies and all products just to be able to redo an initial replication from a new (NOT additional!!!) backend system?

BTW: In the actual R3MATCLASS hierarchy I have some categories from our old backend system and some additional new ones from the new backend system. How can I make sure to have only categories from 1, the new one, backend system?

I'm kind of lost here...

Best regards,

Renaud

[Former Member · Accepted solution]

Hi Renaud,

for R3MATCLASS: if you also unassign the existing hierarchy from purchasing application, the system will create a new one instead of updating existing one.

Hope you won't have the same control on hierarchy ID as for R3PRODHIER.

Else, you will have to delete old hierarchies and their categories: use report COM_HIERARCHY_DELETE_SINGLE:

- non executable in a productive client

- must register the deletion in table comc_pr_tool_reg

This should solve your issue.

Rgds

Christophe

[Former Member · Accepted solution]

Hi Christophe

You're the man! Had the same issue with R3MATCLASS. Thanks to the report COM_HIERARCHY_DELETE_SINGLE I also found the report to delete ALL hierarchies and also another one to delete ALL products I replicated beforehand from our no more valid backend system.

We now were able to replicate DNL_CUST_BASIS0, DNL_CUST_PROD0 and DNL_CUST_PROD1 from our exchanged backend system without a hitch.

Thanks a lot! You really deserve the rewarded points...

Regards,

Renaud

[Former Member · Accepted solution]

Hi Christophe,

I am following your steps but the report (for registering) tells me that no entries have been found for the specified field.

Program name: COM_HIERARCHY_DELETE_SINGLE

Username: TMOS

Exec date: 18.03.2009

I am using se16.

What could I be doing wrong?

T Mos