Document 1061798.1 https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-stat...

Copyright (c) 2022, Oracle. All rights reserved. Oracle Confidential.

R12: Calendar Changes that can be Supported in General Ledger (GL) (Doc ID 1061798.1)

APPLIES TO:

Oracle General Ledger - Version 12.1.3 and later

Information in this document applies to any platform.
Form:GLCALSC.FMB - GL Calendars
Form:GLXSTCAL.FMB - Calendar
Older note 1049792.6 is covered in this note. It has been Archived

PURPOSE

This Bulletin describes how to find the cause of general ledgers calendar form preventing updates to a calendar. It uses
similar sql to the application to highlight the cause of 'APP-SQLGL-08044: You can only modify periods which have never
been used'. Where there is nothing we can do to allow changes to be made it gives the reasons that support is unable to
release fixes for many calendar changes and discusses the limitations of the calendar change solutions that are available.
This note addresses issue in R12 although similar issues exist in 11i these are addressed in Note.357269.1 11i Calendar
Changes That Can be supported in General Ledger (GL).

SCOPE

This is limited to the supported options in calendar change that can be supported by Oracle Development and Oracle
support. This does not cover offerings from Oracle Consultancy who can offer their own support. You may get consultancy
to make changes for you but each solution would have to be tailored to fit the setup of an instance and thorough testing
undertaken. Oracle support does not have the capacity for this activity. Consultancy can also offer support for your changes
when made by them.

In R12 as in 11i before it the General Ledger calendar tables are used by other Oracle Applications as the basis for their
own calendar information. In some cases the calendar is copied to other tables in it's entirety for use by other ledgers.
Transactions posted in GL and elsewhere may record both the date and the period it relates to based on the GL calendar
tables. Also it is possible for customisations to use data from the calendar tables as this is known as the central point for
calendar related data.

DETAILS

Summary

The calendar update form ( GLXSTCAL ) has a number of checks in place to prevent the use of a calendar when known
situations exist that would have a potential for data corruption. Attempting to change the calendar once its in use bypasses
these checks and can cause data corruption. The sql below can be used to establish which check has prevented the
calendar change and caused the error message:

APP-SQLGL-08044: You can only modify periods which have never been used.

If you can remove the obstacle that prevents the form from changing the calendar without compromising your data then
you may be able to make some types of change through the form.

You cannot change a calendar period through the calendar form if:

1 of 7 11/2/2022, 1:38 PM
Document 1061798.1 https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-stat...

1. The status of the period is future enterable, open, closed, or permanently closed in any ledger it is attached to.
2. It has an open budget or the period is in the current encumbrance year.
3. If the application has copied the calendar from GL to any other product or subledger, for example AGIS, Projects,
Project Intelligence (PJI), Oracle Sales Compensation, etc.

If any of the above is true, then the supported solution is to create a new ledger that uses a new calendar with the correct
period dates. You can run Consolidation to move the General Ledger data from the old to the new ledger. For step by step
instructions on the Consolidation process, refer to the Oracle General Ledger User's Guides. This may also mean that you
need to re-install your subledgers so they will use the new ledger.
See note:134362.1 General Ledger Calendar FAQ. Question 8

Reason for each Constraint

1. Status of period:

a. Future enterable - in this status journals are allowed to be created but not posted. We often see
journals raised between the close of a subledger like payables or Recievables and the close of the General
ledger. Purchasing journals may be raised for many periods in the future when prepayments are made.
Journal tables may have period details from the existing calendar.

b. Open period - in this status the balances from the previous period have been carried forward each with
the period name. Journals can be raised and posted using the existing period name and transaction or
effective dates defined at the time. Journal tables may have period details from the existing calendar.

c. Closed and permanent closed - in either status journals will have been raised using the existing period
name and transaction or effective dates defined at the time.Journal tables may have period details from the
existing calendar.

2. Budget or Encumbrance
transactions may have been posted to the balances table and may also exist in posted journals tables with
details consistent with the existing calendar. Normally the period name is important but the transaction date
is not.

3. If you have copied the calendar from GL to other product or subledger

• AGIS: the calendar used in AGIS (Advanced Global Intercompany System) will not be updated when
you update the gl calendar form. Any changes may cause corruption in the AGIS data or errors in
AGIS forms or programs.
• Projects: this calendar will not be updated when you update the gl calendar form. Any changes will
not be reflected in existing projects tables. The transactions already posted may have behaved
differently if the calendar had been as the expected change would be.
• Oracle Sales Compensation: the calendar changes in the Gl Calendar form will not be effected
there and transactions already posted will not be changed.
• Project Intelligence (PJI): the calendar changes in the Gl Calendar form will not be effected there
and transactions already posted will not be changed.

Scripts to identify the Cause of the Error:

Here are some sql statements that can be used to detect what is causing the 'APP-SQLGL-08044' message (have your
Ledger name ready to start with):

1. Get the ledger_id and period set name and all the ledgers sharing this calendar

select name, period_set_name setname,Latest_opened_period_name

latest_period,Ledger_id,name,future_enterable_periods_limit FE,
latest_encumbrance_year,
enable_budgetary_control_flag,enable_average_balances_flag,

2 of 7 11/2/2022, 1:38 PM
Document 1061798.1 https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-stat...

accounted_period_type
from gl_ledgers
where period_set_name =
(select period_set_name
from gl_ledgers
where name = '&ledger_name');

2. Get the period type for the next sql. Use the ledger_ids from above in this sql

select distinct (period_type)

from gl_period_statuses
where ledger_id = &ledger_id;

3. This sql will show if the calendar has been copied into other application. Use the period name and the numeric period
type and period set name from above.

SELECT PERIOD_NUM, PERIOD_NAME, PERIOD_YEAR,

CLOSING_STATUS STATUS, LED.ledger_ID LEDID,
APPLICATION_ID APP_ID
FROM GL_PERIOD_STATUSES PS, gl_ledgers LED
WHERE PS.APPLICATION_ID IN (
101, -- GL
275, -- PA
283, -- CN
435, -- FUN
8721, -- IPA
8405) -- IGS
AND PS.PERIOD_NAME = '&PERIOD_NAME'
AND PS.CLOSING_STATUS <> 'N'
AND
PS.ledger_ID = LED.ledger_ID+0
AND PS.PERIOD_TYPE = '&PERIOD_TYPE' AND
LED.PERIOD_SET_NAME = '&PERIOD_SET_NAME';

3a. This sql will identify if the Projects calendar table is populated for the month entered. Enter the period twice and the
period_set_name we identified above

SELECT PERIOD_NAME
FROM PA_PERIODS_ALL PRD, PA_IMPLEMENTATIONS_ALL IMP,
gl_ledgers LED
WHERE (PERIOD_NAME = '&period_name'
OR GL_PERIOD_NAME = '&period_name')
AND NVL(PRD.ORG_ID, -99) = NVL(IMP.ORG_ID, -99)
AND IMP.set_of_books_id = LED.ledger_ID
AND LED.PERIOD_SET_NAME = '&period_set_name'
AND ROWNUM =1;

This will return rows if the projects tables have the period populated for period and calendar. If so the
calendar cannot be changed unless the projects calendar can also be changed.

3b. There is a potential additional constraint from the Projects area if Project Intelligence (PJI) in use.

SELECT COUNT(*) FROM fii_time_cal_name cal, pji_time_cal_period prd

WHERE cal.period_set_name = <calendar name>
AND prd.name = 'period name'
AND prd.calendar_id = cal.calendar_id
AND ROWNUM =1;

If it is not in use this table will not exist so ignore messages saying table or view does not exist as that
means the product is not installed.

4. The calendar also cannot be changed if the period is used in budgets or Encumbrances. This SQL

3 of 7 11/2/2022, 1:38 PM
Document 1061798.1 https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-stat...

is the sql used at period end and will detect that. The result Used for encumbrance will appear if the latest encumbrance
year is the year your are trying to change or higher. The latest encumbrance year is always set as the current year when
you first create the ledger so that can cause issues:

SELECT name, accounted_period_type, 'Used for encumbrances', ledger_id

FROM
gl_ledgers LED WHERE LED.PERIOD_SET_NAME = '&period_set_name'
AND LED.LATEST_ENCUMBRANCE_YEAR >= &period_year
AND LED.ACCOUNTED_PERIOD_TYPE = '&period_type';

If you do not use Budgetary control (the enable_budgetary_control_flag is N in all ledgers associated with
this calendar - see sql 1) then you may consider changing the encumbrance year to one year earlier to allow
a change.

This sql will let you know if you have balances in the table. You may need this if rolling back encumbrances is
a possibility at your site. You will need to raise an SR if this is the only obstacle to making an essential
change.We may not be able to help with all changes for example period name changes still cant be done.

SELECT distinct B.PERIOD_NAME PERIOD, B.PERIOD_NUM NUM, B.ACTUAL_FLAG, B.ledger_ID

LEDID
FROM GL_BALANCES B, GL_PERIOD_STATUSES PS, gl_ledgers LED
WHERE B.ACTUAL_FLAG IN ('E','B')
AND B.PERIOD_NAME='&PERIOD_NAME'
AND B.ledger_ID = PS.ledger_ID
AND B.ledger_ID = LED.ledger_ID
AND PS.ledger_ID = LED.ledger_ID+0
AND LED.PERIOD_SET_NAME = '&PERIOD_SET_NAME';

This identifies the Ledger that has a budget period or encumbrance year open that has the same calendar as
the one that you are trying to change.

5. We can check that the budget calendar is not using periods from this period year with the following sql:

Enter the year from the year column on the form for the period you want to change and a ledger_id that
uses the calendar from the first sql

SELECT 'Used for budgets',

ledt.NAME ledger_name,
ledt.LEDGER_ID,
b.BUDGET_NAME,
bv.BUDGET_VERSION_ID,
bpr.PERIOD_YEAR
FROM GL_BUDGETS B,
GL_BUDGET_VERSIONS BV,
GL_BUDGET_PERIOD_RANGES BPR,
GL_LEDGERS LEDo, -- Original Ledger
GL_LEDGERS LEDt -- Other Ledgers sharing the PERIOD_SET_NAME and
ACCOUNTED_PERIOD_TYPE
WHERE BV.BUDGET_NAME = B.BUDGET_NAME
AND BV.BUDGET_TYPE = B.BUDGET_TYPE
AND BPR.BUDGET_VERSION_ID = BV.BUDGET_VERSION_ID
AND BPR.PERIOD_YEAR = &PeriodYear
AND LEDt.LEDGER_ID = B.LEDGER_ID
AND LEDo.PERIOD_SET_NAME = LEDt.PERIOD_SET_NAME
AND LEDo.ACCOUNTED_PERIOD_TYPE = LEDt.ACCOUNTED_PERIOD_TYPE
AND LEDo.LEDGER_ID = &LedgerId

The results will say Used for Budgets and list all the ledgers that are using this calendar for budgets.

6. We can establish if journals have been raised in a period say from interfaces from purchasing where order can be raised
in advance

4 of 7 11/2/2022, 1:38 PM
Document 1061798.1 https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-stat...

select distinct(period_name), count(*), status

from gl_je_headers
where period_name in
(select period_name
from gl_period_statuses
where period_year =&PERIOD_YEAR
and ledger_id = &LEDGER_ID)
group by period_name, status;

If you have data returned here we don't have a supported fix for most problems. However in some specific
cases such as the addition of the 29th of Feb there is limited choices and the addition of a day would simply
mean that the transactions already entered would have dates of 28th or earlier. In that case the obvious
choice is to go ahead with a fix.

Examples of Issues

1. A date is missing at the end of a month eg 29th Feb was missed in a leap year.

It is possible to resolve this by adding the date in gl_periods and gl_period_statuses and gl_date_period_map
please raise an SR with support for guidance on how to do this. Upload the results of sql in this note and
reference unpublished Note.95447.1 for 11i which may need some adjustment and support from
development.

If Projects is used you need to change the calendar there too. For Projects the last date in the period is used
when creating journals after the period's last date is passed but adding a date will no make a material
difference. Customers using average daily balances need to unpost/repost journals. Otherwise the average is
incorrectly calculated. Please see Note.184436.1 Effects of Not Fixing Gaps in the General Ledger Calendar
for details of what might be affected if you don't get this fixed.

For this fix you will be able to run the sql fix in gl before or after the sql update fix in projects. Projects will
need to copy the new GL calendar so that part of the projects fix should always come after you are satisfied
that the GL datafix is correct

2. Changing the start date of an active period ie. Future enterable or Open.

This is usually impossible because subledgers may have already used that date to pass transactions to GL.
The GL_DATE_PERIOD_MAP table holds the start and end dates to all periods so this would need to be
changed and if Projects or Sales Compensation is used then they would also need to be corrected. The first
date of the month is used by subledgers when creating journals before the first day of the month has arrived.
Moving this date forward will put that date in the wrong period.
The exception is where that date would otherwise be missing entirely.

3.The calendar needs to be changed from calendar to fiscal.

This can be fixed as long as the periods concerned have not been used in practice it usually means it is fixed
in the following year (for 11i see Note:102460.1 a similar note does not yet exist for r12 at this point.

See also What Are The Year Types 'Fiscal' And 'Calendar' Used For ? (Doc ID 1013624.102)

4. First accounting period is incorrect and no transactions have been processed

Please follow note:1292917.1 R12: How To Change The Ever First Accounting Open Period In The Ledger
Setup In R12

5. Changing the name of an existing period when this is not allowed in the form.

5 of 7 11/2/2022, 1:38 PM
Document 1061798.1 https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-stat...

A period name change is not allowed under any circumstances if the form will show error message,no data
fix will be attempted. The period name may not be changed even if the period has never been used. There
are hundreds of tables that use the period name from GL and they are expected to agree. It is not possible
to be totally confident that the old name has not been stored elsewhere.
Also some products must use the same period name as GL in order to import journals to GL so that would
cause problems.
In release 11i, the FA period name had to be the same, but for release 12 there is no longer this restriction.
See note:1316725.1 Can FA Period Names Differ from GL Period Names in R12?

Under no circumstances should any attempt be made to change period names for periods that have been
opened or are future enterable. This is because the period name will be on a number of tables in various
products and it is not possible to know all the places it could be stored.

6. Change a Permanently Closed Period to Closed

Sorry - no confirmed information available on this in R12

7. Changing a period number

This cannot be fixed under normal circumstances but in a live situation raise a tar and support will make our
best efforts.

8. Change the Year from fiscal to Calendar

This can be fixed as long as the periods concerned have not been used in practice it usually means it is fixed
in the following year (for 11i see Note:102460.1 a similar note does not yet exist for R12 at this point but
same steps applies)

see also R12: Is It Still Possible To Change GL Calendar From Fiscal to Calendar Year In Release12? (Doc ID
836263.1)

9. Fixing wrong quarter start dates when transactions are posted - this may be possible because quarters are not generally
used outside of GL

Raise an SR asking for help and mention Unpublished Note.316295.1 Wrong Quarter Entered Into Calender.

10. If you open too many period you can not use sql to set back to Never Opened or Future Enterable.

Sql changes of this sort are not supported. Some customers have tried to and it causes corruptions because
the gl_balances is updated when the open the period the first time and resetting the flag allows the system
to open the period a second time and doubles the balances. See Note:1069426.6 PERD - Wrong period is
opened by Open Next Period.
This is still true in R12.

11. If the calendar will not open the next period but you have defined a period for that calendar month in the calendar.

Make sure that the next period is in the same year as the previous one in the define calendar screen under
the year column. Unless you have reached the last period num in that year as per the number of periods
setup for the ledger it will not move onto the next year.

Example:
If you create a calendar for fiscal year 2009 starting in June 2009 and ending May 2010 then all the periods
for that year must have the year column in the calendar setup screen set to 2009 (fiscal year). A common
mistake is to create January period with 2010.
In case the period was never used and also no encumbrance year open or budget year open, the period
name and dates can be modified using the application form. If you cannot do this check above scripts for
possible reasons.

6 of 7 11/2/2022, 1:38 PM
Document 1061798.1 https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-stat...

Once the period has been used it cannot be modified. See also General Ledger FAQ for Calendar (Doc ID
134362.1) point 8.

There is also an example given in the General Ledger Implementation Guide :-

Enter the Year of the accounting period. This is the year in which your fiscal year
ends. For example, if your fiscal year begins in 2005 and ends in 2006, enter 2006 for
all periods in the fiscal year.

NOTE:
Oracle Consulting have a Calendar Switch solution.
Oracle SSI’s “Calendar Switch” solution, basically lets you setup a new calendar and then switch over to using the new
calendar.
So for those cases where Support cannot offer a datafix for a calendar issue, you may wish to contact consulting for
the OSSI Calendar Switch solution.

Service offerings are available at:

http://www.oracle.com/consulting/index.html?content.html

When on the URL above, click on global contacts at the top right of this page to find contact details for your country.

Feedback

To provide feedback on this note, click on the Rate this document link.

REFERENCES

NOTE:553342.1 - Is A Generic Datafix Available To Correct Period Definitions That Are Incorrect In Oracle Project
Accounting?
NOTE:1316725.1 - Can FA Period Names Differ from GL Period Names in R12?
NOTE:134362.1 - General Ledger FAQ for Calendar

NOTE:1999230.1 - R12 Users Can Correct Incorrectly Defined Projects Periods

Didn't find what you are looking for?

7 of 7 11/2/2022, 1:38 PM