Monitoring changes to user parameters and defaults

[Former Member]

Hello Everyone,

We have a requirement in our project to monitor the changes to user parameter values. I know that this is not done in the standard system. But, I would like to know if anyone is aware of implementing such an functionality wherein we can also log the changes to the user parameters and defaults.

Regards,

Subbu

[Former Member]

I don't think logging is active here because there is no formal requirement for it.

PIDs should only be used for preferences and remembering values. I don't think that table logging will help you much either, incase someone posts something about activating that.

My suggestion would be to challenge the use of PIDs for something which requires logging, or if you want to have this as a "nice to have" then consider using the GOS history option. But as with PIDs, the user can clear the history if they want to.

Bottom line: It you use something beyond it's scope, then "missing functionality" is a natural (often self inflicted) consequence.

Cheers,

Julius

[Former Member]

Hi Subbu,

Out of interest why do they want this? If you could get this functionality then one problem that immediately comes to mind is that you would get lots of change records for PID's which are set automatically. If you have logging activated for USR05 I suppose this could pick it up PID changes.

If they are sensitive why not prevent users from maintaining these values & put in a change control process for any changes which are made centrally.

[Former Member]

Hello Alex,

We have had instances wherein the parameter ids of the users were changed and we had no clue as to who has done the changes. There is no automatic assignment of parameters on this system. The client wants that we should be able to track the parameter changes on this system as some of these ids were really critical.

Yes, we could also block the users access to parameter changes that is one option, but as of now we are considering the possibilities of being able to log the paramer changes.

Thanks for your suggested option.

Regards,

Subbu

[Former Member]

Hi Subbu,

What I meant by automatic assignment was where selecting options within a transaction automatically updates PID's. The most obvious examples are transactions like FB00 and OKKS. If a user makes setting with these then their PID's are updated without anyone maintaining the PID field in the UMR. It is possible that these are the cause of some of the issues.

Regardless of the above, it does sound like some additional logging is desirable in your situation.

Are there business process which are dependent on the PID values?

Cheers

Alex

[Former Member]

Hello Alex,

Yes, there are some business processes which are dependant on the parameter values and that is why it becomes so critical.

I have tried your suggestion in sandbox and have activated table logging for USR05, but I am still unable to find the change log for the user parameter. How do I find it?

Regards,

Subbu

[Former Member]

I am not 100% sure on this but you may need to bounce the box to activate the logging parameter. Did you do this?

Once activated & table set to be logged, you should pick up the logs in SCU3 for changes to the table USR05.