Row Security implementation

[jimmymac]

Greetings,

We are on a JDE E1 9.0 environment and use G/L and A/P and have a multicompany environment. We are converting some data and will be adding additional companies that will be managed by a separate accounting group. We have a requirement that our two accounting groups cannot see or process the other groups companies. Basically so that someone in one accounting group wouldn't fatfinger and accidently key in a journal entry for the wrong groups company.

So it would seem row security would be the best practical solution and appreciate feedback. Reviewing the documentation it seems it would be basically a matter of adding security workbench entries for row security and defining the company range that would be excluded. Set it up for files F0911, and perhaps F0901 and F0902. The view/add/change/delete options would be all checked N, and it would be defined by role. So depending on the role of the user they would or would not be allowed to enter journal entries for a particular company.

We have more to set up than just that but in terms of preventing an unwanted journal entry for a company, that would see to be the basic idea. Is there anything else obvious I might be missing?

Thanks, and appreciate any comments.

 

[Oliver]

Hi,

The one obvious missing process is how to troubleshoot if you apply row security and it does not do what you intended it to do?

I have checked on oracle kb and i found this document that might be helpful:

E1: SEC: Troubleshooting Issues with Row Security [ID 648423.1]

Hope this helps.

 

[pfd]

The logic seems alright. One thing to be aware of is that the batch header (F0011) does not have a company field. So when they create batches and if they post the batch it could update F0011 but not F0902.

Thanks,
Matt

 

[Luke Phillips]

Check that you dont allow your users to sign in with individual roles (rather than forcing *ALL). If you do (and need to) I have a fix.

Otherwise, what you say sounds the best way forward for you in my view.