GL: Statistical Journals -- not suppport by journal approval workflow

I saw this question on OAUGnet and thought I'd respond to it...

"Can anyone verify this: In R12 G/L, the seeded Journal Approval workflow (WF) will not route a statistical journal for approval regardless of the journal's source."

Here is what I found in My Oracle Support
MOS [ID 1076823.1]
"Currently Statistical journals do not require approval as per standard functionality.

The only limitation you can make is that you can use the profile option Journals: Mix Statistical and Monetary to prevent STAT and monetary lines on the same journal.
It is not possible to restrict entry of STAT lines by user."

Not really sure I understand how this profile option 'limitation' addresses the issue, but it is there nonetheless... Sometimes support analysts just hate saying "no Oracle doesn't provide that functionality"...

Regards,
Jeffrey T. Hare, CPA CISA CIA
ERP Risk Advisors
http://www.linkedin.com/in/jeffreythare
send me a linked in request - jhare@erpra.net

Does your organization maintain proper workflow history?

Reviewing docs for a client today and ran across this comment in a document "I believe that there are audit reporting requirements to provide evidence of workflow approvals of changes to compensation or position-related edits"

Question: Does your company property maintain workflow history for approvals? Let me help with another question to ask your DBAs - how often are workflow history tables purged? Your homework for the day...

Based on my experience, many organizations do not have the evidence for such approvals if an auditor asks for this type of history.

I have enabled anonymous comments to protect the identity of those responding. Please respond anonymously with any comments.

Ad hoc SQL statements in Production environments by a developer

I had a client email me today the following:
"Is it normal to have IT dev/support group run SQL queries in production to fix errant/stuck data in an Oracle EBS shop? As an example have an data issue that is listing the load weight as 0LB and have IT fix that through an SQL query directly in production?"

Here was my response:
"No. This is not normal for two reasons:

1. Developers should not have access to run scripts in Prod. Any scripts should be developed by the developers, executed by the DBAs in a non-prod environment, tested by an end user then executed by the DBAs in Prod.

2. May or may not be an issue... SQL scripts can either be supported or not supported by Oracle depending on how they are written. If they call a public API, generally they are supported. If there is no public API, Oracle should be providing the data fix script. Otherwise, they'll not support it and the execution of it may void your support agreement."

Top 10 Fraud Risks in an E-Business Suite Environment

Great response to Top 10 Fraud Risks in an E-Business Suite Environment. Had some technical difficulties with GoToWebinar (a first for me). Not sure if the full webinar was recorded. Will try to post this our website as well as the slides as soon as possible. May be doing a follow up webinar.

Thanks to Steve Kost from Integrigy for hosting today's webinar.

Regards,
Jeffrey T. Hare, CPA CISA CIA
jhare@erpra.net
LinkedIn Profile

Great piece: Matt Taibbi's Latest: " Why Isn't Wall Street In Jail?"

Highly recommend this read:
http://www.zerohedge.com/article/matt-taibbis-latest-why-isnt-wall-street-jail

For those of you that spent countless hour preparing for Sarbanes-Oxley compliance and labored night and day, rest assured... it has accomplished nothing... Your only consolation is that is many of you have found gainful employment because of of SOX.

Actually, to be fair, SOX has greatly increased the awareness of, documentation of, and execution of internal controls for many organizations. It has not, however, helped cure the systemic fraud which was part of what lead to SOX.

Regards,
Jeffrey T. Hare, CPA CIA CISA

Oracle's E-Business Suite: Overly complicated security model!

Oracle has its feet firmly planted in two security models - the 'legacy' model is that often referred to as Function Security. The 'new' model is what Oracle attempted to evolve into an RBAC model using the User Management module. What they have created is an overly complicated mess that frustrates even the most experienced security administrators.

One frustration is the background process that 'synchs' the data between the two models (there may actually be more than two...) For example, a responsibility made in the Users form doesn't show up for several minutes in the home page that you receive when you log in. And new functions added to menus often aren't 'available' to be used for several minutes after they are added to a menu.

While I hope Oracle doesn't make the same mistakes in the development of its Fusion apps, those companies planning to continue using Oracle's E-Business Suite have a rude awakening... Oracle continues to make its security model more complicated and frustrating. Double the time you anticipate developing security in your R12 implementation or R12 upgrade. You'll need it to troubleshoot issues...

Why doesn't Oracle provide view only access to their data via forms???

I'll continue to say it... Oracle doesn't have a clue how to build their applications to meet common GRC and internal control requirements. Those that have followed my work for long know my feelings on this topic...

In the traditional forms development standards Oracle has provided organizations with the ability to easily create a custom "read only" form by setting the QUERY_ONLY=Yes parameter. However, in OA framework forms, no equivalent process has been provided. Why not? Because they don't understand how companies have to customize (personalize) the application in the real world.

EVERY form/web page should have an equivalent inquiry form out-of-the-box. Auditors and others in the organization such as Business Analysts need access to such data in Production environments and NOT via Discoverer, OBIEE, or another other ad hoc method.

Thanks for listening to my rants...

Regards,
Jeffrey T. Hare, CPA CISA CIA