Search Results per_proposal_question_types




Overview
Explore in AI Chat

Overview

PER_PROPOSAL_QUESTION_TYPES is a Human Resources (PER) module table in Oracle E-Business Suite that stores the master definitions of generic web offer questions. In EBS 12.1.1 and 12.2.2, it functions as the reusable question library underpinning the recruiting and offer-management workflow, where recruiters, hiring managers, and applicants answer configured questions during the offer or proposal process. Each row defines one question along with its presentation, formatting, default-value, and lookup behavior, so that the same question template can be attached to many offers without redefining its metadata.

From a Data Vault modeling perspective, the mined foreign-key structure classifies this table as hub-leaning. It behaves as a central reference point: the question type is the business entity, and the two dependent tables (answers and members) act as link or satellite structures pointing back to it. This classification is a heuristic suggestion derived from the FK topology rather than a documented Oracle design statement.

Key Information Stored

The table is owned by the HR schema and contains 24 documented columns. The primary key constraint is PER_PROPOSAL_QUESTIONS_TYPE_PK, which is built on the business-key candidate PROPOSAL_QUESTION_NAME together with the ZD_EDITION_NAME column. PROPOSAL_QUESTION_NAME is the natural identifier referenced by all dependent tables; ZD_EDITION_NAME supports multi-tenant or editioning semantics. No separate numeric surrogate key is documented, so the composite of these two columns serves as the effective unique identifier.

The most significant columns include:

Common Use Cases and Queries

The table is most commonly queried to inventory the question catalog, to diagnose how a specific offer question renders, and to verify which lookup or SQL source supplies its values. A typical reporting pattern joins it to PER_ASSIGN_PROPOSAL_ANSWERS to determine which questions were actually answered on an offer:

  • List all questions by type: SELECT proposal_question_name, full_text, html_type FROM hr.per_proposal_question_types WHERE type = :p_type;
  • Find list-driven questions: SELECT proposal_question_name, lookup_type, option_sql_text FROM hr.per_proposal_question_types WHERE lookup_type IS NOT NULL;
  • Resolve answers to question text: SELECT a.*, q.full_text FROM hr.per_assign_proposal_answers a, hr.per_proposal_question_types q WHERE a.proposal_question_name = q.proposal_question_name;

Because ZD_EDITION_NAME participates in the unique index, edition-aware queries should restrict on the appropriate edition when running in 12.2.x environments.

Related Objects

Two documented foreign keys reference this table through the PROPOSAL_QUESTION_NAME column, making them the principal dependent objects:

  • PER_ASSIGN_PROPOSAL_ANSWERS — stores the answers captured against each assigned offer; joined on PER_ASSIGN_PROPOSAL_ANSWERS.PROPOSAL_QUESTION_NAME = PER_PROPOSAL_QUESTION_TYPES.PROPOSAL_QUESTION_NAME.
  • PER_PROPOSAL_QUESTION_MEMBERS — associates question types with their member definitions; joined on PER_PROPOSAL_QUESTION_MEMBERS.PROPOSAL_QUESTION_NAME = PER_PROPOSAL_QUESTION_TYPES.PROPOSAL_QUESTION_NAME.

Additional PER objects such as the proposal and assignment tables that consume these questions through the answer and member tables complete the offer-question model, but the two FK relationships above are the documented dependents grounded in the ETRM metadata.