ECC PO wtih reference to SRM PO

[Former Member]

Hi ,

In my case PO has been crearted in SRM system, but PO has not been replicated in ECC system.

How do check for the reason why PO is not created in ECC system ?

Thanks and regards,

Amit R.

[Former Member · Accepted solution]

Hi

<u>Which SRM and ECC versions are you using ?</u>

<b><u>Please implement BBP_CREATE_PO_BACK BADI or BBP_ECS_PO_OUT_BADI</u></b>

<b>FYI, In ECS, the PO will created in R/3 directly.</b>

<b><u>PO Replication to R/3</u></b>

<u>PO is "replicated" the same way with both scenarios. SRM triggers a RFC call in R/3 and BAPIS are activated (BBP_PO_CREATE and BBP_PO_SAVE*)</u>

Difference between scenarios

WIth classic scenario, the SC following document is to be created in your R/3 backend(s). Thus you can get an PO, a PR or a stock reservation in R/3.

With extended classic the following document is to be found in SRM itself. Thus from a SC item you can get a complete PO, an incomplete PO or depending on your customizing a Sourcing cockpit (now called Sourcing Application) requirement. Additional FM are called when you tick the box "Enable Extended classic" in the IMG activity, enabling you to get a local PD.

If you need to get a stock reservation in R/3 with extended classic, you will have to switch back to classic scenario for the particular category or product with a dedicated BADI ("Control extended classic ").

Be aware that with extended classic, the PO created in R/3 is not exactly a replication. That is a "copy" with that crucial difference that the SRM PO will use a different Purchase Organization that of R/3. It enables you to centralize your purchasing. In SRM you can create a "local" Purch. Org for EMEA zone for instance while in R/3 that is rare you can purchasing above a country (because in the backend you have to produce legal documents related to one company). Those "local" (=SRM) Purch. Org. are required to enable extended classic and it makes simpler Contract management for instance (in classic scenario contracts may need to be replicated to your R/3 back end and adjusted for each back end and each Purch Org in R/3, and even for each plants).

<u>In a nutshell with extended classic you have a PO in SRM, and this PO is assigned to a different Purch Org that of R/3. Purch Org in R/3 are determined on the basis of the "Location" (R/3 plant you have replicated from your backend into SRM).</u>

<b>Extended classic is required for service purchasing when you want your requesters to be able to adjust the PO price while they can not access R3. In extended classic, PO is issued from SRM and not from R3.</b>

<u>Do the setting in SPRO--> Cross Application Settings --> Define Backend System.

Where you need to select the Product category--> source system --> Purchase Group for the material and select in the drop down field " Always PR or Always PO". One you do the same it will work.</u>

If you want a controlled extended classic scenario whereby once you create a Shopping cart it should create a P.R / P.O in the backend like classic scenario. You can use the BADI for this purpose which will overwrite the standard ECS settings for the particular product category / purchasing group / purchasing org.

Implement BADI : <b>BBP_EXTLOCALPO_BADI</b>

The following methods can be used : DETERMINE_EXTPO ,

DETERMINE_EXTPO_CREATE

<u>Related links -></u>

<u><b>Please let me know in case of any clarification.</b></u>

Regards

- Atul

[Former Member · Accepted solution]

Hi Atul,

I am using SRM 5.0.

This problem is not occuring for every PO,but for very few POs.

Thanks and regards,

Amit R.

[pvanhoove · Accepted solution]

Hello ,

Log with an administartor role and check the application monitors. You should see the error there.

Rgds,

Pierre

[Former Member · Accepted solution]

Hi,

When I checked status against for this PO through transaction BBP_PD,

it has one of the status as,

HEADER I1132 Transfer Failed (E.Sys.)

which is not present with other POs which have been successfully replicated in ECC system.

Thanks and regards,

Amit R.

[yeushengteo · Accepted solution]

Hi,

What Pierre meant is to check the application log in your SRM server. Not the BBP_PD. The corresponding transaction is RZ20 provided you have switch it on.

Regards.

[Former Member · Accepted solution]

Hi Amit,

There are various OSS notes available if the transfer fails with the code I1132.

Some of them for your reference:

Note 1081552 - Deletion of service items not transfered to backend.

Note 1069278 - Error while transferring PO with deleted accounting line

Note 664522 - Plan-driven service PO: Error during transfer to backend

However if you want to do the transfer manually to back end R/3 you can use the following function modules by using the SE37 transaction.

<b>BBP_PD_PO_TRANSFER_EXEC_V2</b>

<b>BBP_PD_PO_TRANSFER_EXEC</b>

the P.O can be manually pushed to R/3 by entering the GUID of the concerned P.O.

Hope this resolves your issue. Clarifications are welcome.

Award points for suitable answers.

Rgds,

Teja

[Former Member]

thanks for replies.