cancel
Showing results for 
Search instead for 
Did you mean: 

Shopping on behalf-of

Former Member
0 Kudos

Hi,

In our Portal implementation, we have the Shopping on behalf-of iView exposed. Users can access the iView and shop on behalf of another user. Recently, we have received reports that the iView is not working as it is supposed to be.

On Day 1, user A was able to shop on behalf-of user B. When creating a shopping cart, user A was able to search for user B and put user B as the requester.

On Day 5, user A is again trying to shop on behalf-of user B. When creating a shopping cart, user A is now UNABLE to search for user B. User A is NOT ABLE to put user B as the requester because user B is no longer found. However, when user A enters the transaction code "bp" in SRM, user B is listed. When attempting to recreate the shopping cart by search for user B with the BP Number (which was obtained from SRM), no results were returned.

Why is it that user B is not listed in the requester list? User B was listed on Day 1 but has mysteriously disappeared. Please note that user B is still active in the company and his records were not purged in any way (as evident when we try to search using t-code "bp" in SRM).

Any help/suggestions to resolve this would be much appreciated.

Thank You.

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi

In t.code PPOMA_BBP in attibutes of user A check for the attribute "requistioner" there you assign the attribute value as US"B" - where B represtnes the user id.

with regards

Manjunath

Former Member
0 Kudos

Hi,

Thank you for your reply. We followed the recommendation, but are still not getting user B to come up in search.

In addition, the posts have not explained why user B appeared in the search on Day 1 but would mysteriously disappear on Day 5.

Any other help/suggestions would be much appreciated.

Thank You.

Former Member
0 Kudos

HI Voon,

Your USER A shop on behalf of for USER B did not mysteriously disappear. The product category that you are using on Day 5 differes from the product category that you used on Day 1.

So basically, you need to ensure that the PGroup that has the responsibility of the product category that you are using on day 5 also has the organization responsibility of the Org Unit that the Users A and B are integrated in.

Please assign the organizational responsibilty of the Org unit containing users A and users B for the corresponding Pgroup->product category.

Hope this resolves your issue !

Pls assign points if answer is usefull !

Thanks,

Sundeep

Former Member
0 Kudos

Hi,

Thank you for your reply. Please note that even before selecting a product, we are not able to get user B as a requester. The following is an outline of the steps user A followed to shop on behalf of user B:

1. user A logs on to the Portal (SAP Netweaver 2004s with SRM 5.0 business package)

2. user A accesses the Shop iView from the SRM 5.0 business package to shop on behalf of user B

3. at the requester input box, user A tries to get user B by searching with user B's name

3a. user B is not listed

4. at the requester input box, user A now tries to get user B by searching with user B's bp number

4a. user B is not listed

It just seems weird that we are able to get user B's bp number by using "bp" in SRM, but we are not able to get user B as a requester even when we are searching with user B's bp number.

Please help.

Former Member
0 Kudos

Hi Voon,

It is difficult to say what is the issue in this case with the info. provided.

Try to maintain the "Requisitioner" attribute for User B and enter the user A i.d with prefix US.

And with User B try to Shop on behalf of User A and vice versa. Sometimes it works. If the problem still persists you have to look out for the SAP OSS notes.

Let us know the outcome.

Rgds,

Teja

Former Member
0 Kudos

Hi Rama,

Thank you for your reply. As mentioned, the "requisitioner" attribute in this case has been filled. The structure for both users A and B is built in such a way so that both can shop on behalf of each other (since both A and B are under the same Org node). In any case, we found that user B is now APPEARING on the BP search list when user A retries shopping on behalf-of user B. When user A now searches for user B for the requester field during an attempt to recreate the shopping car, user B is now AVAILABLE. This is really freaky because to our knowledge, no one has done ANYTHING to the system, yet B is now visible.

I think we might need to file a case to SAP support. Thanks again.

Former Member
0 Kudos

Hi Voon,

It looks your problem is resolved now.

If this is the case please close the issue and mark it as answered.

In case you find the same issue again please inform us.

Rgds,

Teja

Answers (3)

Answers (3)

Former Member
0 Kudos

While we are now able to list the requester, who was previously not found, we are still not able to find out what caused it to disappear and then reappear. An SAP support case has been filed.

Former Member
0 Kudos

In our case, we found out that our users are actually created via HR replication. The HR system transfers the user ID from ECC to SRM via IDOC. The corresponding replication only results in the creation of a BP only. Somehow, the HR replication logic is not working correctly. The relationship between the replicated accounts gets deleted, causing the BP on SRM to be unusable. The corresponding technical person responsible for the HR replication re-transferred the user from ECC to SRM. After the re-transfer, the user appears in the system.

Former Member
0 Kudos

Hi

Setting the attribute Requester should work. Keep in mind it must start with US then user ID in upper case. The attribute requester is to be filled with the complete object reference, which can be:

-Assigning all the users under an org node: 'O node_number' (don't forget the space between the letter and the number)

-Assigning a specific user: 'USUser_id'

<u>Please go through the related links -></u>

Regards

- Atul

Former Member
0 Kudos

Hi,

Both users A and B are under organization node O. User A's "requisitioner" attribute has been set with the "O node_number". Since all users under organization node O can shop-on behalf of each other, we did not specify any specific user. However, we are still not able to search for user B when user A attempts to shop-on behalf of B.

In addition, the posts have not explained why user B appeared in the search on Day 1 but would mysteriously disappear on Day 5.

Any other help/suggestions would be much appreciated.

Thank You.

Former Member
0 Kudos

Hi Voon,

As informed by Manjunath you have to maintain the "Requisitioner" attribute in the PPOMA_BBP.

In case of user A & B. If A wants to shop on behalf of B the Requisitoner attribute to be maintained in the attributes list of A with the Prefix US and the user ID

i.e B

In such a case the user A can able to shop and create P.O on behalf of user B but he can not able to receive the Goods on behalf of B.

If you want user A to even recieve the goods on behalf of B the "Requisitioner" attribute to be maintained in the attributes list of user B.

Hope this resolves your issue. Clarifications are welcome.

Rgds,

Teja

Former Member
0 Kudos

Hi,

Thank you for your reply. We followed the recommendation, but are still not getting user B to come up in search.

In addition, the posts have not explained why user B appeared in the search on Day 1 but would mysteriously disappear on Day 5.

Any other help/suggestions would be much appreciated.

Thank You.