Search Results ap_pbatch_sets




Overview
Explore in AI Chat

Overview

APPS.AP_PBATCH_SETS_V is a reporting and integration view in Oracle E-Business Suite that exposes the definition of Payment Batch Sets used by the Oracle Payables payment processing engine. In Oracle Payables, a payment batch set is a grouping mechanism that allows multiple payment batches to be generated, formatted, and processed together as a single logical unit, principally to support payment formats and banking arrangements that require consolidated output across several batches. The view provides a stable, read-oriented projection over the underlying AP_PBATCH_SETS table, allowing concurrent programs, reports, and external integrations to reference batch set definitions without accessing the base table directly.

The view is owned by the APPS schema and is available in both EBS 12.1.1 and 12.2.2. Because it is a simple single-table view rather than a join across multiple entities, it functions as a lightweight metadata access point — suitable for lookups, validation, list-of-values enrichment, and extraction into data warehouses. It carries no row-level security constructs of its own; any multi-org filtering is applied by referencing the ORG_ID column and by the standard operating unit context established through MOAC (Multi-Org Access Control) where applicable.

Underlying Base Objects

The view is defined over a single documented base object: the synonym AP_PBATCH_SETS, which resolves to the Payables payment batch sets entity in the AP schema. The view text is an unmodified projection of that table, listed in the ETRM documentation as selecting ROWID, BATCH_SET_ID, BATCH_SET_NAME, ORG_ID, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATION_DATE, CREATED_BY, and INACTIVE_DATE from AP_PBATCH_SETS.

Because the definition is a direct SELECT with no joins, aggregations, or filters, the view imposes no additional performance overhead beyond statement parsing. It inherits the indexing and partitioning characteristics of the base table, and its ROWID pseudocolumn is exposed explicitly as ROW_ID, which preserves the ability to correlate rows back to the physical base record. No other documented base objects participate in the definition.

Key Columns

  • ROW_ID — The base table ROWID, exposed for direct row addressing and for use in update or correlation logic.
  • BATCH_SET_ID — The unique primary identifier of the payment batch set; the principal join key to payment batches and related Payables entities.
  • BATCH_SET_NAME — The user-defined name of the batch set as entered during setup; the primary descriptive attribute for reporting.
  • ORG_ID — The operating unit identifier that owns the batch set, used for multi-org filtering and MOAC enforcement.
  • INACTIVE_DATE — The date on which the batch set was deactivated; a NULL value indicates an active batch set.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — Standard EBS audit columns capturing when and by whom the record was last modified.
  • CREATION_DATE, CREATED_BY — Standard EBS audit columns capturing record creation metadata.

Common Use Cases and Queries

Typical uses include validating a batch set identifier supplied by an external system, populating a list of values, and extracting active batch sets per operating unit for reporting or migration.

  • Retrieve all active batch sets for an operating unit: 
    SELECT batch_set_id, batch_set_name
FROM   apps.ap_pbatch_sets_v
WHERE  org_id = :p_org_id
AND    inactive_date IS NULL;
  • Look up a batch set by name: 
    SELECT batch_set_id, org_id, creation_date
FROM   apps.ap_pbatch_sets_v
WHERE  batch_set_name = :p_name;
  • Audit recently changed definitions: 
    SELECT batch_set_id, batch_set_name, last_update_date, last_updated_by
FROM   apps.ap_pbatch_sets_v
WHERE  last_update_date >= TRUNC(SYSDATE) - 7;

Because the view is read-only in practice and mirrors its base table exactly, it is safe to use in place of AP_PBATCH_SETS for query-only access, preserving the documented interface while insulating integrations from future base table changes.