Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Ideas for restricting access to orders by user 1

Status
Not open for further replies.

MacolaHelp

Instructor
Mar 19, 2003
659
US
One of my clients wants to have the views and transaction screens (of which there are many) set up so that users can only access customers and related transactions that are "theirs". This would not only involve arcusfil, oeordhdr, oeordlin, iminvtrx. The list is virtually endless. They don't want 2 companies because both companies sell the same items, they just pretend to the outside world they are 2 separate companies, therefore inventory management would be a nightmare. I can think of a few creative ways to modify searches, but they could still get to the data we are "hiding" by using the vcr buttons to scroll through the file or randomly type in a customer or order number they saw on someone else's desk. Short of writing a brand new front end for any of these transactions & views, does anyone have any ideas? Can any of you eSynergy users tell me if we can restrict the access to the big database by customer & user? And, if we can, do the links to order entry now exist so they can see their orders & check stock from esynergy so that I could remove their macola access? We are psql2000i & macola 7.6.100a.
 
We've done something similar and we put all of the users into the salesman table because of the UDF's. You could "code" the customers and items a company code, based on which one they are associated with. That would also assume that the customers don't cross over between companies. Each customer would be coded, either using something like the customer type or a UDF.

You would then add flex code that would check the salesman table for the company code and the customer file for the same code to see if you had rights to pull up that record.

I think the transactions would be the easier part. I think it would be more difficult to modify some of the canned reports and you would have to take them all away and do outside reporting.

Kevin Scheeler
 
The "rights" issue is the key here. What field would you use in arcusfil, oeordhdr, oeordlin, iminvtrx, ppordfil, etc, etc, to create a "right" to that record that would preclude an "unauthorized" user from viewing or editing this record? I have 5 salespeople who should see each other's orders, customers, transactions related to same including invoicing, etc. I have 8 who need to see each others stuff, but the 5 person group & 8 person group are mutually exclusive. Then I have about 30 users who need to be able to see both. When you consider how many customer lookups exist, how many routes to get to customers and orders from any of the distribution or accounting view screens, the magnitude of this creation of security controls within the program boggles my mind. I've been told by macola support (taken with a grain of salt, for sure), that you cannot do this in sql, either. For example, there is no way to allow some AP entry staff to see all vendors & another AP clerk to see only a portion of this file. For example, I don't want average AP clerk to see distributions or expense reimbursements to owners, a much simpler restriction than something involving the entire distribution suite of modules. It seems to me that if this would be done inside macola in the distribution world, it would have to be a source code mod (limiting us for future upgrades due to macola's position on release of source code in the future) or a complete VB front end rewrite. Flex, I do not believe, can cope with a project of this magnitude.

BTW, for now, our customers have 2 separate numbers for the 2 separate divisions. At some future date, I would like to get away from this, but that is far in the future.
 
You're right that there are alot of possible screens that access that data in some fashion. Understanding the reason is also important. Do they want to segregate the information to make it easier for the end user to do their job by limiting the data they have access to or is it because they "shouldn't" see those customers at all and know they exist. More for security reasons.

If it's the first reason, you can still customize highly used screens with flex that get used often which will help them do their day to day tasks and not necessarily worry if they can access the data through obscure screens.

If it's the 2nd reason, two companies is the best approach and you would have to look at doing reports that combine information from them like inventory stock levels.

Kevin Scheeler
 
It's the second reason. We don't trust our sales staff to "mind their own business", but we trust mfg & acct to respect the rules of the road. It is a security issue & I have tried to explain that the only way to achieve true "security" is to have 2 companies. Then, what about users that need access to both companies, which are the majority of my users? Without a field designated for this specific purpose or true row level security based on user id, I can't fathom how we could do this within the existing framework. Unless, of course, eSynergy will be the magic bullet . . .
 
In macola you can gave the two companies setup and give access to only one company. You can restrict access to individual companies through Macola security. The users just have to sign into the company they need to deal with at that time.

I agree that for shipping and manufacturing this could be a pain to have to schedule from two companies for the same manufacturing plant but that could be addressed with reports that combine the data from both companies.

I dont think that you are going to get what you are looking for out of Macola w/wo eSynergy.

If someone says eSyngergy will allow you to do exactly what you are looking for I would be interested in seeing it in action.

Thanks
Andy

Andy Baldwin
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top