9General Ledger Options

This chapter contains the following:

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

Manage Data Access Sets

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.

You can combine ledger and ledger set assignments in single data access sets if the ledgers share a common chart of accounts and calendar. If you have primary balancing segment values assigned to a legal entity within the ledger, then you can use data access sets to secure access to specific legal entities. You can also secure access to primary balancing segments assigned directly to the ledger.

When a ledger or ledger set is created, a data access set for that ledger or ledger set is automatically created, giving full read and write access to those ledgers. You can also manually create data access sets to give read and write access, or read-only access to entire ledgers or portions of the ledger represented as primary balancing segment values.

The following figure shows that a data access set consists of an access set type and an access level. The access set type can be set to full ledger or primary balancing segment value. The access level can be read only or read and write.

This figure shows the components of a data access set.
A data access set has an access set type and an access level.

The Full Ledger access set type provides access to the entire ledger or ledger set. This could be for read-only access or both read and write access to the entire ledger.

The Primary Balancing Segment Value access set type provides access to one or more primary balancing segment values for that ledger. This access set type security can be specified by parent or detail primary balancing segment values. The specified parent value and all its descendants, including middle level parents and detail values are secured. You can specify read only, read and write access, or combination of both, for different primary balancing segment values for different ledgers and ledger sets.

For more information about security assignments and managing data access for users, see the Securing Oracle ERP Cloud guide.

This example shows a data access set that secures access by using primary balancing segment values that correspond to legal entities.

Scenario

The following figure shows a data access set for the US Financial Services Ledger. The access set type is Primary Balancing Segment Value, with each primary balancing segment value representing different legal entities. Read-only access has been assigned to primary balancing segment value 131, which represents the Insurance legal entity. Read and write access has been assigned to primary balancing segment values 101 and 102, which represent the Banks and Capital legal entities.

For this data access set, the user can:

  • View the journals, balances, and reports for primary balancing segment value 131 for the Insurance legal entity.

  • Create journals and update balances, as well as view journals, balances and reports for primary balancing segment value 101 and 102 for legal entities Banks and Capital.

This figure shows an example of a data access set
with two levels of access.
Note: In financial reporting, the list of ledgers isn't secured by data access sets when viewing a report in Preview mode. Users can view the names of ledgers they don't have privileges to view. However, the data from a secured ledger doesn't appear on the report.

For more information about security assignments and managing data access for users, see the Securing Oracle ERP Cloud guide.

Manage 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

In the Offerings work area, enable the Accounting Automation feature as follows:

  • Offering: Financials

  • Functional Area: General Ledger

  • Feature: Accounting Automation

When you opt in, you're automatically directed to the Manage Accounting Automation page where you can set up the automation. To make changes after the initial setup, use the following 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.

On the Manage Accounting Automation page you:

  • Enable automation for all ledgers (primary, secondary, and reporting currencies with currency conversion levels of Journal or Subledger).

  • Specify when to submit the automation.

  • Specify who should receive the email notification for each accounting automation run. The notification provides a summary of the processed data and a detail listing of all errors.

  • Optionally specify who should receive an email notification for errors generated while processing transactions for a specific combination of ledger (or ledger set) and error category. You can notify more than one user for the same ledger and error category combination. You can also specify a ledger of Any or No Ledger. With this selection, users can be notified of transactions that don't have a ledger associated with them, such as daily rates import, and for scenarios where you want to include all ledgers.

The following table describes each error category.

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.

Note: Accounting automation doesn't submit approval for any type of journal batch. If a journal batch needs approval, it must be submitted for approval manually or through the AutoPost Journals process.

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.

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.

  • 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 specified in the Default User to Notify field on the Manage Accounting Automation page, and the other is for users 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 receives a notification after every accounting automation run with information about the processed data and errors. Here's an example of the email subject for the notification: Accounting Automation Results from 1/2/18 8:00 AM for Your Review.

The other users receive a notification for their assigned primary ledger (or ledger set) and error category, if errors occur. Here's an example of the email subject for the notification: Accounting Automation on 1/2/18 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

The Posted Transactions Summary section displays a summary of the posted balances by ledger. Only the default user receives this summary. If no accounting transactions were successfully posted for any ledger after an accounting automation run, a message displays in place of this section.

The following figure shows an example of a posting summary. In this example, a total of 302 USD was posted to the ledger Vision Operations (USA).

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

The following table describes the columns that display in this section.

Column Description

Ledger

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

Total Amount

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

Currency

The ledger currency.

Automation Errors Summary

The Automation Errors Summary section displays a summary of the errors by ledger and error category. The default user and users who are assigned to the error category that has errors receive this summary.

The following figure shows an example of the errors summary.

In this example, the Vision Operations (USA) ledger has 3 transactions totaling 750 USD with currency conversion errors, and 23 transactions totaling 75,990 USD with period status errors. All of the errors were new for the latest accounting automation run, so the error counts of 3 and 23 appear in the New column. The Users Notified column is blank for both error rows, which indicates that no users were set up to receive notifications for the Vision Operations (USA) ledger and the Currency Conversion and Period Status error categories.

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 six columns:
Ledger, Error Category, Total Amount, Currency, Number of Errors,
and Users Notified. The Number of Errors column heading spans two
columns: Total and New. The table has two rows of sample data.

The following table describes the columns that display in this section.

Column Description

Ledger

The 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

The error category associated with the error.

Total Amount

The sum of the accounted amounts that could not be processed due to the error category for the ledger.

Currency

The ledger currency.

Number of Errors - Total

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

Number of Errors - New

The 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 is always notified. Is blank if no users were set up to receive email notifications for the respective ledger and error category.

Pending Approvals Summary

The Pending Approvals Summary section displays 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 who are assigned the Approval error category receive this summary.

The following figure shows an example of the Pending Approvals Summary section. In this example, the Vision Operations (USA) ledger has two journal batches totaling 24,000 USD that have been pending approval within the last 4 to 7 days.

This figure shows an example of the Pending Approvals
Summary section of an email notification that was 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.

The following table describes the columns that display in this section.

Column Description

Ledger

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

Amount

The sum of the journal batches that are in the approval flow.

Currency

The ledger currency.

Pending Approval Batches: Amount

The 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

The 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

The Automation Errors Details section displays the detailed transactions or journals for the errors reported in the Automation Errors Summary section.

The following figure shows the transactions with the currency conversion errors reported in the Automation Errors Summary section. In this example, all three errors come from subledger transactions. For subledger transactions, the Transaction column provides the name of the subledger application, which in this example is Payables, and includes detail information such as the invoice number and amount. The invoice currency is SGD and the error for all three rows indicates that SGD isn't valid for the accounting date specified on each invoice. Possible corrective actions to resolve the issue are listed in the Error column after the errors. The sum of the accounted amounts is 750 USD, which is the 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.

This figure shows one of the three currency conversion
errors for the Vision Operations (USA) ledger. The table has four
columns: Transaction Type, Transaction, Error, and Amount.

The following table describes the columns that display in this section.

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

Transaction

The 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)

The total of the accounted debits for the transaction.

Pending Approvals Details

The Pending Approvals Details section displays the details for the Pending Approvals Summary section.

Note: Accounting automation doesn't submit approval for any type of journal batch. If a journal batch needs approval, it must be submitted for approval manually or through the AutoPost Journals process.

The following figure provides an example of two journal batches with pending approvals. The approval for one batch was rejected, and the other batch is in the process of being approved. Mary Johnson initiated the approval for both batches and it's been 7 days since the last approval action for both.

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.

The following table describes the columns that display in this section.

Column Description

Journal Batch

The name of the journal batch.

Source

The source of the journal batch.

Initiator

The user who requested the approval.

Status

The approval status of the batch.

Amount (Currency)

The journal batch amount in the ledger currency.

Days Outstanding

The number of days since the last approval action.

FAQs for Manage 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.

Manage 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 is not 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 is 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 do not impact financial results.

You can assign a document sequence number to each business document or business event to uniquely identify it. For example, you can assign a document sequence number to an invoice that gets generated in response to a purchase order. However, you must enable the document sequencing option for that business document or event to start assigning the number. A document sequence number is useful in tracking completed or failed transactions.

You can set up document sequencing in three different modes:

  • Automatic

  • Manual

  • Gapless

Note: Plan your document sequencing carefully before you start applying sequence numbers. Avoid switching to a different mode after you saved your work on the Manage Document Sequences and Manage Document Sequence Categories pages.

Automatic Sequencing

Automatic document sequencing assigns a unique number to each document automatically when the document is generated. That unique number is stored in the database. You can set an initial value for the numbering sequence. Thereafter, the numbering is sequential by date and time of creation. If you don't provide an initial value, the application sets the default initial value as 1.

Manual Sequencing

Use the manual sequencing mode to assign a unique number to each document before the document is generated. In manual sequencing, the numeric ordering and completeness of a transaction is not automatically enforced. As a result, users can skip or omit numbers when entering the sequence value. However, each time a user assigns a number, the application validates its uniqueness.

Gapless Sequencing

Gapless sequencing is similar to automatic sequencing. It automatically generates a unique number for each document, but does that only for successfully generated documents. Sequence numbers are not assigned to incomplete or failed documents. As a result, the sequence is maintained for all the successfully generated documents.

Additionally, you can control the gapless document sequencing by enforcing the Transaction Date Validation option. When enabled, this option checks for the transaction date of a particular document and assigns the sequence number accordingly, to chronologically maintain the documents. The sequence numbers and the transaction dates are chronologically correlated to prevent any mismatch of a new document sequence being assigned to an older document or vice versa.

Note: Use this type of sequencing only if necessary because it may affect the performance of the application and slow down transaction processing.

A document sequence category is a set of documents that share similar characteristics and that are formed into a logical group. Document sequence categories simplify the task of assigning number sequences to specific documents. Instead of assigning a number to each document, you assign a document sequence to one or more document sequence categories. The document sequence category automatically takes care of numbering the documents.

A document sequence category identifies the database table that stores documents resulting from transactions that your users enter. When you assign a sequence to a category, the sequence numbers the documents that are stored in a particular table. You must create document sequence categories to be able to manage the task of assigning document sequences.

Note: Once a document sequence category is created, you can't change the application, the category code, or the table name. Therefore, carefully consider these details and plan your document sequencing requirement before you begin working with the application.

Once you create a document sequence category, it is available for use in the Document Sequences: Assignments section on the Manage Document Sequences page. The Category field contains the name of the document sequence category. After you create a document sequence, you can assign it to a document sequence category.

Document Sequences: Points to Consider

Sequencing documents is an important business and legal requirement. Therefore, you must first decide the appropriate document sequence to use for a set of documents. Before you begin, here are a few prerequisites:

  • Determine beforehand the mode of document sequencing, because you can't switch to other types once a sequence is in use.

  • Note details such as the document sequence and document sequence category, for later reference.

  • Identify if there are any restrictions or configuration prerequisites.

Note: Products that implement document sequencing have specifications about its usage. Refer to the corresponding product documentation for specific details and also to determine if there are any restrictions or configuration prerequisites.

Creating and Editing Document Sequences

You can create document sequences that are automatic, manual, or gapless, depending on the business or legal requirement. By default, the current date is considered as the start date. The sequence definition never expires if you don't provide an end date. Among the several options used in creating and editing document sequences, the following options are functionally more important and therefore must be carefully determined:

  • Determinant Type: Select to limit the document sequencing activity to certain documents that belong to a specific business entity, such as Ledger, Tax Registration, and so on.

  • Initial Value: Enter a value for the first document in your sequence. This field applies only to sequences with automatic or gapless numbering types. Sequence numbers must not be greater than eight digits. If you leave this field blank, the first document is automatically assigned a value of 1. Once a document sequence is defined, you can't change this initial value.

Creating and Editing Document Sequence Categories

Document sequence categories are defined to make it easy to assign document sequence definitions to a group of documents instead of to individual documents. Each document sequence category is mapped to a specific table, where the documents belonging to that category are stored. When specifying the table, you must consider the following points:

  • When the sequential numbering feature checks for completeness or generates a report, it locates the category's documents in the table.

  • Select only those tables that belong to the application associated with the category.

  • Once a category is defined, you can't switch to another table.

Assigning Document Sequences

Identify the documents to be numbered before assigning them a document sequence. For each document sequence, there can be only one active assignment to a document sequence category, and a determinant value (if applicable). As part of the assignment, specify whether the document is created automatically (for example, due to a batch process, or manually through a form). If you don't specify an end date, the assignment continues to remain active throughout the process cycle. If a determinant type was specified for the document sequence, then enter a specific determinant value related to the determinant type.

At run time, when users create documents, the document sequence to be assigned is determined based on the following:

  • An active assignment that matches the correct combination of category

  • The numbering method

  • The date range containing the transaction date

Auditing Document Sequences

You can audit document sequences, if required, to provide an audit trail of the document sequences used in a specific product. However, before enabling the audit functionality for a document sequence, you must have created an audit table for the specific document sequence, using appropriate details. Enabling the audit functionality is permitted only for newly created document sequences. You can't audit document sequences that are already in use by a specific product.

For more information about defining a document sequence audit table, see the Oracle Fusion Applications Developer's Guide.

FAQs for Manage Accounting and Reporting Sequences

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

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

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

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

To define approval management:

  • In the Offerings work area, enable the Approval Routing Administration feature at the offering level so that relevant setup tasks are available.

  • In the Setup and Maintenance work area, use the following setup tasks in the Application Extensions or another functional area.

    • Manage Task Configurations

    • Manage Approval Groups

Task Configuration

Manage rule sets and rules that control approval flows.

Approval Groups

Each approval group includes a set of users that you configure to act on tasks in a certain pattern. Tasks can be defined to get routed to an approval group instead of an individual user.

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.

  • Where you are 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 are 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.

Creating 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 the following steps:

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

  2. Verify if the Approval Routing Administration feature is enabled. If it is not enabled, navigate to the Offerings work area and enable the Approval Routing Administration feature as follows:

    Offering: Financials

    Functional Area: Financials

    Feature: Approval Routing Administration

  3. In the Setup and Maintenance work area, use the following:

    Offering: Financials

    Functional Area: Application Extensions

    Task: Manage Workflow Rules in Spreadsheet

Download the Rules Template

To download the rule template, perform the following 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. The rule template spreadsheet has the following sheets:

  1. Instructions: Provides details of the help topics present on Oracle Help Center for this feature. 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 on 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 the following 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 are not matched to a purchase order must be approved by two levels of the supervisory hierarchy starting from the manager of the user who is creating 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.

To define approval rules, use the Workflow Rules sheet. Enter the details in the following sections:

  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. The following table provides 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 needs to take 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 is not 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, for Payables, in the Invoice Approval template, you can select attributes such as Business Unit and Invoice Amount from the list of values associated with 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. The following table lists the supported operators.

    Condition Value Type Format Example

    Attribute is a specific value

    Text, number, or date

    value

    Note: There is no specific format. You can just enter the value as it is.

    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/08/2018 and 31/08/2019

    OR

    01/08/2018 to 31/08/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/10/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/10/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/10/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/10/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 are not case sensitive. However, you must enter the date in the DD/MM/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 is not 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 where you define a business rule and all aspects of the business rule. 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 allows you to 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 needs to 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 the following steps:

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

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

  3. Depending on the approval routing of the rule for which you are using the data set, enter the value in the Approval Group/Supervisory Level/Job Level Range/User/Role

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

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

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

  7. 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 by prefixing the data set name with $. For example, if you want to reference a data set named Supervisory, then in the workflow Rules sheet, enter the value as $Supervisory Set.

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, you can enter data set references in the following columns:

  • Job Level Range

  • Approval Level

  • Group/User/Role Name

Generate Rule File

After entering the data in the Workflow Rules sheet, click Generate Rule File 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 are 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.

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.

Journal Approval Workflow Rule Templates: Explained

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

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.

Creating Journal Approval Rules Using Oracle Business Process Management

Watch video

Watch: This video tutorial shows you how to create journal approval rules that either automatically approve a journal batch, or that route the batch for supervisory approvals based on the ledger and journal amounts. The content of this video is also covered in text topics.

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 from the list, select More Details.

  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 Journal Approvals 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 has 17 predefined participants. Typically you use only one or two participants, but you have the flexibility 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 Add Rule icon.

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

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

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

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

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

  16. In the Right Value field, enter the name of the ledger in quotation marks, for example, enter "Vision Operations (USA)".

    Note: The first condition uses the operator named is. This operator compares the two values.
  17. Click the Add simple test icon from the list to add another condition.

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

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

  20. Click OK. The Condition Browser window closes.

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

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

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

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

  25. Click OK. The Right Operand window closes.

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

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

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

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

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

  32. 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.
  33. Click the Get User button.

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

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

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

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

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

Predefined Journal Approval Participants and Attributes: Explained

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

  • Offering: Financials

  • Functional Area: Application Extensions

  • Task: Manage Task Configurations for Financials

The name of the journal approval workflow task is FinGlJournalApproval.

Assignees

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

  • Single: Maps to a user, group, or role. Select this type if the approval request requires only a single user to approve. When the request is sent to a group or to an application role, all of the users within that group or that carry that application role receive the notification, but only one user's approval is required.

  • Parallel: Indicates that a set of people work in parallel and that everyone's approval is required. For example, a journal batch affects multiple lines of business and requires approval from the controllers for each line of business. The controllers can approve the journal batch in parallel.

  • Serial: Indicates that a set of users must work in sequence. The most common scenario is supervisory chain approval, which is done by specifying that the list is based on a supervisory chain.

  • FYI: Maps to a single user, group, or role, just as the Single assignee type. However, this type of assignee just receives a notification, and the business process doesn't wait for the assignee's response. FYI assignees can't directly impact the outcome of a task, but in some cases can provide comments or add attachments.

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

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

Attributes

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

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

Name Description

Accounting Period Type

Name of the accounting calendar.

Batch Type Indicator

Indicator for the type of amounts that the batch contains. Valid values are A or E, representing the following respective types: Actual and Encumbrance.

Approval Status

Approval status of the journal batch. Valid values are A, I, J, V, R, or Z, representing the following respective statuses: Approved, In Process, Rejected, Validation Error, Required, and Not Required.

For Oracle internal use only.

Approver Employee ID

Internal identifier of the employee who submitted the batch for approval. For Oracle internal use only.

Average Balance Journal Indicator

Indicator for whether the journal is an average balance journal. Valid values are Y or N, representing Yes and No.

Batch Amount

Amount of the journal batch.

Budgetary Control Status

Not currently used.

Calendar

Reference to the Calendar object. For Oracle internal use only.

Chart of Accounts ID

Internal identifier of the chart of accounts.

Control Total

Control total of the journal batch.

Created By

Sign in name of the user who created the journal batch.

Creation Date and Time

Date and time when the journal batch was created.

Creation Date

Date when the journal batch was created. For Oracle internal use only.

Default Accounting Date

Internal default accounting date. For Oracle internal use only.

Accounting Period Name

Accounting period of the journal batch.

Description

Description of the journal batch.

Earliest Postable Date

For Oracle internal use only.

Group ID

Internal identifier of the interface group. For Oracle internal use only.

Batch ID

Internal identifier of the journal batch. For Oracle internal use only.

Source

Internal identifier of the journal source. For Oracle internal use only.

Journal Batch Ledger

Reference to the Journal Batch Ledger object. For Oracle internal use only.

Journal Batch Source

Reference to the Journal Batch Source object. For Oracle internal use only.

Journal Header

Reference to the Journal Header object. For Oracle internal use only.

Last Updated Date

Date when the journal batch was last updated.

Last Updated Login

For Oracle internal use only.

Last Updated By

Sign in name of the user who last updated the batch.

Lookup Code

For Oracle internal use only.

Lookup Type

For Oracle internal use only.

Maximum Amount Journal

Reference to the Maximum Amount Journal object. For Oracle internal use only.

Maximum Journal Line Amount

Reference to the Maximum Journal Line Amount object. For Oracle internal use only.

Batch Type

Full text value for the Batch Type Indicator attribute. Valid values are Actual or Encumbrance.

Name

Name of the journal batch.

Object Version Number

For Oracle internal use only.

Packet ID

For Oracle internal use only.

Parent Batch ID

For Oracle internal use only.

Period

Reference to the Period object. For Oracle internal use only.

Accounting Period Set Name

Accounting calendar name for the accounting period.

Posted Date

For Oracle internal use only.

Posting Run ID

Internal identifier. For Oracle internal use only.

Request ID

Internal identifier. For Oracle internal use only.

Accounted Running Total Credit

Total accounted credit amount of the journal batch.

Accounting Running Total Debit

Total accounted debit amount of the journal batch.

Entered Running Total Credit

Total entered credit amount of the journal batch.

Entered Running Total Debit

Total entered debit amount of the journal batch.

Status

Status of the journal batch. Valid values are u, U, S, I, or P, representing the following respective statuses: Incomplete, Unposted, Selected for Posting, Processing, and Posted.

Status Verified by Posting Indicator

Indicator for whether the status of the journal batch has been verified. Valid values are Y and N, representing Yes and No. For Oracle internal use only.

Submitted Period

Reference to the Submitted Period object. For Oracle internal use only.

Not Reserved Packet ID

For Oracle internal use only.

Journal Batch Creator

Reference to the Journal Batch Creator object. For Oracle internal use only.

Journal Batch Approval Requester

Reference to the Journal Batch Approval Requester object. For Oracle internal use only.

Descriptive Flexfield Structure Definition 1

Structure definition of the Journal Batches descriptive flexfield.

Descriptive Flexfield Attributes 1 through 10

Segments of the Journal Batches descriptive flexfield.

Funds Status

Budgetary control status for the batch. A list of valid values can be found in the lookup type XCC_BC_FUNDS_STATUSES. For example, RESERVED_PARTIAL or RESERVED_PASSED, representing Partially reserved and Reserved.

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

Name Description

Batch ID

Internal identifier of the journal batch. For Oracle internal use only.

Currency

Currency of the ledger. For example USD or EUR.

Ledger Category Code

Category of the ledger. Valid values are SECONDARY, PRIMARY, NONE, and ALC, representing the following respective categories: Secondary Ledger, Primary Ledger, None, and Reporting Currency.

Ledger Enabled for Journal Approvals Indicator

Indicator for whether approval is enabled for the ledger. Valid values are Y or N, representing Yes and No.

Ledger ID

Internal identifier of the ledger.

Ledger Name

Name of the ledger.

Meaning

For Oracle internal use only.

Period Set Name

Internal name for the accounting calendar, which is the original calendar name that a user entered. For Oracle internal use only.

Primary Ledger Currency

Ledger currency defined for the primary ledger. For example, USD or EUR.

Descriptive Flexfield Structure Definition

Structure definition of the Ledgers descriptive flexfield.

Descriptive Flexfield Attributes 1 through 15

Segments 1 through 15 of the Ledgers descriptive flexfield.

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

Name Description

Journal Source ID

Internal identifier of the journal source. For Oracle internal use only.

Journal Reference Indicator

Indicates whether journal import saves the references to the subledger transactions. Saved references let you drill from a general ledger journal to the subledger transaction. Valid values are Y or N, representing Yes and No.

Override Edits Indicator

Indicator for whether a user can update the journal that has the journal source. Valid values are Y, N, or P, representing Yes, No, and Partial, respectively.

Type

Identifies whether the source for the batch is a subledger application. Valid values are SLA or Non-SLA, representing subledger accounting and nonsubledger accounting, respectively.

Journal Source Name

User-defined name for the journal source.

Source Key

Unique identifier for a journal source.

Descriptive Flexfield Attributes 1 through 5

Segments 1 through 5 of the Journal Sources descriptive flexfield.

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

Name Description

Calendar ID

Internal identifier of the accounting calendar. For Oracle internal use only.

Period Set ID

Internal identifier. For Oracle internal use only.

Period Set Name

Name of the accounting calendar when first created. If the calendar name is later changed in the user interface, this original name remains stored internally as a unique identifier. For Oracle internal use only.

Period Type

Internally generated value based on period frequency of the accounting calendar. For Oracle internal use only.

Period Type ID

Internal identifier of the period type. For Oracle internal use only.

User Period Set Name

Current name of the accounting calendar.

Descriptive Flexfield Structure Definition

Structure definition of the Calendars descriptive flexfield.

Descriptive Flexfield Attributes 1 through 5

Segments 1 through 5 of the Calendars descriptive flexfield.

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

Name Description

Category ID

Internal identifier of the journal category. For Oracle internal use only.

Journal Category Name

Translated name of the journal category. Might not uniquely identify a category in an approval rule. Varies depending on a user's language setting.

Category Key

User-defined category key that uniquely identifies the category.

Descriptive Flexfield Structure Definition

Structure definition of the Journal Categories descriptive flexfield.

Descriptive Flexfield Attributes 1 through 5

Segments 1 through 5 of the Journal Categories descriptive flexfield.

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

Name Description

Reversed Journal Indicator

Indicator for whether the journal was reversed. Valid values are Y or N, representing Yes and No.

Accounted Currency

Currency of the ledger. For example, USD or EUR.

Accounting Date

Accounting date of the journal.

Batch ID

Internal identifier of the journal batch. For Oracle internal use only.

Category

Internal identifier of the journal category. For Oracle internal use only.

Journal from Subledger Indicator

Indicator for whether the journal was created through subledger accounting. Valid values are Y or N, representing Yes and No.

Header ID

Internal identifier of the journal. For Oracle internal use only.

Journal Header Category

Reference to the Journal Header Category object. For Oracle internal use only.

Journal Line

Reference to the Journal Line object. For Oracle internal use only.

Ledger ID

Identifier for the ledger.

Ledger Name

Name of the ledger.

Reference Date

Reference date entered for the journal.

Running Total Accounted Credit

Total accounted credit amount of the journal.

Running Total Accounted Debit

Total accounted debit amount of the journal.

Attachment Exists Indicator

Indicator for whether the journal has attachments. Valid values are Y or N, representing Yes and No.

Entered Currency

Entered currency of the journal. For example, USD or EUR.

Journal Description

Description of the journal.

Journal Name

Name of the journal.

Reversing Journal Indicator

Indicator for whether the journal resulted from a reversal. Values are Y or N, representing Yes and No.

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.

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.

Using the Maximum Amount Journal and Maximum Amount Journal Line Objects in Journal Approval Rules: Explained

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.

Configure Journal Approval Email Notifications

Financials Configurable Workflow Notifications: Overview

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. Oracle Business Intelligence (BI) Publisher reports are used for some flows to generate the 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.

The following table shows the financial products that use configurable notifications, along with their associated features, and workflow task names:

Product Feature Name Report or Notification Name Workflow Task Name

General Ledger

Journal Approval Notifications

Journal Approval Report

FinGlJournalApproval

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

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

FinExmReimToEmpByCheckFyi

FinExmReimToEmpByDepositFyi

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

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

Bill Management

User Registrations Notifications

Registration Confirmation.

New Account Registration Confirmation.

Account Access Revocation Notification.

Access Revocation Notification.

N/A

Budgetary Control

Budgetary Control Override Email Notifications

Budget Override Request Notification Budget

OverrideNotificationFyi

Budgetary Control

Budgetary Control Override Email Notifications

Override Taken Notification

OverrideNotificationFyi

Receivables

Manual Credit Memo Request Notification

Manual Credit Memo Request Notification

Note: The in-app notification is also configurable.

FinArTrxnsCreditMemosCreationPostProcessing

Note: When you receive a workflow email notification, you can alternatively find the same notification by clicking the Notifications icon in the global header or opening the Worklist: Notifications and Approvals work area.Your report edits don't affect the other notification methods.

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.

This figure shows how these objects work together
to generate the output used for email 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: What the notification looks like, leveraging components from the subtemplate and styles from the style template used for the report

  • 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

When you enable configurable email notifications, the predefined reports and related objects in the BI catalog will be used to generate the email notifications. 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. To modify the email 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 workflow email notifications, it's recommended that you familiarize yourself with BI Publisher in general. This will improve your ability to change your notifications by formatting emails to meet your business requirements.

With BI Publisher-based email 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: Review the My Oracle Support (MOS) note: Configurable Workflow Notifications: Implementation Considerations (Doc ID 2215570.1).

Steps to Enable

In the Offerings work area, enable the Configurable Email Notifications feature as follows:

  1. Offering: Financials

  2. Functional Area: Budgetary Control, Expenses, Intercompany, General Ledger, or Payables

  3. Feature: Configurable Email Notifications

  4. Choices: The specific notifications you want to enable

  5. Click Done.

Modifying Journal Approval Email Notifications Using Oracle Business Intelligence (BI) Publisher: Worked Example

This example shows how to modify email 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 email notification header?

Append the fiscal year.

What additional field should the email notification header include?

The name of the user who created the journal batch.

What changes are needed in the details section of the email 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 email 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 email 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 email notification.

  6. Uploading the modified report layout template.

For more information about configuring BI Publisher email 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 email notification. To display a combination of segment values and descriptions on the email 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 email 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 email 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 Email 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 email 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 email 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 email 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 email 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 email 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 Email 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 in emails sent 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 email 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.

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

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

    Manage AutoPost

    This example shows how to create an AutoPost Criteria Set to post your general ledger journal entries that were created by the journal import process for your subledger transactions. Your enterprise, InFusion Corporation:

    • Implemented Oracle Fusion General Ledger and the Oracle Fusion subledgers: Payables and Receivables.

    • Uses a non-Oracle subledger called Fast Assets for fixed asset tracking and depreciation.

    • Plans to automate posting of general ledger journal batches created by the journal import process to protect the subledger sourced journal entries from edits or deletion that might cause an out-of-balance situation between the subledgers and general ledger.

    Consider the following points while 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.

    Creating an AutoPost Criteria Set

    Create your AutoPost Criteria Set to automatically post journal entries from both Oracle and non-Oracle subledgers.

    1. On the Manage AutoPost Criteria Sets page, click the Create icon to open the Create AutoPost Criteria Set page.

    2. Enter the criteria set name: All Journal Imported Entries.

    3. Select the Enabled check box.

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

    5. Click the Add Row icon to add each new line.

    6. Complete the fields, as shown in this table.

      Priority Ledger or Ledger Set Source Category Accounting Period

      1

      InFusion Corporation Ledger

      Payables

      All

      All

      2

      InFusion Corporation Ledger

      Receivables

      All

      All

      3

      InFusion Corporation Ledger

      Fast Assets

      All

      All

    7. For all three sources, select Yes for the Process All Criteria option, and enter 30 as the number of days before and after submission date. Setting the before and after day with a wide range of days enables the process to run less often.

    8. Click Save and Close.

    9. Schedule the process to run immediately after the journal import 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 Manage 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.

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

    • Journal imports completed successfully.

    • Journal batches are error free and ready to post.

    • Specified accounting period is open.

    Manage Journal Reversals

    Journal Reversals: Explained

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

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

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

    The journal was replicated from the primary ledger.

    Yes

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

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

    The journal was created directly in the secondary ledger.

    Yes

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

    The journal was replicated from the primary ledger.

    No

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

    The journal was created directly in the secondary ledger.

    No

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

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

    • Offering: Financials

    • Functional Area: General Ledger

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

    FAQs for Manage Journal Reversals

    When does a journal become reversible?

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

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

    Criteria Eligible for Manual Reversal? Eligible for Automatic Reversal?

    The journal has a balance type of Actual.

    Yes

    Yes

    The journal has a balance type of Encumbrance.

    Yes

    No

    The journal is posted and not yet reversed.

    Yes

    Yes

    The reversal period is open or future enterable.

    Yes

    Yes

    The journal isn't a reversal journal.

    Note: Reversal journals can't be reversed.

    Yes

    Yes

    The journal category is enabled for automatic reversal.

    N/A

    Yes

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

    Yes

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

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

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

    Yes

    Yes

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

    Yes

    Yes

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

    Yes

    Yes

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

    Define 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 cannot 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 is not predefined data

    No

    Deleting codes

    Yes

    Yes, only if the code is not 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.

    Standard, Common, and Set-Enabled Lookups

    The following table shows the available types of lookups.

    Lookup Type Description

    Standard

    Lists the available codes and translated meanings.

    Set-enabled

    Associates a reference data set with the lookup codes.

    Common

    Legacy lookups or lookups that have attributes.

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

    Accessing Lookups

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

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

    Enabling Lookups

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

    Enable lookups based on the following.

    • Selecting an Enabled check box

    • Specifying an enabled start date, end date, or both

    • Specifying a reference data setdeterminant

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

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

    • Manage Standard Lookups

    • Manage Common Lookups

    • Manage Set-Enabled Lookups

    Translating Lookups

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

    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 was not enabled and does not 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 does not 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 is 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 Define Lookups

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

    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 or task list 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 cannot 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.

    Use the Query By Example functionality to sort through hundreds of lookup codes for a lookup type, and display a specific lookup code. Enter the first few characters of the lookup code value in any of the relevant fields to filter the records.

    Note: The search functionality is case sensitive.

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

    Planning Descriptive Flexfields: Points to Consider

    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. For more information about extending the BI enabled segments into OTBI, see the Setup and Configuration chapter in the Oracle Transactional Business Intelligence Administrator's Guide.

    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 cannot enter a number for one segment that 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 is 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 cannot 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 are 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 cannot 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 the following bind variables in the WHERE clause of the SQL statement.

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

      • :{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 cannot be a multiple-row context.

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

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

    For more information about using bind variables, see the help for value sets.

    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 additional information about logical objects and import, refer to the Oracle Transactional Business Intelligence Administrator's Guide.

    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 additional information about import, refer to the Oracle Transactional Business Intelligence Administrator's Guide.

    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 are not displayed by default. When a Global Segment is added to a Search Panel, it is 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 are 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.

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

    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.

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

    Setting Profile Option Values: Procedure

    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.

    Creating and Editing Profile Options: Procedure

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