how to keep Journal Entry Approval History

Goal
You have recently setup automatic journal entry approval would like to report on the date and time of
approval and the approver name. Where is the history for the journal approval? Which tables store this
information? i.e Journal name, requestor, approver name, approve time and date.

Solution
The journal approval process is designed primarily to control the posting of journals only after the
appropriate approvals have been obtained, so audit is not its main function.

Journal approval doesn't provide an audit trail nor does it store the approver information in the journal or
the GL tables.

If you look at the workflow notifications associated with the routing of the journal approval process, you do
get some information on who originated the entry, who needs to approve it, whether it has been approved
or rejected etc. and this can serve as some form of audit information.

However, if the approval went through a multi level chain, you will not necessarily get a clear and complete
picture of the entire routing through the notifications

The related tables to get some information on this are as follows:

WF_NOTIFICATIONS
WF_ITEMS
WF_ITEM_ACTIVITY_STATUSES
WF_PROCESS_ACTIVITIES

You can run the following SQL scripts in sequence and check the results that you need.

Select * from wf_notifications where message_type = 'GLBATCH'

Select * from wf_items where item_key = '&item_key'

Select P.PROCESS_NAME, S.*

from wf_item_activity_statuses S,
wf_process_activities P
where item_key = '&item_key'
AND P.INSTANCE_ID = S.PROCESS_ACTIVITY
order by begin_date, end_date

Apart from this, there are no other options to check any of the data you would want to report on.

-----------------------------------------------------------------------------------------------

Note :- 1) You would not be able to track the approval data if you purge of workflow table data. 2) If you
wish to retain the approval data you may need to perform a customization / archeive the workflow data

Source:

http://dasarinarasimha.blogspot.com/2009/06/how-to-keep-journal-entry-approval.html

http://bansibaba.blogspot.com/2011/07/

http://rushikeshranade.blogspot.com/2011/
--Useful sql scripts related to Journal approval workflow
--A. How to find versions of files in gl workflow?

select text from dba_source

where name = 'GL_WF_JE_APPROVAL_PKG'
and text like '%Header%';

This will show versions of files:

glwfjeas.pls
glwfjeab.pls

B. How to check if the package is valid?

select OWNER,OBJECT_TYPE,OBJECT_NAME,STATUS
from dba_objects
where object_name='GL_WF_JE_APPROVAL_PKG';

C. Use the following SQL to obtain the item_key and item_type for a Journal
BatchApproval workflow:

SELECT item_type,item_key
FROM wf_items
WHERE user_key = 'Journal Batch Name';

D. To check if the workflow process exists or not

select *
from wf_notifications b
where b.subject like '%ournal batch%'
or begin_date like to_date ('01012017', 'dd/mm/yyyy')
and rownum < 5

or b.recipient_role like '%Approver_name%'

E. To check the approval status of the batch

/* Formatted on 9/25/2017 4:22:28 PM (QP5 v5.136.908.31019) */

SELECT distinct
b.JE_BATCH_ID,
h.je_header_id,
B.NAME BATCH_NAME ,
H.NAME JOURNAL_NAME,
b.CREATION_DATE,
cr.USER_NAME created_by,
ps.USER_NAME posted_by,
-- b.approval_status_code,
-- b.status,
-- b.budgetary_control_status,
b.posted_date
-- h.status,
-- h.posted_date,
-- h.accrual_rev_status,
-- l.gl_sl_link_id
FROM gl_je_headers h, gl_je_batches b, gl_je_lines l, fnd_user cr, fnd_user
ps
WHERE -- b.je_batch_id =
:batch_id
-- b.je_batch_id = 1539326
B.NAME = 'Manual 1639309 31-JUL-2015 10:25:45'
AND b.je_batch_id = h.je_batch_id
AND h.je_header_id = l.je_header_id
and b.created_by = cr.user_id
and b.posted_by = ps.user_id
-- AND B.ACTUAL_FLAG = 'B'
-- and rownum < 5
--AND UPPER(H.NAME) LIKE '%MANUAL%'
-- and b.creation_date between '01-APR-2017' and '05-SEP-2017' ;
How To Check The User Which Posted GL Journal Batch (Doc ID 2203939.1)

APPLIES TO:
Oracle General Ledger - Version 12.1.3 and later
Information in this document applies to any platform.

GOAL

How to check the user which posted GL Journal Batch.

Able to extract posted_date from gl_je_headers, but need to find also the user which
posted the related journal.

SOLUTION

From GL_JE_HEADERS table, check the LAST_UPDATED_BY field, which is the last
person who made some changes.

From GL_JE_BATCHES table, check the POSTED_BY field, which represents the user
who posted the journal batch.

a.
Select gjb.je_batch_id, gjb.creation_date, gjb.created_by,
gjb.last_update_date, gjb.last_updated_by, gjb.posted_date,
gjb.posted_by, gjb.default_period_name, gjb.*
from gl_je_batches gjb
where gjb.name = '&batch_name';

b.
Select gjh.je_batch_id, gjh.je_header_id, gjh.creation_date,
gjh.created_by, gjh.last_update_date, gjh.last_updated_by,
gjh.posted_date, gjh.period_name, gjh.*
from gl_je_batches gjb, gl_je_headers gjh
where gjb.je_batch_id = gjh.je_batch_id
and gjb.name ='&batch_name';
c.
select gjb.posted_by, fu.user_name
from gl_je_batches gjb, fnd_user fu
where gjb.posted_by = fu.user_id
and gjb.name ='&batch_name';

Hint:
-----
To find the batch id and header id for one specific journal:
Help->Diagnostic->Examine.
Specify Block Name : HEADER and Field:JE_BATCH_ID
Specify Block Name : HEADER and Field:JE_HEADER_ID

-------------------------------------------------------------------------------------------------------

Oracle EBS Journal Entry Approval Workflow R12.1.3

http://blogs.perficient.com/oracle/2015/12/15/oracle-ebs-journal-entry-
approval-workflow-r12-1-3/

The intent of this document is provide the reader with a fundamental understanding of
Oracle’s Journal Entry Approval Workflow enriched with lessons learned from actual
implementations. Matt Makowsky is an Oracle Financial Applications Consultant with
17 years experience and a Senior Solutions Architect with Perficient. Feel free to ask
him any questions in the comments section below the blog.

Oracle’s Journal Entry Approval Workflow enables what in many companies may be a
key SOX control:

 prevent unauthorized journals from posting into your ledger

 prevent unsubstantiated changes to financial statements

The control does this by ensuring journal entries are reviewed by supervisors to verify
the journal is complete, accurate, and has supporting documentation.

Journal Approval works as follows in EBS:

1. A journal is created in EBS (or uploaded via WebADI)

 2. The user clicks the “Approve” button on the journal form (note, if submitted via WebADI, the user must query the journal up in the
core forms to submit for approval)
3. The approver, typically the user’s supervisor as defined in Oracle HR, receives a notification with the ability to review the journal,
and then approve, reject, or ask for more information.
4. The workflow will move to the next supervisor if the value of the largest journal line is greater than the supervisors approval
threshold.

Those are the basics, but under the hood there are a lot of mechanisms in motion to
make it all work.

Enabling Journal Approval: The basics

Journal Approvals can be enabled easily with the following basic setups:

1. For a given ledger (primary or secondary), navigate to the setups and “Enable Journal Approval”
2. Review your Journal Sources, and enable Journal Approval for a given source – turn it off where journal approval is not required
(ie: subledger journals from Receivables, Assets, Payables, and so on)
3. Add Approvers and “signing limits” into the system by ledger.
4. Set profile options to enable/disable “preparer can approve own journal” – if enabled, the preparer can approve their own journal,
providing they have the signing limit for the journal.

Best practice is to disable this capability, to prevent people from splitting journals for the
purpose of self approval.

Points to remember:

 Journal approval is conducted at the journal batch level. The highest journal line value across all journals within the batch will
determine the supervisor.
 Journal approval looks at amounts, not accounts. To look at accounts, customization will be required.
 Journals will always go up the supervisor hierarchy, although there are options to “go direct” or to move up through the
hierarchy. If going direct, the journal will skip anyone who would not have signing authority, as determined in the signing limits
definition.
 Be sure managers have remote access to email and email is enabled for month end approvals.
 Appoint a workflow administrator to reassign workflows in the event an approver is absent and has not set their vacation rules.
 AME is not available for Journal Entry Approval as of 12.1.3. Customization must be done through workflow.

Pros and Cons of Implementing Journal Workflow

Pros

1. Enables and simplifies a key sox control.

2. Electronic signatures, governed by the system, are more easily audited.
3. Prevents forgery of approved documents and loss of offline data.

Cons

1. Month End process can be slowed if approvers are on vacation or out sick.
2. Limited functionality in standard approval rules.

Implementation Recommendations and Considerations

 1. The size of your accounting department, the number of managers, the number of approvals needed
o Avoid situations where multiple approvals are needed, especially at month end, enabling “unlimited” authority for most
managers.
2. Consider other controls to prevent over burdensome approvals
o Mass Allocations and Recurring Journals- disable approvals for mass allocations, provided that the forumlas are
“locked down” to select users (supervisors and managers)
o Sub Ledgers – disable approvals. The source of the activity has already been approved, or was otherwise generated
with other system controls in place.
o Freeze all subledger journals to prevent changes and out of balance control accounts.
o Disable approval for automatic reversing journals (controlled by profile option)
3. Create workflow reports
o Monitor the status of unapproved journals
o Audit Preparer vs. Approver to check on “system gaming” if preparers are allowed to approve own journals. See who is
approving their own journals on a regular basis.
4. Enable Auto Post and Schedule it Frequently (often at Month End)
o Auto Post simplifies the record to report process, by posting journals automatically (as the name suggests) if the journal
has an approved status or does not require approval.
o Auto Post reduces redundancy in process. Consider that once approved, a journal is expected to be posted. Let the
system manage the process from Approval to Post.
5. Customization
o Avoid unnecessary customization, balancing business requirements against the technical complexities.
o Be flexible and look for functional solutions, using reports or other controls before customizing the workflow.

In summary, Journal Approval Workflow can provide huge benefits to your enterprise:
Control over and Insight into your process. Prevent simple accounting errors, and
streamline your month end process. Combined with Auto Post, implementing approvals
can fundamentally change the way your finance team does business.