on 10-23-2007 9:45 AM
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.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
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
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.
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
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.