Product category/multiple backends (BBP_DET_LOGSYS)

[Former Member]

Hello SRM gurus,

At this moment we’re upgrading from SRM2.0 to SRM5.0 in the Classic Scenario. The Ramp-Up system is on SP4 (SAPKIBKT04) and kernel release 700 (SP 61).

We’re having a problem with product categories in multiple backend systems. This is defined in SPRO >> SRM >> SRM Server >> Technical Basic Settings >> Define backend system for product category. This table (BBP_DET_LOGSYS) has only three fields: category ID, Source system and Target system (with the first two fields being the key fields).

The current SRM environment at our client is used globally with approximately 17 backends. Instaed of replicating the product categories form each backend they have maintain the Product cateories locally in

the SRM system(via transaction COMM_HIERARCHY) and are used throughout the world. This means the source system for the product categories is always SRM but the target systems are different.

However, given the definition of table BBP_DET_LOGSYS it isn’t possible to maintain this data. For example:

Product category 001

Source system SRM1

Target systems BCKEND1 and BCKEND2

Making the first entry (001/SRM1/BCKEND1) isn’t a problem. However, the second entry cannot be made, as that combination of key fields already exists.Could you advise how to deal with this situation? We’ve searched for

applicable notes but haven’t found anything useful.

BR

Bharat M

[Former Member]

Hi,

I think maintaining multiple entries should be fine if its a one time configuration rather than enhancing the std structure!

BR,

Disha.

Pls reward points for helpful answers.

[Former Member]

HI

I have understood your problem and the solution is to modify the structure and make Back end system also as a primary key field. but in that case you need to add one z fiedl as all the fields cannot be primary field .

Second optionis to change the seqence of the fields in the table BBP_DET_LOGSYS where

first field is Category_ID

SEcond - LOgsys_source

third - Los_sys

then change the third field to second and make the backend field as primary key to get a unique option

Third option is

To create different names for the source logical systems and make one to one corresponding name for both logical system name for backend and source,

means 17 source systems names and 17 backend system name

regards,

Nimish Sheth

pls reward points for helpful answers.

[Former Member]

Hi Nimesh,

Good attempt but the problem here is table BBP_DET_LOGSYS also contains the fields Client and Category (these are not visible in the customizing transaction in spro) & they are also a primary key field.The field Category contain the GUID for a product category. These two fields form the key for this table (together with Category ID and Source System).

Actually we have raised this issue to SAP as well & their reply is very strange. They reproduce this on their test system & found that it is possible to to

have two different target systems for the same product category and source system. For example;

Product Category Source System Target System

00105 QZACLNT100 E5UCLNT300

00105 QZACLNT100 QZ8CLNT100

But when i checked the GUID for this product category in sap test system it was not same.This explains why it is seemingly possible to maintain two entries like the one shown above in customizing.

Now my question here how it is possible to have two different GUID for one prodcut category which has been replicated from the same backend i.e QZACLNT100.

BR

Bharat M