Search Results pay_us_county_tax_info_f




Overview
Explore in AI Chat

Overview

The PAY_US_COUNTY_TAX_INFO_F table resides in the HR schema and belongs to the Oracle Payroll (PAY) product family. It is classified as a date-tracked (suffix "_F") table that holds United States county-level tax information used during payroll processing and tax calculation for US-based employees. Within Oracle EBS 12.1.1 and 12.2.2, this object supplies the jurisdiction-specific rate and withholding definitions that payroll runs consult when computing county, head, and school district taxes for a given jurisdiction.

The ETRM metadata classifies this object as standalone under the heuristic Data Vault model. No foreign-key relationships were mined, suggesting the table functions as an independent reference container rather than a transactional link between other entities. In Data Vault terms, it is best modeled as a reference or hub-like structure keyed on county tax information identity and jurisdiction code, with date-tracked effective dating that approximates a satellite.

Key Information Stored

The table's primary key is PAY_US_COUNTY_TAX_INFO_F_PK, defined on COUNTY_TAX_INFO_ID, EFFECTIVE_START_DATE, EFFECTIVE_END_DATE, and JURISDICTION_CODE. The metadata also documents a unique index that extends this business key candidate with ZD_EDITION_NAME (a date-effective edition discriminator used by the DateTrack/ZD framework), which is the strongest candidate for the true business key.

  • COUNTY_TAX_INFO_ID — surrogate identifier for each county tax record; first component of the primary key.
  • EFFECTIVE_START_DATE / EFFECTIVE_END_DATE — DateTrack effective-dating boundaries that control which version of a record applies on a payroll run date.
  • JURISDICTION_CODE — the tax jurisdiction the record describes; together with the effective dates it forms the natural business key.
  • COUNTY_TAX, HEAD_TAX, SCHOOL_TAX — the core tax rate/amount fields for county, head (per-capita) and school district taxes.
  • ZD_EDITION_NAME — the DateTrack edition identifier used in the unique index for 12.2.x date-effective editions.
  • CNTY_INFORMATION_CATEGORY and CNTY_INFORMATION1..30 — the flexfield (DFF) descriptive segments storing additional jurisdiction-defined tax attributes.
  • CNTY_ATTRIBUTE1..20 — developer-defined attribute columns retained for extensibility.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATED_BY, CREATION_DATE — standard WHO audit columns.
  • REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — concurrent program audit trail identifying the process that created or last updated the record.

Common Use Cases and Queries

The primary use case is payroll tax calculation and rate verification. Payroll administrators and tax analysts query this table to confirm the county, head and school tax values applied for a jurisdiction on a given pay date. Common reporting includes jurisdiction rate extracts, effective-dated change audits, and validation of DFF information.

  • Retrieve the current effective tax record for a jurisdiction: SELECT county_tax, head_tax, school_tax FROM pay_us_county_tax_info_f WHERE jurisdiction_code = :p_jurisdiction AND TRUNC(SYSDATE) BETWEEN effective_start_date AND effective_end_date;
  • Audit historical rate changes by ordering on effective_start_date for a given county_tax_info_id.
  • Report tax setup by DFF category using cnty_information_category and the cnty_information segments.

Related Objects

The metadata documents no foreign-key relationships, so this table is largely referenced through jurisdiction code and county tax information ID at runtime rather than through enforced constraints. The most significant related objects are the payroll tax calculation processes and the jurisdiction definitions that share the JURISDICTION_CODE value, along with the DateTrack edition infrastructure that governs effective-dated editions via ZD_EDITION_NAME. Payroll run results and tax reporting extracts depend on the rates sourced here, joining on jurisdiction code and effective date range. Because FK data was not mined, integration should be validated against the actual EBS schema before relying on implied relationships.