Results for “hxt_timecards_d”

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

Overview

HXT_TIMECARDS_D is a denormalized reporting view owned by the APPS schema in Oracle E-Business Suite, defined over the Time and Labor (HXT) timecard header table. Its purpose is to present timecard approval information in a form that is directly usable by reports, BI Publisher data templates, and integration extracts without requiring the caller to resolve the foreign keys that link a timecard to the person who approved it and to the application user who last modified the record. In Oracle EBS 12.1.1 and 12.2.2 the object is registered in ETRM as a VALID view under the HXT product, with referenced base objects including HXT_TIMECARDS_F, PER_PEOPLE_F, FND_USER_VIEW, and the HR_GENERAL, HR_PERSON_NAME, and HR_SECURITY packages.

The view is significant to users who search on approver_name, because that column is the human-readable identity of the approving person. Rather than storing an APPROVER_NAME column on the timecard itself, the view derives it at query time from PER_PEOPLE_F using the APPROV_PERSON_ID foreign key, applying the effective-dating predicate so that the name returned corresponds to the person record in effect at the time of approval.

Underlying Base Objects

The view text joins three primary sources. HXT_TIMECARDS_F is the Time and Labor timecard header entity and supplies the timecard ID, effective dates, approval timestamp, and the LAST_UPDATED_BY user identifier. PER_PEOPLE_F is the effective-dated person view; it is joined with an outer join (+) on APPROV_PERSON_ID = PERSON_ID and constrained by APPROVED_TIMESTAMP BETWEEN EFFECTIVE_START_DATE(+) AND EFFECTIVE_END_DATE(+), which preserves timecards that have not yet been approved. FND_USER_VIEW supplies the USER_NAME of the user who last updated the row, joined by an outer join on LAST_UPDATED_BY = USER_ID.

The package dependencies HR_GENERAL, HR_PERSON_NAME, and HR_SECURITY are inherited through PER_PEOPLE_F and govern how the person name is formatted and how row-level security is applied to person records. This means query results for APPROVER_NAME are subject to the same HR security profile restrictions as any other access to PER_PEOPLE_F in the responsibility being used.

Key Columns

• ID — The timecard header identifier from HXT_TIMECARDS_F. Serves as the join key back to the base timecard for detail-level reporting.
• EFFECTIVE_START_DATE / EFFECTIVE_END_DATE — The effective-dating range of the timecard header row itself, not of the approver.
• APPROVER_NAME — The formatted full name of the approving person, obtained from PER_PEOPLE_F.FULL_NAME via APPROV_PERSON_ID. This is the column most commonly used as a search or filter criterion.
• APPROVED_TIMESTAMP — The date and time the approval action was recorded. Also drives the effective-date lookup against PER_PEOPLE_F.
• LAST_UPDATE_DATE — Audit column indicating when the timecard row was most recently changed.
• LAST_UPDATED_BY — The FND user ID of the last modifier. Note that the view exposes the numeric user ID; the corresponding USER_NAME is selected in the view text but is not listed among the documented output columns, so callers generally join FND_USER separately when the login name is required.

Common Use Cases and Queries

Typical uses include approval audit reports, aging analysis of unapproved timecards, and extracts that feed downstream payroll or project costing interfaces where the approver identity must be carried alongside the timecard.

• Listing approved timecards with their approver and approval date for a date range.
• Identifying timecards that remain unapproved; because APPROVER_NAME comes from an outer join, it is NULL until approval occurs, which provides a convenient filter.
• Reconciling the LAST_UPDATED_BY user against FND_USER to identify who touched the record most recently.

A representative query filtered on the searched attribute follows:

SELECT id, approver_name, approved_timestamp, last_update_date
FROM apps.hxt_timecards_d
WHERE approver_name = :p_approver_name
AND approved_timestamp >= :p_from_date;

Because the view contains no responsibility-specific WHERE clause of its own, all HR security enforcement occurs through the underlying PER_PEOPLE_F access, and performance depends on the indexes supporting HXT_TIMECARDS_F and the effective-dated person join.