Results for “ben_bnft_vrbl_rt_v”

20 results




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

Overview

BEN_BNFT_VRBL_RT_V is a reporting and integration view owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It belongs to the BEN (Advanced Benefits) product family and presents benefit variable rate records in a date-effective, session-filtered form. The view is documented in the ETRM metadata as "Retrofitted," indicating that it was re-engineered to align with the multi-organization and effective-dating conventions used throughout the BEN schema in Release 12.

In the Oracle EBS reporting architecture, BEN_BNFT_VRBL_RT_V acts as a secure, effective-dated projection over the underlying benefit variable rate entity. It exposes the transactional columns of the base table while restricting rows to those effective on the session effective date. This makes it suitable for concurrent programs, Oracle Business Intelligence Publisher reports, and integration extracts that must return only currently applicable benefit variable rate configurations.

Underlying Base Objects

The view is defined over two referenced base objects, both accessed through APPS synonyms:

  • BEN_BNFT_VRBL_RT_F — the primary base table holding benefit variable rate records. Aliased as BVR in the view definition, it supplies all transactional and descriptive columns.
  • FND_SESSIONS — the Oracle Application Object Library session table, aliased as SE. It is joined to enforce the session effective date filter.

The join predicate is SE.SESSION_ID = USERENV('SESSIONID') combined with SE.EFFECTIVE_DATE BETWEEN BVR.EFFECTIVE_START_DATE AND BVR.EFFECTIVE_END_DATE. This pattern is the standard BEN effective-dating construct: the view returns only those variable rate rows whose date range encloses the current session's effective date, rather than requiring the caller to supply a date predicate.

Key Columns

The view exposes the following significant columns:

  • ROW_ID — the ROWID of the base table row, used for identifying and locking the underlying record.
  • BNFT_VRBL_RT_ID — primary identifier of the benefit variable rate record.
  • EFFECTIVE_START_DATE / EFFECTIVE_END_DATE — the date-effective range governing the validity of the record.
  • CVG_AMT_CALC_MTHD_ID — references the coverage amount calculation method applied to the variable rate.
  • VRBL_RT_PRFL_ID — identifies the variable rate profile associated with the record.
  • BUSINESS_GROUP_ID — the business group that owns the record, supporting multi-organization data segregation.
  • BVR_ATTRIBUTE_CATEGORY — the descriptive flexfield context (structure) for the record. This is the column most directly associated with the search term bvr_attribute_category.
  • BVR_ATTRIBUTE1 through BVR_ATTRIBUTE30 — the descriptive flexfield segment columns carrying user-defined attributes for the variable rate.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATED_BY, CREATION_DATE, OBJECT_VERSION_NUMBER — standard Oracle EBS audit and concurrency columns.
  • ORDR_NUM — ordering sequence for the variable rate record.

Common Use Cases and Queries

The view is typically queried where the current effective variable rate configuration must be retrieved without manual date handling. A representative query follows:

SELECT BVR_ATTRIBUTE_CATEGORY, BNFT_VRBL_RT_ID, VRBL_RT_PRFL_ID, BVR_ATTRIBUTE1
FROM APPS.BEN_BNFT_VRBL_RT_V
WHERE BUSINESS_GROUP_ID = :p_business_group_id;

Analysts investigating the bvr_attribute_category value use the view to group records by flexfield context and review how descriptive attributes are populated:

SELECT BVR_ATTRIBUTE_CATEGORY, COUNT(*)
FROM APPS.BEN_BNFT_VRBL_RT_V
GROUP BY BVR_ATTRIBUTE_CATEGORY;

Because the view applies the session effective-date filter automatically, callers should be aware that results depend on the FND_SESSIONS effective date of the executing session. In concurrent or integration contexts where a specific historical date is required, the base table BEN_BNFT_VRBL_RT_F should be queried directly with an explicit date predicate instead of relying on this view.