Oracle® CLE: Correspondence Accounting User Guide Release 12.0

Oracle® CLE
Correspondence Accounting User Guide

Release 12.0
Part No. B00001-05
January 2008
Oracle CLE Correspondence Accounting User Guide, Release 12.0
Part No. B00001-05
Copyright © 2008, Oracle. All rights reserved.
Primary Author: Iyer Kannan Ramalingam and Pawan Tallam
The Programs (which include both the software and documentation) contain proprietary information; they
are provided under a license agreement containing restrictions on use and disclosure and are also protected
by copyright, patent, and other intellectual and industrial property laws. Reverse engineering, disassembly, or
decompilation of the Programs, except to the extent required to obtain interoperability with other
independently created software or as specified by law, is prohibited.
The information contained in this document is subject to change without notice. If you find any problems in
the documentation, please report them to us in writing. This document is not warranted to be error-free.
Except as may be expressly permitted in your license agreement for these Programs, no part of these
Programs may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any
purpose.
If the Programs are delivered to the United States Government or anyone licensing or using the Programs on
behalf of the United States Government, the following notice is applicable:
U.S. GOVERNMENT RIGHTS

Programs, software, databases, and related documentation and technical data delivered to U.S. Government
customers are "commercial computer software" or "commercial technical data" pursuant to the applicable
Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication,
disclosure, modification, and adaptation of the Programs, including documentation and technical data, shall
be subject to the licensing restrictions set forth in the applicable Oracle license agreement, and, to the extent
applicable, the additional rights set forth in FAR 52.227-19, Commercial Computer Software--Restricted
Rights (June 1987). Oracle Corporation, 500 Oracle Parkway, Redwood City, CA 94065.
The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or other inherently
dangerous applications. It shall be the licensee's responsibility to take all appropriate fail-safe, backup,
redundancy and other measures to ensure the safe use of such applications if the Programs are used for such
purposes, and we disclaim liability for any damages caused by such use of the Programs.
The Programs may provide links to Web sites and access to content, products, and services from third parties.
Oracle is not responsible for the availability of, or any content provided on, third-party Web sites. You bear all
risks associated with the use of such content. If you choose to purchase any products or services from a third
party, the relationship is directly between you and the third party. Oracle is not responsible for: (a) the quality
of third-party products or services; or (b) fulfilling any of the terms of the agreement with the third party,
including delivery of products or services and warranty obligations related to purchased products or services.
Oracle is not responsible for any loss or damage of any sort that you may incur from dealing with any third
party.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks
of their respective owners.

Contents
Send Us Your Comments
Preface
1 Introduction
Correspondence Accounting Functionality.............................................................................. 1-1
2 Localization Setup
Setting Up Correspondence Accounting solution.................................................................... 2-1
3 Solution Overview
Overview................................................................................................................................... 3-2
4 CLE: CA GL Translation Program

Introduction............................................................................................................................... 4-1
Prerequisites.............................................................................................................................. 4-1
Program Submission................................................................................................................. 4-2
Program Parameters................................................................................................................... 4-2
Processing.................................................................................................................................. 4-3
Output ..................................................................................................................................... 4-25
Exceptions................................................................................................................................ 4-25
5 CLE: CA Universal Tool

Introduction............................................................................................................................... 5-1
Prerequisites.............................................................................................................................. 5-2
iii
Form Navigation ....................................................................................................................... 5-3
Processing.................................................................................................................................. 5-7
6 CLE: CA XLA Translation Program

Introduction............................................................................................................................... 6-1
Prerequisites.............................................................................................................................. 6-2
Program Output......................................................................................................................... 6-5
Processing.................................................................................................................................. 6-5
7 CLE: CA Correction Form

Introduction............................................................................................................................... 7-1
Prerequisites.............................................................................................................................. 7-1
Form Navigation........................................................................................................................ 7-1
Form Descriptions..................................................................................................................... 7-1
8 CLE: CA Interface Transfer Program

Introduction............................................................................................................................... 8-1
Prerequisites.............................................................................................................................. 8-1
Output File................................................................................................................................. 8-3
Exceptions.................................................................................................................................. 8-3
9 CLE: CA Interface Post Program

Introduction............................................................................................................................... 9-1
Processing.................................................................................................................................. 9-2
Output File................................................................................................................................. 9-3
Exceptions.................................................................................................................................. 9-3
10 CLE: CA Account Reconciliation Report

Introduction............................................................................................................................. 10-1
Prerequisites............................................................................................................................ 10-1
Program Submission............................................................................................................... 10-1
Program Parameters................................................................................................................. 10-2
Program Output....................................................................................................................... 10-2
iv
Processing................................................................................................................................ 10-3
11 CLE: CA Account Analysis Report

Introduction............................................................................................................................. 11-1
Prerequisites............................................................................................................................ 11-1
Program Output....................................................................................................................... 11-3
Processing................................................................................................................................ 11-3
12 CLE: CA Account Journal Report

Introduction............................................................................................................................. 12-1
Prerequisites............................................................................................................................ 12-1
Program Output....................................................................................................................... 12-3
Processing................................................................................................................................ 12-3
13 Custom Sources
Details...................................................................................................................................... 13-1
14 Glossary
Details...................................................................................................................................... 14-1
Index
v

Send Us Your Comments
Oracle CLE Correspondence Accounting User Guide, Release 12.0

Part No. B00001-05
Oracle welcomes customers' comments and suggestions on the quality and usefulness of this document.
Your feedback is important, and helps us to best meet your needs as a user of our products. For example:
• Are the implementation steps correct and complete?
• Did you understand the context of the procedures?
• Did you find any errors in the information?
• Does the structure of the information help you with your tasks?
• Do you need different information or graphics? If so, where, and in what format?
• Are the examples correct? Do you need more examples?
If you find any errors or have any other suggestions for improvement, then please tell us your name, the
name of the company who has licensed our products, the title and part number of the documentation and
the chapter, section, and page number (if available).
Note: Before sending us your comments, you might like to check that you have the latest version of the
document and if any concerns are already addressed. To do this, access the new Applications Release
Online Documentation CD available on Oracle MetaLink and www.oracle.com. It contains the most
current Documentation Library plus all documents revised or released recently.
Send your comments to us using the electronic mail address: appsdoc_us@oracle.com
Please give your name, address, electronic mail address, and telephone number (optional).
If you need assistance with Oracle software, then please contact your support representative or Oracle
Support Services.
If you require training or instruction in using Oracle software, then please contact your Oracle local office
and inquire about our Oracle University offerings. A list of Oracle offices is available on our Web site at
www.oracle.com.
vii

Preface
Intended Audience
Welcome to Release 12.0 of the Oracle CLE Correspondence Accounting User Guide.
Welcome to Release 12 of the Oracle Correspondence Accounting User Guide. This user
guide includes following information to help you understand the following aspects of
the Localization and implement the Localization effectively for Russian, Ukrainian and
Romanian customers.
• Product Setup
• Solution Overview
• Translation Programs
• Programs
• Reports
About this Country-Specific User Guide

This user guide documents the functionality of Russian, Ukrainian and Romanian
specific consulting Localization components developed in this patch. This document
explains the additional functionality provided by Russian, Ukrainian and Romanian
Consulting Localization patch and supplements the functionality of Standard Financial
/ SCM modules and Russian, Ukrainian and Romanian country specific Localization.
User's Guides Related to This Product
This guide contains references to the following Oracle publications. Use the Release 12i
versions of these guides, unless otherwise specified.
• Oracle General Ledger User's Guide
• Oracle Payable User's Guide
ix
• Oracle Receivables User's Guide
• Oracle Cash Management User's Guide
• Oracle Assets User's Guide
• Oracle Inventory User's Guide
• Oracle Cost Management User's Guide
• Oracle Subledger Accounting User's Guide
DISCLAIMER:
CURRENTLY, ORACLE OFFERS CERTAIN RESALABLE ASSETS OR OTHER
DEFINED SERVICE DELIVERABLES (COLLECTIVELY REFERRED TO AS
"SERVICE DELIVERABLES") UNDER A LIMITED USE LICENSE. THE SERVICE
DELIVERABLES CURRENTLY INCLUDE, BUT ARE NOT LIMITED TO, ORACLE
INTEGRATION HUB. YOU AGREE THAT:
• SERVICE DELIVERABLES ARE NOT ORACLE STANDARD SOFTWARE
PROGRAMS.
• TECHNICAL SUPPORT FOR SERVICE DELIVERABLES IS NOT AVAILABLE

FROM OR UNDER, OR PROVIDED BY OR THROUGH, ORACLE'S SUPPORT
SERVICES ORGANIZATION OR YOUR ORACLE PROGRAM LICENSE
AGREEMENT.
• YOUR RIGHT TO USE AND RECEIVE SUPPORT SERVICES FOR SERVICE

DELIVERABLES IS SOLELY AS DESCRIBED IN YOUR CONTRACT FOR
SUCH SERVICE DELIVERABLES.
• A SERVICE REQUEST REGARDING SERVICE DELIVERABLES,

REGARDLESS OF HOW INITIATED OR LOGGED, WILL BE ADDRESSED IN
ACCORDANCE WITH THE TERMS OF YOUR CONTRACT FOR SUCH
SERVICE DELIVERABLES.
Installation
This product is installed after the base install of oracle e-business suite before using the
application for transaction processing. The details of the patches to be applied are
available to download from metalink. Please ensure the prerequisites are taken care
before installing the patch
See Related Information Sources on page xii for more Oracle Applications product
information.
x
TTY Access to Oracle Support Services
Oracle provides dedicated Text Telephone (TTY) access to Oracle Support Services
within the United States of America 24 hours a day, seven days a week. For TTY
support, call 800.446.2398.
Documentation Accessibility
Our goal is to make Oracle products, services, and supporting documentation
accessible, with good usability, to the disabled community. To that end, our
documentation includes features that make information available to users of assistive
technology. This documentation is available in HTML format, and contains markup to
facilitate access by the disabled community. Accessibility standards will continue to
evolve over time, and Oracle is actively engaged with other market-leading technology
vendors to address technical obstacles so that our documentation can be accessible to all
of our customers. For more information, visit the Oracle Accessibility Program Web site
at http://www.oracle.com/accessibility/ .
Accessibility of Code Examples in Documentation

Screen readers may not always correctly read the code examples in this document. The
conventions for writing code require that closing braces should appear on an otherwise
empty line; however, some screen readers may not always read a line of text that
consists solely of a bracket or brace.
Accessibility of Links to External Web Sites in Documentation

This documentation may contain links to Web sites of other companies or organizations
that Oracle does not own or control. Oracle neither evaluates nor makes any
representations regarding the accessibility of these Web sites.
Structure
1 Introduction
2 Localization Setup
3 Solution Overview
4 CLE: CA GL Translation Program
5 CLE: CA Universal Tool
6 CLE: CA XLA Translation Program
7 CLE: CA Correction Form
8 CLE: CA Interface Transfer Program
9 CLE: CA Interface Post Program
10 CLE: CA Account Reconciliation Report
11 CLE: CA Account Analysis Report
12 CLE: CA Account Journal Report
13 Custom Sources
xi
14 Glossary
Related Information Sources
Integration Repository
The Oracle Integration Repository is a compilation of information about the service
endpoints exposed by the Oracle E-Business Suite of applications. It provides a
complete catalog of Oracle E-Business Suite's business service interfaces. The tool lets
users easily discover and deploy the appropriate business service interface for
integration with any system, application, or business partner.
The Oracle Integration Repository is shipped as part of the E-Business Suite. As your
instance is patched, the repository is automatically updated with content appropriate
for the precise revisions of interfaces in your environment.
Do Not Use Database Tools to Modify Oracle Applications Data

Oracle STRONGLY RECOMMENDS that you never use SQL*Plus, Oracle Data
Browser, database triggers, or any other tool to modify Oracle Applications data unless
otherwise instructed.
Oracle provides powerful tools you can use to create, store, change, retrieve, and
maintain information in an Oracle database. But if you use Oracle tools such as
SQL*Plus to modify Oracle Applications data, you risk destroying the integrity of your
data and you lose the ability to audit changes to your data.
Because Oracle Applications tables are interrelated, any change you make using an
Oracle Applications form can update many tables at once. But when you modify Oracle
Applications data using anything other than Oracle Applications, you may change a
row in one table without making corresponding changes in related tables. If your tables
get out of synchronization with each other, you risk retrieving erroneous information
and you risk unpredictable results throughout Oracle Applications.
When you use Oracle Applications to modify your data, Oracle Applications
automatically checks that your changes are valid. Oracle Applications also keeps track
of who changes information. If you enter information into database tables using
database tools, you may store invalid information. You also lose the ability to track who
has changed your information because SQL*Plus and other database tools do not keep a
record of changes.
xii
1
Introduction
Correspondence Accounting Functionality

Oracle EMEA Consulting Localizations – Correspondence Accounting provides
additional functionality to help Russian, Ukrainian and Romanian customers meet legal
and business requirements as a part of core Oracle Payables, Receivables, General
Ledger, Assets, Inventory, Purchasing and Cost Management products.
Correspondence Accounting provides the functionality not available in core product
but essential for Russian, Ukrainian and Romanian customer.
This User guide provides detail about setup and functionality of the following
Translation Programs, Forms and Reports.
• CLE: CA GL Translation Program
• CLE: CA XLA Translation Program (includes the utool.parse pl/sql package)
• CLE: CA Universal Tool Form
• CLE: CA Correction Form
• CLE: CA Interface Transfer Program
• CLE: CA Interface Post Program
• CLE: CA Account Reconciliation Report
• CLE: CA Account Analysis Report
• CLE: CA Account Journal Report
Introduction 1-1
2
Localization Setup
Setting Up Correspondence Accounting solution

Correspondence Accounting does not require any additional E-Business Suite setups.
There are Custom Profile Values, which needs to be setup as follows:
1. CLE: CA Ledger
This is a mandatory profile to be setup.
All the programs, forms and reports in Correspondence Accounting solution use
this profile. The ledger name for which processing is to be done in the
Correspondence Accounting solution should be selected in this profile option.
2. CLE: CA Intercompany Line Added by Posting

This is a mandatory profile to be setup.
This is used to enter the string which will be used to identify intercompany lines in
a journal.. This could be entered in English or other languages. For example, in
English it will be 'Intracompany balancing line added by Posting. The string entered
identifies whether in a journal, the line is an intercompany line or not.
3. CLE: CA GL Manual Source

This is a non-mandatory profile to be setup.
This profile is used to identify the manual journal source.
4. CLE: CA Commit Value

This is a non-mandatory profile to be setup.
This profile is used to determine the number of events that will be processed at a
time.
This is used by CLE: CA GL Translation Program and CLE: CA XLA Translation
Program.
Localization Setup 2-1

5. CLE: CA Revaluation Default Definition
The profile option lists all the revaluations that are defined for the ledger that has
been selected in CLE: CA Ledger'
This profile is used to determine the gain and loss account in a case when
GAIN_LOSS line is absent in a revaluation journal being processed. It concerns the
both revaluation cases – when GL Revaluation: Tracking by Cost Center profile is
set to 'Y' or 'N'. This profile contains the names of Revaluation definitions defined
under Revaluation.
6. CLE: CA GL Offset Line Number

This profile is used to determine the offset account in many-many journals. User
can enter the any number in the profile, which will be used and that line will be
used for offsetting with the other lines of the journal.
7. CLE: CA Debug Flag

The profile with the Value 'Y' will print the debug messages in the log file of the
concurrent program.
2-2 Oracle CLE Correspondence Accounting User Guide

3
Solution Overview
Solution Overview 3-1

Overview
CLE: CA GL Translation Program: Translates GL entries and stores (translated and

untranslated entries) in CLE_F000_ACC_CORR_INT and CLE_F000_ACC_CORR_EV
tables. Translated Entries are stored with status P and untranslated entries are stored
with status E in CLE_F000_ACC_CORR_EV table.
CLE: CA XLA Translation Program: Translates SLA events/accounting data and stores
(translated and untranslated entries) in CLE_F000_ACC_CORR_INT and
CLE_F000_ACC_CORR_EV tables.
Translated events are stored with status P and untranslated events are stored with
status E in CLE_F000_ACC_CORR_EV table.
CLE: CA Correction Form: This is used to manually pair the accounting entries coming
from both GL and SLA (which was translated with exceptions by the translation
programs).
CLE: CA Interface Transfer Program: Transfers data from CLE_F000_ACC_CORR_INT
table to CLE_F000_ACC_CORR table where status in CLE_F000_ACC_CORR_EV table
is P.

CLE: CA Interface Post Program: Populates data from CLE_F000_ACC_CORR table to
CLE_F000_ACC_CORR_BAL table. This program maintains accounts balances like the
standard GL posting program does.
CLE: CA Account Reconciliation Report: A report used to ensure that all journals and
transactions were translated in Correspondence records and the balance for accounts in
the standard balance table and Correspondence balance table is matching.
CLE: CA Account Analysis Report: A report used to present data in a ledger form with
the accounts correspondence information.
CLE: CA Account Journal Report: A report used to present data in a ledger form with
analytical data.
The solution will provide users with the possibility to get accounting information in the
form that conforms to the Russian, Ukranian and Romanian correspondence accounting
requirements. The solution components will read the sub-ledgers accounting and
general ledger data and corresponding records in the format required.
Solution Overview 3-3

4
CLE: CA GL Translation Program
Introduction
This section talks about the GL (General Ledger) translation program of
Correspondence Accounting solution:
When a transaction takes place, accounting entries are created with:
1. One debit and one credit OR
2. One debit and more than one credit OR
3. More than one debit and one credit OR
4. More than one debit and more than one credit
The above entries in GL are translated based on the journal source. The journal source
determines the rule for pairing.
Translates GL entries and stores (paired and unpaired entries) in
CLE_F000_ACC_CORR_INT and CLE_F000_ACC_CORR_EV tables. Paired Entries are
stored with status P and unpaired entries are stored with status E in
CLE_F000_ACC_CORR_EV table.
The untranslated entries are available for correction in the CLE: CA Correction Form,
enabling the user to manually do the paring.
Users can write their own program code to translate standard accounting journals into
the correspondence accounting format. There are special hooks for that – before_journal
and after_journal. One can use or before_journal or after_journal for a particular
journal, not the both (see the technical reference manual for more information).
Prerequisites
• Setup
CLE: CA GL Translation Program 4-1

The following profile values should be setup.
1. CLE: CA Ledger
2. CLE: CA Intercompany Line Added by Posting
3. CLE: CA GL Manual Source
4. CLE: CA Revaluation Default Definition
5. CLE: CA Commit Value
6. CLE: CA GL Offset Line Number
• Processing
1. Only Actual type journals are considered. The Correspondence Accounting
does not consider Budget and encumbrance journals.
2. The Journals should be posted in General Ledger.
3. Journals with currency as STAT will not be processed.
Program Submission
Run the program CLE: CA GL Translation Program from Standard Request Submission
(SRS), General Ledger responsibility.
Program Parameters
Source: This parameter is mandatory. Enter the Source for which the General Ledger
transactions need to be processed by the Translation Program.
Period Name: This parameter is mandatory. Enter the General Ledger Accounting
Period for which the General Ledger transactions need to be processed by the
translation program.

Batch Name : This parameter is not mandatory. Based on the above given parameters
(source and period name ) the parameter list downs all the posted batches in the LOV.
The Translation program can be submitted for a selected batch or for all batches within
the above selected period. Other than the batches, which are processed successfully in
the previous run, are displayed. Batches that are in error status are also displayed.
Transaction Mode: This parameter is mandatory. Enter either Final or Draft. If Final,
the translation program populates the CLE_F000_ACC_CORR_INT and
CLE_F000_ACC_CORR_EV tables.
If Draft, the translation program will not populate data in to the
CLE_F000_ACC_CORR_INT table. But you can see the results of the translation in the
output (exceptions if any). Default value is 'Draft'
Process Error Records: If Process Error Events is No, the events already processed as
Error, are not considered for processing again.
If Process Error Events is Yes, the error events already processed and new events that
have not been processed are consider ed for processing.
Of course error events and new events are based on other parameters selected. This is a
mandatory parameter, containing two values in LOV: Yes and No. Default value is No
Processing
1. The Correspondence Accounting programs are created for Oracle E-business Suite
Version 12i
2. Standard journals entered with Source as specified in the CLE: GL Manual Source
will be considered as Manual Journals.
3. When entering standard journal entries, numerate journal lines in increasing order
while entering all journal entries by accounting groups. Each group can consist of
any number of lines and should have "one-to-one" or "one-to-many" structure.
4. "CLE: CA GL Offset Line Number" profile option can be any number set by user
(Profile option value should be MAXIMUM of the line numbers).
5. The scope of this program is to translate the data from General Ledger and populate
the accounting pairs to interim table CLE_F000_ACC_CORR_INT table.
6. Data is considered for all the periods other than Never Opened Period.
7. Date format and amount format is as per the standard reports.
The following are the list of events that generate accounting entries in General Ledger.
Different logics have been built for each type of event to pair the accounting entries that
are generated. Type of Journal is identified from JE_SOURCE column of
GL_JE_HEADERS table.

• Standard Journals
• Recurring standard Journals
• Revaluation Journals
• Massallocation Journals
• Intercompany & Intracompany Journals
• Closing Journals
A) Standard Journal
The CLE: CA GL Translation Program process the standard Journal in two types. The
first one uses "offset" line number to detect the opposite line to build accounting pairs.
This "magic" line number is defined in 'CLE: GL Offset Line Number' profile. For
example,
Note: "CLE: GL Offset Line Number" profile option is set to "9999"
Line no Accounting Flexifield Debit Credit
10 01-740-7420-0000-000 100
20 01-000-7420-0000-000 -200
30 01-110-7420-0000-000 -300
40 01-000-7430-0000-000 600
50 01-740-7430-0000-000 700
9999 01-000-1110-0000-000 100
The data in CLE_F000_ACC_CORR_INT table after the journal processed:
Line no Debit Credit Amount
20 & 9999 01-740-7420-0000-000 01-000-1110-0000-000 100
30 & 9999 01-000-7420-0000-000 01-000-1110-0000-000 -200
9999 & 32 01-000-1110-0000-000 01-110-7420-0000-000 -300

Line no Debit Credit Amount
40 & 9999 01-000-7430-0000-000 01-000-1110-0000-000 600
9999 & 50 01-000-1110-0000-000 01-740-7430-0000-000 700
So if the profile is set up and presents in the journal being translated this processing
logic is used (the offset account is used as opposite one for all other accounts).
Otherwise we suppose having the second type of standard journal. In this case the
journal must have the special structure and we will be able to use particular parsing
logic.
To parse standard GL journal one must enter journals using special rules. The journal is
entered in groups. Each group can consists of two or more lines and all lines must be
balanced. The group can start from debit or credit lines and from one or many lines on
the same side. The example of journals is given below.
Example 1
This simplest example shows the correct Standard Journal entry with "one-to-one" line
relationships (each group consists of two lines).
Group Line Account Debit Credit
1 10 01-000-7420-0000-000 1000
20 01-000-1110-0000-000 1000
2 30 01-740-7430-0000-000 1500
40 01-000-1110-0000-000 1500
3 50 01-110-7420-0000-000 2000
60 01-000-1110-0000-000 2000
The data in cle_f000_acc_corr_int table after the journal processed:
Rec ID Journal Line Debit Account Credit Account Accounted

numbers Amount
1 10, 20 01-000-7420-0000-000 01-000-1110-0000-000 1000

Rec ID Journal Line Debit Account Credit Account Accounted
numbers Amount
2 30, 40 01-740-7430-0000-000 01-000-1110-0000-000 1500
3 50, 60 01-110-7420-0000-000 01-000-1110-0000-000 2000
Each group is processed individually.

1. Detect which line is the opposite line in the group. The opposite line is the only line
on a particular side – Debit or Credit. If the group consists of two lines any line can
be considered as the opposite one. The opposite line will be paired with the other
lines.
2. Pairing is done with the opposite line with all other lines. Amount from
non-opposite line is used in the pair. The line side remains the same as it was in the
original journal entry.
B) Recurring Journals
Recurring Journals should not contain a line number defined by profile option "CLE:
CA GL Offset Line Number".
The Recurring journals are paired as similar to the standard journal entries.
C) Revaluation Journals
The GL Translation programs groups the revaluation journal by balancing segment and
then the entries are paired with GAIN_LOSS as the offset account. In case the GL
Revaluation: Tracking by Cost Center profile is set to 'Y' then grouping is done based
on the cost center and then the pairing happens.
In case the GAIN_LOSS line is absent in the revaluation journal the GL Translation
programs reads the profile option CLE: CA Default Revaluation Definition for
deriving the GAIN_LOSS account. The Gain and loss account are derived from the
revaluation definition mentioned under the profile option.
Example 1
(GL Revaluation: Tracking by Cost Center profile is set to 'N')
Line Account Accounted Accounted LINE_TYPE_CO

Debit Credit DE
10 01-0020-0000 7000
20 01-0030-0000 1000

Line Account Accounted Accounted LINE_TYPE_CO
Debit Credit DE
30 01-0040-0000 2000
40 01-0050-0000 1000
50 01-0060-0000 3000
60 01-0070-0000 2000
70 GAIN-LOSS (01) 10000 GAIN_LOSS
80 02-0070-0000 555
90 GAIN-LOSS (02) 555 GAIN_LOSS
Fiscal accounting entry
Line ref Accounting Pair Account class Amount Debit Credit

#
10 1 01-0020-0000 7000 X
70 1 GAIN-LOSS 7000 X
20 2 01-0030-0000 1000 X
30 3 01-0040-0000 2000 X
40 4 01-0050-0000 1000 X
50 5 01-0060-0000 3000 X

#
60 6 01-0070-0000 0 X
80 6 02-0070-0000 555 X
90 6 GAIN-LOSS (02) 555 X
Example 2
(GL Revaluation: Tracking by Cost Center profile is set to 'Y')
Note: In this example cost center is the third segment.
Standard Revaluation journal.
Line Account Accounted Debit Accounted LINE_TYPE_CODE

Credit
10 01-0020-0000 7000
20 01-9999-0000 7000 GAIN_LOSS
30 01-0040-1111 2000
40 01-0050-1111 500
50 01-9999-1111 1500 GAIN_LOSS
80 02-9999-0000 555 GAIN_LOSS
90 02-0070-0000 555
Correspondence Accounting Entry

#
10 1 01-0020-0000 7000 X

#
20 1 01-9999-0000 7000 X
30 2 01-0040-1111 2000 X
50 2 01-9999-1111 2000 X
40 3 01-0050-1111 500 X
50 3 01-9999-1111 500 X

90 6 02-0070-0000 555 X
80 6 02-9999-0000 555 X
There can be a case where GAIN_LOSS line can be absent in the group being processed.
It concerns the both revaluation cases – when GL Revaluation: Tracking by Cost
Center profile is set to 'Y' or 'N'. In such a situation the program handles the situation as
the following:
Get value from CLE: CA Default Revaluation Definition system profile. The profile is
defined for this purpose. The program pickups the name of the revaluation from the
profile and the unrealized gain and loss accounts are derived from GL_Revaluations for
the given ledger id ('CLE: CA Ledger'). Only the not null segments are extracted.
Balancing segment value is taken from the account being revalued. Other segment
values are being taken from the revaluation definition. In case the profile option GL
Revaluation: Tracking by Cost Center profile is set to 'Y' cost center segment is taken
from the account being revalued.
Build accounting pairs. Each account being revalued is paired with an unrealized
account: for regular journals - if the account being revalued is on credit Unrealized Gain
account is used, if the account being revalued is on debit Unrealized Loss account is
used; for reversing journal corresponding unrealized account is taken from original
journal been reversed (using JE_LINE_NUM column).
Example 3
GAIN SEGMENT2=9901, LOSS SEGMENT2=9902, GAIN SEGMENT3=0000, LOSS
SEGMENT3=0000
Standard Revaluation journal

Line Account Accounted Debit Accounted LINE_TYPE_CODE
Credit
10 01-0020-0000 100
20 01-0030-0000 100
30 01-0040-1111 2000
40 01-0050-1111 500
50 01-9999-1111 1500 GAIN_LOSS
Correspondence Accounting Entry

#
10 1 01-0020-0000 100 X
LOSS 1 01-9902-0000 100 X
20 2 01-0030-0000 100 X
GAIN 2 01-99010000 100 X
30 3 01-0040-1111 2000 X
50 3 01-9999-1111 2000 X
40 4 01-0050-1111 500 X
50 4 01-9999-1111 500 X
Example 4
This example covers the case when there are groups with GAIN_LOSS and NO
GAIN_LOSS lines at the same time.
Standard journal

CONCATENATED_SEGMENTS ACCOUNTED_D ACCOUN LINE_TYPE_C
R TED_CR ODE
1 01-50.01.21-00125-0-0-0-0-0 0.01 0
2 01-91.02.10-00125-Z9960002-790-N 0 0.01 GAIN_LOSS

EOPR3-0-0
3 01-50.01.17-00038-R2613000-0-0-0- 100 0
0
4 01-50.01.17-00038-0-0-0-0-0 0 100
5 01-50.01.21-0-0-0-0-0-0 10 0
6 01-60.07.01-0-0-0-0-0-0 0 15
7 01-76.02.12-0-0-0-0-0-0 3 0
8 01-91.02.10-0-Z9960002-790-NEOP 0 2 GAIN_LOSS
R3-0-0
There are three balancing segment/cost center group here:

01/00125, 01/00038, 01/ 0
For groups #1,3 the logic when GAIN_LOSS line presents is used; for group #2, the logic
when GAIN_LOSS does not present (NO GAIN_LOSS line) is used.
Fiscal journal
Line Acc. Pair # Account Cost Debit Credit

ref Center
1 1 01-50.01.21-00125-0-0-0-0-0 125 0.01
2 1 01-91.02.10-00125-Z9960002-79 0.01
0-NEOPR3-0-0
3 2 01-50.01.17-00038-R2613000-0-0 38 100
-0-0
2 Unrealized Gain/Loss Account 100

Line Acc. Pair # Account Cost Debit Credit
ref Center
3 Unrealized Gain/Loss Account 100
4 3 01-50.01.17-00038-0-0-0-0-0 100
5 01-50.01.21-0-0-0-0-0-0 0 10
8 01-91.02.10-0-Z9960002-790-NE 10
OPR3-0-0
6 01-60.07.01-0-0-0-0-0-0 15
8 01-91.02.10-0-Z9960002-790-NE 15
OPR3-0-0
7 01-76.02.12-0-0-0-0-0-0 3
8 01-91.02.10-0-Z9960002-790-NE 3
OPR3-0-0
Reversal Of Revaluation Journal

The GL Translation program considers a special logic while pairing a Revaluation
Journal reversal. In a revaluation journal the LINE_TYPE_CODE is not copied from the
original journal in case of reversal.
The program firsts checks the journal whether it is a reversed journal or not
(gl_je_headers.reversed_je_header_id is not null). If yes, then program finds the
GAIN_LOSS Lines in the original journal and copy GAIN_LOSS value into the
corresponding line of the reversing journal. Then the journal can be parsed using the
standard logic.
D) MassAllocation Journals
For processing of a mass allocation journal the mass allocation formulae is been
analyzed by the GL Translation Program. Firstly, the mass allocation formulae can be
identified from the mass allocation definition's name , which can be derived from the
GL Batch name. General Ledger names your MassAllocation journal batches as follows:
MA: <Request ID><Mass Allocation Batch Name><Period>;
<Request ID>-the request's code, which created the batch
(GJ_JE_BATCHES.REQUEST_ID);
<MassAllocation Batch Name>-MassAllocation definition's name;
<Period>-the period of journal in the General Ledger

For example, the General Ledger MassAllocation batch's name is 'MA: 474362 Rent
Budget Allocation Dec–07'. Then MassAllocation definition's name is 'Rent Budget
Allocation'.
Then we find the allocation batch_id from GL_ALLOC_BATCHES. Using this
allocation_batch_id, the program gets allocation_formula_id, the name coincides with
the name of the MassAllocation journal from processed batch created in the GL
(GL_ALLOC_FORMULAS.NAME).
Looks for the OFFSET line in the formula corresponding to the journal
(GL_ALLOC_FORMULA_LINES.LINE_TYPE = 'O').
If all segments of the Offsetting Account are Constant segment type
(GL_ALLOC_FORMULA_LINES.SEGMENTS_TYPE_KEY = 'C-C-C-...-C'), then journal
will be 'one to many'. In this case the journal will have only one Offsetting Account. We
look for the journal line, where account equals to Offsetting Account.
Important: While constructing of the Offsetting Account from the

OFFSET line of the formula, it is necessary to consider sequence of
segments in AFF, instead of a serial number of a segment.
Build accounting pairs pairing this journal line with the other lines. If the Offsetting
Account have segments of looping type, then journal will be 'many to many'. In that
case, considering Allocation Formula Rules, the program builds accounting pairs as
follows:
A journal line is taken. This is the first line of the accounting pair. Segments in the
account of this journal line are chosen, which in the Offsetting Account of the Allocation
Formula are set with type ' L '. This are called as 'L' segments.
Find the journal line with account which has the same values of 'L' segments as the
account of the first line of the accounting pair. This is line will be the second line of the
accounting pair. For control:
1. Accounting pairs will consist of one Target Account and one Offsetting Account.
The Constant type segments are used to detect account type (Target or Offsetting).
2. The Debit and Credit amount of each line of accounting pair should will be
identical.
3. If Target and Offsetting Accounts have not Constant type segments then program
will check only Debit and Credit amount in the accounting pair line.
4. If even one of these rules is not carried out, the journal is considered as
EXCEPTION.
Process the next journal line if it still does not belong to any accounting pair.
1. If Target and Offsetting Accounts have not Constant type segments then program
will check only Debit and Credit amount in the accounting pair line.

If even one of these rules is not carried out, the journal is considered as EXCEPTION.
For processing Reversing Journals where source is 'MassAllocation', it is necessary:
Define the journal that has been reversed.
Define MassAllocation Formula's name, which created this journal. Construct
accounting pairs in the Reversing Journal with the algorithm described above.
Example 1
MassAllocation Formula
Factor Oper Sum Co Type Dept Type Acct Type
A E 1 C T C 10 C
B * 0.1
C / 1
T E 1 C T L 10 C
O E 1 C 1000 C 90 C
Original MassAllocation Journal
Line Account Account Type Debit Credit

amount amount
10 01-0030-0010 100
20 01-0020-0010 10
30 01-0010-0010 50
40 01-1000-0090 Offsetting 160
Transformed Journal (Fiscal)

Example 2
MassAllocation Formula

Line Pair Number Account Debit Credit
amount amount
10 1 01-0030-0010 100
40 1 01-1000-0090 100
20 2 01-0020-0010 10
40 2 01-1000-0090 10
30 3 01-0010-0010 50
40 3 01-1000-0090 50
A E 1 C T L 2300 S
B T 1 C T S 2000 C
C / 1 C T S 2300 S
T E 1 C T L 2099 C
O E 1 C T L 2399 C

amount amount
10 01-0030-2099 120
20 01-0020-2099 150
30 01-0030-2399 Offsetting 120
40 01-0020-2399 Offsetting 150


amount amount
10 1 01-0030-2099 120
30 1 01-0030-2399 120
20 2 01-0020-2099 150
40 2 01-0020-2399 150
Example 3
Reversing journal
Line Account Debit amount Credit amount
10 01-0030-2099 120
20 01-0020-2099 150
30 01-0030-2399 120
40 01-0020-2399 150

amount amount
10 1 01-0030-2099 120
30 1 01-0030-2399 120
20 2 01-0020-2099 150
40 2 01-0020-2399 150
Example 4

MassAllocation Formula (all segments are looping)
A E T L T L T L
B T 0.1
C / 1
T E T L T L T L
O E T L T L T L
T – is the parent account.


amount amount
10 01-0030-002 Looping 120
20 01-0040-003 Looping 150
30 01-0050-003 Looping 200
40 01-0030-002 Looping 120
50 01-0040-003 Looping 150
60 01-0050-003 Looping 200

amount amount
10 1 01-0030-002 120
40 1 01-0030-002 120

amount amount
20 2 01-0040-003 150
50 2 01-0040-003 150
30 3 01-0050-003 200
60 3 01-0050-003 200
e) Intercompany and Intracompany

Inter-company journal is a standard one with different values in balancing segments.
The following setup has been assumed
• Use Default Balancing Account
• Balance by Detail
• Clearing Company are not used
All other inter-company journals are under common exceptions rules.

Inter-company journal example:
Line Account Debit Credit
10 01-1210-0000 100
20 02-1210-0000 100
25 01-1210-0000 100
30 03-1210-0000 100
After the posting process we will have:
Line Account Debit Credit Description
10 01-1210-0000 100

Line Account Debit Credit Description
20 02-1210-0000 100
25 01-1210-0000 100
30 03-1210-0000 100
31 01-2370-0000 100 Intercompany Line

Added by Posting

Added by Posting

Added by Posting

Added by Posting
The algorithm of inter-company journal parsing is as per the following:

The program searches for the lines with 'Inter-company Line Added by Posting'
description (depends on the environment language, as the matter of fact it's taken from
the profile value). After search is completed we will have two groups of lines: the first
one is the added by posting and the second one is the original line. Then program
builds accounting pair for each line of the first group (added by posting) and search in
the second group (original lines) for the line with the same balancing segment value.
Build the accounting pair for the lines selected Journal with correct accounting scheme
are given below:
Line Accounting Account Debit Credit Description

Pair #
10 1.1 01-1210-0000 100
31 1.1 01-2370-0000 100 Intercompany

Line Added by
Posting
25 1.2 01-1210-0000 100

Line Accounting Account Debit Credit Description
Pair #
33 1.2 01-2370-0000 100 Intercompany

Line Added by
Posting
20 2 02-1210-0000 100
32 2 02-1810-0000 100 Intercompany

Line Added by
Posting
30 3 03-1210-0000 100
34 3 03-1810-0000 100 Intercompany

Line Added by
Posting
f) Income Statement Closing Journals

The last journal entry (sorted by line number) in the journal is always offsetting (closing
account). So, every journal entry should correspond (or make an accounting pair) with
the entry. An account can have amount in debit and in credit in the same time. In this
case each side is paired with the offset account individually.
Standard journal entries:
Line Account class (sign) Multiply lines Debit Credit
10 01-0020-0000 Y 7000
20 01-0030-0000 Y 1000
30 01-0040-0000 Y 2000
40 01-0050-0000 Y 1000
50 01-0060-0000 Y 3000
60 01-0070-0000 Y 2000

Line Account class (sign) Multiply lines Debit Credit
70 Last entry (Offset 10000

Account)
Line ref Accounting Account class Amoun Debit Credit

Pair # t
10 1 01-0020-0000 7000 X
20 1 Last entry 7000 X
30 2 01-0030-0000 -1000 X
40 2 Last entry -1000 X
50 3 01-0040-0000 2000 X
70 4 01-0050-0000 1000 X
90 5 01-0060-0000 3000 X
110 6 01-0070-0000 -2000 X
120 6 Last entry -2000 X
A closing journal can have accounts with different balancing segment values. In this
case groups with one balancing segment value must be selected firstly and then each
group must be parsed individually. Offset account is always the last one in the group.
Example:

Line Account class (sign) Debit Credit
10 01-0020-0000 700 300
20 Last entry (Balancing segment 300 700

01)
30 02-0030-0000 1000
40 Last entry (Balancing segment 1000

02)
Line Account class (sign) Amount Debit Credit
10 1 01-0020-0000 700 X
20 1 Last entry (Balancing 700 X

segment 01)
10 2 01-0020-0000 300 X
20 2 Last entry (Balancing 300 X

segment 01)
30 02-0030-0000 1000 X
40 Last entry (Balancing 100 X

segment 02)
g) Balance Sheet Closing Journals

The last journal entry (sorted by line number) in the journal is always offsetting. So,
every journal entry should correspond (or make an accounting pair) with the entry. An
account can have amount in debit and in credit in the same time. In this case each side is
paired with the offset account individually.

10 01-0020-0000 7000 3000
20 01-0030-0000 2000 1000
30 01-0040-0000 2000 1100
40 01-0050-0000 1000 2300
50 01-0060-0000 3000 5600
60 01-0070-0000 1200 2000
70 Last entry (Offset Account) 15000 16200
Line ref Dr Cr Amount
10 01-0020-0000 Last entry 7000
10 Last entry 01-0020-0000 3000
20 01-0030-0000 Last entry 2000
20 Last entry 01-0020-0000 1000
30 01-0040-0000 Last entry 2000
30 Last entry 01-0020-0000 1100
40 01-0050-0000 Last entry 1000
40 Last entry 01-0020-0000 2300
50 01-0060-0000 Last entry 3000
50 Last entry 01-0020-0000 5600
60 01-0070-0000 Last entry 1200

Line ref Dr Cr Amount
60 Last entry 01-0020-0000 2000
A closing journal can have accounts with different balancing segment values. In this
case groups with one balancing segment value will be selected firstly and then each
group must be parsed individually. Offset account is always the last one in the group.
Example:
10 01-0020-0000 700 300
20 Last entry (Balancing 300 700

segment 01)
30 02-0030-0000 200 1000
40 Last entry (Balancing 1000 200

segment 02)
Line Dr Cr Amount
10 01-0020-0000 Last entry (Balancing 700

segment 01)
10 Last entry (Balancing segment 01-0020-0000 300

01)
20 02-0030-0000 Last entry (Balancing 200

segment 02)
20 Last entry (Balancing segment 02-0030-0000 1000

02)
Reversing Journals
It's assumed that journals generated in product modules are not reversed in GL

Output
Output of the translation program has the following three sections:

1. Summary on processed transactions
2. Summary on skipped due to translation problem transactions
3. Detail list of skipped due to translation problem transactions
Sample output given by the General Ledger translation program is as follows-

General Ledger Translation Program – Output
Exceptions
If any of the mandatory profiles are not setup, the program will end with warning
status.

5
CLE: CA Universal Tool
Introduction
Universal Tool (Utool) is part of the XLA Translation program. The XLA Translation
program first checks for any Alternative SLA Journal Line Defenition (AJLD) defined in
the utool and whether active or not, else it will process as per the XLA Translation
program.
Utool is composed of the following components:
• CA Universal Tool Form that allows maintaining an alternative journal line
definitions (AJLD). This form has four windows for defining, updating and deleting
the alternative journal line definitions.
• CA Utool pl/sql package that incorporates the translation logic
• EXTENSIONS pl/sql package that is to incorporate custom translation logic.
Correspondence Accounting with Universal Tool process flow
CLE: CA Universal Tool 5-1

On the figure:
Standard processing – Events are processed presuming JLD has two JLTs
Alternative processing – Events are processed based on alternative JLD (JLD with direct
accounts correspondence defined)
Prerequisites
Setup
• The Form should be added to the menu for the selected responsibility.
• SLA: Account method Builder Context (AMB Context) profile option has to be
setup. The Utool form works under the given AMB context.

Form Navigation
• The CLE: CA Universal tool Form is available in the General Ledger responsibility.
Find Alternative Journal Line Definitions window
Application: This field contains all the complete list of sub ledger applications.
Owner:This field contains values "Owner, User and Blank". Default value is set to User.
Event_class:This field will display the event class for the given owner, application.
Event_type :This field will display the event types for the given event_class, owner and
application.
Definition_code:This field will display all the Journal Line Defintion codes for the
given event type, event class, owner and application. This is a corresponding field for
the definition name.
Definition_name:This field will display all the Journal Line Definition names for the
given event type, event class, owner and application
Alternative Definition:This field contains values "Exist, Not Exist and Blank". Default
value is set to blank.
Journal Line Definitions List window

In this window the results of the search are being displayed. You can start defining an
alternative definition from this window. Once the alternative definition is been defined
for a given JLD, the AJLD button appearing on the search results window will get
checked. Once the AJLD is completely defined you can make the Active checkbox
checked for considering this AJLD in the XLA Translation program.
Accounting Pairs window

The accounting pairs are defined in this window. You may refer the below note before
defining the accounting pairs.
The default value in the event type (2) is based on the event type (1). If you have any
specific event type in the event type (1) the value defaulted in the event type (2) will be
same. You cannot select any different event type in event type (2).
In case the event type (1) has a value of 'All' then event type (2) will be defaulted with
value 'All' but the value can be changed from 'All' to any other value displayed in the
LOV. Please use Ctrl+Down keys for creating new records. The Utool package checks
for the event type (2) for identifying the AJLD for a JLD.
Consider Source Identification: If checked the program translates SDID+JLD set of
accounting lines, otherwise whole JLD is parsed.
Source Side: Values are Dr and Cr. This field denotes account side where the account
must be located in order to the program considers an accounting line as the source line
to build accounting pair.
Offset:Values are Yes or No. This field denotes which JLT can be made as offset in
'One-2-Many" events.
Active:Each accounting pair line can be considered made active or in active.
Amounts: This button takes to the amount window for the current record.
Important: You have two event type fields in the form. The event type
(1) (top right side, above owner field) is the JLD event type. And the
event type (2) one is defined for the purpose of AJLD.

Amounts window
In this window we have two-tab regions -Entered Amount, Accounted Amount. The
fields are similar in both the tabs.
NO:This is the serial number generated by the system incrementally.
Op:Operand(Op) has values '+','-'. This values are used in the calculation of formulae.
Source Type:
1. JLT – from the corresponding JLT
2. Constant – any value (number)
3. Custom Source – user should enter pl/sql function name which will return amount
value. The function should have the following the list of parameters:
,p_event_id in number not null -- event being processed
,p_ae_header_id in number not null -- ae_header being processed
,p_ledger_id in number not null -- source ledger_id
,p_amb_context_code in varchar 2 not null -– amb context code
,p_apps_id in number not null -- application_id
,p_event_class_code in varchar2 not null -- event class code
,p_event_type_code in varchar2 not null -- event type code

,p_jld_owner_code in varchar2
,p_source_jld in varchar2 not null –- JLD used to create accounting
The amount is calculated based on the formulae given in the amounts window. The
value can be positive or negative.
Processing
Defining an Alternative Journal Definition (AJLD)
Before we define the Alternative Journal Definition the profile option XLA Accounting
Methods Builder Context has to be defined.
• Navigate to the CA Universal Tool menu
The Find Journal Line Definition appears
• Enter the
• Application (Mandatory)
• Owner
• Event Class
• Event Type
• Definition Code
• Definition Name
• - Alternative Definition
• The Search Results window appears
• Select the Journal Line Definition (JLD) for which you want to define alternative
JLD
• The Accounting Pair window appears
• Select the event type (2) in the form

• Note: There are two event type fields in the form. The event
type (1) (top right side, above owner field) is the JLD event
type. And the event type (2) one is defined for the purpose of
AJLD.

• Event type (2) will have the values of all event types for the JLD in case the
event type (1) is All. You can select either All or all other specific events. Both
All and specific cannot be used.
• If the event type (1) is specific then the event type (2) will default the same
value. Here you will not be able to change the value.
• Consider source identification check box in case you require the accounting should
happen on Source distribution ID.
• Define the Accounting pairs in the way the accounting should happen.
• Enter the Source side (dr/cr) of JLT in the standard tables. (For ex- The source side
of liability will be debit and cash clearing credit in case of payment created event).
• Enter Offset (Yes/No). This option can be used when you encounter one to many
events.
• Active checkbox checked by default. In case the accounting pair has to be

de-activated you can make by un-checking the active checkbox. This accounting
pair line is not considered while translation program happens.
• Click on the Amounts button. The amounts window appears.
• You have two tabs Entered Amount and Accounted Amounts in this window
• The amount of each accounting pair is derived from this window with the formulae
mentioned against each accounting pair line.
• There are three values in the source type (JLT/Constant/Custom)

• JLT – Entered/Accounted amounts from the corresponding JLT
• Constant – Enter any number
• Custom - user should enter pl/sql function name, which will return amount
value.
The function should have the following the list of paratmeters:
,p_event_id in number not null -- event being processed
,p_ae_header_id in number not null -- ae_header being processed
,p_ledger_id in number not null -- source ledger_id
,p_amb_context_code in varchar 2 not null -– amb context code
,p_apps_id in number not null -- application_id
,p_event_class_code in varchar2 not null -- event class code

,p_event_type_code in varchar2 not null -- event type code ,p_jld_owner_code
in varchar2 ,p_source_jld in varchar2 not null –- JLD used to create accounting
• ('+','-',blank) are the values available in the operand column. Can be used while
defining the formuale, as needed.
• The final amounts are delivered by calculating using formula lines.

Once the AJLD definition is complete, the AJLD has to be made active in the search
results window. Unless the AJLD is active the XLA translation program will not be
considered in the program.
CA UTOOL pl/sql package

The package consists of one procedure – CLE_F000_UTOOLCLE.PARSE This procedure
is called from the XLA translation program (refer the topic of XLA Translation
program). And translates event if there are an active alternative JLD
Utool pl/sql package incorporates the procedures that translate the accounting events
that have AJLDs and enabled. If the AJLD doesn't exist or if the AJLD exist and it is not
active the XLA Translation program will try to pair in case the JLD has two JLTs. The
events which has AJLD and it is not defined properly are flagged as errors by utool
pl/sql package itself, before XLA Translation program does it.
Once the translation program pairs the entries in accordance of the AJLD, the balance
check level will check for the original accounting lines and built accounting pairs
((entered/accounted debits = entered/accounted credits). Incase of any difference
between two would generate an exception.
Also there is CLE_ACC_CORR_EXTENSIONS pack that allows using special translators
for particular JLDs. It's called from CLE_F000_UTOOLCLE.PARSE procedure. This is
designed for facilitating the customer requirements.
UTOOL Program does not handle Inter/Intra company Transactions. The same are
handled by CLE: CA XLA Translation Program.

6
CLE: CA XLA Translation Program
Introduction
Till EBS 11i, the accounting of Subledger transactions was handled by respective
applications. In Oracle R12 the accounting function is handled by SLA.
When a transaction takes place, accounting entries are created with:
1. One debit and one credit OR
2. One debit and more than one credit OR
3. More than one debit and one credit OR
4. More than one debit and more than one credit
The accounting entries created by SLA also works on the same principle. However SLA
uses certain new concepts like Event model, transaction source, Journal Line Definition,
Journal Line Type, etc.
Refer SLA User Guide for description of these concepts and working.
However the requirement of some countries involves having accounting entries with
one debit and one credit only. This involves a process of converting the standard
accounting entries with more than one debit and / or one credit into country specific
one debit and one credit.
This process of conversion of accounting entries called pairing. XLA Translation
Program does the function of pairing SLA entries into one debit and one credit.
The pairing can be done by:
1. Custom Hooks where users can write their own ways to pair and populate the
accounting entries.There are two hooks types – before_event and after_event. Users
can write their own logic to translate standard accounting events into the
correspondence accounting format. One can use or before_event or after_event for a
CLE: CA XLA Translation Program 6-1

particular event, not the both (see the technical reference manual for more
information).
2. SLA Translation Program where Journal Line Definition (JLD) having 2 Journal
Line Types (JLT) are be considered for pairing. Following accounting entries are not
handled by the program:
• One debit and more than one credit
• More than one debit and once credit
• More than one debit and more than one credit

However pairing of Intra Company and Inter company transactions are done
by SLA Translation Program.
3. Utool Program where users can define rules for translation for accounting entries
with
• One debit and one credit OR
• One debit and more than one credit OR
• More than one debit and once credit OR
• More than one debit and more than one credit
Please note that Utool is also run through SLA translation Program. There is no
separate program to run pairing defined in Utool.s
If there are rules in Utool Program and SLA Program, Utool Program has priority
over SLA Program and will handle the event.
4. Utool Extension Program: This is also a user defined program where users can
handle the events in their own way
Please note that Utool Extension is also run through SLA translation Program.
There is no separate program to run pairing defined in Utool extension.
If there are rules in Utool Extension Program and Utool Program Utool Extension
Program has priority over Utool Program and will handle the event.
Prerequisites
Setup:
a) The Ledger name should be selected in the Profile 'CLE: CA Ledger '. Processing will
happen for transactions with this ledger name.
Processing:

a) Only Actual entries are considered. Budget and Encumbrance entries are not
considered.
b) The transaction should be validated / accounted.
c) Create Accounting Program should run with Mode as Final or Final Post.
d) Transactions belonging to same or different balancing segments (Intra company and
Inter company transactions) are also considered.
e) Posting of journals in GL is not a mandatory requirement.
f) All SLA JLTs are defined with "Merge Matching Lines" option set to "No"
Program Submission
Run the program CLE: XLA Translation Program from Standard Request Submission
from General Ledger responsibility.
Program Parameters
1) Application
This parameter is mandatory.
There is no default value.
Each translation program is run for a particular application only. Only Sub ledger
Applications appear in LOV. Currently the list contains 14 applications.
2) Entity Name

R12 uses the concept of Event Model. Each accounting entry has an event type which
are grouped into Event Class, which are in turn grouped into Entity Name. Entity
Names are specific to an application.
Use this parameter to limit the data to be processed based on Entity Name. This is not a
mandatory parameter.
If no value is specified for the parameter, all the events for the application are
considered for processing.
If an entity code is specified, events with event types belonging to the specified entity
name are considered for processing.
3) Event Class Name
For Entity Codes specified in the above parameter, all the event class names that are
enabled for accounting are listed in this parameter.
Selecting a value in the parameter will limit the data.
This is not a mandatory parameter.
If no value is specified for the parameter, all the events with event types belonging to
event class names for selected entity code are considered for processing.
If an event class name is specified, events with event types belonging to the specified
event class name are considered for processing.
4) GL Period
This is a mandatory parameter.
All the periods except Never Open periods will appear in the LOV.
5) Translation Mode
This is a mandatory parameter, containing two values in LOV: Draft and Final. Default
value is Draft.
If Translation Mode is Draft, the program processes the events but does not store any
data in the tables. This is only for viewing to ensure whether data is getting processed
correctly or not. The user can run the program in Final mode.
If Translation Mode is Final, the program processes the events and saves data in the
tables. Once program is run with Final Mode, data cannot be changed in the tables.
6) Process Error Events
This is a mandatory parameter, containing two values in LOV: Yes and No. Default
value is No.
If Process Error Events is No, the events already processed with Error, are not
considered for processing again.
If Process Error Events is Yes, the error events already processed and new events that
have not been processed are considered for processing.
Of course error events and new events are based on other parameters selected.

Program Output
The output will display the following:
The output file has 3 sections:

Record Summary: This gives count of events processed based on selected parameters.
Summary on skipped due to translation problem transactions: This gives count of
error events processed based on selected parameters.
Detail list of skipped due to translation problem transactions: This section lists the
details of the error events.
Processing
1. CLE: CA XLA Translation Program is designed to handle any SLA setup which
conforms to the prerequisites.
2. Based on the parameters accounting events will be looked selected for processing.
3. Generally an accounting event can have multiple JLDs and each JLD can have 2 or
multiple JLTs. CLE: CA XLA Translation Program will pair only events where 1
JLD has 2 JLTs only. There can be entries where there are multiple lines for 1 JLD =
2 JLT. However these are not paired by CLE: CA XLA Translation Program. Utool
should have pairing defined for handling these cases or else CLE: CA Correction
Form should be used to pair this.
4. If AJLD is defined in UTOOL, event will be processed based on pairing rules

defined. Note that AJLD can handle events with 1 JLD = 2 JLT rule as well.
5. IF AJLD is not defined, CLE: CA XLA Translation Program will pair the event.
However since CLE: CA XLA Translation Program is programmed to handle only
events with 1 JLD = 2 JLT rule, events having JLD with more than 2 JLT will be
errored out to be handled by CLE: CA Correction Form.

6. Intra and Inter company transactions are handled by CLE: CA XLA Translation
Program.

7
CLE: CA Correction Form
Introduction
The events processed by CLE: XLA Translation Program and / or CLE: GL Translation
Program with errors can be corrected using the CLE: CA Correction Form.
There are certain steps that need to be followed while correcting the error events.
Prerequisites
Processing:
There should be atleast one error event to open the Correction Form.
Form Navigation
This is available in Menu as CA Correction Form in General Ledger responsibility.
Form Descriptions
There are 3 forms used in the Correction process.
A. Find Errors Form
B. Correct Translation Errors Form
C. Modal Correction Results Window
These forms are described as under:
A. Find Errors Form
This is the first form that opens when CA Correction Form is executed.
CLE: CA Correction Form 7-1

Form Fields:
Source Application:
This is a mandatory field. This limits the erroneous data for correction by Application
name. The LOV is restricted to SLA and General Ledger applications.
If the field is not selected, user will not be able to enter / select any of the other fields. If
there is no error data, LOV will not show any application name.
Event Type:
Limits the erroneous data for correction by event type within an Application name.
Inventory Item:
Limits the erroneous data for correction by inventory item. LOV will show values for
Cost Manager, Purchasing, Payables and Receivables applications.
Asset:
Limits the erroneous data for correction by Asset. LOV will show values for Assets
application.
Document:
Limits the erroneous data for correction by document sequence values. This is
applicable where document sequences are enabled.
Transaction ID:
Limits the erroneous data for correction by one transaction. LOV will have EVENT_ID
for Subledger and JE_HEADER_ID for General Ledger. In case there is no value
available, Document Number will be displayed in LOV.
Accounting Dates From, Accounting Dates To:
Limits the erroneous data for correction by range of accounting dates.
Processing:

1. Based on the parameters values selected, error records will be displayed so that
necessary correction can be carried out.
2. On clicking CLEAR button the parameters values selected will be cleared from the
Form.
3. On clicking FIND button, another form, Correct Translation Errors Form, will be
opened with necessary data for correction
B. Correct Translation Errors Form

Correct Translation Errors Form is opened from Find Errors Form. This form cannot be
called directly.
Form Fields:
Correction description:Unique for current user, given by system.
Application Source:Description for application with language of current session
Include:This is a check box to indicate inclusion of accounting lines for correction. This
is an enterable field.
Split:Allowed for rows with "Include" tick enabled.
This is a check box to indicate splitting of one accounting line for correction. This is an
enterable field.
Only one row from those with "Include" tick enabled can have "Split" tick enabled.
Account side:Only row from those with "Include" tick enabled may have a value in the
"Account side" field. This is an enterable field.with values Dr or Cr.

Other columns displayed for each line:
Transaction ID
Dr Account - LOV for natural account segment of KFF
Cr Account - LOV for natural account segment of KFF
Amount Entered
Amount Accounted
Acc Event ID
Period
Company - LOV for balancing segment of KFF
Currency
Event Date
Event Type
Event Line Type
Operation Unit I
Inventory Organization Document
Inventory Item Asset, etc.
Accounted Debit Amount:
Sum of accounted debit amount for rows where Dr is not empty and "Include" tick is
enabled
Accounted Credit Amount:
Sum of accounted credit amount for rows where Cr is not empty and "Include" tick is
enabled
Entered Debit Amount:
Sum of entered debit amount for rows where Dr is not empty and "Include" tick is
enabled
Entered Credit Amount:
Sum of entered credit amount for rows where Cr is not empty and "Include" tick is
enabled
Account:
Account Code Combination for current row
Account Description:
Concatenated Description for Account Code Combination of current row
Processing:

1. This form is used to manually pair the accounting entries in one debit and one
credit. The process is called Correction.
2. The end result of this form is not actual pairing but showing the paired lines in a
modal window as described in next form section.
3. Correction may be partial or full. In case of part correction, the balance correction
can be done at any time till CLE: XLA Translation Program or CLE: GL Translation
Program is run for that event with Process Error Event parameter value as Yes.
4. Only one transaction can be corrected at one time.
5. Split checkbox can be enabled only for Include enabled line. When You enable Split
that line will be paired with each other line having Include enabled. If total for all
pairs is different from original amount of Split line, the difference will be remaining
amount.
6. Only one line can have Split checkbox enabled. At the same time, any set of records
having Include enabled, must have one line with Split enabled.
7. Users can only select Include checkbox, Split checkbox and Account side field. All
other fields including amount fields are non editable.
8. The method of correction is

a. Where 2 lines are to be paired into 1 line
i. Enable the Include checkbox for two lines.
ii. Click on Translate button to get the Modal Window
iii. If the sign needs to be changed from positive to negative or vice versa, put the
opposite sign of that line in the Account side field for all the lines. By default, no
value is required in this field.
b. Where more than 2 lines are to be paired into more than one line – With one debit
and more than one credit OR With more than one debit and one credit
i. Enable the Include checkbox for all the lines for that event.
ii.Enable Split checkbox for appropriate line. I.e., when you have several debit lines
and one credit, the Split is to be enabled for credit line.
opposite sign of that line in the Account side field for all the lines. By default, no
value is required in this field.
c. Where more than 2 lines are to be paired into more than one line – With multiple
debit and credit lines.
i. Enable the Include checkbox for all the lines for that event.
ii. Enable Split checkbox for line, which will be paired with each other lines.

opposite sign of that line in the Account side field for all the lines.
9. Once proper selection is done, click on Translate button. This will take to Modal
Important: The Folder Tool is available for arranging data records and
fields in a convenient way for user.
C. Modal "Correction Results" Window
Based on the criteria selected for pairing, pairing will be shown in this window. The
Modal Window is used to confirm or cancel pairing.
The fields of the window are similar to the contents of Correct Translation Errors Form,
except that paired lines appear in this window.
Refer to the contents of Correct Translation Errors Form for details.
Processing:
1. If the pairing appears correct, click on OK button. Once OK button is pressed,
pairing actually happens to the error lines.
2. If the pairing appears incorrect, click on Cancel button to cancel the pairing.

8
CLE: CA Interface Transfer Program
Introduction
The CLE: CA Interface Transfer Program moves the successful translated accounting
entries from CLE_F000_ACC_CORR_INT (Interim) table to CLE_F000_ACC_CORR
(final) table.
Prerequisites
Setup
• 'CLE: CA Ledger' profile value should be setup.
Processing
• CLE: CA GL Translation program (or) CLE: CA XLA Translation Program should
have been ran before running this program.
• There should be atleast one entry/event with status as Processed in the

Program Submission
Run the program CLE: Interface Transfer Program from Standard Request Submission
CLE: CA Interface Transfer Program 8-1

Program Parameters
CLE: CA Interface Transfer Program

Application: Enter the Application you want to the process the accounting entries by
the program. This parameter is optional.
GL Period: Enter the General Ledger Accounting Period for which the Accounting
entries need to be processed by the program. This parameter is mandatory.
Processing:
• The program selects translated Accounting entries from
CLE_F000_ACC_CORR_INT table that have STATUS_FLAG ='P' in the
• The Program then inserts selected accounting entries from

CLE_F000_ACC_CORR_INT Interim table records into CLE_F000_ACC_CORR
final table.
• The program finally, deletes records from the CLE_F000_ACC_CORR_INT table

those have being inserted successfully into CLE_F000_ACC_CORR table.
• The records with status flag='E" are remained in the Interim and event table.
• The output of the program shows the transferred and skipped records separately
for each application, entity, and event class code wise.
• The error records are also printed in the log file with record id, error code and error
description.
• The records once moved from Interim table to Final table are updated with
status_flag with 'T' in the CLE_F000_ACC_CORR_EV table.

Output File
Exceptions
If any of the mandatory profiles are not setup, the program will end with Error status.
CLE: CA Interface Transfer Program 8-3

9
CLE: CA Interface Post Program
Introduction
The CLE: CA Interface Post Program moves the accounting entries from
CLE_F000_ACC_CORR (Final) table to CLE_F000_ACC_CORR_BAL (Balances) table
and update accounts balances.
Prerequisites
Setup
• 'CLE: CA Ledger' profile value should be setup.
Processing
• CLE: CA GL Translation program (or) CLE: CA XLA Translation Program should
have been successfully completed before running this program.
• CLE: CA Interface Transfer Program should have been run for the said period.
The records selected for posting should have status flag 'T'
Program Submission
Run the program CLE: Interface Post Program from Standard Request Submission from
General Ledger responsibility.
CLE: CA Interface Post Program 9-1

Program Parameters
Application: Enter the Application you want to the process the accounting entries by
the program. This parameter is optional.
GL Period: Enter the General Ledger Accounting Period for which the Accounting
entries need to be processed by the program. This parameter is mandatory.
Processing
It mainly consists of following steps:
• The Program select entries from CLE_F000_ACC_CORR table that have "U" in
POST_STATUS fields.
• The Program then update account balances in the CLE_F000_ACC_CORR_BAL

table for processed record. It has the same logic and rules as standard GL Post
program.
• The program should update records in the CLE_F000_ACC_CORR table and

CLE_F000_ACC_CORR_EV that have being processed successfully with "P" value
in the POST_STATUS field.

Output File
Exceptions
If any of the mandatory profiles are not setup, the program will end with Warning
status.
CLE: CA Interface Post Program 9-3

10
CLE: CA Account Reconciliation Report
Introduction
The purposes of this report are:
1. Make sure all journals and transactions were translated in Correspondence
Accounting records; and
2. Check the balance for each account in the standard balance table and
Correspondence balance table is matching.
Prerequisites
Setup:
The Ledger name for which translations are to be paired should be selected in the
Profile 'CLE: CA Ledger'.
Program Submission
Run the program CLE: CA Account Reconciliation Report from Standard Request
Submission from General Ledger responsibility.
CLE: CA Account Reconciliation Report 10-1

Program Parameters
Period:
Limits the report data by period. At a time Reconciliation Report can be run only for
one period.
The LOV contains periods except Never Opened from accounting calendar for the
ledger from parameter "LedgerId".
This is a mandatory parameter. There is no default value.
Source:
Limits the report data by the list of sources available for the ledger.
This is not a mandatory parameter. There is no default value.
Account From, Account To:
Limits the report data by account combinations.
This is not a mandatory parameter. In case no account is selected, report is run for all
the account combinations. There is no default value.
LOV shows segment values of AFF available in the ledger
Show Totals Only:
This is used to display the contents of the report.
LOV has 2 values, Yes and No. If value selected is Yes, only a summary of transactions
are shown. If value selected is No, details of transactions are shown.
This is a mandatory parameter. There is no default value.
Program Output

Processing
1. Based on the parameters selected, events are processed to check its status. The
statuses available are:
• Not translated: The event has not been translated yet, using CLE: XLA
Translation Program and / or CLE: GL Translation Program
• Error: The events are in error status. CLE: XLA Translation Program and / or
CLE: GL Translation Program has eroded out the events.
• Not transferred: The events successfully processed are not transferred from
temporary to final tables using CLE: CA Interface Transfer Program
• Not posted: The events transferred to final tables have not been posted using
CLE: CA Interface Post Program.
2. If events are in any one of the statuses, those events are reported in the pending
events section of the Reconciliation report.
3. If there are no events with above statuses, balance divergence is reported. This
shows all the accounts where the balance for an account as per standard balance
table is not matching with correspondence balance table.
4. If there are any accounts in the divergence section, that needs to be analyzed for
CLE: CA Account Reconciliation Report 10-3

reasons.
5. If there are no accounts in the divergence section with no pending events, that
means the balances are reconciled.
6. SLA Transactions not posted in General Ledger will be reported in the Balance
Divergence Section.

11
CLE: CA Account Analysis Report
Introduction
Part of the Correspondence Accounting solution, Account Analysis Report shows the
accounts information (ledger) of one or more accounts. The Account Analysis Report is
required by and complies with the common business practice.
Prerequisites
Setup:
• The Ledger name for which translations are to be paired should be selected in the
• A dummy KFF is defined with the same structure as the one for the LEDGER
mentioned in the Profile CLE: CA Ledger.The new structure should be named as
'CLE_' followed by the KFF name for the LEDGER_ID mentioned in the CLE
Ledger ID profile. For e.g., if the structure code is
ROMANIA_ACCOUNTING_FLEX, then dummy KFF name should be
CLE_ROMANIA_ACCOUNTING_FLEX.
• The segment separator used in dummy KFF should be same as mentioned for the
KFF for the ledger mentioned in the Profile CLE: CA Ledger.
Program Submission
Run the program CLE: Account Analysis Report from Standard Request Submission
CLE: CA Account Analysis Report 11-1

Program Parameters
Period From, Period To:

Limits the report data by Period.
LOV contains all the period names for the Ledger specified.
The Default Value is last open period.
In the Period To parameter, only periods mentioned in the Period From parameter are
available for selection.
Currency:
Limits the report data by currency codes.
LOV contains all active currency codes. NULL value is also allowed in the parameter.
If field is blank, the report shows data in the ledger functional currency (the records
nominated in any currency are processed and the data is displayed in the functional
currency)
If it is not blank then report will show for the currency specified (the records nominated
in this currency are processed only).
Account:
User must enter From/To Account parameters.
If 'From Account' parameter is specified then we must specified 'To Account'.
Summary Mask:
The Summary Mask shows, which segment of account, should be summed up in the
report.
The parameter is accounting flexfield and for each segment two possible values, D
(Detail) and T (Total) are available in LOV.

Program Output
Processing
1. If there are any unposted events in Correspondence tables, the report will not
display any data. This will be mentioned in the log file.
2. Based on the parameters, accounts are processed, accounts are displayed based on
the summary mask parameter.
3. Where all the segments have summary mask parameter value as D (Detail), all the
accounts selected will be displayed in the report.
4. However where any of the segments have summary mask parameter value as T
(Total), the accounts will be displayed with *(Asterisk) in the report. For example, if
following accounts are selected in the parameters:
Account from 01-000-2110-2102-000
Account to 01-003-2112-2104-000; and
Summary mask is defined as T-D-D-T-T.
Then report will show for following accounts:
**-000-2110-****-***
CLE: CA Account Analysis Report 11-3

**-001-2110-****-***
**-002-2110-****-***
**-003-2110-****-***
**-000-2111-****-***
**-001-2111-****-***
**-002-2111-****-***
**-003-2111-****-***
**-000-2112-****-***
**-001-2112-****-***
**-002-2112-****-***
**-003-2112-****-***
5. For each of the above account, balance and transactions will be shown for all
accounts that fall within the purview of the account combination. For example
Account combination - **-000-2110-****-*** may have various account combinations
like 01-000-2110-0000-000, 01-000-2110-1000-000, 02-000-2110-1000-000,
02-000-2110-1000-000, etc. These account combinations will not be displayed
separately but will be grouped into **-000-2110-****-*** as per the summary mask.
6. For each of the account thus selected, the corresponding accounts are displayed in
the transactions in debit / credit side as the case may be, along with the debit / credit
amount.
7. The amount appearing in the debit side will be displayed in the debit side and vice
versa, irrespective of whether the amount is positive or negative.
8. The opening balance, transactions amount and closing balance will be displayed for
an account or group of accounts based on summary mask as under:
• Where Currency parameter is functional – functional currency amount for
functional currency transactions.
• Where Currency parameter is foreign – foreign currency amount for foreign

currency transactions.
• Where Currency parameter is ALL – functional currency amount for all

9. Where selected accounts have no opening balance and transactions, those accounts
will not be displayed in the report. In other words, only accounts that have opening
balance and / or transactions will appear in the report.

12
CLE: CA Account Journal Report
Introduction
Part of the Correspondence Accounting solution, Account Journal Report shows the
accounts correspondence information for one or a few accounts and the list of
operations on this account. The Account Analysis Report is required by and complies
with the common business practice.
Prerequisites
Setup:
• The Ledger name for which translations are to be paired should be selected in the
• A dummy KFF is defined with the same structure as the one for the LEDGER
mentioned in the Profile CLE: CA Ledger.The new structure should be named as
'CLE_' followed by the KFF name for the LEDGER_ID mentioned in the CLE
Ledger ID profile. For e.g., if the structure code is
ROMANIA_ACCOUNTING_FLEX, then dummy KFF name should be
CLE_ROMANIA_ACCOUNTING_FLEX.
• The segment separator used in dummy KFF should be same as mentioned for the
KFF for the ledger mentioned in the Profile CLE: CA Ledger.
Program Submission
Run the program CLE: CA Account Journal Report from Standard Request Submission
CLE: CA Account Journal Report 12-1

Program Parameters
Period Name:
Limits the report data by Period.
LOV contains all the period names for the Ledger specified.
The Default Value is last open period.
If Date From and Date To parameters are specified, Period Name parameter gets
disabled and cannot be entered.
Date From, Date To:
Limits the report data by Date range.
There is no default value
In the Date To parameter, date on and after the date mentioned in the Date From
parameter are available for entry.
If Period Name parameter is specified, Date From and Date To parameters gets disabled
and cannot be entered
Currency:
Limits the report data by currency codes.
LOV contains all active currency codes. NULL value is also allowed in the parameter.
Select
If field is blank, the report shows data in the ledger functional currency (the records
nominated in any currency are processed and the data is displayed in the functional
currency)
If it is not blank then report will show for the currency specified (the records nominated
in this currency are processed only).
Account From. Account To:

The segments based on the ledger specified in the Profile 'CLE_ACC_CORR_LEDGER'.
Are displayed for entry / selection.
For each segment, the value in the To Account parameter should be greater than the
value in the From Account parameter.
Summary Mask:
The Summary Mask shows which segment of account should be summed up in the
report.
The parameter is accounting flexfield and for each segment two possible values, D
(Detail) and T (Total) are available in LOV.
Program Output
Processing
1. Based on the parameters, accounts are processed, accounts are displayed based on
the summary mask parameter
2. Where all the segments have summary mask parameter value as D (Detail), all the
accounts selected will be displayed in the report.
3. However where any of the segments have summary mask parameter value as T
(Total), the accounts will be displayed with *(Asterisk) in the report. For example, if

following accounts are selected in the parameters:
Account from 01-000-2110-2102-000
Account to 01-003-2112-2104-000; and
Summary mask is defined as T-D-D-T-T.
Then report will show for following accounts:
**-000-2110-****-***
**-001-2110-****-***
**-002-2110-****-***
**-003-2110-****-***
**-000-2111-****-***
**-001-2111-****-***
**-002-2111-****-***
**-003-2111-****-***
**-000-2112-****-***
**-001-2112-****-***
**-002-2112-****-***
**-003-2112-****-***
4. For each of the above account, balance and transactions will be shown for all
accounts that fall within the purview of the account combination. For example
Account combination - **-000-2110-****-*** may have various account combinations
like 01-000-2110-0000-000, 01-000-2110-1000-000, 02-000-2110-1000-000,
02-000-2110-1000-000, etc. These account combinations will not be displayed
separately but will be grouped into **-000-2110-****-*** as per the summary mask.
5. For each of the account thus selected, the corresponding accounts are also selected
in the same way and data is displayed for combination of Account and
corresponded account. The transactions is displayed in the debit / credit side as the
case may be.
6. In Account Journal Report, along with the amount, analytical data is also presented.
These data are specific to entity code within an application. The following table
shows the analytical data displayed.
Application Entity Code Additional Data
Payables AP_INVOICES INVOICE_NUM

Payables AP_INVOICES VENDOR_NAME
Payables AP_INVOICES INVOICE_TYPE
Payables AP_PAYMENTS PAYMENT_NUMBER
Payables AP_PAYMENTS VENDOR_NAME
Payables AP_PAYMENTS PAYMENT_METHOD
Receivables TRANSACTIONS TRX_NUMBER
Receivables TRANSACTIONS CUSTOMER_NAME
Receivables TRANSACTIONS TRANSACTION_TYPE
Receivables RECEIPTS RECEIPT_TYPE
Receivables RECEIPTS CUSTOMER_NAME
Receivables RECEIPTS RECEIPT_NUMBER
Receivables RECEIPTS PAYMENT METHOD
Receivables ADJUSTMENTS ADJUSTMENT_NUMBER
Receivables ADJUSTMENTS CUSTOMER_NAME
Receivables ADJUSTMENTS ADJUSTMENT_TYPE
Receivables ADJUSTMENTS ADJUSTMENT TRANSACTION

NUMBER
Receivables BILLS_RECEIVABLE BR_TRX_NUMBER
Receivables BILLS_RECEIVABLE BR_STATUS
Receivables BILLS_RECEIVABLE TRX_CLASS

Cost Management MTL_ACCOUNTING_EVEN INVENTORY_ORGANIZATION

TS
Cost Management MTL_ACCOUNTING_EVEN SUBINVENTORY

TS
Cost Management MTL_ACCOUNTING_EVEN TRANSACTION_NUMBER

TS
Cost Management MTL_ACCOUNTING_EVEN TRANSACTION_TYPE

TS
Cost Management MTL_ACCOUNTING_EVEN TRANSACTION_ID

TS
Cost Management MTL_ACCOUNTING_EVEN TRANSACTION_SOURCE_TYPE

TS
Cost Management MTL_ACCOUNTING_EVEN TRANSACTION_SOURCE_ID

TS
Cost Management MTL_ACCOUNTING_EVEN TRANSACTION_SOURCE

TS
Cost Management RCV_ACCOUNTING_EVEN INVENTORY_ORGANIZATION

TS
Cost Management RCV_ACCOUNTING_EVEN SUBINVENTORY

TS
Cost Management RCV_ACCOUNTING_EVEN TRANSACTION_TYPE

TS
Cost Management RCV_ACCOUNTING_EVEN VENDOR_NAME

TS
Cost Management RCV_ACCOUNTING_EVEN ITEM

TS
Cost Management RCV_ACCOUNTING_EVEN ITEM_DESCRIPTION

TS

Cash Management CE_CASHFLOWS CASH_FLOW_NUMBER
Cash Management CE_CASHFLOWS BANK_ACCOUNT_NUMBER
Cash Management CE_CASHFLOWS TRANSACTION_TYPE
Cash Management CE_CASHFLOWS CASHFLOW_DIRECTION
Cash Management CE_CASHFLOWS CASHFLOW_STATUS
Purchasing PURCHASE_ORDER PO_TYPE
Purchasing PURCHASE_ORDER VENDOR_NAME
Purchasing PURCHASE_ORDER PO_NUMBER
Purchasing PURCHASE_ORDER BUYER
Purchasing RELEASE PO_NUMBER
Purchasing RELEASE VENDOR_NAME
Purchasing RELEASE RELEASE_NUM
Purchasing RELEASE BUYER
Purchasing REQUISITION REQ_NUMBER
Purchasing REQUISITION REQ_TYPE
Purchasing REQUISITION REQ_STATUS
Purchasing REQUISITION PREPARER
Assets TRANSACTIONS BOOK_TYPE_CODE
Assets TRANSACTIONS ASSET_NUMBER
Assets TRANSACTIONS ASSET_DESCRIPTION

Assets DEPRECIATION BOOK_TYPE_CODE
Assets DEPRECIATION ASSET_NUMBER
Assets DEPRECIATION ASSET_DESCRIPTION
Assets DEFERRED_DEPRECIATIO BOOK_TYPE_CODE

N
Assets DEFERRED_DEPRECIATIO ASSET_NUMBER

N
Assets DEFERRED_DEPRECIATIO ASSET_DESCRIPTION

N
General Ledger GL Date
General Ledger Journal Name
General Ledger Journal Source
General Ledger Journal Category
Note that the above data is captured by CLE: CA GL Translation Program and CLE:
CA XLA Translation Program.
7. Note that only above columns are displayed for an entity code; not all entity codes
are considered and not all applications are considered. If an entry is fond where an
application / entity code is not available for analytical reporting, the report will
indicate that fact and display basic details like amount for that account.
8. The amount appearing in the debit side will be displayed in the debit side and vice
versa, irrespective of whether the amount is positive or negative.
9. The opening balance, transactions amount and closing balance will be displayed for
an account or group of accounts based on summary mask as under:
• Where Currency parameter is functional – functional currency amount for
functional currency transactions.
• Where Currency parameter is foreign – foreign currency amount for foreign


• Where Currency parameter is blank – functional currency amount for all
10. Where selected accounts have no opening balance and transactions, those accounts
will not be displayed in the report. In other words, only accounts that have opening
balance and / or transactions will appear in the report.

13
Custom Sources
Details
1. CLE_CA_ADR_AR_ADJ_REC
2. CLE_CA_ADR_AR_CM_REC
Custom Sources 13-1

3. CLE_CA_ADR_AR_INV_REC

4. CLE_CA_ADR_AR_INV_REV4TAX
Custom Sources 13-3

5. CLE_CA_AMNT_AR_INV_REV

6. CLE_CA_AR_INV_REV
Custom Sources 13-5

Export Application Accounting Definitions
The Export Application Accounting Definitions program exports all application
accounting definitions of an application from a database to the file system and produces
a report of the results. All application accounting definitions and journal entry setups
for an application are exported to the same data file. When the application accounting
definitions are exported, a new version is stamped on the application accounting

definitions, mapping sets, and account derivation rules referenced by exported
application accounting definitions.
Parameters
Account Method Builder Context -AMB context for the application accounting
definitions to be imported; defaulted from the SLA Accounting Methods Builder
Context profile option; required
Destination File - Path Full path name, including the .ldt file name, ofthe file system
where the application accounting definitions are to be exported; required Path name
example: /home/jdoe/out/APAAD.ldt
Important: At least one of the three destination file path names must be
entered.
Destination File Pathname for Base Application - Valid file path name for the base
application
Destination File Pathname for Budgetary Control -Valid path name for the federal
budgetary control
Versioning Mode - Indicates whether the exported application accounting definitions
are a result of leapfrogging. Select Standard if the AAD to be exported is based on the
latest version; select Leapfrog if the AAD to be exported is not based on the latest
version; or select Supersede if the AAD to be exported is not based on the latest version
and is not a leapfrog. Default is Standard.
Custom Sources 13-7

User Version - User-assigned version;optional
Export Comment -User-entered export comments; optional
When completed successfully, the Export Application Accounting Definitions program
produces a report highlighting all the exported application accounting definitions as
well as all the errors that occurred during the export process.
Import Application Accounting Definitions
Application accounting definitions are imported using the Import Application
Accounting Definitions concurrent program. This program imports the application
accounting definitions from a data file to the Accounting Methods Builder (AMB)
context specified in the SLA: Accounting Methods Builder Context profile option and
produces a report of the results.
When running the Import Application Accounting Definitions concurrent program,
users specify whether to run the merge analysis, merge, or overwrite processes
Parameters
Accounting Methods Builder Context - AMB context for the application accounting
definitions to be imported; defaulted from the SLA: Accounting Methods Builder
Context profile option; required
Source Data File Full path name, including the .ldt file name, of the data file containing
the application accounting definitions to be imported; required. Path name example:
/home/jdoe/out/APAAD.ldt

Important: At least one of the three source path names must be entered.
Source File Pathname for Base Application - Valid source file path name
Source File Pathname for Budgetary Control - Valid source file path name
Merge Analysis Only - Determines whether merge analysis is performed to the
imported application accounting definitions. Default is Yes.
Batch Name - User-entered merge analysis report name
Import Option - Enabled and required only if the Merge Analysis Only parameter is set
to No; indicates whether the application accounting definitions from the data file
should be merged or overwritten to the database. Default is Merge.
Validate - Enabled and required only if the Merge Analysis Only parameter is set to No;
determines whether the Validate Application Accounting Definitions concurrent
program should be submitted to validate all the imported application accounting
definitions. Default is Yes.
Force Overwrite - Enabled and required only if the MergeAnalysis Only parameter is
set to No and the Import Option is Overwrite; indicates whether Subledger Accounting
should allow an application accounting definition to be overwritten from the data file to
the database if the version in the data file is lower than the version in the database.
Default is No.
When the Import Application Accounting Definitions program is completed
successfully, a report highlighting all the imported application accounting definitions
and their versions as well as all the errors that occurred during the import process is
produced
Custom Sources 13-9

14
Glossary
Details
SLA
SLA (Subledger Accounting Architecture) is the R12 solution that enables one to have
user defined accounting entries for the application products accounting events.
Correspondence Accounting
The set of standard OEBS and additionally developed features that provides the
representation of accounting information in a form that complies with the accounts
correspondence format ("One-to-One" rule).
Accounting scheme
A set of accounting lines (each accounting line has definite accounting class) that
represents the accounting of definite accounting events.
In SLA terms an accounting scheme is a set of Journal Line Definitions for a particular
accounting event type.
Accounting pair
Accounting pairs is a set of two accounting lines that form accounts correspondence.
Accounts Correspondence
Accounting scheme that settles direct relationships between all accounting lines in the
Accounting Scheme with "One-to-One" rule.
Glossary 14-1
In the following the accounting scheme the account correspondence is determined
directly:
There are two accounting pairs: Dr RECEIVABLES – Cr REVENUE on 120.00 and Dr

REVENUE – Cr TAX on 20.00.
In the following example of the accounting scheme the account correspondence is not
determined directly but it can be detected and the accounting pairs built:
Two accounting pairs can be built: Dr LIABILITY – Cr CHARGE 1 on 150.00 and Dr

LIABILITY – Cr CHARGE 2 on 50.00.
In the following example the account correspondence cannot be determined:
Accounting event:
It is an event that causes / triggers accounting for a transaction. Validating an invoice or
making a payment are examples of events.
Accounting Pair Definition Code (APDC):
A combination of one Journal Line Definition and two Journal Line Types that allows

detecting and building the accounts correspondence (accounting pair).
Alternative Journal Line Definition (AJLD):
An alternative JLD defined in UTOOL where user defines pairing so that pairing can
happen. An alternative JLD is defined on top of standard SLA JLD
Glossary 14-3

Index
Introduction, 1-1, 5-1, 6-1, 7-1, 8-1, 9-1, 10-1, 11-1,

Symbols 12-1
Introduction, 4-1
L
C
Localization Setup, 2-1
CLE: CA Account Analysis Report, 11-1
CLE: CA Account Journal Report, 12-1
O
CLE: CA Account Reconciliation Report, 10-1
CLE: CA Correction Form, 7-1 Output, 4-25
CLE: CA GL Translation Program , 4-1 Output File, 8-3, 9-3
CLE: CA Interface Post Program, 9-1 Overview, 3-2
CLE: CA Interface Transfer Program, 8-1
CLE: CA Universal Tool, 5-1 P
CLE: CA XLA Translation Program, 6-1 prerequisites, 5-2
Correspondence Accounting Functionality, 1-1 Prerequisites, 4-1, 6-2, 7-1, 8-1, 10-1, 11-1, 12-1
Custom Sources, 13-1 Processing, 4-3, 5-7, 6-5, 9-2, 10-3, 11-3, 12-3
Program Output, 6-5, 10-2, 11-3, 12-3
D Program Parameters, 6-3, 10-2, 11-2, 12-2
Details, 13-1, 14-1 Program submission, 9-1
Program Submission, 4-2, 6-3, 8-1, 10-1, 11-1, 12-1
E
S
Exceptions, 8-3, 9-3
Setting Up Correspondence Accounting solution,
F 2-1
Solution Overview, 3-1
Form Descriptions, 7-1
Form Navigation , 5-3
G
Glossary, 14-1
Index-1

Oracle® CLE: Correspondence Accounting User Guide Release 12.0

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Oracle® CLE: Correspondence Accounting User Guide Release 12.0

Hochgeladen von

Copyright:

Verfügbare Formate

Oracle® CLE

Correspondence Accounting User Guide

Part No. B00001-05

Copyright © 2008, Oracle. All rights reserved.

Primary Author: Iyer Kannan Ramalingam and Pawan Tallam

U.S. GOVERNMENT RIGHTS

Send Us Your Comments

4 CLE: CA GL Translation Program

5 CLE: CA Universal Tool

6 CLE: CA XLA Translation Program

7 CLE: CA Correction Form

8 CLE: CA Interface Transfer Program

9 CLE: CA Interface Post Program

10 CLE: CA Account Reconciliation Report

11 CLE: CA Account Analysis Report

12 CLE: CA Account Journal Report

Oracle CLE Correspondence Accounting User Guide, Release 12.0

About this Country-Specific User Guide

• Oracle Payable User's Guide

• Oracle Cash Management User's Guide

• Oracle Assets User's Guide

• Oracle Inventory User's Guide

• Oracle Cost Management User's Guide

• Oracle Subledger Accounting User's Guide

• TECHNICAL SUPPORT FOR SERVICE DELIVERABLES IS NOT AVAILABLE

• YOUR RIGHT TO USE AND RECEIVE SUPPORT SERVICES FOR SERVICE

• A SERVICE REQUEST REGARDING SERVICE DELIVERABLES,

Accessibility of Code Examples in Documentation

Accessibility of Links to External Web Sites in Documentation

Related Information Sources

Do Not Use Database Tools to Modify Oracle Applications Data

Correspondence Accounting Functionality

• CLE: CA XLA Translation Program (includes the utool.parse pl/sql package)

• CLE: CA Universal Tool Form

• CLE: CA Correction Form

• CLE: CA Interface Transfer Program

• CLE: CA Interface Post Program

• CLE: CA Account Reconciliation Report

• CLE: CA Account Analysis Report

• CLE: CA Account Journal Report

Setting Up Correspondence Accounting solution

2. CLE: CA Intercompany Line Added by Posting

3. CLE: CA GL Manual Source

4. CLE: CA Commit Value

Localization Setup 2-1

6. CLE: CA GL Offset Line Number

7. CLE: CA Debug Flag

2-2 Oracle CLE Correspondence Accounting User Guide

Solution Overview 3-1

CLE: CA GL Translation Program: Translates GL entries and stores (translated and

3-2 Oracle CLE Correspondence Accounting User Guide

Solution Overview 3-3

2. One debit and more than one credit OR

3. More than one debit and one credit OR

4. More than one debit and more than one credit

CLE: CA GL Translation Program 4-1

2. CLE: CA Intercompany Line Added by Posting

3. CLE: CA GL Manual Source

4. CLE: CA Revaluation Default Definition

5. CLE: CA Commit Value

6. CLE: CA GL Offset Line Number

2. The Journals should be posted in General Ledger.

3. Journals with currency as STAT will not be processed.