How PO data will be replicated to the backend system

[venky_k]

Hi All,

How exactly the PO related data will be replicated to the backend in SRM Extended Classic Scenario?

Thanks in Advance.

[Former Member]

Hi Venky,

Forwarding the post from Le Radis on this earlier, it will help...

PO Replication to R/3

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*)

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).

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 backent into SRM).

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.

Ashutosh

[Former Member]

Hi

Please implement BBP_CREATE_PO_BACK BADI or BBP_ECS_PO_OUT_BADI

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

Regards

- Atul