Change User Function Name

Question

Hi all,
I'm trying to create menus & responsibilities using data loader so that I don't need to recreate it manually but data loader crashed because some of the user function name are the same.
For example, open Sysadmin -> Application -> Menu -> AP_PAYMENTS_ENTRY_GUI12 in Vision. In Seq. 3 we have Payments menu with AP_APXPAWKB_CHECK_MENU submenu and Payments functions. Tried to search in Functions LOV and we'll get some User Function Name equal to Payments but different Function Name.
I'd tried to change some User Function Name and all the menus that directed to it changed too, the referential integrity worked I think :P but I want to ask whether it will caused any trouble if I changed it in Test & Production environment?
Thx.

Answer 1

I don't consider those to be "hacks" in my book
They are just bad design approaches:
In the first case, you will loose the audit trail to the caller.
In the second case you will be forced to grant authority to the end user to open a step in another user's context. That will open another backdoor for them as well in SM37 etc...
> PS: If the real problem is just that you cannot grant the authorization on a certain function module as it is used in different standard applications so the authorization for your program would result in to powerful authorizations in sap standard transactions, the I would copy the function module and use it. This Z fm could be authorized bypassing this problem.
A better option with less coding involved, would be to use SU24. This way you keep the audit trail and isolate the transaction as being an exception to the standard checks for one specific object. An auditor might wonder why a user can release a PO when they don't have one of the required objects, but they will easily find it if they know where to look.
It is also easy to do this in a secure way, such that you can document it for the auditor and give it to them upfront to understand. A good auditor should understand and appreciate that.
If you achieve this programmatically with tricks, you will have a tough time... (as will the auditor).
I have done many audits and also hunted down some dodgey coding in my time. The idea should not be to run away from the auditors, but rather expect that they know what they are talking about and make your design compliant with their and your client's control requirements.
This should be the approach regardless of whether or not you can change sy-uname as a developer.
The original question might also have been: "Can I pass a backdated authority-check against a user who once had the authorizations way back when?" Same thing... bad idea...
Cheers,
Julius