General Ledger Options (Chapter 9) 20C

Ledger Sets

Examples of Ledger Sets

When you use multiple ledgers, you can group all types of ledgers in a ledger set. For example, group primary ledger, secondary ledgers, and reporting currencies (journal and subledger levels) as long as they share the same chart of accounts, calendar and period type.

Ledger sets are used to manage ledgers, including:

Opening and closing of periods.
Running reports and processes for multiple ledgers simultaneously.
Supporting adjustments and allocations.

Regulation Requirements Example

You have 26 registered companies in Vision Corporation. The regulations require that each company is to maintain a separate ledger. All companies share the same chart of accounts and calendar.

You set up a ledger for each company and group them into a ledger set. You can then use the ledger set to perform all accounting activities, while the data remains partition for reporting purpose for each company.

Multiple Countries Example

You have a parent company in one country. You operations in five other countries. Each country has its own legal entity and must report to both the parent company and the local government. All legal entities use the same chart of accounts and calendar. Currency is different and Reporting Currency ledgers have been created. You can group all of the primary and reporting currencies ledgers into one Ledger Set. You can then perform all accounting activities as though you had one worldwide ledger.

Data Access Sets

Data Access Set Security

Data Access Sets secure access to ledgers, ledger sets, and portions of ledgers using primary balancing segment values. If you have primary balancing segment values assigned to a legal entity, then you can use this feature to secure access to specific legal entities.

Related Topics

Accounting Automation

Accounting automation streamlines and automates end-to-end accounting and transaction processes, including daily rates import, accounting creation, journal import, and journal posting. Data flows through all of the required processing steps without user intervention. Users are notified of exceptions and provided with the information to help resolve them. Additional users can optionally be notified of errors generated during the transaction accounting process.

Setup and Considerations

Use this navigation in the Setup and Maintenance work area.

Offering: Financials
Functional Area: General Ledger
Task: Manage Accounting Automation

Note: If you use, or plan to use, any form of coexistence solution, such as Oracle Fusion Accounting Hub Reporting Cloud, you should not enable accounting automation.

Here are the general settings on the Manage Accounting Automation page.

Setting	What It Is
Enable Automation	Indicator for whether accounting automation is enabled for all ledgers (primary, secondary, and reporting currencies with currency conversion levels of Journal or Subledger).
Scheduled Submission Time	Time when accounting automation is submitted and when daily email notifications are sent. The process can run an additional three times a day (every six hours), if transactions are pending. If no transactions are pending, accounting automation runs only at the time you specify here.
Notification Preference	Setting that determines whether to send email notifications to users or roles.
Default User to Notify or Default Role to Notify	User or role that receives an email notification for each accounting automation run. The notification provides a summary of the processed data and a detail listing of all errors.

Optionally use the Error Notifications section to send certain users or roles notifications for errors generated while processing transactions for specific combinations of attribute values. The values you can specify depend on your Notification Preference setting.

Notification Preference	What You Can Set
User	One or more users can receive notifications based on a specific combination of ledger (or ledger set), error category, and journal source. Use a ledger value of Any or No Ledger to notify users of transactions that don't have a ledger associated with them, such as daily rates import, and for all ledgers.
Role	One or more roles can receive notifications based on a specific combination of error category and journal source. Here's how it works with ledgers. Let's say a GL role has three users: User 1, User 2, and User 3. User 1 has access to Ledger 1 and Users 2 and 3 have access to both Ledger 1 and Ledger 2. When you set the error category to All and the source to All for that role, User 1 sees the data and errors only for Ledger 1. Users 2 and 3 see the data and errors for both ledgers.

User

One or more users can receive notifications based on a specific combination of ledger (or ledger set), error category, and journal source. Use a ledger value of Any or No Ledger to notify users of transactions that don't have a ledger associated with them, such as daily rates import, and for all ledgers.

Role

One or more roles can receive notifications based on a specific combination of error category and journal source.

Here's how it works with ledgers. Let's say a GL role has three users: User 1, User 2, and User 3. User 1 has access to Ledger 1 and Users 2 and 3 have access to both Ledger 1 and Ledger 2. When you set the error category to All and the source to All for that role, User 1 sees the data and errors only for Ledger 1. Users 2 and 3 see the data and errors for both ledgers.

Here are the error categories.

Category	Description
Account Mapping	Issues with chart of account mappings and subledger accounting mapping sets.
Account Status	Issues related to account statuses such as invalid accounts, or issues related to generation of balancing accounts.
Approval	Rejected journal batches, journal batches that require approval, and journal batches that are in the process of being approved.
Balancing	Issues related to balancing, such as intercompany, suspense, entered currency, and rounding.
Budgetary Control	Errors related to funds reservation.
Critical Error	Critical issues, such as wrong batch statuses.
Currency Conversion	Issues related to currencies, such as missing conversion rates and invalid currencies.
Journal Interface	Issues with importing journal data.
Period Status	Errors related to period statuses, such as a closed period and unopened encumbrance year.
Subledger Transaction Data	Issues with transaction data from subledgers, such as Oracle Fusion Payables, Oracle Fusion Project Costing, Oracle Fusion Receivables, and Oracle Fusion Assets.
System Error	System-related issues.
Warning	Warnings generated by processes.
Other	Errors outside of the predefined error categories. For example, errors related to assignment of balancing segment values to a ledger or legal entity, document sequencing, reversals, no data, and average daily balancing.

The last section on the Manage Accounting Automation page is the Accounting Automation Exclusions section. That's where you can optionally select journal sources to exclude from accounting automation.

Some additional considerations:

Accounting automation doesn't process transactions that were created before the automation was enabled, unless the accounting date on the transaction is the same as, or later than, the date automation was enabled.
Accounting automation doesn't process incomplete batches for posting.
If you use Receivables and plan to enable accounting automation, you must schedule the Create Receivables Accounting process to run daily, before the Accounting Automation process scheduled time.

Users and Email Notifications

The accounting automation process produces two types of email notifications. One type is for the user or role specified in the Default User to Notify or Default Role to Notify fields, and the other is for the users or roles specified in the Error Notifications section. The email subject for both types of notifications includes the date and time of the accounting automation run.

The default user or role receives a notification daily with information about the processed data and errors. Here's an example of the email subject for that notification: Accounting Automation Results from 6/1/19 8:00 AM for Your Review.

If errors occur, the other users receive a notification as designated in the Error Notifications section. Here's an example of the email subject for that notification: Accounting Automation on 6/1/19 8:00 AM Resulted in Issues Requiring Your Attention.

Notifications can include the following sections:

Posted Transactions Summary
Automation Errors Summary
Pending Approvals Summary
Automation Errors Details
Pending Approvals Details

Posted Transactions Summary

This section shows a summary of the posted balances by ledger. Only the default user or role receives this summary. If no accounting transactions were successfully posted for any ledger after an accounting automation run, a message appears in place of this section.

Here's an example of a posting summary. A total of 288 US dollars was posted to the Vision Corporation ledger and 712, 566 US dollars was posted to the Seven Corporation ledger.

This figure shows an example of the Posted Transactions
Summary section in an email notification. This summary has a table
with three columns: Ledger, Total Amount, and Currency. The table
has two rows of data.

Here's more information about each column shown in the example.

Column	Description
Ledger	Names of the ledgers (primary, secondary, and reporting currency) that journal batches were posted to.
Total Amount	Sum of the accounted debits for the journal batches that were posted to the ledger.
Currency	Ledger currency.

Automation Errors Summary

This section shows a summary of errors by ledger, source, and error category. The default user and users (or roles) assigned to the error category with the errors, receive this summary.

Here's an example. The Vision Corporation ledger has 3 transactions totaling 165 US dollars with balancing errors. All of the errors were new for the latest accounting automation run, so the error count of 3 appears in the New column. The errors occurred in both the AutoCopy and Manual journal sources. Maria Smith was notified of the error in the AutoCopy source and Michael Taylor was notified of the error in the Manual source.

This figure shows an example of the Automation
Errors Summary section of an email notification that was sent after
an accounting automation run. The section has a table with seven columns:
Ledger, Error Category, Total Amount, Currency, Number of Errors,
Source, and Users Notified. The Number of Errors column heading spans
two columns: Total and New. The table has one row of sample data.

Here's more information about each column shown in the example.

Column	Description
Ledger	Ledger (primary, secondary, or reporting currency) of the transaction. Is blank if no ledger is associated with the transaction, such as daily rates import errors.
Error Category	Error category associated with the error.
Total Amount	Sum of the accounted amounts that couldn't be processed due to the error category for the ledger.
Currency	Ledger currency.
Number of Errors - Total	Count of the transactions that have errors. Links to the error details section of the email notification.
Number of Errors - New	Count of the transactions that have errors appearing for the first time in the latest accounting automation run. Links to the error details section of the email notification.
Users Notified	Users who were notified of the errors, excluding the default user who's always notified. Is blank if no users were set up to receive email notifications for the respective ledger, source, and error category.

Pending Approvals Summary

This section shows a summary of the journal batches, by aging bucket, that require approval, are in the process of being approved, or were rejected. The default user and the users (or roles) assigned the Approval error category, receive this summary.

Here's an example. The Vision Corporation ledger has one journal batch totaling 7 US dollars that's been pending approval within the last 3 days.

This figure shows an example of the Pending Approvals
Summary section of an email notification sent after an accounting
automation run. The section has a table with a column for the ledger,
amount, and currency, followed by aging bucket columns, each with
an amount and count. The table has one row of sample data.

Here's more information about each column shown in the example.

Column	Description
Ledger	Ledger (primary, secondary, or reporting currency) of the journal batch.
Amount	Sum of the journal batches that are in the approval flow.
Currency	Ledger currency.
Pending Approval Batches: Amount	Total amount of journal batches pending approval broken down into the following aging buckets since the last approval action: 0 - 3 days, 4 - 7 days, 8 - 11 days, more than 12 days.
Pending Approval Batches: Count	Number of journal batches pending approval broken down into the following aging buckets since the last approval action: 0 - 3 days, 4 - 7 days, 8 - 11 days, more than 12 days. Links to the Pending Approvals Details section of the email notification.

Automation Errors Details

This section shows the detailed transactions or journals for the errors reported in the Automation Errors Summary section.

Here's an example of the transactions for the balancing errors reported in the Automation Errors Summary section. All three errors come from General Ledger journals. Possible corrective actions to resolve the issue are listed in the Error column after the errors. The sum of the accounted amounts is 165 US dollars, which is the same amount reported in the Automation Errors Summary section.

Note: The information that appears in the Transaction column is related to the type of transaction. For example, for posting errors, the transaction information includes the journal batch name, the period name, and potentially a journal name and line number. For subledger transactions, the Transaction column provides the name of the subledger application and includes detail information such as the invoice number and amount.

This figure shows the balancing errors for this
example. The table has five columns: Transaction Type, Source, Transaction,
Error, and Amount.

Here's more information about each column shown in the example.

Column	Description
Transaction Type	Identifies the source of the error, which includes: Subledger Transaction: Transactions from subledger applications, such Payables and Receivables Accounting Entry: Accounting entries created in the Oracle Fusion Subledger Accounting application Journal Interface: Oracle Fusion General Ledger journal import transactions General Ledger Journal Daily Rates Import
Source	Journal source of the transaction.
Transaction	Object of the transaction and identifying information. For example, the Subledger Transaction type for a Payables transaction displays the application, party name, party site name, invoice number, date, and amount.
Error	Information about the error that occurred, including suggested corrective actions in some cases. Errors appearing for the first time in the latest automation run are prefixed with a dot icon.
Amount (Currency)	Total of the accounted debits for the transaction.

Pending Approvals Details

This section shows details for the Pending Approvals Summary section.

Here's an example of a journal batch in the process of being approved. Mary Johnson initiated the approval and it's been less than a day since the last approval action.

This figure shows the details for the two journal
batches that are pending approval. The table has six columns: Journal
Batch, Source, Initiator, Status, Amount, and Days Outstanding.

Here's more information about each column shown in the example.

Column	Description
Journal Batch	Name of the journal batch.
Source	Source of the journal batch.
Initiator	User who requested the approval.
Status	Approval status of the batch.
Amount (Currency)	Journal batch amount in the ledger currency.
Days Outstanding	Number of days since the last approval action.

Related Topics

FAQs for Accounting Automation

How can I provide users access to the log and output files for the accounting automation child processes?

Sign in to the Security Console as security manager and perform the following steps:

Create a job role for the users who require access.
Create a data security policy for the ESS_REQUEST_HISTORY object.

The following figure shows an example of the Policy page for a policy called Accounting Automation Read. The Policy page has these tabs: General Information, Role, Rule, and Action.
1. Assign the new job role to the policy.
2. Create a rule and select this value for the condition: ESS requests submitted by Accounting Automation process.
3. To allow users to view the log and output files, select these actions: ESS_REQUEST_READ, ESS_REQUEST_OUTPUTREAD.
4. To allow users to cancel the Accounting Automation job, select the ESS_REQUEST_CANCEL action.

Accounting and Reporting Sequences

Overview of Accounting and Reporting Sequences

When you record your journals, you can assign unique sequence numbers. Sequence numbering the journals simplifies the task of tracing the journal entries and is a legal requirement in some countries, especially those in Europe, Asia, and Latin America. Sequencing enables the fiscal authorities to easily verify the completeness of a company's accounting record.

Sequential numbering of journals enables you to:

Maintain gapless sequence numbers.
Sequentially number subledger journal entries. Generate a sequence number for journal entries created by subledger accounting before transferring them to general ledger.
Sequentially number general ledger journal entries.
Assign sequences within a ledger or legal entity.
Generate reports based on the sequence numbers.

The two different types of journal sequences used with Subledger Accounting and General Ledger journals are:

Accounting Sequences: Gapless sequence numbering for journals which is assigned when the journals are posted or subledger accounting runs.
Reporting Sequences: Gapless and chronological sequence numbering which is assigned to journals when the General Ledger period is closed.

Note: You can sequence journals for ledgers (primary and secondary ledgers) and journal level and subledger level reporting currencies as well as legal entities. If you use journal or subledger level reporting currencies, first define sequences for the source ledger. The sequence number generated for the source ledger isn't automatically assigned to the reporting currency journal. You must then set up accounting and reporting sequences separately for the reporting currencies.

Related Topics

How to Define Journal Sequences Manually

You can manually define sequences to generate numbers for journal entries. Use the Manage Accounting and Reporting Sequences task to search, create, and update sequences, sequence versions, and sequencing assignments. You can also create journal sequences using the Rapid Implementation process. The process creates and assigns the sequences.

Sequences

Create, update, and search for sequences from the Sequences tab on the Manage Accounting and Reporting Sequences page. To define a sequence, enter a unique sequence name and description. Create at least one sequence version to complete the sequence. The sequence version indicates the series of sequence numbers to be used and the effective date range of the series.

When you create a sequence version, you specify the:

Effective Start Date: The default date is the current date. The date can be set to any date in the past or future.
Effective End Date: The date when the sequence should be disabled.
Initial Number: A positive integer that's the starting number of the sequence. The number increments by one for each accounting entry.

Note: The Edit Sequences page displays the last sequence number used for each sequence version.

Sequencing Assignments

After creating your sequences, assign them various criteria to specify when the sequences are generated. Use the Sequencing Assignments tab on the Manage Accounting and Reporting page to search, update, or create sequencing assignments.

The following table describes the fields on the Sequencing Assignments tab.

Field	Description
Ledger	The ledger for which the journal entries must be sequentially numbered or that contains the legal entity.
Legal Entity	The legal entity for which the journal entries must be sequentially numbered. The Legal Entity field appears when you set your Sequence By ledger option to Legal Entity.
Journal Entry Type	Select whether general ledger or subledger entries are being sequentially numbered.
Sequencing Event	The event which triggers the sequence numbering,
Sequence Validation Date	The date when generating a sequence number. This date is used to determine if a sequence is available and the sequence assignment is active.
Require Assignment for All Journals	If you select this option, you must explicitly define valid Sequence Assignments, Exceptions, or Exclusions for all journal entries.
Status	Indicates if the assignment is enabled or disabled.

The following table outlines some of the different combinations of journal entry type, sequencing event, sequence validation date, journal sorting date. For each combination, the table also indicates whether the sequence is an accounting or reporting sequence.

Journal Entry Type	Sequencing Event	Sequence Validation Date	Journal Sorting Date	Remark
General Ledger	Posting	Accounting Date	Accounting Date	Accounting Sequence
Subledger Accounting	Subledger Accounting	Accounting Date	Completion or Posting Date or Accounting Date	Accounting Sequence
General Ledger	Period Close	Accounting Date	Accounting Date	Reporting Sequence
General Ledger	Period Close	Reference Date	Reference Date	Reporting Sequence
Subledger Accounting	Period Close	Accounting Date of Reference Date	Reference Date	Reporting Sequence

Tip: For reporting sequences, you can specify fiscal balancing segment values to specify what balancing segment values to use with reporting sequences for period close. You can deselect the option to exclude balancing segments with management type journals or nonfinancial journals such as, statistical journals.

The following figure shows the Fiscal Balancing Segment Values section from the Sequencing Assignment page. The section includes the segment value, description, and an indicator for whether the segment value is selected for use with the reporting sequence.

This figure shows the Fiscal Balancing Segment
Values section of the Sequencing Assignment page.

Sequencing Assignment Details

The following table lists and describes the fields in the Sequences section on the Create Sequencing Assignment page.

Field	Description
Status	Status of the assignment such as New or Used.
Priority	Priority of the exception. This option is inactive unless you define an exception.
Sequence Name	Name of the sequence to be assigned. A blank indicates the entries must not be sequenced.
Start Date	Define the effective start date for the sequence assignment.
End Date	Define the effective end date for the sequence assignment.
Journal Source	Select the journal sources from the list to be sequentially numbered for a sequence event.
Journal Category	Select the journal categories from the list to be sequentially numbered for a sequence event.
Accounting Event Type	Select the accounting event types to be sequentially numbered (only for subledger entries).
Accounting Entry Type	Select the accounting entry types to be sequentially numbered (only for subledger entries).
Document Category	Select to group transactions assigned to the sequence.

The following figure shows the Add Exception and Add Exclusion buttons on the Create Sequencing Assignment page.

This figure shows the Add Exception and Add Exclusion
buttons on the Create Sequencing Assignment page.

Use the following buttons to add a row:

Add Exception: When you create an exception, the priority value is always one more than the highest number in the Priority field. Use exceptions to assign different sequences to certain journal sources, journal categories, accounting event types, or accounting entity types. For example, you want to include all journal sources, but assign a different sequence for your Expense journals.
Add Exclusion: Create exclusions to exclude specific journal sources, journal categories, accounting event types, or accounting entity types. For example, you want to exclude journal sources and categories containing management or statistical accounts that don't impact financial results.

FAQs for Accounting and Reporting Sequences

What happens when I enable sequencing in the rapid implementation spreadsheet?

Two sets of defaults are generated: general and country specific. The process applies the general defaults first and the country specific defaults override general defaults. For example, using the predefined defaults, sequencing is enabled at the ledger level. For some countries like Spain and Italy, the general defaults are overridden by country defaults and sequences are set at the legal entity level.

Accounting and reporting sequences are generated based on the predefined country defaults. For example, for a France ledger, accounting sequences are generated for each legal entity of the ledger. For an Italian ledger, both accounting and reporting sequences are generated for each legal entity of the ledger.

Journal Approval Rules

Overview of Approval Management

Use approval management to define policies that apply to approval workflows. For example, to reflect your own corporate policies, you can specify levels of approval for transactions over a particular amount and determine how the approvals are routed.

Approval management:

Controls workflows for business objects such as expense reports.
Enables you to define complex, multistage task routing rules.
Integrates with the setup in Human Capital Management (HCM) to derive approvers based on the supervisory hierarchy.

Getting Started

In the Offerings work area, enable the Approval Routing Administration feature at the offering level so that relevant setup tasks are available.
In the Setup and Maintenance work area, use the following setup tasks in the Application Extensions or another functional area.

Manage Task Configurations
Manage Approval Groups

Related Topics

Considerations for Defining Journal Approval Rules

Use approval management to define policies that apply to the journal approval workflow.

Rule Definition Consideration

One predefined approval rule exists for journal approval. If a journal's ledger and source are enabled for approval, then that journal is sent for one level of approval to the supervisor of the person who submitted the journal for approval. You can configure journal approval rules in the Business Process Management Worklist application. Open the application by selecting the Notifications icon on the home page and clicking More Details or, by using the following in the Setup and Maintenance work area:

Offering: Financials
Functional Area: Application Extensions
Task: Manage Task Configurations for Financials

For a simple approval scenario, start by defining one or all of the following journal approval rules based on:

The highest journal line amount per ledger per batch.
The highest journal amount per ledger per batch.
Your stage in the period close process. For example, are you in the beginning, middle, or end of the month, or in preclose, close, post close, or quarter close process?

The following table provides an example of rule conditions and approval actions that route a journal approval based on maximum journal line amounts.

Condition	Approval Action
Less than 50,000 USD	No approval required
Between 50,000 and 100,000 USD	One level of approval required
Greater than 100,000 USD	Two levels of approval required

You can build your rules for combinations of ledger, entered amount, approval level, or other scenarios. In addition, you can define rules based on attributes from different parts of your journal, including the ledger, batch, header, or line level. For example, you can use category, source, account, or descriptive flexfield information as selection criteria for journal approval.

Note: To prevent a submitter from approving their own journal batch, select the Skip creator for Approval List check box on the Configuration page in the Worklist application. The approval task is then assigned to other approvers or automatically routed to the manager of the submitter.

Approvals List Builder Considerations

List builders are the way approvals management builds the list of approvers required for a transaction based on the rule condition. Each approval rule is associated with a list builder for generating the list of approvers.

The following table describes the list builders you can use to build a journal approval list.

List Builder	Description
Supervisory	Based on the employee supervisory hierarchy, which is defined in HCM. Employees must be set up with appropriate jobs and supervisors. For example, a clerk reports to a manager, who reports to the director.
Job Level	Based on the job level, which is defined in HCM. Employees must be set up with the appropriate job levels and supervisors. For example, a job level 1 employee, a clerk, reports to a job level 2 employee, a manager, who reports to a job level 4 employee, a director. The approval list is generated based on the starting position specified in the rule and continues until an approver with a sufficient job level is found. The supervisory hierarchy must be defined along with the corresponding job levels.
Position	Based on the position hierarchy, which is defined in HCM. The position hierarchy must be defined and employees must be assigned the corresponding positions. Use this hierarchy if you need a hierarchy that's different from the supervisory hierarchy, or multiple hierarchies selected based on different attributes.
Approval Group	Consists of a static predefined set of users configured to act on a task. For example, you can create an approval group called Finance Group, consisting of users from the finance department who must participate in the task approval.
Resource	Builds the approvers list by using a specific user, enterprise group or application role.

Other Considerations

Other functionality to consider before defining approval rules.

Both the ledger and journal source must be enabled for the approval process.

Caution: You should not enable journal approval for journals that come from subledgers (with subledger journal sources). Otherwise, if a journal from a subledger isn't approved, the journal can get stuck in the approval process. For any subledger journal sources, approvals for subledger transactions should be done in the subledgers themselves.
Approval is for the entire journal batch, regardless of the attributes used in the approval rules.
If a journal requires approval, submitting a journal for posting automatically routes the journal for approval before posting.
A journal can be escalated to an approver by the administrator.
The task initiator can select Withdraw Approval on the Journals page at any time in the approval process to withdraw journals from the process. Clicking this button enables editing of 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 work area displays journals requiring your approval and journals pending approval from others.
If you're the current approver, the Journals page shows the journals to be approved or rejected.
Allocation journals aren't routed through the approval process.
You can review the details of the journals and journal lines included in a journal batch on the online and email journal batch approval notifications.

Related Topics

Update Existing Setup Data

Create Journal Approval Rules Using a Spreadsheet

Create Workflow Rules Using a Spreadsheet

The Simplified Workflow Rules Configuration feature is a spreadsheet based alternative to creating rules in Oracle Business Process Management (BPM). You can use spreadsheet templates available on the Manage Workflow Rules in Spreadsheet page to manage rules for Financials application workflows.

Note: Currently, only Payables Invoice Approval and General Ledger Journal Approval workflows use this feature.

To create workflow rules in a spreadsheet, perform the following steps:

Steps to create workflow rules using a spreadsheet.

Sign in and navigate to the Manage Workflow Rules in Spreadsheet task.
Download the rule template from the Rule Templates section of the Manage Workflow Rules in Spreadsheet page.
Define the workflow rules in the spreadsheet.
Generate the rule file.
Upload the rule file to create rules.
Verify the spreadsheet upload.

Caution: You must use MS Excel version 2016 to create workflow rules. Also, every successful rule upload using a spreadsheet template overrides the existing rules for the workflow.

Tip: Once you create rules using the rule templates, we recommend you use the spreadsheet method only for any future maintenance of rules.

Manage Workflow Rules Using a Spreadsheet

Before creating and managing workflow rules, perform these steps:

Sign in to the application as a Financial Application Administrator.
Verify if the Approval Routing Administration feature is enabled at Offerings > Financials > Opt In Features. Click the Edit icon for Financials. If the feature isn't enabled, and select its check box.
In the Setup and Maintenance work area, go to Financials > Application Extensions > Manage Workflow Rules in Spreadsheet task.

Download the Rules Template

Download the rule template by performing these steps:

In the Rule Templates section of the Manage Workflow Rules in Spreadsheet page, select the required workflow.
Click Download. The Download Templates dialog box appears.
From the dialog box, select the required template. Save the template to your local computer.

Caution: You must use MS Excel version 2016 to create workflow rules.

Note: Each rule template contains an example of an approval business case to demonstrate how to manage workflow rules using the rule template.

Define the Rules in the Spreadsheet

After downloading the rule template, you must define the workflow rules using the sheets provided in the rule template. Here's a list of sheets you can see in the rule template spreadsheet:

Instructions: This sheet contains details of the help topics present on Oracle Help Center for this feature and the Generate Rule File button. You can also update your rule template version from the Instructions sheet.
Workflow Rules: Provides a template for configuring transaction approval rules.

Note: The name of this sheet varies for each product. For example, for Payables, the sheet is labeled as Invoice Approval Rules.
Data Set: This sheet provides a template to map the varying attributes to the data.

Note: Currently, data sets are only available for Payables workflows. For more information about data sets, refer to the Data Sets section.

A business rule is an approval requirement within your approval policy. Before defining rules in the rule template, you must analyze approval policy. Consider these points before defining a business rule:

Which transactions require approval?
Who approves transactions in your organization?
Do the approvers vary based on the transaction attributes? If so, use a data set.
What are approval conditions?
How do you want to route the approval notifications?
Which approvals require FYI notifications?
Which transactions are exempted from the approval rule?

For example, for Payables, if your organization's approval policy mandates that:

All invoices that aren't matched to a purchase order must be approved at two levels of the supervisory hierarchy. This hierarchy starts from the manager of the user who creates the invoice.
All invoices that have an invoice amount of more than 5000 USD must be approved by a group of personnel from the Finance department.

For this example, you need two business rules.

Use the Workflow Rules sheet to define approval rules. Enter these details:

Rule Description

Enter the description for each approval business rule that you define.

Approvers

In this section, designate approvers and specify approval routing. The template supports a variety of approval routing options. This table provides you details on approval routing and how it works.

Approval Routing	How Approval Routing Works
Supervisory Hierarchy	Members of the supervisory hierarchy beginning from the first applicable approver receive approval notifications.
Group in Parallel	Members of an approval group receive approval notifications. All members receive notifications at the same time. All members must take an action on the approval notification.
Group in Serial	Members of an approval group receive approval notifications. Only when a member takes an action on the approval notification does the next member of the series receive the approval notification.
Group First Responder	Members of an approval group receive approval notifications. All members receive notifications at the same time. Only one member is required to take an action on the approval notification.
Job Level Hierarchy	Members of the job hierarchy beginning from the first applicable approver receive approval notifications.
User	The specified application user receives the approval notification.
Role	The users with the specified application role receive the approval notification.
Auto Approve	Transactions that are automatically approved. No notifications are sent.
Auto Reject	Transactions that are automatically rejected. No notifications are sent.
FYI	Information only notifications. No action is required from the approver.
Skip Approval	Transactions for which the rule isn't applicable. No notifications are sent.

Note: You can only use an approval group that exists in the BPM.

For detailed instructions on the other columns in the Approvers section, refer to the tool tip on each column header.

Approval Conditions

In the Approval Conditions section you can select the attributes based on which the transaction should be evaluated for the workflow rules. You can also add attribute categories.

To add an attribute category:

Open the list of values associated with the last column in the Approval Conditions section.
Select the required attribute category.

To add an attribute:

Open the list of values associated with the attribute category.
Select the required attribute.

For example, in the Invoice Approval template for Payables, you can select Business Unit and Invoice Amount attributes for the attribute category Invoice Header. Similarly, you can select attributes for categories, such as Invoice Line, Invoice Distributions, and more.

While defining approval conditions, you can use a variety of operators. This table lists the supported operators.

Condition	Value Type	Format	Example
Attribute is a specific value	Text, number, or date	value Note: No specific format applies here.	If the Invoice Type is Standard, then enter the value as: Standard
Attribute value is one of multiple specific values	Text or number	`in (value 1, value 2, ...)`	If the BU name is Vision Operations, Vision Services, or Vision Foods then enter the value as: In (Vision Operations, Vision Services, Vision Foods
Attribute value should be within a range of values	Number or date	between value 1 and value 2 OR value 1 to value 2	If the Invoice Date is between 01 August 2018 to 01 August 2019, then enter the value as: Between 01/aug/2018 and 31/aug/2019 OR 01/aug/2018 to 31/aug/2018
Attribute value starts with a specific value	Text	Starts with value	If the BU name starts with Vision then enter the value as: Starts with Vision
Attribute value ends with a specific value	Text	Ends with value	If the BU name ends with Operations then enter the value as: Ends with Operations
Attribute value contains a specific value	Text	Contains value	If the Pay Group contains Standard then enter the value as: Contains Standard
Attribute value matches a specific value	Text	Matches value	If the Description matches manual invoice then enter the value as: `Matches manual\\s(.) invoice` In this example, the Matches operator begins with Manual and ends with Invoice. Between the two words, there can be one space and any character. Other options that can be used with the Matches operator are: `(.)` - Denotes zero or more characters. `(.+)` - Denotes one or more characters. `\\s` - Denotes space. `\\d` - Denotes numbers from 0-9. `?` - Makes a character optional. For example: `\\d?` `[ ]` - Specifies range such as A-Z, 0-9
Attribute value is more than or equal to a specific number	Number	More than equal to number OR >= number	If the Invoice amount is more than or equal to 500, then enter the value as: More than equal to 500 OR >= 500
Attribute value is less than or equal to a specific number	Number	Less than equal to number OR <= number	If the Invoice amount is less than or equal to 500, then enter the value as: Less than equal to 500 OR <= 500
Attribute value is more than a specific number	Number	More than number OR >number	If the Invoice amount is more than 500, then enter the value as: More than 500 OR >500
Attribute value is less than a specific number	Number	Less than number OR <number	If the Invoice amount is less than 500, then enter the value as: Less than 500 OR <500
Attribute value is on or before a specific date	Date	On or before date	If the Invoice date is on or before 01/10/2018, then enter the value as: On or before 01/oct/2018
Attribute value is on or after a specific date	Date	On or after date	If the Invoice date is on or after 01/10/2018, then enter the value as: On or after 01/oct/2018
Attribute value is before a specific date	Date	Before date	If the Invoice date is before 01/10/2018, then enter the value as: Before 01/oct/2018
Attribute value is after a specific date	Date	After date	If the Invoice date is after 01/10/2018, then enter the value as: After 01/oct/2018
Attribute value is a specific value and the condition must be evaluated as case insensitive	Text	Equals ignore case value	If the Invoice Source is equal to Manual, then enter the value as: Equals ignore case manual

Note: The operators aren't case-sensitive. However, you must enter the date in the DD/MMM/YYYY or DD-MMM-YYYY format only.

If you have a negative approval condition, add Not as a prefix to any of the supported operators. For example, your approval condition states that BU name isn't Vision Operations, Vision Services, or Vision Foods then enter the value as: Not In (Vision Operations, Vision Services, Vision Foods).

If you have two distinct rule conditions that require the same approval routing, then you must enter the rule conditions in two separate rows. Ensure that the information in the Approvers section is identical for both the rows.

Rule Blocks

A rule block is a group of rows in the workflow rules spreadsheet. You can define a business rule and all aspects of the business rule in these rows. Use a separate block for each business rule.

While all rule aspects defined within a rule block are processed simultaneously, rule blocks are processed in sequence. Therefore, before defining the rules, you must consider the sequence in which the rules should be processed.

You can create additional rows in a block and additional blocks in a sheet as needed.

To insert more blocks in a rule block:

Select a row.
Right-click and select Add Block.

To add a rule block after the existing rule blocks, click Add Block in the sheet.

To insert more rows in a rule block:

Select a row and right-click.
From the menu, select Insert.

To delete a rule block:

Select all the rows in a rule block.
Right-click and select Delete Block.

Data Sets

In your approval policy, if the approver of a transaction varies based on the transaction attributes, then you should use a data set. A data set lets you define a mapping between your data and the variation in approvers based on such data.

For example, a transaction with an amount greater than 5000 USD must be approved by an approval group. However, the approval group varies depending on the cost center. In this case, you can use a data set to define a mapping between the cost center and the approval group.

Note: Currently, data sets are only available for templates for Payables Invoice Approval Workflow.

To define a data set, perform these steps:

Open the Data Set sheet of the rule template.
In the Set Name column, enter a unique name.
Enter the value in the Approval Group/Supervisory Level/Job Level Range/User/Role column. This value depends on the approval routing of the rule for which you're using the data set.

For the given example, specify the approval group name in the Approval Group/Supervisory Level/Job Level Range/User/Role column.

Note: You can only use an approval group that already exists in the BPM.
If your starting approver for rules using Supervisory or Job Level Hierarchy approval routing varies based on transaction attributes, then click the Add Start Approver to add the Start Approver column in the dataset. You can select any of the values from the list of values or directly enter a user name as the start approver.

Note: If you're specifying start approver in the dataset, then you must select a value of Use Dataset in the Start Approver column of the Approvers section in the Invoice Approval Rules or Invoice Request Approval Rules sheet as applicable. This ensures that the Start Approvers are picked up from the dataset for such rules.
In the Varying Attribute section, select the attributes based on which the approver varies for the transaction.

For the given example, select Distribution Cost Center Segment from the list of values and specify the cost center values for each approval group.
Enter values for each varying attribute. You can also use the supported operators with the values.
Click Add New Column to create additional columns for varying attributes.
Click Add Data Set to create additional data sets.

After you create a data set, you must enter a data set reference in your rule in the Workflow Rules sheet. Prefix the data set name with $ to create a reference. For example, to reference a data set named Supervisory, enter the value as $Supervisory Set in the Workflow Rules sheet.

You can enter the data set references in the Approvers section of the Workflow Rules sheet. Based on the approval routing used for the rule, enter data set references in these columns:

Job Level Range
Approval Level
Group/User/Role Name

Generate Rule File

After entering the data in the Workflow Rules sheet, click the Generate Rule File button located in the Instructions sheet to generate the rule file. A compressed file is generated. Save the file in your local computer.

Upload the Rule File

To upload the rule file, perform the following steps:

Navigate to the Manage Workflow Rules in Spreadsheet page.
In the Rule Templates section, select the required workflow.
Click Upload. The Upload File dialog box appears.
In the File field, click Choose File.
From your local directory, select the compressed rule file that was generated from the workflow rules template.
Click Submit. A confirmation message stating the process ID appears.

Caution: Every successful rule upload using a spreadsheet template overrides the existing rules for the workflow.
Click OK.
Check the status of the upload in the Upload History section.

Update the Rule Template Version

While uploading your rule template, if you're asked to update the file version, perform the following steps:

Download the latest version of the rule template from the Manage Workflow Rules in Spreadsheet page. You can select any of the available templates for the workflow.
In the Instructions sheet of the rule template, click Update Spreadsheet.
Select the older version of the rule template and click OK.

This copies rules from the older version of your rule template to the latest version.
Review the copied rules and proceed as usual to create rules using the latest version of the rule template.

Verify the Spreadsheet Upload

The Upload History section displays details of the spreadsheet uploads such as the date, user, rule template used, and the status.

If the rule upload process fails, the status is displayed as Error. Click Error to download the Error CSV file. Review the error details, resolve the errors in the spreadsheet, and generate the rule file again.

Related Topics

Modify Workflow Rules Using a Spreadsheet

After creating the rules using a spreadsheet template, you can modify them using a spreadsheet.

Note: Each time you make modifications, a new set of rules are created. The new rules overwrite the existing rules.

To modify workflow rules using a spreadsheet, perform the following steps:

Navigate to the Manage Rules in Spreadsheet page.
In the Rule templates section, select the required workflow.
For the workflow, select the link in the Last Successful Upload column. Save the copy of the last successfully uploaded rule template to your local computer.
Make the necessary changes in the spreadsheet and click Generate Rule File. A compressed file is generated. Save the generated rule file in your local directory.
On the Manage Rules in Spreadsheet page, select the required workflow in the Rule Templates section.
Click Upload. The Upload File dialog box appears.
In the File field, click Choose File.
From your local directory, select the compressed rule file to be uploaded for the rule creation that was generated from the workflow rules template.
Click Submit. A confirmation message stating the process ID appears.
Click OK.
Check the status of the upload in the Upload History section.

Note: If the upload fails, the status is displayed as Error. Click Error to download the Error CSV file. Review the error details, resolve the errors, and generate the rule file again.

Workflow Rule Templates for Journal Approval

The Simplified Workflow Rules Configuration feature enables you to create rules for the General Ledger Approval workflow using a spreadsheet. You can select from among the available sample templates in the Download column on the Manage Workflow Rules in Spreadsheet page:

Journal Approval Basic Template
Journal Approval Sample Template 1
Journal Approval Sample Template 2

Each template contains two worksheets: Instructions and Journal Approval Rules. The Journal Approval Rules worksheet contains sample rules. You can modify them or define your own rules.

You use the templates to create approval rules in accordance with your approval policy. Each sample template contains use cases that you can refer to. You can define your specific rules using any of the templates.

Journal Approval Basic Template: Supervisory Hierarchy-Based Approval

The rule in this template demonstrates the following approval policy requirement:

All journal batches require approval from the direct supervisor of the user submitting the batch for approval.

You don't have to make any changes to this rule to use it.

Note: The General Ledger Journal workflow implementation comes with a predefined rule. That rule is represented in the Journal Approval Basic Template.

Tip: You can upload this sample rule to reset the journal approval rule back to its predefined state.

Journal Approval Sample Template 1: Group-Based Approval

The rules in this template demonstrate the following approval policy requirement:

All journal batches from a specific ledger and from the specific journal sources require approval from one user of the nominated approval groups. The approval group is different when the journal batch has been created by some nominated users and has some specific description.
Journal batches from sources other than these sources are automatically rejected.

The business rule from the approval policy is represented in one block in this template with four listed rules.

To use these rules, ensure:

The approval groups that you enter in the spreadsheet are defined in the approval management application.
The specified users are valid.
The specified ledger ID is valid.

Note: When a journal batch satisfies more than one rule within a block, the notification flow and approval process completion can vary depending on the approval routings specified for those rules within that block. For this template, if a journal batch satisfies more than one rule, all of the users of the nominated groups are notified, and only one user must take an action to complete the approval process.

Journal Approval Sample Template 2: Supervisory Hierarchy and Group-Based Approval

The rules in this template demonstrate the following approval policy requirement. The business rules are represented in multiple blocks depending on the business requirement and the approval routing.

First block: All journal batches for journal sources Manual, AutoCopy, and Spreadsheet, and with a total batch amount greater than 250000, require supervisory approval. Any batch from those same sources with a total batch amount up to 250000 is automatically approved. Journal batches from sources other than these sources don't require this type of approval.
Second block: All journal batches with a total batch amount up to 250000 for journal sources Allocations, Revaluation, and Balance Transfer, require approval from any one member of the designated approval group. All journal batches with a total batch amount up to 250000 for journal sources other than these sources don't require this type of approval. All journal batches with a total batch amount greater than 250000 don't require this type of approval.
Third block: All journal batches with a total batch amount greater than 250000 for the journal sources Allocations, Revaluation, and Balance Transfer, require approval from all members of the designated approval group. All journal batches with a total batch amount greater than 250000 for journal sources other than these sources don't require this type of approval. All journal batches with a total batch amount up to 250000 don't require this type of approval.

To create rules for these business rules, you must first analyze and separate the requirements into distinct rules. All the rules that are included in a block must be collectively exhaustive. It's important that all approval scenarios are defined. If not, errors might occur.

The following table displays the details of the rules that are created to enforce the business requirement presented in the first block in this sample template.

Rule Name	Approval Routing	Approval Condition Attribute	Approval Condition Operator
Source_amount up to 250000	Auto Approve	Journal Batch Total Accounted Credit	<=250000
		Journal Source Name	in (Manual, AutoCopy, Spreadsheet)
Source_amount up to 250000_other source	Skip Approval	Journal Batch Total Accounted Credit	<=250000
		Journal Source Name	not in (Manual, AutoCopy, Spreadsheet)
Source_amount greater than 250000	Supervisory	Journal Batch Total Accounted Credit	>250000
		Journal Source Name	in (Manual, AutoCopy, Spreadsheet)
Source_amount greater than 250000_other source	Skip Approval	Journal Batch Total Accounted Credit	>250000
		Journal Source Name	not in (Manual, AutoCopy, Spreadsheet)

The same logical process is followed to define rules for the remaining approval policy requirements.

To use this rule, ensure the approval groups that you enter in the spreadsheet are defined in the approval management application.

Approval Conditions in Journal Approval Rule Templates

For the journal approval workflow, approval conditions define the criteria that a journal batch is evaluated against. The approval conditions are defined using the attributes available in the drop-down list of each attribute category. There are three default attribute categories: Journal Batch, Journal Header, Journal Line.

You can use the predefined approval conditions in the sample rule templates, or you can modify the conditions to meet your company approval policy requirements.

In addition to the attribute categories displayed in the rule templates, you can add more attribute categories by selecting the drop-down list after the last displayed attribute category.

Here's the list of attribute categories that you can use to define your approval conditions:

Journal Batch Approval Requester
Journal Batch Creator
Journal Batch Ledger
Journal Batch Source
Journal Category
Journal Calendar
Journal Header
Journal Line
Maximum Amount Journal
Maximum Amount Journal Line
Period
Submitted Period

Each attribute category has its own set of attributes that you can select from.

Rule Evaluation Currency Attribute

To create workflow rules that should be evaluated in a specific currency, enter the currency using the attribute Rule Evaluation Currency. The attribute is available for these attribute categories:

Journal Header
Journal Line
Maximum Amount Journal
Maximum Amount Journal Line

Specify the currency value following the ISO 4217 standard. The resulting rules that are created apply Corporate as the rate type and the Accounting Date as the rate date for evaluating transactions that satisfy rule conditions.

Create Journal Approval Rules Using Oracle Business Process Management

Watch video

You can use the Business Process Management Worklist application to configure journal approval rules. For example, you can create journal approval rules that automatically approve a journal batch, or that route the batch for approval based on the ledger and journal amounts.

This procedure creates the following approval rules:

When the largest journal amount in a batch is more than 500, and less than 10,000, the batch requires one level of supervisory approval.
When the largest journal amount is 10,000 or more, two levels of supervisory approval are required.
If the largest journal amount in a batch is 500 or less, the batch doesn't require approval or it's automatically approved.

Create a Rule That Requires One Level of Supervisory Approval

In the Global menu, click the Notifications icon and select More Details. If you're using the news feed default home page layout, then select Show All and click Worklist.
Select Financials. The Business Process Management Worklist application page opens.
Click your user name and select Administration. You can manage the journal approval rules only if you have administrator access.
Click the Task Configuration tab.
From the Tasks to be configured pane, select the FinGLJournalApproval task.
Click Edit task to create the rules.
Click the Assignees tab. The Assignees page shows the participant tree. A participant is a user or set of users in the approval assignment and routing definition. The journal approval task displays three predefined participants. Typically you use only one or two participants, but have the flexibility to add more participants to meet more complex approval requirements. Each participant is associated with one rule set, and a rule set can have one or more approval rules.
On the Supervisory Journal Approver participant, click Go to rule.
Click the Expand icon on the Manager Approval Rule. That's the default predefined approval rule. If a journal's ledger and source are enabled for approval, the rule is configured to send that journal for one level of approval to the supervisor of the person who submitted the journal for approval.
Click the Show Advanced Settings icon.
Click in the Active check box to deselect it. When this check box is cleared, the approval routing process doesn't use the rule.
Click the Add Rule icon.
In the Name field, enter the name of the rule: Between 500 and 10000.
Click Expand. Each rule defines the conditions for when the journal batch should be approved and by whom.

Note: The IF component evaluates the journal based on batch, journal, or journal line-level attributes. The THEN component determines who the approval should be routed to.
In the IF section, click the Left Value icon. The Condition Browser window opens.
Click the Expand icon on the Maximum Amount Journal folder.
Click the Name attribute, which represents the ledger name.
Click OK. The Condition Browser window closes and the attribute name is populated in the Left Value field.
In the Right Value field, enter the name of the ledger in quotation marks, for example, enter "Vision Corporation".

Note: The first condition uses the operator named is. This operator compares the two values.
Click the Add simple test icon from the list to add another condition.
Click the Left Value icon. The Condition Browser window opens.
Expand the Maximum Journal Amount folder and select the Maximum Accounted Amount Credit attribute. This attribute stores the maximum accounted credit amount across all journals in the batch.
Click OK. The Condition Browser window closes.
In the second condition, click in the Operator field and select the operator named between.
Click the Right Value icon. The Right Operand window opens.
In the Operand 1 field, enter the lower limit as 500.
In the Operand 2 field, enter the upper limit as 10000.
Click OK. The Right Operand window closes.
To configure the action to send the journal batch for one level of supervisory approval, click the Add Action icon in the THEN section.
Select Add Approver and select Supervisory.

Note: The Supervisory list builder generates the list of approvers by moving up the supervisory hierarchy that's set up in the Human Resources application. Specify the number of approvers, the first approver, and the highest possible approver.
To route the journal batch for one level of supervisory approval, in the Number of levels field, enter 1.
In the Starting Participant field, click Search. The Add Hierarchy Participant window opens and the Get Manager option is selected by default.
For this rule, the starting participant or first approver, is going to be the manager of the person who submits the journal batch for approval. In the Reference User field, enter Task.Workflow Submitter.
Click OK. The Add Hierarchy Participant window closes.
In the Top Participant field, click Search. The Add Hierarchy Participant window opens.

Note: The top participant is the last user in the approval hierarchy. The list builder continues to add users to the approvers list from the supervisory hierarchy of the first approver, until the number of levels is met, or the top participant is reached.
Click the Get User button.
In the Reference User field, enter the sign in name of the top participant within quotation marks.
Click OK. The Add Hierarchy Participant window closes.
From the Tasks to be configured pane, click Save. The Enter Comments window opens.
Click OK. The Enter Comments window closes and a message appears stating that the rule has been saved.
Click OK.

Create a Rule That Requires Two Levels of Supervisory Approval

Create a rule for the same ledger requiring two levels of supervisory approval if the largest journal amount is 10,000 or more. Copy the first rule and make changes for this second rule.

Click the Assignees tab.
Select the first rule.
Click the list on the Cut icon and select Copy.
Click the list on the Cut icon and select Paste. The second rule appears after the first rule.
In the Name field for the second rule, enter Greater than 10000.
Click Expand.
The first condition in the IF section that checks for the ledger, stays the same. Change the operator of the second condition to same or more than.
In the Right Value field, enter 10000.
In the THEN section, in the Number of levels field, enter 2.
Click Collapse. The second approval rule is complete.

Create a Rule That Automatically Approves Journals

Create the rule that automatically approves journals that are 500 or less for a specific ledger. The rule must also ensure that journal batches for all other ledgers are automatically approved as well.

Caution: It's very important that the rules in a rule set cover all conditions and are collectively exhaustive. If not, errors might occur.

Select the first rule.
Click the list on the Cut icon and select Copy.
Click the list on the Cut icon and select Paste. The third rule appears after the first rule.
Click in the Rule Name field and rename the third rule to Less than 500.
Click the Expand icon to open the new rule.
Create a condition for journals 500 or less in the specified ledger by first grouping the two existing conditions together. In the IF section, click both conditions to select them.
Click the Surround selected tests with parenthesis icon. Both conditions are now enclosed within a set of parentheses.
Click in the Operator field of the second condition and select same or less than from the list. The amount automatically changes to 500.
Now add another condition to cover all of the other batches that don't have journals for the specified ledger. Click the Add simple test icon. A third condition row is added after the two grouped conditions.
Since this new condition is mutually exclusive to the grouped conditions, click the connector to change it from and to or.
Click the Left Value icon. The Condition Browser window opens.
Expand the Maximum Journal Amount folder and select Name.
Click OK. The Condition Browser window closes.
Click in the Operator field and select the operator named isn't.
In the Right Value field, enter the name of the ledger in quotation marks.
Now set up the automatic approval. The Supervisory list builder has two parameters that override the supervisory approval and return a preconfigured approval action. In the THEN section, click in the Auto Action Enabled field, and select True.
In the Auto Action field, enter "APPROVE". Include the quotation marks.
Collapse the rule.

You have now defined three rules that meet the business requirements and are collectively exhaustive. All journal batches satisfy the conditions in at least one of the three rules and are routed for approval accordingly. If a journal batch doesn't satisfy the conditions in at least one rule within a rule set, the rule evaluation process would fail with errors.
Deploy the rules so that they can be used. On the Tasks to be configured toolbar, click the Commit Task icon. The Enter Comments window opens.
Click OK. The Enter Comments window closes and a message appears stating that the data rule has been saved and committed.
Click OK.

After journal approval is enabled, journal batches being posted are submitted for approval based on these rules.

Predefined Journal Approval Participants and Attributes

You can configure journal approval rules in the Business Process Management Worklist application. Open the Worklist application by selecting the Notifications icon on the home page and clicking More Details or, by using the following in the Setup and Maintenance work area:

Offering: Financials
Functional Area: Application Extensions
Task: Manage Task Configurations for Financials

The name of the journal approval workflow task is FinGlJournalApproval.

Assignees

Assignees, also called participants, are users or a set of users that an approval request is routed to. There are four types of assignees.

Single: Maps to a user, group, or role. Select this type if the approval request requires only a single user to approve. When the request is sent to a group or to an application role, all of the users within that group or that carry that application role receive the notification, but only one user's approval is required.
Parallel: Indicates that a set of people work in parallel and that everyone's approval is required. For example, a journal batch affects multiple lines of business and requires approval from the controllers for each line of business. The controllers can approve the journal batch in parallel.
Serial: Indicates that a set of users must work in sequence. The most common scenario is supervisory chain approval, which is done by specifying that the list is based on a supervisory chain.
FYI: Maps to a single user, group, or role, just as the Single assignee type. However, this type of assignee just receives a notification, and the business process doesn't wait for the assignee's response. FYI assignees can't directly impact the outcome of a task, but in some cases can provide comments or add attachments.

The journal approval workflow task contains three assignees (participants) with a type of Single, Serial, and Parallel, each. These three predefined assignees are arranged in the parallel mode. Assignees can be arranged in parallel or sequential mode. For assignees in parallel mode, a task is assigned and notifications are sent to all of the assignees at once in parallel. For assignees in sequential mode, a task is assigned and notifications are sent in a sequential manner, meaning one after another, to each assignee.

You can select to use any one, or combination of, the three assignees. You can delete them, or add new ones as needed. The Serial type assignee has a predefined journal approval rule based on the requester's supervisory hierarchy. If a ledger and journal source are enabled for approval, the predefined journal approval rule sends a journal belonging to that ledger and source to the requester's manager for approval.

Attributes

The tables in this section list the objects and attributes that appear in the Condition Browser window in the Worklist application.

The following table describes the attributes for the Journal Batch object.

Name	Description
Accounting Period Type	Name of the accounting calendar.
Batch Type Indicator	Indicator for the type of amounts that the batch contains. Valid values are A or E, representing the following respective types: Actual and Encumbrance.
Approval Status	Approval status of the journal batch. Valid values are A, I, J, V, R, or Z, representing the following respective statuses: Approved, In Process, Rejected, Validation Error, Required, and Not Required. For Oracle internal use only.
Approver Employee ID	Internal identifier of the employee who submitted the batch for approval. For Oracle internal use only.
Average Balance Journal Indicator	Indicator for whether the journal is an average balance journal. Valid values are Y or N, representing Yes and No.
Batch Amount	Amount of the journal batch.
Budgetary Control Status	Not currently used.
Calendar	Reference to the Calendar object. For Oracle internal use only.
Chart of Accounts ID	Internal identifier of the chart of accounts.
Control Total	Control total of the journal batch.
Created By	Sign in name of the user who created the journal batch.
Creation Date and Time	Date and time when the journal batch was created.
Creation Date	Date when the journal batch was created. For Oracle internal use only.
Default Accounting Date	Internal default accounting date. For Oracle internal use only.
Accounting Period Name	Accounting period of the journal batch.
Description	Description of the journal batch.
Earliest Postable Date	For Oracle internal use only.
Group ID	Internal identifier of the interface group. For Oracle internal use only.
Batch ID	Internal identifier of the journal batch. For Oracle internal use only.
Source	Internal identifier of the journal source. For Oracle internal use only.
Journal Batch Ledger	Reference to the Journal Batch Ledger object. For Oracle internal use only.
Journal Batch Source	Reference to the Journal Batch Source object. For Oracle internal use only.
Journal Header	Reference to the Journal Header object. For Oracle internal use only.
Last Updated Date	Date when the journal batch was last updated.
Last Updated Login	For Oracle internal use only.
Last Updated By	Sign in name of the user who last updated the batch.
Lookup Code	For Oracle internal use only.
Lookup Type	For Oracle internal use only.
Maximum Amount Journal	Reference to the Maximum Amount Journal object. For Oracle internal use only.
Maximum Journal Line Amount	Reference to the Maximum Journal Line Amount object. For Oracle internal use only.
Batch Type	Full text value for the Batch Type Indicator attribute. Valid values are Actual or Encumbrance.
Name	Name of the journal batch.
Object Version Number	For Oracle internal use only.
Packet ID	For Oracle internal use only.
Parent Batch ID	For Oracle internal use only.
Period	Reference to the Period object. For Oracle internal use only.
Accounting Period Set Name	Accounting calendar name for the accounting period.
Posted Date	For Oracle internal use only.
Posting Run ID	Internal identifier. For Oracle internal use only.
Request ID	Internal identifier. For Oracle internal use only.
Accounted Running Total Credit	Total accounted credit amount of the journal batch.
Accounting Running Total Debit	Total accounted debit amount of the journal batch.
Entered Running Total Credit	Total entered credit amount of the journal batch.
Entered Running Total Debit	Total entered debit amount of the journal batch.
Status	Status of the journal batch. Valid values are u, U, S, I, or P, representing the following respective statuses: Incomplete, Unposted, Selected for Posting, Processing, and Posted.
Status Verified by Posting Indicator	Indicator for whether the status of the journal batch has been verified. Valid values are Y and N, representing Yes and No. For Oracle internal use only.
Submitted Period	Reference to the Submitted Period object. For Oracle internal use only.
Not Reserved Packet ID	For Oracle internal use only.
Journal Batch Creator	Reference to the Journal Batch Creator object. For Oracle internal use only.
Journal Batch Approval Requester	Reference to the Journal Batch Approval Requester object. For Oracle internal use only.
Descriptive Flexfield Structure Definition 1	Structure definition of the Journal Batches descriptive flexfield.
Descriptive Flexfield Attributes 1 through 10	Segments of the Journal Batches descriptive flexfield.
Funds Status	Budgetary control status for the batch. A list of valid values can be found in the lookup type XCC_BC_FUNDS_STATUSES. For example, RESERVED_PARTIAL or RESERVED_PASSED, representing Partially reserved and Reserved.

The following table describes the attributes for the Journal Batch Ledger object.

Name	Description
Batch ID	Internal identifier of the journal batch. For Oracle internal use only.
Currency	Currency of the ledger. For example USD or EUR.
Ledger Category Code	Category of the ledger. Valid values are SECONDARY, PRIMARY, NONE, and ALC, representing the following respective categories: Secondary Ledger, Primary Ledger, None, and Reporting Currency.
Ledger Enabled for Journal Approvals Indicator	Indicator for whether approval is enabled for the ledger. Valid values are Y or N, representing Yes and No.
Ledger ID	Internal identifier of the ledger.
Ledger Name	Name of the ledger.
Meaning	For Oracle internal use only.
Period Set Name	Internal name for the accounting calendar, which is the original calendar name that a user entered. For Oracle internal use only.
Primary Ledger Currency	Ledger currency defined for the primary ledger. For example, USD or EUR.
Descriptive Flexfield Structure Definition	Structure definition of the Ledgers descriptive flexfield.
Descriptive Flexfield Attributes 1 through 15	Segments 1 through 15 of the Ledgers descriptive flexfield.

The following table describes the attributes for the Journal Batch Source object.

Name	Description
Journal Source ID	Internal identifier of the journal source. For Oracle internal use only.
Journal Reference Indicator	Indicates whether journal import saves the references to the subledger transactions. Saved references let you drill from a general ledger journal to the subledger transaction. Valid values are Y or N, representing Yes and No.
Override Edits Indicator	Indicator for whether a user can update the journal that has the journal source. Valid values are Y, N, or P, representing Yes, No, and Partial, respectively.
Type	Identifies whether the source for the batch is a subledger application. Valid values are SLA or Non-SLA, representing subledger accounting and nonsubledger accounting, respectively.
Journal Source Name	User-defined name for the journal source.
Source Key	Unique identifier for a journal source.
Descriptive Flexfield Attributes 1 through 5	Segments 1 through 5 of the Journal Sources descriptive flexfield.

The following table describes the attributes for the Journal Calendar object.

Name	Description
Calendar ID	Internal identifier of the accounting calendar. For Oracle internal use only.
Period Set ID	Internal identifier. For Oracle internal use only.
Period Set Name	Name of the accounting calendar when first created. If the calendar name is later changed in the user interface, this original name remains stored internally as a unique identifier. For Oracle internal use only.
Period Type	Internally generated value based on period frequency of the accounting calendar. For Oracle internal use only.
Period Type ID	Internal identifier of the period type. For Oracle internal use only.
User Period Set Name	Current name of the accounting calendar.
Descriptive Flexfield Structure Definition	Structure definition of the Calendars descriptive flexfield.
Descriptive Flexfield Attributes 1 through 5	Segments 1 through 5 of the Calendars descriptive flexfield.

The following table describes the attributes for the Journal Category object.

Name	Description
Category ID	Internal identifier of the journal category. For Oracle internal use only.
Journal Category Name	Translated name of the journal category. Might not uniquely identify a category in an approval rule. Varies depending on a user's language setting.
Category Key	User-defined category key that uniquely identifies the category.
Descriptive Flexfield Structure Definition	Structure definition of the Journal Categories descriptive flexfield.
Descriptive Flexfield Attributes 1 through 5	Segments 1 through 5 of the Journal Categories descriptive flexfield.

The following table describes the attributes for the Journal Header object.

Name	Description
Reversed Journal Indicator	Indicator for whether the journal was reversed. Valid values are Y or N, representing Yes and No.
Accounted Currency	Currency of the ledger. For example, USD or EUR.
Accounting Date	Accounting date of the journal.
Batch ID	Internal identifier of the journal batch. For Oracle internal use only.
Category	Internal identifier of the journal category. For Oracle internal use only.
Journal from Subledger Indicator	Indicator for whether the journal was created through subledger accounting. Valid values are Y or N, representing Yes and No.
Header ID	Internal identifier of the journal. For Oracle internal use only.
Journal Header Category	Reference to the Journal Header Category object. For Oracle internal use only.
Journal Line	Reference to the Journal Line object. For Oracle internal use only.
Ledger ID	Identifier for the ledger.
Ledger Name	Name of the ledger.
Reference Date	Reference date entered for the journal.
Running Total Accounted Credit	Total accounted credit amount of the journal.
Running Total Accounted Debit	Total accounted debit amount of the journal.
Attachment Exists Indicator	Indicator for whether the journal has attachments. Valid values are Y or N, representing Yes and No.
Entered Currency	Entered currency of the journal. For example, USD or EUR.
Journal Description	Description of the journal.
Journal Name	Name of the journal.
Reversing Journal Indicator	Indicator for whether the journal resulted from a reversal. Values are Y or N, representing Yes and No.
Clearing Company	Intercompany clearing entity used to balance the journal.
Control Total	Control total entered for the journal.
Conversion Date	Date for the conversion rate, which is used to convert an amount into another currency.
Encumbrance Type	Type of encumbrance for journal batches with the Encumbrance batch type.
Journal Reference	Additional information entered by a user.
Legal Entity	Name of the legal entity associated with the journal.
Total Entered Credit	Total journal batch credit amount in the entered currency.
Total Entered Debit	Total journal batch debit amount in the entered currency.
Conversion Rate Type	Source of a currency conversion rate, such as User, Spot, or Corporate.
Descriptive Flexfield Structure Definition 1	Structure definition of the Journals descriptive flexfield.
Descriptive Flexfield Attributes 1 through 10	Segments 1 through 10 of the Journals descriptive flexfield.

The following table describes the attributes for the Journal Line object.

Name	Description
Accounted Credit	Accounted credit amount of the journal line.
Accounted Debit	Accounted debit amount of the journal line.
Entered Currency	Entered currency of the journal line. For example, USD or EUR.
Accounted Currency	Ledger currency of the journal line. For example, USD or EUR
Entered Credit	Entered credit amount of the journal line.
Entered Debit	Entered debit amount of the journal line.
Header ID	Internal identifier of the journal. For Oracle internal use only.
Line Number	Number of the journal line.
Ledger ID	Internal identifier of the ledger. For Oracle internal use only.
Ledger ID 1	For Oracle internal use only.
Account	Reference to the Account object. For Oracle internal use only.
Chart of Accounts ID	Internal identifier of the chart of accounts.
Account Combination ID	Internal identifier of the account combination.
Concatenated Segment	For Oracle internal use only.
Account Combination	Concatenated segments separated by the key flexfield delimiter. For example, 101-10-110-11010-0000.
Account Type	Valid values are A, L, E, R, or O, representing the following respective account types: Asset, Liability, Expense, Revenue, and Owner Equity.
Conversion Date	Date for the conversion rate, which is used to convert an amount into another currency.
Conversion Rate Type	Source of a currency conversion rate, such as User, Spot, or Corporate.
Descriptive Flexfield Structure Definition 1	Structure definition of the Journal Lines descriptive flexfield.
Descriptive Flexfield Attributes 1 through 10	Segments 1 through 10 of the Journal Lines descriptive flexfield.
Descriptive Flexfield Structure Definition 3	Structure definition of the Journals Captured Information descriptive flexfield.
Descriptive Flexfield Attributes 11 through 20	Segments 11 - 20 of the Journals Captured Information descriptive flexfield.

The following table describes the attributes for the Maximum Amount Journal object.

Name	Description
Batch ID	Internal identifier of the batch. For Oracle internal use only.
Journal Ledger Category Code	Category of the ledger. Valid values are SECONDARY, PRIMARY, NONE, and ALC, representing the following respective categories: Secondary Ledger, Primary Ledger, None, and Reporting Currency.
Ledger Enabled for Journal Approval Indicator	Indicator for whether approval is enabled for the ledger. Valid values are Y or N, representing Yes and No.
Ledger ID	Internal identifier for the ledger. For Oracle internal use only.
Name	Name of the ledger.
Maximum Accounted Amount Credit	Maximum accounted credit journal amount of the journal batch.
Maximum Accounted Amount Debit	Maximum accounted debit journal amount of the journal batch.
Maximum Net Accounted Amount	Maximum accounted net journal amount of the journal batch.
Accounted Currency	Currency of the ledger. For example, USD or EUR.

The following table describes the attributes for the Maximum Amount Journal Line object.

Name	Description
Batch ID	Internal identifier of the journal batch. For Oracle internal use only.
Journal Ledger Category Code	Category of the ledger. Valid values are SECONDARY, PRIMARY, NONE, and ALC, representing the following respective categories: Secondary Ledger, Primary Ledger, None, and Reporting Currency.
Ledger Enabled for Journal Approval Indicator	Indicator for whether approval is enabled for the ledger. Valid values are Y or N, representing Yes and No.
Ledger ID	Identifier of the ledger. For Oracle internal use only.
Ledger Name	Name of the ledger.
Maximum Accounted Line Amount Credit	Maximum accounted credit amount of a journal line in the journal batch for the ledger. For example, if a journal batch has five credit lines, this attribute holds the largest value of those five credit lines.
Maximum Accounted Line Amount Debit	Maximum accounted debit amount of a journal line in the journal batch for the ledger. For example, if a journal batch has five debit lines, this attribute holds the largest value of those five debit lines.
Maximum Net Accounted Line Amount	Maximum accounted net amount of a journal line in the journal batch for the ledger.
Accounted Currency	Currency of the ledger. For example, USD or EUR.

The following table describes the attributes for the Period object, which has details for the period that the journal belongs to.

Name	Description
Description	Description of the accounting period.
End Date	End date of the accounting period.
Name	Name of the accounting period.
Number	Number of the accounting period in the fiscal year.
Set Name	Name of the accounting calendar when first created. If the calendar name is later changed in the user interface, this original name remains stored internally as a unique identifier.
Type	Internally generated value based on the period frequency of the accounting calendar. For Oracle internal use only.
Year	Year for the accounting period.
Quarter Number	Quarter number of the accounting period.
Start Date	Start date of the accounting period.
Adjustment Period Indicator	Indicator for whether the period is an adjustment period. Valid values are Y or N, representing Yes and No.
Descriptive Flexfield Structure Definition	Structure definition of the Accounting Calendar Periods descriptive flexfield.
Descriptive Flexfield Attributes 1 through 8	Segments 1 through 8 of the Accounting Calendar Periods descriptive flexfield.
Descriptive Flexfield Dates 1 through 5	Date segments 1 through 5 of the Accounting Calendar Periods descriptive flexfield.
Descriptive Flexfield Numbers 1 through 5	Number segments 1 through 5 of the Accounting Calendar Periods descriptive flexfield.

The following table describes the attributes for the Submitted Period object, which has details for the period in which a journal was submitted for approval.

Name	Description
Adjustment Period Indicator	Indicator for whether the period is an adjustment period. Valid values are Y or N, representing Yes and No.
End Date	End date of the accounting period.
Most Recent Period End Date	End date of the accounting period that's two months before the current accounting period. For example, if a journal is submitted for approval in February 2018, this attribute would contain December 31, 2017.
Name	Name of the accounting period for the journal.
Number	Number of the accounting period in the fiscal year.
Set Name	Name of the accounting calendar when first created. If the calendar name is later changed in the user interface, this original name remains stored internally as a unique identifier.
Type	Internally generated value based on the period frequency of the accounting calendar. For Oracle internal use only.
Year	Accounting period year.
Previous Period End Date	End date of the previous accounting period. For example, if a journal is submitted for approval in February 2018, this attribute would contain January 31, 2018.
Start Date	Start date of the accounting period.
Descriptive Flexfield Structure Definition	Structure definition of the Accounting Calendar Periods descriptive flexfield.
Descriptive Flexfield Attributes 1 through 8	Segments 1 through 8 of the Accounting Calendar Periods descriptive flexfield.
Descriptive Flexfield Dates 1 through 5	Date segments 1 through 5 of the Accounting Calendar Periods descriptive flexfield.
Descriptive Flexfield Numbers 1 through 5	Number segments 1 through 5 of the Accounting Calendar Periods descriptive flexfield.

Related Topics

Update Existing Setup Data

Examples of Maximum Amount Journal and Maximum Amount Journal Line Objects in Journal Approval Rules

You can configure journal approval rules in the Business Process Management Worklist application. Open the Worklist application by selecting the Notifications icon on the home page and clicking More Details or, by using the following in the Setup and Maintenance work area:

Offering: Financials
Functional Area: Application Extensions
Task: Manage Task Configurations for Financials

The name of the journal approval workflow task is FinGlJournalApproval.

To configure journal approval rules that route journals for approval based on amounts, you can use the Maximum Amount Journal and Maximum Amount Journal Line objects in your approval rule definitions.

Maximum Amount Journal

To route journal batches for approval based on the largest journal amount within a batch, you can use the Maximum Amount Journal object in your approval rule definition. For a journal batch, this object contains the maximum accounted debit and credit amounts at the journal level, per ledger.

The following table shows an example of a journal batch that has four journals for two ledgers with different ledger currencies.

Journal	Ledger	Ledger Currency	Accounted Amount
1	USA	USD	500
2	USA	USD	700
3	France	EUR	500
4	France	EUR	900

Note: Since each journal balances, the value in the Accounted Amount column represents the sum of all of the debits, as well as the sum of all of the credits for each journal.

For the USA ledger, journal 2 has the largest accounted amount of 700. For the France ledger, journal 4 has the largest accounted amount of 900. This journal batch is represented in the Maximum Amount Journal object by two rows of information, one row for each ledger.

The following table shows the relevant attributes in the Maximum Amount Journal object and the values that these attributes contain.

Name (Ledger)	Maximum Accounted Amount Debit	Maximum Accounted Amount Credit
USA	700	700
France	900	900

The values for the debit and credit amount attributes for the USA ledger row are 700, and the values for the debit and credit amount attributes for the France ledger row are 900.

Maximum Amount Journal Line

To route journal batches for approval based on the largest journal line amounts, you can use the Maximum Amount Journal Line object in your approval rule definition. For a journal batch, this object contains the maximum accounted debit and credit amounts at the journal line level, per ledger.

The following table shows an example of a journal batch that has two journals for two ledgers with different ledger currencies. Each journal has four lines.

Journal	Ledger	Ledger Currency	Journal Line Number	Accounted Debit	Accounted Credit
1	USA	USD	1	400
1	USA	USD	2	100
1	USA	USD	3		400
1	USA	USD	4		100
2	France	EUR	1	200
2	France	EUR	2	300
2	France	EUR	3		200
2	France	EUR	4		300

For the USA ledger, the journal line with the largest accounted debit is number 1 with 400. The journal line with the largest accounted credit is number 3, also with 400. For the France ledger, the journal line with the largest accounted debit is number 2 with 300. The journal line with the largest accounted credit is number 4, also with 300. This journal batch is represented in the Maximum Amount Journal Line object by two rows of information, one row for each ledger.

The following table shows the relevant attributes in the Maximum Amount Journal Line object and the values that the attributes contain.

Ledger Name	Maximum Accounted Line Amount Debit	Maximum Accounted Line Amount Credit
USA	400	400
France	300	300

The values for the debit and credit amount attributes for the USA ledger row are 400, and the values for the debit and credit amount attributes for the France ledger row are 300.

Related Topics

Update Existing Setup Data

Journal Approval Notifications

Overview of Financials Configurable Workflow Notifications

The Financial applications, as part of certain business flows, automatically send notifications for review or approval. For example, when a user submits an expense report, the approvers receive an email containing the approval request.

In addition to getting notifications in email, users can also view in-app notifications, for example, by:

Clicking the Notifications icon in the global header and opening a notification
Going to the Worklist: Notifications and Approvals work area and opening a notification
Clicking the In-App Notification link at the end of an email notification

Oracle Business Intelligence (BI) Publisher reports are used for some flows to generate the notification content and format. You can enable BI Publisher-based notifications, which are ready to use as delivered. The notification templates can be easily configured to meet other specific requirements. If required, you can change the delivered template layouts and content, to add images, change colors and styling, add or remove attributes or modify text.

This table shows the products that have configurable notifications, along with their associated features, and workflow task names. You can configure only the email notifications for these tasks.

Product	Feature Name	Report or Notification Name	Workflow Task Name
Bill Management	User Registrations Notifications	Registration Confirmation New Account Registration Confirmation Account Access Revocation Notification Access Revocation Notification	N/A
Budgetary Control	Budgetary Control Override Email Notifications	Budget Override Request Notification Budget	OverrideNotificationFyi
Budgetary Control	Budgetary Control Override Email Notifications	Override Taken Notification	OverrideNotificationFyi

Product

Feature Name

Report or Notification Name

Workflow Task Name

Bill Management

User Registrations Notifications

Registration Confirmation

New Account Registration Confirmation

Account Access Revocation Notification

Access Revocation Notification

N/A

Budgetary Control

Budgetary Control Override Email Notifications

Budget Override Request Notification Budget

OverrideNotificationFyi

Budgetary Control

Budgetary Control Override Email Notifications

Override Taken Notification

OverrideNotificationFyi

This table shows the products that have configurable notifications, along with their associated features, and workflow task names. You can configure both the email and in-app notifications for these workflow tasks.

Product	Feature Name	Report or Notification Name	Workflow Task Name
Advanced Collections	Configurable Collections Bankruptcy Workflow Notification	Bankruptcy Notification	BankruptcyApproval
Expenses	Expense Report Approval Notifications	Expense Report Approval Notification	FinExmWorkflowExpenseApproval
Expenses	Expense Reimbursement Notifications	Reimbursement Paid to Card Issuer Notification Reimbursement Paid by Check Notification Reimbursement Paid by Direct Deposit Notification	FinExmReimToCardIssuerFyi FinExmReimToEmpByCheckFyiFin ExmReimToEmpByDepositFyi
Expenses	Expense Audit and Receipt Management Notifications	Expense Report Adjusted by Auditor Notification Expense Report Rejected by Auditor Notification Pending Payment with Warnings Notification Expense Report Returned by Auditor Notification Short-Paid Report with Receipt Issue Notification Short-Paid Report with Noncompliance Notification	FinExmExpenseAuditFyi FinExmExpenseAuditFyi FinExmExpenseAuditFyi FinExmReceiptManagementFyi FinExmReportShortpaidReceiptIssue FinExmReportShortpaidPolicyIssue
Expenses	Cash Advance Notifications	Cash Advances Approval Notification	FinExmWorkflowCashAdvanceApproval
Expenses	Expense Audit and Receipt Management Notifications	Payment is Held Notification	FinExmReceiptManagementFyi
Expenses	Expense Audit and Receipt Management Notifications	Payment is Released Notification	FinExmReceiptManagementFyi
Expenses	Expense Reimbursement Notifications	Reimbursement Has Been Paid to Employer Notification	FinExmReimToEmpByCheckFyi
Expenses	Expense Audit and Receipt Management Notifications	Mileage Adjustment Notification	ExpenseAuditMileageAdjustmentFyi
Expenses	Expense Audit and Receipt Management Notifications	Missing Receipt Declaration is Required Notification	FinExmReceiptManagementFyi
Expenses	Cash Advances Notifications	Overdue Cash Advance Notification	FinExmWorkflowOverdueNotification
Expenses	Cash Advances Notifications	Cash Advances Automatically Applied Notification	FinExmWorkflowCashAdvanceAutoAppliedFyi
Expenses	Expense Audit and Receipt Management Notifications	Inactive Employee's Outstanding Transactions Notification	FinExmInactiveEmployeeSubmitExpenseFyi
Expenses	Expense Audit and Receipt Management Notifications	Inactive Employee-Accept Responsibility Notification	FinExmInactiveEmployeeAcceptResp
General Ledger	Journal Approval Notifications	Journal Approval Report	FinGlJournalApproval
Intercompany	Intercompany Email Notifications	Intercompany Transaction Approval Notification Intercompany Enter Receiver Distribution Notification	FinFunTransactionApproval for Intercompany Transaction Approval Notification FinFunEnterDistRequestForAction for Intercompany Enter Receiver Distribution Notification
Payables	Invoice Approval Notifications	Invoice Approval Report	FinApInvoiceApproval
Payables	Hold Resolution Notifications	Hold Resolution Notification	FinApHoldApproval
Payables	Payment Approval Notifications	Payment Approval Notification	PaymentApproval
Payables	Invoice Account Coding Notifications	Invoice Account Coding Email Notification	FinApInvoiceAccountCoding
Receivables	Manual Credit Memo Request Notification	Manual Credit Memo Request Notification	FinArTrxnsCreditMemosCreationPostProcessing

Process Overview

Generating configurable notifications through BI Publisher involves various types of objects in the BI catalog, including data models, subtemplates, style templates, and reports. Reports pull data from data models and generate notifications in an HTML format. The report layout templates use common table and paragraph styles and refer to a central subtemplate that contains reusable notification components.

This figure shows how these BI objects work together to generate the notification content.

BI Publisher objects, including data model, subtemplate,
style template, layout template, and report, working together to generate
HTML output for workflow notifications.

Data Sources: Store the attributes and attribute values for business objects and transactions in the application (example of data sources being transaction tables)
Data Model: Determines which attributes from data sources are available to be included in the notification and how that data is retrieved
Subtemplate: Provides common components, such as a branding logo and buttons, that can be reused in multiple reports.
Style Template: Provides styles such as the type of lines and fonts to use in tables, or the font type, size, and color to use for headings
Report: Contains a layout template that determines:
- Which attributes appear in the notification, from the data model used for the report
- What the notification looks like, leveraging components from the subtemplate and styles from the style template used for the report
HTML: Format of the output generated by the report
Email Notification: Has the HTML output embedded in the email body
In-App Notification: Has the HTML output embedded in the application UI

Each workflow task with configurable notifications has a corresponding predefined report in the BI catalog. For example, the Invoice Approval report contains the Invoice Approval Notifications report layout template and uses the Invoice Approval Data Model.

Notification Modifications

After you enable configurable workflow notifications, the predefined reports and related objects in the BI catalog work by default. The report-based notifications provide the same information as the standard notifications. In addition, the format of report-based notifications is optimized for mobile devices. If you need to modify the notifications, you can edit copies of the predefined reports, data models, and subtemplate. However, you can't change the style template. You proceed as you would to edit any report, data model, or subtemplate in the catalog, for example:

Find a predefined report for expense approval in the BI catalog.
Use the Customize option to create a copy, or copy the report and paste it within the Custom folder.
Edit the copied report layout template.

Before modifying configurable notifications, it's recommended that you familiarize yourself with BI Publisher in general. This improves your ability to format your notifications to meet your business requirements.

With BI Publisher-based notifications you:

Use only the Template Builder for Word add-in to edit the .rtf template in Microsoft Word, rather than the layout editor or other tools available for creating and editing report layout.
Edit a copy of predefined layout templates, rather than creating reports or layout templates.

Note: For more information, see Configurable Workflow Notifications: Implementation Considerations (2215570.1) on My Oracle Support at https://support.oracle.com.

Steps to Enable

In the Offerings work area, enable the configurable notifications feature as follows:

Offering: Financials
Functional Area: Budgetary Control, Expenses, Intercompany, General Ledger, or Payables
Feature: Configurable Workflow Notifications
Choices: The specific notifications you want to enable
Click Done.

For configurable email notifications, make sure that the email domain setup is correct in BI Publisher so that the emails get sent.

Related Topics

Apply Changes to Workflow Notifications Soon After Upload

Configurable workflow notifications are refreshed every 24 hours so that they perform better for your users. But when you're making changes to reports, subtemplates, or data models, you can apply your changes sooner so they're available for testing. Create profile options to control when notifications reflect your changes after you upload them to the BI catalog. When you're done configuring notifications, use the same profile options to turn the refresh back to every 24 hours, to optimize performance. But even if you don't, the refresh automatically resets to 24 hours when it's been more than eight hours since you set the profile options.

Note: The refresh applies only to changes uploaded to the BI catalog and the actual notifications that are then sent out with your changes. You can always preview changes to layout templates while you're editing in Microsoft Word or view the report in BI Publisher.

Create Profile Options to Control the Refresh

Your profile options can apply to all workflow tasks, a product family, or a product. Based on the scope you want, your profile option must have a profile option code that follows a certain format.

Scope	Profile Option Code	Examples
Global	BIP_CLIENT_REFRESH_TIME	BIP_CLIENT_REFRESH_TIME
Product Family	BIP_CLIENT_REFRESH_TIME_<FAMILY>	BIP_CLIENT_REFRESH_TIME_FIN BIP_CLIENT_REFRESH_TIME_HCM BIP_CLIENT_REFRESH_TIME_PRC BIP_CLIENT_REFRESH_TIME_PRJ BIP_CLIENT_REFRESH_TIME_SCM
Product	BIP_CLIENT_REFRESH_TIME_<FAMILY>_<PRODUCT>	BIP_CLIENT_REFRESH_TIME_FIN_AP BIP_CLIENT_REFRESH_TIME_HCM_PER BIP_CLIENT_REFRESH_TIME_PRC_PON BIP_CLIENT_REFRESH_TIME_PRJ_PJE BIP_CLIENT_REFRESH_TIME_SCM_EGO

The profile options with a smaller scope take precedence. For example, you have profile option A with a global scope and profile option B with a product scope. If you're currently configuring notifications for a particular product, use profile option B to adjust the refresh time just for that product. But based on profile option A, the refresh is still at 24 hours for all other configurable notifications in all other products. Profile option B takes precedence over profile option A only for that one product.

Tip: To find the product family or product code, go to the Setup and Maintenance work area. Use the Manage Taxonomy Hierarchy task in the Application Extensions functional area for any offering. In the hierarchy, expand the root node and then the Oracle Fusion node. Find the row for the family or product and look in the Module Key column for the code.

Now you're ready to create your profile options!

In the Setup and Maintenance work area, go to the Manage Applications Core Profile Options task in the Application Extensions functional area for your offering.
On the Manage Applications Core Profile Options page, click the New icon.
On the Create Profile Option page, enter the profile option code in the format that corresponds to the scope you want.
Enter a display name that you can easily remember to help you find the profile option later.
From the Application list, select Oracle Middleware Extensions for Applications.
From the Module list, select Application Core.
Specify a start date.
Click Save and Close.
On the Manage Applications Core Profile Options page, make sure your new profile option is selected in the Search Results: Profile Options subsection.
In the <Profile Option>: Profile Option Levels subsection, select the Enabled and Updatable check boxes for the Site level.
Save your work.

Set the Refresh Interval

In the Setup and Maintenance work area, go to the Manage Applications Core Administrator Profile Values task in the Application Extensions functional area. Set your profile option at the Site level and enter 15 or higher for the refresh interval in minutes. For example, if you enter 15, then your changes are applied to notifications 15 minutes after you upload to the BI catalog.

Caution: Make sure to enter a whole number.

When you're done making and testing your changes, set the profile option back to 1440, which is 24 hours in minutes. If you forget and leave your profile option as is for longer than eight hours, don't worry! At that point, the profile option resets itself back to 1440 minutes.

Related Topics

Example of Modifying Journal Approval Notifications Using Oracle Business Intelligence (BI) Publisher

This example shows how to modify notifications for the journal approval workflow using BI Publisher reports.

The following table summarizes the key decisions for this scenario.

Decisions to Consider	In This Example
What text changes are needed in the notification header?	Append the fiscal year.
What additional field should the notification header include?	The name of the user who created the journal batch.
What changes are needed in the details section of the notification?	Replace the values of the cost center and account segments with the descriptions for those segments. The chart of accounts has the following segments: Company, Cost Center, Account, Product.

Modify the journal approval notification by:

Downloading the report layout template.
Copying and modifying the data model. This step is only needed if the attributes to be added to the notification aren't already present in the data model.
Exporting the data model. You must perform this step even if you didn't make changes to the data model. This step is needed for previewing.
Editing the report layout template.
Previewing the modified notification.
Uploading the modified report layout template.

For more information about configuring BI Publisher notifications, see the Reports chapter in the Creating Analytics and Reports for Financials Cloud guide.

Prerequisites

To edit the report layout template, download and install Template Builder for Word, which is an extension to Microsoft Word.
1. Sign in to the application with the application consultant job role.
2. In the Reports and Analytics work area, click the Browse Catalog button.
3. Click the Home link.
4. In the Get Started section, click the Download BI Desktop Tools link.
5. Select Template Builder for Word from the list.
6. Save the file and run the installer.
To preview the notification output for your modified report layout template, you must first download a copy of the Workflow Notification Subtemplate.
1. Click the Catalog link on the Oracle Business Intelligence home page and expand the Shared Folders > Common Content > Templates folder.
2. Click the Edit link for the Workflow Notification Subtemplate. The subtemplate page opens.
3. In the Templates section, click the language name link in the Locale column.
4. Save the subtemplate .rtf file to your computer.
The predefined data model displays the account combination, which is based on segment values, on the journal approval notification. To display a combination of segment values and descriptions on the notification, identify the segment codes for all of the chart of account segments. The segment codes are used in the task Copying and Modifying the Data Model.
1. In the Setup and Maintenance work area, go to the following:
  - Offering: Financials
  - Functional Area: Financial Reporting Structures
  - Task: Manage Chart of Accounts Structure
2. Search for the Accounting Flexfield and click Manage Structures to open the Manage Key Flexfield Structures page.
3. Search for your chart of accounts and click Edit in the Search Results section.
4. Find the segment code values for all of the segments in the Segment Code column. In this example, the segment codes are VF_Company, VF_Cost_Center, VF_Account, and VF_Product.
Find an existing journal approval notification and note the values for the following attributes: accounting period, journal batch name, and ledger name. This information is used to produce sample report data for the task Exporting the Data Model.

Note: The exact steps can vary depending on your version of Microsoft Word.

Downloading the Report Layout Template

The report layout template contains the structure of the notification. To download a copy of the journal approval report layout template to your local drive for modification:

Sign in to the BI server (for example, http://hostname.com:7001/xmlpserver) with the application consultant job role to open the Oracle Business Intelligence home page.
Click the Catalog link to open the Catalog page.
In the Folders pane, expand the Shared Folders > Financials > Workflow Notifications > General Ledger folder.
Click the Journals folder to display the Data Models subfolder and the Journal Approval Report.
Click the More link for the Journal Approval Report, and then select Customize from the menu. The Journal Approval Report folder, containing the predefined report layout template, is automatically copied to the Custom folder and the Journal Approval Report page opens from within that folder.

Note: If the Customize option isn't available from the menu, check that you signed in to the BI server as mentioned in step 1.
Click the Edit link on the copy of the Journal Approval Notification report layout template.
Save the copy of the .rtf file to your local drive and change the file name to distinguish it from the predefined report layout template. For example, save the file as UpdatedJournalApprovalNotificationReport.rtf.

Caution: Be sure to change the name of the .rtf file, otherwise you could overwrite the predefined report layout template.

Copying and Modifying the Data Model

Always make a copy of the data model to preserve the predefined data model from errors and to have a data model to which you can revert. Modify the copy to add or remove attributes from the data model. In this example, you modify the data model to include either a segment value or a segment description for each segment in the chart of accounts.

To copy the data model:
1. Click the Catalog link on the Oracle Business Intelligence home page to open the Catalog page.
2. In the Folders pane, expand the Shared Folders > Financials > Workflow Notifications > General Ledger folder.
3. Click the Journals folder to display the Data Models subfolder and the Journal Approval Report.
4. In the Folders pane, click the Data Models subfolder to select it.
5. In the toolbar, click the Copy Resource button.
6. In the Folders pane, expand the Shared Folders > Custom > Financials > Workflow Notifications > General Ledger folder.
7. Click the Journals folder to select it.
8. In the toolbar click the Paste Resource button to create a copy of the Data Models folder.
  
  Note: The Journal Approval Report is automatically redirected to use the copy of the data model in the Custom folder.

Use a text editor to construct the SQL statement for each segment in the chart of accounts to display either a value or a description.

Use this statement as a template for displaying a segment value: FUN_BIP_UTIL_PKG.get_seg_value_from_code(lines.CODE_COMBINATION_ID,'Segment_code') as Segment_Val.

Use this statement as a template for displaying a segment description: FUN_BIP_UTIL_PKG.get_seg_description_from_code(lines.CODE_COMBINATION_ID,'Segment_Code') as Segment_Desc
Replace the Segment_code value in each statement with the segment codes from your chart of accounts.
Replace the Segment_Val or Segment_Desc values at the end of each statement with a user-defined term for that segment.

Note: The user-defined terms are added to the report layout template as part of the task Editing the Report Layout Template.

The following table shows the segment names, segment codes, and prepared SQL statements for each segment in the chart of accounts. Each SQL statement includes the segment code and ends with the user-defined term representing the segment and indicating whether it's a value or a description. For example, the SQL statement for the cost center ends with CostC_Desc. Each statement ends with a comma.

Segment Name	Segment Code	SQL Statement
Company	VF_Company	`FUN_BIP_UTIL_PKG.get_seg_value_from_code(lines.CODE_COMBINATION_ID,'VF_Company') as Company_Value,`
Cost Center	VF_Cost_Center	`FUN_BIP_UTIL_PKG.get_seg_description_from_code(lines.CODE_COMBINATION_ID,'VF_Cost_Center') as CostC_Desc,`
Account	VF_Account	`FUN_BIP_UTIL_PKG.get_seg_description_from_code(lines.CODE_COMBINATION_ID,'VF_Account') as Account_Desc,`
Product	VF_Product	`FUN_BIP_UTIL_PKG.get_seg_value_from_code(lines.CODE_COMBINATION_ID,'VF_Product') as Product_Value,`

To edit the copy of the data model:
1. Find your copy of the data model by expanding the Shared Folders > Custom > Financials > Workflow Notifications > General Ledger > Journals > Data Models folder.
2. Click the Edit button for the Journal Approval Data Model copy. The Journal Approval Data Model page opens.
3. In the Data Model pane, in the Data Sets folder, click the Journal Lines data set.
4. On the Diagram tab, click the Edit Selected Data Set button. The Edit Data Set - Journal Lines dialog box opens with the SQL query for the Journal Lines data set.
  
  The following figure shows the Edit Data Set - Journal Lines dialog box with the predefined SQL query.
5. In the SQL Query field, place your cursor after SELECT and insert rows for the new SQL statements.
6. Copy the SQL statements that you prepared in step 2 into the SQL query field after the word SELECT and before the lines.JE_HEADER_ID HDR_ID.
  
  The following figure shows the Edit Data Set - Journal Lines dialog box with the new SQL statements.
7. Click OK to close the Edit Data Set - Journal Lines dialog box.
8. Click the Save button to save the modified copy of the data model.

Exporting the Data Model

To add fields from the data model to your copy of the report layout template, you must first export the modified data model .xml file.

Click the Catalog link on the Oracle Business Intelligence page to open the Catalog page.
In the Folders pane, expand the Shared Folders > Custom > Financials > Workflow Notifications > General Ledger > Journals folder.
Click the Data Models folder to display the modified Journal Approval Data Model.
Click the Edit link for the data model. The data model page opens on the Diagram tab.
Click the Data tab.
To export the full data model .xml file, click in each of these fields and enter values from an existing journal approval notification: Accounting Period, Journal Batch Name and Ledger Name.
To include empty fields in the data model export, click the Properties link in the Data Model pane.
On the Properties page, select the Include Empty Tags for Null Elements option.
Click Save.
In the Data Model pane, click the Data Sets link to return to the Data tab.
Click the View button to view the sample data.
Click the Export button and save the Journal Approval Data Model .xml file to a local drive.
Repeat step 7 to return to the Properties page and deselect the Include Empty Tags for Null Elements option.

Note: If you leave this option selected, performance issues could result.
Click Save.

Editing the Report Layout Template

Edit the copy of the report layout that you downloaded earlier in the task Downloading the Report Layout Template.

To append the fiscal year to the notification header:
1. Open your local copy of the report layout template using Microsoft Word.
2. Place your cursor at the end of the default header text, which is Journal Batch Approval.
3. Add a space and enter the text Fiscal Year 2017 - 2018. The header now says Journal Batch Approval Fiscal Year 2017 - 2018.
  
  The following figure shows the modified notification header.
To add the name of the user who created the journal batch to the notification:
1. Select the BI Publisher tab to open the BI Publisher ribbon.
2. In the Load Data group on the ribbon, click Sample XML.
3. On the XML data selection dialog box, select the .xml file that you saved in step 11 of the task Exporting the Data Model. Click Open.
4. Click OK on the message that appears indicating that the data was successfully loaded.
5. In the header section of the report layout template, place your cursor at the end of the BATCH_SOURCE field, and insert a new line.
6. Enter the text label for the new field, such as Batch Created By, and then add a space.
7. In the Insert group on the BI Publisher ribbon, click the Field button. The Field dialog box opens with a list of the data model fields.
8. In the JOURNAL_BATCH folder, select the BATCH_CREATOR field and click Insert. The field is automatically added to the header section after the new text label.
9. On the Field dialog box, click Close.
  
  The following figure shows the modified notification header.
To replace the account combination ID fields on the report layout template with the segment values and descriptions that were added to the data model:
1. Place your cursor after the label called StrtLineLINE_ACCOUNTEC and insert a new line.
2. In the Insert group on the BI Publisher ribbon, click the Field button. The Field dialog box opens with a list of the data model fields.
3. In the Journal Lines folder, select the COMPANY_VALUE field. The name for this field is the user-defined name for the company segment from the task Copying and Modifying Data Model.
4. Click Insert to add the field to the report layout template.
5. In the report layout template, add a character such as a hyphen, to separate the segments.
6. Select the rest of the segments from the Field dialog box and insert them into the report layout template with a separator between each segment.
  
  The following figure shows the modified notification with the account segments.
7. Format the segments that were added by copying the format from the CLINE_ACCOUNTEC field in the report layout template. Click the CLINE_ACCOUNTEC field.
8. Click the Home ribbon, select the Format Painter button, and select the segments that were added. For example, select COMPANY_VALUE-COSTC_DESC-ACCOUNT_DESC-PRODUCT_VALUE.
9. Place your cursor after the CLINE_ACCOUNTEC field and insert a new line.
10. Copy the account line that you created in the previous steps of this section and paste it into the new line.
  
  The following figure shows the modified notification with the account segments appearing after both the
  StrtLineLINE_ACCOUNTEC and the CLINE_ACCOUNTEC fields.
Delete the fields StrtLineLINE_ACCOUNTEC and CLINE_ACCOUNTEC from the report layout template.
Click Close on the Field dialog box.

Save your local copy of the report layout template.

Previewing the Modified Notification

Before uploading your modified report layout template to the BI catalog, you should preview the output with the changes that you made. You can avoid uploading a broken report that displays an error to users.

Replace the path at the beginning of the modified .rtf template with the location of the subtemplate that you downloaded as a prerequisite. For example, change <?import:xdoxsl:///Common Content/Templates/Workflow Notification Subtemplate.xsb?> to <?import:file:///C:/Template_Directory/FinFunWorkflowNotificationSub.rtf?>.

Note: Save the original path information so you can copy it back after previewing.
In the Preview group on the BI Publisher ribbon, click HTML.

The following figure shows an example of how the account combination appears in the preview. The value for the company segment is 31111. The segment description for cost center is R&D US. The description for the account segment is White Wine Revenue, and the value for the product segment is 0000.
If the preview reflects your changes as expected, then change the subtemplate path in the .rtf file back to the original location.
In the Tools group on the BI Publisher ribbon, click Validate Template.
Save the modified report layout template.

Uploading the Modified Report Layout Template

To use the modified report layout template for future journal approval notifications:

Click the Catalog link on the Oracle Business Intelligence home page to open the Catalog page.
In the Folders pane, expand the Shared Folders > Custom > Financials > Workflow Notifications > General Ledger folder.
Select the Journals folder to display the Data Models folder and the Journal Approval Report.
Click the Edit link for the Journal Approval Report to open the Journal Approval Report page.
Click the View a list link to open the Layout page.

Tip: The Layout page displays the copy of the predefined report layout template that was automatically created in step 5 of the task Downloading the Report Layout Template. If you're not satisfied with your changes, you can revert back to this copy by making it the default layout. (Refer to step 11.) Alternatively, you can revert back to the predefined report layout template by deleting the Journal Approval Report folder from the directory Shared Folders > Custom > Financials Workflow Notifications > General Ledger.
Click the Create button. A page opens with a Create Layout section and an Upload or Generate Layout section.
In the Upload or Generate Layout section, click the Upload button. The Upload Template File dialog box opens.

Complete the fields, as shown in this table.

Field	Value
Layout Name	Enter a name for the modified report layout template. For example, enter Modified Journal Approval Template.
Template File	Click Browse. Locate and select the modified report layout template that's on your local drive. Click Open to return to the Upload Template File dialog box.
Type	RTF Template
Locale	English

Click Upload. The Journal Approval Report page returns to the thumbnail view and displays the report layout template that you just uploaded, along with the original copy.

Note: Configurable workflow notifications are refreshed every 24 hours so that they perform better for your users. But when you're making changes to reports, subtemplates, or data models, you can apply your changes immediately so they're available for testing. For more information, see the Apply Changes to Workflow Notifications Immediately After Upload topic.
Click the View a list link to return to the Layout page with the list of the report layout templates.
In the row for the report layout template that you just uploaded, click the Default Layout option. This step enables the modified report layout template for future journal approval notifications.
Click the Save button to save the change to the default layout.

Related Topics

AutoPost

Create an AutoPost Criteria Set

In this example, you're creating an AutoPost criteria set to post the general ledger journal entries created by journal import for your subledger transactions.

Here's the relevant setup for your Vision Corporation ledger.

You implemented Oracle Fusion General Ledger and the subledgers Oracle Fusion Payables and Oracle Fusion Receivables.
You use a non-Oracle subledger called Fast Assets for fixed asset tracking and depreciation.
You plan to automate posting of general ledger journal batches created by journal import. The automation is to protect the subledger-sourced journal entries from edits or deletion that could cause an out-of-balance situation between the subledgers and general ledger.

Consider these points when creating a criteria set:

Use the All option for category and accounting period to reduce maintenance and ensure that all journal imports are included in the posting process.
Create a criteria set that includes all your subledger sources. Create multiple criteria sets by source only if you must schedule different posting times to balance close activities or reduce processing time.

Create the Set

Go to the following:
- Offering: Financials
- Functional Area: General Ledger
- Task: Manage AutoPost Criteria Sets
Click Create.
Enter this name: All Journal Imported Entries.
Enter this description: Posting journals imported from the subledgers.
Select Enabled.
Select the Use Batch Creator as Approval Submitter check box if you require keeping the creator of the journal batch as the user who submitted the batch for approval when the AutoPost Journals process runs. If you don't select this check box, the user running the AutoPost journals process is the submitter for approval.

Enter these values and click Add Row to add each new line.

Priority	Ledger or Ledger Set	Source	Category	Accounting Period	Balance Type
1	Vision Corporation	Payables	All	All	All
2	Vision Corporation	Receivables	All	All	All
3	Vision Corporation	Fast Assets	All	All	All

Select Yes for the Process All Criteria check box, and enter 30 as the number of days before and after the submission date. The process runs less often when you specify a wide range.
Click Save and Close.

Tip: Schedule the process to run immediately after the Import Journals process to prevent changes to the journals. Run the process during nonpeak times to save resources.

Related Topics

Submit Scheduled Processes and Process Sets

Examples of Manually Running the AutoPost Process

Create an AutoPost criteria set and schedule the AutoPost Journals process to run on a regular basis following your scheduled journal imports from your subledgers. When errors occur that prevent posting of the journal imports, you must correct the errors and manually run the AutoPost process. The following scenarios illustrate the kinds of errors that could occur and how you can resolve these errors.

Scenario

The following table lists the errors that prevented journal batches from posting when the scheduled AutoPost Journals process ran.

Error	Cause	Solution
Unopened accounting period	The journal import was imported into a future period. An error arises when the AutoPost Journals process runs on a schedule because journals can't be posted in a future period.	Open the period.
Invalid or no journals	Journal import fails to import transactions from the general ledger interface table. The AutoPost Journals process runs on schedule but finds no batches to post. The posting process doesn't run and the AutoPost Execution report shows that no batches matched the criteria.	Correct the error that caused the journal import to fail.
Invalid or no journals	No journals were selected based on the posting criteria. Journal batches are available for posting. The posting process doesn't run and the AutoPost Execution report shows that no batches matched the criteria.	Revise the criteria set.

After you correct the errors:

Manually run the AutoPost Journals process by selecting the Run AutoPost option from the Tasks panel on the journal pages.
Click Generate on the AutoPost criteria set pages.
Verify that the process ran successfully by reviewing the AutoPost Execution report.

FAQs for AutoPost

How can I run the AutoPost process?

After you define an automatic posting criteria set, run the AutoPost process by clicking the Generate button on the Manage AutoPost Criteria Sets page or the Launch AutoPost link from the Journals task pane. The AutoPost process posts the journal batches that meet the criteria defined. Optionally, schedule the AutoPost process for specific automatic posting criteria sets through the Schedule tab in the Schedule Process: Advanced region to run at specific times and submission intervals.

How can I identify errors that occurred during the AutoPost process?

Review the AutoPost process results on the AutoPost Execution report. This report is automatically created when the process completes successfully. The report contains the batch name, accounting period, and balance type for each posted journal batch, and lists error statuses for batches that fail to post. The unposted journals with their error status are also displayed on the Requiring Attention tab of the Journals work area and the General Accounting Dashboard.

Note: The Requiring Attention tab also shows journals with rejected approvals.

Why didn't the AutoPost process post journal batches as expected?

Verify that the posting criteria set specifies the precise criteria required to post the wanted journals. If the criteria is correct, then verify the following:

Journal imports completed successfully.
Journal batches are error free and ready to post.
Specified accounting period is open.

Manage Journal Reversals

Journal Reversals

You can reverse journals manually by selecting a reversal action in the user interface, or you can reverse journals automatically by running a process. Decide which approach is best for journals such as accruals, estimates, errors, temporary adjustments, or reclassifications that require reversal. Reversing journals saves you time and helps prevent data entry errors.

Here are the key areas to understand when reversing journals:

Reversal Settings on Journals
Manual Journal Reversal
Journal Reversal Criteria Sets
Automatic Journal Reversal
Reversal Synchronization Between a Primary Ledger and Its Secondary Ledgers

Reversal Settings on Journals

You can enter and view a journal's reversal settings in the Reversal tab on the Create and Edit Journal pages:

Reversal Period: Accounting period for the resulting reversal journal. Required for reversal.
Reversal Date: Applicable only to average daily balance ledgers. Accounting date to be applied to the reversed journal, since that's needed for calculating average balances. For ledgers that aren't average daily balance ledgers, default logic is applied to determine the accounting date for the generated reversal.
Reversal Method: Method for reversing amounts in the reversal journal. Select from Change Sign or Switch Debit or Credit. The default setting is Switch Debit or Credit. The Change Sign setting means the reversal puts the original journal amount in the same Debit or Credit column, but with the opposite (negative or positive) sign. The Switch Debit or Credit setting means the amount is moved to the other column. Required for reversal.
Reversal Status: View-only state of the journal reversal. For example, Not reversed or Reversed.

You can enter a reversal period and method at any time, even after the journal is posted. If applicable, the following values also display in the Reversal tab:

Reversal Journal: If you're reviewing a journal that was reversed, this setting displays the name and link to the reversal journal.
Originating Journal: If you're reviewing a reversal journal, this setting displays the name and link for the journal that was reversed.

Manual Journal Reversal

You can manually reverse posted journals that are eligible for reversal on both the Manage Journals and Edit Journal pages. Both pages provide an action to reverse a journal and an action to reverse a batch.

On the Edit Journal page, you can select Reverse from the Batch Actions menu to reverse a journal batch, or you can select Reverse from the Journal Actions menu to reverse a specific journal. On the Manage Journals page, you can select rows in the Search Results section and then select the Reverse Batch or Reverse Journal buttons. To select multiple rows at once, use the Shift or Control key. You can reverse multiple journals of the same batch, or of different batches, or reverse entire journal batches that are eligible for reversal, based on the rows you selected.

Each reversal journal is created in its own reversal batch and the batch name starts with the word Reverses. When you reverse a batch, a single reversal request is submitted. However, the reversal journal for each journal in the reversed batch is still generated in its own journal batch. Reversal journals for journal-level reporting currencies are grouped into the same reversal batch as the corresponding reversal journal of their associated primary or secondary ledger. Reversal journals for subledger-level reporting currencies are grouped into the same reversal batch as their corresponding primary ledger.

Here are some examples of when you might want to use batch reversal.

Scenario	How It Works
You want to reverse all of the journals in a batch that aren't yet reversed, using the same reversal settings. For example, using the same reversal period for ledgers that aren't enabled for average balances, or the same reversal period and date for ledgers that are enabled for average balances. Or, you want to use the same reversal method.	When you select the reverse batch action, the Reverse Journal Batch window opens. You provide the reversal period, date, or method. The information you enter overrides any reversal settings at the journal level of journals that aren't yet reversed. All journals eligible for reversal are reversed according to what you specified on the Reverse Journal Batch window.
You specified reversal settings for every journal that's not yet reversed in a batch, and you want to process reversals more efficiently using batch reversal.	Leave the fields blank on the Reverse Journal Batch window. Each of these journals is reversed according to the journal's reversal settings.
You specified reversal settings for some, but not all, of the journals that aren't yet reversed in a batch, and you want to process reversals more efficiently using batch reversal.	Use the Manage Journals page to reverse the batch. Leave the fields blank on the Reverse Journal Batch window. Each of these journals is reversed according to the journal's reversal settings.
You want to reverse multiple journals from different batches using the reversal settings specified on each journal in these batches.	Use the Manage Journals page to select the rows for the batches and then select the reverse batch action. Each journal that's eligible for reversal in these batches is reversed according to the journal's reversal settings.

Journal Reversal Criteria Sets

To provide default reversal settings to a newly-created journal based on the journal's category, or to also proceed with automatically reversing a posted journal, create a journal reversal criteria set and assign it to a ledger. A journal reversal criteria set contains all journal categories with their corresponding reversal settings and can be shared with any number of ledgers.

Here's how to navigate to the journal reversal criteria set page from the Setup and Maintenance work area:

Offering: Financials
Functional Area: General Ledger
Task: Manage Journal Reversal Criteria Sets

The Create Journal Reversal Criteria Set page lists all of the journal categories with default reversal settings. Find the journal categories that you want to specify reversal criteria for and set the values accordingly. This table describes each reversal setting.

Setting	Values	Description
Reversal Period	No Default, Same Period, Next Period, Next Nonadjusting Period, Next Day, Same Day	Accounting period for the resulting reversal journal. The following values apply only to average balance ledgers: Next Day, Same Day. Selecting those values for a ledger that isn't an average balance ledger is the same as selecting the value No Default.
Reversal Date	First Day, Next Day, Last Day	Day of the accounting period when the journal is to be reversed. A reversal date only applies to average balance ledgers. You must specify a reversal date if you select the following values for the reversal period: Next Nonadjusting Period, Next Period, Same Period.
Reversal Method	Change Sign, Switch Debit or Credit	Method for reversing amounts in the reversal journal.
Automatic Reversal Option	None, Reverse Automatically, Reverse and Post Automatically	Setting that determines whether a journal is selected for automatic reversal, and whether the reversal journal is posted after it's reversed. Unlike the previous settings in this table, which are propagated directly as attributes in the journal, this setting is used to determine the reversal action that's applied when the automatic reversal process is run.

After you create the journal reversal criteria set, assign it to one or more of your ledgers. Here's how to navigate to the ledger page in the Setup and Maintenance work area where you can assign the journal reversal criteria set:

Offering: Financials
Functional Area: General Ledger
Task: Specify Ledger Options, with the ledger scope set

When you create a journal for a ledger with an assigned criteria set, the journal's reversal period and method are populated according to the criteria setting for that journal's category. This applies to journals entered through the user interface and the Create Journal spreadsheet. You can accept the defaulted reversal values or change them at any time, even after the journal is posted.

Automatic Journal Reversal

The automatic reversal process only selects reversible journals whose categories are enabled for automatic reversal in the journal reversal criteria set that's assigned to the ledger. The automatic reversal option for those categories must be set to either Reverse Automatically or Reverse and Post Automatically.

Here's how you can run the automatic reversal process:

Select the Run AutoReverse task from the tasks pane in the Journals work area. The task opens the Scheduled Process page for the AutoReverse Journals process. You might want to run automatic reversals this way for one-time accruals entered in the current period, but tagged to reverse in a later period.
Submit or schedule the AutoReverse Journals process on the Scheduled Processes page.
Enable the ledger option Run AutoReverse After Open Period on the Specify Ledger Options page. When enabled, the automatic reversal process is submitted with the reversal period choice of All.

Note: If you usually reverse journals on the last day of every month, don't enable this option. Instead, schedule the automatic reversal process to run on the last day of the month. The accounting period parameter automatically increments for each subsequent run.

The automatic journal reversal process creates one journal batch for each journal that's reversed. The names for the reversal batch and reversal journal begin with the word Reverses. The process also produces the AutoReverse Execution report, which prints the name of the journal batch that was submitted for reversal, along with the journal batch accounting period. If the automatic reversal option is set to Reverse and Post Automatically, then the report also provides information about the reversal batch.

Note: The AutoPost Journals process that's automatically submitted by the reversal process posts only the reversal journals that it generated, not other journals that are pending posting.

If reversal synchronization is enabled (refer to the next section for details), the process generates a journal reversal in the corresponding secondary ledger and the AutoReverse Execution report includes information about the journal reversal batch that's generated in the secondary ledger.

After the process completes, you can review the reports for any problems and verify that all journals were processed properly.

Here are some points to consider if you decide to run the automatic reversal process:

If the automatic reversal option on the applicable journal reversal criteria set is set to:
- Reverse and Post Automatically and journal approval is enabled, journals posted by the process bypass approval.
- Reverse Automatically, you must manually post the reversal journals.
If you have an average balance ledger, the automatic reversal process doesn't check that the reversal date is a valid business day. However, the journal validation in the journal pages and the import process perform this check and, if necessary, roll the date to the next business day.

Reversal Synchronization Between a Primary Ledger and Its Secondary Ledgers

If you have secondary ledgers, it's recommended that you enable the primary ledger option Synchronize Reversals Between Primary and Secondary Ledgers. Reversal synchronization helps to ensure that the secondary ledger remains as an accurate alternate representation of its corresponding primary ledger. If you enable this option, a journal reversal (manual or automatic) in the primary ledger triggers the reversal of the corresponding journal in the associated secondary ledger. If you didn't enable this option, you would have to actively manage the reversal of journals in the secondary ledger, whether they were replicated from its primary ledger or created directly in the secondary ledger. To set this option for a primary ledger, use the same navigation as you did for assigning the journal reversal criteria set to the ledger.

Note: Reversal synchronization is relevant only for secondary ledgers with a data conversion level of Journal or Subledger because primary ledger journal replication is applicable only to secondary ledgers at those conversion levels. Reversals for reporting currencies at a Journal level of conversion for a primary or secondary ledger, and also at a Subledger level for a primary ledger, are automatically synchronized with their source ledger, regardless of the synchronization option setting.

Here's how reversal synchronization works with journal approval when you have this setup:

You enabled journal approval in both the primary and secondary ledger.
You enabled reversal synchronization between the two ledgers.

The reversal journal generated in the secondary ledger (for the primary ledger reversal) won't require a separate approval.

This table shows how journals are reversed in a secondary ledger when synchronization is enabled. Journal reversal depends on how the journals were created in the secondary ledger and on whether a reversal criteria set is assigned to the secondary ledger.

How was the journal that's going to be reversed created in the secondary ledger?	Did you assign a journal reversal criteria set to the secondary ledger?	How is the journal reversed in the secondary ledger?
The journal was replicated from the primary ledger.	Yes	The journal is reversed automatically when the journal in the primary ledger is reversed. The reversal settings in the primary ledger source journal override any reversal settings on the journal in the secondary ledger that's being reversed. Note: Because the journal was replicated from the primary ledger, the journal reversal criteria set has no impact on the reversal.
The journal was created directly in the secondary ledger.	Yes	If the journal category is set for automatic reversal in the secondary ledger's assigned criteria set, you can run the automatic reversal process in the secondary ledger. Otherwise, you must reverse the journal manually.
The journal was replicated from the primary ledger.	No	The journal is reversed automatically when the journal in the primary ledger is reversed.
The journal was created directly in the secondary ledger.	No	You must specify reversal information in the journal and manually reverse the journal in the secondary ledger.

Once set, the primary ledger option Synchronize Reversals Between Primary and Secondary Ledgers applies to any secondary ledger of the primary ledger. The option Post Journals Automatically from Source Ledger is set by the individual secondary ledgers of the primary ledger and controls automatic posting of secondary ledger journals (reversals and otherwise), when the corresponding primary ledger journal is posted. To set this option, use this navigation in the Setup and Maintenance work area:

Offering: Financials
Functional Area: General Ledger
Task: Complete Primary to Secondary Ledger Mapping, with the primary ledger and secondary ledger scope set

FAQs for Manage Journal Reversals

When does a journal become reversible?

You can reverse journals manually by selecting a reversal action in the user interface, or you can reverse journals automatically by running a process.

This table describes the criteria that must be met before you can reverse a journal, and indicates whether that criteria applies to manual or automatic journal reversal.

Criteria	Eligible for Manual Reversal?	Eligible for Automatic Reversal?
The journal has a balance type of Actual.	Yes	Yes
The journal has a balance type of Encumbrance.	Yes	No
The journal is posted and not yet reversed.	Yes	Yes
The reversal period is open or future enterable.	Yes	Yes
The journal isn't a reversal journal. Note: Reversal journals can't be reversed.	Yes	Yes
The journal category is enabled for automatic reversal.	N/A	Yes
The journal source for the posted journal isn't frozen.	Yes	Yes, however, this only applies to posted journals that originate from Oracle Fusion Subledger Accounting whose journal source isn't frozen. Posted journals that originate from a source other than Oracle Fusion Subledger Accounting are eligible for automatic reversal, regardless of the Freeze Journals setting.
The journal isn't a posted journal for a reporting currency that was replicated from its source ledger. Note: Reporting currency journals that were replicated from a source ledger are reversed when the source journal is reversed.	Yes	Yes
Where a secondary ledger is involved, the corresponding journals for the primary and secondary journals are both posted.	Yes	Yes
If using the Clearing Accounts Reconciliation feature, the posted journal doesn't include reconciliation lines for clearing accounts.	Yes	Yes

Tip: Use the Reversible Detail column in the Search Results section on the Manage Journal page for details on whether a journal is reversible.

Lookups

Overview of Lookups

Lookups are lists of values in applications. You define a list of values as a lookup type consisting of a set of lookup codes, each code's translated meaning, and optionally a tag. End users see the list of translated meanings as the available values for an object.

Lookups provide a means of validation and lists of values where valid values appear on a list with no duplicate values. For example, an application might store the values Y and N in a column in a table, but when displaying those values in the user interface, Yes or No (or their translated equivalents) should be available for end users to select. For example, the two lookup codes Y and N are defined in the REQUIRED_INDICATOR lookup type.

The following table contains an example of a lookup type for marital status (MAR_STATUS) that has lookup codes for users to specify married, single, or available legal partnerships.

Lookup Code	Meaning	Tag
M	Married	Not applicable
S	Single	Not applicable
R	Registered Partner	+NL
DP	Domestic Partner	-FR, AU

In this case, tags are used for localizing the codes. All legislations list Married and Single. Only the Dutch legislation lists Registered Partner. And all legislations except France and Australia also list Domestic Partner.

When managing lookups, you need to understand the following.

Using lookups in applications
Configuration levels
Accessing lookups
Enabling lookups
The three kinds of lookups: standard, common, and set-enabled

Using Lookups in Applications

Use lookups to provide validation or a list of values for a user input field in a user interface.

An example of a lookup used for validation is a flexfield segment using a table-validated value set with values from a lookup type. An example of a lookup in a list of values is a profile option's available values from which users select one to set the profile option. Invoice Approval Status gives the option of including payables invoices of different approval statuses in a report. The lookup code values include All, so that users can report by all statuses: Approved, Resubmitted for approval, Pending or rejected, and Rejected.

Configuration Level

The configuration level of a lookup type determines whether the lookups in that lookup type can be edited. This applies data security to lookups.

Some lookup types are locked so no new codes and other changes can be added during implementation or later, as needed. Depending on the configuration level of a lookup type, you may be able to change the codes or their meanings. Some lookups are designated as extensible, so new lookup codes can be created during implementation, but the predefined lookup codes can't be modified. Some predefined lookup codes can be changed during implementation or later, as needed.

The configuration levels are user, extensible, and system. The following table shows the lookup management tasks permitted at each configuration level.

Permitted Task	User	Extensible	System
Deleting a lookup type	Yes	No	No
Inserting new codes	Yes	Yes	No
Updating start date, end date, and enabling the lookup code	Yes	Yes, only if the code isn't predefined data	No
Deleting codes	Yes	Yes, only if the code isn't predefined data	No
Updating tags	Yes	No	No
Updating module	Yes	No	No

Predefined data means LAST_UPDATED_BY = SEED_DATA_FROM_APPLICATION.

If a product depends on a lookup, the configuration level must be system or extensible to prevent deletion.

Once the configuration level is set for a lookup type, it can't be modified. The configuration level for newly created lookup types is by default set at the User level.

Access to the REST Resources

Users can retrieve information about lookups using the following REST resources:

standardLookupsLOV
commonLookupsLOV
setEnabledLookupsLOV
genericLookupsLOV

However, you can control whether a lookup is a part of the LOV or not. On the UI, for each lookup you can specify the REST Access Secured value that in turn determines whether it's included in the response or not. These values are:

Anonymous: Lookup is available to a user having anonymous role or authenticated role.
Authenticated: Lookup is available to a user having only the authenticated role.
Secure: Lookup isn't available to users as part of the generic resource. To make it available securely, you must create a specific resource, assign it to a role, and assign that role to select users.

For all lookups, the default value is set to Secure. So, if you want to make the lookup available to users through any of those resources, you must change the value to Authenticated or Anonymous, depending on who needs to access that information.

Standard, Common, and Set-Enabled Lookups

The following table shows the available types of lookups.

Lookup Type	Description
Standard	Lists the available codes and translated meanings.
Set-enabled	Associates a reference data set with the lookup codes.
Common	Legacy lookups or lookups that have attributes.

Standard lookups are the simplest form of lookup types consisting only of codes and their translated meaning. They differ from common lookups only in being defined in the standard lookup view. Common lookups exist for reasons of backward compatibility and differ from standard lookups only in being defined in the common lookup view. These can also be lookups having attribute columns. Set-enabled lookup types store lookup codes that are enabled for reference data sharing. At runtime, a set-enabled lookup code is visible because the value of the determinant identifies a reference data set in which the lookup code is present.

Accessing Lookups

Standard, set-enabled, and common lookups are defined in the Standard, Set-enabled, and Common views, respectively. Applications development may define lookups in an application view to restrict the UI pages where they may appear.

In lookups management tasks, lookups may be associated with a module in the application taxonomy to provide criteria for narrowing a search or limiting the number of lookups accessed by a product specific task such as Manage Purchasing Lookups.

Enabling Lookups

A lookup type is reusable for attributes stored in multiple tables.

Enable lookups based on the following.

Selecting an Enabled check box
Specifying an enabled start date, end date, or both
Specifying a reference data set determinant

If you make changes to a lookup, users must sign out and back in before the changes take effect. When defining a list of values for display rather than validation, limit the number of enabled lookup codes to a usable length.

To view the predefined lookups and their lookup codes, use the following tasks in the Setup and Maintenance work area:

Manage Standard Lookups
Manage Common Lookups
Manage Set-Enabled Lookups

Translating Lookups

You can translate the lookups that you defined to the preferred language(s) without changing the language session of the application. Use the translation option available on the lookup code table. By default, for each lookup, all the permitted language rows in the translator dialog box appear in the source language (the current session language). When you edit a particular language entry, you can modify the translated meaning and description to the language in which you want the lookup to appear. Once the updates are made, the end-users can view the lookup in the translated text.

Note: You can add the translation for only as many languages as are permitted by the administrator. The functionality to limit the number of languages displayed on the dialog box is controlled through the Translation Editor Languages profile option. It can be set at the SITE or USER level. If nothing is specified, all active languages are displayed.

Related Topics

Enter or Edit Translated Text

Example of a Standard Lookup

Creating a new standard lookup involves creating or selecting a lookup type containing the lookup code. The task also involves determining appropriate values for the lookup codes and their meanings. You can only create or edit lookup codes for a particular lookup type if its configuration level supports it.

Creating a Lookup Type Called COLORS

Your enterprise needs a list of values to be used as different statuses on a process. Each status is indicated using a color. Therefore, you create a lookup type called COLORS. The following table lists a mapping between the lookup type parameters and the actual values assigned to those parameters to create the required list of values.

Lookup type parameters	Value
Lookup type name	COLORS
Meaning	Status
Description	Status by color
Module	Oracle Fusion Middleware Extensions for Oracle Application

After you define the lookup type, you need to define the lookup codes and their related details. The following table lists the lookup codes you define for the COLORS lookup type.

Lookup Code	Meaning	Enabled	Display Sequence
BLUE	Urgent	No	4
RED	Stop	Yes	1
GREEN	Proceed	Yes	3
YELLOW	Check	Yes	2

The Resulting Data Entry List of Values

Only the enabled lookup codes appear in the list of values for the COLORS lookup type. You must select one of them to complete the activity.

The following table lists the meanings and the codes that were enabled. They appear in the order of the defined display sequence.

Meaning	Lookup Code
Stop	RED
Check	YELLOW
Proceed	GREEN

Analysis

The BLUE lookup code wasn't enabled and doesn't appear in the list of values. The display sequence of values in the list of values is alphabetic, unless you enter a number manually to determine the order of appearance. Number 1 indicates the first value that appears in the list. Only lookups that are enabled and active between start and end dates are visible.

The Transaction Table

When users enter one of the values from the list of values for the lookup type COLORS, the transaction table records the lookup code. The following table contains an example, where the lookup code is stored in the Status column of the transaction table.

Transaction number	User name	Status
1	Jane	RED
2	Bob	YELLOW
3	Alice	BLUE

The status for one user is BLUE because at the time they entered a value, BLUE was enabled. Disabling a lookup code doesn't affect transaction records in which that code is stored. Data querying and reporting have access to disabled lookup codes in transaction tables.

Example of a Set-Enabled Lookup

Creating a new set-enabled lookup is similar to creating a standard lookup with the addition of specifying a reference data set determinant for the lookup codes. You can only create or edit lookup codes for a particular lookup type if its configuration level supports it.

The reference data set for a set-enabled lookup code is part of its foreign key. This is unlike other set-enabled entities. Use the Manage Set Assignments task to define and manage reference data set assignments.

Selecting a Reference Group for a Set-Enabled Lookup Type

Specify a reference group for a set-enabled lookup type to indicate which reference data set assignments are available for its lookup codes. For example a COLORS lookup type might be set-enabled for a Countries reference group that includes the US and EU reference data set assignments.

Selecting a Reference Data Set for a Set-Enabled Lookup

The reference data set determines which lookup code is included in the list of values. For example, there are two references data sets - one for the US and the other for EU. If a COLORS lookup type contains RED, YELLOW, ORANGE, and GREEN lookup codes, you can enable one RED lookup code from the US reference data set and another RED lookup from the EU reference data, each lookup code having different meanings.

The following table elaborates the example, how these two reference data sets (US and EU) contain one lookup code that's common, but each differing in its lookup meaning.

Reference Data Set	Lookup Code	Lookup Meaning
US	RED	Red
US	YELLOW	Yellow
US	GREEN	Green
EU	RED	Rouge
EU	ORANGE	Orange

Some lookup codes may be unique to one or another reference data set as the ORANGE lookup is to the EU reference data set in the example.

In another example in the following table, a lookup type called HOLD_REASON provides a list of reasons for putting a contract renewal on hold. Reference data sets determine which codes are included in the Hold Reason list of values.

Reference Data Set	Lookup Code	Lookup Meaning
US	SEC	SEC Compliance Review
US	DIR	Needs Director's Approval
US	VP	Needs Vice President's Approval
CHINA	CSRC	Pending China Securities Regulatory Commission Review
CHINA	PR	Needs President's Approval
COMMON	REQUESTED	Customer Request

Referring to the example in the table, when end-users place a contract on hold in the US business unit, the three reason codes in the US set are available. When placing a contract on hold in the China business unit, the two codes in the China set are available.

FAQs for Lookups

How can I edit lookups?

On any of the Manage Lookups pages, you can edit the existing lookup codes of a lookup type or add new lookup codes. You can edit lookups using the following tasks in the Setup and Maintenance work area:

Manage Standard Lookups
Manage Common Lookups
Manage Set-enabled Lookups

Each task contains a predefined set of lookup types that are classified and stored. Open a task to search and edit the required lookup. However, you may not be able to edit a lookup if its configuration level doesn't support editing.

Why can't I see my lookup types?

Lookup types are classified using tasks that involve a group of related lookups, such as Manage Geography Lookups. Each task gives you access only to certain lookup types. However, the generic tasks provide access to all lookups types of a kind, such as common lookups associated with the Manage Common Lookups task.

If the lookup types in an application are available in the standard, common, or set-enabled lookups view, they're are central to an application. However, lookup types defined for a specific application are managed using the task for that application.

What's the difference between a lookup type and a value set?

A lookup type consists of lookups that are static values in a list of values. Lookup code validation is a one to one match.

A table-validated value set may consist of values that are validated through a SQL statement, which allows the list of values to be dynamic. The following table brings out the differences between a lookup type and a value set.

Tip: You can define a table-validated value set on any table, including the lookups table. Thus, you can change a lookup type into a table-validated value set that can be used in flexfields.

Area of Difference	Lookup Type	Value Set
List of values	Static	Dynamic if the list is table-validated
Validation of values	One to one match of meaning to code included in a lookup view, or through the determinant of a reference data set	Validation by format or inclusion in a table
Format type of values	char	varchar2, number, and so on
Length of value	Text string up to 30 characters	Any type of variable length from 1 to 4000
Duplication of values	Never. Values are unique.	Duplicate values allowed
Management	Both administrators and end-users manage these, except system lookups or predefined lookups at the system configuration level, which can't be modified.	Usually administrators maintain these, except some product flexfield codes, such as GL for Oracle Fusion General Ledger that the end-users maintain.

Both lookup types and value sets are used to create lists of values from which users select values.

A lookup type can't use a value from a value set. However, value sets can use standard, common, or set-enabled lookups.

What's a lookup tag used for?

A tag is an additional label attached to the lookup. Tags are user defined and can be grouped depending on the user's requirement to make search convenient and effective.

The same tag may be used across lookup categories. In such cases, tags are used as a refined search criterion to filter information across several groups and get the search result.

How can I access predefined lookups?

Search for predefined lookups using any of the manage lookups tasks.

In the Setup and Maintenance work area, go to any of the following tasks that contains the lookups you're looking for:
- Manage Standard Lookups
- Manage Common Lookups
- Manage Set-enabled Lookups
Enter any of the search parameters and click Search. If you don't know the lookup type or the meaning, use the Module field to filter search results.
Click a lookup type to view its lookup codes.

Tip: Click the Query By Example icon to filter the lookup codes.

Related Topics

Use Query By Example

Descriptive Flexfields

Overview of Descriptive Flexfields

Use descriptive flexfields to add attributes to business object entities, and define validation for them.

All the business object entities that you can use in the application are enabled for descriptive flexfields. However, configuring descriptive flexfields is an optional task.

Context

A descriptive flexfield can have only one context segment to provide context sensitivity. The same underlying database column can be used by different segments in different contexts.

For example, you can define a Dimensions context that uses the following attributes:

ATTRIBUTE1 column for height
ATTRIBUTE2 column for width
ATTRIBUTE3 column for depth

You can also define a Measurements context that uses the same columns for other attributes:

ATTRIBUTE1 column for weight
ATTRIBUTE2 column for volume
ATTRIBUTE3 column for density

Segments and Contexts

The following table lists the different types of descriptive flexfield segments.

Segment Type	Run Time Appearance
Global segment	Always available
Context segment	Determines which context-sensitive segments are displayed
Context-sensitive segment	Displayed depending on the value of the context segment

The following figure displays a descriptive flexfield having one context segment called Category for which there are three values: Resistor, Battery, and Capacitor. Additionally, the descriptive flexfield comprises two global segments that appear in each context, and three context-sensitive segments that only appear in the specific context.

The figure contains an example of how context segment
serves as a category for the attributes, whether resistor, battery,
or capacitor. Global segments are always available. However, context-sensitive
segments are available depending on the context.

Application development determines the number of segments available for configuring. During implementation, configure the flexfield by determining the following:

Attributes to add using the available segments
Context values
The combination of attributes in each context

Value Sets

For each global and context-sensitive segment, you configure the values permitted for the segment. Based on it, the values that end users enter are validated, including interdependent validation among the segments.

Protected Descriptive Flexfield Data

Application developers may mark some data configurations in a descriptive flexfield as protected, indicating that you can't edit them.

Related Topics

Considerations for Planning Descriptive Flexfields

Once you have identified a flexfield to configure, plan the configuration in advance. Compile a list of the UI pages and other artifacts in your deployment that are affected by the configuration. Verify that you are provisioned with the roles needed to view and configure the flexfield. View the flexfield using the Highlight Flexfields command in the Administration menu while viewing the run time page where the flexfield appears. Plan how you will deploy the flexfield for test and production users. Review the tools and tasks available for managing flexfields for adding and editing flexfield segments.

Planning a descriptive flexfield can involve the following tasks:

Identify existing parameters.
Identify existing context values and whether the context value is derived.
Identify user-defined attributes and plan the descriptive flexfield segments, segment properties, and structure.
Plan validation rules.
Plan initial values.
Plan attribute mapping to Oracle Business Intelligence objects.

Identify Existing Descriptive Flexfield Parameters

Some descriptive flexfields provide parameters that can be used to specify the initial value of a descriptive flexfield segment. The parameter is external reference data, such as a column value or a session variable. For example, if a flexfield has a user email parameter, you can configure the initial value for a customer email attribute to be derived from that parameter.

Review the list of available parameters in the Derivation Value field in the Create Segment page for a descriptive flexfield. If you decide to use one of the parameters to set an initial value, select that parameter from the Derivation Value drop-down list when you add the descriptive flexfield segment.

Evaluate Whether the Context Value Is Derived

The context value for a descriptive flexfield might have been preconfigured to be derived from an external reference. For example, if the context is Marriage Status, then the value might be derived from an attribute in the employee business object. When the context value is derived, you might need to take the derived values and their source into consideration in your plan.

To determine whether the context value is derived, access the Edit Descriptive Flexfield task to view the list of configured context values for the flexfield. The Derivation Value field in the Context Segment region displays a list of available parameters. If context values have been preconfigured, see Oracle Applications Cloud Help for product-specific information about the use of those values.

Plan the Segments, Segment Properties, and Structure

Identify the user-defined attributes you need for a business object to determine the segments of the descriptive flexfield. Determine the segment properties such as the prompt, display type, or initial value.

The structure of the descriptive flexfield is determined by its global, context, and context-sensitive segments. Plan a global segment that captures an attribute for every instance of the business object. Plan a context for segments that depend on a condition of situation applying to a particular instance of the business object. Plan context-sensitive segments to capture attributes that are relevant in the context.

There is only one context segment available for descriptive flexfields. If you have more than one group of user-defined attributes where you could use the context segment, you will have to pick one group over the others, based on your company's needs and priorities, and add the other user-defined attributes as global segments.

Plan Validation Rules

Define each segment's validation rules and check if value sets exist for those rules or you must create new ones. If you must create a value set, you can create it either before configuring the flexfield or while creating or editing a segment.

When determining a segment's validation rules, consider the following questions:

What is the data type - character, date, date and time, or number?
Does the segment require any validation beyond data type and maximum length?
Should a character type value be restricted to digits, or are alphabetic characters allowed?
Should alphabetic characters automatically be changed to uppercase?
Should numeric values be zero-filled?
How many digits can follow the radix separator of a numeric value? In base ten numeric systems, the radix separator is decimal point.
Does the value need to fall within a range?
Should the value be selected from a list of valid values? If so, consider the following questions:
- Can you use an existing application table from which to obtain the list of valid values, or do you need to create a list?
- If you are using an existing table, do you need to limit the list of values using a WHERE clause?
- Does the list of valid values depend on the value in another flexfield segment?
- Is the list of valid values a subset of another flexfield segment's list of values?

Plan Initial Values

For every segment, list the constant value or SQL statement, if any, to use for the initial value of the user-defined attribute.

Plan How Segments Map to Oracle Business Intelligence Objects

You can extend descriptive flexfields into Oracle Transactional Business Intelligence (OTBI) for ad hoc reporting purposes. Determine the descriptive flexfield segments to be made available for reporting, and select the BI Enabled check box accordingly on the Manage Descriptive Flexfields page. You must run a process to extend the BI enabled segments into OTBI.

Depending on the reporting needs, you may map similar context-sensitive attributes from different contexts to the same attribute in OTBI. For example, there may be a segment tracking the Product Color attribute in different contexts of a context sensitive descriptive flexfield. You can use segment labels to map these context-sensitive attributes together by defining a segment label and updating the BI Label list accordingly.

Related Topics

Considerations for Managing Descriptive Flexfields

Configuring descriptive flexfields involves managing the available flexfields registered with your Oracle Applications Cloud database and configuring their flexfield-level properties, defining and managing descriptive flexfield contexts, and configuring global and context-sensitive segments.

Every descriptive flexfield is registered to include a context segment, which you may choose to use or not.

In general, configuring descriptive flexfields involves:

Creating segment labels for business intelligence enabled flexfields.
Configuring global segments by providing identity information, the initial default value, and the display properties.
Configuring the context segment by specifying the prompt, whether the context segment should be displayed, and whether a value is required.
Configuring contexts by specifying a context code, description, and name for each context value, and adding its context-sensitive segments, each of which is configured to include identifying information, the column assignment, the initial default value, and the display properties.

The following aspects are important in understanding descriptive flexfield management:

Segments
Adding segments to highlighted descriptive flexfields
Usages
Parameters
Delimiters
Initial Values
Business Intelligence

Segments

You can assign sequence order numbers to global segments and to context-sensitive segments in each context. Segment display is always in a fixed order. You can't enter a number for a segment if that number is already in use for a different segment.

Value sets are optional for context segments and follow specific guidelines:

The value set that you specify for a context segment consists of a set of context codes.
Each context code corresponds to a context that's appropriate for the descriptive flexfield.
The value set must be independent or table-validated.
If table-validated, the WHERE clause must not use the VALUESET.value_set_code or SEGMENT.segment_code bind variables.
The value set must be of data type Character with the maximum length of values being stored no larger than the context's column length.
If you don't specify a value set for a context segment, the valid values for that context segment are derived from the context codes. The definition of each context segment specifies the set of context-sensitive segments that can be presented when that context code is selected by the end user.
For reasons of data integrity, you can't delete an existing context. Instead, you can disable the associated context value in its own value set by setting its end date to a date in the past.
You can configure the individual global segments and context-sensitive segments in a descriptive flexfield. These segment types are differentiated by their usage, but they're configured on application pages that use most of the same properties.

Adding Segments to Highlighted Descriptive Flexfields

When you highlight flexfields on a run time page and use an Add Segment icon button to create a segment, the segment code, name, description, table column, and sequence number are set automatically. If you use an Add Segment icon button to configure descriptive flexfield segments, you can't use an existing value set. Value sets are created automatically when you add the segments. You can enter the valid values, their descriptions, and the default value or specify the formatting constraints for the value set, such as minimum and maximum values.

Depending on display type, the value set you create using the Add Segment icon button is either an independent value set or a format-only value set. The following table shows which type of value set is created depending on the segment display component you select.

Display Component	Value Set Created Using Add Segment
Check Box	Independent
Drop-down List	Independent
List of Values	Independent
Radio Button Group	Independent
Text Field With Search	Independent
Text box	Format Only
Text area	Format Only
Date/Time	Format Only

Tip: After you add a context value, refresh the page to see the new value.

Usages

Descriptive flexfield usages allow for the same definition to be applied to multiple entities or application tables, such as a USER table and a USER_HISTORY table. Descriptive flexfield tables define the placeholder entity where the flexfield segment values are stored once you have configured the descriptive flexfield. When you configure a flexfield, the configuration applies to all its usages.

Parameters

Some descriptive flexfields provide parameters, which are attributes of the same or related entity objects. Parameters are public arguments to a descriptive flexfield. Parameters provide outside values in descriptive flexfield validation. You use parameters to set the initial value or derivation value of an attribute from external reference data, such as a column value or a session variable, rather than from user input. Parameters can be referenced by the logic that derives the default segment value, and by table-validated value set WHERE clauses.

Delimiters

A segment delimiter or separator visually separates segment values when the flexfield is displayed as a string of concatenated segments.

Initial Values

The SQL statement defining an initial value must be a valid statement that returns only one row and a value of the correct type.

You can use two types of SQL statements:

SQL statement with no binding. For example, select MIN(SALARY) from EMPLOYEES.
SQL statement with bind variables. You can use these bind variables in the WHERE clause of the SQL statement.
- :{SEGMENT.<segment_code>}: Identifies a segment in the same context.
- :{PARAMETER.<parameter_code>}: Identifies a parameter.
- :{CONTEXT.<context_code>;SEGMENT.<segment_code>}: Identifies a segment in a different context. The context must be in the same category or in an ancestor category, and it can't be a multiple-row context.
- :{VALUESET.<value_set_code>}: Identifies the closest prior segment in the same context that's assigned to the specified value set.
- :{FLEXFIELD.<internal_code>}: Identifies a flexfield.

Business Intelligence

Selecting a global, context, or context-sensitive segment's BI Enabled check box specifies that the segment is available for use in Oracle Business Intelligence.

When the flexfield is imported into Oracle Business Intelligence, the label you selected from the BI Label drop-down list equalizes the segment with segments in other contexts, and maps the segment to the logical object represented by the label.

Related Topics

Considerations for Enabling Descriptive Flexfield Segments for Business Intelligence

A descriptive flexfield that is registered in the database as enabled for Oracle Business Intelligence (BI) includes a BI Enabled setting for each of its segments. When a global, context, or context-sensitive segment is BI-enabled, it is available for use in Oracle Business Intelligence.

The following aspects are important in understanding BI-enabled flexfield segments:

Flattening business components to use BI-enabled segments in Oracle BI
Equalizing segments to prevent duplication and complexity in the flattened component
Mapping attributes of flattened business components to logical objects in Oracle BI
Managing the labels that map segments to logical objects in Oracle BI

After you deploy a business intelligence-enabled flexfield, use the Import Oracle Fusion Data Extensions for Transactional Business Intelligence process to import the flexfield changes into the Oracle Business Intelligence repository. Users can make use of the newly-generated attributes in business intelligence applications. For example, a user can generate a report that includes attributes added by the descriptive flexfield. For information about logical objects and import, see the Creating and Administering Analytics and Reports guide for your products.

Flattening

When you deploy a business intelligence-enabled descriptive flexfield, the deployment process generates an additional set of flattened Application Development Framework (ADF) business components in addition to the usual ADF business components and ADF faces run time artifacts that are generated during deployment. The flattened business components include attributes for business intelligence-enabled segments only. Flattening means each user-defined column in each context shows up as an attribute in an Oracle Business Intelligence folder.

Flattened components include one attribute for the BI-enabled context-segment, and one attribute for each business intelligence-enabled global segment. For BI-enabled context-sensitive segments, consider the following:

If you assigned a label to the segment, the flattened components include an additional single attribute representing segments with that label.
If you didn't assign a label, the flattened components include a discrete attribute for each BI-enabled context-sensitive segment in each context.

Mapping to Logical Objects in Business Intelligence

You can simplify reporting by representing similar segments as a single logical object in Business Intelligence.

If you assign a label to any set of context-sensitive segments that serve the same purpose in different contexts, you can consolidate or equalize the segments into a single attribute. This prevents duplication and the extra workload and complexity that result from the flattening process. For example, a United States context might have a Passport segment and a Canada context might have Visa segment. If you assign the NationalID segment label to both the Passport and Visa segments, they are equalized into the same NationalID attribute in the flattened business component.

Non-labeled context-sensitive segments aren't equalized across context values, so the flattened components include a separate attribute for each context-sensitive segment for each context value. It may not be possible to equalize similarly labeled segments if they have incompatible data types or value set types.

Assign a label to a global segment, context segment, or context-sensitive segment to map the corresponding attribute in the flattened components to a logical object in Oracle Business Intelligence. Using labels to map segments to BI logical objects minimizes the steps for importing the flexfield into Oracle Business Intelligence.

Note: Assigning a label to a context-sensitive segment serves to equalize the attribute across contexts, as well as map the equalized attribute to business intelligence.

Managing Labels

You may assign a predefined label (if available) to segments or create new labels for assignment, as needed. Specify a code, name, and description to identify each label. In the BI Object Name field, enter the name of the logical object in Oracle Business Intelligence to which the segment label should map during import. Specifying the BI logical object minimizes the steps for importing the flexfield into Oracle Business Intelligence and helps to equalize context-sensitive segments across contexts.

If no labels are assigned to a BI-enabled segment, or the BI Object Name on the assigned label doesn't exist in business intelligence, you must manually map the segment to the desired logical object when importing into Oracle Business Intelligence.

In addition, context-sensitive segments without labels cannot be equalized across context values. The flattened components include a separate attribute for each non-labeled context-sensitive segment in each context.

Importing to Oracle Business Intelligence Repository

After you deploy a business intelligence-enabled flexfield, import the flexfield changes into the Oracle Business Intelligence repository to make use of the newly flattened business components in business intelligence and then propagate the flexfield object changes. When you import the metadata into the Oracle Business Intelligence repository, you must do so as the FUSION_APPS_BI_APPID user.

To import flexfield changes into the Oracle Business Intelligence repository in Oracle Cloud implementations, run the Import Oracle Fusion Data Extensions for Transactional Business Intelligence process. For information about logical objects and import, see the Creating and Administering Analytics and Reports guide for your products.

Note: When you import a flexfield into the Oracle Business Intelligence repository, you see both <name>_ and <name>_c attributes for each segment, along with some other optional attributes. The <name> attribute contains the value. The <name>_c attribute contains the code of the value set that the value comes from, and is used for linking to the value dimension. You must import both attributes.

Related Topics

Financial Descriptive Flexfields

In Oracle Fusion Financial Applications, the descriptive flexfields are available from either the Basic or Advanced Search sections for all transaction objects that have Secure Enterprise Search (SES) enabled.

Examples of the descriptive flexfields available are:

Oracle Fusion Payables: Invoices
Oracle Fusion Receivables: Adjustments
Oracle Fusion Expenses: Expense
Oracle Fusion Assets: Assets Invoices
Intercompany: Intercompany Transaction Headers (Inbound Transaction)
Intercompany: Intercompany Transaction Batches (Outbound Transaction)
Oracle Fusion General Ledger: Journal Batches
Oracle Fusion General Ledger: Journals
Oracle Fusion Subledger Accounting: Subledger Journal Entry Header

Descriptive flexfields consists of segments.

The following table lists the descriptive flexfield segments.

Segment	Description
Global Segment	Are always displayed, if enabled.
Context Segment	Used to determine which context sensitive segments are displayed.
Context Sensitive Segment	Displayed values based on the defined value in the context segment.

In some products, the descriptive flexfields are displayed by default in the Search section, while others are available in the Add Fields menu.

Global Segments: Generally available in the Add Fields menu if they're not displayed by default. When a Global Segment is added to a Search Panel, it's displayed before the context segments.
Context Segments: Generally available in the Advanced Search section by default.
Context Sensitive Segments: Available in the Add Fields menu after you select a context segment value.
The segments are displayed in the Search Panel in the following order:
1. Global Segments
2. Context Segments
3. Context Sensitive Segments, after their Context Segment

Note:

The list of values on the Add Fields menu lists all descriptive flexfields alphabetically, followed by all other fields alphabetically.
If more than one global segment is defined, then all global segments are displayed in the Search panel in the sequence defined by you, the user, followed by context segments.
Similarly for context segments, all context segments are displayed in the Search panel in your defined sequence defined order.
When context sensitive segments are added to a Search panel, they're also displayed in your defined sequence order.

Related Topics

Intercompany Descriptive Flexfields

How You Search for Journal Descriptive Flexfields

Use descriptive flexfields to define and store additional information for journals. You have the capability to retrieve the information from descriptive flexfields by using the Advanced Search in the Manage Journals Search panel.

The two descriptive flexfields available for search on the journal pages are in the following regions:

Journal Batches
Journals

You can search using global and context segments, and both are available from the Advanced Search panel. After adding the context segment, a value is selected and a list of context-sensitive segments become available in the Add Fields.

Example of Additional Journal Information with Descriptive Flexfields Based on Ledger or Account Value

This example shows how to capture additional journal line information in the context of a specific ledger or natural account segment value, during journal entry.

Scenario

Your company has multiple ledgers. When entering journal lines for the Vision Corporation ledger, users must enter a source voucher number as additional information. For the Spruce Street Foods ledger, users must enter both a source voucher number and a source voucher date. The remaining ledgers don't have to track this information.

In addition, when entering journals, if the natural account segment in an account combination has a value of 7620, which represents legal expenses, users must provide a litigation file number. If the segment value is 52310, which represents insurance expenses, users must provide the name of the insurer and the policy number.

Configuring General Ledger Descriptive Flexfields

Before configuring the descriptive flexfield for source voucher information, you must find the ledger ID for each ledger. Use the Manage Primary Ledgers task in the Setup and Maintenance work area. If the Ledger ID column isn't displayed, click Columns, Ledger ID, from the View menu. In this example, the ledger ID for Vision Corporation is 1000, and the ledger ID for Spruce Street Foods is 1225.

Analysis

To capture the source voucher information, use the Manage General Ledger Descriptive Flexfields task in the Setup and Maintenance work area. Create a context segment for the Journal Lines descriptive flexfield with ledger ID as the context segment value. Set up the value to automatically default from the Ledger ID parameter.

The following image shows the Context Segment section on the Edit Descriptive Flexfield page for the Journal Lines flexfield, which has the flexfield code GL_JE_LINES. The context segment has a prompt of Ledger Details, a default type of Parameter, a default value of Ledger ID, a derivation value of Ledger ID, and a display type of List of Values.

This image shows a context segment that's configured
for the ledger ID.

Next, define a context-sensitive segment for the source voucher number, within the context of the Vision Corporation ledger. Set the context code to 1000, and set the segment to required. Then, define context-sensitive segments for the source voucher number and source voucher dates, within the context of the Spruce Street Foods ledger. Set the context code to 1225 and set both segments to required.

The following image shows part of the Edit Context page for the Spruce Street Foods ledger context with the two context-sensitive segments.

This image shows the context segment for the Spruce
Street Foods ledger, which has a ledger ID of 1225. The context segment
has two context-sensitive segments, one named Source Voucher Number
and the other named Source Voucher Date. Both context-sensitive segments
use the Character data type and are set to display in a text box.

Similarly, to capture information that's based on natural account segment values, create a context segment for the Journals Captured Information descriptive flexfield (flexfield code GL_CAPTURED_INFO) with natural account as the context segment value. Set up the value to automatically default from the Natural Account parameter.

Next, define a context-sensitive segment for the litigation file number, within the context of the legal expenses account. Set the context code to 7620 and set the segment to required. Then, define context-sensitive segments for the insurer and policy number, within the context of the insurance expenses account. Set the context code to 52310 and set both segments to required.

Deploy each descriptive flexfield after the setup is complete.

Resulting Prompts During Journal Line Entry

The prompts for providing the additional information appear on both the Create Journal page and the Create Journal spreadsheet, which you open using the Create Journal in Spreadsheet task. If prompted, you must provide the information to save the journal.

The following image shows part of the Journal Lines section on the Create Journal page. The ledger for the journal is Vision Corporation, and the natural account segment value on the journal line is 7620. The Source Voucher Number and Litigation File Number fields are required. The values for the context segment prompts of Ledger Details and Account Number are automatically defaulted.

This image shows journal line 1 with fields for
capturing additional information. The Ledger Details field displays
Vision Corporation, which is the ledger for the journal, and the Account
Number field displays 7620.

When entering journal lines for the Spruce Street Foods ledger and the insurance expenses account, users must provide a source voucher number, source voucher date, name of the insurer, and policy number. Journal lines with natural account segment values other than 52310 only require a source voucher number and date.

The following image shows part of the Journal Lines section on the Create Journal page. The ledger for the journal is Spruce Street Foods, and the natural account segment value on the journal line is 52310. The Source Voucher Number, Source Voucher Date, Insurer's Name, and Policy Number fields are required. The values for the context segment prompts of Ledger Details and Account Number are automatically defaulted.

This image shows journal line 1 with fields for
capturing additional information. The Ledger Details field displays
Spruce Street Foods, which is the ledger for the journal, and the
Account Number field displays 52310.

Profile Options

Overview of Profile Options

Profile options are a set of preferences that you use to centrally manage the user interface settings and application behavior.

You can use the profile options to manage, for example:

User preferences to specify language or currency.
Configuration choices to change the user interface skin or appearance of fonts.
Processing options to determine how much of an activity needs to be logged and at which level.

In the Setup and Maintenance work area, use any of the following tasks:

Manage Profile Options
Manage Profile Categories
Manage Administrator Profile Values

The following table contains a functional description of each task.

Task Name	Function
Manage Profile Options	Create new profile options or modify existing profile options, except some which are predefined and restricted to prevent any modifications.
Manage Profile Categories	Group the profile options based on their functional similarities.
Manage Administrator Profile Values	Set the profile values for the enabled profile options to control application behavior.

Hierarchy in Profile Levels

The hierarchy in profile levels determines the context for making a profile option effective.

You can enable a profile option at the following levels:

Site level (lowest): The entire site of deployment
User level (highest): A specific user

After you create or edit a profile option on the Manage Profile Options page, you must enable it. You can enable it at multiple levels. The setting at the highest enabled level takes precedence over the lower levels. User level is the highest in the hierarchy and always takes precedence over the settings at the site level.

On the Manage Administrative Profile Values page, set the profile value at any of the enabled levels of the profile option.

Example of Profile Option Hierarchy

The following table shows an example of setting the currency profile option at different levels.

Profile Level	Hierarchy	Currency
Site	Lowest	Euro
User	Highest	US Dollar

For this example, there are two users, John and Lisa. For John, the user-level profile value currency is set to US Dollar. If the Currency profile option is enabled only at the site level, both John and Lisa would see Euro as the default currency. If the profile option is enabled at the user level, users having a different currency set as their currency profile value would see only that currency. In this case, John would see US Dollar as the default currency. If the Currency profile option is enabled at the user level and there is no user level currency defined, the site level setting takes effect. When both site and user levels are enabled, the value for the user level takes precedence over the site level value.

Set Profile Option Values

Each profile option contains specific values that determine how it affects the application. You can add or modify the values for each profile option. Select or enter the value for one or more of the available levels (site, product, and user) so that each setting takes effect at the intended level.

Setting the Profile Value

In the Setup and Maintenance work area, go to the Manage Administrator Profile Values task.
On the Manage Administrator Profile Values page, search for and select the profile option.
In the Profile Values section, click Add. A new row is added for you to specify the following conditions:
- Profile Level: Specify the level at which the profile value is to be set. If the profile value applies to the entire site, select Site.
- Product Name: If you select Product as the profile level, select a product and specify the associated profile value.
- User Name: If you select User as the profile level, select the user name and specify the associated profile value.
- Profile Value: Select or enter the value corresponding to the selected profile level.
Note: For an existing entry, you can modify only the profile value.
Repeat step 3 to add more rows and set the profile values.
Click Save and Close.

Note: Changes in the profile values take effect for a user on the next sign in.

Create and Edit Profile Options

Use profile options to manage user preferences and control the general function of applications. For example, you can control user preferences involving language, date, time, currency, and other similar general settings.

You can create a profile option and also determine the level at which that profile option takes effect. You can also define the profile values for the profile option. The profile values appear on the Manage Administrator Profile Values page when you select the profile option.

Creating a Profile Option

In the Setup and Maintenance work area, go to the Manage Profile Options task.
On the page, click Actions > New.
On the Create Profile Option page, fill all the fields with relevant details with specific attention to the following:
- Use the SQL Validation field to provide an SQL statement that displays the permissible profile values to be used. Using an SQL statement, you can select the values from another table and display them as a list of values.
  
  For example, to display the values Yes and No from a lookup table, you can use the following SQL statement:
```
select MEANING, LOOKUP_CODE from FND_LOOKUPS where LOOKUP_TYPE='YES_NO'
```
  As a result, on the Manage Administrator Profile Values page, the profile values Yes and No are available for selection for that profile option.
- You can specify a date range to keep the profile option active during that period. Beyond the specified duration, the profile option automatically becomes inactive. If you no longer require the profile option, you must manually delete it from the Manage Profile Options page.
Click Save and Close.
On the Manage Profile Options page, search for the newly created profile option and from the results, select it.
In the Profile Option Levels section, do the following:
1. In Enabled, select the levels at which you want to enable the profile option.
  
  Note: You can enable a profile option at multiple levels, but a higher-level profile value overrides a lower-level value. Therefore, enable them only at the required levels.
2. In Updatable, select the profile level at which you want implementors to have update privileges. Leave the check box deselected if you don't want the implementors to modify the profile values (they appear in read-only mode).
Click Save and Close.

To edit a profile option that you created, search for it and edit the necessary details.

Note: While creating and editing profile options and profile categories, you can translate the details to the preferred languages without changing the language session of the application. To specify the translations in all the enabled language rows, use the Translation Editor option. Once the updates are made, users can view the translated text for the specific details.

Related Topics

Enter or Edit Translated Text

Profile Categories

You can create profile categories to group profile options based on their functional similarities and their use. In the Setup and Maintenance work area, use the Manage Profile Categories task.

Profile categories help administrators or implementors in retrieving profile options using a search criterion on the Manage Administrator Profile Values page.

Managing Profile Categories

Consider the following options while managing profile categories:

Create profile categories and add existing profile options to them
Add newly created profile options to existing user-defined profile categories

Note: While you can add a profile option to more than one category, some profile categories are predefined and restricted from any modifications. So, you can't edit them or add profile options to them.

Setting Display Sequence for the Profile Options

You must set the display sequence for each profile option that you add to a profile category. Display sequence determines the order in which the profile options appear in a search result, based on the profile category. You can set the sequence beginning with zero or one for the first profile option to display, and proceed sequentially to assign the values to the remaining profile options.

The following table demonstrates the effect of the display sequence on the profile options when they're retrieved as search results.

Profile Category	Included Profile Option - Assigned Display Sequence	Display Sequence of Profile Options in the Search Results
Attachments	Attachment File Directory - 2 Indicate Attachments - 1	Indicate Attachments Attachment File Directory

FAQs for Profile Options

How can I access predefined profile options?

Search for predefined profile options using the Manage Profile Options task.

In the Setup and Maintenance work area, go to the Manage Profile Options task.
On the page, enter any of the search parameters and click Search.

Tip: If you don't know the profile option code or the display name, use the Application or Module fields to filter search results.
Click a profile option to view its details.

Workflow Transaction Console

Overview of Workflow Transaction Console for Financials

Use the workflow Transaction Console to monitor and troubleshoot workflow tasks for the Invoice, Expenses, and Journal Approval workflows.

From the console you can:

View the latest status of all workflow tasks.
Review the issue description and resolution for failed tasks.
Take appropriate action on a failed task.
Search tasks based on user-defined criteria.
Download search results to a spreadsheet.

Related Topics

Give Users Access to Manage Financials Workflow Transactions

Users can manage transactions for the Invoice, Expenses, and Journal Approvals workflows from the Transaction Console.

Give Financial Users Administrator access

You have a couple of options for giving users access to the Transaction Console work area, depending on whether you're assigning them predefined job roles, or your own configured job roles.

Assign the predefined Financials Application Administrator (ORA_FUN_FINANCIAL_APPLICATION_ADMINISTRATOR_JOB) job role.
Your own configured job role must include the Financial Transaction Approval Reviewing (ORA_FIN_REVIEW_APPROVAL_TRANSACTIONS) duty role.

Limit What Users Can See

By default, users who have access to the Transaction Console work area can see all transactions, from all product families.

To make sure that financial users view only the financial workflows, enable transaction security:

In the Setup and Maintenance work area, go to the Manage Enterprise HCM Information task.
- Offering: Financials
- Functional Area: Enterprise Profile
- Task: Manage Enterprise HCM Information
On the Edit Enterprise page, click Edit and then select Update.
Complete the fields in the Update Enterprise dialog box and click OK.
In the Transaction Console Information section, select Enable Transaction Security.
Click Submit.

Note: You just need to do this for one offering. The setting now applies to all product families. If you're also using Oracle HCM Cloud, make sure transaction security profiles are set up so that HCM administrators can see and act on HCM transactions.

Related Topics

Manage Workflow Transactions

After workflow tasks are created, it's helpful to keep track of them and jump in when you need to, especially when something goes wrong. If you have the appropriate roles, you can monitor and troubleshoot workflow tasks for others and for yourself. Use the Transaction Manager: Transactions page in the Transaction Console work area to manage transactions. A transaction is a business process that involves a workflow task.

Here are some of the things you can do:

Track transaction statuses and download spreadsheets with information about transactions.
Download and review diagnostic logs for transactions with errors.
Depending on what's going on with the transaction and what roles you have, you might be able to, for example, reassign or recover the transaction.

Find Transactions

Follow these steps:

Click Navigator > Tools > Transaction Console.
If you see tabs, make sure you're on the Transaction Summary tab.
On the Transaction Manager: Transactions page, check the Last Refresh time stamp after the page title to see when the transaction statuses were last updated. Click the Refresh icon if needed. You can refresh any time as long as someone else didn't already start a refresh.
- You can also set the Refresh Transaction Administrator Console Transaction Status scheduled process to run on a schedule, to automatically refresh the statuses on a regular basis. Start by setting it to run once every hour, and then see how it goes and adjust from there.
- If you open the details for a specific transaction (step 5), its status also refreshes and you see the latest on the details page.
View the transactions with a status that matches the default Status filter, for example Failed. You can remove this filter to get results for all statuses. Or, use the search and filters to apply your own criteria, for example, to find transactions that are priority 1 or submitted by a specific person.
- You can use the search to find results based on keywords in the Name or Process Name column, or specifically use the Name or Process Name filters. Name is the person or object the workflow task applies to, and the process reflects the type of workflow task.
- You can personalize filters to add or hide filters, and create saved searches for future use.
Select and act on the transactions right there from the results table, or click the transaction in the Name column to see details, such as diagnostic information for failed transactions, and go from there.

Act On Transactions Without Opening Details

Here's what you do:

Select one or more transactions from the results table.
Optionally use the Priority menu to set an issue priority, so that you can later filter on the priority to find these transactions.
Open the Actions menu and select an action. If you selected more than one transaction, you see only the actions that can apply to all of them.

Use Transaction Details

What you can see and do in the transaction details depends on the transaction status and what roles you have. For example, for transactions that are in progress or completed, you might see the approval history, which shows who already approved and who the current assignee is, if any.

For failed transactions, you can get information about the issues and, if you're an administrator, usually take some action:

Select an issue from the Issues list, if the transaction has more than one issue.
Review the information in the Instructions and Details sections, including any description and resolution for the issue, as well as the related workflow task and approval rule.
Click the Download link to get the diagnostic log.
Use the Issue Priority list to set an issue priority, if you want to later filter on the priority to find this transaction.
From the Assigned To list, select the person who should fix the issue, for tracking and filtering purposes.
Add comments, for example to track what you're doing to address the issue, or note down any service request IDs. You and others can see these comments only in the Transaction Console, not with the workflow task in the worklist.
If you can, take action to address the issue. Here are some examples of how you might go about it:
- Open the Actions menu and select an action to manage the transaction.
- Follow up with the person you assigned the issue to or your help desk. Give them the diagnostic log and other information from the transaction details.
- Reconfigure the approval rule that the transaction is based on, and have the workflow task resubmitted.
Select another issue from the Issues list, if any, and go through the same process.
Click Save and Close.

Download a Spreadsheet of Transactions

This is all you need to do:

In the results table, select the transactions you want to include in the spreadsheet. To get all transactions, either select all of them or none at all.
On the Actions menu, click Download.

Related Topics

Statuses for Filtering Transactions

Use the Transaction Manager: Transactions page in the Transaction Console work area to track the status of transactions. For example, you can filter the transactions by status to see just the transactions that are in progress or stuck. These statuses aren't the actual workflow task statuses that you see in the worklist or in notifications.

Status	Description
Auto Recovery	The transaction ran into some issues, but the application is trying to fix them without any action on your end.
Completed	All approvals are done and the transaction successfully went through all processes.
Draft	The transaction is saved but not submitted yet. This status doesn't apply to all product families.
Failed	The transaction has one or more errors, for example, due to a network or database outage, or an issue in the approval rules setup.
In Progress	At least one approval is still pending for the transaction before it's all done.
Stuck	The transaction was submitted, but ran into issues so the workflow task doesn't exist yet.
Submitted	The transaction was just created and hasn't moved on yet to another status. This status doesn't apply to all product families.

Related Topics

Actions and Statuses for Workflow Tasks

Actions for Managing Transactions

Use the Transaction Manager: Transactions page in the Transaction Console work area to manage and troubleshoot transactions. For example, you can withdraw a transaction even if you're not the one who submitted it. What you can do depends on the transaction status and the roles you have. Some actions, such as approve and reassign, are the same as the ones you can take on the workflow tasks from the worklist or from notifications.

Action	Description
Add Comment	Add your notes for the transaction, for example to track what you're doing to address the issue, or to jot down any service request IDs. You and others can see these comments only in the Transaction Console.
Alert Initiator on Error	Notify the submitter if the transaction ends up in error.
Approve	Approve the transaction if the workflow task is currently assigned to you to approve or reject.
Download	Get a spreadsheet with information about the selected transactions.
Reassign	Reassign the workflow task to an approver, the submitter, or someone else.
Recover	Restart the process after the transaction stopped due to errors. After you address the issue, use this action to get the application to pick up where the process last left off and retry whatever had ended up in error.
Reject	Reject the transaction if the workflow task is currently assigned to you to approve or reject.
Terminate Process	Completely end the transaction so that no one can see or act on the workflow task again.
Withdraw	Remove the workflow task from the workflow. You can ask the submitter to submit again, for example, after an issue is resolved.

Related Topics

Actions and Statuses for Workflow Tasks