Results for “pbm_attribute1”

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

Overview

BEN_PL_R_OIPL_PREM_BY_MO_X is a reporting view in the Oracle E-Business Suite Advanced Benefits (BEN) module, owned by the APPS schema. Its purpose is to expose premium-by-month detail records that are currently in force, presenting a date-filtered, read-only projection of the premium calculation data held in the underlying base table. The trailing _X convention signals a translated or reporting-oriented view designed for query and integration consumption rather than for direct DML.

The view is bounded by the effective dating pattern standard across Oracle HRMS and Benefits objects. It filters on TRUNC(SYSDATE) falling between EFFECTIVE_START_DATE and EFFECTIVE_END_DATE, meaning it always returns only those premium rows whose date-tracked version is current as of the run date. This makes it well suited to point-in-time reporting, concurrent programs, and downstream extracts that require the active record without additional date predicates.

The name reflects its business content: PL for plan, R for the rate or result designation, OIPL for the originating premium calculation context, and PREM_BY_MO for premium-by-month. Each row represents a premium amount for a given month and year within a plan's calculation lifecycle.

Underlying Base Objects

The view is defined over a single documented base object, BEN_PL_R_OIPL_PREM_BY_MO_F, referenced through a synonym. The _F suffix identifies this as the full (date-tracked) transactional table holding all effective-dated versions of each premium-by-month record. The view selects every column exposed by the base table's attribute set.

Because the base table is date-tracked, it can contain multiple rows per logical record across different date ranges. The view narrows this to the single currently effective row per record, driven by the SYSDATE predicate. The view is therefore not a join or aggregation, but a filtered pass-through that simplifies currency-of-record queries.

Key Columns

The view exposes the full set of premium-by-month attributes:

• PL_R_OIPL_PREM_BY_MO_ID — Primary identifier for the premium-by-month record.
• EFFECTIVE_START_DATE / EFFECTIVE_END_DATE — The date-track bounds establishing record validity.
• MNL_ADJ_FLAG — Indicates whether a manual adjustment was applied to the calculated premium.
• MO_NUM and YR_NUM — The month and year to which the premium figure applies.
• VAL — The premium value or amount.
• UOM — Unit of measure for the value.
• PRTTS_NUM — Participant number associated with the premium.
• ACTL_PREM_ID — Reference to the actual premium record.
• BUSINESS_GROUP_ID — The business group (HR operating unit) owning the record.
• PBM_ATTRIBUTE_CATEGORY and PBM_ATTRIBUTE1 through PBM_ATTRIBUTE30 — The descriptive flexfield segment set. This is the region relevant to the search term pbm_attribute1, which is the first of thirty DFF columns carried through from the base table.
• Standard WHO and concurrency columns — LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATED_BY, CREATION_DATE, and OBJECT_VERSION_NUMBER.
• Concurrent program context — REQUEST_ID, PROGRAM_ID, PROGRAM_APPLICATION_ID, PROGRAM_UPDATE_DATE, and COST_ALLOCATION_KEYFLEX_ID.

Common Use Cases and Queries

The view supports premium auditing, monthly cost reporting, and extracts into payroll or carrier interfaces. The most common pattern retrieves active premium rows for a business group and period:

• Retrieving current premiums for a participant: SELECT prtts_num, yr_num, mo_num, val, uom FROM apps.ben_pl_r_oipl_prem_by_mo_x WHERE business_group_id = :p_bg_id AND prtts_num = :p_person;
• Reviewing flexfield-tagged records using the searched attribute: SELECT pl_r_oipl_prem_by_mo_id, yr_num, mo_num, val, pbm_attribute1 FROM apps.ben_pl_r_oipl_prem_by_mo_x WHERE pbm_attribute1 = :p_value;
• Identifying manual adjustments: SELECT * FROM apps.ben_pl_r_oipl_prem_by_mo_x WHERE mnl_adj_flag = 'Y' AND business_group_id = :p_bg_id;

Because the view applies the SYSDATE filter internally, no date predicate is required. Queries needing historical versions must target the _F base table directly. All access should respect business group security to ensure data segregation across operating units.