Extended Classic Scenario - how does the integration work ?

[Former Member]

Hi,

Apologies for asking a basic question, but we are looking at requirements for integrating SRM with R/3 using the extended classic scenario and I need to understand how the integration actually works ? How is the data transferred between the 2 systems ? Does it use BADI's, idocs etc ?

Many thanks,

fiona

[Former Member]

Hi Fiona,

In the extended classic scenario, you can transfer Purch. Requisitions from R/3 to your SRM via qRFCs, do the sourcing in SRM, create a local SRM PO and transfer this purchase order to your R/3 with an RFC - BAPI call. (for example the BAPI_PO_CREATE1) Technically there is a so called Plug-in in your backend where the mapping from the SRM-PO to the BAPI structures is done. After this, the BAPI is called in the R/3.

In the extended classic scenario, the SRM is the leading system. So in the R/3 you will only have a copy of the PO which can not be changed.

Best regards,

Olaf

[Former Member]

Hi Olaf,

I just wanted to give some precision on what you said (in the thread also)

The Extended classic scenario only refers to the local PO creation replicated in R/3.

In this scenario, in the R/3 PO only the data not managed/sent from the SRM are available for modification (which depends on the SRM version you use)

The "PR transfer from R/3" is called "Plan driven procurement", and in this scenario only RFC is used, the qRFC are only used for BDocs of the CRM Middleware.

Regards.

Vadim

[Former Member]

Thanks Vadim.

So to confirm, the GR and invoice transfer via ALE - is this using a BADI ?

What about master data integration, eg: GL accounts,

Cost Centres, etc. How are they made available to SRM ?

Thanks,

Fiona

[Former Member]

Fiona,

The BADIs for changes and check on documents can be used for GR and invoices. There is normally another one for the IDOCs generation.

For accounting data:

-You can choose through IMG where the account assignment check takes place (localy in SRM, in R/3 or not check).

-Concerning the codes, there is no standard inteface for GL accounts. For costs centers and the other Acc assignment objects, with SRM 4.0 and a backend version 4.6C or higher, you can you can use the backend search help directly.

PS:If you really want to create locally the Acc assignment objet, have a look in R/3, some ALE scenarios exist.

Regards.

Vadim

[Former Member]

Thanks Vadim,

So, to clarify; for example with an invoice - if an invoice is entered in SRM, it is created in R/3 by idoc. Subsequent changes to the invoice would be updated by BAPI from SRM to R/3 ?

Is it possible to integrate the Material

Masters in MM with the catalog in SRM ?

Thanks

[Former Member]

Fiona,

Concerning GR & Invoices, the updates are sent to R/3 through ALE/IDOC.

Concerning Materials, you can incorporate MAterial numbers in the catalog, without replication locally the materials (If you use CCM 2.0, a product catalog can be directly from MM Material master, to enrich Supplier data).

To avoid local material check, in the catalog link customizing point put the corresponding flag, and fill in a logical system (do not put the local system, or the SRM will continue to check local Material master).

Best regards.

Vadim

[Former Member]

Hi,

The process in the extended classic scenario is:

1-SC created locally

2-SC Workflow approval

3-Local PO creation (if the PO is incomplete, it has to be completed manually by a purchaser user)

4-PO edition (print, mail, XML and/or fax)

5-PO transfer in R/3 (BAPI RFC Call) (the created PO cannot be modified in R/3)

For GR and invoices, they may be created in SRM, then they are transfered through ALE in R/3.

You've got BADIs in the system for all these documents creations, check,...

Regards.

Vadim