Results for “target_duration_uom”

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

Overview

PER_TASKS_IN_CHECKLIST is a Human Resources (PER) module table in the HR schema that stores the individual task definitions belonging to a checklist. Where PER_CHECKLISTS defines the container or header record, PER_TASKS_IN_CHECKLIST defines each ordered task that a checklist comprises — its name, description, mandatory status, target completion duration, associated action URL, and eligibility constraints. The object carries 60 documented columns in the ETRM 12.2.2 physical schema and is flagged as valid in both Oracle EBS 12.1.1 and 12.2.2.

In a heuristic Data Vault classification mined from its foreign key structure, PER_TASKS_IN_CHECKLIST is satellite-leaning. It attaches descriptive and contextual attributes to a parent checklist entity (PER_CHECKLISTS) rather than resolving a many-to-many relationship between independent hubs. Modelers should treat this as a suggestion derived from FK topology, not as an authoritative Data Vault designation.

Key Information Stored

The surrogate primary key is TASK_IN_CHECKLIST_ID, enforced by the unique index PER_TASKS_IN_CHECKLIST_PK. This is the sole documented business-key candidate unique index; no alternate unique constraint on business columns is identified in the metadata. The principal columns are:

• TASK_IN_CHECKLIST_ID — surrogate primary key identifying one task within a checklist.
• CHECKLIST_ID — foreign key to PER_CHECKLISTS; ties the task to its parent checklist.
• CHECKLIST_TASK_NAME — the display name of the task.
• DESCRIPTION — free-text detail describing what the task requires.
• MANDATORY_FLAG — indicates whether completion is required.
• TARGET_DURATION and TARGET_DURATION_UOM — the expected time to complete and its unit of measure.
• TASK_SEQUENCE — ordering of tasks within the checklist.
• ACTION_URL — the navigable action or link associated with the task.
• ELIGIBILITY_OBJECT_ID and ELIGIBILITY_PROFILE_ID — eligibility targeting for the task.
• AME_ATTRIBUTE_IDENTIFIER — approval management (AME) linkage used in routing.
• INFORMATION_CATEGORY and INFORMATION1–INFORMATION20 — a descriptive flexfield-style information block.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE20 — the standard EBS descriptive flexfield columns.
• OBJECT_VERSION_NUMBER, LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATED_BY, CREATION_DATE — the standard audit and optimistic-locking columns.

Common Use Cases and Queries

Typical usage centers on rendering and auditing the task list of a checklist, validating mandatory tasks, and reporting target durations. A common pattern joins the child tasks to their parent checklist:

• Tasks for a checklist: SELECT checklist_task_name, task_sequence, mandatory_flag FROM per_tasks_in_checklist WHERE checklist_id = :p_checklist_id ORDER BY task_sequence;
• Mandatory-task audit: SELECT checklist_id, COUNT(*) FROM per_tasks_in_checklist WHERE mandatory_flag = 'Y' GROUP BY checklist_id;
• Eligibility reporting: filter on eligibility_profile_id or ame_attribute_identifier to identify tasks routed through approval management.
• Change tracking: query by last_update_date and last_updated_by for delta extracts.

Because the action URL and eligibility columns drive runtime behavior, extracts feeding self-service checklist UI or AME routing should be validated against these fields.

Related Objects

• PER_CHECKLISTS — the parent table, joined on PER_TASKS_IN_CHECKLIST.CHECKLIST_ID = PER_CHECKLISTS.CHECKLIST_ID.
• PER_TASKS_IN_CHECKLIST_PK — the primary-key index on TASK_IN_CHECKLIST_ID.
• AME routing and eligibility APIs — consume AME_ATTRIBUTE_IDENTIFIER, ELIGIBILITY_OBJECT_ID, and ELIGIBILITY_PROFILE_ID for approval determination.
• Oracle HRMS self-service checklist/tasklist UI components — read TASK_SEQUENCE, CHECKLIST_TASK_NAME, and ACTION_URL to render tasks.
• Concurrent processing and HRMS extracts — query the table by CHECKLIST_ID for task-level reporting.

Direct DML against this table should generally be performed through supported Oracle HRMS APIs rather than SQL, because the audit columns and object version number are maintained by the application layer.