2Journals
This chapter contains the following:
Accounting Cycle
Example of an Accounting Cycle
This example demonstrates the steps in completing the accounting cycle to achieve successful financial reporting for your enterprise. These steps may vary based on your business processes and enterprise structure.
Scenario
Your company, InFusion Corporation, is a multinational conglomerate that operates in the United States (US) and the United Kingdom (UK). InFusion Corporation:
-
Uses Oracle Fusion General Ledger and all of the Oracle Fusion subledgers.
-
Includes all the components to build and maintain air quality monitoring systems for homes and businesses in your business line.
-
Provides funding to your customers for the start up costs of these systems through your financial services organization.
-
Purchases raw materials from other countries, which requires you to record foreign currency transactions.
-
Consists of three subsidiaries.
-
InFusion Financial Services
-
InFusion UK Services
-
InFusion America
-
-
Consolidates financials with all its subsidiaries monthly in the parent, InFusion Corporation ledger.
The following are the tasks that your staff performs to complete the accounting cycle and ensure accurate capturing of your accounting transactions.
-
Open the accounting period.
-
Enter manual journal entries: standard, statistical, and intercompany balancing journal entries between your parent company and your three subsidiaries.
-
Import journals from your subledgers. Correct or delete journal entries that failed the import process. If necessary, run the import process again.
-
Define journals that occur periodically and allocation journal formulas for transactions that have a common format, require allocation of amounts or accounts to other accounts, or that are entered frequently.
-
Generate recurring and allocation journal batches based on your defined formulas.
-
Review the details of the unposted journal batches.
-
Edit unposted journals to change or correct information, including the batch period and the journal currency.
-
Post journal batches manually or automatically.
-
Check for posting errors. Use the Posting Execution Report and the Automatic Posting Execution Report to check the results of your posting. These reports are created automatically when the posting programs are completed.
-
Reverse posted journals as needed. Assign a reversing period to the journal, generate the journal, and post the reversing batch.
Note: Journals can be set to automatically reverse when you open the period. Subsequent adjustments to the accounts are then based on balances net of those reversals. -
Revalue foreign currency denominated balances to reflect conversion rate fluctuations at the end of the accounting period.
-
Translate actual account balances in your UK subsidiary to US dollars to report to your US parent. You consolidate the ledgers for all your subsidiaries in US dollars.
-
Consolidate ledgers by defining and running a consolidation for all your subsidiaries.
-
Produce financial reports and perform online inquiries to review current account balances.
-
Close the current accounting period.
-
Open the next accounting period.
How to Prevent a General Ledger Period from Closing When Open Subledger Periods Exist
You can prevent a General Ledger accounting period from closing when any, or some of the corresponding subledgers are still open, or the period has incomplete accounting entries or transactions. This can help ensure an effective period close process that validates all transactions are complete and aren't held up during the close.
Exceptions That Prevent a Period from Closing
Here are the period status exceptions.
-
Subledger accounting periods aren't closed
Here are the transaction exceptions.
-
Unprocessed and untransferred subledger transactions
-
Pending Intercompany transactions
-
Pending transactions in the General Ledger interface
-
Unposted transactions in General Ledger
Benefits
Here are the benefits.
-
Brings the General Ledger period close process in line with corporate-wide business policy, if any.
Helps you comply with the general business practice of not allowing a closed General Ledger period to be reopened unless there are material changes. In general, periods aren't reopened unless there are strong justifications and related approvals. By using this feature, you might not need to reopen a closed period, because you already ensured that all unprocessed transactions and exceptions were duly resolved before closing it.
-
Provides more meaningful and accurate financial reporting, because all exceptions would have been resolved and accounted for, before reporting.
-
Helps you comply with audit requirements, if any.
How to Set It Up
-
Go to the following:
-
Offering: Financials
-
Functional Area: General Ledger
-
Task: Specify Ledger Options, with the primary ledger scope set
-
-
In the Period Close section, select the Prevent General Ledger Period Closure When Open Subledger Periods Exist option.
Here's an image of the ledger option and field help on the Specify Ledger Options page.
-
Save the change.
How to Optionally Exclude Specific Subledgers
When you set the ledger option, by default the General Ledger Period Close process checks these subledgers for period status exceptions: Cost Management, Payables, Receivables, Projects Foundation, and Revenue Management. You can optionally exclude one or more of them, so the General Ledger period close process skips the period status exceptions encountered within the context of the excluded subledgers. The transaction exceptions previously listed are still checked and period close prevented if the process encounters such exceptions.
-
Go to the following:
-
Offering: Financials
-
Functional Area: General Ledger
-
Task: Manage General Ledger Lookup Values
-
-
In the Lookup Type field, enter ORA_GL_INCLD_STRICT_PRD_CLOSE and click Search.
Here's an image of the search results with the list of subledgers.
-
Click in the Enabled field to deselect the subledger that you want to exclude.
Note: Select the Enabled field to reinstate a previously excluded subledger. -
Save your changes.
Example of How It Works
Let's say you enabled the ledger option for your primary ledger Vision Corporation and you didn't exclude any subledgers. The December 2019 period is open for both General Ledger and the Payables subledger. When you go to close the December 2019 General Ledger accounting period from either the Manage Accounting Periods or Edit Accounting Period Statuses pages, an error message will appear telling you the option is enabled and that the Payables subledger is still open. Instead, if you submit the period close process from the Scheduled Processes page, this same message will appear in the process log files. The rest of the message helps get you started with processing the pending transactions and resolving exceptions.
Journal Capture
Journal Capture Options
The ledger and subledger transactions are captured in four ways:
-
Entering journals manually
-
Entering journals in spreadsheets
-
Importing journals
-
Creating journals automatically
Use of these methods varies depending on:
-
The application providing the data
-
The reason for the entry, such as error correction versus monthly entries
-
The tools available, such as the calculation engine used in the automation of journal entries
Entering Journals Manually
Enter journals manually that occur once or infrequently, such as journals to:
-
Correct errors
-
Reclassify account balances
-
Accrue balances for unusual transactions
This method requires the most time and is open to errors from human intervention.
Entering Journals in Spreadsheets
Enter manual and recurring journal entries through a spreadsheet interface. Then:
-
Load the completed spreadsheet into the import interface.
-
Schedule or manually submit the Journal Import process to import the data into the ledger.
Working in spreadsheets adds functionality such as the use of macros, formulas, and links to existing documents.
Importing Journals
Use Oracle Fusion Subledger Accounting to submit journal entries from subledger applications to the import interface to prepare for data transfer into the ledger. Subledger applications include both Oracle and non-Oracle. Then:
-
Schedule or manually submit the Journal Import process to perform the import.
-
Verify that the data is transferred completely and accurately.
This method efficiently and correctly populates the bulk of the data in the ledger.
Creating Journals Automatically
In Oracle Fusion General Ledger, create journal entries automatically to automate processes and reduce both errors and data entry time. For example:
-
Define allocation rules and rule sets in the Oracle Fusion Calculation Manager. Then:
-
Generate your defined allocation formulas to automatically populate the allocated data to the import interface.
-
Schedule or manually submit the Journal Import process to import the journal lines into the general ledger to create unposted allocation batches.
-
Post automatically during the generate process or manually to allocate data from amounts or accounts to other accounts on a periodic basis.
-
-
Define journal reversal criteria sets for specific journal categories to automatically create reversal journal entries. Schedule or manually submit the AutoReverse process. The process creates journal entries when it reverses the journals that match the criteria specified.
-
Define revaluation definitions to properly account for unrealized gains and losses on currency exchange fluctuations. Then:
-
Schedule or manually submit the Revaluation process.
-
Post the revaluation journal batch.
The process adjusts the respective foreign currency denominated asset or liability to its current accounted value. The adjustment is offset to the unrealized gain or loss account.
-
-
Use the Balances Transfer process for generic cross ledger balance transfers. This process:
-
Transfers copies of the data from your source ledgers to your target ledgers.
-
Initiates this process at periodic intervals as needed.
-
Automatically creates postable journal entries that update account balances in the target ledger with a journal source of Balance Transfer.
-
Is used to transfer specifically from the primary ledger to its balance level secondary ledger.
-
Uses the primary ledger as the journal source.
-
Create Standard Journals
Overview of Journal Entry and Actions
Journal entries are posted to the ledger to record data from accounting transactions that reflect your entity's business events. Journal creation, approval, posting, and editing work together in the recording process to produce accurate financial records.
Creating Journal Entries
The process begins with creating journals. You can create journals in several ways:
-
Enter manually directly in the ledger.
-
Use a spreadsheet interface.
-
Import journals into the ledger.
-
Create automatically from formulas or processes.
All methods produce a journal entry consisting of:
-
A batch that determines the accounting period of all journals associated with the batch.
-
One or more journals, with a category and a currency assigned to each.
Note: For cross-currency journals, the currency is assigned at the line level. -
Lines that contain the accounting for the transaction.
Save to create the journal entry. Complete the journal to submit it for posting. After creation, apply an optional journal approval process to the entry.
A journal entry that has been saved, completed, and, if necessary, approved, is available for posting.
Approving Journal Entries
If you're using journal approval, you can select the Request Approval action for the journal batch to initiate the approval process. After the batch is approved, you must then post it. If you skip the action of requesting approval, and instead select to post the batch, or if the batch is picked up for posting through an AutoPost criteria set, the batch proceeds through the approval process, after which posting is automatically submitted.
Posting Journal Entries
You can post journal entries only in open accounting periods. Keep all but the current periods closed to prevent posting of amounts in incorrect periods. During the posting process, the journal entry is validated and, if successful, the credit and debit amounts are updated to their respective accounts in the ledger. You can't change a journal entry that's posted.
Once posting has finished successfully, run reports and performs queries on the updated account balances in the ledger.
Editing Journal Entries
Edit journal entries as needed before they're posted. After posting, either reverse and enter the journal again, or enter a new journal to correct the amounts in question.
Journal Entry Components
Journal entries post accounting balances to the ledger for reporting and analysis.
Journal entries consist of three components: a batch, journals, and lines. You can organize journals with common attributes into batches. The journal information identifies common details for a single journal entry. The lines specify the accounting information for the journal entry. Batches can multiple journals and journals can have multiple lines.
The following figure shows the three journal components and the data required for each component.

Batch
A batch can contain multiple journals, each of which can belong to a different ledger. All of the ledgers within a batch must have the same accounting calendar and chart of accounts. Batches require a name, source, and accounting period. All journal entries in a batch must share the same period. You can create a journal batch by entering a user-defined name in an open or future enterable accounting period. You must post batches in open accounting periods. If you don't want to enter the batch information, start by entering data in the Journals section on the Create Journal page. The batch name is created automatically using the following components:
-
Journal source name of manual
-
A unique batch
-
System date
Journals
A journal requires the following data:
-
Ledger name
-
Journal name
-
Accounting date
-
Source
-
Category
-
Currency
To select the ledger from the choice list, your data access set must provide one of the following
-
Read and write access to the ledger
-
Read and write access to one or more balancing or management segment values
If you use reporting currencies or secondary ledgers with a journal or subledger conversion level, select a reporting currencies or secondary ledger for your journal. Creating manual journals is an exception for the secondary and reporting ledgers because their journals propagate directly from their primary ledger.
Lines
The lines require accounts and amounts. Total debits must equal total credits for all journal entries except for statistical journal entries.
Single or Multiple Journal Batches
Entering journal batches is optional. The application creates a unique batch ID automatically; using the journal entry name combined with the system date and time. All journal entries in a batch must share the same accounting period. Enter journals only in a current or future enterable accounting period. Batches can contain one or an unlimited number of journal entries. When you post one journal entry, the entire batch posts. Posting is always done at the batch level.
Using a Single Batch
You can record a set of journal entries in a single batch. For example, all of your statistical entries or monthly accruals can be entered in one batch for easy reference, querying, and posting.
Using Multiple Batches
Use multiple batches when it's important for each journal entry to be reversed separately or to document a specific transaction or adjustment.
Example of Statistical Journal Entry
This example uses headcount to illustrate how a company can record statistical information in a journal entry. The posted statistical balances can then be used in journal entries that allocate expenses.
Scenario
InFusion America Incorporated hires thirty new employees and assigns them to the sales, accounting, and purchasing departments. To allocate expenses properly, InFusion America Incorporated must track headcount for each department.
Transaction Details
The thirty new employees are assigned as follows:
-
Twelve to the sales department
-
Ten to the accounting department
-
Eight to the purchasing department
Analysis
The sales department has expanded its territory and needs twelve new employees to cover the new areas. The sales force works in the field and has travel expenses.
The accounting department has lost four employees to retirement so needs four new employees to fill those vacated positions. The accounting department also added six new positions to handle the expected increase in sales. Accounting employees work in a central office, and the department allocates expenses across other departments.
The purchasing department has added four new buyer positions and four new warehouse positions to handle the expected increase in orders. Purchasing employees work in the warehouse and participate in InFusion America Incorporated health insurance plan.
Resulting Statistical Journal Entry
The following table shows the journal entry that was created, using the STAT currency, to capture the headcount information for each department.
Department | Department Number | Debits | Credits | Description |
---|---|---|---|---|
Sales |
200 |
12 |
Sales force addition due to territory expansion. |
|
Accounting |
300 |
10 |
4 |
Addition of six new positions and the loss of four due to retirement, which requires four new employees. |
Purchasing |
500 |
8 |
Addition of four buyers and four warehouse positions. |
|
Total |
Not Applicable |
30 |
4 |
Not Applicable |
Enter Foreign Currency Journals
This example demonstrates how to create a journal entry in a foreign currency. Your company, InFusion America, has purchased a new truck from a company located in the United Kingdom. The price is in British pounds (GBP) and your ledger currency is United States dollars (USD). When the cost was booked in purchasing, the freight costs weren't included. You must enter a manual journal entry for the missing freight costs.
Follow these steps to enter a manual journal entry using a foreign currency. A currency is classified as foreign if it isn't your ledger currency or a reporting currency you're using with the journal or subledger level reporting currency functionality.
Entering a Foreign Currency Journal
-
Navigate to the Manage Journals page and select the Create Journal task.
-
Complete the fields, as shown in this table.
Field Value Batch Name
UK Sales Adjustment
Batch Description
Freight costs on purchase of a truck
Journal Name
UK Sales Adjustment
Journal Description
Freight costs on purchase of a truck
Category
Adjustment
Currency
GBP
Conversion Rate Type
User
Conversion Rate
1.59
Debit Account
Your purchase account
Debit Amount
500
Credit Account
Your payables account
Credit Amount
-500
-
Click Post.
The application saves, completes, and posts the entry.
Note: In this example, the conversion rate type of User was selected, which requires you to enter the conversion rate. Other conversion rate types are Spot, Corporate, or user-defined. These other conversion rate types can automatically enter the conversion rate based on the data in the daily rates tables and the conversion date. Select a conversion date within the accounting period that you defined for the journal entry. The conversion date field lets you select other dates to use a different daily rate. The default conversion date is equal to the journal accounting date.
How You Require Manual Journals Balance by Entered Currency
You can require that manual journals balance by entered currency when a journal is created. So when a journal preparer creates a journal on the Create Journal page or Create Journal spreadsheet, total debits must equal total credits for each entered currency, otherwise the journal can't be saved.
This also means that the journal posting process doesn't have to generate additional lines to balance the journal. The posting process continues to balance any unbalanced journals coming in through external feeds.
Here's how you set it up.
-
In the Setup and Maintenance work area, go to the Specify Ledger Options task:
-
Offering: Financials
-
Functional Area: General Ledger
-
Task: Specify Ledger Options, with the primary ledger scope set
-
-
On the Specify Ledger Options page, enable the Require manually entered journals balance by currency option in the Journal Processing Balancing section. The option is automatically enabled for any associated secondary ledgers and reporting currencies.
How You Limit a Journal to a Single Currency
You can enforce single currency journals for a journal source. The limit applies to journals entered on the Create Journal page and to journals that are imported. The Import Journals process automatically separates the journals by currency.
Here's how you set it up.
-
In the Setup and Maintenance work area, go to the Specify Ledger Options task:
-
Offering: Financials
-
Functional Area: General Ledger
-
Task: Specify Ledger Options, with the primary ledger scope set
-
-
On the Specify Ledger Options page, enable the Limit a journal to a single currency option in the Journal Processing Entry section. The option is automatically enabled for any associated secondary ledgers and reporting currencies.
-
Go to the Manage Journal Sources task:
-
Offering: Financials
-
Functional Area: General Ledger
-
Task: Manage Journal Sources
-
-
On the Manage Journal Sources page, enable the Limit Journal to Single Currency option for the applicable journal sources.
Note: You can't enable the option for these journal sources: Allocations, AutoCopy, Balance Transfer, Closing Journal, and Revaluation.
How Journal Import Data Is Processed
Use the Journal Import file-based data import to upload journal entry data from external sources into Oracle Fusion General Ledger. You can download a spreadsheet template to use to prepare your journal entry data. The template contains an instruction sheet to help guide you through the process of entering your journal information.
To access the template, complete the following steps:
-
Navigate to the File-Based Data Import for Oracle Financials Cloud guide.
-
In the Table of Contents, click File-Based Data Imports.
-
Click Journal Import.
-
In the File Links section, click the link to the Excel template.
Follow these guidelines when preparing your data in the worksheet:
-
Enter the required information for each column. Refer to the tool tips on each column header for detailed instructions.
-
Don't change the order of the columns in the template.
-
You can hide or skip the columns you don't use, but don't delete them.
Settings That Affect the Journal Import Process
The Journal Import template contains an instructions tab and a tab that represents the table where the data is loaded.
The Instructions and CSV Generation tab contains information about:
-
Preparing the journal data.
-
Understanding the format of the template.
-
Entering journals.
-
Loading the data into the interface table and the product.
The GL_INTERFACE tab is where you enter information about the journals that you're adding, such as the journal source, category, currency, and amount.
How Journal Import Is Processed
To load the data into the interface table:
-
Click the Generate CSV File button on the instructions tab to create a CSV file in a .zip file format.
-
Save the .zip file locally.
-
Navigate to the Scheduled Processes work area.
-
Select the Load Interface File for Import process.
-
For the Import Process parameter, select Import Journals.
-
For the Data File parameter, select the file that you saved in step 1.
To load the data from the interface table into the product:
-
Navigate to the Journals work area and select the Import Journals task.
-
Enter values for the parameters.
-
If the process ends in error or warning, you can correct or delete the rows that have errors.
-
To correct the rows with errors:
-
Review the log and output files for details about the rows that caused the failure.
-
Navigate to the Journals work area and select the Correct Import Errors task to download the journal corrections worksheet.
-
Search for the errors rows using the Source and Group ID fields.
-
Correct the entries in the worksheet and click Upload. If you select to save to the interface, you must rerun the Import Journals process.
-
-
To delete the rows with errors:
-
Navigate to the Journals work area and select the Delete Import Data task.
-
Provide values for the required parameters. For the Process ID parameter, specify the ID for the Import Journals process.
-
-
To delete the data from the interface table without loading into the product, while the status of the interface rows is NEW:
-
Navigate to the Scheduled Processes work area and select the Purge Interface Tables process.
-
Accept the default value of File-based data import for the Purge Process Intent parameter.
-
Select Import Journals for the Import Process parameter.
-
Enter the process ID from the Load Interface File for Import process into the Load Request ID parameter.
Financial Descriptive Flexfields
In Oracle Fusion Financial Applications, the descriptive flexfields are available from either the Basic or Advanced Search sections for all transaction objects that have Secure Enterprise Search (SES) enabled.
Examples of the descriptive flexfields available are:
-
Oracle Fusion Payables: Invoices
-
Oracle Fusion Receivables: Adjustments
-
Oracle Fusion Expenses: Expense
-
Oracle Fusion Assets: Assets Invoices
-
Intercompany: Intercompany Transaction Headers (Inbound Transaction)
-
Intercompany: Intercompany Transaction Batches (Outbound Transaction)
-
Oracle Fusion General Ledger: Journal Batches
-
Oracle Fusion General Ledger: Journals
-
Oracle Fusion Subledger Accounting: Subledger Journal Entry Header
Descriptive flexfields consists of segments.
The following table lists the descriptive flexfield segments.
Segment | Description |
---|---|
Global Segment |
Are always displayed, if enabled. |
Used to determine which context sensitive segments are displayed. |
|
Displayed values based on the defined value in the context segment. |
In some products, the descriptive flexfields are displayed by default in the Search section, while others are available in the Add Fields menu.
-
Global Segments: Generally available in the Add Fields menu if they're not displayed by default. When a Global Segment is added to a Search Panel, it's displayed before the context segments.
-
Context Segments: Generally available in the Advanced Search section by default.
-
Context Sensitive Segments: Available in the Add Fields menu after you select a context segment value.
-
The segments are displayed in the Search Panel in the following order:
-
Global Segments
-
Context Segments
-
Context Sensitive Segments, after their Context Segment
-
-
The list of values on the Add Fields menu lists all descriptive flexfields alphabetically, followed by all other fields alphabetically.
-
If more than one global segment is defined, then all global segments are displayed in the Search panel in the sequence defined by you, the user, followed by context segments.
-
Similarly for context segments, all context segments are displayed in the Search panel in your defined sequence defined order.
-
When context sensitive segments are added to a Search panel, they're also displayed in your defined sequence order.
How You Search for Journal Descriptive Flexfields
Use descriptive flexfields to define and store additional information for journals. You have the capability to retrieve the information from descriptive flexfields by using the Advanced Search in the Manage Journals Search panel.
The two descriptive flexfields available for search on the journal pages are in the following regions:
-
Journal Batches
-
Journals
You can search using global and context segments, and both are available from the Advanced Search panel. After adding the context segment, a value is selected and a list of context-sensitive segments become available in the Add Fields.
Example of Additional Journal Information with Descriptive Flexfields Based on Ledger or Account Value
This example shows how to capture additional journal line information in the context of a specific ledger or natural account segment value, during journal entry.
Scenario
Your company has multiple ledgers. When entering journal lines for the Vision Corporation ledger, users must enter a source voucher number as additional information. For the Spruce Street Foods ledger, users must enter both a source voucher number and a source voucher date. The remaining ledgers don't have to track this information.
In addition, when entering journals, if the natural account segment in an account combination has a value of 7620, which represents legal expenses, users must provide a litigation file number. If the segment value is 52310, which represents insurance expenses, users must provide the name of the insurer and the policy number.
Configuring General Ledger Descriptive Flexfields
Before configuring the descriptive flexfield for source voucher information, you must find the ledger ID for each ledger. Use the Manage Primary Ledgers task in the Setup and Maintenance work area. If the Ledger ID column isn't displayed, click Columns, Ledger ID, from the View menu. In this example, the ledger ID for Vision Corporation is 1000, and the ledger ID for Spruce Street Foods is 1225.
Analysis
To capture the source voucher information, use the Manage General Ledger Descriptive Flexfields task in the Setup and Maintenance work area. Create a context segment for the Journal Lines descriptive flexfield with ledger ID as the context segment value. Set up the value to automatically default from the Ledger ID parameter.
The following image shows the Context Segment section on the Edit Descriptive Flexfield page for the Journal Lines flexfield, which has the flexfield code GL_JE_LINES. The context segment has a prompt of Ledger Details, a default type of Parameter, a default value of Ledger ID, a derivation value of Ledger ID, and a display type of List of Values.

Next, define a context-sensitive segment for the source voucher number, within the context of the Vision Corporation ledger. Set the context code to 1000, and set the segment to required. Then, define context-sensitive segments for the source voucher number and source voucher dates, within the context of the Spruce Street Foods ledger. Set the context code to 1225 and set both segments to required.
The following image shows part of the Edit Context page for the Spruce Street Foods ledger context with the two context-sensitive segments.

Similarly, to capture information that's based on natural account segment values, create a context segment for the Journals Captured Information descriptive flexfield (flexfield code GL_CAPTURED_INFO) with natural account as the context segment value. Set up the value to automatically default from the Natural Account parameter.
Next, define a context-sensitive segment for the litigation file number, within the context of the legal expenses account. Set the context code to 7620 and set the segment to required. Then, define context-sensitive segments for the insurer and policy number, within the context of the insurance expenses account. Set the context code to 52310 and set both segments to required.
Deploy each descriptive flexfield after the setup is complete.
Resulting Prompts During Journal Line Entry
The prompts for providing the additional information appear on both the Create Journal page and the Create Journal spreadsheet, which you open using the Create Journal in Spreadsheet task. If prompted, you must provide the information to save the journal.
The following image shows part of the Journal Lines section on the Create Journal page. The ledger for the journal is Vision Corporation, and the natural account segment value on the journal line is 7620. The Source Voucher Number and Litigation File Number fields are required. The values for the context segment prompts of Ledger Details and Account Number are automatically defaulted.

When entering journal lines for the Spruce Street Foods ledger and the insurance expenses account, users must provide a source voucher number, source voucher date, name of the insurer, and policy number. Journal lines with natural account segment values other than 52310 only require a source voucher number and date.
The following image shows part of the Journal Lines section on the Create Journal page. The ledger for the journal is Spruce Street Foods, and the natural account segment value on the journal line is 52310. The Source Voucher Number, Source Voucher Date, Insurer's Name, and Policy Number fields are required. The values for the context segment prompts of Ledger Details and Account Number are automatically defaulted.

Create Journals in Spreadsheets
How You Create Journals in Workbooks
You can use the Create Journals workbook for high volume journal entry. You can prepare the journals offline, distribute the workbooks for review, or save the journals for recurring entry.
Setup
Before you can use the Create Journals workbook, you must install an Excel add-in. Navigate to the Tools work area and select the Download Desktop Integration Installer link.
You can optionally set a profile option to require that journals entered in workbooks balance, regardless of the suspense setting on the Specify Ledger Options page. To set the profile option as needed, use the Manage General Ledger Profile Options task in the Setup and Maintenance work area. The name of the profile option is Journals: Balanced Spreadsheet Journals Required.
Download
To download the Create Journals workbook, navigate to the Journals work area and select the Create Journal in Spreadsheet task.
Journal Entry
The Create Journals workbook has two worksheets. On the Single Journal worksheet, you can create a journal for one ledger, similar to using the Create Journal page in the application. On the Multiple Journals worksheet, you can create multiple journals and multiple journal batches for different ledgers.
Submission
When you're ready to submit the journals for processing, click Submit on the Create Journal ribbon. Some initial validations are performed, such as verifying that you provided an accounting date and a valid journal category. The validation results display in the Status Viewer pane on the worksheet.
Make the necessary corrections and resubmit the worksheet. On the Submission Options window, accept the default selection or select one of the other options:
-
Save to Interface: If you select this option, you must submit the import and posting process later to create and post the journals.
-
Submit Journal Import: If you select this option, you must submit the posting process later to post the journals.
-
Submit Journal Import and Posting (default selection)
You can also select from among these additional options:
-
Import Descriptive Flexfields: If you selected one of the import options, you can also specify whether to import descriptive flexfields and validate them.
-
Defer Account Validations to Journal Import: If you plan to load a high volume of data, this option can improve the performance of the workbook. When you select this option, the account combinations used in the workbook aren't validated or created during the workbook upload. Instead, the Import Journals process creates the account combinations and performs these validations.
Note: When this option is selected, journals being created aren't checked against third-party control accounts. -
Send Email Notification for Journal Import Failures: If you select one of the import options, you can also receive email notifications for warnings or failures encountered during the journal import process.
Examples of Balancing Validations in Journal Workbook Upload
The Create Journals workbook has validations on the Single Journal and Multiple Journals worksheets. The validations ensure that unbalanced actual journals aren't uploaded when suspense accounting isn't enabled for the ledger or when the Journals: Balanced Spreadsheet Journals Required profile isn't enabled. Validation is affected by the way journals are grouped and classified.
Journal lines are grouped into one journal if the following data is the same:
-
Journal Batch Name and Description
-
Source
-
Journal Name and Description
-
Ledger
-
Category
-
Clearing Company
-
Legal Entity
The legal entity is used as a grouping criterion only when sequencing is enabled at the legal entity level for your ledger.
Journals are classified as single currency journals if all the journal lines have the same data for these fields:
-
Currency
-
Conversion Rate Type
-
Conversion Rate
-
Conversion Date
Any journal which doesn't qualify as a single currency journal is classified as a multicurrency journal. Different criteria is used to validate the balancing of single and multicurrency journals.
A single currency journal is unbalanced if:
-
Entered amounts are not equal or
-
The percentage difference in the accounted amounts is equal to or greater than the Balancing Threshold Percentage on the Specify Ledger Options page.
Journal Validation Examples
Example 1: A single currency journal with unequal accounted debit and accounted credit amounts.
-
On the Specify Ledger Options page, set:
-
Currency: USD
-
Enable Suspense is not checked for General Ledger
-
Balancing Threshold Percent = 1 percent
-
-
Here are the details for the Multiple Journals worksheet:
-
Journal Batch: Year End Adjustments
-
Journal: Bad debt adjustment
-
Ledger: Vision Operations (USA)
-
Accounting Date: 9/30/17
-
Source: Spreadsheet
-
Category: Adjustment
-
Currency for each line: EUR
-
Entered Debit: 240
-
Entered Credit 240
-
Accounted Debit: 270.4
-
Accounted Credit: 270.82
-
This journal has a single currency. The entered debit amount is equal to the entered credit amount, but the accounted debit and credit amounts are different. The percentage difference of the accounted amounts is (0.42/270.82)*100 = 0.155 percent. The percentage difference is less than the 1 percent threshold provided on the Specify Ledger Options page. Hence the journal is balanced.
Example 2: A multicurrency journal that is not balanced by clearing company.
-
On the Specify Ledger Options page, set:
-
Currency: USD
-
Enable Suspense option is not checked for General Ledger
-
Balancing Threshold Percent = 1 percent
-
Enable intercompany accounting option is checked
-
-
Here are the details for the Multiple Journals worksheet:
-
Journal Batch: Intercompany accruals
-
Journal: Rent accruals
-
Ledger: Vision Operations (USA)
-
Accounting Date: 9/30/17
-
Source: Spreadsheet
-
Category: Accrual
-
Currency on all journals line: USD
-
Clearing company on journals lines: 99, 98
-
Total Entered Debit for all journal lines: 2300
-
Total Entered Credit for all journal lines: 2300
-
Total Entered Credit for lines with clearing company 99: 2300
-
Total Entered Debit for lines with clearing company 99: 0
-
Total Entered Credit for lines with clearing company 98: 0
-
Total Entered Debit for lines with clearing company 98: 2300
-
This journal has a single currency and two clearing companies. The clearing company was used as the grouping criterion. The lines with clearing company 99 are grouped into one journal and the lines with clearing company 98 are grouped into another. So although the journal name is the same, the validation evaluates each group of clearing company lines as a separate journal. Both of these journals are unbalanced since one has the credit amount and the other has the debit amount.
How Journals Are Imported
Oracle Fusion Financials reflect the traditional segregation between the Oracle General Ledger and associated subledgers. Detailed transactional information is captured in the subledgers and periodically imported and posted in summary or detail to the General Ledger. You import from the subledgers to the General Ledger in real time or you can import and post automatically based on a defined schedule. Once the data is posted in the General Ledger, the data is available for balance inquiry and reporting.
Use journal import to integrate transactions from other applications such as payroll, accounts receivable, accounts payable, and fixed assets with your General Ledger. You can import ledger currency and foreign currency encumbrance journals, if encumbrance accounting has been enabled for the ledger.
For each accounting period, you import accounting data from the subledger application, then review, update, and post the journal entries. You can also use journal import to import historical data from your previous accounting application. Import data from multiple interface tables by entering a particular source and group ID combination for the data in each interface table. Journal import processes data from one table at a time.
The following table lists the effect of security privileges on the journal import process.
Security Privilege | Journal Import |
---|---|
Control Accounts |
Not blocked. |
Segment Value Security |
If the account combination exists, then no check happens. If the journal import process creates an account combination, then segment value security is enforced. |
Cross-Validation Rules |
If the account combination exists, then no check happens. If the journal import process creates an account combination, then cross-validation rules are enforced. |
Settings That Affect Journal Import
Configure the following settings before running the Import Journals process.
-
Set up your General Ledger to accept journal import data by defining your ledger, currencies, accounts, journal sources, and categories.
-
Optionally, run the Optimizer process to ensure optimal system performance.
-
Define your import process parameters and schedule, if using automatic processing.
-
Set the period status to either future enterable or open. Journals can be created by the journal import process in a future enterable period, but not posted. Posting requires an open period.
-
Export data from your subledgers and populate the General Ledger Interface table.
-
Optionally, enable encumbrance accounting.
How Journal Import Is Processed
Transactions can be imported into General Ledger from Oracle subledgers and legacy applications.
The flow of accounting data includes the following steps:
-
The transaction data entered in both Oracle and legacy application subledgers is imported into the General Ledger Interface table. If the process completes successfully, journal entries are created. If the process fails, the error lines are loaded into the corrections spreadsheet or are deleted using the Delete Journal Import Data process. After correcting the errors or deleting the error lines, run the Import Journals process again.
-
After the journal entries are created in the General Ledger from the imported data, post the journals. The posting process validates the data and records it in both the General Ledger Balances table and the balances cube. Posting errors are listed in the Posting Execution report and can also be viewed in the Journals dashboard and on the Manage Journals page. After correcting the errors, run the posting process again.
-
After posting completes, the data is available for reporting and balance inquiry.
The following figure outlines the flow of accounting data between the subledgers and General Ledger.

Error Codes for Journal Import
Journal import error codes appear in the log file on the Schedule Process page after the import process is run. The codes help identify errors and assist you in correcting the errors.
Journal Import Error Codes
The following table describes the period error codes.
Code | Description |
---|---|
EP01 |
This date is not in any open or future enterable period. |
EP03 |
This date is not within any period in an open encumbrance year. |
EP04 |
This date is not a business day. |
EP05 |
There are no business days in this period. |
The following table describes the unbalanced journal error codes.
Code | Description |
---|---|
WU01 |
This journal entry is unbalanced. It is processed because suspense posting is allowed in this ledger. |
EU02 |
This journal entry is unbalanced and suspense posting is not allowed in this ledger. |
EU03 |
This encumbrance journal entry is unbalanced and the Reserve for Encumbrance account is not defined. |
The following table describes the flexfield error codes.
Code | Description |
---|---|
EF01 |
This account is inactive for this accounting date. |
EF02 |
Detail posting not allowed for this account. |
EF03 |
Disabled account. |
EF04 |
This is an invalid account. Check your cross-validation rules and segment values. |
EF05 |
There is no account with this Code Combination ID. |
EF06 |
The alternate account is invalid. |
WF01 |
An alternate account was used instead of the original account. |
WF02 |
A suspense account was used instead of the original account. |
The following table describes the foreign currency error codes.
Code | Description |
---|---|
EC01 |
A conversion rate must be entered when using the User conversion rate type. |
EC02 |
There is no conversion date supplied. |
EC03 |
A conversion rate type or an accounted amount must be supplied when entering foreign currency journal lines. |
EC06 |
There is no conversion rate for this currency, conversion rate type, and conversion date. |
EC08 |
Invalid currency. |
EC09 |
No currencies are enabled. |
EC10 |
Encumbrance journals cannot be created in a foreign currency. |
EC11 |
Invalid conversion rate type. |
EC12 |
The entered amount must equal the accounted amount in a ledger or statistical currency journal line. |
EC13 |
Amount is too large. |
ECW1 |
Converted amounts could not be validated because the conversion rate type is not specified. |
The following table describes the budget error codes.
Code | Description |
---|---|
EB01 |
A budget version is required for budget lines. |
EB02 |
Journals cannot be created for a frozen budget. |
EB03 |
The budget year is not open. |
EB04 |
This budget does not exist for this ledger. |
EB05 |
The encumbrance_type_id column must be null for budget journals. |
EB06 |
A period name is required for budget journals. |
EB07 |
This period name is not valid. Check calendar for valid periods. |
EB08 |
Average journals cannot be created for budgets. |
EB09 |
Originating company information cannot be specified for budgets. |
The following table describes the encumbrance error codes.
Code | Description |
---|---|
EE01 |
An encumbrance type is required for encumbrance lines. |
EE02 |
Invalid or disabled encumbrance type. |
EE03 |
Encumbrance journals cannot be created in the STAT currency. |
EE04 |
The BUDGET_VERSION_ID column must be null for encumbrance lines. |
EE05 |
Average journals cannot be created for encumbrances. |
EE06 |
Originating company information cannot be specified for encumbrances. |
The following table describes the reversal error codes.
Code | Description |
---|---|
ER01 |
This reversal period name is invalid. Check your calendar for valid periods. |
ER02 |
This reversal period name is invalid. Check your calendar for valid periods. |
ER03 |
The reversal date must be provided. |
ER04 |
This reversal date is not in a valid period. |
ER05 |
This reversal date is not in your database date format. |
ER06 |
Your reversal date must be the same as or after your effective date. |
ER07 |
This reversal date is not a business day. |
ER08 |
There are no business days in your reversal period. |
ER09 |
Default reversal information could not be determined. |
The following table describes the descriptive flexfield error codes.
Code | Description |
---|---|
ED01 |
The context and attribute values do not form a valid descriptive flexfield for Journals - Journal Entry Lines. |
ED02 |
The context and attribute values do not form a valid descriptive flexfield for Journals - Captured Information. |
The following table describes the miscellaneous error codes.
Code | Description |
---|---|
EM01 |
Invalid journal entry category. |
EM02 |
There are no journal entry categories defined. |
EM05 |
The ENCUMBRANCE_TYPE_ID column must be null for actual journals. |
EM06 |
The budget_version_id column must be null for actual journals. |
EM07 |
The statistical amount belongs in the entered_dr or entered_cr column when entering a STAT currency journal line. |
EM09 |
There is no Transaction Code defined. |
EM10 |
Invalid Transaction Code. |
EM12 |
An error occurred when generating sequential numbering. |
EM13 |
The assigned sequence is inactive. |
EM14 |
There is a sequential numbering setup error resulting from a missing grant or synonym. |
EM17 |
Sequential numbering is always used and there is no assignment for this ledger and journal entry category. |
EM18 |
Manual document sequences cannot be used with Journal Import. |
EM19 |
Value Added Tax data is only valid in conjunction with actual journals. |
EM24 |
Average journals can only be imported into consolidation ledgers. |
EM25 |
Invalid average journal column value. Valid values are {Y_CODE, {N_CODE, and null. |
EM26 |
Invalid originating company. |
EM27 |
Originating company information can only be specified when intercompany balancing is enabled. |
EM29 |
You do not have access to this ledger and account combination. |
EM30 |
This primary balancing segment value is not valid for this ledger. |
EM31 |
This management segment value is not valid for this ledger. |
Reverse Journals
Journal Reversals
You can reverse journals manually by selecting a reversal action in the user interface, or you can reverse journals automatically by running a process. Decide which approach is best for journals such as accruals, estimates, errors, temporary adjustments, or reclassifications that require reversal. Reversing journals saves you time and helps prevent data entry errors.
Here are the key areas to understand when reversing journals:
-
Reversal Settings on Journals
-
Manual Journal Reversal
-
Journal Reversal Criteria Sets
-
Automatic Journal Reversal
-
Reversal Synchronization Between a Primary Ledger and Its Secondary Ledgers
Reversal Settings on Journals
You can enter and view a journal's reversal settings in the Reversal tab on the Create and Edit Journal pages:
-
Reversal Period: Accounting period for the resulting reversal journal. Required for reversal.
-
Reversal Date: Applicable only to average daily balance ledgers. Accounting date to be applied to the reversed journal, since that's needed for calculating average balances. For ledgers that aren't average daily balance ledgers, default logic is applied to determine the accounting date for the generated reversal.
-
Reversal Method: Method for reversing amounts in the reversal journal. Select from Change Sign or Switch Debit or Credit. The default setting is Switch Debit or Credit. The Change Sign setting means the reversal puts the original journal amount in the same Debit or Credit column, but with the opposite (negative or positive) sign. The Switch Debit or Credit setting means the amount is moved to the other column. Required for reversal.
-
Reversal Status: View-only state of the journal reversal. For example, Not reversed or Reversed.
You can enter a reversal period and method at any time, even after the journal is posted. If applicable, the following values also display in the Reversal tab:
-
Reversal Journal: If you're reviewing a journal that was reversed, this setting displays the name and link to the reversal journal.
-
Originating Journal: If you're reviewing a reversal journal, this setting displays the name and link for the journal that was reversed.
Manual Journal Reversal
You can manually reverse posted journals that are eligible for reversal on both the Manage Journals and Edit Journal pages. Both pages provide an action to reverse a journal and an action to reverse a batch.
On the Edit Journal page, you can select Reverse from the Batch Actions menu to reverse a journal batch, or you can select Reverse from the Journal Actions menu to reverse a specific journal. On the Manage Journals page, you can select rows in the Search Results section and then select the Reverse Batch or Reverse Journal buttons. To select multiple rows at once, use the Shift or Control key. You can reverse multiple journals of the same batch, or of different batches, or reverse entire journal batches that are eligible for reversal, based on the rows you selected.
Each reversal journal is created in its own reversal batch and the batch name starts with the word Reverses. When you reverse a batch, a single reversal request is submitted. However, the reversal journal for each journal in the reversed batch is still generated in its own journal batch. Reversal journals for journal-level reporting currencies are grouped into the same reversal batch as the corresponding reversal journal of their associated primary or secondary ledger. Reversal journals for subledger-level reporting currencies are grouped into the same reversal batch as their corresponding primary ledger.
Here are some examples of when you might want to use batch reversal.
Scenario | How It Works |
---|---|
You want to reverse all of the journals in a batch that aren't yet reversed, using the same reversal settings. For example, using the same reversal period for ledgers that aren't enabled for average balances, or the same reversal period and date for ledgers that are enabled for average balances. Or, you want to use the same reversal method. |
When you select the reverse batch action, the Reverse Journal Batch window opens. You provide the reversal period, date, or method. The information you enter overrides any reversal settings at the journal level of journals that aren't yet reversed. All journals eligible for reversal are reversed according to what you specified on the Reverse Journal Batch window. |
You specified reversal settings for every journal that's not yet reversed in a batch, and you want to process reversals more efficiently using batch reversal. |
Leave the fields blank on the Reverse Journal Batch window. Each of these journals is reversed according to the journal's reversal settings. |
You specified reversal settings for some, but not all, of the journals that aren't yet reversed in a batch, and you want to process reversals more efficiently using batch reversal. |
Use the Manage Journals page to reverse the batch. Leave the fields blank on the Reverse Journal Batch window. Each of these journals is reversed according to the journal's reversal settings. |
You want to reverse multiple journals from different batches using the reversal settings specified on each journal in these batches. |
Use the Manage Journals page to select the rows for the batches and then select the reverse batch action. Each journal that's eligible for reversal in these batches is reversed according to the journal's reversal settings. |
Journal Reversal Criteria Sets
To provide default reversal settings to a newly-created journal based on the journal's category, or to also proceed with automatically reversing a posted journal, create a journal reversal criteria set and assign it to a ledger. A journal reversal criteria set contains all journal categories with their corresponding reversal settings and can be shared with any number of ledgers.
Here's how to navigate to the journal reversal criteria set page from the Setup and Maintenance work area:
-
Offering: Financials
-
Functional Area: General Ledger
-
Task: Manage Journal Reversal Criteria Sets
The Create Journal Reversal Criteria Set page lists all of the journal categories with default reversal settings. Find the journal categories that you want to specify reversal criteria for and set the values accordingly. This table describes each reversal setting.
Setting | Values | Description |
---|---|---|
Reversal Period |
No Default, Same Period, Next Period, Next Nonadjusting Period, Next Day, Same Day |
Accounting period for the resulting reversal journal. The following values apply only to average balance ledgers: Next Day, Same Day. Selecting those values for a ledger that isn't an average balance ledger is the same as selecting the value No Default. |
Reversal Date |
First Day, Next Day, Last Day |
Day of the accounting period when the journal is to be reversed. A reversal date only applies to average balance ledgers. You must specify a reversal date if you select the following values for the reversal period: Next Nonadjusting Period, Next Period, Same Period. |
Reversal Method |
Change Sign, Switch Debit or Credit |
Method for reversing amounts in the reversal journal. |
Automatic Reversal Option |
None, Reverse Automatically, Reverse and Post Automatically |
Setting that determines whether a journal is selected for automatic reversal, and whether the reversal journal is posted after it's reversed. Unlike the previous settings in this table, which are propagated directly as attributes in the journal, this setting is used to determine the reversal action that's applied when the automatic reversal process is run. |
After you create the journal reversal criteria set, assign it to one or more of your ledgers. Here's how to navigate to the ledger page in the Setup and Maintenance work area where you can assign the journal reversal criteria set:
-
Offering: Financials
-
Functional Area: General Ledger
-
Task: Specify Ledger Options, with the ledger scope set
When you create a journal for a ledger with an assigned criteria set, the journal's reversal period and method are populated according to the criteria setting for that journal's category. This applies to journals entered through the user interface and the Create Journal spreadsheet. You can accept the defaulted reversal values or change them at any time, even after the journal is posted.
Automatic Journal Reversal
The automatic reversal process only selects reversible journals whose categories are enabled for automatic reversal in the journal reversal criteria set that's assigned to the ledger. The automatic reversal option for those categories must be set to either Reverse Automatically or Reverse and Post Automatically.
Here's how you can run the automatic reversal process:
-
Select the Run AutoReverse task from the tasks pane in the Journals work area. The task opens the Scheduled Process page for the AutoReverse Journals process. You might want to run automatic reversals this way for one-time accruals entered in the current period, but tagged to reverse in a later period.
-
Submit or schedule the AutoReverse Journals process on the Scheduled Processes page.
-
Enable the ledger option Run AutoReverse After Open Period on the Specify Ledger Options page. When enabled, the automatic reversal process is submitted with the reversal period choice of All.
Note: If you usually reverse journals on the last day of every month, don't enable this option. Instead, schedule the automatic reversal process to run on the last day of the month. The accounting period parameter automatically increments for each subsequent run.
The automatic journal reversal process creates one journal batch for each journal that's reversed. The names for the reversal batch and reversal journal begin with the word Reverses. The process also produces the AutoReverse Execution report, which prints the name of the journal batch that was submitted for reversal, along with the journal batch accounting period. If the automatic reversal option is set to Reverse and Post Automatically, then the report also provides information about the reversal batch.
If reversal synchronization is enabled (refer to the next section for details), the process generates a journal reversal in the corresponding secondary ledger and the AutoReverse Execution report includes information about the journal reversal batch that's generated in the secondary ledger.
After the process completes, you can review the reports for any problems and verify that all journals were processed properly.
Here are some points to consider if you decide to run the automatic reversal process:
-
If the automatic reversal option on the applicable journal reversal criteria set is set to:
-
Reverse and Post Automatically and journal approval is enabled, journals posted by the process bypass approval.
-
Reverse Automatically, you must manually post the reversal journals.
-
-
If you have an average balance ledger, the automatic reversal process doesn't check that the reversal date is a valid business day. However, the journal validation in the journal pages and the import process perform this check and, if necessary, roll the date to the next business day.
Reversal Synchronization Between a Primary Ledger and Its Secondary Ledgers
If you have secondary ledgers, it's recommended that you enable the primary ledger option Synchronize Reversals Between Primary and Secondary Ledgers. Reversal synchronization helps to ensure that the secondary ledger remains as an accurate alternate representation of its corresponding primary ledger. If you enable this option, a journal reversal (manual or automatic) in the primary ledger triggers the reversal of the corresponding journal in the associated secondary ledger. If you didn't enable this option, you would have to actively manage the reversal of journals in the secondary ledger, whether they were replicated from its primary ledger or created directly in the secondary ledger. To set this option for a primary ledger, use the same navigation as you did for assigning the journal reversal criteria set to the ledger.
Here's how reversal synchronization works with journal approval when you have this setup:
-
You enabled journal approval in both the primary and secondary ledger.
-
You enabled reversal synchronization between the two ledgers.
The reversal journal generated in the secondary ledger (for the primary ledger reversal) won't require a separate approval.
This table shows how journals are reversed in a secondary ledger when synchronization is enabled. Journal reversal depends on how the journals were created in the secondary ledger and on whether a reversal criteria set is assigned to the secondary ledger.
How was the journal that's going to be reversed created in the secondary ledger? | Did you assign a journal reversal criteria set to the secondary ledger? | How is the journal reversed in the secondary ledger? |
---|---|---|
The journal was replicated from the primary ledger. |
Yes |
The journal is reversed automatically when the journal in the primary ledger is reversed. The reversal settings in the primary ledger source journal override any reversal settings on the journal in the secondary ledger that's being reversed. Note: Because the journal was replicated from the primary
ledger, the journal reversal criteria set has no impact on the reversal.
|
The journal was created directly in the secondary ledger. |
Yes |
If the journal category is set for automatic reversal in the secondary ledger's assigned criteria set, you can run the automatic reversal process in the secondary ledger. Otherwise, you must reverse the journal manually. |
The journal was replicated from the primary ledger. |
No |
The journal is reversed automatically when the journal in the primary ledger is reversed. |
The journal was created directly in the secondary ledger. |
No |
You must specify reversal information in the journal and manually reverse the journal in the secondary ledger. |
Once set, the primary ledger option Synchronize Reversals Between Primary and Secondary Ledgers applies to any secondary ledger of the primary ledger. The option Post Journals Automatically from Source Ledger is set by the individual secondary ledgers of the primary ledger and controls automatic posting of secondary ledger journals (reversals and otherwise), when the corresponding primary ledger journal is posted. To set this option, use this navigation in the Setup and Maintenance work area:
-
Offering: Financials
-
Functional Area: General Ledger
-
Task: Complete Primary to Secondary Ledger Mapping, with the primary ledger and secondary ledger scope set
Post Journals
Overview of Journal Posting
Journal posting is a process that updates balances in general ledger accounts to reflect an entity's business transactions and provides data for financial reporting.
Two aspects to consider in journal posting are:
-
Functionally
-
Timing
Functionality
Posting is done from the journals pages by selecting journal entries and clicking the Post button. Automate your posting process by scheduling an automatic posting process to periodically select and post batches. You can start posting from the journal creation spreadsheet in Oracle Fusion Application Development Framework Desktop Integration. You can also start posting through the Import and Post option, which imports the data in the spreadsheet and then runs the posting process. Once you post a journal batch, you cannot modify its contents, including additional descriptive information. You cannot delete posted journals but you can copy or reverse them. To reverse a posted journal, modify the reversal fields in on a posted journal or use the automatic reversal functionality. You can only reverse a journal once.
Timing
Journal entries can be posted to a current or prior accounting period, or to an open prior fiscal year. When you post to a prior period, the general ledger automatically updates the beginning balances of all subsequent periods, even if the period is closed. If you post a journal entry into a prior year, the retained earnings balance is adjusted for the effect on the income and expense accounts. When you finalize the activity for an accounting period, close the period to prevent the entry or posting of additional journal entries.
Automatic or Manual Journal Posting
The two methods for posting journal batches are:
-
Manually from these pages: Create Journal, Manage Journals
-
Automatically using criteria sets, spreadsheet creation, allocation and revaluation processes, or propagation to secondary ledgers
Manual
From the journal pages, click the Post button during the creation process or at a later time. Use this method for manually created journals and other types of journals that are infrequent and unscheduled. Use manual posting after error correction when the initial posting, either manual or automatic, fails to post the journal entry.
All Oracle Fusion General Ledger job roles, except the financial analyst, have predefined function security privileges to enter and post journals. Use journal approval to provide a layer of security for posting, if needed. For example, construct approval rules to require a manager to approve the journal entry before posting is permitted.
Automatic
Select options to automatically post journal entries when using spreadsheet creation, defining allocation and revaluation processes, transferring balances, or propagating journal entries to secondary ledgers.
Create AutoPost criteria sets in advance to automatically post journal entries. These posting criteria sets use the period, source, and category to select the journal entries for posting. Automatic posting is especially important for journal imports because it prevents editing of the journal import data. Editing of such data causes permanent out-of-balance situations between the subledger and the general ledger. Schedule the AutoPost process after journal import processes for increased efficiency.
Statuses for Unposted Journal Batches
All batches that aren't in a Posted status are considered unposted batches. These unposted batches have various statuses, including the following:
-
Incomplete: Batch has been saved but not completed.
-
Selected for Posting: Batch was selected but the posting process hasn't begun.
-
Processing: Posting process is currently running.
-
Error: Statuses assigned to journal batches at the end of the posting process to indicate problems preventing posting. Error statuses are displayed on the Journals work area landing page and General Accounting dashboard, as well as on the Posting Execution report.
Completing a Journal
Incomplete journals are listed on the Incomplete tab of the Journals work area landing page and General Accounting dashboard. You can manually enable the Complete status by clicking the Complete button or the Post button while the journal is still in an incomplete status.
Using the Incomplete Status
Use the Incomplete status to prevent posting of your journal batch while waiting on information or if you haven't completed all the entries within the batch. For example, you have to verify the amounts or accounts entered on the journal, or you have additional journal entries or lines to add. The Incomplete status also prevents the journal batch from being selected for posting by the AutoPost process.
How Account Balances Are Calculated
Account balances, when correctly calculated, create accurate financial statements that an entity can use to report its transactions.
Settings That Affect Account Balances
The initial ledger setup of the primary ledger controls how account balances are calculated. If implemented, accounting representations for secondary ledgers and currency conversion levels for reporting currencies are settings that affect account balances.
How Account Balances Are Calculated
Account balances are calculated when a journal is posted. The following occurs:
-
The application updates the general ledger balances table and the balances cubes, which are based on the chart of accounts and hierarchies, known as trees.
-
Balances are preaggregated in the balances cubes at every level in the account hierarchy for each chart of accounts segment.
-
Balances cubes store both detail and aggregated balances.
-
For each chart of accounts segment, balances are preaggregated at every level in the account hierarchy.
-
-
Foreign currency journal entries update account balances for both the foreign currency that is entered and the amount in the ledger currency that is accounted for during journal entry.
-
If you enable journal or subledger level options for reporting currencies or secondary ledgers, the journal is replicated to the reporting currency or secondary ledger.
-
Reporting currencies offer accounting representations that differ by currency from the source ledger, either primary or secondary. Suspense, rounding imbalances, and intracompany balancing lines are generated independently for each reporting currency at the journal and subledger level by the posting process.
-
Secondary ledgers are additional accounting representations that differ from primary ledgers in either the chart of accounts, accounting calendar, currency, accounting method, or ledger options. For instance, a secondary ledger may be required for local government compliance and reporting. Suspense, rounding imbalances, and intracompany balancing lines are generated independently for each secondary ledger at journal and subledger level by the posting process.
How Single Currency Journals Are Balanced
A journal must balance before it can be posted. If a journal is out of balance when submitted for posting, the posting process can automatically create balancing lines, or add differences to existing lines, depending on your setup.
Settings That Affect Balancing for Single Currency Journals
On the Specify Ledger Options page:
-
You can set these options in the Journal Processing Balancing section:
-
Enable Suspense for General Ledger or Subledger
-
Default Suspense Account
-
Rounding Account
-
Balancing Threshold Percent
Note: The Entered Currency Balancing Account option is only applicable to journals with multiple currencies. -
-
You can set the Enable intercompany accounting option in the Journal Processing Intercompany section and define balancing rules on the Manage Intercompany Balancing Rules page.
On the Manage Suspense Accounts page, you can define suspense accounts for specific journal sources and categories.
How Single Currency Journals Are Balanced
The posting process checks entered amounts, accounted amounts, and balancing segment values in determining whether a journal balances. When a journal doesn't balance, the posting process uses your setup to process the differences and automatically balances the journal. When differences can't be handled automatically, the posting process fails.
The following figure shows the flow that the posting process follows to balance journals that have a single currency.
-
Are entered and accounted amounts in balance, or are accounted amount differences within threshold? If yes, the process continues to step 2. If no, and suspense is enabled, suspense balancing lines are created and the balancing process is complete. If no, and suspense isn't enabled, posting fails.
-
For each balancing segment value, are entered and accounted amounts in balance, or are accounted amount differences within threshold? If yes, the process continues to step 3. If no, and intercompany is enabled, intercompany balancing lines are created and the process continues to step 3. If no, and intercompany isn't enabled, posting fails.
-
Are there any remaining accounted amount differences? If yes, the process continues to step 4. If no, the balancing process is complete.
-
Is the Rounding account defined? If yes, rounding balancing lines are created and the balancing process is complete. If no, the difference is added to the largest line and the balancing process is complete.

The following examples compare unposted journals with the decision points in the flow to illustrate how the journals are subsequently balanced. The first segment in the account combination is the balancing segment, the ledger currency is USD, and the applicable options are set as follows:
-
Enable Suspense: Yes for General Ledger.
-
Default Suspense Account: 101.10.29900.000.000.
-
Rounding Account: None.
-
Balancing Threshold Percent: None for examples 1 through 4. For example 5, this option is set to 1.
-
Enable Intercompany Accounting: Enabled and intercompany rules defined.
Example 1: Entered Amount Differences
The following table shows the lines, accounts, and debits and credits, for an unposted journal in the ledger currency with differences between entered amounts.
Line | Account | Entered (USD) Debit | Entered (USD) Credit |
---|---|---|---|
1 |
101.10.11300.000.000 |
10,000.00 |
|
2 |
101.10.11200.000.000 |
10,000.01 |
|
Total |
10,000.00 |
10,000.01 |
To understand how the journal is balanced, follow the flow:
-
Entered and accounted amounts balanced or accounted amount differences within threshold? No. Entered debits don't equal entered credits.
-
Suspense enabled? Yes. Suspense is enabled for General Ledger and the suspense account is 101.10.29900.000.000. To balance the journal, the posting process creates suspense line 3.
The following table shows the lines, accounts, amounts, and descriptions, for the posted journal.
Line | Account | Entered (USD) Debit | Entered (USD) Credit | Description |
---|---|---|---|---|
1 |
101.10.11300.000.000 |
10,000.00 |
||
2 |
101.10.11200.000.000 |
10,000.01 |
||
3 |
101.10.29900.000.000 |
0.01 |
Suspense line. |
|
Total |
10,000.01 |
10,000.01 |
Example 2: Accounted Amount Differences
The following table shows the lines, accounts, and debits and credits, for an unposted journal in a nonledger currency with differences between accounted amounts.
Line | Account | Entered (GBP) Debit | Entered (GBP) Credit | Accounted (USD) Debit | Accounted (USD) Credit |
---|---|---|---|---|---|
1 |
101.10.11300.000.000 |
10,000.00 |
15,297.54 |
||
2 |
101.10.11200.000.000 |
10,000.00 |
15,297.55 |
||
Total |
10,000.00 |
10,000.00 |
15,297.54 |
15,297.55 |
Follow the posting flow:
-
Entered and accounted amounts balanced or accounted amount differences within threshold? No. Accounted debits don't equal accounted credits and no threshold is defined.
-
Suspense enabled? Yes. Suspense is enabled for General Ledger and the suspense account is 101.10.29900.000.000. To balance the journal, the posting process creates suspense line 3.
The following table shows the lines, accounts, amounts, and descriptions, for the posted journal.
Line | Account | Entered (GBP) Debit | Entered (GBP) Credit | Accounted (USD) Debit | Accounted (USD) Credit | Description |
---|---|---|---|---|---|---|
1 |
101.10.11300.000.000 |
10,000.00 |
15,297.54 |
|||
2 |
101.10.11200.000.000 |
10,000.00 |
15,297.55 |
|||
3 |
101.10.29900.000.000 |
0.01 |
Suspense line. |
|||
Total |
10,000.00 |
10,000.00 |
15,297.55 |
15,297.55 |
Example 3: Entered Amount Differences by Balancing Segment Value
The following table shows the lines, accounts, and debits and credits for an unposted journal in the ledger currency with entered amount differences for each balancing segment value.
Line | Account | Entered (USD) Debit | Entered (USD) Credit |
---|---|---|---|
1 |
101.10.11300.000.000 |
10,000.00 |
|
2 |
102.10.11200.000.000 |
10,000.01 |
|
Total |
10,000.00 |
10,000.01 |
Follow the posting flow:
-
Entered and accounted amounts balanced or accounted amount differences within threshold? No. Entered debits don't equal entered credits.
-
Suspense enabled? Yes. Suspense is enabled for General Ledger and the suspense account is 101.10.29900.000.000. To balance the journal, the posting process creates suspense lines 3 and 4.
The following table shows the lines, accounts, amounts, and descriptions, for the posted journal.
Line | Account | Entered (USD) Debit | Entered (USD) Credit | Description |
---|---|---|---|---|
1 |
101.10.11300.000.000 |
10,000.00 |
||
2 |
102.10.11200.000.000 |
10,000.01 |
||
3 |
102.10.29900.000.000 |
10,000.01 |
Suspense line. |
|
4 |
101.10.29900.000.000 |
10,000.00 |
Suspense line. |
|
Total |
20,000.01 |
20,000.01 |
Example 4: Balancing Segment Values Out of Balance
The following table shows the lines, accounts, and debits and credits, for an unposted journal in the ledger currency that balances in total, but not by balancing segment value.
Line | Account | Entered (USD) Debit | Entered (USD) Credit |
---|---|---|---|
1 |
101.10.11300.000.000 |
10,000.00 |
|
2 |
102.10.11200.000.000 |
10,000.00 |
|
Total |
10,000.00 |
10,000.00 |
Follow the posting flow:
-
Entered and accounted amounts balanced or accounted amount differences within threshold? Yes. Entered debits equal entered credits.
-
Entered and accounted amounts balanced by balancing segment value or accounted amount differences within threshold? No. Balancing segment value 101 has only debits and balancing segment value 102 has only credits and the threshold applies only to accounted amounts.
-
Intercompany enabled? Yes. To balance the journal by balancing segment value, the posting process creates intercompany balancing lines 3 and 4.
The following table shows the lines, accounts, amounts, and descriptions, for the posted journal.
Line | Account | Entered (USD) Debit | Entered (USD) Credit | Description |
---|---|---|---|---|
1 |
101.10.11300.000.000 |
10,000.00 |
||
2 |
102.10.11200.000.000 |
10,000.00 |
||
3 |
102.10.18100.000.101 |
10,000.00 |
Intercompany balancing line. |
|
4 |
101.10.29100.000.102 |
10,000.00 |
Intercompany balancing line. |
|
Total |
20,000.00 |
20,000.00 |
Example 5: Rounding Difference
The following table shows the lines, accounts, and debits and credits, for an unposted journal in a nonledger currency with a difference due to rounding.
Line | Account | Entered (GBP) Debit | Entered (GBP) Credit | Accounted (USD) Debit | Accounted (USD) Credit |
---|---|---|---|---|---|
1 |
101.10.11300.000.000 |
10,000.00 |
15,297.54 |
||
2 |
101.10.11200.000.000 |
4,500.00 |
6,883.89 |
||
3 |
101.10.12110.000.000 |
5,500.00 |
8,413.64 |
||
Total |
10,000.00 |
10,000.00 |
15,297.54 |
15,297.53 |
Follow the posting flow:
-
Entered and accounted amounts balanced or accounted amount differences within threshold? Yes. The difference between the accounted debits and the accounted credits, which is .01, is within the specified threshold of 1 percent.
Note: The threshold is calculating by multiplying the Balancing Threshold Percent setting by the total accounted debits or credits, whichever is greater. In this example, the threshold is 152.98, which is 1 percent of 15,297.54. -
Entered and accounted amounts balanced by balancing segment value or accounted amount differences within threshold? Yes. All lines have a balancing segment value of 101.
-
Accounted amount differences remaining? Yes. The accounted debits are 15,297.54 and the accounted credits are 15,297.53.
-
Rounding account defined? No. To balance the journal, the posting process adds the rounding difference to the largest credit line, which is line 3.
The following table shows the lines, accounts, and amounts for the posted journal.
Line | Account | Entered (GBP) Debit | Entered (GBP) Credit | Accounted (USD) Debit | Accounted (USD) Credit |
---|---|---|---|---|---|
1 |
101.10.11300.000.000 |
10,000.00 |
15,297.54 |
||
2 |
101.10.11200.000.000 |
4,500.00 |
6,883.89 |
||
3 |
101.10.12110.000.000 |
5,500.00 |
8,413.65 |
||
Total |
10,000.00 |
10,000.00 |
15,297.54 |
15,297.54 |
How MultiCurrency Journals Are Balanced
A journal must balance before it can be posted. If a journal is out of balance when submitted for posting, the posting process can automatically create balancing lines, or add differences to existing lines, depending on your setup.
Settings That Affect Balancing for Multicurrency Journals
On the Specify Ledger Options page:
-
You can set these options In the Journal Processing Balancing section:
-
Enable Suspense for General Ledger or Subledger
-
Default Suspense Account
-
Rounding Account
-
Entered Currency Balancing Account
-
Balancing Threshold Percent
-
-
You can set the Enable intercompany accounting option in the Journal Processing Intercompany section and define balancing rules on the Manage Intercompany Balancing Rules page.
On the Manage Suspense Accounts page, you can define suspense accounts for specific journal sources and categories.
How Multicurrency Journals Are Balanced
The posting process checks entered amounts, accounted amounts, balancing segment values, and currencies, in determining whether a journal balances. When a journal doesn't balance, the posting process uses your setup to process the differences and automatically balances the journal. When the differences can't be handled automatically, the posting process fails.
The following figure shows the flow that the posting process follows to balance journals that have multiple currencies.
-
Are accounted amounts in balance, or are accounted amount differences within threshold? If yes, the process continues to step 2. If no, and suspense is enabled, suspense balancing lines are created and the balancing process is complete. If no, and suspense isn't enabled, posting fails.
-
For each balancing segment value, are accounted amounts in balance, or are accounted amount differences within threshold? If yes, the process continues to step 3. If no, and intercompany is enabled, intercompany balancing lines are created and the process continues to step 3. If no, and intercompany isn't enabled, posting fails.
-
Does each balancing segment value balance by entered currency? If yes, the process continues to step 4. If no, and the Entered Currency Balancing account is defined, entered currency balancing lines are created and the process continues to step 4. If no, and the Entered Currency Balancing account isn't defined, posting fails.
-
Are there any remaining accounted amount differences? If yes, the process continues to step 5. If no, the balancing process is complete.
-
Is the Rounding account defined? If yes, rounding balancing lines are created and the balancing process is complete. If no, the difference is added to the largest line and the balancing process is complete.

The following examples compare unposted journals with the decision points in the flow to illustrate how the journals are balanced. The first segment in the account combination is the balancing segment, the ledger currency is USD, and the applicable options are set as follows:
-
Enable Suspense: Yes for General Ledger.
-
Default Suspense Account: 101.10.29900.000.000.
-
Rounding Account: 101.10.78550.000.000.
-
Entered Currency Balancing Account: 101.10.22270.000.000.
-
Balancing Threshold Percent: 1.
-
Enable Intercompany Accounting: Enabled and intercompany rules defined.
Example 1: Accounted Amount Differences
The following table shows the lines, accounts, currencies, and debits and credits, for an unposted multicurrency journal with accounted amount differences.
Line | Account | Currency | Entered Debit | Entered Credit | Accounted (USD) Debit | Accounted (USD) Credit |
---|---|---|---|---|---|---|
1 |
101.10.11300.000.000 |
GBP |
10,000.00 |
15,297.54 |
||
2 |
101.10.11200.000.000 |
ANG |
9,500.00 |
9,500.00 |
||
Total |
10,000.00 |
9,500.00 |
15,297.54 |
9,500.00 |
To understand how the journal is balanced, follow the flow:
-
Accounted amounts balanced or accounted amount differences within threshold? No. The difference between the total accounted debits and total accounted credits is 5,797.54, which isn't within the specified threshold of 1 percent.
Note: The threshold is calculated by multiplying the Balancing Threshold Percent setting by the total accounted debits or credits, whichever is greater. In this example, the threshold is 152.98, which is 1 percent of 15,297.54. -
Suspense enabled? Yes. Suspense is enabled for General Ledger and the suspense account is 101.10.29900.000.000. To balance the journal for each currency, the posting process creates suspense lines 3 and 4.
The following table shows the lines, accounts, currencies, amounts, and descriptions, for the posted journal.
Line | Account | Currency | Entered Debit | Entered Credit | Accounted (USD) Debit | Accounted (USD) Credit | Description |
---|---|---|---|---|---|---|---|
1 |
101.10.11300.000.000 |
GBP |
10,000.00 |
15,297.54 |
|||
2 |
101.10.11200.000.000 |
ANG |
9,500.00 |
9,500.00 |
|||
3 |
101.10.29900.000.000 |
ANG |
9,500.00 |
9,500.00 |
Suspense line. |
||
4 |
101.10.29900.000.000 |
GBP |
10,000.00 |
15,297.54 |
Suspense line. |
||
Total |
19,500.00 |
19,500.00 |
24,797.54 |
24,797.54 |
Example 2: Entered Amounts Out of Balance by Entered Currency
The following table shows the lines, accounts, currencies, and debits and credits, for an unposted multicurrency journal that doesn't balance by entered currency.
Line | Account | Currency | Entered Debit | Entered Credit | Accounted (USD) Debit | Accounted (USD) Credit |
---|---|---|---|---|---|---|
1 |
101.10.11300.000.000 |
GBP |
10,000.00 |
15,297.54 |
||
2 |
101.10.11200.000.000 |
ANG |
9,500.00 |
15,297.54 |
||
Total |
10,000.00 |
9,500.00 |
15,297.54 |
15,297.54 |
Follow the posting flow:
-
Accounted amounts balanced or accounted amount differences within threshold? Yes. Total accounted debits equal total accounted credits.
-
Accounted amounts balanced by balancing segment value or accounted amount differences within threshold? Yes. The balancing segment value for both lines is 101 and total accounted debits equal total accounted credits.
-
Entered amounts balanced by currency and balancing segment value? No. The journal doesn't balance by entered currency. The GBP currency has only debits and the ANG currency has only credits.
-
Entered Currency Balancing account defined? Yes. The Entered Currency Balancing account is 101.10.22270.000.000. To balance the journal, the posting process creates entered currency balancing lines 3 and 4 for each currency.
The following table shows the lines, accounts, currencies, amounts, and descriptions, for the posted journal.
Line | Account | Currency | Entered Debit | Entered Credit | Accounted (USD) Debit | Accounted (USD) Credit | Description |
---|---|---|---|---|---|---|---|
1 |
101.10.11300.000.000 |
GBP |
10,000.00 |
15,297.54 |
|||
2 |
101.10.11200.000.000 |
ANG |
9,500.00 |
15,297.54 |
|||
3 |
101.10.22270.000.000 |
ANG |
9,500.00 |
15,297.54 |
Entered currency balancing line. |
||
4 |
101.10.22270.000.000 |
GBP |
10,000.00 |
15,297.54 |
Entered currency balancing line. |
||
Total |
19,500.00 |
19,500.00 |
30,595.08 |
30,595.08 |
Example 3: Entered Currencies and Balancing Segment Values Out of Balance
The following table shows the lines, accounts, currencies, and debits and credits, for an unposted multicurrency journal that doesn't balance by entered currency or balancing segment value.
Line | Account | Currency | Entered Debit | Entered Credit | Accounted (USD) Debit | Accounted (USD) Credit |
---|---|---|---|---|---|---|
1 |
101.10.11300.000.000 |
GBP |
10,000.00 |
15,297.54 |
||
2 |
102.10.11200.000.000 |
ANG |
9,500.00 |
15,297.54 |
||
Total |
10,000.00 |
9,500.00 |
15,297.54 |
15,297.54 |
Follow the posting flow:
-
Accounted amounts balanced or accounted amount differences within threshold? Yes. Total accounted debits equal total accounted credits.
-
Accounted amounts balanced by balancing segment value or accounted amount differences within threshold? No. Balancing segment value 101 has only debits totaling 15,297.54. Balancing segment value 102 has only credits totaling 15,297.54. Each balancing segment value needs 15,297.54 to balance, which isn't within the threshold.
Note: The threshold is 152.98, which is 1 percent of 15,297.54. -
Intercompany enabled? Yes. To balance the accounted amounts by balancing segment value, the posting process creates intercompany balancing lines 3 and 4 in the USD currency.
-
Entered amounts balanced by currency and balancing segment value? No to both. The GBP currency has only debits and the ANG currency has only credits. Debits don't equal credits for either balancing segment value.
-
Entered Currency Balancing account defined? Yes. The Entered Currency Balancing account is 101.10.22270.000.000. To balance by currency, the posting process creates entered currency balancing lines 5 and 6. To balance by balancing segment value, the posting process creates entered currency balancing lines 7 and 8 in the USD currency.
The following table shows the lines, accounts, currencies, amounts, and descriptions, for the posted journal.
Line | Account | Currency | Entered Debit | Entered Credit | Accounted (USD) Debit | Accounted (USD) Credit | Description |
---|---|---|---|---|---|---|---|
1 |
101.10.11300.000.000 |
GBP |
10,000.00 |
15,297.54 |
|||
2 |
102.10.11200.000.000 |
ANG |
9,500.00 |
15,297.54 |
|||
3 |
101.10.29100.000.102 |
USD |
15,297.54 |
15,297.54 |
Intercompany balancing line. |
||
4 |
102.10.18100.000.101 |
USD |
15,297.54 |
15,297.54 |
Intercompany balancing line. |
||
5 |
102.10.22270.000.000 |
ANG |
9,500.00 |
15,297.54 |
Entered currency balancing line. |
||
6 |
101.10.22270.000.000 |
GBP |
10,000.00 |
15,297.54 |
Entered currency balancing line. |
||
7 |
101.10.22270.000.000 |
USD |
15,297.54 |
15,297.54 |
Entered currency balancing line. |
||
8 |
102.10.22270.000.000 |
USD |
15,297.54 |
15,297.54 |
Entered currency balancing line. |
||
Total |
50,095.08 |
50,095.08 |
61,190.16 |
61,190.16 |
Example 4: Rounding Difference
The following table shows the lines, accounts, currencies, and debits and credits, for an unposted multicurrency journal with a rounding difference.
Line | Account | Currency | Entered Debit | Entered Credit | Accounted (USD) Debit | Accounted (USD) Credit |
---|---|---|---|---|---|---|
1 |
101.10.11300.000.000 |
GBP |
10,000.00 |
15,297.54 |
||
2 |
101.10.11200.000.000 |
ANG |
9,500.00 |
15,297.54 |
||
3 |
101.10.11200.000.000 |
GBP |
10,000.00 |
15,297.54 |
||
4 |
101.10.11300.000.000 |
ANG |
9,500.00 |
15,297.35 |
||
Total |
19,500.00 |
19,500.00 |
30,594.89 |
30,595.08 |
Follow the posting flow:
-
Accounted amounts balanced or accounted amount differences within threshold? Yes. The difference between accounted debits and accounted credits is 0.19, which is within the threshold.
Note: The threshold is 305.95, which is 1 percent of 30,595.08. -
Accounted amounts balanced by balancing segment value or accounted amount differences within threshold? Yes. The balancing segment value for all lines is 101 and the difference between accounted debits and accounted credits is 0.19, which is within the threshold.
-
Entered amounts balanced by currency and balancing segment value? Yes. For each currency, entered debits equal entered credits, and the balancing segment value is the same for all lines.
-
Accounted amount differences remaining? Yes. For the ANG currency, the difference between accounted debits and accounted credits is 0.19.
-
Rounding account defined? Yes. The rounding account is 101.10.78550.000.000. To balance the journal, the posting process creates rounding line 5 for the ANG currency.
The following table shows the lines, accounts, currencies, amounts, and descriptions, for the posted journal.
Line | Account | Currency | Entered Debit | Entered Credit | Accounted (USD) Debit | Accounted (USD) Credit | Description |
---|---|---|---|---|---|---|---|
1 |
101.10.11300.000.000 |
GBP |
10,000.00 |
15,297.54 |
|||
2 |
101.10.11200.000.000 |
ANG |
9,500.00 |
15,297.54 |
|||
3 |
101.10.11200.000.000 |
GBP |
10,000.00 |
15,297.54 |
|||
4 |
101.10.11300.000.000 |
ANG |
9,500.00 |
15,297.35 |
|||
5 |
101.10.78550.000.000 |
ANG |
0.19 |
Rounding line. |
|||
Total |
19,500.00 |
19,500.00 |
30,595.08 |
30,595.08 |
Create an AutoPost Criteria Set
In this example, you're creating an AutoPost criteria set to post the general ledger journal entries created by journal import for your subledger transactions.
Here's the relevant setup for your Vision Corporation ledger.
-
You implemented Oracle Fusion General Ledger and the subledgers Oracle Fusion Payables and Oracle Fusion Receivables.
-
You use a non-Oracle subledger called Fast Assets for fixed asset tracking and depreciation.
-
You plan to automate posting of general ledger journal batches created by journal import. The automation is to protect the subledger-sourced journal entries from edits or deletion that could cause an out-of-balance situation between the subledgers and general ledger.
Consider these points when creating a criteria set:
-
Use the All option for category and accounting period to reduce maintenance and ensure that all journal imports are included in the posting process.
-
Create a criteria set that includes all your subledger sources. Create multiple criteria sets by source only if you must schedule different posting times to balance close activities or reduce processing time.
Create the Set
-
Go to the following:
-
Offering: Financials
-
Functional Area: General Ledger
-
Task: Manage AutoPost Criteria Sets
-
-
Click Create.
-
Enter this name: All Journal Imported Entries.
-
Enter this description: Posting journals imported from the subledgers.
-
Select Enabled.
-
Select the Use Batch Creator as Approval Submitter check box if you require keeping the creator of the journal batch as the user who submitted the batch for approval when the AutoPost Journals process runs. If you don't select this check box, the user running the AutoPost journals process is the submitter for approval.
-
Enter these values and click Add Row to add each new line.
Priority Ledger or Ledger Set Source Category Accounting Period Balance Type 1
Vision Corporation
Payables
All
All
All
2
Vision Corporation
Receivables
All
All
All
3
Vision Corporation
Fast Assets
All
All
All
-
Select Yes for the Process All Criteria check box, and enter 30 as the number of days before and after the submission date. The process runs less often when you specify a wide range.
-
Click Save and Close.
Tip: Schedule the process to run immediately after the Import Journals process to prevent changes to the journals. Run the process during nonpeak times to save resources.
Examples of Manually Running the AutoPost Process
Create an AutoPost criteria set and schedule the AutoPost Journals process to run on a regular basis following your scheduled journal imports from your subledgers. When errors occur that prevent posting of the journal imports, you must correct the errors and manually run the AutoPost process. The following scenarios illustrate the kinds of errors that could occur and how you can resolve these errors.
Scenario
The following table lists the errors that prevented journal batches from posting when the scheduled AutoPost Journals process ran.
Error | Cause | Solution |
---|---|---|
Unopened accounting period |
The journal import was imported into a future period. An error arises when the AutoPost Journals process runs on a schedule because journals can't be posted in a future period. |
Open the period. |
Invalid or no journals |
Journal import fails to import transactions from the general ledger interface table. The AutoPost Journals process runs on schedule but finds no batches to post. The posting process doesn't run and the AutoPost Execution report shows that no batches matched the criteria. |
Correct the error that caused the journal import to fail. |
Invalid or no journals |
No journals were selected based on the posting criteria. Journal batches are available for posting. The posting process doesn't run and the AutoPost Execution report shows that no batches matched the criteria. |
Revise the criteria set. |
After you correct the errors:
-
Manually run the AutoPost Journals process by selecting the Run AutoPost option from the Tasks panel on the journal pages.
-
Click Generate on the AutoPost criteria set pages.
-
Verify that the process ran successfully by reviewing the AutoPost Execution report.
Journal Batch Summary Report
Use the Journal Batch Summary report to review your posted journal batches for a particular ledger, balancing segment value, currency, or date range.
The report provides data on:
-
Actual balances for your journal batches, sources, and posting dates
-
Total entered debits and credits
-
Journal batches within each journal entry category
Run the report from the Manage Journal Task Panel and optionally schedule the report to run periodically.
Before running this report, you must:
-
Approve all journals batches
-
Post all journals batches
-
Optionally, close the accounting period to ensure no further journal batches are entered
- Ledger Set
-
To obtain a consolidated report across all ledgers, you must enter a ledger set representing all ledgers.
- Balancing Segment Value
-
Leave the Balancing Segment Value parameter blank.
- Currency
-
Enter a currency.
- Start and End Date
-
Enter the accounting period date range.
Report Across All Ledgers
- Ledger Set
-
To obtain a report on a specific ledger or entity, you must enter the value for that ledger.
- Balancing Segment Value
-
Leave the Balancing Segment Value parameter blank.
- Currency
-
Enter a currency.
- Start and End Date
-
Enter the accounting period date range.
Report on a Specific Ledger
- Ledger Set
-
To obtain a report on a specific ledger or entity, you must enter the value for that ledger.
- Balancing Segment Value
-
Enter the value representing the entity in the Balancing Segment Value parameter.
- Currency
-
Enter a currency.
- Start and End Date
-
Enter the accounting period date range.
Report on a Specific Entity
Report Results
The report provides data on Actual balances for your journal batches by sources, batches, posting dates, and total entered debits and credits. The report sorts the data by journal batch within each journal entry category. In addition, totals are provided for each journal category and a grand total for each ledger and balancing segment value combination selected.
Approve Journals
Considerations for Defining Journal Approval Rules
Use approval management to define policies that apply to the journal approval workflow.
Rule Definition Consideration
One predefined approval rule exists for journal approval. If a journal's ledger and source are enabled for approval, then that journal is sent for one level of approval to the supervisor of the person who submitted the journal for approval. You can configure journal approval rules in the Business Process Management Worklist application. Open the application by selecting the Notifications icon on the home page and clicking More Details or, by using the following in the Setup and Maintenance work area:
-
Offering: Financials
-
Functional Area: Application Extensions
-
Task: Manage Task Configurations for Financials
For a simple approval scenario, start by defining one or all of the following journal approval rules based on:
-
The highest journal line amount per ledger per batch.
-
The highest journal amount per ledger per batch.
-
Your stage in the period close process. For example, are you in the beginning, middle, or end of the month, or in preclose, close, post close, or quarter close process?
The following table provides an example of rule conditions and approval actions that route a journal approval based on maximum journal line amounts.
Condition | Approval Action |
---|---|
Less than 50,000 USD |
No approval required |
Between 50,000 and 100,000 USD |
One level of approval required |
Greater than 100,000 USD |
Two levels of approval required |
You can build your rules for combinations of ledger, entered amount, approval level, or other scenarios. In addition, you can define rules based on attributes from different parts of your journal, including the ledger, batch, header, or line level. For example, you can use category, source, account, or descriptive flexfield information as selection criteria for journal approval.
Approvals List Builder Considerations
List builders are the way approvals management builds the list of approvers required for a transaction based on the rule condition. Each approval rule is associated with a list builder for generating the list of approvers.
The following table describes the list builders you can use to build a journal approval list.
List Builder | Description |
---|---|
Supervisory |
Based on the employee supervisory hierarchy, which is defined in HCM. Employees must be set up with appropriate jobs and supervisors. For example, a clerk reports to a manager, who reports to the director. |
Job Level |
Based on the job level, which is defined in HCM. Employees must be set up with the appropriate job levels and supervisors. For example, a job level 1 employee, a clerk, reports to a job level 2 employee, a manager, who reports to a job level 4 employee, a director. The approval list is generated based on the starting position specified in the rule and continues until an approver with a sufficient job level is found. The supervisory hierarchy must be defined along with the corresponding job levels. |
Position |
Based on the position hierarchy, which is defined in HCM. The position hierarchy must be defined and employees must be assigned the corresponding positions. Use this hierarchy if you need a hierarchy that's different from the supervisory hierarchy, or multiple hierarchies selected based on different attributes. |
Approval Group |
Consists of a static predefined set of users configured to act on a task. For example, you can create an approval group called Finance Group, consisting of users from the finance department who must participate in the task approval. |
Resource |
Builds the approvers list by using a specific user, enterprise group or application role. |
Other Considerations
Other functionality to consider before defining approval rules.
-
Both the ledger and journal source must be enabled for the approval process.
Caution: You should not enable journal approval for journals that come from subledgers (with subledger journal sources). Otherwise, if a journal from a subledger isn't approved, the journal can get stuck in the approval process. For any subledger journal sources, approvals for subledger transactions should be done in the subledgers themselves. -
Approval is for the entire journal batch, regardless of the attributes used in the approval rules.
-
If a journal requires approval, submitting a journal for posting automatically routes the journal for approval before posting.
-
A journal can be escalated to an approver by the administrator.
-
The task initiator can select Withdraw Approval on the Journals page at any time in the approval process to withdraw journals from the process. Clicking this button enables editing of the journal. After your changes are made, submit the entry for approval again. When a journal is withdrawn, the completion status is set to Incomplete.
-
Approval notifications display a table of key journal attributes for each journal and a list of past, current, and future approvers.
-
The Journals work area displays journals requiring your approval and journals pending approval from others.
-
If you're the current approver, the Journals page shows the journals to be approved or rejected.
-
Allocation journals aren't routed through the approval process.
-
You can review the details of the journals and journal lines included in a journal batch on the online and email journal batch approval notifications.
Create Journal Approval Rules Using a Spreadsheet
Create Workflow Rules Using a Spreadsheet
The Simplified Workflow Rules Configuration feature is a spreadsheet based alternative to creating rules in Oracle Business Process Management (BPM). You can use spreadsheet templates available on the Manage Workflow Rules in Spreadsheet page to manage rules for Financials application workflows.
To create workflow rules in a spreadsheet, perform the following steps:

-
Sign in and navigate to the Manage Workflow Rules in Spreadsheet task.
-
Download the rule template from the Rule Templates section of the Manage Workflow Rules in Spreadsheet page.
-
Define the workflow rules in the spreadsheet.
-
Generate the rule file.
-
Upload the rule file to create rules.
-
Verify the spreadsheet upload.
Manage Workflow Rules Using a Spreadsheet
Before creating and managing workflow rules, perform these steps:
-
Sign in to the application as a Financial Application Administrator.
-
Verify if the Approval Routing Administration feature is enabled at Offerings > Financials > Opt In Features. Click the Edit icon for Financials. If the feature isn't enabled, select its check box.
-
In the Setup and Maintenance work area, go to Financials > Application Extensions > Manage Workflow Rules in Spreadsheet task.
Download the Rules Template
Download the rule template by performing these steps:
-
In the Rule Templates section of the Manage Workflow Rules in Spreadsheet page, select the required workflow.
-
Click Download. The Download Templates dialog box appears.
-
From the dialog box, select the required template. Save the template to your local computer.
Define the Rules in the Spreadsheet
After downloading the rule template, you must define the workflow rules using the sheets provided in the rule template. Here's a list of sheets you can see in the rule template spreadsheet:
-
Instructions: This sheet contains details of the help topics present on Oracle Help Center for this feature and the Generate Rule File button. You can also update your rule template version from the Instructions sheet.
-
Workflow Rules: Provides a template for configuring transaction approval rules.
Note: The name of this sheet varies for each product. For example, for Payables, the sheet is labeled as Invoice Approval Rules. -
Data Set: This sheet provides a template to map the varying attributes to the data.
Note: Currently, data sets are only available for Payables workflows. For more information about data sets, refer to the Data Sets section.
A business rule is an approval requirement within your approval policy. Before defining rules in the rule template, you must analyze approval policy. Consider these points before defining a business rule:
-
Which transactions require approval?
-
Who approves transactions in your organization?
-
Do the approvers vary based on the transaction attributes? If so, use a data set.
-
What are approval conditions?
-
How do you want to route the approval notifications?
-
Which approvals require FYI notifications?
-
Which transactions are exempted from the approval rule?
For example, for Payables, if your organization's approval policy mandates that:
-
All invoices that aren't matched to a purchase order must be approved at two levels of the supervisory hierarchy. This hierarchy starts from the manager of the user who creates the invoice.
-
All invoices that have an invoice amount of more than 5000 USD must be approved by a group of personnel from the Finance department.
For this example, you need two business rules.
Use the Workflow Rules sheet to define approval rules. Enter these details:
-
Rule Description
Enter the description for each approval business rule that you define.
-
Approvers
In this section, designate approvers and specify approval routing. The template supports a variety of approval routing options. This table provides you details on approval routing and how it works.
Approval Routing How Approval Routing Works Supervisory Hierarchy
Members of the supervisory hierarchy beginning from the first applicable approver receive approval notifications.
Group in Parallel
Members of an approval group receive approval notifications. All members receive notifications at the same time. All members must take an action on the approval notification.
Group in Serial
Members of an approval group receive approval notifications. Only when a member takes an action on the approval notification does the next member of the series receive the approval notification.
Group First Responder
Members of an approval group receive approval notifications. All members receive notifications at the same time. Only one member is required to take an action on the approval notification.
Job Level Hierarchy
Members of the job hierarchy beginning from the first applicable approver receive approval notifications.
User
The specified application user receives the approval notification.
Role
The users with the specified application role receive the approval notification.
Auto Approve
Transactions that are automatically approved. No notifications are sent.
Auto Reject
Transactions that are automatically rejected. No notifications are sent.
FYI
Information only notifications. No action is required from the approver.
Skip Approval
Transactions for which the rule isn't applicable. No notifications are sent.
Note: You can only use an approval group that exists in the BPM.For detailed instructions on the other columns in the Approvers section, refer to the tool tip on each column header.
-
Approval Conditions
In the Approval Conditions section you can select the attributes based on which the transaction should be evaluated for the workflow rules. You can also add attribute categories.
To add an attribute category:
-
Open the list of values associated with the last column in the Approval Conditions section.
-
Select the required attribute category.
To add an attribute:
-
Open the list of values associated with the attribute category.
-
Select the required attribute.
For example, in the Invoice Approval template for Payables, you can select Business Unit and Invoice Amount attributes for the attribute category Invoice Header. Similarly, you can select attributes for categories, such as Invoice Line, Invoice Distributions, and more.
While defining approval conditions, you can use a variety of operators. This table lists the supported operators.
Condition Value Type Format Example Attribute is a specific value
Text, number, or date
value
Note: No specific format applies here.If the Invoice Type is Standard, then enter the value as:
Standard
Attribute value is one of multiple specific values
Text or number
in (value 1, value 2, ...)
If the BU name is Vision Operations, Vision Services, or Vision Foods then enter the value as:
In (Vision Operations, Vision Services, Vision Foods
Attribute value should be within a range of values
Number or date
between value 1 and value 2
OR
value 1 to value 2
If the Invoice Date is between 01 August 2018 to 01 August 2019, then enter the value as:
Between 01/aug/2018 and 31/aug/2019
OR
01/aug/2018 to 31/aug/2018
Attribute value starts with a specific value
Text
Starts with value
If the BU name starts with Vision then enter the value as:
Starts with Vision
Attribute value ends with a specific value
Text
Ends with value
If the BU name ends with Operations then enter the value as:
Ends with Operations
Attribute value contains a specific value
Text
Contains value
If the Pay Group contains Standard then enter the value as:
Contains Standard
Attribute value matches a specific value
Text
Matches value
If the Description matches manual invoice then enter the value as:
Matches manual\\s(.*) invoice
In this example, the Matches operator begins with Manual and ends with Invoice. Between the two words, there can be one space and any character.
Other options that can be used with the Matches operator are:
(.*)
- Denotes zero or more characters.(.+)
- Denotes one or more characters.\\s
- Denotes space.\\d
- Denotes numbers from 0-9.?
- Makes a character optional. For example:\\d?
[ ]
- Specifies range such as A-Z, 0-9Attribute value is more than or equal to a specific number
Number
More than equal to number
OR
>= number
If the Invoice amount is more than or equal to 500, then enter the value as:
More than equal to 500
OR
>= 500
Attribute value is less than or equal to a specific number
Number
Less than equal to number
OR
<= number
If the Invoice amount is less than or equal to 500, then enter the value as:
Less than equal to 500
OR
<= 500
Attribute value is more than a specific number
Number
More than number
OR
>number
If the Invoice amount is more than 500, then enter the value as:
More than 500
OR
>500
Attribute value is less than a specific number
Number
Less than number
OR
<number
If the Invoice amount is less than 500, then enter the value as:
Less than 500
OR
<500
Attribute value is on or before a specific date
Date
On or before date
If the Invoice date is on or before 01/10/2018, then enter the value as:
On or before 01/oct/2018
Attribute value is on or after a specific date
Date
On or after date
If the Invoice date is on or after 01/10/2018, then enter the value as:
On or after 01/oct/2018
Attribute value is before a specific date
Date
Before date
If the Invoice date is before 01/10/2018, then enter the value as:
Before 01/oct/2018
Attribute value is after a specific date
Date
After date
If the Invoice date is after 01/10/2018, then enter the value as:
After 01/oct/2018
Attribute value is a specific value and the condition must be evaluated as case insensitive
Text
Equals ignore case value
If the Invoice Source is equal to Manual, then enter the value as:
Equals ignore case manual
Note: The operators aren't case-sensitive. However, you must enter the date in the DD/MMM/YYYY or DD-MMM-YYYY format only.If you have a negative approval condition, add Not as a prefix to any of the supported operators. For example, your approval condition states that BU name isn't Vision Operations, Vision Services, or Vision Foods then enter the value as: Not In (Vision Operations, Vision Services, Vision Foods).
If you have two distinct rule conditions that require the same approval routing, then you must enter the rule conditions in two separate rows. Ensure that the information in the Approvers section is identical for both the rows.
-
Rule Blocks
A rule block is a group of rows in the workflow rules spreadsheet. You can define a business rule and all aspects of the business rule in these rows. Use a separate block for each business rule.
While all rule aspects defined within a rule block are processed simultaneously, rule blocks are processed in sequence. Therefore, before defining the rules, you must consider the sequence in which the rules should be processed.
You can create additional rows in a block and additional blocks in a sheet as needed.
To insert more blocks in a rule block:
-
Select a row.
-
Right-click and select Add Block.
To add a rule block after the existing rule blocks, click Add Block in the sheet.
To insert more rows in a rule block:
-
Select a row and right-click.
-
From the menu, select Insert.
To delete a rule block:
-
Select all the rows in a rule block.
-
Right-click and select Delete Block.
Data Sets
In your approval policy, if the approver of a transaction varies based on the transaction attributes, then you should use a data set. A data set lets you define a mapping between your data and the variation in approvers based on such data.
For example, a transaction with an amount greater than 5000 USD must be approved by an approval group. However, the approval group varies depending on the cost center. In this case, you can use a data set to define a mapping between the cost center and the approval group.
To define a data set, perform these steps:
-
Open the Data Set sheet of the rule template.
-
In the Set Name column, enter a unique name.
-
Enter the value in the Approval Group/Supervisory Level/Job Level Range/User/Role column. This value depends on the approval routing of the rule for which you're using the data set.
For the given example, specify the approval group name in the Approval Group/Supervisory Level/Job Level Range/User/Role column.
Note: You can only use an approval group that already exists in the BPM. -
If your starting approver for rules using Supervisory or Job Level Hierarchy approval routing varies based on transaction attributes, then click Add Start Approver to add the Start Approver column in the dataset. You can select any of the values from the list of values or directly enter a user name as the start approver.
Note: If you're specifying start approver in the dataset, then you must select a value of Use Dataset in the Start Approver column of the Approvers section in the Invoice Approval Rules or Invoice Request Approval Rules sheet as applicable. This ensures that the Start Approvers are picked up from the dataset for such rules. -
In the Varying Attribute section, select the attributes based on which the approver varies for the transaction.
For the given example, select Distribution Cost Center Segment from the list of values and specify the cost center values for each approval group.
-
Enter values for each varying attribute. You can also use the supported operators with the values.
-
Click Add New Column to create additional columns for varying attributes.
-
Click Add Data Set to create additional data sets.
After you create a data set, you must enter a data
set reference in your rule in the Workflow Rules sheet. Prefix the
data set name with $
to create a reference.
For example, to reference a data set named Supervisory, enter the
value as $Supervisory Set
in the Workflow
Rules sheet.
You can enter the data set references in the Approvers section of the Workflow Rules sheet. Based on the approval routing used for the rule, enter data set references in these columns:
-
Job Level Range
-
Approval Level
-
Group/User/Role Name
Generate Rule File
After entering the data in the Workflow Rules sheet, click the Generate Rule File button located in the Instructions sheet to generate the rule file. A compressed file is generated. Save the file in your local computer.
Upload the Rule File
To upload the rule file, perform the following steps:
-
Navigate to the Manage Workflow Rules in Spreadsheet page.
-
In the Rule Templates section, select the required workflow.
-
Click Upload. The Upload File dialog box appears.
-
In the File field, click Choose File.
-
From your local directory, select the compressed rule file that was generated from the workflow rules template.
-
Click Submit. A confirmation message stating the process ID appears.
Caution: Every successful rule upload using a spreadsheet template overrides the existing rules for the workflow. -
Click OK.
-
Check the status of the upload in the Upload History section.
Update the Rule Template Version
While uploading your rule template, if you're asked to update the file version, perform the following steps:
-
Download the latest version of the rule template from the Manage Workflow Rules in Spreadsheet page. You can select any of the available templates for the workflow.
-
In the Instructions sheet of the rule template, click Update Spreadsheet.
-
Select the older version of the rule template and click OK.
This copies rules from the older version of your rule template to the latest version.
-
Review the copied rules and proceed as usual to create rules using the latest version of the rule template.
Verify the Spreadsheet Upload
The Upload History section displays details of the spreadsheet uploads such as the date, user, rule template used, and the status.
If the rule upload process fails, the status is displayed as Error. Click Error to download the Error CSV file. Review the error details, resolve the errors in the spreadsheet, and generate the rule file again.
Migrate Workflow Rules to Simplified Workflow Rules Configuration Templates
Import existing rules from Oracle Business Process Management (BPM) directly into spreadsheet-based templates.
You can then use the spreadsheet to view and update these rules, before uploading this spreadsheet back on the Manage Rules in Spreadsheet page. Previously, BPM rules had to be manually entered into the spreadsheets to use the Simplified Workflow Rules Configuration feature.
At present, you can use this feature to migrate rules for these workflows:
-
Payables Invoice Approval
-
General Ledger Journal Approval
Here's how you migrate BPM rules to a Simplified Workflow Rules Configuration spreadsheet:
-
Download a BPM rules file.
-
Import the rules from the BPM rules file into the Simplified Workflow Rules Configuration template for the workflow.
Download BPM Rules File
Perform these steps to download a file that contains the BPM rules:
-
Go to the Manage Workflow Rules in Spreadsheet page.
-
In the Migrate Rules from BPM section, click Download BPM Rules.
-
On the Download BPM Rules dialog box, select the workflow for which you want to download the rules.
-
Click OK.
A copy of your current rule configuration for a workflow is saved in UCM when you successfully download it for the first time. The configuration copy is used to restore the rules back to this state after migration.
Import Rules to Simplified Workflow Rules Configuration Spreadsheet
Here’s how you import the downloaded rules into a Simplified Workflow Rules Configuration spreadsheet:
-
Go to the Manage Workflow Rules in Spreadsheet page.
-
In the Rule Templates section, select any of the available templates for a workflow and click the Download icon in the same row.
-
Open the downloaded file and go to the Instructions sheet.
-
Click the Import Rules button and then select the BPM rule file downloaded previously. This imports your BPM rules into the spreadsheet.
Once the rule migration has completed, you can review the rules and proceed to use this template to view and modify the rules. Once you’re done, go to the Instructions sheet and generate the rule file. Next, upload the rule file on the Manage Workflow Rules in Spreadsheet page. The migration process is completed only after a successful upload.
Restore Rules
Use the Restore Rules feature to restore the rules to their previous state (the way they were when the BPM rules file was first downloaded).
Here’s what you do to restore the rules:
-
Go to the Manage Workflow Rules in Spreadsheet page.
-
In the Migrate Rules from BPM section, click Restore Rules.
Note: The Restore Rules button is enabled only when there is at least one workflow for which a BPM rule file has been successfully downloaded at least once previously. -
On the Restore Rules dialog box, select the workflow for which you want to restore the rules.
-
Click OK.
After you confirm this action, the configuration file stored in UCM is used to restore the workflow rules to the state before migration.
Modify Workflow Rules Using a Spreadsheet
After creating the rules using a spreadsheet template, you can modify them using a spreadsheet.
To modify workflow rules using a spreadsheet, perform the following steps:
-
Navigate to the Manage Rules in Spreadsheet page.
-
In the Rule templates section, select the required workflow.
-
For the workflow, select the link in the Last Successful Upload column. Save the copy of the last successfully uploaded rule template to your local computer.
-
Make the necessary changes in the spreadsheet and click Generate Rule File. A compressed file is generated. Save the generated rule file in your local directory.
-
On the Manage Rules in Spreadsheet page, select the required workflow in the Rule Templates section.
-
Click Upload. The Upload File dialog box appears.
-
In the File field, click Choose File.
-
From your local directory, select the compressed rule file to be uploaded for the rule creation that was generated from the workflow rules template.
-
Click Submit. A confirmation message stating the process ID appears.
-
Click OK.
-
Check the status of the upload in the Upload History section.
Note: If the upload fails, the status is displayed as Error. Click Error to download the Error CSV file. Review the error details, resolve the errors, and generate the rule file again.
Workflow Rule Templates for Journal Approval
The Simplified Workflow Rules Configuration feature enables you to create rules for the General Ledger Approval workflow using a spreadsheet. You can select from among the available sample templates in the Download column on the Manage Workflow Rules in Spreadsheet page:
-
Journal Approval Basic Template
-
Journal Approval Sample Template 1
-
Journal Approval Sample Template 2
Each template contains two worksheets: Instructions and Journal Approval Rules. The Journal Approval Rules worksheet contains sample rules. You can modify them or define your own rules.
You use the templates to create approval rules in accordance with your approval policy. Each sample template contains use cases that you can refer to. You can define your specific rules using any of the templates.
Journal Approval Basic Template: Supervisory Hierarchy-Based Approval
The rule in this template demonstrates the following approval policy requirement:
-
All journal batches require approval from the direct supervisor of the user submitting the batch for approval.
You don't have to make any changes to this rule to use it.
Journal Approval Sample Template 1: Group-Based Approval
The rules in this template demonstrate the following approval policy requirement:
-
All journal batches from a specific ledger and from the specific journal sources require approval from one user of the nominated approval groups. The approval group is different when the journal batch has been created by some nominated users and has some specific description.
-
Journal batches from sources other than these sources are automatically rejected.
The business rule from the approval policy is represented in one block in this template with four listed rules.
To use these rules, ensure:
-
The approval groups that you enter in the spreadsheet are defined in the approval management application.
-
The specified users are valid.
-
The specified ledger ID is valid.
Journal Approval Sample Template 2: Supervisory Hierarchy and Group-Based Approval
The rules in this template demonstrate the following approval policy requirement. The business rules are represented in multiple blocks depending on the business requirement and the approval routing.
-
First block: All journal batches for journal sources Manual, AutoCopy, and Spreadsheet, and with a total batch amount greater than 250000, require supervisory approval. Any batch from those same sources with a total batch amount up to 250000 is automatically approved. Journal batches from sources other than these sources don't require this type of approval.
-
Second block: All journal batches with a total batch amount up to 250000 for journal sources Allocations, Revaluation, and Balance Transfer, require approval from any one member of the designated approval group. All journal batches with a total batch amount up to 250000 for journal sources other than these sources don't require this type of approval. All journal batches with a total batch amount greater than 250000 don't require this type of approval.
-
Third block: All journal batches with a total batch amount greater than 250000 for the journal sources Allocations, Revaluation, and Balance Transfer, require approval from all members of the designated approval group. All journal batches with a total batch amount greater than 250000 for journal sources other than these sources don't require this type of approval. All journal batches with a total batch amount up to 250000 don't require this type of approval.
To create rules for these business rules, you must first analyze and separate the requirements into distinct rules. All the rules that are included in a block must be collectively exhaustive. It's important that all approval scenarios are defined. If not, errors might occur.
The following table displays the details of the rules that are created to enforce the business requirement presented in the first block in this sample template.
Rule Name | Approval Routing | Approval Condition Attribute | Approval Condition Operator |
---|---|---|---|
Source_amount up to 250000 |
Auto Approve |
Journal Batch Total Accounted Credit |
<=250000 |
Journal Source Name |
in (Manual, AutoCopy, Spreadsheet) |
||
Source_amount up to 250000_other source |
Skip Approval |
Journal Batch Total Accounted Credit |
<=250000 |
Journal Source Name |
not in (Manual, AutoCopy, Spreadsheet) |
||
Source_amount greater than 250000 |
Supervisory |
Journal Batch Total Accounted Credit |
>250000 |
Journal Source Name |
in (Manual, AutoCopy, Spreadsheet) |
||
Source_amount greater than 250000_other source |
Skip Approval |
Journal Batch Total Accounted Credit |
>250000 |
Journal Source Name |
not in (Manual, AutoCopy, Spreadsheet) |
The same logical process is followed to define rules for the remaining approval policy requirements.
To use this rule, ensure the approval groups that you enter in the spreadsheet are defined in the approval management application.
Approval Conditions in Journal Approval Rule Templates
For the journal approval workflow, approval conditions define the criteria that a journal batch is evaluated against. The approval conditions are defined using the attributes available in the drop-down list of each attribute category. There are three default attribute categories: Journal Batch, Journal Header, Journal Line.
You can use the predefined approval conditions in the sample rule templates, or you can modify the conditions to meet your company approval policy requirements.
In addition to the attribute categories displayed in the rule templates, you can add more attribute categories by selecting the drop-down list after the last displayed attribute category.
Here's the list of attribute categories that you can use to define your approval conditions:
-
Journal Batch Approval Requester
-
Journal Batch Creator
-
Journal Batch Ledger
-
Journal Batch Source
-
Journal Category
-
Journal Calendar
-
Journal Header
-
Journal Line
-
Maximum Amount Journal
-
Maximum Amount Journal Line
-
Period
-
Submitted Period
Each attribute category has its own set of attributes that you can select from.
Rule Evaluation Currency Attribute
To create workflow rules that should be evaluated in a specific currency, enter the currency using the attribute Rule Evaluation Currency. The attribute is available for these attribute categories:
-
Journal Header
-
Journal Line
-
Maximum Amount Journal
-
Maximum Amount Journal Line
Specify the currency value following the ISO 4217 standard. The resulting rules that are created apply Corporate as the rate type and the Accounting Date as the rate date for evaluating transactions that satisfy rule conditions.
Create Journal Approval Rules Using Oracle Business Process Management
You can use the Business Process Management Worklist application to configure journal approval rules. For example, you can create journal approval rules that automatically approve a journal batch, or that route the batch for approval based on the ledger and journal amounts.
This procedure creates the following approval rules:
-
When the largest journal amount in a batch is more than 500, and less than 10,000, the batch requires one level of supervisory approval.
-
When the largest journal amount is 10,000 or more, two levels of supervisory approval are required.
-
If the largest journal amount in a batch is 500 or less, the batch doesn't require approval or it's automatically approved.
Create a Rule That Requires One Level of Supervisory Approval
-
In the Global menu, click the Notifications icon and select More Details. If you're using the news feed default home page layout, then select Show All and click Worklist.
-
Select Financials. The Business Process Management Worklist application page opens.
-
Click your user name and select Administration. You can manage the journal approval rules only if you have administrator access.
-
Click the Task Configuration tab.
-
From the Tasks to be configured pane, select the FinGLJournalApproval task.
-
Click Edit task to create the rules.
-
Click the Assignees tab. The Assignees page shows the participant tree. A participant is a user or set of users in the approval assignment and routing definition. The journal approval task displays three predefined participants. Typically you use only one or two participants, but have the flexibility to add more participants to meet more complex approval requirements. Each participant is associated with one rule set, and a rule set can have one or more approval rules.
-
On the Supervisory Journal Approver participant, click Go to rule.
-
Click the Expand icon on the Manager Approval Rule. That's the default predefined approval rule. If a journal's ledger and source are enabled for approval, the rule is configured to send that journal for one level of approval to the supervisor of the person who submitted the journal for approval.
-
Click the Show Advanced Settings icon.
-
Click in the Active check box to deselect it. When this check box is cleared, the approval routing process doesn't use the rule.
-
Click the Add Rule icon.
-
In the Name field, enter the name of the rule: Between 500 and 10000.
-
Click Expand. Each rule defines the conditions for when the journal batch should be approved and by whom.
Note: The IF component evaluates the journal based on batch, journal, or journal line-level attributes. The THEN component determines who the approval should be routed to. -
In the IF section, click the Left Value icon. The Condition Browser window opens.
-
Click the Expand icon on the Maximum Amount Journal folder.
-
Click the Name attribute, which represents the ledger name.
-
Click OK. The Condition Browser window closes and the attribute name is populated in the Left Value field.
-
In the Right Value field, enter the name of the ledger in quotation marks, for example, enter "Vision Corporation".
Note: The first condition uses the operator named is. This operator compares the two values. -
Click the Add simple test icon from the list to add another condition.
-
Click the Left Value icon. The Condition Browser window opens.
-
Expand the Maximum Journal Amount folder and select the Maximum Accounted Amount Credit attribute. This attribute stores the maximum accounted credit amount across all journals in the batch.
-
Click OK. The Condition Browser window closes.
-
In the second condition, click in the Operator field and select the operator named between.
-
Click the Right Value icon. The Right Operand window opens.
-
In the Operand 1 field, enter the lower limit as 500.
-
In the Operand 2 field, enter the upper limit as 10000.
-
Click OK. The Right Operand window closes.
-
To configure the action to send the journal batch for one level of supervisory approval, click the Add Action icon in the THEN section.
-
Select Add Approver and select Supervisory.
Note: The Supervisory list builder generates the list of approvers by moving up the supervisory hierarchy that's set up in the Human Resources application. Specify the number of approvers, the first approver, and the highest possible approver. -
To route the journal batch for one level of supervisory approval, in the Number of levels field, enter 1.
-
In the Starting Participant field, click Search. The Add Hierarchy Participant window opens and the Get Manager option is selected by default.
-
For this rule, the starting participant or first approver, is going to be the manager of the person who submits the journal batch for approval. In the Reference User field, enter Task.Workflow Submitter.
-
Click OK. The Add Hierarchy Participant window closes.
-
In the Top Participant field, click Search. The Add Hierarchy Participant window opens.
Note: The top participant is the last user in the approval hierarchy. The list builder continues to add users to the approvers list from the supervisory hierarchy of the first approver, until the number of levels is met, or the top participant is reached. -
Click the Get User button.
-
In the Reference User field, enter the sign in name of the top participant within quotation marks.
-
Click OK. The Add Hierarchy Participant window closes.
-
From the Tasks to be configured pane, click Save. The Enter Comments window opens.
-
Click OK. The Enter Comments window closes and a message appears stating that the rule has been saved.
-
Click OK.
Create a Rule That Requires Two Levels of Supervisory Approval
Create a rule for the same ledger requiring two levels of supervisory approval if the largest journal amount is 10,000 or more. Copy the first rule and make changes for this second rule.
-
Click the Assignees tab.
-
Select the first rule.
-
Click the list on the Cut icon and select Copy.
-
Click the list on the Cut icon and select Paste. The second rule appears after the first rule.
-
In the Name field for the second rule, enter Greater than 10000.
-
Click Expand.
-
The first condition in the IF section that checks for the ledger, stays the same. Change the operator of the second condition to same or more than.
-
In the Right Value field, enter 10000.
-
In the THEN section, in the Number of levels field, enter 2.
-
Click Collapse. The second approval rule is complete.
Create a Rule That Automatically Approves Journals
Create the rule that automatically approves journals that are 500 or less for a specific ledger. The rule must also ensure that journal batches for all other ledgers are automatically approved as well.
-
Select the first rule.
-
Click the list on the Cut icon and select Copy.
-
Click the list on the Cut icon and select Paste. The third rule appears after the first rule.
-
Click in the Rule Name field and rename the third rule to Less than 500.
-
Click the Expand icon to open the new rule.
-
Create a condition for journals 500 or less in the specified ledger by first grouping the two existing conditions together. In the IF section, click both conditions to select them.
-
Click the Surround selected tests with parenthesis icon. Both conditions are now enclosed within a set of parentheses.
-
Click in the Operator field of the second condition and select same or less than from the list. The amount automatically changes to 500.
-
Now add another condition to cover all of the other batches that don't have journals for the specified ledger. Click the Add simple test icon. A third condition row is added after the two grouped conditions.
-
Since this new condition is mutually exclusive to the grouped conditions, click the connector to change it from and to or.
-
Click the Left Value icon. The Condition Browser window opens.
-
Expand the Maximum Journal Amount folder and select Name.
-
Click OK. The Condition Browser window closes.
-
Click in the Operator field and select the operator named isn't.
-
In the Right Value field, enter the name of the ledger in quotation marks.
-
Now set up the automatic approval. The Supervisory list builder has two parameters that override the supervisory approval and return a preconfigured approval action. In the THEN section, click in the Auto Action Enabled field, and select True.
-
In the Auto Action field, enter "APPROVE". Include the quotation marks.
-
Collapse the rule.
You have now defined three rules that meet the business requirements and are collectively exhaustive. All journal batches satisfy the conditions in at least one of the three rules and are routed for approval accordingly. If a journal batch doesn't satisfy the conditions in at least one rule within a rule set, the rule evaluation process would fail with errors.
-
Deploy the rules so that they can be used. On the Tasks to be configured toolbar, click the Commit Task icon. The Enter Comments window opens.
-
Click OK. The Enter Comments window closes and a message appears stating that the data rule has been saved and committed.
-
Click OK.
After journal approval is enabled, journal batches being posted are submitted for approval based on these rules.
Predefined Journal Approval Participants and Attributes
You can configure journal approval rules in the Business Process Management Worklist application. Open the Worklist application by selecting the Notifications icon on the home page and clicking More Details or, by using the following in the Setup and Maintenance work area:
-
Offering: Financials
-
Functional Area: Application Extensions
-
Task: Manage Task Configurations for Financials
The name of the journal approval workflow task is FinGlJournalApproval.
Assignees
Assignees, also called participants, are users or a set of users that an approval request is routed to. There are four types of assignees.
-
Single: Maps to a user, group, or role. Select this type if the approval request requires only a single user to approve. When the request is sent to a group or to an application role, all of the users within that group or that carry that application role receive the notification, but only one user's approval is required.
-
Parallel: Indicates that a set of people work in parallel and that everyone's approval is required. For example, a journal batch affects multiple lines of business and requires approval from the controllers for each line of business. The controllers can approve the journal batch in parallel.
-
Serial: Indicates that a set of users must work in sequence. The most common scenario is supervisory chain approval, which is done by specifying that the list is based on a supervisory chain.
-
FYI: Maps to a single user, group, or role, just as the Single assignee type. However, this type of assignee just receives a notification, and the business process doesn't wait for the assignee's response. FYI assignees can't directly impact the outcome of a task, but in some cases can provide comments or add attachments.
The journal approval workflow task contains three assignees (participants) with a type of Single, Serial, and Parallel, each. These three predefined assignees are arranged in the parallel mode. Assignees can be arranged in parallel or sequential mode. For assignees in parallel mode, a task is assigned and notifications are sent to all of the assignees at once in parallel. For assignees in sequential mode, a task is assigned and notifications are sent in a sequential manner, meaning one after another, to each assignee.
You can select to use any one, or combination of, the three assignees. You can delete them, or add new ones as needed. The Serial type assignee has a predefined journal approval rule based on the requester's supervisory hierarchy. If a ledger and journal source are enabled for approval, the predefined journal approval rule sends a journal belonging to that ledger and source to the requester's manager for approval.
Attributes
The tables in this section list the objects and attributes that appear in the Condition Browser window in the Worklist application.
The following table describes the attributes for the Journal Batch object.
Name | Description |
---|---|
Accounting Period Type |
Name of the accounting calendar. |
Batch Type Indicator |
Indicator for the type of amounts that the batch contains. Valid values are A or E, representing the following respective types: Actual and Encumbrance. |
Approval Status |
Approval status of the journal batch. Valid values are A, I, J, V, R, or Z, representing the following respective statuses: Approved, In Process, Rejected, Validation Error, Required, and Not Required. For Oracle internal use only. |
Approver Employee ID |
Internal identifier of the employee who submitted the batch for approval. For Oracle internal use only. |
Average Balance Journal Indicator |
Indicator for whether the journal is an average balance journal. Valid values are Y or N, representing Yes and No. |
Batch Amount |
Amount of the journal batch. |
Budgetary Control Status |
Not currently used. |
Calendar |
Reference to the Calendar object. For Oracle internal use only. |
Chart of Accounts ID |
Internal identifier of the chart of accounts. |
Control Total |
Control total of the journal batch. |
Created By |
Sign in name of the user who created the journal batch. |
Creation Date and Time |
Date and time when the journal batch was created. |
Creation Date |
Date when the journal batch was created. For Oracle internal use only. |
Default Accounting Date |
Internal default accounting date. For Oracle internal use only. |
Accounting Period Name |
Accounting period of the journal batch. |
Description |
Description of the journal batch. |
Earliest Postable Date |
For Oracle internal use only. |
Group ID |
Internal identifier of the interface group. For Oracle internal use only. |
Batch ID |
Internal identifier of the journal batch. For Oracle internal use only. |
Source |
Internal identifier of the journal source. For Oracle internal use only. |
Journal Batch Ledger |
Reference to the Journal Batch Ledger object. For Oracle internal use only. |
Journal Batch Source |
Reference to the Journal Batch Source object. For Oracle internal use only. |
Journal Header |
Reference to the Journal Header object. For Oracle internal use only. |
Last Updated Date |
Date when the journal batch was last updated. |
Last Updated Login |
For Oracle internal use only. |
Last Updated By |
Sign in name of the user who last updated the batch. |
Lookup Code |
For Oracle internal use only. |
Lookup Type |
For Oracle internal use only. |
Maximum Amount Journal |
Reference to the Maximum Amount Journal object. For Oracle internal use only. |
Maximum Journal Line Amount |
Reference to the Maximum Journal Line Amount object. For Oracle internal use only. |
Batch Type |
Full text value for the Batch Type Indicator attribute. Valid values are Actual or Encumbrance. |
Name |
Name of the journal batch. |
Object Version Number |
For Oracle internal use only. |
Packet ID |
For Oracle internal use only. |
Parent Batch ID |
For Oracle internal use only. |
Period |
Reference to the Period object. For Oracle internal use only. |
Accounting Period Set Name |
Accounting calendar name for the accounting period. |
Posted Date |
For Oracle internal use only. |
Posting Run ID |
Internal identifier. For Oracle internal use only. |
Request ID |
Internal identifier. For Oracle internal use only. |
Accounted Running Total Credit |
Total accounted credit amount of the journal batch. |
Accounting Running Total Debit |
Total accounted debit amount of the journal batch. |
Entered Running Total Credit |
Total entered credit amount of the journal batch. |
Entered Running Total Debit |
Total entered debit amount of the journal batch. |
Status |
Status of the journal batch. Valid values are u, U, S, I, or P, representing the following respective statuses: Incomplete, Unposted, Selected for Posting, Processing, and Posted. |
Status Verified by Posting Indicator |
Indicator for whether the status of the journal batch has been verified. Valid values are Y and N, representing Yes and No. For Oracle internal use only. |
Submitted Period |
Reference to the Submitted Period object. For Oracle internal use only. |
Not Reserved Packet ID |
For Oracle internal use only. |
Journal Batch Creator |
Reference to the Journal Batch Creator object. For Oracle internal use only. |
Journal Batch Approval Requester |
Reference to the Journal Batch Approval Requester object. For Oracle internal use only. |
Funds Status |
Budgetary control status for the batch. A list of valid values can be found in the lookup type XCC_BC_FUNDS_STATUSES. For example, RESERVED_PARTIAL or RESERVED_PASSED, representing Partially reserved and Reserved. |
Chart of Accounts Code |
The chart of account structure code used to record transactions and maintain account balances. |
Descriptive Flexfield Structure Definition 1 |
Structure definition of the Journal Batches descriptive flexfield. |
Descriptive Flexfield Attributes 1 through 10 |
Segments of the Journal Batches descriptive flexfield. |
The following table describes the attributes for the Journal Batch Ledger object.
Name | Description |
---|---|
Batch ID |
Internal identifier of the journal batch. For Oracle internal use only. |
Currency |
Currency of the ledger. For example USD or EUR. |
Ledger Category Code |
Category of the ledger. Valid values are SECONDARY, PRIMARY, NONE, and ALC, representing the following respective categories: Secondary Ledger, Primary Ledger, None, and Reporting Currency. |
Ledger Enabled for Journal Approvals Indicator |
Indicator for whether approval is enabled for the ledger. Valid values are Y or N, representing Yes and No. |
Ledger ID |
Internal identifier of the ledger. |
Ledger Name |
Name of the ledger. |
Meaning |
For Oracle internal use only. |
Period Set Name |
Internal name for the accounting calendar, which is the original calendar name that a user entered. For Oracle internal use only. |
Primary Ledger Currency |
Ledger currency defined for the primary ledger. For example, USD or EUR. |
Descriptive Flexfield Structure Definition |
Structure definition of the Ledgers descriptive flexfield. |
Descriptive Flexfield Attributes 1 through 15 |
Segments 1 through 15 of the Ledgers descriptive flexfield. |
The following table describes the attributes for the Journal Batch Source object.
Name | Description |
---|---|
Journal Source ID |
Internal identifier of the journal source. For Oracle internal use only. |
Journal Reference Indicator |
Indicates whether journal import saves the references to the subledger transactions. Saved references let you drill from a general ledger journal to the subledger transaction. Valid values are Y or N, representing Yes and No. |
Override Edits Indicator |
Indicator for whether a user can update the journal that has the journal source. Valid values are Y, N, or P, representing Yes, No, and Partial, respectively. |
Type |
Identifies whether the source for the batch is a subledger application. Valid values are SLA or Non-SLA, representing subledger accounting and nonsubledger accounting, respectively. |
Journal Source Name |
User-defined name for the journal source. |
Source Key |
Unique identifier for a journal source. |
Descriptive Flexfield Attributes 1 through 5 |
Segments 1 through 5 of the Journal Sources descriptive flexfield. |
The following table describes the attributes for the Journal Calendar object.
Name | Description |
---|---|
Calendar ID |
Internal identifier of the accounting calendar. For Oracle internal use only. |
Period Set ID |
Internal identifier. For Oracle internal use only. |
Period Set Name |
Name of the accounting calendar when first created. If the calendar name is later changed in the user interface, this original name remains stored internally as a unique identifier. For Oracle internal use only. |
Period Type |
Internally generated value based on period frequency of the accounting calendar. For Oracle internal use only. |
Period Type ID |
Internal identifier of the period type. For Oracle internal use only. |
User Period Set Name |
Current name of the accounting calendar. |
Descriptive Flexfield Structure Definition |
Structure definition of the Calendars descriptive flexfield. |
Descriptive Flexfield Attributes 1 through 5 |
Segments 1 through 5 of the Calendars descriptive flexfield. |
The following table describes the attributes for the Journal Category object.
Name | Description |
---|---|
Category ID |
Internal identifier of the journal category. For Oracle internal use only. |
Journal Category Name |
Translated name of the journal category. Might not uniquely identify a category in an approval rule. Varies depending on a user's language setting. |
Category Key |
User-defined category key that uniquely identifies the category. |
Descriptive Flexfield Structure Definition |
Structure definition of the Journal Categories descriptive flexfield. |
Descriptive Flexfield Attributes 1 through 5 |
Segments 1 through 5 of the Journal Categories descriptive flexfield. |
The following table describes the attributes for the Journal Header object.
Name | Description |
---|---|
Reversed Journal Indicator |
Indicator for whether the journal was reversed. Valid values are Y or N, representing Yes and No. |
Accounted Currency |
Currency of the ledger. For example, USD or EUR. |
Accounting Date |
Accounting date of the journal. |
Batch ID |
Internal identifier of the journal batch. For Oracle internal use only. |
Category |
Internal identifier of the journal category. For Oracle internal use only. |
Journal from Subledger Indicator |
Indicator for whether the journal was created through subledger accounting. Valid values are Y or N, representing Yes and No. |
Header ID |
Internal identifier of the journal. For Oracle internal use only. |
Journal Header Category |
Reference to the Journal Header Category object. For Oracle internal use only. |
Journal Line |
Reference to the Journal Line object. For Oracle internal use only. |
Ledger ID |
Identifier for the ledger. |
Ledger Name |
Name of the ledger. |
Reference Date |
Reference date entered for the journal. |
Running Total Accounted Credit |
Total accounted credit amount of the journal. |
Running Total Accounted Debit |
Total accounted debit amount of the journal. |
Attachment Exists Indicator |
Indicator for whether the journal has attachments. Valid values are Y or N, representing Yes and No. |
Entered Currency |
Entered currency of the journal. For example, USD or EUR. |
Journal Description |
Description of the journal. |
Journal Name |
Name of the journal. |
Reversing Journal Indicator |
Indicator for whether the journal resulted from a reversal. Values are Y or N, representing Yes and No. |
Clearing Company |
Intercompany clearing entity used to balance the journal. |
Control Total |
Control total entered for the journal. |
Conversion Date |
Date for the conversion rate, which is used to convert an amount into another currency. |
Encumbrance Type |
Type of encumbrance for journal batches with the Encumbrance batch type. |
Journal Reference |
Additional information entered by a user. |
Legal Entity |
Name of the legal entity associated with the journal. |
Total Entered Credit |
Total journal batch credit amount in the entered currency. |
Total Entered Debit |
Total journal batch debit amount in the entered currency. |
Conversion Rate Type |
Source of a currency conversion rate, for example User, Spot, and Corporate. |
Descriptive Flexfield Structure Definition 1 |
Structure definition of the Journals descriptive flexfield. |
Descriptive Flexfield Attributes 1 through 10 |
Segments 1 through 10 of the Journals descriptive flexfield. |
The following table describes the attributes for the Journal Line object.
Name | Description |
---|---|
Accounted Credit |
Accounted credit amount of the journal line. |
Accounted Debit |
Accounted debit amount of the journal line. |
Entered Currency |
Entered currency of the journal line. For example, USD or EUR. |
Accounted Currency |
Ledger currency of the journal line. For example, USD or EUR |
Entered Credit |
Entered credit amount of the journal line. |
Entered Debit |
Entered debit amount of the journal line. |
Header ID |
Internal identifier of the journal. For Oracle internal use only. |
Line Number |
Number of the journal line. |
Ledger ID |
Internal identifier of the ledger. For Oracle internal use only. |
Ledger ID 1 |
For Oracle internal use only. |
Account |
Reference to the Account object. For Oracle internal use only. |
Chart of Accounts ID |
Internal identifier of the chart of accounts. |
Account Combination ID |
Internal identifier of the account combination. |
Concatenated Segment |
For Oracle internal use only. |
Account Combination |
Concatenated segments separated by the key flexfield delimiter. For example, 101-10-110-11010-0000. |
Account Type |
Valid values are A, L, E, R, or O, representing the following respective account types: Asset, Liability, Expense, Revenue, and Owner Equity. |
Conversion Date |
Date for the conversion rate, which is used to convert an amount into another currency. |
Conversion Rate Type |
Source of a currency conversion rate, for example User, Spot, and Corporate. |
Detail Posting Allowed |
Indicator for whether the account allows posting. Valid values are Y and N. |
Account Enabled |
Indicator for whether the account is available for use. |
Account End Date |
The date when the account becomes inactive. |
Financial Category |
Group assigned to a Natural Account segment value. Used for reporting with Oracle Transactional Business Intelligence. A list of accepted values is defined in the FINANCIAL_CATEGORY lookup type. |
Reconciliation Enabled Account |
Indicator assigned to a Natural Account segment value for whether the account is enabled for reconciliation. Valid values are Y and N. |
Control Account |
Setting assigned to a Natural Account segment value for maintaining detailed balances by third party. Valid values are CUSTOMER, N, R, SUPPLIER, and Y, representing the following respective controls: Customer Control Account, No, Restricted GL Manual Journals, Supplier Control Account, and Third-Party Control Account. |
Account Start Date |
The date when the account becomes active. |
Account Segments 1 through 30 |
Value of a segment in the account combination. |
Descriptive Flexfield Structure Definition 1 |
Structure definition of the Journal Lines descriptive flexfield. |
Descriptive Flexfield Attributes 1 through 10 |
Segments 1 through 10 of the Journal Lines descriptive flexfield. |
Descriptive Flexfield Structure Definition 3 |
Structure definition of the Journals Captured Information descriptive flexfield. |
Descriptive Flexfield Attributes 11 through 20 |
Segments 11 - 20 of the Journals Captured Information descriptive flexfield. |
The following table describes the attributes for the Maximum Amount Journal object.
Name | Description |
---|---|
Batch ID |
Internal identifier of the batch. For Oracle internal use only. |
Journal Ledger Category Code |
Category of the ledger. Valid values are SECONDARY, PRIMARY, NONE, and ALC, representing the following respective categories: Secondary Ledger, Primary Ledger, None, and Reporting Currency. |
Ledger Enabled for Journal Approval Indicator |
Indicator for whether approval is enabled for the ledger. Valid values are Y or N, representing Yes and No. |
Ledger ID |
Internal identifier for the ledger. For Oracle internal use only. |
Name |
Name of the ledger. |
Maximum Accounted Amount Credit |
Maximum accounted credit journal amount of the journal batch. |
Maximum Accounted Amount Debit |
Maximum accounted debit journal amount of the journal batch. |
Maximum Net Accounted Amount |
Maximum accounted net journal amount of the journal batch. |
Accounted Currency |
Currency of the ledger. For example, USD or EUR. |
The following table describes the attributes for the Maximum Amount Journal Line object.
Name | Description |
---|---|
Batch ID |
Internal identifier of the journal batch. For Oracle internal use only. |
Journal Ledger Category Code |
Category of the ledger. Valid values are SECONDARY, PRIMARY, NONE, and ALC, representing the following respective categories: Secondary Ledger, Primary Ledger, None, and Reporting Currency. |
Ledger Enabled for Journal Approval Indicator |
Indicator for whether approval is enabled for the ledger. Valid values are Y or N, representing Yes and No. |
Ledger ID |
Identifier of the ledger. For Oracle internal use only. |
Ledger Name |
Name of the ledger. |
Maximum Accounted Line Amount Credit |
Maximum accounted credit amount of a journal line in the journal batch for the ledger. For example, if a journal batch has five credit lines, this attribute holds the largest value of those five credit lines. |
Maximum Accounted Line Amount Debit |
Maximum accounted debit amount of a journal line in the journal batch for the ledger. For example, if a journal batch has five debit lines, this attribute holds the largest value of those five debit lines. |
Maximum Net Accounted Line Amount |
Maximum accounted net amount of a journal line in the journal batch for the ledger. |
Accounted Currency |
Currency of the ledger. For example, USD or EUR. |
The following table describes the attributes for the Period object, which has details for the period that the journal belongs to.
Name | Description |
---|---|
Description |
Description of the accounting period. |
End Date |
End date of the accounting period. |
Name |
Name of the accounting period. |
Number |
Number of the accounting period in the fiscal year. |
Set Name |
Name of the accounting calendar when first created. If the calendar name is later changed in the user interface, this original name remains stored internally as a unique identifier. |
Type |
Internally generated value based on the period frequency of the accounting calendar. For Oracle internal use only. |
Year |
Year for the accounting period. |
Quarter Number |
Quarter number of the accounting period. |
Start Date |
Start date of the accounting period. |
Adjustment Period Indicator |
Indicator for whether the period is an adjustment period. Valid values are Y or N, representing Yes and No. |
Descriptive Flexfield Structure Definition |
Structure definition of the Accounting Calendar Periods descriptive flexfield. |
Descriptive Flexfield Attributes 1 through 8 |
Segments 1 through 8 of the Accounting Calendar Periods descriptive flexfield. |
Descriptive Flexfield Dates 1 through 5 |
Date segments 1 through 5 of the Accounting Calendar Periods descriptive flexfield. |
Descriptive Flexfield Numbers 1 through 5 |
Number segments 1 through 5 of the Accounting Calendar Periods descriptive flexfield. |
The following table describes the attributes for the Submitted Period object, which has details for the period in which a journal was submitted for approval.
Name | Description |
---|---|
Adjustment Period Indicator |
Indicator for whether the period is an adjustment period. Valid values are Y or N, representing Yes and No. |
End Date |
End date of the accounting period. |
Most Recent Period End Date |
End date of the accounting period that's two months before the current accounting period. For example, if a journal is submitted for approval in February 2018, this attribute would contain December 31, 2017. |
Name |
Name of the accounting period for the journal. |
Number |
Number of the accounting period in the fiscal year. |
Set Name |
Name of the accounting calendar when first created. If the calendar name is later changed in the user interface, this original name remains stored internally as a unique identifier. |
Type |
Internally generated value based on the period frequency of the accounting calendar. For Oracle internal use only. |
Year |
Accounting period year. |
Previous Period End Date |
End date of the previous accounting period. For example, if a journal is submitted for approval in February 2018, this attribute would contain January 31, 2018. |
Start Date |
Start date of the accounting period. |
Descriptive Flexfield Structure Definition |
Structure definition of the Accounting Calendar Periods descriptive flexfield. |
Descriptive Flexfield Attributes 1 through 8 |
Segments 1 through 8 of the Accounting Calendar Periods descriptive flexfield. |
Descriptive Flexfield Dates 1 through 5 |
Date segments 1 through 5 of the Accounting Calendar Periods descriptive flexfield. |
Descriptive Flexfield Numbers 1 through 5 |
Number segments 1 through 5 of the Accounting Calendar Periods descriptive flexfield. |
Examples of Maximum Amount Journal and Maximum Amount Journal Line Objects in Journal Approval Rules
You can configure journal approval rules in the Business Process Management Worklist application. Open the Worklist application by selecting the Notifications icon on the home page and clicking More Details or, by using the following in the Setup and Maintenance work area:
-
Offering: Financials
-
Functional Area: Application Extensions
-
Task: Manage Task Configurations for Financials
The name of the journal approval workflow task is FinGlJournalApproval.
To configure journal approval rules that route journals for approval based on amounts, you can use the Maximum Amount Journal and Maximum Amount Journal Line objects in your approval rule definitions.
Maximum Amount Journal
To route journal batches for approval based on the largest journal amount within a batch, you can use the Maximum Amount Journal object in your approval rule definition. For a journal batch, this object contains the maximum accounted debit and credit amounts at the journal level, per ledger.
The following table shows an example of a journal batch that has four journals for two ledgers with different ledger currencies.
Journal | Ledger | Ledger Currency | Accounted Amount |
---|---|---|---|
1 |
USA |
USD |
500 |
2 |
USA |
USD |
700 |
3 |
France |
EUR |
500 |
4 |
France |
EUR |
900 |
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.
Workflow Transaction Console
Overview of Workflow Transaction Console for Financials
Use the workflow Transaction Console to monitor and troubleshoot workflow tasks for the Invoice, Expenses, and Journal Approval workflows.
From the console you can:
-
View the latest status of all workflow tasks.
-
Review the issue description and resolution for failed tasks.
-
Take appropriate action on a failed task.
-
Search tasks based on user-defined criteria.
-
Download search results to a spreadsheet.
Give Users Access to Manage Financials Workflow Transactions
Users can manage transactions for the Invoice, Expenses, and Journal Approvals workflows from the Transaction Console.
Give Financial Users Administrator access
You have a couple of options for giving users access to the Transaction Console work area, depending on whether you're assigning them predefined job roles, or your own configured job roles.
-
Assign the predefined Financials Application Administrator (ORA_FUN_FINANCIAL_APPLICATION_ADMINISTRATOR_JOB) job role.
-
Your own configured job role must include the Financial Transaction Approval Reviewing (ORA_FIN_REVIEW_APPROVAL_TRANSACTIONS) duty role.
Limit What Users Can See
By default, users who have access to the Transaction Console work area can see all transactions, from all product families.
To make sure that financial users view only the financial workflows, enable transaction security:
-
In the Setup and Maintenance work area, go to the Manage Enterprise HCM Information task.
-
Offering: Financials
-
Functional Area: Enterprise Profile
-
Task: Manage Enterprise HCM Information
-
-
On the Edit Enterprise page, click Edit and then select Update.
-
Complete the fields in the Update Enterprise dialog box and click OK.
-
In the Transaction Console Information section, select Enable Transaction Security.
-
Click Submit.
Manage Workflow Transactions
After workflow tasks are created, it's helpful to keep track of them and jump in when you need to, especially when something goes wrong. If you have the appropriate roles, you can monitor and troubleshoot workflow tasks for others and for yourself. Use the Transaction Manager: Transactions page in the Transaction Console work area to manage transactions. A transaction is a business process that involves a workflow task.
Here are some of the things you can do:
-
Track transaction statuses and download spreadsheets with information about transactions.
-
Download and review diagnostic logs for transactions with errors.
-
Depending on what's going on with the transaction and what roles you have, you might be able to, for example, reassign or recover the transaction.
Find Transactions
Follow these steps:
-
Click Navigator > Tools > Transaction Console.
-
If you see tabs, make sure you're on the Transaction Summary tab.
-
On the Transaction Manager: Transactions page, check the Last Refresh time stamp after the page title to see when the transaction statuses were last updated. Click the Refresh icon if needed. You can refresh any time as long as someone else didn't already start a refresh.
-
You can also set the Refresh Transaction Administrator Console Transaction Status scheduled process to run on a schedule, to automatically refresh the statuses on a regular basis. Start by setting it to run once every hour, and then see how it goes and adjust from there.
-
If you open the details for a specific transaction (step 5), its status also refreshes and you see the latest on the details page.
-
-
View the transactions with a status that matches the default Status filter, for example Failed. You can remove this filter to get results for all statuses. Or, use the search and filters to apply your own criteria, for example, to find transactions that are priority 1 or submitted by a specific person.
-
You can use the search to find results based on keywords in the Name or Process Name column, or specifically use the Name or Process Name filters. Name is the person or object the workflow task applies to, and the process reflects the type of workflow task.
-
You can personalize filters to add or hide filters, and create saved searches for future use.
-
-
Select and act on the transactions right there from the results table, or click the transaction in the Name column to see details, such as diagnostic information for failed transactions, and go from there.
Act On Transactions Without Opening Details
Here's what you do:
-
Select one or more transactions from the results table.
-
Optionally use the Priority menu to set an issue priority, so that you can later filter on the priority to find these transactions.
-
Open the Actions menu and select an action. If you selected more than one transaction, you see only the actions that can apply to all of them.
Use Transaction Details
What you can see and do in the transaction details depends on the transaction status and what roles you have. For example, for transactions that are in progress or completed, you might see the approval history, which shows who already approved and who the current assignee is, if any.
For failed transactions, you can get information about the issues and, if you're an administrator, usually take some action:
-
Select an issue from the Issues list, if the transaction has more than one issue.
-
Review the information in the Instructions and Details sections, including any description and resolution for the issue, as well as the related workflow task and approval rule.
-
Click the Download link to get the diagnostic log.
-
Use the Issue Priority list to set an issue priority, if you want to later filter on the priority to find this transaction.
-
From the Assigned To list, select the person who should fix the issue, for tracking and filtering purposes.
-
Add comments, for example to track what you're doing to address the issue, or note down any service request IDs. You and others can see these comments only in the Transaction Console, not with the workflow task in the worklist.
-
If you can, take action to address the issue. Here are some examples of how you might go about it:
-
Open the Actions menu and select an action to manage the transaction.
-
Follow up with the person you assigned the issue to or your help desk. Give them the diagnostic log and other information from the transaction details.
-
Reconfigure the approval rule that the transaction is based on, and have the workflow task resubmitted.
-
-
Select another issue from the Issues list, if any, and go through the same process.
-
Click Save and Close.
Download a Spreadsheet of Transactions
This is all you need to do:
-
In the results table, select the transactions you want to include in the spreadsheet. To get all transactions, either select all of them or none at all.
-
On the Actions menu, click Download.
Statuses for Filtering Transactions
Use the Transaction Manager: Transactions page in the Transaction Console work area to track the status of transactions. For example, you can filter the transactions by status to see just the transactions that are in progress or stuck. These statuses aren't the actual workflow task statuses that you see in the worklist or in notifications.
Status | Description |
---|---|
Auto Recovery |
The transaction ran into some issues, but the application is trying to fix them without any action on your end. |
Completed |
All approvals are done and the transaction successfully went through all processes. |
Draft |
The transaction is saved but not submitted yet. This status doesn't apply to all product families. |
Failed |
The transaction has one or more errors, for example, due to a network or database outage, or an issue in the approval rules setup. |
In Progress |
At least one approval is still pending for the transaction before it's all done. |
Stuck |
The transaction was submitted, but ran into issues so the workflow task doesn't exist yet. |
Submitted |
The transaction was just created and hasn't moved on yet to another status. This status doesn't apply to all product families. |
Actions for Managing Transactions
Use the Transaction Manager: Transactions page in the Transaction Console work area to manage and troubleshoot transactions. For example, you can withdraw a transaction even if you're not the one who submitted it. What you can do depends on the transaction status and the roles you have. Some actions, such as approve and reassign, are the same as the ones you can take on the workflow tasks from the worklist or from notifications.
Action | Description |
---|---|
Add Comment |
Add your notes for the transaction, for example to track what you're doing to address the issue, or to jot down any service request IDs. You and others can see these comments only in the Transaction Console. |
Alert Initiator on Error |
Notify the submitter if the transaction ends up in error. |
Approve |
Approve the transaction if the workflow task is currently assigned to you to approve or reject. |
Download |
Get a spreadsheet with information about the selected transactions. |
Reassign |
Reassign the workflow task to an approver, the submitter, or someone else. |
Recover |
Restart the process after the transaction stopped due to errors. After you address the issue, use this action to get the application to pick up where the process last left off and retry whatever had ended up in error. |
Reject |
Reject the transaction if the workflow task is currently assigned to you to approve or reject. |
Terminate Process |
Completely end the transaction so that no one can see or act on the workflow task again. |
Withdraw |
Remove the workflow task from the workflow. You can ask the submitter to submit again, for example, after an issue is resolved. |
FAQs for Journals
How can I copy a journal entry?
Begin by opening an existing journal entry from the Manage Journals page. Select the Copy action in the Batch Actions drop down on the Journal Batch region to copy the entire journal batch. You can then delete any journals you don't need and modify the new journal batch, including the batch name, period, and accounting date, as needed. When you save, an unposted journal batch is created, that you then complete, approve, and post following your standard procedures. The copied journal has a source of AutoCopy instead of Manual.
What happens if I change the currency on a journal entry?
The journal entered and accounted amounts are recalculated to reflect the new currency amounts. The default conversion date is the journal accounting date. You can override the conversion date but the conversion date must be within the accounting period that you defined for the journal entry.
If the currency isn't the ledger currency, enter the currency conversion information at
-
The journal level for a single currency journal.
-
The journal line level for a cross currency journal.
Enter a conversion rate, if you enter User as the conversion rate type. When using a conversion rate type of Spot or Corporate, the daily conversion rate entered in the daily rates table automatically populates the conversion rate.
How can I add the Inverse Conversion Rate field to the Journal pages?
Use the Personalization functionality to add the Inverse Conversion Rate field to the Journal and Journal Lines regions of the Create and Edit Journal pages. The Inverse Conversion Rate field appears automatically on pages displaying a completed Conversion Rate field.
How can I prevent edits to journal entries created from journal import?
Select the value of Yes in the Freeze Journals field for the wanted source in the Manage Journal Sources page. This ensures that the subledger and general ledger balances reflect the same data. The value of Partial - Allow Import Correction Only prevents edits in the journal pages, but allows edits in the journal import correction spreadsheet.
What's the maximum number of journal lines that can be exported to an integrated Excel workbook?
When you are reviewing a journal, 500 journal lines can be exported. To review the details of a journal larger than 500 lines, run the General Ledger Journals Report for the journal batch.
What happens if an error occurs with the Journal Import service?
The Journal Import public web service provides specific validation errors and the account combination that has the error when invalid data is loaded.
What's the difference between incomplete and unposted batch statuses?
All batches that are not in a Posted status are considered unposted batches. These unposted batches have various statuses, including Incomplete, Selected for Posting, Processing, or Error.
A journal batch that is in an incomplete status has been saved, but is not completed. Incomplete journals are listed on the Incomplete tab of the Journals work area landing page and General Accounting dashboard.
What happens if I use suspense posting or other options to post an unbalanced journal entry?
If you enabled suspense posting when you define the ledger or after creating the ledger, Oracle Fusion General Ledger automatically creates additional journal lines. The process uses the suspense account you specify to balance your journal entries. You can optionally specify a threshold at which journal entries for monetary amounts are balanced.
General Ledger analyzes the journal entry and creates the additional balancing journal lines for the following situations in the order listed.
-
Suspense posting of unbalanced journals when suspense posting is enabled. If suspense posting happens, then the remaining balancing options don't occur.
-
Rounding differences at the journal level when journals are unbalanced because of rounding differences on currency conversion.
-
Intercompany or intracompany balancing for journals that aren't balanced by ledger or balancing segment value combination.
-
Entered currency balancing for journals that are unbalanced by the entered currencies. This option is only used on multicurrency journals.
-
Rounding differences by balancing segment when journals are unbalanced because of rounding differences on currency conversion and more than one balancing segment is effected.
Why didn't my journal batch post?
Common reasons why a journal batch doesn't post are the following:
-
Account is disabled or not valid as of the accounting date.
-
Period isn't open for the ledger or for its secondary ledger or reporting currency.
-
Journal is imported into future-enterable period and the AutoPost program tries to post in an unopened period.
-
Journal is unbalanced and suspense balancing is turned off or not set up properly.
-
Journal is unbalanced by balancing segment value, and intercompany balancing is turned off or not set up properly.
The unposted journals with their error status are displayed on the Requiring Attention tab of the Journals work area and the General Accounting Dashboard. The error status also shows on the Posting Execution report. The Posting Execution report is created automatically when the Posting process completes. Use these sources to help in the error correction process.
How can I correct errors that occur during the posting process?
Identify the error by using the Posting Execution report or by clicking the Show Errors button when querying the journal on the journal pages. The Posting Execution report lists the batches that are successfully posted and the batches that encounter posting errors. The Show Errors button appears when errors are detected during journal batch posting process. Clicking the Show Errors button displays a dialog box with an error message. Use the following methods to correct the error:
If it's an unopened accounting period for the ledger, the reporting currency, or the secondary ledger, the accounting period must be open.
If it's a disabled or invalid account combination, that combination must be enabled or made valid, or changed to a valid one.
If it's an unbalanced journal, the corresponding balancing method, suspense, rounding, entered currency, or intercompany, must be set up correctly and enabled with valid, related accounts.
How can I run the AutoPost process?
After you define an automatic posting criteria set, run the AutoPost process by clicking the Generate button on the Manage AutoPost Criteria Sets page or the Launch AutoPost link from the Journals task pane. The AutoPost process posts the journal batches that meet the criteria defined. Optionally, schedule the AutoPost process for specific automatic posting criteria sets through the Schedule tab in the Schedule Process: Advanced region to run at specific times and submission intervals.
How can I confirm that my journal entries were automatically posted?
Review the AutoPost Execution report. This report is created when the AutoPost process completes and contains the batch name, accounting period, and balance type for each batch posted, as well as error codes for those batches that failed to post. The posting status of journal batches is also listed on the Journals work area and the General Accounting Dashboard.
Why didn't the AutoPost process post journal batches as expected?
Verify that the posting criteria set specifies the precise criteria required to post the wanted journals. If the criteria is correct, then verify the following:
-
Journal imports completed successfully.
-
Journal batches are error free and ready to post.
-
Specified accounting period is open.
How can I identify errors that occurred during the AutoPost process?
Review the AutoPost process results on the AutoPost Execution report. This report is automatically created when the process completes successfully. The report contains the batch name, accounting period, and balance type for each posted journal batch, and lists error statuses for batches that fail to post. The unposted journals with their error status are also displayed on the Requiring Attention tab of the Journals work area and the General Accounting Dashboard.
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 |
Can I edit a journal that's approved and not yet posted?
Yes. Here's how you do it.
From the Journals work area:
-
Select the Manage Journals task.
-
Search for the journal and open it.
-
On the Edit Journal page, click Edit. A message will appear telling you that if you continue, the journal will return to an unapproved state. The approval status on the journal will change to Required.
-
Click Save.
-
Make your edits as needed.
-
Resubmit the journal for approval.