on 09-01-2006 5:49 PM
Is there a way in SRM to give the user the ability to create a shopping list of items and then have someone else retrieve that cart and complete the necessary information?
We would like to give more users access to SRM. But, they may not be aware of the appropriate account assignments to use. Currently, they provide someone with a list of items to order (either via e-mail or paper) and that person creates the shopping cart in SRM.
Our current SRM users have the Employee job role which allows them to only see their own carts for processing.
Monique
Following 2 options are available. You can check which one will be suitable to your requirement.
1.In SRM there is a standard role called Purchasing Assistant (SAP_EC_BBP_SECRETARY).
Purchasing assistants can define templates for recurring procurement processes, which employees can then use when creating shopping carts.
2.There is an attribute called REQUESTER to maintain alternate Goods recipient. Employee with this attribute can create shopping carts for those users defined in the REQUESTER attribute value field.
PS : Reward points if helpful.
Regards
Jagadish
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I'm not sure if the first option would work because the templates would be visible by anyone. We would want to have some restrictions in place.
For option 2, we are already using the attribute. That is not what I am trying to accomplish. We are trying to allow the users to create a barebones shopping cart and have someone else pull it up and complete the rest of it.
In that case try to create a new role and give access to the Templates link in the SC.
Then assign this role to all users whom you want to order.
For rest of users assign different role which will not have access to Templates.
Here you need to work with customized roles which give access to customized menu links.
PS : Reward points if helpful
Regards
Jagadish
It does not appear that public templates exist in SRM 4.0. I had the t-code added to the role but nothing changed. I remember reading somewhere that public templates were removed. There is still a place for Old PO's and templates. However, when you click on it, it shows previous carts created by the user logged in. There is no option to create new templates.
I have added the Create Template transaction in our Dev system with one of our existing job roles. We do not use the Purchaser or Secretary roles.
However, I am running into a couple of issues.
We do not allow our users to copy previous shopping carts if the items are from a catalog. The prices are not updating to the current price. The programmer is playing with the BADI so that templates do not generate the same message though. The BADI does not seem to distinguish between a true shopping cart and a template. Any suggestions to get around the error message?
Once the template is used and copied into a shopping cart, is there a way to delete the template? If so, can only the person who created the template delete it?
Message was edited by: Monique Stephens
Monique
If a Template(not a shopping cart) is created, then in table BBP_PDHGP, field SUBTYPE will be having value "ST".
If a SC is created SUBTYPE field value will be blank.
But I do not know if there is any indication in table which tells that SC line item is from template.
All users will have access to the templates created by any users. They can copy the line items from the templates and create SC with those items. Line items in the templates will not be deleted once you copy them into SC.
Only users who have created the templates will have access to delete them.
PS : Reward points if helpful.
Regards
Jagadish
Monique: have you considered using the following Workflow: <a href="http://help.sap.com/saphelp_srm40/helpdata/en/1c/df0e3bfd97304a94b064d6a87cf72d/frameset.htm">Shopping Cart Completion by Purchaser</a>?
Cheers,
Serguei
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I have not considered that workflow. We are already using a one-step approval workflow. Is the workflow you recommended possible when another workflow already exists? We are only using the Employee job role for the shopping cart creators. I assume we would need to create a new role for the other users that would be creating an incomplete cart. How would we tell the system to route the cart to a user with the Employee role to complete the cart and send through the approval process?
Monique: the completion workflow can co-exist with any other SC approval workflow(s). You just need to define workflow start conditions properly.
You don't need to create additional roles for your shoppers. The "incomplete" shopping cart goes to the Purchaser (Purchasing Group) set as responsible for the user's org unit in Org Plan. The purchaser completes the shopping cart, and sends back to the original requester. The requester reviews the changes and re-submits the SC. Then the SC goes through the approval workflow. Please refer to the process diagram in the link that I sent you.
Cheers,
Serguei
I did look over the diagram.
However, I do not think it will work for our situation. We use the classic scenario. Currently, our users create a shopping cart that will route to their approver in the department. Depending on other factors, the cart can also route to Finance or Grants for approval. After all approvals are done, the shopping cart status changes to "Approved". If the items are to a catalog vendor, the PO will be automatically created on the R3 side. If the cart was free text, the cart becomes a requisition on R3 and our Purchasing department converts the requisition into a PO. We have 4 purchasing groups set up in our SRM system. There are more than that in the R3 system but we do not bring them over into SRM.
We will look over the diagram and see if it can work for us with a little bit of manipulation.
Thanks for your help.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.