Search Results arp_reconcile




Overview
Explore in AI Chat

Overview

ARP_RECONCILE is a PL/SQL package body owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. Its business purpose is the reconciliation of Accounts Receivable transaction data against the accounting distributions and subledger balances generated for those transactions. Within Oracle Receivables, reconciliation ensures that the receivable balance carried on a transaction, the payment schedules assigned to it, the applications and adjustments applied against it, and the resulting general ledger distributions all remain internally consistent. ARP_RECONCILE provides the programmatic logic that inspects and corrects or reports on this consistency, typically as part of the transaction processing and accounting lifecycle.

The dependency metadata confirms that the package operates deep within the Receivables core. It calls into ARP_ACCT_MAIN (accounting mainline), ARP_ALLOCATION_PKG (tax and freight allocation), ARP_GLOBAL (global setup and initialization), ARP_PROCESS_BR_HEADER (transaction business rule header processing), ARP_STANDARD (standard utilities), and ARPCURR (currency handling). This dependency set indicates that ARP_RECONCILE is not a standalone utility but a component that participates in the posting and balancing of Receivables data.

Key Procedures and Functions

The documented metadata identifies a single program unit within the package body:

  • RECONCILE_TRX_BR — The reconciliation routine for transaction business-rule processing. It performs the comparison and reconciliation of transaction-level data, working in conjunction with the header processing logic in ARP_PROCESS_BR_HEADER. Consistent with the package's purpose, this procedure evaluates the receivable transaction against its associated distributions, payment schedules, applications, and adjustments to detect and address discrepancies.

No additional procedures or functions are documented in the available metadata. Parameter signatures are not published in the ETRM extract and are therefore not reproduced here.

Tables Accessed

The package references the following tables, all through APPS synonyms:

  • RA_CUSTOMER_TRX — the transaction header, providing the receivable being reconciled.
  • RA_CUSTOMER_TRX_LINES — transaction lines that detail the amounts, taxes, freight, and revenue assigned to the transaction.
  • RA_CUST_TRX_LINE_GL_DIST — the general ledger distributions generated for transaction lines, used to confirm that accounting derived from the transaction is complete and balanced.
  • AR_PAYMENT_SCHEDULES — the installment schedule representing the customer's obligation, a primary source of the receivable balance.
  • AR_RECEIVABLE_APPLICATIONS — cash and credit applications that reduce the open balance.
  • AR_ADJUSTMENTS — adjustments that modify the outstanding receivable, including write-offs and credits.
  • AR_DISTRIBUTIONS — the distribution records underlying accounting entries for Receivables activity.
  • DUAL — the standard single-row pseudo-table used for expression evaluation and PL/SQL assignments.
  • PLITBLM — the PL/SQL integer table type used for array processing within PL/SQL constructs.

Collectively these tables allow the package to reconcile the transaction header and lines against the payment schedules, applications, adjustments, and GL distributions that constitute the full accounting footprint of the transaction.

Usage Notes

ARP_RECONCILE is not referenced by any database object, meaning it is invoked by Oracle Forms, concurrent programs, or custom code rather than by triggers or views. In standard Receivables flows it is typically reached during transaction processing and accounting, especially where business rules are applied at the transaction header level through ARP_PROCESS_BR_HEADER. The presence of RECONCILE_TRX_BR supports its use as part of the AutoInvoice and transaction posting cycle, where consistency between the transaction, its schedules, and its distributions must be verified. Customizations should treat the package as Oracle-owned and call it only through supported APIs; direct modification of the package body is not supported and may be overwritten during patching or upgrades.