On the shop floor people use a “generic” login account. We do this as our shop floor employees need to login in multiple locations on the shop floor(shipping area and at their bench). We limit sessions to 1 except for this one “generic” account. This approach is working well for us, although any recommendations on better approaches would be appreciated.
The problem we are being asked to solve is we don’t want this “generic” account to access the full version of Epicor, as we loose traceability in regards to who did what. Any advice?
We do something similar with control at the workstartion, but because our supervisors want to be able to log in on those machines, we can’t do what @JasonMcD suggested.
We used the Menu & Security Groups to pigeon hole our MES users accounts to only a few menu options like Issue/Return material, cycle count tag entry, etc. - things they are allowed to do out on the plant floor.
like @MikeGross said, you need to assign the MES ONLY login to a security group that doesn’t have access to all the menu items, or only menu items that are trackers, etc.
Also, as @JasonMcD points out, you NEED to secure EVERYTHING in the system. Not just folders. This is a common mistake / assumption that people make that “if they can’t see it, then they can’t run it”… the problem is, if they have a dashboard that lets them into the PART Tracker, They can get into just about any screen from there. They can right-click on the Part Class, then right-click on the GL info, and keep following down to the Payment entry, Receipt entry, or any other program that has not been secured. The only way to properly secure each program is to secure it with a security group.
Good discussion guys. Yes, I agree with both of you @JasonMcD@timshuwy - security is so granular and everyone’s needs are so diverse that the ONLY way to do it properly is a combination of all of the above - and maybe a good edit of the Process Security tree as well. I’ll have to double check some things because it’s been a long time since I was looking deeply into this, but our MES user security groups have some specific denials, and very limited access to anything but the few buttons on the MES screen that are allowed by there Employee setup (Material handler, etc.). I’ll need to go look at some of the right-click stuff like Open With, and see if I missed anything.
We’re a bit odd in that almost all of our folks have multiple duties, so securing everything in a ‘binary’ model just won’t suffice, but I’ll tell you that using the ‘sieve’ model isn’t any easier (lots of ‘holes’). LOL!
so one of my rules for Menu security is to assign EVERY menu option to at least one group. That way, if you create a user, and do not assign a group to the user, they see nothing. I like to implicitly “allow” the menu options that they should see. it takes the guesswork out of what someone will see. I also like to define a security group for ERP_Team that has the special options that only really knowledgeable people can run.
LOL! How long does that take? And How many groups do you create? I think that might get quickly out of hand given some of the granularity our managers wanted around here (that I successfully quashed btw).
You still get the employee ID recorded even if the user is the same for all records the employee ID would be different. Epicor doesn’t do a great job of exposing that. Example if you look at Part Transaction History tracker you will see the same user over and over. Look at the PartTran table and you’ll note the employee ID was also captured, just not exposed in the UI.
Biggest issue with this is when you start using Workstation’s with an assigned Label Printer, Paper Printer and back in the days with Insite Manifest… Let’s say a Material Handler comes and logs in as HH01 and doesn’t logout, suddenly all Labels would go to the HH01 assigned Workstation and not the MES01 for example. Just a heads-up.
Appreciate it sir Luckily those folks don’t cross over the functional borders for us yet, and we don’t print labels for WIP (no finished goods until last operation) so labeling is quite easy and in a single location for us - for now…
This is great, this is exactly what we want - traceability in regards to who made what transactions!! I attempted to customize Part Transaction history to show the PartTran.EmpID, but unfortunately I don’t see that field listed. The EpiBinding is to PartTranHist(is this a view?), that is it doesn’t appear to be bound to the PartTran table…
I ran into the same problem. I just rebuilt it with a couple dashboards. One that is the classic transaction history tracker by part, and another that does it by bin. If we are on the hunt for something (usually to fix an issue) we use mine otherwise we in general use the OG screen.
If I remember I did a POST Directive on Erp.PartTranHist.RunPartTranHistory and simply hijacked one of the fields I never planned to use PCID2 and put in the EmpID – then changed the label.
EDIT
I modified the EntryPerson and simply added EmpID to it.
LOL! How long does that take? And How many groups do you create? I think that might get quickly out of hand given some of the granularity our managers wanted around here (that I successfully quashed btw).
Luckily those folks don’t cross over the functional borders for us yet, and we don’t print labels for WIP (no finished goods until last operation) so labeling is quite easy and in a single location for us - for now…
