Search Results update_f_bs_id

Overview

ARP_TBAT_PKG is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It provides the core table-handling API layer for the ra_batches entity, which stores Receivables batch records used to group transactions for entry, approval, and posting. The package declares AUTHID CURRENT_USER, meaning its SQL executes under the privileges of the calling schema rather than the defining schema. This is consistent with the Oracle Forms server-side processing model, where the runtime session must resolve APPS synonyms and apply row-level locking in the context of the connected user.

The package name reflects its function as a table API (TBAT) for batches: it isolates the low-level INSERT, SELECT, UPDATE, DELETE, and locking logic required by the Receivables batch maintenance form (RAXTRX) and by downstream batch-processing programs. By centralizing these operations, Oracle ensures that batch row access, concurrency control, and master-detail cleanup behave consistently across all callers.

Key Procedures and Functions

• INSERT_P — Inserts a new row into RA_BATCHES from a record structure. It returns the generated batch identifier and batch name to the caller for subsequent use.
• FETCH_P — Retrieves a single batch row, keyed by batch identifier, into a RA_BATCHES%ROWTYPE output record.
• UPDATE_P — Updates an existing batch row identified by batch identifier, writing the values supplied in the input record.
• UPDATE_F_BS_ID — Updates batches associated with a given batch source, keyed by BATCH_SOURCE_ID in RA_BATCH_SOURCES. Used when batch source attributes must be propagated or reassigned.
• DELETE_P — Deletes a single batch row by batch identifier.
• DELETE_F_BS_ID — Deletes batches belonging to a specified batch source, supporting source-level maintenance and cleanup.
• LOCK_P — Issues a lock against a batch row to serialize concurrent access before modification.
• LOCK_FETCH_P — Combines locking and retrieval, returning the locked batch record in a single call.
• LOCK_COMPARE_P — Locks the batch row and compares it against a caller-supplied record, detecting concurrent modification.
• LOCK_COMPARE_COVER — Performs an extended lock-and-compare across individual batch columns (name, source, dates, status, type, currency, exchange details, control totals, accounting set of books, and comment fields) rather than the full record.
• SET_TO_DUMMY — Assists in initializing or nulling record attributes, typically prior to form-level population.
• DISPLAY_BATCH — Renders or logs batch information for display or diagnostic purposes.
• DISPLAY_BATCH_REC — Presents a batch record, used for review or debugging output.

Tables Accessed

The package references RA_BATCHES as its primary table, with the _S suffix variant RA_BATCHES_S used for the related search/alternate-key access path and possibly localization support. RA_BATCH_SOURCES supplies batch source definitions used by the source-keyed update and delete routines. AR_SYSTEM_PARAMETERS provides Receivables system option values, including the accounting set of books context. RA_CUSTOMER_TRX is referenced for transaction-to-batch relationships, and DUAL is used for single-row PL/SQL evaluation; DBMS_SQL supports dynamic SQL where the static cursor cannot be used. All access resolves through APPS synonyms.

Usage Notes

ARP_TBAT_PKG is invoked primarily from the Receivables transaction and batch forms, which call the INSERT_P, FETCH_P, UPDATE_P, DELETE_P, and LOCK_COMPARE_COVER routines to persist user changes with optimistic locking. Batch source maintenance paths invoke UPDATE_F_BS_ID and DELETE_F_BS_ID. The package is referenced by three other packages, indicating layered reuse by higher-level Receivables APIs and concurrent programs that create or purge batches. Its $Header places the source at ARTIBATS.pls, version 120.4 (2005), and the package is classified as OTHER in the ETRM API registry, meaning it is an internal implementation package rather than a formally published public API. Custom code should therefore avoid direct dependency where a supported Receivables open interface or public API is available.