Re: field by field security -- BPCS-L

We are on version 405 CD - mixed mode.

You may have to compromise between what you want & what is practical.

This sort of issue should have been decided before your company selected 
BPCS, but I recognize that sometimes there is a change in management that 
wants stuff from the existing ERP that is contrary to the philosophy of that 
ERP.

I agree that there is no field level security on BPCS like there is in some 
other ERP packages such as MAPICS, that control who may access certain fields 
that you might want to keep confidential.  There is some granularity of 
security to control who may run which BPCS programs, get into which 
facilities, do what kinds of transactions, etc. but not what you are looking 
for.

You can block people from seeing anything in the General Ledger, Costing, and 
other modules, narrowing their access to specific programs.

We have some users who can only run a very narrow selection of inquiry 
programs.

We use IBM 400 secondary user groups to control who has certain kinds of 
security ... a new person needs a certain level - we do not have to figure 
out how that was done, we just add them or subtract them from these secondary 
user groups. 

Such as being able to see the contents of someone else
reports
job logs
copy a query that is not in your library list

I have some suggestions however, that I think are practical so long as the 
numbers of programs you want this for are relatively small, and you have 
access to BPCS source code or As/Set equivalent, and some way to generate 
reports or inquiry off of BPCS data base without being restricted to using 
BPCS programs.

We use query/400 heavily where a small group of people create the queries & a 
large group of them use them.  To the degree that you can transfer the users 
who are not supposed to see cost price data to using queries, or some other 
AS/400 tool to access BPCS data, then you can control what they can see by 
combination of what goes on the queries that they run, and a naming 
convention that ties into BPCS security.  

Enforcing this can also be a nightmare.  The people who create queries, and 
CL to run the queries ... they have to know who is allowed & who is not 
allowed to see cost/price data ... then when management moves users between 
the groups, you have to have mechanism to implement such requests without a 
big hassle.

It can be done with good naming conventions that tie into SSA Security.

For example, a BPCS program is named ABC123 - 3 letters 3 digits
one of our queries is named ABC#AAAA - 3 letters 1 digit for type of query 
(inquiry, report, intermediate file) - then letters related to what it is 
doing - with a similar naming convention you might have ABCC____ where the 
first letter after the 3 letters is for CONFIDENTIAL contents like cost/price 
& so long as your query managers stick to this naming convention, then you 
can use standard SSA security to control who has access to the CONFIDENTIAL 
queries.

Anything in this software is not a problem when you upgrade BPCS - the only 
problem is enforceing your naming convention.

Think 2 versions of some program, say like ORD300 has price details.
ORD3H might have everything that is on ORD300 except price.

Now I have trouble imagining where you would want people looking at customer 
requirements & not seeing price, and there is the risk that someone who is 
not authorized to see this info is communicating with customer & cannot tell 
customer what customer needs to know.  So there will be a lot of programs 
where it is obvious that people either have access or they do not, there is 
no in between.

The users who you do not want to access price on ORD300 would be security 
blocked from running ORD300 but allowed access to ORD3H.
The vanilla menus would be left intact, but the user menus would have ORD300C 
& ORD3HC contiguous choices.
For each program that you want to block this info, it will take you a while 
to get the modification functional - this is not a trivial task.

Now when there are version upgrades, BMRs etc., you have the challenge of 
getting the new code into your ORD3H clone, and every other variant you have 
out there.  If you are not careful, this can be a modification maintenance 
nightmare.

On INV100 we have had similar challenge.
We do not do our costs in INV100 because CST100 handles that.
We have recently started putting our prices there, after experimenting with 
some alternatives.
We have some user fields for our own purposes (literals altered) & certain 
people only maintain those user fields. 
Purchasing dept maintains what vendor we get raw materials from.
Engineering dept maintains most of the data there.
Some people in some departments see some fields that appear blank in the 
items that they are maintaining & they start to populate them with stuff that 
is helpful to their departments without consulting people in other 
departments, or studying help explanation what those fields are for.

Solution was for certain people placed in charge of certain files - they make 
the rules.

> Subj:  field by field security
>  From:    MAndreen1@aol.com
>  
>  Good  afternoon,
>  
>  We are on version 6.1 --- mixed mode. We have identified some cost/price 
>  fields that we require to be blank during inquiries by specific users and 
>  also blank on standard, vanilla BPCS printed reports again by specific 
users.
>  
>  Also from a maintenance perspective we require limited capability on a 
field 
> 
>  level basis--- for example: on INV100 we wish to have specific users 
> maintain 
>  only certain fields but not have maintenance capability throughout the 
> entire 
>  seven INV100 screens. Two SSA HelpDesk employees as well as our SSA 
> technical 
>  support expert have advised that there is no field level security within 
> BPCS 
>  nor any add-on tools that allow field level security support. We do not 
wish 
> 
>  to modify all the corresponding BPCS programs which utilize these 
cost/price 
> 
>  fields ---- since we will probably eventually upgrade to future BPCS 
>  releases.  However, they did recommend this forum for feedback. Any 
>  suggestions would indeed be appreciated. 
>  
>          have  a  World  Class  day                            Curt


MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
AS/400 Data Manager & Programmer for BPCS 405 CD Rel-02 mixed mode (twinax 
interactive & batch) @ http://www.cen-elec.com Central Industries of 
Indiana--->Quality manufacturer of wire harnesses and electrical 
sub-assemblies - fax # 812-424-6838

+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---