Search Results pay_range_temp_pk

Overview

PAY_RANGE_TEMP is a transient staging table owned by the HR schema within the Oracle E-Business Suite Payroll (PAY) product module. As its documented description states, it serves as an "Intermediate Table to store processing data for Tax Tables." In Oracle EBS 12.1.1 and 12.2.2, payroll tax processing engines and concurrent programs write intermediate range and band data into PAY_RANGE_TEMP before that data is validated, transformed, and committed to permanent tax configuration and calculation tables. The table is therefore a working buffer rather than a transactional system of record, and its contents are typically short-lived, scoped to a specific processing run or range table load.

The ETRM metadata classifies this object heuristically as standalone under a Data Vault modeling lens. In practice this means the table exhibits no documented foreign key dependencies and could be modeled as an isolated structure rather than a hub, link, or satellite. The absence of inbound or outbound FK relationships is consistent with a temporary staging surface whose rows are keyed only by their own surrogate identifier.

Key Information Stored

The table is documented with 15 columns and a single unique index, PAY_RANGE_TEMP_PK, defined on RANGE_ID. RANGE_ID is the surrogate primary key and the sole documented unique-index candidate, meaning it is the only column positioned as a business-key candidate in the physical schema — though in a temporary table, its uniqueness is usually limited to the lifespan of the processing run rather than enforced across time.

• RANGE_ID — Surrogate primary key (PAY_RANGE_TEMP_PK); identifies each staged range record.
• RANGE_TABLE_NUMBER — Groups rows belonging to a particular range table or tax table set, tying staged rows back to their parent range definition.
• ROW_VALUE_UOM — Unit of measure for the row value, distinguishing how band boundaries are interpreted.
• PERIOD_FREQUENCY — Indicates the payroll period frequency (for example, weekly, biweekly, or monthly) that the band applies to.
• EARNINGS_TYPE — Associates the range record with a specific earnings or element classification, scoping the band to relevant pay components.
• LOW_BAND and HIGH_BAND — The lower and upper thresholds defining the range interval.
• AMOUNT1 through AMOUNT8 — A set of eight generic numeric amount columns holding the tax, rate, or value figures associated with each band; the wide AMOUNT1–AMOUNT8 series reflects the multi-bracket, multi-basis nature of tax table calculations.

Common Use Cases and Queries

The primary use case is diagnostics and reconciliation of tax table processing runs. Because rows are written before final commit, DBAs and payroll technical consultants query the table to verify what an engine staged, to detect incomplete or failed loads, or to compare staged bands against the permanent configuration.

SELECT range_id, range_table_number, period_frequency,
       earnings_type, low_band, high_band,
       amount1, amount2, amount3
FROM   hr.pay_range_temp
WHERE  range_table_number = :p_range_table_number
ORDER  BY low_band;

A second scenario groups staged rows by range table to confirm expected band coverage and detect gaps between HIGH_BAND and the next LOW_BAND. Because the table is temporary, queries should also consider run context and timing — rows from an earlier run may persist until cleaned by the next execution or truncation.

Related Objects

The documented metadata records PAY_RANGE_TEMP as a standalone table with no foreign key relationships, so no join columns can be asserted from ETRM facts alone. Logical associations, inferred from its stated purpose of staging tax table data, include the permanent payroll range and tax table definitions that consume its rows, the earnings types referenced by EARNINGS_TYPE, and the period frequency values referenced by PERIOD_FREQUENCY. In EBS environments these typically resolve to payroll tax range and calculation tables within the PAY schema, along with the concurrent program that populates PAY_RANGE_TEMP during tax table processing. Any join key should be confirmed against the target object, since the ETRM data does not document an enforced foreign key constraint on this table.