Oracle White Paper

How to Define Journal Approval Rules

Fusion General Ledger

Fusion General Ledger Product Management Team

Disclaimer

The following is intended to outline our general product direction. It is intended for information
purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any
material, code, or functionality, and should not be relied upon in making purchasing decisions. The
development, release, and timing of any features or functionality described for Oracle’s products
remains at the sole discretion of Oracle.

1|Page
Table of Contents
1. Introduction............................................................................................................................ 3
2. Introduction to Human Workflow Concepts ...................................................................... 4
2.1.1 Introduction to Design and Runtime Concepts ........................................................................................ 4
2.1.2 Task Assignment and Routing .................................................................................................................4
2.1.3 Participant ................................................................................................................................................5
2.1.4 Participant Type .......................................................................................................................................5
2.1.5 Participant Assignment ............................................................................................................................ 6
3. GL Implementation of participant types ............................................................................. 7
4. Available Attributes............................................................................................................. 11
5. Seeded Rule .......................................................................................................................... 17
6. User Flow for definition of the Journal Approval Rule ................................................... 18
6.1 Approval Rule Creation Process .............................................................................................. 18
6.1.1 Navigate to BPM Worklist ..................................................................................................................... 18
6.1.2 Define Approval Rules ........................................................................................................................... 29
6.1.3 Define Account Flexfield Based Approval Rules .................................................................................. 71
7. Considerations...................................................................................................................... 87
7.1.1 Rule Definition Consideration ............................................................................................................... 87
7.1.2 AMX List Builder Considerations ......................................................................................................... 87
8. Other Considerations .......................................................................................................... 89
9. Creating Job Level and Position Level Hierarchies ......................................................... 91
10. Troubleshooting ............................................................................................................... 97
10.1 Troubleshooting Details ............................................................................................................ 97
10.1.1 Overview............................................................................................................................................ 97
10.1.2 Flow ................................................................................................................................................... 98
10.1.3 Configuration ................................................................................................................................... 100
10.1.4 Troubleshooting Steps ..................................................................................................................... 100
11. Glossary ........................................................................................................................... 103

2|Page
1. Introduction

Oracle Fusion General Ledger supports flexible and configurable approval rules for journal batch
approval using the Approvals Management Extensions (AMX) of Oracle Service-Oriented Architecture
(SOA) Suite and Oracle Business Process Management (BPM) Suite. BPM provides the interface to
administer the approval rules. A BPM Worklist administrator, who is a user with the role Financial
Application Administrator, can access the approval rules in the BPM Worklist.

When the user submits a journal batch for posting, General Ledger initiates a SOA Composite instance
which evaluates the rules created in AMX to build the list of approvers. AMX then sends out approval
notifications to the approvers. AMX rebuilds the approval list each time it receives response to an
approval notification. This is repeated until all approvals are complete.

The approval rules are managed through the BPM Worklist. Users who are authorized to manage the
approval rules have an Administration link in the top right hand corner of the Worklist page.

To generate the list of approvers, each rule requires a list builder to be associated with it. The following
list builders are available in BPM Worklist.

List Builder Description

Supervisory Ascends the primary supervisory hierarchy, starting at the requestor or at a given
approver, and generates the approval chain.

Job Level Ascends the supervisory hierarchy, starting at a given approver and continuing
until an approver with a sufficient job level is found.
Position Ascends the position hierarchy, starting at a given approver's position and
continuing until a position with a sufficient job level is found.
Resource Static list of approvers. Deploying companies can choose a user name or a
function that returns a set of approvers.
Approval Group Group of approvers. Deploying companies can create approver groups consisting
of static members for use in the rule sets.

3|Page
2. Introduction to Human Workflow Concepts

This section introduces key human workflow design time and runtime concepts.

2.1 Introduction to Design and Runtime Concepts

A typical task, such as Journal Batch Approval task, consists of a subject, priority, task participants, task
parameters or data, deadlines, notifications or reminders, and task forms. This section provides an
overview of the key concepts.

2.2 Task Assignment and Routing

Human workflow supports declarative assignment and routing of tasks. In the simplest case, a task is
assigned to a single participant (user or group). However, there are many situations in which more
detailed task assignment and routing is necessary (for example, when a task must be approved by a
management chain or worked and voted on by a set of people in parallel, as shown in Figure 27-2).
Human workflow provides declarative, pattern-based support for such scenarios.

Figure 27-2 Participants in a Task

Description: This image shows the Assignment and Routing Policy section of the Human Task Editor. A
stage labeled Work appears on the left and a stage labeled Comment appears on the right. Below Work
is a block labeled Performer. Below that is a block labeled Performer’s Manager. Below Comment is a

4|Page
block labeled Performer’s Team. At the bottom and connecting to both of these stages is another stage
labeled Review. Below Review is a block labeled Review Team.

2.3 Participant
A participant is a user or set of users in the assignment and routing policy definition. In Figure 27-2, each
block with an icon representing people is a participant.

2.4 Participant Type

In simple cases, a participant maps to a user, group, or role. However, workflow supports declarative
patterns for common routing scenarios such as management chain or group vote. The following
participant types are available:

 Single approver

This is the simple case where a participant maps to a user, group, or role.

For example, a vacation request is assigned to a manager. The manager must act on the request task
three days before the vacation starts. If the manager formally approves or rejects the request, the
employee is notified with the decision. If the manager does not act on the task, the request is treated as
rejected. Notification actions similar to the formal rejection are taken.

 Parallel

This participant indicates that a set of people must work in parallel. This pattern is commonly used for
voting.

For example, multiple users in a hiring situation must vote to hire or reject an applicant. You specify the
voting percentage that is needed for the outcome to take effect, such as a majority vote or a unanimous
vote.

 Serial

This participant indicates that a set of users must work in sequence. While working in sequence can be
specified in the routing policy by using multiple participants in sequence, this pattern is useful when the
set of people is dynamic. The most common scenario for this is management chain escalation, which is
done by specifying that the list is based on a management chain within the specification of this pattern.

 FYI (For Your Information)

This participant also maps to a single user, group, or role, just as in single approver. However, this
pattern indicates that the participant just receives a notification task and the business process does not
wait for the participant's response. FYI participants cannot directly impact the outcome of a task, but in
some cases can provide comments or add attachments.

5|Page
For example, a regional sales office is notified that a candidate for employment has been approved for
hire by the regional manager and their candidacy is being passed onto the state wide manager for
approval or rejection.

2.5 Participant Assignment

A task is work that must be done by a user. When you create a task, you assign humans to participate in
and act upon the task. Participants can perform actions upon tasks during runtime from Oracle BPM
Worklist, such as approving a vacation request, rejecting a purchase order, providing feedback on a help
desk request, or some other action. There are three types of participants:

 Users

You can assign individual users to act upon tasks. For example, you may assign users jlondon or jstein to
a particular task. Users are defined in an identity store configured with the SOA Infrastructure. These
users can be in the embedded LDAP of Oracle WebLogic Server, Oracle Internet Directory, or a third
party LDAP directory.

 Groups

You can assign groups to act upon tasks. Groups contain individual users who can claim and act upon a
task. For example, users jcooper and fkafka may be members of the group LoanAgentGroup that you
assign to act upon the task.

As with users, groups are defined in the identity store of the SOA Infrastructure.

 Application roles

You can assign users who are members of application roles to claim and act upon tasks.

Application roles consist of users or other roles grouped logically for application-level authorizations.
These roles are application-specific and are defined in the application Java policy store rather than the
identity store. These roles are used by the application directly and are not necessarily known to a Java
EE container.

Application roles define policy. Java permissions can be granted to application roles. Therefore,
application roles define a set of permissions granted to them directly or indirectly through other roles if
a role is granted to a role. The policy can contain grants of application roles to enterprise groups or
users. In the jazn-data.xml file of the file-based policy store, these roles are defined in <app-
role> elements under <policy-store> and written to system-jazn-data.xml at the farm level during
deployment. You can also define these roles after deployment using Oracle Enterprise Manager Fusion
Middleware Control. You can set a task owner or approver to an application role at design time if the
role has been previously deployed.

6|Page
3. GL Implementation of participant types
(Feature introduced in Release 4)
Following 17 participant types are seeded by Fusion General Ledger. 10 participants are of parallel
type and 7 are of sequential type.

- Each participant type shown above is represented by Rule Set as shown below in the Worklist
application for journal approval rule creation.

7|Page
 Participant Routing Voting Regime
Supervisory_JournalApprovalRuleSet Serial Consensus
ApprovalGroup_JournalApprovalRuleSet Parallel Consensus
JobLevel_JournalApprovalRuleSet Serial Consensus
Position_JournalApprovalRuleSet Serial Consensus
ParallelTypeParticipantOneInParallelModeRuleSet Parallel Consensus
ParallelTypeParticipantTwoInParallelModeRuleSet Parallel Consensus
SingleTypeParticipantOneInParallelModeRuleSet Parallel First Responder Wins
SingleTypeParticipantTwoInParallelModeRuleSet Parallel First Responder Wins
FyiTypeParticipantOneInParallelModeRuleSet Serial
FyiTypeParticipantTwoInParallelModeRuleSet Serial
ParallelTypeParticipantOneInSequentialModeRuleSet Parallel Consensus
SingleTypeParticipantOneInSequentialModeRuleSet Parallel First Responder Wins
FyiTypeParticipantOneInSequentialModeRuleSet Serial
ParallelTypeParticipantTwoInSequentialModeRuleSet Parallel Consensus
SerialTypeParticipantTwoInSequentialModeRuleSet Serial Consensus
SingleTypeParticipantTwoInSequentialModeRuleSet Parallel First Responder Wins
FyiTypeParticipantTwoInSequentialModeRuleSet Serial

Participant Types are explained in 2.1.4 above.

Now what does it mean by participants in Parallel mode and in Sequential mode?
- Parallel Mode: When the participants are in parallel mode the task gets assigned and the
notifications will go to all the participants at once in parallel. And they have to approve the task.
- Sequential Mode: The task gets assigned and notifications go in sequential manner meaning
one after another to each participant in the sequential mode. All have to approve sequentially
to get the task approved.
Important Notes:
- If you are not using a particular participant in your solution you need to ignore those
participants either by checking the ignore participants checkbox or by the seeded rule to ignore
the participant.
- Except the first parallel participant Supervisory_JournalApprovalRuleSet all are ignored by
default in seeded GL solution.
- The first participant has the seeded GL approval rule covered in topic 5 below.
- You cannot change the order of Serial participant types but you can use the ones you require
and ignore the others.

8|Page
 - You can use multiple list builders under one rule set now.
- New Participants cannot be added.
- Existing Participant Order cannot be changed. This is crucial when the participants are in
Sequential mode.
- Approval Group can be used as list builders in parallel participant if all in the group needs to
approve.
- Approval Group can be used with single participant provided approval from only one person
from the group is sufficient.
- We do not yet support voting regime for an approval group.

Use Cases and its implementation using the participant types:

Use Case 1

1. You require the company’s supervisory hierarchy to approve the journal batches based on the
journal batch amount limits.
2. During the month end close period you need any one of the month end approvers to approve
the batches.
3. During the Corporate close period, along with the supervisory and month end approvers, you
want any one of the corporate approvers to also approve the batches.

- For this purpose you need to use three participant types in parallel mode. All other participants
will be ignored.
o Serial Type (Supervisory_JournalApprovalRuleSet) with supervisory hierarchy as list
builder.
o Single Type (Single Type ParticipantOneInParallelModeRuleSet) with approval group as
list builder for month end approvers (any one can approve).
o Single Type (Single Type ParticipantTwoInParallelModeRuleSet) with approval group as
list builder for corporate approvers (any one can approve).

- Use Case 2

1. You require your job level hierarchy to approve the journal batches based on the different net
journal line amount limits as:
i. Up to $1000 – M2 Job Level can approve.
ii. From $1000 to $5000 – M3 Job Level can approve.

9|Page
 iii. From $5000 to $10000 – M4 Job Level can approve.
iv. From $10000 and above – M6 Job Level can approve.
v. From $50000 and above – CEO can approve.

- For this purpose you will only require one participant in parallel mode with 5 different rules for
each condition above in the rule set. For i. to iv. you need to use job level hierarchy as list
builder and for rule v. you need to use the resource list builder.

10 | P a g e
4. Available Attributes
The following table lists a subset of the view objects and the attributes that are available for use in the
condition of a journal approval rule.
View Object in Condition
Browser
MaxJournalLineAmount
MaxJournalLineAmount
MaxJournalLineAmount
MaxJournalLineAmount
MaxJournalLineAmount
MaxJournalLineAmount
MaxJournalLineAmount
MaxJournalLineAmount
Calendar
Calendar
Calendar
Calendar
Calendar
Calendar
Calendar
MaxJournalAmount
MaxJournalAmount
MaxJournalAmount
MaxJournalAmount
MaxJournalAmount
Attribute Description
JeBatchId Internal identifier of the journal
batch.
LedgerId Internal identifier of the ledger.
Name Name of the ledger.
EnableJeApprovalFlag Flag indicating whether approval is
enabled for the ledger.
LedgerCategoryCode Category code of the ledger.
MaxLineAmountDr Maximum debit amount of the
journal batch for the ledger.
MaxLineAmountCr Maximum credit amount of the
journal batch for the ledger.
MaxLineNetAmount Maximum net amount of the
journal batch for the ledger.
CalendarId Internal identifier of the
accounting calendar.
UserPeriodSetName Translated user entered name of
the period set.
PeriodSetName Untranslated name of the period
set.
PeriodSetId Internal identifier of the period set.
PeriodType Type of period.
PeriodTypeId Internal identifier for the type of
period.
AttributeCategory Category of the descriptive
flexfield for the calendar.
JeBatchId Internal identifier of the journal
batch.
LedgerId Internal identifier of the ledger.
Name Name of the ledger.
EnableJeApprovalFlag Flag indicating whether approval is
enabled for the ledger.
LedgerCategoryCode Category code of the ledger.
11 | P a g e
MaxJournalAmount MaxJournalAmountDr Maximum debit amount of the
journal for the ledger.
MaxJournalAmount MaxJournalAmountCr Maximum credit amount of the
journal for the ledger.
MaxJournalAmount MaxJournalNetAmount Maximum net amount of the
journal for the ledger.

JournalBatchLedger JeBatchId Internal identifier of the journal

batch.
JournalBatchLedger LedgerId Internal identifier of the ledger.
JournalBatchLedger Name Name of the ledger.
JournalBatchLedger CurrencyCode Functional currency defined for the
ledger.
JournalBatchLedger PrimaryLedgerCurrencyCode Functional currency defined for the
primary ledger.
JournalBatchLedger EnableJeApprovalFlag Flag indicating whether approval is
enabled for the ledger.
JournalBatchLedger PeriodSetName Untranslated name of the period
set.
JournalBatchLedger Meaning Field indicating whether it is a
ledger set or ledger. Value would
always be translation of text
Ledger.
JournalBatchLedger AttributeCategory Category of the descriptive
flexfield for the ledger.
JournalBatchLedger LedgerCategoryCode Category code of the ledger.

JournalLine JeHeaderId Internal identifier of the journal.

JournalLine JeLineNum Line number of the journal line.
JournalLine LedgerId Internal identifier of the ledger.
JournalLine EnteredDr Entered debit amount for the
journal line.
JournalLine EnteredCr Entered credit amount for the
journal line.
JournalLine AccountedDr Accounted debit amount for the
journal line.
JournalLine AccountedCr Accounted credit amount for the
journal line.
JournalLine CurrencyCode Currency code for the journal line.
JournalLine AttributeCategory Category of the descriptive
flexfield for the journal line.
JournalLine AttributeCategory2 Not used in Oracle Fusion v1.

12 | P a g e
JournalLine AttributeCategory3 Not used in Oracle Fusion v1.
JournalLine AttributeCategory4 Not used in Oracle Fusion v1.

Period PeriodName Name of the accounting period of

the journal.
Period PeriodSetName Untranslated name of the
accounting period set.
Period StartDate Start date of the accounting
period.
Period EndDate End date of the accounting period.
Period PeriodType Type of accounting period.
Period PeriodYear Accounting period year.
Period PeriodNum Accounting period number.
Period QuarterNum Quarter number.
Period Description Description of the accounting
period.

SubmittedPeriod PeriodName Name of the current accounting

period for example as of today.
SubmittedPeriod PeriodNum Accounting period number.
SubmittedPeriod PeriodSetName Untranslated name of the
accounting period set.
SubmittedPeriod PeriodType Type of accounting period.
SubmittedPeriod PeriodYear Accounting period year.
SubmittedPeriod StartDate Start date of the accounting
period.
SubmittedPeriod EndDate End date of the accounting period.
SubmittedPeriod AdjustmentPeriodFlag Flag indicating if this is an
adjustment period.
SubmittedPeriod MostRecentPeriodEndDate End date of the most recent
accounting period.
SubmittedPeriod PreviousPeriodEndDate End date of the previous
accounting period.

JournalHeader JeHeaderId Internal identifier of the journal.

JournalHeader LedgerId1 Internal identifier of the ledger.
JournalHeader Name1 Name of the ledger.
JournalHeader CurrencyCode Functional currency code of the
ledger.
JournalHeader RunningTotalAccountedDr Total accounted debit amount for
the journal.

13 | P a g e
JournalHeader RunningTotalAccountedCr Total accounted credit amount for
the journal.
JournalHeader DefaultEffectiveDate Accounting date for the journal.
JournalHeader JeCategoryName Internal category name for the
journal.
JournalHeader AttributeCategory Category of the descriptive
flexfield for the journal.
JournalHeader AttributeCategory2 Not used in Oracle Fusion v1.
JournalHeader ReferenceDate Reference date entered for the
journal.
JournalHeader AccrualRevFlag Flag indicating the reversal status
of the journal.
JournalHeader JeFromSlaFlag Flag indicating whether this journal
was created via subledger
accounting.
JournalHeader JeBatchId Internal identifier of the journal
batch.

JournalHeaderCategory AttributeCategory Category of the descriptive

flexfield for the journal category.
JournalHeaderCategory JeCategoryName Untranslated internal name for the
journal category.
JournalHeaderCategory UserJeCategoryName Translated user entered name for
the journal category.

JournalBatchSource JeSourceName Untranslated internal name for the

journal source.
JournalBatchSource SourceType Used internally to indicate if
journal source is a subledger
application.
JournalBatchSource UserJeSourceName Translated user entered name for
the journal source.

JournalBatch JeBatchId Internal identifier for the journal

batch.
JournalBatch LastUpdateDate Date on which the journal batch
was last updated.
JournalBatch LastUpdatedBy User who last updated the journal
batch.
JournalBatch Name Name of the journal batch.
JournalBatch Status Status of the journal batch.
JournalBatch StatusVerified Flag indicating if the status of the
journal batch has been verified.
JournalBatch ActualFlag Balance type of Actual, Budget, or
Encumbrance. For Oracle Fusion v1

14 | P a g e
 only value is Actual.
JournalBatch DefaultEffectiveDate Date within default accounting
period.
JournalBatch CreationDate Date on which the journal batch
was created.
JournalBatch CreatedBy User who created the journal
batch.
JournalBatch LastUpdateLogin Login of the user who created the
journal batch.
JournalBatch DefaultPeriodName Accounting period for batch.
JournalBatch EarliestPostableDate Earliest date batch can be posted.
JournalBatch PostedDate Date batch was posted.
JournalBatch DateCreated Date batch was created.
JournalBatch Description journal entry batch description.
JournalBatch ControlTotal Control total column
JournalBatch RunningTotalDr Total debit amount for the journal
batch.
JournalBatch RunningTotalCr Total credit amount for the journal
batch.
JournalBatch RunningTotalAccountedDr Total accounted debit amount for
the journal batch.
JournalBatch RunningTotalAccountedCr Total accounted credit amount for
the journal batch.
JournalBatch BudgetaryControlStatus Journal entry batch funds check
status (Not used in Oracle Fusion
v1.)
JournalBatch PacketId Packet defining column for last
funds check of the batch (Not used
in Oracle Fusion v1) .
JournalBatch PostingRunId Posting sequence number.
JournalBatch RequestId Posting Enterprise Scheduler v1 job
identifier.
JournalBatch UnreservationPacketId Packet defining column for last
funds unreserved in batch (Not
used in Oracle Fusion v1) .
JournalBatch AverageJournalFlag Average journal flag.
JournalBatch ApprovalStatusCode Journal entry batch approval
status.
JournalBatch ParentJeBatchId Defining column of the parent
batch in the source reporting
currency ledger.
JournalBatch ChartOfAccountsId Key flexfield structure for the
journal batch.
JournalBatch PeriodSetName Accounting period set name.

15 | P a g e
JournalBatch AccountedPeriodType Type of accounting period.
JournalBatch GroupId General ledger interface group
identifying column.
JournalBatch ApproverEmployeeId Identifier of the employee who
submitted the journal batch for
approval.
JournalBatch JeSource Untranslated internal name for the
journal source.
JournalBatch AttributeCategory Internal category name for the
journal batch.
JournalBatch AttributeCategory2 Not used in Oracle Fusion v1.
JournalBatch BatchAmount Batch amount.
JournalBatch Meaning Balance type of Actual, Budget, or
Encumbrance. For Oracle Fusion v1
only value is Actual.
JournalBatch LookupType Has value ‘BATCH_TYPE’ .
JournalBatch LookupCode Balance type of Actual, Budget, or
Encumbrance. For Oracle Fusion v1
only value is A for Actual.

16 | P a g e
5. Seeded Rule

There is one predefined journal approval rule. If the journal’s ledger and the source are enabled for
approval, then the journal entry is sent for one level of approval by default (supervisory level –
supervisor/manager of the person who created it. The implementer / system administrator must specify
the Top participant as per the deploying organization’s requirements in the rule. Below is the seeded
approval rule.

You need to specify the Top Participant in the THEN condition shown above.

17 | P a g e
6. User Flow for definition of the Journal Approval Rule
6.1 Approval Rule Creation Process

Use Case:

InFusion Financial Services Ltd submits journal entries recorded for approval by supervisor of the worker
entering the journal entry based on following three conditions:

1. Journals with net journal line amount greater than or equal to $1000 to $25000 = one level up
supervisory approval.
2. Journals with net journal line amount greater than $25000 = two level up supervisory approval.
3. Journals with net journal line amount greater than or equal to $0 to $1000 = auto approval (self
approval).

We will build this use case now using AMX. Below are the details steps with necessary screenshots to
assist.

This demo presents above use case to define a journal approval rules.

6.1.1 Navigate to BPM Worklist

Procedure

In Oracle Fusion Applications, every product family has their own SOA Server. Hence any Human
workflow task initiated would appear in appropriate server BPM Worklist only.

In the Application Toolkit (ATK) Home page, we have worklist table which runs in Federated mode.
Meaning, it would pull all approval task for the logged in user in all Oracle Fusion Applications SOA
Servers and show them on Home page.

If the user is interested in seeing the tasks only on the Financial server, then the navigation is provided
in this demo. This would filter and show only tasks from the Financial SOA Server.

Also there are cases where customers want to specifically go to worklist application to configure task
level settings, preferences, create or modify rules, so on. This demo will provide the required navigation
to the Financial Worklist page.

18 | P a g e
Step Action

1. Login to the Environment by entering the user name and password.

Enter the desired information into the User ID field. Enter FINUSER1.

19 | P a g e
Step Action

2. Click the Sign In button.

20 | P a g e
Step Action

3. On the Home Page under the Worklist portlet click the View menu.

21 | P a g e
Step Action

4. Click the Servers option.

22 | P a g e
Step Action

5. Click the Financials link.

23 | P a g e
Step Action

6. You land on the BPM Worklist Application.

Click the Administration link on the top right.

24 | P a g e
Step Action

7. Click the Task Configuration tab.

25 | P a g e
Step Action

8. Filter the Tasks by checking the Show -> Active Versions option.

Search for FinGlJournalApproval. Click the FinGlJournalApproval tree

item

26 | P a g e
Step Action

9. Click the Rules tab.

The participant tree displays the participants in the GL Journal Approval process. The
participants are organized in two flows: Parallel Mode and Sequential Mode.

27 | P a g e
Step Action

10. Click on any participant to create or edit approval rules related to that participant. By
clicking on participant you cannot configure task level settings etc.

Step Action

11.
End of Procedure.

28 | P a g e
6.1.2 Define Approval Rules
Procedure
Step Action

1. This demo presents a use case to define a journal approval rule.

InFusion Financial Services Ltd submits journal entries recorded for approval by supervisor
of the worker entering the journal entry based on following three conditions:

1. Journals with net journal line amount greater than or equal to $1000 to $25000 = one
level up supervisory approval.
2. Journals with net journal line amount greater than $25000 = two level up supervisory
approval.
3. Journals with net journal line amount greater than or equal to $0 to $1000 = auto
approval (self approval).

We will build this use case now using AMX.

29 | P a g e
Step Action

2. Navigate to the BPM Worklist application to manage the approval rules. Ensure that you
are authorized to manage the approval rules by the necessary functional privileges.

30 | P a g e
Step Action

3. To create new rules or modify existing rules click on the Administration link in the top
right of the BPM Worklist page.

31 | P a g e
Step Action

4. Click the Task Configuration tab.

32 | P a g e
Step Action

5. Click the Task FinGlJournalApproval from the Tasks to be configured pane.

33 | P a g e
Step Action

6. Click the Rules Tab.

34 | P a g e
Step Action

7. Click the Edit Task icon on top of the left pane.

35 | P a g e
Step Action

8. Click the Supervisory Journal Approver participant

36 | P a g e
Step Action

9. Add a rule by clicking the Add Rule icon

37 | P a g e
Step Action

10. Expand the rule by clicking the Expand icon

38 | P a g e
Step Action

11. Define the IF condition:

In the first condition of the rule we check that the Journal Approval Required flag for the
ledger is set to “Y”. To achieve this, click the Left Value icon.

From the pop-up select and expand JournalBatchLedger and select enableJeApprovalFlag
property. Click OK.

39 | P a g e
Step Action

12. Select is from the choice list of operators and enter “Y” on the right hand side text box.

40 | P a g e
Step Action

13. To add another condition click the list icon at the right of the first condition

Select simple test.

41 | P a g e
Step Action

14. In this second condition of the rule we check if the Journal Line Net Amount is between
$1000 to $25000.
To do this click the Left Value icon

Select the variable MaxJournalLineAmount and expand.

42 | P a g e
Step Action

15. Select the variable maxLineNetAmount click the OK button.

43 | P a g e
Step Action

16. Select the between operator.

44 | P a g e
Step Action

17. Specify the amount limits by clicking the Right Value icon.

45 | P a g e
Step Action

18. Specify the starting limit by entering 1000 in the Operand1 text box

46 | P a g e
Step Action

19. Specify the end limit by limit by entering 25000 in the Operand2 text box.

47 | P a g e
Step Action

20. Confirm the entered values.

Click the OK button.

48 | P a g e
Step Action

21. To add the THEN Action, click the Add Action icon under THEN.

Hover over Add Approver

49 | P a g e
Step Action

22. Select Supervisory as the Approver.

50 | P a g e
Step Action

23. Since we want the approval of a supervisor who is one level higher for this amount
bracket, enter 1 in the Number of levels text box.

51 | P a g e
Step Action

24. Specify the Starting Participant who will perform the approval task.

Invoke the Starting Participant list of values.

Select the Get Manager radio button

52 | P a g e
Step Action

25. Specify the Reference User whose Manager is to be the starting participant.
Enter Task.creator.

53 | P a g e
Step Action

26. Confirm the action by clicking the OK button.

54 | P a g e
Step Action

27. Specify the Top Participant up to whom the supervisory chain extends to.
Invoke the list of values by clicking on the LOV icon.

55 | P a g e
Step Action

28. Select the Get User radio button.

56 | P a g e
Step Action

29. Specify the Reference User "FINUSER30" (in your scenario's it will be your specific user,
generally the top most member of your supervisory hierarchy) and confirm.

Type "FINUSER30" in the field and press OK button.

57 | P a g e
Step Action

30. Specify the Rule Name as “SupervisoryBtwn1000And25000”

58 | P a g e
Step Action

31. Click the Save icon near the top left of the screen to Save the rule.

Enter any comments and click OK.

59 | P a g e
Step Action

32. Create the Second rule.

Click the New Rule button.

Enter the rule name as SupervisoryGreaterThan25000.

Add the IF conditions as done in the previous rule.
Select the more than operator in the second condition and enter 25000 in the right hand
value text box.

60 | P a g e
Step Action

33. Click the Add Action icon under THEN as before.

Select the Add Approver -> Supervisory option as before.

61 | P a g e
Step Action

34. Enter 2 in the Number of Levels text box.

Provide the same inputs for Starting Participant, Top Participant, Auto Action Enabled,
Auto Action as in the first rule.
Enter “SupervisoryGreaterThan25000” in the Rule Name text box.

62 | P a g e
Step Action

35. Click the Save icon near the top left of the screen to Save the rule.

Enter any comments and click OK.

63 | P a g e
Step Action

36. Create the Third Rule.

Click the New Rule button.

Enter the rule name as AutoLessThan1000.

Add the IF conditions as done in the previous rule.
Select the less than operator in the second condition and enter 1000 in the right hand
value text box.

64 | P a g e
Step Action

37. Click the Add Action icon under THEN.

Select the Add Approver -> Supervisory option as before.

65 | P a g e
Step Action

38. Enter 1 in the Number of Levels text box.

Provide the same inputs for Starting Participant, Top Participant as in the previous rules.

66 | P a g e
Step Action

39. Select True from the drop down list for Auto Action Enabled.

Enter “APPROVE” on the Auto Action text box.

Enter “AutoLessThan1000” in the Rule Name text box.

Note that the Auto Action specified overrides the supervisory approval specified when the
Auto Action Enabled flag is set to True.

67 | P a g e
Step Action

40. Click the Save icon near the top left of the screen to Save the rule.

Enter any comments and click OK.

The rules to meet the three conditions have been created. Note that the rules defined
under each participant should be mutually exclusive and collectively exhaustive.

68 | P a g e
Step Action

41. Click on the Commit task icon on the top left corner to deploy the rules. Enter any
comments and click OK.

The approval rules defined will now be applied to any Journals submitted.

69 | P a g e
Step Action

42. You will be taken back to the Rules home page which shows the participant tree.
Notice that except the Edit task icon ( ) on the top left, all other icons are greyed out.

Step Action

43.
End of Procedure.

70 | P a g e
6.1.3 Define Account Flexfield Based Approval Rules
Procedure
Step Action

1. This demo presents a use case to define approval rules based on account flexfields.
Account flexfield based rule enables you to create rules that derive approver(s) based on
which account segment or account code combination has been used in a journal.

Vision Foods USA Ltd. submits all journal entries recorded on the Retained Earnings
Natural Account ‘31010’, to ‘finuser10’.

We will build this use case now using AMX.

71 | P a g e
Step Action

2. Click the Job Level Journal Approver participant

72 | P a g e
Step Action

3. Add a rule by clicking the Add Rule icon

73 | P a g e
Step Action

4. Expand the rule by clicking the Expand icon

74 | P a g e
Step Action

5. Define the IF condition:

In the first condition of the rule we check that the Journal Approval Required flag for the
ledger is set to “Y”. To achieve this, click the Left Value icon.

From the pop-up select and expand JournalBatchLedger and select enableJeApprovalFlag
property. Click OK.

75 | P a g e
Step Action

6. Select is from the choice list of operators and enter “Y” on the right hand side text box.

76 | P a g e
Step Action

7. To add another condition click the list icon at the right of the first condition

Select simple test.

77 | P a g e
Step Action

8. Click the Condition Brower and scroll to find the Accounting Flexfield. In this rule we look
for the Vision Foods Flexfield, Account1105Vision5FFoods5FUSA5FAccount.

78 | P a g e
Step Action

9. Select the Natural Account segment, which in this case is VFAccount, under the Chart of
Accounts in context. Click OK.

79 | P a g e
Step Action

10. Alternatively, to define a rule based on the entire account code, select
FNDACFFConcatenatedStorage attribute.

80 | P a g e
Step Action

11. Enter the natural account segment value for the Retained Earning account, “31010” on
the right side of the is operator.

Alternatively, if you want to enter the rule is for a particular Retained Earnings code
combination, say for Company 3111, you can enter the entire value “3111-000-0000-
0000-31010-0000-0000-0000”.

81 | P a g e
Step Action

12. In the THEN section, add a Resource Approver.

82 | P a g e
Step Action

13.
Since the rule required approval from a specific user, click the search icon next to the
Users textbox

83 | P a g e
Step Action

14. Enter finuser10 in the search box, click Search.

Click the Select radio button and click OK to complete the user selection.

84 | P a g e
Step Action

15. Enter the rule name as “RetainedEarningsApprovalRule” click the Save icon on the top
left of the Tasks panel.

85 | P a g e
Step Action

16. Click the Commit Task icon to publish the rule.

Step Action

17. End of Procedure.

86 | P a g e
7. Considerations

7.1 Rule Definition Consideration

There is one seeded approval rule. If you enable the ledger and the source for approval, then the journal
entry is sent for one level of approval by default. You must configure the approval rules in the AMX
Rules Setup user interface. To experiment with simple approval scenario, start by defining one or all of
the following rules:

 Journal approval based on the highest journal line amount per ledger per batch.
 Journal approval based on the highest journal amount per ledger per batch.
 Journal approval behavior based on where you are in the period close process. For example, are
you in the beginning, middle, or end of the month, or in pre-close, close, post close, or quarter
close process?

For example, after your ledger is enabled for approval, enter the following approval rules to apply when
your maximum journal line amount is:

 Less than 50,000 United States dollars (USD), then there is no approval required.
 Between 50,000 to 100,000 USD, then the journal batch requires one level of approval.
 Greater than 100,000 USD, then the journal batch requires two levels of approval.

Build your rules for every combination of ledger, entered amount, approval level, or other needed
scenarios by using the pattern in the suggested rules. In addition, Oracle Fusion functionality allows you
to further define your own rules based on attributes from the different parts of your journal, including
the ledger, batch, header, or line level. For example, use category, source information as selection
criteria for the journals to be sent for approval.

The ledger is included in the rules because you typically define approval rules per ledger. Set the options
that enable journal approval at the ledger level and by journal source. This allows the approval process
to determine which journals to send for approval.

7.2 AMX List Builder Considerations

Use the following AMX List Builder to build your approval list.

List Builder Functionality Additional Information

Human This method uses the HR This method is most effective when the General
Resources Supervisory hierarchy levels and Accountant enters the journals. For example, if an
(HR) specifies the number of levels accountant enters a journal, he needs approval from
Supervisory available for approval. his manager. If his manager enters a journal he
needs approval from his manager and so on up the
hierarchy for the specified number of levels. Self
approval can be set at any levels in the hierarchy.

87 | P a g e
 Note

If you want to approve by dollar amount, use the Job

Level hierarchy.
Job Level A relative dollar amount can be Enable self-approval to allow approval of journals
attached to a job. The approval created within your authority limit.
list moves up the HR
Supervisory hierarchy to the
point it finds a job with the
necessary approval amount.
Position A relative dollar amount can be This is effective if you need a hierarchy different
attached to a position. than the HR Supervisory hierarchy. It is also effective
when there are multiple hierarchies that need to be
selected based on different attributes.
Approval Approver groups represent
Group functional or subject matter
experts outside the
transaction's managerial chain
of authority, such as Legal or HR
personnel.
Dual Chain Dual chains can be processed at
the same time.

Note

Best practices are to select Resource, Job Level, HR Supervisory, or Position list builders for your journal
approval rules.

88 | P a g e
8. Other Considerations

Other functionality to consider before defining approval rules include:

 Approval is for the entire journal batch regardless of the attributes used in the approval rules.
 The setup options to enable journal approval at the ledger level and by journal source will be
configured in the applicable setup user interfaces. The reason for this is that it will then allow
the Journals user interface to determine which journals to not send for approval.
 For the job and position level approvals, the approval list continues up the job or position
hierarchies until it finds the approver with the correct approval authority.
 If the journal requires approval, submitting a journal for posting automatically routes the journal
for approval before posting.
 A journal can be escalated to a new approver by the administrator.
 The Withdraw Approval button on the Journals page is used at anytime in the approval process
to withdraw journals from the process. Clicking this button allows you to edit to the journal.
After your changes are made, submit the entry for approval again. When a journal is withdrawn,
the completion status is set to Incomplete.
 Approval notifications display a table of key journal attributes for each journal and a list of past,
current, and future approvers.
 The Journals region in the General Accounting (GAM) dashboard displays the journals requiring
your approval (if you have the privilege to approve journals) and pending approval from others.
 The Journals page allows you to approve or reject journals if you are the current approver.
 Allocation journals are not routed through the approval process.
 You cannot use different list builders under same rule set where the batch will get evaluated
against those rules.
 Once you have defined an approval rule you need to have a rule which will catch all remaining
cases. You can enable self approval for it.
 Every string specified directly during rule creation process needs to be enclosed in double
quotes. So when defining the batch name, it needs to be "Batch1". Similarly the approval group
needs to be added to the rule as "Approval Group1”.

Note:

Approval is enabled at the ledger level and source level. Both the ledger and journal source need
to be enabled for the approval process.

89 | P a g e
90 | P a g e
9. Creating Job Level and Position Level Hierarchies
1. Steps to update Job Level for a given Job

Login into the HCM Core Setup WA

User: HR_SPEC_ALL/Welcome1

Search for Job to which you want to update Job-Level.

91 | P a g e
Select the Job, Click on Edit and select update.

Enter the Effective Date and Action Reason and click on Ok.

92 | P a g e
Set the Job-Level(1 to 9) and submit

If it does not require approval, it will update the job-Level. You can verify this upon querying the job
again.

93 | P a g e
Position Based Approval

Define the Position tree in HCM

User details: hr_spec_all/Welcome1

Manage position trees displays the position trees. You can create a new position tree from here.

94 | P a g e
Here you can add /update the positions and their levels.

95 | P a g e
96 | P a g e
10. Troubleshooting

Refer to support document ID:

https://support.us.oracle.com/oip/faces/secure/km/DocumentDisplay.jspx?id=1338489.1

10.1 Troubleshooting Details

10.1.1 Overview
Journal Approval has a SOA Composite which consists of a Mediator, Business Process Execution
Language (BPEL) process and Human Workflow.
The SOA composite is named as FinGlJrnlEntriesApprovalComposite and it can be seen in the following
screenshot.

Screenshot : SOA composite and different SOA components.

This SOA composite will NOT be exposed directly, but can only be initiated by the business event.

The Mediator subscribes to a standalone business event, which can be published from:

 Journal Entry user interface (Post button)

97 | P a g e
  Batch Actions (Request for Approval)
 Search Journals user interface (Submit multiple batches for posting)
 Desktop Integration Spreadsheet (Launch import and post automatically option)
 Journal Import
 Automatic Posting

The mediator then initiates the BPEL process.

The BPEL process further invokes Human Workflow service integrating with AMX, services exposed from
Journal Entry AM, and Enterprise Scheduler Services (ESS) for the Posting program.

The Application Development Framework user interfaces will detect whether journal approval is
required, and if required, then launch the journal approval BPEL process.

The BPEL process which will have to launch the posting program after the approval is done.
If approval is not required, the ADF user interfaces will directly submit the posting program.

The BPEL process accepts a list of Journal Batch Ids. It will first check for each batch if approval is
required.
For all batches that have already been approved or do not required approval, posting program will be
initiated via ESS web service (one request for all batches).

For the ones that require approval, Human Task will be initiated. After the approval task is completed,
posting program will be initiated via ESS web service (one request per batch).

10.1.2 Flow
1. DirectPostingWithoutApproval: This process identifies the batches that require approval and these
batches will be sent for approval. All the batches that do not require approval will be sent for posting
directly at a time. And the remaining which requires approval and posting will be sent for approval and
follows the below mentioned steps.

2. FlowN: This activity is to process multiple journal batches in parallel. Each branch will process one
journal batch. In a scenario of multiple batches, only one posting program should be submitted for all
the batches that do not require approval.

3. JournalBatchApprovalProcess: This step includes the human task activity and updates approval status,
action log, and so on. This step updates the column GL_JE_BATCHES.APPROVAL_STATUS_CODE to I
which means that Journal approval process is in progress.

Upon completion of the human workflow one should check for the following results

98 | P a g e
If Approved

a) Update GL_JE_BATCHES.APPROVAL_STATUS_CODE to A.
b) Update the Approver Employee Id with Person Id.
c) Continue for Posting.

If Rejected

a) Update GL_JE_BATCHES.APPROVAL_STATUS_CODE to J.
b) End the process.

If Withdrawn
a) Update GL_JE_BATCHES.APPROVAL_STATUS_CODE to R.
b) Update GL_JE_BATCHES. STATUS to U.
b) End the process.

Else
a) Update GL_JE_BATCHES.APPROVAL_STATUS_CODE to V.
b) End the process.

The various statuses of Journal Approval GL_JE_BATCHES.APPROVAL_STATUS_CODES are:

Approval Meaning
Status Code

Z N/A

V Validation Failed

R Required

J Rejected

I In Progress

A Approved

4. PostJournalBatch: In this step the posting program is submitted via ESS by passing posting_run_id as a
unique sequence number.

99 | P a g e
10.1.3 Configuration
These are the basic setups needed to setup Journal Approvals.

1. Enable Journal Approval at the Ledger level.

Go to Functional Setup Manager and open the task Specify Ledger Options. Check the Enable journal
approval checkbox for the Ledger.

2. Setup Journal Sources for Journal Approval.

Go to Functional Setup Manager and open the task Manage Journal Sources. Check the Require Journal
Approval checkbox for the source to enable Journal Approval.

3. Setup up Approval rules using AMX. These rules can be seen using the BPM Worklist of FIN Domain-
>Administration->Task Configuration.
Select the human task which is of active composite in the EM i.e. FinGlJournalApproval (1.0).

10.1.4 Troubleshooting Steps

Refer the following steps to understand where the issue is occurring. Provide the output of the following
steps in case of logging the service request.

1. Verify if the ledger and the journal source is enabled for the approval.

Verify the journal approval flag of the ledger:

SELECT enable_je_approval_flag
FROM gl_ledgers
WHERE name = '&Ledger_name'
Verify the approval flag of the ledger:

Verify the journal approval flag of the source:

SELECT journal_approval_flag
FROM gl_je_sources_b
WHERE user_je_source_name = '&Journal_source_name'

2. Verify the status of the batch after it is sent for the approval.

Execute the following queries

SELECT decode(approval_status_code, 'A', 'Approved', 'J', 'Rejected', 'Z', 'Not Required', 'V', 'Validation
Failed', 'R', 'Required', 'I', 'In Progress') approval_status_code,
name,
je_source,

100 | P a g e
approver_employee_id
FROM gl_je_batches
WHERE name = '&Batch_Name'

SELECT gjb.name,
gjal.action_code,
gjal.action_date,
gjal.user_id
FROM gl_je_action_log gjal,
gl_je_batches gjb
WHERE gjal.je_batch_id = gjb.je_batch_id
AND gjb.name = '&Batch_Name';

3. Identify which activity in EM Flow Trace has failed.

Navigation: Login to EM of financial domain ->Look for SOA component
FinGlJrnlEntriesApprovalComposite -> Click on the instance that has failed -> Check the activities in Flow
Trace and the error messages.

Following sample screenshot should be shown

Screenshot . BPEL Flow Trace.

101 | P a g e
Screenshot . BPEL Flow Trace Error message.

Review the composite instance flow and fault details. If the instance is in error due to setup issue and it
is recoverable, attempt recovery using the Recovery tab of the BPEL process service engine in Oracle

Fusion Applications Control.

102 | P a g e
11. Glossary

Term Definition
Notification A notification is an email, SMS or IM message that notifies a user or role
that there is a certain task that requires their attention. Notifications could
be task related or purely FYI.
User Task A user task is a work item or other task that requires manual intervention.
This was referred to as a Notification in Oracle Workflow
Worklist The Worklist interacts with the workflow service to retrieve user tasks and
enables users to perform action on their tasks.
Approval List The Approval list represents the participants generated by AMX for a
transaction defined within the approval task, based on the approval policies
defined for the approval task.
Approval Task Known as Transaction Types in AME.
An Approvals Task denotes the classification of approvals based on the
business purpose. For example, Journal batch Approval, Expense Report
Approvals. A single application can have several Approval Tasks.
Configuration Variables Configuration variables control the behavior of AMX, they are defined for
each Approval Task.
Dimension Dimension categorizes the rule context. For example, the dimensions
defined for Journals are batches, ledger, headers and lines. It is possible for
dimensions to not map to a stage (see below). A dimension may also be
associated with multiple approval stages.
A dimension is known as Message Attribute Group in Human Workflow (see
below) .
Human Workflow Human workflow is a component of AMX that provides a way to add a pre-
defined approval task service to a process flow from the component
palette. It also provides the users a visual interface to act on current
approvals assigned to the user in a secured manner.
Approver Groups Approver Groups are named static or dynamically generated group of
approvers. Typically approver groups represent functional or subject
matter experts outside the transaction’s managerial chain of authority.
Procurement may need HR or legal counsel that need to approve the
transaction before or after management has done so. It is possible that a
customer has a requirement for a separate approver group based on an
attribute at the journal line level or descriptive flexfield (DFF).
Approver groups are also used to simulate a forced hierarchy across
multiple types of approvers, or chaining approvers across multiple approver
types.

List Builders Known as Action Types in AME.

List builders abstract the specification of similar types of actions. An
approver list builder walks up a hierarchy and based on the list builder
constraints, returns an approver list.
The supported list builders are:

103 | P a g e
 1) HR Supervisory: This method will walk up the HR Supervisory a
certain number of levels based on the dollar amount of the journal
attribute that the approval rule uses. A customer may select this
method, but Job Level is probably more ideal for General Ledger.
2) Job Level: This method this may be the most effective for a General
Ledger customer because a relative dollar amount can be attached
to a job, and the approval list will walk up the HR Supervisory
hierarchy up to the point it finds a job with the necessary approval
amount.
3) Position Hierarchy: Similar to job level, but based on positions. This
is effective if customer’s either need a hierarchy different than the
HR Supervisory hierarchy. It is also effective when there a multiple
hierarchies that need to be selected based on different attributes
achieved through PL/SQL script.
4) Approval Groups: Typically approver groups represent functional or
subject matter experts outside the transaction’s managerial chain
of authority, such as Legal or Human Resources.
5) Dual Chain: It is not expected that General Leger customer’s will
use this method.

List Builder Usage The approval list builder usage defines how an approval list builder is used
for a stage within an Approval Task. It defines the
- Preference: Used to specify the order in which the list builder
should be processed for the stage
- Default Voting Regime;
Chain A chain is a sub-path of an approval list builder. In the Approval Group list
builder, if multiple groups are to be included for a stage, then each group is
processed as a separate chain. These chains will always be processed in
parallel.
Condition Conditions are the IF clauses in an approval rule and are defined as
condition types, either true or false. For the rule to apply to a transaction,
all of its conditions must be true.
An example of a Condition is: 0 USD <= JOURNAL_BATCH_TOTAL
<=1,000,000 USD
Criteria The set of conditions under which a rule would be applicable is called
Criteria. If all the conditions in a routing policy are true, then that routing
policy is active for the transaction.
Terms Known as Attributes in AME.
Terms are semantic units of information relevant to a business user. Most
Terms originate from member fields of business objects, such as the First
Name of a Person.

Whereas Attributes had to be seeded within AME to be used within Rules,

this is different for Fusion. Terms will not be specified within AMX, but will
be inferred from the appropriate view object or view link (VO or VL)
definition. When an Approval Task is created there will be one VO
associated with it i.e. at header level. This view can have multiple VL’s

104 | P a g e
 linked to it. The following dimensions will then be created: Journal Batch,
Journal Header and Journal Line level.

Note: Terms can also be known as Attributes in AMX

Approval Routing Policies Known as Rules in AME.
Approval routing policies or rules determine the approver list builders to be
used to determine the approvers or FYI notification recipients required for
a business transaction.
Each routing policy defines:
- Approval Policy Type
- Action
- Criteria
- Priority
- Response Type
- Validity Period

Approval Policy Type Describes the type of action being done to the approver list. The supported
policy types are:
- List Creation
- List Modifications
- Approver Substitution

Journal Approval will only support the List Creation approval policy type.
Action An Action is an instruction to AMX to include a given set of approvers in a
transaction’s approver list.
For List Creation policy, it defines the:
- Approver list builder to be used
- Stopping rule
- Response type
- Include all members in the list
- Voting regime for the rule

Example of an action: Requires approvals up to position equal to Controller.

Priority Rule arbitration is carried out by means of prioritizing rules.
Response Type This describes the type of response expected from the approver for the
approval task. It includes:
- Required (For Approval Notifications)
- Not required (FYI)
- Optional (For Review)
Validity Period The validity period if the time period for which the rule is valid.
Run Time user interface The set of user interfaces that are generated at runtime includes the Task
List, Approval List Display UI, so on.
Design Time user The set of user interfaces used to design the approval task is referred to as
interface Design Time user interface. This includes the Rule definition user interface,
Approval Task Creation or Configuration user interface and the creation of
stages or approval maps, so on.

105 | P a g e