Search Results get_batch_amount




Overview
Explore in AI Chat

Overview

AR_INTEREST_BATCHES_PKG is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite Receivables (AR). It encapsulates the business logic used to manage interest batches, which are the parent grouping entities under which interest calculations are run against past-due customer transactions. Interest batches in Receivables organize the calculation of late charges on delinquent invoices and debit memos, and their processing produces interest headers and interest lines that eventually flow into the general ledger. The package therefore sits at the transaction-control layer for the Receivables interest processing feature, providing the validation, locking, updating, deletion, and monetary aggregation services that both the Oracle Forms interest-batch interface and the interest-related concurrent programs depend upon. It is classified as an "OTHER" API rather than a public or private API in ETRM, meaning it is intended primarily for internal use by Oracle's own forms and concurrent request infrastructure, although it is exposed through APPS synonyms and can be called from custom PL/SQL where the calling code honors its validation and message-handling conventions. The package header carries a version stamp of 120.3, reflecting a maintenance lineage dating to 2006, and it follows the standard Oracle EBS API design pattern of returning a return status, message count, and message data to the caller.

Key Procedures and Functions

  • GET_BATCH_AMOUNT — A function that accepts an interest batch identifier and returns the monetary amount associated with that batch. This is the object surfaced by the search term "get_batch_amount," and it is typically used by forms and reports to display or derive the total interest amount for a batch without re-querying and summing the underlying interest lines independently.
  • LOCK_BATCH — A procedure that performs the standard Oracle Forms "lock and re-validate" operation against an interest batch record. It takes the batch identifier, name, calculate-interest-to date, GL date, transferred status, batch status, organization identifier, and object version number, and returns the standard API return status, message count, and message data. Its purpose is to detect concurrent modification via the object version number and to raise consistent validation errors before an update is attempted.
  • VALIDATE_BATCH — A procedure that validates an interest batch record. It accepts an action indicator, an updating program identifier defaulting to the interest processing program ARIINR, an old batch record, and a new batch record, and returns a cascade-update flag plus a return status. This routine enforces business rules before batch DML is committed, including conditions that may require dependent rows to be updated as a consequence.
  • DELETE_BATCH — A procedure that removes an interest batch. It accepts an initialization flag defaulting to FND_API.G_FALSE and an interest batch identifier, and returns an object version number together with the standard return status, message count, and message data. It is the controlled deletion path for batch records as opposed to direct SQL deletes.
  • UPDATE_BATCH — A procedure that updates an interest batch. It accepts an initialization flag, the batch identifier, the new batch status, the new transferred status, an optional GL date, and an updating program identifier defaulting to ARIINR, and returns an updated object version number plus the standard return status, message count, and message data. It is the principal state-transition routine for moving a batch through its lifecycle, including transfer to general ledger indicators.

Tables Accessed

  • AR_INTEREST_BATCHES — The batch master table. It stores the batch header record, including batch name, calculate-interest-to date, GL date, transferred status, batch status, and organization identifier. The package reads it for locking and validation and writes it during update and delete operations.
  • AR_INTEREST_HEADERS — The interest header table, which holds the interest calculation header rows associated with a batch. It is referenced as part of the batch's dependent data, most notably when validation determines whether cascading updates to child records are required.
  • AR_INTEREST_LINES — The interest line table, containing the individual calculated interest amounts per transaction. It represents the detail level from which batch-level amounts are ultimately derived, and it is accessed when the package resolves amounts and validates the completeness and consistency of a batch.

Usage Notes

In a 12.1.1 or 12.2.2 environment, AR_INTEREST_BATCHES_PKG is most commonly invoked indirectly. The Receivables interest batch form calls LOCK_BATCH, VALIDATE_BATCH, UPDATE_BATCH, and DELETE_BATCH as the user creates, modifies, or removes batches, while reports and inquiries call GET_BATCH_AMOUNT to display batch monetary totals. Concurrent processing for interest calculation and transfer to general ledger interacts with the same tables and relies on the status fields the update routine maintains. Because the package is owned by APPS and is not classified as a public API, customizations should call it only through the APPS synonym, supply the correct object version number for optimistic locking, respect the FND_API-style initialization flag, and always inspect the returned status, message count, and message data rather than assuming success. Custom code that manipulates AR_INTEREST_BATCHES directly bypasses validation and lock semantics and risks corrupting the batch state used by the standard Receivables interest pipeline. Multi-org filtering is handled through the organization identifier passed to LOCK_BATCH, so callers must resolve the correct operating unit context before invoking the package.