Search Results arp_proc_receipts2




Overview
Explore in AI Chat

Overview

ARP_PROC_RECEIPTS2 is an internal PL/SQL package owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It belongs to the Oracle Receivables (AR) module and functions as a low-level processing engine for cash receipts. Its documented API classification is "OTHER," meaning it is not part of Oracle's published, externally supported API set, and it is instead an internal worker package invoked by higher-level Receivables APIs and forms.

The package encapsulates the core database operations that create, populate, and remit manual and miscellaneous cash receipts. It is the layer beneath the public Receivables receipt interfaces: rather than being called directly by customers, it is called by AR_RECEIPT_API_PUB and by other internal Receivables logic. The ETRM metadata confirms the package status as VALID and records three documented program units: REVISION, INSERT_CASH_RECEIPT, and REMIT_CASH_RECEIPT. It references six Receivables base tables through APPS synonyms and is referenced by one other package.

Key Procedures and Functions

The package exposes three documented program units, all of which relate to the receipt lifecycle:

  • INSERT_CASH_RECEIPT — Inserts the header and line rows for a new cash receipt into the Receivables tables. This unit is the creation path used when a receipt is entered or imported and must be persisted before any application, distribution, or accounting activity can occur.
  • REMIT_CASH_RECEIPT — Handles the remittance stage of the receipt lifecycle, moving a receipt from entered to remitted status. Remittance updates the receipt record and writes the corresponding remittance accounting rows so the funds can be reconciled against bank deposits.
  • REVISION — Supports the revision of an existing receipt, allowing controlled changes to receipt attributes while preserving the receipt history chain. Receipt revision is required when a receipt's identifying details must be corrected without invalidating downstream application and accounting activity.

The ETRM record does not publish individual parameter lists for these units; signatures are governed by the internal Receivables interface and may vary between patch levels, which is a further reason custom code should not call them directly.

Tables Accessed

The package reads and writes the following Receivables tables through APPS synonyms:

  • AR_CASH_RECEIPTS — the receipt header table; this is the primary insert and update target for receipt creation, remittance, and revision.
  • AR_CASH_RECEIPT_HISTORY — records the status and transactional history of each receipt, preserving the audit trail across the create, remit, and revise operations.
  • AR_RECEIVABLE_APPLICATIONS — stores the linkage between a receipt and the transactions it is applied against.
  • AR_PAYMENT_SCHEDULES — holds the transaction installments that are affected when a receipt is applied or adjusted.
  • AR_DISTRIBUTIONS — receives the accounting distribution rows generated in support of receipt activity.
  • AR_RECEIPT_METHOD_ACCOUNTS — supplies the receipt method's default accounts, which drive the cash, unapplied, unidentified, and unearned account derivation.

Usage Notes

ARP_PROC_RECEIPTS2 is not a supported public API. The ETRM dependency data shows it is referenced by AR_RECEIPT_API_PUB, the published Receivables receipt API, and by one additional package. Supported integrations should always be built against AR_RECEIPT_API_PUB rather than this package, so that Oracle's internal implementation remains free to change.

The package is invoked by Receivables forms, by the AutoReceipts and receipt-related concurrent programs, and by internal API logic during receipt creation, remittance, and revision. Custom code that references it directly risks failure on patching or upgrade because both the internal signatures and the set of tables touched are subject to change. When diagnosing receipt integrity issues, the tables listed above — particularly AR_CASH_RECEIPTS and AR_CASH_RECEIPT_HISTORY — should be examined to confirm the state the package produced.