Case1: Dual Posting of Journals

1. Dual Posting from Journal Enter Form:

Cause: Application, in certain cases, allowed Journals Entry form to post a Journal that was already selected for posting, causing incorrect balances.

Solution :

a) Please check the existing version of the file : GLXJEENT.fmb
One could use the command as follows to retrieve the version:

strings -a $GL_TOP/forms/US/GLXJEENT*|grep -i '$header'

b) Please apply the following Patch

For 12.0.x: Patch 19886857:R12.GL.A (delivers file GLXJEENT.fmb with version 120.81.12000000.67)
For 12.1.x: Patch 19886857:R12.GL.B (delivers file GLXJEENT.fmb with version 120.83.12010000.49)
For 12.2.x: Patch 19886857:R12.GL.C (delivers file GLXJEENT.fmb with version 120.121.12020000.20)

c) Reconfirm the new file version as above to confirm succesful application of patch

2. Dual Posting of Consolidation Journals

Cause: Consolidation Transfer done with Auto Post option did not update the Request_Id for the posted Journals and hence, AutoPost Program also picked up these journals for posting, causing doubled balances

Solution :

a) Please check the existing version of the file : glijeapb.pls
One could use the command as follows to retrieve the version:

strings -a $GL_TOP/patch/115/sql/glijeapb.pls|grep -i '$header'

b) Please apply the following Patch

For 12.0.x: Patch 18781670:R12.GL.A (delivers source file glijeapb.pls with version 120.6.12000000.2)
For 12.1.x: Patch 18781670:R12.GL.B (delivers source file glijeapb.pls with version 120.6.12010000.2)
For 12.2.x: Patch 18781670:R12.GL.C (delivers source file glijeapb.pls with version 120.6.12020000.2)

c) Reconfirm the new file version as above to confirm succesful application of patch.

3. Dual Posting of Mass Allocation Journals

Cause: Mass Allocation journals generated by AutoAllocation get double posted at times, if other user selects them for posting immediately after the creation and before posting.This was again caused becase of Request_Id not being populated in the table GL_JE_HEADERS, when the journal was posted once already

Solution :

a) Please check the existing version of the file : glwfalcb.pls
One could use the command as follows to retrieve the version:

strings -a $GL_TOP/patch/115/sql/glwfalcb.pls|grep -i '$header'

b) Please apply the following Patch

For 12.0.x: Patch 16769996:R12.GL.A (delivers file glwfalcb.pls version 120.15.12000000.3)
For 12.1.x: Patch 16769996:R12.GL.B (delivers file glwfalcb.pls version 120.15.12010000.3)
For 12.2.x: Patch 16769996:R12.GL.C (delivers file glwfalcb.pls version 120.16.12020000.2)

c) Reconfirm the new file version as above to confirm succesful application of patch

Case2 : Program Incompatibilities

GL Balance Corruption can occur due to program incompatibilities. Please ensure the Program Incompatibilities are set rightly.

Please refer the following Notes for details:

R12 : Please refer Note 1070410.1  How to Prevent Possible General Ledger Balances Corruption Due to Incorrect Program Incompatibilities in Release 12
R11i : Please refer Note 300933.1   How to Prevent Possible General Ledger Balances Corruption Due to Incorrect Program Incompatibilities in 11.5

Case3: Deletion of Unposted Reversed journal in Primary, deletes related Reversal in secondary even is Its Posted, causing Balance Corruption.

a) Please check the existing version of the file : glijebab.pls
One could use the command as follows to retrieve the version:

strings -a $GL_TOP/patch/115/sql/glijebab.pls|grep -i '$header'

b) Please apply the following Patch

For 12.0.x: Patch 13867844:R12.GL.A (delivers file glijebab.pls version 120.16.12000000.5 )
For 12.1.x: Patch 13867844:R12.GL.B  (delivers file glijebab.pls version 120.17.12010000.4 )
For 12.2.x: Patch 13867844:R12.GL.C  (delivers file glijebab.pls version 120.17.12020000.4 )

c) Reconfirm the new file version as above to confirm succesful application of patch

Case4: Incomplete Custom Codes:

It is learnt that in some cases, users submit posting program(GLPPOS) using a custom program/custom code. While this is not supported normally, it is suggested to please ensure that Column REQUEST_ID of Table GL_JE_BATCHES is updated with the right value as soon as the Posting program is submitted.
Below sample code shows on how to update REQUEST_ID column of GL_JE_BATCHES table after posting program is submitted.

Case5: Suggestions to follow before Opening First Period of a New Year:

Please follow below steps before opening a first period of a new year to avoid corruption in beginning balances.

1. Ensure there are no misclassified accounts before opening first period of new year.
Refer Note 259210.1 to identify misclassified accounts and correct them.

2. Ensure there are no code combinations with account types other than Asset('A),Liability('L'), Revenue('R', Expense('E') & Owner's Equity('O').
Use below query to check if there are other account types and if there are any raise SR with Oracle support to correct them.

Case 6: Open Period Program Creates Duplicates in R11i

 In Version 11i of the application, Open Period Program inserted duplicate rows in GL_BALANCES table, while opening the period, in certain cases due to a code issue. To prevent this

Apply Patch 10182098 .
The patch delivers file glooap.opc with version 115.13.115103.2.

Use fiollowing command to check the version of glooap.opc: strings -a $GL_TOP/bin/GLOOAP|grep -i '$header'|grep -i glooap