Results for “hxt_rotation_plan_id”

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

Overview

HXT_TIM_SUMMARY_FMV is a read-only Oracle EBS view owned by the APPS schema, classified under the HXT (Time and Labor) product family. In Oracle EBS 12.1.1 and 12.2.2 it exposes a consolidated, denormalized snapshot of timecard activity, linking each timecard record to the assignment, organization, payroll, time period, rotation plan, and approver context in which it was processed. The "_FMV" suffix conventionally denotes a "Flat/Formatted Materialized View" style object intended primarily for reporting and integration rather than for transactional processing.

Rather than forcing report developers to join the underlying HR and Time and Labor tables manually, the view pre-resolves the effective-dated relationships between people, assignments, time periods, and payrolls. This makes it a convenient single source for approved timecard summaries, approval audit trails, and organization-level time reporting. Because the view references only other views, synonyms, and packaged functions (not tables directly), it is a logical reporting layer, and its data always reflects the current state of the base tables at query time.

Underlying Base Objects

The view is defined over the following documented base objects:

• PER_PEOPLE_F — supplies person attributes (employee number, full name) and the approver's name via an outer join.
• PER_ASSIGNMENTS — provides the assignment, organization, and business group linkage.
• PER_TIME_PERIODS — provides the time period and its END_DATE, which anchors the effective-date logic.
• HXT_TIMECARDS — the primary transactional source (approval person, approval timestamp, timecard ID).
• HXT_PER_AEI_DDF_V — the assignment extra-information view supplying the rotation plan reference.
• HXT_ROTATION_PLANS — provides the rotation plan name.
• HR_ORGANIZATION_UNITS — supplies the organization name and organization business group.
• PAY_PAYROLLS_F — supplies the payroll ID and payroll name.
• HR_GENERAL / HR_PERSON_NAME / HR_SECURITY — packaged utilities and security referenced within the definition.

The joins rely heavily on the BETWEEN effective-date pattern, ensuring that each row reflects only the person, assignment, and rotation-plan versions valid as of the time period end date. The approver person is joined with an outer join, so timecards with no approver still appear.

Key Columns

• ORGANIZATION_ID / ORGANIZATION_NAME — the assignment's organization and its descriptive name.
• ASG_BUS_GRP_ID / ORG_BUS_GRP_ID / PAY_BUS_GRP_ID / EMP_BUS_GRP_ID / APP_BUS_GRP_ID — business group identifiers from each source, useful for multi-org security filtering.
• PERSON_ID / EMPLOYEE_NUMBER / FULL_NAME — the worker identity.
• TIM_ID / TIM_ROW_ID — the timecard identifier and its ROWID.
• TIME_PERIOD_ID / END_DATE — the time period and its end date.
• PAYROLL_ID / PAYROLL_NAME — the payroll the timecard is associated with.
• APPROV_PERSON_ID / APPROV_PERSON_NAME / APPROVED_TIMESTAMP — approval audit information.
• HXT_ROTATION_PLAN_ID / ROTATION_PLAN_NAME — rotation plan context where applicable.
• CREATED_BY / CREATION_DATE / LAST_UPDATED_BY / LAST_UPDATE_DATE / LAST_UPDATE_LOGIN — standard audit lineage columns.

Common Use Cases and Queries

This view is typically used for timecard approval reporting, organization roll-ups, and payroll-period reconciliation extracts.

• Approved timecards by organization: filter on ORGANIZATION_ID and APPROVED_TIMESTAMP IS NOT NULL to list approved entries.
• Approval audit trail: select EMPLOYEE_NUMBER, FULL_NAME, APPROV_PERSON_NAME, APPROVED_TIMESTAMP ordered by END_DATE.
• Payroll reconciliation: group by PAYROLL_NAME and END_DATE to count timecards per period.

Sample query:

SELECT employee_number, full_name, organization_name, payroll_name, end_date, approv_person_name, approved_timestamp FROM apps.hxt_tim_summary_fmv WHERE organization_id = :org_id AND approved_timestamp IS NOT NULL ORDER BY end_date;

Because the view performs several effective-dated joins, queries should always constrain ORGANIZATION_ID or a business-group column to maintain acceptable performance in large multi-org environments.