Results for “arp_cr_icr_lines_pkg”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

ARP_CR_ICR_LINES_PKG is an Oracle Application Object Library (APPS) PL/SQL package body within the Oracle E-Business Suite Receivables (AR) module. Its name reflects its role: it manages the line-level records held in the interim cash receipts tables (AR_INTERIM_CASH_RECEIPTS and AR_INTERIM_CASH_RECEIPT_LINES) associated with cash receipts and the resulting application lines. Interim cash receipt tables serve as staging structures used during cash receipt processing, particularly during automatic receipt creation, quick cash entry, and remittance batch import. Because these staging tables must be kept synchronized before final posting to the AR cash receipt base tables, a dedicated package encapsulates the insert, update, delete, lock, and fetch logic for those interim lines. In the context of both 12.1.1 and 12.2.2, the object is a standard, VALID APPS-owned component whose functionality is stable; no changes to its purpose are documented between those releases.

Key Procedures and Functions

The ETRM metadata documents eleven callable units. These fall into four functional categories:

• SET_TO_DUMMY — assigns placeholder or dummy values, typically used to initialize or neutralize a record before further processing.
• INSERT_P — inserts a new interim cash receipt line record.
• UPDATE_P — updates an existing interim cash receipt line record.
• DELETE_P — deletes an interim cash receipt line record based on its primary identifier.
• DELETE_FK — performs a delete using a foreign-key relationship, removing dependent interim lines when their parent interim receipt is removed.
• LOCK_P — obtains a row-level lock with an unconditional wait, providing concurrency control during modification.
• NOWAITLOCK_P — attempts a row-level lock without waiting, returning immediately if the row is already held.
• FETCH_P — retrieves a single interim cash receipt line record, with a locking variant to control concurrent access.
• LOCK_FETCH_P — fetches a record while acquiring a waiting lock.
• NOWAITLOCK_FETCH_P — fetches a record while attempting a non-blocking lock.

The naming convention mirrors the standard Oracle Tools/APIs style (DML plus lock/fetch prefixed by timing semantics), indicating the package was generated or written to conform to the AR entity-handler pattern used throughout Receivables.

Tables Accessed

The package references four documented objects through APPS synonyms:

• AR_INTERIM_CASH_RECEIPTS — the header-level staging table for interim cash receipts; read to validate parent context and used by DELETE_FK for cascade-style removal.
• AR_INTERIM_CASH_RECEIPT_LINES — the primary target of the insert, update, delete, and fetch operations; stores the individual receipt application or distribution lines staged prior to posting.
• AR_SYSTEM_PARAMETERS — read to obtain Receivables setup flags and defaults that govern validation and processing behavior for the lines.
• DBMS_SQL — the Oracle-supplied dynamic SQL package, referenced for dynamic statement construction or execution within the package logic.

Additional dependencies include the APPS packages ARP_GLOBAL and ARP_STANDARD, which supply global constants and shared utility routines, and FND_PROFILE, used to read profile option values (for example, the operating unit context) that affect interim processing.

Usage Notes

ARP_CR_ICR_LINES_PKG is not referenced by any other database object within the ETRM dependency view; rather, it is referenced by two other packages, which places it in a supporting, lower-tier position in the application call stack. It is generally invoked indirectly—by Receivables forms, AutoCash/automatic receipt concurrent programs, lockbox and remittance processing, or custom extensions—rather than called directly by end users. Developers integrating with Receivables interim receipts should call the appropriate INSERT_P, UPDATE_P, or DELETE_P entry point and honor the LOCK/FETCH variants to preserve record integrity under concurrent access. Because the package is VALID and stable in both 12.1.1 and 12.2.2, existing customizations that depend on it remain compatible across these releases.