on 07-18-2007 10:03 AM
Hello all
We had previously customized some storage locations (sloc) in our backend system that we won't need and deleted them again (this was ok because not a single document was created in backend referencing to one of those deleted sloc's).
But unfortunately those deleted sloc's still show up in SRM (e.g. in the extended attributes) within the favorites and in the search result list. I already tried out to use Report BBP_ATTR_TEXT_REFRESH. It says that it deleted the sloc but when going to see whether or not it worked the sloc is still there showing up with its ID instead of its name. So it's still there and can be choosen but definitely it will cause shopping cart errors because the sloc doesn't exist anymore in the backend system and the material isn't created in this sloc as well of course.
So my question is: how to properly get rid of deleted sloc's in the favorites list and in the search result list?
TIA for any helpful ideas
Renaud
Hi
<b>You need to Implement BBP_F4_READ_ON_EXIT BADI using SE18 Transaction. Take help of ABAP person here.</b>
<u>Here are the detailed links with steps, source code -></u>
<b>Here is the required code to be used in your case. -> </b>
Method IF_EX_BBP_F4_READ_ON_EXIT~GET_BOBUSER.
*--- Delete Favorites for: Requester (Buying on Behalf of)
delete ET_BOBUSER_FAVOURITES.
*--- Delete Favorites for: Requester (Buying on Behalf of), Texts,
delete ET_BOBUSER_LIST.
Endmethod.
Do let me know.
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,
See if the foll note helps:
Note 301610 - Deletion of old texts for attribute values
BR,
Disha.
Pls reward points for useful answers.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Monique
Not yet but I'm aware of it.
The problem here is, that our organization is quite "complicated" and we really couldn't find an org. structure for our ppoma_bbp allowing us to built a structure based on useful criteria like department, cost center, supervisor, ... whatever. There were finally always too multiple "shop on behalf" relations accross all criteria that could help us to setup a useful structure... so we ended up in assigning storage locations on user level. We have round about 1300 end useres and it is quite time consuming to manually go through them one by one.
And changing the organization is another question / topic that I really don't want to discuss here.
BR
Renaud
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.