Search Results bad_start




Overview
Explore in AI Chat

Overview

APPS.GL_CALENDAR_PKG is a server-side PL/SQL utility package that provides helper routines for working with Oracle General Ledger accounting calendars. It is declared with AUTHID CURRENT_USER, meaning that its contained SQL statements execute under the privilege context of the invoking user rather than the package owner, which is the standard convention for shared Oracle Applications utility packages that must respect the caller's security profile.

The package header, sourced from the original glustcls.pls script, explicitly documents its purpose as providing "various utilities for working with GL calendars" that "are available for use by other teams within Oracle Applications." A critical governance note accompanies this: the utilities are not available for customization purposes. In the 12.1.1 and 12.2.2 release lines, GL_CALENDAR_PKG therefore functions as an internal shared-services layer that other Oracle-developed packages call rather than as a supported extension point for customer code.

Key Procedures and Functions

ETRM documents one public routine in this package:

  • GET_NUM_PERIODS_IN_DATE_RANGE — Accepts a calendar name, a period type, a start date, and an end date, and determines the number of non-adjustment periods within that calendar and period type whose date spans fall inside the supplied range. It returns the computed count through a num_periods output parameter and a status indicator through return_code. The routine defines a fixed set of return-code constants: SUCCESS, BAD_START (the start date belongs to no non-adjustment period), BAD_END (the end date belongs to no non-adjustment period), and UNMAPPED_DAY.

The check_missing parameter is central to this routine's behavior. When check_missing is passed as true, the procedure does not merely resolve the two boundary dates; it walks every individual date in the range and verifies that each one maps to a non-adjustment period. If any date in the range fails that test, the procedure raises the UNMAPPED_DAY return code and reports the specific offending date back to the caller through an unmapped_date output parameter. This makes check_missing the switch between a fast, boundary-only calculation and an exhaustive gap-detection scan.

Tables Accessed

Two GL tables are referenced through APPS synonyms:

  • GL_PERIODS — the definition table for calendar periods, including period type, start and end dates, and the adjustment-period flag. This is the source of the period enumeration and of the non-adjustment filtering logic.
  • GL_DATE_PERIOD_MAP — the date-to-period association table used to resolve whether an individual date is owned by a period. This table is what supports the date-by-date scan activated by check_missing and is what allows the routine to detect unmapped days.

Usage Notes

Because this package is classified as OTHER rather than as a public API, it is intended for internal consumption. ETRM records that it is referenced by two other packages, confirming its role as a dependent utility library. It is typically invoked from PL/SQL — either from other Oracle Applications packages, from concurrent program logic, or from custom code that must establish how many GL periods a given date range spans before performing period-based validation, proration, or transfer of balances.

When calling GET_NUM_PERIODS_IN_DATE_RANGE, developers should always inspect the returned return_code before consuming num_periods, since a BAD_START, BAD_END, or UNMAPPED_DAY result indicates the count is not reliable. Enabling check_missing is advisable when data quality across the entire range matters, and should be disabled when only the boundary conditions require confirmation, because the exhaustive scan against GL_DATE_PERIOD_MAP is materially more expensive. Although the package is technically invokable from custom code, Oracle's documented position is that it is not supported for customization, so production extensions should treat its signature and behavior as subject to change.