× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



We chose:

GELMAS, TEMGEN, MBBFREP, DCPMST <non-mapics file for discounts>, PSFMST
<non-mapics file for price sheets>,
RPTWTRFK/FL/FM/FT/FX for our financial statement formats.

ten files in all.

Your choices look good too!

Greg

-----Original Message-----
From: Burns, Bryan [mailto:Bryan_Burns@xxxxxxxxxxxx]
Sent: Wednesday, July 30, 2008 12:39 PM
To: MAPICS ERP System Discussion
Subject: Re: [MAPICS-L] Change Management

Greg,

Would you mind telling us the 11 files?

I'm going to propose to management that we use your approach and journal
the following files:

GELMAS, TEMGEN, MANPAY
ARTRAN, ARHSTS, OPNPAYM,
OPNPAYP, OPENAR, CHECKA,
CHECKB, and CHECKC.

Of course, I'm going to ask Accounting for their input.

Thanks,

Bryan Burns
iSeries Specialist
ECHO, Incorporated
Lake Zurich, Illinois

-----Original Message-----
From: mapics-l-bounces@xxxxxxxxxxxx
[mailto:mapics-l-bounces@xxxxxxxxxxxx] On Behalf Of Greg Wenzloff
Sent: Thursday, July 24, 2008 8:19 AM
To: MAPICS ERP System Discussion
Subject: Re: [MAPICS-L] Change Management

Bryan,

We designated 11 MAPICS files as being financially significant for SOX.

Then we journalled those files.
We run a nightly program to read the journal and list whenever anyone
with *allobj authority touches one of them.
If they are touched then justification is required.
The controller signs this daily report.

SOX auditors are OK with this arrangement.

Greg

-----Original Message-----
From: Burns, Bryan [mailto:Bryan_Burns@xxxxxxxxxxxx]
Sent: Thursday, July 24, 2008 9:03 AM
To: MAPICS-L@xxxxxxxxxxxx
Subject: [MAPICS-L] Change Management

We'll be undergoing an internal controls IT audit later this year and
like a lot of small shops, our MIS staff has *ALLOBJ special authority
in their user profiles. In addition, all our AMFLIBx files have
authority for *PUBLIC as *CHANGE. Because our users don't have a
command line and we control ODBC updates through an exit point package,
*PUBLIC having *CHANGE to files isn't an issue. But the MIS staff
having *ALLOBJ to production files and being able to DFU any one of them
is an issue.

I believe there're at least 3 ways we can approach this:

1. Implement object level authority. (This is something management
really doesn't want to consider).
2. Run a nightly program to GRTOBJAUT of *EXCLUDE for every object
in our production libraries for every MIS user profile. In addition,
remove *ALLOBJ special authority from the MIS user profiles.
3. Implement a third party package like Authority Broker from the
PowerTech Group.

Have any of you had a similar security set-up as we have and had to
comply with Sarbanes-Oxley regulations or something similar? If so, I'd
like your input on the three approaches above or any other approach you
might recommend.

Thanks in advance,


Bryan Burns
iSeries Specialist
ECHO, Incorporated
Lake Zurich, Illinois


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.