Purpose To help diagnose and resolve Error 7 in journal posting.
Scope and Application
Novice
Investigating Journal posting error7 Description:
The Posting Execution report should give you some information showing what the error 7 is caused by for all journals. A bug introduced in patch
2805480 glperp.lpc 115.5 prevented this report from showing this information. This was fixed in Bug 3473512 glperp.lpc 115.7.
When you post a journal and get error 7 it usually means that one or many journal lines are pointing to a combination that is no longer valid. The message is as follows:
'Error7 Showing invalid journal entry lines or no journal entry lines' It will also occur if the journal header is missing but that rarely happens. When you try to review the batch it will come up with an error message saying
"Posting is not allowed for this account."
You have checked the posting report and no failures due to cross validation rules etc are mentioned.
Check that the account in the code combination Allows posting. 1. Navigate to the Setup > financial > Flexfield > Key > Segments 2. Query back the hierarchy
3. Click on unfreeze.
4. Navigate to the Setup > financial > Flexfield > Key > Values in the GL superuser responsibility.
5. Query back the hierarchy and the account segment.
6. Query back the value for the account segment that it is failing on. 7. Tab to the qualifier field and set Allow Posting to yes.
8.Save your work.
9.Go back to the flexfields hierarchy screen as step 1 and refreeze the hierarchy.
If it is not that.
Note that pressing History gives no further information. If you review the
journal it has one or more code combinations blanked out in 10.7 it is not blanked
in R11 which makes the whole thing easier. If you check the report that is with
the posting run time log in the SRS screen it should tell you where the error lies.
It is sometimes the case that the journal cannot be changed because the source is
frozen or funds have been reserved so the journal cannot be changed.
Solutions to this are given later.
While we can use the Help Tools Examine function to confirm what the problem is and find the JE_BATCH_ID we need to go to sql to solve the problem. In R11 you can use Help > Tools > Examine on the header line and change the field to Status. A full list of Status codes is given in the R11 Technical
Reference Manual against the relevant tables.
Using Help > Tools > Examine with a Block of 'Batch' and a Field of 'Frozen_source_flag', if it is 'N' you should be able to edit the journal.
Change the field to status and you will see it is Z which is expected for Error7. Get the values for the je_batch_id and budgetary_control_status for later.
Unless the customer knows what the combination is or knows what combinations were recently changed we need to use sql to investigate further.
Investigation Perform the following sql using sqlplus logged in as GL/GLpassword or as APPS/ APPSpassword.
1. This will give us the batch header to use in the next sql and prove the status of the batch (V for error7). The Budgetary_control_status lets us know whether funds have been reserved, P means they have (see Budgetary control' below). The
Frozen_source_flag shows if the source is frozen, N means it is not (see 'Frozen Source' below)
select je_batch_id, name, status, budgetary_control_status,
frozen_source_flag from gl_je_batches where name = '&BATCH NAME' and default_period_name = '&PERIOD_NAME';
example of expected result : JE_BATCH_ID NAME S B F
5643 VPN For Release 11i change the from to gl_je_batches_v instead of gl_je_batches.
Here the Frozen _source_flag is 'N' but if it were 'Y' you would not be able to edit the journal.
Frozen Source:
If you need to change the journal and it has the Frozen_source Flag set then you need to navigate to Setup > Journal > Source form. Query back the source and untick the freeze journal box and save your work. Remember this is set to keep the source and General ledger the same so a changed combination here will not be reflected in the source data eg payables invoice.
Budgetary Control:
If the funds have been reserved for the journal and you need to change the journal just use the More Actions 'Unreserve Funds' button. If this is greyed out it is likely that the funds are reserved in the sub ledger and cannot be unreserved here. I know of no solution to this. You will need to correct the problem in the code combination. 2. The script in 1. gave us the header_id and batch status. We now need the Header status details of which are given in the Technical Reference manual against the GL_JE_HEADERS table. These codes describe what is wrong with the code combination ie C is 'detail posting not allowed'. set serveroutput on set lines 110 set pages 1000
select je_header_id,name HEADER NAME, status STATUS from gl_je_headers where je_batch_id = &batch_id <from 1 above>;
example of expected result :
JE_HEADER_ID HEADER NAME STATUS 5444 Cash only C
3. The following code uses the je_header_id found in 2 above. It will return the code combination id, line number, start date, end date and the segment values of the code combination. You will need to change the segment columns to match the ones in your accounting flexfield. In the application navigate to Financial > Flexfields > Key > Segments choose Oracle General ledger Accounting Flexfield choose your
structure for the set of books you are working on. Press the segments button and look at the column labelled 'Column' replace all the c.segment1(to 8) values in this script with the ones given here.
The code returns the code combinations that are not valid. You can use the Header status to identify what is wrong with the code combination
e.g. Status J "Code combination not yet effective (date)" relates to the
start_date_active being more recent than the effective date of the journal being posted (not the system date).
The solution is to remove the start date for that code or use a different code. The sql also returns codes that are disabled, or do not have the posting flag set or are summary accounts.
select distinct(a.code_combination_id), a.je_line_num line, c.start_date_active, c.end_date_active, c.segment1,c.segment2,c.segment3,c.segment4,c.segment5, c.segment6,c.segment7,c.segment8
from gl_je_lines a, Gl_code_combinations c where a.je_header_id = &header_id and a.code_combination_id = c.code_combination_id and (c.start_date_active is not null or c.end_date_active is not null
or c.summary_flag != 'N'
or c.detail_posting_allowed_flag != 'Y' or c.enabled_flag != 'Y')
Expected result:
Enter value for batch_id: 5444 old 6: where a.je_header_id = &batch_id new 6: where a.je_header_id = 5444
CODE_COMBINATION_ID LINE START_DAT END_DATE_ SEGMENT1
SEGMENT2 SEGMENT3 SEGMENT4
SEGMENT5 SEGMENT6 SEGMENT7
SEGMENT8
1063 1 01
100 1400 000
Post the Journal
The above code should have identified the journal line and the code combination that is in error. To get the journal to post you now need to amend the code combination in the form so it can be posted to. You may need to unfreeze the source at Setup > Journal > Source
Then using the system administrators responsibility navigate to profile > system screen and mark user or responsibility and query back the profile
'Journals: Allow journal posting from the Journal entry screen'.
Make sure the user or responsibility you want to use in GL is set to 'YES'. Change it if necessary.
Change responsibility back to GL and post the journal that is in error from the enter journals > review journals screen using 'More Actions'. Journal Approval:
A journal cannot be changed while being approved. Once approved in later versions you can use More actions unnapprove in the journal edit screen.
RELATED DOCUMENTS