Search Results display_selection_rec




Overview
Explore in AI Chat

Overview

ARP_SELECTION_CRITERIA_PKG is an Oracle Receivables (AR) PL/SQL package owned by the APPS schema that encapsulates the create, read, update, delete (CRUD) and concurrency-handling logic for the AR_SELECTION_CRITERIA entity. In Oracle EBS 12.1.1 and 12.2.2, selection criteria records define reusable sets of filter conditions — date ranges, transaction types, receipt methods, bank branches, transaction numbers, and customer classification attributes — that Receivables uses to select groups of transactions or receipts for processing. The package declares AUTHID CURRENT_USER, and the header ($Header: ARBRSELS.pls 120.4) indicates it is a long-standing, stable API surface whose last significant revision predates R12. Because it isolates the underlying table access behind a procedural interface, it allows Oracle Forms-based screens, concurrent programs, and custom extensions to manipulate selection criteria consistently while preserving row-level locking semantics and audit column maintenance.

Key Procedures and Functions

The ETRM metadata documents eleven public subprograms, each mapped to a discrete operation on the AR_SELECTION_CRITERIA record structure:

  • INSERT_P — Creates a new selection criteria row and returns the generated selection_criteria_id primary key to the caller.
  • UPDATE_P — Modifies the attribute values of an existing selection criteria row identified by its selection_criteria_id.
  • DELETE_P — Removes a selection criteria row by primary key.
  • FETCH_P — Retrieves a single AR_SELECTION_CRITERIA row into a %ROWTYPE record for a supplied primary key, performing a normal (non-blocking) read.
  • LOCK_P — Acquires a row-level lock on the selection criteria record, supporting Forms-style pessimistic locking before an update.
  • LOCK_FETCH_P — Combines locking and retrieval in one call, returning the locked row into a %ROWTYPE parameter.
  • LOCK_COMPARE_P — Implements optimistic concurrency by locking the row and comparing the caller's in-memory record against the current database values, signalling if another user has changed the data.
  • LOCK_COMPARE_COVER — Performs an equivalent lock-and-compare operation driven by individual criteria attributes (date ranges, transaction type, receipt method, bank branch, transaction number range, customer class and category codes) rather than a full row record, matching the specific "cover" columns used by the calling form.
  • SET_TO_DUMMY — Initialises a record with default or placeholder values, typically for form-level initialisation.
  • DISPLAY_SELECTION — Produces a human-readable rendering of a selection criteria record, used for diagnostic or informational display.
  • DISPLAY_SELECTION_REC — The record-based counterpart of DISPLAY_SELECTION, formatting the contents of a %ROWTYPE parameter for display or logging.

Your search term, display_selection, resolves directly to the DISPLAY_SELECTION and DISPLAY_SELECTION_REC procedures.

Tables Accessed

The package operates against AR_SELECTION_CRITERIA, the base entity table holding one row per named selection criteria definition, and its companion AR_SELECTION_CRITERIA_S, which follows the standard EBS pattern of storing translated or descriptive (name/description) columns keyed to the same primary key. DML and locking occur on AR_SELECTION_CRITERIA; the _S table supplies the human-readable name of the selection used in display routines. DUAL is referenced for scalar lookups and utility statements. All three are addressed through APPS synonyms.

Usage Notes

ARP_SELECTION_CRITERIA_PKG is invoked primarily from the Receivables selection criteria maintenance form, where LOCK_P, LOCK_FETCH_P, and LOCK_COMPARE_COVER implement the Forms optimistic and pessimistic locking contract. SET_TO_DUMMY initialises form blocks, and DISPLAY_SELECTION / DISPLAY_SELECTION_REC supply diagnostic output. Concurrent programs and custom PL/SQL typically call INSERT_P, UPDATE_P, and DELETE_P directly rather than issuing DML against AR_SELECTION_CRITERIA, ensuring the locking and validation conventions are respected. Because the package is referenced by one other documented package, extensions should treat it as a shared dependency and avoid recompiling it without impact analysis. No public API classification beyond OTHER is assigned, so Oracle does not guarantee this package as a supported external interface; customisations relying on it should be regression-tested during upgrades between 12.1.1 and 12.2.2.