Results for “per_spinal_point_steps_v”

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

Overview

The APPS.PER_SPINAL_POINT_STEPS_V view is a database object within the Oracle E-Business Suite Human Resources (PER) module. As documented in the ETRM metadata for release 12.1.1 and 12.2.2, its primary purpose is to support the user interface. The view is not designed as a general-purpose reporting object; instead, it supplies the specific, session-aware data set that the Oracle Forms-based HR interface requires when administrators define or maintain spinal point steps associated with a grade spine.

Unlike a conventional reporting view that can be queried independently of runtime context, this view is highly dependent on the user's current session. It joins the base tables against FND_SESSIONS and filters rows by comparing the current session's effective date to each record's effective start and end dates. This design ensures that the form displays only the data valid as of the date the user is working with, honoring Oracle HRMS date-tracked (datetrack) behavior. Consequently, any external integration or ad hoc query against this view must satisfy the same session conditions; otherwise, it will return no rows.

Underlying Base Objects

The view is defined over three referenced objects, all resolved through APPS synonyms:

• PER_SPINAL_POINT_STEPS_F — the core datetracked table holding the definition of each spinal point step, aliased as SPS in the view text.
• PER_SPINAL_POINTS — the parent table describing the spinal point itself, aliased as SP.
• FND_SESSIONS — the Oracle Applications session table, aliased as FND, used to constrain results to the current user session's effective date.

The join conditions link SPS.SPINAL_POINT_ID to SP.SPINAL_POINT_ID, and require FND.SESSION_ID to equal USERENV('SESSIONID') while the session's EFFECTIVE_DATE falls between SPS.EFFECTIVE_START_DATE and SPS.EFFECTIVE_END_DATE. This combination produces a session- and date-filtered projection of spinal point steps, enriched with the descriptive spinal point value from the parent table.

Key Columns

The view exposes the full column list of the base steps table plus the SPINAL_POINT description from the parent. Notable columns include:

• STEP_ID — unique identifier for the spinal point step.
• SPINAL_POINT_ID — foreign key to the associated spinal point.
• GRADE_SPINE_ID — the grade spine to which the step belongs.
• EFFECTIVE_START_DATE / EFFECTIVE_END_DATE — datetrack boundaries controlling row validity.
• SEQUENCE — ordering of the step within the spine.
• SPINAL_POINT — descriptive value retrieved from PER_SPINAL_POINTS.
• BUSINESS_GROUP_ID — the business group (legislative) context.
• INFORMATION1 through INFORMATION30 and INFORMATION_CATEGORY — flexfield (DFF) segments for descriptive and legislative attributes.
• Audit columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN.
• Concurrent program columns — REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE.
• ROW_ID — the ROWID of the base steps row.

Common Use Cases and Queries

Because the view filters on USERENV('SESSIONID'), it is intended for use within an active Forms session. Standalone SQL run outside the EBS runtime will generally return no rows unless the session context is emulated. Practical uses include querying the currently effective steps for a given grade spine while logged into the application:

• Retrieving active steps for a spine: SELECT step_id, sequence, spinal_point FROM per_spinal_point_steps_v WHERE grade_spine_id = :spine_id ORDER BY sequence;
• Inspecting descriptive flexfield values: SELECT information1, information_category FROM per_spinal_point_steps_v WHERE spinal_point_id = :id;
• Validating datetrack windows for a business group: SELECT effective_start_date, effective_end_date FROM per_spinal_point_steps_v WHERE business_group_id = :bg_id;

For reporting and integration outside the Forms context, the datetrack-aware base table PER_SPINAL_POINT_STEPS_F joined to PER_SPINAL_POINTS is preferred, since it avoids the session dependency that restricts this view to interface support.