Search Results get_next_period




Overview
Explore in AI Chat

Overview

The APPS.GL_RECURRING_VALID_PERIODS_PKG is a General Ledger (GL) server-side PL/SQL package that supports the Oracle E-Business Suite recurring journal entry process. Its stated purpose, per the package header, is "to retrieve the information from the gl_recurring_valid_periods_v view." Recurring journal batches are templates that generate journal entries on a scheduled basis across successive accounting periods. Before a batch can be submitted for a given period, the application must determine which accounting periods are genuinely open and thus eligible for entry generation. This package encapsulates that determination logic, insulating callers from the underlying view definition and any period-status validation rules.

The package carries the internal revision marker $Header: glirjvps.pls 120.4 2005/05/05 01:20:45 kvora ship $, indicating it is a long-standing, shipped component of the GL module. It was originally created on 07/10/96 by W Ho, and its API classification within the ETRM repository is OTHER.

Key Procedures and Functions

The package exposes a single documented procedure:

  • GET_NEXT_PERIOD — Retrieves the next open accounting period for a given recurring batch and returns it through the x_next_period output parameter. Its documented arguments are x_ledger_id (the ledger identifier), x_recurring_batch_id (the recurring batch identifier), x_period (the last executed period), and x_next_period (the next open period, declared as an IN OUT NOCOPY VARCHAR2). The procedure's stated purpose is "to get the next open period and return it in x_next_period." Internally, it queries the valid-periods view using the ledger and batch context, treating the supplied last-executed period as the starting point for the search. The NOCOPY hint on the IN OUT parameter avoids a copy-back on this VARCHAR2 value, which is a minor performance consideration for repeated invocations.

No other procedures or functions are documented for this package, and no additional overloading is exposed in the specification.

Tables Accessed

The ETRM metadata records no direct table references via APPS synonyms; the package is documented as operating against the GL_RECURRING_VALID_PERIODS_V view. Because it is a view rather than a base table, the package performs read-only access. The view supplies the set of periods that are valid and open for recurring journal processing, filtered by ledger and recurring batch. By centralizing this query inside the package, Oracle ensures that all consumers obtain a consistent definition of "next open period," including any period-status or calendar rules embedded in the view.

Usage Notes

The documented example shows the procedure being invoked from a form context:

  • gl_recurring_valid_periods_pkg.get_next_period(:block.ledger_id, :block.recurring_batch_id, :block.period, :block.next_period);

This indicates the package is typically called from the Recurring Journal Batches form to populate the next period field as the user works with a batch definition. The ETRM metadata records zero packages referencing this package, meaning it is not a widely reused internal dependency; it is intended primarily for the form and any custom extensions that need to advance a recurring batch to an eligible period. In Oracle EBS 12.1.1 and 12.2.2, custom code should invoke the procedure within the APPS schema context (or via a synonym) and must handle the case where no open period remains, since the VARCHAR2 output is the only channel for the result. Standard practice is to hard-code against the documented signature and avoid depending on the underlying view directly, preserving upgrade safety.