Search Results pay_us_garn_fee_rules_f




Overview

PAY_US_GARN_FEE_RULES_F is a date-tracked (effective-dated) configuration table within the Oracle E-Business Suite Payroll (PAY) module, owned by the HR schema. It stores the fee rules that govern how garnishment processing fees are calculated and applied to employee pay, deductions, and third-party disbursements for United States legislative garnishments. Because garnishment fee treatment varies by state and by garnishment category, this table provides the rules engine inputs that Oracle Payroll consumes during the garnishment calculation phase of a payroll run.

The table carries a Data Vault classification (heuristic, mined from the foreign-key structure) of standalone. In dimensional-modeling terms this suggests the table behaves as an independent reference/satellite object rather than participating in a hub-and-link structure with other payroll entities. It has no documented outgoing foreign keys to other business objects, which is consistent with a self-contained rules lookup keyed by business attributes (state and garnishment category).

Key Information Stored

The table consists of 19 physical columns. The most significant are listed below. Effective-dating is central: EFFECTIVE_START_DATE and EFFECTIVE_END_DATE bound the validity window of each rule, allowing the application to track historical changes without losing prior configurations.

  • FEE_RULE_ID — Surrogate primary key, uniquely identifying a fee rule record. Combined with the effective dates in PAY_US_GARN_FEE_RULES_F_PK.
  • STATE_CODE and GARN_CATEGORY — Together these form the alternate unique key (PAY_US_GARN_FEE_RULES_F_UK2) with the effective dates and ZD_EDITION_NAME. They determine which rule applies to a given state and garnishment type.
  • FEE_RULE — The rule identifier or rule type controlling how the fee is derived (for example, flat amount versus percentage).
  • FEE_AMOUNT — The fixed fee amount applied when the rule calls for a flat charge.
  • ADDL_GARN_FEE_AMOUNT — An additional or secondary fee amount layered on top of the base fee.
  • MAX_FEE_AMOUNT — The ceiling cap on the fee that may be charged, protecting the employee from excessive withholding.
  • PCT_CURRENT — The percentage applied when the fee rule is expressed as a proportion of current pay or earnings.
  • CORRESPONDENCE_FEE — Fee charged for correspondence or notification activity associated with the garnishment.
  • TAKE_FEE_ON_PRORATION — Flag indicating whether the fee is taken on a prorated basis when the garnishment is only partially funded in a pay period.
  • CREATOR_TYPE — Identifies the origin or type of the creating entity for the rule.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATED_BY, CREATION_DATE — Standard WHO audit columns.
  • ZD_EDITION_NAME — The Oracle Data Vault / e-Business Suite edition column, present in all unique indexes and supporting multi-tenant or editioned deployments.

The surrogate key (FEE_RULE_ID plus effective dates) should be distinguished from the business-key candidates: STATE_CODE plus GARN_CATEGORY plus effective dates (UK2) represents the natural/business identifier a functional user would recognize.

Common Use Cases and Queries

The principal use case is validating which fee applies to a garnishment order for a specific state and category as of a payroll date. A typical query resolves the effective-dated row:

  • Retrieving the active fee rule for a state and garnishment category as of a given date, filtering on STATE_CODE, GARN_CATEGORY, and the effective-date range.
  • Reporting the full fee history for a state/category to audit fee changes over time, ordering by EFFECTIVE_START_DATE.
  • Reconciling garnishment deduction amounts against MAX_FEE_AMOUNT and FEE_AMOUNT to confirm caps were honored.
  • Identifying rules where PCT_CURRENT or TAKE_FEE_ON_PRORATION drive variable, earnings-based fees, useful for downstream deduction calculations.
  • Data-conversion and configuration audit queries confirming that every active STATE_CODE/GARN_CATEGORY combination has a current (non-expired) rule.

A representative SQL pattern selects FEE_RULE_ID, FEE_RULE, FEE_AMOUNT, MAX_FEE_AMOUNT, and PCT_CURRENT where STATE_CODE and GARN_CATEGORY match the target and SYSDATE falls between EFFECTIVE_START_DATE and EFFECTIVE_END_DATE.

Related Objects

The documented metadata classifies this table as standalone with no explicit foreign-key relationships, so the following are the objects most likely to reference or depend on it in practice. Where join columns are documented, they are named; others are inferred from the garnishment processing model.

  • PAY_US_GARN_FEE_RULES_F_PK — Primary key index (FEE_RULE_ID, EFFECTIVE_START_DATE, EFFECTIVE_END_DATE, ZD_EDITION_NAME); enforces uniqueness on the surrogate key.
  • PAY_US_GARN_FEE_RULES_F_UK2 — Alternate unique index (STATE_CODE, GARN_CATEGORY, EFFECTIVE_START_DATE, EFFECTIVE_END_DATE, ZD_EDITION_NAME); the business-key constraint referenced during rule resolution.
  • Garnishment order and deduction tables within PAY (for example, the US garnishment order/deduction entities) that consume FEE_RULE_ID or the STATE_CODE/GARN_CATEGORY combination to determine fee treatment during a payroll run.
  • Payroll deduction and calculation elements whose processing logic reads FEE_AMOUNT, MAX_FEE_AMOUNT, and PCT_CURRENT to compute the payable fee.
  • Payroll legislative data group and state configuration objects that supply STATE_CODE context.
  • Oracle Payroll garnishment calculation APIs and concurrent programs that apply these rules during fee determination.

Because the table is confined to garnishments and independently keyed, changes to its rows directly affect garnishment fee outcomes and should be managed through controlled, effective-dated updates rather than destructive modifications.