Extended classic scenario

[Former Member]

Hi Friends,

Can you please let me know what is the impact of activating extended classic scenario? are there any advantages and disadvantages of doing it? I know this is totally a business decision, but what are the things which we need to take into consideration before activating the extended classic scenario.

Thanks in advance.

Regards,

Kumar

[Former Member · Accepted solution]

Hello,

In the extended classic scenario, the follow-on documents of the purchase order, confirmation and invoice, can be created either in SAP SRM or in the ERP back-end system. The data is synchronized between the two systems, so that the document history is always up-to-date in both systems. The data synchronization between the back-end system and SAP SRM has an effect on the following search options for the purchase order:

Purchase orders with outstanding confirmations

Purchase orders with outstanding invoices

When the purchase order is created in SAP SRM, the back-end FI system sets up a corresponding commitment (using IDoc BBPCO01). An exception here is direct material purchase orders.

You can use an SRM Server Business Add-In to change data that you transfer into the logistics back end.

For more information, see the IMG: SRM Server Business Add-Ins (BAdIs) Control Extended Classic Scenario Transfer Purchase Order Data to Logistics BackEnd .

In the back-end system, you activate the application SRMNTY in table TBE11 using transaction FIBF so that the purchase order follow-on data is transferred from the SAP back end to the SRM Server system. In this way, the SRM Server system is notified when follow-on documents are created in the back-end system.

In the SRM Server System, you also need to schedule a background job for the program CLEAN_REQREQ_UP using in transaction SA38, or vary an existing job in such a way that entries of type AV are processed in the table BBP_DOCUMENT_TAB. The background job calls the purchase order follow-on data from the database of the back-end system, via RFC communication.

If there is no standard RFC connection set up with an RFC destination that has the same name as the logical system of the purchase order, you must establish this RFC communication.

I hope this helps.

Kind regards,

Gaurav

[Former Member]

Hi Kumar,

in addition....

---Procurement Card (PCard) Functionality is not supported in Extended Classic Scenario (this is only supp in Standalone).

--Shopping Carts do not create PR in the backend - so no committments for SC. This is primarily for Public Sector Implementations.

---Purchase Order Printing only possible in SRM.

Pls reward points if useful.

Regards

Srini Khasnavees

[Former Member]

considerations:

- whether the purchasers are comfortable to work in SRM for purchase orders with web screens

- if for some matl grps ECC PO is created can they work in two systems for PO processing (generally business does not like this)

- PO printing programme in SRM

- PO layout in SRM

- pricing conditions import/create

- IPC set up

to mention some

BR

Dinesh