Search Results ar_om_prepay_refund_pvt




Overview
Explore in AI Chat

Overview

AR_OM_PREPAY_REFUND_PVT is a private PL/SQL package owned by the APPS schema in Oracle E-Business Suite Receivables. Its header carries the source control identifier AROMRFNS.pls and version 120.2, dated 30-OCT-2005. The package provides the internal implementation supporting refund of customer prepayments, particularly in Order Management contexts where the prepayment originated from an order or where multiple prepayments are projected into refund activity. It is classified as a PVT API, meaning it is not intended as a public integration interface; it is invoked by other Receivables components that present the refund prepayment functionality to end users.

The specific error string associated with this object — "EA19 refund is not supported for movement / bills" — arises from validation logic in the prepayment refund path. When a user attempts to refund a prepayment whose application was created through Order Management movement or bills flows, the package rejects the request because the refund cannot be systematically processed for that application context. This is a deliberate control rather than a defect: refunds require a receipt method and bank account to generate the refund receipt, and movement/bill-originated applications do not carry the attributes needed to complete that downstream processing.

Key Procedures and Functions

The ETRM metadata documents a single public procedure, REFUND_PREPAYMENT_WRAPPER.

  • REFUND_PREPAYMENT_WRAPPER — This procedure is described in the package header comments as functionally equivalent to the AR_PREPAYMENTS refund logic, with one additional input parameter, p_bank_account_id. When both p_bank_account_id and p_receipt_method_id are supplied with values, the wrapper populates global variables that are subsequently consumed by AR_PREPAYMENTS.Refund_Prepayment. The wrapper follows standard Oracle API conventions, accepting the API version, initialization flag, commit flag, and validation level as inputs, and returning the standard return status, message count, and message data outputs. It additionally returns the prepayment application identifier and a count of refund receipts generated. The procedure was originally created on 14-AUG-2003.

No additional procedures or functions are documented in the provided metadata.

Tables Accessed

The documented table references are limited to two Receivables base tables accessed through APPS synonyms:

  • AR_CASH_RECEIPTS — The refund process creates one or more refund receipts. This table stores the resulting cash receipt records for the generated refunds.
  • AR_RECEIVABLE_APPLICATIONS — The p_prepay_application_id output parameter is typed against this table's receivable_application_id column. The table holds the application records that determine which prepayment is being refunded and whether that application qualifies for refund processing.

The internal prepayment refund logic invoked by the wrapper operates against AR_PREPAYMENTS, as indicated by the package header comments; however, AR_PREPAYMENTS is not listed among the documented table references for this package.

Usage Notes

Because this package is classified as PVT, it should not be called directly from custom integrations. It is referenced by one other package, which is the normal invocation path: a public or shared Receivables component calls REFUND_PREPAYMENT_WRAPPER, passing the bank account and receipt method so that the global variables required by AR_PREPAYMENTS.Refund_Prepayment are populated correctly.

From a functional standpoint, refunds of prepayments are initiated from the Receivables receipts interface when a prepayment with an unapplied balance is selected for refund. The refund receipt requires an active receipt method and, for certain methods, a valid bank account. The EA19 error is encountered when the underlying receivable application traces back to an Order Management movement or bill, where the application is not a standard manual prepayment application and therefore lacks the structure the refund path expects. In such cases, the appropriate resolution is to correct the application path rather than bypass the validation, since forcing a refund would produce a receipt that cannot be reconciled against the originating application. In both 12.1.1 and 12.2.2, the package structure and the EA19 message remain consistent; the source file version in the metadata predates the 12.2 release and carries a noship (non-shipped) designation, indicating the logic is delivered as part of the underlying Receivables and Order Management integration rather than as a separately available API.