9General Ledger Options
This chapter contains the following:
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.
Accounting Automation
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
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. |
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.

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.

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.

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.

Here's more information about each column shown in the example.
Column | Description |
---|---|
Transaction Type |
Identifies the source of the error, which includes:
|
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.

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. |
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.
-
Assign the new job role to the policy.
-
Create a rule and select this value for the condition: ESS requests submitted by Accounting Automation process.
-
To allow users to view the log and output files, select these actions: ESS_REQUEST_READ, ESS_REQUEST_OUTPUTREAD.
-
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.
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.
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 |
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.

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.

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
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.
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.
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.
To create workflow rules in a spreadsheet, perform the following steps:

-
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.
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.
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-9Attribute 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.
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.
Modify Workflow Rules Using a Spreadsheet
After creating the rules using a spreadsheet template, you can modify them using a spreadsheet.
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.
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.
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
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.
-
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. |
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 |
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.
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 |
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.

-
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.
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.
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> |
|
Product |
BIP_CLIENT_REFRESH_TIME_<FAMILY>_<PRODUCT> |
|
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.
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.
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.
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.
-
Sign in to the application with the application consultant job role.
-
In the Reports and Analytics work area, click the Browse Catalog button.
-
Click the Home link.
-
In the Get Started section, click the Download BI Desktop Tools link.
-
Select Template Builder for Word from the list.
-
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.
-
Click the Catalog link on the Oracle Business Intelligence home page and expand the Shared Folders > Common Content > Templates folder.
-
Click the Edit link for the Workflow Notification Subtemplate. The subtemplate page opens.
-
In the Templates section, click the language name link in the Locale column.
-
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.
-
In the Setup and Maintenance work area, go to the following:
-
Offering: Financials
-
Functional Area: Financial Reporting Structures
-
Task: Manage Chart of Accounts Structure
-
-
Search for the Accounting Flexfield and click Manage Structures to open the Manage Key Flexfield Structures page.
-
Search for your chart of accounts and click Edit in the Search Results section.
-
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:
-
Click the Catalog link on the Oracle Business Intelligence home page 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.
-
In the Folders pane, click the Data Models subfolder to select it.
-
In the toolbar, click the Copy Resource button.
-
In the Folders pane, expand the Shared Folders > Custom > Financials > Workflow Notifications > General Ledger folder.
-
Click the Journals folder to select it.
-
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
orSegment_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:
-
Find your copy of the data model by expanding the Shared Folders > Custom > Financials > Workflow Notifications > General Ledger > Journals > Data Models folder.
-
Click the Edit button for the Journal Approval Data Model copy. The Journal Approval Data Model page opens.
-
In the Data Model pane, in the Data Sets folder, click the Journal Lines data set.
-
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.
-
In the SQL Query field, place your cursor after
SELECT
and insert rows for the new SQL statements. -
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.
-
Click OK to close the Edit Data Set - Journal Lines dialog box.
-
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:
-
Open your local copy of the report layout template using Microsoft Word.
-
Place your cursor at the end of the default header text, which is Journal Batch Approval.
-
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:
-
Select the BI Publisher tab to open the BI Publisher ribbon.
-
In the Load Data group on the ribbon, click Sample XML.
-
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.
-
Click OK on the message that appears indicating that the data was successfully loaded.
-
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.
-
Enter the text label for the new field, such as Batch Created By, and then add a space.
-
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.
-
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.
-
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:
-
Place your cursor after the label called
StrtLineLINE_ACCOUNTEC
and insert a new line. -
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.
-
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.
-
Click Insert to add the field to the report layout template.
-
In the report layout template, add a character such as a hyphen, to separate the segments.
-
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.
-
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.
-
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
. -
Place your cursor after the
CLINE_ACCOUNTEC
field and insert a new line. -
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 theCLINE_ACCOUNTEC
fields.
-
-
Delete the fields
StrtLineLINE_ACCOUNTEC
andCLINE_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.
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.
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.
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.
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.
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 |
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. |
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 setdeterminant
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.
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 setdeterminant 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.
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.
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 |
Determines which context-sensitive segments are displayed |
|
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.

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.
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.
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 |
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.
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.
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.
<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.
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. |
Used to determine which context sensitive segments are displayed. |
|
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:
-
Global Segments
-
Context Segments
-
Context Sensitive Segments, after their Context Segment
-
-
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.
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.

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.

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.

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.

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.
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:
-
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. -
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.
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
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 |
|
|
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.
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.
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.
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. |
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. |