As you can see, we have three User IDs that need access to two separate Departments: 10380 and 10385. These three User IDs handle the budgeting to and reporting of costs to the two Departments. If USER3 were to leave the organization, the Role is still intact and can be changed when the replacement of USER3 arrives.
If USER3 changes departments, just change their Role Relationships. No need to go in and change the User Security.
(Hint: Use the Organizational Structure Inquiry/Revisions, P0050, to help you build your organizational structure diagram, get the way that accurately reflects your organization and then construct your Business Unit Security using that framework.)
This same methodology can be used for all types of Row Security. We also used it to limit access to certain Object Accounts. In the above example, USER2 and USER3 are at the executive level. They need to see the information for all General Ledger Accounts within both Departments. USER1 is at the administrative level and should be restricted from seeing Accounts that contain Salary and Wage information – this is particularly true in very small departments (three people) where a little math could divine the salaries of your co-workers, at least in total.
The Role, AL_EXCLS_W, has the following exclusions:
As you can see from a partial listing of the Chart of Accounts shown below, the only Account that USER1 with the Role AL_EXCLS_W has assigned to them is the S & W (Salaries and Wages) for Temporary Clerical workers. They need this type of access to verify the charges on the incoming Invoices from the temp agencies.
With standard JDE, you can only go one level. When using ALL Out Security, you can build hierarchical levels.
In my next post, I’ll be discussing the uses of Super Roles.