Search Results debit_memo_reversal

Overview

ARP_REVERSE_RECEIPT is a Receivables module package body in Oracle E-Business Suite (12.1.1 and 12.2.2) that provides the core business logic for reversing, cancelling, and validating cash receipts. Its primary function is to orchestrate the complete reversal lifecycle of a receipt — including the reversal of associated claims, adjustments, and accounting distributions — while guarding against state conditions that make a receipt ineligible for reversal. The package is commonly implicated in scenarios users describe as "debit_memo_reversal," since reversing a receipt frequently involves the reversal of the debit memo or chargeback claims against it. It is classified as an OTHER API in ETRM, indicating it is primarily an internal utility layer invoked by forms and other packages rather than a formally published public API. The package is referenced by four other packages, reflecting its role as a shared dependency for receipt-reversal processing across Receivables.

Key Procedures and Functions

ETRM documents seven procedures and functions within this package body:

• REVERSE — The principal driver procedure. It performs the receipt reversal, coordinating argument validation, updating the cash receipt and its history, and handling the reversal of related claims and distributions.
• RECEIPT_HAS_NON_CANCEL_CLAIMS — A validation function that determines whether a receipt has claims that cannot be cancelled, used to block or condition the reversal path.
• CANCEL_CLAIMS — Cancels the claims associated with a receipt as part of the reversal or cancellation workflow.
• RECEIPT_HAS_CLAIMS — A check that returns whether any claims exist against a receipt, helping callers branch logic before attempting reversal.
• CHECK_NETTED_RECEIPTS — Validates netted receipt conditions, ensuring reversal is not attempted on receipts whose netting state precludes it.
• RECEIPT_HAS_PROCESSED_REFUNDS — Determines whether a receipt has refunds that were already processed, a condition that typically restricts reversal.
• CHECK_SETTLEMENT_STATUS — Evaluates the settlement status of a receipt to confirm whether it may be reversed.

The private procedures visible in the source header (for example validate_args and update_current_cr_rec) support the public routines by validating input arguments and updating the current cash receipt record with reversal category, reversal date, reason code, comments, and descriptive flexfield attributes.

Tables Accessed

The package reads and writes the following tables via APPS synonyms:

• AR_CASH_RECEIPTS and AR_CASH_RECEIPT_HISTORY — store the receipt header and reversal history, including reversal GL date, category, and reason.
• AR_PAYMENT_SCHEDULES — maintains installment and claim balances affected by reversal.
• RA_CUSTOMER_TRX, RA_CUST_TRX_LINE_GL_DIST, and RA_CUST_TRX_TYPES — supply transaction, distribution, and transaction-type context for the claims being reversed.
• AR_ADJUSTMENTS, AR_DISTRIBUTIONS, and AR_MISC_CASH_DISTRIBUTIONS — support reversal of adjustments and accounting distributions.
• AR_MEMO_LINES_B and AR_MEMO_LINES_TL — hold debit memo and chargeback line detail relevant to "debit_memo_reversal."
• AR_ACTIVITY_DETAILS and AR_ACTIVITY_DETAILS_S — reference date and activity context.
• AR_RECEIPT_METHODS and AR_BATCHES — provide receipt method and batch context used during reversal processing.

Usage Notes

ARP_REVERSE_RECEIPT is typically invoked from the Receivables Reverse Receipt form and from concurrent or internal processes that need to reverse or cancel a receipt and its associated claims, including debit memos. Because it is classified as an OTHER API, it is intended primarily for internal Oracle use; custom code should generally call the supported Receivables APIs rather than this package directly. Direct invocation requires a valid cash receipt identifier and reversal parameters (category, GL date, reversal date, reason code), and callers must first satisfy the various guard checks — claims, netted receipts, processed refunds, and settlement status — to avoid runtime errors. Any customization should account for the fact that four other packages also depend on this body, so behavior changes can ripple through receipt-reversal processing.