Processing Consolidations

This chapter provides an overview of consolidation processing and discusses how to:

• Validate the consolidation setup.

• Process eliminations.

• Process equitization.

• Process data flows.

• Process closing rules.

• Run tree flattener.

• Review application engine messages.

• Run related processes.

Note. This chapter assumes that you are already familiar with run controls, jobstreams, and PeopleSoft Enterprise Process Scheduler.

See Also

Enterprise PeopleTools PeopleBook: PeopleSoft Process Scheduler

Understanding Consolidation Processing

This section lists prerequisites and discusses:

• Consolidation processing.

• Reconciliation for consolidation processes.

• Delivered application engines and job streams.

Prerequisites

Before processing consolidations, you must:

• Prepare ledgers (including all related rules and processing).

• Define consolidation models, including elimination, equitization, flows, and non-controlling interest groups.

See Also

Running Ledger Preparation

Consolidation Processing

There are four main consolidation application engines: eliminations, data flows, equitization, and close. Each application engine is launched by a separate run control page. As with all application engines within the Enterprise Warehouse environment, you specify the following run control parameters: business unit, scenario, fiscal year, and accounting period. The system uses these parameters to determine which consolidation model it uses. For PeopleSoft Enterprise Global Consolidations processes, the specified business unit must be a common consolidation business unit. Depending on the processing method that you specify on the Ledger Template page, the system processes either a single period or all periods for that fiscal year that are less than or equal to the specified run control period.

Global Consolidations uses several record objects during processing: the consolidation ledger (CLED), the input log (ILOG), the output log (OLOG), the journal table, and related temporary tables. During processing, the general data flow is:

1. The system retrieves data that matches the run control parameter criteria from the consolidation ledger and stores it in the ILOG.

2. Processing occurs, using the consolidation model rules that apply.

3. The system writes results to the OLOG and calculates any out-of-balance amounts.

4. The system writes the resulting journal lines to the journal table that you define in the ledger template for the consolidation ledger.

5. Depending on the processing options that you select, the system posts the journals to the consolidation ledger as the last processing step, or you can run the Ledger Post application engine at a later time.

   The system does not update the consolidation ledger with the results until you run the ledger post process.

This diagram illustrates the process flow:

Overview of process flow

Spawning

When you process eliminations and equitization, the system uses spawning to process multiple jobs, optimizing performance. The main application engines, or parent jobs, spawn the child jobs.

During elimination processing, the system assigns one record suite to the parent elimination manager (GC_ELIMMGR) engine, spawns one job for intercompany eliminations, and as many non-controlling interest (NCI) jobs as the number of remaining available record suites. For example, if there are a total of three record suites available, one is used by the elimination manager, one is used by the intercompany elimination spawned job, and the third is used for an NCI spawned job. If there are five record suites available, three can be used for NCI spawned jobs.

The system equitizes subsidiaries based on the ownership level sequence. Spawning of equitization jobs depends on the total number of subsidiaries in the ownership level divided by the number of record suites available. This strategy enables parallel processing for subsidiaries, reducing the amount of time required to process them all. The more record suites that are available, the faster processing occurs. During equitization processing, the system assigns one record suite to the parent equitization manager (GC_EQ_MGR) engine, spawning two (child) equitization jobs for each ownership level. When both jobs for the lowest ownership level are complete, the system spawns two more jobs for the next ownership level, and so on.

If you need to cancel processing for eliminations or equitization jobs, you should cancel spawned jobs first (the child jobs), then the parent job. If you are using the delivered jobstreams for processing, you can identify parent jobs by the process name PF_JOBSTREAM. The process names for spawned jobs are:

• GC_ICUELIMS for intercompany eliminations.

• GC_NCI_ELIM for non-controlling interest eliminations.

• GC_EQTZ for equitization.

This process monitor example shows the parent and spawned children for an equitization process that was run by using the delivered jobstream:

Process Monitor page

ILOG and OLOG Maintenance for Reruns

During a rerun, the system adds the prior run's batch ID to GC_DELBATCH_TBL. The Delete Batch engine (GC_DELB) deletes the ILOG and OLOG data for the prior run batch. You should either run this as the last job in the jobstream when processing eliminations or equitization, or run it as a separate jobstream that you can schedule to run during off-peak hours—for example, sometime overnight. The delivered jobstream is GC_DELB.

See Also

Streamlining Processing with Jobstreams

Defining System-Wide Security and Processing Options

Reconciliation for Consolidation Processes

As part of consolidation processing, reconciliation occurs at several stages. The reconciliation programs include balance rules that check the records used during ledger preparation and consolidation processing. For ledger preparation, the system uses a filter-based query that returns the count of the number of records in the source and target tables during calendar mapping, account mapping, and currency mapping. The number of records in the source and target should be equivalent. For consolidation processing, the system uses a filter-based query that verifies that debits equal credits in the output journal. This table describes the individual jobs that are used to reconcile specific aspects of ledger preparation or consolidation processing:

Ledger preparation reconciliation points

These jobs are run as part of ledger preparation or consolidation processing. The IDs for the balance rules, filters, and constraints used by these jobs all start with GCRECN, and are in the SHARE setID. For these jobs to work, you must not remove any rows from the delivered filter and constraint definitions. The delivered rules are intended primarily as examples; review them for applicability to your specific business requirements.

To view the status of the reconciliation jobs on the consolidation manager or ledger preparation manager pages, use the Consolidation Processes page to add the job IDs to their related page, and then on the Status Details page, click the View Reconciliation Totals link to view the results.

See Also

Configuring the Consolidation Manager and Ledger Preparation Manager Pages

Using Balancing and Reconciliation Features

Delivered Application Engines and Jobstreams

The Global Consolidation batch processes use several different PeopleSoft application engine programs. This section provides a complete list of the engines used and the jobstream definitions that are provided with the delivered sample database in the SHARE setID. This information is provided so that you can create your own jobstreams or modify the delivered ones to suit your implementation.

Delivered Application Engines

PeopleSoft Enterprise Performance Management applications use application engines to run each process. Engine metadata is delivered with the system; unless you are revising the application, you should not need to modify it. This metadata stores information about the various PeopleSoft application engine programs used within an engine. This table lists the delivered engines that are used by PeopleSoft Enterprise Global Consolidations when processing consolidations by using the delivered jobstreams and their associated jobs:

Delivered Jobstreams

PeopleSoft Enterprise Global Consolidations uses jobstreams for processing. Jobstreams enable different users to run a series of application engines at the same time by using temporary tables. Instead of using fact tables in the Enterprise Performance Warehouse, temporary tables, using record suites, use only the relevant data from the main fact tables to run the application engines and process the data. This strategy enables the application engines in the jobstream to run faster (because the entire fact table is not being used) while keeping the fact tables open and accessible to other users so that they can run the same engines simultaneously. The record suites are assigned when the first application engine runs, then released when the last application engine is finished.

You associate each main application engine with a job ID on the Job Metadata page. You associate jobs with a jobstream on the Jobstream setup page. You must also define record suites for the jobstream on the Jobstream Record Suites page. A job must be unique across all jobstreams, so if you require additional jobstreams, you first need to create new jobs to use in each jobstream. This table lists each batch process, the delivered jobstream, and the engines and job IDs used in that jobstream:

Note. Do not select As Of Dated Jobstream. This option is not supported for PeopleSoft Enterprise Global Consolidations application engines. If you select this option, your results will be incorrect.

Validating the Consolidation Setup

This section provides an overview of the Consolidation Validation application engine and describes how to run the Validation application engine.

Understanding the Consolidation Validation Application Engine

PeopleSoft recommends that you run the Consolidation Validation application engine to verify that the consolidation setup is correct. The delivered job and jobstream are both named GC_VALID. You may opt to run the Consolidation Validation application engine in its own jobstream by using the delivered run control page, or consider adding it to other jobstreams, depending on your organization's requirements. Optimally, you should check the validation errors before running the Ledger Preparation application engine or processing consolidations business rules.

The Consolidation Validation application engine checks that these objects and rules are valid, writing the results to the PeopleSoft Enterprise Performance Warehouse message log:

• Consolidation model definition.

• Mapping rules (calendar mapping, currency mapping, data mapping for ChartFields).

• Consolidation tree.

• Equitization rules.

• Elimination rules.

• Non-controlling interest rules.

• Data flow rules.

• Closing rules.

• Ownership rules, including circular references or ownership validation.

Page Used to Validate the Consolidation Setup

Running the Validation Application Engine

Access the Validation run control page.

Unit, Scenario ID, Fiscal Year, and Period	Specify the common consolidation business unit, scenario ID, fiscal year, and accounting period to process.
Jobstream ID	Accept the default value, GC_VALID, to use the delivered jobstream ID.

Review the application engine message log for the process instance after processing is complete to see the results.

See Reviewing Application Engine Messages.

Processing Eliminations

This section provides an overview of elimination processing and discusses how to run the Elimination application engine.

Understanding Elimination Processing

Use the Elimination run control page to process eliminations, which eliminates or cancels out the effects of intercompany transactions and non-controlling interests. When you process eliminations, you can opt to process intercompany eliminations or non-controlling interest eliminations, or both.

When you specify to process intercompany eliminations, the system:

1. Resolves data from the CLED into the ILOG, based on the elimination rules for the consolidation model, the fiscal year, and period that you specify in the run control, and adds a sequence number key to each row.

2. Processes eliminations on the resolved ILOG data by creating entries in the OLOG to the specified elimination target ChartFields with a reversed sign, booking the entries to the elimination entity for that node.

3. After populating the OLOG with the elimination entries, calculates the out-of-balance amount from the OLOG lines and creates the out-of-balance entries to the OLOG.

4. Creates reversal entries for eliminations, if necessary.

   This step depends on the processing method, which is established on the Ledger Template page. The system creates reversal entries only if you are using a trial balance format and processing year-to-date, except when you are processing the last accounting period of the year.

   Note. Steps one through four use temporary (work) tables.

5. Merges the temporary ILOG and OLOG tables into their permanent tables, GC_ILOG_XXX_TBL and GC_OLOG_XXX_TBL, respectively.

6. Creates the journal lines in the journal table with a GC_SOURCE of 04 (elimination entry).

7. Posts the journals to the CLED, if you choose to automatically post them.

If you are processing a rerun, then during the initial stages of processing, the system unposts any posted journals from the prior run that affect the same data, or the system deletes them if they weren't posted. If you rerun using a different consolidation tree node, the system only unposts (or deletes) journals from the prior run that were recorded against nodes within the tree node now being processed.

When you specify to process non-controlling interest eliminations, the system:

1. Resolves the data for the subsidiary equity accounts from the CLED into the ILOG, and adds a sequence number key to each row.

2. Resolves the data for the parent investment accounts from the CLED into the ILOG.

3. Eliminates the subsidiary equity data by creating the entries in the OLOG to the specified elimination target ChartFields with a reversed sign, booking the entries to the elimination entity.

4. Similarly, eliminates the parent investment data, generates non-controlling interest adjustments, and creates out-of-balance amounts in the OLOG, if applicable.

5. Creates reversal entries for the non-controlling interest eliminations, if necessary.

   This step depends on the processing method, which is established on the Ledger Template page. The system creates reversal entries only if you are using a trial balance format and processing year-to-date, except when you are processing the last accounting period of the year.

   Note. Steps one through five use temporary (work) tables.

6. Merges the temporary ILOG and OLOG tables into their permanent tables, GC_ILOG_XXX_TBL and GC_OLOG_XXX_TBL, respectively.

7. Creates the journal lines in the journal table with one of these GC_SOURCE values:

   6A	The parent investment elimination and the elimination of the portion of the subsidiary equity that is from that parent, as well as any out-of-balance entries.
   6B	The non-controlling interest liability elimination, and the elimination of the portion of the subsidiary equity due to the non-controlling interest.

8. Posts the journals to the CLED, if you choose to automatically post them.

Note. When using the financial statement format, you must run the NCI eliminations after the equitization process. In this way, the system properly eliminates the additional investment from the equitization process.

Pages Used to Process Eliminations

Running the Elimination Application Engine

Access the Eliminations run control page.

Unit, Scenario ID, Fiscal Year, and Period	Specify the common consolidation business unit, scenario ID, fiscal year, and accounting period to process.
Jobstream ID	Accept the default value, GC_ELIMMGR, to use the delivered jobstream ID.

Select which of these processing options to use:

Processing Equitization

This section provides an overview of equitization processing and discusses how to run the Equitization application engine.

Understanding Equitization Processing

If you've set up equitization groups for your consolidation model, use the Equitization run control page to process equitization, which equitizes the current period changes in equity (for example, net income) of subsidiaries.

When processing equitization, the system completes these steps for each ChartField value in the equitization rule group:

1. Resolves data from the CLED into the ILOG, based on the equitization rule group for the consolidation model, the fiscal year, and the period that you specify in the run control, and adds a sequence number key to each row.

2. Debits the ownership percentage amount for the account of the subsidiary against the parent investment account of the parent (if the control percentage is greater than the threshold), and credits the ownership percentage amount for the account of the subsidiary against the investment offset of the parent, and then moves the data to the OLOG.

   These entries, which increase the parent investment account and increase parent earnings, are booked directly against the parent. Optionally, the system eliminates the amount equitized against the elimination entity (if you define the eliminate equitizations fields for the rule). For the financial statement format, the system creates offset balance entries for the income statement side, similar to the investment offset entries.

3. Offsets the total equitized source amount to the equitization summary account specified in the rule by debiting the equitization offset account for the subsidiary and crediting the equitization summary, and then moves the data to the OLOG.

   These entries are booked against the subsidiary. (This is an optional step, completed only if defined on the Equitization - Subsidiary Offset page.)

4. Generates non-controlling interest adjustments for claims on the subsidiary’s net income for the period.

   For trial balance format, the system debits the non-controlling interest expense account and credits the non-controlling interest liability account. For financial statement format, only the expense entries are created. The entries are booked to the elimination entity.

5. For the financial statement format, creates elimination entries at the controlling parent to eliminate 100 percent of the source amounts identified if the equitization rule's processing option is Source Elimination.

   Optionally, the system creates non-controlling interest entries and the corresponding elimination entries.

6. Creates dividend reclassification entries to the equitizing parent for the dividend amounts of a subsidiary, distributed to the direct parents of the subsidiary if the equitization rule's processing option is Dividend Reclassification.

   Optionally, the system creates additional reclassification entries for the dividend amount to the elimination unit that is common to both the equitizing parent and the direct parent.

7. Creates reversal entries for the equitization, if necessary.

   This step depends on the processing method, which is established on the Ledger Template page. The system creates reversal entries only if you are using a trial balance format and processing YTD, except when you are processing the last accounting period of the year.

8. Merges the temporary ILOG and OLOG tables into their permanent tables, GC_ILOG_XXX_TBL and GC_OLOG_XXX_TBL, respectively.

9. Creates journal lines in the journal table with one of these GC_SOURCE values:

   5A	Equitization.
   5B	Equitization - elimination entry.
   5C	NCI for current earnings.
   5D	Equitization - subsidiary offset entry.
   5E	Equitization - elimination of NCI.
   5F	Equitization - elimination of source.
   5G	Equitization - dividend reclassification.

10. Posts the journals to the CLED, if you choose to automatically post the journals.

See Consolidation Data Source.

If you are processing a rerun, then during the initial stages of processing, any journals that were posted during the prior run affecting the same data are unposted, or are deleted if they weren't posted. If you rerun using a different consolidation tree node, the system only unposts (or deletes) journals from the prior run that were recorded against nodes within the tree node now being processed.

Pages Used to Process Equitization

Running the Equitization Application Engine

Access the Equitization run control page.

Unit, Scenario ID, Fiscal Year, and Period	Specify the common consolidation business unit, scenario ID, fiscal year, and accounting period to process.
Jobstream ID	Accept the default value, GC_EQ_MGR, to use the delivered jobstream ID.

Select which of these processing options to use:

Processing Data Flows

This section provides an overview of the flow update process and discusses how to:

• Run the Source Flow Update process.

• Run the Journal Flow Update process.

• Run the Flow Flattener.

Understanding the Flow Update Process

The flow update process enables you to validate, translate, and update the flow amounts to the Flow Activity record (GC_FLOW_MGT_F00). The flow update engines update the flows based on the ledger business unit and returns errors for you to review on the Source Flow and Journal Flow Input pages if the flows do not validate, i.e. the difference to reconciled is zero.

Flow processing occurs in the following steps:

• Enter flows on the Source Flow Input page.

• Run the Source Flow Update process.

  • Associate flow codes to journal lines.

  • Associate flow codes to allocations.

  • Run the Journal Post process.

• Run the Journal Flow Update process.

  • Correct flow amounts for journals on Journal Flow Input page.

  • Rerun the Journal Flow Update process.

• Run the Flow Flattener.

Flow processing is divided into two phases: Source Flows and Journal Flows. After running Ledger Preparation, you can enter flow amounts in the Source Flow Input page and run the Source Flow Update engine to update the flow activity record. Source flows are entered by Fiscal Year, Accounting Period, Ledger Business Unit and template. Note that if book code functionality is turned on, you must select a book code group to enter the source flows by book code. As source flows are entered in the foreign currency, the Source Flow Update engine will translate and update the flow activity record accordingly. The engine will translate the flow amounts at the closing rate and cash flow rate. The Source Flow Update process also updates the Source Flows status on the Ledger Enrichment Manager page.

The second phase for processing flows is for journals. Journal flows can be recorded one of two ways: associating flow codes on the journal lines or entering journal flow amounts directly within the Journal Flow Input page.

To tie flow codes to journal lines, you must turn on flow processing on the Ledger Template setup page. After you turn on flow processing, the flow code column is active on the Journal Entry, Recurring Journal, and Allocations setup pages. You can enter flow codes on these pages and run the Journal Post process to post the journal.

After you post the journal, run the Journal Flow Update process to write the flows to the Flow Activity record (GC_FLOW_MGT_F00) . Any corrections to the journal flow amounts can be performed within the Journal Flow Input page. NOTE: The Journal Flow Update engine does not perform any translations as all journal flows are entered in the consolidation currency. The journal Flow Update program updates the Journal Flows status on the Consolidation Manager.

The Flow Flattener application engine populates the flow flattener table, which designates the flow template and accounts by business unit, scenario, fiscal year, and accounting period. This table is a key input for the Flow Inquiry report. The system calls the Flow Flattener application engine when the Source Flow Update or Journal Flow Update application engines are run. Occasionally, you may need to run this engine separately. You can access the Flow Flattener run control page to run this application engine.

Pages Used to Process Flow Updates

Running the Source Flow Update Process

Access the Source Flow Update run control page.

Business Unit, Scenario ID, Fiscal Year, and Period	Enter the common consolidation business unit, scenario ID, fiscal year, and accounting period to process.
Jobstream ID	Accept the default value, GC_FLSRC, to use the delivered jobstream ID.
Rerun Option	Select this check box if you are rerunning this job. If you get the same record suites, the system does not re-resolve the tables prior to running the job. Re-resolving means that data is reselected from the permanent table and moved to temporary tables of the assigned record suite. By selecting this option, you can enhance performance.
Run Group ID and Ledger Unit	Select either a run group ID to process or a single ledger unit (the business unit associated with the ledger).

Running the Journal Flow Update Process

Access the Journal Flow Update run control page.

Business Unit, Scenario ID, Fiscal Year, and Period	Specify the common consolidation business unit, scenario ID, fiscal year, and accounting period to process.
Jobstream ID	Accept the default value, GC_FLJRNL, to use the delivered jobstream ID.
Rerun Option	Select this check box if you are rerunning this job. If you get the same record suites, the system does not re-resolve the tables prior to running the job. Re-resolving means that data is re-selected from the permanent table and moved to temporary tables of the assigned record suite. By selecting this option, you can enhance performance.
View Pending Batches	Click to view pending or posted batches on the Flow Journal Update - Pending Batches page. This does not have the same functionality as in the Post process. All the pending batches will be processed. Use the magnifier push buttons to view the TSE error summary or balance error details. Use the force flag to post the batch even if TSE or balance errors exist. However, only valid data from the process run is posted.

Running the Flow Flattener

Access the Run Flow Flattener page.

Business Unit, Scenario ID, Fiscal Year, and Period	Specify the common consolidation business unit, scenario ID, fiscal year, and accounting period to process.
Jobstream ID	Accept the default value, GC_FLOWFLT, to use the delivered jobstream ID.
Rerun Option	Select this check box if you are rerunning this job. If you get the same record suites, the system does not re-resolve the tables prior to running the job. Re-resolving means that data is reselected from the permanent table and moved to temporary tables of the assigned record suite. By selecting this option, you can enhance performance.

Processing Close

This section provides an overview of the Closing process and discusses how to run the Closing process (GC_CLOSMGR).

Understanding the Closing Process

If you have setup Close group for your consolidations model, use the Close Process run control to page to process Close, which Closes the Income statement account balances to retained Earnings and rolls forward Balance sheet account Balances.

When running the close process, you either run year-end or period-end processing. Trial balance based consolidation uses year-end processing, whereas financial statement based consolidation uses period-end processing.

When you enter the business unit and scenario on the run control page, an edit checks the consolidation model, consolidated ledger, and the ledger template to determine whether the business unit and scenario combination is a trial balance or financial statement based consolidation. If the consolidation method is trial balance, the period input field is display-only, and the system displays a close process type of Year End Processing in grey. In addition, the request type options are limited to Close/Rollforward or Delete. The Delete request type enables you to clear out the previous run data and reset the close and rollforward amounts to zero. If the consolidation method is Financial Statement, enter the fiscal year and period in which you want to perform the close processing. If the period selected is not the last period of the fiscal year (e.g. 12), then you may only select Rollforward Only or Delete. If the period selected is the last period, then you may select Close/Rollforward or Delete.

When processing Close, here is an overview of the steps performed for each Consolidation Dimension value/Tree Node in the Close Process group:

1. Resolves data from the CLED, based on the Close Process group for the consolidation model, the fiscal year, and the period that you specify in the run control, and Ledger Template associated with the consolidation Model.

2. If processing the Close Option, the system creates a target entry in the next fiscal year/accounting period based on ChartField Value sets and Source Input option specified on Close Rule.

3. If processing the RollForward Option, the system rolls forward balances in the next accounting period based on ChartField Value sets and Source Input option specified on RollForward Rule.

The Close Process Creates Ledger entries with following GC source values:

After the close process has run, you can review the results on the Ledger Inquiry page. To view the amounts closed to retained earnings or balances rolled forward for trial balance based consolidations, specify the period of zero for the next fiscal year.

For financial statement based consolidations, select the fiscal year and period in which the balances were rolled forward. View this inquiry after the rollforward process has been run but before the next period is processed, or you can view through the consolidation audit, and filter by the source process on the rollforward processing entries.

Page Used to Process Closing Rules

Running the Closing Process

Access the Close Process page.

Unit, Scenario ID, Fiscal Year, and Period	Specify the common consolidation business unit, scenario ID, fiscal year, and accounting period to process.
Scenario Locking	Select this option to lock a period to processing. Click to access the Scenario Locking page, on which you can prevent journals from being posted to the selected fiscal year or period.
Override Scenario's Tree Node	Select to use a different tree node than that specified on the consolidation model. Click the Tree button to select a tree node if you use this option. The tree node that you specify must be at a lower hierarchical level of the tree than the node specified on the consolidation model.
Jobstream ID	Accept the default value, GC_CLOSMGR, to use the delivered jobstream ID.
Close Process Type	Select the close process type. If the consolidation method is trial balance, the period input field is inactive and the system displays the close process type as Year End Processing in grey. If the consolidation method is financial statement based, the period input field is active and the close process type is Period End Processing in grey. The parameter options are the same as year-end processing with two exceptions. First, you must specify the period that is to be rolled forward. The request type options you can choose are: Close/Rollforward, Rollforward Only, or Delete. If you select a period other than the last period, then you can only select Rollforward Only or Delete. If you select the last period, then you can select Close/Rollforward or Delete. Note. Financial statement consolidations do not have a period zero. When selecting period end processing with a period set to the last period, the system runs the close process to period one of the next fiscal year.
Close Request Type	Select the close request type. When the request type option is Close/Rollforward, the application engine posts the close amounts to the target account as a one-sided entry as well as posts the carry-forward balances to period 0 of the next fiscal year.

If you need to undo the year-end or period-end process, the system provides you with two options. First, if you incorrectly ran the close process and need to reset the posted amounts to zero, then set the close request type to Delete. If you want to replace the amounts that have been posted, then rerun the run control. The application engine deletes the entries from the previous run and replaces the amounts to retained earnings and rollforward balances with the current posting.

Running Tree Flattener

This section provides an overview of tree flattener and discusses how to run the Tree Flattener application engine (GC_TREEFLT).

Understanding Tree Flattener

To improve performance on the inquiry and analysis pages, run tree flattener on any trees that you use for inquiries—for example, an account tree. This process creates a database table of the tree structure, which the inquiry and analysis pages use to navigate through the tree nodes.

To use the Trial Balance page prior to processing eliminations or equitizations, you must run tree flattener on your consolidation tree. This step is not a requirement if you have already run eliminations or equitization, as the consolidation tree is automatically flattened during those processes.

See Also

Understanding Tree and Recursive Hierarchy Processing

Page Used to Run Tree Flattener

Running Tree Flattener

Access the Run Tree Flattener page.

Unit, Scenario ID, Fiscal Year, and Period	Specify the common consolidation business unit, scenario ID, fiscal year, and accounting period to process.
Jobstream ID	Accept the default value, GC_TREEFLT, to use the delivered jobstream ID.
Trees to Flatten	Select the trees to process.

Reviewing Application Engine Messages

Use the PeopleSoft Enterprise Performance Warehouse Engine Message component to review any messages generated during a specific process instance. For details about using these pages, refer to the PeopleSoft Enterprise Performance Warehouse documentation.

See Common Elements Used in This Section.

See Viewing Engine Messages.

Pages Used to Review Engine Messages

Running Related Processes

There are several additional PeopleSoft Enterprise Performance Warehouse processes that you may run in the course of using PeopleSoft Enterprise Global Consolidations:

• Ledger Post and Ledger Unpost.

• Allocations.

• ETL to the Multidimensional Warehouse for Reporting.

• Reconciliation.

These application engines are delivered as part of PeopleSoft Enterprise Performance Warehouse and are covered in detail in the PeopleSoft Enterprise Performance Warehouse 8.9 PeopleBook.

See Working with EPM Foundation Utilities.