Re: User transactions tracking in BPCS v4

> From: Lisa.Abney@universalflavors.com

>  Al ... 
>  don't see any reference to your specific example of facility security.  

I posted several e-mails with mildly different slants on the auditor interest.
You saw one that did not answer that question before the arrival of another 
one
that perhaps did, but only indirectly.

>  We run a reasonable tight shop (or we like to think so!) 
>  where users don't have access to command lines, security
>  files, programmer access, or creating DFU's 
> (although we occassionally write one for them for a temporary, 
>  limited data correction process).  

>  Where, specifically, do you see places (within standard BPCS)
>  that users at one facility can change data at another facility,
> assuming my position of facility/warehouse authority?

There are several ways that I am aware of in which the wrong facility can be 
mucked up & in fact the wrong facility is mucked up by innocent users who are 
not doing it via command line authority or DFU but from BPCS menu options in 
which I am saying that the way BPCS V4 security is designed it is not a real 
good match to OUR needs.  But our problems might not be applicable to your 
company.

We have users who are based in one facility & do lots of transactions in that 
facility & who need to do inquiry into another facility but are not supposed 
to be doing inventory transactions there.  

Now we could create for them two sign-ons ... one that can inquire into many 
facilities but not do any transactions & another that can do lots of 
transactions but only in one set of warehouses.

But I have enough trouble with people who have large scale access and leave 
unattended tubes signed on as them in places that were setup for limited 
access ... we have el cheapo display stations all over the factory floor, in 
which there is a very limited access user assigned for inquiry only ... 
arrives a user who is authorized for more, needs to do more, signs off signs 
on, does more, leaves it signed on.

I do not want to make security any more complicated than it needs to be, 
because it leads to corporate culture tension, that could compromise security 
interests.

There is an office left unlocked at lunch time.  Intruder alert varies off 
the work station there .... someone with access to system console messages 
sees vary off & ASSUMES it is a hardware problem & varies it back on ... I 
review history of system messages periodically then show the documentation to 
the occupant of the office & that office is no longer left unlocked 
unattended.

We have turn-over in a facility & users in some other facility are assigned 
to help out, like managing what shop orders need to be released, so that the 
remaining personnel in the facility that suffered the turn-over only have to 
print the shop packet material without the work up front, until the 
replacement personnel are replaced.

We have users whose job responsibility involves multiple facilities & they 
make honest mistakes.

We do not have a complete crew of all job responsibilities in the hands of 
different people at each facility.  There are people who have a mixture of 
responsibilities for a mixture of facilities.  They make honest mistakes.

There are a whole bunch of personnel scenarios that we have, where people 
make mistakes & do transactions in the wrong facility.  Now if you make an 
OOPS in the facility that you are working with ALL THE TIME you are more 
likely to notice it.

We also have had people posting transactions to the wrong warehouse within 
the same facility because of a break down in training regarding the purposes 
of the different warehouses.

I also make mistakes ... I am supposed to run a fix program against CIC 
warehouses every nite before doing MRPs, because vanilla CIC is unable to 
plan multiple warehouses in a facility ... about once every 10 days I manage 
to miss that step.

All of this stuff might be personnel issues that do not apply to your company.

----- another aspect of this ----

Due to my legacy PC I have been having a hard time getting stuff from OSG so 
today a co-worker delivered into my hands a list of which BMRs do what on 
which applications ... you might want to check on the full details in OSG ... 
what exactly is the story on BMR 14790 on SYS610 ... sounds to me like user 
not authorized to all warehouses, is in fact so authorized by mistake & this 
BMR fixes that.

Also, the latest Y2K BMRs for 405 CD include a bunch of fixes for UR354* 
programs.  What gives?  According to the on-line system functions document 
SSARUN92, UR1 thru UR5 are reserved for user-defined programs.  I suspect 
some SSA stuff has encroached into this area & then needs to be fixed.

Somewhere I said there's a security thingamagig supplied by SSA to circumvent 
SYS600 rules, but I could not remember what it was.  Scan for SYS625 in the 
on-line document SSARUN92.  As I understand the deal here, it is INTENDED for 
stuff added by programmers to BPCS collection ... we could stick in something 
that does not have one of the prefixes that shows up in the SYS600 options, 
then through SYS625 say "make access to this by the same rules as ORD or ACP 
or whatever" but someone could go in with some pre-existing BPCS job & say 
"transfer this to a different set of rules."  

Obviously if end users are not given certain access, then the number of 
people, who can accidentally mess this up by not understanding the system, is 
reduced to official MIS staff & helpful consultants.

SYS120 & SYS015 also play a role with this stuff.

There are some options I have not thoroughly tested ... I am a coward - I do 
not want to mess with that, so it is possible I do not have a complete 
picture on what all is involved.

Incidentally, at Central Industries, I have SYS-NO for 99% of our users in 
SYS600, then Yes for specific functions like the Pop-Up Menu.

Al Macintyre 
Computer Data Base Janitor etc. at Central Industries
+---
| 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
+---