cancel
Showing results for 
Search instead for 
Did you mean: 

Shopping cart item deleted after FOD created in backend system

Former Member
0 Kudos

Hi.

We are using component version SRM 5.00, with SRM_SERVER 550 in Classic scenario.

We have noticed that an item in shopping cart can be deleted even if FOD has already been generated in R/3.

But we do not want this. User should not able to delete an item in shopping cart if FOD for that item is already generated. We tried to track the event of deletion in BADI for BBP_DOC_CHANGE_BADI, but we see system goes to this BADI after deleting the item and clearing deletion indicator of that item does not help to solve this problem.

Pls suggest how to stop deletion of an item in SC after FOD generation.

Thanks and regards.

Sriparna.

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi,

This can be controlled by user level authorization settings.

Go to SU01 for that particular user(employee who shops) and in the "Personalization" tab you will find the Personalization Object key BBP_WFL_SECURITY which has four authorization levels None, Low, Medium and High. I think "None" will work in your case.

Check this out and let me know if you are able to succeed by this.

Or

Create a Z role for the employee without the change authorization for the shopping cart (from PFCG) and assign this to that particular user in SU01 if this is feasible.

Best regards,

Sridhar.

Former Member
0 Kudos

No, this is not my requirement. Our requirement is that, if FOD (child of the SC item) has been created in tte R/3, SRM system should not allow to delete the parent shopping cart item.

Pls suggest if this can be done using any config setting or BAdi.

Thanks.

Sriparna.

Former Member
0 Kudos

Hi. Use the BBP_DOC_CHECK_BADI.

When you press the delete button a certain SY-UCOMM will be sent.

In the code of the BADI look for this SY-UCOMM, and if it is the right one then do whatever checks you want, and you can issue an error if the user is trying to do something they should not be.

Regards,

Dave.