Row Security for the company fields: CO, KCO, KCOO, & PKCO

I am prototyping row security for the company field (CO, KCO, KCOO, PKCO).. I have set up a default user "MWSYSADMIN" with very broad rights to the system. i have given the USER row security rights to all companies (00000-99999) for the above fields. When I try to enter a voucher or journal entry I get a commit error for fields PKCO and KCO even though i have explicit rules that allow full capabilities to those fields. Attached you will find screen shots of the security workbench for all of my row security rules and a screen shot of the job log.

Environment: B8.10
Tools: 8.96 H1
System: Windows & SQL

Thanks for any help you can provide

Meg

Meg -

It's been a while since I have worked with company security but if I remember correctly the range you specify is the range of companies the user does NOT have access to. For example, if I have a user who should only be able to access company 00002, then I should set up two ranges. 00000 - 00001 and a second range of 00003 - 99999. By leaving 00002 out, they should have access..

Another point to note, when you tie a user to company security you also limit their access to Business Units. Since each BU is associated with a company, the company security applies to restricted BUs. If you have branch plants and BUs using the same number they will be restricted as well.

Give it a try and let me know what you find..

Thanks

I would advise against any type of security over the KCO fields. These fields are used not necessarily in conjunction with the company the transaction is for. They are used mainly to distiguish one document from another when the document number is the same. Unless security was put in place right from the beginning of implementation you may run into issues even if you get your security to work. As an example, a user may be able to key in a voucher for company 00001 but the doc company may be company 00002. If this type of voucher already exists prior to your security, the user may be secured out of seeing his or her own voucher.

Again, there is no functional reason to secure out the document company fields in 99% of cases.

Thanks for your input and i understand what your saying. My reasoning behind securing KCO comes from the journal entry screen P0911/W0911A. The field on that screen is KCO not CO. Does that change your view?

Thank you for your response. I believe you are refering to exclusive security. I am trying to implement inclusive.

Again, there is almost no functional reason to secure this field even on the P0911/W0911A. If you do, it may come back to haunt you. Like I said earlier, if you are implementing this security at implementation time, then go ahead. But if users have been working in a live environment a while, I would think again.

What you may want to do is SQL the F0911 to determine if there are transactions in which the KCO is different from the CO within the same set of journal entries. If KCO is always zero then by all means you're fine.