Search Results create_receipt_writeoff

Overview

ARP_PROCESS_WRITEOFF is an Oracle Application Object Library PL/SQL package owned by the APPS schema that supports the Oracle Receivables write-off and receipt adjustment process. Its principal business function is to create accounting-bearing write-off receipts that reduce an open receivable balance, allowing uncollectible or immaterial customer balances to be removed from the receivables aging while preserving a complete audit trail. The package is classified as an OTHER API in the ETRM repository for 12.2.2, indicating that it is an internal processing package rather than a formally published, externally supported open interface. It is closely associated with Oracle Receivables' automatic write-off functionality and with the receipt-based write-off flows that generate adjustments against payment schedules.

The package holds a VALID status in both the 12.1.1 and 12.2.2 environments and consists of a package specification and package body. It operates against standard Oracle Receivables transaction tables through APPS synonyms, ensuring that the same logic is available irrespective of the underlying database schema configuration.

Key Procedures and Functions

The documented API surface exposes five procedures and functions:

• CREATE_RECEIPT_WRITEOFF — The central routine that creates a write-off receipt and applies it against the specified customer balance, effectively closing out the receivable. It drives the creation of the AR_CASH_RECEIPTS record and the corresponding application rows.
• UNAPPLIED_AMOUNT — Returns the portion of a receipt or balance that remains unapplied, used to determine how much of an amount can still be directed to a write-off or other application.
• APPLIED_AMOUNT — Returns the amount already applied against a given receipt or transaction, supporting balancing and validation logic during the write-off process.
• ON_ACCOUNT_AMOUNT — Returns the on-account portion of a receipt, distinguishing funds held without a specific application from those already applied.
• BALANCING_SEGMENT — Derives the balancing segment value required for the accounting entries generated by the write-off, ensuring the resulting journal entries satisfy the ledger's balancing requirements.

Tables Accessed

The package reads and writes the core Receivables and supporting tables via APPS synonyms:

• AR_CASH_RECEIPTS, AR_CASH_RECEIPT_HISTORY, AR_RECEIVABLE_APPLICATIONS — store the write-off receipt header, its status history, and the application of the receipt to the open receivable.
• AR_PAYMENT_SCHEDULES — holds the installments whose balances are reduced by the write-off.
• AR_BATCHES — provides the receipt batch context for the generated write-off receipt.
• AR_APPROVAL_USER_LIMITS — enforces user approval limits governing write-off amounts.
• AR_SYSTEM_PARAMETERS — supplies system-level defaults controlling the write-off behavior.
• HZ_CUST_ACCOUNTS — identifies the customer account associated with the balance.
• GL_CODE_COMBINATIONS — resolves the accounting flexfield combinations used for the write-off distribution.
• FND_CONCURRENT_REQUESTS — tracks concurrent program submissions associated with the processing.
• PLITBLM — provides the standard Oracle numeric/string table type used internally by the package.

Usage Notes

ARP_PROCESS_WRITEOFF is normally invoked indirectly by Oracle Receivables forms and concurrent programs rather than being called directly by end users. Receipt-based write-off processing, automatic write-off during receipt application, and related adjustment workflows invoke the CREATE_RECEIPT_WRITEOFF routine to generate the write-off receipt and its accounting. The package is referenced by the AR_RX_OTHER_APPLICATIONS_V view and by one other package within the APPS schema, confirming that it operates as a shared internal service rather than a standalone entry point. Custom code should treat these routines as internal APIs: parameter lists are not published in the ETRM metadata, signatures may vary between release levels, and direct calls carry upgrade risk. Developers requiring write-off automation should prefer documented public APIs where available and validate behavior against the specific patch level in use.