Search Results ar_refunds_grp




Overview
Explore in AI Chat

Overview

AR_REFUNDS_GRP is a public PL/SQL group package in the Oracle E-Business Suite Receivables (AR) module, owned by the APPS schema. It is classified in the ETRM as a GRP (group) package, a designation reserved for packages that encapsulate a set of related procedures without exposing a formal public API surface for external development. The header block, sourced from ARXGREFS.pls (version 120.0, dated 10-JAN-2006), identifies the package name through the constant G_PKG_NAME.

The package addresses refund processing, specifically the situation in which a refund to a customer that originates in Oracle Payables is cancelled outside of Receivables. Because payables-driven refunds are represented within Receivables as receipts or credit memos, cancellation must be communicated back so that the previously applied amounts are released. AR_REFUNDS_GRP provides the subscription mechanism that Receivables exposes for this purpose, allowing the Payables refund workflow to notify Receivables of a cancellation event and trigger the appropriate unapplication activity. Its behavior is limited and highly targeted: it is an event handler rather than a general-purpose refunds API.

The package does not appear in the dependency tree of other documented packages, and ETRM records zero other packages referencing it. This is consistent with a subscriber callback design, where invocation arrives through the Oracle Workflow Business Event System rather than through direct package-to-package calls.

Key Procedures and Functions

The ETRM documents a single public procedure for this package.

  • SUBSCRIBETO_INVOICE_EVENT — The sole documented entry point. Per the embedded header comment, this procedure calls activity_unapplication for a receipt or a credit memo, and is explicitly described as being for use by Payables when a payment request is cancelled outside of AR. It accepts an event type and an invoice identifier as inputs and returns the standard concurrent-style status trio: return status, message count, and message data. The procedure is declared as a subscription handler, meaning it is registered against a business event and invoked by the event system when that event is raised.

No additional public functions or procedures are declared. The package body is not represented in the provided documentation except through the header comments, and no overloads, private helpers, or initialization blocks are documented.

Tables Accessed

ETRM lists four base tables referenced through APPS synonyms. These are consistent with the documented unapplication behavior.

  • AR_CASH_RECEIPTS — The receipt header table. Read to identify the receipt associated with the refund being cancelled so that its application records can be reversed.
  • AR_RECEIVABLE_APPLICATIONS — The core application table that links receipts and credit memos to transactions. The unapplication logic updates or removes rows here to release the applied amount.
  • AR_RECEIVABLE_APPLICATIONS_ALL — The org-stripped (ALL) view or table variant of the applications table, used so that the operation resolves correctly across operating units through the multi-org access mechanism.
  • RA_CUSTOMER_TRX — The transaction header table, consulted to identify the invoice or credit memo against which the receipt was applied.

Writes are expected against the applications tables; the receipts and transaction tables are treated as read-only lookup sources during the unapplication.

Usage Notes

AR_REFUNDS_GRP is invoked indirectly. Its documented purpose is to serve as the Receivables-side endpoint for a Payables refund cancellation, so the normal calling path is a business event subscription rather than a form or a concurrent program. When a payment request is cancelled in Payables, the event is raised with the relevant invoice identifier and event type, and SUBSCRIBETO_INVOICE_EVENT performs the unapplication against the corresponding receipt or credit memo.

Because the package is a GRP and exposes only a subscription handler, it should not be treated as a supported API for custom development in either 12.1.1 or 12.2.2. Custom code that needs to unapply receipts or credit memos should use the documented Receivables APIs (such as AR_RECEIPT_API_PUB) instead of calling this package directly. Implementers diagnosing refund or cancellation issues should verify that the relevant event subscription is active and that the return status and message data returned by the procedure are captured, since those outputs carry the outcome of the unapplication attempt. The package header carries a "noship" designation from its original source control, indicating it was not shipped as a standalone patchable file but delivered as part of the AR code line; this does not affect its availability at runtime but does mean it is not independently versioned for customer modification.