Results for “hxt_tasks”

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

Overview

HXT_TASKS is a table in the Oracle E-Business Suite Time and Labor (HXT) product module, owned by the HXT schema and holding VALID status in both 12.1.1 and 12.2.2. The ETRM documentation describes the object as "a divided project assigned to an employee," indicating that it stores the task-level breakdown of a project structure used by Time and Labor to capture, validate, and report time against granular work assignments. Within the Time and Labor data model, HXT_TASKS functions as the subordinate grouping beneath HXT_PROJECTS, allowing organizations to track effort at a finer level than the project header.

From a heuristic Data Vault modeling perspective, the mined foreign-key structure classifies HXT_TASKS as satellite-leaning. The single documented foreign key to HXT_PROJECTS suggests the table hangs off a project hub or link and carries descriptive, time-bounded attributes. This classification is a modeling suggestion only; the table is a native Oracle EBS transactional entity, not a Data Vault construct. The documented physical schema for 12.2.2 contains 14 columns.

Key Information Stored

The table is keyed by HXT_TASKS_PK, a composite primary key defined on ID and PRO_ID, where ID is the surrogate identifier for the task record and PRO_ID links to the parent project in HXT_PROJECTS. A second unique index, HXT_TASKS_UK, spans PRO_ID and NAME, making the task name unique within a given project — the principal business-key candidate.

Core descriptive and control columns include:

• ID — surrogate task identifier, part of the primary key.
• PRO_ID — foreign key to HXT_PROJECTS; the owning project.
• NAME — the task name, unique within the project.
• TASK_NUMBER — the externally referenced task number used in UI and integrations.
• DESCRIPTION — free-text detail describing the task's scope.
• DATE_FROM / DATE_TO — the effective date range during which the task may be used for time entry.
• ESTIMATED_TIME — the planned or budgeted effort for the task.
• FCL_UNITS — units associated with the task, typically applied to flexible (FCL) entry rules.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard EBS audit columns tracking record provenance and change history.

Common Use Cases and Queries

Typical uses include validating the task/project combinations available to an employee during timecard entry, reporting burden or effort by task, and auditing which tasks are active within a date window. Because task selection is project-driven, joins back to HXT_PROJECTS are fundamental.

Example: list active tasks for a project.

• SELECT t.id, t.name, t.task_number, t.estimated_time, t.date_from, t.date_to FROM hxt.hxt_tasks t WHERE t.pro_id = :project_id AND trunc(sysdate) BETWEEN t.date_from AND nvl(t.date_to, sysdate);

Example: reconcile tasks to their owning project.

• SELECT p.name AS project_name, t.name AS task_name, t.task_number FROM hxt.hxt_projects p, hxt.hxt_tasks t WHERE p.pro_id = t.pro_id;

These patterns support reporting on planned versus actual effort and on task availability for a given pay period or date range.

Related Objects

The documented relationship data links HXT_TASKS primarily to its parent project structure and to downstream time-entry transactions.

• HXT_PROJECTS — joined via HXT_TASKS.PRO_ID = HXT_PROJECTS.PRO_ID; the principal parent. The FK HXT_TASKS.PRO_ID references HXT_PROJECTS.
• HXT_TASK_DETAILS / time-entry detail tables — task records are referenced by timecard line detail records that capture hours against a specific project and task combination.
• HXT_TIME_ENTRY / OTL timecard interfaces — validation and retrieval of valid tasks during time entry.
• HXT_TASKS_PK and HXT_TASKS_UK indexes — supporting unique access paths on (ID, PRO_ID) and (PRO_ID, NAME) respectively.

Because the ETRM metadata identifies only HXT_PROJECTS as a documented foreign-key target, that relationship should be treated as authoritative; additional dependent objects should be confirmed against the live 12.1.1/12.2.2 schema before reliance.