UDC Security

As part of meeting SOx requirements our auditors have said we need to tighten security on users who can add or change UDC values. Currently I have about 10 manager type roles that have this functionality. Our auditors concern is that any individual that can change UDC's, can change any UDC, and they would like this restricted. How have others restricted this access?

Corky,

we have made UDC maintenance a CNC function due to the potential impact of deleting a UDC code. Users submit Add/Change requests when needed.

Regards,

Larry,
In your opinion is this the standard way to maintain UDC's? I have a case opened on this but I'm just trying to find out what the norm is.
Thanks,
Corky (CNC)
E1 8.9 SP2 upgrading to 8.9.4 in the near future.
AIX/Oracle, JAS, Citrix

I second Larry's means to control... If it's not a CNC Function - it needs to be made the monopoly of an audit function (and someone that understands the big picture).

(db)

In our case UDC value maintenance is restricted to the centralized application support team. This team provides second level application support to our field offices and are the only ones with access to the UDC values themselves. A small number of selected field users (one or two per field office) are allowed to assign new UDC values to objects like accounts or business units, but no one in the field can edit the values lists themselves. New UDC values are requested through the same central support group, who must approve the new value before adding it to the system.

Good luck!

Jim,
How have you restricted the small number of field users to only being able to add UDC's for specific objects? I was under the impression that row and column security for UDC's was a bad idea. I am interested in the method you used to secure this because I have 1 group in the EAM area that are adamant that having the CNC's or a support team maintain the UDC's will not work for their area since they enter 100 - 200 UDC values each day for the 12/ST.

Any suggestions or comments welcomed.
Thanks,
Corky

Not knowing what release you're on, there is table security at the row and column that will limit access in E1. If you are on E1 8.10, there is also version security that limits what version can be run.

corkyj <[email protected]> wrote:As part of meeting SOx requirements our auditors have said we need to tighten security on users who can add or change UDC values. Currently I have about 10 manager type roles that have this functionality. Our auditors concern is that any individual that can change UDC's, can change any UDC, and they would like this restricted. How have others restricted this access?

We have restricted what a user can modify on the UDC. We have created versions of the P0004A that allow access to certain UDCs. Then using Application Version security (type 3), only allowed these certain users to these versions, and locked down the Prompt for Version and changing Values (type 5), locked down the alias RT and alias SY columns (type 2) so these columns are view only.

Hi Corky.

We do not have any row security on the UDC table. I, too, have heard multiple times from JDE/PS/Oracle that UDC row security was strongly discouraged.

No one outside of our central support team has access to edit the UDCs themselves (P0004A). For most users it is secured out. In key areas like business units, branch plants and the chart of accounts we use column security to prevent changes to the assigned UDC value (P0005S). Only a handful of screens are involved. Each location has one or two users who can selected new values. In our case the UDCs on business units change frequently. The field can plan for new values and submit them in advance to be added the system. We allow selected users, typically the local support team or key super users, access to these columns for update.

If your users need to add 100 to 200 new UDC values daily I would still restrict it to two or three people. That volume is not so great that it could not be funneled to one or two users. And if they are adding that many there must be a convention used to create them. It may even be possible to preload a lot of values based on your naming conventions, reducing the daily maintenance. Some user process changes could be required also. But the UDCs are too sensitive an area to leave at risk.