Results for “per_checklists”

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

Overview

PER_CHECKLISTS is the HR schema table that defines checklist templates within Oracle E-Business Suite Human Resources. A checklist is a reusable, named grouping of tasks that must be performed against a person, assignment, or other HR entity — for example a new-hire onboarding checklist, a termination checklist, or a transfer checklist. The table stores the checklist header (identity, name, category, and descriptive text) while the individual task lines are held in the companion table PER_TASKS_IN_CHECKLIST. At runtime, a template defined here is copied into PER_ALLOCATED_CHECKLISTS, which represents an actual checklist instance attached to a specific person or assignment.

PER_CHECKLISTS is owned by the HR schema and is a core reference/definition object in the PER (Human Resources) product. It is multi-tenant within EBS in the sense that every row is scoped to a business group through BUSINESS_GROUP_ID, allowing different enterprises (and different legislative setups) to maintain their own checklist libraries. The columns LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATED_BY, CREATION_DATE, and OBJECT_VERSION_NUMBER implement standard EBS audit and optimistic-locking conventions, and the 20 ATTRIBUTE and 20 INFORMATION flexfield columns provide DFF and descriptive flexfield extensibility (with INFORMATION_CATEGORY as the context column).

The mined Data Vault classification is hub-leaning. In a Data Vault model, PER_CHECKLISTS would most naturally be represented as a hub, since CHECKLIST_ID is a stable, unique business key and the table is referenced by multiple dependent tables. Its descriptive columns (NAME, DESCRIPTION, checklist attributes) would be carried in an accompanying satellite, while the business group relationship and task membership would be modeled as links.

Key Information Stored

The table contains 54 documented columns. The most significant are:

• CHECKLIST_ID — the surrogate primary key (PER_CHECKLISTS_PK) and the sole unique index candidate. It is the value propagated to all child tables.
• NAME — the user-visible checklist template name.
• DESCRIPTION — free-text explanation of the checklist's purpose.
• CHECKLIST_CATEGORY — classifies the checklist (for example onboarding, offboarding, or other HR-process groupings).
• EVENT_REASON_ID — links the checklist to the HR event reason that triggers it.
• BUSINESS_GROUP_ID — the foreign key to HR_ALL_ORGANIZATION_UNITS that scopes the checklist to an enterprise/business group.
• OBJECT_VERSION_NUMBER — optimistic-locking version counter used by the HR APIs.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATED_BY, CREATION_DATE — standard EBS audit trail.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE20 — descriptive flexfield context and segments.
• INFORMATION_CATEGORY and INFORMATION1–INFORMATION20 — additional developer/extension attributes (often called the "information" flexfield).

The surrogate key CHECKLIST_ID is the only documented unique index; NAME is not documented as unique, so two business groups may reuse the same checklist name.

Common Use Cases and Queries

Typical reporting and integration scenarios include listing all active checklist templates for a business group, finding checklists tied to a specific event reason, and drilling from a template into its task lines.

• Retrieve checklist headers by category for a business group: SELECT checklist_id, name, checklist_category FROM per_checklists WHERE business_group_id = :p_bg_id AND checklist_category = :p_cat ORDER BY name;
• Join template to its tasks: SELECT c.name, t.* FROM per_checklists c, per_tasks_in_checklist t WHERE c.checklist_id = t.checklist_id AND c.checklist_id = :p_id;
• Report assigned instances against their source template: SELECT a.allocation_id, c.name FROM per_allocated_checklists a, per_checklists c WHERE a.checklist_id = c.checklist_id;
• Audit newly created templates: SELECT checklist_id, name, created_by, creation_date FROM per_checklists WHERE creation_date >= :p_from;

Because the table carries a DFF, reporting queries commonly extract ATTRIBUTE1–ATTRIBUTE20 and INFORMATION1–INFORMATION20 with a flexfield view (for example the generated _DFV view) rather than reading raw segments.

Related Objects

• PER_TASKS_IN_CHECKLIST — child table holding the tasks belonging to each checklist; joined on CHECKLIST_ID. This is the dependency that makes a checklist meaningful.
• PER_ALLOCATED_CHECKLISTS — the allocated/instance table referencing PER_CHECKLISTS.CHECKLIST_ID, capturing checklists actually assigned to people or assignments.
• HR_ALL_ORGANIZATION_UNITS — parent table for BUSINESS_GROUP_ID, providing the enterprise scoping of the checklist library.
• OKL_LEASEAPP_TEMPL_VERSIONS_B — an Oracle Lease Management table that also references CHECKLIST_ID, an example of cross-product reuse.
• PER_CHECKLIST_API / HR_CHECKLIST_* PL/SQL APIs — the supported programmatic interfaces for creating and maintaining checklist templates, which should be used instead of direct DML against this table.