Search Results initialize_period_statuses

Overview

APPS.GL_PERIOD_STATUSES_PKG is a core General Ledger maintenance package in Oracle E-Business Suite, present in both release 12.1.1 and 12.2.2. Its stated purpose, as recorded in the package header, is to contain the validation and insertion routines for the GL_PERIOD_STATUSES table. The package therefore provides the low-level data access layer through which period status rows are created, queried, updated, and removed for every accounting ledger defined in the application.

Because GL_PERIOD_STATUSES governs whether a period is Open, Closed, Never Opened, or Permanently Closed for a given ledger and period type, this package sits beneath a wide range of period-control activities: opening and closing periods, defaulting the correct accounting period during journal entry, advancing to the next open period, and populating period status rows when a new ledger or calendar is defined. Its API classification is recorded as OTHER, meaning it is an internal support package rather than a formally published business API, though many of its routines are still invoked directly by forms and by other packages.

Key Procedures and Functions

The documented metadata lists twenty-four procedures and functions. The most commonly referenced include the following.

• INITIALIZE_PERIOD_STATUSES — the routine most often sought when this package is searched. It performs the bulk initialization of period status rows, establishing the baseline set of periods for a ledger or ledger set so that subsequent open/close operations have rows to act upon.
• DEFAULT_ACTUAL_PERIOD — a function that determines the default period for actual (non-encumbrance) batches within a given ledger, based on the current access set.
• GET_NEXT_PERIOD — returns the next open period following a supplied period, used to move a user or batch forward in the accounting calendar.
• INSERT_LED_PS — inserts GL_PERIOD_STATUSES records for a newly created ledger, taking the ledger, calendar name, and period type.
• INSERT_PS_API and INSERT_PERIOD — insertion entry points for period status rows.
• UPDATE_PERIOD and DELETE_PERIOD — modify or remove existing period status records.
• SELECT_ROW and SELECT_COLUMNS — retrieval routines; SELECT_COLUMNS additionally returns the period number and year.
• LOCK_ROW, INSERT_ROW, UPDATE_ROW, UPDATE_ROW_DFF, and DELETE_ROW — row-level locking and DML helpers, with UPDATE_ROW_DFF handling descriptive flexfield attribute updates.
• SELECT_ENCUMBRANCE_PERIODS — returns encumbrance-related periods for a ledger.
• SELECT_YEAR_1ST_PERIOD and SELECT_PRIOR_YEAR_1ST_PERIOD — identify the first period of the current and prior fiscal year.
• GET_EXTENDED_QUARTER and GET_EXTENDED_YEAR — derive extended quarter and year values used in period calculations.

Tables Accessed

The package operates primarily against GL_PERIOD_STATUSES, which stores the open/closed state of each period per ledger and period type; this is the table the insert, update, delete, and lock routines maintain. Supporting reference data is read from GL_LEDGERS, GL_PERIODS, GL_PERIOD_TYPES, and GL_APPLICATION_GROUPS to resolve valid ledgers, calendars, and period definitions. GL_DATE_PERIOD_MAP is used to translate between accounting dates and their corresponding periods, supporting the default-period and next-period logic. FND_PRODUCT_INSTALLATIONS is consulted for installation-level information, a common pattern in seeded Oracle packages.

Usage Notes

The package is invoked from General Ledger setup and period-close forms, from concurrent programs that open or close periods, and internally by other packages — the metadata records it as referenced by twelve other packages. Typical call sites include ledger definition, where INSERT_LED_PS and INITIALIZE_PERIOD_STATUSES seed period rows, and journal entry, where DEFAULT_ACTUAL_PERIOD and GET_NEXT_PERIOD supply default period values. Because the package is not a formally published API, custom code should use it cautiously and prefer supported APIs such as GL_PERIOD_STATUSES_PKG only where no higher-level interface exists. Direct DML against GL_PERIOD_STATUSES should be avoided in favour of these routines, which enforce the package's validation logic. Any customization must be re-verified on upgrade, as the header shows the package has been patched repeatedly across releases.