Results for “batch”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

PA_MASS_UPDATE_BATCHES_ALL is the header table within the Oracle Projects (PA) module that stores batches created for the mass update of project and task attributes. Each row represents a single mass update batch — a logical grouping that lets a user apply a common attribute change to many projects or tasks in one operation rather than editing each record individually. The table resides in the PA schema and is documented as VALID in both Oracle EBS 12.1.1 and 12.2.2.

The physical schema exposes 35 columns and is anchored by the primary key constraint PA_MASS_UPDATE_BATCHES_PK on BATCH_ID. A unique index, PA_MASS_UPDATE_BATCHES_U1, is also defined on BATCH_ID, confirming the column as the definitive business-key candidate while the surrogate key drives all downstream relationships. From a Data Vault modeling perspective, the mined relationship structure classifies this object as hub-leaning: it holds the identity and descriptive context of each batch, and other tables reference it through foreign keys rather than the reverse.

Key Information Stored

The most operationally significant columns include:

• BATCH_ID — Surrogate primary key. Uniquely identifies each mass update batch and is the column referenced by dependent detail tables.
• BATCH_NAME and DESCRIPTION — User-facing label and free-text explanation of the batch’s purpose.
• BATCH_STATUS_CODE — Tracks the lifecycle stage of the batch (for example, unprocessed, processed, or rejected).
• PROJECT_ATTRIBUTE — Identifies which project or task attribute the mass update targets.
• REJECTION_CODE — Populated when the batch fails validation, indicating the reason for rejection.
• EFFECTIVE_DATE — The date on which the attribute change takes effect.
• PROCESS_RUN_DATE and PROCESS_RUN_BY — Audit columns recording when and by whom the batch was processed.
• ORG_ID — Operating unit context, supporting multi-organization data separation.
• REQUEST_ID, PROGRAM_ID, and PROGRAM_APPLICATION_ID — Concurrent program identifiers linking the batch to the request that created or processed it.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE15 — The standard Oracle EBS descriptive flexfield (DFF) columns for capturing additional client-specific batch information.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, and LAST_UPDATE_LOGIN — Standard WHO audit columns present on transactional tables.

Common Use Cases and Queries

This table is primarily queried to monitor the progress and outcome of mass update activity, and to trace which concurrent request processed a given batch. A typical query joins the header to its detail lines:

• Batch status reporting: SELECT batch_id, batch_name, batch_status_code, effective_date FROM pa_mass_update_batches_all WHERE org_id = :org_id;
• Determining the source concurrent request: SELECT batch_id, request_id, program_id, process_run_date FROM pa_mass_update_batches_all WHERE batch_status_code = 'PROCESSED';
• Failed batch investigation: filtering rows where REJECTION_CODE is not null to identify validation failures.
• Joining to detail lines: SELECT b.batch_name, d.* FROM pa_mass_update_batches_all b, pa_mass_update_details d WHERE b.batch_id = d.batch_id;

Reconciliation and audit reporting frequently relies on the WHO columns and ORG_ID to attribute activity to a specific operating unit and user.

Related Objects

The most significant dependent object is PA_MASS_UPDATE_DETAILS, which references this table through PA_MASS_UPDATE_DETAILS.BATCH_ID → PA_MASS_UPDATE_BATCHES_ALL.BATCH_ID. This parent-child relationship is the core of the mass update model: the header defines the batch intent, while the detail table identifies each project or task affected. Additional reference points include the concurrent program and request infrastructure surfaced through REQUEST_ID and PROGRAM_ID, the FND_LOOKUPS or Projects lookup views validating BATCH_STATUS_CODE and REJECTION_CODE, and the standard Oracle EBS WHO audit columns shared across PA transactional tables. Together these objects support end-to-end traceability from a batch definition through to its individual project and task updates.