Any suggestion on Security Setup by Company?


We have encoutner some problem on performing Security Setting :

We do have two companies setup in our JDE System, Company A with
Company Number 100 and Company B with Company Number 200.

Since we have users assigned only perform data entry for either one
company above, we decided to use Row Security to lock them, inorder to ensure they did not keyin wrong info to another companies, also prevent them to delete/view info from another companies (I believe this is quite a common practice, right?)

We lodge this issue before, and respond line suggest us to lock
data item "Company" for "*All" tables.

But after sometime, we realised that User can still enter data into
the company which suppose to be disable.

For example, User David are disable from Company ABC with Row Security
disable View, Edit, Delete, Add on Company with "100". But under P0413M, he still can enter data for Object Account "100.3212.PBB".

Anyone have better suggest or guideline on how we can achieve this ?

Thanks !


Active Member

We are in a similar setup - 2 companies. Besides securing the company
number, we have also included the business units (GL) as well as business
units (Inventory) which is the branch plant.

We are further departmentalised, so we even have an additional by gl class.

Hope that helps.


Sook Fun

OneWorld B732.2 SP 12.2
HP UX 11.0
Oracle 8.0.4
Citrix Metraframe 1.8
Fat clients - NT, Win98, Win95


Active Member
We had to do the exact same thing as you in that we had users who had to
be able to only view certain companies, while being able to
add/change/delete on others.
I think that the RL put you into the right direction. You would want to
first start with locking down the company alias for all tables. There are
other aliases which you may need to lock down as well, such as the
costcenter alias in the f0101 to cover address book entries. My point is
that not all tables use the company alias, some use others so you may have
to do a little digging (such as we did).
Also note in the table security, the biggest mistake most people made, and
which I made when I was learning it was how it actually works, it's not
quite as intuitive as it could be. The entries that you make in row level
security are the data ranges that you are BLOCKING from the user, not
granting. The 'holes' that are created between the values are the values the
users have complete control (add, change, delete, view, etc).
Drop me an email offline if you wish to discuss more of how we setup our


Xe, SP14.2, NT/SQL7, Metaframe 1.8


Active Member
In addition to the "company" field, we have found a couple of other data
items useful for company security.
We use a combination of the following fields:

Company (CO)
CostCenter (MCU)
CompanyKeyOrderNo (KCOO)

For the tables they can still update, check for other data items that
contain a company value. If you have XE, you can use the P80010 Browse Table
Definitions application to see what data items are in each table.


Jeffrey Nack
The Vollrath Company
OW XE SP13.1, AS/400 V4R5, CO NT SQL 7.0, WTS
Discover how to build no-code data integrations and business process automations.


Re: RE: Any suggestion on Security Setup by Company?

Thanks for your info, at least we know we are in the right direction on this matter.

Yes, you are right, some Digging will be needed inorder to work out a really tight security.

But I found some really impossible such as Voucher Match, where it update to F0413, as the table does not consist anything related to Company/Business Unit/Cost Center, and it cause some table Updated by some table not Updated when we put up the Row Security.

For example, when user perform a match for a Company that he/she not suppose to access, althoght the system shown "User Does not Authorized" as it update F0411, but the match Amount was deducted in F0413 as F0413 only refer to it parent table for Company no.

Anyway, thanks for all your info here !!


VIP Member
Hello there.
We setup 2nd company couple months ago with no issue.

Make sure you secure *All *Blank as well.