Search Results ar_interest_batches_pkg




Overview
Explore in AI Chat

Overview

AR_INTEREST_BATCHES_PKG is a PL/SQL package body in the APPS schema that supports the Oracle Receivables late charge (interest) calculation and invoicing process. In Oracle EBS 12.1.1 and 12.2.2, the package acts as the batch-level programmatic interface for interest batches — the logical grouping units that hold a set of customer interest calculations produced by a given interest run. It is the batch-editing counterpart to the collection-level logic that builds interest lines, providing controlled operations for reading, validating, modifying, and removing interest batch records before they are converted into debit memos or invoices against customer accounts.

Because the object is registered in ETRM with an API classification of OTHER, it is treated as an internal/private utility package rather than a formal published public API. It is invoked by Oracle Receivables' own interest processing components, and it is also safe for controlled custom extension where batch maintenance automation is required. The package depends on the ARP_* interest core utilities, the FND_API error-handling framework, and the AR_INTEREST_BATCHES base table hierarchy, and it is referenced by two other database objects.

Key Procedures and Functions

  • GET_BATCH_AMOUNT — Returns the accumulated monetary amount for an interest batch. It is the standard accessor used by callers to obtain the batch total without querying AR_INTEREST_BATCHES directly, ensuring the same rounding and aggregation rules are applied consistently.
  • LOCK_BATCH — Acquires a logical lock on a batch so that concurrent interest processes or user sessions cannot modify or delete the same batch simultaneously. This protects the batch from double processing during calculation and invoicing.
  • VALIDATE_BATCH — Performs the business-rule validation of a batch before it is posted or deleted. Validation covers the batch status, the presence and consistency of associated interest headers and lines, and eligibility for the intended operation.
  • DELETE_BATCH — Removes an interest batch and its dependent interest headers and lines after validation succeeds. This supports the rerun-and-replace model common in late charge processing, where a prior interest run must be cleared before recalculation.
  • UPDATE_BATCH — Applies permitted changes to batch attributes, such as status or control values, within the constraints enforced by VALIDATE_BATCH and the held lock.

Tables Accessed

  • AR_INTEREST_BATCHES — The primary table managed by this package. It stores the batch header rows that group interest activity; GET_BATCH_AMOUNT, LOCK_BATCH, VALIDATE_BATCH, DELETE_BATCH, and UPDATE_BATCH all operate against this table.
  • AR_INTEREST_HEADERS — Stores the per-customer interest header rows linked to a batch. It is read during validation and removed during batch deletion.
  • AR_INTEREST_LINES — Stores the individual late charge lines belonging to each interest header. It is consulted during validation and cascaded during deletion.

All three tables are referenced through APPS synonyms. The package also references ARPT_SQL_FUNC_UTIL, ARP_GLOBAL, and ARP_UTIL for shared interest calculation and utility logic, and FND_API, FND_MESSAGE, and FND_MSG_PUB for the standard API return status and message stack.

Usage Notes

AR_INTEREST_BATCHES_PKG is normally invoked indirectly. The Receivables interest concurrent programs and the interest-related forms call the batch operations as part of running, reviewing, and reversing late charge batches. Typical invocation patterns include: calling VALIDATE_BATCH followed by DELETE_BATCH to clear a previous interest run; using LOCK_BATCH around UPDATE_BATCH to serialize edits; and calling GET_BATCH_AMOUNT to display or report batch totals.

For custom development, the package should be called from PL/SQL within the same database session, respecting the lock-before-update discipline. Because the API classification is OTHER rather than PUBLIC, parameter signatures are not guaranteed across releases; custom code should verify the package specification on the target instance. FND_MSG_PUB should be initialized so that error messages raised by the package are captured correctly. The package is not referenced by any database object, so removing or extending it does not cascade to other schema objects, but it is referenced by two other packages, and direct table manipulation should be avoided in favor of these routines to preserve validation and locking integrity.