tag:blogger.com,1999:blog-4311640442921669554.post4982573672455462126..comments2022-11-03T06:31:36.077-07:00Comments on ERP Risk Advisors blog: Ad hoc SQL statements in Production environments by a developerUnknownnoreply@blogger.comBlogger6125tag:blogger.com,1999:blog-4311640442921669554.post-12895030711201414682011-11-03T07:32:27.288-07:002011-11-03T07:32:27.288-07:00Anonymous,
Some thoughts...
First, the GL interf...Anonymous,<br /><br />Some thoughts...<br /><br />First, the GL interface table has a form in 11i to fix the issues. Users should be correcting the issues themselves.<br /><br />Second, mitigating controls - users should review the journal entries after they are fixed - or may be approving them via the journal approval workflow. Apart from that you have all the financial close controls - budget to actual, flux analysis, reconciliations, etc.<br /><br />If you feel comfortable with the F/S close controls you are probably ok from a SOX perspective. <br /><br />One recommendation you may have is to make the users fix the issues with the GL interface JE correction form. I totally agree that the DBAs and/or developers should not be the ones to make the fixes.Jeffrey T. Hare, CPA CISA CIAhttps://www.blogger.com/profile/13323748862907193430noreply@blogger.comtag:blogger.com,1999:blog-4311640442921669554.post-4129397507660290642011-11-03T02:31:37.092-07:002011-11-03T02:31:37.092-07:00I hope its not too late to comment ...
In the env...I hope its not too late to comment ... <br />In the environment I work in, we have plenty of customization to the EBS, so we get a more then a fair share of errors and records stuck in interface tables (GL) due to the not so perfect implementation... Until we fix these core design issues, DBAs and sometimes developers are going there and releasing these records one by one... As an Auditor I cannot see how I can mitigate that risk, and hence I just accept it as risky as it might be... any suggestions ??Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4311640442921669554.post-45182064691812959732011-03-18T05:52:46.060-07:002011-03-18T05:52:46.060-07:002 comments - One ask your company how they would e...2 comments - One ask your company how they would explain this action with documentation to an auditor. Secondly - Without documentation of the action that occurred, supposed 6 months from now, someone determines the action taken to make the change was incorrect. How do you get back to the original data? You don't have the code documented to reverse the changes, and with out some documentation of what was changed, you can be sure you have reset the same record IDs.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4311640442921669554.post-27128161614730987512011-03-18T01:27:18.224-07:002011-03-18T01:27:18.224-07:00Not to mention the high risk of data corruption di...Not to mention the high risk of data corruption directly in your production instance and as this has potentially been done in an unsupported manner you may not be supported by Oracle.Anonymoushttps://www.blogger.com/profile/04530247324810230473noreply@blogger.comtag:blogger.com,1999:blog-4311640442921669554.post-15845746796403651732011-03-17T09:15:19.103-07:002011-03-17T09:15:19.103-07:00At my company, we allow the Oracle developers and ...At my company, we allow the Oracle developers and a few analysts read-only access to the production database. Only the DBAs get write access. Anything developed by the programmers is tested in a test instance first, signed off on by an end-user, and moved to production by one of the DBAs.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4311640442921669554.post-70966855573698999112011-03-16T14:30:39.544-07:002011-03-16T14:30:39.544-07:00And I might add... should be subject to DBA and/or...And I might add... should be subject to DBA and/or developer peer review.Jeffrey T. Hare, CPA CISA CIAhttps://www.blogger.com/profile/13323748862907193430noreply@blogger.com