Shopping Cart with Sourcing

[Former Member]

Hi guys,

We have the following situation:

We use in SRM 5.0 (classic scenario), shopping carts which are transfered automatically to the Back End system where they generate Pur.Requisitions.

NOw we want to implement a sourcing process via the sourcing cockpit which generates a Backend PO (starting with a Shopping cart)

Our problem is that we do not know how to seperate a shopping cart which goes directly to the backend (PurReq) from a shopping cart which has to pass the sourcing process.

We cannot distinguish by Product Category and both shopping carts can be without vendor located in the positions!

We could not find a config which allows to use different documento types!

anyone had this situation before? How can we solve this problem?

Thanks for any reply,

Aart

[masa_139 · Accepted solution]

Hi,

How about implementing the BADI BBP_SRC_DETERMINE.

Regards,

Masa

[Former Member]

Hello,

Could you checkthe foll cust link in SPRO:

Define Objects in Backend System (Purch. Reqs, Reservations, Purch. Orders).

PO is created if you set the "*" for EITHER the purchasing group OR the product category.

SRM is creating PR or PO depending on:

SRM customizing (ex: always external proc + PR if incomplete, PO if complete)

the interpretation of SC data by R/3.

IF your SC is considered complete by SRM (but with a fixed vendor and not a preferred vendor) the system will check if it can create a PO in R/3.

For this, each item will request a META_INTERPRETE_DATA to R/3, asking if it can create a PO. If R/3 considers this data as incomplete, it will reply to create a PR.

Usual cases of R/3 PR creation instead of PO:

prefered vendor in SRM (and not a fixed one)

custom checks in user exits in R/3

error messages in R/3 (ex: O6 334 In the case of a fixed vendor, please enter info record)

...

To debug without debuging into R/3, you can also try the following:

use BADI DETERMINE_TARGET_OBJECT and force PO creation

so the system will always try to create a PO

R/3 won't create the PO (for the same reason as in META_INTERPRETE_DATA), and will raise an error in SRM

finally you get the real error in application monitor (SC --> backend application errors

Related thread:

I hope this will help.

Kind regards,

Gaurav