Skip to Content
avatar image
Former Member

Extended classic scenario

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

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

3 Answers

  • Best Answer
    avatar image
    Former Member
    Apr 04, 2008 at 07:24 PM

    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

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Apr 04, 2008 at 07:15 AM

    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

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Apr 05, 2008 at 02:22 AM

    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

    Add comment
    10|10000 characters needed characters exceeded