Results for “fl_tm_pt_tm_meaning”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

BEN_FL_TM_PT_TM_RT_D is a denormalized reporting view owned by the APPS schema within the Oracle Advanced Benefits (BEN) module. Its name decodes to "Flexible Time Period Time Rounding," exposing configuration rows that govern how the Benefits engine applies time-period rounding when calculating variable rate profiles, premiums, and other time-based benefit computations. The view carries the "- Retrofitted" designation in ETRM, indicating it was introduced or regenerated to bring legacy Advanced Benefits functionality into the current 12.1.1 and 12.2.2 data model naming conventions without altering the underlying base entity BEN_FL_TM_PT_TM_RT_F.

Because it is a view and not a table, it holds no data of its own; it presents a user-friendly projection of the base entity joined to lookup and profile lookups. This makes it suitable for BI Publisher reports, custom concurrent programs, Oracle Discoverer workbooks, and integration extracts where descriptive text is required instead of coded lookup values.

Underlying Base Objects

The ETRM 12.2.2 metadata documents the following referenced objects:

• BEN_FL_TM_PT_TM_RT_F (synonym) — the primary base table holding flexible time period time rounding rows, keyed by FL_TM_PT_TM_RT_ID with EFFECTIVE_START_DATE and EFFECTIVE_END_DATE for date-tracked changes.
• BEN_VRBL_RT_PRFL_F (synonym) — supplies VRBL_RT_PRFL_NAME, linking each rounding record to its variable rate profile.
• FND_USER (synonym) — resolves LAST_UPDATED_BY to the application user name via an outer join.
• HR_LOOKUPS (view) — referenced twice, once for the BEN_FL_TM_PT_TM lookup type (resolving FL_TM_PT_TM_MEANING) and once for the YES_NO lookup type (resolving EXCLD_MEANING).
• HR_API (package) — the standard HR security and date-tracking API package referenced in the view's dependency chain.

All joins to FND_USER, BEN_VRBL_RT_PRFL_F, and HR_LOOKUPS are outer joins (+), so rounding rows persist even when a lookup value or user is missing or end-dated.

Key Columns

• ROW_ID — the ROWID of the base row, useful for direct DML or de-duplication.
• FL_TM_PT_TM_RT_ID — primary identifier of the rounding record.
• EFFECTIVE_START_DATE / EFFECTIVE_END_DATE — date-track bounds; always filter these against SYSDATE or a parameter date for point-in-time reporting.
• EXCLD_MEANING — decoded YES/NO flag indicating whether the rounding rule is excluded (inactive) for the associated profile.
• ORDR_NUM — sequence controlling evaluation order when multiple rounding rules apply.
• FL_TM_PT_TM_MEANING — decoded flexible time period code (for example, Monthly, Quarterly) used to establish the rounding interval.
• VRBL_RT_PRFL_NAME — name of the variable rate profile the rounding rule is attached to.
• LAST_UPDATE_DATE, LAST_UPDATED_BY — audit columns; LAST_UPDATED_BY is supplemented by the corresponding FND_USER name.

Common Use Cases and Queries

Typical scenarios include auditing rounding configuration by profile, reproducing point-in-time benefit calculations for compliance reporting, and feeding external payroll or actuarial extracts.

Example — all active rounding rules with descriptive text as of today:

• SELECT FL_TM_PT_TM_RT_ID, VRBL_RT_PRFL_NAME, FL_TM_PT_TM_MEANING, EXCLD_MEANING, ORDR_NUM FROM BEN_FL_TM_PT_TM_RT_D WHERE SYSDATE BETWEEN EFFECTIVE_START_DATE AND EFFECTIVE_END_DATE ORDER BY VRBL_RT_PRFL_NAME, ORDR_NUM;

Example — non-excluded rules for a specific variable rate profile by name:

• SELECT R.ORDR_NUM, R.FL_TM_PT_TM_MEANING, R.LAST_UPDATE_DATE FROM BEN_FL_TM_PT_TM_RT_D R WHERE R.VRBL_RT_PRFL_NAME = :p_profile_name AND R.EXCLD_MEANING = 'No' AND TRUNC(SYSDATE) BETWEEN R.EFFECTIVE_START_DATE AND R.EFFECTIVE_END_DATE;

Example — audit extract of who last changed each rule:

• SELECT FL_TM_PT_TM_RT_ID, LAST_UPDATED_BY, LAST_UPDATE_DATE FROM BEN_FL_TM_PT_TM_RT_D ORDER BY LAST_UPDATE_DATE DESC;

Because the view is a read-only projection, all DML must target BEN_FL_TM_PT_TM_RT_F directly through the supported Benefits configuration forms or the corresponding public APIs, respecting the date-tracked effective dating enforced by the HR_API framework.