Step 26: Set Up Automatic Tax Calculation

Set Up Automatic Tax Calculation if You Do Not Have Oracle Receivables and Oracle Payables Installed. Since journal entry taxes are computed similarly to taxes within Payables or Receivables, much of your Payables or Receivables setup is reusable. If you do not use those applications, you can also access the setup forms from within General Ledger.

Other journal entry tax setup information is associated with a particular ledger; therefore, you need to complete this setup for each ledger. Also, if you use multiple organization support in Payables and Receivables, tax information is associated with a specific operating unit, so you need to complete this setup for each operating-unit-specific responsibility.

Perform this step once per ledger.

Step 27: Define Your Automatic Posting Criteria (optional)

You can automatically post journal batches that meet specific criteria that you have defined in an AutoPost criteria set. You can define multiple criteria sets that include a range of journal effective dates and multiple AutoPost priorities. AutoPost priorities can be defined for combinations of journal source, journal category, balance type, and period.

Perform this step once per criteria set for your installation.

Step 28: Define Encumbrance Types (optional)

Define custom encumbrance types in addition to the encumbrance types installed with General Ledger to classify and track your expenditures according to your purchasing approval process.

Perform this step once per installation.

Step 29: Set Up Budgets (optional)

Use budgets to enter estimated account balances for a specified range of periods. You can use these estimated amounts to compare actual balances with projected results, or to control actual and anticipated expenditures.

Define a budget to represent specific estimated cost and revenue amounts for a range of accounting periods. You can create as many budget versions as you need for a ledger.

You can create one or multiple budgets for a ledger at any time. You can create budget hierarchies by assigning a master budget to lower-level budgets. This enables you to track budgeted amounts against a control budget.

Note: You must complete this step if you want to enable budgetary control.

Step 30: Define One or More Budgetary Control Groups (optional)

If You Enabled Budgetary Control, You can create a budgetary control group by specifying funds check level (absolute, advisory, or none) by journal entry source and category, together with tolerance percent and tolerance amount, and an override amount allowed for insufficient funds transactions. You must define at least one budgetary control group to assign to a site through a profile option.

Important: You must install General Ledger to use budgetary control, encumbrance accounting, budgetary accounts, and funds checking. Full use of these features also requires installing Purchasing and Payables.

Context: Perform this step once per installation.

Step 31: Define Security Rules (optional)

Define segment value security rules to restrict user access to certain segment values when entering journals, performing online inquiries, and running FSG and some standard reports. Segment value security rules can work alone or with data access set security that secures data in ledgers, balancing segment values, or management segment values.

If you skip this step, you will be able to use and view all segment values defined, 
assuming you have read and write access to those values via your data access set. You can perform this step at anytime. The same security rules can be applied to multiple Responsibility and Application combinations.

Step 32: Set Your General Ledger Profile Options (optional)

Profile options specify how your Oracle General Ledger application controls access
to and processes data. In general, profile options can be set at one or more of the
following levels: site, application, responsibility, and user. 

You need to perform this step only once per installation.

Step 33: Open Accounting Period

Open and close accounting periods to control journal entry and journal posting, as well as to compute the beginning period balances when opening the first period of a new year. Perform this step once per ledger.

Step 34: Set up the Global Consolidation System

Set up the Global Consolidation System (GCS) if you want to consolidate multiple
companies using separate ledgers.

If you skip this step, you cannot use the Global Consolidation System to consolidate
financial results of multiple companies in your organization to a parent company. Perform this step once per installation.

Step 8: Define Ledger Currency

Define the currency for your ledger, or enable one of the predefined ISO (International Standards Organization) currencies. You should also define or enable any additional currencies you plan to use. 

You need to perform this step only once per ledger and reporting currency.

GL Summary Accounts

Oracle GL Summary Accounts from Baker Khader Abdallah, PMP

Encumberance Accounting

Encumbrance Accounting from Baker Khader Abdallah, PMP

Mass Allocations

Mass allocation is a facility in Oracle Financials through which one can create journals that distribute and allocate revenues and expenses across a group of cost centers, departments, divisions, and so on. It is a very useful tool to properly distribute amounts between accounts. For example rent for the entire premises can be allocated to different cost centers based on the area occupied by each department. 

To define MassAllocation formulas, you create a MassAllocation batch that contains one or more MassAllocation formula entries. You can also copy an existing MassAllocation batch then modify it as needed for your new batch. By including parent values in allocation formulas, you can allocate to the child values referenced by the parent without having to enumerate each child separately. You can create MassAllocations in your functional currency, a foreign currency or statistical currency.

The Mass allocation journals in Oracle are handled in a step by step manner. The following steps are involved in created a Mass Allocation Journal Entry:

1. Create MassAllocation Definition - First the user needs to define the mass allocation definition. The definition contains parameters as to how expenses etc would be distributed.
2. Validate the Mass Allocation definition - The second step is to validate the mass allocation definitions with valid account segments to ensure that same are correct and accurate.
3. Generate the Mass Allocation journals - Finally from journal entries already posted, mass allocation journals need to be passed so as to distribute or allocate the amounts to valid accounts based on proportion.
4. Review and post the entries - Once the mass allocation journals are generated, the last step in the process is to review the journals and post the entries to the Oracle General Ledger.

Formula Lines

Operand Lines

All MassAllocation formulas use the following equation to determine allocation amounts:

COST POOL * (USAGE FACTOR / TOTAL USAGE)

General Ledger uses the following format to represent the equation. Each factor in this equation relates to a separate formula line.

A * B / C

You can enter any combination of fixed amounts and accounts in formula lines A, B, or C.

Note: When you create MassAllocation formulas, you can enter specific amounts or specify an account for lines A, B or C. If you do not choose Full Cost Allocation: you can enter an amount instead or an account in any of lines A,B or C. If you choose Full Cost Allocation: you can enter an amount in line A but lines B and C must contain accounts only. See also the Validation Business Rules for Allocation Formulas with Full Cost Pool enabled.

Target Account

Enter an account in the Target line to specify the destination for your allocations.

When the result of your allocation formula is a positive number, the resulting journal entry debits the target account and credits the offset account. When the result of your allocation formula is a negative number, the resulting journal entry credits the target account and debits the offset account.

Note: The target account must conform to the allocation formula rules for target accounts. Be sure to also follow the account segment cross–validation rules. The validation program does not check for account cross–validation rule violations. If you enter a target account that violates a cross–validation rule General Ledger creates invalid journal lines when you generate the formula. You must correct the resulting journals in the Enter Journals window before you post.

Offsetting Account

Enter an account in the Offset line to specify the account to use for the offsetting debit or credit from your allocation. The Offset account is usually the same account as formula line A to reduce the cost pool by the allocated amount. When the result of your allocation formula is a positive number, the resulting journal entry debits the target accounts and credits the offset account. 
When the result of your allocation formula is a negative number, the resulting journal entry credits the target accounts and debits the offset account.

Note: The offset account must conform to the allocation formula rules for offsetting accounts. Be sure to also follow the account segment cross–validation rules. The validation program does not check for account cross–validation rule violations. If you enter an offset account that violates a cross–validation rule General Ledger creates invalid journal lines when you generate the formula. You must correct the result in

Validating MassAllocation Batches

After you define a new allocation batch, or change an allocation formula, you must validate the batch by running the MassAllocation/ MassBudget Validation program. The program verifies that your allocation formulas conform to the allocation formula definition rules.

You can run the program to validate all previously unvalidated batches, or you can validate all unvalidated batches when you close the window.

Allocation Formula Rules

Use the following definition rules when creating your allocation formulas. The allocation validation program checks that your formulas adhere to these rules:

For formula lines A, B and C (operand lines):

·         You can enter either an amount or an account in lines A, B and C.

·         If you enter an account, child values must have a Constant segment type.

·         Parent values may have a Constant, Looping or Summing segment type.

·         You can use a Constant segment type with a parent value only if it references a summary account.

·         If you use a Looping segment type on the same segment in more than one of the operand lines, you must use the same parent.

·         If you use a Looping segment type in your Target line, you must use a Looping segment type on the same segment using the same parent in lines A, B or C.

·         To use summary accounts, all segments in your formula must be assigned a segment type of Constant.

For target and offset lines (lines T and O)

·         You must enter an account in the Target and Offset lines.

·         Detail values must have a Constant segment type.

·         Parent values must have a Looping segment type.

·         Your Target account must be different from your Offset account.

For the target line only (line T)

·         If you use a Looping segment type in lines A, B or C, you must use a Looping segment type on the same segment using the same parent in your Target line.

For the offset line only (line O)

·         You can only use a Looping segment type in your Offset line if the corresponding segment type in your Target line is Looping.

·         If you use a Looping segment type in your Offset line, you must use the same parent as in your Target line.

Validation Business Rules

If you choose to use Full Cost Pool Allocation, below are the business rules used to validate your Allocation Formula Rules for lines A, B, and C. If your full cost pool allocation contains violations of the business rules, the execution report will detail the errors.

1. Line B is account based.

2. Line B has at least one looping segment.

3. Line C is account based and has the same segment values as line B.

4. Line C uses Constant or Summing segment type if line B uses Constant or Summing segment type.

5. At least one Summing or Constant segment in line C corresponds to a looping segment in line B.

Generating MassAllocation Journals

Generate MassAllocations to create unposted journal batches based on your validated MassAllocation formulas. The generated journal batch contains one entry for each allocation formula in the batch.

Use MassAllocation journals to reverse existing balances, post new allocation amounts, or generate journals that increment the existing balances to match the current allocation amount.

You can generate MassAllocation journal batches for any range of open or future enterable periods. If you are allocating encumbrances, all of the periods must be in open encumbrance years. General Ledger creates one unposted journal batch for each period in the range. If there is a closed period in the range of periods you specify, General Ledger generates a batch that cannot be posted until you open the period.

Choosing an Allocation Method

You can generate journals from allocation formulas using a full or incremental allocation method, depending on whether you want to replace or increment existing account balances.

Generating Journals Using the Full Allocation Method

Choose the Full allocation method to generate journals that reverse previous allocations or to post new allocation amounts. We recommend that you use this method only if you are allocating amounts for the first time, or only once.

To replace a previous allocation requires two steps. First, reverse the original allocation. Second, create a mass allocation for the new amounts.

Generating Journals Using the Incremental Allocation Method

Choose the Incremental allocation method when you want to update allocated balances without reversing the previous allocation batches. Using this method, you can generate allocation journals as many times as you wish, provided there is no activity against the target accounts between runs.

We recommend that you do not use the incremental method the first time you generate a MassAllocation entry. However, if you do generate your first MassAllocation entry using this method, your target balance must be zero.

Before generating incremental allocation journals, post all batches you previously generated from the same formula batch.

If you rerun your incremental batches, General Ledger uses cumulative period–to–date, quarter–to–date, year–to–date or project–to–date balances for the accounting period you specify. The first amount type General Ledger encounters in the A*B/C formula is the amount type used for the target account when calculating the incremental allocation amount (A*B/C).

Scheduling Your Allocation or MassAllocation Batch

You can generate your Allocation or MassAllocation Journal Batch according to schedules in Oracle Applications; schedules you define in Oracle Applications, or schedules you define in General Ledger.

MassAllocation Examples

The basic concept of Mass Allocation is dividing your cost on some factor. If we take a simple real life example then consider 5 friends having a dinner at a restaurant. Each of them buys a meal deal which costs $260 per person. Now if one of the friends pays the whole amount which is $1300. How will he calculate per head cost? The answer is simply by dividing 1300 by 5 or multiplying 1300 by 1/5. Mathematically 1300*1/5

This is the formula for MassAllocation A*B/C where,

A = Total Cost ($ 1300)

B = Factor (1deal per person)

C = Total Factor (Total Deals)

In Oracle General Ledger this facility is given to divide or allocate your expense cost or revenue income on your selected distributing criteria which can be your no. of departments, branches, head count, covered area, etc.

Example 1:

Suppose your account is composed of three segments: Company, Department and Account. You want to redistribute your monthly rent expense from department 100 to each department based on the amount of space each department occupies.

Department 999 is a parent that includes all departments except 100.

Department 100 is the department that stores all rent expenses.

Account 5740 is the rent expense account. SQFT is the statistical account used to record square footage for each department.

To allocate the monthly rent expense for company 01, define the following MassAllocation formula:

Row A represents the cost pool that you want to allocate to all departments. Rows B and C compute the relative amount of floor space occupied by each department. These rows access statistical accounts of the form 01–101–SQFT, 01–102–SQFT, and so on. 

Row B loops through all department segment values. Row C computes the total of all floor space occupied. Now assume that you will want to reallocate an adjusted cost pool without reversing the posted journal batches created by the previous MassAllocations. 

You define your MassAllocation with a different offset account from your cost pool:

The examples below will build upon the same MassAllocation as in the previous example, except the allocation amount is the incremental change. The original MassAllocation used a cost pool of $100,000, resulting in a journal entry like the following:

debit 01 – 101 – 5740.......45,000 Rent Expense – Dept 101

debit 01 – 102 – 5740.......30,000 Rent Expense – Dept 102

debit 01 – 103 – 5740.......25,000 Rent Expense – Dept 103

credit 01 – 100 – 5740.......100,000 Rent Expense – Dept 100

Now, assume that later you want to reallocate a rent cost pool increased by $10,000 to a total of $110,000. When you run the same MassAllocation formula in incremental mode for an accounting period with a cost pool of $110,000, General Ledger only allocates the adjustment to the cost pool, or $10,000. This produces the following journal entry:

debit 01 – 101 – 5740.......4,500 Rent Expense – Dept 101

debit 01 – 102 – 5740.......3,000 Rent Expense – Dept 102

debit 01 – 103 – 5740.......2,500 Rent Expense – Dept 103

credit 01 – 100 – 5740.......10,000 Rent Expense – Dept 100

After you post this journal entry, the balances in your rent expense accounts are:

01 – 101 – 5740.......49,500 Rent Expense – Dept 101

01 – 102 – 5740.......33,000 Rent Expense – Dept 102

01 – 103 – 5740.......27,500 Rent Expense – Dept 103

01 – 100 – 5740.......110,000 Rent Expense – Dept 100

Now assume that later you want to reallocate a rent cost pool decreased by $30,000 to a total of $80,000. When you run the same MassAllocation formula in incremental mode for an accounting period with $80,000 of rent expense, General Ledger produces the following journal entry:

debit 01 – 100 – 5740.......30,000 Rent Expense – Dept 100

credit 01 – 101 – 5740.......13,500 Rent Expense – Dept 101

credit 01 – 102 – 5740.......9,000 Rent Expense – Dept 102

credit 01 – 103 – 5740.......7,500 Rent Expense – Dept 103

After you post this journal entry, the new balances in your rent expense accounts are:

01 – 101 – 5740.......36,000 Rent Expense – Dept 101

01 – 102 – 5740.......24,000 Rent Expense – Dept 102

01 – 103 – 5740.......20,000 Rent Expense – Dept 103

01 – 100 – 5740.......80,000 Rent Expense – Dept 100

Posting the resulting incremental MassAllocation journal entry has a net effect of replacing the existing target balance with the allocated amounts from A*B/C.

Warning: When using MassAllocations or MassBudgeting, use accounts that receive all of their activity solely from incremental and regular MassAllocations and MassBudgeting. This ensures that General Ledger uses an accurate target balance for the incremental allocation.

Example 2

Consider an organization with 4 divisions or departments:

1. Enterprise Resource Planning (ERP)

2. Software Development (SD)

3. Software Support (SS)

4. Network Infrastructure (NI)

The COA Structure of this organization is Company-Branch-Department-Product-Account

The segment values of Department or the hierarchy of Department segment is

0000 - Common or No Department

1200- Information Technology (Parent) (Child Ranges: 1201 - 1299)

1201-ERP

1202-Software Development

1203-Software Support

1204-Network Infrastructure

Let’s allocate the telephone bill expense of $18950 for the month of June incurred at X branch on the number of employee each department has. The allocation basis in this example is Head Count per Department.

The account code for X branch is 101 and the natural Account for PTCL expense is 50201 and each department has 9, 11, 5, and 3 employees respectively. That is ERP has a head count of 9, SD has 11, SS has 5 and NI has a head count of 3.

Now the MassAllocation procedure steps starts.

STEP1: We will create a total cost or “A” of the formula. Pass a Standard JV in the period of JUNE with the following Lines

Line1: 1-101-0000-00-50201 18950(DR)

Line2: 1-101-0000-00-10122 18950(CR)

Line 1 Account Description: XYZ-X-NoDeparment-NoProduct-PTCL Expense

Line 2 Account Description: XYZ-X-NoDepartment-NoProduct-Bank

This journal entry is equivalent to paying your PTCL telephone bill. Ideally this expense entry should be coming from Oracle Payables. We are manually entering this actual journal so that we can created a 

Cost Pool “A” having an amount of $18950.

STEP2: Now we will create the “B” and “C” or Usage Factor and “Total Usage”. Pass a STAT JV. STAT is short for Statistical and it can be used by changing the currency from PKR to STAT. The STAT journal doesn’t need to be balanced. But they do affect the account balances if we inquire on the currency type of TOTAL but let’s not get there, it is a different topic. Simply pass a STAT JV to create “B” and “C”. Remember the Period of the JV should be JUNE as the Standard JV.

The account code combination for the STAT journals in this scenario will be

Line1: 1-101-1201-00-50201 9(DR)

Account Description: XYZ-X-ERP-NoProduct-PTCL Expense

Line2: 1-101-1202-00-50201 11(DR)

Line3: 1-101-1203-00-50201 5(DR)

Line4: 1-101-1204-00-50201 3(DR)

By passing or posting this STAT journal we are creating a basis for expense allocation. The line 1 tells that the XYZ organization has 9 employees at Karachi branch in ERP department incurring PTCL Expense. We can enable UOM on STAT journal by enabling the profile option JOURNAL:MIX STATISTICAL AND MONETARY to YES. Similarly so on and so forth. Now where are “B” and “C” in this journal? You can see 4 lines with changing Department codes, these four lines individually represent Usage Factor “B” which is 9, 11, 5 & 3 and collectively they represent Total Usage “C” which is equal to 9+11+5+3=28.

Now moving on with STEP3

Create a MassAllocation Batch and then a Journal. Name it X PTCL Expense Formula.

When you open the formula entry form you will find the three constant of the Mass Allocation formula A, B, C and two other fields T and O. “T” stands for Target Account and “O” stands for Offset Account. We will explain these Accounts later. Let’s continue with the formula.

Now give the account of the “A” which is 1-101-0000-00-50201 having the value of $18950. On the account entry form you will find that the system prompts or asks for Ledger, it is an optional field. This option of ledger set is used when we are allocating cost from multiple ledgers. And there is another LOV having the value as:

C: Constant - The segment is constant and doesn’t need any Loop or Sum. And the balance should be picked against “A” as a constant

L: Looping - The segment needs to loop from first value to last value provided in STAT JV.

S: Summing - The segment needs to sum the value in provided in STAT JV.

Generally the account code in “A” doesn’t not need any kind of looping or summing. So every segment should be given the value of C. The value this account has for the particular period should be picked as a constant. Keep the currency as Entered.

Now move on to enter the code for “B”. The account code for Usage Factor in our example will be

1-101-1200-00-50201. Note that I have given the department code as 1200 which is parent of the departments we selected for allocation basis. Give every segment a Constant C but the segment of Department will be having the value as Looping L. Why? Because we need to pick the individual values of 9, 11, 5 and 3.

REMEMBER: looping is only done on Parent Value of the Segment. In this example 1200 is the Parent department which has the child departments 1201, 1202, 1203 and 1204.

The system will automatically pick the allocation basis by matching the natural account and the looping segment.

REMEMBER: The currency for “B” and “C” should be STAT.

Now give the account code for the Total Usage “C”. The account code will remain the same as “B” with 1200 as the department code. The only difference this time is that instead of Looping we will give the Department segment the value of Summing S. so that we can have the sum of head count which is 28.

It’s time to give the “T” account. No, it’s not the T Account as we see in Ledger. It is the Target Account of the cost pool or these are the Debit Accounts which should hold the allocated expense. In our example these account are the accounts we gave in “B”. Yes the account code combination 1-101-1200-00-50201 with 1200 as Looping. IN FACT, usually the accounts given in “B” are repeated in “T” and account given in “A” is repeated in “O”

Let’s proceed further by entering the “O” or the Offset account. This account is same as the account we gave in “A”. This is the credit account. The account code combination given here wills 1-101-0000-00-50201 with every segment as Constant.

With this step we have completed our allocation formula. The final Journal generated with this formula should be:

Line 1	1-101-1201-00-50201	6091.071
Line2	1-101-1202-00-50201	7444.643
Line3	1-101-1203-00-50201	3383.929
Line4	1-101-1204-00-50201	2030.357
Line5	1-101-0000-00-50201		18950

If you enable the Full Cost Pool Allocation option then the system will post the rounding difference to the account with highest value. In this case the all the rounding will be given to line2 account. The first four accounts are the accounts we mentioned in Target field and the last account is the one we mentioned in Offset field. The accounting done here is that the PTCL Expense posted on a Common department was credited and distributed to four other departments on the basis we defined in STAT journal in Step 2.

If the concurrent request ends with an error then check the Output and Log file for error details.

Consolidations

Consolidation is the period-end process of combining the financial results of separate subsidiaries with the parent company to form a single, combined statement of financial results. If your company has shifted operations to another country or acquired a new subsidiary. then you may want to bring your foreign operations into the same database.

If you have operations or financial transactions in foreign currencies it is most likely that you operate with multiple sets of books. It is also possible that you operate multiple sets of books within the same functional currency. If this is the case, you should take advantage of the consolidation features of Oracle’s General Ledger.

The purpose of using Oracle consolidations is to move financial results from one set of books to another. The most common reason for setting up additional sets of books is to transact business in a different currency. Other reasons for setting up additional sets of books include using a different chart of accounts, operating with a different calendar, or using different document sequences for the same transaction source.

Consolidations in Oracle

There are some important issues to be considered before setting up consolidations:

• Do you have multiple consolidation levels? 
• Are all consolidated results reported in the same currency? Some organizations may need a consolidation of financial results in Euros and in USD.

Other important issues to discuss before setting up any consolidations are:

• How frequently will you consolidate financial results? 
• Will you consolidate budget amounts in addition to actual results? 
• What level of detail do you need in the consolidated set of books – balances or transactions from the subsidiary sets of books? Most organizations consolidate balances and use account drilldowns to view source transactions.
• When is the first period you want to consolidate financial results? The first period you consolidate; you should use LTD numbers to establish beginning balances.
• Do all of the subsidiaries set of books use the same chart of accounts? If not, then you will have to prepare a mapping of the account values.
• Do you use Multiple Reporting Currency (MRC) or Currency Translations to translate transactions from a foreign currency to your reporting currency?

What You Can Consolidate

With GCS, you can consolidate any business dimension at any level of detail from any point of view:

Any Source: Data from any source system, including ledger, databases, Oracle and non-Oracle applications can be consolidated with GCS. For Oracle Applications, use Cross Instance Data Transfer to transfer consolidation data to your parent on a remote instance. For non-Oracle applications use a customizable spreadsheet front-end or the open consolidation interface to upload your data into GCS.

Any Chart of Accounts: Subsidiaries can use separate chart of accounts from the parent to address unique operational accounting practices and meet local statutory requirements. GCS enables you to consolidate across diverse charts of accounts.

Any Calendar: Subsidiaries can use different accounting calendars from the parent. GCS enables you to consolidate across calendars.

Any Currency: Subsidiaries can use a ledger currency which differs from the parent’s ledger currency. GCS revalues and translates all subsidiary balances to ensure consistent consolidated results.

Any Level of Detail: Consolidate detail transactions, detail balances, and summary balances.

• Consolidate transactions when you want the convenience of accessing detailed information in the consolidated ledger and the ability to perform incremental updates to consolidated balances.
• Consolidate balances when you want the flexibility to transfer account details for only selected accounts.
• Consolidate summary balances when you only want to transfer aggregated account balances to the consolidated ledger. This method requires fewer resources and enhances processing performance.

Any Balance Type: Consolidate any balance type; including actual, average, translated, budget, and statistical balances.

Oracle Consolidation Setup Steps

The steps to set up and use the consolidation features in Oracle are:

1. Define the Parent or Consolidated Set of Books2. Map the values from the subsidiary set of books to the parent set of books.
3. Define the Eliminations

Executing the Consolidation Process

The first step in consolidation process begins with translating the accounts to the conversion currency. Depending on the methodology to translate your account balances, you may need to revalue some or all of the balances. Oracle has a process that follows accepted accounting principles to do that too. Once accounts are translated and properly valued, then you begin the consolidation process and that is to:

1. Transfer the Consolidation Mappings
2. Post the Consolidation Journals
3. Generate and Post the Elimination Journals

The first step is to transfer the account balances from the subsidiary set of books to the consolidated set of books. The Transfer Data form allows you to do this by clicking on the Transfer button. A few comments about the fields in this form will highlight the versatility of consolidations.

Balance Type: Use this field to transfer actual or budget amounts.
Currency: The amounts to be transferred from the subsidiary to the parent set of books must be in the same currency.
Method: Choose balances or transactions.

The values of these three fields are determined by the setups in the consolidation mapping. 

In the Subsidiary region, enter an Amount Type of PTD. Use PJTD the first time you transfer amounts to establish the correct beginning balance but after that you will only want to use PTD. Enter the period that is the source of the balances to be transferred. The screen shot shown below illustrates the Transfer of Consolidation Data Sets. Oracle provides a similar form to transfer a single consolidation mapping.

Use the Apply Defaults button to apply the values in the Default Parameters region to all the consolidation mappings in this mapping data set. The Options button allows you to select values for three different run options. They are:

1. Run Journal Import. The consolidation transfer process creates transactions that will populate the gl_interface table. Checking this option submits the Journal Import process that will create a journal in the consolidated set of books. The format of the journal batch name is <Date> <Consolidation Name> Consolidation <Request ID>: <Balance Type> <Group ID>

2. Audit Mode. Select this option to have the system keep a record of how accounts from the subsidiary set of books are mapped to the parent set of books. You can then run the Consolidation Audit Report and the Unmapped Subsidiary Accounts Report to see the audit information. (Only use this as needed to verify your consolidation mappings. You can improve the system’s performance by not using this option).

3. Create Summary Journals. If your mapping options point different subsidiary accounts to the same parent account then you might want to use this option so that only one entry for that account is created in the parent set of books.

When the transfer process is complete, the general ledger will have journals that are eligible for posting. Posting the journals is the second step. It is important to note that if for whatever reason you find that you need to execute the transfer consolidation for the same period again, you will have to reverse the journal. There is no mechanism to do an incremental transfer of consolidation data.

The third and final step is to generate and post the elimination journals. The first time you do this you will want to verify that the eliminations calculate the correct amounts.


Consolidation Workbench

In addition to providing mapping sets, Oracle has a Consolidation Workbench to help you manage the consolidation process. This is especially useful if you have to manage many consolidation mappings because it gives you in one view, the status of all your consolidation mappings and it provides a launch point to execute the next step in the consolidation. An example of this workbench or state controller as Oracle calls it is shown below:

Reporting

Aside from the obvious advantages of having all the financial results in one set of books, one very nice advantage about reporting is that all the existing financial statements will work for consolidation reporting. Nevertheless, with the financial results in one set of books, you may want to prepare additional financial statements such as those that show results of the subsidiaries in columns across the page.


All the standard reports such as trial balances and account analysis are also available.

Account Inquiry

You can use the account inquiry function in the consolidated set of books and trace the transaction source clear back to its original entry in the subsidiary set of books without having to sign in to the subsidiary set of books. You can do inquiries in the reporting currency or in the functional currency. Further, you can drill down to the source in that set of books whether it be an invoice, receipt, payment, etc.

Conclusion

Having consolidated data in one set of books offers advantages to financial reporting, analysis, and management. It helps ensure consistency in financial reporting and helps assure that financial controls are consistently applied. These advantages are significant and provide every reason to use the consolidation features in the Oracle General Ledger.


If you have the need to produce consolidated financial results and if you have more than one set of books, the Oracle Consolidation Process is an efficient method to accomplish that objective.