Search Results arrx_c_unapp




Overview
Explore in AI Chat

Overview

ARRX_C_UNAPP is a PL/SQL package body owned by the APPS schema in Oracle E-Business Suite, with a status of VALID under both 12.1.1 and 12.2.2. The "ARRX" prefix identifies this object as part of the Oracle Receivables (AR) product family. The Receivables "RX" module designation relates to the Receivables eBTax / tax reporting and reconciliation infrastructure, where the RX series of packages supports unapplied receipt analysis and the reconciliation of receipt applications against system parameters and tax reporting utilities. The "_C_UNAPP" suffix indicates a "C" (customizable or client-layer) variant of unapplied receipt processing logic.

ARRX_C_UNAPP addresses the "unapplied" state of receipts — funds received from customers that have not yet been applied to a specific transaction or invoice. The package provides technical infrastructure for registering and tracking unapplied receipt records, working in conjunction with its sibling package ARRX_RC_UNAPP (referenced in the dependency graph), which supplies the core reconciliation logic. ARRX_C_UNAPP acts as the caller/wrapper layer that surfaces that logic for external invocation.

Key Procedures and Functions

The ETRM metadata documents one procedure for this package body:

  • AR_UNAPP_REC_REGISTER — The documented entry point for registering an unapplied receipt record. In the Receivables reconciliation framework, this procedure is responsible for identifying receipts that sit in an unapplied state and enrolling them (or their reconciliation status) into the relevant tracking structures consumed by downstream tax reporting and reconciliation processes. Parameter lists are not documented in the metadata, and accordingly are not enumerated here. Its classification as OTHER indicates it is not a formal public API, but rather an internal utility invoked by the surrounding RX reconciliation framework.

This single documented procedure conforms to the naming convention of the RX family: AR_UNAPP_REC_REGISTER combines the product prefix (AR), the functional subject (UNAPP), and the action (REC_REGISTER), consistent with registration semantics for unapplied receipt records.

Tables Accessed

The metadata records one table referenced through APPS synonyms:

  • AR_SYSTEM_PARAMETERS_ALL — The Receivables system options table. ARRX_C_UNAPP reads this table to retrieve the operating configuration of the Receivables installation, including settings that govern receipt processing, tax and reconciliation behavior, and organizational context. These parameters determine whether and how unapplied receipt registration proceeds for a given operating unit.

Beyond the documented table dependency, the package references several supporting packages rather than tables directly: FA_RX_UTIL_PKG (the shared RX utility library), FND_DATE (date conversion), FND_GLOBAL (session and context initialization such as user and responsibility), and MO_GLOBAL (multi-org access control), plus the SYS.STANDARD package. Collectively these indicate that AR_UNAPP_REC_REGISTER establishes multi-org context and derives session identity before performing its registration work.

Usage Notes

ARRX_C_UNAPP is not referenced by any other database object, per the ETRM dependency report. This is an important characteristic: the package is not part of a call chain initiated by another stored package. Instead, it is invoked either by an Oracle Receivables form or by a concurrent program in the Receivables reconciliation and tax reporting flow, where unapplied receipts must be periodically identified and registered.

The presence of MO_GLOBAL and FND_GLOBAL calls indicates the package expects to run within a properly initialized EBS session — either an OAF/Forms session or a concurrent manager session that sets org context. When reading AR_SYSTEM_PARAMETERS_ALL, the caller must ensure the correct ORG_ID is initialized, otherwise registration will apply to an unintended operating unit.

Because ARRX_C_UNAPP is not referenced programmatically by other objects, customizations should not assume it is a stable extension point. Rather, it should be treated as internal infrastructure whose behavior is driven by the Receivables system parameters and the shared RX utility package FA_RX_UTIL_PKG.