Search Results pa_ar_adv_receipt




Overview
Explore in AI Chat

Overview

PA_AR_ADV_RECEIPT is an Oracle EBS Applications (APPS) PL/SQL package that governs the integration between Oracle Projects and Oracle Receivables for advance receipts applied against project agreements. Its central purpose is to move advance receipt amounts, which originate in Oracle Receivables, into the Project Billing and Project Costing flow so they can be consumed, offset, or reversed as project funding. The package is declared with AUTHID CURRENT_USER, meaning that all SQL executed on its behalf runs under the privileges of the invoking user rather than the package owner. The header information (PAGARADS.pls 120.2, dated 2006/12/20) indicates a long-standing, low-versioned component of the Projects-to-Receivables integration layer, consistent with APIs that have stabilized over multiple release cycles. In the context of EBS 12.1.1 and 12.2.2, the package remains a supporting API invoked by Projects funding and billing logic rather than an end-user-facing interface.

Key Procedures and Functions

The package exposes two documented procedures. Neither returns a value; both communicate outcome through the standard EBS API return-status convention (x_return_status, x_msg_count, x_msg_data).

  • APPLY_RECEIPT — Associates a specified Oracle Receivables receipt with a project agreement so that the receipt is treated as an advance against that agreement. In addition to the receipt identifier and an accounting date (GL date), the procedure accepts an agreement identifier and agreement number to determine the funding target. It returns or updates a payment set identifier (x_payment_set_id, declared IN OUT NOCOPY) that groups the resulting application, together with the standard message outputs. This is the entry point used when a receipt is first consumed as project advance funding.
  • UNAPPLY_RECEIPT — Reverses a prior advance receipt application. It accepts the receipt identifier together with the payment set identifier produced by APPLY_RECEIPT, and reports success or failure through the same x_return_status, x_msg_count, and x_msg_data outputs. This is the procedure a user locates when searching for "unapply_receipt": it is the documented mechanism for backing out an advance receipt that was previously applied to a project agreement, for example when a receipt is misapplied, refunded, or reclassified.

Tables Accessed

The documented table references are AR_RECEIVABLE_APPLICATIONS, its index-organized companion AR_RECEIVABLE_APPLICATIONS_S1, and DUAL.

  • AR_RECEIVABLE_APPLICATIONS — The core Receivables table holding receipt application and unapplication records. The package writes and reverses rows here to create or remove the link between the receipt, the agreement, and the payment set, which is why both procedures ultimately affect the state of this table.
  • AR_RECEIVABLE_APPLICATIONS_S1 — The secondary structure associated with the same application data, accessed to support lookups and consistency checks during apply and unapply processing.
  • DUAL — Used for single-row evaluations and PL/SQL constructs where no base table is otherwise required.

Usage Notes

PA_AR_ADV_RECEIPT is an integration utility, not a form-bound API. It is typically invoked from Oracle Projects funding and billing logic, from Receivables-side processing that must coordinate with project agreements, or from custom PL/SQL that automates application and unapplication of advance receipts. Callers must honor the standard EBS API contract: inspect x_return_status for success or error, and when errors occur, walk x_msg_count and x_msg_data through FND_MSG_PUB to retrieve the full message stack. Because the procedure uses NOCOPY for its OUT parameters, callers should not rely on the values of x_payment_set_id, x_return_status, x_msg_count, or x_msg_data being unchanged if the routine raises an unhandled exception. The package is referenced by no other documented package, so it should be treated as a leaf-level API invoked directly by application logic. Any custom usage should be validated in both 12.1.1 and 12.2.2, since the underlying Receivables application tables and their indexes are subject to release-specific differences.