Journal Line Reconciliation Whitepaper- GL

Journal Line Reconciliation in R12 Page 1

JJoouurrnnaall LLiinnee RReeccoonncciilliiaattiioonn::

RReelleeaassee 1122 FFuunnccttiioonnaalliittyy

An Oracle Whitepaper 2014

Author: Anshu Anand

Scope: Reconciliation functionality has always been available as a part Oracle Financials

Common County Applications (European Localizations). The functionality was later

incorporated as a part of Standard Release 12 application considering its advantages and

Business Applications.

The scope of this document is to describe the features of this functionality along with

Business Advantages it has to Offer. The document talks of the Setups required, Reporting,

Technical References and few of the Known Issues.


TABLE OF CONTENTS

Overview ………………………………………………………………………….3

Application Setup…………………………………………………………….4

Populating References

Populating Line References Manually ……………………………….6

Reconciliation Reference for Journal Header…………………....7

Populating References from Submodules…………………………..9

Reconciliation Process

Manual Reconciliation…………………………………………………………..13

Automatic Reconciliation……………………………………………………...15

Effect on References on Reversals and Reporting

Ledgers…………………………………………………………………………….…17

Multi Currency Reconciliation ……………………………………….19

Reconciliation Reversal……………………………………………………20

Upgrade Considerations…………………………………………………..23

Reports……………………………………………………………………………….24

Technical Reference…………………………………………………………26

Some Common Queries Answered…………………………………28

Known Issues…………………………………………………………………….30


General Ledger Entry Reconciliation functionality lets you reconcile transactions in General

Ledger that should ideally balance to zero. Examples could be all clearing Accounts, VAT

control account, Suspense Accounts etc.

Let begin by taking a simple Business Example:

a) When you receive an Inventory item, Ideally the Journal entry would be –

Inventory…….Dr

AP Accrual account…….Cr

b) When you book the Invoice and Validate, the journal that gets generated is

AP Accrual account…….Dr

Control account/Party……...Cr

c) Which means, once the cycle completes, the Credit and Debit for Accrual Account

should ideally knock off, leaving a final journal as follows:

Inventory…….Dr

Control account/Party…….Cr

Hence, at any point of time, once the cycle completes, the net for the AP Accrual Account

should be zero. Also, to clear this AP Accrual account, you should be able to give the

breakup of invoices not booked for the material received.

This is where our Journal Line Reconciliation helps us. It allows you to knock of such related

debit and credit pieces and also helps in identifying which transactions still remain

incomplete. This type of reconciliation requires user’s business discipline that all the invoices

will matched to a receipt and not PO, else the reconciliation for this account might go for a

toss.

Journal Reconciliation is available for journals of the balance type of Actual and Journal type

of Standard only. The application allows the Reconciliation process to be performed

manually or even automatically by populating references. The details of the same have been

provided in the following pages.


APPLICATION SETUP

1. Enable ‘Reconciliation’ for your Ledger:

Query for your ledger and ensure the ‘Reconciliation’ checkbox is checked.

Navigation: General Ledger Responsibility -> Setup -> Financials ->

Accounting Setup Manager -> Advanced Options

2. Set the ‘Reconciliation‘ Segment qualifier for your Accounting Flexfield:

To set the Reconciliation Flag segment qualifier, enter ‘Yes’ for Reconciliation Flag to

allow reconciliation for natural accounts that you would wish to use for this purpose.

You can enable or disable reconciliation for an account segment value or for specific

account code combinations as well.


Navigation: General Ledger Responsibility -> Setup -> Financials ->

Flexfield -> Key -> Values

The Release 11i Reconciliation feature did not have Reconciliation Qualifier existing. One

had to create the ‘GL Reconciliation Flag’ valueset with Values as Yes/No and then register the

same against the ‘Natural Account ‘Flexfield. (Ref Doc Id: 1041211.6)

If you are enabling the Reconciliation Reference for an already existing Natural Account,

please ensure to the ‘Program - Inherit Segment Value Attributes’ to ensure the Reconciliation Flag

enable is cascaded to the related code combinations as well.


3. Populating Reconciliation References

Imagine the Application returning a whole lot of journal lines upon querying and you

are expected to choose the relevant ones that need to get reconciled. Can get

difficult in case of organizations that indulge in large number of transactions.

‘Reconciliation References’ are identifiers or short messages that can be entered

against journal lines to help them cross-reference each other. With References, you

can selectively cross-reference transactions in General Ledger by entering

reconciliation reference information at journal line level. When the balance for a

group of transactions is zero, the transactions can be marked as reconciled.

Please note that references are not mandatory. Journal lines can be reconciled even

if they have blank references.

Let us take an example of a Manual Journal:

The cross-references can be entered against the ‘Reconciliation Reference’ field. It

could be any text you wish to choose, though it is always suggested to have a

reference that holds a meaningful relation to the lines. In the above example is

trying to track payments against check#6789.

References can also be imported for transactions coming in from the submodules like

payables, Receivables, Fixed Assets etc. A customization of ‘Subledger Accounting

Method’ (SLAM) may be needed to populate the logic.


b) Reconciliation Reference for a Journal Header

Well …yes! While we have always been talking of reconciling Journal Lines, it is

possible to assign a Reconciliation Reference to the Journal Header as well. Once the

user enters a Reconciliation Reference for the Journal Header in the ‘Other

Information’ tab, all the lines entered into this journal, post addition of the reference,

shall automatically inherit the reference provided at the header level. Of course, if

any of the lines are created for a code combination not marked for reconciliation, no

reference shall be populated in this case.

Please note that any journal line that was entered before the Reference was provided

at the header, shall NOT inherit the reference. Which also means that if a Journal line

was entered prior to the Reconciliation Reference being provided for a code

combination marked for Reconciliation, it would automatically populate the

Reconciliation Reference as ‘Null’ for such lines.

Step1 : Create a New Journal and enter a Reconciliation Reference for the

Header

Navigation : Journal -> Enter -> Other Information Tab


Step2: Now Enter the Journal Lines and see the Reconciliation Reference

populate automatically

Navigation: Journal -> Enter

Header References can be created using Journal Enter form only. It is not possible to import

references for headers either from the third party tool, Web ADI or even using a standard

submodule, since the table gl_interface does not provide for it.


c) Setups for populating References from Submodules

The main improvement of the R12 functionality is the ability to populate the

reconciliation reference automatically in the GL Interface from the subledgers. This

can be done by enabling the Reconciliation Reference in the respective Journal Line

Type, and requires a custom Subledger Accounting Method (SLAM).

Detailed steps are demonstrated in the trail below:

Step1:

Navigation: Setup > Financials > Subledger Accounting > Accounting

Methods Builder > Journal Entry Setups > Journal Line Types

1. Query a seeded Journal Line Type and copy it by clicking on the Copy button at

the bottom left of the form

2. Give your Journal Line Type code, name, and description a meaningful name.

3. Ensure the “Transfer to GL” field is chosen as ‘Detail’


Step2:

1. Click on the Accounting Attribute Assignments button at the bottom right of the

form

2. Pick a Source for the Reconciliation Reference.


A ‘Source’ signifies the field you would wish to populate the reconciliation reference

against while creating the transaction in the submodule. In the example above, we

have chosen the source as ‘Invoice Distribution Reference’. Hence, whatever

message you record against the Description field of an Invoice Distribution shall get

cascaded as the Journal Line ‘Reconciliation Reference’ in General Ledger.

One could also choose source to be Invoice Description, Invoice Amount etc, based

on the Business Requirement.

3. Save.

Step3:

Navigation: Setup > Financials > Subledger Accounting > Accounting Methods

Builder > Methods and Definitions > Journal Line Definitions

1. Link the Journal Line Type just created to the Journal Line Definition. Copy a

seeded one and create your own if needed.


Step4:

Ensure that the JLD is already linked to the Application Accounting Definition,

validate the Application Accounting Definition either in the form or via the concurrent

program 'Validate Application Accounting Definitions'.

Assuming also that the Application Accounting Definition is already linked to the

Subledger Accounting Method which in turn is already linked with the ledger, Create

Accounting can now be run.

Step5: Create a Transaction in the Submodule and run the Import Program

Notice that the Invoice Distribution Description is populated as ‘AA May02’.

Step6: Journal gets populated in General Ledger with the Line References as per

the setup.


THE RECONCILIATION PROCESS

1. Manual Reconciliation

General Ledger allows you to reconcile transactions by choosing the relevant journal

lines manually. In the Reconciliation Lines window, you can query the transactions

that are available for reconciliation and select the transactions that you want to

reconcile with each other. If the sum total of the selected transactions is equal to

zero when you save the reconciliation, then General Ledger marks the journal lines

as reconciled. You can reconcile transactions by the entered debit or credit amounts.

Step1: Query for the desired Journal Lines

Navigation: Journals -> Reconciliation -> Reconcile

Choose the desired parameters. Please note that its only the Ledger, Currency and

Period that is mandatory. Others could be left blank. Choosing the Reconciliation

Reference as blank shall list all the Journal lines – irrespective of them having a

reference value populated or not.


Step2: Select the Journal Lines

Hitting the Search button on the above form shall show up all the journal lines

matching the criteria provided for search. Select the lines you wish to pick up.

Step3: Reconcile

Once the required lines are selected, simply click on the ‘Reconcile’ button.

General Ledger assigns a unique ID to each reconciliation that you perform. You can

use this ‘Reconciliation ID’ to query the reconciliation in the Reverse Reconciled Lines

window, or to identify the reconciliation on the Reconciled Transactions report.

Step4: Confirmation from Backend

Reconciliation details are populated in the table gl_je_lines_recon in Release12 of the

application. Please refer an extract from Sqlplus below:


select * from gl_je_lines_recon

where JGZZ_RECON_ID = '13021'

Note that the column JDZZ_RECON_STATUS changed to ‘R’ (Reconciled)

2. Automatic Reconciliation

Application also provides a feature to automatically reconcile the journal lines using a

concurrent Program. The Program ‘Reconciliation – Automatic Reconciliation’

takes similar parameters like the Manual Reconciliation form along the following:

a) Reconciliation Rule:

This parameter determines the logic to be used while reconciling the journal

lines.

Valid Options for ‘Reconciliation Rule’ are –

• By Account and Reference- Match reconciliation transactions that share the

same account code combination and reconciliation reference.

• By Balancing Segment and Reference- Match reconciliation transactions

that share the same balancing segment value and reconciliation reference.

• By Balancing Segment, Natural Account and Blank Reference- Match

transactions that share the same balancing segment value, natural account and

have no reconciliation reference

• By Balancing Segment, Natural Account and Reference - Match

transactions that share the same balancing segment value, natural account and

reconciliation reference.

Please note the difference between Option 1 and Option 4. While ‘Account’ in the

Option 1 refers to a Code Combination, the term ‘Natural Account’ in the Option 4 refers to

the Flexfield qualifier ‘Natural Account’


b) Perform Reconciliation :

No: Gives a preview of reconciliation matching. No matching would be

performed though.

Yes: Final Mode that completes the reconciliation matching Process.

To View a sample Output of the Report, please click here

Reconciliation___Automatic_Rec_060514.txt


EFFECT ON RECONCILIATION REFERENCES ON

REVERSALS AND REPORTING LEDGERS

Reconciliation References flow through exactly like the Original Journal upon Reversal

or even when they get replicated in the Reporting Ledger

Reporting Ledgers

Original Journal:

If you notice, exactly the same reconciliation references get populated for the

Reporting Journal, once the original journal is posted in the Primary Ledger. In case

of Reporting ledgers set up at the ‘Subledger level’, the Submodule transfers the

same reconciliation reference to the Journal created at the Reporting ledger level as

well.

The Header level Reconciliations get replicated as well.

Journal with Reporting Ledger


Reversal Journals

Original Journal:

Reversed Journal


MULTI-CURRENCY RECONCILIATION

Let us take an example. A business user buys an Asset for 1000 USD (which is the foreign

currency) at the rate of 2.0 and by the time the payment of this 1000 USD is made, the rate

changes from 2.0 to 3.0. Summing up, notice that though the accounted amounts for the

purchase and payments are different in the functional currency, the actual amount of

transaction in USD remains constant. Since a Purchase and its Payment ideally complete a

cycle, these two lines should be allowed to be reconciled.

Application allows reconciliation of transactions for a currency other than the Primary

currency as well. The reconciliation process expects the ‘Entered Currency’ to total up to

Zero irrespective of the Accounted Amounts matching or not. It is not possible to reconcile

journals lines of one currency with the other.

In the example below, we have tried reconciling transactions for the USD currency. If you

notice, the application creates Reconciliation Id successfully for Journal lines where Entered

Debit less Entered Credit is zero but the Accounted Debit less Accounted Credit is not.

Entered Debit : 10

Entered Credit : 10

Accounted Debit : 10

Accounted Credit : 20


RECONCILIATION REVERSAL

Reconciliation Reversal can be used to disassociate transactions that that have been

previously reconciled with each other.

In the Reverse Reconciliations window, you can query transactions that you

previously reconciled and select the transactions that you want to disassociate from

each other. If the sum total of the selected transactions is equal to zero when you

save the reconciliation reversal, then General Ledger marks the journal lines as

unreconciled. These transactions then become available for reconciliation again.

Lets take the same example of Reconciliation Id 13021 that we manually reconciled

in the previous example:

Step1: Query for the Reconciliation Id or Reference that you wish to

Unreconcile

Navigation: Journals -> Reconciliation -> Reverse


Step2: Select the Journal Lines and ‘Unreconcile’

Here again, you will have have to ensure that the sum of debits and credits equals

zero.

Step3: Confirmation from Backend

Reversal details shall be populated in the table gl_je_lines_recon in Release12 of the

application. Please refer an extract from Sqlplus below:

select * from gl_je_lines_recon

where JGZZ_RECON_ID = '13021'

Note that querying journals on the Reconciliation Id returns no rows.


Also, upon querying the table for the Journal header Id, note that the Reconciliation

Status identified by JG_ZZ_RECON_STATUS is set back to Unreconciled(U) and the

values populated for the Reconciliation Reference in the column JG_RECON_ID has

been removed as well.


UPGRADE CONSIDERATIONS

Users who are planning to upgrade from 11i to R12 and have been using the

Reconciliation functionality in 11i, shall have to run ‘Program - Upgrade Journal

Lines For Reconciliation’ (GLRCNM) as part of the upgrade to ensure the

reconciliation relevant data is available in Release 12. This program should be run as

part of the upgrade from 11i. It takes the journals from release 11i and adds them

to the table GL_JE_LINES_RECON and thus makes them available on the

reconciliation form.

The program cannot be run more than once. If you try to run it again it will issue a

warning to say it has already been run and the upgrade is done. Also, It can only be

run as part of an upgrade from release 11i, as it uses the information in release 11i

tables to populate the table GL_JE_LINES_RECON.

This program is also known to work for post-upgrade journals. The program spawns

another program ‘Insert Journal Lines for Reconciliation’ (GLRCNINS) which

inserts into the gl_je_lines_recon table for every code combination that has

jgzz_recon_flag Y but the lines do not exists in gl_je_lines_recon.

Below the insert performed:

INSERT INTO gl_je_lines_recon

.

.

FROM gl_code_combinations c, gl_je_lines l ' ||

' WHERE c.code_combination_id between :start_id and :end_id ' ||

'AND c.code_combination_id = l.code_combination_id ' ||

'AND c.jgzz_recon_flag = ' || '''' || 'Y' || '''' ||

' AND NOT EXISTS ' ||

'(SELECT /*+ ORDERED INDEX(r gl_je_lines_recon_u1) */ 1 ' ||

'FROM gl_je_lines_recon r ' ||

'WHERE r.je_header_id = l.je_header_id ' ||

'AND r.je_line_num = l.je_line_num) ';


REPORTS

1. Reconciliation – Reconciled Transactions

As the name suggests, the Reconcile Transactions Report provides a detailed

view of the transactions that have been reconciled already. The report groups

transactions based on the Reconciliation Id and Reconciliation Date for easy

reference.

It takes parameters like Ledger Name, Currency, Period, Start & End Dates and

the Account Range you wish to run the report for.

Following is a sample output of the Report:

2. Reconciliation – Unreconciled Transactions

Similar to the above, the Unreconciled Transactions Report lists all the transactions

for a provided Account range that have not yet been reconciled. These shall be

basically the journal lines that exist in the table GL_JE_LINES_RECON with

Reconciliation Status as ‘U’ (Unreconciled). You can use this information to help you

decide whether to perform additional automatic or manual reconciliations for these

accounts.


The report also takes parameters like Ledger Name, Currency, Period, Start & End

Dates and the Account Range you wish to run the report for.

Following is a sample output of the Report:


TECHNICAL REFERENCE

1. Table GL_JE_LINES _RECON

This table can be called as the spinal cord for the entire Reconciliation Process. For a

user to be able to run reconciliation or reverse it, run any reports, data should exist

in this table.

Column Name Significance

JE_HEADER_ID The Journal Header Id

JE_LINE_NUMBER Journal Line Number

JGZZ_RECON_STATUS Reconciliation Status

U – Unreconciled

R - Reconciled

JGZZ_RECON_DATE

Date when reconciliation was performed

JGZZ_RECON_ID

Reconciliation Id created by the

application.

JGZZ_RECON_REFERENCE

Reconciliation Reference

2. Table GL_JE_LINES

Release 12 of the application does not populate any data in the table gl_je_lines



JE_LINE_NUMBER Journal Line Number

JGZZ_RECON_STATUS_11I

These columns were created to capture

11i data but the initial upgrade code did

not take care of the same. The table

GL_JE_LINES _RECON populates the

data now. Hence, these columns

normally remain blank.

JGZZ_RECON_DATE_11I

JGZZ_RECON_ID_11I

JGZZ_RECON_REF_11I


3. Table GL_JE_HEADERS

In case where the Reconciliation Reference is populated at the Journal header level,

the header referenced is also recorded in the table gl_je_headers



NAME Journal Name

JGZZ_RECON_REF Header Reconciliation Reference

Please note the reconciliation reference is also stamped in the table GL_JE_LINES

_RECON for the journal lines that uses a Header Reference.

4. Table GL_INTERFACE


LEDGER_ID The Ledger Id

USER_JE_SOURCE_NAME Source of the Journal

JGZZ_RECON_REF Reconciliation Reference for Journal

Line.

To Re-iterate, It is not possible to import references for headers either from the third

party tool, Web ADI or even using a standard submodule, since the table gl_interface

does not provide for it. Table gl_interface provides for storing Reconciliation

References at Journal Lines level only.


SOME COMMON QUERIES ADDRESSED

1. Can one Reconcile Unposted Journal Lines?

No. Only Posted journal lines can be reconciled.

2. Is it Mandatory to have a Reconciliation Reference populated?

No. In case reference is not populated for a code combination that is marked for

reconciliation, it is recorded and treated as ‘Null’ for all practical purposes.

3. I donot see any concurrent Program getting fired upon clicking the

‘Reconcile’ button. Anything I am missing out on?

The Reconciliation Process does not fire any concurrent program as such. Click of

the ‘Reconcile’ or ‘Unreconcile’ button shall automatically launch the process.

4. Is there an Option that makes populating Reconciliation Reference

mandatory? There are cases where users miss on entering the references

while creating a transaction, causing issues with identification of the

right Journal Line during Reconciliation.

Though the reconciliation reference field is displayed, the entry of this data is

optional. Enhancement request 7410862 has been raised to request for a

possibility of making this field as mandatory.

We are looking at the possibility of a profile option or some means when enabling

reconciliation references for specific accounts, by which entry of the references,

during journal entry can be made mandatory. Until then a form personalization

could make this field mandatory, while the enhancement is not

approved/released.

5. On the Reconciliation form, after entering the selection criteria, is it

possible to select all the items listed at one go - A Select All Option.

Normally you have to select each item one at a time. With the current

design, if the customer has large number of lines to reconcile, it becomes

tedious and time consuming to select them one by one?

Currently this feature does not exist. Following Enhancement request has been

raised, Bug: 16566905 - GLXRCENT provide "Select All" Feature or Enable

"Edit -> Select All" On the Toolbar.

https://bug.oraclecorp.com/pls/bug/webbug_print.show?c_rptno=7410862

https://mosemp.us.oracle.com/epmos/faces/BugDisplay?id=16566905


6. Can Encumbrance and Budget lines be reconciled – separately or even

put together?

Only Actual lines can be reconciled. There was a bug with the code in initial versions that returned Budget and Encumbrance lines for reconciliation as well.

A patch was later released to resolve the issue. Please refer the ‘Known Issues’

section.


KNOWN ISSUES

S.No. Issue Possible Solution

1

Automatic Reconciliation Program does

not reconcile corresponding Journal

lines even when sum of debit and sum

of credit equal zero.

This happens when there is negative

amount in debit or credit for example :

Debit = -1000

Cause : The Issue was identified with

code of the Program over Bug Number

7291942

Solution: Apply Patch 7291942.

The Patch would upgrade the file version

for GLXRCAUT.rdf as follows:

For R12.0:

GLXRCAUT.rdf 20.6.12000000.3

For R12.1:

GLXRCAUT.rdf 120.6.12010000.3

2

JGZZ_RECON_REF Field in

GL_JE_LINES_RECON is not getting

populated in Reporting Ledger

Journal created in Primary Ledger.

While entering Journal,

Reconciliation field (JGZZ_REC_REF

field in GL_JE_LINES_RECON) is

populated.

The Primary Journal got posted and

the Journal Created in Reporting

Ledger. But JGZZ_RECON_REF

field is not populated for Reporting

Ledger Journal in

GL_JE_LINES_RECON Table

Cause: The issue was with the logic used

in the code for Package

lines_recon_pkg.insert_alc_recon_lines

which did not handle references for the

Reporting Ledger. The Issue was

identified with code of the Program over

Bug Number 16890927.

Solution : Apply Patch 16890927

The Patch would Upgrade the file versions

as follows:

For R12.0:

glirclnb.pls 120.9.12000000.5

glirclns.pls 120.4.12000000.1

For R12.1

glirclnb.pls 120.9.12010000.5

glirclns.pls 120.4.12010000.1

3

In Enter Journals form the

Reconciliation Reference field appears

grayed out and is not possible to

update. You need to enter a reference

in order to use Automatic

Reconciliation functionality in GL.

You already have the following Setup:

- account code value with appropriate

segment qualifier (Reconciliation set to

Yes)

- enabled the code combination

Cause: The issue is due to Ledger setup -

Journal Reconciliation is not enabled.

Solution :

1. Navigate to Accounting Setup Manager

2. Query your Ledger

3. Select the Enable Journal

Reconciliation checkbox for the ledger in

the Ledger Options page.


SNo. Issue Possible Solution

4.

When trying to reconcile the data for

an account, the tax line automatically

generated in journal entry for

reconcilable account does not appear in

the screen GLXRCENT. The line entered

manually for the same account appears

successfully into the reconciliation

form.

Cause :

The cause was identified as a code issue

over Bug:13350390 - R12 GLXRCENT :

Tax Line Automatically Generated in

Journal Entry Cannot Appear

Solution :

Apply Patch:13350390

The Patch would Upgrade the file versions

as follows:

For R12.0:

glujetxb.pls 120.6.12000000.3

glujetxs.pls 120.4.12000000.1

For R12.1:

glujetxb.pls 120.7.12010000.2

glujetxs.pls 120.4.12010000.1

5

Reconciliation form returns

Encumbrance and Budget Journal lines

as well for Reconciliation.

Cause :

The cause was identified as a code issue

over Bug 8980612 : General Ledger

Reconciliation Showing Encumbrance and

Budget Entries

Solution :

Apply Patch 8980612. The Patch would

Upgrade the file versions as follows:

For R12.0:

glgvwreg.ldt 120.16.12000000.12

glgvw.odf 120.24.12000000.12

For R12.1:

glgvwreg.ldt 120.16.12010000.13

glgvw.odf 120.24.12010000.14

Run following query to find out the

reconciliations where

encumbrance/budget journal was

reconciled along with actual journals :

select rec.*

from gl_je_lines_recon rec

where rec.ledger_id = &ledger_id

and rec.jgzz_recon_status = 'R'

and rec.jgzz_recon_date is not null

and exists

(select 1 from gl_je_headers h

where h.ledger_id = rec.ledger_id

and h.je_header_id = rec.je_header_id

and h.actual_flag in ( 'E' , 'B' ));


Thank You!!!

Date post:	17-Feb-2016
Category:	Documents
Upload:	rai-prashant-kumar-rai
View:	54 times
Download:	18 times

Journal Line Reconciliation Whitepaper- GL

Documents