SRM - Classic or Extended Classic - both?

[Ray_Rickard]

We are in the process of building a SRM sandbox environment, and the business team are stating that they are expecting to leverage a 'hybrid' approach to implementing the system where they have some functionality from the Classic scenario and some from the Extended Classic. Is this feasible?

We are already live on ECC6EHP8, and we have a PO 7.5 box. For this sandbox environment, we have stood up a single SRM 7.14 server with the db, an AS ABAP and AS Java stack. We created a second client for SUS but have not done any config yet.

From the master guide it appears there are three technical scenarios: Standalone, Classic and Extended classic. Presuming that a hybrid scenario approach is feasible, should I implement the Extended Classic implementation steps?

[Former Member · Accepted solution]

1. Extended classic scenario = If you need to edit PO in SRM and send a read only copy to ECC

Do GR in SRM and send a copy to ECC

2. Classic Scenario = Create PO in SRM and send an editable copy in ECC

Do GR in ECC and can /cannot update back to SRM

Most people implement extended classic since you would want the PO to be modifiable only from SRM and not in ECC

Mostly depends on what your business requirement is

Read this blog for more information

https://wiki.scn.sap.com/wiki/display/SRM/Technical+Scenarios

Hope that helps

Regards

Vinita