A Succession Management Tool for SAP Sourcing
Definition
What happens if a potential SAP Sourcing user leaves the company? How will the ownership of their documents they worked on be reflected and tackled going forward?
Typically SAP Sourcing already does, built-in, provide possibilities to do this. I.e. typically you could either do an Ownership change of a business document via the UI (which certainly would only make sense if but a few documents were to be changed) or alternatively for large scale changes imports can be served with this purpose. SAP note 1092321 (Can you update collaborators on documents) does elaborate on this approach. While working however it may be time-consuming to perform the necessary steps to fill the import template and hence, should this be a recurring task, a more proper UI solution could be thought of.
This is where this implementation of a Succession Management Tool (in this context to be understood as a tool handy to change Ownership on business documents within SAP Sourcing) comes in. Note that this is based on this post (Leavers and joiners policy ideas) if you wanted to investigate the original idea.
Installation
This implementation is delivered as follows in the attachment called (SMT with UDO – please rename the .txt extension again to .zip as this had to be done to be able to attach this here):
a) a system manager user workbook (as the SMT tool is using the User Defined Master Data 2 object by default)
b) an enterprise manager user workbook that contains the rest of the logic
c) the actual scripts that are being used and are referenced in the “script_definition” tab of the enterprise manager workbook
For the “script_definition” tab in the enterprise manager workbook make sure to check/adapt this to your local preferences/settings. Note the business context and the location of the scripts. The scripts need to be in a directory that the application server, where SAP Sourcing is deployed, can access.
Workflow
1) Log in as the Enterprise Manager user and find on the Master Data tab the SMT tool
2) Create new ownership change documents that are being used to trigger the ownership change. Here you can also see the customized columns.
3) The UI is split as follows – the actual logic is to be found under “Scripts” (once in “Edit” mode) whilst the from and to Ownership change is found below. The extension collections do show the Determined Documents for change(s) and also, once updated, will update their respective detail extension collection with the document/template ids that have been changed.
4) Determine the documents by using (in “Edit” mode) the respective “Determine…” scripts
5) This will then look like this
6) Then let`s update (aka change the owner to the from/to values) e.g. the Projects
7) Which yields the ID of the changed document
Note: In general if you have access to it I found it advisable to use the Enterprise Manager user for this task. If you do use a normal user (either of the affected / from the from/to fields) you a) may not get any notifications of the ownership change and b) if the security profile settings are not configured you may run into security issues upon ownership change attempt.
I hope this idea/implementation can help in managing this particular occurrence with the SAP Sourcing application. As always, with all posts, remember that this is provided “as is” and that as such no responsibility for any damages incurred can be taken. If you are in doubt please contact a SAP Sourcing consultant or similar resource.
Regards,
Joerg Lippmann
Thanks, Joerg. This is very interesting.
Is there any way to do this for Contract Templates and Master Agreement Templates (rather than created documents) specifically?
The way our system was setup, users that edit templates have to impersonate a special non-user account in Sourcing, just in case one of them ever leaves... But this is an issue with our security group because it removes personal accountability.
I have found a work-around of exporting the contracts to an oma file; manually updating the owner; and reimporting. But this is complicated, slow, and technically risky/unsupported.
For this purpose a simple beanshell script utility that could be run on demand would be sufficient. I see a TemplateContractIBeanIfc, but not sure if that includes Master Agreement Templates.
Would appreciate any insight you may have...
Thanks in advance.
Mike
Hi Mike,
good question. Thinking about this I see the following options at this point:
1) Looking at TemplateContractIBeanIfc I see this to be part of com.sap.eso.api.contractgen and thus comparing that to ContractIBeanIfc which is in com.sap.eso.api.contracts I`m not too sure the TemplateContractIBeanIfc would behave as expected. Try looking into ContractIBeanIfc as you`ll have a method for isTemplate.
If you need further input on this I`d suggest posting that on the forums directly here: http://scn.sap.com/community/sourcing so others are also more likely to reply as well
2) Practically there is also always in your current setup a way to find out who impersonated that special user. The application logs would show that as the username column would also have the impersonator and impersonated user logged. Due to the nature of the logs however of course that information wouldn`t be there forever unless you`d frequently be saving the logs. By default however the NW will rotate the logs and hence after a while they`ll end up being overwritten.
3) For the OMA approach - I`m presuming you`re using something like the FCI-AllContractTemplates query to determine the entries for the OMA? An interesting approach as ultimately there is at this point no importer for any business documents directly. If you check this outlined approach here however you`ll also note that the returned updated entries for templates will actually show what you see in the OMA in field UNIQUE_DOC_NAME.
4) Why not actually solve the access/accountability problem to the Template via Group membership (if possible)? As long as potential users are collaborators they could make necessary changes and, due to the logged Change History, you`d ultimately fulfill the request of the Security Group. The Owner can still stay the non-user account. The Document Security Templates could be your point of entry here besides the Groups.
I hope this makes sense?
Regards,
Joerg Lippmann
Joerg-
Thanks for the detailed response. Regarding each of your points:
1) I had pretty much the same thoughts/questions you ran into. I will post a question to SCN about it soon. I was thinking that maybe the ContractIBeanIfc with isTemplate = TRUE meant that it was a Master Agreement Template and TemplateContractIBeanIfc was for Contract Templates, but I'm not sure and haven't done any experimenting... Since this happens so infrequently, I think a utility script like this would be the cleanest and easiest to remember approach in our situation.
2) True, but seemed like it would take some significant work for the reasons you mentioned and also because access to the NWA logs is limited.
3) I was doing something very similar, but had to run 3-- one each for contract gen clauses, sections, and templates. Basically doing same type of export as we do when we move the templates between instances, except instead of importing them into the different environment, I reimport it into the same environment (after doing sanity checks in sandbox). During testing so far,I have not seen any concerns other than the ones i mentioned in first post about this being generally bad practice. I can write a small C# utility to make it easier to modify the file, but still would rather not do this at all....
4) This may be possible. I haven't looked specifically for each screen of Contract Templates, Sections, & Clauses, but i've seen on other screens that logging can be incomplete or misleading while impersonating. We have also run into an issue a few times where the user the person is impersonating gets logged off automatically, but instead of exiting the session, it just falls back to their own account. If they don't happen to notice that the name at the top changed, all the changes go under their own name anyways... That's another reason that I think it'd be easiest if they could simply use their own names-- because I've actually had to do #3 to change the owner to the account they were supposed to be impersonating....
Seems like there should be an easier way...
Thanks again,
Mike
Yes. I wrote the script yesterday and it seems to work great for our purposes. Your blog post was what spurred me in that direction. I really appreciate it! What you've done here is largely over my head at this point, but still learning and hope to get to this level...
The script is nothing fancy and I still have some cleanup to do, but if anyone wants it, just post a reply here or on the SCN thread and I will post the code.
Thanks again,
Mike
Thanks Mike - appreciate your feedback.
Regards,
Joerg Lippmann