9General Ledger Options

This chapter contains the following:

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

Setup and Considerations

Use this navigation in the Setup and Maintenance work area.

  • Offering: Financials

  • Functional Area: General Ledger

  • Task: Manage Accounting Automation

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

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

Setting What It Is

Enable Automation

Indicator for whether accounting automation is enabled for all ledgers (primary, secondary, and reporting currencies with currency conversion levels of Journal or Subledger).

Scheduled Submission Time

Time when accounting automation is submitted and when daily email notifications are sent. The process can run an additional three times a day (every six hours), if transactions are pending. If no transactions are pending, accounting automation runs only at the time you specify here.

Notification Preference

Setting that determines whether to send email notifications to users or roles.

Default User to Notify or Default Role to Notify

User or role that receives an email notification for each accounting automation run. The notification provides a summary of the processed data and a detail listing of all errors.

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

Notification Preference What You Can Set

User

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

Role

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

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

Here are the error categories.

Category Description

Account Mapping

Issues with chart of account mappings and subledger accounting mapping sets.

Account Status

Issues related to account statuses such as invalid accounts, or issues related to generation of balancing accounts.

Approval

Rejected journal batches, journal batches that require approval, and journal batches that are in the process of being approved.

Balancing

Issues related to balancing, such as intercompany, suspense, entered currency, and rounding.

Budgetary Control

Errors related to funds reservation.

Critical Error

Critical issues, such as wrong batch statuses.

Currency Conversion

Issues related to currencies, such as missing conversion rates and invalid currencies.

Journal Interface

Issues with importing journal data.

Period Status

Errors related to period statuses, such as a closed period and unopened encumbrance year.

Subledger Transaction Data

Issues with transaction data from subledgers, such as Oracle Fusion Payables, Oracle Fusion Project Costing, Oracle Fusion Receivables, and Oracle Fusion Assets.

System Error

System-related issues.

Warning

Warnings generated by processes.

Other

Errors outside of the predefined error categories. For example, errors related to assignment of balancing segment values to a ledger or legal entity, document sequencing, reversals, no data, and average daily balancing.

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

Some additional considerations:

  • Accounting automation doesn't process transactions that were created before the automation was enabled, unless the accounting date on the transaction is the same as, or later than, the date automation was enabled.

  • Accounting automation doesn't process incomplete batches for posting.

  • If you use Receivables and plan to enable accounting automation, you must schedule the Create Receivables Accounting process to run daily, before the Accounting Automation process scheduled time.

Users and Email Notifications

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

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

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

Notifications can include the following sections:

  • Posted Transactions Summary

  • Automation Errors Summary

  • Pending Approvals Summary

  • Automation Errors Details

  • Pending Approvals Details

Posted Transactions Summary

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

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

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

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

Column Description

Ledger

Names of the ledgers (primary, secondary, and reporting currency) that journal batches were posted to.

Total Amount

Sum of the accounted debits for the journal batches that were posted to the ledger.

Currency

Ledger currency.

Automation Errors Summary

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

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

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

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

Column Description

Ledger

Ledger (primary, secondary, or reporting currency) of the transaction. Is blank if no ledger is associated with the transaction, such as daily rates import errors.

Error Category

Error category associated with the error.

Total Amount

Sum of the accounted amounts that couldn't be processed due to the error category for the ledger.

Currency

Ledger currency.

Number of Errors - Total

Count of the transactions that have errors. Links to the error details section of the email notification.

Number of Errors - New

Count of the transactions that have errors appearing for the first time in the latest accounting automation run. Links to the error details section of the email notification.

Users Notified

Users who were notified of the errors, excluding the default user who's always notified. Is blank if no users were set up to receive email notifications for the respective ledger, source, and error category.

Pending Approvals Summary

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

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

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

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

Column Description

Ledger

Ledger (primary, secondary, or reporting currency) of the journal batch.

Amount

Sum of the journal batches that are in the approval flow.

Currency

Ledger currency.

Pending Approval Batches: Amount

Total amount of journal batches pending approval broken down into the following aging buckets since the last approval action: 0 - 3 days, 4 - 7 days, 8 - 11 days, more than 12 days.

Pending Approval Batches: Count

Number of journal batches pending approval broken down into the following aging buckets since the last approval action: 0 - 3 days, 4 - 7 days, 8 - 11 days, more than 12 days. Links to the Pending Approvals Details section of the email notification.

Automation Errors Details

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

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

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

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

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

Column Description

Transaction Type

Identifies the source of the error, which includes:

  • Subledger Transaction: Transactions from subledger applications, such Payables and Receivables

  • Accounting Entry: Accounting entries created in the Oracle Fusion Subledger Accounting application

  • Journal Interface: Oracle Fusion General Ledger journal import transactions

  • General Ledger Journal

  • Daily Rates Import

Source

Journal source of the transaction.

Transaction

Object of the transaction and identifying information. For example, the Subledger Transaction type for a Payables transaction displays the application, party name, party site name, invoice number, date, and amount.

Error

Information about the error that occurred, including suggested corrective actions in some cases. Errors appearing for the first time in the latest automation run are prefixed with a dot icon.

Amount (Currency)

Total of the accounted debits for the transaction.

Pending Approvals Details

This section shows details for the Pending Approvals Summary section.

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

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

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

Column Description

Journal Batch

Name of the journal batch.

Source

Source of the journal batch.

Initiator

User who requested the approval.

Status

Approval status of the batch.

Amount (Currency)

Journal batch amount in the ledger currency.

Days Outstanding

Number of days since the last approval action.

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:

  1. Create a job role for the users who require access.

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

    This figure shows the Policy page for an existing
policy called Accounting Automation Read policy.
    1. Assign the new job role to the policy.

    2. Create a rule and select this value for the condition: ESS requests submitted by Accounting Automation process.

    3. To allow users to view the log and output files, select these actions: ESS_REQUEST_READ, ESS_REQUEST_OUTPUTREAD.

    4. To allow users to cancel the Accounting Automation job, select the ESS_REQUEST_CANCEL action.

Accounting and Reporting Sequences

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

Sequential numbering of journals enables you to:

  • Maintain gapless sequence numbers.

  • Sequentially number subledger journal entries. Generate a sequence number for journal entries created by subledger accounting before transferring them to general ledger.

  • Sequentially number general ledger journal entries.

  • Assign sequences within a ledger or legal entity.

  • Generate reports based on the sequence numbers.

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

  • Accounting Sequences: Gapless sequence numbering for journals which is assigned when the journals are posted or subledger accounting runs.

  • Reporting Sequences: Gapless and chronological sequence numbering which is assigned to journals when the General Ledger period is closed.

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

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

Sequences

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

When you create a sequence version, you specify the:

  • Effective Start Date: The default date is the current date. The date can be set to any date in the past or future.

  • Effective End Date: The date when the sequence should be disabled.

  • Initial Number: A positive integer that's the starting number of the sequence. The number increments by one for each accounting entry.

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

Sequencing Assignments

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

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

Field Description

Ledger

The ledger for which the journal entries must be sequentially numbered or that contains the legal entity.

Legal Entity

The legal entity for which the journal entries must be sequentially numbered. The Legal Entity field appears when you set your Sequence By ledger option to Legal Entity.

Journal Entry Type

Select whether general ledger or subledger entries are being sequentially numbered.

Sequencing Event

The event which triggers the sequence numbering,

Sequence Validation Date

The date when generating a sequence number. This date is used to determine if a sequence is available and the sequence assignment is active.

Require Assignment for All Journals

If you select this option, you must explicitly define valid Sequence Assignments, Exceptions, or Exclusions for all journal entries.

Status

Indicates if the assignment is enabled or disabled.

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

Journal Entry Type Sequencing Event Sequence Validation Date Journal Sorting Date Remark

General Ledger

Posting

Accounting Date

Accounting Date

Accounting Sequence

Subledger Accounting

Subledger Accounting

Accounting Date

Completion or Posting Date or Accounting Date

Accounting Sequence

General Ledger

Period Close

Accounting Date

Accounting Date

Reporting Sequence

General Ledger

Period Close

Reference Date

Reference Date

Reporting Sequence

Subledger Accounting

Period Close

Accounting Date of Reference Date

Reference Date

Reporting Sequence

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

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

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

Sequencing Assignment Details

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

Field Description

Status

Status of the assignment such as New or Used.

Priority

Priority of the exception. This option is inactive unless you define an exception.

Sequence Name

Name of the sequence to be assigned. A blank indicates the entries must not be sequenced.

Start Date

Define the effective start date for the sequence assignment.

End Date

Define the effective end date for the sequence assignment.

Journal Source

Select the journal sources from the list to be sequentially numbered for a sequence event.

Journal Category

Select the journal categories from the list to be sequentially numbered for a sequence event.

Accounting Event Type

Select the accounting event types to be sequentially numbered (only for subledger entries).

Accounting Entry Type

Select the accounting entry types to be sequentially numbered (only for subledger entries).

Document Category

Select to group transactions assigned to the sequence.

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

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

Use the following buttons to add a row:

  • Add Exception: When you create an exception, the priority value is always one more than the highest number in the Priority field. Use exceptions to assign different sequences to certain journal sources, journal categories, accounting event types, or accounting entity types. For example, you want to include all journal sources, but assign a different sequence for your Expense journals.

  • Add Exclusion: Create exclusions to exclude specific journal sources, journal categories, accounting event types, or accounting entity types. For example, you want to exclude journal sources and categories containing management or statistical accounts that don't impact financial results.

FAQs for Accounting and Reporting Sequences

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

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

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

Rule Definition Consideration

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

  • Offering: Financials

  • Functional Area: Application Extensions

  • Task: Manage Task Configurations for Financials

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

  • The highest journal line amount per ledger per batch.

  • The highest journal amount per ledger per batch.

  • Your stage in the period close process. For example, are you in the beginning, middle, or end of the month, or in preclose, close, post close, or quarter close process?

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

Condition Approval Action

Less than 50,000 USD

No approval required

Between 50,000 and 100,000 USD

One level of approval required

Greater than 100,000 USD

Two levels of approval required

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

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

Approvals List Builder Considerations

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

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

List Builder Description

Supervisory

Based on the employee supervisory hierarchy, which is defined in HCM. Employees must be set up with appropriate jobs and supervisors. For example, a clerk reports to a manager, who reports to the director.

Job Level

Based on the job level, which is defined in HCM. Employees must be set up with the appropriate job levels and supervisors.

For example, a job level 1 employee, a clerk, reports to a job level 2 employee, a manager, who reports to a job level 4 employee, a director. The approval list is generated based on the starting position specified in the rule and continues until an approver with a sufficient job level is found. The supervisory hierarchy must be defined along with the corresponding job levels.

Position

Based on the position hierarchy, which is defined in HCM. The position hierarchy must be defined and employees must be assigned the corresponding positions. Use this hierarchy if you need a hierarchy that's different from the supervisory hierarchy, or multiple hierarchies selected based on different attributes.

Approval Group

Consists of a static predefined set of users configured to act on a task. For example, you can create an approval group called Finance Group, consisting of users from the finance department who must participate in the task approval.

Resource

Builds the approvers list by using a specific user, enterprise group or application role.

Other Considerations

Other functionality to consider before defining approval rules.

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

    Caution: You should not enable journal approval for journals that come from subledgers (with subledger journal sources). Otherwise, if a journal from a subledger isn't approved, the journal can get stuck in the approval process. For any subledger journal sources, approvals for subledger transactions should be done in the subledgers themselves.
  • Approval is for the entire journal batch, regardless of the attributes used in the approval rules.

  • If a journal requires approval, submitting a journal for posting automatically routes the journal for approval before posting.

  • A journal can be escalated to an approver by the administrator.

  • The task initiator can select Withdraw Approval on the Journals page at any time in the approval process to withdraw journals from the process. Clicking this button enables editing of the journal. After your changes are made, submit the entry for approval again. When a journal is withdrawn, the completion status is set to Incomplete.

  • Approval notifications display a table of key journal attributes for each journal and a list of past, current, and future approvers.

  • The Journals work area displays journals requiring your approval and journals pending approval from others.

  • If you're the current approver, the Journals page shows the journals to be approved or rejected.

  • Allocation journals aren't routed through the approval process.

  • You can review the details of the journals and journal lines included in a journal batch on the online and email journal batch approval notifications.

Create Journal Approval Rules Using a Spreadsheet

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

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

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

Steps to create workflow rules using a spreadsheet.
  1. Sign in and navigate to the Manage Workflow Rules in Spreadsheet task.

  2. Download the rule template from the Rule Templates section of the Manage Workflow Rules in Spreadsheet page.

  3. Define the workflow rules in the spreadsheet.

  4. Generate the rule file.

  5. Upload the rule file to create rules.

  6. Verify the spreadsheet upload.

Caution: You must use MS Excel version 2016 to create workflow rules. Also, every successful rule upload using a spreadsheet template overrides the existing rules for the workflow.
Tip: Once you create rules using the rule templates, we recommend you use the spreadsheet method only for any future maintenance of rules.

Before creating and managing workflow rules, perform these steps:

  1. Sign in to the application as a Financial Application Administrator.

  2. 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, select its check box.

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

  1. In the Rule Templates section of the Manage Workflow Rules in Spreadsheet page, select the required workflow.

  2. Click Download. The Download Templates dialog box appears.

  3. From the dialog box, select the required template. Save the template to your local computer.

Caution: You must use MS Excel version 2016 to create workflow rules.
Note: Each rule template contains an example of an approval business case to demonstrate how to manage workflow rules using the rule template.
Define the Rules in the Spreadsheet

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

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

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

  1. Rule Description

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

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

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

    1. Open the list of values associated with the last column in the Approval Conditions section.

    2. Select the required attribute category.

    To add an attribute:

    1. Open the list of values associated with the attribute category.

    2. Select the required attribute.

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

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

    Condition Value Type Format Example

    Attribute is a specific value

    Text, number, or date

    value

    Note: No specific format applies here.

    If the Invoice Type is Standard, then enter the value as:

    Standard

    Attribute value is one of multiple specific values

    Text or number

    in (value 1, value 2, ...)

    If the BU name is Vision Operations, Vision Services, or Vision Foods then enter the value as:

    In (Vision Operations, Vision Services, Vision Foods

    Attribute value should be within a range of values

    Number or date

    between value 1 and value 2

    OR

    value 1 to value 2

    If the Invoice Date is between 01 August 2018 to 01 August 2019, then enter the value as:

    Between 01/aug/2018 and 31/aug/2019

    OR

    01/aug/2018 to 31/aug/2018

    Attribute value starts with a specific value

    Text

    Starts with value

    If the BU name starts with Vision then enter the value as:

    Starts with Vision

    Attribute value ends with a specific value

    Text

    Ends with value

    If the BU name ends with Operations then enter the value as:

    Ends with Operations

    Attribute value contains a specific value

    Text

    Contains value

    If the Pay Group contains Standard then enter the value as:

    Contains Standard

    Attribute value matches a specific value

    Text

    Matches value

    If the Description matches manual invoice then enter the value as:

    Matches manual\\s(.*) invoice

    In this example, the Matches operator begins with Manual and ends with Invoice. Between the two words, there can be one space and any character.

    Other options that can be used with the Matches operator are:

    (.*) - Denotes zero or more characters.

    (.+) - Denotes one or more characters.

    \\s - Denotes space.

    \\d - Denotes numbers from 0-9.

    ? - Makes a character optional. For example: \\d?

    [ ] - Specifies range such as A-Z, 0-9

    Attribute value is more than or equal to a specific number

    Number

    More than equal to number

    OR

    >= number

    If the Invoice amount is more than or equal to 500, then enter the value as:

    More than equal to 500

    OR

    >= 500

    Attribute value is less than or equal to a specific number

    Number

    Less than equal to number

    OR

    <= number

    If the Invoice amount is less than or equal to 500, then enter the value as:

    Less than equal to 500

    OR

    <= 500

    Attribute value is more than a specific number

    Number

    More than number

    OR

    >number

    If the Invoice amount is more than 500, then enter the value as:

    More than 500

    OR

    >500

    Attribute value is less than a specific number

    Number

    Less than number

    OR

    <number

    If the Invoice amount is less than 500, then enter the value as:

    Less than 500

    OR

    <500

    Attribute value is on or before a specific date

    Date

    On or before date

    If the Invoice date is on or before 01/10/2018, then enter the value as:

    On or before 01/oct/2018

    Attribute value is on or after a specific date

    Date

    On or after date

    If the Invoice date is on or after 01/10/2018, then enter the value as:

    On or after 01/oct/2018

    Attribute value is before a specific date

    Date

    Before date

    If the Invoice date is before 01/10/2018, then enter the value as:

    Before 01/oct/2018

    Attribute value is after a specific date

    Date

    After date

    If the Invoice date is after 01/10/2018, then enter the value as:

    After 01/oct/2018

    Attribute value is a specific value and the condition must be evaluated as case insensitive

    Text

    Equals ignore case value

    If the Invoice Source is equal to Manual, then enter the value as:

    Equals ignore case manual

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

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

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

Rule Blocks

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

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

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

To insert more blocks in a rule block:

  1. Select a row.

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

  1. Select a row and right-click.

  2. From the menu, select Insert.

To delete a rule block:

  1. Select all the rows in a rule block.

  2. Right-click and select Delete Block.

Data Sets

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

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

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

To define a data set, perform these steps:

  1. Open the Data Set sheet of the rule template.

  2. In the Set Name column, enter a unique name.

  3. 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.
  4. If your starting approver for rules using Supervisory or Job Level Hierarchy approval routing varies based on transaction attributes, then click 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.
  5. 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.

  6. Enter values for each varying attribute. You can also use the supported operators with the values.

  7. Click Add New Column to create additional columns for varying attributes.

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

  1. Navigate to the Manage Workflow Rules in Spreadsheet page.

  2. In the Rule Templates section, select the required workflow.

  3. Click Upload. The Upload File dialog box appears.

  4. In the File field, click Choose File.

  5. From your local directory, select the compressed rule file that was generated from the workflow rules template.

  6. 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.
  7. Click OK.

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

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

  2. In the Instructions sheet of the rule template, click Update Spreadsheet.

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

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

Import existing rules from Oracle Business Process Management (BPM) directly into spreadsheet-based templates.

You can then use the spreadsheet to view and update these rules, before uploading this spreadsheet back on the Manage Rules in Spreadsheet page. Previously, BPM rules had to be manually entered into the spreadsheets to use the Simplified Workflow Rules Configuration feature.

At present, you can use this feature to migrate rules for these workflows:

  • Payables Invoice Approval

  • General Ledger Journal Approval

Here's how you migrate BPM rules to a Simplified Workflow Rules Configuration spreadsheet:

  1. Download a BPM rules file.

  2. Import the rules from the BPM rules file into the Simplified Workflow Rules Configuration template for the workflow.

Download BPM Rules File

Perform these steps to download a file that contains the BPM rules:

  1. Go to the Manage Workflow Rules in Spreadsheet page.

  2. In the Migrate Rules from BPM section, click Download BPM Rules.

  3. On the Download BPM Rules dialog box, select the workflow for which you want to download the rules.

  4. Click OK.

Note: The BPM rule file is generated only when your rules are supported for migration. You get a message when your rules aren’t supported for migration. In such cases, you must use Oracle BPM to manage your rules. Click BPM Worklist to go to the Task Configuration tab of the BPM Worklist.

A copy of your current rule configuration for a workflow is saved in UCM when you successfully download it for the first time. The configuration copy is used to restore the rules back to this state after migration.

Import Rules to Simplified Workflow Rules Configuration Spreadsheet

Here’s how you import the downloaded rules into a Simplified Workflow Rules Configuration spreadsheet:

  1. Go to the Manage Workflow Rules in Spreadsheet page.

  2. In the Rule Templates section, select any of the available templates for a workflow and click the Download icon in the same row.

  3. Open the downloaded file and go to the Instructions sheet.

  4. Click the Import Rules button and then select the BPM rule file downloaded previously. This imports your BPM rules into the spreadsheet.

Note: Ensure that you select a template for the workflow for which you want to migrate the rules. For example, you must use an Invoice approval workflow template to migrate Invoice rules.

Once the rule migration has completed, you can review the rules and proceed to use this template to view and modify the rules. Once you’re done, go to the Instructions sheet and generate the rule file. Next, upload the rule file on the Manage Workflow Rules in Spreadsheet page. The migration process is completed only after a successful upload.

Restore Rules

Use the Restore Rules feature to restore the rules to their previous state (the way they were when the BPM rules file was first downloaded).

Here’s what you do to restore the rules:

  1. Go to the Manage Workflow Rules in Spreadsheet page.

  2. In the Migrate Rules from BPM section, click Restore Rules.

    Note: The Restore Rules button is enabled only when there is at least one workflow for which a BPM rule file has been successfully downloaded at least once previously.
  3. On the Restore Rules dialog box, select the workflow for which you want to restore the rules.

  4. Click OK.

After you confirm this action, the configuration file stored in UCM is used to restore the workflow rules to the state before migration.

Note: The Restore Rules always restores the rules to the state they were in at the first time the rule file was ever downloaded. Even if you subsequently change the BPM rules and download the rules file again, this doesn’t change the rules file stored in the UCM. It remains the same as the first time the rule file was ever downloaded.

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

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

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

  1. Navigate to the Manage Rules in Spreadsheet page.

  2. In the Rule templates section, select the required workflow.

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

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

  5. On the Manage Rules in Spreadsheet page, select the required workflow in the Rule Templates section.

  6. Click Upload. The Upload File dialog box appears.

  7. In the File field, click Choose File.

  8. From your local directory, select the compressed rule file to be uploaded for the rule creation that was generated from the workflow rules template.

  9. Click Submit. A confirmation message stating the process ID appears.

  10. Click OK.

  11. Check the status of the upload in the Upload History section.

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

Workflow Rule Templates for Journal Approval

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

  • Journal Approval Basic Template

  • Journal Approval Sample Template 1

  • Journal Approval Sample Template 2

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

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

Journal Approval Basic Template: Supervisory Hierarchy-Based Approval

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

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

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

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

Tip: You can upload this sample rule to reset the journal approval rule back to its predefined state.
Journal Approval Sample Template 1: Group-Based Approval

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

  • All journal batches from a specific ledger and from the specific journal sources require approval from one user of the nominated approval groups. The approval group is different when the journal batch has been created by some nominated users and has some specific description.

  • Journal batches from sources other than these sources are automatically rejected.

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

To use these rules, ensure:

  • The approval groups that you enter in the spreadsheet are defined in the approval management application.

  • The specified users are valid.

  • The specified ledger ID is valid.

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

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

  • First block: All journal batches for journal sources Manual, AutoCopy, and Spreadsheet, and with a total batch amount greater than 250000, require supervisory approval. Any batch from those same sources with a total batch amount up to 250000 is automatically approved. Journal batches from sources other than these sources don't require this type of approval.

  • Second block: All journal batches with a total batch amount up to 250000 for journal sources Allocations, Revaluation, and Balance Transfer, require approval from any one member of the designated approval group. All journal batches with a total batch amount up to 250000 for journal sources other than these sources don't require this type of approval. All journal batches with a total batch amount greater than 250000 don't require this type of approval.

  • Third block: All journal batches with a total batch amount greater than 250000 for the journal sources Allocations, Revaluation, and Balance Transfer, require approval from all members of the designated approval group. All journal batches with a total batch amount greater than 250000 for journal sources other than these sources don't require this type of approval. All journal batches with a total batch amount up to 250000 don't require this type of approval.

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

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

Rule Name Approval Routing Approval Condition Attribute Approval Condition Operator

Source_amount up to 250000

Auto Approve

Journal Batch Total Accounted Credit

<=250000

Journal Source Name

in (Manual, AutoCopy, Spreadsheet)

Source_amount up to 250000_other source

Skip Approval

Journal Batch Total Accounted Credit

<=250000

Journal Source Name

not in (Manual, AutoCopy, Spreadsheet)

Source_amount greater than 250000

Supervisory

Journal Batch Total Accounted Credit

>250000

Journal Source Name

in (Manual, AutoCopy, Spreadsheet)

Source_amount greater than 250000_other source

Skip Approval

Journal Batch Total Accounted Credit

>250000

Journal Source Name

not in (Manual, AutoCopy, Spreadsheet)

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

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

Approval Conditions in Journal Approval Rule Templates

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

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

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

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

  • Journal Batch Approval Requester

  • Journal Batch Creator

  • Journal Batch Ledger

  • Journal Batch Source

  • Journal Category

  • Journal Calendar

  • Journal Header

  • Journal Line

  • Maximum Amount Journal

  • Maximum Amount Journal Line

  • Period

  • Submitted Period

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

Rule Evaluation Currency Attribute

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

  • Journal Header

  • Journal Line

  • Maximum Amount Journal

  • Maximum Amount Journal Line

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

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

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

  2. Select Financials. The Business Process Management Worklist application page opens.

  3. Click your user name and select Administration. You can manage the journal approval rules only if you have administrator access.

  4. Click the Task Configuration tab.

  5. From the Tasks to be configured pane, select the FinGLJournalApproval task.

  6. Click Edit task to create the rules.

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

  8. On the Supervisory Journal Approver participant, click Go to rule.

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

  10. Click the Show Advanced Settings icon.

  11. Click in the Active check box to deselect it. When this check box is cleared, the approval routing process doesn't use the rule.

  12. Click the Add Rule icon.

  13. In the Name field, enter the name of the rule: Between 500 and 10000.

  14. 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.
  15. In the IF section, click the Left Value icon. The Condition Browser window opens.

  16. Click the Expand icon on the Maximum Amount Journal folder.

  17. Click the Name attribute, which represents the ledger name.

  18. Click OK. The Condition Browser window closes and the attribute name is populated in the Left Value field.

  19. 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.
  20. Click the Add simple test icon from the list to add another condition.

  21. Click the Left Value icon. The Condition Browser window opens.

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

  23. Click OK. The Condition Browser window closes.

  24. In the second condition, click in the Operator field and select the operator named between.

  25. Click the Right Value icon. The Right Operand window opens.

  26. In the Operand 1 field, enter the lower limit as 500.

  27. In the Operand 2 field, enter the upper limit as 10000.

  28. Click OK. The Right Operand window closes.

  29. To configure the action to send the journal batch for one level of supervisory approval, click the Add Action icon in the THEN section.

  30. 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.
  31. To route the journal batch for one level of supervisory approval, in the Number of levels field, enter 1.

  32. In the Starting Participant field, click Search. The Add Hierarchy Participant window opens and the Get Manager option is selected by default.

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

  34. Click OK. The Add Hierarchy Participant window closes.

  35. 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.
  36. Click the Get User button.

  37. In the Reference User field, enter the sign in name of the top participant within quotation marks.

  38. Click OK. The Add Hierarchy Participant window closes.

  39. From the Tasks to be configured pane, click Save. The Enter Comments window opens.

  40. Click OK. The Enter Comments window closes and a message appears stating that the rule has been saved.

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

  1. Click the Assignees tab.

  2. Select the first rule.

  3. Click the list on the Cut icon and select Copy.

  4. Click the list on the Cut icon and select Paste. The second rule appears after the first rule.

  5. In the Name field for the second rule, enter Greater than 10000.

  6. Click Expand.

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

  8. In the Right Value field, enter 10000.

  9. In the THEN section, in the Number of levels field, enter 2.

  10. Click Collapse. The second approval rule is complete.

Create a Rule That Automatically Approves Journals

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

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

  2. Click the list on the Cut icon and select Copy.

  3. Click the list on the Cut icon and select Paste. The third rule appears after the first rule.

  4. Click in the Rule Name field and rename the third rule to Less than 500.

  5. Click the Expand icon to open the new rule.

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

  7. Click the Surround selected tests with parenthesis icon. Both conditions are now enclosed within a set of parentheses.

  8. Click in the Operator field of the second condition and select same or less than from the list. The amount automatically changes to 500.

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

  10. Since this new condition is mutually exclusive to the grouped conditions, click the connector to change it from and to or.

  11. Click the Left Value icon. The Condition Browser window opens.

  12. Expand the Maximum Journal Amount folder and select Name.

  13. Click OK. The Condition Browser window closes.

  14. Click in the Operator field and select the operator named isn't.

  15. In the Right Value field, enter the name of the ledger in quotation marks.

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

  17. In the Auto Action field, enter "APPROVE". Include the quotation marks.

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

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

  20. Click OK. The Enter Comments window closes and a message appears stating that the data rule has been saved and committed.

  21. Click OK.

After journal approval is enabled, journal batches being posted are submitted for approval based on these 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.

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.

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.

Chart of Accounts Code

The chart of account structure code used to record transactions and maintain account balances.

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.

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, for example User, Spot, and 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, for example User, Spot, and Corporate.

Detail Posting Allowed

Indicator for whether the account allows posting. Valid values are Y and N.

Account Enabled

Indicator for whether the account is available for use.

Account End Date

The date when the account becomes inactive.

Financial Category

Group assigned to a Natural Account segment value. Used for reporting with Oracle Transactional Business Intelligence. A list of accepted values is defined in the FINANCIAL_CATEGORY lookup type.

Reconciliation Enabled Account

Indicator assigned to a Natural Account segment value for whether the account is enabled for reconciliation. Valid values are Y and N.

Control Account

Setting assigned to a Natural Account segment value for maintaining detailed balances by third party. Valid values are CUSTOMER, N, R, SUPPLIER, and Y, representing the following respective controls: Customer Control Account, No, Restricted GL Manual Journals, Supplier Control Account, and Third-Party Control Account.

Account Start Date

The date when the account becomes active.

Account Segments 1 through 30

Value of a segment in the account combination.

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

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

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

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

Name (Ledger) Maximum Accounted Amount Debit Maximum Accounted Amount Credit

USA

700

700

France

900

900

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

Maximum Amount Journal Line

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

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

Journal Ledger Ledger Currency Journal Line Number Accounted Debit Accounted Credit

1

USA

USD

1

400

1

USA

USD

2

100

1

USA

USD

3

400

1

USA

USD

4

100

2

France

EUR

1

200

2

France

EUR

2

300

2

France

EUR

3

200

2

France

EUR

4

300

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

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

Ledger Name Maximum Accounted Line Amount Debit Maximum Accounted Line Amount Credit

USA

400

400

France

300

300

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

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 product that has configurable notifications, along with its associated feature. You can configure only the email notifications.

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

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

Advanced Collections

Configurable Collections Activity Management Notification

Collections Activity Management

ActivityManagement

Budgetary Control

Budgetary Control Override Email Notifications

Budget Override Request Notification Budget

OverrideNotificationFyi

Budgetary Control

Budgetary Control Override Email Notifications

Override Taken Notification

OverrideNotificationFyi

Cash Management

Configurable Cash Management Workflow Notifications

Bank Transfer Approval Notification

BankAcctTransferRequestForAction

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

Receivables

Configurable Receivables Credit Memo Request Manual Entry Workflow Notification

Credit Memo Request Manual Entry Notification

FinArTrxnsCreditMemosManualEntryRequestForAction

Process Overview

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

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

BI Publisher objects, including data model, subtemplate,
style template, layout template, and report, working together to generate
HTML output for workflow notifications.
  • Data Sources: Store the attributes and attribute values for business objects and transactions in the application (example of data sources being transaction tables)

  • Data Model: Determines which attributes from data sources are available to be included in the notification and how that data is retrieved

  • Subtemplate: Provides common components, such as a branding logo and buttons, that can be reused in multiple reports.

  • Style Template: Provides styles such as the type of lines and fonts to use in tables, or the font type, size, and color to use for headings

  • Report: Contains a layout template that determines:

    • Which attributes appear in the notification, from the data model used for the report

    • What the notification looks like, leveraging components from the subtemplate and styles from the style template used for the report

  • HTML: Format of the output generated by the report

  • Email Notification: Has the HTML output embedded in the email body

  • In-App Notification: Has the HTML output embedded in the application UI

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

Notification Modifications

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

  1. Find a predefined report for expense approval in the BI catalog.

  2. Use the Customize option to create a copy, or copy the report and paste it within the Custom folder.

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

Setup

You can opt out of BI Publisher-based notifications from the Features Overview page. To reenable them, follow these steps:

  1. In the Setup and Maintenance work area, go to the following:

    • Offering: Financials

    • Functional Area: The applicable functional area

    • Feature: The applicable configurable workflow notifications feature

    • Choices: The specific notifications you want to enable

  2. Click Done.

Note: You can't opt out of the User Registrations Notifications or Manual Credit Memo Request Notification features.

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.

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

Create Profile Options to Control the Refresh

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

Scope Profile Option Code Examples

Global

BIP_CLIENT_REFRESH_TIME

BIP_CLIENT_REFRESH_TIME

Product Family

BIP_CLIENT_REFRESH_TIME_<FAMILY>

  • BIP_CLIENT_REFRESH_TIME_FIN

  • BIP_CLIENT_REFRESH_TIME_HCM

  • BIP_CLIENT_REFRESH_TIME_PRC

  • BIP_CLIENT_REFRESH_TIME_PRJ

  • BIP_CLIENT_REFRESH_TIME_SCM

Product

BIP_CLIENT_REFRESH_TIME_<FAMILY>_<PRODUCT>

  • BIP_CLIENT_REFRESH_TIME_FIN_AP

  • BIP_CLIENT_REFRESH_TIME_HCM_PER

  • BIP_CLIENT_REFRESH_TIME_PRC_PON

  • BIP_CLIENT_REFRESH_TIME_PRJ_PJE

  • BIP_CLIENT_REFRESH_TIME_SCM_EGO

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

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

Now you're ready to create your profile options!

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

  2. On the Manage Applications Core Profile Options page, click the New icon.

  3. On the Create Profile Option page, enter the profile option code in the format that corresponds to the scope you want.

  4. Enter a display name that you can easily remember to help you find the profile option later.

  5. From the Application list, select Oracle Middleware Extensions for Applications.

  6. From the Module list, select Application Core.

  7. Specify a start date.

  8. Click Save and Close.

  9. On the Manage Applications Core Profile Options page, make sure your new profile option is selected in the Search Results: Profile Options subsection.

  10. In the <Profile Option>: Profile Option Levels subsection, select the Enabled and Updatable check boxes for the Site level.

  11. Save your work.

Set the Refresh Interval

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

Caution: Make sure to enter a whole number.

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

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:

  1. Downloading the report layout template.

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

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

  4. Editing the report layout template.

  5. Previewing the modified notification.

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

  1. To edit the report layout template, download and install Template Builder for Word, which is an extension to Microsoft Word.

    1. Sign in to the application with the application consultant job role.

    2. In the Reports and Analytics work area, click the Browse Catalog button.

    3. Click the Home link.

    4. In the Get Started section, click the Download BI Desktop Tools link.

    5. Select Template Builder for Word from the list.

    6. Save the file and run the installer.

  2. To preview the notification output for your modified report layout template, you must first download a copy of the Workflow Notification Subtemplate.

    1. Click the Catalog link on the Oracle Business Intelligence home page and expand the Shared Folders > Common Content > Templates folder.

    2. Click the Edit link for the Workflow Notification Subtemplate. The subtemplate page opens.

    3. In the Templates section, click the language name link in the Locale column.

    4. Save the subtemplate .rtf file to your computer.

  3. The predefined data model displays the account combination, which is based on segment values, on the journal approval notification. To display a combination of segment values and descriptions on the notification, identify the segment codes for all of the chart of account segments. The segment codes are used in the task Copying and Modifying the Data Model.

    1. In the Setup and Maintenance work area, go to the following:

      • Offering: Financials

      • Functional Area: Financial Reporting Structures

      • Task: Manage Chart of Accounts Structure

    2. Search for the Accounting Flexfield and click Manage Structures to open the Manage Key Flexfield Structures page.

    3. Search for your chart of accounts and click Edit in the Search Results section.

    4. Find the segment code values for all of the segments in the Segment Code column. In this example, the segment codes are VF_Company, VF_Cost_Center, VF_Account, and VF_Product.

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

  2. Click the Catalog link to open the Catalog page.

  3. In the Folders pane, expand the Shared Folders > Financials > Workflow Notifications > General Ledger folder.

  4. Click the Journals folder to display the Data Models subfolder and the Journal Approval Report.

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

  6. Click the Edit link on the copy of the Journal Approval Notification report layout template.

  7. 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.
  1. To copy the data model:

    1. Click the Catalog link on the Oracle Business Intelligence home page to open the Catalog page.

    2. In the Folders pane, expand the Shared Folders > Financials > Workflow Notifications > General Ledger folder.

    3. Click the Journals folder to display the Data Models subfolder and the Journal Approval Report.

    4. In the Folders pane, click the Data Models subfolder to select it.

    5. In the toolbar, click the Copy Resource button.

    6. In the Folders pane, expand the Shared Folders > Custom > Financials > Workflow Notifications > General Ledger folder.

    7. Click the Journals folder to select it.

    8. In the toolbar click the Paste Resource button to create a copy of the Data Models folder.

      Note: The Journal Approval Report is automatically redirected to use the copy of the data model in the Custom folder.

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

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

    2. Replace the Segment_code value in each statement with the segment codes from your chart of accounts.

    3. Replace the Segment_Val or Segment_Desc values at the end of each statement with a user-defined term for that segment.

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

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

    Segment Name Segment Code SQL Statement

    Company

    VF_Company

    FUN_BIP_UTIL_PKG.get_seg_value_from_code(lines.CODE_COMBINATION_ID,'VF_Company') as Company_Value,

    Cost Center

    VF_Cost_Center

    FUN_BIP_UTIL_PKG.get_seg_description_from_code(lines.CODE_COMBINATION_ID,'VF_Cost_Center') as CostC_Desc,

    Account

    VF_Account

    FUN_BIP_UTIL_PKG.get_seg_description_from_code(lines.CODE_COMBINATION_ID,'VF_Account') as Account_Desc,

    Product

    VF_Product

    FUN_BIP_UTIL_PKG.get_seg_value_from_code(lines.CODE_COMBINATION_ID,'VF_Product') as Product_Value,

  3. To edit the copy of the data model:

    1. Find your copy of the data model by expanding the Shared Folders > Custom > Financials > Workflow Notifications > General Ledger > Journals > Data Models folder.

    2. Click the Edit button for the Journal Approval Data Model copy. The Journal Approval Data Model page opens.

    3. In the Data Model pane, in the Data Sets folder, click the Journal Lines data set.

    4. On the Diagram tab, click the Edit Selected Data Set button. The Edit Data Set - Journal Lines dialog box opens with the SQL query for the Journal Lines data set.

      The following figure shows the Edit Data Set - Journal Lines dialog box with the predefined SQL query.

      This figure shows the Edit Data Set - Journal Lines
dialog box with fields for Name, Data Source, Type of SQL, and SQL
Query.
    5. In the SQL Query field, place your cursor after SELECT and insert rows for the new SQL statements.

    6. Copy the SQL statements that you prepared in step 2 into the SQL query field after the word SELECT and before the lines.JE_HEADER_ID HDR_ID.

      The following figure shows the Edit Data Set - Journal Lines dialog box with the new SQL statements.

      This figure shows the Edit Data Set - Journal Lines
dialog box with fields for the Name, Data Source, Type of SQL, and
SQL Query. The SQL Query field includes the statements constructed
in step 2 of this task.
    7. Click OK to close the Edit Data Set - Journal Lines dialog box.

    8. Click the Save button to save the modified copy of the data model.

Exporting the Data Model

To add fields from the data model to your copy of the report layout template, you must first export the modified data model .xml file.
  1. Click the Catalog link on the Oracle Business Intelligence page to open the Catalog page.

  2. In the Folders pane, expand the Shared Folders > Custom > Financials > Workflow Notifications > General Ledger > Journals folder.

  3. Click the Data Models folder to display the modified Journal Approval Data Model.

  4. Click the Edit link for the data model. The data model page opens on the Diagram tab.

  5. Click the Data tab.

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

  7. To include empty fields in the data model export, click the Properties link in the Data Model pane.

  8. On the Properties page, select the Include Empty Tags for Null Elements option.

  9. Click Save.

  10. In the Data Model pane, click the Data Sets link to return to the Data tab.

  11. Click the View button to view the sample data.

  12. Click the Export button and save the Journal Approval Data Model .xml file to a local drive.

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

  14. 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.
  1. To append the fiscal year to the notification header:

    1. Open your local copy of the report layout template using Microsoft Word.

    2. Place your cursor at the end of the default header text, which is Journal Batch Approval.

    3. Add a space and enter the text Fiscal Year 2017 - 2018. The header now says Journal Batch Approval Fiscal Year 2017 - 2018.

      The following figure shows the modified notification header.

      This figure shows the header portion of the report
layout template with the text Fiscal Year 2017 - 2018 appended after
the Batch Approval text.

  2. To add the name of the user who created the journal batch to the notification:

    1. Select the BI Publisher tab to open the BI Publisher ribbon.

    2. In the Load Data group on the ribbon, click Sample XML.

    3. On the XML data selection dialog box, select the .xml file that you saved in step 11 of the task Exporting the Data Model. Click Open.

    4. Click OK on the message that appears indicating that the data was successfully loaded.

    5. In the header section of the report layout template, place your cursor at the end of the BATCH_SOURCE field, and insert a new line.

    6. Enter the text label for the new field, such as Batch Created By, and then add a space.

    7. In the Insert group on the BI Publisher ribbon, click the Field button. The Field dialog box opens with a list of the data model fields.

    8. In the JOURNAL_BATCH folder, select the BATCH_CREATOR field and click Insert. The field is automatically added to the header section after the new text label.

    9. On the Field dialog box, click Close.

      The following figure shows the modified notification header.

      This figure shows the header portion of the report
layout template with the Batch Created By text followed by the BATCH_CREATOR
field. The BATCH_CREATOR field was inserted from the data model.

  3. To replace the account combination ID fields on the report layout template with the segment values and descriptions that were added to the data model:

    1. Place your cursor after the label called StrtLineLINE_ACCOUNTEC and insert a new line.

    2. In the Insert group on the BI Publisher ribbon, click the Field button. The Field dialog box opens with a list of the data model fields.

    3. In the Journal Lines folder, select the COMPANY_VALUE field. The name for this field is the user-defined name for the company segment from the task Copying and Modifying Data Model.

    4. Click Insert to add the field to the report layout template.

    5. In the report layout template, add a character such as a hyphen, to separate the segments.

    6. Select the rest of the segments from the Field dialog box and insert them into the report layout template with a separator between each segment.

      The following figure shows the modified notification with the account segments.

      This figure shows the modified report layout template
with all of the segments separated by a hyphen: COMPANY_VALUE-COSTC_DESC-ACCOUNT_DESC-PRODUCT_VALUE.
    7. Format the segments that were added by copying the format from the CLINE_ACCOUNTEC field in the report layout template. Click the CLINE_ACCOUNTEC field.

    8. Click the Home ribbon, select the Format Painter button, and select the segments that were added. For example, select COMPANY_VALUE-COSTC_DESC-ACCOUNT_DESC-PRODUCT_VALUE.

    9. Place your cursor after the CLINE_ACCOUNTEC field and insert a new line.

    10. Copy the account line that you created in the previous steps of this section and paste it into the new line.

      The following figure shows the modified notification with the account segments appearing after both the

      StrtLineLINE_ACCOUNTEC and the CLINE_ACCOUNTEC fields.

    This figure shows the modified report layout template
with all of the segments separated by a hyphen: COMPANY_VALUE-COSTC_DESC-ACCOUNT_DESC-PRODUCT_VALUE
after the CLINE_ACCOUNTEC field.
  4. Delete the fields StrtLineLINE_ACCOUNTEC and CLINE_ACCOUNTEC from the report layout template.

  5. 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.
    1. 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.

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

      This figure shows an example of the notification
with the account number.

    3. If the preview reflects your changes as expected, then change the subtemplate path in the .rtf file back to the original location.

    4. In the Tools group on the BI Publisher ribbon, click Validate Template.

    5. Save the modified report layout template.

    Uploading the Modified Report Layout Template

    To use the modified report layout template for future journal approval notifications:
    1. Click the Catalog link on the Oracle Business Intelligence home page to open the Catalog page.

    2. In the Folders pane, expand the Shared Folders > Custom > Financials > Workflow Notifications > General Ledger folder.

    3. Select the Journals folder to display the Data Models folder and the Journal Approval Report.

    4. Click the Edit link for the Journal Approval Report to open the Journal Approval Report page.

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

    6. Click the Create button. A page opens with a Create Layout section and an Upload or Generate Layout section.

    7. In the Upload or Generate Layout section, click the Upload button. The Upload Template File dialog box opens.

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

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

    10. Click the View a list link to return to the Layout page with the list of the report layout templates.

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

    12. Click the Save button to save the change to the default layout.

    AutoPost

    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

    1. Go to the following:

      • Offering: Financials

      • Functional Area: General Ledger

      • Task: Manage AutoPost Criteria Sets

    2. Click Create.

    3. Enter this name: All Journal Imported Entries.

    4. Enter this description: Posting journals imported from the subledgers.

    5. Select Enabled.

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

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

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

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

    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

    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.

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

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

    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

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

    Here are the key areas to understand when reversing journals:

    • Reversal Settings on Journals

    • Manual Journal Reversal

    • Journal Reversal Criteria Sets

    • Automatic Journal Reversal

    • Reversal Synchronization Between a Primary Ledger and Its Secondary Ledgers

    Reversal Settings on Journals

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

    • Reversal Period: Accounting period for the resulting reversal journal. Required for reversal.

    • Reversal Date: Applicable only to average daily balance ledgers. Accounting date to be applied to the reversed journal, since that's needed for calculating average balances. For ledgers that aren't average daily balance ledgers, default logic is applied to determine the accounting date for the generated reversal.

    • Reversal Method: Method for reversing amounts in the reversal journal. Select from Change Sign or Switch Debit or Credit. The default setting is Switch Debit or Credit. The Change Sign setting means the reversal puts the original journal amount in the same Debit or Credit column, but with the opposite (negative or positive) sign. The Switch Debit or Credit setting means the amount is moved to the other column. Required for reversal.

    • Reversal Status: View-only state of the journal reversal. For example, Not reversed or Reversed.

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

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

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

    Manual Journal Reversal

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

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

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

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

    Scenario How It Works

    You want to reverse all of the journals in a batch that aren't yet reversed, using the same reversal settings. For example, using the same reversal period for ledgers that aren't enabled for average balances, or the same reversal period and date for ledgers that are enabled for average balances. Or, you want to use the same reversal method.

    When you select the reverse batch action, the Reverse Journal Batch window opens. You provide the reversal period, date, or method. The information you enter overrides any reversal settings at the journal level of journals that aren't yet reversed. All journals eligible for reversal are reversed according to what you specified on the Reverse Journal Batch window.

    You specified reversal settings for every journal that's not yet reversed in a batch, and you want to process reversals more efficiently using batch reversal.

    Leave the fields blank on the Reverse Journal Batch window. Each of these journals is reversed according to the journal's reversal settings.

    You specified reversal settings for some, but not all, of the journals that aren't yet reversed in a batch, and you want to process reversals more efficiently using batch reversal.

    Use the Manage Journals page to reverse the batch. Leave the fields blank on the Reverse Journal Batch window. Each of these journals is reversed according to the journal's reversal settings.

    You want to reverse multiple journals from different batches using the reversal settings specified on each journal in these batches.

    Use the Manage Journals page to select the rows for the batches and then select the reverse batch action. Each journal that's eligible for reversal in these batches is reversed according to the journal's reversal settings.

    Journal Reversal Criteria Sets

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

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

    • Offering: Financials

    • Functional Area: General Ledger

    • Task: Manage Journal Reversal Criteria Sets

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

    Setting Values Description

    Reversal Period

    No Default, Same Period, Next Period, Next Nonadjusting Period, Next Day, Same Day

    Accounting period for the resulting reversal journal. The following values apply only to average balance ledgers: Next Day, Same Day. Selecting those values for a ledger that isn't an average balance ledger is the same as selecting the value No Default.

    Reversal Date

    First Day, Next Day, Last Day

    Day of the accounting period when the journal is to be reversed. A reversal date only applies to average balance ledgers. You must specify a reversal date if you select the following values for the reversal period: Next Nonadjusting Period, Next Period, Same Period.

    Reversal Method

    Change Sign, Switch Debit or Credit

    Method for reversing amounts in the reversal journal.

    Automatic Reversal Option

    None, Reverse Automatically, Reverse and Post Automatically

    Setting that determines whether a journal is selected for automatic reversal, and whether the reversal journal is posted after it's reversed. Unlike the previous settings in this table, which are propagated directly as attributes in the journal, this setting is used to determine the reversal action that's applied when the automatic reversal process is run.

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

    • Offering: Financials

    • Functional Area: General Ledger

    • Task: Specify Ledger Options, with the ledger scope set

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

    Automatic Journal Reversal

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

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

    • Select the Run AutoReverse task from the tasks pane in the Journals work area. The task opens the Scheduled Process page for the AutoReverse Journals process. You might want to run automatic reversals this way for one-time accruals entered in the current period, but tagged to reverse in a later period.

    • Submit or schedule the AutoReverse Journals process on the Scheduled Processes page.

    • Enable the ledger option Run AutoReverse After Open Period on the Specify Ledger Options page. When enabled, the automatic reversal process is submitted with the reversal period choice of All.

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

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

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

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

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

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

    • If the automatic reversal option on the applicable journal reversal criteria set is set to:

      • Reverse and Post Automatically and journal approval is enabled, journals posted by the process bypass approval.

      • Reverse Automatically, you must manually post the reversal journals.

    • If you have an average balance ledger, the automatic reversal process doesn't check that the reversal date is a valid business day. However, the journal validation in the journal pages and the import process perform this check and, if necessary, roll the date to the next business day.

    Reversal Synchronization Between a Primary Ledger and Its Secondary Ledgers

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

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

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

    • You enabled journal approval in both the primary and secondary ledger.

    • You enabled reversal synchronization between the two ledgers.

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

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

    How was the journal that's going to be reversed created in the secondary ledger? Did you assign a journal reversal criteria set to the secondary ledger? How is the journal reversed in the secondary ledger?

    The journal was replicated from the primary ledger.

    Yes

    The journal is reversed automatically when the journal in the primary ledger is reversed. The reversal settings in the primary ledger source journal override any reversal settings on the journal in the secondary ledger that's being reversed.

    Note: Because the journal was replicated from the primary ledger, the journal reversal criteria set has no impact on the reversal.

    The journal was created directly in the secondary ledger.

    Yes

    If the journal category is set for automatic reversal in the secondary ledger's assigned criteria set, you can run the automatic reversal process in the secondary ledger. Otherwise, you must reverse the journal manually.

    The journal was replicated from the primary ledger.

    No

    The journal is reversed automatically when the journal in the primary ledger is reversed.

    The journal was created directly in the secondary ledger.

    No

    You must specify reversal information in the journal and manually reverse the journal in the secondary ledger.

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

    • Offering: Financials

    • Functional Area: General Ledger

    • Task: Complete Primary to Secondary Ledger Mapping, with the primary ledger and secondary ledger scope set

    FAQs for Manage Journal Reversals

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

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

    Criteria Eligible for Manual Reversal? Eligible for Automatic Reversal?

    The journal has a balance type of Actual.

    Yes

    Yes

    The journal has a balance type of Encumbrance.

    Yes

    No

    The journal is posted and not yet reversed.

    Yes

    Yes

    The reversal period is open or future enterable.

    Yes

    Yes

    The journal isn't a reversal journal.

    Note: Reversal journals can't be reversed.

    Yes

    Yes

    The journal category is enabled for automatic reversal.

    N/A

    Yes

    The journal source for the posted journal isn't frozen.

    Yes

    Yes, however, this only applies to posted journals that originate from Oracle Fusion Subledger Accounting whose journal source isn't frozen. Posted journals that originate from a source other than Oracle Fusion Subledger Accounting are eligible for automatic reversal, regardless of the Freeze Journals setting.

    The journal isn't a posted journal for a reporting currency that was replicated from its source ledger.

    Note: Reporting currency journals that were replicated from a source ledger are reversed when the source journal is reversed.

    Yes

    Yes

    Where a secondary ledger is involved, the corresponding journals for the primary and secondary journals are both posted.

    Yes

    Yes

    If using the Clearing Accounts Reconciliation feature, the posted journal doesn't include reconciliation lines for clearing accounts.

    Yes

    Yes

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

    Lookups

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

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

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

    Lookup Code Meaning Tag

    M

    Married

    Not applicable

    S

    Single

    Not applicable

    R

    Registered Partner

    +NL

    DP

    Domestic Partner

    -FR, AU

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

    When managing lookups, you need to understand the following.

    • Using lookups in applications

    • Configuration levels

    • Accessing lookups

    • Enabling lookups

    • The three kinds of lookups: standard, common, and set-enabled

    Using Lookups in Applications

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

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

    Configuration Level

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

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

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

    Permitted Task User Extensible System

    Deleting a lookup type

    Yes

    No

    No

    Inserting new codes

    Yes

    Yes

    No

    Updating start date, end date, and enabling the lookup code

    Yes

    Yes, only if the code isn't predefined data

    No

    Deleting codes

    Yes

    Yes, only if the code isn't predefined data

    No

    Updating tags

    Yes

    No

    No

    Updating module

    Yes

    No

    No

    Predefined data means LAST_UPDATED_BY = SEED_DATA_FROM_APPLICATION.

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

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

    Access to the REST Resources

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

    • standardLookupsLOV

    • commonLookupsLOV

    • setEnabledLookupsLOV

    • genericLookupsLOV

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

    • Anonymous: Lookup is available to a user having anonymous role or authenticated role.

    • Authenticated: Lookup is available to a user having only the authenticated role.

    • Secure: Lookup isn't available to users as part of the generic resource. To make it available securely, you must create a specific resource, assign it to a role, and assign that role to select users.

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

    Standard, Common, and Set-Enabled Lookups

    The following table shows the available types of lookups.

    Lookup Type Description

    Standard

    Lists the available codes and translated meanings.

    Set-enabled

    Associates a reference data set with the lookup codes.

    Common

    Legacy lookups or lookups that have attributes.

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

    Accessing Lookups

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

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

    Enabling Lookups

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

    Enable lookups based on the following.

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

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

    • Manage Standard Lookups

    • Manage Common Lookups

    • Manage Set-Enabled Lookups

    Translating Lookups

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

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

    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.

    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

    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.

    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.

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

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

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

    List of values

    Static

    Dynamic if the list is table-validated

    Validation of values

    One to one match of meaning to code included in a lookup view, or through the determinant of a reference data set

    Validation by format or inclusion in a table

    Format type of values

    char

    varchar2, number, and so on

    Length of value

    Text string up to 30 characters

    Any type of variable length from 1 to 4000

    Duplication of values

    Never. Values are unique.

    Duplicate values allowed

    Management

    Both administrators and end-users manage these, except system lookups or predefined lookups at the system configuration level, which can't be modified.

    Usually administrators maintain these, except some product flexfield codes, such as GL for Oracle Fusion General Ledger that the end-users maintain.

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

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

    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.

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

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

    3. Click a lookup type to view its lookup codes.

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

    Descriptive Flexfields

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

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

    Context

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

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

    • ATTRIBUTE1 column for height

    • ATTRIBUTE2 column for width

    • ATTRIBUTE3 column for depth

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

    • ATTRIBUTE1 column for weight

    • ATTRIBUTE2 column for volume

    • ATTRIBUTE3 column for density

    Segments and Contexts

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

    Segment Type Run Time Appearance

    Global segment

    Always available

    Context segment

    Determines which context-sensitive segments are displayed

    Context-sensitive segment

    Displayed depending on the value of the context segment

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

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

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

    • Attributes to add using the available segments

    • Context values

    • The combination of attributes in each context

    Value Sets

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

    Protected Descriptive Flexfield Data

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

    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:

    1. Identify existing parameters.

    2. Identify existing context values and whether the context value is derived.

    3. Identify user-defined attributes and plan the descriptive flexfield segments, segment properties, and structure.

    4. Plan validation rules.

    5. Plan initial values.

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

    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:

    1. Creating segment labels for business intelligence enabled flexfields.

    2. Configuring global segments by providing identity information, the initial default value, and the display properties.

    3. Configuring the context segment by specifying the prompt, whether the context segment should be displayed, and whether a value is required.

    4. Configuring contexts by specifying a context code, description, and name for each context value, and adding its context-sensitive segments, each of which is configured to include identifying information, the column assignment, the initial default value, and the display properties.

    The following aspects are important in understanding descriptive flexfield management:

    • Segments

    • Adding segments to highlighted descriptive flexfields

    • Usages

    • Parameters

    • Delimiters

    • Initial Values

    • Business Intelligence

    Segments

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

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

    • The value set that you specify for a context segment consists of a set of context codes.

    • Each context code corresponds to a context that's appropriate for the descriptive flexfield.

    • The value set must be independent or table-validated.

    • If table-validated, the WHERE clause must not use the VALUESET.value_set_code or SEGMENT.segment_code bind variables.

    • The value set must be of data type Character with the maximum length of values being stored no larger than the context's column length.

    • If you don't specify a value set for a context segment, the valid values for that context segment are derived from the context codes. The definition of each context segment specifies the set of context-sensitive segments that can be presented when that context code is selected by the end user.

    • For reasons of data integrity, you can't delete an existing context. Instead, you can disable the associated context value in its own value set by setting its end date to a date in the past.

    • You can configure the individual global segments and context-sensitive segments in a descriptive flexfield. These segment types are differentiated by their usage, but they're configured on application pages that use most of the same properties.

    Adding Segments to Highlighted Descriptive Flexfields

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

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

    Display Component Value Set Created Using Add Segment

    Check Box

    Independent

    Drop-down List

    Independent

    List of Values

    Independent

    Radio Button Group

    Independent

    Text Field With Search

    Independent

    Text box

    Format Only

    Text area

    Format Only

    Date/Time

    Format Only

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

    Usages

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

    Parameters

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

    Delimiters

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

    Initial Values

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

    You can use two types of SQL statements:

    • SQL statement with no binding. For example, select MIN(SALARY) from EMPLOYEES.

    • SQL statement with bind variables. You can use these bind variables in the WHERE clause of the SQL statement.

      • :{SEGMENT.<segment_code>}: Identifies a segment in the same context.

      • :{PARAMETER.<parameter_code>}: Identifies a parameter.

      • :{CONTEXT.<context_code>;SEGMENT.<segment_code>}: Identifies a segment in a different context. The context must be in the same category or in an ancestor category, and it can't be a multiple-row context.

      • :{VALUESET.<value_set_code>}: Identifies the closest prior segment in the same context that's assigned to the specified value set.

      • :{FLEXFIELD.<internal_code>}: Identifies a flexfield.

    Business Intelligence

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

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

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

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

    • Flattening business components to use BI-enabled segments in Oracle BI

    • Equalizing segments to prevent duplication and complexity in the flattened component

    • Mapping attributes of flattened business components to logical objects in Oracle BI

    • Managing the labels that map segments to logical objects in Oracle BI

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

    Flattening

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

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

    • If you assigned a label to the segment, the flattened components include an additional single attribute representing segments with that label.

    • If you didn't assign a label, the flattened components include a discrete attribute for each BI-enabled context-sensitive segment in each context.

    Mapping to Logical Objects in Business Intelligence

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

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

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

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

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

    Managing Labels

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

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

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

    Importing to Oracle Business Intelligence Repository

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

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

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

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

    Examples of the descriptive flexfields available are:

    • Oracle Fusion Payables: Invoices

    • Oracle Fusion Receivables: Adjustments

    • Oracle Fusion Expenses: Expense

    • Oracle Fusion Assets: Assets Invoices

    • Intercompany: Intercompany Transaction Headers (Inbound Transaction)

    • Intercompany: Intercompany Transaction Batches (Outbound Transaction)

    • Oracle Fusion General Ledger: Journal Batches

    • Oracle Fusion General Ledger: Journals

    • Oracle Fusion Subledger Accounting: Subledger Journal Entry Header

    Descriptive flexfields consists of segments.

    The following table lists the descriptive flexfield segments.

    Segment Description

    Global Segment

    Are always displayed, if enabled.

    Context Segment

    Used to determine which context sensitive segments are displayed.

    Context Sensitive Segment

    Displayed values based on the defined value in the context segment.

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

    • Global Segments: Generally available in the Add Fields menu if they're not displayed by default. When a Global Segment is added to a Search Panel, it's displayed before the context segments.

    • Context Segments: Generally available in the Advanced Search section by default.

    • Context Sensitive Segments: Available in the Add Fields menu after you select a context segment value.

    • The segments are displayed in the Search Panel in the following order:

      1. Global Segments

      2. Context Segments

      3. Context Sensitive Segments, after their Context Segment

    Note:
    • The list of values on the Add Fields menu lists all descriptive flexfields alphabetically, followed by all other fields alphabetically.

    • If more than one global segment is defined, then all global segments are displayed in the Search panel in the sequence defined by you, the user, followed by context segments.

    • Similarly for context segments, all context segments are displayed in the Search panel in your defined sequence defined order.

    • When context sensitive segments are added to a Search panel, they're also displayed in your defined sequence order.

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

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

    • Journal Batches

    • Journals

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

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

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

    Scenario

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

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

    Configuring General Ledger Descriptive Flexfields

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

    Analysis

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

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

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

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

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

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

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

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

    Deploy each descriptive flexfield after the setup is complete.

    Resulting Prompts During Journal Line Entry

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

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

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

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

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

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

    Profile Options

    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.

    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.

    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

    1. In the Setup and Maintenance work area, go to the Manage Administrator Profile Values task.

    2. On the Manage Administrator Profile Values page, search for and select the profile option.

    3. 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.
    4. Repeat step 3 to add more rows and set the profile values.

    5. Click Save and Close.

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

    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

    1. In the Setup and Maintenance work area, go to the Manage Profile Options task.

    2. On the page, click Actions > New.

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

    4. Click Save and Close.

    5. On the Manage Profile Options page, search for the newly created profile option and from the results, select it.

    6. In the Profile Option Levels section, do the following:

      1. In Enabled, select the levels at which you want to enable the profile option.

        Note: You can enable a profile option at multiple levels, but a higher-level profile value overrides a lower-level value. Therefore, enable them only at the required levels.
      2. In Updatable, select the profile level at which you want implementors to have update privileges. Leave the check box deselected if you don't want the implementors to modify the profile values (they appear in read-only mode).

    7. Click Save and Close.

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

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

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

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

    Managing Profile Categories

    Consider the following options while managing profile categories:

    • Create profile categories and add existing profile options to them

    • Add newly created profile options to existing user-defined profile categories

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

    Setting Display Sequence for the Profile Options

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

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

    Profile Category Included Profile Option - Assigned Display Sequence Display Sequence of Profile Options in the Search Results

    Attachments

    • Attachment File Directory - 2

    • Indicate Attachments - 1

    1. Indicate Attachments

    2. Attachment File Directory

    FAQs for Profile Options

    How can I access predefined profile options?

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

    1. In the Setup and Maintenance work area, go to the Manage Profile Options task.

    2. 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.
    3. Click a profile option to view its details.

    Workflow Transaction Console

    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:

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

    2. On the Edit Enterprise page, click Edit and then select Update.

    3. Complete the fields in the Update Enterprise dialog box and click OK.

    4. In the Transaction Console Information section, select Enable Transaction Security.

    5. Click Submit.

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

    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:

    1. Click Navigator > Tools > Transaction Console.

    2. If you see tabs, make sure you're on the Transaction Summary tab.

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

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

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

    1. Select one or more transactions from the results table.

    2. Optionally use the Priority menu to set an issue priority, so that you can later filter on the priority to find these transactions.

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

    1. Select an issue from the Issues list, if the transaction has more than one issue.

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

    3. Click the Download link to get the diagnostic log.

    4. Use the Issue Priority list to set an issue priority, if you want to later filter on the priority to find this transaction.

    5. From the Assigned To list, select the person who should fix the issue, for tracking and filtering purposes.

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

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

    8. Select another issue from the Issues list, if any, and go through the same process.

    9. Click Save and Close.

    Download a Spreadsheet of Transactions

    This is all you need to do:

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

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

    Processing Schedules

    When you have a nonstandard accounting calendar, you can create a processing schedule that runs processes like Generate General Ledger Allocations using that calendar.

    Here's how you do it:

    1. In the Setup and Maintenance work area, go to the Manage Processing Schedules task:

      • Offering: Financials

      • Functional Area: General Ledger

      • Task: Manage Processing Schedules

    2. On the Manage Processing Schedules page, click the Add Row icon.

    3. Enter a name for the schedule.

    4. Select the accounting calendar.

    5. Accept or change the default settings for Run Day and Time.

    6. Save the schedule.

    Now that you created your schedule, you can select it when scheduling a process on the Scheduled Processes page.