Single SRM instance with multiple ECC backend

[Former Member]

Guys,

Wondering if you know any of the SAP's clients that have implemented single SRM instance with multiple ECC backend?

My company, Verizon is looking at going with that option and we would like to know if anyone has alreday implemented that model. If so, we would like to get an idea of the challenges involved.

Thank you,

Seyed

[Former Member]

Wow, you guys/girls are amazing. Thanks for sharing all your experiences.

Regards,

Seyed

[Former Member]

In Deploying to our second backend, we ran into pain points in the following areas:

- Vendor Replication (duplicate vendors in both system got different BP in SRM, hence users in backend 2 were confused as to which vendor or bp number to use).

- Product Category replication - Some customizations did not take into account global product category would be duplicated in SRM, one for each backend. In general, anywhere you could have duplicates across backends is an area to pay extra attention to: Plants, PORGS/PGRPS, etc

- Exchange Rate & Currency: SRM always overwrites so basically the last system to replicate from wins. Since Europe was more used to managing exchange rates, they had the added task of maintaining US rates with Mex, CAD etc in their backend. You will need to pick one master backend for currency & exchange rate replication.

PO Document Numbers - Since the source of PO's is SRM, the PO's will be sequential, but when replicated to R/3 there will be gaps. Backend #1 might get PO 1000, backend #2 might get 1002 & 1003 etc. Our business was initially concerned about the "waste" but the added cost of customizing number range for each backend was prohibitive, plus there was a desire to standardize on global number ranges for different doc types.

[former_member183819]

My pain points in one scenario itself on contract

create GOA

distribute to backend

now my OA -Ordering address has been changed in the vendor master.

How do you change the OA in GOA .

as you aware if you make any changes in master data , you need to change in SRM Contract too.

OA and VN vendors are different ..

- GOA - VN -Vendor (12345 - ABCD Tokyo) and OA 2346- ABCD Newdelhi

- Now OA vendor ABCD New Delhi 2345 i have to change in to OA 2346 Chennai - How can i do it ? and it must be reflected in the GOA. i will not change in me22k.

now all PO should go to OA 2346 ABCD Chennai rather than OA ABCD Newdelhi

autobos:- Please try this one.you can..

vendor numbers are different . i dont want to do via BP

muthu

[Former Member]

We had the same problem exactly what you have told. During the idoc posting we changed the logic to pick up oa from VD. If there is anything you found out. Please let me know.

[former_member183819]

Hi

interesting tell me autobots.

hwo did you achieve it

while redistributing the same vendor to ecc and try to pick from vendor master as OA.

since OA concepts are not in SRM right.

Muthu

[Former Member]

Hi,

I know for sure of companies under the referred landscape. They have a global SRM system and mutliple R/3 back ends with another HRMS system. On top of that they have both classic and extended classic deployment in SRM.

The challenges you may face:

01) Middleware replication for basis objects, product categories

02) Country specific customizings

03) HR replication (would be tricky if there is a separate HR system) and a global Org structure and the attributes maintanance. I do not think the HR org structure would really support you for the root level attributes maintanance.

04) Work flow template requirements.

05) Vendor replications

06) Exchange rates, curreincies... all would have to be in sync.

We have implemented this and there are lessons learnt also especially when the HR data is replicated from a separate system. I am sure in your case of multiple R/3 back ends, neither of the systems would have the HR data.

Hope these pointers will help.

DV

[former_member183819]

indeed they are pain points Rao . very good.

master data synchronisation are very challenges across all the systems.

Muthu

[Former Member]

The main challenge will be if anyone of the backend system is shutdown the srm doesn't work for the particular group of users. Refresh of the quality system is also challenging you need to take backup of all the system at the sametime.

Data visibility also important. User should not be able to see the documents belonging to other backend system. Roles should not have any open value like * in the purchase organisation or purchasing group. I have worked with one srm and three backend. Catalogue URL switch also a big challenge.

[mani_sreedharala]

Hello,

Yes, it is possible and we have implemented this scenario at one of our client. Challenges which i see would be the master data extraction and tracking of the follow-on documents during the support period. That's all we faced and it was smooth.

Any other challenges faced by any other SRM SDN colleagues..?

Regards,

Mani

[Former Member]

Mani,

Can you pls. share the name of the client, if that is acceptable?

Thanks,

Seyed