Shoping cart / Classic / Delivery address

[Former Member]

Hello,

Our context:

Technical: ECC 6.0 / SRM55 SP5

Functional: on "plant", 3 company codes, 5 locations for delivery, 600+ users.

In the current set-up, I understand that EBP creates a delivery address per shopping cart, and then in the back-end we have several addresses for PO created from multiple shopping cart.

Our consultant applied notes 576665, but the problem persist if for example a PO is created from a first set of SC and put on hold, and then the next day additional SC are inclued.

In my logical view, we only have 5 adresses and I would be more than happy to assign the rigth address id to each user as an attribute (it's very easy it's the second level of my orgmanagement chart!) and that EBP stops creating address IDs.

Any suggestion?

Thanks,

Anne

[Former Member · Accepted solution]

Hi

Please verify whether the OSS note - 576665 is correctly implemented in the system.

Also refer to the dependent OSS note -

Note 945631 - Delivery address BAPI_PO_CREATE1/BAPI_PO_CHANGE

Hope it helps.

Pls reward suitable points.

Regards

- Atul

[Former Member · Accepted solution]

Hi,

My consultant also mention note 945631, but I was unsure of the use as we only generate PR in our backend as our users don't enter a vendor.

We'll have a more thorough check.

The direct flow

SC (with more than one line) => Back-end PR => Back-end PO

works (address only displayed at the top of the printed PO)

But

SC1=> Back-end PR1 => Back-end PO on Hold

SC2=> Back-end PR2 => Add to Back-end PO on Hold

Fails and is unfortunatelly 50-70% of my puchaser cases...

Anne

[Former Member · Accepted solution]

Hi

The user from which you are testing should have enough system priviledges.

For time being, try to give SAP_ALL access to the user and again try out.

Hope it will help.

Regards

- Atul

[Former Member · Accepted solution]

Hello Atul,

Unfortunatelly, I'm not just testing, I have this problem in production, but I'll give it a try in the test system with SAP_ALL (and reward you after the test).

Anne

[Former Member · Accepted solution]

Hi,

I had a look at the SRM 5.0 release notes and undertsood that using new BADI BBP_CREATE_BE_RQ_NEW instead of BBP_CREATE_REQ_BACK could solved the problem (we only create requisitions).

I haven't tested it personnally, but I'm confident that it works.

Anne

[Former Member · Accepted solution]

Hi

We are using SRM 5.5 and faced a similar situation earlier.

<b>This BADI -> BBP_CREATE_BE_RQ_NEW will definitely work in SRM 5.0 or higher versions.</b>

The documentation of this BADI is as follows:-

---

Purchase Requisition in Backend System

Using Business Add-In BBP_CREATE_BE_RQ_NEW you can change all the data that is transferred to the backend system for generation of a requirement. This includes, for example, item data, account assignment data, and texts. You can access all the shopping cart data in the method FILL_RQ_INTERFACE for generation of the backend reservation via the BAPI BAPI_REQUISITION_CREATE.

Standard settings

The settings for this BAdI override those of BAdI Grouping of Shopping Cart Items for Follow-on Documents (BBP_BS_GROUP_BE). BBP_CREATE_BE_RQ_NEW is called up following call-up of BBP_BS_GROUP_BE and shortly before the documents are created in the backend.

Recommendation

If you use BAdI Group Shopping Cart Items to Follow-on Documents in order to determine number ranges, assign numbers, or to group requirements, SAP recommends that you do not overwrite this data with BBP_BS_GROUP_BE.

---

Pls read the definition documenatation in your system in order to how to implement the BADI.

Please reward suitable points.

Hope this will help.

Regards

- Atul