Search Results pay_pl_paye_details_f




Overview

PAY_PL_PAYE_DETAILS_F is a date-tracked (effective-dated) table residing in the HR schema and owned by the Oracle Payroll (PAY) product module. It stores the tax details of a Polish person — specifically the attributes required to compute Polish pay-as-you-earn (PAYE) income tax withholding for an employee or payroll assignment. The table is part of the Oracle EBS localization layer for Poland and is delivered in both release 12.1.1 and 12.2.2 with an identical documented column footprint of 21 columns.

The table follows the standard Oracle EBS "F" (federal/core) naming convention, indicating that it is a base, non-translated table, and it is protected by the date-effective pattern shared across HR and Payroll datetracked entities: rows are versioned by EFFECTIVE_START_DATE and EFFECTIVE_END_DATE. Its primary key, PAY_PL_PAYE_DETAILS_F_PK, is a composite of EFFECTIVE_END_DATE, EFFECTIVE_START_DATE, and PAYE_DETAILS_ID, which confirms the datetracked design.

Under the heuristic Data Vault classification supplied in the metadata, this object is modeled as standalone. In Data Vault terms, that suggests it is best treated as a satellite-like structure keyed by its own surrogate identifier and its effective dates, without a documented foreign-key dependency to a parent hub or link within the documented relationship set. Where a customer builds a Data Vault or dimensional model over EBS Payroll, this table would therefore likely be staged as a descriptive satellite attached to a person, assignment, or payroll-relationship hub resolved outside the documented FK graph.

Key Information Stored

The most significant columns fall into three logical groups: identity and datetracking, tax computation attributes, and standard EBS audit/WHO columns.

  • PAYE_DETAILS_ID — the surrogate identifier for the tax-detail record; it forms the leading component of the primary key together with the effective dates.
  • EFFECTIVE_START_DATE and EFFECTIVE_END_DATE — the datetrack boundaries that define the validity window of each tax-detail version. These two columns, together with PAYE_DETAILS_ID, constitute the unique index PAY_PL_PAYE_DETAILS_F_PK.
  • PER_OR_ASG_ID — the person or assignment identifier to which the tax details belong. Despite the absence of a documented foreign key, this is the de facto business link to the payroll person/assignment being taxed.
  • BUSINESS_GROUP_ID — the enterprise business group (legal employer) context for the record, used for multi-organization partitioning.
  • CONTRACT_CATEGORY — the contract category that governs which tax rule set applies to the person.
  • TAX_REDUCTION — the tax-reducing amount (for example, the Polish monthly tax-free allowance) applied during withholding calculation.
  • TAX_CALC_WITH_SPOUSE_CHILD — a flag indicating whether the tax calculation is performed jointly with a spouse and/or child, a common Polish PAYE option.
  • INCOME_REDUCTION — the indicator controlling whether an income reduction applies.
  • INCOME_REDUCTION_AMOUNT — the monetary value of the income reduction.
  • RATE_OF_TAX — the tax rate used in the calculation for this effective version.
  • OBJECT_VERSION_NUMBER — the optimistic-locking version counter used by the Oracle Applications Framework (OAF) and PL/SQL DML to detect concurrent updates.

The remaining documented columns are the standard EBS "WHO" audit set and concurrent-program context: CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, PROGRAM_ID, PROGRAM_LOGIN_ID, PROGRAM_APPLICATION_ID, and REQUEST_ID. These describe who or what process created and last touched the row and are essential for reconciliation and support diagnostics.

Common Use Cases and Queries

PAYE_DETAILS_F is typically queried when diagnosing Polish payroll tax withholding, validating employee tax setups, or extracting a historical picture of a person's tax configuration for auditing or year-end reporting. Because the table is datetracked, almost every practical query anchors on a date and filters out the future-dated placeholder rows that EBS uses to close a datetrack window.

A representative pattern to retrieve a person's current Polish PAYE details:

  • SELECT paye_details_id, per_or_asg_id, contract_category, tax_reduction, rate_of_tax, income_reduction_amount FROM hr.pay_pl_paye_details_f WHERE per_or_asg_id = :p_person_or_assignment AND trunc(sysdate) BETWEEN effective_start_date AND effective_end_date;

A temporal query for the state at a prior payroll run uses the same predicate but substitutes the run's effective date. For extraction into a reporting schema, joining to person and assignment entities outside the documented FK set is required, since the metadata records no foreign key from PER_OR_ASG_ID. Reconciliation reporting compares the population of this table against payroll run results to confirm that each taxed assignment had a valid PAYE-detail row covering the payroll period. Exception reporting looks for overlapping or missing effective-date windows per PAYE_DETAILS_ID, and audit reporting selects the WHO columns and REQUEST_ID to trace which concurrent program introduced a change.

Related Objects

Because the metadata classifies this object as standalone, no explicit foreign keys are documented. The following are the most significant related objects by functional role and by the join keys implied in the schema:

Support and integration work should treat this table as a payroll-owned, datetracked configuration store for Polish tax attributes, accessed directly for reporting and managed through the Polish Payroll localization setup rather than through generic DML.