Search Results pay_batch_headers_pk

Overview

PAY_BATCH_HEADERS is the header table for Oracle Payroll's Batch Element Entry (BEE) facility, residing in the HR schema and delivered as a VALID database object under the PAY – Payroll product. Each row represents a single batch of element entries submitted for processing, carrying the control attributes that govern how the batch is validated, transferred, and either applied or rolled back. The table sits at the center of the batch element entry data model: it is the parent of both the batch lines and the batch control totals, meaning every individual element entry staged for processing and every aggregate control figure is anchored to a header row identified by BATCH_ID.

From a dimensional modeling perspective, the mined foreign-key structure classifies PAY_BATCH_HEADERS as hub-leaning. In Data Vault terms this suggests treating BATCH_ID as a business hub key, with the descriptive and control attributes modeled as satellite detail and the child tables (lines, control totals) attached as links or downstream satellites. This is a heuristic recommendation derived from the FK topology rather than a mandated design.

Key Information Stored

The surrogate primary key is BATCH_ID, enforced by the PAY_BATCH_HEADERS_PK unique index, which is also the only documented unique index and therefore the sole business-key candidate in the ETRM 12.2.2 physical schema. The table carries 22 documented columns.

• BATCH_ID – surrogate primary key and sole documented business key; the join column for all child objects.
• BUSINESS_GROUP_ID – the enterprise/legislative business group owning the batch; the primary partitioning and security filter in multi-organization environments.
• BATCH_NAME – user-supplied identifier used to locate and reference the batch in forms and reports.
• BATCH_STATUS – lifecycle state of the batch (for example, unreleased, released, transferred, or rolled back), the single most common filter in operational queries.
• BATCH_TYPE – classifies the batch and influences which processing rules apply.
• BATCH_SOURCE – origin of the batch, distinguishing manual entry from external or interface-loaded data.
• BATCH_REFERENCE – external or upstream reference retained for traceability back to the originating system or document.
• ACTION_IF_EXISTS – controls behavior when an entry already exists in the period, driving update versus reject semantics.
• DATE_EFFECTIVE_CHANGES – governs how effective-dated changes on the underlying element entries are treated.
• REJECT_IF_FUTURE_CHANGES and REJECT_IF_RESULTS_EXISTS – validation switches that cause the batch to be rejected rather than partially applied.
• REJECT_ENTRY_NOT_REMOVED, ROLLBACK_ENTRY_UPDATES, PURGE_AFTER_TRANSFER, and PURGE_AFTER_ROLLBACK – rollback and housekeeping controls determining whether processed or reversed entries are updated, retained, or purged.
• COMMENTS – free-text annotation entered by the batch creator.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATED_BY, CREATION_DATE, OBJECT_VERSION_NUMBER – standard who-columns and the optimistic locking counter.

Common Use Cases and Queries

The dominant operational scenario is monitoring batches awaiting transfer or rollback. A typical query joins the header to its control totals to compare entered amounts against expected totals before release:

• List in-flight batches for a business group: SELECT batch_id, batch_name, batch_status, batch_type FROM pay_batch_headers WHERE business_group_id = :bg_id AND batch_status = :status ORDER BY creation_date DESC;
• Reconcile batch contents by joining lines to the header on PAY_BATCH_LINES.BATCH_ID = PAY_BATCH_HEADERS.BATCH_ID.
• Audit batch activity by creator and date using CREATED_BY and CREATION_DATE.
• Identify batches eligible for purge after transfer using PURGE_AFTER_TRANSFER and BATCH_STATUS.

Reporting typically aggregates through the child tables, while the header supplies the descriptive context and the control switches that explain why a batch was rejected or rolled back.

Related Objects

Two documented child tables reference this header through the BATCH_ID column, and the header owns the primary key that both depend upon.

• PAY_BATCH_LINES – the individual element entries staged within the batch; join on PAY_BATCH_LINES.BATCH_ID = PAY_BATCH_HEADERS.BATCH_ID.
• PAY_BATCH_CONTROL_TOTALS – aggregate control figures used to verify the batch before transfer; join on PAY_BATCH_CONTROL_TOTALS.BATCH_ID = PAY_BATCH_HEADERS.BATCH_ID.

Because BATCH_ID is the sole documented key and both children resolve to it, any query or extract must drive from PAY_BATCH_HEADERS to preserve the batch-level status and control attributes.