Search Results set_receipt_gl_date




Overview

ARP_VIEW_CONSTANTS is a PL/SQL package in the Oracle E-Business Suite Receivables (AR) module, owned by the APPS schema. Its role is to act as a session-level repository of user-entered values and calculation results that must persist across multiple interactions within an Oracle Forms session. Rather than re-querying or re-deriving critical values on each call, the package relies on paired setter and getter procedures and functions to store and retrieve a controlled set of attributes, including customer context, application dates, receipt attributes, sales order references, and status flags.

The unit belongs to the API classification "OTHER" in the ETRM metadata for Release 12.2.2. The source header (ARCUVIES.pls, version 120.3, dated 2005/11/14) indicates the package has remained stable across the 11i and R12 code lines. It is referenced by 9 other packages, underscoring its role as a shared global state holder for the AutoReceipts and related views rather than a standalone business API.

The user search term "set_ps_selected_in_batch" corresponds to the package's setter for the Payment/Receipt batch-selection flag, one of several state variables maintained by this unit.

Key Procedures and Functions

Tables Accessed

The package reads from AR_SYSTEM_PARAMETERS, the Receivables system options table, to obtain defaulting and validation parameters (such as default GL date rules) that drive the GL date functions. It also references GL_PERIOD_STATUSES to determine whether a given accounting period is open, closed, or otherwise valid for a proposed GL date during validation. Access is via APPS synonyms. Write operations to business tables are not documented; the package primarily governs session state and validation logic.

Usage Notes

ARP_VIEW_CONSTANTS is typically invoked from Oracle Forms windows in the Receivables module, particularly the AutoReceipts, cash application, and receipt views where user selections must persist across block navigation. It is also referenced by nine other packages that require access to the same session values. The setter/getter design makes it unsuitable for concurrent request execution, since state is held in package-level variables scoped to a single database session. Custom extensions that require the same defaulting or validation behavior should call IS_GL_DATE_VALID, MASS_APPS_DEFAULT_GL_DATE, and GET_DEFAULT_GL_DATE directly rather than reimplementing period logic. Because the package is not a published API, changes to its header or behavior across patches should be monitored; however, the version history suggests long-term stability.