Search Results batch_status_code




Overview
Explore in AI Chat

Overview

PA_EXPENDITURE_BATCHES is a single-organization (Single-Org) reporting view within the Oracle Projects (PA) module, available in Oracle E-Business Suite 12.1.1 and 12.2.2. It presents expenditure batch header information in a form that is filtered by the operating unit context of the current session. Rather than storing data itself, the view exposes a curated subset of columns from the multi-organization table PA_EXPENDITURE_BATCHES_ALL, restricting the result set to the organization identified by the session's client information. This design allows forms, reports, and concurrent programs to query expenditure batch data without explicitly qualifying every statement by ORG_ID.

Expenditure batches are the grouping mechanism used by Oracle Projects to collect and process expenditure items before they are interfaced to subledgers and General Ledger. The BATCH_STATUS_CODE column, which is the term the user searched, is the attribute that governs where a batch sits within that processing lifecycle, making this view a common reference point for status-driven reporting and integration queries.

Underlying Base Objects

The view is defined over a single documented base object, PA_EXPENDITURE_BATCHES_ALL. The view text is a straightforward projection of ten columns from that table followed by a WHERE clause that enforces the single-org filter:

The USERENV('CLIENT_INFO') function retrieves the organization context set by the Oracle Applications session, and the DECODE/SUBSTRB logic extracts the first ten characters as the numeric ORG_ID. Where ORG_ID is null, the expression resolves to -99, providing a sentinel that matches rows with no organization assignment. The parent table stores the same rows for all operating units, so PA_EXPENDITURE_BATCHES can be understood as the organization-filtered, read-oriented face of PA_EXPENDITURE_BATCHES_ALL.

Key Columns

  • BATCH_NAME — the user-defined or system-generated identifier for the expenditure batch; typically the primary business key in reports.
  • BATCH_STATUS_CODE — the current lifecycle status of the batch (for example, pending, released, or interfaced). This is the column most often used to determine whether a batch is eligible for further processing or interface to Oracle Payables and General Ledger.
  • BATCH_DATE — the accounting or transaction date associated with the batch, used for period and cut-off reporting.
  • BATCH_SOURCE — indicates the origin of the batch, distinguishing batches created through different entry paths such as manual entry, transaction import, or other feeder processes.
  • ORG_ID — the operating unit identifier used to enforce the single-org filter; it is also available for cross-checking organization assignment.
  • Audit columns — LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, and LAST_UPDATE_LOGIN support auditing, change tracking, and interfaces that need to identify the creating or modifying user and time.

Common Use Cases and Queries

Typical scenarios include status monitoring of expenditure batches, identifying batches ready for interface, and reconciliation of batch activity by source or date within the current operating unit.

To list batches by status:

  • SELECT batch_name, batch_status_code, batch_date, batch_source FROM pa_expenditure_batches WHERE batch_status_code = '&status';

To find recently created or updated batches for audit purposes:

  • SELECT batch_name, batch_status_code, creation_date, created_by, last_update_date FROM pa_expenditure_batches WHERE last_update_date >= :from_date ORDER BY last_update_date DESC;

To summarize batch volume by source and status:

  • SELECT batch_source, batch_status_code, COUNT(*) FROM pa_expenditure_batches GROUP BY batch_source, batch_status_code;

Because the view applies the single-org predicate automatically, these queries return only rows for the organization context of the session. Where no organization is set, the -99 sentinel causes the view to return organization-less rows, so integrations should set the client information explicitly before querying.