Search Results arrx_rc_unapp




Overview
Explore in AI Chat

Overview

ARRX_RC_UNAPP is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It belongs to the Receivables (AR) product family and, more specifically, to the ARRX module, which supports Receivables Reconciliation and related reporting utilities. The "RC" in the package name denotes Receivables Reconciliation, while "UNAPP" refers to unapplied receipts — customer payments recorded in Receivables that have not yet been applied to a specific invoice, debit memo, or other open transaction.

The package provides the backend processing logic used to identify, extract, and reconcile unapplied receipt activity, typically in support of reconciliation reports and diagnostic functions. Its status is VALID in the ETRM repository, confirming that the compiled package and package body exist in the database and that all referenced dependencies resolve successfully. It is classified under the "OTHER" API category, meaning Oracle does not expose it as a formally documented public API; it is an internal implementation object called by other Receivables components rather than a supported integration interface.

Key Procedures and Functions

The ETRM metadata documents four callable units within ARRX_RC_UNAPP:

  • AR_UNAPP_REG — The primary (and likely public) entry point of the package, responsible for registering or initializing the unapplied-receipt reconciliation process at the SQL level. Its name combines the AR product prefix with "UNAPP" (unapplied) and "REG" (register/registration), indicating it sets up the query or result registration used by the remainder of the package.
  • BEFORE_REPORT — A report lifecycle hook executed before the reconciliation report is generated. It performs the preparatory work needed prior to report data extraction, such as initializing session context or binding data structures.
  • BIND — A binding routine used in the report generation cycle. Because the package references DBMS_SQL, BIND most likely associates values with dynamic SQL cursors, supplying parameter values that the dynamically constructed report query requires.
  • AFTER_FETCH — The post-fetch hook invoked after rows are retrieved from the report query. It performs row-level processing or formatting on each fetched record before the output is produced.

The grouping of BEFORE_REPORT, BIND, and AFTER_FETCH indicates a standard report driver pattern in which the package cooperates with a report or concurrent-program engine through well-defined callback points. No parameter lists are documented in the ETRM excerpt, and none should be assumed.

Tables Accessed

The documented table references for this package are limited to DBMS_SQL and DUAL, both resolved through APPS synonyms. DBMS_SQL is the Oracle-supplied dynamic SQL built-in package, which confirms that ARRX_RC_UNAPP builds and executes SQL statements dynamically at runtime rather than relying on static embedded SQL. DUAL, the standard one-row dictionary table, is used for simple single-row evaluations and control queries. The ETRM metadata does not list any Receivables base tables such as AR_CASH_RECEIPTS, AR_RECEIVABLE_APPLICATIONS_ALL, or AR_PAYMENT_SCHEDULES_ALL as direct dependencies; any such access would occur through dynamically constructed SQL executed via DBMS_SQL, which is why it does not appear in the static dependency list. This dynamic construct is characteristic of reconciliation utilities that must accommodate flexible criteria.

Usage Notes

ARRX_RC_UNAPP is referenced by two objects within the APPS schema: the package ARRX_C_UNAPP and the ARRX_RC_UNAPP package body itself. ARRX_C_UNAPP — where "C" conventionally denotes a report or concurrent-program-side driver in Receivables utilities — acts as the caller, invoking the procedures in ARRX_RC_UNAPP as part of the unapplied receipt reconciliation report flow. The package is therefore not typically invoked directly by end users or through standard Receivables forms; it is an internal engine invoked by a companion concurrent program or report component.

Because the package is classified as a non-public API and relies on dynamic SQL with DBMS_SQL cursors, customizations should avoid calling it directly. Instead, integrators should invoke the associated concurrent program or use supported Receivables APIs. Direct dependency on internal procedures such as AR_UNAPP_REG, BIND, or AFTER_FETCH risks breakage during patching or upgrade, particularly between 12.1.1 and 12.2.2, where internal report internals may be modified without notice. When troubleshooting reconciliation output, verify that ARRX_C_UNAPP and ARRX_RC_UNAPP are both VALID in the APPS schema, since an invalid state in either object will prevent the unapplied receipt reconciliation process from completing.