cancel
Showing results for 
Search instead for 
Did you mean: 

Changing Owner of a shopping card (Enterprise Buyer SRM 4.0)

Former Member
0 Kudos

Hallo,

a customer has a few users.

Often old user should be deleted.

Because of needed licences and other things.

A "Administartor" of a customer should can delete user they never more works for his company anything else....

But it should be possible to work with old Shopping Baskets of the customer.

How ist the standard-Business-Workflow for this problems?

Is there a chance to change the owner (CRMD_ORDERADM_H-CREATED_BY) to another user from the customer.

I am very happy, if someone can help me.

Greetings

Jürgen Spranz

Accepted Solutions (1)

Accepted Solutions (1)

yann_bouillut
Active Contributor
0 Kudos

Hi Also found an interesting OSS note 978126 with a report done initially for Ericsson in SRM40.

"The requirement from customer is to have a report having a listing of POs in case the person who has created the PO has left the organization or has been moved out of the purchasing organization/group. The report should also be able to update the PO with the new requestor and/or new recipient."

You should be able to adapt it to Shopping cart ))

Kind regards,

Yann

mr_stirfry
Explorer
0 Kudos

Ah, very good information, Yann. That's a recently updated OSS Note too, though version 3.

Give this man the 10 pointer!

stirfry...today is 'tofu'

Answers (3)

Answers (3)

yann_bouillut
Active Contributor
0 Kudos

Hi,

To complete Stirfry post, sapgui transaction SWIA (admin role) enable you to forward the workitem to another user.

Kind regards,

Yann

mr_stirfry
Explorer
0 Kudos

hola -

wow, a few things here.

one i would not up and changed the crmd_orderadm_h-created_by field. it's kind-of would be an audit issue. plus there are many other places including crmd_orderadm_i, etc.

also, would not recommend deleting a user out of the system. you loose visibility. audit issue again. also, how about if you rehire them? so many things why it would be good to keep the user in the system. now, i understand about the whole licensing, however, what would be a better business practice depends on the scenario and typically locking and invalidating the SU01 record should not count against you on paying for licensing.

for non-hr ale replicated users (srm locally maintained in SRM without HR integration):

============================================================

- in the SRM org. structure, get the proper responsible resource to unassign the user from the position. this will not delete the user's BP and CP and thus maintain the historical data of the person...if the individual so happens to return to the organization later in life.

- in SRM, get the proper responsible resource to delimit the user in transaction: SU01 (see validity period under logon data) by putting an Valid through end date as well as lock the user. By doing this, you should be ok with the licensing issue and have the SU01 record in the system is ok as long as the user is locked down and not active for the period.

for hr ale replicated users (HR Master maintained in HR system and then replicated to SRM):

============================================================

there are several ways to do this, but here is my recommendation:

- HR Action on the HR Master record would be termination (or whatever process is invoked within the organization). Thus, this will delimit the HR Master record...and I believe the SU01 in the HR system, but should check the SU01 to make sure. Can't remember off the top of my head.

- replicate HR Master and Org. Structure changes (usually depends on the frequency and proces that was invoked within the organization). check SRM and the user in the original position should reflect, depending on HR validity date that was entered, what the validity of the Org. Structure view is set to, etc.

- in SRM, get the proper responsible resource to delimit the user in transaction: SU01 (see validity period under logon data) by putting an Valid through end date as well as lock the user. By doing this, you should be ok with the licensing issue and have the SU01 record in the system is ok as long as the user is locked down and not active for the period.

now your question about: 'it should be possible to work with old Shopping Baskets of the customer. How ist the standard-Business-Workflow for this problems?'

well, there is a proactive approach and a reactive approach.

proactive is to invoke a process within the organization in place where as part of the employee exit is to make sure all their responsibilities are completely closed out, including fully completing an open SC, approved all work items, in the Inbox 'Forward' on the Work Item to someone else, etc. this is not perfect, but there is usually a process in place.

ok, let's say it does not happen (which will occur), then the reactive approach is (if the user is not deleted in the system):

- if open shopping cart, might be easier to just reorder the shopping cart depending on where it is in the approval chain. if has gone through many approvals, then those approvers probably would not be happy to get a duplicate shopping.

- if an approver leaves, then get the workflow administrator to forward the work item to someone else...this is reflects/log in the system (unless something 'creative' was done), so it should not violate any audit rules.

deleting the SU01 record posses a lot of problems. if already done, may or may not be able to do anything salvage the open items.

don't know the exact specific details, so take whatever makes sense.

regards,

stirfry...today is 'chicken'

Former Member
0 Kudos

Hello, if you want to change the owner of an SC you will have to change the partner in table CRMD_PARTNER the partner function of the requester is identified by '16' . The CREATED_BY field is not taken into account when determining the requester.

Regards, Luciano.