Search Results ar_irec_apply_credits




Overview
Explore in AI Chat

Overview

AR_IREC_APPLY_CREDITS is an Oracle Receivables PL/SQL package owned by the APPS schema and classified as an "OTHER" API within the ETRM repository for Oracle EBS 12.1.1 and 12.2.2. Its principal business function is to support the iReceivables (AR_IREC) self-service application by automatically applying open credit transactions—credit memos, on-account credits, and unapplied cash—against a customer's open debit items such as invoices and debit memos. The package drives the "Apply Credits" feature exposed to customers and collections agents through the iReceivables web interface, allowing a customer to select which credits should offset which open receivables without manual intervention by an AR specialist.

The package works by staging candidate transactions into temporary global temporary tables (GTTs), where the iReceivables UI displays them to the user. Once the user confirms the application, the package writes matching rows into the receivable applications tables and returns the resulting cash receipt or application identifiers to the caller. The AUTHID CURRENT_USER declaration means the package executes with the privileges of the invoking schema rather than as definer-rights code.

Key Procedures and Functions

The package exposes ten documented procedures that fall into four functional groupings:

  • Staging procedures: COPY_TRANSACTION_LIST_RECORDS, COPY_OPEN_DEBITS, and COPY_OPEN_CREDITS populate the GTTs with the customer's eligible transactions. COPY_OPEN_DEBITS retrieves open debit items, COPY_OPEN_CREDITS retrieves open credit items, and COPY_TRANSACTION_LIST_RECORDS copies the full transaction list for display.
  • Record management procedures: CREATE_APPLY_CREDITS_RECORD and DELETE_APPLY_CREDITS_RECORD add or remove individual staging rows for a given payment schedule, while DELETE_ALL_CREDITS, DELETE_ALL_DEBITS, and DELETE_ALL_RECORDS clear the staging tables for a customer, site use, and currency combination.
  • APPLY_CREDITS: the core processing procedure. It takes a customer, optional site use, a driving customer, currency, and a credit-memos-only flag, then performs the application of selected credits to open debits. It returns output parameters indicating whether open invoices remain, the payment schedule IDs of any duplicate debit or credit applications, the generated cash receipt ID if applicable, and standard message count/data and return status fields.
  • COPY_APPLY_CREDITS_RECORDS: refreshes the staging GTT with the current set of apply-credits records for the customer context.

Tables Accessed

The package reads and writes several core Receivables tables via APPS synonyms. AR_IREC_APPLY_CREDIT_GT and AR_IREC_PAYMENT_LIST_GT are the global temporary tables used to stage credit and debit candidate transactions for the iReceivables UI. AR_PAYMENT_SCHEDULES supplies installment-level information about open debit and credit items and their remaining balances. AR_RECEIVABLE_APPLICATIONS and AR_RECEIVABLE_APPLICATIONS_ALL store the actual application records created when credits are applied to debits. HZ_CUST_ACCOUNTS provides customer identity and relationship information. RA_CUSTOMER_TRX holds the transaction headers and lines for invoices, credit memos, and debit memos. RA_TERMS supplies payment term definitions used when evaluating due dates and eligibility for credit application.

Usage Notes

AR_IREC_APPLY_CREDITS is normally invoked indirectly by the iReceivables Java/HTML front end rather than called directly by end users. When a customer selects the "Apply Credits" action in the self-service portal, the application server calls the staging procedures to populate the GTTs, presents the results, and—upon confirmation—calls APPLY_CREDITS to post the applications and commit the results. The package is not documented as being referenced by other PL/SQL packages, indicating it is a top-level entry point used by the web layer. Customizations that extend iReceivables credit-application behavior should wrap APPLY_CREDITS rather than modifying it, and any direct invocation from concurrent programs or custom code must respect the customer, site use, and currency context expected by the staging procedures to avoid applying credits across incorrect transaction sets.